Amazon DOP-C02: Seguridad, Cumplimiento y Gobernanza — Guía de estudio

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

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

Información general

La seguridad, el cumplimiento y la gobernanza en AWS se basan en controles deterministas que escalan entre cuentas y regiones sin ralentizar la entrega. Un diseño robusto superpone controles de identidad (IAM, límites de permisos y políticas de control de servicios), gobernanza de múltiples cuentas (AWS Organizations y Control Tower), evaluación y remediación continuas (AWS Config), detección de amenazas (Security Hub, GuardDuty, Inspector), higiene de secretos, cifrado con AWS KMS y aislamiento de red (grupos de seguridad de VPC, NACL, endpoints y PrivateLink). El objetivo es minimizar el radio de impacto, demostrar el cumplimiento de forma continua y automatizar la prevención y la remediación, preservando al mismo tiempo el privilegio mínimo y la autonomía de los desarrolladores.

Identidad, políticas y gobernanza de múltiples cuentas

Los roles de IAM, las políticas, los límites de permisos y las SCP funcionan en conjunto para formar el conjunto de permisos efectivos. Las políticas basadas en identidad de un rol de IAM definen las acciones permitidas; la política de confianza del rol define quién puede asumirlo. Los límites de permisos restringen lo que una entidad principal puede hacer, independientemente de lo que digan las políticas de identidad. Las SCP en AWS Organizations establecen el máximo absoluto para cualquier entidad principal en una cuenta miembro (incluido el usuario raíz). Las políticas basadas en recursos (para S3, KMS, Secrets Manager, etc.) pueden permitir el acceso entre cuentas, pero tampoco pueden exceder los límites impuestos por las SCP o los límites de permisos. El permiso efectivo es la intersección de: políticas de identidad ∩ límite de permisos ∩ políticas de sesión (si están presentes) ∩ política de recursos (si aplica) ∩ SCP, con cualquier Deny explícito tomando precedencia.

Utilice los límites de permisos para habilitar un autoservicio seguro en una sola cuenta. Por ejemplo, una canalización de aprovisionamiento para desarrolladores puede crear roles solo si adjunta un límite que deniegue

undefined

excepto para patrones específicos, deniegue

undefined

en claves sensibles y limite los tipos de instancia de EC2. Los límites solo pueden ser adjuntados por entidades principales que ya tengan

undefined

; proteja ese derecho rigurosamente.

Las SCP son barreras de protección para toda la organización. Las barreras de protección comunes incluyen prohibir la desactivación de AWS Config o CloudTrail, impedir invitaciones externas a la organización, denegar cambios al administrador delegado de IAM Identity Center y restringir regiones. Prefiera patrones explícitos de permitir por excepción con condiciones (por ejemplo, permitir cambios por un rol de administrador central) para minimizar la fricción. Permita siempre la creación y el uso de los roles vinculados a servicios necesarios (p. ej., para GuardDuty, Inspector, Config) o sus SCP bloquearán inadvertidamente las configuraciones de los servicios.

AWS Organizations proporciona unidades organizativas (OU) jerárquicas para separar entornos (p. ej., Sandbox, Dev, Prod), tipos de cargas de trabajo y carriles de excepción. Herede las SCP de las OU principales para evitar la deriva de políticas. Utilice el aprovisionamiento de cuentas para estandarizar la configuración de las mismas: Account Factory de AWS Control Tower (consola) o Account Factory for Terraform (AFT) para integrarlo en CI/CD. AFT añade flujos de trabajo estilo GitOps, detección de deriva y feature flags (p. ej., aprovisionamiento de Enterprise Support), y escala a cientos de cuentas con barreras de protección base consistentes.

AWS Control Tower automatiza una landing zone con barreras de protección prescriptivas. Las barreras de protección preventivas son SCP que Control Tower gestiona; las barreras de protección de detección son reglas de AWS Config que despliega. Control Tower integra IAM Identity Center para SSO y conjuntos de permisos. Utilice conjuntos de permisos basados en ABAC con atributos para el control de acceso para limitar las acciones por

undefined

o atributos de identidad. Amplíe la base con Customizations for AWS Control Tower (CfCT) para desplegar CloudFormation, SCP y paquetes de Config por OU/cuenta automáticamente. Mantenga unidades organizativas de excepción para alojar cargas de trabajo que necesiten políticas personalizadas sin debilitar las barreras de protección globales.

Cumplimiento continuo y remediación automatizada

Habilite AWS Config en toda la organización desde una cuenta de administrador delegado. Active la grabación para todos los recursos en todas las regiones y agregue la configuración de toda la organización con un agregador de la organización. Utilice reglas administradas para controles comunes (p. ej.,

undefined

) y cree reglas personalizadas respaldadas por Lambda para lógica a medida (p. ej., verificar la cadencia de rotación de KMS contra una política de 90 días o aplicar etiquetas y valores predeterminados). Los paquetes de conformidad agrupan reglas, parámetros y remediaciones en paquetes versionados y desplegables por OU; manténgalos en un control de versiones y despliéguelos a través de StackSets o CfCT para obtener consistencia y auditabilidad.

La remediación automatizada cierra el ciclo. Asigne la evaluación de incumplimiento de cada regla a un runbook de SSM Automation que aplique la configuración base: adjuntar un perfil de instancia predeterminado, aplicar una etiqueta con un valor predeterminado, activar el Bloqueo de acceso público de S3 o reiniciar una instancia de EC2 para mantenimiento. Utilice documentos parametrizados y entradas dinámicas (p. ej., del hallazgo de Config) para mantener los runbooks genéricos. Para recursos de alto riesgo, configure la remediación para que se ejecute automáticamente; para acciones sensibles, requiera una aprobación de cambio o una invocación manual a través de EventBridge y ChatOps. Proteja el propio Config con SCP que denieguen la detención del grabador o la eliminación de los canales de entrega, excepto por un administrador central.

Firewall Manager complementa esta capa para la política como servicio entre cuentas, utilizando Organizations. Delegue un administrador central y cree políticas para asociaciones de ACL web de WAF en ALBs/API Gateway orientados a internet, auditoría y limpieza de grupos de seguridad de VPC, o propagación de reglas de DNS Firewall. Esto cambia la aplicación futura de la detección/remediación a la prevención.

Protección de datos y seguridad de red

