Semana 7 · Módulo 7 de 11

Seguridad de datos: cifrado, secretos, identidad de aplicaciones y detección

Cómo protege AWS los datos en reposo y en tránsito (KMS, CloudHSM, ACM), cómo guardar credenciales de aplicación (Secrets Manager, Parameter Store), cómo autenticar usuarios finales (Cognito) y cómo detectar, auditar y demostrar cumplimiento (GuardDuty, Inspector, Macie, Detective, Security Hub, CloudTrail, Config, Artifact). Es el núcleo de las tareas 1.2 y 1.3 del dominio con más peso del examen.

Reparto de la semana

Por qué importa

El dominio 1 (Design Secure Architectures) vale el 30 % del examen, más que ningún otro. Dentro de él, la tarea 1.3 (Determine appropriate data security controls) es casi entera de este módulo, y la 1.2 (Design secure workloads and applications) pregunta por los servicios de seguridad «con casos de uso adecuados»: Cognito, GuardDuty, Macie, Secrets Manager…

Las preguntas de este bloque suelen tener esta forma:

• «Una empresa debe cifrar datos en reposo y controlar quién puede usar la clave / rotarla cada año / auditar cada uso» → AWS KMS con una customer managed key.
• «…con un HSM de un solo inquilino (single-tenant) bajo control exclusivo del cliente» → AWS CloudHSM.
• «Credenciales de base de datos con rotación automática» → AWS Secrets Manager.
• «Detectar datos personales (PII) en buckets S3» → Amazon Macie.
• «¿Quién borró este recurso?» → AWS CloudTrail. «¿Cómo estaba configurado el recurso el martes y cumple la norma?» → AWS Config.

Aprenderás aquí vocabulario que se repite en muchas preguntas: encryption at rest, encryption in transit, key policy, least privilege, audit trail, compliance, data residency.

Conceptos base del cifrado

Antes de los servicios, tres ideas que el examen da por sabidas:

• Cifrado en reposo (encryption at rest): los datos almacenados (disco EBS, objeto S3, instantánea RDS, mensaje en una cola) están cifrados. Quien robe el soporte físico no puede leerlos.
• Cifrado en tránsito (encryption in transit): los datos que viajan por la red van dentro de un canal cifrado, casi siempre TLS (el sucesor de SSL) o IPsec en las VPN.
• ¿Quién gestiona la clave? Es la pregunta que decide el servicio:

Simétrico frente a asimétrico. Una clave simétrica cifra y descifra (AES-256): es lo normal para datos. Un par asimétrico (RSA, curva elíptica) separa clave pública y privada: sirve para firmas digitales o para que terceros cifren algo que solo tú descifrarás.

AWS KMS a fondo

AWS Key Management Service (AWS KMS) es el servicio gestionado para crear y controlar claves criptográficas. Las claves viven en módulos de seguridad hardware (hardware security modules, HSM) validados FIPS 140 que gestiona AWS, y el material de la clave no sale nunca de KMS sin cifrar. Tú no ves la clave: pides a KMS que cifre, descifre o genere claves de datos, y KMS decide si tienes permiso.

KMS se integra con casi todos los servicios que almacenan datos (S3, EBS, RDS, DynamoDB, EFS, SQS, SNS, Secrets Manager, CloudTrail…) y registra cada uso de una clave en CloudTrail. Esa auditoría es uno de sus grandes argumentos en el examen.

Tipos de KMS key según quién la gestiona

Una KMS key (antes llamada customer master key, CMK; verás ese nombre en material antiguo) es un recurso regional con ID, ARN, política y material criptográfico.

Cuándo elegir cada una:

• AWS owned key: cifrado por defecto sin esfuerzo ni coste. No hay auditoría ni control. Es lo que usa, por ejemplo, DynamoDB por defecto.
• AWS managed key: cifrado con KMS sin gestionar nada, con auditoría. AWS la documenta como tipo heredado (legacy): desde 2021 los servicios nuevos usan claves AWS owned. Limitación clave para el examen: no puedes compartir recursos cifrados con ella con otra cuenta (por ejemplo, una instantánea de EBS cifrada con aws/ebs no se puede compartir).
• Customer managed key: cuando el enunciado pide controlar la política de la clave, compartir entre cuentas, desactivar o borrar la clave, elegir el periodo de rotación o separar funciones entre administradores y usuarios de la clave.

Tipos de clave según su uso

• Simétrica de cifrado (SYMMETRIC_DEFAULT, AES-256-GCM): la de siempre; es la que usan los servicios integrados.
• Asimétrica (RSA o ECC): cifrar/descifrar o firmar/verificar. La clave pública se puede descargar y usar fuera de AWS.
• HMAC: generar y verificar códigos de autenticación de mensajes.

