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

Last reviewed 2024-05-21 UTC

Este guia mostra aos profissionais de segurança como incorporar Google Cloud registos para utilização em estatísticas de segurança. Ao realizar análises de segurança, ajuda a sua organização a prevenir, detetar e responder a ameaças como software malicioso, phishing, ransomware e recursos mal configurados.

Este guia mostra-lhe como fazer o seguinte:

• Ativar a análise dos registos.
• Encaminhe esses registos para um único destino, consoante a ferramenta de análise de segurança que escolher, como o Log Analytics, BigQuery, Google Security Operations ou uma tecnologia de gestão de eventos e informações de segurança (SIEM) de terceiros.
• Analise esses registos para auditar a sua utilização da nuvem e detetar potenciais ameaças aos seus dados e cargas de trabalho, usando consultas de exemplo do projeto Community Security Analytics (CSA).

As informações neste guia fazem parte das Google Cloud operações de segurança autónomas, que incluem a transformação liderada pela engenharia das práticas de deteção e resposta e a análise de segurança para melhorar as suas capacidades de deteção de ameaças.

Neste guia, os registos fornecem a origem de dados a ser analisada. No entanto, pode aplicar os conceitos deste guia à análise de outros dados complementares relacionados com a segurança de Google Cloud, como conclusões de segurança do Security Command Center. O Security Command Center Premium oferece uma lista de detetores geridos atualizados regularmente, concebidos para identificar ameaças, vulnerabilidades e configurações incorretas nos seus sistemas quase em tempo real. Ao analisar estes sinais do Security Command Center e correlacioná-los com os registos carregados na sua ferramenta de análise de segurança, conforme descrito neste guia, pode obter uma perspetiva mais ampla de potenciais ameaças de segurança.

O diagrama seguinte mostra como as origens de dados de segurança, as ferramentas de estatísticas de segurança e as consultas da CSA funcionam em conjunto.

O diagrama começa com as seguintes origens de dados de segurança: registos do Cloud Logging, alterações de recursos do Cloud Asset Inventory e resultados de segurança do Security Command Center. O diagrama mostra, em seguida, estas origens de dados de segurança a serem encaminhadas para a ferramenta de estatísticas de segurança à sua escolha: Log Analytics no Cloud Logging, BigQuery, Google Security Operations ou um SIEM de terceiros. Por último, o diagrama mostra a utilização de consultas da CSA com a sua ferramenta de estatísticas para analisar os dados de segurança recolhidos.

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

Esta secção descreve os passos para configurar a análise de registos de segurança no Google Cloud. O fluxo de trabalho consiste nos três passos apresentados no diagrama seguinte e descritos nos parágrafos seguintes:

• Ative os registos: existem muitos registos de segurança disponíveis no Google Cloud. Cada registo tem informações diferentes que podem ser úteis para responder a perguntas de segurança específicas. Alguns registos, como os registos de auditoria da atividade do administrador, são ativados por predefinição. Outros têm de ser ativados manualmente porque incorrem em custos de carregamento adicionais no Cloud Logging. Por conseguinte, o primeiro passo no fluxo de trabalho é dar prioridade aos registos de segurança mais relevantes para as suas necessidades de análise de segurança e ativar individualmente esses registos específicos.

  Para ajudar a avaliar os registos em termos da visibilidade e da cobertura de deteção de ameaças que oferecem, este guia inclui uma ferramenta de âmbito de registos. Esta ferramenta mapeia cada registo para táticas e técnicas de ameaças relevantes na matriz MITRE ATT&CK® para empresas. A ferramenta também mapeia as regras de Deteção de ameaças de eventos no Security Command Center para os registos nos quais se baseiam. Pode usar a ferramenta de âmbito dos registos para avaliar os registos independentemente da ferramenta de estatísticas que usa.

• Registos de rotas: depois de identificar e ativar os registos a serem analisados, o passo seguinte é encaminhar e agregar os registos da sua organização, incluindo todas as pastas, projetos e contas de faturação contidos. A forma como encaminha os registos depende da ferramenta de estatísticas que usa.

  Este guia descreve os destinos de encaminhamento de registos comuns e mostra-lhe como usar um destino agregado do Cloud Logging para encaminhar registos ao nível da organização para um contentor de registos do Cloud Logging ou um conjunto de dados do BigQuery, consoante opte por usar o Log Analytics ou o BigQuery para análise.

• Analise os registos: depois de encaminhar os registos para uma ferramenta de estatísticas, o passo seguinte é analisar estes registos para identificar potenciais ameaças de segurança. A forma como analisa os registos depende da ferramenta de análise que usa. Se usar o Log Analytics ou o BigQuery, pode analisar os registos através de consultas SQL. Se usar o Google Security Operations, analisa os registos através de regras YARA-L. Se estiver a usar uma ferramenta SIEM de terceiros, usa a linguagem de consulta especificada por essa ferramenta.

  Neste guia, encontra consultas SQL que pode usar para analisar os registos no Log Analytics ou no BigQuery. As consultas SQL fornecidas neste guia são provenientes do projeto Community Security Analytics (CSA). O CSA é um conjunto de estatísticas de segurança fundamentais de código aberto concebido para lhe fornecer uma base de consultas e regras pré-criadas que pode reutilizar para começar a analisar os seus Google Cloud registos.

As secções seguintes fornecem informações detalhadas sobre como configurar e aplicar cada passo no fluxo de trabalho de estatísticas dos registos de segurança.

Ative os registos

O processo de ativação dos registos envolve os seguintes passos:

1. Identifique os registos de que precisa através da ferramenta de âmbito de registos neste guia.
2. Registe o filtro de registos gerado pela ferramenta de âmbito dos registos para utilização posterior ao configurar o destino do registo.
3. Ative o registo para cada tipo de registo identificado ou Google Cloud serviço. Consoante o serviço, também pode ter de ativar os registos de auditoria de acesso a dados correspondentes, conforme detalhado mais adiante nesta secção.

Identifique registos através da ferramenta de definição do âmbito dos registos

Para ajudar a identificar os registos que cumprem as suas necessidades de segurança e conformidade, pode usar a ferramenta de âmbito de registos apresentada nesta secção. Esta ferramenta fornece uma tabela interativa que apresenta registos valiosos relevantes para a segurança em várias áreas, incluindo registos de auditoria do Cloud, registos de transparência de acesso, registos de rede e vários registos da plataforma.Google Cloud Esta ferramenta mapeia cada tipo de registo para as seguintes áreas:

• MITRE ATT&CK táticas e técnicas de ameaças que podem ser monitorizadas com esse registo.
• CIS Google Cloud Computing Platform violações de conformidade que podem ser detetadas nesse registo.
• Regras de Deteção de ameaças de eventos que dependem desse registo.

A ferramenta de âmbito dos registos também gera um filtro de registos que aparece imediatamente após a tabela. À medida que identifica os registos de que precisa, selecione-os na ferramenta para atualizar automaticamente esse filtro de registos.

Os seguintes procedimentos breves explicam como usar a ferramenta de âmbito dos registos:

• Para selecionar ou remover um registo na ferramenta de âmbito do registo, clique no botão para ativar/desativar junto ao nome do registo.
• Para selecionar ou remover todos os registos, clique no botão ativar/desativar junto ao cabeçalho Tipo de registo.
• Para ver que técnicas do MITRE ATT&CK podem ser monitorizadas por cada tipo de registo, clique em junto ao cabeçalho Táticas e técnicas do MITRE ATT&CK.

Ferramenta de definição do âmbito do registo

Registe o filtro de registo

O filtro de registos gerado automaticamente pela ferramenta de âmbito dos registos contém todos os registos que selecionou na ferramenta. Pode usar o filtro tal como está ou refiná-lo ainda mais, consoante os seus requisitos. Por exemplo, pode incluir (ou excluir) recursos apenas num ou mais projetos específicos. Depois de ter um filtro de registo que cumpre os seus requisitos de registo, tem de guardar o filtro para utilização ao encaminhar os registos. Por exemplo, pode guardar o filtro num editor de texto ou guardá-lo numa variável de ambiente da seguinte forma:

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

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

   export LOG_FILTER='LOG_FILTER'
   

   Substitua LOG_FILTER pelo código do filtro de registo.

Ative os registos da plataforma específicos do serviço

Para cada um dos registos da plataforma que selecionar na ferramenta de âmbito dos registos, esses registos têm de ser ativados (normalmente ao nível do recurso) serviço a serviço. Por exemplo, os registos do Cloud DNS estão ativados ao nível da rede VPC. Da mesma forma, os registos de fluxo de VPC são ativados ao nível da sub-rede para todas as VMs na sub-rede, e os registos do registo de regras de firewall são ativados ao nível da regra de firewall individual.

Cada registo da plataforma tem as suas próprias instruções sobre como ativar o registo. No entanto, pode usar a ferramenta de âmbito de registos para abrir rapidamente as instruções relevantes para cada registo da plataforma.

Para saber como ativar o registo de um registo de plataforma específico, faça o seguinte:

1. Na ferramenta de definição do âmbito dos registos, localize o registo da plataforma que quer ativar.
2. Na coluna Ativado por predefinição, clique no link Ativar que corresponde a esse registo. O link direciona para instruções detalhadas sobre como ativar o registo para esse serviço.

Ative os registos de auditoria de acesso a dados

Como pode ver na ferramenta de âmbito de registo, os registos de auditoria de acesso a dados dos registos de auditoria do Google Cloud oferecem uma ampla cobertura de deteção de ameaças. No entanto, o volume pode ser bastante elevado. Por conseguinte, a ativação destes registos de auditoria de acesso a dados pode resultar em encargos adicionais relacionados com o carregamento, o armazenamento, a exportação e o processamento destes registos. Esta secção explica como ativar estes registos e apresenta algumas práticas recomendadas para ajudar a fazer a compensação entre o valor e o custo.

Nota: os registos de auditoria de acesso aos dados podem conter informações de identificação pessoal (PII), como identidades de chamadores e endereços IP. Tem de aplicar as definições de controlo de acesso e retenção adequadas disponíveis na sua ferramenta de estatísticas para proteger os dados de registo, reter esses dados apenas durante o tempo necessário e, em seguida, eliminar esses dados em segurança.

Os registos de auditoria de acesso a dados, exceto para o BigQuery, estão desativados por predefinição. Para configurar os registos de auditoria de acesso aos dados para Google Cloud serviços que não sejam o Google Cloud BigQuery, tem de os ativar explicitamente através da Google Cloud consola ou através da Google Cloud CLI para editar os objetos de políticas de gestão de identidade e de acesso (IAM). Quando ativa os registos de auditoria de acesso aos dados, também pode configurar os tipos de operações que são registados. Existem três tipos de registos de auditoria de acesso a dados:

• ADMIN_READ: regista operações que leem metadados ou informações de configuração.
• DATA_READ: regista operações que leem dados fornecidos pelos utilizadores.
• DATA_WRITE: regista operações que escrevem dados fornecidos pelos utilizadores.

Tenha em atenção que não pode configurar a gravação de operações ADMIN_WRITE, que são operações que escrevem metadados ou informações de configuração. As operações ADMIN_WRITE estão incluídas nos registos de auditoria da atividade do administrador dos registos de auditoria do Cloud e, por isso, não podem ser desativadas.

Prática recomendada: ative os registos de auditoria de acesso a dados ao nível da pasta ou da organização para garantir a conformidade em todos os projetos subordinados dessa pasta ou organização. Quando ativa os registos de auditoria ao nível da pasta ou da organização, a política de auditoria aplica-se a todos os projetos existentes e novos nessa pasta ou organização. Não é possível desativar essa política de auditoria ao nível do projeto.

Faça a gestão do volume de registos de auditoria de acesso aos dados

Quando ativa os registos de auditoria de acesso aos dados, o objetivo é maximizar o respetivo valor em termos de visibilidade da segurança, ao mesmo tempo que limita os custos e a sobrecarga de gestão. Para ajudar a alcançar esse objetivo, recomendamos que faça o seguinte para filtrar registos de volume elevado e valor baixo:

• Priorize os serviços relevantes, como os serviços que alojam cargas de trabalho, chaves e dados confidenciais. Para ver exemplos específicos de serviços que pode querer priorizar em relação a outros, consulte a Configuração de registo de auditoria de acesso a dados de exemplo.

• Priorize projetos relevantes, como projetos que alojam cargas de trabalho de produção, em vez de projetos que alojam ambientes de teste e de programadores. Para filtrar todos os registos de um projeto específico, adicione a seguinte expressão ao filtro de registos do seu destino. Substitua PROJECT_ID pelo ID do projeto do qual quer filtrar todos os registos:

  Projeto	Expressão de filtro de registo
  Exclua todos os registos de um determinado projeto	NOT logName =~ "^projects/PROJECT_ID"

