Si solo te llevas una idea de todo el capítulo de seguridad, que sea esta: el principio de mínimo privilegio. Es la regla de oro de la seguridad en la nube (y en toda la informática). Entenderla y aplicarla te ahorrará incidentes graves y es lo que distingue a un profesional de un principiante descuidado.

El principio de mínimo privilegio (least privilege) dice:

Da a cada usuario, servicio o aplicación SOLO los permisos que necesita para hacer su trabajo, y ni uno más.

Ni más permisos «por comodidad», ni más «por si acaso». Exactamente los necesarios, nada extra.

Analogía: Imagina un hotel. Al personal de limpieza le das una tarjeta que abre las habitaciones, pero no la caja fuerte ni la oficina del director. Al cocinero, acceso a la cocina, pero no a las habitaciones. Cada uno tiene acceso solo a lo que necesita para su trabajo. No le das a todo el mundo una llave maestra «para simplificar», porque sería un riesgo enorme.

La razón es simple: reducir el daño cuando algo sale mal. Y algo, tarde o temprano, sale mal.

Imagina dos escenarios con un usuario cuyas credenciales son robadas por un atacante:

El mínimo privilegio limita el radio de la explosión. Si una credencial se ve comprometida (y ocurre más de lo que crees), el atacante solo puede hacer lo poco que esa identidad podía hacer.

Ejemplo real (patrón común): Un desarrollador sube sin querer sus claves de acceso a un repositorio público de GitHub. Bots automáticos las detectan en segundos y las usan. Si esas claves tenían permisos de administrador, el atacante lanza decenas de servidores carísimos para minar criptomonedas y la víctima recibe una factura de miles de euros. Si las claves tenían permisos mínimos (solo leer un bucket), el atacante no puede hacer prácticamente nada. El mínimo privilegio convierte un desastre en un susto.

Aplicar el mínimo privilegio es una forma de pensar más que un botón. Estas son las pautas:

En AWS, por defecto, todo está denegado hasta que lo permites explícitamente. Aprovéchalo: parte de cero y añade solo los permisos que se demuestren necesarios, en vez de dar mucho y quitar después.

No des permiso sobre «todos los buckets» si solo se necesita uno. No des permiso sobre «todas las acciones» si solo se necesita leer.

Mal (demasiado amplio): «Puede hacer cualquier cosa con cualquier bucket de S3.» Bien (mínimo): «Puede leer objetos solo del bucket informes-2026.»

Dar AdministratorAccess (permiso total) es cómodo pero peligroso. Resérvalo para las poquísimas identidades que de verdad lo necesitan. La mayoría de usuarios y servicios necesitan mucho menos.

Como vimos en el subcapítulo 7.1, da a cada servicio (una instancia EC2, una función Lambda) un rol con exactamente los permisos que necesita, no más.

Los permisos tienden a acumularse («permission creep»). Revísalos periódicamente y quita lo que ya no se use. AWS tiene herramientas (IAM Access Analyzer, que veremos en el subcapítulo 7.5) que te dicen qué permisos se otorgan pero nunca se usan.

Seamos honestos: el mínimo privilegio da más trabajo que dar permisos amplios. Es tentador soltar un AdministratorAccess y olvidarse. Pero ese atajo es exactamente el origen de la mayoría de incidentes de seguridad graves.

Mentalidad correcta: un poco de incomodidad ahora (configurar permisos ajustados) a cambio de evitar un desastre después. Los profesionales asumen esa pequeña fricción como parte normal del trabajo bien hecho.

Un truco práctico para encontrar el equilibrio: empieza con los permisos que crees que se necesitan, ejecuta la aplicación, y si falla por falta de permisos, añade exactamente el que falta. Así llegas al mínimo real sin pasarte.

Este principio no es solo de IAM; lo has visto ya por todo el libro:

• Security Groups (Capítulo 4): abre solo los puertos necesarios.
• Subredes privadas (Capítulo 6): no expongas a internet lo que no lo necesita.
• Políticas de bucket S3 (Capítulo 5): da acceso solo a quien debe.

Es una filosofía transversal de toda la seguridad en la nube.

• Mínimo privilegio: da a cada identidad solo los permisos que necesita, ni uno más.
• Su objetivo es limitar el daño si una credencial se ve comprometida (reducir el «radio de explosión»).
• En la práctica: parte de cero, sé específico con acciones y recursos, evita permisos de administrador, usa roles para servicios y revisa periódicamente.
• Da algo más de trabajo que dar permisos amplios, pero ese pequeño esfuerzo previene desastres.
• Es una filosofía transversal: aplica también a redes, Security Groups y políticas de S3.

En el siguiente subcapítulo profundizaremos en cómo se escriben los permisos: las políticas basadas en identidad vs en recurso.