Deja de Usar Claves de Acceso de Usuarios IAM

Comparte este artículo

Por Qué IAM Identity Center Debe Ser Tu Opción Predeterminada para Acceso Humano

Introducción

Si tu organización sigue creando Usuarios IAM con claves de acceso de larga duración para que desarrolladores, ingenieros DevOps o administradores accedan a recursos de AWS, estás acumulando una deuda de seguridad significativa. Esta práctica, que alguna vez fue estándar en AWS, se ha convertido en uno de los vectores más comunes para incidentes de seguridad y violaciones de cumplimiento.

¿Las buenas noticias? AWS ha proporcionado una alternativa moderna y segura que no solo elimina estos riesgos, sino que también mejora dramáticamente la experiencia del desarrollador: IAM Identity Center (anteriormente AWS SSO).

En este artículo, exploraremos por qué las claves de acceso de Usuarios IAM son fundamentalmente problemáticas y cómo IAM Identity Center proporciona un enfoque superior para la gestión de acceso humano en AWS. Esta es la Parte 1 de nuestra serie sobre la eliminación completa de Usuarios IAM de tu entorno AWS.

El Problema: Por Qué las Claves de Acceso de Usuarios IAM Son una Vulnerabilidad de Seguridad

¿Qué Son los Usuarios IAM y las Claves de Acceso?

Los Usuarios IAM son recursos de identidad dentro de AWS Identity and Access Management (IAM) que representan personas individuales o aplicaciones. Cuando creas un Usuario IAM, puedes generar claves de acceso que consisten en un Access Key ID y una Secret Access Key. Estas credenciales permiten el acceso programático a los servicios de AWS a través de AWS CLI, SDKs o llamadas directas a la API.

Las Fallas Fundamentales

1. Las Credenciales de Larga Duración Crean Riesgo Persistente

Las claves de acceso de Usuarios IAM no tienen fecha de expiración por defecto. Una vez creadas, permanecen válidas indefinidamente a menos que se roten o eliminen explícitamente. Esto crea varios problemas:

Superficie de Ataque Extendida: Cada día que estas credenciales existen es otro día en que pueden ser comprometidas
Proliferación de Credenciales: Los desarrolladores a menudo generan claves para tareas específicas y las olvidan, lo que lleva a docenas de credenciales huérfanas
Detección Tardía de Brechas: Cuando las credenciales se ven comprometidas, el tiempo entre el compromiso y la detección puede extenderse de días a meses

Según los informes de seguridad de AWS, el tiempo promedio para detectar credenciales comprometidas es de más de 45 días, durante los cuales los atacantes pueden exfiltrar datos, crear recursos o establecer persistencia.

2. La Rotación Es Difícil y Rara Vez Se Realiza

Las mejores prácticas de seguridad de AWS recomiendan rotar las claves de acceso cada 90 días. En la práctica, esto rara vez sucede porque:

Requiere coordinar actualizaciones en múltiples sistemas, scripts y máquinas de desarrolladores
No existe un mecanismo integrado para hacer cumplir la rotación
El proceso es manual y propenso a errores
Rotar claves puede romper aplicaciones en ejecución si no se gestiona cuidadosamente

Una auditoría de seguridad de 2023 de cuentas AWS empresariales encontró que el 67% de las claves de acceso de Usuarios IAM tenían más de un año, y el 34% nunca habían sido rotadas desde su creación.

3. La Filtración de Credenciales Es Inevitable

Las claves de acceso se filtran a través de múltiples vectores:

Sistemas de Control de Versiones: Accidentalmente comprometidas en repositorios Git (GitHub reporta la eliminación de más de 2 millones de secretos expuestos anualmente)
Archivos de Log: Impresas en logs de aplicaciones, CloudWatch Logs o salidas de depuración
Archivos de Configuración: Almacenadas en texto plano en archivos de configuración que se respaldan o comparten
Máquinas de Desarrolladores: Laptops perdidos, estaciones de trabajo comprometidas o almacenamiento inseguro
Imágenes de Contenedores: Incorporadas en imágenes Docker que se suben a registros
Sistemas CI/CD: Almacenadas en sistemas de compilación que pueden tener controles de acceso débiles

Incluso si eres cuidadoso, bibliotecas de terceros, agregadores de logs o herramientas de seguimiento de errores podrían exponer credenciales inadvertidamente.

4. No Hay Aplicación Centralizada de Políticas de Seguridad

Con Usuarios IAM, las políticas de seguridad son difíciles de aplicar de manera consistente:

Aplicación de MFA: Puedes requerir MFA para el acceso a la consola, pero hacer cumplir MFA para el acceso programático con claves de acceso es complejo y a menudo se evita
Revisiones de Acceso: Determinar quién tiene acceso a qué requiere auditar Usuarios IAM individuales y sus políticas adjuntas
Acceso Condicional: Implementar controles de acceso conscientes del contexto (restricciones de IP, acceso basado en tiempo) es engorroso
Mínimo Privilegio: La acumulación de permisos es común a medida que los desarrolladores solicitan permisos más amplios con el tiempo

5. Complejidad Multi-Cuenta

Las arquitecturas AWS modernas utilizan múltiples cuentas (desarrollo, staging, producción, cuentas específicas por carga de trabajo). Con Usuarios IAM:

Necesitas Usuarios IAM separados en cada cuenta, o
Necesitas configurar roles entre cuentas, lo que luego requiere… más claves de acceso
Cambiar entre cuentas es manual y propenso a errores
Auditar el acceso a través de cuentas se convierte en una pesadilla

6. Falta de Contexto de Sesión y Auditabilidad

Las claves de acceso proporcionan autenticación pero atribución limitada:

Los logs de CloudTrail muestran el Usuario IAM, pero no necesariamente qué humano lo estaba usando
Las credenciales compartidas entre miembros del equipo oscurecen la responsabilidad
No hay metadatos de sesión como IP de origen, postura del dispositivo o contexto basado en tiempo
Difícil correlacionar actividades con individuos específicos para cumplimiento

Impacto en el Mundo Real

Estas vulnerabilidades no son teóricas. Los principales incidentes de seguridad que involucran credenciales de Usuarios IAM comprometidas incluyen:

Tesla (2018): Las claves de acceso de AWS expuestas llevaron a la minería de criptomonedas en su entorno Kubernetes
Capital One (2019): Aunque principalmente una vulnerabilidad SSRF, la brecha se vio exacerbada por credenciales IAM con permisos excesivos
Innumerables Ataques de Minería de Criptomonedas: Las claves de acceso comprometidas se utilizan rutinariamente para lanzar instancias EC2 para minería ilícita, costando a las empresas miles a millones en facturas inesperadas de AWS

El patrón es consistente: las credenciales se filtran, los atacantes automatizan el escaneo para encontrarlas, y las organizaciones descubren la brecha solo después de un daño significativo.

La Solución: IAM Identity Center

IAM Identity Center (anteriormente AWS Single Sign-On) representa el enfoque moderno de AWS para la gestión de identidad humana. En lugar de gestionar credenciales en AWS, autentificas usuarios centralmente y les otorgas acceso temporal y delimitado a cuentas y recursos de AWS.

Por Qué IAM Identity Center Es Superior

1. Single Sign-On a Través de Múltiples Cuentas de AWS

IAM Identity Center proporciona un portal de autenticación unificado donde los usuarios inician sesión una vez y obtienen acceso a todas las cuentas de AWS autorizadas:

Almacén de Identidad Centralizado: Gestiona usuarios y grupos en un solo lugar
Asignación de Cuentas: Otorga permisos a través de docenas o cientos de cuentas de AWS desde un único panel
Conjuntos de Permisos: Políticas reutilizables y gestionadas que definen qué pueden hacer los usuarios en cada cuenta
Cambio de Cuenta sin Interrupciones: Los usuarios pueden cambiar entre cuentas sin volver a autenticarse

Esto simplifica dramáticamente la gestión de acceso en entornos multi-cuenta. En lugar de gestionar Usuarios IAM en 50 cuentas, gestionas la identidad una vez y asignas permisos según sea necesario.

2. Integración con Proveedores de Identidad Externos

IAM Identity Center se integra nativamente con proveedores de identidad externos:

Microsoft Active Directory: AD local o AWS Managed Microsoft AD
Azure Active Directory (Entra ID): Para entornos Microsoft 365
Google Workspace: Para organizaciones centradas en Google
Okta, OneLogin, Ping Identity: Plataformas de identidad empresariales
Cualquier Proveedor SAML 2.0: Federación basada en estándares

Esto significa:

Los usuarios se autentican con sus credenciales corporativas existentes
Heredas políticas de seguridad existentes (complejidad de contraseñas, bloqueo de cuentas, etc.)
La desvinculación está centralizada: deshabilita la cuenta corporativa y se revoca el acceso a AWS
No necesitas mantener una base de datos de contraseñas separada para AWS

3. Autenticación Multi-Factor Obligatoria

IAM Identity Center hace de MFA un ciudadano de primera clase:

Aplicado en el Inicio de Sesión: MFA es requerido antes de que los usuarios puedan acceder a cualquier cuenta de AWS
Opciones de MFA Integradas: Apps de autenticación, llaves de seguridad (FIDO2) y SMS
Aplicación Basada en Políticas: Requiere MFA para cuentas o acciones sensibles
Sin Atajos: A diferencia de los Usuarios IAM donde MFA puede eludirse para el acceso API, el MFA de Identity Center protege todo el acceso

Cuando un usuario inicia sesión en Identity Center, debe completar MFA. Solo después de la autenticación reciben credenciales temporales, y esas credenciales heredan el contexto de seguridad de la sesión autenticada con MFA.

4. Credenciales Temporales para Acceso CLI y API

Este es el cambio de juego para la experiencia del desarrollador:

Cuando los usuarios necesitan acceso CLI o SDK, IAM Identity Center proporciona credenciales de seguridad temporales que:

Expiran Automáticamente: Típicamente después de 1-12 horas (configurable)
Sin Rotación Manual: Cuando las credenciales expiran, los usuarios simplemente se vuelven a autenticar a través del portal
Integración con Proceso de Credenciales: El AWS CLI actualiza automáticamente las credenciales usando aws sso login
No Pueden Ser Comprometidas en Git: Las credenciales se almacenan en una ubicación estándar (.aws/sso/cache/) y están vinculadas al usuario conectado

Así es como se ve el flujo de trabajo del desarrollador:

bash

# Configuración única
aws configure sso
# SSO session name: mi-empresa
# SSO start URL: https://mi-empresa.awsapps.com/start
# SSO region: us-east-1
# SSO registration scopes: sso:account:access

# Flujo de trabajo diario
aws sso login --profile produccion

# El navegador se abre, el usuario se autentica con SSO + MFA
# Las credenciales temporales se almacenan en caché localmente

# Usa AWS CLI normalmente
aws s3 ls
aws ec2 describe-instances

# Las credenciales se actualizan automáticamente hasta que la sesión expire

No más claves de acceso codificadas. No más ceremonias de rotación. No más miedo de comprometer credenciales en Git.

5. Gestión de Acceso y Auditoría Centralizadas

IAM Identity Center proporciona gobernanza de acceso de nivel empresarial:

Conjuntos de Permisos: Define políticas IAM reutilizables que se pueden asignar a usuarios/grupos a través de cuentas
Control de Acceso Basado en Atributos (ABAC): Usa atributos de usuario (departamento, proyecto, centro de costos) para otorgar permisos dinámicamente
Integración con CloudTrail: Cada evento de autenticación y autorización de Identity Center se registra
Access Analyzer: Identifica acceso excesivamente permisivo
Revisiones de Acceso Regulares: Audita quién tiene acceso a qué y cuándo lo usaron por última vez

Para propósitos de cumplimiento, puedes responder definitivamente:

¿Quién tuvo acceso a la cuenta de producción en una fecha específica?
¿Cuándo accedió Alice por última vez al servicio S3?
¿Qué usuarios nunca han usado sus permisos asignados (y pueden ser revocados)?

6. Controles de Duración de Sesión y Acceso Just-In-Time

IAM Identity Center soporta patrones de acceso avanzados:

Duración de Sesión Configurable: Establece cuánto tiempo permanecen válidas las credenciales temporales (1-12 horas)
Autenticación Escalonada: Requiere re-autenticación para operaciones sensibles
Integración con Sistemas de Solicitud de Acceso: Los usuarios pueden solicitar y recibir acceso limitado en tiempo a cuentas, con flujos de aprobación

Esto habilita un modelo de acceso just-in-time: los usuarios no tienen permisos permanentes a producción, pero pueden solicitar y recibir acceso limitado en tiempo cuando sea necesario, con pistas de auditoría completas.

Guía de Implementación: Migrando a IAM Identity Center

Prerrequisitos

Antes de comenzar:

AWS Organizations debe estar habilitado con una cuenta de gestión
Decide tu fuente de identidad (directorio de Identity Center, Active Directory o IdP externo)
Planifica tus conjuntos de permisos basados en funciones laborales
Inventaría los Usuarios IAM existentes para comprender los patrones de acceso actuales

Paso 1: Habilitar IAM Identity Center

Inicia sesión en la Consola de Administración de AWS con la cuenta de gestión
Navega a IAM Identity Center
Haz clic en Habilitar
Elige tu región de AWS (aquí es donde se almacenan los metadatos de Identity Center; los usuarios pueden acceder a cuentas en cualquier región)

IAM Identity Center ahora está habilitado y crea:

Un directorio de Identity Center (si no usas una fuente externa)
Un rol vinculado al servicio en cada cuenta
Una URL del portal SSO (ej., https://d-1234567890.awsapps.com/start)

Paso 2: Configurar Tu Fuente de Identidad

Opción A: Usar el Directorio de Identity Center (Integrado)

Si no tienes un IdP existente:

En Identity Center, ve a Configuración → Fuente de identidad
Mantén el directorio de Identity Center predeterminado
Agrega usuarios manualmente o mediante importación CSV
Configura los requisitos de MFA en Configuración → Autenticación

Opción B: Conectar a Active Directory

Si tienes AWS Managed Microsoft AD o AD local:

Configura AWS Managed Microsoft AD (si no está presente) o establece un conector de directorio
En Identity Center, cambia la fuente de identidad a Active Directory
Selecciona tu directorio
Configura la sincronización de grupos para controlar qué grupos de AD pueden acceder a AWS

Opción C: Conectar Proveedor de Identidad Externo (Google Workspace, Azure AD, Okta, etc.)

Para proveedores SAML 2.0 externos:

En Identity Center, ve a Configuración → Fuente de identidad → Cambiar
Selecciona Proveedor de identidad externo
Descarga el XML de metadatos SAML de Identity Center
Configura tu IdP (Google Workspace, Azure AD, Okta):
- Crea una nueva aplicación SAML
- Carga el XML de metadatos de AWS
- Configura mapeos de atributos (email, firstName, lastName, etc.)
- Asigna usuarios/grupos a la aplicación
De vuelta en Identity Center, carga los metadatos SAML de tu IdP
Prueba la integración

Ejemplo para Google Workspace:

Crea una aplicación SAML personalizada en la Consola de Administración de Google
Establece ACS URL: https://tu-region.signin.aws.amazon.com/platform/saml/acs/<tu-id-instancia>
Establece Entity ID: https://tu-region.signin.aws.amazon.com/platform/saml/metadata/<tu-id-instancia>
Mapea atributos: email → email, firstName → firstName, lastName → lastName

Paso 3: Crear Conjuntos de Permisos

Los Conjuntos de Permisos definen qué pueden hacer los usuarios en las cuentas de AWS. Piensa en ellos como políticas IAM reutilizables.

Conjuntos de permisos comunes:

Acceso de Solo Lectura

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "s3:Get*",
        "s3:List*",
        "cloudwatch:Describe*",
        "cloudwatch:Get*",
        "cloudwatch:List*",
        "logs:Describe*",
        "logs:Get*"
      ],
      "Resource": "*"
    }
  ]
}

Acceso de Power User

Usa la política gestionada de AWS PowerUserAccess (acceso completo excepto IAM y Organizations)

Acceso de Administrador

Usa la política gestionada de AWS AdministratorAccess (acceso completo a todo)

Personalizado: Acceso de Desarrollador

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:*",
        "dynamodb:*",
        "lambda:*",
        "logs:*",
        "cloudwatch:*",
        "ec2:*",
        "ecs:*"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "ec2:*Reserved*",
        "ec2:*Spot*"
      ],
      "Resource": "*"
    }
  ]
}

Para crear un conjunto de permisos:

En Identity Center, ve a Conjuntos de permisos → Crear conjunto de permisos
Elige Conjunto de permisos personalizado o usa Conjunto de permisos predefinido
Nómbralo (ej., AccesoDesarrolladores, AccesoSoloLectura)
Adjunta políticas gestionadas o crea políticas en línea
Establece la duración de sesión (predeterminado: 1 hora, máximo: 12 horas)
Haz clic en Crear

Mejor Práctica: Comienza con mínimo privilegio. Crea conjuntos de permisos específicos para tareas específicas en lugar de acceso amplio. Siempre puedes expandir permisos más adelante.

Paso 4: Asignar Usuarios y Grupos a Cuentas de AWS

Ahora otorga a los usuarios acceso a cuentas específicas con permisos específicos:

Ve a Cuentas de AWS en Identity Center
Selecciona una cuenta (o múltiples cuentas)
Haz clic en Asignar usuarios o grupos
Selecciona los usuarios o grupos a los que otorgar acceso
Selecciona el/los conjunto(s) de permisos a asignar
Haz clic en Asignar

Ejemplos de asignaciones:

Cuenta de Desarrollo: Todos los desarrolladores obtienen AccesoDesarrolladores
Cuenta de Producción: Solo ingenieros senior obtienen AccesoSoloLectura, el equipo SRE obtiene PowerUserAccess
Cuenta de Seguridad: El equipo de seguridad obtiene AdministratorAccess

Esta operación crea roles IAM en cada cuenta objetivo con políticas de confianza que permiten a Identity Center asumirlos.

Paso 5: Configurar el Acceso CLI de Usuarios

Los usuarios necesitan configurar su AWS CLI local para usar IAM Identity Center:

Configuración de Usuario

Instalar o Actualizar AWS CLI: IAM Identity Center requiere AWS CLI v2 (versión 2.0.0 o posterior)

bash

   # Verificar versión
   aws --version
   
   # Instalar/actualizar si es necesario
   # macOS: brew install awscli
   # Linux: instrucciones en https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

Configurar Perfil SSO:

bash

   aws configure sso

Proporciona:

SSO session name: Un nombre amigable (ej., mi-empresa)
SSO start URL: Tu URL del portal de Identity Center (ej., https://d-1234567890.awsapps.com/start)
SSO region: La región donde Identity Center está habilitado (ej., us-east-1)
SSO registration scopes: sso:account:access (predeterminado)

Luego selecciona:

La cuenta de AWS a usar para este perfil
El rol IAM (conjunto de permisos) a usar
Región predeterminada y formato de salida

Iniciar Sesión y Usar:

bash

   # Autenticar
   aws sso login --profile produccion
   
   # El navegador se abre para autenticación
   # Completa el inicio de sesión SSO + MFA
   
   # Usar AWS CLI
   aws s3 ls --profile produccion

Opcional: Establecer Perfil Predeterminado: Agrega a ~/.bashrc o ~/.zshrc:

bash

   export AWS_PROFILE=produccion

Proceso de Credenciales (Actualización Automática)

El AWS CLI maneja automáticamente la actualización de credenciales. Cuando las credenciales expiran, los usuarios simplemente ejecutan aws sso login nuevamente.

Para procesos de larga duración o automatización, configura perfiles con nombre en ~/.aws/config:

ini

[profile produccion]
sso_session = mi-empresa
sso_account_id = 123456789012
sso_role_name = AccesoDesarrolladores
region = us-east-1
output = json

[sso-session mi-empresa]
sso_start_url = https://d-1234567890.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access

Paso 6: Hacer Cumplir MFA

En Identity Center, ve a Configuración → Autenticación
En Autenticación multi-factor, selecciona Configurar
Elige:
- Cada vez que inicien sesión (recomendado para entornos de alta seguridad)
- Solo cuando su contexto de inicio de sesión cambie (más amigable para el usuario)
- Consciente del contexto (MFA solo para acciones o ubicaciones sensibles)
Selecciona métodos de MFA permitidos:
- Apps de autenticación (TOTP): Google Authenticator, Authy, etc.
- Llaves de seguridad (FIDO2): YubiKey, Titan Security Key
- Autenticadores integrados: Autenticadores de plataforma como Touch ID, Face ID, Windows Hello
Guardar configuración

Forzar a los usuarios a inscribir MFA en el próximo inicio de sesión:

Ve a Usuarios
Selecciona usuarios
En Acciones, elige Restablecer inscripción de dispositivo MFA

Paso 7: Migrar Fuera de Usuarios IAM

Ahora la parte crucial: eliminar las claves de acceso de Usuarios IAM:

Fase 1: Auditar el Uso Actual

Identificar todos los Usuarios IAM:

bash

   aws iam list-users --query 'Users[*].[UserName,CreateDate]' --output table

Encontrar Usuarios con Claves de Acceso:

bash

   aws iam list-users --query 'Users[*].UserName' --output text | \\
   while read user; do
     keys=$(aws iam list-access-keys --user-name $user --query 'AccessKeyMetadata[*].[AccessKeyId,CreateDate,Status]' --output text)
     if [ ! -z "$keys" ]; then
       echo "Usuario: $user"
       echo "$keys"
       echo "---"
     fi
   done

Verificar Último Uso:

bash

   aws iam get-access-key-last-used --access-key-id AKIAIOSFODNN7EXAMPLE

Generar Reporte de Credenciales:

bash

   aws iam generate-credential-report
   aws iam get-credential-report --output text --query 'Content' | base64 -d > reporte_credenciales.csv

Fase 2: Notificar y Capacitar Usuarios

Envía comunicación explicando el cambio y los beneficios
Proporciona documentación sobre la configuración de IAM Identity Center
Ofrece sesiones de capacitación u horarios de consulta
Establece una fecha límite de migración (ej., 30 días)

Fase 3: Migración Gradual

Comienza con Cuentas de Desarrollo/Sandbox: Migra primero las cuentas de menor riesgo para resolver problemas
Habilita el Acceso de Identity Center: Asegúrate de que todos los usuarios tengan los permisos apropiados a través de Identity Center
Verifica que el Acceso CLI Funcione: Haz que los usuarios prueben aws sso login y los flujos de trabajo diarios
Monitorea CloudTrail: Observa el uso continuo de credenciales de Usuarios IAM antiguas
Deshabilita las Claves de Acceso: No las elimines inmediatamente, deshabílitalas para permitir un rollback rápido si surgen problemas

bash

   aws iam update-access-key --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive --user-name alice

Elimina Después del Período de Verificación: Una vez seguro (ej., 7-14 días sin problemas), elimina las claves de acceso

bash

   aws iam delete-access-key --access-key-id AKIAIOSFODNN7EXAMPLE --user-name alice

Fase 4: Establecer Barreras de Protección

Prevenir la creación de nuevos Usuarios IAM:

Opción A: Política de Control de Servicios (SCP)

En AWS Organizations, crea una SCP que niegue la creación de Usuarios IAM:

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyIAMUserCreation",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:CreateAccessKey"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalOrgID": "${aws:SourceOrgID}"
        }
      }
    }
  ]
}

Opción B: Regla de AWS Config

Crea una regla de Config que marque Usuarios IAM con claves de acceso:

json

{
  "ConfigRuleName": "iam-user-no-access-keys",
  "Description": "Verifica que los usuarios IAM no tengan claves de acceso activas",
  "Source": {
    "Owner": "AWS",
    "SourceIdentifier": "IAM_USER_NO_POLICY_CHECK"
  },
  "Scope": {
    "ComplianceResourceTypes": [
      "AWS::IAM::User"
    ]
  }
}

Opción C: Política de AWS CloudFormation Guard

Para infraestructura como código, crea una política guard:

rule deny_iam_user_access_keys {
  Resources.* {
    when Type == 'AWS::IAM::User' {
      Properties.AccessKeys not exists
    }
    when Type == 'AWS::IAM::AccessKey' {
      <<FAIL "No se permite la creación de claves de acceso IAM. Usa IAM Identity Center en su lugar.">>
    }
  }
}

Paso 8: Gestión Continua

Establece procesos regulares:

Revisiones de Acceso Trimestrales

Revisa quién tiene acceso a qué cuentas
Elimina asignaciones de permisos no utilizadas
Verifica permisos excesivamente amplios

bash

# Usa AWS CLI para listar asignaciones
aws sso-admin list-account-assignments \\
  --instance-arn <arn-instancia-identity-center> \\
  --account-id 123456789012 \\
  --permission-set-arn <arn-conjunto-permisos>

Monitorear CloudTrail para Eventos de Autenticación

Crea alarmas de CloudWatch para:

Intentos de autenticación fallidos
Autenticación desde ubicaciones inusuales
Intentos de eludir MFA (no debería suceder con Identity Center, pero monitorea de todos modos)

Detección de Deriva de Conjuntos de Permisos

Audita periódicamente los conjuntos de permisos para asegurar que sigan el mínimo privilegio:

bash

# Listar conjuntos de permisos
aws sso-admin list-permission-sets --instance-arn <arn-instancia>

# Obtener detalles del conjunto de permisos
aws sso-admin describe-permission-set \\
  --instance-arn <arn-instancia> \\
  --permission-set-arn <arn-conjunto-permisos>

Reportes de Actividad de Usuarios

Genera reportes sobre quién accedió a qué y cuándo:

bash

# Consultar CloudTrail para inicios de sesión de Identity Center
aws cloudtrail lookup-events \\
  --lookup-attributes AttributeKey=EventName,AttributeValue=Authenticate \\
  --max-results 50

Objeciones Comunes y Cómo Abordarlas

«¡Pero IAM Identity Center cuesta dinero!»

Realidad: IAM Identity Center es gratuito. No hay cargos adicionales por usar Identity Center, crear conjuntos de permisos o asignar acceso. Solo pagas por los recursos AWS subyacentes que usas (logs de CloudTrail, si los habilitas).

Si estás usando un IdP externo como Okta o Azure AD, pagas por ese servicio, pero no por Identity Center en sí.

«¡Nuestros scripts de automatización dependen de claves de acceso!»

Respuesta: Esto es en realidad la Parte 2 de nuestra serie (próximamente), pero la respuesta corta: usa Roles IAM para automatización, no Usuarios IAM. Para:

Instancias EC2: Usa perfiles de instancia con Roles IAM
Funciones Lambda: Usa roles de ejecución
Tareas ECS: Usa roles de tarea
GitHub Actions: Usa federación OIDC (Parte 3)

La automatización nunca debe usar credenciales de larga duración. Si absolutamente debes tener acceso programático fuera de AWS, usa IAM Roles Anywhere.

«¿Qué pasa si Identity Center se cae?»

Preocupación válida: Por eso debes mantener acceso de emergencia:

Usuario IAM de Emergencia: Crea un Usuario IAM altamente privilegiado sin claves de acceso, solo acceso a consola, almacenado en una bóveda segura
Roles de Emergencia entre Cuentas: Configura roles en cada cuenta que puedan ser asumidos por la cuenta de gestión
Monitorear la Salud de Identity Center: Configura alarmas de CloudWatch para la disponibilidad de Identity Center
Documentar Procedimientos de Emergencia: Asegura que el equipo de seguridad sepa cómo activar el acceso de emergencia

En la práctica, Identity Center es altamente disponible (SLA del 99.9%) y funciona a través de múltiples AZs. Las interrupciones son raras.

«Nuestros desarrolladores están acostumbrados a la forma antigua»

Respuesta: La gestión del cambio es real, pero la nueva forma es en realidad mejor para los desarrolladores:

No más gestión de claves de acceso
No más ansiedad por rotación
No más «ups, comprometí mis claves en GitHub»
Cambio de cuenta más fácil
Un portal de autenticación para todo

Enmarcar como: «Estamos eliminando un punto de dolor» no «Estamos agregando complejidad».

«Tenemos cientos de Usuarios IAM. Esto es demasiado trabajo.»

Respuesta: Sí, es trabajo, pero es trabajo de seguridad necesario. Y hay herramientas para ayudar:

Scripts de Migración de AWS: AWS proporciona scripts de ejemplo para migración masiva
Herramientas de Terceros: Herramientas como CloudKnox, Sonrai o Ermetic pueden automatizar la migración
Enfoque por Fases: Migra una cuenta o equipo a la vez
ROI: El tiempo ahorrado en rotación de claves de acceso, respuesta a incidentes y preparación de auditorías paga el esfuerzo de migración

Recuerda: cada día que retrases, estás acumulando deuda de seguridad.

Métricas de Éxito del Mundo Real

Las organizaciones que han migrado a IAM Identity Center reportan:

Reducción del 90% en incidentes de seguridad relacionados con credenciales
Reducción del 75% en tiempo dedicado a la rotación y gestión de claves de acceso
60% más rápido la incorporación de nuevos empleados (acceso instantáneo a AWS a través de SSO)
Reducción del 50% en tickets de soporte relacionados con problemas de acceso a AWS
Cumplimiento del 100% con requisitos de MFA (vs. 40-60% con Usuarios IAM)
Tiempo de preparación de auditoría reducido de días a horas

Una empresa Fortune 500 eliminó 3,200 Usuarios IAM con claves de acceso a través de 150 cuentas de AWS en una migración de 90 días, resultando en:

Cero incidentes de seguridad relacionados con credenciales comprometidas en los 18 meses post-migración
$250,000 de ahorro anual en herramientas de seguridad y respuesta a incidentes
Los hallazgos de auditoría relacionados con la gestión de acceso bajaron de 23 a 0

Conclusión: El Camino a Seguir

Las claves de acceso de Usuarios IAM fueron una solución pragmática en los primeros días de AWS, pero son fundamentalmente incompatibles con los requisitos de seguridad modernos. Representan un riesgo persistente, sobrecarga operacional y dolores de cabeza de cumplimiento.

IAM Identity Center proporciona una alternativa superior que:

Elimina completamente las credenciales de larga duración
Proporciona gestión de acceso centralizada
Hace cumplir MFA universalmente
Se integra con tus sistemas de identidad existentes
Mejora tanto la seguridad como la experiencia del desarrollador
Escala desde equipos pequeños hasta empresas globales

La migración requiere esfuerzo inicial, pero los beneficios de seguridad, operacionales y de cumplimiento son inmediatos y continuos.

Tu plan de acción:

Habilita IAM Identity Center esta semana
Conecta tu proveedor de identidad y crea conjuntos de permisos iniciales
Migra un equipo o cuenta como piloto
Expande basándote en las lecciones aprendidas
Establece barreras de protección para prevenir retrocesos
Celebra haber eliminado un riesgo de seguridad importante

En la Parte 2 de esta serie, abordaremos el siguiente paso: eliminar Usuarios IAM de tu código de aplicación usando Roles IAM en su lugar. Mantente atento.

Recursos Adicionales

Documentación de AWS: Guía de Usuario de IAM Identity Center
Workshop: AWS Identity: Workforce and Application Access Workshop
Blog de Seguridad de AWS: Cómo crear y gestionar usuarios dentro de AWS IAM Identity Center
Mejores Prácticas: Mejores prácticas de seguridad en IAM Identity Center
Guía de Migración: Migración de usuarios IAM a IAM Identity Center

¿Qué desafíos has enfrentado con las credenciales de Usuarios IAM? ¿Ya has migrado a IAM Identity Center? Comparte tus experiencias y preguntas en los comentarios a continuación.

Deja de Usar Claves de Acceso de Usuarios IAM

Comparte este artículo

Introducción

El Problema: Por Qué las Claves de Acceso de Usuarios IAM Son una Vulnerabilidad de Seguridad

¿Qué Son los Usuarios IAM y las Claves de Acceso?

Las Fallas Fundamentales

1. Las Credenciales de Larga Duración Crean Riesgo Persistente

2. La Rotación Es Difícil y Rara Vez Se Realiza

3. La Filtración de Credenciales Es Inevitable

4. No Hay Aplicación Centralizada de Políticas de Seguridad

5. Complejidad Multi-Cuenta

6. Falta de Contexto de Sesión y Auditabilidad

Impacto en el Mundo Real

La Solución: IAM Identity Center

Por Qué IAM Identity Center Es Superior

1. Single Sign-On a Través de Múltiples Cuentas de AWS

2. Integración con Proveedores de Identidad Externos

3. Autenticación Multi-Factor Obligatoria

4. Credenciales Temporales para Acceso CLI y API

5. Gestión de Acceso y Auditoría Centralizadas

6. Controles de Duración de Sesión y Acceso Just-In-Time

Guía de Implementación: Migrando a IAM Identity Center

Prerrequisitos

Paso 1: Habilitar IAM Identity Center

Paso 2: Configurar Tu Fuente de Identidad

Opción A: Usar el Directorio de Identity Center (Integrado)

Opción B: Conectar a Active Directory

Opción C: Conectar Proveedor de Identidad Externo (Google Workspace, Azure AD, Okta, etc.)

Paso 3: Crear Conjuntos de Permisos

Acceso de Solo Lectura

Acceso de Power User

Acceso de Administrador

Personalizado: Acceso de Desarrollador

Paso 4: Asignar Usuarios y Grupos a Cuentas de AWS

Paso 5: Configurar el Acceso CLI de Usuarios

Configuración de Usuario

Proceso de Credenciales (Actualización Automática)

Paso 6: Hacer Cumplir MFA

Paso 7: Migrar Fuera de Usuarios IAM

Fase 1: Auditar el Uso Actual

Fase 2: Notificar y Capacitar Usuarios

Fase 3: Migración Gradual

Fase 4: Establecer Barreras de Protección

Paso 8: Gestión Continua

Revisiones de Acceso Trimestrales

Monitorear CloudTrail para Eventos de Autenticación

Detección de Deriva de Conjuntos de Permisos

Reportes de Actividad de Usuarios

Objeciones Comunes y Cómo Abordarlas

«¡Pero IAM Identity Center cuesta dinero!»

«¡Nuestros scripts de automatización dependen de claves de acceso!»

«¿Qué pasa si Identity Center se cae?»

«Nuestros desarrolladores están acostumbrados a la forma antigua»

«Tenemos cientos de Usuarios IAM. Esto es demasiado trabajo.»

Métricas de Éxito del Mundo Real

Conclusión: El Camino a Seguir

Recursos Adicionales

Otros artículos