Estadísticas del registro de seguridad en Google Cloud

Last reviewed 2022-12-14 UTC

En esta guía, se muestra a los profesionales de seguridad cómo incorporar los registros de Google Cloud para usarlos en estadísticas de seguridad. Mediante las estadísticas de seguridad, ayudas a tu organización a prevenir, detectar y responder a amenazas, como software malicioso, suplantación de identidad (phishing), ransomware y recursos mal configurados.

Esta guía te muestra cómo hacer lo siguiente:

• Habilitar los registros que se analizarán
• Exportar esos registros a la herramienta de estadísticas de tu elección, como BigQuery, Chronicle o una información de seguridad de terceros y administración de eventos Tecnología de SIEM
• Analizar esos registros para auditar tu uso de la nube y detectar amenazas potenciales a tus datos y cargas de trabajo mediante consultas de muestra del proyecto Estadísticas de seguridad de la comunidad (CSA)

La información de esta guía forma parte de las operaciones de seguridad autónomas de Google Cloud, que incluyen la transformación basada en ingeniería de las prácticas de detección y respuesta y las estadísticas de seguridad para mejorar las funciones de detección de amenazas.

En esta guía, los registros proporcionan la fuente de datos que se analizará. Sin embargo, puedes aplicar los conceptos de esta guía para analizar otros datos complementarios relacionados con la seguridad de Google Cloud, como los resultados de seguridad de Security Command Center. En Security Command Center Premium hay una lista de detectores administrados actualizados con regularidad que están diseñados para identificar amenazas, vulnerabilidades y configuraciones incorrectas casi en tiempo real. Mediante el análisis de estos indicadores de Security Command Center y su correlación con los registros transferidos en tu herramienta de estadísticas de seguridad como se describe en esta guía, puedes obtener una visión más amplia sobre las posibles amenazas a la seguridad.

En el siguiente diagrama, se muestra cómo trabajan en conjunto las fuentes de datos de seguridad, las herramientas de estadísticas de seguridad y las consultas de CSA.

En el diagrama, se comienza con las siguientes fuentes de datos de seguridad: los registros de Cloud Logging, los cambios de recursos de Cloud Asset Inventory y los resultados de seguridad de Security Command Center. Luego, en el diagrama se muestran estas fuentes de datos de seguridad que se exportan a la herramienta de estadísticas de seguridad que elijas: BigQuery, Chronicle o una herramienta de SIEM de terceros. Por último, en el diagrama se muestra el uso de consultas de CSA con la herramienta de estadísticas para analizar las fuentes de datos de seguridad exportadas.

Flujo de trabajo de estadísticas del registro de seguridad

En esta sección, se describen los pasos para configurar las estadísticas de registros de seguridad en Google Cloud. El primer paso para configurar las estadísticas de registros de seguridad es habilitar los registros que deseas analizar. luego, deberás exportarlos y Por último, deberás analizarlos. En el siguiente diagrama, se proporciona una representación gráfica de estos tres pasos.

Cada paso del proceso consta de varios componentes, como se describe en la siguiente lista:

• Habilita registros: Hay muchos registros de seguridad disponibles en Google Cloud. Cada registro tiene información diferente que puede ser útil para responder preguntas específicas de seguridad. Algunos registros, como los Registros de auditoría de Cloud, están habilitados de forma predeterminada. Otras se deben habilitar de forma manual, ya que generan costos de transferencia adicionales en Cloud Logging. Por lo tanto, el primer paso del flujo de trabajo es priorizar los registros de seguridad que sean más relevantes para tus necesidades de análisis de seguridad y habilitar esos registros específicos de forma individual.

  Para ayudarte a evaluar los registros en términos de la visibilidad y la cobertura de detección de amenazas que proporcionan, esta guía incluye una herramienta de alcance de registro. Esta herramienta asigna cada registro a tácticas y técnicas de amenaza relevantes en MITRE ATT&CK® Matrix for Enterprise. La herramienta también asigna reglas de Detección de amenazas a eventos en Security Command Center para los registros en los que se basan. Puedes usar la herramienta de permiso de registro para evaluar los registros sin importar la herramienta de estadísticas que uses.

• Exportar registros: después de identificar y habilitar los registros que se analizarán, el siguiente paso es exportarlos a una herramienta de estadísticas como BigQuery, Chronicle o una herramienta de SIEM de terceros.

  La forma de exportar registros depende de la herramienta de estadísticas que uses. En esta guía, se describen brevemente las diversas opciones de exportación y, luego, se muestra cómo exportar registros a BigQuery con un receptor de registros.

• Analizar registros: después de exportar los registros a una herramienta de estadísticas, el siguiente paso es realizar un análisis de los registros exportados para identificar posibles amenazas de seguridad. La forma en la que analizas los registros exportados depende de la herramienta de estadísticas que uses. Si usas un conjunto de datos de BigQuery, puedes analizar los registros mediante consultas de SQL. Si usas Chronicle, analizas los registros mediante las reglas de YARN-L. Si usas una herramienta de SIEM de terceros, usa el lenguaje de consulta que especifica esa herramienta.

  En esta guía, encontrarás consultas de SQL que puedes usar a fin de analizar los registros en tu conjunto de datos de BigQuery o posiblemente en tu herramienta SIEM de terceros. Las consultas de SQL que se proporcionan en esta guía provienen del proyecto Estadísticas de seguridad de la comunidad (CSA). El CSA es un conjunto de código abierto de estadísticas de seguridad fundamentales diseñado para proporcionarte un modelo de referencia de consultas y reglas compiladas con anterioridad que puedes volver a usar a fin de comenzar a analizar tus registros de Google Cloud.

En las siguientes secciones, se proporciona información detallada sobre cómo configurar y aplicar cada paso del flujo de trabajo de estadísticas de registros de seguridad.

Habilitar registros

El proceso completo de habilitación de registros es el siguiente:

• Identifica los registros que se exportarán mediante la herramienta de permisos de registro de esta guía.
• Registra del filtro de registro que genera la herramienta de permisos de registro para usarlo cuando configures el receptor de registros.
• Habilita el registro para cada registro o servicio seleccionado.

Ten en cuenta que el registro no está habilitado de forma predeterminada para todos los servicios. La selección de registros en la herramienta de permisos de registro no los habilita de forma automática. Debes asegurarte de que se haya habilitado el nivel de registro correcto para los servicios específicos que te interesan. Según el servicio, es posible que debas habilitar los registros de auditoría de acceso a los datos correspondientes desde Registros de auditoría de Cloud y los de plataforma, como se detalla más adelante en esta sección.

Identifica los registros con la herramienta de permiso de registros

La herramienta de permiso de registro consta de la siguiente tabla interactiva y filtro de registro. Esta herramienta enumera registros relevantes para la seguridad en Google Cloud, incluidos los registros de auditoría de Cloud, los registros de Transparencia de acceso, los registros de red y varios registros de plataformas. Para usar esta herramienta, primero debes seleccionar los registros que quieras exportar y analizar en función de tus necesidades de seguridad y cumplimiento. Cada registro que seleccionas se agrega al filtro de registro que genera la herramienta.

Para ayudarte a evaluar qué registros seleccionar, esta herramienta asigna cada tipo de registro a las siguientes áreas:

• Reglas Event Threat Detection que dependen de ese registro.
• Infracciones de cumplimiento de CIS para Google Cloud Computing Platform que se pueden detectar en ese registro.
• Tácticas y técnicas de amenaza Mitre ATT&CK® que se pueden supervisar con ese registro.

Herramienta de alcance de registros

La tabla interactiva de esta sección funciona como la herramienta de permisos de registro. El filtro de registro que genera la herramienta aparece en la sección “Filtro de registro generado de forma automática” que sigue a la tabla. Usa la herramienta para identificar y seleccionar los registros que deseas exportar:

