Límites de permisos de AWS para principiantes

Los límites de permisos de AWS son confusos. Sé que son confusos porque a mí me confundieron, y me tomó un par de años entenderlos. También sé que son confusos porque Corey Quinn lo dijo, y pidió que alguien los hiciera menos confusos.

Probablemente fracase, pero aquí va.

En resumen: las políticas normales de IAM le permiten hacer cosas, pero también pueden impedirle hacer cosas. Los límites de permisos solo le impiden hacer cosas. En general se usan para dejar que alguien administre algunas cosas de IAM, pero no tantas como para que pueda escalar privilegios (para sí mismo o para otra persona). Son un mecanismo de seguridad. Si permite que alguien administre IAM en una cuenta y no quiere que pueda escalar privilegios, ¡casi siempre necesita un límite de permisos!

La documentación oficial de AWS tiene mucho detalle, pero sigue siendo algo confusa. Esta publicación busca ayudarle a entender los conceptos y la razón por la que existen, no a conocer todos los detalles de cómo escribirlos (con una excepción).

Imagine que soy un niño de quinto grado, no un principiante, y explíquelos de nuevo

Bueno, si insiste.

Antes de los límites de permisos de IAM era MUY DIFÍCIL permitir que alguien administrara permisos de IAM sobre sus propios recursos sin crear un problema de seguridad al asignar demasiados permisos a algo como una instancia EC2 o… a sí mismo. El problema surgía sobre todo cuando quería permitirles escribir políticas de IAM y luego asignarlas. Es el problema de la administración delegada. “Permitir que alguien administre algunas cosas relacionadas con IAM, pero no esas otras cosas”.

Este es un escenario muy común. Los desarrolladores suelen crear un rol para una instancia, una función lambda o una tarea de contenedor en su stack de aplicaciones y luego asignar permisos a ese rol. Puede ser algo tan simple como permitir que una instancia lea datos de un bucket de S3. Resulta que esto es difícil de manejar desde el punto de vista de la seguridad:

• Si permite que el desarrollador escriba sus propias políticas, podría agregar privilegios excesivos… como *.*.
• Si permite que el desarrollador asigne políticas, podría adjuntar una política existente con demasiados permisos.
• Si permite que el desarrollador cree un rol nuevo Y asigne una política… tiene los mismos problemas.

Sí, podría hacer que el equipo de seguridad o un administrador de alto nivel se encargue de todo esto, pero es ineficiente. Los límites de permisos le permiten tener dos niveles de administradores de IAM: los de alto nivel con responsabilidad general sobre la seguridad, y los de nivel inferior que se encargan del día a día.

Un límite de permisos es simplemente una política de IAM que enumera los privilegios máximos que puede tener alguien o algo. Usted adjunta esa política y los desarrolladores que administran ese recurso nunca podrán otorgarle más permisos que los permitidos en el límite. Incluso puede permitir que el desarrollador cree nuevos roles y usuarios y les asigne permisos, pero exigiendo que todo lo que cree tenga ese límite de permisos. Así, nunca podrá crear ni modificar nada otorgándole más permisos de los que usted quiere.

No estoy seguro de que eso fuera para un niño de quinto grado, ¿me da un ejemplo?

Alice es la superadministradora de una organización de AWS. Debe supervisar cientos de cuentas, y cada cuenta tiene sus propios administradores locales y desarrolladores que se encargan de la construcción real de las aplicaciones.

Bob es uno de esos desarrolladores locales. Bob está creando una nueva aplicación y es más eficiente que él cree sus propios roles y políticas, ya que sabe lo que su aplicación necesita.

Alice decide permitir que Bob administre IAM para partes de su aplicación. En concreto:

• Bob puede escribir y asignar nuevas políticas de IAM con los permisos que necesitan sus instancias y funciones lambda.
• Hay otros servicios de AWS en uso que esos componentes nunca deberían tocar. Por lo tanto, no se pueden simplemente desactivar con una política de control de servicios. Eso interrumpiría esos servicios para los componentes que sí pueden usarlos.
• Bob no tiene permitido asignarse una nueva política a sí mismo.

Es un caso clásico de administración delegada: Bob puede administrar solo una parte de IAM. Aquí es donde se usaría un límite de permisos:

• Alice crea un límite de permisos “A” que permite accesos a los servicios de AWS con los que pueden comunicarse las instancias y funciones lambda de Bob (por ejemplo, S3, SNS, SQS).
• Alice crea un límite de permisos “B” que permite a Bob crear roles y políticas de IAM (y asignarlos), pero NO asignárselos a sí mismo.
• Alice le da a Bob permisos de IAM para crear y asignar nuevos roles y políticas, pero todo rol nuevo debe tener el límite de permisos “A”. Esto significa que esas instancias y funciones lambda NUNCA tendrán más permisos que los del límite, aunque pueden tener menos.
• Alice asigna el límite de permisos “B” a Bob para evitar que se asigne permisos a sí mismo. Ahora él no puede eliminar el requisito de implementar recursos con “A” aplicado.

