Amazon SCS-C02: Cifrado, KMS y Secretos — 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.

Tipos de claves, políticas y control de acceso de AWS KMS

AWS KMS admite tres categorías generales de claves, y elegir la correcta determina quién controla el material de la clave, dónde reside y cómo se puede rotar. Las claves propiedad de AWS son invisibles para ti, no cuestan nada y son utilizadas por servicios como S3 cuando habilitas SSE-S3. Las claves administradas por AWS (con alias aws/<service>) permiten que un servicio cifre en tu nombre, pero no puedes modificar su política de clave, por lo que no son adecuadas para el acceso entre cuentas o una gobernanza detallada. Las claves administradas por el cliente (CMK) son el caballo de batalla: tú controlas la política de clave, la rotación (anual automática o bajo demanda), los grants, los alias y el período de eliminación.

Dos variantes especializadas son importantes. El material de clave importado se utiliza cuando los requisitos regulatorios o de BYOK (Bring Your Own Key) te obligan a generar material de clave fuera de AWS e importarlo a una clave de KMS. El material importado es la única forma de configurar una expiración explícita del material de clave; las CMK generadas por AWS nunca expiran. No puedes habilitar la rotación anual automática de AWS en claves importadas; debes volver a importar el material tú mismo. Las claves multirregión comparten el mismo ID de clave y material entre regiones a través de claves de réplica, por lo que un texto cifrado producido en us-east-1 puede ser descifrado en us-west-1 sin necesidad de volver a cifrar. Cada réplica tiene su propia política de clave y alias independientes, pero el material criptográfico está sincronizado.

El control que más se malinterpreta es la política de claves de KMS. A diferencia de la mayoría de los recursos de AWS donde las políticas de IAM por sí solas otorgan acceso, las claves de KMS utilizan su política de clave como la autorización raíz. Una política de IAM que otorga kms:Decrypt sobre una clave es inerte a menos que la política de clave también delegue el acceso a IAM (a través de un Principal de la raíz de la cuenta más una declaración apropiada, o nombrando al principal directamente). Es por esto que un ingeniero con AdministratorAccess aún puede recibir un AccessDenied al llamar a Decrypt en una CMK cuya política no confía en la cuenta. La declaración de delegación canónica se ve así:

{
  "Sid": "EnableIAMPermissions",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
  "Action": "kms:*",
  "Resource": "*"
}

Los grants y las condiciones ViaService añaden restricciones en capas; por ejemplo, forzando que una clave se use solo a través de S3 en una región específica con kms:ViaService: s3.us-east-1.amazonaws.com.

Cifrado del lado del servidor y del lado del cliente

Para S3, las dos opciones comunes del lado del servidor difieren principalmente en el control y la auditabilidad:

• SSE-S3 (AES-256): S3 gestiona las claves por completo; no hay una política de clave visible para el cliente, no hay eventos de descifrado por clave en CloudTrail y no hay gobernanza entre cuentas. Es adecuado para un cifrado en reposo básico, pero insuficiente cuando el cumplimiento normativo requiere probar quién descifró los datos.
• SSE-KMS: Utiliza una CMK que tú controlas; cada llamada de descifrado se registra en logs, la política de clave impone el acceso y puedes restringir por contexto de cifrado. Cuesta más por solicitud y consume cuotas de TPS de KMS, por lo que las claves de bucket (BucketKeyEnabled: true) deben habilitarse para reducir drásticamente las llamadas a KMS.

El cifrado del lado del cliente utilizando el AWS Encryption SDK es apropiado cuando los datos deben cifrarse antes de que salgan de la aplicación, o cuando el servicio de almacenamiento nunca debe ver el texto plano. Las cargas de trabajo de alto rendimiento deben envolver el SDK con el gestor de materiales criptográficos en caché (CachingCryptoMaterialsManager), que reutiliza las claves de datos en muchos mensajes dentro de límites configurables de bytes, mensajes y TTL. Sin el almacenamiento en caché, cada llamada a encrypt desencadena una solicitud GenerateDataKey, saturando rápidamente las cuotas de solicitud de KMS e inflando los costos.

from aws_encryption_sdk import CachingCryptoMaterialsManager, LocalCryptoMaterialsCache
cache = LocalCryptoMaterialsCache(capacity=100)
ccmm = CachingCryptoMaterialsManager(
    master_key_provider=mkp, cache=cache,
    max_age=600.0, max_messages_encrypted=10000)

Secrets Manager y Parameter Store

