Entradas do registo de rotas

Este documento explica como o Cloud Logging encaminha as entradas de registo que são recebidas por Trusted Cloud by S3NS. Existem vários tipos diferentes de destinos de encaminhamento. Por exemplo, pode encaminhar as entradas de registo para um destino, como um contentor de registos, que armazena as entradas de registo. Se quiser exportar os dados de registos para um destino de terceiros, pode encaminhar as entradas de registos para o Pub/Sub. Além disso, uma entrada de registo pode ser encaminhada para vários destinos.

Acerca dos routers de registos

Cada Trusted Cloud projeto, conta de faturação, pasta e organização tem um Log Router, que gere o fluxo de entradas de registo através de destinos ao nível do recurso. Um Log Router também gere o fluxo de uma entrada do registo através de destinos que se encontram na hierarquia de recursos da entrada. Os destinos controlam a forma como as entradas de registo são encaminhadas para os destinos.

Um Log Router armazena uma entrada de registo temporariamente. Este comportamento protege contra interrupções temporárias e indisponibilidades que podem ocorrer quando uma entrada de registo flui através de destinos. O armazenamento temporário não protege contra erros de configuração.

O armazenamento temporário do Log Router é diferente do armazenamento a longo prazo fornecido pelos contentores de registos.

As entradas de registo recebidas com indicações de tempo que sejam anteriores ao período de retenção de registos ou que sejam posteriores a 24 horas são rejeitadas.

Acerca dos sinks de registo

Quando um destino de registo recebe uma entrada de registo, determina se deve ignorar ou encaminhar a entrada de registo. Esta decisão é tomada comparando a entrada do registo com os filtros no destino do registo. Quando a entrada do registo é encaminhada, o destino do registo envia a entrada do registo para o destino especificado pelo destino do registo. Esse destino pode ser um projeto, uma localização de armazenamento ou um serviço.

Os destinos de registo pertencem a um determinado Trusted Cloud by S3NS recurso: Trusted Cloud projetos, contas de faturação, pastas e organizações. Estes recursos também contêm vários destinos de registo. Quando um recurso recebe uma entrada de registo, cada destino de registo nesse recurso avalia independentemente a entrada de registo. Consequentemente, vários destinos de registo podem encaminhar a mesma entrada de registo.

Por predefinição, os dados de registo são armazenados no projeto onde os dados têm origem. No entanto, existem vários motivos pelos quais pode querer alterar esta configuração:

  • Para centralizar o armazenamento dos dados de registo.
  • Para juntar os dados de registo com outros dados empresariais.
  • Para organizar os dados de registo de uma forma útil para si.
  • Para transmitir os seus registos para outras aplicações, outros repositórios ou terceiros. Por exemplo, pode querer exportar os seus registos do Trusted Cloud by S3NS para os poder ver numa plataforma de terceiros. Para exportar as entradas de registo, crie um destino de registo que encaminhe as entradas de registo para o Pub/Sub.

Um sink de registo configurado incorretamente não encaminha as entradas de registo. Quando um destino está configurado incorretamente, são escritas entradas de registo que comunicam os detalhes do erro. Além disso, é enviado um email para os contactos essenciais do recurso. Para mais informações, consulte o artigo Resolução de problemas: ver erros.

Os destinos de registos não podem encaminhar retroativamente entradas de registos. Ou seja, um destino de registo não pode encaminhar uma entrada de registo que foi recebida antes de o destino ter sido criado. Da mesma forma, se um destino estiver configurado incorretamente, encaminha apenas as entradas de registo que chegam depois de o erro de configuração ser resolvido.

Suporte para organizações e pastas

Para ajudar a gerir os dados de registo numa organização ou pasta, pode fazer o seguinte:

  • Pode criar destinos agregados, que encaminham as entradas de registo de uma organização ou uma pasta e respetivos filhos para o destino especificado pelo destino. Existem dois tipos de destinos agregados:

    • Destinos agregados sem interceção
    • Intercetar destinos agregados

    A diferença entre estes dois tipos de destinos é que os destinos de interceção num nível da hierarquia de recursos podem afetar o encaminhamento de recursos num nível inferior da hierarquia. Os destinos não intercetores não afetam o encaminhamento de outros recursos. Quando um filtro de interceção num recurso corresponde a uma entrada de registo, a entrada de registo não é enviada para os filtros nos recursos secundários, com a exceção de que a entrada de registo é sempre enviada para o filtro de registo _Required no recurso onde a entrada de registo tem origem.

  • Pode configurar as predefinições de recursos para especificar a configuração do destino _Default criado pelo sistema para novos recursos numa organização ou numa pasta. Por exemplo, pode usar estas definições para desativar o destino _Default ou especificar os filtros nesse destino.

Exemplos de encaminhamento

Esta secção ilustra como uma entrada de registo originada num projeto pode fluir através dos destinos na respetiva hierarquia de recursos.

Exemplo: não existem destinos agregados

Quando não existem destinos agregados na hierarquia de recursos da entrada de registo, a entrada de registo é enviada para os destinos de registo no projeto de onde a entrada de registo é originária. Um sink ao nível do projeto encaminha a entrada de registo para o destino do sink quando a entrada de registo corresponde ao filtro de inclusão do sink, mas não corresponde a nenhum dos filtros de exclusão do sink.

Exemplo: existe um ponto de recolha agregado não intercetor

Suponha que existe um destino agregado sem interceção na hierarquia de recursos para uma entrada de registo. Depois de o Log Router enviar a entrada do registo para o destino agregado não intercetor, ocorre o seguinte:

  1. O sink agregado não intercetor encaminha a entrada do registo para o destino do sink quando a entrada do registo corresponde ao filtro de inclusão, mas não corresponde a nenhum filtro de exclusão.

  2. O Log Router envia a entrada do registo para os destinos de registo no projeto onde a entrada do registo teve origem.

    Um sink ao nível do projeto encaminha a entrada de registo para o destino do sink quando a entrada de registo corresponde ao filtro de inclusão do sink, mas não corresponde a nenhum dos filtros de exclusão do sink.

Exemplo: existe um destino agregado de interceção

Suponha que existe um destino agregado de interceção na hierarquia de recursos para uma entrada de registo. Depois de o Log Router enviar a entrada do registo para o destino agregado de interceção, ocorre uma das seguintes situações:

  • A entrada do registo corresponde ao filtro de inclusão, mas não corresponde a nenhum filtro de exclusão:

    1. A entrada de registo é encaminhada para o destino do sink agregado de interceção.
    2. A entrada de registo é enviada para o destino _Required no projeto onde a entrada de registo foi criada.

  • A entrada do registo não corresponde ao filtro de inclusão ou corresponde a, pelo menos, um filtro de exclusão:

    1. A entrada do registo não é encaminhada pelo destino agregado de interceção.

    2. O Log Router envia a entrada do registo para os destinos de registo no projeto onde a entrada do registo teve origem.

      Um sink ao nível do projeto encaminha a entrada de registo para o destino do sink quando a entrada de registo corresponde ao filtro de inclusão do sink, mas não corresponde a nenhum dos filtros de exclusão do sink.

Filtros de sinks de registo

Cada destino de registo contém um filtro de inclusão e pode conter vários filtros de exclusão. Estes filtros determinam se o destino do coletor recebe uma entrada de registo. Se não especificar filtros, todas as entradas de registo são encaminhadas para o destino do coletor.

Uma entrada de registo é encaminhada por um destino de registo com base nestas regras:

  • Se a entrada do registo não corresponder ao filtro de inclusão, não é encaminhada. Quando um destino não especifica um filtro de inclusão, todas as entradas de registo correspondem a esse filtro.

  • Se a entrada do registo corresponder ao filtro de inclusão e, pelo menos, a um filtro de exclusão, não é encaminhada.

  • Se a entrada do registo corresponder ao filtro de inclusão e não corresponder a nenhum filtro de exclusão, é encaminhada para o destino do coletor.

Os filtros num destino do registo são especificados através da linguagem de consulta de registo.

Não pode usar filtros de exclusão para reduzir o consumo da sua entries.write quota da API nem o número de entries.write chamadas da API. Os filtros de exclusão são aplicados depois de as entradas de registo serem recebidas pela API Logging.

Sinks de registo criados pelo sistema

Para cada Trusted Cloud projeto, conta de faturação, pasta e organização, o Cloud Logging cria dois destinos de registo, um denominado _Required e o outro denominado _Default. Os filtros de inclusão e exclusão para estes destinos verificam se cada entrada de registo que atinge o recurso é encaminhada por um destes destinos. Ambos os destinos encaminham os dados de registo para um contentor de registos que se encontra no mesmo recurso que o destino de registos.

O resto desta secção fornece informações sobre os filtros e os destinos dos contentores de registos criados pelo sistema.

_Required sink de registo

O _Required sink de registo num recurso encaminha um subconjunto de registos de auditoria para o _Required contentor de registos do recurso. Este destino não especifica filtros de exclusão e o filtro de inclusão é o seguinte:

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")

O destino de registo _Required só corresponde a entradas de registo originárias do recurso onde o destino de registo _Required está definido. Por exemplo, suponhamos que um destino de registo encaminha uma entrada do registo de atividade do projeto A para o projeto B. Uma vez que a entrada de registo não teve origem no projeto B, o destino de registo _Required no projeto B não encaminha esta entrada de registo para o contentor de registos _Required.

Não pode modificar nem eliminar o destino de registo _Required.

_Default sink de registo

O destino de registo _Default num recurso encaminha todas as entradas de registo, exceto as que correspondem ao filtro do destino de registo _Required, para o contentor de registos _Default do recurso. Uma vez que o filtro de inclusão para este destino está vazio, corresponde a todas as entradas de registo. No entanto, o filtro de exclusão está configurado da seguinte forma:

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")

Pode modificar e desativar o destino de registo _Default. Por exemplo, pode editar o destino do registo _Default e alterá-lo. Também pode modificar qualquer filtro existente e adicionar filtros de exclusão.

Destinos de sincronização

O destino de um coletor pode estar num recurso diferente do coletor. Por exemplo, pode usar um destino de registo para encaminhar entradas de registo de um projeto para um contentor de registo armazenado num projeto diferente.

Os seguintes destinos são suportados:

Trusted Cloud projeto

Selecione este destino quando quiser que os destinos de registo no projeto de destino reencaminhem as suas entradas de registo ou quando tiver criado um destino agregado de interceção. Os sinks de registo no projeto que é o destino do sink podem reencaminhar as entradas de registo para qualquer destino suportado, exceto um projeto.

Contentor de registo
Selecione este destino quando quiser armazenar os seus dados de registo em recursos geridos pelo Cloud Logging. Os dados de registo armazenados em contentores de registos podem ser vistos e analisados através de serviços como o Explorador de registos.
Tópico do Pub/Sub
Selecione este destino quando quiser exportar os dados de registo do Trusted Cloud by S3NS e, em seguida, usar uma integração de terceiros. As entradas de registo são formatadas em JSON e, em seguida, encaminhadas para um tópico do Pub/Sub.

Limitações de destinos

Esta secção descreve as limitações específicas do destino:

  • Aplicam-se as seguintes limitações quando o destino de um coletor de registos é um Trusted Cloud projeto:

    • Existe um limite de um salto.
    • As entradas de registo que correspondem ao filtro do _Required sink de registo só são encaminhadas para o contentor de registos _Required do projeto de destino quando têm origem no projeto de destino.
    • Apenas os destinos agregados que se encontram na hierarquia de recursos de uma entrada de registo processam a entrada de registo.

    Por exemplo, suponha que o destino de um coletor de registos no projeto A é o projeto B. Então, as seguintes afirmações são verdadeiras:

    • Devido ao limite de um salto, os destinos de registo no projeto B não podem reencaminhar entradas de registo para um projeto Trusted Cloud .
    • O contentor de registos _Required do projeto B apenas armazena entradas de registo que têm origem no projeto B. Este contentor de registos não armazena entradas de registo originárias de outros recursos, incluindo as originárias do projeto A.
    • Se a hierarquia de recursos do projeto A e do projeto B for diferente, então uma entrada de registo que um destino de registo no projeto A encaminha para o projeto B não é enviada para os destinos agregados na hierarquia de recursos do projeto B.
    • Se o projeto A e o projeto B tiverem a mesma hierarquia de recursos, as entradas de registo são enviadas para os destinos agregados nessa hierarquia. Se uma entrada de registo não for intercetada por um sink agregado, o Router de registos envia a entrada de registo para os sinks no projeto A.

Práticas recomendadas

