Guías de seguridad
Exposición pública del almacenamiento en la nube: cuando los datos pueden filtrarse aunque Block Public Access esté activado
Las filtraciones de buckets son problemas de configuración, no intrusiones. AWS indica que Block Public Access no modifica las políticas ni las ACL existentes, así que los ajustes públicos siguen ahí debajo. Cómo auditarlo y corregirlo de verdad.
Las filtraciones desde el almacenamiento de objetos normalmente no implican ninguna intrusión. Nadie entró en un sistema, no se robó ninguna credencial y no hay nada raro en los registros. Simplemente la configuración hizo públicos los datos.
Por qué se filtran datos sin que nadie entre
Intrusión
vulnerabilidad o credenciales → entrar → sacar los datos
los parches, la autenticación y la monitorización tienen cada uno una oportunidad de pararla
Configuración incorrecta (bucket público)
conocer (o adivinar) la URL → descargarla
no es que se saltara la autenticación: la autenticación nunca se pidió
Lo que hace difícil detectar este tipo de fallo es que el acceso no parece ilegítimo. El atacante envía un GET normal a un punto que es realmente público, así que hay poco que puedan captar la detección de intrusiones o las anomalías en los registros. Es el mismo problema que lo que nunca debe estar en un directorio público, pero en el almacenamiento en lugar de en el servidor.
Cada uno de los cuatro ajustes detiene algo distinto
S3 Block Public Access son cuatro ajustes independientes que se pueden combinar como se quiera. Los nombres se parecen tanto que se tratan como un solo interruptor, pero cada uno detiene algo distinto.
- BlockPublicAcls
- Hace fallar los intentos de aplicar una ACL pública nueva (
PutBucketAcl,PutObjectAclo unPutObjectque lleve una ACL pública). Las políticas y ACL existentes no se modifican, así que una ACL pública que ya existía sigue ahí - IgnorePublicAcls
- Hace que S3 ignore todas las ACL públicas del bucket y de sus objetos. Un
PutObjectcon una ACL pública sigue funcionando (esa es la diferencia con BlockPublicAcls). No elimina las ACL existentes ni impide que se establezcan ACL públicas nuevas - BlockPublicPolicy
- Rechaza una política de bucket que permita el acceso público (
PutBucketPolicyy las llamadas equivalentes de los puntos de acceso). No afecta a las políticas existentes - RestrictPublicBuckets
- Limita el acceso a un bucket con una política pública a las entidades de servicio de AWS y a los usuarios autorizados de la cuenta propietaria. Bloquea el acceso entre cuentas (salvo el de las entidades de servicio de AWS), incluida la delegación no pública a una cuenta concreta
La propiedad que comparten los cuatro y que casi todos pasan por alto
Fíjate en que cada entrada de arriba dice que las políticas y ACL existentes no se modifican. La documentación expone la consecuencia de forma directa: los ajustes de bloqueo no alteran las políticas ni las ACL existentes, de modo que quitar un ajuste de bloqueo hace que un bucket u objeto con una política o ACL pública vuelva a ser accesible públicamente.
Así que activar el bloqueo no eliminó el peligro. Solo detiene el acceso por ahora, y las políticas y ACL públicas siguen ahí. Que alguien lo quite temporalmente para investigar algo, una copia a otra cuenta, un diff de Terraform que lo revierta: cualquiera de esas cosas vuelve a hacer públicos los datos. Define tu objetivo como «no es público con el bloqueo desactivado», no como «el bloqueo está activado».
«Público» se define de forma más amplia de lo que crees
Puedes considerar privado un bucket y que S3 lo evalúe como público.
Se evalúa como público
・Una ACL que concede permisos a AllUsers o AuthenticatedUsers; el segundo significa cualquiera con una cuenta de AWS, no cualquiera de tu empresa
・Una política de bucket que nombra entidades con valores que contienen un comodín o una variable de política
・Un rango de aws:SourceIp demasiado amplio (más amplio que /8 en IPv4 o que /32 en IPv6, sin contar los rangos privados)
S3 empieza suponiendo que una política de bucket es pública y luego evalúa si puede considerarse no pública. Si hay ambigüedad, se evalúa como pública.
Se evalúa como no público
Una política que limita el acceso a valores fijos sin comodines: una entidad, un conjunto de bloques CIDR, aws:SourceArn, aws:SourceVpc, aws:SourceVpce, aws:SourceOwner, aws:SourceAccount, etc.
El propio ejemplo de la documentación: aws:SourceVpc con el valor vpc-* es público; con un valor fijo como vpc-91237329 no lo es. «Lo he restringido» y «lo he restringido a un valor fijo» son los dos lados de esa evaluación.
Activa el bloqueo a nivel de cuenta, no por bucket
La documentación recomienda aplicar BlockPublicPolicy a nivel de cuenta, porque una política de bucket puede permitir a los usuarios modificar los ajustes de bloqueo de ese bucket.
Solo a nivel de bucket
alguien que puede cambiar la política del bucket → inserta una política que desactiva el bloqueo → el bucket puede hacerse público
A nivel de cuenta
aunque se reescriba la política del bucket, S3 bloquea la política pública
Cuando los ajustes del punto de acceso, del bucket y de la cuenta difieren, S3 aplica la combinación más restrictiva. Gana el ajuste más estricto, así que restringir en el nivel superior (la cuenta) impide relajarlo por debajo: es el mínimo privilegio aplicado al almacenamiento.
En qué orden corregirlo
Mira qué es público antes de ocultarlo
Activar el bloqueo primero detiene la exposición y, a la vez, te impide ver qué estaba expuesto. Eso es justo lo que BlockPublicAcls dice permitir: protegerte del acceso público mientras puedes auditar, ajustar o modificar de otro modo las políticas y ACL existentes. AWS ofrece IAM Access Analyzer para S3, que enumera los buckets cuyas ACL o políticas conceden acceso público e indica, para cada hallazgo, el origen y el nivel de ese acceso. Haz primero el inventario ahí.
Activa los cuatro ajustes a nivel de cuenta
AWS recomienda activar los cuatro ajustes de bloqueo del acceso público en tu cuenta (y en cada bucket, que es lo que comprueba el control S3.8 de Security Hub). Comprueba antes que tus aplicaciones funcionan sin acceso público: si algo lo necesita de verdad, como el alojamiento de un sitio web estático, ajusta ese caso por separado en lugar de renunciar al control en todas partes.
Elimina de verdad las ACL y políticas públicas (el paso más importante)
El bloqueo no borra las políticas públicas ni las ACL públicas existentes. Vuelve al inventario del paso 1 y elimínalas o reescríbelas. Solo entonces estás en el estado «no es público con el bloqueo desactivado». La mayoría de los equipos se queda en el paso 2, y ese es el punto principal de este artículo.
En los buckets que deben ser públicos, controla lo que se guarda
Cuando el acceso público sea un requisito real, separa el almacenamiento para que un bucket público solo contenga cosas que puedan ser públicas. Las copias de seguridad, los volcados de bases de datos y las listas de clientes no comparten bucket con los recursos publicados. Lo que guardas en un bucket decide cuánto puede filtrarse de él. La versión de este mismo razonamiento en el servidor está en cómo mantener el .env fuera de alcance en un hosting compartido.
No te fíes del nombre del archivo
«Nadie conoce la URL» no es control de acceso (es el mismo problema que los identificadores fáciles de adivinar). Un nombre imposible de adivinar es una protección extra, no un sustituto de la comprobación de permisos. Cuando necesites compartir algo de forma temporal, usa algo que caduque solo, como una URL firmada con tiempo limitado, y deja cerrado el ajuste público.
La visión de este sitio: los incidentes de configuración solo desaparecen cuando el estado se puede auditar
La exposición de buckets se repite no porque la gente sea descuidada, sino porque el estado no se ve. A diferencia de un permiso de archivo o un ajuste del servidor, que el almacenamiento sea público depende de la combinación de cuatro capas (política, ACL, ajuste de cuenta y punto de acceso), y ninguna por sí sola da la respuesta. Nuestra postura en áreas así es dejar que una máquina evalúe la combinación en lugar de depender de la atención de las personas: restringir en el nivel superior para que no se pueda relajar por debajo, y repetir el inventario de forma periódica con algo que dé por ti el veredicto de público o no público. «Tener cuidado» no es un control; es la misma conclusión a la que llegamos con las dependencias (primeros pasos con osv-scanner).
Fuentes (primarias)
- Amazon Web Services, "Blocking public access to your Amazon S3 storage" (Guía del usuario de Amazon S3) — docs.aws.amazon.com (el comportamiento de los cuatro ajustes, la indicación de que el bloqueo no modifica las políticas ni las ACL existentes, la definición de «público» y el motivo de recomendar la aplicación a nivel de cuenta proceden de este documento)
Leer a continuación
- Ubicación: lo que nunca debe estar en un directorio público / cómo mantener el .env fuera de alcance en un hosting compartido
- Credenciales: qué tiene de peligroso el .env y las claves de API / claves SSH y mínimo privilegio
- Inventario: la lista de comprobación del inventario de activos
- La misma forma de «filtración por configuración»: la toma de subdominios y los registros DNS colgantes
FAQ
QSi Block Public Access está activado, ¿estoy a salvo?
Ahora mismo no hay nada accesible desde fuera, pero el peligro no ha desaparecido. La documentación de AWS indica que los ajustes de bloqueo del acceso público no modifican las políticas ni las ACL existentes y que, por tanto, quitar un ajuste de bloqueo hace que un bucket u objeto con una política o ACL pública vuelva a ser accesible públicamente. Las políticas y ACL públicas siguen ahí, debajo del bloqueo. Lo que buscas no es «el bloqueo está activado», sino «nada sería público aunque se desactivara el bloqueo», y eso significa borrar las propias políticas y ACL públicas.
Q¿Debo aplicar los ajustes por bucket o por cuenta?
Por cuenta. Al hablar de BlockPublicPolicy, la documentación explica por qué: una política de bucket puede permitir a los usuarios modificar los ajustes de bloqueo de ese bucket, así que cualquiera que pueda cambiar una política de bucket podría insertar una política que desactive el bloqueo. Con el ajuste activado para toda la cuenta, S3 bloquea las políticas públicas aunque un usuario modifique la política del bucket. Un ajuste a nivel de bucket lo pueden quitar quienes pueden editar las políticas de bucket.
Q¿Qué cuenta exactamente como «público»?
Una definición más amplia de lo que la mayoría supone. Una ACL es pública si concede permisos a los grupos predefinidos AllUsers o AuthenticatedUsers, y AuthenticatedUsers significa cualquiera con una cuenta de AWS, no cualquiera de tu empresa. Con las políticas de bucket, S3 empieza suponiendo que la política es pública y luego evalúa si puede considerarse no pública; solo lo es cuando el acceso se limita a valores fijos sin comodines ni variables de política. Una política que usa aws:SourceIp con un rango muy amplio (más amplio que /8 en IPv4) también se evalúa como pública.
Q¿Los buckets nuevos son seguros por defecto?
La documentación dice que, por defecto, los buckets, puntos de acceso y objetos nuevos no permiten el acceso público, pero que los usuarios pueden modificar las políticas de bucket, las de los puntos de acceso o los permisos de los objetos para permitirlo. Así que el valor por defecto es el lado seguro, y casi todos los incidentes ocurren donde alguien se apartó de él a propósito, o de forma temporal para una tarea. No te fíes del valor por defecto: necesitas a la vez un control que no se pueda desactivar localmente (el bloqueo a nivel de cuenta) y una forma de ver cuándo algo se ha desviado.