Sí, hay varias maneras de abordar este problema… pero la versión corta es que cada vez que quiera permitir que alguien administre parte de IAM en una cuenta, probablemente necesite un límite de permisos si no quiere que haga demasiado.

¿Por qué una política de control de servicios no funciona aquí?

A veces una SCP podría funcionar, pero solo puede usar una SCP si está en una organización, mientras que un límite de permisos funciona en cualquier cuenta. Además, las SCP son muy buenas para cosas como limitar qué llamadas a la API se pueden hacer (y por lo tanto qué servicios de AWS se pueden usar), pero no están realmente pensadas para este nivel de granularidad y condicionales.

Piense en mi ejemplo anterior: puede que Alice tenga que conocer los identificadores de recursos para permitir el acceso a servicios en la cuenta, pero no desde los recursos creados por Bob. Hay maneras de manejar esto (por ejemplo, rutas de recursos), pero no son más simples que nuestro ejemplo de límite de permisos y no siempre funcionan, según las claves de condición admitidas.

En mi campo de entrenamiento de respuesta a incidentes uso una SCP para impedir que los usuarios administradores (los estudiantes) de las cuentas rompan mi acceso a nivel de Organizations y algunas otras cosas. Pero eso solo funciona porque les doy IAM completo y ya son uno de esos superadministradores. Si quisiera limitar su capacidad de crear recursos con permisos excesivos, necesitaría un límite de permisos o una SCP para restringirlos a asignar únicamente ciertas políticas preestablecidas.

¿No puedo simplemente usar políticas de denegación?

En realidad no. Lo intentamos antes de que existieran los límites de permisos y, más allá de la complejidad, había demasiados vacíos.

¿Me da otro ejemplo sencillo?

¡Claro que sí! Aquí hay uno que usamos nosotros mismos.

Algunos usuarios nos permiten hacer cambios de IAM en sus cuentas. Para eso usamos roles entre cuentas. Cuando los usuarios implementan el rol, aplican un límite de permisos que nunca nos deja cambiar nuestros propios permisos. Esto evita la escalada de privilegios.

Creo que lo entiendo, pero ¿cómo interactúan todas estas políticas de IAM?

Consulte la documentación de AWS sobre la lógica de evaluación de políticas, pero aquí están mis apuntes:

• Las políticas de control de servicios limitan lo que cualquiera puede hacer en una cuenta (por ejemplo, pueden activar y desactivar servicios).
• Las políticas de permisos de IAM permiten que usuarios y roles hagan cosas en una cuenta.
• Las políticas de recursos de IAM permiten que usuarios y roles interactúen con el recurso al que está adjunta la política.
• Los límites de permisos establecen los privilegios máximos que puede tener un usuario o un rol. No le permiten hacer cosas, pero pueden impedirle hacerlas.

Todas las políticas funcionan en conjunto. Para que usted pueda hacer algo, debe tener un permiso en algún punto del conjunto que lo autorice y no debe haber ninguna política de denegación en ninguna parte que se lo impida. Una sola denegación anula cualquier autorización, sin importar dónde se encuentre.

¿Cuándo debo usar límites de permisos?

Cuando quiera permitir que alguien administre parte de IAM en una cuenta, pero limitando hasta dónde, debería pensar en un límite de permisos.

Incluso cuando usa herramientas avanzadas de IAM como nuestro nuevo FireMon Authorization Control, es posible que aún quiera algunos límites de permisos, especialmente en cuentas muy sensibles.

¿Cuál es el único ejemplo que dijo que incluiría?

Aunque los límites de permisos están pensados para impedirle hacer ciertas cosas, aun así requieren que usted especifique todos los permisos de tipo allow. En otras palabras, si escribe un límite de permisos con una declaración DENY para bloquear lo único que no quiere que ese usuario o rol haga, de todos modos necesitaría una declaración ALLOW * o no podrá hacer nada.

Esta es la parte que me confundió al principio, ya que leí mal la descripción de Amazon y pensé que se podía usar un límite de permisos simplemente para bloquear acciones. Sí se puede, pero salvo por un caso de uso de políticas de recursos en el que no quiero entrar hoy, el límite de permisos también debe incluir todo lo que usted quiere permitir. No puede simplemente aplicar DENY a una cosa en el límite de permisos y ALLOW a otras cosas en la política de permisos de IAM habitual y esperar que funcione. El límite de permisos también debe tener las declaraciones ALLOW (y sí, hago trampa y a veces usaré ALLOW * aquí).

Sigo confundido

Envíeme un correo electrónico. En serio, estas cosas son realmente confusas.