Amazon SCS-C02: Gobernanza, Configuración y Automatización — 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.

Políticas de Control de Servicio y Barreras de Protección a Nivel de Organización

Las Service Control Policies (SCPs) forman el límite más externo de lo que cualquier principal puede hacer en una AWS Organization. Una SCP no es una política de IAM; no concede nada, solo define los permisos máximos disponibles para las cuentas bajo una OU o para toda la organización. Un Allow en una política de IAM, una política de recursos o un límite de permisos (permissions boundary) es completamente inerte si una SCP deniega la acción. Esta asimetría es exactamente la razón por la que las SCPs son la herramienta correcta para establecer barreras de protección (guardrails) a nivel de organización: restricciones de región, servicios prohibidos, protección de roles de IAM gestionados centralmente y aplicación del cifrado en la creación de recursos.

Una SCP canónica que deniega la creación de tablas de DynamoDB y buckets de S3 sin cifrar se ve así:

Version: "2012-10-17"
Statement:
  - Sid: DenyUnencryptedS3
    Effect: Deny
    Action: s3:CreateBucket
    Resource: "*"
    Condition:
      StringNotEquals:
        s3:x-amz-server-side-encryption-aws-kms-key-id: !Ref CmkArn
  - Sid: DenyUnencryptedDdb
    Effect: Deny
    Action: dynamodb:CreateTable
    Resource: "*"
    Condition:
      "Null":
        dynamodb:SSESpecificationEnabled: "true"

Una trampa común es intentar forzar que “nadie en la organización pueda usar us-east-2” o que “nadie pueda deshabilitar CloudTrail” mediante políticas de IAM adjuntas en cada cuenta. Incluso con un límite de permisos y una alineación de políticas de identidad, un administrador local puede concederse una vía de escape. Solo se puede confiar en una SCP aplicada en la raíz o en una OU, porque restringe incluso al usuario raíz de las cuentas miembro (con la pequeña excepción de un puñado de acciones que no se pueden restringir).

Las SCPs también deberían proteger los roles de acceso de emergencia (break-glass) y de administración delegada: añade un Deny explícito a cualquier acción dirigida a un rol como OrganizationAccountAccessRole o SecurityAudit, a menos que el aws:PrincipalArn de quien realiza la llamada coincida con una lista aprobada.

AWS Config, Paquetes de Conformidad y Aplicación Multi-Cuenta

AWS Config proporciona la capa de evaluación continua que complementa a las SCPs (que previenen) con la detección (que observa e informa sobre desviaciones o drift). Un paquete de conformidad (conformance pack) es un conjunto de reglas de Config —tanto reglas administradas como s3-bucket-server-side-encryption-enabled como reglas personalizadas respaldadas por Lambda o Guard— empaquetado como un único artefacto YAML desplegable con acciones de remediación opcionales.

Para desplegar una línea base estándar en toda la organización, se combinan dos mecanismos:

CloudFormation StackSets desde la cuenta de administración con permisos administrados por el servicio y AutoDeployment: Enabled para que cualquier cuenta nueva que se una a la organización reciba automáticamente un stack que active el grabador (recorder) y el canal de entrega (delivery channel) de Config. Esto resuelve el problema de arranque (bootstrap): un paquete de conformidad no puede evaluar una cuenta donde Config no está habilitado.
Paquetes de conformidad desplegados desde la cuenta de administrador delegado (por ejemplo, security-01) usando PutOrganizationConformancePack. Esto propaga un conjunto de reglas consistente a todas las cuentas actuales y futuras sin necesidad de tocar cada cuenta manualmente.

El patrón de administrador delegado + agregador es importante: permite al equipo de seguridad ver el cumplimiento de todas las cuentas en un solo lugar, al tiempo que permite a los equipos de aplicación añadir sus propias reglas localmente. Desplegar las mismas reglas directamente desde la cuenta de administración funcionaría, pero viola el principio de privilegio mínimo y bloquea las auditorías de separación de funciones.

CloudFormation Guard, StackSets y Service Catalog

La prevención debe desplazarse a la izquierda (shift left). CloudFormation Guard (cfn-guard) es un motor de política como código (policy-as-code) que analiza plantillas de CloudFormation (o cualquier JSON/YAML) y las evalúa contra reglas declarativas antes del despliegue. Una regla de Guard se ve así:

rule s3_encrypted {
  Resources.*[ Type == "AWS::S3::Bucket" ] {
    Properties.BucketEncryption exists
    Properties.BucketEncryption.ServerSideEncryptionConfiguration[*] {
      ServerSideEncryptionByDefault.SSEAlgorithm == "aws:kms"
    }
  }
}

Integrar esto en una etapa de CI/CD —típicamente como un paso en un contenedor Docker que ejecuta cfn-guard validate -r rules.guard -d template.yaml— hace que el pipeline falle antes de que se cree cualquier recurso no conforme. En caso de una violación, el pipeline publica en un tema de SNS al que el equipo de seguridad está suscrito, dándoles visibilidad sin convertirse en un cuello de botella de aprobación manual. Confiar únicamente en los StackSets o en la revisión de conjuntos de cambios (change-set) de CloudFormation para notificar al equipo de seguridad es una trampa: ninguno de los dos servicios emite resultados de cumplimiento por recurso, y para cuando se ha creado un stack, el recurso ya existe en la cuenta.

Service Catalog complementa a Guard en la última milla (last mile). En lugar de permitir que los desarrolladores escriban CloudFormation arbitrario, el equipo de plataforma publica productos verificados (líneas base de VPC, patrones de RDS, clústeres de EKS) como portafolios de Service Catalog compartidos entre cuentas a través de AWS RAM. Los desarrolladores los lanzan con parámetros restringidos, y un rol de IAM de restricción de lanzamiento (launch constraint) aprovisiona los recursos con permisos elevados que el desarrollador no posee personalmente. Esto proporciona un modelo de despliegue de autoservicio auditable donde la plantilla subyacente ya ha pasado las verificaciones de Guard.

Los propios StackSets necesitan una configuración correcta: utiliza el modelo de permisos SERVICE_MANAGED al desplegar desde la cuenta de administración de la organización, habilita el acceso de confianza para CloudFormation en Organizations y configura los roles de ejecución cuidadosamente. El par AdministrationRoleARN/ExecutionRoleName (en modo autogestionado o self-managed) o los roles vinculados a servicios (en modo administrado por el servicio o service-managed) deben tener el permiso iam:PassRole para el rol de servicio de CloudFormation que realmente crea los recursos. Olvidar adjuntar un rol de servicio de CloudFormation y en su lugar depender de las credenciales del usuario que despliega conduce a errores intermitentes de AccessDenied en iam:PassRole, una causa común de operaciones de StackSet fallidas. El patrón correcto es un rol de servicio dedicado por cada stack con solo los permisos necesarios para crear los tipos de recursos declarados.

Canalizaciones de remediación automatizada

Cuando Config detecta un incumplimiento, la remediación debe ser automática para todo lo que pueda autorrepararse de forma segura. El flujo de eventos es:

Config publica un evento Compliance Change en el bus de eventos predeterminado.
Una regla de EventBridge filtra los hallazgos NON_COMPLIANT en reglas específicas y los dirige a un documento de Systems Manager Automation (para correcciones simples e idempotentes como habilitar el cifrado de S3), a una función de Lambda (para correcciones a nivel de API) o a una máquina de estados de Step Functions (para flujos de trabajo de varios pasos que requieren aprobaciones, reintentos u orquestación entre servicios).

Por ejemplo, si se activa s3-bucket-public-read-prohibited, un runbook de SSM Automation AWS-DisableS3BucketPublicReadWrite lo remedia. Para flujos más complejos —por ejemplo, una política de clave de KMS que se desvía y debe ser reconciliada mientras se notifica al equipo propietario— Step Functions coordina: leer la política actual, compararla con la versión de referencia (golden version), llamar a kms:PutKeyPolicy y luego publicar en SNS. Almacenar la lógica de remediación en Step Functions en lugar de en una única Lambda proporciona observabilidad en cada paso y una semántica de reintentos limpia.

IAM Access Analyzer y validación de políticas

IAM Access Analyzer responde a dos preguntas distintas. Primero, los analizadores de acceso externo identifican recursos (S3, KMS, roles de IAM, Lambda, SQS, Secrets Manager) cuyas políticas otorgan acceso a entidades principales (principals) fuera de una zona de confianza definida, ya sea la cuenta o la organización. Habilite el analizador a nivel de organización desde la cuenta de administrador delegado para que los hallazgos se agreguen de forma centralizada.

Segundo, la validación de políticas y la generación de políticas de Access Analyzer se ejecutan durante la creación. aws accessanalyzer validate-policy devuelve advertencias de seguridad, errores y sugerencias (por ejemplo, marcando un Resource: "*" demasiado amplio combinado con acciones sensibles). Integre esto en la misma etapa de CI/CD que cfn-guard para que las políticas de IAM incrustadas en CloudFormation se verifiquen antes del despliegue. Access Analyzer también puede generar una política de privilegio mínimo a partir del historial de CloudTrail, reemplazando una política con comodines (wildcard) por las acciones exactas que un rol ha utilizado realmente; es la respuesta mecánica para «aplicar el privilegio mínimo para el acceso a los datos» junto con una política de clave de KMS con alcance limitado que solo permite kms:Decrypt cuando el servicio que llama es S3, DynamoDB, Lambda o EKS a través de condiciones kms:ViaService.

Problema práctico: Escenario de caso de uso

Escenario: Meridian Financial opera una AWS Organization multicuenta que incluye cuentas de producción, staging, sandbox y una cuenta de seguridad centralizada. Despliegan cargas de trabajo con una mezcla de plantillas de CloudFormation y plantillas impulsadas por desarrolladores en el sandbox; la propiedad está federada entre equipos y deben cumplir con la gobernanza interna para el cifrado de datos y el acceso de privilegio mínimo.

Desafío: Los desarrolladores en el sandbox han creado accidentalmente buckets de S3 públicos y políticas de IAM demasiado permisivas que se propagaron a otras cuentas, y el equipo de seguridad carece de una aplicación automatizada y consistente y de validación de plantillas en toda la Organization.

Enfoque recomendado:

Crear Service Control Policies (SCPs) a nivel de Organization para denegar el acceso público a S3, forzar el cifrado de buckets y restringir acciones privilegiadas de IAM en la raíz de la Organization para proporcionar barreras de protección (guardrails) preventivas.
Desde la cuenta de seguridad central, desplegar un agregador de AWS Config y Conformance Packs usando CloudFormation StackSets en cada cuenta y región para evaluar continuamente el acceso público a S3, los patrones de adjunción de políticas de IAM y el cumplimiento del cifrado.
Integrar reglas de CloudFormation Guard (cfn-guard) en la canalización de CI/CD (CodePipeline/CodeBuild) y requerir productos de Service Catalog para la infraestructura aprobada, de modo que las plantillas se validen y solo se puedan aprovisionar stacks que cumplan con las políticas.
Habilitar la remediación automatizada de AWS Config con documentos de SSM Automation o runbooks de Lambda para hallazgos de alta prioridad (bloquear automáticamente el acceso público a S3, remediar políticas de IAM demasiado amplias) y activar flujos de trabajo adicionales a través de EventBridge.
Ejecutar IAM Access Analyzer y la validación de políticas de forma centralizada, ingerir los hallazgos en Security Hub y automatizar la creación de tiques o los playbooks de remediación para políticas entre cuentas o demasiado permisivas que se descubran.

Justificación: Este enfoque combina barreras de protección preventivas para toda la organización (SCPs), detección continua (Config/Conformance Packs), validación de plantillas temprana (shift-left) (cfn-guard/Service Catalog) y remediación automatizada con IAM Access Analyzer para aplicar el privilegio mínimo y lograr una gobernanza multicuenta consistente según las mejores prácticas de AWS.

AWS Config: Reglas de organización, agregadores y administración delegada

AWS Config es la base del cumplimiento detectivo en AWS. Registra continuamente las configuraciones de los recursos y las evalúa contra reglas, ya sean gestionadas por AWS (por ejemplo, restricted-ssh, vpc-flow-logs-enabled, encrypted-volumes) o personalizadas (respaldadas por Lambda o Guard). A escala empresarial, tres decisiones de arquitectura importan más que las reglas en sí: cómo se despliegan las reglas, cómo se agregan los hallazgos y quién es el propietario de las herramientas.

Para despliegues multicuenta y multirregión bajo AWS Organizations, el patrón correcto es designar una cuenta de administrador delegado (típicamente la cuenta de seguridad o auditoría, no la cuenta de administración) mediante aws organizations register-delegated-administrator --service-principal=config-multiaccountsetup.amazonaws.com. Desde esa cuenta, usa PutOrganizationConfigRule o PutOrganizationConformancePack para distribuir las reglas a cada cuenta miembro y región. Omitir la administración delegada te obliga a habilitar Config manualmente en cada cuenta o a ejecutar todo desde la cuenta de administración; esto último viola la separación de funciones y lo primero no escala más allá de un puñado de cuentas.

Las reglas de organización distribuyen una única definición de regla; los agregadores recopilan las evaluaciones resultantes. Crea un agregador en la cuenta de administrador delegado con un OrganizationAggregationSource que cubra todas las cuentas y regiones. El panel del agregador responde entonces a preguntas como “¿qué VPCs en 200 cuentas no tienen Flow Logs?” sin tener que hacer malabares con roles entre cuentas. Ten en cuenta que los agregadores son de solo lectura: exponen el estado de cumplimiento, pero no remedian por sí mismos.

Paquetes de conformidad para la aplicación de líneas base

Un paquete de conformidad agrupa reglas de Config y sus acciones de remediación en una única plantilla YAML. AWS ofrece paquetes mapeados a marcos de referencia como PCI DSS, HIPAA, NIST 800-53 y CIS. Desplegar un paquete de conformidad de la organización desde el administrador delegado apunta a OUs específicas; por ejemplo, aplicando un paquete más estricto a la OU Prod que a la de Sandbox. Esta es la forma más eficiente de aplicar una línea base consistente en cientos de cuentas, porque una sola llamada a la API propaga el conjunto de reglas y su cableado de remediación a todas partes a la vez.

Resources:
  EncryptedVolumesRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: encrypted-volumes
      Source:
        Owner: AWS
        SourceIdentifier: ENCRYPTED_VOLUMES
  EncryptedVolumesRemediation:
    Type: AWS::Config::RemediationConfiguration
    Properties:
      ConfigRuleName: encrypted-volumes
      TargetType: SSM_DOCUMENT
      TargetId: AWSConfigRemediation-EncryptS3BucketVolume
      Automatic: true
      MaximumAutomaticAttempts: 3
      RetryAttemptSeconds: 60

Patrones de remediación automática

Existen dos rutas de remediación canónicas, y la elección entre ellas depende de los requisitos de latencia y complejidad.

La ruta de remediación nativa de Config utiliza AWS::Config::RemediationConfiguration para invocar un runbook de SSM Automation cada vez que una regla reporta NON_COMPLIANT. AWS proporciona runbooks preconstruidos como AWS-EnableVPCFlowLogs, AWSConfigRemediation-RemoveUnrestrictedSourceIngressRules y AWSConfigRemediation-EncryptSNSTopic. Esta ruta es declarativa, se integra limpiamente con los paquetes de conformidad y es ideal cuando una demora de varios minutos es aceptable.

La ruta impulsada por EventBridge es necesaria cuando la latencia importa o cuando se necesita una orquestación personalizada. Config emite un evento Config Rules Compliance Change en cada transición de estado. Una regla de EventBridge filtra por detail.newEvaluationResult.complianceType = NON_COMPLIANT y apunta a una función Lambda (o una Step Function, o un runbook de SSM directamente). Como EventBridge se dispara a los pocos segundos de la evaluación, las ventanas de remediación por debajo del minuto se vuelven factibles.

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["restricted-ssh"],
    "newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
  }
}

El manejador de Lambda llama entonces a RevokeSecurityGroupIngress en el SG infractor. Cualquiera que sea la ruta que elijas, la automatización debe asumir un rol de IAM con los permisos mínimos para modificar el recurso de destino. Un modo de fallo frecuente es una regla de Config que muestra el estado de cumplimiento alternando entre NON_COMPLIANT y COMPLIANT indefinidamente porque el runbook de remediación falla con AccessDenied; Config registra la invocación pero procede silenciosamente. Inspecciona siempre el historial de ejecución de SSM Automation y concede al rol del runbook los permisos de modificación específicos que necesita (por ejemplo, ec2:CreateFlowLogs, iam:PassRole para el rol de entrega de flow-logs y logs:CreateLogGroup).

Systems Manager Automation y Patch Manager

Los runbooks de SSM Automation son el caballo de batalla para la remediación imperativa. Son documentos YAML/JSON versionados que describen pasos (llamadas a la API, aprobaciones, bifurcaciones) ejecutados por un rol de IAM que tú especificas. Más allá de la remediación activada por Config, ejecutan tareas de higiene programadas: rotar claves de acceso, etiquetar volúmenes EBS no adjuntos o terminar instancias detenidas después de 30 días.

Patch Manager es un subsistema de SSM que mantiene los sistemas operativos en cumplimiento con una línea base de parches (un conjunto de parches aprobados, clasificaciones y filtros de severidad). Las instancias se agrupan en grupos de parches a través de la etiqueta Patch Group; una ventana de mantenimiento programa el documento AWS-RunPatchBaseline contra ellos. El estado de cumplimiento fluye de vuelta hacia Config y Security Hub, cerrando el ciclo entre el estado a nivel de sistema operativo y los reportes organizacionales.

Service Catalog, CloudFormation StackSets y Barreras de Protección Preventivas

La detección y la remediación son reactivas. Para prevenir el incumplimiento, utiliza controles preventivos:

Service Catalog publica plantillas de CloudFormation seleccionadas y parametrizadas como productos. Los desarrolladores lanzan patrones aprobados (una VPC reforzada, un clúster RDS cifrado) sin necesitar permisos de IAM para los servicios subyacentes, lo que impone la separación de funciones entre el equipo de la plataforma y los consumidores.
CloudFormation StackSets despliega stacks idénticos entre cuentas y regiones. Con permisos administrados por el servicio y la selección de OUs como objetivo, una sola operación instala grabadores de Config, roles de IAM o detectores de GuardDuty en cada cuenta de la organización, incluidas las recién creadas mediante el despliegue automático.
Las Service Control Policies (SCPs) son el único mecanismo que puede denegar directamente una llamada a la API en el límite de la organización. Config y SSM no pueden prevenir una llamada RunInstances que carezca de cifrado; solo pueden detectarla y remediarla después. Intentar imponer prohibiciones estrictas (“nunca buckets de S3 públicos”) únicamente con reglas de Config deja una ventana de tiempo entre la creación del recurso y la remediación. Combina una regla de detección de Config con un SCP como la denegación de s3:PutBucketPublicAccessBlock para cerrar esa brecha.

Recuperación de Desastres: Copias de Seguridad, Plantillas y Control de Código Fuente

Cumplir con los objetivos de RPO/RTO requiere que tanto los datos como las definiciones de la infraestructura sean recuperables. AWS Backup centraliza las políticas de copia de seguridad en EBS, RDS, DynamoDB, EFS y FSx; las políticas de copia de seguridad de la organización imponen planes en las cuentas miembro, y las copias entre regiones y entre cuentas protegen contra la pérdida de una región y la vulneración de una cuenta. El RPO se establece por la frecuencia de las copias de seguridad; el RTO depende de la mecánica de restauración (una restauración PITR de DynamoDB tarda minutos; una restauración de un snapshot de RDS entre regiones puede tardar una hora).

La recuperación de la infraestructura se basa en plantillas de CloudFormation almacenadas en CodeCommit (u otro proveedor de Git) como la única fuente de verdad. Redesplegar un StackSet desde plantillas controladas por versiones reconstruye VPCs, IAM y stacks de aplicaciones en una región de recuperación en minutos. Mantener las plantillas solo en la consola, sin un repositorio, hace que el RTO sea impredecible porque no hay un artefacto reproducible.

Análisis de Errores Comunes

Tres conceptos erróneos producen respuestas incorrectas de forma consistente. Primero, tratar a Config como un control preventivo: evalúa después de que CloudTrail registra el cambio, por lo que las prohibiciones genuinas requieren SCP. Segundo, configurar la remediación sin un rol de IAM con el alcance adecuado: el documento de SSM existe y la regla de Config se activa, pero el runbook falla silenciosamente por errores de permisos. Tercero, ejecutar servicios para toda la organización desde la cuenta de administración en lugar de registrar un administrador delegado, lo que obliga a la habilitación manual por cuenta e impide que los agregadores de toda la organización funcionen correctamente.

Problema Práctico: Escenario de Caso de Uso

Escenario: Meridian Financial opera un entorno de AWS multicuenta con cuentas separadas de producción, desarrollo y seguridad bajo AWS Organizations. El equipo de seguridad debe demostrar el cumplimiento continuo con los controles internos y los reguladores mientras gestiona cientos de instancias EC2, buckets de S3 y funciones Lambda en varias regiones.

Desafío: Una auditoría reciente encontró instancias EC2 sin parches, buckets de S3 públicos y una aplicación inconsistente de las líneas base entre cuentas; la remediación es manual y lenta, y los controles preventivos no se aplican de manera uniforme.

Enfoque Recomendado:

Designar la cuenta de Seguridad como el administrador delegado de AWS Config y desplegar un AWS Config Aggregator mediante CloudFormation StackSets para recopilar datos de configuración y cumplimiento de todas las cuentas y regiones.
Desplegar Conformance Packs de AWS Config a nivel de organización desde la cuenta de seguridad (usando StackSets) para codificar los controles de línea base (acceso público de S3, cifrado, etiquetado) de modo que las mismas reglas se apliquen de manera consistente.
Asociar acciones de remediación automática de AWS Config a las reglas de alto riesgo que invocan documentos de AWS Systems Manager Automation (registrados como runbooks de remediación) para que las violaciones activen la remediación de SSM Automation o Run Command automáticamente.
Usar AWS Systems Manager Patch Manager con SSM Patch Baselines y State Manager para definir grupos de parches y automatizar la aplicación de parches del sistema operativo entre cuentas; enviar los resultados de cumplimiento de parches al Config Aggregator.
Publicar plantillas de CloudFormation aprobadas en AWS Service Catalog y usar CloudFormation StackSets para desplegar o actualizar stacks que cumplan con las normativas; aplicar barreras de protección preventivas con Service Control Policies de AWS Organizations para bloquear la creación de recursos no permitidos (por ejemplo, deshabilitar la creación de buckets de S3 públicos).
Configurar Amazon EventBridge (CloudWatch Events) y SNS para notificar al equipo de seguridad sobre incumplimientos y para desencadenar flujos de trabajo adicionales de SSM Automation para incidentes complejos.

Justificación: Centralizar la detección con Config Aggregator y los conformance packs, automatizar la remediación a través de SSM y aplicar barreras de protección preventivas mediante Service Catalog/StackSets y SCP proporciona controles consistentes y auditables, así como una remediación rápida, en línea con las mejores prácticas de AWS para seguridad, cumplimiento y mínimo privilegio.

← Seguridad de Borde y Aplicaciones · Todos los dominios · Vulnerabilidades →

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

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

Aprueba tu examen →

Explorar Amazon →