Use gcloud logging read com um filtro em cloudaudit.googleapis.com, ou execute a mesma consulta no Logs Explorer e baixe os resultados como JSON:
gcloud logging read 'logName:"cloudaudit.googleapis.com" AND timestamp>="2026-10-19T00:00:00Z" AND timestamp<"2026-10-20T00:00:00Z"'
--project=my-project --format=json > gcp_audit_1019.json
Os registros de auditoria de Atividade de Administração estão sempre ativados e são mantidos por 400 dias. Os registros de Acesso a Dados estão desativados por padrão, exceto para BigQuery, e são mantidos por 30 dias uma vez habilitados.
Os Cloud Audit Logs registram quem alterou o que nos seus projetos Google Cloud: concessões de IAM, novas chaves de conta de serviço, mudanças de firewall, VMs criadas em regiões incomuns. O Prime Core possui 140 regras de detecção para logs de auditoria do Google Cloud, mapeadas para 74 técnicas MITRE ATT&CK. Entre elas: abuso de contas na nuvem (T1078.004), credenciais extras como novas chaves de conta de serviço (T1098.001) e adulteração dos próprios logs (T1562.008).
Antes de começar
Saiba qual registro de auditoria você precisa.
| Tipo | Ativado por padrão? | Retenção | O que contém |
|---|---|---|---|
| Atividade de Administração | Sempre, não pode ser desativado | 400 dias | Configurações e mudanças de IAM |
| Evento do Sistema | Sempre | 400 dias | Ações que os sistemas do Google executaram em seus recursos |
| Acesso a Dados | Não (exceto BigQuery) | 30 dias | Leituras de dados e metadados |
| Política Negada | Yes | 30 dias | Solicitações bloqueadas por políticas de segurança |
Se a pergunta é “quem leu este bucket?” e os registros de Acesso a Dados nunca foram ativados, a resposta não está no Cloud Logging.
Permissões. Logs Viewer (roles/logging.viewer) cobre Atividade de Administração, Evento do Sistema e Política Negada. Os registros de Acesso a Dados precisam de Private Logs Viewer (roles/logging.privateLogViewer).
Escopo. Os registros de auditoria vivem por projeto. As atividades no nível da organização e da pasta possuem seus próprios registros. Consulte-os com –organization=<ORG_ID> ou –folder=<FOLDER_ID> em vez de –project.
Opção 1: Logs Explorer
Na console, abra Logging → Logs Explorer, insira logName:”cloudaudit.googleapis.com”, defina o intervalo de tempo, execute a consulta e baixe os resultados como JSON. O download tem um limite. Para intervalos maiores, use gcloud.
Opção 2: gcloud logging read
O comando no topo é a forma básica. Três detalhes economizam tempo.
Sempre coloque a janela de tempo no filtro. Sem uma condição de timestamp, o gcloud logging read limita-se silenciosamente ao último dia (–freshness padrão é 1d). Isso surpreende quase todos uma vez.
Aumente o limite quando necessário. Adicione –limit=100000 (ou o que for adequado) para janelas grandes.
Achatar para upload. A saída é um array JSON. Transforme-o em uma entrada por linha:
jq -c '.[]' gcp_audit_1019.json > gcp_audit_1019.jsonl
Filtros mais restritos úteis:
# Apenas Atividade de Administração
logName="projects/my-project/logs/cloudaudit.googleapis.com/activity"
# novas chaves de conta de serviço
protoPayload.methodName="google.iam.admin.v1.CreateServiceAccountKey"
# tudo que uma identidade fez
protoPayload.authenticationInfo.principalEmail="suspicious-sa@my-project.iam.gserviceaccount.com"
Opção 3: Histórico em massa a partir de sinks
Se sua organização roteia logs de auditoria por meio de um sink para o Cloud Storage ou BigQuery, essa cópia pode voltar mais no tempo do que os buckets acima. Puxe os arquivos com gcloud storage cp, ou consulte o BigQuery e exporte o resultado como JSON.
O que procurar
| Método ou campo | Por que é importante |
|---|---|
| CreateServiceAccountKey | Credenciais de longa duração que um invasor pode levar |
| SetIamPolicy | Concessões de função; observe roles/owner, roles/editor e allUsers |
| UpdateSink, DeleteSink, novas exclusões | Alguém redirecionando ou silenciando logs |
| v1.compute.instances.insert em regiões incomuns | A clássica pegada de criptomining |
| Rupturas com status.code: 7 (PERMISSION_DENIED) | Credenciais roubadas avaliando o que podem fazer |
Upload, sanitize e revise no LogTotal
- Fazer upload. Abrir logtotal.com e solte o arquivo .jsonl.
- Sanitizar. [what gets masked: principal emails, project IDs, IPs, resource names]. Look it over before you continue.
- Revisar.
Quando dá errado
| Sintoma | Causa provável | Fix |
|---|---|---|
| Apenas as últimas 24 horas são retornadas | Nenhum timestamp no filtro, então –freshness=1d se aplica | Coloque a janela no filtro |
| Nenhuma entrada de Acesso a Dados | Os registros de Acesso a Dados nunca foram ativados | Esperado; ative-os para o futuro |
| PERMISSION_DENIED ao ler logs | Falta Private Logs Viewer para Acesso a Dados | Solicite roles/logging.privateLogViewer |
| Resultados param antes | Limite padrão ou explícito atingido | Aumente o –limit, ou divida a janela |
| Mudanças no nível da organização ausentes | Você consultou um projeto | Use –organization |
FAQ
Os logs do Google Workspace estão aqui?
Apenas se sua organização compartilhar dados do Workspace com o Google Cloud, e então no nível da organização.
E quanto ao GKE?
O GKE grava seus logs de auditoria do Kubernetes nos Cloud Audit Logs também