Secrets Manager almacena credenciales cifradas con una CMK de KMS y admite la rotación automática a través de una función Lambda; AWS proporciona plantillas para RDS, Redshift y DocumentDB, y las Lambdas personalizadas se encargan de cualquier otra cosa. La rotación ejecuta una máquina de estados de cuatro pasos (createSecret, setSecret, testSecret, finishSecret) que prepara las nuevas credenciales bajo la etiqueta AWSPENDING antes de promoverlas a AWSCURRENT. Las aplicaciones deben capturar los fallos de autenticación, refrescar el secreto y reintentar; este patrón elimina el tiempo de inactividad porque la credencial anterior permanece válida brevemente a través de AWSPREVIOUS.

Cuando la Lambda de rotación se ejecuta dentro de una VPC (típico para alcanzar una instancia de RDS privada), necesita acceso de red de salida al punto de enlace (endpoint) del servicio Secrets Manager. En una VPC privada sin NAT, debes desplegar un punto de enlace de VPC de tipo interfaz (com.amazonaws.<region>.secretsmanager) y permitir que el grupo de seguridad de la Lambda alcance el punto de enlace en el puerto 443. Olvidar esto es un fallo clásico: la rotación parece configurada pero cada invocación expira por tiempo de espera (timeout).

Para la resiliencia entre regiones, utiliza una clave KMS multirregión y la función de secretos de réplica de Secrets Manager. El secreto primario en us-east-1 se cifra con la CMK primaria; la réplica en us-west-1 descifra utilizando la CMK de réplica. Los alias como alias/prod-db pueden apuntar a un nuevo ID de clave bajo demanda para una rotación rápida de claves sin cambiar el código de la aplicación.

El tipo SecureString de Parameter Store es una alternativa ligera cuando no necesitas rotación. Ambos servicios exponen referencias dinámicas en CloudFormation ({{resolve:secretsmanager:MySecret:SecretString:password}}) para que las plantillas de stack nunca incrusten texto plano.

Cifrado de EBS, RDS, Aurora y snapshots

El cifrado en reposo se habilita por volumen o por instancia en el momento de la creación y no se puede activar/desactivar sobre el recurso existente. El patrón de remediación para un recurso no cifrado que no cumple con las normativas es una copia de snapshot con cifrado:

aws ec2 copy-snapshot --source-snapshot-id snap-abc \
  --source-region us-east-1 --encrypted \
  --kms-key-id alias/prod-ebs
aws ec2 create-volume --snapshot-id snap-newEncrypted ...

Para RDS y Aurora, restaura el snapshot cifrado en una nueva instancia y realiza el cambio. La recuperación entre cuentas requiere compartir el snapshot y otorgar a la cuenta de destino los permisos kms:CreateGrant y kms:Decrypt sobre la CMK a través de la política de clave; compartir solo el snapshot fallará porque el destino no puede descifrar la clave de datos. El cifrado por defecto de EBS a nivel de cuenta debe habilitarse para que los volúmenes recién creados siempre estén cifrados, independientemente del comportamiento de quien realiza la llamada.

TLS: Políticas de ACM y ALB

ACM emite y renueva automáticamente certificados públicos sin costo cuando se vinculan a servicios integrados (ALB, CloudFront, API Gateway). Los certificados no se pueden exportar, por lo que el TLS terminado en EC2 requiere ya sea ACM Private CA (para certificados privados que sí se pueden exportar) o un certificado importado. Un patrón pragmático: terminar el TLS público en el ALB con un certificado de ACM, y usar un certificado autofirmado o de una CA privada para el salto del ALB a EC2 si se requiere cifrado de extremo a extremo. Force a los clientes a usar cifrados modernos con una política de seguridad como ELBSecurityPolicy-TLS13-1-2-2021-06, que deshabilita TLS 1.0/1.1 y las suites débiles.

Errores Comunes

IAM sin política de clave. Otorgar kms:Decrypt en una política de IAM mientras que la política de clave de la CMK omite el principal de la cuenta produce un AccessDenied. KMS trata la política de clave como la fuente autoritativa; los permisos de IAM solo pueden restringir aún más lo que la política de clave permite.

Lambda de rotación sin un VPC endpoint. Si la Lambda se ejecuta en subredes privadas y el VPC no tiene NAT ni un endpoint de interfaz para secretsmanager, la llamada de rotación a secretsmanager.<region>.amazonaws.com no puede resolverse o conectarse. El grupo de seguridad del endpoint también debe permitir el puerto 443 desde el SG de la Lambda.

Equiparar SSE-S3 con SSE-KMS. SSE-S3 utiliza una clave propiedad de AWS sin una política editable por el cliente, sin registro de descifrado por objeto en CloudTrail y sin posibilidad de compartir la clave entre cuentas. Cumple con los requisitos de “cifrado en reposo”, pero no puede forzar qué principales descifran objetos específicos; solo SSE-KMS con una CMK proporciona esa gobernanza.

Problema Práctico: Escenario de Caso de Uso

Escenario: Meridian Financial opera una AWS Organization multicuenta con una cuenta de Seguridad, cuentas separadas de Prod/NonProd, microservicios detrás de un ALB en ECS/EKS, clústeres de RDS/Aurora, instancias EC2 con respaldo en EBS y data lakes en S3. Los desarrolladores y la automatización utilizan actualmente una mezcla de claves administradas por AWS, parámetros de SSM en texto plano y compartición manual ocasional de snapshots entre cuentas.

Desafío: Un ingeniero compartió accidentalmente un snapshot de RDS sin cifrar con una cuenta de terceros y se descubrieron varias credenciales de API almacenadas como parámetros SecureString en texto plano, creando un riesgo de exfiltración de datos y acceso no autorizado a la restauración.

Enfoque Recomendado:

1. Crear una CMK simétrica de AWS KMS administrada por el cliente y con alcance de organización en la cuenta de Seguridad, con una política de clave que otorgue su uso a través de aws:PrincipalOrgID a las cuentas miembro y habilitar la rotación automática; usar grants para operaciones entre cuentas de corta duración.
2. Remediar los artefactos existentes copiando el snapshot de RDS sin cifrar y cualquier snapshot de EBS mientras se selecciona la nueva CMK para producir copias cifradas, y luego eliminar los snapshots originales sin cifrar; establecer los valores predeterminados de la cuenta para que los nuevos RDS y EBS creen recursos cifrados por defecto.
3. Migrar los secretos a AWS Secrets Manager (o SSM Parameter Store SecureString) cifrados con la CMK, habilitar la rotación automática de Secrets Manager para las credenciales de la base de datos a través de Lambda, y restringir el acceso usando políticas basadas en recursos y roles de IAM con privilegios mínimos.
4. Forzar el cifrado en tránsito aprovisionando certificados TLS administrados por ACM y adjuntándolos a los ALBs con una política de TLS moderna (TLS 1.2/1.3), y configurar las bases de datos y los clientes para que requieran conexiones TLS.
5. Prevenir la recurrencia con barreras de protección (guardrails): aplicar Service Control Policies para denegar la creación/compartición de snapshots sin cifrar y las operaciones “put” en S3 sin cifrado, habilitar reglas de AWS Config para recursos cifrados, y monitorear el uso de KMS y Secrets Manager a través de CloudTrail y CloudWatch Alarms.

Justificación: El uso de CMKs centralizadas con políticas a nivel de organización, el recifrado automatizado, Secrets Manager para el ciclo de vida de los secretos, la aplicación de TLS y las barreras de protección preventivas siguen las mejores prácticas de AWS de privilegios mínimos y defensa en profundidad para eliminar los secretos en texto plano y el acceso no autorizado a los snapshots.

CMK administradas por el cliente: multirregión, material importado y políticas de clave

Una CMK administrada por el cliente es el plano de control para cada operación criptográfica sobre los datos que posees en AWS. Las tres propiedades que con mayor frecuencia determinan si un diseño tiene éxito o produce una interrupción son la topología de región de la clave, el origen de su material de clave y la política adjunta a ella.

Claves multirregión son un conjunto de claves de KMS en diferentes regiones que comparten el mismo ID de clave y, fundamentalmente, el mismo material de clave subyacente. No se replican automáticamente de la misma manera que las tablas globales de DynamoDB; tú creas explícitamente réplicas a partir de una clave principal usando ReplicateKey. Debido a que el material de clave es idéntico en todas las réplicas, el texto cifrado producido en us-east-1 puede ser descifrado en us-west-1 sin necesidad de llamadas de KMS entre regiones. Esta es exactamente la propiedad requerida al replicar un secreto de Secrets Manager entre regiones: el secreto de réplica en la región de conmutación por error (failover) debe poder descifrarse localmente, tanto para eliminar la latencia entre regiones en cada GetSecretValue como para sobrevivir a una interrupción regional de la principal. Una CMK de una sola región no puede respaldar una réplica de Secrets Manager en otra región, por lo que el patrón correcto es cifrar el secreto principal con una CMK multirregión, replicar la clave en la región de destino y luego replicar el secreto apuntando a la CMK de réplica.

aws kms create-key --multi-region --region us-east-1
aws kms replicate-key --key-id mrk-abc123 \
  --replica-region us-west-1
aws secretsmanager replicate-secret-to-regions \
  --secret-id prod/db \
  --add-replica-regions Region=us-west-1,KmsKeyId=mrk-abc123

Material de clave importado (origen externo, Origin=EXTERNAL) existe cuando generas el material AES-256 en bruto fuera de AWS y lo importas a una estructura de clave de KMS (key shell). AWS nunca tiene una copia de ese material fuera de la memoria protegida del HSM, y no hay copia de seguridad. Si eliminas el material importado, ya sea a través de DeleteImportedKeyMaterial o porque su fecha de vencimiento ha pasado, la clave pasa al estado PendingImport y todo el texto cifrado producido con esa clave es irrecuperable a menos que reimportes exactamente los mismos bytes. Esta es la ruta de recuperación cuando, por ejemplo, un volumen de EBS no se puede adjuntar porque su clave de datos cifrada no se puede descifrar: reimporta el material de clave idéntico desde tu depósito de seguridad offline (escrow), y el volumen vuelve a ser utilizable. No hay restauración por parte de AWS, ningún truco de rotación y ningún ticket de soporte que pueda recuperar el material importado eliminado. Trata la copia offline como infraestructura de nivel cero (tier-zero).

Las políticas de clave son la raíz de confianza para cada clave de KMS. A diferencia de IAM por sí solo, KMS requiere un allow explícito en la propia política de clave; una política de IAM que concede kms:Decrypt es ineficaz a menos que la política de clave delegue en IAM ("Principal": {"AWS": "arn:aws:iam::111122223333:root"} combinado con una declaración condicional). Para el uso entre cuentas, la política de la clave debe nombrar explícitamente la cuenta o el principal externo, y la cuenta externa debe luego conceder permiso a sus propios usuarios a través de IAM. Olvidar el lado de la política de clave es la causa más común de fallos de Secrets Manager entre cuentas: la política de recursos de Secrets Manager permite al principal externo llamar a GetSecretValue, pero el Decrypt subyacente falla porque la CMK sigue rechazando a quien realiza la llamada.

Patrones de Secrets Manager y Parameter Store SecureString

Tanto Secrets Manager como los SecureStrings de SSM Parameter Store delegan el cifrado a KMS, pero difieren en costo, semántica de rotación y comportamiento entre regiones. Secrets Manager admite replicación multirregión nativa, versionado con etiquetas de etapa (AWSCURRENT, AWSPENDING) y rotación respaldada por Lambda. Parameter Store SecureString es más económico, se integra con rutas jerárquicas y funciona bien para secretos de tipo configuración que rotan con poca frecuencia.

Para el acceso entre cuentas, debes actualizar tanto la política de recursos en el secreto (o la política de IAM en la cuenta consumidora de Parameter Store) como la política de clave de KMS en la CMK que cifra. Asumir que los permisos de Secrets Manager por sí solos son suficientes es incorrecto, porque el flujo de trabajo de recuperación siempre realiza un kms:Decrypt implícito contra la CMK; sin un allow en la política de clave para la cuenta externa, quien realiza la llamada recibe AccessDeniedException en el paso de Decrypt aunque la propia política del secreto se cumpla.

• Secrets Manager: rotación administrada, estructura JSON, ~$0.40/secreto/mes, replicación multirregión incorporada
• Parameter Store SecureString (Advanced): más económico para muchos valores, 8 KB por parámetro, sin replicación entre regiones incorporada
• Parameter Store SecureString (Standard): nivel gratuito para parámetros cifrados con KMS de hasta 4 KB, sin marco de rotación

Cifrado de sobre, claves de bucket y tokens de concesión

El cifrado de sobre significa que KMS nunca toca sus datos masivos. Usted llama a GenerateDataKey, que devuelve tanto una clave de datos en texto plano (usada localmente para cifrar su carga útil con AES-GCM) como una copia cifrada de esa clave de datos (almacenada junto al texto cifrado). Para descifrar, llama a Decrypt sobre la clave de datos encapsulada y vuelve a derivar la clave en texto plano localmente. Este patrón es esencial porque KMS tiene cuotas de solicitud (por región, por clave) y precios por llamada a la API. Si cifra cada registro de 4 KB con una llamada directa a Encrypt, alcanzará las limitaciones (throttling) y picos de costos; si genera una clave de datos por lote o por archivo, el rendimiento escala linealmente con su biblioteca de criptografía local.

Las claves de bucket de S3 (S3 Bucket Keys) aplican el mismo principio dentro de S3 para SSE-KMS. Sin una clave de bucket, cada PUT y GET de un objeto SSE-KMS genera una llamada a GenerateDataKey o Decrypt. En un bucket que recibe miles de objetos por segundo, esto produce tanto throttling de KMS como una factura de KMS sorprendente. Habilitar una clave de bucket hace que S3 genere una clave de corta duración a nivel de bucket y la reutilice para muchos objetos, reduciendo el volumen de solicitudes a KMS en órdenes de magnitud:

aws s3api put-bucket-encryption --bucket app-data \
  --server-side-encryption-configuration '{
    "Rules":[{
      "ApplyServerSideEncryptionByDefault":{
        "SSEAlgorithm":"aws:kms","KMSMasterKeyID":"alias/app"},
      "BucketKeyEnabled":true}]}'

Las concesiones (Grants) son una alternativa a las políticas de clave para una delegación temporal y detallada. Son importantes operacionalmente debido a la consistencia eventual: después de que CreateGrant retorna, la concesión no es visible inmediatamente para todos los endpoints de KMS en la región. Si un cliente intenta un Encrypt unos milisegundos después, puede recibir una AccessDeniedException. El cuerpo de la respuesta de CreateGrant incluye una cadena GrantToken que, cuando se pasa en llamadas posteriores a KMS a través del parámetro --grant-tokens, obliga a KMS a respetar la concesión inmediatamente, sin importar el estado de propagación.

TOKEN=$(aws kms create-grant --key-id $KEY \
  --grantee-principal arn:aws:iam::111122223333:role/worker \
  --operations Encrypt Decrypt --query GrantToken --output text)
aws kms encrypt --key-id $KEY --plaintext fileb://payload \
  --grant-tokens "$TOKEN"

Confiar en reintentos con retroceso exponencial (retry-with-backoff) en lugar del token de concesión es una mitigación válida pero inferior: desperdicia latencia y aun así falla bajo carga. La respuesta canónica es siempre: devolver el token de concesión desde el servicio que crea la concesión y exigir a quienes lo llaman que lo presenten en su primera operación.

Problema práctico: Escenario de caso de uso

Escenario: Meridian Financial opera un entorno de AWS con múltiples cuentas que aloja PII (información de identificación personal) de clientes en S3, bases de datos transaccionales en RDS y procesamiento sin servidor a través de Lambda. Utilizan CMK administradas por el cliente con material de clave importado para cumplir con las reglas regionales de custodia de claves y replican las claves a una segunda región para la recuperación ante desastres.

Desafío: Una auditoría reciente encontró una política de clave de KMS mal configurada que permitía descifrados entre cuentas, y un auditor externo necesita acceso temporal para descifrar un subconjunto de objetos de S3; Meridian también necesita una rotación segura de secretos y un cifrado eficiente para objetos grandes para controlar los costos de solicitud de KMS.

Enfoque recomendado:

1. Rotar la política de la CMK mal configurada en AWS KMS a una política de privilegios mínimos que otorgue explícitamente solo a las entidades principales y roles de IAM requeridos, y crear una CMK de réplica multirregional para DR utilizando claves multirregionales de KMS.
2. Reimportar o programar la gestión del ciclo de vida para el material de clave importado según las ventanas de cumplimiento y habilitar notificaciones automáticas de vencimiento/rotación del material de clave utilizando AWS Config y EventBridge.
3. Para el auditor, crear una concesión de KMS con un TTL corto y usar el token de concesión inmediatamente en la sesión de asunción de rol del auditor para permitir operaciones de descifrado temporales sin cambiar la política de la clave.
4. Mover las credenciales de larga duración a AWS Secrets Manager con rotación basada en Lambda vinculada al servicio subyacente (RDS o claves de API) y almacenar los parámetros de infraestructura como SecureString de Systems Manager Parameter Store para elementos que no rotan, aplicando el cifrado con la CMK y políticas estrictas basadas en recursos.
5. Implementar el cifrado de sobre para objetos grandes de S3 llamando a GenerateDataKey (Encrypt/Decrypt) de KMS en el código de la aplicación o a través del SDK de AWS, y habilitar las claves de bucket de S3 (S3 Bucket Keys) para reducir las solicitudes a KMS y el costo del cifrado del lado del servidor para objetos grandes.
6. Habilitar el registro de CloudTrail y el registro de uso de claves de KMS, y crear alarmas de CloudWatch/reglas de GuardDuty para alertar sobre descifrados inesperados o creaciones de concesiones.

Justificación: Este enfoque impone el acceso a claves con privilegios mínimos, preserva el cumplimiento para el material importado y la continuidad multirregional, utiliza concesiones temporales para un acceso seguro a terceros, centraliza los secretos con rotación y optimiza el uso y el costo de KMS según las mejores prácticas de AWS.

← Registros · Todos los dominios · Protección de Datos y S3 →

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

Explorar Amazon →