Certificación especializada en seguridad que valida la arquitectura de seguridad AWS, protección de datos y cumplimiento normativo.
Amazon GuardDuty, Amazon Detective, AWS Security Hub, Amazon EventBridge, Automatización de respuesta a incidentes, AWS Systems Manager Incident Manager
AWS CloudTrail, Amazon CloudWatch Logs, VPC Flow Logs, AWS Config, Análisis de logs con Amazon Athena, Amazon OpenSearch Service
Seguridad de Amazon VPC, AWS WAF, AWS Shield, AWS Network Firewall, AWS PrivateLink, Seguridad en el borde y CloudFront
Políticas IAM de AWS, AWS IAM Identity Center, Amazon Cognito, SCPs de AWS Organizations, Federación y SAML, Límites de permisos
AWS KMS, AWS CloudHSM, AWS Certificate Manager, Amazon Macie, Cifrado y políticas de buckets S3, AWS Secrets Manager
AWS Organizations, AWS Control Tower, AWS Audit Manager, AWS Trusted Advisor, Marcos de cumplimiento, AWS Artifact
Prueba preguntas tipo examen del conjunto de muestra gratuito. Cada respuesta incluye una explicación completa.
El equipo de seguridad de una empresa global de servicios financieros quiere configurar aplicaciones de múltiples cuentas de workload para acceder a un bucket S3 en una cuenta de datos central dentro de un entorno de AWS Organizations.
Los roles IAM en las cuentas de workload tienen permisos de acceso a S3, pero se producen errores de acceso durante los intentos de acceso reales. El equipo de seguridad quiere resolver este problema manteniendo el principio de menor privilegio y minimizando la sobrecarga operativa.
¿Qué se DEBE configurar adicionalmente para permitir correctamente el acceso S3 entre cuentas en esta situación?
Respuesta: A. Política de bucket S3, permitir Principal entre cuentas
Para el acceso S3 entre cuentas, AWS requiere Allow explícito tanto en la política IAM del lado del solicitante como en la política de bucket S3 del lado del recurso. Incluso si el rol IAM en la cuenta de workload tiene permisos S3, se producirá un error de acceso si la política de bucket S3 de la cuenta central no permite explícitamente al Principal de la cuenta de workload. Es obligatorio agregar el Principal entre cuentas (ARN del rol IAM de la cuenta de workload o ID de cuenta) a la política de bucket S3.
La política de bucket S3 es una política basada en recursos. Para que un Principal de otra cuenta acceda al bucket, debe haber Allow explícito en esa política de bucket. En un entorno de Organizations, puede especificar el ID de cuenta o ARN del rol IAM como Principal en políticas de bucket individuales para mantener el menor privilegio.
En el examen, los errores de S3 entre cuentas siempre son causados por una política de bucket faltante. Las ACL de S3 son un mecanismo heredado que dificulta la gestión del menor privilegio, las SCP son para restricciones no concesiones, y las políticas IAM por sí solas no pueden habilitar el acceso S3 entre cuentas.
El equipo de seguridad de una empresa energética global tiene un requisito de seguridad para bloquear inmediatamente a todos los desarrolladores de un grupo IAM de crear y modificar recursos de AWS fuera de una región específica. Sin embargo, el acceso a servicios clasificados globalmente, como IAM, CloudFront y Route 53, debe seguir estando permitido.
¿Qué configuración de política IAM MEJOR permite aplicar una restricción masiva a todo el grupo sin modificar las políticas de usuarios individuales, mientras maneja las excepciones de servicios globales?
Respuesta: B. Política de grupo IAM, Deny con aws:RequestedRegion, servicios globales excluidos con NotAction
Las dos condiciones clave en este escenario son: la restricción debe aplicarse a todo el grupo IAM a la vez, y los servicios globales (IAM, CloudFront, Route 53) deben estar exentos. Usar NotAction con la condición aws:RequestedRegion en una política de grupo IAM permite bloquear todas las solicitudes fuera de una región específica, excepto las acciones de servicios globales listadas. Este es el enfoque más directo para aplicar restricciones a nivel de grupo de inmediato sin tocar las políticas de usuarios individuales.
En una declaración Deny de una política de grupo IAM, NotAction excluye solo las acciones de servicios globales listadas, aplicando el Deny de condición de región a todas las demás acciones. La clave de condición aws:RequestedRegion filtra según la región de AWS a la que se dirige la solicitud, y dado que los servicios globales no tienen como objetivo una región específica, es necesaria la exclusión explícita mediante NotAction.
En el examen, es fácil confundir las SCP con las políticas de grupo IAM. Las SCP se aplican a nivel de jerarquía de AWS Organizations y no se pueden adjuntar directamente a grupos IAM, y los Permission Boundaries solo definen el alcance máximo permitido y no son adecuados para el bloqueo masivo de grupos.
El equipo de seguridad de una empresa global de software necesita permitir que el equipo de desarrollo cree directamente roles y usuarios IAM para pipelines CI/CD, mientras controla centralmente que los principales IAM creados por el equipo de desarrollo no puedan exceder el alcance máximo de permisos definido por el equipo de seguridad. El objetivo es prevenir la escalada de privilegios donde el equipo de desarrollo podría crear roles con permisos casi administrativos y asignarlos a pipelines, manteniendo la autonomía del equipo de desarrollo.
¿Qué enfoque de control de acceso MEJOR permite al equipo de seguridad gestionar centralmente los límites máximos de permisos mientras permite al equipo de desarrollo crear principales IAM?
Respuesta: B. IAM permissions boundary, otorgar condición para creación de roles por el equipo de desarrollo
El equipo de seguridad de una empresa de software necesita controlar centralmente el límite máximo de permisos mientras garantiza la autonomía del equipo de desarrollo en la creación de recursos IAM. El IAM permissions boundary define el límite máximo de permisos que puede tener un principal IAM, por lo que incluso si el equipo de desarrollo crea un rol con permisos poderosos, los permisos que excedan el boundary no se aplicarán realmente. Al hacer que el equipo de seguridad gestione centralmente la política de boundary y requiriendo que el equipo de desarrollo adjunte este boundary al crear roles, se puede prevenir la escalada de privilegios manteniendo la autonomía del equipo.
El IAM permissions boundary se aplica junto con las políticas basadas en identidad, y solo la intersección de ambas políticas se convierte en los permisos efectivos. Esto significa que incluso si el equipo de desarrollo adjunta políticas de nivel AdministratorAccess a un rol, los permisos no incluidos en el boundary se bloquean automáticamente. A diferencia de los SCPs, la característica clave es que se aplica a nivel de principal IAM individual en lugar de a toda la cuenta.
En los exámenes, los SCPs y el permissions boundary son fáciles de confundir. Los SCPs se aplican a nivel de AWS Organizations a cuentas enteras, mientras que el permissions boundary se aplica a principales IAM individuales. Cuando el escenario implica limitar el alcance de creación de IAM para un equipo de desarrollo específico, elija permissions boundary; cuando se restrinja el uso de servicios en toda una cuenta organizacional, elija SCP.
El equipo de seguridad de una empresa de consultoría global debe restringir el acceso para que los usuarios IAM de socios externos solo puedan cargar objetos a buckets S3 designados durante un período de contrato específico. El acceso debe bloquearse automáticamente cuando termine el período de contrato, y quieren implementar esto sin que los equipos de operaciones modifiquen políticas manualmente.
¿Cuál es el enfoque MÁS apropiado para permitir S3 PutObject solo durante un período específico usando condiciones de tiempo en políticas basadas en identidad IAM?
Respuesta: C. Política IAM, Allow de condición aws:CurrentTime
La condición más crítica en este escenario es el bloqueo automático de acceso usando condiciones de tiempo en políticas basadas en identidad IAM. Agregar condiciones aws:CurrentTime (DateGreaterThan/DateLessThan) a una política Allow de IAM permite S3 PutObject solo durante el período especificado, y después de que termina el período, la condición no se cumple, resultando en Deny implícito. Este enfoque es la manera más concisa de implementar bloqueo automático sin trabajo operacional separado.
La condición aws:CurrentTime es una clave de contexto de condición global de IAM que compara fechas y horas en formato ISO 8601. Especificar el tiempo de inicio con DateGreaterThan y el tiempo de finalización con DateLessThan permite que solo pasen las solicitudes dentro de esa ventana. Cuando esta condición se aplica a una instrucción Allow, la política no se aplica cuando la condición no se cumple, denegando acceso a menos que haya otro Allow.
En exámenes, cuando aparezca control de acceso automático basado en tiempo, elija aws:CurrentTime condición Allow. Aplicar condiciones a instrucciones Deny invierte la lógica y complica la gestión, y la expiración de sesión STS es adecuada para sesiones cortas (hasta 12 horas), lo que la hace inadecuada para control de contratos a largo plazo.
El equipo de desarrollo de una empresa global de medios experimenta un problema donde las cargas de archivos pequeños a un bucket S3 cifrado con SSE-KMS tienen éxito, pero las cargas de archivos grandes fallan con errores de permisos. El rol de ejecución de la función Lambda tiene el permiso kms:GenerateDataKey otorgado.
¿Cuál es la causa de este error y qué permiso KMS adicional se requiere durante el proceso de carga multiparte para archivos grandes?
Respuesta: A. Permiso kms:Decrypt faltante
La diferencia entre cargas de archivos pequeños y grandes en la carga multiparte radica en los requisitos de permisos de KMS. Las cargas PUT únicas de archivos pequeños pueden cifrar usando solo kms:GenerateDataKey para crear una clave de datos, pero durante la fase CompleteMultipartUpload de cargas multiparte, S3 requiere el permiso kms:Decrypt para descifrar las claves de datos cifradas de cada parte. Dado que el rol de ejecución de Lambda carece de kms:Decrypt, las cargas de archivos grandes fallan.
La carga multiparte SSE-KMS consta de tres fases. Primero, CreateMultipartUpload genera la clave de datos, luego cada parte se envía a través de UploadPart y finalmente CompleteMultipartUpload combina todas las partes en un solo objeto. En esta última fase, S3 debe descifrar la información de clave de cifrado de cada parte para regenerar la DEK (Data Encryption Key) para el objeto final, lo que requiere kms:Decrypt.
En el examen, cuando aparezcan errores de permisos SSE-KMS, distinga entre PUT único vs. carga multiparte. Para cargas únicas, kms:GenerateDataKey es suficiente; para multiparte, se requieren tanto kms:GenerateDataKey como kms:Decrypt.
El examen AWS Certified Security - Specialty (SCS-C03) consta de 65 preguntas y tiene un límite de 170 minutos.
La puntuación de aprobación del examen SCS-C03 es de 750 sobre 1000.
El conjunto de muestra de SCS-C03 (20 preguntas con explicaciones completas) es gratuito. El banco completo de más de 340 preguntas está disponible con una suscripción a CloudMasterIT.
La certificación SCS-C03 es válida durante 3 años después de aprobar. Después se requiere recertificación.