Análise de registros de segurança em Google Cloud

Last reviewed 2024-05-21 UTC

Neste guia, profissionais de segurança sabem como integrar os registros do Google Cloud a serem usados em análises de segurança. Ao realizar análises de segurança, você ajuda sua organização a evitar, detectar e responder a ameaças como malware, phishing, ransomware e recursos mal configurados.

Neste guia, você aprende as seguintes ações com relação à verificação de tempo de atividade:

• Ative os registros a serem analisados.
• Encaminhe esses registros para um único destino, dependendo da opção de ferramenta de análise de segurança, como Log Analytics, BigQuery, Google Security Operations ou uma tecnologia de gerenciamento de eventos e informações de segurança (SIEM, na sigla em inglês) de terceiros.
• Analise esses registros para auditar o uso da nuvem e detectar possíveis ameaças nos seus dados e cargas de trabalho, usando consultas de amostra do projeto Community Security Analytics (CSA).

As informações neste guia fazem parte das Google Cloud Operações de Segurança Autônoma, que incluem transformação orientada por engenharia de práticas de detecção e resposta, além de análises de segurança para melhorar os recursos de detecção de ameaças.

Neste guia, os registros fornecem a fonte de dados a ser analisada. No entanto, é possível aplicar os conceitos deste guia à análise de outros dados complementares relacionados à segurança do Google Cloud, como descobertas de segurança do Security Command Center. No Security Command Center Premium, há uma lista de detectores gerenciados atualizados regularmente, projetadas para identificar ameaças, vulnerabilidades e configurações incorretas nos sistemas quase em tempo real. Ao analisar esses indicadores do Security Command Center e correlacioná-los aos registros ingeridos na sua ferramenta de análise de segurança, conforme descrito neste guia, é possível ter uma perspectiva mais ampla sobre possíveis ameaças de segurança.

O diagrama a seguir mostra como as fontes de dados de segurança, as ferramentas de análise de segurança e as consultas de CSA funcionam juntas.

O diagrama começa com as seguintes fontes de dados de segurança: registros do Cloud Logging, alterações de recursos do Inventário de recursos do Cloud e descobertas de segurança do Security Command Center. O diagrama mostra as origens de dados de segurança que são roteadas para a ferramenta de análise de segurança escolhida: análise de registros no Cloud Logging, BigQuery, Google Security Operations ou um SIEM de terceiros. Por fim, o diagrama mostra o uso de consultas de CSA com sua ferramenta de análise para analisar os dados de segurança agrupados.

Fluxo de trabalho de análise de registros de segurança

Nesta seção, descrevemos as etapas para configurar a análise de registros de segurança no Google Cloud. O fluxo de trabalho consiste nas três etapas mostradas no diagrama a seguir e descritas nos parágrafos a seguir:

• Ativar registros:há vários registros de segurança disponíveis no Google Cloud. Cada registro tem informações diferentes que podem ser úteis para responder a perguntas específicas sobre segurança. Alguns registros, como os registros de auditoria do Cloud, são ativados por padrão. Outros precisam ser ativados manualmente, porque geram custos adicionais de ingestão no Cloud Logging. Portanto, a primeira etapa no fluxo de trabalho é priorizar os registros de segurança mais relevantes para as necessidades de análise de segurança e ativar esses registros específicos individualmente.

  Para ajudar a avaliar os registros em termos de visibilidade e detecção de ameaças, este guia inclui uma ferramenta de escopo de registros. Essa ferramenta mapeia cada registro para táticas e técnicas de ameaça relevantes na matriz MITRE ATT&CK® para empresas. A ferramenta também mapeia regras de detecção de ameaças a eventos no Security Command Center para os registros em que elas dependem. Use a ferramenta de escopo de registro para avaliar registros, seja qual for a ferramenta de análise usada.

• Registros de rota:depois de identificar e ativar os registros para análise, a próxima etapa é rotear e agregar os registros da sua organização, incluindo pastas, projetos e contas de faturamento contidos (em inglês). A maneira como você exporta os registros depende da ferramenta de análise usada.

  Neste guia, descrevemos destinos comuns de roteamento de registros e mostramos como usar um coletor agregado do Cloud Logging para rotear registros da organização para um bucket de registros{/3. } ou um conjunto de dados do BigQuery, dependendo se você optar por usar a análise de registros ou o BigQuery para análise.

• Analisar registros: depois de rotear os registros para uma ferramenta de análise, a próxima etapa é realizar uma análise desses registros para identificar possíveis ameaças de segurança. A análise dos registros exportados depende da ferramenta de análise usada. Se você usa a análise de registros ou o BigQuery, é possível analisá-los usando consultas SQL. Se você usar as Operações de segurança do Google, analise os registros usando as regras YARA-L. Se você estiver usando uma ferramenta SIEM de terceiros, utilize a linguagem de consulta especificada por essa ferramenta.

  Neste guia, você vai encontrar consultas SQL que podem ser usadas para analisar os registros na análise de registros ou no BigQuery. As consultas SQL fornecidas neste guia são parte do projeto Community Security Analytics (CSA). O CSA é um conjunto de análises de segurança de código aberto projetado para fornecer um valor de referência de consultas e regras pré-criadas que podem ser reutilizadas para análise dos registros do Google Cloud .

Confira nas seções a seguir informações detalhadas sobre como configurar e aplicar cada etapa do fluxo de trabalho de análise de registros de segurança.

Ativar registros

O processo de ativação de registros envolve as seguintes etapas:

1. Identifique os registros necessários usando a ferramenta de escopo de registros neste guia.
2. Gravação do filtro de registro gerado pela ferramenta de escopo de registro para uso posterior na configuração do coletor de registros;
3. Ative a geração de registros para cada tipo de registro ou serviço do Google Cloud identificado. Dependendo do serviço, talvez seja necessário ativar os registros de auditoria de acesso a dados correspondentes, conforme detalhado posteriormente nesta seção.

Identificar registros usando a ferramenta de escopo de registro

Para identificar os registros que atendem às necessidades de segurança e conformidade, use a ferramenta de escopo de registros mostrada nesta seção. Essa ferramenta oferece uma tabela interativa que lista registros valiosos e relevantes para a segurança no Google Cloud , incluindo registros de auditoria do Cloud, de transparência no acesso, de rede e vários registros de plataforma. Essa ferramenta mapeia cada tipo de registro para as seguintes áreas:

• Técnicas e táticas de ameaças do MITRE ATT&CK que podem ser monitoradas com esse registro.
• Violações de compliance da CIS Google Cloud Computing Platform que podem ser detectadas nesse registro.
• Regras de Detecção de ameaças a eventos que dependem desse registro.

A ferramenta de escopo de registro também gera um filtro de registro que aparece imediatamente após a tabela. Ao identificar os registros necessários, selecione-os na ferramenta para atualizar automaticamente esse filtro de registro.

Estes procedimentos curtos explicam como usar a ferramenta de escopo de registro:

• Para selecionar ou remover um registro na ferramenta de escopo de registro, clique no botão de alternância ao lado do nome do registro.
• Para selecionar ou remover todos os registros, clique no botão de alternância ao lado do título Tipo de registro.
• Para ver quais técnicas do MITRE ATT&CK podem ser monitoradas por cada tipo de registro, clique no ao lado do título Táticas e técnicas do MITRE ATT&CK.

Ferramenta de escopo de registros

Grave o filtro de registros

O filtro de registro gerado automaticamente pela ferramenta de escopo de registro contém todos os registros selecionados na ferramenta. É possível usar o filtro como está ou refinar o filtro de registro ainda mais dependendo dos seus requisitos. Por exemplo, é possível filtrar ou excluir recursos somente em um ou mais projetos específicos. Quando você tiver um filtro de registro que atenda aos requisitos, será necessário salvá-lo para usá-lo na exportação dos registros. Por exemplo, salve o filtro em um editor de texto ou em uma variável de ambiente da seguinte maneira:

1. Na seção "Filtro de registro gerado automaticamente" que segue a ferramenta, copie o código do filtro de registro.
2. Opcional: edite o código copiado para refinar o filtro.

3. No Cloud Shell, crie uma variável para salvar o filtro de registro:

   export LOG_FILTER='LOG_FILTER'
   

   Substitua LOG_FILTER pelo código do filtro de registro.

Ativar registros de plataforma específicos do serviço

