Cibersegurança e segurança da informação

Investigação de incidentes na Google Cloud com Audit Logs e Security Command Center

6 min de leituraPublicado: 5 de agosto de 2026

Ilustração visual profissional sobre investigação de incidentes na Google Cloud na área de Cloud Security e IR

Resposta rápida

A investigação de incidentes na Google Cloud exige a conexão de identidade, Audit Logs, ações de API, recursos, regiões e sessões. Comece por preservar as provas e construir uma cronologia, e só depois implemente a contenção documentada.

A investigação na cloud exige a ligação de identidades, Control Plane, recursos, chaves, sessões e serviços de segurança. Uma vez que a atividade está distribuída por vários serviços e regiões, a cronologia e a compreensão das permissões são cruciais. Este artigo centra-se na investigação de incidentes na Google Cloud e destina-se a analistas de cloud e SOC. O objetivo é fornecer um método de trabalho que possa ser aplicado na prática, numa entrevista profissional e num ambiente de trabalho, sem se limitar a uma definição de dicionário.

O principal desafio é que os dados estão quase sempre incompletos. Os Cloud Audit Logs, principalEmail, methodName podem indicar uma direção, mas o seu significado depende do tempo, do ativo, do utilizador e da atividade esperada. Por isso, construiremos o exame em torno de uma questão de investigação, provas necessárias e um critério claro para a conclusão.

O cenário prático no artigo é: Cronologia de uma alteração de IAM e acesso a um recurso simulado. Todos os exemplos são dados de laboratório ou descrições de processos. No caso de Testes de Penetração, Web ou Cloud, deve-se trabalhar apenas com autorização explícita, um Scope definido e a capacidade de parar o teste.

Mapeamento da organização e projetos

O tópico 'Mapeamento da Organização e Projetos' é uma parte central do trabalho de investigação de incidentes na Google Cloud. Recomenda-se dividi-lo em três perguntas: Qual é a entrada, qual a decisão a tomar e que evidência é suficiente para justificá-la. Estas perguntas impedem o uso automático de ferramentas sem entender o objetivo.

Na prática, registe os Cloud Audit Logs, principalEmail, methodName, resourceName, Security Command Center, compare com o comportamento esperado e defina pelo menos um Pivot. O resultado deve ser verificável por outro analista, incluindo limitações e próximos passos.

Audit Logs

O tópico 'Audit Logs' é uma parte central do trabalho de investigação de incidentes na Google Cloud. Recomenda-se dividi-lo em três perguntas: Qual é a entrada, qual a decisão a tomar e que evidência é suficiente para justificá-la. Estas perguntas impedem o uso automático de ferramentas sem entender o objetivo.

IAM e Service accounts

O tópico 'IAM e Service accounts' é uma parte central do trabalho de investigação de incidentes na Google Cloud. Recomenda-se dividi-lo em três perguntas: Qual é a entrada, qual a decisão a tomar e que evidência é suficiente para justificá-la. Estas perguntas impedem o uso automático de ferramentas sem entender o objetivo.

Security Command Center findings

O tópico 'Security Command Center findings' é uma parte central do trabalho de investigação de incidentes na Google Cloud. Recomenda-se dividi-lo em três perguntas: Qual é a entrada, qual a decisão a tomar e que evidência é suficiente para justificá-la. Estas perguntas impedem o uso automático de ferramentas sem entender o objetivo.

Scoping, Contenção e Recuperação

A resposta a um incidente na Google Cloud deve mitigar o risco sem apagar as provas que ainda são necessárias. Comece com uma ação reversível e focada, confirme a propriedade e autoridade, e documente a hora, o executante e o resultado.

Uma correção a longo prazo aborda a causa raiz: permissões, configuração, validação, telemetria, processo ou formação. Após a implementação, realize um Reteste e monitorize os sinais de recorrência, em vez de se contentar com o fecho do Ticket.

Pontos de controlo únicos

Neste tópico, é aconselhável construir um mapa de evidências focado com antecedência. Os principais pontos de controlo são: Cloud Audit Logs, principalEmail, methodName, resourceName, Security Command Center, project/organization. A lista não é uma lista de verificação automática; cada item é escolhido porque pode ligar uma entidade, uma ação e um tempo, ou explicar um comportamento legítimo.

Cloud Audit Logs: Defina o valor esperado, o que seria considerado anómalo e qual a fonte adicional que verificaria a descoberta.
principalEmail: Defina o valor esperado, o que seria considerado anómalo e qual a fonte adicional que verificaria a descoberta.
methodName: Defina o valor esperado, o que seria considerado anómalo e qual a fonte adicional que verificaria a descoberta.
resourceName: Defina o valor esperado, o que seria considerado anómalo e qual a fonte adicional que verificaria a descoberta.
Security Command Center: Defina o valor esperado, o que seria considerado anómalo e qual a fonte adicional que verificaria a descoberta.
project/organization: Defina o valor esperado, o que seria considerado anómalo e qual a fonte adicional que verificaria a descoberta.