Diseñe el cifrado usando KMS con políticas de clave explícitas. Las políticas de clave, no solo las políticas de IAM, son las que en última instancia autorizan a las entidades principales para realizar operaciones criptográficas en una CMK. Adopte un modelo de política de clave basado en roles y de mínimo privilegio: delegue la administración a un rol de administrador de KMS central; conceda derechos de uso de forma restringida a los roles de las cargas de trabajo; no permita el comodín kms:* para evitar una escalada accidental de privilegios. Use claves de condición (`kms:EncryptionContext:*) para vincular el descifrado a los contextos esperados. Las claves multirregionales permiten un cifrado activo-activo donde los datos se replican entre regiones.

Las concesiones (grants) son la herramienta adecuada para delegar el uso de claves de forma temporal o con un alcance muy limitado sin editar la política de clave, y son necesarias para algunos flujos de servicio (p. ej., EC2 Auto Scaling usando plantillas de lanzamiento cifradas, uso de AMI entre cuentas). Para permitir que otra cuenta cree concesiones, la política de clave debe permitir kms:CreateGrant a las entidades principales de esa cuenta; el beneficiario (grantee) debe proporcionar un token de concesión (grant token) para su uso inmediato en la misma ruta de llamada. Para las AMI cifradas entre cuentas, copie y cifre la AMI con una CMK, comparta la AMI, permita que la cuenta de destino cree concesiones sobre la CMK y haga que el rol vinculado al servicio de destino reciba una concesión.

El cifrado de sobre (envelope encryption) es el patrón por defecto: genere una clave de datos con KMS, cifre los datos localmente con la clave de datos en texto plano, y luego almacene solo el texto cifrado y la clave de datos cifrada. En la lectura, llame a KMS Decrypt para recuperar la clave de datos en texto plano en la memoria. Esto minimiza las llamadas a KMS para cargas de datos grandes y limita la exposición de la clave en texto plano. Donde sea compatible, use el cifrado del lado del servidor gestionado por el servicio con KMS (SSE-KMS) (S3, EBS, RDS) para simplificar la operativa, pero aun así alinee las políticas de clave para los productores/consumidores entre cuentas.

La seguridad de la VPC comienza con grupos de seguridad de mínimo privilegio. Los grupos de seguridad tienen estado (stateful); el tráfico de retorno está implícito. Prefiera las referencias a grupos de seguridad en lugar de reglas basadas en CIDR para evitar listas de permisos de IP frágiles y para mantener la intención con el código de infraestructura. Los permisos de salida por defecto son arriesgados; restrinja explícitamente el tráfico de salida (egress) a los destinos requeridos y use VPC endpoints para el acceso a los servicios de AWS. Las NACL no tienen estado (stateless) y se evalúan primero; manténgalas como controles generales a nivel de subred con retornos explícitos para puertos efímeros solo cuando deba implementar un límite adicional o cumplir con requisitos normativos; de lo contrario, favorezca los grupos de seguridad por su facilidad de gestión.

Elimine las dependencias de internet usando VPC endpoints. Los endpoints de puerta de enlace (Gateway endpoints) (S3, DynamoDB) enrutan el tráfico de forma privada a través de la red de AWS; asocie una política de endpoint para restringir los buckets o tablas accesibles. Los endpoints de interfaz (Interface endpoints) (AWS PrivateLink) exponen los servicios de AWS (Secrets Manager, KMS, SSM, ECR, CloudWatch) a través de IP privadas; despliéguelos en subredes con los grupos de seguridad adecuados y habilite el DNS privado para que los nombres de servicio estándar se resuelvan a direcciones privadas. Para microservicios productor-consumidor entre cuentas/VPC, publique un servicio de endpoint respaldado por un NLB y haga que los consumidores creen endpoints de interfaz hacia él a través de PrivateLink, evitando el peering o los transit gateways y manteniendo el tráfico fuera de la red pública de internet. Combine estos controles con subredes sin NAT ni IGW, y una inspección centralizada del tráfico de salida donde se requiera acceso a internet.

Escenario de un problema práctico

Expedia Group se está expandiendo a cientos de cuentas de AWS en múltiples regiones y debe aplicar una base de seguridad estricta: sin tráfico de salida a internet para las cargas de trabajo, remediación automatizada de configuraciones incorrectas, detección centralizada de amenazas, rotación de secretos y uso compartido controlado entre cuentas de AMI cifradas para estandarizar las imágenes de oro (golden images).

Establecer una gobernanza multicuenta con AWS Organizations y AWS Control Tower

Acción: Crear OU para Sandbox, Dev, Prod y Security. Desplegar Control Tower para establecer la landing zone, habilitar las barreras de protección (guardrails) obligatorias e integrar IAM Identity Center. Usar Account Factory for Terraform (AFT) para aprovisionar cuentas a través de GitOps.
Por qué: Control Tower proporciona barreras de protección (guardrails) listas para usar y aplicadas continuamente (SCP y reglas de Config). AFT estandariza el aprovisionamiento de cuentas a escala y codifica las bases de seguridad en el control de versiones.

Crear SCP para aplicar barreras de protección globales con excepciones

Acción: Adjuntar SCP que denieguen la desactivación de CloudTrail y AWS Config, restrinjan las regiones y eviten las ACL públicas de S3. Incluir excepciones basadas en condiciones para un rol de administrador de seguridad en la OU de Security. Permitir la creación/uso de los roles vinculados a servicios (service-linked roles) requeridos.
Por qué: Las SCP limitan los privilegios de todas las entidades principales, incluida la raíz, evitando desviaciones de la configuración (drift) y permitiendo al mismo tiempo excepciones controladas para las operaciones centrales.

Desplegar paquetes de conformidad (conformance packs) de Config con remediación automatizada

Acción: Desde la cuenta de administrador delegado de Security, habilitar AWS Config en toda la organización y crear un agregador. Desplegar un paquete de conformidad que imponga el cifrado de EBS por defecto, SSH restringido, etiquetas obligatorias con valores por defecto y WAF requerido en los puntos de entrada públicos. Mapear cada regla a documentos de SSM Automation para correcciones automáticas (p. ej., adjuntar el perfil de instancia por defecto, establecer las etiquetas que faltan en ‘weekly’).
Por qué: Los paquetes de conformidad ofrecen una política como código (policy-as-code) coherente y auditable con autorremediación que mantiene los entornos en un estado de cumplimiento sin la sobrecarga de generar tickets.

Centralizar la detección con Security Hub, GuardDuty e Inspector

Acción: Habilitar GuardDuty e Inspector en toda la organización con un administrador delegado. Habilitar los estándares de Security Hub (AWS FSBP y CIS) y agregar los hallazgos (findings). Crear reglas de EventBridge para enrutar los hallazgos de alta severidad a runbooks de SSM Automation y a un tema de SNS para el personal de guardia (on-call).
Por qué: La detección gestionada y la evaluación de vulnerabilidades proporcionan una cobertura continua con una sobrecarga operativa mínima, y Security Hub consolida las señales para una clasificación (triage) y respuesta más rápidas.

Aplicar el mínimo privilegio en IAM con límites de permisos (permission boundaries) y ABAC

Acción: En las cuentas aprovisionadas con AFT, requerir que los roles creados por desarrolladores adjunten un límite de permisos que deniegue iam:PassRole excepto a roles seleccionados y que limite las API de alto impacto. Usar conjuntos de permisos (permission sets) de IAM Identity Center con ABAC para limitar las acciones por etiquetas de equipo.
Por qué: Los límites de permisos permiten un autoservicio seguro a la vez que evitan la escalada de privilegios; ABAC reduce la proliferación de políticas y se mantiene alineado con los atributos de identidad.

Reforzar las rutas de red con VPC endpoints y PrivateLink

Acción: Eliminar los IGW/NAT de las subredes de aplicación. Crear endpoints de interfaz para KMS, Secrets Manager, SSM, ECR, CloudWatch, y endpoints de puerta de enlace para S3/DynamoDB con políticas de endpoint restrictivas. Publicar los servicios de plataforma internos a través de NLB respaldados por PrivateLink para el consumo entre cuentas.
Por qué: La conectividad privada elimina la exposición a internet y asegura que los servicios permanezcan accesibles en entornos restringidos.

Implementar una estrategia de claves KMS con concesiones (grants) para AMI entre cuentas

Acción: Crear CMK por entorno con políticas de clave con alcance a roles. En la cuenta de creación de imágenes, cifrar las AMI de oro y compartirlas. Actualizar la política de la CMK para permitir que las cuentas de destino creen concesiones, y luego crear concesiones para los roles vinculados a servicios en esas cuentas de destino.
Por qué: Las concesiones (grants) proporcionan una delegación con alcance definido y auditable sin necesidad de editar las políticas de clave para cada consumidor, permitiendo que Auto Scaling lance instancias desde AMI cifradas entre cuentas.

Estandarizar la rotación de secretos y el acceso entre cuentas

Acción: Almacenar las credenciales de bases de datos y API en Secrets Manager. Implementar la rotación con Lambda para destinos que no sean RDS y habilitar la rotación integrada para RDS. Para los secretos de plataforma compartidos, adjuntar políticas basadas en recursos que concedan GetSecretValue a los roles consumidores en otras cuentas y asegurar que las políticas de la CMK permitan el descifrado. Ubicar las Lambdas de rotación en VPC con los endpoints necesarios.
Por qué: La rotación automatizada reduce el riesgo de las credenciales; las políticas de recursos alineadas con KMS permiten un consumo seguro entre cuentas, preservando el mínimo privilegio y las pistas de auditoría.

Esta arquitectura proporciona a Expedia Group barreras de protección (guardrails) de obligado cumplimiento, cumplimiento demostrable, correcciones automatizadas y rutas de acceso a datos estrictamente controladas, todo ello preservando la velocidad de los desarrolladores a través de un autoservicio seguro y conectividad privada.

← Monitoreo · Todos los dominios · Contenedores y Operaciones sin Servidor →

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