Cada acción que ocurre en un entorno cloud —desde lanzar una instancia EC2 hasta leer un objeto en S3— esta mediada por un sistema de identidad y acceso. IAM (Identity and Access Management) es el servicio que determina quien puede hacer que sobre cuales recursos, y es el componente de seguridad mas crítico en cualquier arquitectura cloud. Una configuración IAM deficiente es la causa principal de brechas de seguridad en la nube, y dominar sus conceptos es indispensable para cualquier profesional DevOps.

Fundamentos de IAM

IAM se basa en tres conceptos fundamentales que aplican a cualquier proveedor cloud:

  • Autenticación (AuthN): Verificar la identidad. Responde a la pregunta “quien eres”. Se logra mediante credenciales (usuario/contrasena, access keys, certificados, tokens).
  • Autorización (AuthZ): Determinar los permisos. Responde a “que puedes hacer”. Se define mediante políticas que otorgan o deniegan acciones sobre recursos.
  • Auditoria: Registrar quien hizo que y cuando. CloudTrail en AWS, Activity Log en Azure, Audit Logs en GCP.

AWS IAM en Profundidad

Entidades Principales

AWS IAM opera con cuatro tipos de entidades:

Usuarios IAM: Representan personas o aplicaciones con credenciales permanentes. En entornos modernos, los usuarios IAM con access keys de larga duración deberian minimizarse en favor de roles y federation.

Grupos IAM: Agrupaciones logicas de usuarios que comparten los mismos permisos. La práctica recomendada es asignar permisos a grupos, nunca directamente a usuarios individuales.

Roles IAM: Identidades temporales que pueden ser asumidas por usuarios, servicios o cuentas externas. Los roles son el mecanismo preferido para otorgar acceso porque utilizan credenciales temporales que expiran automáticamente.

Políticas IAM: Documentos JSON que definen permisos. Pueden ser AWS Managed (mantenidas por AWS), Customer Managed (creadas por la organización) o Inline (embebidas directamente en un usuario, grupo o rol).

Anatomia de una Política IAM

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadOnly",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-app-data",
        "arn:aws:s3:::my-app-data/*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "10.0.0.0/8"
        }
      }
    }
  ]
}

Cada statement tiene: un efecto (Allow o Deny), acciones (que operaciones de API se permiten), recursos (sobre que ARNs aplica) y condiciones opcionales (restricciones adicionales como IP de origen, hora del dia o MFA requerido).

Principio de Privilegio Minimo

El principio de least privilege establece que cada identidad debe tener exclusivamente los permisos necesarios para cumplir su función, ni uno mas. Es simple de enunciar pero complejo de implementar en la práctica.

Estrategias para Implementar Least Privilege

Empezar con cero permisos: En lugar de otorgar amplios permisos y luego restringir, empezar sin acceso y agregar permisos a medida que se necesitan.

Usar IAM Access Analyzer: AWS IAM Access Analyzer genera políticas basadas en la actividad real registrada en CloudTrail. Despues de un período de observación, se puede generar una política que contenga solo los permisos que realmente fueron usados.

# Generar politica basada en actividad de los ultimos 90 dias
aws accessanalyzer generate-policy \
  --policy-generation-details '{"principalArn":"arn:aws:iam::123456789012:role/MyAppRole"}' \
  --cloud-trail-details '{
    "trails": [{"cloudTrailArn":"arn:aws:cloudtrail:us-east-1:123456789012:trail/main","allRegions":true}],
    "startTime":"2025-01-01T00:00:00Z",
    "endTime":"2025-03-31T23:59:59Z"
  }'

Permission boundaries: Los permission boundaries establecen el límite máximo de permisos que un rol o usuario puede tener, incluso si una política le otorga mas. Son útiles para delegar la creación de roles sin riesgo de escalación de privilegios.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:*",
        "dynamodb:*",
        "lambda:*",
        "logs:*"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "iam:*",
        "organizations:*",
        "cloudtrail:*"
      ],
      "Resource": "*"
    }
  ]
}

Identity Federation y SSO

En organizaciones con multiples cuentas AWS, crear usuarios IAM en cada cuenta es insostenible. La federación de identidades permite que los usuarios se autentiquen contra un proveedor de identidad externo (IdP) y luego asuman roles en AWS.

AWS IAM Identity Center (antes AWS SSO)

IAM Identity Center es el servicio recomendado para gestionar acceso federado a multiples cuentas AWS. Se integra con proveedores de identidad como:

  • Microsoft Entra ID (Azure AD)
  • Okta
  • Google Workspace
  • Cualquier IdP compatible con SAML 2.0
# Configuracion de IAM Identity Center con Terraform
resource "aws_ssoadmin_permission_set" "developer" {
  name             = "DeveloperAccess"
  instance_arn     = data.aws_ssoadmin_instances.main.arns[0]
  session_duration = "PT4H"
  description      = "Developer access with limited permissions"
}