Para ver práticas recomendadas sobre a utilização do encaminhamento para a gestão de dados ou para exemplos de utilização comuns, consulte os seguintes documentos:

Exemplos: centralize o armazenamento de registos

Esta secção descreve como pode configurar o armazenamento centralizado. O armazenamento centralizado oferece um único local para consultar dados de registo, o que simplifica as suas consultas quando está a pesquisar tendências ou a investigar problemas. Do ponto de vista da segurança, também tem uma localização de armazenamento, o que pode simplificar as tarefas dos seus analistas de segurança.

Se centralizar o armazenamento de registos, considere se deve colocar um ónus no projeto que armazena os dados de registo. Um bloqueio pode impedir a eliminação acidental de um projeto. Para saber mais, consulte o artigo Proteger projetos com hipotecas.

Centralize o armazenamento de registos de projetos numa pasta

Suponhamos que gere uma pasta e quer centralizar o armazenamento das suas entradas de registo. Para este exemplo de utilização, pode fazer o seguinte:

  1. Na pasta, cria um projeto com o nome CentralStorage.
  2. Crie um sink agregado de interceção para a sua pasta e configure-o para encaminhar todas as entradas de registo. Define o destino do coletor como o projeto com o nome CentralStorage.

Quando chega uma entrada de registo originária da pasta ou de um dos respetivos recursos subordinados, essa entrada de registo é enviada para o destino agregado de interceção que criou. Esse destino encaminha as entradas do registo para o projeto com o nome CentralStorage. Os sinks de registo neste projeto processam as entradas do registo:

  • O _Default destino de registo encaminha para o _Default contentor de registos todas as entradas de registo que correspondem ao filtro do destino. Este contentor de registos é a sua localização de armazenamento centralizada.

  • O _Required destino de registos encaminha para o _Required contentor de registos as entradas de registos que correspondem aos filtros do destino e que têm origem no projeto CentralStorage. Este contentor de registos não é uma localização de armazenamento centralizada. No entanto, pode armazenar centralmente todos os seus dados de registo. Para ver um exemplo, consulte o artigo Armazene registos de auditoria numa localização central.

Após a conclusão do processamento do destino agregado, a entrada de registo é enviada para o destino de registo _Required no recurso no qual a entrada de registo teve origem. Quando a entrada do registo corresponde ao filtro no sink de registo _Required, a entrada do registo é encaminhada para o contentor de registos _Required do recurso. Consequentemente, cada Trusted Cloud projeto na sua pasta armazena entradas de registo no respetivo contentor de registos _Required.

Centralize o armazenamento de registos para um conjunto de projetos

Também pode armazenar entradas de registo numa única localização quando não tem uma organização nem uma pasta. Por exemplo, pode fazer o seguinte:

  1. Crie um projeto com o nome CentralStorage.
  2. Para cada projeto, exceto CentralStorage, edite o sink de registo _Default e defina o destino como o projeto denominado CentralStorage.

Pode perguntar-se por que motivo o exemplo anterior define o destino dos _Default coletores de registos como um projeto, em vez do _Default contentor de registos nesse projeto. Os principais motivos são a simplicidade e a consistência. Quando encaminha entradas de registo para um projeto, os destinos de registo no projeto de destino controlam que entradas de registo são armazenadas e onde são armazenadas. Ou seja, centraliza a funcionalidade de filtro e destino. Se quiser alterar as entradas de registo armazenadas ou onde são armazenadas, só tem de modificar os destinos de registo num projeto.

Centralize o armazenamento de registos de auditoria

Pode armazenar centralmente entradas de registo que correspondam ao _Required destino do registo. Se quiser armazenar estas entradas do registo centralmente, faça uma das seguintes ações:

  • Crie destinos de registo que encaminham as entradas de registo que correspondem ao destino de registo _Required para um contentor de registo centralizado.

  • Configure os sinks de registo como nos dois exemplos anteriores e, em seguida, adicione um sink de registo no projeto de destino que encaminhe as entradas de registo que correspondam ao sink de registo _Required para um contentor de registos. Também pode editar os filtros no destino de registo _Default.

Antes de implementar uma estratégia deste tipo, reveja as diretrizes de preços.

O que se segue?

Para ajudar a encaminhar e armazenar dados do Cloud Logging, consulte os seguintes documentos: