S3 guarda tus datos, pero ¿quién puede verlos o modificarlos? Controlar el acceso a tus buckets es uno de los aspectos más críticos de la seguridad en la nube. Las filtraciones de datos por buckets mal configurados han sido noticia muchas veces. En este subcapítulo aprenderás a controlar quién accede a qué, y los errores que nunca debes cometer.

Buena noticia para empezar: por defecto, un bucket nuevo es completamente privado. Solo tu cuenta puede acceder a él. Para que alguien más (otra cuenta, un servicio, o el público) pueda acceder, tú tienes que concederlo explícitamente. AWS aplica aquí el principio de «denegar por defecto».

El problema casi siempre viene cuando alguien abre el acceso de más sin querer. Vamos a ver las herramientas para abrirlo (con cuidado).

Hay varias maneras de gestionar permisos en S3. Las principales:

Una bucket policy es un documento (en formato JSON) que se adjunta a un bucket y define reglas detalladas sobre quién puede hacer qué con los objetos.

Analogía: Es como el reglamento de acceso de un edificio, colgado en la entrada: «los repartidores pueden entrar al almacén; el público solo a la recepción; nadie entra a las oficinas sin tarjeta».

Una política de bucket especifica, en cada regla:

• Quién (qué cuenta, usuario o servicio, o «todo el mundo»).
• Qué acción (leer, escribir, borrar…).
• Sobre qué objetos (todo el bucket o una parte).
• Permitir o denegar.

Ejemplo conceptual de una política:

Esto serviría, por ejemplo, para una web estática (subcapítulo 5.5) donde quieres que todo el mundo vea ciertos archivos pero no otros.

Aquí tienes un ejemplo real de bucket policy que permite lectura pública de una carpeta:

No te preocupes por entender cada línea ahora; lo veremos en detalle con IAM en el Capítulo 7. Lo importante: Effect es permitir/denegar, Principal es quién, Action es qué puede hacer y Resource es sobre qué.

Las ACLs (Access Control Lists, listas de control de acceso) son un mecanismo más antiguo y simple para dar permisos básicos a objetos o buckets.

Recomendación de AWS: evita las ACLs. Hoy en día AWS recomienda usar políticas de bucket e IAM en su lugar, porque son más claras y potentes. De hecho, AWS ahora deshabilita las ACLs por defecto en los buckets nuevos. Debes conocer que existen (las verás en documentación antigua), pero no las uses si puedes evitarlo.

También puedes controlar el acceso desde el lado del usuario con políticas de IAM (Capítulo 7): «este usuario puede leer de estos buckets». Es complementario a las políticas de bucket. La diferencia: las políticas de bucket se adjuntan al recurso (el bucket), las de IAM se adjuntan a la identidad (el usuario o rol).

AWS aprendió de los muchos incidentes de buckets expuestos y creó una protección extra llamada Block Public Access (bloquear el acceso público).

Es un interruptor de seguridad que, cuando está activado (lo está por defecto en buckets nuevos), impide que el bucket se haga público, aunque alguien escriba por error una política que lo permita. Es como un doble seguro.

⚠️ Regla de oro: Deja Block Public Access activado salvo que tengas una razón muy concreta y consciente para desactivarlo (como alojar una web pública). Y aun así, valora poner CloudFront delante en lugar de exponer el bucket directamente. Desactivarlo «por probar» y olvidarse es exactamente cómo ocurren las filtraciones.

Estos son los fallos que han causado filtraciones de datos famosas:

1. Hacer un bucket público sin querer. Si pones datos sensibles (datos de clientes, copias de seguridad) en un bucket público, cualquiera en internet puede descargarlos. Esto ha expuesto millones de registros en empresas reales.
2. Desactivar Block Public Access sin necesidad.
3. Dar permisos demasiado amplios («que cualquiera pueda escribir/borrar»). Un atacante podría borrar o secuestrar tus datos.
4. Usar ACLs heredadas en lugar de políticas claras.

Caso real (patrón repetido): Numerosas empresas han sufrido filtraciones porque un desarrollador dejó un bucket con datos de clientes configurado como público «temporalmente» y se olvidó. Investigadores de seguridad (y atacantes) escanean internet buscando estos buckets abiertos. La lección: trata cada bucket como privado por defecto y abre solo lo imprescindible.

• Privado por defecto: abre acceso solo cuando sea estrictamente necesario.
• Mínimo privilegio: da los permisos justos, ni uno más (concepto clave que veremos en el Capítulo 7).
• Usa políticas de bucket e IAM, no ACLs.
• Mantén Block Public Access activado salvo excepción justificada.
• Cifra los datos (S3 cifra en reposo por defecto; lo veremos con KMS en el Capítulo 23).
• Para webs públicas, sirve a través de CloudFront en lugar de exponer el bucket directamente.

• Los buckets son privados por defecto; tú concedes el acceso explícitamente.
• Las políticas de bucket (JSON) son la forma principal y recomendada de controlar el acceso: definen quién, qué acción, sobre qué y si se permite o deniega.
• Las ACLs son el método antiguo: evítalas, AWS las desactiva por defecto.
• Block Public Access es una red de seguridad que impide exponer el bucket por error: déjalo activado.
• El error más grave y frecuente es hacer público un bucket con datos sensibles. Privado por defecto, mínimo privilegio.

En el último subcapítulo de S3 veremos un uso muy práctico y popular: alojar un sitio web estático directamente en S3.