Para cada um dos registros da plataforma selecionados na ferramenta de escopo de registro, esses registros precisam ser ativados (geralmente no nível do recurso) serviço a serviço. Por exemplo, os registros do Cloud DNS são ativados no nível da rede VPC. Da mesma forma, os registros de fluxo de VPC são ativados no nível da sub-rede para todas as VMs na sub-rede, e os registros de regras de firewall são ativados no nível da regra de firewall individual.

Cada registro de plataforma tem as próprias instruções sobre como ativar a geração de registros. No entanto, é possível usar a ferramenta de escopo de registros para abrir rapidamente as instruções relevantes para cada registro da plataforma.

Para saber como ativar a geração de registros para um registro de plataforma específico, faça o seguinte:

1. na ferramenta de escopo de registro, localize o registro da plataforma que você quer ativar.
2. Na coluna Ativado por padrão, clique no link Ativar que corresponde a esse registro. O link levará a instruções detalhadas sobre como ativar a geração de registros para esse serviço.

Ativar os registros de auditoria de acesso a dados

Como é possível ver na ferramenta de escopo de registros, os registros de auditoria de acesso a dados dos Registros de auditoria do Cloud fornecem uma ampla cobertura de detecção de ameaças. No entanto, o volume pode ser muito grande. A ativação desses registros de auditoria de acesso a dados pode resultar em cobranças extras relacionadas à ingestão, armazenamento, exportação e processamento desses registros. Nesta seção, explicamos como ativar esses registros e apresentamos algumas práticas recomendadas para ajudar você a compensar o valor e o custo.

Observação: os registros de auditoria de acesso a dados podem conter informações de identificação pessoal (PII), como identidades de autor da chamada e endereços IP. Você precisa aplicar as configurações de controle de acesso e retenção apropriadas disponíveis na sua ferramenta de análise para proteger seus dados de registro, reter esses dados somente pelo tempo necessário e, em seguida, descartar esses dados com segurança.

.

Os registros de auditoria de acesso a dados (exceto no BigQuery) estão desativados por padrão. Para configurar os registros de auditoria de acesso a dados para serviços do Google Cloud diferentes do BigQuery, ative-os explicitamente usando o console do Google Cloud ou usando a Google Cloud CLI para editar objetos de política do Identity and Access Management (IAM). Ao ativar os registros de auditoria de acesso a dados, também é possível configurar quais tipos de operações são gravados. Há três tipos de registro de auditoria de acesso a dados:

• ADMIN_READ: registra operações que leem metadados ou informações de configuração.
• DATA_READ: registra operações que leem dados fornecidos pelo usuário.
• DATA_WRITE: registra operações que gravam dados fornecidos pelo usuário.

Observe que não é possível configurar a gravação de operações ADMIN_WRITE, que são operações que gravam metadados ou informações de configuração. As operações ADMIN_WRITE são incluídas nos registros de auditoria da atividade do administrador nos registros de auditoria do Cloud e não podem ser desativadas.

Prática recomendada: ative os registros de auditoria de acesso a dados no nível da pasta ou da organização para garantir compliance em todos os projetos filhos da pasta ou da organização. Quando você ativa os registros de auditoria no nível da pasta ou da organização, a política de auditoria é aplicada a todos os projetos novos e existentes nessa pasta ou organização. Essa política de auditoria não pode ser desativada no nível do projeto.

Gerenciar o volume de registros de auditoria de acesso a dados

Ao ativar os registros de auditoria de acesso a dados, o objetivo é maximizar o valor deles em termos de visibilidade de segurança, além de limitar a sobrecarga de custos e gerenciamento. Para ajudar a atingir essa meta, recomendamos que você faça o seguinte para filtrar registros de alto valor e baixo valor:

• Priorize serviços relevantes, como serviços que hospedam cargas de trabalho, chaves e dados confidenciais. Para exemplos específicos de serviços que você queira priorizar, consulte Exemplo de configuração do registro de auditoria de acesso a dados.

• Priorize projetos relevantes, como projetos que hospedam cargas de trabalho de produção, em vez de projetos que hospedam ambientes de desenvolvimento e de preparo. Para filtrar todos os registros de um projeto específico, adicione a seguinte expressão ao filtro de registro do coletor. Substitua PROJECT_ID pelo ID do projeto do qual você quer filtrar todos os registros:

  Projeto	Expressão de filtro de registro
  Excluir todos os registros de um determinado projeto	NOT logName =~ "^projects/PROJECT_ID"

• Priorize um subconjunto de operações de acesso a dados, como ADMIN_READ, DATA_READ ou DATA_WRITE, para um conjunto mínimo de operações registradas. Por exemplo, alguns serviços, como o Cloud DNS, gravam os três tipos de operações, mas é possível ativar a geração de registros somente para operações ADMIN_READ. Depois de configurar um desses três tipos de operações de acesso a dados, convém excluir operações específicas que têm um volume particularmente grande. É possível excluir essas operações de grande volume modificando o filtro de registro do coletor. Por exemplo, você decide ativar a geração de registros de auditoria de acesso total a dados, incluindo operações DATA_READ em alguns serviços críticos de armazenamento. Para excluir operações específicas de leitura de dados de alto tráfego nessa situação, adicione as seguintes expressões de filtro de registro recomendadas ao filtro de registro do coletor:

  Serviço	Expressão de filtro de registro
  Excluir registros de grande volume do Cloud Storage	NOT (resource.type="gcs_bucket" AND (protoPayload.methodName="storage.buckets.get" OR protoPayload.methodName="storage.buckets.list"))
  Excluir registros de grande volume do Cloud SQL	NOT (resource.type="cloudsql_database" AND protoPayload.request.cmd="select")

• Priorize recursos relevantes, como recursos que hospedam suas cargas de trabalho e dados mais confidenciais. É possível classificar os recursos com base no valor dos dados processados e no risco de segurança deles, como acessíveis externamente ou não. Embora os registros de auditoria de acesso a dados estejam ativados por serviço, é possível filtrar recursos ou tipos de recursos específicos por meio do filtro de registro.

• Excluir principais específicos de ter seus acessos de dados registrados. Por exemplo, é possível isentar suas contas de teste internas de ter as operações registradas. Para saber mais, consulte Definir isenções na documentação de registros de auditoria de acesso a dados.

Observação: além de usar o filtro de registro do coletor para filtrar os registros adicionais, conforme discutido nesta seção, é possível excluir a ingestão desses registros no Cloud Logging por motivos de custo. Para evitar que esses registros sejam ingeridos, aplique as expressões de filtro de registro listadas nesta seção como filtros de exclusão no coletor de registros _Default predefinido que encaminha registros (incluindo registros de auditoria de acesso a dados) para o bucket de registros _Default. Os filtros de exclusão têm o efeito oposto de um filtro de registro, que é um filtro de inclusão. Portanto, ao configurar essas expressões como filtros de exclusão, você precisará remover o operador booleano NOT anterior das expressões de filtro exibidas nesta seção.

Exemplo de configuração de registros de auditoria de acesso a dados

Confira na tabela a seguir uma configuração registro de auditoria de acesso a dados de referência que pode ser usada para projetos do Google Cloud com o objetivo de limitar os volumes de registro e garantir uma visibilidade de segurança valiosa:

Nível	Serviços	Tipos de registros de auditoria de acesso a dados	Táticas do MITRE ATT&CK
Serviços de autenticação e autorização	IAM Identity-Aware Proxy (IAP)^1 Cloud KMS Secret Manager Resource Manager	ADMIN_READ DATA_READ	Descoberta Acesso a credenciais Escalonamento de privilégios
Serviços de armazenamento	BigQuery (ativado por padrão) Cloud Storage^1, 2	DATA_READ DATA_WRITE	Coleção Exfiltração
Serviços de infraestrutura	Política da organização do Compute Engine	ADMIN_READ	Discovery

¹ Ativar os registros de auditoria de acesso a dados para o IAP ou o Cloud Storage pode gerar grandes volumes de registros quando há alto tráfego para recursos da Web protegidos pelo IAP ou para objetos do Cloud Storage.

² Ativar os registros de auditoria de acesso a dados para o Cloud Storage pode interromper o uso de downloads do navegador autenticado para objetos não públicos. Para mais detalhes e soluções alternativas sugeridas, consulte o Guia de solução de problemas do Cloud Storage.

No exemplo de configuração, observe como os serviços são agrupados em níveis de sensibilidade com base nos dados, metadados ou configuração. Esses níveis demonstram a seguinte granularidade recomendada da geração de registros de auditoria de acesso a dados:

• Serviços de autenticação e autorização: para esse nível de serviço, recomendamos auditar todas as operações de acesso a dados. Esse nível de auditoria ajuda a monitorar o acesso a chaves confidenciais, Secrets e políticas do IAM. O monitoramento desse acesso pode ajudar você a detectar táticas do MITRE ATT&CK como Descoberta, Acesso a credenciais e Escalonamento de privilégios.
• Serviços de armazenamento: para esse nível de serviço, recomendamos auditar as operações de acesso a dados que envolvem dados fornecidos pelo usuário. Esse nível de auditoria ajuda a monitorar o acesso aos dados valiosos e sensíveis. O monitoramento desse acesso pode ajudar a detectar táticas do MITRE ATT&CK como Coleção e Exfiltração contra seus dados.
• Serviços de infraestrutura: para este nível de serviço, recomendamos auditar as operações de acesso a dados que envolvem metadados ou informações de configuração. Esse nível de auditoria ajuda a monitorar a verificação da configuração da infraestrutura. Monitorar esse acesso pode ajudar você a detectar táticas do MITRE ATT&CK como Descoberta contra suas cargas de trabalho.

Encaminhar registros

Depois que os registros são identificados e ativados, a próxima etapa é encaminhar os registros para um único destino. O destino, o caminho e a complexidade do roteamento variam de acordo com as ferramentas de análise usadas, conforme mostrado no diagrama a seguir.

O diagrama mostra as seguintes opções de roteamento:

• Se você usa a análise de registros, precisa de um coletor agregado para agregar os registros da sua Google Cloud organização em um único bucket do Cloud Logging.

• Se você usa o BigQuery, precisa de um coletor agregado para agregar os registros de toda a sua organização Google Cloud em um único conjunto de dados do BigQuery.

• Se você usa as Operações de Segurança do Google e esse subconjunto predefinido de registros atende às necessidades de análise de segurança, é possível agregar automaticamente esses registros à sua conta do Operações de Segurança do Google usando o Security Operations Ingestão de operações. Também é possível visualizar esse conjunto predefinido de registros na coluna Exportável diretamente para o Google Security Operations da ferramenta de escopo de registros. Para mais informações sobre como exportar esses registros predefinidos, consulte Ingerir registros do Google Cloud no Google Security Operations.

• Se você usa o BigQuery, um SIEM de terceiros ou quer exportar um conjunto expandido de registros para o Google Security Operations, o diagrama mostra que uma etapa extra é necessária entre ativar os registros e analisá-los. Essa etapa adicional consiste em configurar um coletor agregado que roteie os registros selecionados de maneira adequada. Se você estiver usando o BigQuery, esse coletor de registros é tudo o que você precisa para encaminhar os registros para o BigQuery. Se você estiver usando um SIEM de terceiros, precisará que o coletor de registros agregue os registros selecionados no Pub/Sub ou no Cloud Storage antes que eles possam ser inseridos na ferramenta de análise.

Observação: Se você usa a análise de registros (ou o BigQuery) e já configurou um coletor agregado para armazenar registros em um bucket central do Logging (ou em um conjunto de dados central do BigQuery), pule esta seção do guia e atualize o coletor com o filtro de registro da seção anterior. No caso da análise de registro, faça upgrade do bucket de registros atual para usar a análise de registros.

As opções de roteamento para as operações de segurança do Google e um SIEM de terceiros não são abordadas neste guia. No entanto, as seções a seguir mostram as etapas detalhadas de roteamento de registros para a análise de registros ou o BigQuery:

1. Configurar um único destino
2. Criar um coletor de registro agregado.
3. Conceda acesso ao coletor.
4. Configure o acesso de leitura ao destino.
5. Verifique se os registros são roteados para o destino.

Configurar um único destino

Análise de registros

Observação :ignore esta etapa se você usar um bucket do Cloud Logging que já existe no projeto Google Cloud em que os registros serão agregados. É possível usar o bucket _Default, mas recomendamos que você crie um bucket separado para esse caso de uso.

1. Abra o console Google Cloud no projeto Google Cloud em que você quer agregar os registros.

   Acessar o console do Google Cloud

2. Em um terminal do Cloud Shell, execute o comando gcloud a seguir para criar um bucket de registros:

   gcloud logging buckets create BUCKET_NAME \
     --location=BUCKET_LOCATION \
     --project=PROJECT_ID
   

   Substitua:

   • PROJECT_ID: o ID do projeto Google Cloud em que os registros agregados serão armazenados.
   • BUCKET_NAME: o nome do novo bucket do Logging.

   • BUCKET_LOCATION: a localização geográfica do novo bucket do Logging. Os locais compatíveis são global, us ou eu. Para saber mais sobre essas regiões de armazenamento, consulte Regiões com suporte. Se você não especificar um local, a região global será usada. Isso significa que os registros podem estar fisicamente localizados em qualquer uma das regiões.

     Observação: depois de criar seu bucket, não será possível alterar a região dele.

3. Verifique se o bucket foi criado:

   gcloud logging buckets list --project=PROJECT_ID
   

4. (Opcional) Defina o período de armazenamento dos registros no bucket. O exemplo a seguir estende a retenção de registros armazenados no bucket para 365 dias:

   gcloud logging buckets update BUCKET_NAME \
     --location=BUCKET_LOCATION \
     --project=PROJECT_ID \
     --retention-days=365
   

5. Para fazer upgrade do seu novo bucket para usar a análise de registros, siga estas etapas.

BigQuery

1. Abra o console Google Cloud no projeto Google Cloud em que você quer agregar os registros.

   Acessar o console do Google Cloud

2. Em um terminal do Cloud Shell, execute o comando bq mk a seguir para criar um conjunto de dados:

   bq --location=DATASET_LOCATION mk \
       --dataset \
       --default_partition_expiration=PARTITION_EXPIRATION \
       PROJECT_ID:DATASET_ID
   

   Substitua:

   • PROJECT_ID: o ID do Google Cloud projeto em que os registros agregados serão armazenados.
   • DATASET_ID: o ID do novo conjunto de dados do BigQuery.

   • DATASET_LOCATION: a localização geográfica do conjunto de dados. Após a criação de um conjunto de dados, o local não pode ser alterado.

     Observação: se escolher EU ou alguma região da UE como o local do conjunto de dados, os principais dados de cliente do BigQuery ficarão na União Europeia. Os dados do seu cliente principal do BigQuery são definidos nos Termos específicos do serviço.

   • PARTITION_EXPIRATION: o ciclo de vida padrão (em segundos) das partições nas tabelas particionadas que são criadas pelo coletor de registros. Você vai configurar o coletor de registros na próxima seção. O coletor de registros configurado usa tabelas particionadas particionadas por dia com base no carimbo de data/hora da entrada. As partições (incluindo entradas de registro associadas) são excluídas PARTITION_EXPIRATION segundos após a data da partição.

     Prática recomendada: defina a propriedade de expiração da partição padrão do conjunto de dados com base nos requisitos de retenção de registros para que os registros mais antigos sejam excluídos e expirem. É possível fazer isso durante ou após a criação do conjunto de dados. Isso permite reter registros pelo tempo necessário e limitar o tamanho total do armazenamento de registros e o custo associado. Se você tiver requisitos de retenção mais granulares com base no tipo de registro, poderá modificar essa propriedade no nível da tabeladepois O coletor iniciou o roteamento de registros e criou as tabelas particionadas correspondentes. Por exemplo, talvez seja necessário manter os dados de registros de auditoria do Cloud por três anos, mas os registros de fluxo de VPC e os registros de regras de firewall só precisam ser mantidos por 90 dias. Se você não definir uma expiração de partição padrão no nível do conjunto de dados e não definir uma expiração de partição quando a tabela for criada, as partições nunca expirarão

Criar um coletor de registros agregado

Para encaminhar os registros da organização para o destino, crie um coletor agregado no nível da organização. Para incluir todos os registros selecionados na ferramenta de escopo de registro, configure o coletor com o filtro de registro gerado pela ferramenta de escopo de registro.

Observação: o roteamento de registros para esse novo destino não significa que seus registros serão redirecionados para ele. Em vez disso, os registros são armazenados duas vezes: uma vez no projeto Google Cloud pai e outra no novo destino. Para evitar esse armazenamento duplicado dos registros, adicione um filtro de exclusão ao coletor _Default de cada projeto Google Cloud filho na organização. Para interromper a ingestão de registros nos coletores _Default de projetos futuros doGoogle Cloud na organização, desative o coletor _Default nas configurações padrão da organização.

