En equipos de Data Analytics y Machine Learning, el almacenamiento en buckets (S3, GCS, Azure Blob) se convierte en el “bus” de datos: ahí aterrizan extracciones, datasets intermedios, features, artefactos de entrenamiento y resultados. La presión por iterar rápido suele empujar a atajos: compartir un bucket “solo para el equipo”, abrirlo “un rato” para un proveedor, o asumir que un entorno de análisis está aislado porque vive en una cuenta separada.
El problema es que un bucket público no es un fallo teórico: suele ser un punto ciego donde se acumulan gigas de información sensible (PII, datos de clientes, logs con tokens) y, en el peor caso, un canal para que terceros escriban dentro y condicionen tus modelos o tus costes. El matiz clave es distinguir lectura pública (exfiltración) de escritura pública (manipulación y abuso), porque el impacto y la urgencia operativa no son los mismos.
Qué salió mal en la práctica: “era un bucket de laboratorio”
El patrón se repite: un equipo crea un bucket para compartir datasets con analistas y notebooks gestionados. Para evitar fricción con credenciales y permisos finos, alguien habilita acceso público “temporal” durante una importación o para que un tercero cargue ficheros. El sprint sigue, el bucket queda con ACL/políticas permisivas y, semanas después, ese bucket ya contiene datos reales porque el pipeline lo reutiliza por comodidad.
En empresa, el daño raramente aparece como “nos hackearon el bucket”. Aparece como alertas de DLP por exposición de PII, como hallazgos en auditoría (“datos de clientes accesibles desde Internet”) o como incidentes de integridad: datasets que cambian sin trazabilidad, features que dejan de cuadrar y modelos que empiezan a degradar por causas que nadie entiende.
Cuando el bucket es de lectura pública, el riesgo inmediato es la extracción silenciosa: un crawler o un actor oportunista puede listar/descargar si la configuración lo permite. Cuando además es de escritura pública, el escenario se vuelve más peligroso: cualquiera podría subir objetos que tu pipeline consume automáticamente, generando contaminación de datos o activando costes inesperados.
Lectura pública vs. escritura pública: por qué escritura es otro nivel
La lectura pública convierte el bucket en un repositorio expuesto. En analítica/ML, el impacto no es solo reputacional: puede incluir datasets con PII, snapshots de entrenamiento con datos derivados, o exports con identificadores que parecían “anonimizados” pero son re-identificables. Además, muchas organizaciones subestiman lo que hay en “outputs”: predicciones, explicaciones, logs de inferencia y muestras para debugging suelen contener información sensible.
La escritura pública habilita ataques de integridad y abuso operativo. Un ejemplo realista: un pipeline de entrenamiento toma “el último dataset” desde una ruta fija (p. ej. s3://ml-lab/datasets/current/). Si un tercero puede escribir ahí, puede introducir un dataset adulterado o simplemente un volumen masivo de datos que dispare tiempos y costes. Si además hay procesos automáticos que descomprimen o transforman objetos sin validación, se abren puertas a DoS lógico y a fallos en librerías de parsing.
- Lectura pública: fuga de PII, exposición de datos de clientes/finanzas, y pérdida de ventaja competitiva por divulgación de datasets, features o artefactos.
- Escritura pública: manipulación de datasets, contaminación de modelos, “envenenamiento” de datos, y abuso de costes al forzar cómputo/almacenamiento y retrainings innecesarios.
En entornos corporativos, la escritura pública suele pasar más desapercibida porque el bucket “funciona”: los jobs siguen corriendo. El síntoma llega tarde, cuando el equipo de ML detecta drift extraño o cuando FinOps pregunta por un incremento de coste en almacenamiento y en jobs de procesamiento.
Dónde se esconden los puntos ciegos en plataformas de Analytics y ML
Los buckets expuestos rara vez nacen “maliciosamente públicos”. Se crean en momentos de urgencia: migraciones de datasets, PoCs que se convierten en producción, o integraciones con herramientas de BI/ETL que recomiendan permisos amplios para “que funcione”. El punto ciego típico es asumir que una cuenta de “data sandbox” es equivalente a aislamiento de red; si el bucket permite acceso público, Internet no respeta tus fronteras internas.
Hay señales operativas repetidas: buckets con nombres evidentes (data-lake-dev, ml-artifacts), presencia de dumps con fechas, ficheros .parquet/.csv grandes, y rutas “shared/” o “temp/”. En ML es muy frecuente encontrar artefactos de experimentos: model.pkl, metrics.json, feature_store_export, que parecen inocuos pero pueden revelar estructura de datos, variables sensibles o incluso endpoints y credenciales si se han logueado mal.
- Rutas “temporales” que se vuelven permanentes:
/tmp,/staging,/external. Suelen ser las primeras en abrirse por prisa y las últimas en revisarse. - Integraciones con terceros: proveedores que piden “public read” para descargar o “public write” para subir. En la práctica, esto termina sustituyendo un mecanismo correcto (roles, identidades federadas, URLs firmadas) por una puerta abierta.
Ambos casos comparten una característica: nadie “posee” el bucket a nivel operativo. Está en tierra de nadie entre Data, Plataforma y Seguridad, y por eso no hay revisiones periódicas ni pruebas de exposición desde fuera.
Cómo hacerlo en la práctica: detectar y validar exposición (con ejemplos en AWS)
Para operar esto en empresa, lo primero es distinguir “configuración permisiva” de “exposición efectiva”. En AWS, un bucket puede tener una policy que permita Principal: "*", pero estar mitigado por Block Public Access. O al revés: puede parecer cerrado a nivel IAM, pero una ACL antigua o una policy mal redactada lo deja público. La validación debe ser sistemática y repetible.
Acciones concretas: crea un inventario de buckets y automatiza checks de exposición. En AWS, apóyate en S3 Block Public Access, IAM Access Analyzer y AWS Config (reglas gestionadas para S3 público). A nivel de operación diaria, exige que cada bucket tenga owner, entorno, y clasificación de datos como tags, porque sin eso el hallazgo se queda en “bucket público” sin contexto para priorizar.
- Revisar Block Public Access: valida a nivel de cuenta y a nivel de bucket que los cuatro flags estén habilitados, especialmente “BlockPublicPolicy” y “RestrictPublicBuckets”.
- Buscar políticas con principal público: identifica statements con
"Principal": "*"o condiciones laxas. Un ejemplo típico de lectura pública es permitirs3:GetObjecta cualquier principal. - Detectar escritura pública: prioriza cualquier permiso a
s3:PutObject(y tambiéns3:DeleteObject) con principal público; suele ser menos común pero mucho más dañino.
Ejemplo de policy (AWS S3) que habilita lectura pública de objetos, algo que aparece en laboratorios cuando se comparte un dataset “para descargar”:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicReadObjects",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::mi-bucket-analitica/*"
}
]
}
Ejemplo de policy peligrosa por permitir escritura pública (escenario de abuso e integridad). Aunque parezca “solo para que suban ficheros”, en pipelines automatizados esto es una puerta directa a contaminación:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicWrite",
"Effect": "Allow",
"Principal": "*",
"Action": ["s3:PutObject","s3:AbortMultipartUpload"],
"Resource": "arn:aws:s3:::mi-bucket-analitica/inbox/*"
}
]
}
Validación de que quedó bien cerrado: además de ver “verde” en consola, verifica con Access Analyzer que ya no haya hallazgos de acceso público y revisa el estado efectivo de “public access” del bucket. En auditorías internas, el punto débil suele ser cerrar la policy pero olvidar ACLs históricas u objetos con ACL pública heredada.
Recomendaciones para entornos corporativos
Los “public buckets” en analítica y ML suelen nacer por velocidad y falta de ownership, no por desconocimiento técnico. El riesgo real no es solo la fuga de datos: cuando hay escritura pública, el impacto pasa a integridad del dato y del modelo, con costes y degradación difíciles de atribuir.
Operativamente, lo que funciona en empresa es tratar la exposición como un control continuo: inventariar, detectar configuración y exposición efectiva, y cerrar el acceso público con mecanismos de compartición adecuados. Si tu plataforma permite que un bucket “de laboratorio” acabe alimentando pipelines, ese bucket debe cumplir el mismo estándar que producción.
La diferencia entre lectura y escritura pública debe reflejarse en la priorización y en la respuesta. Cerrar lectura pública reduce exfiltración; cerrar escritura pública protege la cadena de datos/ML de manipulación y del abuso operativo que luego se manifiesta como drift, incidentes de calidad o explosiones de coste.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.