Registros Data Access de GCP: desactivados y puntos ciegos
Por qué los registros Data Access de GCP son el callejón sin salida habitual: desactivados, 30 días de retención, lo que no se ve y qué habilitar antes.
En resumen. Los registros de auditoría Data Access son el único rastro de las lecturas en Google Cloud: objetos descargados, secretos consultados, tokens emitidos para cuentas de servicio, políticas de IAM leídas. Están desactivados por defecto (salvo en algunos servicios de BigQuery), se conservan 30 días por defecto y no se pueden activar con carácter retroactivo. Cuando faltan, una investigación puede demostrar lo que se cambió, pero no lo que se llevaron. Habilítelos ya, al menos para IAM, Cloud Storage y Secret Manager, y envíelos a un destino donde sobrevivan más de 30 días.
Es el callejón sin salida más habitual con el que me encuentro en los casos de Google Cloud. Los cambios de IAM, las VM y los borrados de sinks están todos en Admin Activity. Luego, la pregunta «¿qué archivos se llevaron?» se topa con el silencio.
Qué cubren los registros Data Access
Google divide los registros Data Access en tres tipos (configurar los registros de auditoría Data Access):
| Tipo | Ejemplos en una investigación |
|---|---|
ADMIN_READ | GetIamPolicy, ListServiceAccounts, GetServiceAccountKey y GenerateAccessToken en la API IAM Credentials |
DATA_READ | storage.objects.get, AccessSecretVersion, lectura de datos de tablas |
DATA_WRITE | storage.objects.create / delete, escritura de datos en los servicios |
ADMIN_WRITE es el registro Admin Activity, siempre activo. El resto hay que activarlo.
Lo que no se ve sin ellos
| Pregunta | Prueba necesaria | Sin registros Data Access |
|---|---|---|
| ¿Qué objetos se descargaron? | storage.objects.get | Se desconoce |
| ¿Se leyeron secretos? | AccessSecretVersion | Se desconoce |
| ¿Quién suplantó qué cuenta de servicio? | GenerateAccessToken, SignJwt | Solo visible en las llamadas de escritura posteriores mediante serviceAccountDelegationInfo (suplantación) |
| ¿Qué enumeró el atacante? | Llamadas List*, Get* | Solo las llamadas fallidas en escrituras; el reconocimiento es casi invisible |
| ¿Qué leyó una clave filtrada antes de escalar? | Lecturas con serviceAccountKeyName | Solo sus escrituras |
El analizador detecta esta situación y muestra un aviso cuando una exportación no contiene ninguna entrada Data Access: «las lecturas de datos … son invisibles». Las reglas que dependen de las lecturas (bulk_object_reads, sa_impersonation) no pueden activarse, y un veredicto «Limpio» o «Sospechoso» debe leerse con eso en mente.
Por qué suelen estar desactivados
Tres motivos, todos legítimos:
- Coste y volumen. Las lecturas superan con mucho a las escrituras; los registros Data Access se ingieren y almacenan como cualquier otro registro.
- Efectos secundarios. Google advierte que habilitar los registros Data Access para Cloud Storage puede hacer fallar algunas descargas autenticadas desde el navegador (configurar los registros de auditoría Data Access).
- Nadie lo decidió. No hay valor por defecto más allá de BigQuery, así que, salvo que alguien defina un
auditConfiga nivel de organización, los proyectos se crean sin ellos.
Un compromiso razonable: habilitar DATA_READ y ADMIN_READ para IAM, Cloud Storage (en los buckets que importan, si el coste es un problema) y Secret Manager a nivel de organización, y eximir con exemptedMembers a las cuentas de servicio ruidosas y bien conocidas en lugar de apagarlo todo.
Retención: 30 días salvo que actúe
Los registros Data Access y Policy Denied van al bucket _Default, 30 días por defecto; los Admin Activity y System Event van a _Required, 400 días (descripción general del enrutamiento, cuotas). Los incidentes se descubren a menudo semanas después del acceso inicial. Para entonces, las lecturas de los primeros días han caducado, mientras que las escrituras siguen ahí. La asimetría produce una imagen engañosa: un ataque que parece empezar con una escalada de privilegios porque el reconocimiento previo ha desaparecido.
Opciones, de más a menos robusta:
- Un sink de registros (idealmente un sink agregado a nivel de organización) hacia un bucket de un proyecto separado, con una política de retención bloqueada.
- Una retención más larga en
_Defaulten cada proyecto. - Un sink de BigQuery para disponer de un histórico consultable.
Los sinks no recuperan datos anteriores. Lo que configure hoy protege el próximo incidente, no el actual. Para el actual, exporte de inmediato, antes de que se agoten los 30 días: vea Tipos de Cloud Audit Logs explicados.
Otros puntos ciegos que conviene dejar por escrito
Los registros Data Access son la mayor laguna, pero no la única. Un informe completo enumera lo que no se pudo ver:
- Objetos públicos: Google indica que Cloud Audit Logs no registra el acceso a objetos públicos (registros de auditoría de Cloud Storage). Tras conceder
allUsers, las lecturas son invisibles incluso con registros Data Access. - Dentro de la VM: los procesos, archivos y comandos de una instancia de Compute Engine quedan fuera de Cloud Audit Logs. Hacen falta instantáneas de disco y registros del sistema operativo.
- Red: sin VPC Flow Logs en la subred, la salida de una VM comprometida no se registra; con ellos, los volúmenes son estimaciones muestreadas.
- IP de origen ocultada: las llamadas entre servicios de Google muestran
private, y las llamadas desde VM sin IP externa pueden mostrargce-internal-ip(referencia de AuditLog). - Identidades ocultadas: en las llamadas de solo lectura que fallan con PERMISSION_DENIED, Google puede ocultar el correo de quien llama salvo que sea una cuenta de servicio (descripción general de Cloud Audit Logs).
- Otros planos: los registros de auditoría de la API de Kubernetes de GKE y los de Google Workspace son otra historia. El analizador los deriva a Kubernetes Forensics y a Google Workspace Forensics.
Límites del propio analizador
Para ser igual de explícito con la herramienta:
- Solo lee JSON: las descargas CSV de Logs Explorer y las exportaciones Avro / Parquet de BigQuery se rechazan con una explicación.
- Los umbrales heurísticos son fijos (por ejemplo, 100 lecturas de objetos en 10 minutos), lo que puede generar alertas con cuentas de ETL muy activas o no detectar una exfiltración lenta.
- Los trabajos de extracción de BigQuery hacia buckets externos y varias vías de ataque más recientes (invocadores públicos de Cloud Run, acceso masivo a Secret Manager, cambios en VPC Service Controls) todavía no están cubiertos por reglas.
- «IP nueva» y «región nueva» son relativas a lo que exportó. Una exportación corta hace que la IP del atacante parezca la referencia.
Qué habilitar antes del próximo incidente
- Registros Data Access (
ADMIN_READ,DATA_READ) para IAM, Cloud Storage y Secret Manager, a nivel de organización. - Un sink agregado a nivel de organización hacia un bucket bloqueado en un proyecto dedicado.
- VPC Flow Logs en las subredes sensibles.
- Alertas sobre los methodNames de evasión de defensas del artículo sobre evasión de defensas.
Preguntas frecuentes
¿Están habilitados por defecto los registros Data Access de GCP?
No. Los registros de auditoría Data Access están desactivados por defecto en todos los servicios salvo algunos servicios de BigQuery. Hay que habilitarlos por servicio (o para allServices) en la sección auditConfigs de la política de IAM, a nivel de proyecto, carpeta u organización.
¿Cuánto tiempo se conservan los registros Data Access?
Se guardan en el bucket de registros _Default, cuya retención por defecto es de 30 días. Para conservarlos más tiempo hay que cambiar la retención del bucket o enrutarlos con un sink a Cloud Storage, BigQuery u otro bucket de registros.
¿Puedo habilitar los registros Data Access después de un incidente para ver qué pasó?
No. Al habilitarlos solo se registran las llamadas hechas a partir de ese momento; no se recupera nada anterior. Habilítelos ahora para que la próxima investigación los tenga.
Lecturas recomendadas
- Configurar los registros de auditoría Data Access — documentación de Google Cloud.
- Prácticas recomendadas para Cloud Audit Logs — documentación de Google Cloud.
- Google Cloud comprometido: guía de respuesta a incidentes.