IAM controla qué identidades pueden realizar acciones sobre qué recursos. Es la base de seguridad de una infraestructura AWS.

Por qué importa en una infraestructura moderna

Una aplicación puede necesitar publicar en un tema SNS pero no modificarlo ni borrar colas. Un rol temporal con permisos concretos es mejor que guardar claves permanentes en el código.

Cómo utilizarlo correctamente

Una plantilla que crea roles IAM requiere una revisión especialmente cuidadosa y puede pedir confirmar capacidades. Aplica mínimos privilegios, MFA en cuentas humanas relevantes, credenciales temporales y registros de auditoría. Evita asignar permisos administrativos para solucionar errores sin analizarlos.

¿Cuándo conviene utilizar AWS IAM?

Es útil cuando resuelve una necesidad real de arquitectura; incluir todos los servicios en una plantilla solo porque existen añade complejidad, permisos y costes. Empieza con el flujo más pequeño posible, documenta las responsabilidades, trabaja primero en pruebas y crea alarmas de coste y operación.

Infraestructura como código con CloudFormation

Cuando haya que repetir el despliegue, usa una plantilla versionada que describa los recursos pertinentes y sus relaciones. Revisa los permisos antes de ejecutar cambios. Para aprender se puede empezar desde la consola de AWS y pasar a AWS CLI después.

Artículos de esta serie

Referencia oficial

Documentación de AWS sobre AWS IAM.

Ejemplo: tres identidades, tres responsabilidades

Un administrador humano puede revisar despliegues; una aplicación puede publicar mensajes SNS; una Lambda puede recibir y borrar mensajes de SQS. Los tres necesitan permisos diferentes. IAM permite definirlos sin dar a cada componente acceso de administrador. Antes de configurar una política, escribe las acciones necesarias, los ARN concretos y quién asumirá el rol.

Política de ejemplo limitada a una cola

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "sqs:ReceiveMessage",
      "sqs:DeleteMessage",
      "sqs:GetQueueAttributes"
    ],
    "Resource": "arn:aws:sqs:eu-west-1:111122223333:demo-queue"
  }]
}

El ARN es ficticio. Estos permisos no incluyen la escritura en CloudWatch Logs ni las operaciones KMS que una cola cifrada con clave propia podría requerir. Una política adjunta no basta si una política de denegación explícita, una política de organización o la política del recurso impide la operación.

Roles frente a claves de acceso

Para Lambda, utiliza un rol de ejecución que AWS asume temporalmente. Para herramientas locales o CI/CD, elige federación o credenciales temporales cuando sea posible. Evita insertar claves de acceso permanentes en YAML, repositorios o servidores compartidos. IAM es el sistema que autoriza el acceso: Secrets Manager almacena credenciales externas cuando hacen falta; son funciones distintas.

La trampa de permisos excesivos en CloudFormation

Al desplegar una plantilla que crea roles IAM, CloudFormation puede pedir confirmación de capacidades como CAPABILITY_IAM o CAPABILITY_NAMED_IAM. Esa advertencia merece revisión: un rol con Action: * y Resource: * puede otorgar privilegios inadecuados. Una plantilla descargada de terceros no debe desplegarse sin inspección. Considera usar un rol de ejecución de CloudFormation con permisos limitados.

Verificación y auditoría

Usa IAM Access Analyzer para detectar permisos amplios y CloudTrail para revisar acciones relevantes. Habilita MFA en identidades humanas y elimina credenciales innecesarias. Una buena política no es solo la que «funciona», sino la que deja de permitir acciones cuando no son necesarias.

Guías relacionadas de Laraflex

CloudFormation · Amazon SNS · Amazon SQS · AWS Lambda · AWS KMS · AWS Secrets Manager

Consulta la documentación oficial de AWS para ampliar y contrastar los detalles técnicos.