• Priorizar um subconjunto de operações de acesso aos dados, como ADMIN_READ, DATA_READ ou DATA_WRITE, para um conjunto mínimo de operações registadas. Por exemplo, alguns serviços, como o Cloud DNS, escrevem os três tipos de operações, mas pode ativar o registo apenas para operações ADMIN_READ. Depois de configurar uma ou mais destas três operações de acesso a dados, pode querer excluir operações específicas que tenham um volume particularmente elevado. Pode excluir estas operações de volume elevado modificando o filtro de registo do destino. Por exemplo, decide ativar o registo de auditoria de acesso a dados completo, incluindo operações DATA_READ em alguns serviços de armazenamento críticos. Para excluir operações de leitura de dados de tráfego elevado específicas nesta situação, pode adicionar as seguintes expressões de filtro de registo recomendadas ao filtro de registo do destino:

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

• Priorize os recursos relevantes, como os recursos que alojam os seus dados e cargas de trabalho mais sensíveis. Pode classificar os seus recursos com base no valor dos dados que processam e no respetivo risco de segurança, como se são acessíveis externamente ou não. Embora os registos de auditoria de acesso a dados estejam ativados por serviço, pode filtrar recursos ou tipos de recursos específicos através do filtro de registos.

• Exclua determinados responsáveis para que os respetivos acessos aos dados não sejam registados. Por exemplo, pode isentar as suas contas de testes internos do registo das respetivas operações. Para saber mais, consulte o artigo Defina isenções na documentação dos registos de auditoria de acesso aos dados.

Nota: além de usar o filtro de registo do sink para filtrar os registos adicionais, conforme abordado nesta secção, pode querer excluir estes registos da ingestão no Cloud Logging por motivos de custo. Para impedir que estes registos sejam carregados, pode aplicar as expressões de filtro de registos indicadas nesta secção como filtros de exclusão no destino _Default predefinido que encaminha registos (incluindo registos de auditoria de acesso a dados) para o _Default contentor de registos. Os filtros de exclusão têm o efeito oposto ao de um filtro de registo, que é um filtro de inclusão. Assim, quando configurar estas expressões como filtros de exclusão, tem de remover o operador booleano NOT das expressões de filtro apresentadas nesta secção.

Exemplo de configuração do registo de auditoria de acesso a dados

A tabela seguinte fornece uma configuração de registo de auditoria de acesso a dados de base que pode usar para Google Cloud projetos de modo a limitar os volumes de registos e, ao mesmo tempo, obter uma visibilidade de segurança valiosa:

Nível	Serviços	Tipos de registos 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 Escalamento de privilégios
Serviços de armazenamento	BigQuery (ativado por predefinição) Cloud Storage^1, 2	DATA_READ DATA_WRITE	Recolha Exfiltração
Serviços de infraestrutura	Compute Engine Política da organização	ADMIN_READ	Descoberta

¹ A ativação dos registos de auditoria de acesso aos dados para o IAP ou o Cloud Storage pode gerar grandes volumes de registos quando existe um tráfego elevado para recursos Web protegidos pelo IAP ou para objetos do Cloud Storage.

² A ativação dos registos de auditoria de acesso a dados para o Cloud Storage pode interromper a utilização de transferências autenticadas do navegador para objetos não públicos. Para ver mais detalhes e soluções alternativas sugeridas para este problema, consulte o guia de resolução de problemas do Cloud Storage.

Na configuração de exemplo, repare como os serviços estão agrupados em níveis de sensibilidade com base nos respetivos dados, metadados ou configuração subjacentes. Estes níveis demonstram a seguinte granularidade recomendada do registo de auditoria de acesso a dados:

• Serviços de autenticação e autorização: para este nível de serviços, recomendamos a auditoria de todas as operações de acesso aos dados. Este nível de auditoria ajuda a monitorizar o acesso às suas chaves, segredos e políticas de IAM confidenciais. A monitorização deste acesso pode ajudar a detetar táticas do MITRE ATT&CK, como Descoberta, Acesso a credenciais e Aumento de privilégios.
• Serviços de armazenamento: para este nível de serviços, recomendamos a auditoria das operações de acesso a dados que envolvem dados fornecidos pelos utilizadores. Este nível de auditoria ajuda a monitorizar o acesso aos seus dados valiosos e confidenciais. A monitorização deste acesso pode ajudar a detetar táticas do MITRE ATT&CK, como recolha e exfiltração, contra os seus dados.
• Serviços de infraestrutura: para este nível de serviços, recomendamos a auditoria das operações de acesso a dados que envolvem metadados ou informações de configuração. Este nível de auditoria ajuda a monitorizar a procura de configuração da infraestrutura. A monitorização deste acesso pode ajudar a detetar táticas do MITRE ATT&CK, como a descoberta, contra as suas cargas de trabalho.

Registos de rotas

Depois de identificar e ativar os registos, o passo seguinte é encaminhá-los para um único destino. O destino, o caminho e a complexidade do encaminhamento variam consoante as ferramentas de estatísticas que usa, conforme mostrado no diagrama seguinte.

O diagrama mostra as seguintes opções de planeamento de trajeto:

• Se usar o Log Analytics, precisa de um destinatário agregado para agregar os registos de toda a sua Google Cloud organização num único contentor do Cloud Logging.

• Se usar o BigQuery, precisa de um destino agregado para agregar os registos de toda a sua organização num único conjunto de dados do BigQuery. Google Cloud

• Se usar o Google Security Operations e este subconjunto predefinido de registos satisfizer as suas necessidades de análise de segurança, pode agregar automaticamente estes registos na sua conta do Google Security Operations através do carregamento incorporado do Google Security Operations. Também pode ver este conjunto predefinido de registos consultando a coluna Exportável diretamente para o Google Security Operations da ferramenta de âmbito dos registos. Para mais informações sobre a exportação destes registos predefinidos, consulte o artigo Carregue Google Cloud registos para o Google Security Operations.

• Se usar o BigQuery ou um SIEM de terceiros, ou quiser exportar um conjunto expandido de registos para o Google Security Operations, o diagrama mostra que é necessário um passo adicional entre a ativação dos registos e a respetiva análise. Este passo adicional consiste em configurar um destino agregado que encaminha os registos selecionados de forma adequada. Se estiver a usar o BigQuery, este destino é tudo o que precisa para encaminhar os registos para o BigQuery. Se estiver a usar um SIEM de terceiros, tem de fazer com que o destino agregue os registos selecionados no Pub/Sub ou no Cloud Storage antes de os registos poderem ser extraídos para a sua ferramenta de estatísticas.

Nota: se usar o Log Analytics (ou o BigQuery) e já tiver configurado um destino agregado para armazenar registos num contentor de registos central (ou num conjunto de dados do BigQuery central), pode ignorar esta secção do guia e, em alternativa, basta atualizar o destino com o filtro de registos da secção anterior. No caso do Log Analytics, certifique-se de que atualiza o contentor de registos existente para usar o Log Analytics.

As opções de encaminhamento para o Google Security Operations e um SIEM de terceiros não são abordadas neste guia. No entanto, as secções seguintes fornecem os passos detalhados para encaminhar os registos para o Log Analytics ou o BigQuery:

1. Configure um único destino
2. Crie um destino de registo agregado.
3. Conceda acesso ao lavatório.
4. Configure o acesso de leitura ao destino.
5. Verifique se os registos são encaminhados para o destino.

Configure um único destino

Análise de registos

Nota: pode ignorar este passo se usar um contentor do Cloud Logging que já exista no projeto Google Cloud onde quer agregar os registos. Pode usar o content_id_bucket, mas recomendamos que crie um content_id_bucket separado para este exemplo de utilização.

_Default

1. Abra a Google Cloud consola no Google Cloud projeto no qual quer agregar registos.

   Aceda à Google Cloud consola

2. Num terminal do Cloud Shell, execute o seguinte comando gcloud para criar um contentor de registos:

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

   Substitua o seguinte:

   • PROJECT_ID: o ID do projeto Google Cloud onde os registos agregados vão ser armazenados.
   • BUCKET_NAME: o nome do novo contentor de registo.

   • BUCKET_LOCATION: a localização geográfica do novo contentor de registo. As localizações suportadas são global, us ou eu. Para saber mais sobre estas regiões de armazenamento, consulte o artigo Regiões suportadas. Se não especificar uma localização, é usada a região global, o que significa que os registos podem estar fisicamente localizados em qualquer uma das regiões.

     Nota: depois de criar o seu contentor, não pode alterar a região do mesmo.

3. Verifique se o contentor foi criado:

   gcloud logging buckets list --project=PROJECT_ID
   

4. (Opcional) Defina o período de retenção dos registos no contentor. O exemplo seguinte prolonga a retenção dos registos armazenados no contentor para 365 dias:

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

5. Atualize o novo contentor para usar o Log Analytics seguindo estes passos.

BigQuery

1. Abra a Google Cloud consola no Google Cloud projeto no qual quer agregar registos.

   Aceda à Google Cloud consola

2. Num terminal do Cloud Shell, execute o seguinte comando bq mk para criar um conjunto de dados:

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

   Substitua o seguinte:

   • PROJECT_ID: o ID do Google Cloud projeto onde os registos agregados vão ser 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, não é possível alterar a localização.

     Nota: se escolher UE ou uma região baseada na UE para a localização do conjunto de dados, os seus dados de clientes principais do BigQuery residem na UE. Os dados do cliente do BigQuery Core são definidos nos Termos Específicos do Serviço.

   • PARTITION_EXPIRATION: o tempo de vida predefinido (em segundos) para as partições nas tabelas particionadas criadas pelo destino do registo. Configura o destino do registo na secção seguinte. O destino do registo que configurar usa tabelas particionadas por dia com base na data/hora da entrada do registo. As partições (incluindo as entradas de registo associadas) são eliminadas PARTITION_EXPIRATION segundos após a data da partição.

     Prática recomendada: defina a propriedade de expiração da partição predefinida do conjunto de dados com base nos requisitos de retenção de registos para que os registos mais antigos envelheçam e expirem. Pode fazê-lo durante ou depois de criar o conjunto de dados. Isto permite-lhe reter registos durante o tempo necessário, ao mesmo tempo que limita o tamanho total do armazenamento de registos e o custo associado. Se tiver requisitos de retenção mais detalhados com base no tipo de registo, pode substituir esta propriedade ao nível da tabela depois de o destino de registos ter começado a encaminhar registos e ter criado as tabelas particionadas correspondentes. Por exemplo, pode ter de manter os dados dos registos de auditoria do Cloud durante três anos, mas os registos de regras de firewall e os registos de fluxos da VPC só têm de ser mantidos durante 90 dias. Se não definir uma data de validade da partição predefinida ao nível do conjunto de dados e não definir uma data de validade da partição quando a tabela é criada, as partições nunca expiram

Crie um destino de registo agregado

Encaminha os registos da sua organização para o destino criando um destino agregado ao nível da organização. Para incluir todos os registos que selecionou na ferramenta de âmbito dos registos, configure o destino com o filtro de registos gerado pela ferramenta de âmbito dos registos.

Nota: o encaminhamento de registos para este novo destino não significa que os seus registos sejam redirecionados para ele. Em alternativa, os registos são armazenados duas vezes: uma vez no projeto principal e, em seguida, novamente no novo destino. Google Cloud Para evitar esta duplicação do armazenamento dos seus registos, adicione um filtro de exclusão ao _Defaultdestino de cada projeto secundário Google Cloud na sua organização. Para impedir que os registos sejam carregados para os destinos _Default de projetos futuros Google Cloud na sua organização, desative o destino _Default nas predefinições da sua organização.

Análise de registos

1. Num terminal do Cloud Shell, execute o seguinte comando gcloud para criar um destino agregado ao 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 o seguinte:

   • SINK_NAME: o nome do coletor que encaminha os registos.
   • PROJECT_ID: o ID do Google Cloud projeto onde os registos agregados vão ser armazenados.
   • BUCKET_LOCATION: a localização do contentor de registo que criou para o armazenamento de registos.
   • BUCKET_NAME: o nome do contentor do Logging que criou para o armazenamento de registos.
   • LOG_FILTER: o filtro de registo que guardou a partir da ferramenta de âmbito do registo.
   • ORGANIZATION_ID: o ID do recurso da sua organização.

   A flag --include-children é importante para que os registos de todos os projetos na sua organização também sejam incluídos.Google Cloud Para mais informações, consulte o artigo Recolha e encaminhe registos ao nível da organização para destinos suportados.

2. Verifique se o destino foi criado:

   gcloud logging sinks list --organization=ORGANIZATION_ID
   

