Cómo un bucket queda público · Buckets expuestos: el error más caro de la nube

En los proveedores actuales, ningún bucket nace público. Alguien lo abre, casi siempre con buena intención y un viernes a las cinco. Estos son los seis caminos que más se repiten; en una revisión, búsquelos en este orden.

Camino 1: una política que permite a todos

En S3, una política de bucket es un documento JSON que dice quién puede hacer qué. El comodín peligroso es el principal "*": cualquier persona, autenticada o no.

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::fotos-app-ejemplo/*"
}

A veces es intencional, como las imágenes públicas de un sitio web. El lío empieza cuando en ese mismo bucket terminan respaldos o exportaciones.

Cómo leer una política

JSON (JavaScript Object Notation) es texto con pares "campo": valor. Una política tiene una lista Statement de sentencias con esta forma:

"Effect": "Allow" o "Deny",
"Principal": QUIÉN,
"Action": "SERVICIO:OPERACIÓN" o [VARIAS],
"Resource": "ARN-DEL-BUCKET[/CLAVES]",
["Condition": { OPERADOR: { CLAVE-DE-CONTEXTO: VALOR } }]

Campo	Qué significa	Ejemplo
`Effect`	Permitir o denegar	`"Deny"` gana siempre sobre `"Allow"`
`Principal`	Quién recibe el permiso	`"*"` es cualquiera; un ARN de rol es una identidad concreta
`Action`	Qué operación	`s3:GetObject` descarga, `s3:PutObject` sube, `s3:ListBucket` lista
`Resource`	Sobre qué	`arn:aws:s3:::bucket/*` son todos sus objetos
`Condition`	Bajo qué circunstancias	exigir HTTPS o pertenecer a una organización

El ARN (Amazon Resource Name) es el identificador único de cualquier recurso de AWS. Si la política está mal escrita, AWS la rechaza al guardarla:

An error occurred (MalformedPolicy) when calling the PutBucketPolicy operation: Action does not apply to any resource(s) in statement

Casi siempre es el par acción y recurso: s3:ListBucket actúa sobre el bucket y pide su ARN sin /*; s3:GetObject actúa sobre objetos y pide bucket/*. Revise eso antes de buscar otra causa.

Camino 2: ACL heredadas

Las ACL (Access Control List) son el mecanismo viejo de S3 y GCS. Dar lectura al grupo AllUsers o allUsers tiene el mismo efecto que la política anterior, y muchos tutoriales antiguos todavía lo recomiendan para "arreglar" un error de permisos. Desde abril de 2023, los buckets nuevos de S3 nacen con las ACL deshabilitadas (propiedad "Bucket owner enforced"), así que este camino aparece sobre todo en buckets antiguos o cuando alguien las vuelve a activar para seguir un tutorial viejo.

Camino 3: listado habilitado

Poder leer un objeto cuyo nombre ya se conoce no es lo mismo que poder listar el bucket. Con s3:ListBucket abierto, un desconocido recibe el inventario completo de claves y ya no tiene que adivinar nada.

Un bucket con dos fotos y un respaldo de base de datos. Cerrado, la petición anónima se rechaza. Cuando la política abre la lectura a cualquiera, un desconocido descarga una foto cuyo nombre conoce. Cuando también se permite listar, recibe el inventario, ve el nombre del respaldo y lo descarga. — [fig] Leer un objeto cuyo nombre se conoce no es lo mismo que listar el bucket: con el listado abierto, el atacante ya no adivina nada.

Camino 4: acceso anónimo en Azure

Si la cuenta de almacenamiento permite acceso anónimo, cada contenedor puede marcarse como Blob (lectura de objetos) o Container (lectura y listado). El contenedor que se abrió "para una prueba" suele seguir así meses después.

Camino 5: enlaces que no caducan

Las URL prefirmadas de S3, las SAS (Shared Access Signature) de Azure y las URL firmadas de GCS dan acceso temporal a un objeto. Generadas con vigencia de años, con permiso de escritura o pegadas en un repositorio público, funcionan como llave maestra.

Camino 6: credenciales filtradas

El bucket puede ser privado y aun así quedar expuesto si las claves de una cuenta con permisos amplios aparecen en código, en una imagen de contenedor o en un .env publicado. Técnicamente no es público; en la práctica, el resultado es el mismo.