Análise de registros

1. Em um terminal do Cloud Shell, execute o comando gcloud a seguir para criar um coletor agregado no nível da organização:

   gcloud logging sinks create SINK_NAME \
     logging.googleapis.com/projects/PROJECT_ID/locations/BUCKET_LOCATION/buckets/BUCKET_NAME \
     --log-filter="LOG_FILTER" \
     --organization=ORGANIZATION_ID \
     --include-children
   

   Substitua:

   • SINK_NAME: o nome do coletor que encaminha os registros.
   • PROJECT_ID: o ID do Google Cloud projeto em que os registros agregados serão armazenados.
   • BUCKET_LOCATION: o local do bucket do Logging que você criou para o armazenamento de registros.
   • BUCKET_NAME: o nome do bucket do Logging que você criou para o armazenamento de registros.
   • LOG_FILTER: o filtro de registro salvo da ferramenta de escopo de registro.
   • ORGANIZATION_ID: o ID do recurso para sua organização.

   A flag --include-children é importante para que os registros de todos os projetosGoogle Cloud da sua organização também sejam incluídos. Para mais informações, consulte Agrupar e rotear registros no nível da organização para destinos compatíveis.

2. Verifique se o coletor foi criado:

   gcloud logging sinks list --organization=ORGANIZATION_ID
   

3. Consiga o nome da conta de serviço associada ao coletor que você acabou de criar:

   gcloud logging sinks describe SINK_NAME --organization=ORGANIZATION_ID
   

   A saída será assim:

   writerIdentity: serviceAccount:[e-mail]`
   

4. Copie toda a string para writerIdentity que começa com serviceAccount:. Esse identificador é a conta de serviço do coletor. Até que você conceda a essa conta de serviço acesso de gravação ao bucket de registros, o roteamento de registros desse coletor falhará. Você concede acesso de gravação à identidade de gravador do coletor na próxima seção.

BigQuery

1. Em um terminal do Cloud Shell, execute o comando gcloud a seguir para criar um coletor agregado no nível da organização:

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

   Substitua:

   • SINK_NAME: o nome do coletor que encaminha os registros.
   • PROJECT_ID: o ID do projeto do Google Cloud em que você quer agregar os registros.
   • DATASET_ID: o ID do conjunto de dados do BigQuery que você criou.
   • LOG_FILTER: o filtro de registro salvo da ferramenta de escopo de registro.
   • ORGANIZATION_ID: o ID do recurso para sua organização.

   A flag --include-children é importante para que os registros de todos os projetosGoogle Cloud da sua organização também sejam incluídos. Para mais informações, consulte Agrupar e rotear registros no nível da organização para destinos compatíveis.

   A sinalização --use-partitioned-tables é importante para que os dados sejam particionados por dia com base no campo timestamp da entrada de registro. Isso simplifica a consulta dos dados e ajuda a reduzir os custos das consultas, reduzindo a quantidade de dados verificados. Outra vantagem das tabelas particionadas é que é possível definir uma expiração de partição padrão no nível do conjunto de dados para atender aos requisitos de retenção de registros. Você já definiu uma expiração de partição padrão ao criar o destino do conjunto de dados na seção anterior. Também é possível definir uma expiração de partição no nível da tabela individual, fornecendo controles de retenção de dados refinados com base no tipo de registro.

2. Verifique se o coletor foi criado:

   gcloud logging sinks list --organization=ORGANIZATION_ID
   

3. Consiga o nome da conta de serviço associada ao coletor que você acabou de criar:

   gcloud logging sinks describe SINK_NAME --organization=ORGANIZATION_ID
   

   A saída será assim:

   writerIdentity: serviceAccount:[e-mail]`
   

4. Copie toda a string para writerIdentity que começa com serviceAccount:. Esse identificador é a conta de serviço do coletor. Até que você conceda a essa conta de serviço acesso de gravação ao conjunto de dados do BigQuery, o roteamento de registros desse coletor falhará. Você concede acesso de gravação à identidade de gravador do coletor na próxima seção.

Permitir acesso ao coletor

Depois de criar o coletor de registros, conceda ao coletor acesso de gravação no destino, seja o bucket do Logging ou o conjunto de dados do BigQuery.

Nota: Para rotear registros para um recurso protegido por um perímetro de serviço, é necessário adicionar a conta de serviço desse coletor a um nível de acesso e, em seguida, atribuí-la ao perímetro de serviço de destino de dados. Isso não é necessário para coletores não agregados. Para detalhes, consulte VPC Service Controls: Cloud Logging.

Análise de registros

Para adicionar as permissões à conta de serviço do coletor, siga estas etapas:

1. No console do Google Cloud , acesse a página do IAM:

   Acessar a página do IAM

2. Verifique se você selecionou o projeto de destino Google Cloud que contém o bucket do Logging criado para o armazenamento de registros central.

3. Clique em CONCEDER ACESSO.

4. No campo Novos principais, insira a conta de serviço do coletor sem o prefixo serviceAccount:. Lembre-se de que essa identidade vem do campo writerIdentity que você recuperou na seção anterior depois de criar o coletor.

5. No menu suspenso Selecionar um papel, selecione Gravador do bucket de registros.

6. Clique em Adicionar condição do IAM para restringir o acesso da conta de serviço apenas ao bucket de registros que você criou.

7. Insira um Título e uma Descrição para a condição.

8. No menu suspenso Tipo de condição, selecione Recurso > Nome.

9. No menu suspenso Operador, selecione Encerra com.

10. No campo Valor, insira o local e o nome do bucket da seguinte maneira:

    locations/BUCKET_LOCATION/buckets/BUCKET_NAME
    

11. Clique em Salvar para adicionar a condição.

12. Clique em Salvar para definir as permissões.

BigQuery

Para adicionar as permissões à conta de serviço do coletor, siga estas etapas:

1. No console Google Cloud , acesse o BigQuery:

   Acessar o BigQuery

2. Abra o conjunto de dados do BigQuery que você criou para o armazenamento de registros central.

3. Na guia "Informações do conjunto de dados", clique no menu suspenso Compartilhamento e em Permissões.

4. No painel lateral "Permissões do conjunto de dados", clique em Adicionar principal.

5. No campo Novos principais, insira a conta de serviço do coletor sem o prefixo serviceAccount:. Lembre-se de que essa identidade vem do campo writerIdentity que você recuperou na seção anterior depois de criar o coletor.

6. No menu suspenso Papel, selecione Editor de dados do BigQuery.

7. Clique em Save.

Depois de conceder acesso ao coletor, as entradas de registro começarão a preencher o destino do coletor: o bucket do Logging ou o conjunto de dados do BigQuery.

Configurar o acesso de leitura ao destino

Agora que o coletor de registros roteia os registros de toda a organização para um único destino, é possível pesquisar em todos esses registros. Use as permissões do IAM para gerenciar as permissões e conceder acesso conforme necessário.

Análise de registros

Para conceder acesso para visualizar e consultar os registros no novo bucket de registros, siga estas etapas.

1. No console do Google Cloud , acesse a página do IAM:

   Acessar a página do IAM

   Verifique se você selecionou o projeto Google Cloud que está usando para agregar os registros.

2. Clique em Adicionar.

3. No campo Novo principal, adicione sua conta de e-mail.

4. No menu suspenso Selecionar um papel, selecione Acessador de visualizações de registros.

   Com esse papel, o principal recém-adicionado tem acesso de leitura a todas as visualizações de todos os buckets no projeto Google Cloud . Para limitar o acesso de um usuário, adicione uma condição que permita que ele leia apenas do novo bucket.

   1. Clique em Adicionar condição.

   2. Insira um Título e uma Descrição para a condição.

   3. No menu suspenso Tipo de condição, selecione Recurso > Nome.

   4. No menu suspenso Operador, selecione Encerra com.

   5. No campo Valor, insira o local e nome do bucket e a visualização de registro padrão _AllLogs da seguinte maneira:

      locations/BUCKET_LOCATION/buckets/BUCKET_NAME/views/_AllLogs
      

      Observação: o Cloud Logging cria automaticamente a visualização _AllLogs para cada bucket, que mostra todos os registros no bucket. Para ter um controle mais granular sobre quais registros podem ser visualizados e consultados nesse bucket de registros, é possível criar e usar uma visualização de registros personalizada em vez de _AllLogs.

   6. Clique em Salvar para adicionar a condição.

