Protección de Datos en S3 con Bucket Policy, SSE, Macie y Object Lock para SCS-C03
_Category: Data Protection_
S3 es el servicio de almacenamiento más utilizado en AWS y, al mismo tiempo, el que primero sufre incidentes de seguridad cuando está mal configurado. En el examen SCS-C03, la protección de datos en S3 se evalúa desde múltiples ángulos: el orden de evaluación de políticas de acceso, los mecanismos de inmutabilidad, la detección de datos sensibles y el diseño de logs de auditoría. Organizamos todo siguiendo cinco capas — control de acceso → cifrado → protección ante cambios → clasificación → auditoría — con las trampas más frecuentes en entornos reales.
---
El modelo de defensa en capas de S3 (acceso, cifrado, inmutabilidad, clasificación y auditoría)
Proteger datos en S3 no se reduce a activar una única función: requiere un enfoque de "defensa en profundidad" (Defense in Depth). Piénsalo como la seguridad de una cámara acorazada: control de acceso al edificio (capa de acceso), cerradura de la cámara (cifrado), sellado interior (inmutabilidad), etiquetas de clasificación del contenido (clasificación de datos) y el registro de entradas y salidas (logs de auditoría). Cada capa refuerza a las demás.
Capa 1 — Control de acceso: Bucket Policy, ACL, IAM Policy, Block Public Access, S3 Access Points, VPC Endpoint Policy. Capa 2 — Cifrado: SSE-S3, SSE-KMS, SSE-C, DSSE-KMS y la condición para forzar TLS. Capa 3 — Inmutabilidad: Versioning, MFA Delete, Object Lock (Governance Mode, Compliance Mode y Legal Hold). Capa 4 — Clasificación: Amazon Macie detecta automáticamente PII, datos financieros y credenciales. Capa 5 — Auditoría: Server Access Logging, CloudTrail Data Events e S3 Inventory.
---
Bucket Policy, ACL e IAM Policy: quién tiene prioridad y por qué (orden de evaluación)
Cuando llega una solicitud a S3, AWS evalúa las políticas en un orden específico. No conocer ese orden hace casi imposible diagnosticar por qué se deniega el acceso.
Orden de evaluación: Deny explícito → Block Public Access → Allow en Bucket Policy → Allow en IAM Policy → Allow en ACL. Cualquier Deny encontrado en cualquier punto detiene la evaluación de inmediato. Block Public Access anula incluso las políticas de Bucket Policy que permiten acceso público.
| Tipo de política | Aplica a | Característica principal | Trampa en el examen | |-----------------|----------|--------------------------|---------------------| | IAM Policy | Identidades IAM (usuarios/roles) | Basada en credenciales; no soporta condiciones de VPC | Si el mismo rol existe en otra VPC, el aislamiento es incompleto | | Bucket Policy | Recursos de bucket/objeto | Soporta condiciones como , | En acceso cross-account se requieren Allow en ambas: Bucket Policy y IAM Policy | | ACL | Objeto/bucket | Legado, granularidad por cuenta | Se desactiva completamente con Bucket Owner Enforced |
Clave para el acceso cross-account: el Allow en la Bucket Policy de la cuenta propietaria del bucket más el Allow en la IAM Policy de la cuenta que accede son ambos obligatorios. Si falta uno, la solicitud se deniega. Al activar Bucket Owner Enforced con , las ACL se desactivan por completo y el control queda exclusivamente en Bucket Policy e IAM Policy — es como si el dueño del edificio retirara todos los pases de acceso individuales.
Para restringir el acceso a una VPC específica, usa la condición en la Bucket Policy. Es indispensable que exista previamente un S3 VPC Endpoint (Gateway o Interface). El Gateway Endpoint es gratuito; el Interface Endpoint tiene cargo por hora.
---
Block Public Access y los errores de exposición más comunes
Block Public Access es el mecanismo de seguridad que previene la causa más frecuente de exposición de datos en S3: habilitar el acceso público por error. Se puede configurar a nivel de cuenta y a nivel de bucket; el nivel de cuenta es más restrictivo.
BlockPublicAcls impide agregar ACL públicas. IgnorePublicAcls ignora las ACL públicas ya existentes. BlockPublicPolicy bloquea la aplicación de Bucket Policies que otorguen acceso público. RestrictPublicBuckets neutraliza las políticas públicas existentes y solo permite el acceso a los principales de servicio de S3 y a los usuarios IAM de la cuenta propietaria del bucket.
Hay tres errores frecuentes que conviene memorizar. El primero: desactivar Block Public Access a nivel de cuenta para exponer un bucket concreto, sin darse cuenta de que otros buckets también quedan expuestos. El segundo: no saber que CloudFront con OAC (Origin Access Control) permite servir contenido de S3 manteniendo Block Public Access activo, y desactivarlo innecesariamente. El tercero: combinar con la condición puede hacer que RestrictPublicBuckets interprete la política como pública y la bloquee — la solución es acotar el Principal a una cuenta o rol específico.
Para aplicar Block Public Access de forma global en la organización, añade un Deny de en una SCP, o utiliza la regla de AWS Config con corrección automática.
---
Las cuatro opciones de cifrado en el servidor (SSE-S3 / SSE-KMS / SSE-C / DSSE-KMS)
Desde 2023, SSE-S3 se aplica por defecto a todos los buckets de S3. Sin embargo, los requisitos de cumplimiento normativo y de gestión de claves suelen exigir opciones más específicas.
| Opción | Gestión de claves | Integración con KMS | Costo | Caso de uso principal | |--------|-------------------|---------------------|-------|----------------------| | SSE-S3 | AWS gestiona completamente (AES-256) | No | Gratuito | Cifrado base, minimizar costos | | SSE-KMS | CMK en KMS, control del cliente | Sí (logs de auditoría) | Cargo por llamada a KMS API | Auditoría, rotación y control cross-account de claves | | SSE-C | El cliente provee la clave directamente | No | Sin cargo (pero carga operativa) | No delegar material de clave a AWS | | DSSE-KMS | CMK en KMS, doble cifrado | Sí | Aproximadamente el doble de SSE-KMS | Cumplimiento con doble cifrado FIPS 140-3 |
La trampa más habitual de SSE-KMS es el incremento inesperado de costos. Cada operación PUT/GET llama a KMS API, lo que en buckets de alto tráfico puede disparar la factura. La solución es S3 Bucket Keys: genera un DEK a nivel de bucket y reduce las llamadas a KMS API hasta en un 99 %. Si usas SSE-KMS, activar S3 Bucket Keys no es opcional.
SSE-C requiere que el cliente provea la clave en cada solicitud; AWS no la almacena. Tres restricciones clave: HTTPS obligatorio, imposibilidad de recuperación si se pierde la clave y sin soporte para Cross-Region Replication (CRR). DSSE-KMS utiliza dos claves KMS independientes para doble cifrado y se elige en entornos que exigen cumplimiento FIPS 140-3.
Para forzar cifrado SSE-KMS: Bucket Policy con Deny sobre PUT sin la condición . Para forzar TLS: Bucket Policy con Deny cuando sea .
!4 opciones de cifrado del lado del servidor en S3
Object Lock y Versioning: protección frente a modificaciones y eliminaciones
S3 Object Lock impide que los objetos sean eliminados o sobreescritos durante un período definido. Solo puede activarse al crear el bucket (no puede desactivarse después) y requiere que Versioning esté habilitado.
Governance Mode permite que un administrador con el permiso especial desbloquee o modifique el período de retención. Es el modo flexible: los errores se pueden corregir.
Compliance Mode es la "cámara blindada cuya llave no existe": durante el período de retención, ningún usuario — ni siquiera el root de AWS — puede eliminar el objeto ni acortar el período de retención. Es obligatorio para cumplir requisitos legales como FINRA, SEC Rule 17a-4 e HIPAA.
| Aspecto | Governance Mode | Compliance Mode | |---------|----------------|----------------| | Desbloqueo | Posible con permiso especial | Imposible antes de que expire el período | | Reducir período de retención | Posible con permiso especial | Imposible | | Cuenta root de AWS | Puede desbloquear | No puede desbloquear | | Casos de uso | Pruebas, cumplimiento flexible | FINRA, SEC, HIPAA y obligaciones legales |
Legal Hold bloquea el objeto sin fijar un período de retención; solo quien tenga el permiso puede activarlo o desactivarlo. Se usa para preservar evidencia en litigios.
Cuando se elimina un objeto en un bucket con Versioning activo, se crea un "Delete Marker" y la versión original se conserva. MFA Delete añade autenticación MFA al borrar versiones, protegiendo ante eliminaciones masivas provocadas por el robo de credenciales (solo puede activarse desde la CLI con la cuenta root). Si existe conflicto entre Object Lock y una política Lifecycle, Object Lock siempre tiene prioridad: un objeto bajo retención no puede ser eliminado por Lifecycle.
---
Macie: clasificación automática y monitoreo de datos sensibles
Amazon Macie usa machine learning para detectar y clasificar automáticamente datos sensibles en buckets de S3. En lugar de revisar miles de buckets a mano, Macie identifica PII (información de identificación personal), datos financieros, credenciales e información médica de forma automática.
Macie ofrece dos capacidades principales: evaluación de seguridad del bucket (acceso público, cifrado y configuración de uso compartido de forma automática) y detección de datos sensibles (escaneos programados o bajo demanda para encontrar números de tarjetas de crédito, números de identificación, credenciales de AWS y más). Los hallazgos se envían a EventBridge y desde allí a Security Hub, SNS o Lambda. Para el escenario "notificar y aislar automáticamente cuando se sube PII a S3", el patrón correcto es Macie + EventBridge + Lambda.
Una distinción que el examen evalúa con frecuencia: Macie clasifica el contenido de los datos (información sensible), mientras que GuardDuty detecta comportamientos anómalos en S3 API (descargas masivas, accesos desde regiones inusuales). Para la gestión centralizada de Macie en toda la organización, se usa AWS Organizations con un Delegated Administrator.
---