resource "aws_ssoadmin_managed_policy_attachment" "developer_policy" {
  instance_arn       = data.aws_ssoadmin_instances.main.arns[0]
  managed_policy_arn = "arn:aws:iam::aws:policy/PowerUserAccess"
  permission_set_arn = aws_ssoadmin_permission_set.developer.arn
}

resource "aws_ssoadmin_account_assignment" "developer_assignment" {
  instance_arn       = data.aws_ssoadmin_instances.main.arns[0]
  permission_set_arn = aws_ssoadmin_permission_set.developer.arn
  principal_id       = aws_identitystore_group.developers.group_id
  principal_type     = "GROUP"
  target_id          = var.dev_account_id
  target_type        = "AWS_ACCOUNT"
}

Flujo de Autenticación Federada

El flujo tipico funciona así:

  1. El usuario accede al portal de IAM Identity Center
  2. Se autentica contra el IdP corporativo (con MFA)
  3. Recibe una lista de cuentas y roles disponibles
  4. Selecciona la cuenta y el rol deseado
  5. Obtiene credenciales temporales (STS AssumeRole) validas por la duración configurada
  6. Accede a la consola o CLI con esas credenciales temporales

MFA - Autenticación Multifactor

MFA agrega una capa adicional de seguridad exigiendo un segundo factor de autenticación además de la contrasena. En entornos cloud, MFA deberia ser obligatorio para:

  • Todos los usuarios humanos, sin excepción
  • Operaciones criticas (eliminar recursos, modificar IAM, acceso a producción)
  • El usuario root de cada cuenta AWS

Enforcement de MFA via Política

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowViewAccountInfo",
      "Effect": "Allow",
      "Action": [
        "iam:ListMFADevices",
        "iam:GetAccountPasswordPolicy"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowManageOwnMFA",
      "Effect": "Allow",
      "Action": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:ResyncMFADevice"
      ],
      "Resource": [
        "arn:aws:iam::*:mfa/${aws:username}",
        "arn:aws:iam::*:user/${aws:username}"
      ]
    },
    {
      "Sid": "DenyAllExceptMFASetup",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:ListMFADevices",
        "iam:GetUser",
        "sts:GetSessionToken"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

Esta política fuerza a los usuarios a configurar MFA antes de poder realizar cualquier otra acción.

Service Accounts y Roles para Servicios

Las aplicaciones y servicios que corren en la nube también necesitan identidad. La práctica correcta es usar roles en lugar de access keys estaticas.

EC2 Instance Profiles

resource "aws_iam_role" "app_role" {
  name = "my-app-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "ec2.amazonaws.com"
        }
      }
    ]
  })
}

resource "aws_iam_instance_profile" "app_profile" {
  name = "my-app-profile"
  role = aws_iam_role.app_role.name
}

EKS Pod Identity / IRSA

En Kubernetes sobre EKS, IAM Roles for Service Accounts (IRSA) permite asignar roles IAM a pods individuales, evitando que todos los pods del nodo compartan los mismos permisos:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app
  namespace: production
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role

Acceso Cross-Account

En arquitecturas multi-cuenta, los servicios y usuarios frecuentemente necesitan acceder a recursos en otras cuentas. El patron recomendado es usar AssumeRole con trust policies explicitas.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:role/ci-cd-role"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "unique-external-id-12345"
        }
      }
    }
  ]
}

El External ID agrega una capa adicional de protección contra el problema de confused deputy, donde un atacante podria intentar que un servicio asuma un rol en su nombre.

Mejores Prácticas de IAM

  1. No usar el usuario root: Configurar MFA en la cuenta root y no usarla para operaciones diarias. Guardar las credenciales root en un lugar seguro para emergencias.

  2. Eliminar access keys de larga duración: Migrar a roles IAM y credenciales temporales. Si se necesitan access keys, rotarlas periódicamente y monitorizear su uso.

  3. Revisar permisos regularmente: Ejecutar IAM Access Analyzer mensualmente para identificar permisos no utilizados y acceso público no intencionado.

  4. Separación de ambientes: Usar cuentas AWS separadas para producción, staging y desarrollo. Cada entorno con sus propios roles y políticas.

  5. Centralizar la gestión de identidades: Usar IAM Identity Center con un IdP corporativo en lugar de gestionar usuarios IAM en cada cuenta.

  6. Monitorear actividad sospechosa: Configurar alertas de GuardDuty y CloudTrail para detectar patrones anomalos como accesos desde ubicaciones inusuales o uso de credenciales comprometidas.

Conclusion

IAM es la primera linea de defensa en la seguridad cloud y, al mismo tiempo, una de las areas donde mas errores se cometen. La combinación de principio de privilegio mínimo, federación de identidades, MFA obligatorio, credenciales temporales y auditoria continua proporciona una postura de seguridad sólida. No se trata de implementar todos los controles de una vez, sino de avanzar progresivamente desde lo básico (eliminar access keys root, habilitar MFA) hacia lo avanzado (IRSA, permission boundaries, policy-as-code) a medida que la madurez de la organización lo permita.

Recursos