5. Clique em Salvar para definir as permissões.

BigQuery

Para conceder acesso para visualizar e consultar os registros no conjunto de dados do BigQuery, siga as etapas na seção Como conceder acesso a um conjunto de dados da documentação do BigQuery.

Verificar se os registros são roteados para o destino

Análise de registros

Ao rotear registros para um bucket de registros atualizado para a análise de registros, é possível visualizar e consultar todas as entradas de registro por meio de uma única visualização de registros com um esquema unificado para todos os tipos de registros. Siga estas etapas para verificar se os registros estão roteados corretamente.

1. No console Google Cloud , acesse a página "Análise de dados de registros":

   Acessar a análise de registros

   Verifique se você selecionou o projeto Google Cloud que está usando para agregar os registros.

2. Clique na guia Log Views.

3. Expanda as visualizações de registro no bucket de registros que você criou (ou seja, BUCKET_NAME) se ele ainda não estiver expandido.

4. Selecione a visualização de registro padrão _AllLogs. Agora você pode inspecionar todo o esquema do registro no painel à direita, conforme mostrado na captura de tela a seguir:

   

5. Ao lado de _AllLogs, clique em Consulta . O editor de consulta será preenchido com uma consulta de amostra SQL para recuperar as entradas de registro roteadas recentemente.

6. Clique em Executar consulta para ver as entradas de registro roteadas recentemente.

Dependendo do nível de atividade nos projetos do Google Cloud na organização, talvez seja necessário aguardar alguns minutos até que alguns registros sejam gerados e roteados para o bucket de registros.

BigQuery

Quando você exporta registros para um conjunto de dados do BigQuery, o Cloud Logging cria tabelas do BigQuery para armazenar as entradas de registro exportadas, conforme mostrado na captura de tela a seguir:

A captura de tela mostra como o Cloud Logging nomeia cada tabela do BigQuery com base no nome do registro a que uma entrada pertence. Por exemplo, a tabela cloudaudit_googleapis_com_data_access selecionada na captura de tela contém registros de auditoria de acesso a dados com ID de registro cloudaudit.googleapis.com%2Fdata_access. Além de serem nomeadas com base na entrada de registro correspondente, cada tabela também é particionada com base nos carimbos de data/hora de cada entrada.

Dependendo do nível de atividade nos projetos do Google Cloud na organização, talvez seja necessário esperar alguns minutos até que alguns registros sejam gerados e, em seguida, roteados para o conjunto de dados do BigQuery.

Note: Os registros de atividade de administração e de acesso a dados são carregados no BigQuery com o campo de entrada de registro protoPayload renomeado como protoPayload_auditlog no BigQuery. Para mais informações sobre conversões de esquema feitas pelo Cloud Logging antes de gravar no BigQuery, consulte Campos em registros de auditoria exportados.

Analisar registros

Você pode executar uma ampla variedade de consultas nos registros de auditoria e de plataforma. Veja na lista a seguir um conjunto de exemplos de perguntas de segurança que você pode querer fazer sobre seus próprios registros. Para cada pergunta dessa lista, há duas versões da consulta de CSA correspondente: uma para uso com a análise de registros e outra para uso com o BigQuery. Use a versão da consulta que corresponda ao destino do coletor configurado anteriormente.

Análise de registros

Antes de usar qualquer uma das consultas SQL abaixo, substitua MY_PROJECT_ID pelo ID do projeto Google Cloud em que você criou o bucket de registros (ou seja, PROJECT_ID), e MY_DATASET_ID pela região e o nome desse bucket de registros (ou seja, BUCKET_LOCATION.BUCKET_NAME).

Acessar a análise de registros

BigQuery

Antes de usar as consultas SQL abaixo, substitua MY_PROJECT_ID pelo ID do projeto Google Cloud em que você criou o conjunto de dados do BigQuery (ou seja, PROJECT_ID) e MY_DATASET_ID pelo nome desse conjunto de dados, que é DATASET_ID.

Acessar o BigQuery

1. Perguntas de login e acesso
   • Alguma tentativa de login suspeita foi sinalizada pelo Google Workspace?
   • Há falhas de login excessivas de qualquer identidade do usuário?
   • Alguma tentativa de acesso viola o VPC Service Controls?
   • Alguma tentativa de acesso viola os controles de acesso do Identity-Aware Proxy?
2. Perguntas sobre mudanças de permissão
   • Algum usuário foi adicionado a grupos altamente privilegiados?
   • Alguma permissão foi concedida em uma conta de serviço?
   • Alguma conta ou chave de serviço foi criada por identidade não aprovada?
   • Algum usuário foi adicionado ou removido da política de IAM confidencial?
3. Perguntas sobre o provisionamento de atividades
   • Houve alguma mudança nas configurações de geração de registros?
   • Algum registro de fluxo da VPC está desativado?
   • Um número excepcionalmente incomum de regras de firewall foi modificado na última semana?
   • Alguma VM foi excluída na última semana?
4. Perguntas sobre o uso da carga de trabalho
   • Alguma API teve uso excepcionalmente alto por qualquer identidade de usuário na última semana?
   • Qual foi o uso por escalonamento automático por dia no mês passado?
5. Perguntas sobre o acesso a dados
   • Quais usuários acessaram os dados com mais frequência na última semana?
   • Quais usuários acessaram os dados na tabela "accounts" no mês passado?
   • Quais tabelas são acessadas com mais frequência e por quem?
   • Quais foram as 10 principais consultas do BigQuery na semana passada?
   • Quais foram as ações mais comuns gravadas no registro de acesso a dados no último mês?
6. Perguntas sobre segurança de rede
   • Alguma conexão de um IP novo com uma sub-rede específica?
   • Alguma conexão bloqueada pelo Google Cloud Armor?
   • Existe algum vírus ou malware de alta gravidade detectado pelo Cloud IDS?
   • Quais são os principais domínios consultados do Cloud DNS da sua rede VPC?

Perguntas de login e acesso

Essas consultas de amostra realizam análises para detectar tentativas de login suspeitas ou tentativas iniciais de acesso ao seu ambiente Google Cloud .

Observação: a atividade de login é capturada nos registros do Cloud Identity incluídos na Auditoria de login do Google Workspace. Para analisar a atividade de login e usar algumas das consultas desta seção, ative o compartilhamento de dados do Google Workspace com Google Cloud. Para saber mais sobre como compartilhar registros de auditoria do Google Workspace com o Google Cloud, consulte Visualizar e gerenciar registros de auditoria do Google Workspace.

Alguma tentativa de login suspeita foi sinalizada pelo Google Workspace?

Ao pesquisar os registros do Cloud Identity que fazem parte da Auditoria de login do Google Workspace, a consulta a seguir detecta tentativas de login suspeitas sinalizadas pelo Google Workspace. Essas tentativas de login podem ser feitas no console Google Cloud , no Admin Console ou na CLI gcloud.

Análise de registros

