AWS S3: 10 Ajustes de Supervivencia antes de que los Hackers Encuentren tu Data
Por Jayson Espiritusanto | AWS Security Expert & Fundador de Academia SPG
Por Jayson Espiritusanto | AWS Security Expert & Fundador de Academia SPG
Imagina por un momento que eres el gerente de un banco. Tienes la bóveda más segura del mundo: acero reforzado, sensores biométricos, guardias armados. Pero, por comodidad, decides dejar la puerta trasera abierta de par en par porque el conserje “necesita entrar y salir rápido” para limpiar.
Suena ridículo, ¿verdad? Nadie en su sano juicio haría eso en el mundo físico.
Sin embargo, en la nube, esto ocurre cada segundo. Un bucket de Amazon S3 mal configurado es exactamente eso: una bóveda bancaria con la puerta trasera abierta. La historia reciente de la tecnología está llena de gigantes corporativos que cayeron por este simple error: datos financieros expuestos, credenciales robadas y reputaciones construidas durante décadas, destruidas en segundos.
No importa si gestionas terabytes de data para una multinacional o un simple backup; si tus buckets no son seguros, tu infraestructura no es un activo… es una bomba de tiempo.
He auditado innumerables entornos AWS y el patrón es siempre el mismo: ingenieros brillantes que construyen arquitecturas complejas pero olvidan los cimientos. Por eso he creado este documento con un solo objetivo: darte herramientas tácticas y directas para endurecer tu seguridad hoy mismo, sin teoría aburrida.
Aquí tienes los 10 ajustes para desactivar esa bomba.
1. Bloqueo Global: “Block Public Access”
Vivimos en una era donde la “apertura” es un valor, pero en seguridad, el aislamiento es supervivencia. A menos que tengas una razón muy específica (como un sitio web estático público), esta configuración debe estar activada globalmente.
He visto ingenieros dejar buckets abiertos “temporalmente” para pruebas, solo para olvidar cerrarlos. Semanas después, un script automatizado encuentra ese bucket y exfiltra todo.
La Solución Táctica: Debes activar “Block Public Access” a nivel de cuenta. No lo hagas bucket por bucket; hazlo global. Esto actúa como un escudo maestro que bloquea cualquier intento, presente o futuro, de hacer públicos tus objetos mediante ACLs o políticas nuevas. Es tu primera línea de defensa.
- Acción: Ve a la consola S3 > “Block Public Access settings for this account” > Check en “Block all public access”.
2. Cifrado de Datos: Encriptación por Defecto
Si alguien logra entrar a tu casa, no quieres que puedan leer tu diario. Los datos en reposo deben ser ilegibles para cualquiera que no tenga la llave. En 2026, guardar datos en texto plano es una negligencia profesional.
AWS nos ofrece dos caminos principales, y ambos son no negociables:
- SSE-S3: Gestión simple, donde AWS maneja las claves por ti.
- SSE-KMS: Mayor control y auditoría. Esta opción es superior porque te permite saber exactamente qué usuario desencriptó qué archivo y cuándo.
Configura la encriptación por defecto en todos tus buckets.
3. Precisión Absoluta: El Principio de Privilegio Mínimo
El error más común y peligroso en la gestión de IAM es la comodidad. Es muy fácil escribir una política con Action: "s3:*" porque funciona a la primera y no da errores. Pero al hacer eso, le estás dando a un simple script de reportes el poder absoluto para borrar tu base de datos de producción.
Tus políticas de bucket deben ser granulares. Debes aplicar el Principio de Privilegio Mínimo definiendo explícitamente tres vectores:
- Quién (Principal): El usuario o rol exacto.
- Qué (Action): ¿Solo necesita leer? Entonces jamás le des permisos de escritura o borrado.
- Sobre qué (Resource): ¿A qué bucket o carpeta específica tiene acceso?.
Si un rol solo necesita leer archivos, darle permisos administrativos es una invitación al desastre.
4. Red de Seguridad: Versionado (Versioning)
¿Qué pasa cuando un Ransomware cifre tus archivos o un ingeniero junior borre la base de datos por error?. Sin versionado, esos datos se han ido para siempre.
El versionado es tu seguro contra el desastre. Cuando está activo, guarda un historial de cada cambio. Si algo se borra, AWS no lo elimina físicamente del disco; simplemente añade un “marcador de borrado” (delete marker). Tú puedes revertir ese cambio eliminando el marcador. Es, literalmente, el “Ctrl+Z” de la nube.
5. La Barrera Infranqueable: MFA Delete
Aquí es donde separamos a los novatos de los expertos. El versionado (punto anterior) es excelente, pero tiene una vulnerabilidad crítica: si un atacante compromete una cuenta de administrador o roba tus credenciales, podría entrar y borrar todas las versiones antiguas, dejándote sin nada.
Para evitar esto, debes implementar MFA Delete.
Esta configuración añade una capa de autenticación física al proceso de destrucción de datos. MFA Delete exige que, para eliminar permanentemente una versión de un objeto, se introduzca un código de autenticación multifactor generado desde tu dispositivo (celular).
Piénsalo así: incluso si un hacker tiene tu usuario y tu contraseña, o si ha logrado secuestrar la sesión de tu cuenta root, no podrá destruir tu data porque no tiene tu teléfono físico en la mano para generar el código. Es un mecanismo de defensa final que garantiza que, pase lo que pase con tus credenciales digitales, la integridad de tu historia de datos permanece intacta.
6. Datos Intocables: S3 Object Lock
Para ciertos sectores finanzas, salud, legal la integridad no es opcional. Necesitas garantizar que un archivo no ha sido alterado bajo ninguna circunstancia.
S3 Object Lock utiliza el modelo WORM (Write Once, Read Many). Puedes bloquear objetos para que sean inmutables durante un periodo fijo (por ejemplo, 7 años por normativas fiscales). Durante ese tiempo, ni siquiera el usuario root de la cuenta puede borrarlos o modificarlos. Es ideal para logs de auditoría críticos.
7. Visibilidad Total: Server Access Logging y CloudTrail
La seguridad es visibilidad. Si no puedes verlo, no puedes protegerlo. Necesitas activar dos flujos de información vitales:
- Server Access Logging: Registra cada petición técnica hecha a tu bucket.
- CloudTrail Data Events: Habilítalo para ver quién está accediendo a tus objetos (llamadas de API como
GetObjectoPutObject).
Sin esto, estás operando a ciegas ante una exfiltración de datos.
8. Acceso Temporal: Presigned URLs
A menudo me preguntan: “¿Cómo comparto un reporte confidencial con un cliente externo?”. La respuesta nunca es hacer el bucket público.
La herramienta correcta es una URL prefirmada (Presigned URL). Esto genera un enlace único que otorga acceso temporal al objeto (ej. válido por solo 15 minutos). Es seguro, específico y efímero. Una vez expira el tiempo, el acceso desaparece.
9. Escaneo Automático: Amazon Macie
El error humano existe y es inevitable. Puedes tener las mejores políticas, pero un día, alguien subirá un archivo con datos sensibles donde no debe.
Amazon Macie utiliza Machine Learning para escanear tus buckets automáticamente en busca de información sensible (tarjetas de crédito, PII, llaves privadas). Es tu auditor automático disponible 24/7, alertándote antes de que sea tarde.
10. Gestión Inteligente: Ciclo de Vida (Lifecycle Policies)
La seguridad también es eficiencia. No todos los datos necesitan estar disponibles al instante. Usa Lifecycle Policies para mover datos antiguos a Glacier Deep Archive.
Esto no solo reduce costos drásticamente, sino que coloca la información en un almacenamiento “frío”. La latencia de recuperación de Glacier actúa como una barrera adicional contra la manipulación rápida. Un atacante no puede robar o cifrar lo que tarda horas en recuperarse.
¿Estás listo para el siguiente nivel?
Aplicar estos 10 pasos te pone automáticamente por delante del 90% de los ingenieros que usan AWS hoy en día.
Pero la seguridad en la nube es un ecosistema vivo. Saber configurar un bucket es el inicio. Saber diseñar una arquitectura resiliente, monitorear amenazas en tiempo real y responder a incidentes es lo que diferencia a un usuario promedio de un Experto en Seguridad Cloud.
En Academia SPG ayudo a ingenieros como tú a especializarse en AWS Security, pasando de 0 a experto.
La seguridad no es opcional, es supervivencia.