Amazon SOA-C02: Seguridad, Identidad y Cumplimiento — Guía de estudio

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

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

Este dominio abarca las primitivas de identidad, cifrado, secretos y auditoría que sustentan las operaciones seguras y conformes en AWS. Se centra en conceder el acceso correcto (principio de privilegio mínimo), proteger los datos mediante la gestión de claves y el cifrado, y crear pistas de auditoría inmutables para una conformidad continua. Las responsabilidades diarias de SysOps incluyen diseñar roles de IAM y límites de confianza, operar claves y secretos de KMS, y usar AWS Config y CloudTrail para detectar desviaciones y violaciones de políticas.

IAM, roles, políticas y federación

La gobernanza de IAM debe comenzar con la separación de roles y el privilegio mínimo: use roles separados para la administración, el registro y las cargas de trabajo de las aplicaciones; evite adjuntar políticas amplias como AdministratorAccess a entidades principales de larga duración. Cree roles con una política de confianza (consola o CLI: aws iam create-role –role-name AppRole –assume-role-policy-document file://trust.json) y adjunte políticas de permisos usando aws iam put-role-policy o políticas administradas. Use límites de permisos y condiciones de IAM (aws:SourceIp, aws:RequestedRegion) para limitar dónde y cómo se pueden ejercer los privilegios.

Para la federación de identidades, prefiera SAML/OIDC para emitir credenciales temporales a través de STS. Para SAML, configure un proveedor de identidad en IAM y use aws sts assume-role-with-saml –role-arn arn:aws:iam::123456789012:role/SAMLRole –principal-arn arn:aws:iam::123456789012:saml-provider/IdP. Para OIDC (Cognito, Auth0 u otros proveedores), cree un proveedor OIDC de IAM y mapee las notificaciones (claims) a los roles; la federación de identidades web usa aws sts assume-role-with-web-identity. Elija roles federados cuando los usuarios son externos o cuando los servicios de directorio centralizados gestionan la autenticación; use AWS IAM Identity Center (SSO) para el acceso empresarial centralizado y la gestión de sesiones.

KMS, gestión de claves y cifrado

KMS es el servicio central para el ciclo de vida de las claves y el control de acceso. Elija entre claves administradas por AWS (simplicidad), claves propiedad de AWS y CMK administradas por el cliente (control detallado). Cree CMK con aws kms create-key –description “CMK for prod” y habilite la rotación automática con aws kms enable-key-rotation –key-id alias/ProdKey. Use políticas de clave para definir quién puede administrar las claves y use concesiones (grants) para la delegación de acceso temporal (aws kms create-grant) en lugar de políticas de IAM amplias.

Criterios de decisión: use CMK cuando se requiera auditoría y control del ciclo de vida de la clave (rotación, ventanas de eliminación); use claves administradas por AWS para una conveniencia automática en muchos servicios administrados. Proteja las claves aplicando políticas de IAM + políticas de clave, restrinja el uso a través de kms:ViaService o concesiones de KMS para uso entre cuentas, y evite programar la eliminación inmediata; use una ventana de espera mínima. Supervise el uso de KMS con los registros de CloudTrail para las operaciones Encrypt/Decrypt y GenerateDataKey para detectar un uso anómalo.

Gestión de secretos y almacenes de parámetros

Use AWS Secrets Manager para la rotación de credenciales y la automatización del ciclo de vida, y Systems Manager Parameter Store (SecureString) para secretos más simples donde la rotación es manual. Cree secretos a través de aws secretsmanager create-secret –name prod/db –secret-string ‘{“username”:“app”,“password”:"…"}’ y habilite la rotación especificando una función Lambda para la rotación automática. Para Parameter Store, use aws ssm put-parameter –name /prod/db/password –value “…” –type SecureString –key-id alias/ProdKey.

Puntos de decisión:

Secrets Manager: rotación integrada, versiones de secretos, replicación y plantillas de rotación de consola integradas; mayor costo pero mejor para credenciales de bases de datos y claves de API.
Parameter Store SecureString: nivel gratuito para almacenamiento básico de secretos, use una CMK de KMS para el cifrado y políticas de IAM para el acceso. Restrinja siempre el acceso a los secretos mediante políticas de IAM de privilegio mínimo y prefiera el acceso basado en roles (roles de ejecución de EC2/ECS/Lambda) en lugar de incrustar credenciales de larga duración en el código o en variables de entorno.

AWS Config, auditoría y monitoreo de conformidad

AWS Config proporciona registro continuo de recursos, historial de cambios y evaluación de reglas. Habilite un grabador y un canal de entrega (consola o aws configservice start-configuration-recorder) y cree reglas administradas o personalizadas con aws configservice put-config-rule. Combine Config con CloudTrail (aws cloudtrail create-trail –name audit –s3-bucket audit-bucket) y CloudWatch Alarms para la detección y remediación casi en tiempo real (use acciones de remediación de Config o documentos de Systems Manager Automation).

Decisiones de diseño: use reglas administradas de Config para comprobaciones estándar (lectura pública de buckets de S3, MFA en la cuenta raíz) y reglas personalizadas (Lambda) para controles específicos del dominio. Asegure la agregación multirregional de los datos de Config en un agregador y habilite el registro multicuenta a través de AWS Organizations. Mantenga una pista de auditoría inmutable enviando los registros de CloudTrail a un bucket de S3 centralizado y cifrado (SSE-KMS) y habilite CloudTrail Insights para detectar actividad anómala de la API.

Protección de datos, cifrado en tránsito y en reposo

El cifrado debe aplicarse en capas: en reposo usando cifrado respaldado por KMS para EBS, RDS, S3 (SSE-S3, SSE-KMS o SSE-C) y en tránsito usando TLS para el tráfico de aplicaciones (use ACM para certificados públicos/privados y adjúntelos a los listeners de ALB/NLB: aws elbv2 create-listener –load-balancer-arn … –protocol HTTPS –port 443 –certificates CertificateArn=arn:aws:acm:…). Use el cifrado del lado del cliente cuando se requiera un control adicional y considere el cifrado de sobre con GenerateDataKey al cifrar grandes volúmenes de datos fuera de las cuotas de KMS.

Aplique estos criterios de decisión:

Use SSE-KMS para objetos de S3 cuando necesite auditoría y controles de acceso a la clave; SSE-S3 es adecuado para el cifrado básico del lado del servidor.
Use CMK de KMS para EBS y RDS cuando necesite rotación de claves y control de acceso entre cuentas.
Fuerce siempre el uso de TLS para los puntos de conexión de servicios; use HSTS y algoritmos de cifrado robustos en los balanceadores de carga. Use puntos de conexión de VPC y políticas de IAM para reducir la exposición pública de las API del plano de datos.

Errores Comunes y Criterios de Decisión

Uso excesivo de la cuenta raíz o almacenamiento de sus credenciales: en su lugar, cree roles de administrador con MFA y use AWS SSO o roles de IAM para las tareas diarias; guarde las credenciales raíz en una bóveda segura y habilite MFA.
Depender de claves de acceso de larga duración: rote las claves regularmente o elimínelas en favor de credenciales temporales a través de STS y encadenamiento de roles (roles de EC2/ECS/Lambda).
No rotar o proteger incorrectamente las claves y secretos de KMS: habilite la rotación automática para las CMK cuando sea apropiado, use la rotación de Secrets Manager para las credenciales de bases de datos y monitoree el uso de claves a través de CloudTrail.
Confiar en los permisos o ACL predeterminados de S3: aplique políticas de bucket, bloquee el acceso público y use SSE-KMS para datos sensibles; valide con reglas de AWS Config.
Uso incorrecto de las políticas de clave frente a las políticas de IAM: gestione la administración de la clave en la política de clave de KMS y otorgue el uso a través de concesiones (grants) o IAM cuando sea apropiado; evite otorgar permisos de Decrypt de forma amplia.
Olvidar la centralización de registros y la agregación multirregional: configure trails multirregionales de CloudTrail y agregadores de Config para el cumplimiento entre cuentas.

Problema Práctico: Escenario de Caso de Uso

AcmeFin, una empresa fintech, necesita asegurar las bases de datos y API de producción, al tiempo que proporciona acceso temporal a contratistas y mantiene la auditabilidad para las auditorías de cumplimiento.

Crear roles de IAM separados para el acceso de administrador, aplicación y contratista; exigir MFA y usar IAM Identity Center para la federación basada en SAML para los contratistas.
Cifrar RDS y EBS con una CMK gestionada por el cliente (aws kms create-key), habilitar la rotación de claves y restringir el uso de la clave mediante una política de clave estricta que solo permita los roles de base de datos y auditoría.
Almacenar las credenciales de la base de datos en AWS Secrets Manager con rotación automatizada utilizando la plantilla de rotación de Lambda proporcionada.
Habilitar CloudTrail (multirregional) y el grabador de AWS Config, enviar los registros a un bucket de S3 central cifrado con SSE-KMS y crear reglas de Config para S3 público y recursos no cifrados.
Usar un ALB con certificados emitidos por ACM para HTTPS, y colocar las API detrás de WAF y endpoints de VPC cuando sea apropiado.

Este enfoque aplica el privilegio mínimo mediante la separación de roles, automatiza la rotación de credenciales y claves para reducir el radio de impacto (blast radius), y centraliza los registros y las evaluaciones de Config para que los auditores puedan verificar los controles mientras que las operaciones mantienen patrones de acceso seguros y temporales.

← Implementación · Todos los dominios · Redes y Entrega de Contenido →

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