Quando um dos focos não está disponível, a lacuna deve ser documentada e uma alternativa escolhida. Por exemplo, se um identificador de processo não for estável, pode-se usar o tempo, Host, Utilizador e Pai; se o Payload estiver encriptado, use Metadados, volume, frequência e contexto TLS/DNS.

Processo de trabalho recomendado

Defina o Scope e uma única questão de trabalho sobre a investigação de incidentes na Google Cloud.
Registe as fontes de dados e as provas necessárias: Cloud Audit Logs, principalEmail, methodName, resourceName.
Crie uma linha de base curta de comportamento normal ou resultado esperado.
Realize o teste mínimo num ambiente de laboratório e guarde o tempo, a entrada e a saída.
Crie uma cronologia ou tabela de comparação e separe os factos da interpretação.
Execute um Pivot para uma fonte adicional para verificar ou refutar a explicação inicial.
Conclua a decisão, limitações, ação recomendada e critério de Reteste.

Cenário prático

O cenário escolhido é uma cronologia de alteração de IAM e acesso a um recurso simulado. O objetivo do exercício não é provar a capacidade de ataque, mas sim praticar a recolha, comparação e documentação de forma segura. Antes de iniciar o trabalho, são definidos dados simulados, um período de tempo e um resultado esperado.

No final do exercício, deve ser entregue um produto que um analista ou outro auditor possa rever: uma captura de ecrã ou exportação da evidência, uma cronologia curta, uma hipótese inicial, uma evidência de validação, uma limitação e uma recomendação. Quando não há evidência suficiente, a conclusão correta é que o cenário não foi provado.

Etapa	O que fazer	Produto
Preparação	Defina o Scope, tempo e objetivo. Registe quais campos ou evidências dos Cloud Audit Logs, principalEmail, methodName são esperados.	Plano de teste curto
Criação de dados	Execute uma ação segura e simulada relacionada com a investigação de incidentes na Google Cloud, sem informações reais ou impacto num sistema de produção.	Evento/Pedido/Fluxo controlado
Recolha	Recolha a evidência bruta e o contexto de uma fonte adicional. Verifique o fuso horário, identificadores e integridade.	Duas evidências ligadas
Análise	Escreva o que cada evidência prova, o que não prova e qual a explicação legítima possível.	Conclusão intermédia
Conclusão	Escolha fecho, escalamento, Finding ou Tuning; adicione recomendação e Retest.	Produto documentado

Lista de verificação prática

Verifique e documente: Principal e sessão.
Verifique e documente: Ação da API.
Verifique e documente: Recurso e região.
Verifique e documente: Endereço IP de origem e agente de utilizador.
Verifique e documente: ID do evento de auditoria.
Verifique e documente: GuardDuty/Defender/SCC finding.
Indique o fuso horário, a versão da ferramenta e a hora de recolha.
Guarde os dados brutos antes de filtrar ou alterar.
Escreva o que a descoberta prova e o que ainda é desconhecido.
Defina o proprietário e a ação de acompanhamento com um prazo.

Erros comuns

Focar-se apenas numa área.
Rodar uma chave antes de preservar a cronologia.
Não verificar AssumeRole ou Token.
Ignorar o Control Plane.
Não mapear permissões efetivas.
Inferir que a localização geográfica prova um ataque.

Resumo e CTA

A investigação de incidentes na Google Cloud com Audit Logs e Security Command Center é um tópico que conecta o conhecimento técnico à disciplina de trabalho. Comece com uma pergunta, recolha apenas evidências relevantes, preserve o contexto e o tempo, e escolha uma ação que possa ser justificada e testada novamente.

No curso Cybersecurity & AI da HPI, estes princípios são praticados usando sistemas, logs e laboratórios. O próximo passo natural é consultar os artigos relacionados, realizar o exercício de laboratório e guardar o produto como parte de um portefólio profissional.

Perguntas frequentes

A investigação de incidentes na Google Cloud por si só prova um ataque ou uma vulnerabilidade?

Não. Ela fornece um sinal ou uma descoberta que precisa de contexto, validação e uma fonte adicional. Uma conclusão profissional baseia-se numa sequência de evidências e na conformidade com o comportamento esperado.

O que fazer quando faltam alguns dados?

Documente o que falta, verifique uma fonte alternativa e reduza o nível de confiança. Não deve preencher campos por suposição nem apresentar o 'Desconhecido' como válido.

Por quanto tempo as provas devem ser guardadas?

O tempo depende da política, regulamentação, custo e tipo de incidente. É importante definir antecipadamente a Retenção, a retenção legal e a capacidade de exportar provas num formato verificável.

Como praticar sem comprometer um sistema real?

Use máquinas virtuais, dados simulados, CTF ou um laboratório dedicado. Em testes autorizados, defina o Scope, as condições de paragem e faça backup antes de iniciar o trabalho.