Amazon DVA-C02: Seguridad, IAM, KMS y gestión de secretos (Cognito, Secrets Manager, SSM) — Guía de estudio

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

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

IAM, Roles, Políticas y Acceso entre Cuentas

La gestión de identidades y accesos debe diseñarse en torno al privilegio mínimo, credenciales de corta duración y una separación clara entre identidades de servicio y humanas. Para aplicaciones que se ejecutan en EC2, ECS o Lambda, prefiera roles de instancia/tarea/función en lugar de incrustar claves de acceso; los SDK de AWS utilizan automáticamente la cadena de proveedores de credenciales proporcionada por el entorno y renuevan las credenciales temporales. El acceso entre cuentas debe usar AWS STS AssumeRole (API: sts:AssumeRole) con una política de confianza de rol explícita en la cuenta de destino y una política de IAM en la cuenta que realiza la llamada que limite qué ARN de rol se pueden asumir. Cuando requiera MFA para operaciones sensibles, aplíquelo con una condición en la política de rol o de recurso usando aws:MultiFactorAuthPresent o requiera sts:GetSessionToken para usuarios humanos. Para clientes web o móviles, use AssumeRoleWithWebIdentity (sts:AssumeRoleWithWebIdentity) a través de Cognito Identity o proveedores federados para evitar credenciales a largo plazo. Tenga cuidado con las trampas comunes: acciones/recursos con comodines (wildcards) demasiado permisivos, confiar en políticas basadas en recursos sin las condiciones de principal correspondientes, y olvidar incluir las condiciones SourceAccount o aws:SourceVpc para el acceso entre cuentas a S3 o KMS. Use el simulador de políticas de IAM y sts:GetCallerIdentity para depurar. Considere usar políticas de control de servicios (SCPs) a nivel de organización para aplicar barreras de protección (guardrails) y una denegación explícita para acciones de riesgo como kms:CreateGrant o iam:CreateAccessKey cuando sea apropiado.

KMS, Patrones de Cifrado y Control de Acceso a Claves

Use AWS KMS para el cifrado de sobre (envelope encryption): llame a GenerateDataKey/GenerateDataKeyWithoutPlaintext para producir una clave de datos para el cifrado del lado del cliente o del servidor, luego llame a Encrypt/Decrypt para cargas útiles (payloads) pequeñas o use la clave de datos para el cifrado masivo. Elija la CMK adecuada: propiedad de AWS para mayor comodidad, gestionada por AWS (aws/*) para la integración de servicios, o gestionada por el cliente para un control total y rotación. Las políticas de clave son el control principal para KMS; adjunte políticas de IAM que permitan kms:Decrypt, kms:Encrypt y use concesiones (grants) cuando necesite un uso de clave temporal y delegado para servicios como operaciones respaldadas por CloudHSM o la invocación de Lambda entre cuentas. Incluya un EncryptionContext para vincular el texto cifrado a un contexto de uso y requiéralo a través de una condición kms:EncryptionContextEquals para una mayor garantía. El uso de KMS entre cuentas requiere entradas explícitas en la política de clave que otorguen permisos al principal o rol externo y, en algunos casos, permisos de CreateGrant/RetireGrant. Para auditoría y análisis forense, habilite los eventos de datos de CloudTrail para KMS y S3 para capturar las llamadas a GenerateDataKey y Decrypt; los logs de CloudTrail incluirán arn:aws:kms y detalles sobre qué principal usó la clave. Errores comunes incluyen olvidar permitir kms:CreateGrant para servicios que usan concesiones automáticamente, no rotar las claves gestionadas por el cliente y asumir que las políticas de IAM por sí solas pueden autorizar operaciones de KMS sin las entradas adecuadas en la política de clave.

Gestión de Secretos: Secrets Manager vs Parameter Store

Secrets Manager y Systems Manager Parameter Store ofrecen almacenamiento de secretos cifrados, pero difieren en características y perfil de costos: Secrets Manager admite rotación automática (con plantillas de rotación de Lambda), versionado integrado y replicación integrada, y cobra por secreto; Parameter Store (SecureString) tiene un nivel gratuito para muchos parámetros y es mejor para configuración simple. El acceso se controla mediante políticas de IAM que otorgan secretsmanager:GetSecretValue o ssm:GetParameter con WithDecryption=true, y la clave KMS subyacente debe permitir la desencriptación para el principal. Use políticas basadas en recursos en Secrets Manager para secretos entre cuentas, o la replicación con replicación de secretos. Al usar los SDK, llame a

undefined

o

undefined

y evite registrar los valores de los secretos en los logs; configure las variables de entorno de Lambda para usar referencias a Secrets Manager o Parameter Store con resolución dinámica en CloudFormation o SAM, o use la recuperación mediante el SDK al inicio. Errores comunes de los desarrolladores incluyen almacenar secretos en texto plano en el control de versiones, confiar en las variables de entorno de Lambda para datos muy sensibles sin protección de KMS, y políticas de IAM demasiado permisivas como otorgar secretsmanager:* a roles amplios. Para la rotación, asegúrese de que la Lambda de rotación tenga los permisos correctos de secretsmanager:RotateSecret y kms:GenerateDataKey, y que el código de la aplicación pueda reinicializar las conexiones sin interrupciones cuando las credenciales cambien.

Autenticación, autorización e integración de API con Cognito

Amazon Cognito proporciona user pools para la autenticación y identity pools para credenciales temporales de AWS. Usa Cognito User Pools para gestionar el registro de usuarios, la autenticación multifactor (MFA) y la emisión de JWT (tokens de ID, de acceso y de actualización). Las aplicaciones de página única (single-page apps) basadas en navegador deben usar clientes de aplicación sin un secreto de cliente y deberían utilizar la UI alojada o el SDK de Amazon Cognito (amazon-cognito-identity-js) que implementa el flujo SRP para evitar exponer contraseñas. Verifica los JWT en el servidor o en API Gateway obteniendo el URI del JWKS del user pool y validando la firma, el emisor (issuer), la audiencia (aud) y la expiración del token; los autorizadores JWT de API Gateway o los autorizadores personalizados de Lambda pueden realizar esta validación. Para la autenticación de servidor a servidor, intercambia el token del user pool por credenciales temporales a través de un Cognito Identity Pool con sts:AssumeRoleWithWebIdentity. Algunos errores comunes incluyen URL de callback o de cierre de sesión mal configuradas, no validar los scopes o grupos del token, y esperar que los tokens de ID se puedan usar directamente para llamadas a la API de AWS (debes intercambiarlos a través de un identity pool). Para una autorización detallada, usa grupos o claims personalizados y combina Cognito con políticas basadas en recursos y claves de condición de IAM como aws:userid o cognito-identity.amazonaws.com:sub al mapear la identidad a roles de AWS. Audita los inicios de sesión y las acciones administrativas a través de CloudTrail, y activa las características de seguridad avanzada en Cognito para la detección de credenciales comprometidas.

Problema práctico: Escenario de caso de uso

Escenario: PixelForge, un estudio de videojuegos, ejecuta un backend serverless en una única cuenta de AWS con Lambda, API Gateway, S3, DynamoDB y Cognito user pools. Se almacenan claves de API y credenciales de bases de datos sensibles para múltiples entornos de despliegue, y un equipo de auditoría externo debe acceder a subconjuntos de imágenes de producción en S3 durante 1 a 24 horas.

Desafío: Proporcionar de forma segura acceso auditable y de corta duración a las imágenes de producción para auditores externos, asegurar que los secretos de la aplicación se roten y sean accedidos de forma segura por Lambda, y exigir MFA para el acceso administrativo entre cuentas.

Enfoque recomendado:

1. Crear una clave KMS gestionada por el cliente con una política de clave que permita el descifrado para la cuenta de PixelForge y otorgue permisos a un rol de IAM para auditores; habilitar la rotación de claves y requerir un EncryptionContext durante las operaciones de descifrado.
2. Almacenar las credenciales en Secrets Manager (secretos separados por entorno) y adjuntar un rol de IAM a las funciones Lambda con el permiso mínimo secretsmanager:GetSecretValue y kms:Decrypt para la clave KMS; implementar código de inicio en Lambda para llamar a

undefined

usando el SDK de AWS. 3. Para el acceso de los auditores, crear un rol separado en la cuenta de AWS del auditor y permitir sts:AssumeRole desde la cuenta del auditor en una política de bucket de S3 basada en recursos, limitada por aws:PrincipalArn y un mapeo de roles preconfigurado y con límite de tiempo; generar credenciales de corta duración mediante sts:AssumeRole y exigir MFA con una condición aws:MultiFactorAuthPresent al asumir el rol. 4. Registrar todos los accesos con CloudTrail (eventos de gestión y de datos para S3 y KMS) y habilitar el registro a nivel de objeto de S3 y Amazon Macie o S3 Access Logs para análisis forense adicional; requerir que las sesiones temporales de los auditores usen un EncryptionContext específico y etiquetar objetos/solicitudes para la trazabilidad.

Justificación: Usar Secrets Manager con KMS y credenciales de corta duración de STS impone el principio de privilegio mínimo, permite la rotación automatizada y evita incrustar secretos en el código. Los patrones de assume-role con límite de tiempo, junto con MFA y los eventos de datos de CloudTrail, proporcionan un acceso auditable y revocable para terceros, al tiempo que se preserva la separación de responsabilidades.

← Despliegue y CI · Todos los dominios · Monitoreo →

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

Explorar Amazon →