• Para seleccionar o quitar un registro en la herramienta de permiso de registro, haz clic en el botón de activación junto al nombre del registro.
• Para seleccionar o quitar todos los registros, haz clic el botón de activación junto al encabezado Tipo de registro.
• Para ver qué técnicas de MITRE ATT&CK pueden supervisarse por cada tipo de registro, haz clic en junto al encabezado MITRE ATT&CK tactics and techniques.

Registra el filtro de registro

El filtro de registro que la herramienta de alcance de registros genera de forma automática contiene todos los registros que seleccionaste en la herramienta. Puedes usar el filtro tal como está o puedes definir mejor el filtro de registro según tus requisitos. Por ejemplo, puedes filtrar (o excluir) recursos solo en uno o más proyectos específicos. Una vez que tengas un filtro de registro que cumpla con los requisitos de registro, debes guardarlo para usarlo cuando exportes los registros. Por ejemplo, puedes guardar el filtro en un editor de texto o guardarlo en una variable de entorno de la siguiente manera:

1. Usa la herramienta de permisos de registro para seleccionar los registros que deseas exportar.
2. En la sección "Filtro de registro generado automáticamente" que sigue a la herramienta, copia el código del filtro de registro.
3. Opcional: edita el código copiado para definir mejor el filtro.

4. En Cloud Shell, crea una variable para guardar el filtro de registro:

   export LOG_FILTER='LOG_FILTER'
   

   Reemplaza LOG_FILTER por el código para el filtro de registro.

Habilita los registros de plataforma específicos del servicio

Para cada uno de los registros de la plataforma que seleccionas en la herramienta de permiso de registro, esos registros deben estar habilitados (por lo general, a nivel de recurso), en función de cada servicio. Por ejemplo, los registros de Cloud DNS están habilitados a nivel de la red de VPC. Del mismo modo, los registros de flujo de VPC se habilitan a nivel de subred para todas las VMs y los registros de reglas de firewall se habilitan a nivel de la regla de firewall individual.

Cada registro de la plataforma tiene sus propias instrucciones sobre cómo habilitar el registro. Sin embargo, puedes usar la herramienta de permiso de registro para abrir con rapidez las instrucciones relevantes de cada registro de la plataforma.

Si deseas obtener información sobre cómo habilitar el registro para un registro de plataforma específico, haz lo siguiente:

1. En la herramienta de alcance de registros, busca el registro de la plataforma que deseas habilitar.
2. En la columna Habilitado de forma predeterminada, haz clic en el vínculo Habilitar que corresponde a ese registro. El vínculo te lleva a instrucciones detalladas sobre cómo habilitar el registro para ese servicio.

Habilita todos los registros de auditoría de acceso a los datos

Como puedes ver en la herramienta de permisos de registro, los registros de auditoría de acceso a los datos de Registros de auditoría de Cloud proporcionan una amplia cobertura de detección de amenazas. Sin embargo, su volumen puede ser bastante grande. Por lo tanto, habilitar los registros de auditoría de acceso a los datos puede generar cargos adicionales relacionados con la transferencia, el almacenamiento, la exportación y el procesamiento de estos registros. Estos cargos adicionales se producen a lo largo del proceso de estadísticas, desde los cargos asociados con Cloud Logging hasta los cargos asociados con la herramienta de estadísticas de seguridad. En esta sección, se explica cómo habilitar estos registros y se presentan algunas prácticas recomendadas para ayudarte a realizar la compensación entre valor y costo.

Nota: Los registros de auditoría de acceso a los datos pueden contener información de identificación personal (PII), como la identidad de las personas que llaman y direcciones IP. Debes aplicar la configuración adecuada de control de acceso y retención disponible en la herramienta de estadísticas para proteger los datos de registro, conservarlos solo durante el tiempo necesario y, luego, borrarlos de forma segura.

Los registros de auditoría de acceso a los datos se encuentran inhabilitados de forma predeterminada, excepto para BigQuery. A fin de configurar los registros de auditoría de acceso a los datos para servicios de Google Cloud que no sean BigQuery, debes habilitarlos de manera explícita mediante la consola de Google Cloud o Google Cloud CLI para editar objetos de política de Identity and Access Management. Cuando habilitas los registros de auditoría de acceso a los datos, también puedes configurar los tipos de operaciones que se registran. Existen tres tipos de registros de auditoría de acceso a los datos:

• ADMIN_READ: Registra las operaciones que leen metadatos o información de configuración.
• DATA_READ: Registra las operaciones que leen datos proporcionados por el usuario.
• DATA_WRITE: Registra las operaciones que escriben datos que proporcionó el usuario.

Ten en cuenta que no puedes configurar el registro de las operaciones ADMIN_WRITE, que son operaciones que escriben metadatos o información de configuración. Las operaciones ADMIN_WRITE se incluyen en los registros de auditoría de Registros de auditoría de Cloud y, por lo tanto, no se pueden inhabilitar.

Práctica recomendada: Habilita los registros de auditoría de acceso a los datos a nivel de la carpeta o de la organización para garantizar el cumplimiento en todos los proyectos secundarios de esa organización o carpeta. Cuando habilitas los registros de auditoría a nivel de carpeta o de organización, la política de auditoría se aplica a todos los proyectos nuevos y existentes en esa organización o carpeta. Esa política de auditoría no se puede inhabilitar a nivel del proyecto.

Administra el volumen de los registros de auditoría de acceso a los datos

Cuando se habilitan los registros de auditoría de acceso a los datos, el objetivo es maximizar su valor en términos de visibilidad de seguridad y, al mismo tiempo, limitar su sobrecarga de administración y los costos. Para ayudarte a lograr ese objetivo, te recomendamos que hagas lo siguiente para filtrar los registros de bajo valor y de gran volumen:

• Prioriza los servicios relevantes, como los servicios que alojan cargas de trabajo sensibles, claves y datos. Para ver ejemplos específicos de servicios que deseas priorizar sobre otros, consulta Ejemplo de configuración de registro de auditoría de acceso a los datos.

• Prioriza los proyectos relevantes, como los proyectos que alojan cargas de trabajo de producción en lugar de los proyectos que alojan entornos de desarrollador y de etapa de pruebas. Para filtrar todos los registros de un proyecto en particular, agrega la siguiente expresión a tu filtro de registros para tu receptor. Reemplaza PROJECT_ID por el ID del proyecto en el que deseas filtrar todos los registros:

  Proyecto	Expresión de filtro de registro
  Excluye todos los registros de un proyecto determinado	NOT logName =~ "^projects/PROJECT_ID"

• Prioriza un subconjunto de operaciones de acceso a los datos, como ADMIN_READ, DATA_READ o DATA_WRITE para obtener un conjunto mínimo de operaciones registradas. Por ejemplo, algunos servicios como Cloud DNS escriben los tres tipos de operaciones, pero puedes habilitar el registro solo para operaciones ADMIN_READ. Después de configurar uno de estos tres tipos de operaciones de acceso a los datos, es posible que desees excluir operaciones específicas que tengan un volumen particularmente alto. Puedes excluir estas operaciones de gran volumen si modificas el filtro de registro del receptor. Por ejemplo, decides habilitar el registro de auditoría de acceso a los datos completo, incluidas las operaciones de DATA_READ en algunos servicios de almacenamiento críticos. Para excluir operaciones específicas de lectura de datos de tráfico alto en esta situación, puedes agregar las siguientes expresiones de filtro de registro recomendadas al filtro de registro del receptor:

  Service	Expresión de filtro de registro
  Excluye registros de grandes volúmenes de Cloud Storage	NOT (resource.type="gcs_bucket" AND (protoPayload.methodName="storage.buckets.get" OR protoPayload.methodName="storage.buckets.list"))
  Excluye registros de grandes volúmenes de Cloud SQL	NOT (resource.type="cloudsql_database" AND protoPayload.request.cmd="select")