Las claves se identifican por key ID, key ARN, alias (alias/mi-app) o alias ARN. Un alias es un puntero cambiable: si la aplicación usa el alias, puedes apuntarlo a otra clave sin tocar el código (así se hace la rotación manual).

Envelope encryption (cifrado de sobre)

La operación Encrypt de KMS solo acepta hasta 4.096 bytes de texto en claro con una clave simétrica. KMS no está pensado para cifrar ficheros grandes, sino para proteger claves de datos. El patrón se llama envelope encryption:

1. La aplicación (o el servicio, p. ej. S3) llama a GenerateDataKey. KMS devuelve una clave de datos en dos formatos: en claro y cifrada con tu KMS key.
2. La aplicación cifra los datos localmente con la clave en claro (AES) y borra la clave en claro de memoria.
3. Guarda juntos los datos cifrados y la clave de datos cifrada (el «sobre»).
4. Para descifrar, envía la clave de datos cifrada a KMS (Decrypt), recibe la clave en claro y descifra localmente.

sequenceDiagram
    participant App as Aplicación
    participant KMS as AWS KMS
    participant S3 as Almacenamiento
    App->>KMS: GenerateDataKey (KMS key)
    KMS-->>App: clave de datos en claro + clave de datos cifrada
    App->>App: cifra el fichero con la clave en claro y la borra de memoria
    App->>S3: guarda fichero cifrado + clave de datos cifrada
    Note over App,S3: Para leer
    App->>S3: lee fichero cifrado + clave cifrada
    App->>KMS: Decrypt (clave de datos cifrada)
    KMS-->>App: clave de datos en claro
    App->>App: descifra el fichero localmente

Ventajas: los datos grandes nunca viajan a KMS, el cifrado es rápido y local, y basta proteger una KMS key para proteger millones de claves de datos. Así funcionan por dentro SSE-KMS en S3, EBS, RDS y el AWS Encryption SDK (cifrado en el cliente).

Encryption context: pares clave-valor no secretos que acompañan a una operación con clave simétrica. Para descifrar hay que presentar exactamente el mismo contexto. Añade integridad, aparece en CloudTrail (no pongas secretos en él) y se puede usar en condiciones de la key policy.

Control de acceso: key policies, políticas IAM y grants

Aquí está la diferencia más importante entre KMS y casi cualquier otro servicio:

• Toda KMS key tiene exactamente una key policy (política de recurso). Es el control principal. Si la key policy no lo permite, nadie usa la clave, ni siquiera el root de la cuenta.
• Las políticas IAM solo funcionan con una clave si la key policy lo habilita. La key policy por defecto incluye una declaración que da permisos a la cuenta (arn:aws:iam::111122223333:root), lo que delega en IAM: a partir de ahí, las políticas IAM de usuarios y roles de esa cuenta pueden conceder uso de la clave.
• Los grants (concesiones) dan permisos temporales y acotados sobre una clave a un principal, sin editar la key policy. Los usan sobre todo los servicios de AWS: cuando adjuntas un volumen EBS cifrado a una instancia, EBS crea un grant para que la instancia pueda descifrar la clave de datos del volumen. Se crean con CreateGrant y se retiran o revocan cuando ya no hacen falta.

Ejemplo de key policy con separación de funciones: un rol administra la clave (pero no puede usarla para cifrar) y otro rol la usa (pero no puede administrarla):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "HabilitarPermisosIAMDeLaCuenta",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "AdministradoresDeLaClave",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/AdminClaves" },
      "Action": [
        "kms:Create*", "kms:Describe*", "kms:Enable*", "kms:List*",
        "kms:Put*", "kms:Update*", "kms:Revoke*", "kms:Disable*",
        "kms:Get*", "kms:Delete*", "kms:ScheduleKeyDeletion", "kms:CancelKeyDeletion",
        "kms:TagResource", "kms:UntagResource", "kms:RotateKeyOnDemand"
      ],
      "Resource": "*"
    },
    {
      "Sid": "UsuariosDeLaClaveSoloDesdeS3",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/AppPedidos" },
      "Action": ["kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey"],
      "Resource": "*",
      "Condition": {
        "StringEquals": { "kms:ViaService": "s3.eu-south-2.amazonaws.com" }
      }
    }
  ]
}

En una key policy, "Resource": "*" significa «esta clave». La condición kms:ViaService limita el uso a peticiones que llegan a través de un servicio concreto (aquí, S3 en eu-south-2): la aplicación puede leer objetos cifrados de S3, pero no llamar a Decrypt directamente.

