¿Cuáles son los errores de configuración comunes en buckets de S3 y cómo se previenen?
Respuesta breve
Los errores clásicos son ACL públicas o políticas de bucket que permiten acceso anónimo o a todos los usuarios de AWS, principales demasiado amplios o acciones con comodín, ausencia de cifrado por defecto y falta de registro. Se previenen activando Block Public Access a nivel de cuenta, usando políticas IAM/bucket con privilegio mínimo, exigiendo cifrado por defecto y TLS, y activando el registro de accesos y reglas de Config para detectar desviaciones.
La mala configuración de S3 es la fuga en la nube de manual, porque el almacenamiento de objetos es fácil de hacer público y las consecuencias — millones de registros expuestos — son graves. La entrevista quiere saber si entiendes por qué estas fugas siguen ocurriendo y cómo hacer que la exposición sea estructuralmente difícil.
Los errores comunes
- ACL / políticas de bucket públicas. Conceder acceso de lectura a
AllUsers(cualquiera en Internet) oAuthenticatedUsers(cualquier cuenta de AWS, no solo la tuya — una trampa frecuente). - Principales o acciones con comodín. Una política con
"Principal": "*"o"Action": "s3:*"es mucho más amplia de lo previsto. - Sin cifrado por defecto y sin exigir que las solicitudes usen TLS, de modo que los objetos pueden leerse o escribirse en texto plano.
- Sin registro de accesos ni CloudTrail a nivel de objeto, de modo que una fuga pasa desapercibida y es difícil de investigar.
Cómo prevenirlos
- Block Public Access a nivel de cuenta. Esto anula la configuración individual de los buckets y es el control de mayor valor — hace que "público por accidente" sea casi imposible.
- Políticas de privilegio mínimo. Nombra principales específicos, acota las acciones y prefiere roles IAM frente a políticas de bucket amplias.
- Exige cifrado y TLS. Activa el cifrado por defecto y añade una condición de política que deniegue las solicitudes donde
aws:SecureTransportsea false. - Detecta desviaciones. Usa reglas de Config o una herramienta CSPM para señalar de forma continua cualquier bucket que se vuelva público o pierda el cifrado.
La idea clave: el cifrado en reposo no detiene una lectura anónima si la política la permite — el servicio descifra de forma transparente para una solicitud autorizada, y una política pública convierte al mundo entero en "autorizado".
Qué buscan los entrevistadores
Mencionar Block Public Access primero, distinguir AllUsers de AuthenticatedUsers, y saber que la detección y la prevención importan ambas.
Posibles preguntas de seguimiento
- ¿Qué bloquea realmente S3 Block Public Access, y en qué niveles?
- ¿Cómo detectarías un bucket legible públicamente a través de cientos de cuentas?
- ¿Por qué el cifrado en reposo no ayuda si la política del bucket permite lecturas anónimas?