SAA-C03

Deep Dive

D1 · Arquitecturas seguras

Seguridad en S3

S3 es el servicio de almacenamiento más usado en AWS y uno de los más atacados cuando está mal configurado. El examen SAA-C03 evalúa tu capacidad para proteger datos en S3 con el mecanismo correcto según el escenario.

Contenido

Control de acceso en S3
Bucket policies y ACLs
Cifrado en S3
Presigned URLs y acceso temporal
Object Lock y versioning
CloudFront + OAC para S3 privado

Control de acceso en S3

S3 tiene múltiples capas de control de acceso que trabajan en conjunto. La Block Public Access es la primera línea de defensa — habilitada por defecto en todas las cuentas nuevas.

Mecanismo	Aplica a	Uso recomendado
Block Public Access	Cuenta o bucket	Siempre ON en producción. Previene acceso público accidental.
Bucket Policy (resource-based)	Bucket y objetos	Acceso cross-account, CloudFront OAC, políticas condicionadas por IP/VPC.
IAM Identity Policy	Usuario/Rol IAM	Acceso de identidades dentro de la misma cuenta AWS.
S3 ACLs	Bucket u objeto individual	Legado — usar solo si necesitas permisos por objeto. AWS recomienda desactivarlos.
VPC Endpoint Policy	Acceso desde VPC	Restricción: solo ciertos buckets son accesibles desde una VPC específica.

Bucket policies y ACLs

Escenarios comunes de bucket policies

Acceso cross-account

Cuenta B accede a bucket de Cuenta A. Resource policy en Cuenta A + IAM policy en Cuenta B.

"Principal": {"AWS": "arn:aws:iam::CUENTA-B:root"}

Restricción por IP

Solo permitir acceso desde rangos de IPs corporativas.

"Condition": {"IpAddress": {"aws:SourceIp": "203.0.113.0/24"}}

Denegar HTTP (solo HTTPS)

Forzar cifrado en tránsito denegando requests no seguros.

"Condition": {"Bool": {"aws:SecureTransport": "false"}} → Deny

Restricción por VPC

Solo permitir acceso desde una VPC específica (con VPC Endpoint).

"Condition": {"StringEquals": {"aws:sourceVpc": "vpc-xxxxx"}}

ACLs — cuándo (no) usarlas

AWS recomienda desactivar ACLs

Las ACLs son el mecanismo legado de S3. La nueva configuración recomendada es Bucket Owner Enforced (deshabilita ACLs). Toda nueva creación de buckets debería usar solo bucket policies.

Hacer un objeto público

✅ Bucket policy o CloudFront

❌ Object ACL public-read

Acceso entre cuentas

✅ Bucket policy cross-account

❌ Bucket ACL grantee

Cifrado en S3

SSE-S3 (Server-Side Encryption con S3-managed keys)

AWS gestiona las claves automáticamente. AES-256. Sin costo adicional. Sin trazabilidad por acceso de clave.

EXAMEN: Default desde 2023 en todos los buckets nuevos. Menos control, más sencillo.

SSE-KMS (Server-Side Encryption con KMS keys)

AWS KMS gestiona las claves. Cada acceso a un objeto genera un API call a KMS — trazable en CloudTrail.

EXAMEN: Cuando el requisito dice "auditoría de quién accedió a qué dato" — SSE-KMS es la respuesta.

SSE-C (Server-Side Encryption con customer-provided keys)

El cliente provee la clave en cada request. AWS la usa para cifrar/descifrar y la descarta. Tú guardas la clave.

EXAMEN: Raro en el examen. Principalmente para compliance donde la empresa NO quiere que AWS tenga ninguna clave.

Client-Side Encryption

El cliente cifra antes de subir a S3. S3 almacena datos ya cifrados. AWS nunca ve los datos en claro.

EXAMEN: Máxima seguridad. Útil cuando no se confía en AWS para nada del cifrado.

Cifrado en tránsito

S3 soporta HTTPS (TLS) para cifrar datos en tránsito. Para forzarlo, usa una bucket policy conaws:SecureTransport: false → Deny. Esto deniega cualquier request HTTP no cifrado al bucket.

Presigned URLs y acceso temporal

Una Presigned URL es una URL que incluye credenciales temporales firmadas. Permite que cualquier usuario (sin cuenta AWS) acceda a un objeto privado de S3 por un tiempo limitado.

Cómo funciona

Tu aplicación genera una Presigned URL con SDK de AWS

La URL incluye: bucket, objeto, acción, expiración y firma criptográfica

El usuario accede directamente al objeto en S3 con esa URL

S3 verifica la firma y el tiempo de expiración

Expirado el tiempo → acceso denegado automáticamente

Casos de uso en el examen

→Compartir un video privado con un cliente por 24 horas
→Permitir que un usuario suba un archivo directamente a S3 sin pasar por tu backend
→Descargar un informe generado dinámicamente sin hacerlo público

Trampa de examen

La Presigned URL hereda los permisos del usuario/rol que la generó. Si el rol ya no tiene acceso al objeto cuando se usa la URL, el acceso se deniega.

Object Lock y Versioning

S3 Versioning

Mantiene múltiples versiones de un objeto. Habilitar antes de Object Lock. Un objeto "eliminado" en realidad recibe un Delete Marker — las versiones anteriores existen.

•MFA Delete: requiere código MFA para eliminar versiones permanentemente
•Recuperación de datos: restaurar versión anterior en segundos
•Protección contra ransomware: las versiones cifradas coexisten con versiones limpias

S3 Object Lock (WORM)

Write Once Read Many — nadie puede modificar ni eliminar objetos durante el período de retención. Para cumplimiento regulatorio (HIPAA, SEC, FINRA).

Governance Mode

Admins con permisos especiales pueden superar la retención. Para uso interno.

Compliance Mode

NADIE puede eliminar el objeto durante la retención, ni root de la cuenta. Para regulaciones estrictas.

CloudFront + OAC para S3 privado

El patrón más seguro para servir contenido de S3 es mantener el bucket completamente privado y usar CloudFront como único punto de acceso con Origin Access Control (OAC).

Flujo de una request

Usuario→CloudFront Edge→OAC (firma la request)→S3 Bucket (privado)→Objeto devuelto

Configuración de la bucket policy

Solo CloudFront (service principal) puede hacer GetObject:

"Principal": {
  "Service": "cloudfront.amazonaws.com"
},
"Condition": {
  "StringEquals": {
    "AWS:SourceArn": "arn:aws:cloudfront::ACCOUNT:distribution/ID"
  }
}

OAC vs OAI (legado)

OAC (recomendado)

Soporta SSE-KMS, HTTP methods adicionales, todas las regiones

OAI (legado)

Solo SSE-S3, GET/HEAD. Migrar a OAC.

¿Entendiste este tema?

Pon a prueba lo que acabas de aprender

Una empresa almacena registros financieros en S3 que deben conservarse por exactamente 7 años sin posibilidad de eliminación por ninguna persona, ni siquiera el administrador de la cuenta. ¿Qué configuración de S3 cumple este requisito?