• Prioriza los recursos relevantes, como los recursos que alojan tus cargas de trabajo y datos más sensibles. Puedes clasificar tus recursos en función del valor de los datos que procesan y su riesgo de seguridad, por ejemplo, si son accesibles de forma externa o no. Aunque los registros de auditoría de acceso a los datos están habilitados por servicio, puedes filtrar recursos o tipos de recursos específicos a través del filtro de registro.

• Excluir principales principales para que no se registre su acceso a los datos. Por ejemplo, puedes eximir a tus cuentas de pruebas internas para que sus operaciones no se registren. Para obtener más información, consulta Configura exenciones en la documentación de los registros de auditoría de acceso a los datos.

Nota: Además de usar el filtro de registro del receptor para filtrar los registros adicionales, como se explica en esta sección, es posible que quieras impedir que estos registros se transfieran a Cloud Logging por motivos de costo. Para evitar que se transfieran estos registros, puedes aplicar las expresiones de filtro de registro enumeradas en esta sección como filtros de exclusión en el receptor de registros predefinido _Default que enruta los registros (incluidos los registros de auditoría de acceso a los datos) al bucket de registros de _Default. Los filtros de exclusión tienen el efecto opuesto de un filtro de registro, que es un filtro de inclusión. Por lo tanto, cuando configures estas expresiones como filtros de exclusión, debes quitar el operador booleano NOT anterior de las expresiones de filtro que se muestran en esta sección.

Ejemplo de configuración de registro de auditoría de acceso a los datos

En la siguiente tabla, se proporciona una configuración de registro de auditoría de acceso a los datos de referencia que puedes usar para los proyectos de Cloud a fin de limitar los volúmenes de registro y obtener una visibilidad de seguridad valiosa:

Nivel	Servicios	Tipos de registro de auditoría de acceso a los datos	Tácticas de MITRE ATT&CK
Servicios de autenticación y autorización	IAM Identity-Aware Proxy (IAP)^1 Cloud KMS Secret Manager Resource Manager	ADMIN_READ DATA_READ	Descubrimiento Acceso a las credenciales Elevación del privilegios
Servicios de almacenamiento	BigQuery (habilitado de forma predeterminada) Cloud Storage^1, 2	DATA_READ DATA_WRITE	Conjunto de robo de datos
Servicios de infraestructura	Compute Engine Política de la organización	ADMIN_READ	Detección

¹ Habilitar registros de auditoría de acceso a los datos para IAP o Cloud Storage puede generar grandes volúmenes de registros cuando hay un tráfico alto a los recursos web protegidos con IAP o a los objetos de Cloud Storage.

² Habilitar los registros de auditoría de acceso a los datos para Cloud Storage puede interrumpir el uso de las descargas autenticadas del navegador en objetos no públicos. Para obtener más detalles y soluciones alternativas a este problema, consulta la guía de solución de problemas de Cloud Storage.

En la configuración de ejemplo, observa cómo los servicios se agrupan en niveles de sensibilidad según sus datos subyacentes, metadatos o configuración. Estos niveles demuestran el siguiente nivel de detalle recomendado del registro de auditoría de acceso a los datos:

• Servicios de autenticación y autorización: para este nivel de servicios, recomendamos auditar todas las operaciones de acceso a los datos. Este nivel de auditoría te ayuda a supervisar el acceso a las claves sensibles, los secretos y las políticas de IAM. La supervisión de este acceso puede ayudarte a detectar tácticas del MITRE ATT&CK como el Descubrimiento, el Acceso a las credenciales y la Elevación de privilegios.
• Servicios de almacenamiento: para este nivel de servicios, recomendamos auditar las operaciones de acceso a los datos que involucran datos proporcionados por el usuario. Este nivel de auditoría te ayuda a supervisar el acceso a tus datos sensibles y valiosos. La supervisión de este acceso puede ayudarte a detectar tácticas del MITRE ATT&CK como la recopilación y el robo de tus datos.
• Servicios de infraestructura: para este nivel de servicios, recomendamos auditar las operaciones de acceso a los datos que involucran metadatos o información de configuración. Este nivel de auditoría ayuda a supervisar el análisis de la configuración de la infraestructura. La supervisión de este acceso puede ayudarte a detectar tácticas de MITRE ATT&CK como Discovery en tus cargas de trabajo.

Exporta registros

Después de identificar y habilitar los registros, el siguiente paso es exportar los registros a tu herramienta de estadísticas. El proceso de exportación varía según las herramientas de estadísticas que uses, como se muestra en el siguiente diagrama.

En el diagrama se muestran los siguientes procesos de exportación:

• Si usas Chronicle y este conjunto predefinido de registros satisface tus necesidades de análisis de seguridad, puedes exportar registros de forma automática directamente a Chronicle mediante la transferencia integrada de Chronicle como se muestra en el diagrama. También puedes ver este conjunto predefinido de registros si consultas la columna Exportable directamente a Chronicle de la herramienta de permiso de registros. Para obtener más información sobre cómo exportar estos registros predefinidos, consulta Transfiere registros de Google Cloud a Chronicle.

• Si usas BigQuery, una herramienta de SIEM de terceros o deseas exportar un conjunto expandido de registros a Chronicle, el diagrama muestra que se necesita un paso adicional entre la habilitación de los registros y el análisis de estos. Este paso adicional consiste en configurar un receptor de registros que enrute los registros seleccionados de forma adecuada. Si usas BigQuery, este receptor de registros es todo lo que necesitas para enrutar los registros a BigQuery. Si usas una SIEM de terceros, debes hacer que el receptor de registros agregue los registros seleccionados en Pub/Sub o Cloud Storage antes de que los registros se puedan extraer en tu herramienta de estadísticas.

Los procesos de exportación a Chronicle y una herramienta de SIEM de terceros no se tratan en esta guía. Sin embargo, en las siguientes secciones, se describen los pasos y se proporcionan los detalles que necesitas para exportar registros a BigQuery:

1. Configura el conjunto de datos de exportación de registros en BigQuery.

2. Configura el receptor de registros para BigQuery.

   En esta sección, se muestra cómo configurar el receptor de registros para BigQuery. Sin embargo, puedes aplicar los conceptos del receptor de registros presentados en este ejemplo a fin de exportar registros a una herramienta de SIEM de terceros o cuando se exporta un conjunto expandido de registros a Chronicle. La diferencia principal es el destino del receptor de registros. En lugar de BigQuery, el destino es un bucket de Cloud Storage o un tema de Pub/Sub desde el cual la herramienta de estadísticas posterior extraerá los registros (como se muestra en el diagrama).

3. Configura los permisos de la política de IAM para el conjunto de datos de BigQuery.

4. Confirma que los registros se exportaron a BigQuery.

Configura el conjunto de datos para el conjunto de datos de BigQuery

Sigue las instrucciones para configurar un conjunto de datos que alojará los registros exportados. Si usas registros agregados, debes crear el conjunto de datos de BigQuery en uno de los proyectos de Google Cloud dentro de la organización. Cuando usas exportaciones de registros correspondientes a un proyecto único, debes crear el conjunto de datos de BigQuery en el mismo proyecto.

Práctica recomendada: Establece la propiedad vencimiento de partición predeterminada del conjunto de datos para limitar el tamaño total del almacenamiento de exportación de registros y el costo asociado a lo largo del tiempo. Puedes hacerlo durante o después de crear el conjunto de datos. Si detallaste requisitos de retención basados en el tipo de registro, puedes anular esta propiedad a nivel de la tabla después de que el receptor de registros comience a exportar registros y cree sus tablas correspondientes.

Configura el receptor de registros para BigQuery

Para configurar la exportación de registros, crea un receptor de registros con el filtro de registros que generaste y guardaste antes. Para simplificar la administración y la consulta de los datos, configura el receptor de registros a fin de que exporte datos a tablas particionadas en las que los datos se particionan por día en función del campo timestamp de la entrada de registro. Usar tablas particionadas puede ayudar a reducir los costos de consulta, pues reduce la cantidad de datos que se analizan como parte de las consultas. Otro beneficio de las tablas particionadas es que puedesconfigurar un plazo de vencimiento de partición en la tabla individual o en todo el nivel del conjunto de datos, de modo que mantengas los datos de registro solo mientras te sean útiles. Por ejemplo, puedes conservar datos de registros de auditoría durante tres años y, luego, los datos más antiguos se borran de forma automática a medida que caducan y vencen las particiones.

En la CLI de gcloud, usa el comando gcloud logging sinks create o la llamada a la API organizations.sinks.create para crear un receptor con el filtro de registro adecuado. En el siguiente ejemplo, se usa el comando gcloud a fin de crear un receptor llamado gcp_logging_sink_bq para la organización. El receptor incluye todos los proyectos secundarios y especifica el filtro de registro que se usará.

gcloud logging sinks create gcp_logging_sink_bq \
     bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET_ID \
     --use-partitioned-tables \
     --log-filter="LOG_FILTER" \
     --include-children \
     --organization=ORGANIZATION_ID

Reemplaza lo siguiente:

• PROJECT_ID: Es el ID del proyecto en el que se encuentra el conjunto de datos de BigQuery.
• DATASET_ID: Es el ID del conjunto de datos de BigQuery.
• LOG_FILTER: El filtro de registro que guardaste desde la herramienta de permisos de registro.
• ORGANIZATION_ID: El ID de tu organización.

El comando gcloud logging sinks create muestra una respuesta similar a la siguiente:

Created [https://logging.googleapis.com/v2/organizations/324989855333/sinks/gcp_logging_sink_bq].
Please remember to grant `serviceAccount:[e-mail]` the WRITER role on the dataset..
More information about sinks can be found at /logging/docs/export/configure_export

En el resultado de tu respuesta, copia y guarda el valor que se muestra en el campo serviceAccount para usarlo en la siguiente sección. Por ejemplo, el valor serviceAccount que se muestra en el resultado del ejemplo anterior es [e-mail].

El valor que se muestra en el campo serviceAccount proporciona el identificador de la cuenta de servicio asociada con el receptor que acabas de crear. Este identificador es la identidad del escritor del receptor. Hasta que no otorgues el acceso de escritura en el conjunto de datos de BigQuery a esta identidad, fallarán las exportaciones de entradas de registro desde este receptor. En la siguiente sección, otorgas acceso de escritura a la identidad de escritor del receptor.

Configura los permisos de la política de IAM para el conjunto de datos de BigQuery

Para permitir que el receptor de registros escriba registros exportados en BigQuery, debes agregar la identidad de escritor del receptor al conjunto de datos de BigQuery y otorgar permisos de editor a esa identidad. De lo contrario, la operación de escritura fallará.

Para agregar permisos a la cuenta de servicio, sigue estos pasos:

1. En la consola de Google Cloud, ve a BigQuery:

   Ir a BigQuery

2. Abre el conjunto de datos de BigQuery que creaste para los registros exportados.

3. En la pestaña Información del conjunto de datos, haz clic en el menú desplegable Compartir y, luego, en Permisos.

4. En el panel lateral Permisos del conjunto de datos, haz clic en Agregar principal.

5. En el campo Principales nuevas, ingresa la identidad de escritor del receptor. Recuerda que esta identidad es el valor del campo serviceAccount proporcionado en la respuesta que se generó después de crear el receptor de registros.

6. En el menú desplegable Función, selecciona Editor de datos de BigQuery.

   

Luego de crear la exportación de registros con este filtro, los archivos de registro comenzarán a propagarse en el conjunto de datos de BigQuery del proyecto configurado.

Práctica recomendada: Implementa una política de permisos mínimos según tus necesidades. Puedes configurar los permisos del conjunto de datos en función de las cuentas de usuario de Google Cloud específicas, los grupos o las cuentas de servicio de Google Cloud. Usa los permisos de IAM para otorgar acceso al conjunto de datos de BigQuery.

Confirma que los registros se exportaron a BigQuery.

Cuando exportas registros a un conjunto de datos de BigQuery, Cloud Logging crea tablas de BigQuery para contener las entradas de registro exportadas, como se muestra en la siguiente captura de pantalla:

En la captura de pantalla, se muestra cómo Cloud Logging nombra cada tabla de BigQuery según el nombre del registro al que pertenece una entrada de registro. Por ejemplo, la tabla cloudaudit_googleapis_com_data_access que se selecciona en la captura de pantalla contiene registros de auditoría de acceso a los datos cuyo ID de registro es cloudaudit.googleapis.com%2Fdata_access. Además de asignar un nombre en función de la entrada de registro correspondiente, cada tabla también se particiona en función de las marcas de tiempo de cada entrada de registro.

Los registros de actividad del administrador y de acceso a los datos se cargan en BigQuery con su campo de entrada de registro protoPayload que cambia de nombre a protoPayload_auditlog en BigQuery. Para obtener más información sobre las conversiones de esquema que realiza Cloud Logging antes de escribir en BigQuery, consulta Campos en los registros de auditoría exportados.

Analizar los registros

Puedes ejecutar una gran variedad de consultas en los registros de auditorías y de la plataforma. En la siguiente lista, se proporciona un conjunto de preguntas de seguridad de muestra agrupadas por tipo de pregunta. Para cada pregunta de esta lista, la consulta asociada de CSA también se proporciona en esta guía. Para usar las consultas de CSA asociadas con cada pregunta, reemplaza MY_DATASET_ID por el conjunto de datos de BigQuery que creaste antes en este documento y MY_PROJECT_ID por el ID de proyecto de Google Cloud en el que se encuentra el conjunto de datos.

• Acceso y preguntas sobre el acceso
  • ¿Hay algún intento de acceso sospechoso marcado por Google Workspace?
  • ¿Hay errores de acceso excesivos de cualquier identidad de usuario?
  • ¿Hay intentos de acceso que infrinjan los Controles del servicio de VPC?
  • ¿Hay intentos de acceso que infrinjan los controles de acceso de Identity-Aware Proxy?
• Preguntas sobre los cambios de permisos
  • ¿Se agregó algún usuario a grupos altamente privilegiados?
  • ¿Se otorgan permisos sobre una cuenta de servicio?
  • ¿Hay claves o cuentas de servicio creadas por una identidad no aprobada?
  • ¿Se agregó cualquier usuario a la política de IAM sensible (o se lo quitó de ella)?
• Preguntas sobre la actividad de aprovisionamiento
  • ¿Se realizaron cambios en la configuración de registro?
  • ¿Los registros de flujo de VPC están inhabilitados?
  • ¿Hay una cantidad inusual de reglas de firewall modificadas en la última semana?
  • ¿Se borró alguna de las VMs durante la última semana?
• Preguntas sobre el uso de la carga de trabajo
  • ¿Hay un uso de la API inusualmente alto por parte de cualquier identidad de usuario en la última semana?
  • ¿Cuál es el uso de ajuste de escala automático por día en el último mes?
• Preguntas sobre el acceso a los datos
  • ¿Qué usuarios accedieron a los datos con mayor frecuencia en la última semana?
  • ¿Qué usuarios accedieron a los datos de la tabla “accounts” en el último mes?
  • ¿A qué tablas se accede con más frecuencia y quién accede a ellas?
  • ¿Cuáles fueron las 10 consultas más realizadas en BigQuery en la última semana?
  • ¿Cuáles son las acciones más comunes documentadas en los registros de acceso a los datos en el último mes?
• Preguntas sobre seguridad de red
  • ¿Hay alguna conexión desde una IP nueva a una subred específica?
  • ¿Hay alguna conexión bloqueada por Google Cloud Armor?
  • ¿Hay virus o gravedad de software malicioso detectado por Cloud IDS?
  • ¿Cuáles son los dominios principales consultados de Cloud DNS desde su red de VPC?

Acceso y peguntas sobre el acceso

Estas consultas de muestra llevan a cabo análisis para detectar intentos de registro o acceso inicial sospechosos a tu entorno de Google Cloud.

Nota: La actividad de acceso se captura en los registros de Cloud Identity que se incluyen en la Auditoría de acceso de Google Workspace. Para analizar la actividad de acceso y usar algunas de las consultas de esta sección, debes habilitar el uso compartido de datos de Google Workspace con Google Cloud. Para obtener más información sobre cómo compartir los registros de auditoría de Google Workspace con Google Cloud, consulta Visualiza y administra los registros de auditoría de Google Workspace.

¿Hay algún intento de acceso sospechoso marcado por Google Workspace?

Mediante la búsqueda de registros de Cloud Identity que forman parte de la Auditoría de acceso de Google Workspace, la siguiente consulta detecta intentos de acceso sospechosos marcados por Google Workspace. Estos intentos de acceso pueden ser desde la consola de Google Cloud, la Consola del administrador de Google Workspace o la CLI de gcloud.

backends/bigquery/sql/1_02_suspicious_login_attempt.sql

Ver en GitHub

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.requestMetadata.callerIp,
  protopayload_auditlog.methodName
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`,
  UNNEST(JSON_QUERY_ARRAY(protopayload_auditlog.metadataJson, '$.event[0].parameter')) AS parameter
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
  AND protopayload_auditlog.metadataJson IS NOT NULL
  AND protopayload_auditlog.serviceName = "login.googleapis.com"
  AND protopayload_auditlog.methodName = "google.login.LoginService.loginSuccess"
  AND JSON_VALUE(parameter, '$.name') = "is_suspicious"
  AND JSON_VALUE(parameter, '$.boolValue') = "true"

¿Hay errores de acceso excesivos de cualquier identidad de usuario?

Mediante la búsqueda de registros de Cloud Identity que forman parte de la Auditoría de acceso de Google Workspace, la siguiente consulta detecta usuarios que tuvieron tres o más errores de acceso sucesivos en las últimas 24 horas.

backends/bigquery/sql/1_03_excessive_login_failures.sql

Ver en GitHub

SELECT
  protopayload_auditlog.authenticationInfo.principalEmail,
  MIN(timestamp) AS earliest,
  MAX(timestamp) AS latest,
  count(*) AS attempts
FROM
 `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  AND protopayload_auditlog.serviceName="login.googleapis.com"
  AND protopayload_auditlog.methodName="google.login.LoginService.LoginFailure"
GROUP BY
  1
HAVING
  attempts >= 3

¿Hay intentos de acceso que infrinjan los Controles del servicio de VPC?

En el análisis de los registros de auditoría de política denegada de Registros de auditoría de Cloud, la siguiente consulta detecta intentos de acceso bloqueados por los Controles del servicio de VPC. Cualquier resultado de consulta puede indicar una posible actividad maliciosa, como intentos de acceso de redes no autorizadas con credenciales robadas.

backends/bigquery/sql/1_10_access_attempts_blocked_by_VPC_SC.sql

Ver en GitHub

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.requestMetadata.callerIp,
  protopayload_auditlog.methodName,
  protopayload_auditlog.serviceName,
  JSON_VALUE(protopayload_auditlog.metadataJson, '$.violationReason') as violationReason,
  IF(JSON_VALUE(protopayload_auditlog.metadataJson, '$.ingressViolations') IS NULL, 'ingress', 'egress') AS violationType,
  COALESCE(
    JSON_VALUE(protopayload_auditlog.metadataJson, '$.ingressViolations[0].targetResource'),
    JSON_VALUE(protopayload_auditlog.metadataJson, '$.egressViolations[0].targetResource')
  ) AS  targetResource,
  COALESCE(
    JSON_VALUE(protopayload_auditlog.metadataJson, '$.ingressViolations[0].servicePerimeter'),
    JSON_VALUE(protopayload_auditlog.metadataJson, '$.egressViolations[0].servicePerimeter')
  ) AS  servicePerimeter
FROM
 `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_policy`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 400 DAY)
  AND JSON_VALUE(protopayload_auditlog.metadataJson, '$."@type"') = 'type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata'
ORDER BY
  timestamp DESC
LIMIT 1000

¿Hay algún intento de acceso que infrinja los controles de acceso de IAP?

Mediante el análisis de los registros de balanceo de cargas de HTTP(S), la siguiente consulta detecta los intentos de acceso que bloquea IAP. Cualquier resultado de consulta puede indicar un intento de acceso inicial o un intento de explotación de vulnerabilidades.

backends/bigquery/sql/1_20_access_attempts_blocked_by_IAP.sql

Ver en GitHub

SELECT
  timestamp,
  httpRequest.remoteIp,
  httpRequest.requestMethod,
  httpRequest.status,
  resource.labels.backend_service_name,
  httpRequest.requestUrl,
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].requests`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="http_load_balancer"
  AND jsonpayload_type_loadbalancerlogentry.statusdetails = "handled_by_identity_aware_proxy"
ORDER BY
  timestamp DESC

Preguntas sobre los cambios de permisos

Estas consultas de muestra realizan un análisis sobre la actividad de los administradores que cambia los permisos, como los cambios en las políticas de IAM, grupos y membresías de grupos, cuentas de servicio y cualquier clave asociada. Estos cambios en los permisos pueden proporcionar un alto nivel de acceso a entornos o datos sensibles.

Nota: Los cambios de grupo se recopilan en la Auditoría del administrador de Google Workspace. Para analizar la actividad de los cambios de grupo y usar algunas de las consultas de esta sección, debes habilitar el uso compartido de datos de Google Workspace con Google Cloud. Para obtener más información sobre cómo compartir los registros de auditoría de Google Workspace con Google Cloud, consulta Visualiza y administra los registros de auditoría de Google Workspace.

¿Se agregó algún usuario a grupos altamente privilegiados?

Mediante el análisis de los registros de auditoría de la Auditoría del administrador de Google Workspace, la siguiente consulta detecta usuarios que se agregaron a cualquiera de los grupos altamente privilegiados que se enumeran en la consulta. Usa la expresión regular en la consulta para definir qué grupos supervisar (como [e-mail] o [e-mail]). Cualquier resultado de consulta puede indicar una elevación de privilegios maliciosa o accidental.

backends/bigquery/sql/2_02_user_added_to_privileged_group.sql

Ver en GitHub

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.methodName,
  protopayload_auditlog.resourceName,
  (SELECT JSON_VALUE(x, '$.value')
   FROM UNNEST(JSON_QUERY_ARRAY(protopayload_auditlog.metadataJson, '$.event[0].parameter')) AS x
   WHERE JSON_VALUE(x, '$.name') = "USER_EMAIL") AS userEmail,
  (SELECT JSON_VALUE(x, '$.value')
   FROM UNNEST(JSON_QUERY_ARRAY(protopayload_auditlog.metadataJson, '$.event[0].parameter')) AS x
   WHERE JSON_VALUE(x, '$.name') = "GROUP_EMAIL") AS groupEmail,
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 120 DAY)
  AND protopayload_auditlog.serviceName = "admin.googleapis.com"
  AND protopayload_auditlog.methodName = "google.admin.AdminService.addGroupMember"
  AND EXISTS(
    SELECT * FROM UNNEST(JSON_QUERY_ARRAY(protopayload_auditlog.metadataJson, '$.event[0].parameter')) AS x
    WHERE
      JSON_VALUE(x, '$.name') = 'GROUP_EMAIL'
      AND REGEXP_CONTAINS(JSON_VALUE(x, '$.value'), r'[admin|prod].*') -- Update regexp with other sensitive groups if applicable
  )

¿Se otorgaron permisos en una cuenta de servicio?

Mediante el análisis de los registros de auditoría de la actividad del administrador de Registros de auditoría de Cloud, la siguiente consulta detecta cualquier permiso que se otorgaron a cualquier principal en una cuenta de servicio. Algunos ejemplos de permisos que se podrían otorgar son la capacidad de suplantar esa cuenta de servicio o crear claves de cuentas de servicio. Cualquier resultado de consulta puede indicar una instancia de elevación de privilegios o un riesgo de filtración de credenciales.

backends/bigquery/sql/2_20_permissions_granted_over_SA.sql

Ver en GitHub

SELECT
 timestamp,
 logName,
 protopayload_auditlog.authenticationInfo.principalEmail,
 protopayload_auditlog.methodName,
 protopayload_auditlog.resourceName,
 bindingDelta
FROM
 `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`,
  UNNEST(protopayload_auditlog.servicedata_v1_iam.policyDelta.bindingDeltas) AS bindingDelta
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 400 DAY)
  AND resource.type="service_account"
  AND protopayload_auditlog.methodName LIKE "google.iam.admin.%.SetIAMPolicy"
  AND bindingDelta.action = 'ADD'

¿Hay claves o cuentas de servicio creadas por una identidad no aprobada?

Mediante el análisis de los registros de auditoría de la actividad del administrador, la siguiente consulta detecta cualquier cuenta de servicio o clave que los usuarios crean de forma manual. Por ejemplo, puedes seguir una práctica recomendada para permitir que una cuenta de servicio aprobada cree cuentas de servicio como parte de un flujo de trabajo automatizado. Por lo tanto, cualquier creación de cuenta de servicio fuera de ese flujo de trabajo se considera incompatible y puede ser maliciosa.

backends/bigquery/sql/2_30_service_accounts_or_keys_created_by_non_approved_identity.sql

Ver en GitHub

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.methodName,
  protopayload_auditlog.resourceName,
  JSON_VALUE(protopayload_auditlog.responseJson, "$.email") as serviceAccountEmail
FROM
  `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 180 DAY)
  AND resource.type="service_account"
  AND protopayload_auditlog.methodName LIKE "%CreateServiceAccount%"
  AND protopayload_auditlog.authenticationInfo.principalEmail NOT LIKE "%.gserviceaccount.com"

¿Se agregó cualquier usuario a la política de IAM sensible (o se lo quitó de ella)?

Mediante la búsqueda de registros de auditoría de actividad del administrador, la siguiente consulta detecta cualquier cambio en el acceso de grupo o usuario para un recurso protegido con IAP, como un servicio de backend de Compute Engine. La siguiente consulta busca todas las actualizaciones de políticas de IAM para los recursos de IAP que involucran el rol de IAM roles/iap.httpsResourceAccessor. Este rol proporciona permisos para acceder al recurso HTTPS o al servicio de backend. Cualquier resultado de consulta puede indicar intentos de omitir las defensas de un servicio de backend que podría exponerse a Internet.

backends/bigquery/sql/2_40_user_access_modified_in_IAP.sql

Ver en GitHub

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail,
  resource.type,
  protopayload_auditlog.resourceName,
  JSON_VALUE(binding, '$.role') as role,
  JSON_VALUE_ARRAY(binding, '$.members') as members
FROM
  `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`,
  UNNEST(JSON_QUERY_ARRAY(protopayload_auditlog.responseJson, '$.bindings')) AS binding
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 400 DAY)
  AND protopayload_auditlog.serviceName = "iap.googleapis.com"
  AND protopayload_auditlog.methodName LIKE "%.IdentityAwareProxyAdminService.SetIamPolicy"
  AND JSON_VALUE(binding, '$.role') = "roles/iap.httpsResourceAccessor"
ORDER BY
  timestamp DESC

Preguntas sobre la actividad de aprovisionamiento

Estas consultas de muestra realizan análisis para detectar la actividad sospechosa o anómala del administrador, como el aprovisionamiento y la configuración de recursos.

¿Se realizaron cambios en la configuración de registro?

Mediante la búsqueda de registros de auditoría de actividad del administrador, la siguiente consulta detecta cualquier cambio que se realice en la configuración de registro. La supervisión de la configuración de registro te ayuda a detectar la inhabilitación accidental o maliciosa de los registros de auditoría y técnicas de evasión similares.

backends/bigquery/sql/3_01_logging_settings_modified.sql

Ver en GitHub

SELECT
  receiveTimestamp, timestamp AS eventTimestamp,
  protopayload_auditlog.requestMetadata.callerIp,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.resourceName,
  protopayload_auditlog.methodName
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
  protopayload_auditlog.serviceName = "logging.googleapis.com"

¿Los registros de flujo de VPC están inhabilitados de forma activa?

Mediante la búsqueda de registros de auditoría de actividad del administrador, la siguiente consulta detecta cualquier subred cuyos registros de flujo de VPC se hayan inhabilitado de forma activa. La supervisión de la configuración de los registros de flujo de VPC te ayuda a detectar la inhabilitación accidental o maliciosa de los registros de flujo de VPC y técnicas de evasión similares.

backends/bigquery/sql/3_02_vpc_flows_logging_disabled.sql

Ver en GitHub

SELECT
  receiveTimestamp, timestamp AS eventTimestamp,
  protopayload_auditlog.requestMetadata.callerIp,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.resourceName,
  protopayload_auditlog.methodName
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
protopayload_auditlog.methodName = "v1.compute.subnetworks.patch"
AND JSON_VALUE(protopayload_auditlog.requestJson, "$.logConfig.enable") = "false"

¿Hay una cantidad inusualmente alta de reglas de firewall modificadas en la última semana?

Mediante la búsqueda de los registros de auditoría de actividad del administrador, la siguiente consulta detecta una cantidad inusualmente alta de cambios en las reglas de firewall en un día determinado en la última semana. Para determinar si hay un valor atípico, la consulta realiza un análisis estadístico sobre los recuentos diarios de los cambios de las reglas de firewall. Los promedios y las desviaciones estándar se calculan para cada día si se observan los recuentos diarios anteriores con una ventana de visualización de 90 días. Se considera un valor atípico cuando el recuento diario supera las dos desviaciones estándar por encima de la media. La consulta, incluidos el factor de desviación estándar y los períodos de visualización, se pueden configurar para que se ajusten al perfil de actividad de aprovisionamiento en la nube y a minimizar los falsos positivos.

backends/bigquery/sql/3_11_unusual_number_of_firewall_rules_modified.sql

Ver en GitHub

SELECT
  *,
  AVG(counter) OVER (
    ORDER BY day
    ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS avg,
  STDDEV(counter) OVER (
    ORDER BY day
    ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS stddev,
  COUNT(*) OVER (
    RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS numSamples
FROM (
  SELECT
    EXTRACT(DATE FROM timestamp) AS day,
    ARRAY_AGG(DISTINCT protopayload_auditlog.methodName IGNORE NULLS) AS actions,
    ARRAY_AGG(DISTINCT protopayload_auditlog.authenticationInfo.principalEmail IGNORE NULLS) AS actors,
    COUNT(*) AS counter
  FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
  WHERE
    timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY)
    AND protopayload_auditlog.methodName LIKE "v1.compute.firewalls.%"
    AND protopayload_auditlog.methodName NOT IN ("v1.compute.firewalls.list", "v1.compute.firewalls.get")
  GROUP BY
    day
)
WHERE TRUE
QUALIFY
  counter > avg + 2 * stddev
  AND day >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
ORDER BY
  counter DESC

¿Se borró alguna de las VMs durante la última semana?

Mediante la búsqueda de registros de auditoría de actividad del administrador, en la siguiente consulta se muestra una lista de todas las instancias de Compute Engine borradas en la última semana. Esta consulta puede ayudarte a auditar las eliminaciones de recursos y detectar una posible actividad maliciosa.

backends/bigquery/sql/3_20_virtual_machines_deleted.sql

Ver en GitHub

SELECT
  timestamp,
  resource.labels.instance_id,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.resourceName,
  protopayload_auditlog.methodName
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
  resource.type = "gce_instance"
  AND protopayload_auditlog.methodName = "v1.compute.instances.delete"
  AND operation.first IS TRUE
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
ORDER BY
  timestamp desc,
  resource.labels.instance_id
LIMIT
  1000

Preguntas sobre el uso de la carga de trabajo

Estas consultas de muestra llevan a cabo un análisis para comprender quién y qué consumen tus cargas de trabajo y APIs en la nube, y te ayudan a detectar posibles comportamientos maliciosos de forma interna o externa.

¿Hay un uso de la API inusualmente alto por parte de cualquier identidad de usuario en la última semana?

Mediante el análisis de todos los registros de auditoría de Cloud, la siguiente consulta detecta un uso de la API inusualmente alto por parte de la identidad del usuario en un día determinado de la última semana. Este uso inusualmente alto puede ser un indicador de un posible abuso de la API, una amenaza de usuarios con información privilegiada o credenciales filtradas. Para determinar si hay un valor atípico, esta consulta realiza un análisis estadístico sobre el recuento diario de acciones por principal. Los promedios y las desviaciones estándar se calculan para cada día y principal si se observan los recuentos diarios anteriores con una ventana de visualización de 60 días. Se considera un valor atípico cuando el recuento diario de un usuario supera las tres desviaciones estándar por encima de su media. La consulta, en la que se incluyen el factor de desviación estándar y las ventanas de visualización, se puede configurar para que se ajuste al perfil de actividad de aprovisionamiento en la nube y minimice los falsos positivos.

backends/bigquery/sql/4_01_unusually_high_api_usage_by_user_identity.sql

Ver en GitHub

SELECT
  *,
  AVG(counter) OVER (
    PARTITION BY principalEmail
    ORDER BY day
    ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS avg,
  STDDEV(counter) OVER (
    PARTITION BY principalEmail
    ORDER BY day
    ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS stddev,
  COUNT(*) OVER (
    PARTITION BY principalEmail
    RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS numSamples
FROM (
  SELECT
    protopayload_auditlog.authenticationInfo.principalEmail,
    EXTRACT(DATE FROM timestamp) AS day,
    ARRAY_AGG(DISTINCT protopayload_auditlog.methodName IGNORE NULLS) AS actions,
    COUNT(*) AS counter
  FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_*`
  WHERE
    timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
    AND protopayload_auditlog.authenticationInfo.principalEmail IS NOT NULL
    AND protopayload_auditlog.methodName NOT LIKE "storage.%.get"
    AND protopayload_auditlog.methodName NOT LIKE "v1.compute.%.list"
    AND protopayload_auditlog.methodName NOT LIKE "beta.compute.%.list"
  GROUP BY
    protopayload_auditlog.authenticationInfo.principalEmail,
    day
)
WHERE TRUE
QUALIFY
  counter > avg + 3 * stddev
  AND day >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
ORDER BY
  counter DESC

¿Cuál es el uso de ajuste de escala automático por día en el último mes?

Mediante el análisis de los registros de auditoría de la actividad del administrador, la siguiente consulta informa el uso del ajuste de escala automático por día durante el último mes. Esta consulta se puede usar para identificar patrones o anomalías que justifiquen una investigación de seguridad adicional.

backends/bigquery/sql/4_11_autoscaling_usage_frequency_by_day.sql

Ver en GitHub

SELECT
  TIMESTAMP_TRUNC(timestamp, DAY) AS day,
  protopayload_auditlog.methodName AS methodName,
  COUNT(*) AS counter
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
  resource.type = "gce_instance_group_manager"
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  1, 2
ORDER BY
  1, 2

Preguntas sobre el acceso a los datos

Estas consultas de ejemplo realizan análisis para comprender quién accede a los datos o los modifica en Google Cloud.

¿Qué usuarios accedieron a los datos con mayor frecuencia en la última semana?

En la siguiente consulta, se usan los registros de auditoría de acceso a los datos para encontrar las identidades de los usuarios que accedieron con más frecuencia a los datos de tablas de BigQuery en la última semana.

backends/bigquery/sql/5_01_users_who_most_frequently_accessed_data.sql

Ver en GitHub

SELECT
  protopayload_auditlog.authenticationInfo.principalEmail,
  COUNT(*) AS COUNTER
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`
WHERE
  (protopayload_auditlog.methodName = "google.cloud.bigquery.v2.JobService.InsertJob" OR
   protopayload_auditlog.methodName = "google.cloud.bigquery.v2.JobService.Query")
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY
  1
ORDER BY
  2 desc, 1
LIMIT
  100

¿Qué usuarios accedieron a los datos de la tabla “accounts” en el último mes?

En la siguiente consulta, se usan los registros de auditoría de acceso a los datos para encontrar las identidades de los usuarios que más consultaron una tabla accounts en el último mes. Además de los marcadores de posición MY_DATASET_ID y MY_PROJECT_ID para tu destino de exportación de BigQuery, la siguiente consulta usa los marcadores de posición DATASET_ID y PROJECT_ID. Debes reemplazar los marcadores de posición DATASET_ID y PROJECT_ID para especificar la tabla de destino cuyo acceso se analiza, como la tabla accounts en este ejemplo.

backends/bigquery/sql/5_04_users_who_accessed_data_in_table.sql

Ver en GitHub

SELECT
  protopayload_auditlog.authenticationInfo.principalEmail,
  COUNT(*) AS COUNTER
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`,
  UNNEST(protopayload_auditlog.authorizationInfo) authorizationInfo
WHERE
  (protopayload_auditlog.methodName = "google.cloud.bigquery.v2.JobService.InsertJob" OR
   protopayload_auditlog.methodName = "google.cloud.bigquery.v2.JobService.Query")
  AND authorizationInfo.permission = "bigquery.tables.getData"
  AND authorizationInfo.resource = "projects/[PROJECT_ID]/datasets/[DATASET_ID]/tables/accounts"
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  1
ORDER BY
  2 desc, 1
LIMIT
  100

¿A qué tablas se accede con más frecuencia y quién accede a ellas?

En la siguiente consulta, se usan los registros de auditoría de acceso a los datos para encontrar las tablas de BigQuery que tienen los datos leídos y modificados con mayor frecuencia en el último mes. Muestra la identidad del usuario asociada junto con el desglose de la cantidad total de veces que se leyeron los datos, en comparación con los modificados.

backends/bigquery/sql/5_05_tables_most_frequently_accessed.sql

Ver en GitHub

SELECT
  protopayload_auditlog.resourceName,
  protopayload_auditlog.authenticationInfo.principalEmail,
  COUNTIF(JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.tableDataRead") IS NOT NULL) AS dataReadEvents,
  COUNTIF(JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.tableDataChange") IS NOT NULL) AS dataChangeEvents,
  COUNT(*) AS totalEvents
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`
WHERE
  STARTS_WITH(resource.type, 'bigquery') IS TRUE
  AND (JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.tableDataRead") IS NOT NULL
    OR JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.tableDataChange") IS NOT NULL)
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  1, 2
ORDER BY
  5 DESC, 1, 2
LIMIT 1000

¿Cuáles fueron las 10 consultas más realizadas en BigQuery en la última semana?

En la siguiente consulta, se usan los registros de auditoría de acceso a los datos para encontrar las consultas más comunes de la última semana. También se enumeran los usuarios correspondientes y las tablas referenciadas.

backends/bigquery/sql/5_06_BQ_queries_top.sql

Ver en GitHub

SELECT
  COALESCE(
   JSON_EXTRACT_SCALAR(protopayload_auditlog.metadataJson, "$.jobChange.job.jobConfig.queryConfig.query"),
   JSON_EXTRACT_SCALAR(protopayload_auditlog.metadataJson, "$.jobInsertion.job.jobConfig.queryConfig.query")) as query,
  STRING_AGG(DISTINCT protopayload_auditlog.authenticationInfo.principalEmail, ',') as users,
  ANY_VALUE(COALESCE(
   JSON_EXTRACT_ARRAY(protopayload_auditlog.metadataJson, "$.jobChange.job.jobStats.queryStats.referencedTables"),
   JSON_EXTRACT_ARRAY(protopayload_auditlog.metadataJson, "$.jobInsertion.job.jobStats.queryStats.referencedTables"))) as tables,
  COUNT(*) AS counter
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`
WHERE
  (resource.type = 'bigquery_project' OR resource.type = 'bigquery_dataset')
  AND operation.last IS TRUE
  AND (JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.jobChange") IS NOT NULL
    OR JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.jobInsertion") IS NOT NULL)
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY
  query
ORDER BY
  counter DESC
LIMIT 10

¿Cuáles son las acciones más comunes documentadas en los registros de acceso a los datos en el último mes?

En la siguiente consulta, se usan todos los registros de Registros de auditoría de Cloud para encontrar las 100 acciones más frecuentes registradas en el último mes.

backends/bigquery/sql/5_20_top_data_access_actions.sql

Ver en GitHub

SELECT
  ANY_VALUE(_TABLE_SUFFIX),
  protopayload_auditlog.methodName,
  protopayload_auditlog.serviceName,
  resource.type,
  COUNT(*) AS counter
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  protopayload_auditlog.methodName,
  protopayload_auditlog.serviceName,
  resource.type
ORDER BY
  counter DESC
LIMIT 100

Preguntas sobre seguridad de red

Estas consultas de muestra realizan análisis sobre la actividad de tu red en Google Cloud.

¿Hay alguna conexión desde una IP nueva a una subred específica?

La siguiente consulta detecta conexiones desde cualquier dirección IP de origen nueva a una subred determinada mediante el análisis de los registros de flujo de VPC. En este ejemplo, una dirección IP de origen se considera nueva si se vio por primera vez en las últimas 24 horas durante un período de visualización de 60 días. Es recomendable usar y ajustar esta consulta en una subred que esté dentro del alcance de un requisito de cumplimiento en particular, como PCI.

backends/bigquery/sql/6_10_connection_from_new_IP.sql

Ver en GitHub

SELECT
  jsonPayload.connection.src_ip as src_ip,
  MIN(TIMESTAMP(REGEXP_REPLACE(jsonPayload.start_time, r'\.(\d{0,6})\d+(Z)?$', '.\\1\\2'))) AS firstInstance, --- TIMESTAMP supports up to 6 digits of fractional precision, so drop any more digits to avoid parse errors
  MAX(TIMESTAMP(REGEXP_REPLACE(jsonPayload.start_time, r'\.(\d{0,6})\d+(Z)?$', '.\\1\\2'))) AS lastInstance,
  ARRAY_AGG(DISTINCT resource.labels.subnetwork_name) as subnetNames,
  ARRAY_AGG(DISTINCT jsonPayload.dest_instance.vm_name) as vmNames,
  COUNT(*) numSamples
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].compute_googleapis_com_vpc_flows`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
  AND jsonPayload.reporter = 'DEST'
  AND resource.labels.subnetwork_name IN ('prod-customer-data')
GROUP BY
  src_ip
HAVING firstInstance >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
ORDER BY
  lastInstance DESC,
  numSamples DESC

¿Hay alguna conexión bloqueada por Google Cloud Armor?

La siguiente consulta ayuda a detectar posibles intentos de vulnerabilidades mediante el análisis de los registros de balanceo de cargas de HTTP(S) para encontrar cualquier conexión bloqueada por la política de seguridad configurada en Google Cloud Armor. En esta consulta, se supone que tienes una política de seguridad de Google Cloud Armor configurada en el balanceo de cargas de HTTP(S). También se supone que habilitaste el registro de balanceo de cargas de HTTP(S) como se describe en las instrucciones que proporciona el vínculo Habilitar en la herramienta de permisos de registro.

backends/bigquery/sql/6_20_connections_blocked_by_cloud_armor.sql

Ver en GitHub

SELECT
  timestamp,
  httpRequest.remoteIp,
  httpRequest.requestMethod,
  httpRequest.status,jsonpayload_type_loadbalancerlogentry.enforcedsecuritypolicy.name,
  resource.labels.backend_service_name,
  httpRequest.requestUrl,
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].requests`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="http_load_balancer"
  AND jsonpayload_type_loadbalancerlogentry.statusdetails = "denied_by_security_policy"
ORDER BY
  timestamp DESC

¿Hay virus o gravedad de software malicioso detectado por Cloud IDS?

En la siguiente consulta, se muestra cualquier virus o software malicioso de alta gravedad que detecta IDS de Cloud mediante la búsqueda de los registros de amenazas de IDS de Cloud. En esta consulta, se supone que tienes un extremo de IDS de Cloud configurado.

backends/bigquery/sql/6_30_virus_or_malware_detected_by_cloud_IDS.sql

Ver en GitHub

SELECT
  jsonPayload.alert_time,
  jsonPayload.name,
  jsonPayload.details,
  jsonPayload.application,
  jsonPayload.uri_or_filename,
  jsonPayload.ip_protocol
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].ids_googleapis_com_threat`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="ids.googleapis.com/Endpoint"
  AND jsonPayload.alert_severity IN ("HIGH" OR "CRITICAL")
  AND jsonPayload.type = "virus"
ORDER BY
  timestamp DESC

¿Cuáles son los dominios principales consultados de Cloud DNS desde su red de VPC?

La siguiente consulta enumera los 10 dominios consultados de Cloud DNS principales de tus redes de VPC en los últimos 60 días. En esta consulta, se supone que habilitaste el registro de Cloud DNS para tus redes de VPC, como se describe en las instrucciones que proporciona el vínculo Habilitar en la herramienta de permisos de registro..

backends/bigquery/sql/6_40_DNS_top_queried_domains.sql

Ver en GitHub

SELECT
 jsonPayload.queryname,
 COUNT(jsonPayload.queryname) AS TotalQueries
FROM
 `[MY_PROJECT_ID].[MY_DATASET_ID].dns_googleapis_com_dns_queries`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
GROUP BY
 jsonPayload.queryname
ORDER BY
 TotalQueries DESC
LIMIT
 10

¿Qué sigue?

• Observa los otros casos de exportación:

  • Situación: exportación para satisfacer requisitos de cumplimiento.
  • Situación: exportación a Splunk.

• Transfiere registros de Google Cloud a Chronicle.

• Exporta datos de seguridad de Google Cloud a tu sistema SIEM.

• Explora arquitecturas de referencia, diagramas, instructivos y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.