Enruta entradas de registro

En este documento, se explica cómo Cloud Logging enruta las entradas de registro que recibe Trusted Cloud by S3NS. Existen varios tipos de destinos de enrutamiento. Por ejemplo, puedes enrutar entradas de registro a un destino, como un bucket de registros, que almacena entradas de registro. Si deseas exportar tus datos de registro a un destino de terceros, puedes enrutar las entradas de registro a Pub/Sub. Además, una entrada de registro se puede enrutar a varios destinos.

Información acerca de los routers de registros

Cada Trusted Cloud proyecto, cuenta de facturación, carpeta y organización tiene un enrutador de registros, que administra el flujo de entradas de registro a través de receptores a nivel de recursos. Un enrutador de registros también administra el flujo de una entrada de registro a través de los receptores que se encuentran en la jerarquía de recursos de la entrada. Los receptores controlan cómo se enrutan las entradas de registro a los destinos.

Un enrutador de registros almacena una entrada de registro de forma temporal. Este comportamiento amortigua las interrupciones y las fallas temporales que pueden ocurrir cuando una entrada de registro fluye a través de los receptores. El almacenamiento temporal no protege contra errores de configuración.

El almacenamiento temporal de un enrutador de registros es distinto del almacenamiento a mayor plazo que proporcionan los buckets de Logging.

Se descartan las entradas de registro entrantes con marcas de tiempo que son anteriores al período de retención de registros o que son posteriores a 24 horas.

Información acerca de los receptores de registros

Cuando un receptor de registros recibe una entrada de registro, determina si debe ignorarla o enrutarla. Para tomar esta decisión, se compara la entrada de registro con los filtros del receptor de registros. Cuando se enruta la entrada de registro, el receptor de registros la envía al destino que especifica el receptor de registros. Ese destino puede ser un proyecto, una ubicación de almacenamiento o un servicio.

Los receptores de registros pertenecen a un Trusted Cloud by S3NS recurso determinado: Trusted Cloud proyectos, cuentas de facturación, carpetas y organizaciones. Estos recursos también contienen varios destinos de registro. Cuando un recurso recibe una entrada de registro, cada receptor de registro de ese recurso la evalúa de forma independiente. Como resultado, varios destinos de registro pueden enrutar la misma entrada de registro.

De forma predeterminada, los datos de registro se almacenan en el proyecto en el que se originan. Sin embargo, existen varios motivos por los que tal vez quieras cambiar esta configuración:

  • Para centralizar el almacenamiento de tus datos de registro.
  • Para unir tus datos de registro con otros datos de la empresa.
  • Para organizar tus datos de registro de una manera que te resulte útil.
  • Para transmitir tus registros a otras aplicaciones, otros repositorios o a terceros Por ejemplo, te recomendamos que exportes tus registros desde Trusted Cloud by S3NS para que puedas verlos en una plataforma de terceros. Para exportar tus entradas de registro, crea un receptor de registro que las dirija a Pub/Sub.

Un receptor de registros mal configurado no enruta las entradas de registro. Cuando un receptor está mal configurado, se escriben entradas de registro que informan los detalles del error. Además, se envía un correo electrónico a los Contactos esenciales del recurso. Para obtener más información, consulta Soluciona problemas: Cómo ver errores.

Los receptores de registros no pueden enrutar entradas de registro de forma retroactiva. Es decir, un receptor de registros no puede enrutar una entrada de registro que se recibió antes de que se creara el receptor. Del mismo modo, si un receptor está mal configurado, solo enruta las entradas de registro que llegan después de que se resuelve el error de configuración.

Compatibilidad con organizaciones y carpetas

Para ayudarte a administrar los datos de registro de una organización o carpeta, puedes hacer lo siguiente:

  • Puedes crear receptores agregados, que enrutan las entradas de registro de una organización o carpeta y sus elementos secundarios al destino que especifica el receptor. Existen dos tipos de sumideros agregados:

    • Receptores agregados sin intercepción
    • Cómo interceptar receptores agregados

    La diferencia entre estos dos tipos de sumideros es que interceptar sumideros en un nivel de la jerarquía de recursos puede afectar el enrutamiento de los recursos más abajo en la jerarquía. Los sumideros que no interceptan no afectan el enrutamiento de otros recursos. Cuando un receptor de interceptación en un recurso coincide con una entrada de registro, esta entrada no se envía a los receptores de los recursos secundarios, con la excepción de que la entrada de registro siempre se envía al receptor de registro _Required en el recurso en el que se origina la entrada de registro.

  • Puedes configurar la configuración de recursos predeterminada para especificar la configuración del sumidero _Default creado por el sistema para recursos nuevos en una organización o carpeta. Por ejemplo, puedes usar esta configuración para inhabilitar el sumidero _Default o especificar los filtros en ese sumidero.

Ejemplos de enrutamiento

En esta sección, se ilustra cómo una entrada de registro que se origina en un proyecto podría fluir a través de los receptores en su jerarquía de recursos.

Ejemplo: No existen receptores agregados

Cuando no existen receptores agregados en la jerarquía de recursos de la entrada de registro, esta se envía a los receptores de registro del proyecto en el que se origina. Un receptor a nivel del proyecto enruta la entrada de registro al destino del receptor cuando la entrada de registro coincide con el filtro de inclusión del receptor, pero no coincide con ninguno de los filtros de exclusión del receptor.

Ejemplo: Existe un sumidero agregado que no intercepta

Supongamos que existe un receptor agregado que no intercepta en la jerarquía de recursos para una entrada de registro. Después de que el router de registros envía la entrada de registro al sumidero agregado que no intercepta, ocurre lo siguiente:

  1. El receptor agregado sin intercepción enruta la entrada de registro al destino del receptor cuando la entrada de registro coincide con el filtro de inclusión, pero no coincide con ningún filtro de exclusión.

  2. El Enrutador de registros envía la entrada de registro a los receptores de registros en el proyecto en el que se originó la entrada de registro.

    Un receptor a nivel del proyecto enruta la entrada de registro al destino del receptor cuando la entrada de registro coincide con el filtro de inclusión del receptor, pero no coincide con ninguno de los filtros de exclusión del receptor.

Ejemplo: Existe un sumidero agregado de intercepción

Supongamos que existe un receptor agregado de intercepción en la jerarquía de recursos de una entrada de registro. Después de que el router de registros envía la entrada de registro al sumidero agregado de intercepción, ocurre una de las siguientes situaciones:

  • La entrada de registro coincide con el filtro de inclusión, pero no con ningún filtro de exclusión:

    1. La entrada de registro se enruta al destino del receptor agregado de intercepción.
    2. La entrada de registro se envía al receptor _Required en el proyecto en el que se originó.

  • La entrada de registro no coincide con el filtro de inclusión o coincide con al menos un filtro de exclusión:

    1. El receptor agregado de interceptación no enruta la entrada de registro.

    2. El Enrutador de registros envía la entrada de registro a los receptores de registros en el proyecto en el que se originó la entrada de registro.

      Un receptor a nivel del proyecto enruta la entrada de registro al destino del receptor cuando la entrada de registro coincide con el filtro de inclusión del receptor, pero no coincide con ninguno de los filtros de exclusión del receptor.

Filtros de receptores de registros

Cada receptor de registro contiene un filtro de inclusión y puede contener varios filtros de exclusión. Estos filtros determinan si el receptor de registros enruta una entrada de registro al destino del receptor. Si no especificas ningún filtro, cada entrada de registro se enruta al destino del receptor.

Un sumidero de registros enruta una entrada de registro según estas reglas:

  • Si la entrada de registro no coincide con el filtro de inclusión, no se enruta. Cuando un receptor no especifica un filtro de inclusión, cada entrada de registro coincide con ese filtro.

  • Si la entrada de registro coincide con el filtro de inclusión y al menos un filtro de exclusión, no se enruta.

  • Si la entrada de registro coincide con el filtro de inclusión y no coincide con ningún filtro de exclusión, se enruta al destino del receptor.

Los filtros de un destino de registro se especifican con el lenguaje de consulta de Logging.

No puedes usar filtros de exclusión para reducir el consumo de tu cuota de la API de entries.write ni la cantidad de llamadas a la API de entries.write. Los filtros de exclusión se aplican después de que la API de Logging recibe las entradas de registro.

Receptores de registro creados por el sistema

Para cada Trusted Cloud proyecto, cuenta de facturación, carpeta y organización, Cloud Logging crea dos receptores de registros, uno llamado _Required y el otro llamado _Default. Los filtros de inclusión y exclusión de estos receptores garantizan que cada entrada de registro que llega al recurso se enrute a través de uno de estos receptores. Ambos destinos enrutan los datos de registro a un bucket de registros que se encuentra en el mismo recurso que el destino de registro.

En el resto de esta sección, se proporciona información sobre los filtros y los destinos de los sumideros de registros creados por el sistema.

Receptor de registros _Required

El receptor de registros _Required en un recurso enruta un subconjunto de registros de auditoría al bucket de registros _Required del recurso. Este receptor no especifica ningún filtro de exclusión, y el filtro de inclusión es el siguiente:

LOG_ID("cloudaudit.googleapis.com/activity") OR
LOG_ID("externalaudit.googleapis.com/activity") OR
LOG_ID("cloudaudit.googleapis.com/system_event") OR
LOG_ID("externalaudit.googleapis.com/system_event") OR
LOG_ID("cloudaudit.googleapis.com/access_transparency") OR
LOG_ID("externalaudit.googleapis.com/access_transparency")

El receptor de registros _Required solo coincide con las entradas de registro que se originan en el recurso en el que se define el receptor de registros _Required. Por ejemplo, supongamos que un receptor de registros enruta una entrada de registro de actividad del proyecto A al proyecto B. Como la entrada de registro no se originó en el proyecto B, el sink de registro _Required en el proyecto B no enruta esta entrada de registro al bucket de registros _Required.

No puedes modificar ni borrar el receptor de registros _Required.

Receptor de registros _Default

El receptor de registros _Default de un recurso enruta todas las entradas de registro, excepto aquellas que coinciden con el filtro del receptor de registros _Required, al bucket de registros _Default del recurso. Como el filtro de inclusión de este receptor está vacío, coincide con todas las entradas de registro. Sin embargo, el filtro de exclusión se configura de la siguiente manera:

NOT LOG_ID("cloudaudit.googleapis.com/activity") AND
NOT LOG_ID("externalaudit.googleapis.com/activity") AND
NOT LOG_ID("cloudaudit.googleapis.com/system_event") AND
NOT LOG_ID("externalaudit.googleapis.com/system_event") AND
NOT LOG_ID("cloudaudit.googleapis.com/access_transparency") AND
NOT LOG_ID("externalaudit.googleapis.com/access_transparency")

Puedes modificar y, luego, inhabilitar el receptor de registros _Default. Por ejemplo, puedes editar el sumidero de registros _Default y cambiar el destino. También puedes modificar cualquier filtro existente y agregar filtros de exclusión.

Destinos del receptor

El destino de un receptor puede estar en un recurso diferente al receptor. Por ejemplo, puedes usar un destino de registro para enrutar entradas de registro de un proyecto a un bucket de registros almacenado en un proyecto diferente.

Se admiten los siguientes destinos:

Trusted Cloud proyecto

Selecciona este destino cuando desees que los receptores de registros del proyecto de destino vuelvan a enrutar tus entradas de registro o cuando hayas creado un receptor agregado de intercepción. Los sinks de registro en el proyecto que es el destino del sink pueden redireccionar las entradas de registro a cualquier destino compatible, excepto a un proyecto.

Bucket de registros
Selecciona este destino cuando quieras almacenar tus datos de registro en los recursos que administra Cloud Logging. Los datos de registro almacenados en buckets de registro pueden visualizarse y analizarse con servicios como el Explorador de registros.
Tema de Pub/Sub
Selecciona este destino cuando quieras exportar tus datos de registro desdeTrusted Cloud by S3NS y, luego, usa una integración de terceros. Las entradas de registro se formatean en JSON y, luego, se enrutan a un tema de Pub/Sub.

Limitaciones de destino

En esta sección, se describen las limitaciones específicas de cada destino:

  • Se aplican las siguientes limitaciones cuando el destino de un receptor de registros es un proyecto Trusted Cloud :

    • Hay un límite de un salto.
    • Las entradas de registro que coinciden con el filtro del receptor de registros _Required solo se enrutan al bucket de registros _Required del proyecto de destino cuando se originan en el proyecto de destino.
    • Solo los receptores agregados que se encuentran en la jerarquía de recursos de una entrada de registro la procesan.

    Por ejemplo, supongamos que el destino de un receptor de registros en el proyecto A es el proyecto B. Entonces, se cumple lo siguiente:

    • Debido al límite de un salto, los destinos de registro del proyecto B no pueden redireccionar las entradas de registro a un proyecto Trusted Cloud .
    • El bucket de registros _Required del proyecto B solo almacena entradas de registro que se originan en el proyecto B. Este bucket de registros no almacena ninguna entrada de registro que se origine en ningún otro recurso, incluidos los que se originan en el proyecto A.
    • Si la jerarquía de recursos del proyecto A y del proyecto B difieren, una entrada de registro que un destino de registro en el proyecto A enruta al proyecto B no se envía a los destinos agregados en la jerarquía de recursos del proyecto B.
    • Si el proyecto A y el proyecto B tienen la misma jerarquía de recursos, las entradas de registro se envían a los sumideros agregados en esa jerarquía. Si un receptor agregado no intercepta una entrada de registro, el router de registros la envía a los receptores del proyecto A.

Prácticas recomendadas

Para obtener prácticas recomendadas sobre el uso del enrutamiento para la gobernanza de datos o para casos de uso comunes, consulta los siguientes documentos:

Ejemplos: Centraliza el almacenamiento de registros

En esta sección, se describe cómo puedes configurar el almacenamiento centralizado. El almacenamiento centralizado proporciona un solo lugar para consultar los datos de registro, lo que simplifica tus consultas cuando buscas tendencias o investigas problemas. Desde una perspectiva de seguridad, también tienes una ubicación de almacenamiento, lo que puede simplificar las tareas de tus analistas de seguridad.

Centraliza el almacenamiento de registros de los proyectos en una carpeta

Supongamos que administras una carpeta y quieres centralizar el almacenamiento de tus entradas de registro. Para este caso de uso, puedes hacer lo siguiente:

  1. En tu carpeta, crea un proyecto llamado CentralStorage.
  2. Crea un receptor agregado de intercepción para tu carpeta y configúralo para que enrute todas las entradas de registro. Estableces el destino del receptor como el proyecto llamado CentralStorage.

Cuando llega una entrada de registro que se origina en la carpeta o en uno de sus recursos secundarios, esa entrada de registro se envía al receptor agregado de intercepción que creaste. Ese receptor enruta las entradas de registro al proyecto llamado CentralStorage. Los receptores de registros de este proyecto procesan las entradas de registro:

  • El receptor de registros _Default enruta al bucket de registros _Default todas las entradas de registro que coincidan con el filtro del receptor. Este bucket de registros es tu ubicación de almacenamiento centralizada.

  • El receptor de registros _Required enruta al bucket de registros _Required las entradas de registro que coinciden con los filtros del receptor y que se originan en el proyecto CentralStorage. Este bucket de registros no es una ubicación de almacenamiento centralizada. Sin embargo, puedes almacenar de forma centralizada todos los datos de registro. Para ver un ejemplo, consulta Cómo almacenar registros de auditoría en una ubicación central.

Una vez que se completa el procesamiento del receptor agregado, la entrada de registro se envía al receptor de registros _Required en el recurso en el que se originó la entrada de registro. Cuando la entrada de registro coincide con el filtro en el receptor de registros _Required, se enruta al bucket de registros _Required del recurso. En consecuencia, cada Trusted Cloud proyecto de tu carpeta almacena entradas de registro en su bucket de registros _Required.

Centraliza el almacenamiento de registros para un conjunto de proyectos

También puedes almacenar entradas de registro en una sola ubicación cuando no tienes una organización o una carpeta. Por ejemplo, puedes hacer lo siguiente:

  1. Crea un proyecto llamado CentralStorage.
  2. Para cada proyecto, excepto CentralStorage, debes editar el sumidero de registros _Default y configurar el destino como el proyecto llamado CentralStorage.

Es posible que te preguntes por qué en el ejemplo anterior se establece el destino de los puntos de vertido de registros _Default como un proyecto, en lugar del bucket de registros _Default en ese proyecto. Las razones principales son la simplicidad y la coherencia. Cuando enrutas entradas de registro a un proyecto, los receptores de registros en el proyecto de destino controlan qué entradas de registro se almacenan y dónde. Es decir, centralizas la funcionalidad del filtro y el destino. Si quieres cambiar qué entradas de registro se almacenan o dónde se almacenan, solo debes modificar los destinos de registro en un proyecto.

Centraliza el almacenamiento de registros de auditoría

Puedes almacenar de forma centralizada las entradas de registro que coincidan con el receptor de registros _Required. Si deseas almacenar estas entradas de registro de forma centralizada, haz una de las siguientes acciones:

  • Crea receptores de registros que enruten las entradas de registro que coincidan con el receptor de registros _Required a un bucket de registros centralizado.

  • Configura los receptores de registros como en los dos ejemplos anteriores y, luego, agrega un receptor de registros en el proyecto de destino que enrute las entradas de registro que coincidan con el receptor de registros _Required a un bucket de registros. También puedes editar los filtros en el destino de registro _Default.

Antes de implementar una estrategia de este tipo, revisa los lineamientos de precios.

¿Qué sigue?

Para ayudarte a enrutar y almacenar datos de Cloud Logging, consulta los siguientes documentos: