Deja que la IA haga el trabajo pesado: Audita y crea políticas IAM con PartyRock
Después de haber auditado más de 100 cuentas diferentes de AWS, puedo decir que una de las áreas donde más fallan los equipos técnicos es…
Después de haber auditado más de 100 cuentas diferentes de AWS, puedo decir que una de las áreas donde más fallan los equipos técnicos es en la creación de políticas IAM seguras y con privilegios mínimos.
¿Te imaginas poder crear o auditar una política de IAM en AWS sin romperte la cabeza con permisos, acciones y recursos? Eso fue lo primero que pensé cuando vi que ahora puedes usar inteligencia artificial para generar políticas con privilegios mínimos, solo con un prompt.
En este post, voy a poner a prueba PartyRock y el complemento AWS IAMPolicyForge para ver si realmente la IA puede facilitarnos la vida (y si le confiaría la seguridad de mi cuenta en AWS). ¿Será el fin de las políticas mal configuradas o solo otro experimento más?
¡Te cuento mi experiencia real y cómo funciona esta herramienta en solo unos pasos!
Ejemplo con prompt genérico
Para poner a prueba el complemento IAMPolicyForge en PartyRock, utilicé el siguiente prompt en inglés:
I want to allow an EC2 instance to access an S3 bucket.
El objetivo era ver qué tan bien la IA entiende una solicitud simple y si realmente entrega una política con privilegios mínimos y bien definidos.
La política generada por la IA fue la siguiente:
{
"Version": "2012-10-17",
"Statement": [
{
// Allows listing the contents of the specific bucket
"Sid": "ListBucketAccess",
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": "arn:aws:s3:::my-example-bucket",
"Condition": {
"StringLike": {
"aws:UserAgent": "ec2.*"
}
}
},
{
// Allows reading and writing objects in the specific bucket
"Sid": "BucketObjectAccess",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::my-example-bucket/*",
"Condition": {
"StringLike": {
"aws:UserAgent": "ec2.*"
}
}
}
]
}
Explicación de la política generada
La política otorga a la instancia EC2 permisos mínimos para interactuar con un bucket S3 específico. El primer bloque permite listar los objetos dentro del bucket (s3:ListBucket), mientras que el segundo bloque permite leer, escribir y eliminar objetos en ese bucket (s3:GetObject, s3:PutObject, s3:DeleteObject).
Ambos bloques incluyen una condición que restringe los permisos para que solo se apliquen cuando el agente de usuario (UserAgent) corresponda a una instancia EC2, añadiendo una capa extra de seguridad y asegurando que los permisos no sean demasiado amplios. Esto demuestra que la IA es capaz de interpretar instrucciones genéricas y generar una política que sigue el principio de privilegios mínimos, algo que muchas veces se pasa por alto cuando se crean políticas manualmente.
La herramienta incluso nos da una versión aún más segura, pero como este post no será tan técnico, no abundare esta parte. Para serles sincero me gustó mucho el resultado. Pocas empresas que he evaluado tienen ese nivel de detalle en sus políticas IAM. Eso sí, aunque la IA generó una política mucho más segura de lo que suelo encontrar en la práctica, hay que tener cuidado: recuerden que la IA todavía no está al 100 % y siempre es recomendable revisar y validar manualmente lo que genera.
Para probar algo más avanzado, utilicé el siguiente prompt con la IA:
I want to allow a Lambda function to read items from a specific DynamoDB table, write logs to CloudWatch Logs, and read files from two different S3 buckets. Please generate an IAM policy with the minimum permissions required.
{
"Version": "2012-10-17",
"Statement": [
{
// Allow reading items from the specific DynamoDB table, only in us-east-1 and with the Production tag
"Sid": "DynamoDBReadAccess",
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:Query",
"dynamodb:Scan"
],
"Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/my-app-data",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "us-east-1",
"aws:RequestTag/Environment": "Production"
}
}
},
{
// Allow creating log streams and putting log events in CloudWatch Logs, only in us-east-1 and with the Production tag
"Sid": "CloudWatchLogsAccess",
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:us-east-1:123456789012:log-group:/aws/lambda/my-app-log-group:*",
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "us-east-1",
"aws:RequestTag/Environment": "Production"
}
}
},
{
// Allow listing contents of the S3 buckets
"Sid": "S3ListAccess",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": [
"arn:aws:s3:::app-bucket-1",
"arn:aws:s3:::backup-data-bucket"
]
},
{
// Allow reading objects from the S3 buckets, only in us-east-1 and with the Production tag
"Sid": "S3ReadAccess",
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": [
"arn:aws:s3:::app-bucket-1/*",
"arn:aws:s3:::backup-data-bucket/*"
],
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "us-east-1",
"aws:RequestTag/Environment": "Production"
}
}
},
{
// Deny access to DynamoDB and CloudWatch Logs in any other region
"Sid": "DenyOtherRegions",
"Effect": "Deny",
"Action": [
"dynamodb:*",
"logs:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": "us-east-1"
}
}
}
]
}
La IA generó una política que segmenta perfectamente los permisos para cada servicio, garantizando que la función Lambda solo pueda realizar acciones muy específicas:
- Permite leer datos únicamente de la tabla DynamoDB indicada.
- Permite escribir logs solo en el grupo de logs especificado de CloudWatch.
- Permite listar y leer objetos solo en los dos buckets S3 señalados, y además, restringe ese acceso a la región us-east-1 usando condiciones.
Además, la IA sugirió agregar una política Deny para bloquear el acceso a DynamoDB y CloudWatch Logs fuera de la región permitida, y una validación de tag usando RequestTag/Environment. Aquí debemos tener cuidado: la condición RequestTag/Environment solo es válida en acciones que permiten agregar etiquetas directamente en la solicitud (por ejemplo, creación de recursos). Por lo tanto, no tendría efecto en acciones de lectura o escritura simples como GetItem, GetObject o PutLogEvents. Lo correcto sería usar ResourceTag/Environment, que limita el acceso exclusivamente a recursos que ya tengan asignado el tag Environment=Production, ofreciendo así una protección real y efectiva.
Si bien es cierto que las políticas generadas por la IA fueron notablemente mejores y más seguras que muchas de las políticas que he visto al auditar más de un centenar de cuentas de AWS, es importante aclarar que aún presentan algunos errores o detalles técnicos que pueden pasar inadvertidos en un primer vistazo. Como hemos observado en este ejercicio, ciertas condiciones recomendadas por la IA no aplican correctamente según el contexto específico de las acciones, por lo que no debemos confiar ciegamente en ellas.
Dicho esto, estas herramientas son un excelente punto de partida. La inteligencia artificial no está al 100 % todavía en términos de precisión técnica y contextual, pero puede acelerar considerablemente nuestro trabajo, ahorrarnos tiempo y ayudarnos a evitar el síndrome de la “hoja en blanco” al crear políticas IAM desde cero.
Mi recomendación final es clara: usa la IA para generar un primer borrador o validar rápidamente ciertas políticas, pero siempre realiza una revisión manual cuidadosa antes de implementarlas en entornos productivos.