3. Obtenha o nome da conta de serviço associada ao destino que acabou de criar:

   gcloud logging sinks describe SINK_NAME --organization=ORGANIZATION_ID
   

   O resultado tem um aspeto semelhante ao seguinte:

   writerIdentity: serviceAccount:[e-mail]`
   

4. Copie a string completa para writerIdentity, começando por serviceAccount:. Este identificador é a conta de serviço do destino. Até conceder acesso de escrita à conta de serviço ao contentor de registos, o encaminhamento de registos a partir deste ponto de recolha falha. Concede acesso de escrita à identidade do escritor do destino na secção seguinte.

BigQuery

1. Num terminal do Cloud Shell, execute o seguinte comando gcloud para criar um destino agregado ao 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 o seguinte:

   • SINK_NAME: o nome do coletor que encaminha os registos.
   • PROJECT_ID: o ID do projeto Google Cloud no qual quer agregar os registos.
   • DATASET_ID: o ID do conjunto de dados do BigQuery que criou.
   • LOG_FILTER: o filtro de registo que guardou a partir da ferramenta de âmbito do registo.
   • ORGANIZATION_ID: o ID do recurso da sua organização.

   A flag --include-children é importante para que os registos de todos os projetos na sua organização também sejam incluídos.Google Cloud Para mais informações, consulte o artigo Recolha e encaminhe registos ao nível da organização para destinos suportados.

   A flag --use-partitioned-tables é importante para que os dados sejam particionados por dia com base no campo timestamp da entrada de registo. Isto simplifica a consulta dos dados e ajuda a reduzir os custos das consultas, diminuindo a quantidade de dados analisados pelas consultas. Outra vantagem das tabelas particionadas é que pode definir uma data de validade da partição predefinida ao nível do conjunto de dados para cumprir os seus requisitos de retenção de registos. Já definiu uma expiração da partição predefinida quando criou o destino do conjunto de dados na secção anterior. Também pode optar por definir uma expiração da partição ao nível da tabela individual, o que lhe permite ter controlos de retenção de dados detalhados com base no tipo de registo.

2. Verifique se o destino foi criado:

   gcloud logging sinks list --organization=ORGANIZATION_ID
   

3. Obtenha o nome da conta de serviço associada ao destino que acabou de criar:

   gcloud logging sinks describe SINK_NAME --organization=ORGANIZATION_ID
   

   O resultado tem um aspeto semelhante ao seguinte:

   writerIdentity: serviceAccount:[e-mail]`
   

4. Copie a string completa para writerIdentity, começando por serviceAccount:. Este identificador é a conta de serviço do destino. Até conceder acesso de escrita à conta de serviço ao conjunto de dados do BigQuery, o encaminhamento de registos a partir deste destino vai falhar. Concede acesso de escrita à identidade do escritor do destino na secção seguinte.

Conceda acesso ao lavatório

Depois de criar o destino do registo, tem de conceder ao destino acesso para escrever no respetivo destino, quer seja o contentor de registos ou o conjunto de dados do BigQuery.

Nota: para encaminhar registos para um recurso protegido por um perímetro de serviço>, também tem de adicionar a conta de serviço desse destino a um nível de acesso e, em seguida, atribuí-la ao perímetro de serviço de destino. Isto não é necessário para os destinos não agregados. Para ver detalhes, consulte o artigo VPC Service Controls: Cloud Logging.

Análise de registos

Para adicionar as autorizações à conta de serviço do destino, siga estes passos:

1. Na Google Cloud consola, aceda à página IAM:

   Aceda à página IAM

2. Certifique-se de que selecionou o projeto Google Cloud de destino que contém o contentor de registos que criou para o armazenamento central de registos.

3. Clique em Conceder acesso.

4. No campo Novos membros, introduza a conta de serviço do destino sem o prefixo serviceAccount:. Recorde que esta identidade provém do campo writerIdentity que recuperou na secção anterior depois de criar o destino.

5. No menu pendente Selecionar uma função, selecione Logs Bucket Writer.

6. Clique em Adicionar condição do IAM para restringir o acesso da conta de serviço apenas ao contentor de registos que criou.

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

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

9. No menu pendente Operador, selecione Termina com.

10. No campo Valor, introduza a localização e o nome do contentor da seguinte forma:

    locations/BUCKET_LOCATION/buckets/BUCKET_NAME
    

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

12. Clique em Guardar para definir as autorizações.

BigQuery

Para adicionar as autorizações à conta de serviço do destino, siga estes passos:

1. Na Google Cloud consola, aceda ao BigQuery:

   Aceda ao BigQuery

2. Abra o conjunto de dados do BigQuery que criou para o armazenamento central de registos.

3. No separador Informações do conjunto de dados, clique no menu pendente Partilha e, de seguida, clique em Autorizações.

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

5. No campo Novos membros, introduza a conta de serviço do destino sem o prefixo serviceAccount:. Recorde que esta identidade provém do campo writerIdentity que recuperou na secção anterior depois de criar o destino.

6. No menu pendente Função, selecione Editor de dados do BigQuery.

7. Clique em Guardar.

Depois de conceder acesso ao destino, as entradas do registo começam a preencher o destino: o contentor do Logging ou o conjunto de dados do BigQuery.

Configure o acesso de leitura ao destino

Agora que o destino do registo encaminha os registos de toda a sua organização para um único destino, pode pesquisar em todos estes registos. Use as autorizações de IAM para gerir autorizações e conceder acesso conforme necessário.

Análise de registos

Para conceder acesso à visualização e consulta dos registos no novo contentor de registos, siga estes passos.

1. Na Google Cloud consola, aceda à página IAM:

   Aceda à página IAM

   Certifique-se de que selecionou o Google Cloud projeto que está a usar para agregar os registos.

2. Clique em Adicionar.

3. No campo Novo principal, adicione a sua conta de email.

4. No menu pendente Selecionar uma função, selecione Acesso ao visualizador de registos.

   Esta função concede ao principal recém-adicionado acesso de leitura a todas as vistas para quaisquer contentores no Google Cloud projeto. Para limitar o acesso de um utilizador, adicione uma condição que permita ao utilizador ler apenas a partir do novo contentor.

   1. Clique em Adicionar condição.

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

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

   4. No menu pendente Operador, selecione Termina com.

   5. No campo Valor, introduza a localização e o nome do contentor, e a vista de registo predefinida _AllLogs da seguinte forma:

      locations/BUCKET_LOCATION/buckets/BUCKET_NAME/views/_AllLogs
      

      Nota: o Cloud Logging cria automaticamente a vista _AllLogs para cada contentor, que mostra todos os registos no contentor. Para ter um controlo mais detalhado sobre os registos que podem ser vistos e consultados nesse contentor de registos, pode criar e usar uma vista de registos personalizada em vez de _AllLogs.

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

5. Clique em Guardar para definir as autorizações.

BigQuery

Para conceder acesso à visualização e consulta dos registos no seu conjunto de dados do BigQuery, siga os passos na secção Conceder acesso a um conjunto de dados da documentação do BigQuery.

Verifique se os registos são encaminhados para o destino

Análise de registos

Quando encaminha registos para um contentor de registos atualizado para o Log Analytics, pode ver e consultar todas as entradas de registo através de uma única vista de registos com um esquema unificado para todos os tipos de registos. Siga estes passos para verificar se os registos são encaminhados corretamente.

1. Na Google Cloud consola, aceda à página Log Analytics:

   Aceda ao Log Analytics

   Certifique-se de que selecionou o Google Cloud projeto que está a usar para agregar os registos.

2. Clique no separador Visualizações de registo.

3. Expanda as visualizações de registos no contentor de registos que criou (ou seja, BUCKET_NAME) se ainda não estiverem expandidas.

4. Selecione a vista de registo predefinida _AllLogs. Agora, pode inspecionar todo o esquema de registo no painel direito, como mostrado na captura de ecrã seguinte:

   

5. Junto a _AllLogs, clique em Consulta . Isto preenche o editor Query com uma consulta de exemplo SQL para obter entradas de registo encaminhadas recentemente.

6. Clique em Executar consulta para ver as entradas de registo encaminhadas recentemente.

Consoante o nível de atividade nos Google Cloud projetos da sua organização, pode ter de aguardar alguns minutos até que alguns registos sejam gerados e, em seguida, encaminhados para o seu contentor de registos.

BigQuery

Quando encaminha registos para um conjunto de dados do BigQuery, o Cloud Logging cria tabelas do BigQuery para conter as entradas do registo, conforme mostrado na captura de ecrã seguinte:

A captura de ecrã mostra como o Cloud Logging atribui nomes a cada tabela do BigQuery com base no nome do registo ao qual uma entrada de registo pertence. Por exemplo, a tabela cloudaudit_googleapis_com_data_access selecionada na captura de ecrã contém registos de auditoria de acesso aos dados cujo ID do registo é cloudaudit.googleapis.com%2Fdata_access. Além de terem nomes baseados na entrada de registo correspondente, cada tabela também é particionada com base nas datas/horas de cada entrada de registo.

Consoante o nível de atividade nos Google Cloud projetos da sua organização, pode ter de aguardar alguns minutos até que sejam gerados alguns registos e, em seguida, encaminhados para o seu conjunto de dados do BigQuery.

Nota: os registos de atividade do administrador e de acesso aos dados são carregados no BigQuery com o respetivo campo de entrada do registo protoPayload renomeado para protoPayload_auditlog no BigQuery. Para mais informações sobre as conversões de esquemas efetuadas pelo Cloud Logging antes da gravação no BigQuery, consulte o artigo Campos nos registos de auditoria exportados.

Analise registos

Pode executar uma vasta gama de consultas nos registos de auditoria e da plataforma. A lista seguinte apresenta um conjunto de exemplos de perguntas de segurança que pode querer fazer aos seus próprios registos. Para cada pergunta nesta lista, existem duas versões da consulta CSA correspondente: uma para utilização com o Log Analytics e outra para utilização com o BigQuery. Use a versão da consulta que corresponde ao destino de sincronização que configurou anteriormente.

Análise de registos

Antes de usar qualquer uma das consultas SQL abaixo, substitua MY_PROJECT_ID pelo ID do projeto onde criou o contentor de registos (ou seja, PROJECT_ID)) e MY_DATASET_ID pela região e pelo nome desse contentor de registos (ou seja, BUCKET_LOCATION.BUCKET_NAME). Google Cloud

Aceda ao Log Analytics

BigQuery

Antes de usar qualquer uma das consultas SQL abaixo, substitua MY_PROJECT_ID pelo ID do projeto Google Cloud onde criou o conjunto de dados do BigQuery (ou seja, PROJECT_ID)) e MY_DATASET_ID pelo nome desse conjunto de dados (ou seja, DATASET_ID).

Aceda ao BigQuery

1. Perguntas sobre início de sessão e acesso
   • Alguma tentativa de início de sessão suspeita foi denunciada pelo Google Workspace?
   • Falhas de início de sessão excessivas de qualquer identidade de utilizador?
   • Alguma tentativa de acesso que viole os VPC Service Controls?
   • Alguma tentativa de acesso que viole os controlos de acesso do Identity-Aware Proxy?
2. Perguntas sobre alterações de autorizações
   • Algum utilizador foi adicionado a grupos com privilégios elevados?
   • Existem autorizações concedidas numa conta de serviço?
   • Quaisquer contas de serviço ou chaves criadas por uma identidade não aprovada?
   • Algum utilizador foi adicionado (ou removido) de uma política de IAM sensível?
3. Perguntas sobre a atividade de aprovisionamento
   • Foram feitas alterações às definições de registo?
   • Algum registo de fluxo da VPC desativado?
   • Existe um número invulgar de regras de firewall modificadas na última semana?
   • Alguma MV foi eliminada na semana passada?
4. Perguntas sobre a utilização da carga de trabalho
   • Algum utilizador usou a API de forma invulgarmente elevada na semana passada?
   • Qual é a utilização do dimensionamento automático por dia no último mês?
5. Perguntas sobre o acesso aos dados
   • Que utilizadores acederam aos dados com mais frequência na semana passada?
   • Que utilizadores acederam aos dados na tabela "accounts" no mês passado?
   • Que tabelas são acedidas com mais frequência e por quem?
   • Quais são as 10 principais consultas ao BigQuery na última semana?
   • Quais são as ações mais comuns registadas no registo de acesso aos dados no último mês?
6. Perguntas sobre segurança de redes
   • Existem ligações de um novo endereço IP a uma sub-rede específica?
   • Existem ligações bloqueadas pelo Google Cloud Armor?
   • Algum vírus ou software malicioso de gravidade elevada detetado pelo Cloud IDS?
   • Quais são os principais domínios consultados do Cloud DNS a partir da sua rede VPC?

Perguntas sobre o início de sessão e o acesso

Estas consultas de exemplo realizam análises para detetar tentativas de início de sessão suspeitas ou tentativas de acesso iniciais ao seu ambiente Google Cloud .

Nota: a atividade de início de sessão é capturada nos registos do Cloud ID incluídos na auditoria de início de sessão do Google Workspace. Para analisar a atividade de início de sessão e usar algumas das consultas nesta secção, tem de ativar a partilha de dados do Google Workspace com o Google Cloud. Para saber mais sobre a partilha de registos de auditoria do Google Workspace com o Google Cloud, consulte o artigo Veja e faça a gestão dos registos de auditoria do Google Workspace.

Alguma tentativa de início de sessão suspeita foi denunciada pelo Google Workspace?

Ao pesquisar registos do Cloud Identity que fazem parte da auditoria de início de sessão do Google Workspace, a seguinte consulta deteta tentativas de início de sessão suspeitas denunciadas pelo Google Workspace. Essas tentativas de início de sessão podem ser provenientes da consola do Google Cloud , da consola do administrador ou da CLI gcloud.

Análise de registos

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"

Falhas de início de sessão excessivas de qualquer identidade de utilizador?

Ao pesquisar registos do Cloud ID que fazem parte da auditoria de início de sessão do Google Workspace, a seguinte consulta deteta utilizadores que tiveram três ou mais falhas de início de sessão sucessivas nas últimas 24 horas.

Análise de registos

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 que viole os VPC Service Controls?

Ao analisar os registos de auditoria de políticas negadas dos registos de auditoria do Cloud, a seguinte consulta deteta tentativas de acesso bloqueadas pelos VPC Service Controls. Os resultados de qualquer consulta podem indicar uma potencial atividade maliciosa, como tentativas de acesso a partir de redes não autorizadas com credenciais roubadas.

Análise de registos

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

Existem tentativas de acesso que violam os controlos de acesso do IAP?

Ao analisar os registos do Application Load Balancer externo, a seguinte consulta deteta tentativas de acesso bloqueadas pelo IAP. Quaisquer resultados da consulta podem indicar uma tentativa de acesso inicial ou uma tentativa de exploração de vulnerabilidades.

Análise de registos

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 alterações de autorizações

Estas consultas de exemplo realizam análises sobre a atividade do administrador que altera as autorizações, incluindo alterações nas políticas de IAM, nos grupos e nas associações de grupos, nas contas de serviço e em quaisquer chaves associadas. Essas alterações às autorizações podem fornecer um nível elevado de acesso a dados ou ambientes confidenciais.

Nota: as alterações aos grupos são captadas na auditoria do administrador do Google Workspace. Para analisar a atividade de alterações de grupos e usar algumas das consultas nesta secção, tem de ativar a partilha de dados do Google Workspace com o Google Cloud. Para saber mais sobre a partilha de registos de auditoria do Google Workspace com o Google Cloud, consulte o artigo Veja e faça a gestão dos registos de auditoria do Google Workspace.

Algum utilizador foi adicionado a grupos com privilégios elevados?

Ao analisar os registos de auditoria do Google Workspace Admin Audit, a seguinte consulta deteta utilizadores que foram adicionados a qualquer um dos grupos com privilégios elevados indicados na consulta. Usa a expressão regular na consulta para definir que grupos (como [e-mail] ou [e-mail]) monitorizar. Os resultados de qualquer consulta podem indicar uma escalada de privilégios maliciosa ou acidental.

Análise de registos

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
  )

Existem autorizações concedidas a uma conta de serviço?

Ao analisar os registos de auditoria da atividade do administrador dos registos de auditoria do Cloud, a seguinte consulta deteta todas as autorizações que foram concedidas a qualquer principal numa conta de serviço. Seguem-se exemplos de autorizações que podem ser concedidas: a capacidade de usar a identidade dessa conta de serviço ou criar chaves de contas de serviço. Quaisquer resultados de consultas podem indicar uma instância de escalada de privilégios ou um risco de roubo de credenciais.

Análise de registos

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

Existem contas de serviço ou chaves criadas por uma identidade não aprovada?

Ao analisar os registos de auditoria da atividade de administrador, a seguinte consulta deteta contas de serviço ou chaves que foram criadas manualmente por um utilizador. Por exemplo, pode seguir uma prática recomendada para permitir que apenas uma conta de serviço aprovada crie contas de serviço como parte de um fluxo de trabalho automatizado. Por conseguinte, qualquer criação de conta de serviço fora desse fluxo de trabalho é considerada não conforme e possivelmente maliciosa.

Análise de registos

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 utilizador foi adicionado (ou removido) de uma política de IAM sensível?

Ao pesquisar nos registos de auditoria da atividade do administrador, a seguinte consulta deteta qualquer alteração de acesso de utilizador ou grupo para um recurso protegido pelo IAP, como um serviço de back-end do Compute Engine. A consulta seguinte pesquisa todas as atualizações de políticas de IAM para recursos do IAP que envolvam a função de IAM roles/iap.httpsResourceAccessor. Esta função concede autorizações para aceder ao recurso HTTPS ou ao serviço de back-end. Quaisquer resultados de consultas podem indicar tentativas de contornar as defesas de um serviço de back-end que possa estar exposto à Internet.

Análise de registos

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 a atividade de aprovisionamento

Estes exemplos de consultas realizam análises para detetar atividade de administrador suspeita ou anómala, como o aprovisionamento e a configuração de recursos.

Foram feitas alterações às definições de registo?

Ao pesquisar os registos de auditoria da atividade do administrador, a seguinte consulta deteta qualquer alteração feita às definições de registo. A monitorização das definições de registo ajuda a detetar a desativação acidental ou maliciosa dos registos de auditoria e técnicas semelhantes de evasão de defesa.

Análise de registos

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"

Algum registo de fluxo da VPC ativamente desativado?

Ao pesquisar os registos de auditoria da atividade do administrador, a seguinte consulta deteta qualquer sub-rede cujos registos de fluxo da VPC foram ativamente desativados . A monitorização das definições dos registos de fluxo da VPC ajuda a detetar a desativação acidental ou maliciosa dos registos de fluxo da VPC e técnicas de evasão de defesa semelhantes.

Análise de registos

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"

Existe um número invulgarmente elevado de regras de firewall modificadas na última semana?

Ao pesquisar os registos de auditoria da atividade de administrador, a seguinte consulta deteta um número invulgarmente elevado de alterações às regras da firewall num determinado dia da semana passada. Para determinar se existe um valor atípico, a consulta realiza uma análise estatística das contagens diárias de alterações às regras da firewall. As médias e os desvios padrão são calculados para cada dia com base nas contagens diárias anteriores com um período de análise de 90 dias. Um valor atípico é 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 os períodos de análise, pode ser configurada para se adequar ao seu perfil de atividade de aprovisionamento na nuvem e minimizar os falsos positivos.

Análise de registos

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 eliminada na semana anterior?

Ao pesquisar registos de auditoria da atividade de administrador, a seguinte consulta apresenta uma lista de todas as instâncias do Compute Engine eliminadas na semana passada. Esta consulta pode ajudar a auditar as eliminações de recursos e a detetar potencial atividade maliciosa.

Análise de registos

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 acerca da utilização de cargas de trabalho

Estas consultas de exemplo realizam análises para compreender quem e o que está a consumir as suas cargas de trabalho na nuvem e APIs, e ajudam a detetar potenciais comportamentos maliciosos interna ou externamente.

Algum utilizador usou a API de forma invulgarmente elevada na semana passada?

Ao analisar todos os registos de auditoria da nuvem, a seguinte consulta deteta uma utilização da API invulgarmente elevada por qualquer identidade de utilizador num determinado dia da semana passada. Esta utilização invulgarmente elevada pode ser um indicador de potencial abuso de API, ameaça interna ou credenciais roubadas. Para determinar se existe um valor atípico, esta consulta realiza uma análise estatística sobre a contagem diária de ações por diretor. As médias e os desvios padrão são calculados para cada dia e para cada diretor com base nas contagens diárias anteriores com um período de análise de 60 dias. Um valor atípico é considerado quando a contagem diária de um utilizador está mais de três desvios padrão acima da respetiva média. A consulta, incluindo o fator de desvio padrão e os períodos de análise, são todos configuráveis para se ajustarem ao seu perfil de atividade de aprovisionamento na nuvem e para minimizar os falsos positivos.

Análise de registos

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 é a utilização do ajuste automático por dia no último mês?

Ao analisar os registos de auditoria da atividade do administrador, a consulta seguinte comunica a utilização do ajuste automático por dia no último mês. Esta consulta pode ser usada para identificar padrões ou anomalias que justifiquem uma investigação de segurança mais aprofundada.

Análise de registos

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 aos dados

Estas consultas de exemplo realizam análises para compreender quem está a aceder ou a modificar dados no Google Cloud.

Que utilizadores acederam aos dados com mais frequência na semana passada?

A consulta seguinte usa os registos de auditoria de acesso aos dados para encontrar as identidades dos utilizadores que acederam com maior frequência aos dados das tabelas do BigQuery na semana passada.

Análise de registos

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

Que utilizadores acederam aos dados na tabela "accounts" no mês passado?

A consulta seguinte usa os registos de auditoria de acesso aos dados para encontrar as identidades dos utilizadores que consultaram com maior frequência uma determinada tabela accounts no último mês. Além dos marcadores de posição MY_DATASET_ID e MY_PROJECT_ID para o destino de exportação do BigQuery, a consulta seguinte usa os marcadores de posição DATASET_ID e PROJECT_ID. Tem de substituir os marcadores de posição DATASET_ID e PROJECT_ID para especificar a tabela de destino cujo acesso está a ser analisado, como a tabela accounts neste exemplo.

Análise de registos

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

Que tabelas são acedidas com mais frequência e por quem?

A consulta seguinte usa os registos de auditoria de acesso aos dados para encontrar as tabelas do BigQuery com os dados lidos e modificados com maior frequência no último mês. Apresenta a identidade do utilizador associada, juntamente com a discriminação do número total de vezes que os dados foram lidos em comparação com o número de vezes que foram modificados.

Análise de registos

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 são as 10 principais consultas ao BigQuery na semana passada?

A consulta seguinte usa os registos de auditoria de acesso aos dados para encontrar as consultas mais comuns na última semana. Também lista os utilizadores correspondentes e as tabelas referenciadas.

Análise de registos

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 são as ações mais comuns registadas no registo de acesso aos dados no último mês?

A seguinte consulta usa todos os registos dos registos de auditoria do Cloud para encontrar as 100 ações mais frequentes registadas no último mês.

Análise de registos

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 redes

Estas consultas de exemplo analisam a sua atividade de rede em Google Cloud.

Quaisquer ligações de um novo endereço IP a uma sub-rede específica?

A consulta seguinte deteta ligações de qualquer novo endereço IP de origem a uma sub-rede específica através da análise dos registos de fluxo da VPC. Neste exemplo, um endereço IP de origem é considerado novo se tiver sido visto pela primeira vez nas últimas 24 horas num período de análise de 60 dias. É aconselhável usar e ajustar esta consulta numa sub-rede que esteja no âmbito de um requisito de conformidade específico, como o PCI.

Análise de registos

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

Existem ligações bloqueadas pelo Google Cloud Armor?

A seguinte consulta ajuda a detetar potenciais tentativas de exploração através da análise dos registos do Application Load Balancer externo para encontrar qualquer ligação bloqueada pela política de segurança configurada no Google Cloud Armor. Esta consulta pressupõe que tem uma política de segurança do Google Cloud Armor configurada no seu Application Load Balancer externo. Esta consulta também pressupõe que ativou o registo do Application Load Balancer externo, conforme descrito nas instruções fornecidas pelo link Ativar na ferramenta de âmbito do registo.

Análise de registos

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

Algum vírus ou software malicioso de gravidade elevada detetado pelo Cloud IDS?

A consulta seguinte mostra qualquer vírus ou software malicioso de gravidade elevada detetado pelo Cloud IDS através da pesquisa nos registos de ameaças do Cloud IDS. Esta consulta pressupõe que tem um ponto final do Cloud IDS configurado.

Análise de registos

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 a partir da sua rede VPC?

A seguinte consulta apresenta os 10 principais domínios consultados do Cloud DNS a partir das suas redes VPC nos últimos 60 dias. Esta consulta pressupõe que ativou o registo do Cloud DNS para as suas redes VPC, conforme descrito nas instruções fornecidas pelo link Ativar na ferramenta de âmbito do registo.

Análise de registos

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

O que se segue?

• Veja como transmitir registos de Google Cloud para o Splunk.

• Carregar Google Cloud registos para o Google Security Operations.

• Exportar Google Cloud dados de segurança para o seu sistema SIEM.

• Explore arquiteturas de referência, diagramas e práticas recomendadas sobre o Google Cloud. Consulte o nosso Centro de arquitetura na nuvem.