Ciberseguridad y seguridad de la información

Investigación de incidentes en Google Cloud con Audit Logs y Security Command Center

6 min de lecturaPublicado: 5 de agosto de 2026

Ilustración visual profesional sobre la investigación de incidentes en Google Cloud en el campo de la seguridad en la nube y la respuesta a incidentes

Respuesta rápida

La investigación de incidentes en Google Cloud requiere conectar la identidad, los Audit Logs, las acciones de la API, los recursos, las regiones y las sesiones. Se comienza preservando la evidencia y construyendo una línea de tiempo, y solo después se realiza una contención documentada.

La investigación en la nube requiere conectar identidades, Control Plane, recursos, claves, sesiones y servicios de seguridad. Dado que la actividad se distribuye entre servicios y regiones, una línea de tiempo y la comprensión de los permisos son críticas. Este artículo se centra en la investigación de incidentes en Google Cloud y está dirigido a analistas de Cloud y SOC. El objetivo es proporcionar una metodología de trabajo que pueda aplicarse en la práctica, en una entrevista profesional y en un entorno de trabajo, sin limitarse a una definición de diccionario.

El desafío central es que los datos casi siempre son parciales. Cloud Audit Logs, principalEmail, methodName pueden indicar una dirección, pero su significado depende del tiempo, el activo, el usuario y la actividad esperada. Por lo tanto, construiremos la investigación en torno a una pregunta de investigación, la evidencia requerida y un criterio claro para su finalización.

El escenario práctico en el artículo es: una línea de tiempo de un cambio de IAM y acceso a un recurso simulado. Todos los ejemplos son datos de laboratorio o descripciones de procesos. Cuando se trata de Penetration Testing, Web o Cloud, se debe trabajar únicamente con una autorización explícita, un alcance definido y la capacidad de detener la prueba.

Mapeo de la organización y los proyectos

El tema 'Mapeo de la organización y los proyectos' es una parte central del trabajo sobre la investigación de incidentes en Google Cloud. Se recomienda dividirlo en tres preguntas: cuál es la entrada, qué decisión se desea tomar y qué evidencia es suficiente para justificarla. Estas preguntas evitan el uso automático de una herramienta sin comprender el propósito.

En la práctica, registre Cloud Audit Logs, principalEmail, methodName, resourceName, Security Command Center, compárelo con el comportamiento esperado y defina al menos un Pivot. El resultado debe ser verificable por otro analista, incluyendo limitaciones y próximos pasos.

Audit Logs

El tema 'Audit Logs' es una parte central del trabajo sobre la investigación de incidentes en Google Cloud. Se recomienda dividirlo en tres preguntas: cuál es la entrada, qué decisión se desea tomar y qué evidencia es suficiente para justificarla. Estas preguntas evitan el uso automático de una herramienta sin comprender el propósito.

IAM y cuentas de servicio

El tema 'IAM y cuentas de servicio' es una parte central del trabajo sobre la investigación de incidentes en Google Cloud. Se recomienda dividirlo en tres preguntas: cuál es la entrada, qué decisión se desea tomar y qué evidencia es suficiente para justificarla. Estas preguntas evitan el uso automático de una herramienta sin comprender el propósito.

Hallazgos del Security Command Center

El tema 'Hallazgos del Security Command Center' es una parte central del trabajo sobre la investigación de incidentes en Google Cloud. Se recomienda dividirlo en tres preguntas: cuál es la entrada, qué decisión se desea tomar y qué evidencia es suficiente para justificarla. Estas preguntas evitan el uso automático de una herramienta sin comprender el propósito.

Alcance, contención y recuperación

La respuesta a la investigación de incidentes en Google Cloud debe reducir el riesgo sin eliminar la evidencia aún necesaria. Se comienza con una acción reversible y focalizada, se confirma la propiedad y la autoridad, y se documenta el tiempo, el ejecutor y el resultado.

La corrección a largo plazo aborda la raíz: permisos, configuración, validación, telemetría, proceso o capacitación. Después de la implementación, se realiza una nueva prueba y se monitorean los signos de recurrencia, en lugar de limitarse a cerrar el ticket.

Puntos de control únicos

En este tema, se recomienda construir de antemano un mapa de evidencia específico. Los principales puntos de control son: Cloud Audit Logs, principalEmail, methodName, resourceName, Security Command Center, project/organization. La lista no es una lista de verificación automática; cada elemento se elige porque puede vincular una entidad, una acción y un tiempo, o explicar un comportamiento legítimo.

Cloud Audit Logs: Defina el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.
principalEmail: Defina el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.
methodName: Defina el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.
resourceName: Defina el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.
Security Command Center: Defina el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.
project/organization: Defina el valor esperado, qué se considerará una anomalía y qué fuente adicional verificará el hallazgo.