Acceso entre cuentas (cross-account): hacen falta dos permisos. La key policy de la cuenta propietaria debe permitir a la otra cuenta (o a un rol concreto) usar la clave, y en la otra cuenta una política IAM debe conceder esas acciones sobre el ARN de la clave. Para usar una clave de otra cuenta hay que referenciarla por ARN (no por alias ni por ID). Las cuotas de peticiones se cargan a la cuenta que hace la llamada, no a la dueña de la clave.

Rotación de claves

Rotar una KMS key significa generar nuevo material criptográfico conservando la misma clave lógica (mismo ID, ARN, alias y políticas). KMS guarda todo el material anterior y elige automáticamente el correcto para descifrar, así que no hay que recifrar datos ni cambiar código. La rotación no rota las claves de datos ya generadas ni recifra nada.

• Automática: aws kms enable-key-rotation --key-id … --rotation-period-in-days 180. Viene desactivada por defecto en las customer managed keys.
• Bajo demanda (on-demand): RotateKeyOnDemand rota ya, sin cambiar el calendario automático. Útil tras un incidente o para pruebas.
• Manual: creas una clave nueva y cambias el alias para que apunte a ella. Las aplicaciones que usan el alias empiezan a usar la clave nueva; la antigua debe seguir existiendo para descifrar lo que cifró.

Claves multi-región

Una multi-Region key es un conjunto de claves en varias regiones con el mismo ID de clave (empieza por mrk-) y el mismo material. Lo que se cifra en una región se puede descifrar en otra sin llamar entre regiones ni recifrar. Hay una clave primaria y réplicas; cada una es un recurso independiente con su propia key policy, alias y grants, pero comparten material y la configuración de rotación (que se gestiona en la primaria).

Casos de uso: recuperación ante desastres entre regiones, cifrado en el cliente de datos que viajan entre regiones (p. ej., atributos cifrados en DynamoDB global tables), firmas digitales verificables en varias regiones. No las uses por defecto: AWS recomienda claves de una sola región salvo que necesites exactamente esto, porque replicar material entre regiones puede chocar con requisitos de residencia.

Material de clave importado y custom key stores

• Importar material (bring your own key, BYOK): creas una clave sin material (origen EXTERNAL) e importas el tuyo. Motivos: demostrar la fuente de entropía, conservar el original fuera de AWS, poder fijar caducidad o borrar el material y reimportarlo después. Tú respondes de la durabilidad del original. No admite rotación automática (sí bajo demanda) ni se puede usar en custom key stores.
• Custom key store respaldado por CloudHSM: las claves de KMS se generan y usan dentro de tu clúster de CloudHSM. Mantienes la integración y la API de KMS con HSM de un solo inquilino bajo tu control.
• External key store (XKS): el material vive en un gestor de claves fuera de AWS; KMS le pide cada operación. Para requisitos regulatorios muy estrictos. Añade latencia y dependencia de tu infraestructura.

Desactivar y borrar claves

Borrar una clave es irreversible y deja ilegible todo lo que cifró. Por eso KMS obliga a programar el borrado con un periodo de espera de 7 a 30 días (por defecto 30). Durante la espera la clave está en Pending deletion: no se puede usar y puedes cancelar el borrado. Mientras está pendiente de borrado no se cobra. Si no estás seguro, desactívala (DisableKey) en lugar de borrarla: es reversible. Crea una alarma de CloudWatch que avise si alguien intenta usar una clave pendiente de borrado.

Cuotas y throttling

KMS limita las peticiones por segundo (request quotas). Las operaciones criptográficas simétricas (Encrypt, Decrypt, GenerateDataKey, ReEncrypt…) comparten una cuota por cuenta y región:

(Valores por defecto a 30/09/2026 en la página de cuotas de KMS; son ampliables mediante Service Quotas.) Las claves RSA y ECC tienen cuotas propias mucho menores (1.000/s compartidas por tipo) y los custom key stores, 1.800/s por almacén (no ampliable).

Al superar la cuota, KMS devuelve ThrottlingException. Importa porque las peticiones que hacen los servicios en tu nombre cuentan: cada subida de un objeto a S3 con SSE-KMS genera un GenerateDataKey y cada descarga un Decrypt. Una carga masiva a S3 con SSE-KMS puede agotar la cuota. Soluciones típicas:

• S3 Bucket Keys: S3 genera una clave a nivel de bucket y reduce drásticamente las llamadas a KMS (y su coste).
• Caché de claves de datos del AWS Encryption SDK para reutilizar claves de datos.
• Reintentos con exponential backoff y jitter en el cliente.
• Pedir un aumento de cuota en Service Quotas y vigilar el uso con alarmas de CloudWatch.

