Encontrar almacenamiento público en S3, Azure Blob y GCS en una tarde

Cada uno de los tres grandes proveedores tiene un interruptor por encima de cada bucket individual que anula cualquier configuración hecha por debajo. Su tarde tiene dos tareas: encontrar lo que ya está abierto y activar después esos interruptores para que la próxima política descuidada no surta efecto. Hágalas en ese orden, porque los interruptores romperán todo lo que dependa de ser público.

Qué significa "público" en cada plataforma

Las definiciones difieren, y la auditoría debe buscar cada una de ellas.

S3 trata una bucket policy como pública mientras no se demuestre lo contrario. Solo cuenta como no pública si concede acceso a valores fijos, sin comodines ni variables de política, como un principal concreto o un conjunto de bloques CIDR mediante aws:SourceIp. Por tanto, un principal con comodín no supera la prueba.

En Azure deben cumplirse ambas condiciones. Si la cuenta no permite el acceso anónimo, la configuración del contenedor es irrelevante. Si lo permite, un contenedor sigue siendo privado hasta que alguien establece su nivel en Container o Blob.

Paso 1: encontrar lo que está abierto

S3. La guía de AWS recomienda IAM Access Analyzer for S3 para revisar los buckets públicos, así que empiece por ahí. Después compruebe en cada cuenta los cuatro ajustes de Block Public Access: BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy y RestrictPublicBuckets. Tenga en cuenta que GetBucketAcl devuelve los permisos efectivos. Un bucket con una ACL pública e IgnorePublicAcls activado mostrará una ACL que oculta la real.

Azure. El portal le ofrece primero un recuento de solicitudes anónimas. En la cuenta de almacenamiento, abra Monitoring y después Metrics. Use el espacio de nombres Blob, la métrica Transactions, la agregación Sum y añada un filtro con Authentication igual a Anonymous.

Para ver qué contenedores están implicados, cree un diagnostic setting que envíe los logs a un workspace de Log Analytics. Después ejecute esta consulta, que cubre los últimos siete días:

StorageBlobLogs
| where TimeGenerated > ago(7d) and AuthenticationType == "Anonymous"
| project TimeGenerated, AccountName, AuthenticationType, Uri

La columna Uri indica los contenedores y blobs que se están leyendo. Las métricas y los logs solo muestran quién lee de forma anónima, no qué está expuesto, de modo que un contenedor abierto que nadie ha solicitado permanece invisible. Compruebe también los niveles de acceso de los contenedores.

Google Cloud. Inspeccione las políticas IAM de los buckets en busca de roles concedidos a allUsers o allAuthenticatedUsers. Cloud Asset Inventory muestra las políticas de todos los buckets de un proyecto, carpeta u organización, lo que le evita ir bucket por bucket. Las ACL de objeto requieren una revisión aparte, y las managed folders tienen sus propias políticas IAM. Active los usage logs para ver qué cargas de trabajo acceden a datos públicos. Cloud Audit Logs no registra el acceso a objetos públicos, así que aquí no le servirá.

Paso 2: activar los guardarraíles

S3. AWS recomienda activar los cuatro ajustes a nivel de cuenta. También recomienda activar los cuatro en cada bucket para cumplir el control S3.8 de Security Hub. Si tiene varias cuentas, use una política a nivel de organización. Esa política es de todo o nada, sin elección por ajuste, y anula los ajustes a nivel de cuenta en las cuentas miembro seleccionadas. S3 aplica la combinación más restrictiva entre los distintos niveles, por lo que un bucket no puede debilitar lo que impone la cuenta.

Aplique BlockPublicPolicy a nivel de cuenta en particular. De lo contrario, cualquiera que pueda editar una bucket policy puede insertar una política que desactive el ajuste a nivel de bucket. Los cambios a nivel de cuenta se aplican a todas las regiones, pero puede que no lleguen a todas a la vez. Los ajustes de los access points solo se pueden establecer en el momento de la creación, así que revíselos por separado.

Azure. Establezca AllowBlobPublicAccess en False en cada cuenta de almacenamiento. Esto anula la configuración de todos los contenedores, por lo que no necesita tocarlos. Requiere la versión 2019-04-01 o posterior del proveedor de recursos de Azure Storage. El usuario necesita Microsoft.Storage/storageAccounts/write, permiso que incluyen los roles Owner, Contributor y Storage Account Contributor. Mantenga esas asignaciones lo más acotadas posible.

Google Cloud. Aplique public access prevention en los buckets, o establezca la restricción de política de organización storage.publicAccessPrevention a nivel de proyecto, carpeta u organización. Google aconseja aplicarla en el nivel más alto posible. El estado de un bucket es enforced o inherited. Un bucket con el ajuste en enforced sigue así aunque más adelante desactive la restricción en un nivel superior.

Qué se romperá y qué no

Cuente con que algo se rompa, porque ese es el objetivo del ejercicio.

• S3: Los ajustes no modifican las políticas ni las ACL existentes. Si retira un ajuste, todo lo que tenga una política o una ACL pública vuelve a ser público, así que limpie también los permisos de fondo. Revise además las políticas basadas en identidad y las políticas de recurso, como las key policies de KMS, que Block Public Access no cubre.
• Azure: Las lecturas anónimas empiezan a fallar. El código depende de la versión del servicio: 401 para las versiones 2019-12-12 y posteriores; en las anteriores, 409 si la cuenta no permite el acceso anónimo y 404 si lo permite.
• Google Cloud: Las solicitudes que usan allUsers fallan con HTTP 401 o 403. Los bindings existentes se mantienen, pero quedan anulados. Los intentos de añadirlos fallan con 412 Precondition Failed. Las signed URLs no se ven afectadas. La aplicación puede tardar hasta 10 minutos, y los objetos en caché pueden seguir siendo públicos durante el tiempo de vida de Cache-Control, que por defecto es de 3600 segundos.

El contenido que sea público de verdad, como un sitio web estático, necesita una excepción. Azure aconseja trasladarlo a una cuenta de almacenamiento independiente reservada para el acceso anónimo. En Google Cloud, desactive la prevención en el proyecto concreto que contiene el bucket. En S3, personalice los ajustes individuales de los buckets que lo necesiten.

Por dónde empezar

1. Haga una lista de todas las cuentas de AWS, suscripciones de Azure y proyectos de Google Cloud que contengan almacenamiento, incluidos aquellos que nadie recuerda haber creado.
2. Ejecute el descubrimiento descrito arriba: Access Analyzer for S3, la métrica de solicitudes anónimas y la consulta de logs de Azure, y Cloud Asset Inventory para las políticas IAM de los buckets.
3. Para cada hallazgo público, decida si es deliberado. Traslade el contenido público legítimo a cuentas o proyectos dedicados.
4. Active los controles a nivel de cuenta u organización: los cuatro ajustes de S3, AllowBlobPublicAccess en False y la restricción storage.publicAccessPrevention.
5. Vuelva a ejecutar las consultas unos días después para confirmar que las solicitudes anónimas han bajado a cero, y configure una alerta sobre la métrica de solicitudes anónimas de Azure.
6. Si desea una comprobación externa de lo que sigue siendo accesible, nuestro servicio de pruebas de penetración cubre la exposición en la nube, y nuestro equipo de consultoría puede revisar la estructura de sus cuentas.