Análisis de registros de auditoría de GCP paso a paso
Analice paso a paso los registros de auditoría y VPC Flow Logs de Google Cloud: exportación JSON, carga, veredicto, hallazgos, cronología y remediación.
En resumen. Exporte los registros de auditoría en JSON (no en CSV), suelte todos los archivos en la página de GCP Forensics, compruebe el «periodo cubierto» y los avisos, y lea en este orden: el veredicto, los hallazgos con sus pruebas, la cronología y la lista de remediación. Pivote sobre la IP del atacante y la clave de cuenta de servicio en la pestaña Entidades. Todo se ejecuta localmente en un Web Worker: los registros no se suben.
Este artículo es el complemento práctico de la guía de respuesta a incidentes. Si antes quiere ver el resultado, pulse Probar un ejemplo en la página de la herramienta: carga un incidente ficticio, comentado en el caso práctico ficticio.
Paso 1: exportar los registros en JSON
El analizador lee lo que produce Google Cloud, siempre que sea JSON:
| Origen | Qué se suelta |
|---|---|
| Logs Explorer → Download → JSON | downloaded-logs-*.json (un array JSON); varios archivos si dividió el periodo |
gcloud logging read … --format=json | Un archivo con un array JSON, opcionalmente comprimido con gzip |
| Bucket de sink copiado desde Cloud Storage | La carpeta (o un ZIP) con los archivos JSON lines cloudaudit.googleapis.com/<log>/YYYY/MM/DD/*.json |
| Sink de BigQuery | Resultados de consulta guardados como JSON delimitado por saltos de línea |
Incluya los cuatro tipos de registros de auditoría y VPC Flow Logs si existen. Los detalles, incluido el límite de 10.000 entradas de la descarga de la consola, están en Tipos de Cloud Audit Logs explicados. Las descargas CSV de Logs Explorer y las exportaciones Avro o Parquet de BigQuery se rechazan con una explicación; vuelva a exportar en JSON.
Un mínimo útil para un proyecto a lo largo de 30 días:
gcloud logging read 'logName:"cloudaudit.googleapis.com" OR logName:"vpc_flows"' \
--project=PROJECT_ID --freshness=30d --format=json | gzip > project-logs.json.gz
Paso 2: soltar los archivos
Abra el analizador y suelte los archivos, selecciónelos con Elegir archivos o tome una carpeta completa con Elegir una carpeta. Los ZIP se leen entrada a entrada sin extraerse a disco, los .gz los descomprime el navegador y las exportaciones grandes se procesan en flujo por fragmentos, de modo que la memoria se mantiene acotada.
El parser está escrito en Rust, compilado a WebAssembly y se ejecuta en un Web Worker. Sus registros contienen direcciones de correo, direcciones IP y nombres de recursos; se quedan en su equipo. Puede incluso desconectarse de la red una vez cargada la página.
Paso 3: comprobar qué se ha leído realmente
Antes de fiarse de un veredicto, lea la línea de resumen: periodo cubierto, entradas de registro, archivos, principales y registros de flujo. Después, los avisos:
- Archivos no analizados, cada uno con un motivo (archivo vacío, descarga CSV, no es JSON, gzip dañado, ZIP ilegible).
- No hay registros de auditoría Data Access en esta exportación: las lecturas de datos son invisibles, así que «ningún hallazgo de exfiltración» no significa nada. Vea las limitaciones de los registros Data Access.
- Derivaciones: las entradas de auditoría de GKE / API de Kubernetes se apartan para Kubernetes Forensics y las de Google Workspace para Google Workspace Forensics.
Si el periodo no cubre la intrusión sospechada, pare y exporte más.
Paso 4: leer el veredicto y sus motivos
La política de veredicto está en el archivo de reglas publicado:
| Veredicto | Condición |
|---|---|
| Comprometido | Al menos un hallazgo crítico, o hallazgos de gravedad alta o crítica en al menos dos tácticas distintas |
| Sospechoso | Al menos un hallazgo de gravedad media o superior |
| Limpio | Ningún hallazgo de gravedad media o superior (pueden aparecer notas de gravedad baja, como una cuenta de servicio nueva) |
«Limpio» no es una prueba de ausencia: solo cubre los registros que soltó. Los motivos que aparecen bajo el veredicto enlazan con los hallazgos que lo determinaron.
Paso 5: revisar los hallazgos y sus pruebas
Cada hallazgo muestra su gravedad, su tipo (regla, umbral, análisis o correlación), la táctica, los identificadores de técnicas de MITRE ATT&CK, los objetivos (un ID de clave, un cambio de IAM como ADD roles/owner user:x@gmail.com, un bucket) y las entradas de prueba con el JSON original.
Las detecciones cubren, entre otras cosas:
- Credenciales:
CreateServiceAccountKey, claves subidas, una clave usada desde una IP pública, una clave usada desde una IP que nunca había usado, emisión de tokens a través de la API IAM Credentials, ráfagas de llamadas denegadas. Vea clave de cuenta de servicio filtrada y suplantación. - IAM: concesiones de Owner / Editor / administrador de IAM, cuentas de Gmail, dominios desconocidos,
allUsers. Vea abuso de SetIamPolicy. - Cómputo: scripts de inicio, claves SSH, OS Login eliminado, VM con GPU, ráfagas de creación de VM, VM en regiones nunca usadas, firewalls abiertos a
0.0.0.0/0. Vea abuso de Compute Engine. - Datos: ráfagas de
storage.objects.get, recursos públicos, copias de BigQuery a otros proyectos, imágenes e instantáneas compartidas, grandes salidas en los registros de flujo. Vea exfiltración de GCS y BigQuery. - Antiforense: sinks, exclusiones, buckets de registros, registros, registro Data Access, notificaciones de Security Command Center. Vea evasión de defensas.
La lista completa, con gravedades e identificadores de ATT&CK, está en la tabla de reglas.
Paso 6: reconstruir la cronología y pivotar
La pestaña Cronología ordena en el tiempo la actividad marcada y los hallazgos. La pestaña Entidades lista los principales (con su tipo: cuenta de servicio, usuario, Gmail personal, agente de servicio de Google; y las cadenas de suplantación), las claves de cuenta de servicio (con su creador y sus IP), las IP de origen (con los bytes intercambiados según VPC Flow Logs), los proyectos y los recursos. Un clic en cualquiera de ellos filtra la tabla Eventos por esa entidad.
Los dos pivotes que resuelven la mayoría de los casos:
- La IP del atacante. Todo lo que hizo, con cada identidad que usó.
- El ID de la clave. Dónde se creó la clave, quién la creó y cada IP que la usó.
Cambie entre UTC y hora local según necesite; en el informe, mantenga UTC.
Paso 7: seguir la lista y exportar
La pestaña Remediación convierte los hallazgos en acciones ordenadas: declarar un incidente y preservar los registros, bloquear IP, quitar vinculaciones de IAM, inhabilitar claves, reconstruir VM, restaurar los registros. Marque los elementos a medida que avanza (las marcas no se guardan).
Exporte los eventos en CSV (las celdas que podrían interpretarse como fórmulas de hoja de cálculo se neutralizan) o el resultado completo como Informe JSON para su expediente.
Límites a tener en cuenta
- Las heurísticas orientan, no prueban. Un proveedor de CI que usa una clave desde sus propias IP activará «clave usada desde una IP pública».
- Los umbrales están fijados en el archivo de reglas (por ejemplo, 100 lecturas de objetos en 10 minutos, 20 llamadas denegadas en 10 minutos, 1 GiB hacia una misma IP externa).
- Los eventos rutinarios se listan hasta 100.000 en la tabla; los marcados se conservan siempre y las detecciones cubren todas las entradas.
Lecturas recomendadas
- Descripción general de Cloud Audit Logs — documentación de Google Cloud.
- Responder a credenciales de Google Cloud comprometidas — qué hacer con los hallazgos.
- Un compromiso de GCP comentado (caso ficticio) — el ejemplo, explicado.