Precio

• 1 USD/mes por customer managed key (prorrateado por horas), más el suplemento de las dos primeras rotaciones.
• 0,03 USD por 10.000 peticiones de claves simétricas (la tabla varía por tipo de clave).
• Capa gratuita: 20.000 peticiones al mes (sumando todas las regiones).
• Las claves AWS managed y AWS owned no tienen cuota mensual; las AWS managed pagan uso (a veces lo asume el servicio) y las AWS owned no cuestan nada.

Fuente: AWS KMS Pricing, consultado el 30/09/2026. Estimación orientativa: confirma siempre en la página o en la AWS Pricing Calculator.

Cifrado en reposo en los servicios más preguntados

AWS CloudHSM frente a AWS KMS

AWS CloudHSM te da HSM dedicados de un solo inquilino dentro de tu VPC. AWS gestiona el hardware, la disponibilidad, las copias de seguridad y los parches; tú gestionas los usuarios del HSM y las claves, y AWS no tiene acceso a ellas. Los HSM se agrupan en clústeres; para alta disponibilidad pon al menos dos HSM en AZ distintas (CloudHSM sincroniza las claves entre ellos). Los clústeres pueden funcionar en modo FIPS (HSM validados FIPS 140-2 o 140-3 de nivel 3) o no FIPS.

Consulta el precio por hora de tu región en AWS CloudHSM Pricing o en la AWS Pricing Calculator: con varios HSM encendidos 24/7 es un servicio caro comparado con KMS.

AWS Secrets Manager frente a SSM Parameter Store

La tarea 1.2 empieza por Application configuration and credentials security. La regla de oro: nunca guardes contraseñas, claves de API ni cadenas de conexión en el código, en variables de entorno sin cifrar, en la AMI o en user data. La aplicación obtiene sus credenciales en tiempo de ejecución, autenticándose con su rol IAM, desde uno de estos dos servicios.

AWS Secrets Manager guarda secretos cifrados con KMS (envelope encryption, AES-256), controla el acceso con IAM y políticas de recurso, rota los secretos automáticamente y puede replicarlos a otras regiones. Para Amazon RDS, Aurora, Redshift y DocumentDB ofrece rotación nativa; también hay rotación gestionada (managed rotation) para secretos que administran otros servicios, sin función Lambda que mantener. Para cualquier otro secreto (una clave de API de un tercero), la rotación la hace una función Lambda que escribes o adaptas de una plantilla.

AWS Systems Manager Parameter Store es un almacén jerárquico de configuración (/app/prod/url-bd). Guarda valores String, StringList y SecureString (cifrado con KMS). Es gratuito en el nivel estándar. No rota secretos por sí mismo.

Fuentes: Secrets Manager pricing, Secrets Manager quotas, rotation schedules, Parameter Store tiers y Systems Manager pricing.

Cómo funciona la rotación nativa de una contraseña de RDS: Secrets Manager crea una versión nueva del secreto (etiqueta AWSPENDING), cambia la contraseña en la base de datos, la prueba y mueve la etiqueta AWSCURRENT a la nueva versión. Las aplicaciones que leen siempre AWSCURRENT (y cachean con caducidad) no notan el cambio.

Política IAM mínima para que una aplicación lea un secreto concreto (principio de mínimo privilegio):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "arn:aws:secretsmanager:eu-south-2:111122223333:secret:prod/pedidos/bd-*"
    }
  ]
}

Si el secreto usa una customer managed key, el rol necesita también kms:Decrypt sobre esa clave (y la key policy debe permitirlo).

Amazon Cognito: identidad para los usuarios de tus aplicaciones

IAM e IAM Identity Center son para personas y cargas de trabajo que administran AWS. Para los usuarios finales de tu aplicación web o móvil (clientes, cientos de miles o millones) se usa Amazon Cognito. Tiene dos piezas independientes que se pueden combinar:

flowchart LR
    U["Usuario de la app"] -->|"1. inicia sesión"| UP["Cognito user pool"]
    UP -->|"2. tokens JWT"| U
    U -->|"3a. llama a la API con el token"| APIGW["API Gateway (autorizador Cognito)"]
    APIGW --> L["Backend (Lambda)"]
    U -->|"3b. cambia el token por credenciales"| IP["Cognito identity pool"]
    IP -->|"STS: credenciales temporales (rol IAM)"| U
    U -->|"4. acceso directo"| S3["Amazon S3 / DynamoDB"]

Estado de Amazon Cognito Sync (la antigua sincronización de datos de usuario entre dispositivos): en mantenimiento desde el 30/06/2026, no admite clientes nuevos. No forma parte de lo que pregunta el examen.