Cuando uno de los puntos no está disponible, se debe documentar la brecha y elegir una alternativa. Por ejemplo, si el identificador de proceso no es estable, se puede utilizar el tiempo, el Host, el Usuario y el Parent; si el Payload está cifrado, se utilizan los metadatos, el volumen, la frecuencia y el contexto de TLS/DNS.

Proceso de trabajo recomendado

Defina el alcance y una pregunta de trabajo sobre la investigación de incidentes en Google Cloud.
Registre las fuentes de datos y la evidencia necesaria: Cloud Audit Logs, principalEmail, methodName, resourceName.
Cree una línea base corta de comportamiento normal o resultado esperado.
Realice la prueba mínima en un entorno de laboratorio y guarde el tiempo, la entrada y la salida.
Construya una línea de tiempo o tabla de comparación y separe los hechos de la interpretación.
Realice un Pivot a una fuente adicional para verificar o refutar la explicación inicial.
Resuma la decisión, las limitaciones, la acción recomendada y el criterio de Retest.

Escenario práctico

El escenario elegido es una línea de tiempo de un cambio de IAM y acceso a un recurso simulado. El propósito del ejercicio no es demostrar la capacidad de ataque, sino practicar la recopilación, comparación y documentación de forma segura. Antes de comenzar el trabajo, se definen datos simulados, un marco de tiempo y un resultado esperado.

Al finalizar el ejercicio, se debe presentar un producto que otro analista o evaluador pueda revisar: una captura de pantalla o exportación de la evidencia, una línea de tiempo corta, una suposición inicial, evidencia de corroboración, una limitación y una recomendación. Cuando no hay suficiente evidencia, la conclusión correcta es que el escenario no ha sido probado.

Paso	Qué se realiza	Producto
Preparación	Defina el alcance, el tiempo y el objetivo. Registre qué campos o evidencias de Cloud Audit Logs, principalEmail, methodName se espera que aparezcan.	Plan de prueba corto
Creación de datos	Realice una acción segura y simulada relacionada con la investigación de incidentes en Google Cloud, sin información real ni impacto en un sistema de producción.	Evento/Solicitud/Flujo controlado
Recolección	Recopile la evidencia bruta y el contexto de una fuente adicional. Verifique la zona horaria, los identificadores y la integridad.	Dos evidencias vinculadas
Análisis	Escriba lo que cada evidencia prueba, lo que no prueba y cuál es la posible explicación legítima.	Conclusión provisional
Finalización	Elija un cierre, una escalada, un hallazgo o un ajuste; agregue una recomendación y un Retest.	Producto documentado

Lista de verificación práctica

Verifique y documente: Principal y sesión.
Verifique y documente: Acción de la API.
Verifique y documente: Recurso y región.
Verifique y documente: IP de origen y agente de usuario.
Verifique y documente: ID de evento de auditoría.
Verifique y documente: Hallazgo de GuardDuty/Defender/SCC.
Indique la zona horaria, la versión de la herramienta y la hora de recopilación.
Guarde el dato bruto antes de filtrar o modificar.
Escriba lo que el hallazgo prueba y lo que aún se desconoce.
Defina el propietario y la acción de seguimiento con una fecha.

Errores comunes

Centrarse en una sola región.
Rotar una clave antes de preservar la línea de tiempo.
No verificar AssumeRole o Token.
Ignorar el Control Plane.
No mapear los permisos efectivos.
Deducir que la ubicación geográfica prueba un ataque.

Resumen y CTA

La investigación de incidentes en Google Cloud con Audit Logs y Security Command Center es un tema que conecta el conocimiento técnico con la disciplina de trabajo. Comience con una pregunta, recopile solo evidencia relevante, conserve el contexto y el tiempo, y elija una acción que pueda justificarse y volver a probarse.

En el curso Cybersecurity & AI de HPI, se practican estos principios utilizando sistemas, registros y laboratorios. Un paso natural es pasar a los artículos vinculados, realizar el ejercicio de laboratorio y guardar el producto como parte de una cartera de trabajo profesional.

Preguntas frecuentes

¿La investigación de incidentes en Google Cloud por sí sola prueba un ataque o una debilidad?

No. Proporciona una señal o un hallazgo que necesita contexto, verificación y una fuente adicional. Una conclusión profesional se basa en una secuencia de pruebas y en la conformidad con el comportamiento esperado.

¿Qué se hace cuando faltan algunos datos?

Se documenta lo que falta, se busca una fuente alternativa y se reduce el nivel de confianza. No se deben completar campos con suposiciones ni presentar "Desconocido" como válido.

¿Cuánto tiempo se debe conservar la evidencia?

El tiempo depende de la política, la regulación, el costo y el tipo de incidente. Es importante definir de antemano la retención, la retención legal y la capacidad de exportar la evidencia en un formato verificable.

¿Cómo se practica sin poner en riesgo un sistema real?

Se utilizan máquinas virtuales, datos simulados, CTF o un laboratorio dedicado. En las pruebas autorizadas, se definen el alcance, las condiciones de detención y la copia de seguridad antes de comenzar el trabajo.