Principio de Menor Privilegio, Explicado

El menor privilegio suena obvio una vez que lo dices en voz alta: dale a una cuenta, proceso o usuario solo el acceso que necesita para hacer su trabajo, nada más. La brecha entre decir eso e implementarlo realmente en tus sistemas es donde la mayoría de las brechas se convierten de un incidente menor en un compromiso total del dominio.

Qué significa realmente

El principio de menor privilegio (PoLP) establece que cada sujeto en un sistema — un usuario, una cuenta de servicio, una aplicación, un contenedor — debe operar con el conjunto mínimo de permisos requeridos para completar su función. No los permisos que son convenientes. No los permisos que alguien otorgó hace tres años y olvidó revocar. El mínimo.

Esto aplica en cada capa: permisos del sistema de archivos, roles de base de datos, alcances de API, políticas de IAM en la nube, reglas de firewall, acceso sudo. Un proceso de servidor web leyendo archivos estáticos no necesita acceso de escritura a /etc. Un script de reportes que solo ejecuta consultas SELECT no necesita un rol de base de datos con derechos de DROP TABLE. Un pasante de marketing no necesita ser administrador del dominio porque era más fácil que averiguar el grupo correcto.

Por qué importa más de lo que parece

Cuando un atacante compromete una cuenta o un proceso, hereda todo lo que esa cuenta puede hacer. Si la computadora de un empleado phishing tiene acceso solo a los recursos compartidos relevantes para su equipo, el radio de explosión de ese phishing está contenido. Si esa misma cuenta resulta tener derechos de administrador del dominio porque TI la configuró así una vez para solucionar problemas y nunca revirtió los cambios, el atacante ahora es dueño de la red.

Esta es la lógica detrás de la mayoría de los reportes de análisis post-brecha: el acceso inicial fue de bajo valor, pero el movimiento lateral a través de cuentas con permisos excesivos lo convirtió en ransomware en todo el entorno. El privilegio excesivo no causa el compromiso inicial, pero es casi siempre lo que hace el compromiso costoso.

Dónde aparece en la práctica

IAM en la nube. AWS, Azure y GCP predeterminan a un comportamiento permisivo si no tienes cuidado — una política de IAM con "Action": "*" y "Resource": "*" pasará la validación y funcionará bien, hasta que una clave de acceso filtrada le da a un atacante control total de la cuenta. En su lugar, limita las políticas a acciones específicas y ARNs de recursos en lugar de usar comodines.

Cuentas de servicio. Estas son frecuentemente los peores infractores porque nadie las revisa de la manera que revisa las cuentas humanas. Un pipeline de CI/CD que despliega a un bucket S3 no debería tener credenciales que puedan leer cada bucket en la cuenta.

Roles de base de datos. Separa los roles de reportes de solo lectura de los roles de aplicación que necesitan INSERT/UPDATE, y separa esos del rol de DBA que puede alterar el esquema. PostgreSQL y MySQL ambos soportan declaraciones GRANT granulares — úsalas en lugar de darle a cada conexión de aplicación el equivalente a root.

Sudo y administrador local. La elevación just-in-time (solicita acceso, obtenlo por una ventana limitada, piérdelo automáticamente) supera los derechos de administrador permanentes cada vez. Herramientas como sudo con reglas limitadas en tiempo, o soluciones PAM en entornos empresariales, existen específicamente para esto.

La tensión con