Servicios de detección: qué detecta cada uno

Esta tabla resuelve muchas preguntas. Memorízala por la columna «qué analiza».

flowchart LR
    CT["CloudTrail"] --> GD["GuardDuty (amenazas)"]
    FL["VPC Flow Logs / DNS"] --> GD
    EC2["EC2, ECR, Lambda"] --> INS["Inspector (vulnerabilidades)"]
    S3["Buckets S3"] --> MAC["Macie (datos sensibles)"]
    CFG["Configuración de recursos"] --> CSPM["Security Hub CSPM (estándares)"]
    GD --> SH["Security Hub (correlación y prioridad)"]
    INS --> SH
    MAC --> SH
    CSPM --> SH
    GD --> DET["Detective (investigación)"]
    SH --> EB["EventBridge"]
    EB --> AUTO["Lambda / SSM Automation / SNS"]

Ideas que el examen explota:

• Todos se pueden gestionar en AWS Organizations con una cuenta de administrador delegado (delegated administrator), típicamente la cuenta de seguridad o auditoría, y activarse automáticamente en cuentas nuevas.
• GuardDuty, Inspector, Macie y Security Hub publican sus hallazgos en EventBridge: la respuesta automática (aislar una instancia, avisar por SNS, abrir un ticket) se construye con reglas de EventBridge → Lambda / SSM Automation / SNS.
• GuardDuty, Macie y Detective ofrecen 30 días de prueba gratuita al activarlos por primera vez.
• Ninguno de ellos bloquea tráfico: detectan. Para bloquear ataques web usa AWS WAF; contra DDoS, AWS Shield (módulo 6); para restringir acciones, SCP e IAM.

AWS CloudTrail y AWS Config: auditoría y cumplimiento

AWS CloudTrail: quién hizo qué, cuándo y desde dónde

CloudTrail registra la actividad de la cuenta: cada llamada a la API (desde la consola, la CLI, los SDK u otros servicios) con quién la hizo, cuándo, desde qué IP, con qué parámetros y el resultado.

Tipos de eventos:

Componentes:

• Event history: los últimos 90 días de eventos de gestión, por región, gratis y sin configurar nada. Solo lectura; no sirve para retener más tiempo.
• Trail (registro): entrega continua de eventos a un bucket de S3 (y opcionalmente a CloudWatch Logs y EventBridge). Para retención larga y análisis. Un trail multirregión registra todas las regiones habilitadas (es lo recomendado y lo que crea la consola). Hasta 5 trails por región.
• Organization trail: creado desde la cuenta de administración (o un administrador delegado), registra todas las cuentas de la organización en un bucket central. Las cuentas miembro lo ven pero no pueden desactivarlo ni modificarlo.
• Log file integrity validation: CloudTrail calcula un hash SHA-256 de cada fichero de log y entrega cada hora un fichero de resumen (digest) firmado con RSA. Con aws cloudtrail validate-logs demuestras que ningún log se modificó ni se borró. Protege además el bucket con S3 Object Lock, MFA Delete, cifrado SSE-KMS y una política restrictiva.
• CloudTrail Lake: almacén gestionado de eventos consultable con SQL, con retención de hasta 7 o 10 años según la modalidad de precio.

Precio orientativo (consultado el 30/09/2026 en CloudTrail pricing): el event history es gratis; la primera copia de los eventos de gestión entregada a S3 es gratis; copias adicionales 2,00 USD por 100.000 eventos; data events 0,10 USD por 100.000; Insights, aparte. A eso súmale el almacenamiento en S3.

AWS Config: cómo están configurados tus recursos y si cumplen

AWS Config mantiene un inventario de tus recursos y el historial de su configuración: cada cambio genera un configuration item (CI). Permite responder «¿qué reglas tenía este security group el 3 de marzo?» y «¿qué recursos dependen de esta VPC?».

• Configuration recorder: qué tipos de recursos registrar (todos o una lista), por región.
• Delivery channel: bucket de S3 (instantáneas e historial) y tema de SNS para notificaciones.
• Config rules: evalúan si cada recurso cumple (compliant) o no una regla. Pueden ser gestionadas por AWS (cientos: s3-bucket-versioning-enabled, encrypted-volumes, restricted-ssh, rds-storage-encrypted…) o personalizadas (con Lambda o con el lenguaje Guard). Se disparan al cambiar la configuración o periódicamente.
• Conformance packs: colecciones de reglas (y remediaciones) que se despliegan como una unidad, p. ej. alineadas con PCI DSS o con buenas prácticas operativas; se pueden desplegar en toda la organización.
• Remediation: asociar a una regla un documento de SSM Automation que corrige el recurso no conforme, de forma manual o automática (p. ej., activar el versionado de un bucket o cerrar el puerto 22).
• Aggregator: vista centralizada de inventario y cumplimiento de varias cuentas y regiones en una sola cuenta.
• Advanced queries: consultas tipo SQL sobre el estado actual de los recursos.