SELECT
  timestamp,
  proto_payload.audit_log.authentication_info.principal_email,
  proto_payload.audit_log.request_metadata.caller_ip,
  proto_payload.audit_log.method_name, parameter
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`,
  UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.metadata.event[0].parameter)) AS parameter
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
  AND proto_payload.audit_log IS NOT NULL
  AND proto_payload.audit_log.service_name = "login.googleapis.com"
  AND proto_payload.audit_log.method_name = "google.login.LoginService.loginSuccess"
  AND JSON_VALUE(parameter.name) = "is_suspicious"
  AND JSON_VALUE(parameter.boolValue) = "true"

BigQuery

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"

Há falhas de login excessivas de qualquer identidade do usuário?

Ao pesquisar os registros do Cloud Identity que fazem parte da Auditoria de login do Google Workspace, a consulta a seguir detecta usuários que tiveram três ou mais falhas de login sucessivas nas últimas 24 horas.

Análise de registros

SELECT
  proto_payload.audit_log.authentication_info.principal_email,
  MIN(timestamp) AS earliest,
  MAX(timestamp) AS latest,
  count(*) AS attempts
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  AND proto_payload.audit_log.service_name = "login.googleapis.com"
  AND proto_payload.audit_log.method_name = "google.login.LoginService.loginFailure"
GROUP BY
  1
HAVING
  attempts >= 3

BigQuery

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

Alguma tentativa de acesso viola o VPC Service Controls?

Ao analisar os registros de auditoria de política negada dos registros de auditoria do Cloud, a consulta a seguir detecta tentativas de acesso bloqueadas pelo VPC Service Controls. Qualquer resultado de consulta pode indicar uma possível atividade maliciosa, como tentativas de acesso de redes não autorizadas usando credenciais roubadas.

Análise de registros

SELECT
  timestamp,
  log_name,
  proto_payload.audit_log.authentication_info.principal_email,
  proto_payload.audit_log.request_metadata.caller_ip,
  proto_payload.audit_log.method_name,
  proto_payload.audit_log.service_name,
  JSON_VALUE(proto_payload.audit_log.metadata.violationReason) as violationReason, 
  IF(JSON_VALUE(proto_payload.audit_log.metadata.ingressViolations) IS NULL, 'ingress', 'egress') AS violationType,
  COALESCE(
    JSON_VALUE(proto_payload.audit_log.metadata.ingressViolations[0].targetResource),
    JSON_VALUE(proto_payload.audit_log.metadata.egressViolations[0].targetResource)
  ) AS  targetResource,
  COALESCE(
    JSON_VALUE(proto_payload.audit_log.metadata.ingressViolations[0].servicePerimeter),
    JSON_VALUE(proto_payload.audit_log.metadata.egressViolations[0].servicePerimeter)
  ) AS  servicePerimeter
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND proto_payload.audit_log IS NOT NULL
  AND JSON_VALUE(proto_payload.audit_log.metadata, '$."@type"') = 'type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata'
ORDER BY
  timestamp DESC
LIMIT 1000

BigQuery

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

Existe alguma tentativa de acesso que viola os controles de acesso do IAP?

Ao analisar os registros do balanceador de carga de aplicativo externo, a consulta a seguir detecta as tentativas de acesso bloqueadas pelo IAP. Qualquer resultado de consulta pode indicar uma tentativa de acesso inicial ou de exploração de vulnerabilidade.

Análise de registros

SELECT
  timestamp,
  http_request.remote_ip,
  http_request.request_method,
  http_request.status,
  JSON_VALUE(resource.labels.backend_service_name) AS backend_service_name,
  http_request.request_url
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="http_load_balancer"
  AND JSON_VALUE(json_payload.statusDetails) = "handled_by_identity_aware_proxy"
ORDER BY
  timestamp DESC

BigQuery

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

Perguntas sobre mudanças nas permissões

Essas consultas de amostra realizam análises sobre a atividade do administrador que altera as permissões, incluindo alterações em políticas do IAM, grupos e associações a grupos, contas de serviço e chaves associadas. Essas mudanças de permissão podem fornecer um alto nível de acesso a dados ou ambientes confidenciais.

Observação :as mudanças em grupo são capturadas na auditoria do administrador do Google Workspace. Para analisar a atividade de alterações em grupo e usar algumas das consultas desta seção, ative o compartilhamento de dados do Google Workspace com Google Cloud. Para saber mais sobre como compartilhar registros de auditoria do Google Workspace com o Google Cloud, consulte Visualizar e gerenciar registros de auditoria do Google Workspace.

Algum usuário foi adicionado a grupos altamente privilegiados?

Ao analisar os registros de auditoria da auditoria de amin do Google Workspace, a consulta a seguir detecta os usuários adicionados a qualquer um dos grupos altamente privilegiados listados na consulta. Use a expressão regular na consulta para definir quais grupos (como [e-mail] ou [e-mail]) será monitorado. Qualquer resultado de consulta pode indicar um escalonamento de privilégios malicioso ou acidental.

Análise de registros

SELECT
  timestamp,
  proto_payload.audit_log.authentication_info.principal_email,
  proto_payload.audit_log.method_name,
  proto_payload.audit_log.resource_name,
  (SELECT JSON_VALUE(x.value)
   FROM UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.metadata.event[0].parameter)) AS x
   WHERE JSON_VALUE(x.name) = "USER_EMAIL") AS user_email,
  (SELECT JSON_VALUE(x.value)
   FROM UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.metadata.event[0].parameter)) AS x
   WHERE JSON_VALUE(x.name) = "GROUP_EMAIL") AS group_email,
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 120 DAY)
  AND proto_payload.audit_log.service_name = "admin.googleapis.com"
  AND proto_payload.audit_log.method_name = "google.admin.AdminService.addGroupMember"
  AND EXISTS(
    SELECT * FROM UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.metadata.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
  )

BigQuery

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
  )

Alguma permissão foi concedida em uma conta de serviço?

Ao analisar os registros de auditoria de atividade do administrador nos registros de auditoria do Cloud, a consulta a seguir detecta todas as permissões concedidas a qualquer principal em uma conta de serviço. Exemplos de permissões que podem ser concedidas são a capacidade de representar essa conta de serviço ou criar chaves de conta de serviço. Qualquer resultado de consulta pode indicar uma instância de escalonamento de privilégios ou um risco de vazamento de credenciais.

Análise de registros

SELECT
  timestamp,
  proto_payload.audit_log.authentication_info.principal_email as grantor,
  JSON_VALUE(bindingDelta.member) as grantee,
  JSON_VALUE(bindingDelta.role) as role,
  proto_payload.audit_log.resource_name,
  proto_payload.audit_log.method_name
FROM
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`,
  UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.service_data.policyDelta.bindingDeltas)) AS bindingDelta
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 400 DAY)
  -- AND log_id = "cloudaudit.googleapis.com/activity"
  AND (
    (resource.type = "service_account"
    AND proto_payload.audit_log.method_name LIKE "google.iam.admin.%.SetIAMPolicy")
    OR
    (resource.type IN ("project", "folder", "organization")
    AND proto_payload.audit_log.method_name = "SetIamPolicy"
    AND JSON_VALUE(bindingDelta.role) LIKE "roles/iam.serviceAccount%")
  )
  AND JSON_VALUE(bindingDelta.action) = "ADD"
  -- Principal (grantee) exclusions
  AND JSON_VALUE(bindingDelta.member) NOT LIKE "[e-mail]"
ORDER BY
  timestamp DESC

BigQuery

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail as grantor,
  bindingDelta.member as grantee,
  bindingDelta.role,
  protopayload_auditlog.resourceName,
  protopayload_auditlog.methodName,
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 180 DAY)
  AND (
    (resource.type = "service_account"
    AND protopayload_auditlog.methodName LIKE "google.iam.admin.%.SetIAMPolicy")
    OR
    (resource.type IN ("project", "folder", "organization")
    AND protopayload_auditlog.methodName = "SetIamPolicy"
    AND bindingDelta.role LIKE "roles/iam.serviceAccount%")
  )
  AND bindingDelta.action = 'ADD'
  -- Principal (grantee) exclusions
  AND bindingDelta.member NOT LIKE "[e-mail]"
ORDER BY
  timestamp DESC

Alguma conta ou chave de serviço foi criada por identidade não aprovada?

Ao analisar os registros de auditoria de atividade do administrador, a consulta a seguir detecta todas as contas ou chaves de serviço que foram criadas manualmente por um usuário. Por exemplo, é possível seguir uma prática recomendada para permitir que apenas contas de serviço sejam criadas por um conta de serviço aprovada como parte de um fluxo de trabalho automatizado. Portanto, qualquer criação de conta de serviço fora desse fluxo de trabalho é considerada incompatível e possivelmente maliciosa.

Análise de registros

SELECT
  timestamp,
  proto_payload.audit_log.authentication_info.principal_email,
  proto_payload.audit_log.method_name,
  proto_payload.audit_log.resource_name,
  JSON_VALUE(proto_payload.audit_log.response.email) as service_account_email
FROM
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="service_account"
  AND proto_payload.audit_log.method_name LIKE "%CreateServiceAccount%"
  AND proto_payload.audit_log.authentication_info.principal_email NOT LIKE "%.gserviceaccount.com"

BigQuery

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"

Algum usuário foi adicionado ou removido da política de IAM confidencial?

Ao pesquisar os registros de auditoria de atividade do administrador, a consulta a seguir detecta qualquer alteração no acesso de usuários ou grupos para um recurso protegido pelo IAP, como um serviço de back-end do Compute Engine. A consulta a seguir pesquisa todas as atualizações de política do IAM por recursos do IAP que envolvem o papel do IAM roles/iap.httpsResourceAccessor. Esse papel fornece permissões para acessar o recurso HTTPS ou o serviço de back-end. Qualquer resultado da consulta pode indicar tentativas de ignorar as defesas de um serviço de back-end que poderia ser exposto à internet.

Análise de registros

SELECT
  timestamp,
  proto_payload.audit_log.authentication_info.principal_email,
  resource.type,
  proto_payload.audit_log.resource_name,
  JSON_VALUE(binding, '$.role') as role,
  JSON_VALUE_ARRAY(binding, '$.members') as members
FROM
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`,
  UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.response, '$.bindings')) AS binding
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  -- AND log_id = "cloudaudit.googleapis.com/activity"
  AND proto_payload.audit_log.service_name = "iap.googleapis.com"
  AND proto_payload.audit_log.method_name LIKE "%.IdentityAwareProxyAdminService.SetIamPolicy"
  AND JSON_VALUE(binding, '$.role') = "roles/iap.httpsResourceAccessor"
ORDER BY
  timestamp DESC

BigQuery

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

Perguntas sobre o provisionamento de atividades

Essas consultas de amostra realizam análises para detectar atividades do administrador suspeitas ou anômalas, como o provisionamento e a configuração de recursos.

Houve alguma mudança nas configurações de geração de registros?

Ao pesquisar os registros de auditoria da atividade do administrador, a consulta a seguir detecta qualquer alteração feita nas configurações de geração de registros. O monitoramento das configurações de geração de registros ajuda a detectar a desativação acidental ou maliciosa dos registros de auditoria e de técnicas semelhantes de evasão de defesa.

Análise de registros

SELECT
  receive_timestamp, timestamp AS eventTimestamp,
  proto_payload.audit_log.request_metadata.caller_ip,
  proto_payload.audit_log.authentication_info.principal_email, 
  proto_payload.audit_log.resource_name,
  proto_payload.audit_log.method_name
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  proto_payload.audit_log.service_name = "logging.googleapis.com"
  AND log_id = "cloudaudit.googleapis.com/activity"

BigQuery

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"

Há algum registro de fluxo da VPC desativado ativamente?

Nos registros de auditoria de atividade do administrador, a consulta a seguir detecta qualquer sub-rede com registros de fluxo de VPC desativados ativamente . O monitoramento das configurações de registros de fluxo de VPC ajuda a detectar a desativação acidental ou maliciosa dos registros de fluxo de VPC e de técnicas semelhantes de evasão de defesa.

Análise de registros

SELECT
  receive_timestamp, timestamp AS eventTimestamp,
  proto_payload.audit_log.request_metadata.caller_ip,
  proto_payload.audit_log.authentication_info.principal_email, 
  proto_payload.audit_log.resource_name,
  proto_payload.audit_log.method_name
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  proto_payload.audit_log.method_name = "v1.compute.subnetworks.patch" 
  AND (
    JSON_VALUE(proto_payload.audit_log.request, "$.logConfig.enable") = "false"
    OR JSON_VALUE(proto_payload.audit_log.request, "$.enableFlowLogs") = "false"
  )

BigQuery

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"

Um número excepcionalmente alto de regras de firewall foi modificado na última semana?

Ao pesquisar os registros de auditoria da atividade do administrador, a consulta a seguir detecta qualquer número alto incomum de alterações de regras de firewall em um determinado dia da última semana. Para determinar se há outliers, a consulta realiza uma análise estatística sobre as contagens diárias de alterações de regras de firewall. As médias e os desvios-padrão são computados para cada dia analisando as contagens diárias anteriores com uma janela de lookback de 90 dias. Um outlier é considerado quando a contagem diária é mais de dois desvios-padrão acima da média. A consulta, incluindo o fator de desvio padrão e as janelas de lookback, pode ser configurada para se ajustar ao perfil de atividade de provisionamento na nuvem e minimizar os falsos positivos.

Análise de registros

SELECT
  *
FROM (
  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 proto_payload.audit_log.method_name IGNORE NULLS) AS actions,
      ARRAY_AGG(DISTINCT proto_payload.audit_log.authentication_info.principal_email IGNORE NULLS) AS actors,
      COUNT(*) AS counter
    FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
    WHERE
      timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY)
      AND proto_payload.audit_log.method_name LIKE "v1.compute.firewalls.%"
      AND proto_payload.audit_log.method_name NOT IN ("v1.compute.firewalls.list", "v1.compute.firewalls.get")
    GROUP BY
      day
  )
)
WHERE
  counter > avg + 2 * stddev
  AND day >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) 
ORDER BY
  counter DESC

BigQuery

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

Alguma VM foi excluída na última semana?

Ao pesquisar os registros de auditoria de atividade do administrador, a consulta a seguir lista todas as instâncias do Compute Engine excluídas na última semana. Essa consulta pode ajudar a auditar exclusões de recursos e detectar possíveis atividades maliciosas.

Análise de registros

SELECT
  timestamp,
  JSON_VALUE(resource.labels.instance_id) AS instance_id,
  proto_payload.audit_log.authentication_info.principal_email, 
  proto_payload.audit_log.resource_name,
  proto_payload.audit_log.method_name
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  resource.type = "gce_instance"
  AND proto_payload.audit_log.method_name = "v1.compute.instances.delete"
  AND operation.first IS TRUE
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
ORDER BY
  timestamp desc,
  instance_id
LIMIT
  1000

BigQuery

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

Perguntas sobre o uso da carga de trabalho

Essas consultas de amostra realizam análises para entender quem e o que está consumindo as cargas de trabalho e APIs da nuvem e ajudam a detectar possíveis comportamentos maliciosos interna ou externamente.

Alguma API teve uso excepcionalmente alto por qualquer identidade de usuário na última semana?

Ao analisar todos os Registros de auditoria do Cloud, a consulta a seguir detecta um uso excepcionalmente alto da API por qualquer identidade de usuário em um determinado dia da última semana. Esse uso excepcionalmente alto pode ser um indicador de possível abuso de API, ameaça interna ou credenciais vazadas. Para determinar se há um outlier, essa consulta realiza uma análise estatística da contagem diária de ações por principal. As médias e os desvios-padrão são computados para cada dia e para cada principal analisando as contagens diárias anteriores com uma janela de lookback de 60 dias. Um outlier é considerado quando a contagem diária para um usuário está mais de três desvios-padrão acima da sua média. A consulta, incluindo o fator de desvio-padrão e as janelas de lookback, pode ser configurada para se adequar ao perfil de atividade de provisionamento de nuvem e minimizar os falsos positivos.

Análise de registros

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

BigQuery

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

Qual foi o uso por escalonamento automático por dia no mês passado?

Ao analisar os registros de auditoria de atividade do administrador, a consulta a seguir informa o uso automático por dia no último mês. Essa consulta pode ser usada para identificar padrões ou anomalias que exigem uma investigação mais detalhada da segurança.

Análise de registros

SELECT
  TIMESTAMP_TRUNC(timestamp, DAY) AS day,
  proto_payload.audit_log.method_name,
  COUNT(*) AS counter
FROM
   `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  resource.type = "gce_instance_group_manager"
  AND log_id = "cloudaudit.googleapis.com/activity"
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  1, 2
ORDER BY
  1, 2

BigQuery

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

Perguntas sobre o acesso a dados

Essas consultas de exemplo realizam análises para entender quem está acessando ou modificando dados em Google Cloud.

Quais usuários acessaram os dados com mais frequência na última semana?

A consulta a seguir usa os registros de auditoria de Acesso a dados para localizar as identidades dos usuários que acessaram com mais frequência as tabelas do BigQuery na última semana.

Análise de registros

SELECT
  proto_payload.audit_log.authentication_info.principal_email,
  COUNT(*) AS COUNTER
FROM 
   `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  (proto_payload.audit_log.method_name = "google.cloud.bigquery.v2.JobService.InsertJob" OR
   proto_payload.audit_log.method_name = "google.cloud.bigquery.v2.JobService.Query")
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
  AND log_id = "cloudaudit.googleapis.com/data_access"
GROUP BY
  1
ORDER BY
  2 desc, 1
LIMIT
  100

BigQuery

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

Quais usuários acessaram os dados na tabela "accounts" no mês passado?

A consulta a seguir usa os registros de auditoria de Acesso a dados para encontrar as identidades de usuário que consultou com mais frequência uma determinada tabela accounts no último mês. Além dos marcadores MY_DATASET_ID e MY_PROJECT_ID do seu destino do BigQuery Export, a consulta a seguir usa os marcadores DATASET_ID e PROJECT_ID. É necessário substituir os marcadores DATASET_ID e PROJECT_ID para especificar a tabela de destino cujo acesso está sendo analisado, como a tabela accounts neste exemplo.

Análise de registros

SELECT
  proto_payload.audit_log.authentication_info.principal_email,
  COUNT(*) AS COUNTER
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`,
  UNNEST(proto_payload.audit_log.authorization_info) authorization_info
WHERE
  (proto_payload.audit_log.method_name = "google.cloud.bigquery.v2.JobService.InsertJob" OR
   proto_payload.audit_log.method_name = "google.cloud.bigquery.v2.JobService.Query")
  AND authorization_info.permission = "bigquery.tables.getData"
  AND authorization_info.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

BigQuery

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

Quais tabelas são acessadas com mais frequência e por quem?

A consulta a seguir usa os registros de auditoria de acesso a dados para encontrar as tabelas do BigQuery com dados lidos e modificados com mais frequência no último mês. Ela exibe a identidade do usuário associada ao detalhamento do número total de vezes que os dados foram lidos em comparação aos dados modificados.

Análise de registros

SELECT
  proto_payload.audit_log.resource_name,
  proto_payload.audit_log.authentication_info.principal_email,
  COUNTIF(JSON_VALUE(proto_payload.audit_log.metadata, "$.tableDataRead") IS NOT NULL) AS dataReadEvents,
  COUNTIF(JSON_VALUE(proto_payload.audit_log.metadata, "$.tableDataChange") IS NOT NULL) AS dataChangeEvents,
  COUNT(*) AS totalEvents
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  STARTS_WITH(resource.type, 'bigquery') IS TRUE
  AND (JSON_VALUE(proto_payload.audit_log.metadata, "$.tableDataRead") IS NOT NULL
    OR JSON_VALUE(proto_payload.audit_log.metadata, "$.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

BigQuery

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

Quais foram as 10 principais consultas do BigQuery na semana passada?

A consulta a seguir usa os registros de auditoria de Acesso a dados para encontrar as consultas mais comuns na última semana. Ela também lista os usuários correspondentes e as tabelas referenciadas.

Análise de registros

SELECT
  COALESCE(
   JSON_VALUE(proto_payload.audit_log.metadata, "$.jobChange.job.jobConfig.queryConfig.query"),
   JSON_VALUE(proto_payload.audit_log.metadata, "$.jobInsertion.job.jobConfig.queryConfig.query")) as query,
  STRING_AGG(DISTINCT proto_payload.audit_log.authentication_info.principal_email, ',') as users,
  ANY_VALUE(COALESCE(
   JSON_EXTRACT_ARRAY(proto_payload.audit_log.metadata, "$.jobChange.job.jobStats.queryStats.referencedTables"),
   JSON_EXTRACT_ARRAY(proto_payload.audit_log.metadata, "$.jobInsertion.job.jobStats.queryStats.referencedTables"))) as tables,
  COUNT(*) AS counter
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  (resource.type = 'bigquery_project' OR resource.type = 'bigquery_dataset')
  AND operation.last IS TRUE
  AND (JSON_VALUE(proto_payload.audit_log.metadata, "$.jobChange") IS NOT NULL
    OR JSON_VALUE(proto_payload.audit_log.metadata, "$.jobInsertion") IS NOT NULL)
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY
  query
ORDER BY
  counter DESC
LIMIT 10

BigQuery

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

Quais foram as ações mais comuns gravadas no registro de acesso a dados no último mês?

A consulta a seguir usa todos os registros dos Registros de auditoria do Cloud para encontrar as 100 ações mais frequentes gravadas no último mês.

Análise de registros

SELECT
  proto_payload.audit_log.method_name,
  proto_payload.audit_log.service_name,
  resource.type,
  COUNT(*) AS counter
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND log_id="cloudaudit.googleapis.com/data_access"
GROUP BY
  proto_payload.audit_log.method_name,
  proto_payload.audit_log.service_name,
  resource.type
ORDER BY
  counter DESC
LIMIT 100

BigQuery

SELECT
  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

Perguntas sobre segurança de rede

Esses exemplos de consulta realizam análises sobre sua atividade de rede no Google Cloud.

Alguma conexão de um IP novo com uma sub-rede específica?

A consulta a seguir detecta conexões de qualquer endereço IP de origem novo para uma determinada sub-rede analisando registros de fluxo de VPC. Neste exemplo, um endereço IP de origem é considerado novo se tiver sido visto pela primeira vez nas últimas 24 horas em uma janela de lookback de 60 dias. Use e ajuste essa consulta em uma sub-rede que esteja no escopo para um requisito de conformidade específico, como o PCI.

Análise de registros

SELECT
  JSON_VALUE(json_payload.connection.src_ip) as src_ip,
  -- TIMESTAMP supports up to 6 digits of fractional precision, so drop any more digits to avoid parse errors
  MIN(TIMESTAMP(REGEXP_REPLACE(JSON_VALUE(json_payload.start_time), r'\.(\d{0,6})\d+(Z)?$', '.\\1\\2'))) AS firstInstance,
  MAX(TIMESTAMP(REGEXP_REPLACE(JSON_VALUE(json_payload.start_time), r'\.(\d{0,6})\d+(Z)?$', '.\\1\\2'))) AS lastInstance,
  ARRAY_AGG(DISTINCT JSON_VALUE(resource.labels.subnetwork_name)) as subnetNames,
  ARRAY_AGG(DISTINCT JSON_VALUE(json_payload.dest_instance.vm_name)) as vmNames,
  COUNT(*) numSamples
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
  AND JSON_VALUE(json_payload.reporter) = 'DEST'
  AND JSON_VALUE(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

BigQuery

SELECT
  jsonPayload.connection.src_ip as src_ip,
  -- TIMESTAMP supports up to 6 digits of fractional precision, so drop any more digits to avoid parse errors
  MIN(TIMESTAMP(REGEXP_REPLACE(jsonPayload.start_time, r'\.(\d{0,6})\d+(Z)?$', '.\\1\\2'))) AS firstInstance,
  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

Alguma conexão bloqueada pelo Google Cloud Armor?

A consulta a seguir ajuda a detectar possíveis tentativas de exploração analisando os registros de balanceador de carga de aplicativo externo para encontrar qualquer conexão bloqueada pela política de segurança configurada no Google Cloud Armor. Nesta consulta, presumimos que você tenha uma política de segurança do Google Cloud Armor configurada no balanceador de carga de aplicativo externo. Esta consulta também pressupõe que você ativou a geração de registros do balanceador de carga de aplicativo externo, conforme descrito nas instruções fornecidas pelo link Ativar na ferramenta de escopo de registro.

Análise de registros

SELECT
  timestamp,
  http_request.remote_ip,
  http_request.request_method,
  http_request.status,
  JSON_VALUE(json_payload.enforcedSecurityPolicy.name) AS security_policy_name,
  JSON_VALUE(resource.labels.backend_service_name) AS backend_service_name,
  http_request.request_url,
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="http_load_balancer"
  AND JSON_VALUE(json_payload.statusDetails) = "denied_by_security_policy"
ORDER BY
  timestamp DESC

BigQuery

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

Existe algum vírus ou malware de alta gravidade detectado pelo Cloud IDS?

A consulta a seguir mostra todos os vírus ou malwares de alta gravidade detectados pelo Cloud IDS pesquisando Registros de ameaças do Cloud IDS. Nessa consulta, presumimos que você tenha um endpoint do Cloud IDS configurado.

Análise de registros

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

BigQuery

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", "CRITICAL")
  AND jsonPayload.type = "virus"
ORDER BY 
  timestamp DESC

Quais são os principais domínios consultados do Cloud DNS da sua rede VPC?

A consulta a seguir lista os 10 principais domínios consultados do Cloud DNS das suas redes VPC nos últimos 60 dias. Nesta consulta, presumimos que você tenha ativado a geração de registros do Cloud DNS para suas redes VPC, conforme descrito nas instruções fornecidas pelo link Ativar na ferramenta de escopo de registros.

Análise de registros

SELECT
  JSON_VALUE(json_payload.queryName) AS query_name,
  COUNT(*) AS total_queries
FROM
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
  AND log_id="dns.googleapis.com/dns_queries"
GROUP BY
  query_name
ORDER BY
  total_queries DESC
LIMIT
  10

BigQuery

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

A seguir

• Confira como fazer streaming de registros do Google Cloud para o Splunk.

• Ingerir registros Google Cloud no Google Security Operations.

• Como exportar dados de segurança do Google Cloud para seu sistema SIEM.

• Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.