Amazon SCS-C02: Gestión de Identidad y Acceso — Guía de estudio

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Forma parte de la AWS Security Specialty SCS-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Identidades, principales y evaluación de políticas

IAM distingue entre identidades (usuarios, grupos, roles) y principales (la entidad autenticada que realiza una solicitud). Los usuarios son de larga duración con credenciales estáticas; los roles no tienen credenciales propias y se asumen para generar tokens de STS de corta duración. Los grupos son contenedores para adjuntar políticas a los usuarios; nunca son principales y no se pueden asumir.

Cada llamada a la API pasa por una cadena de evaluación determinista: un Deny explícito en cualquier lugar prevalece, luego las SCP a nivel de organización deben permitirlo, luego los límites de permisos deben permitirlo, luego las políticas de sesión (si las hay) deben permitirlo y, finalmente, al menos una política basada en identidad o en recursos debe contener un Allow. La falta de cualquier capa de Allow resulta en una denegación implícita. Por eso es importante la superposición de capas: una política de identidad que otorga s3:* no tiene sentido si una SCP deniega s3:DeleteBucket o si un límite de permisos omite S3 por completo.

Las políticas basadas en recursos (políticas de bucket de S3, políticas de clave de KMS, políticas de tema de SNS, políticas de función de Lambda) pueden otorgar acceso directamente a un principal sin ninguna política de identidad del lado del solicitante, dentro de la misma cuenta. Para el acceso entre cuentas, tanto la política de identidad en la cuenta de origen como la política de recursos en la cuenta de destino deben permitir la acción.

Roles, políticas de confianza y AssumeRole

Un rol tiene dos documentos de política: la política de confianza (quién puede asumirlo) y una o más políticas de permisos (qué pueden hacer una vez asumido). La política de confianza es una política basada en recursos sobre el propio rol, que utiliza la acción sts:AssumeRole. Sin una política de confianza que coincida, AssumeRole falla con AccessDenied incluso si el solicitante tiene sts:AssumeRole en su política de identidad.

Para la delegación entre cuentas, la política de confianza nombra la cuenta de confianza o un ARN de rol/usuario específico en esa cuenta y, lo que es fundamental para el acceso de terceros, impone un ExternalId:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": { "sts:ExternalId": "unique-shared-secret-9271" }
    }
  }]
}

El ExternalId protege contra el problema del confused deputy (delegado confundido): sin él, un proveedor de SaaS de terceros que asume roles en muchas cuentas de clientes podría ser engañado para actuar sobre el rol del cliente equivocado. Omitir sts:ExternalId en la condición, o pasar un valor incorrecto durante sts:AssumeRole, produce un AccessDenied al asumir el rol; una configuración errónea común al incorporar proveedores como herramientas de monitoreo o CSPM.

Para los servicios de AWS (Lambda, EC2, tareas de ECS), la política de confianza nombra a un principal de servicio, por ejemplo, "Service": "lambda.amazonaws.com". Una función de Lambda que necesite acceso a S3 debe asumir un rol de ejecución cuya política de permisos otorgue s3:GetObject y s3:PutObject sobre el bucket; de forma equivalente, una política de bucket de S3 puede nombrar el ARN del rol de la función como principal. Cualquiera de los dos mecanismos funciona por sí solo dentro de una única cuenta.

Límites de permisos

Un límite de permisos es un control avanzado que se adjunta a un usuario o rol y que limita los permisos máximos que esa identidad puede tener, independientemente de lo que otorguen las políticas basadas en identidad. Los permisos efectivos son la intersección de la política de identidad y el límite. Si una política de grupo otorga ec2:* pero el límite solo permite ec2:Describe*, el usuario solo podrá realizar acciones de descripción.

Los límites se utilizan comúnmente para la delegación de permisos: permitir a los desarrolladores crear roles de IAM para sus aplicaciones, pero exigir que cada rol que creen lleve un límite específico. La política de IAM para el desarrollador incluye una condición como "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DevBoundary" en iam:CreateRole y iam:PutRolePolicy. Esto previene la escalada de privilegios a la vez que habilita el autoservicio.

Un error común es pensar que la pertenencia a un grupo o las políticas adicionales adjuntas pueden “anular” un límite o una SCP. No pueden: el límite y la SCP son techos, no pisos.

Aplicación de MFA mediante condiciones

Dos claves de condición impulsan la política de MFA: aws:MultiFactorAuthPresent (booleano, verdadero si la sesión se obtuvo usando MFA) y aws:MultiFactorAuthAge (numérico, segundos desde que se validó el MFA). La aplicación de MFA para API sensibles y la limitación de la vida útil de la sesión se ve así:

{
  "Effect": "Allow",
  "Action": ["rds:DeleteDBInstance", "kms:ScheduleKeyDeletion"],
  "Resource": "*",
  "Condition": {
    "Bool":            { "aws:MultiFactorAuthPresent": "true" },
    "NumericLessThan": { "aws:MultiFactorAuthAge": "7200" }
  }
}

Dos horas son 7200 segundos. Usar BoolIfExists en lugar de Bool es sutilmente peligroso para las llamadas de principales de servicio que nunca llevan la clave, ya que se evalúa como verdadero y, en la práctica, omite la verificación para esos solicitantes. Por lo tanto, es preferible usar Bool cuando la intención es la aplicación para usuarios humanos.

Debido a que las solicitudes de CLI y SDK que utilizan claves de acceso a largo plazo no llevan el contexto de MFA, los usuarios primero deben llamar a sts:GetSessionToken (con --serial-number y --token-code) o sts:AssumeRole con --serial-number/--token-code para obtener credenciales temporales que incluyan el contexto de MFA. Esas credenciales de corta duración satisfacen entonces la condición MultiFactorAuthPresent:

aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/alice \
  --token-code 123456 \
  --duration-seconds 7200

IAM Identity Center y Federación

IAM Identity Center (anteriormente AWS SSO) centraliza el acceso de la fuerza laboral a través de una AWS Organization. Los conjuntos de permisos (Permission sets) son plantillas que Identity Center materializa como roles de IAM dentro de cada cuenta de destino cuando se asigna un usuario o grupo. Las asignaciones vinculan tres elementos: un principal (usuario o grupo del directorio de Identity Center o de un IdP externo como Okta/Entra ID), un conjunto de permisos y una o más cuentas.

Los conjuntos de permisos pueden contener políticas administradas por AWS, políticas administradas por el cliente (referenciadas por nombre, por lo que deben existir en cada cuenta de destino), políticas insertadas (inline) y un límite de permisos (permissions boundary). Cuando editas un conjunto de permisos, Identity Center reaprovisiona los roles subyacentes; nunca debes editar esos roles directamente.

Para la federación SAML fuera de Identity Center, AWS valida la firma de la aserción con los metadatos del IdP registrados en el objeto del proveedor SAML de IAM. Cuando el IdP rota su certificado de firma, es necesario cargar los metadatos XML actualizados; de lo contrario, STS devuelve InvalidIdentityToken / Response Signature Invalid. Actualizar los metadatos con aws iam update-saml-provider --saml-metadata-document file://metadata.xml --saml-provider-arn ... es la solución con el mínimo esfuerzo, sin necesidad de recrear el proveedor ni reconfigurar las relaciones de confianza.

Cuenta Raíz, Informes de Credenciales y Privilegio Mínimo

El usuario raíz tiene acceso completo que no se puede eliminar y debe tratarse como una identidad de emergencia: habilita un dispositivo MFA de hardware o virtual, elimina cualquier clave de acceso raíz, no lo uses para el trabajo diario y almacena las credenciales fuera de línea. Usa SCPs a nivel de la raíz de la organización o de la OU para evitar que incluso los administradores en las cuentas miembro deshabiliten GuardDuty, eliminen CloudTrail o abandonen regiones específicas. Las SCPs nunca otorgan permisos; solo filtran lo que IAM en la cuenta miembro puede otorgar.

El principio de privilegio mínimo se operacionaliza con herramientas en lugar de con la intuición. Genera el informe de credenciales de IAM (aws iam generate-credential-report y luego get-credential-report) para encontrar usuarios inactivos, claves de acceso antiguas y usuarios sin MFA. Usa IAM Access Analyzer para identificar políticas de recursos que exponen datos entre cuentas y para generar políticas ajustadas a partir de la actividad de CloudTrail. Usa los datos de último acceso (aws iam get-service-last-accessed-details) para eliminar permisos de servicio no utilizados de los roles.

Una última trampa que vale la pena mencionar explícitamente: asumir que agregar un Allow en la identidad es suficiente. Si una política de clave de KMS no nombra tu rol, una SCP deniega la acción o un límite de permisos la omite, la llamada fallará igualmente. Siempre audita la pila completa (SCP, límite de permisos, política de identidad, política de recurso y política de sesión) al solucionar un AccessDenied.

Problema Práctico: Escenario de Caso de Uso

Escenario: Meridian Financial opera una AWS Organization de tres cuentas para cargas de trabajo de gestión, producción y desarrollo, con datos sensibles de trading y de clientes en la cuenta de producción. Actualmente tienen una mezcla de usuarios de IAM de larga duración heredados, cuentas de contratistas y un proveedor de identidad SAML de Okta, lo que produce controles de acceso inconsistentes y configuraciones de roles dispersas entre las cuentas.

Desafío: Un incidente reciente involucró las credenciales comprometidas de un contratista que asumió un rol entre cuentas sin MFA y realizó acciones excesivas porque no existían límites de permisos ni conjuntos de permisos centralizados. Meridian necesita fortalecer la federación, la confianza de los roles y aplicar MFA y el principio de privilegio mínimo en todas las cuentas.

Enfoque Recomendado:

Desplegar AWS IAM Identity Center integrado con Okta SAML como el único plano de identidad federada y migrar a todos los usuarios humanos y contratistas desde usuarios de IAM de larga duración a cuentas basadas en Identity Center, deshabilitando la consola/claves para los usuarios de IAM heredados.
Crear conjuntos de permisos centralizados en IAM Identity Center que se asignen a roles de IAM en las cuentas miembro e implementar límites de permisos de IAM (definidos como políticas de IAM) para todos los roles; desplegar estos límites y plantillas de roles en todas las cuentas usando AWS CloudFormation StackSets.
Actualizar las políticas de confianza de los roles entre cuentas para permitir sts:AssumeRole únicamente desde los ARN de los principales de Identity Center e incluir condiciones que requieran MFA (p. ej., aws:MultiFactorAuthPresent) y restricciones de cuenta de origen; requerir que las etiquetas de sesión (session tags) contengan atributos de identidad.
Forzar el uso de MFA en el IdP (Okta) y reflejar esa obligatoriedad en AWS requiriendo condiciones de MFA en las sesiones de rol; denegar la creación de acceso a la consola o de nuevos usuarios de IAM aplicando Políticas de Control de Servicios (SCPs) en AWS Organizations.
Habilitar AWS CloudTrail, AWS Config e IAM Access Analyzer para el monitoreo continuo y la validación de políticas, y enviar los hallazgos a CloudWatch/GuardDuty para alertas y flujos de trabajo de remediación automatizada.

Justificación: Centralizar la federación a través de IAM Identity Center, aplicar el privilegio mínimo con conjuntos de permisos y límites, requerir MFA en las políticas de confianza y aplicar SCPs a nivel de organización junto con el monitoreo, se alinea con las mejores prácticas de AWS para reducir el radio de impacto, prevenir la escalada de privilegios y proporcionar auditabilidad.

Roles de IAM y políticas de confianza: PassRole y AssumeRole

Un rol de IAM tiene dos superficies de políticas distintas, y confundirlas es la causa principal de la mayoría de los fallos de autorización entre cuentas. La política de confianza (el AssumeRolePolicyDocument) responde a quién puede asumir el rol y bajo qué condiciones. La política de permisos responde a qué puede hacer el rol una vez asumido. Ambas deben permitir la acción; la política de confianza por sí sola nunca concede acceso a S3, KMS ni a nada más.

Cuando una entidad principal llama a sts:AssumeRole, STS evalúa la política de confianza del rol de destino en función de la identidad que realiza la llamada más el contexto de la sesión (IP de origen, estado de MFA, etiquetas de sesión, ID externo). La entidad principal que realiza la llamada debe tener también un Allow basado en la identidad para sts:AssumeRole sobre ese ARN de rol. Este doble requisito es lo que hace que la asunción de roles sea segura a través de los límites de las cuentas.

Una política de confianza canónica entre cuentas que requiere MFA y un ID externo tiene este aspecto:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "Bool": { "aws:MultiFactorAuthPresent": "true" },
      "NumericLessThan": { "aws:MultiFactorAuthAge": "3600" },
      "StringEquals": { "sts:ExternalId": "unique-partner-id-8842" }
    }
  }]
}

La clave aws:MultiFactorAuthPresent solo tiene sentido en la política de confianza de un rol asumible, porque el contexto de MFA se establece en la llamada a STS, no en las llamadas a servicios posteriores. Añadir condiciones de MFA a la política del bucket de S3 o a la política de permisos del rol es un error común: la sesión del rol asumido normalmente no lleva aws:MultiFactorAuthPresent=true aunque el humano original se haya autenticado con MFA, por lo que esas condiciones deniegan todo silenciosamente. Exija el MFA en el momento de la asunción; utilice aws:MultiFactorAuthAge para forzar la reautenticación en sesiones de larga duración.

PassRole es la segunda barrera que causa problemas en los escenarios de examen. Cuando le indicas a un servicio como CloudFormation, EC2, Lambda o CodeBuild que se ejecute como un rol, la identidad que realiza la llamada debe tener `iam:PassRole

Problema práctico: Escenario de caso de uso

Escenario: Meridian Financial gestiona una AWS Organization multicuenta con cuentas separadas para producción, desarrollo y herramientas de CI/CD; utilizan roles de IAM centralizados para despliegues entre cuentas y agentes de CI de terceros que asumen roles para realizar cambios en la infraestructura. Los límites de identidad se aplican mediante políticas de confianza de roles y algunos equipos utilizan perfiles de instancia y funciones de Lambda de larga duración a los que se les concede iam:PassRole para adjuntar roles a instancias o tareas.

Desafío: Una auditoría reciente encontró que un permiso iam:PassRole demasiado amplio permitía a una entidad principal de CI/CD pasar un rol de Administrador a un perfil de instancia de EC2, y un atacante explotó una confianza de AssumeRole para obtener privilegios excesivos entre cuentas.

Enfoque recomendado:

Utilizar AWS CloudTrail y Amazon EventBridge para identificar llamadas recientes a las API iam:PassRole y sts:AssumeRole, y ejecutar consultas en CloudTrail Lake o Athena para listar qué entidades principales pasaron qué ARN de roles y cuándo.
Ejecutar IAM Access Analyzer (para IAM) en todas las cuentas para descubrir exposiciones en políticas de confianza basadas en recursos y listar los roles que son asumibles desde fuera de la Organization o por entidades principales externas.
Reemplazar las políticas iam:PassRole amplias por políticas de IAM de privilegio mínimo que especifiquen los ARN de rol exactos en Resource, y añadir claves de condición como aws:PassedToService o aws:PrincipalOrgID para limitar quién y qué puede recibir el rol.
Reforzar las políticas de confianza de los roles para requerir condiciones —utilizar aws:PrincipalOrgID, sts:ExternalId para terceros, requerir aws:SourceIdentity y aplicar duraciones máximas de sesión— para evitar AssumeRole amplios por parte de entidades principales desconocidas.
Configurar reglas de Amazon EventBridge para detectar anomalías en iam:PassRole y AssumeRole, enviar alertas a Amazon SNS y crear playbooks automatizados con Lambda para revocar o remediar políticas demasiado amplias, y registrar los hallazgos en AWS Security Hub y AWS Config para un cumplimiento continuo.

Justificación: Este enfoque aplica el principio de privilegio mínimo y la defensa en profundidad al restringir los destinos de PassRole y las políticas de confianza, a la vez que permite la detección y la remediación automatizada a través del registro y la monitorización, en línea con las mejores prácticas de AWS para IAM y federación.

Todos los dominios · Detección de Amenazas y Alertas →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →