Deploy básico do Google SecOps no GCP
Processo oficial de onboarding - do contrato até a instância ativa com usuários e SOAR configurados via IAM
Pré-requisitos
Antes de iniciar o onboarding, sua organização precisa ter todos esses pontos atendidos.
Contrato ativo do Google SecOps assinado
Pacotes: Standard, Enterprise ou Enterprise Plus. O contrato autoriza o provisionamento da instância.
Organização Google Cloud configurada
Você precisa de uma organização GCP com permissão de criar projetos (resourcemanager.projects.create).
Conta de faturamento correta
O projeto GCP deve estar vinculado à mesma conta de faturamento usada na assinatura — contas diferentes resultam em cobrança incorreta.
SME de onboarding designado
Um responsável técnico deve ser definido — ele é quem recebe o e-mail de ativação e conduz o processo.
E-mail de ativação
Após a assinatura do contrato, o SME de onboarding recebe um e-mail com o link de ativação.
Ir para ativação no Google Cloud
Criar ou vincular um projeto GCP
Na página de ativação, você escolhe como vincular o SecOps a um projeto GCP.
Criar novo projeto
Projeto dedicado ao SecOps. Isola a telemetria de segurança e logs de auditoria dos outros recursos.
Usar projeto existente
Possível, mas revise permissões e restrições que podem afetar o comportamento da instância.
Habilitar a Chronicle API
Com o projeto selecionado, a Chronicle API precisa estar ativa para que o SecOps se comunique com o GCP.
Se a API não estiver habilitada, aparece o botão Getting Started. Preencha as informações:
Configurar o provedor de identidade (IdP)
O SecOps precisa de um IdP para gerenciar autenticação e acesso dos usuários.
Google Workspace
Mais simples se a organização já usa o ecossistema Google
Cloud Identity
IdP nativo do GCP para organizações sem Google Workspace
IdP terceiro
Okta, Azure AD etc. via Workforce Identity Federation (SAML)
Para IdP de terceiros: crie a aplicação SAML, configure o Workforce Identity Federation no GCP e mapeie os grupos para roles do SecOps após o deploy.
Adicionar usuários e configurar permissões (IAM)
O SecOps usa o Google Cloud IAM para controlar o acesso por features. Defina quem acessa e com qual nível antes de finalizar o deploy.
Roles predefinidos (SIEM)
Chronicle API Admin
roles/chronicle.adminAcesso total. Gerencia configurações, regras, feeds e controle de acesso.
Chronicle API Editor
roles/chronicle.editorCria e edita regras, feeds e configurações operacionais. Sem controle de acesso.
Chronicle API Viewer
roles/chronicle.viewerSomente leitura. Investigações, buscas e dashboards, sem modificar nada.
Chronicle Restricted Viewer
roles/chronicle.restrictedViewerViewer sem acesso a regras de detecção e reference lists.
Conceder acesso via gcloud CLI
--role roles/chronicle.viewer \
--member "group:soc-analysts@empresa.com"
Migrar o SOAR para controle pelo GCP IAM
A partir de 2025, o SOAR passou a ser controlado pelo Google Cloud IAM — unificando o gerenciamento de SIEM e SOAR em um único lugar. Esta migração é obrigatória.
SOAR gerenciado internamente
Permission groups configurados dentro do SOAR. Projeto hospedado pelo Google.
SOAR gerenciado pelo GCP IAM
IAM roles controlam o acesso. Projeto migrado para o GCP do cliente. Logs no Cloud Audit Logs.
Etapas da migração
Migração do projeto e permissões
Como executar a migração
Acesse Administration Settings — SOAR IAM Migration
No console GCP, navegue até Google SecOps > Administration Settings > aba SOAR IAM Migration
Copie o script gerado automaticamente
Em "Migrate role bindings", copie os comandos gcloud gerados com base nos seus permission groups existentes
Execute no Cloud Shell
Abra o Cloud Shell no console GCP, cole e execute os comandos. Verifique se todos rodaram com sucesso.
Clique em Enable IAM
Em "Finished with this task", clique em Enable IAM para ativar o novo controle de acesso unificado.
Mapeie os roles no SOAR
Settings > SOAR Settings > Advanced > IAM Role Mapping — associe cada IAM role ao SOC role e environment.
Boas práticas de permissão
Recomendações da documentação oficial para uma configuração segura e sustentável.
Use grupos, nunca usuários individuais
Atribua roles a grupos do IdP (ex: soc-tier1@empresa.com). Quando um analista sair, basta removê-lo do grupo — sem alterar políticas IAM.
Princípio do menor privilégio
A maioria dos analistas SOC deve ter roles/chronicle.viewer. Apenas engenheiros de detecção precisam de Editor. Admin deve ser reservado para no máximo 2 pessoas.
Unifique SIEM e SOAR no mesmo projeto GCP
Para deployments unificados, use o mesmo projeto para ambos. Isso permite gerenciamento unificado de RBAC, logs e auditoria.
Mapeie roles no SOAR após habilitar IAM
Acesse Settings > SOAR Settings > Advanced > IAM Role Mapping e associe cada IAM role ao SOC role, permission group e environment corretos.
Valide o acesso antes de ir para produção
Faça login com uma conta de teste de cada role. Mudanças IAM têm efeito imediato; mudanças no SOAR Settings só aplicam no próximo login.
Deploy final
Com projeto, API, IdP, permissões e SOAR IAM configurados, o deploy é executado automaticamente pelo sistema.
Sistema valida as configurações
Chronicle API habilitada, billing account correta, permissões do SME verificadas
Instância provisionada
Processo leva até 15 minutos. Uma notificação é enviada ao concluir com sucesso.
Service account criada automaticamente
Visível no IAM com a opção "Include Google-provided Role Grants" ativada
SOAR migrado para o projeto GCP do cliente
Projeto SOAR sai da propriedade do Google e passa para o projeto GCP do cliente. Permissões unificadas via IAM.
Usuários fazem login e são registrados
Ao logar pela primeira vez, cada usuário é adicionado automaticamente em Settings > Organization
Próximos passos
Configurar ingestão de logs (BindPlane, Feeds, API), definir regras YARA-L e RBAC de dados