IAM policy mishaps: Intro to IAM

Este post esta basado en la intro de la charla IAM policy mishaps: A cautionary tale of cloud misconfigurations que dimos el Sábado 27 de Enero en Sh3llCON (Reinosa) y va a ser el primero de una serie acerca de missconfigurations de IAM (si, por desgracia es un tema que da de si como para hacer una serie).

Poco a poco vamos llegando al final de las ponencias. Es el turno de Samuel y Andoni #IAM #sh3llcon2024 pic.twitter.com/azSbJVYCAp

— Sh3llCON (@Sh3llCON) January 27, 2024

Pero antes de nada, es de bien nacidos ser agradecidos, asi que tenemos que dar las gracias a la organización de Sh3llCON por contar con nosotros y a s4ur0n y Quasar por hacer de "puente" para ello. Fue un finde genial, trataremos de repetir.

Ahora si, hablemos de Cloud .

POLP

Todos conocemos el principio de mínimo privilegio, POLP por sus siglas en ingles (Principle Of Least Privilege):

Es el concepto por el que un usuario solo debe tener acceso a lo que necesita estrictamente para desempeñar sus responsabilidades, y nada más.

Después de un tiempo por la nube, me parece que es más fácil decirlo que hacerlo...

Cuando empezamos a estudiar yo recuerdo que para desplegar un WordPress la arquitectura era algo asi:

Fuente: Wikipedia

Es bastante fácil identificar todas las piezas, no? El server HTTP, el server de DNS, las diferentes redes, el router...

Ahora, si comprobamos la arquitectura de referencia de AWS para WordPress:

Fuente: AWS Docs

No quiero decir que sea intrínsecamente más complicado (o peor), pero como mínimo podemos decir que tiene más piezas: Cloudfront, S3, ALB, EC2, ElastiCache, Aurora, EFS, Internet y NAT Gateways, VPC…

Que por cierto, en ese diagrama no se incluye IAM, que es justo de quien vamos a hablar hoy, pero imagino que no era posible añadir más flechas.

IAM

IAM (Identity and Access Management) es un servicio de AWS que permite gestionar quien tiene accesos a los recursos en AWS. Lo típico: usuarios, grupos, políticas de accesos, etc

IAM Policies

Por si no estáis familiarizados con las policies IAM, un poco de contexto. Este es un ejemplo sencillo que da acceso ReadOnly a la consola de IAM:

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow", // (1)!
        "Action": [ // (2)!
            "iam:Get*",
            "iam:List*",
            "iam:Generate*"
        ],
        "Resource": "*" // (3)!
    }
}

1. Effect: Determinamos si estamos permitiendo o denegando el acceso.
2. Action: Acciones sobre la API de AWS que permitimos o denegamos.
3. Resource: Recursos sobre los que aplican estas condiciones.

Si habéis usando la consola de AWS habréis visto que diferentes servicios tienen UIs que solo se parecen por la gama de colores, verdad? Pues ahora imaginad eso con ficheros de JSON

Hablemos un poco más de las Actions... Preparando la charla decidimos buscar cuantas Actions diferentes existían:

Hace 6 años, 3852 actions.

Hace 3 años, 8191 actions.

Lo sentimos, pero ahora mismo no podemos mostrar archivos de este tamaño.

Enero de 2024, 16293 actions.

Por cierto, el 50% son de escritura. (Fuente: aws.permissions.cloud)

Pero no hemos venido solo a quejarnos, también traemos recomendaciones.

Como Monitor AWS Managed IAM Policies (MAMIP), al que os podéis suscribir directamente o como parte del AWS Weekly Digest para recibir los cambios que van haciendo en IAM.

Para terminar de comprender como funciona IAM necesitamos introduciros algunos concepto más.

Resource Policies

El primero de ellos son las Resource Policies. Estas políticas se pueden aplicar a algunos recursos, como S3 o SNS, y nos permiten conceder permisos a estos recursos cuando no tienen asociada una identidad de AWS. Servicios a los que por ejemplo, no puedes asociar un rol de IAM.

En caso de controlar la identidad, los permisos efectivos serán la suma de ambas.

AWS Organizations & SCPs

Continuamos con el de Organización de AWS (AWS Organizations).

AWS Organizations es un servicio desde el que puedes centralizar la gestión de tus cuentas y la configuración de algunos servicios como: billing, eventos de seguridad, políticas de backup...

Pero también nos permite aplicar políticas de IAM, llamadas Service Control Policies (SCPs), nuestras queridas SCPs...

Las SCPs se pueden aplicar a nivel de:

• Organization Aplica a todas las cuentas menos a la de management.
• Organizational Unit (OU) Aplica a todas las cuentas que cuelgan de ella.
• Cuenta Aplica solo a una cuenta.

Estas políticas actúan con las de identidad de la misma forma que las de recurso. Pero en este caso los permisos resultantes son la intersección de las políticas.

Esto se debe a que las SCPs no conceden permisos por sí mismas, por lo que siempre debe existir una política de identidad o de recurso.

Policy evaluation logic

Y por último, ¿en qué orden evaluamos todo esto? Este es el diagrama proporcionado por AWS, y como se indica en su documentación, no está completo.

Fuente: AWS Docs

Para evitar complicarlo demasiado, hemos hecho una versión más resumida incluyendo solo las condiciones que veremos a lo largo de esta serie:

Con esto hemos completado el curso rápido de IAM 101.

Si os preguntáis después de todo esto, ¿que es lo que queda por saber de IAM? Pues como mínimo: Boundaries, Service Roles, PassRole, AssumeRole, Usuarios Federados... Pero eso ya lo dejamos para otro día.

Para terminar os dejamos el enlace al repo donde hemos subido las slides de la charla y donde iremos subiendo el código de los casos prácticos.

En el próximo episodio? missconfigurations en S3.

Saludos, y que la fuerza os acompañe.