Precio orientativo (30/09/2026, Config pricing): 0,003 USD por CI registrado en grabación continua; 0,001 USD por evaluación de regla en el primer tramo. Registrar «todo» en cuentas con mucho movimiento puede salir caro: limita los tipos de recurso si no los necesitas.

CloudTrail frente a Config

Juntos son muy potentes: Config te dice que un security group dejó de cumplir a las 10:02 y, desde su línea temporal, enlazas al evento de CloudTrail que muestra qué usuario hizo el cambio.

AWS Artifact y el cumplimiento normativo

AWS Artifact es el portal de autoservicio, gratuito, donde descargas los informes de cumplimiento de AWS (SOC 1/2/3, PCI DSS, certificaciones ISO, informes de terceros) y gestionas acuerdos con AWS, como el BAA (Business Associate Addendum) necesario para HIPAA, para tu cuenta o para toda la organización. Es la respuesta a «el auditor pide pruebas de que AWS cumple SOC 2 / PCI».

Ojo con el modelo de responsabilidad compartida: los informes de Artifact demuestran que la infraestructura de AWS cumple («seguridad de la nube»). Que tu carga de trabajo cumpla («seguridad en la nube») es cosa tuya. Tus herramientas para demostrarlo:

Para saber si un servicio concreto está dentro del alcance de una norma, AWS publica la lista AWS Services in Scope by Compliance Program. Por ejemplo, la documentación de Cognito indica que su infraestructura cumple SOC 1-3, PCI DSS e ISO 27001 y es apta para HIPAA con BAA.

Cifrado en tránsito: TLS y AWS Certificate Manager

La habilidad del temario es Encrypting data in transit (for example, AWS Certificate Manager [ACM] using TLS) y Rotating encryption keys and renewing certificates.

AWS Certificate Manager (ACM) emite, almacena y renueva automáticamente certificados TLS públicos y privados para servicios integrados: Elastic Load Balancing, Amazon CloudFront, Amazon API Gateway, entre otros. Los certificados públicos de ACM no tienen coste adicional. Con validación DNS, la renovación es automática mientras el registro CNAME siga en su sitio. (ACM y sus detalles de validación son del módulo 6.) Recuerda:

• Los certificados de ACM son regionales; para CloudFront deben estar en us-east-1.
• Para servidores propios (EC2) con certificados públicos, ACM ofrece ahora automatización con el protocolo ACME; para PKI interna, AWS Private CA permite exportar certificados. Los certificados importados en ACM no se renuevan solos: vigila su caducidad (ACM y AWS Config tienen reglas y eventos para avisarte).

Dónde se termina TLS y cómo se fuerza:

Política de bucket que obliga a usar HTTPS:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenegarSinTLS",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::mi-bucket-datos",
        "arn:aws:s3:::mi-bucket-datos/*"
      ],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    }
  ]
}

Gobierno de datos: acceso, clasificación, retención, recuperación y residencia

La tarea 1.3 añade conocimientos de gobierno (Data access and governance, Data recovery, Data retention and classification) y la habilidad Implementing policies for data access, lifecycle, and protection. Aquí los unimos; los detalles de cada servicio de almacenamiento están en los módulos 3 y 4.

Clasificación

• Descubrir qué datos son sensibles: Macie en S3.
• Etiquetar: etiquetas de recurso (clasificacion=confidencial) que luego usan las políticas IAM con ABAC (control por atributos) y las reglas de Config.
• Separar por sensibilidad: buckets, cuentas o incluso OU distintas para datos regulados.

Acceso

• Mínimo privilegio con IAM + políticas de recurso (bucket policies, key policies, políticas de secretos).
• Block Public Access en S3 a nivel de cuenta; VPC endpoints con políticas de endpoint para que los datos no crucen Internet.
• Perímetros de datos con condiciones como aws:PrincipalOrgID (solo identidades de mi organización) y aws:SourceVpce.
• La clave de KMS como segunda barrera: aunque alguien obtenga permiso de lectura en S3, sin kms:Decrypt en la clave no puede leer objetos SSE-KMS.

Retención y ciclo de vida

Recuperación de datos

Versionado de S3, replicación (CRR/SRR), backups automáticos y point-in-time recovery de RDS y DynamoDB, AWS Backup centralizado (con copias entre regiones y entre cuentas) y la papelera de reciclaje (Recycle Bin) para instantáneas. La lección de seguridad: guarda copias en otra cuenta (con su propia clave KMS) para que un atacante con acceso a la cuenta de producción no pueda borrar también los backups.

Políticas de protección de datos

Además de cifrar, AWS ofrece políticas que enmascaran datos sensibles en tránsito por algunos servicios:

• Amazon CloudWatch Logs data protection policies: detectan y enmascaran datos sensibles (tarjetas, correos, credenciales…) en los eventos de log, y auditan dónde aparecen. Solo quien tenga el permiso logs:Unmask ve el valor original.
• Amazon SNS Message Data Protection: hacía lo mismo con mensajes de SNS, pero está en mantenimiento desde el 31/03/2026 (no admite clientes nuevos).

Residencia de datos y soberanía

• Los datos se quedan en la región que elijas; AWS no los mueve a otra región salvo que tú lo configures (replicación, copias de backup entre regiones, claves multi-región…).
• Para garantizar que nadie crea recursos fuera de las regiones permitidas: una SCP que deniegue acciones cuando aws:RequestedRegion no sea la permitida (exceptuando servicios globales como IAM), o el control de denegación de región de AWS Control Tower.
• Revisa qué configuraciones replican datos: CRR de S3, réplicas de lectura entre regiones, global tables, claves multi-región, copias de AWS Backup.
• Para exigencias extremas de soberanía de claves: external key store o CloudHSM.

Ejemplo de SCP de residencia (simplificada: en producción añade todas las excepciones de servicios globales que uses):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SoloRegionesUE",
      "Effect": "Deny",
      "NotAction": [
        "iam:*", "organizations:*", "sts:*", "route53:*",
        "cloudfront:*", "support:*", "budgets:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["eu-south-2", "eu-west-1"]
        }
      }
    }
  ]
}

Seguridad de las cargas de trabajo: repaso integrador de la tarea 1.2

La tarea 1.2 mezcla red y aplicación. La red se estudia a fondo en los módulos 5 y 6; aquí tienes el resumen conectado con lo de esta semana.

• Endpoints de servicio de AWS (AWS service endpoints): cada servicio tiene endpoints regionales públicos (HTTPS), en muchos casos endpoints FIPS para requisitos federales, y puede exponerse dentro de tu VPC con VPC endpoints: gateway (S3 y DynamoDB, gratis) o interface (PrivateLink, para KMS, Secrets Manager, SSM, SQS, SNS, ECR…). Una Lambda o una instancia en subred privada sin NAT necesita endpoints de interfaz para llamar a KMS o Secrets Manager. Las políticas de endpoint limitan qué recursos se pueden usar a través de él.
• Puertos, protocolos y tráfico (Control ports, protocols, and network traffic): security groups (con estado, a nivel de ENI, solo allow) y network ACL (sin estado, a nivel de subred, allow y deny); abre solo lo necesario (443 hacia los endpoints, el puerto de la base de datos solo desde el security group de la aplicación). VPC Flow Logs para ver el tráfico y como fuente de GuardDuty.
• Acceso seguro a aplicaciones (Secure application access): usuarios finales con Cognito; personal con IAM Identity Center; administración de servidores sin abrir SSH con Systems Manager Session Manager; aplicaciones internas sin VPN con autenticación en el ALB.
• Amenazas externas (Threat vectors external to AWS): DDoS → AWS Shield (Standard gratis; Advanced con respuesta 24/7 y protección de costes) y CloudFront; inyección SQL, XSS, bots → AWS WAF con reglas gestionadas delante de CloudFront, ALB, API Gateway o Cognito; credenciales robadas → MFA, roles temporales, GuardDuty.
• Arquitectura de VPC con componentes de seguridad y segmentación: subredes públicas solo para balanceadores y NAT; aplicación y datos en subredes privadas; NAT gateway para salida sin entrada; tablas de rutas que separan capas.
• Integrar servicios para proteger aplicaciones: Shield + WAF en el borde, IAM Identity Center para personas, Secrets Manager para credenciales, KMS para datos, GuardDuty/Inspector para detectar.
• Conexiones externas seguras: Site-to-Site VPN (IPsec sobre Internet, dos túneles), Direct Connect (línea privada; añade VPN o MACsec si se exige cifrado), Client VPN para usuarios remotos.

Trampas típicas del examen

• «AWS managed key» no es lo mismo que «customer managed key». Solo la segunda permite cambiar la key policy, compartir con otras cuentas, desactivar, borrar o elegir el periodo de rotación.
• KMS no cifra ficheros grandes directamente: Encrypt admite como mucho 4 KB. Para datos grandes, envelope encryption con GenerateDataKey.
• La key policy manda. Una política IAM que concede kms:Decrypt no basta si la key policy no delega en IAM o no incluye al principal.
• Rotar la clave no recifra los datos ni cambia el ARN; y KMS descifra lo antiguo sin que hagas nada.
• Las claves son regionales. Para usar datos cifrados en otra región: recifrar con una clave de allí o usar claves multi-región.
• Borrar una KMS key = perder los datos. La respuesta prudente suele ser desactivar o programar el borrado con la espera máxima.
• Throttling de KMS en cargas masivas a S3 con SSE-KMS → S3 Bucket Keys antes que pedir cuota.
• Parameter Store no rota secretos. Si el enunciado pide rotación automática, es Secrets Manager.
• CloudHSM ≠ «más seguro» por defecto. Solo si el enunciado exige HSM dedicado, control exclusivo o APIs estándar. Si pide mínima operación, KMS.
• User pool ≠ identity pool. Tokens JWT para tu API → user pool. Credenciales de AWS para acceder a S3/DynamoDB desde el cliente → identity pool.
• GuardDuty no necesita que actives VPC Flow Logs ni CloudTrail: lee sus propias copias de esas fuentes.
• Macie es solo S3. Datos sensibles en RDS o en EBS no son terreno de Macie.
• Inspector ≠ GuardDuty: Inspector busca vulnerabilidades (CVE, exposición de red); GuardDuty, amenazas y comportamiento malicioso.
• Detective investiga, no detecta ni bloquea. Llega después de un hallazgo de GuardDuty.
• CloudTrail ≠ Config: «quién» → CloudTrail; «cómo estaba / cumple» → Config. Ninguno impide acciones: para eso, SCP e IAM.
• Data events de S3 no están activados por defecto y cuestan aparte.
• Direct Connect no cifra por sí mismo.
• Artifact no evalúa tu cuenta: solo entrega los informes de AWS y los acuerdos.

Palabras clave → respuesta:

Resumen

• AWS KMS protege datos en reposo con envelope encryption: una KMS key cifra claves de datos, que cifran los datos. Cada uso queda en CloudTrail.
• Tres tipos de clave: AWS owned (gratis, invisible), AWS managed (visible, rotación anual, sin control) y customer managed (control total, 1 USD/mes, rotación automática configurable de 90 a 2.560 días).
• El acceso a una clave lo decide la key policy (obligatoria), con IAM y grants como complementos; entre cuentas hacen falta key policy y IAM.
• KMS tiene cuotas por segundo compartidas; las cargas masivas con SSE-KMS se alivian con S3 Bucket Keys y reintentos con backoff.
• CloudHSM = HSM dedicado y control exclusivo; KMS = servicio gestionado e integrado.
• Secrets Manager rota y replica secretos (0,40 USD/secreto/mes); Parameter Store guarda configuración y SecureString (estándar gratis), sin rotación.
• Cognito: user pools autentican y emiten JWT; identity pools dan credenciales temporales de AWS.
• Detección: GuardDuty (amenazas), Inspector (vulnerabilidades), Macie (datos sensibles en S3), Detective (investigación), Security Hub (correlación) y Security Hub CSPM (estándares).
• CloudTrail registra la actividad (quién hizo qué); Config registra configuraciones y evalúa cumplimiento con reglas y remediación. Artifact entrega los informes de cumplimiento de AWS.
• Cifrado en tránsito con TLS y ACM; retención con Object Lock y Backup Vault Lock; residencia con regiones y SCP.

Cobertura del temario

Task 1.2: Design secure workloads and applications

Task 1.3: Determine appropriate data security controls

Servicios in-scope de los que este módulo es dueño

AWS KMS, AWS CloudHSM, AWS Secrets Manager, AWS Systems Manager (Parameter Store), Amazon Cognito, Amazon GuardDuty, Amazon Inspector, Amazon Macie, Amazon Detective, AWS Security Hub (y Security Hub CSPM), AWS CloudTrail, AWS Config y AWS Artifact: todos tratados en las secciones anteriores y practicados en los labs 13 y 14.

Practica lo aprendido

Documentación oficial para ampliar

• AWS KMS keys (conceptos y tipos de clave)
• Rotate AWS KMS keys
• AWS KMS request quotas
• What is AWS CloudHSM?
• AWS Secrets Manager quotas
• Parameter Store — standard and advanced tiers
• What is Amazon Cognito?
• What is Amazon GuardDuty?
• Introduction to AWS Security Hub
• CloudTrail concepts
• What is AWS Config?
• What is AWS Artifact?