Asignar permisos de acceso según el principio de mínimo privilegio

Qué es

El principio de mínimo privilegio (least privilege) exige que una cuenta o un proceso tenga exactamente los permisos que requiere su tarea, no los que resultarían cómodos. Linux ofrece para ello herramientas más finas que el «root o no root»: las capabilities dividen los privilegios del superusuario en capacidades individuales; por ejemplo, CAP_NET_BIND_SERVICE permite por sí sola enlazar puertos por debajo del 1024, sin conceder nada más. En PostgreSQL, GRANT asigna permisos a roles por objeto y por acción (por ejemplo SELECT, INSERT, UPDATE, DELETE), y los roles pueden ser miembros de otros roles, de modo que los permisos se agrupan en lugar de repartirse uno a uno.

Por qué importa

El daño de un error o de una intrusión queda limitado por los permisos de la identidad afectada. Un servicio web con un rol que solo puede leer y escribir en dos tablas no puede borrar el esquema si sufre una inyección SQL. Un script que se ejecuta como usuario normal no puede vaciar el directorio raíz por un error tipográfico. Para los agentes automatizados esto se aplica con más razón: ejecutan instrucciones cuyo origen no siempre pueden evaluar, y sus permisos marcan el límite máximo del daño posible.

Cómo aplicarlo

• Una identidad propia por servicio y entorno: rol de base de datos propio, clave de API propia, usuario de sistema propio; nunca una cuenta «app» compartida para todo.
• Derivar los permisos de la tarea y documentarlos: ¿qué tablas, qué acciones, qué directorios, qué destinos de red? Todo lo demás no se concede. Las migraciones se ejecutan con un rol distinto y en un paso aparte.
• Iniciar los procesos sin root; si hace falta un privilegio de root, conceder solo la capability concreta y descartar las demás.
• Para las personas: cuenta estándar sin privilegios especiales, elevación solo temporal y con registro, y cuentas de administración separadas de la cuenta de uso diario.
• Denegación por defecto: los recursos nuevos son inaccesibles para todos hasta que alguien registre un permiso, y no al revés.
• Depurar con regularidad: retirar los permisos que llevan mucho tiempo sin usarse y eliminar el mismo día a las personas que se han ido y los servicios que se han apagado.

Trampas

Los permisos crecen: cada corrección de una incidencia añade uno y nadie lo retira después. Roles colectivos como «developer» con acceso a producción. El servicio tiene pocos permisos, pero su token de despliegue es administrador. Se considera inofensivo el acceso de lectura, aunque expone datos personales y secretos. El principio de mínimo privilegio limita el abuso de permisos ajenos, no el abuso de los propios, legítimos; para eso hacen falta registro de actividad y el principio de los cuatro ojos.