Conectar um projeto Google Cloud

Conecte um projeto Google Cloud passo a passo. Registre o projeto, crie a identidade somente leitura com o módulo Terraform gerado, o script gcloud ou os passos do console, cole a service account e o identity provider, valide as permissões, escolha se as mudanças serão avaliadas em tempo real a partir do Cloud Audit Logs e leia os primeiros resultados.

Este guia conecta um projeto Google Cloud ao WASViking^® Cloud Security ao lado das suas contas AWS, nas mesmas telas. Ao final, o projeto é lido por meio de uma identidade que é sua, cada recurso está no inventário e avaliado, e os primeiros riscos contextuais e caminhos de ataque aparecem na tela em palavras do Google Cloud. Nada aqui cria uma chave: você cria uma service account no seu projeto com uma custom role que só consegue listar e ler configuração, e a WASViking é federada nela por uma hora de cada vez, por meio de um workload identity pool que aceita um único subject.

Antes de começar

O Cloud Security é um módulo adicional, disponível a partir do plano Pro, ativado por organização pelo seu contato WASViking ou parceiro. O pacote inclui uma conta conectada; uma conta AWS e um projeto Google Cloud contam um cada. Registrar e validar conectores exige a permissão Manage no módulo.

Do lado do Google Cloud, você precisa de alguém que administre o projeto que está conectando: o papel Owner, ou Project IAM Admin, Service Account Admin, Role Administrator, Workload Identity Pool Admin e Service Usage Admin juntos. Essa pessoa aplica o módulo Terraform, roda o script gcloud no Cloud Shell ou segue os passos do console.

Tenha à mão o project id (o identificador em minúsculas, não o número do projeto e não o nome de exibição) e o e-mail do time dono do projeto.

A identidade precisa de cinco APIs do Google habilitadas no projeto: IAM, IAM Service Account Credentials, Security Token Service, Cloud Resource Manager e Service Usage. O módulo e o script as habilitam; os passos do console dizem onde. As APIs dos serviços que você usa ficam como estão: um serviço com a API desabilitada aparece como not enabled na validação e os seus recursos simplesmente não são lidos.

Passo 1: registre o projeto

Abra Cloud Security → Accounts & Connectors e clique em Connect account. Escolha o card Google Cloud e preencha:

• Account name, como o seu time chama o projeto ("Data platform", "Payments production").
• O Google Cloud project id: de 6 a 30 caracteres, letras minúsculas, dígitos e hifens, começando por uma letra, como o console mostra.
• Environment: Production, Staging, Development, Shared, Security, Sandbox ou Audit. O ambiente pesa na pontuação de risco de cada recurso do projeto.
• Owner: o e-mail que recebe os avisos de saúde do projeto.
• Custom role id: WASVikingCloudSecurityReader, que você pode renomear.

O painel à direita mostra em que o pool que você vai criar confiará: a conta AWS da WASViking e a sua role de federação, o subject exato que o pool aceita, um External ID gerado só para este conector, o nome da service account, o nome da custom role e Write access: No. Clique em Register and get the deployment artifacts. O projeto agora aparece na tabela de contas e o assistente pode ser retomado a partir dela a qualquer momento.

Passo 2: crie a identidade somente leitura

A página de implantação oferece três formas de criar os mesmos objetos no seu projeto. As três criam a service account, a custom role e o workload identity pool; nenhuma cria uma chave e nenhuma concede uma escrita.

• Terraform (recomendado): Download module e aplique com uma identidade que administre o projeto: no Cloud Shell, envie o arquivo para um diretório vazio e rode ali terraform init e terraform apply. O módulo habilita as cinco APIs, cria a service account wasviking-cloud-security@<project id>.iam.gserviceaccount.com sem chave, cria a custom role com as permissões de leitura de que o inventário precisa e a concede à service account, cria o pool wasviking-cloud-security com um provider AWS chamado wasviking-aws que nomeia a conta da WASViking, define a attribute condition que aceita só o subject que carrega o seu External ID, e vincula Workload Identity User para esse subject na service account. O External ID já vem preenchido.
• gcloud script: Download script e rode no Cloud Shell ou em um terminal autenticado no projeto. Ele cria os mesmos objetos e imprime os dois valores que você cola no Passo 3.
• Manual: See the steps e crie os objetos no console, em ordem: habilite as APIs; crie a service account sem chave; crie a custom role com exatamente as permissões listadas (cada uma é uma leitura list, get ou getIamPolicy); conceda essa role à service account e nada mais; crie o pool e o seu provider AWS com o attribute mapping e a attribute condition mostrados; conceda Workload Identity User na service account ao subject mostrado; depois cole os dois valores.

O External ID aparece nesta página para membros com a permissão Manage, com um botão de copiar; ele nunca aparece em listas, notificações ou exportações. Se vazar, Rotate External ID emite um novo e mantém o anterior válido por 24 horas para você atualizar a attribute condition e o vínculo sem interrupção. Enquanto a janela está aberta, a página de implantação mostra um bloco Rotation pending com as três linhas gcloud que movem a confiança (atualizar a attribute condition, adicionar o novo vínculo, remover o antigo): cole no Cloud Shell e valide. Com Terraform, baixe o módulo de novo e aplique no mesmo diretório da primeira vez (o estado mora ali; um diretório novo tentaria criar os objetos outra vez).

Passo 3: cole a service account e o identity provider e valide

O Terraform imprime os dois valores como as saídas wasviking_service_account e wasviking_workload_identity_provider; o script os imprime no final; no console, o resource name do provider está na página do provider, dentro do pool, e tem a forma projects/<project number>/locations/global/workloadIdentityPools/wasviking-cloud-security/providers/wasviking-aws.

De volta à página de implantação, cole o e-mail da service account em Service account e o resource name do provider em Workload identity provider, clique em Save identity e depois em Validate connection. A validação federa a identidade da WASViking na service account, confere que o projeto pelo qual ela responde é o que você registrou (id e número), lê os serviços habilitados, testa cada permissão da custom role e descobre as regiões do Compute Engine. O resultado mostra:

• a identidade federada e o projeto conferido,
• as regiões que serão lidas,
• os serviços com a API desabilitada, se houver (os recursos deles não são lidos; nada a corrigir, a menos que você os use),
• Permission coverage: a fração das leituras que a custom role consegue fazer,
• as permissões ausentes, se houver, com um bloco Fix access: uma linha gcloud que as adiciona à custom role e as linhas para colar no módulo Terraform (uma leitura de que só um sinal opcional precisa também aparece ali, com o nome do coletor; ela não reduz a cobertura, mas esse sinal fica sem leitura até você concedê-la),
• a duração estimada da primeira sincronização.

Uma validação que falha permanece neste passo com o motivo e o que mudar (veja Solução de problemas). Uma validação que passa marca o projeto como Healthy, ou Permission gap quando algumas leituras são negadas, e enfileira a primeira sincronização completa na hora. Os dois estados são sincronizados; uma lacuna só significa que alguns controles aparecem como Not evaluated até você adicionar as permissões.

Passo 4: ative a avaliação em tempo real (opcional)

Sem este passo, o projeto é lido a cada 24 horas (configurável em Settings) e cada mudança é registrada a partir da diferença entre duas sincronizações. Com ele, uma mudança administrativa no seu projeto chega à WASViking em até um minuto pelo Cloud Audit Logs e é julgada como risco introduzido, removido ou nenhum, com o ator e a ferramenta que a fizeram.

Clique em Download events Terraform ou Download events script, ou siga os passos da página. O arquivo Terraform é autocontido: aplique em um diretório próprio, separado do módulo do Passo 2 (terraform init e depois terraform apply); o script roda com bash no Cloud Shell. Eles criam, no seu projeto, um log sink chamado wasviking-cloud-security-events sobre os logs de auditoria de Admin Activity, um tópico Pub/Sub e uma subscription do tipo pull com o mesmo nome (prazo de confirmação de 60 segundos, um dia de retenção), concedem Pub/Sub Publisher à identidade de escrita do sink no tópico e concedem Pub/Sub Subscriber à service account da WASViking na subscription. A WASViking consome a subscription pela identidade do próprio conector; ela carrega só eventos de configuração, nunca dados. O passo mostra um estado, não um interruptor: Waiting for events até o primeiro chegar, Receiving events com a hora do último depois disso, ou Paused quando a organização desligou a avaliação em tempo real em Settings. A tabela de contas mostra Periodic, Receiving ou Paused para cada conector.

Opcional, para os repositórios de dados sensíveis: o mesmo sink também pode carregar os logs de auditoria de Data Access do Cloud Storage, do BigQuery, do Cloud SQL e do Secret Manager. Ative os logs de Data Read desses quatro serviços em IAM & Admin, Audit Logs, depois defina data_access_logs = true no arquivo Terraform de eventos (ou rode o script com DATA_ACCESS_LOGS=1), ou amplie o filtro de inclusão do sink para o que a página mostra nos passos manuais. A WASViking guarda essas leituras como sinais de acesso em cada repositório, nunca como mudanças: a página de um bucket, dataset, instância Cloud SQL ou secret mostra Reads observed com as leituras dos últimos sete dias, quantos principais as fizeram, os cinco mais ativos e o último momento. Os contadores ficam por repositório, principal e dia durante trinta dias e não carregam objeto, linha nem payload. Os logs de Data Access são cobrados pelo Cloud Logging como qualquer outro log; o filtro nomeia só os quatro serviços.

Um conector com escopo de organização ou de pasta coloca o sink na organização com os filhos incluídos, de modo que os eventos de todos os projetos abaixo dela chegam à subscription central e a WASViking encaminha cada um ao projeto que ele nomeia.

Sem o Passo 5, cada finding continua carregando o seu plano guiado em quatro formas (passos do console, gcloud, Terraform e a constraint de organization policy que impede o estado) e você o aplica por conta própria.

Passo 5: permita a remediação assistida (opcional)

Todo finding vem com um plano guiado que você mesmo aplica. O Passo 5 deixa a WASViking aplicar por você uma lista curta de correções, cada uma uma mudança de configuração reversível: impor public access prevention em um bucket, remover os membros públicos da política de um bucket, desabilitar uma regra de firewall aberta para o mundo, retirar o endereço público de uma instância do Cloud SQL, habilitar rotação em uma chave do Cloud KMS, desabilitar uma chave de service account gerada pelo usuário. Nada roda sem um pedido em um item de trabalho e uma aprovação sob a política de governança que você definir.

O passo cria uma segunda service account no seu projeto, separada da somente leitura, com uma custom role que carrega só as permissões das ações que você marcar, e um segundo provider no mesmo workload identity pool cuja attribute condition nomeia apenas o subject de remediação (um Remediation External ID gerado para essa identidade). Marque as ações, clique em Enable assisted remediation, baixe o Terraform de remediação e aplique em uma pasta vazia ao lado do módulo do Passo 2 (ou siga os passos manuais), depois clique em Validate remediation identity; o passo lê Ready quando a WASViking federou na segunda service account e provou que ela tem as permissões das ações que você habilitou. Nada é colado: os nomes são fixos e aparecem na página. Mudar a lista depois pede baixar o módulo de novo, aplicar a partir da mesma pasta da primeira vez (o Terraform guarda o estado ali; uma pasta nova tentaria criar o que já existe) e validar de novo; Disable assisted remediation esquece a identidade do nosso lado, e você apaga a service account, a role e o segundo provider no Google Cloud.

Depois abra Settings, ligue Assisted remediation governance, escolha se toda ação precisa de um aprovador ou só as de impacto alto, mantenha a regra de que quem pede nunca aprova o próprio pedido, e marque as ações e os ambientes que você permite. Em um item de trabalho o bloco Assisted actions lista o que se aplica ao recurso dele, com o que muda e como volta atrás; Request this action cria um registro que um aprovador decide na mesma página (Approve and run ou Reject com uma nota), e os canais dos aprovadores recebem o pedido quando assinaram o evento. O registro guarda quem pediu, quem decidiu, o que foi lido antes da mudança e o que foi escrito; Roll back escreve o estado anterior de volta. A próxima passagem de pontuação verifica o item como qualquer correção feita à mão.

A primeira sincronização

A tabela de contas mostra a sincronização avançando por coletor (o projeto e a sua política IAM, service accounts e chaves, custom roles e chaves de API, redes e regras de firewall, balanceamento de carga e Cloud DNS, Compute Engine, GKE, Cloud Functions, Cloud Run, Dataproc e Artifact Registry, discos, snapshots e imagens, Cloud Storage, Cloud SQL, Cloud KMS, Secret Manager, BigQuery, Memorystore, Filestore, Pub/Sub, logging e monitoring, Vertex AI). O Overview permanece no estado "primeira sincronização em andamento" até a avaliação terminar, depois mostra o anel de Cloud Risk com cada ponto nomeado, a postura por domínio e os primeiros findings. Os controles de um projeto Google Cloud são referenciados ao CIS Google Cloud Platform Foundation Benchmark, ao PCI DSS 4.0.1 e ao NIST SP 800-53; a página Compliance mostra o card CIS Google Cloud para o projeto.

O que olhar em seguida:

1. Overview: o aviso de confiança de cobertura (se abaixo de 100 por cento, abra as lacunas e aplique a linha de Fix access), a combinação tóxica principal e os riscos de maior prioridade.
2. Posture Findings: comece pela aba Contextual risks; cada uma nomeia os componentes da combinação e como quebrá-la. A aba Control failures filtrada pelo projeto lista cada controle que falha com a sua referência do CIS Google Cloud.
3. Attack Paths: a cadeia em destaque e a sua opção de quebra recomendada, escrita em palavras do Google Cloud (public access prevention, allUsers, os papéis a substituir, as authorized networks a estreitar).
4. Cloud Inventory: abra qualquer recurso para ler a sua configuração, o grafo ao redor e o seu caminho de exposição (o endereço externo, a rede VPC e as regras de firewall que admitem a internet até ele).
5. Architecture Map: o projeto desenhado com as redes VPC no nível do projeto, as suas sub-redes, as regiões e os serviços que rodam em cada uma.

Lendo todos os projetos de uma organização ou de uma pasta

Um conector pode ler todos os projetos de uma organização Google Cloud ou de uma das suas pastas. No Passo 1, preencha Organization or folder scope com o nó (organizations/123456789012, o número que o console mostra em IAM & Admin, Settings, ou folders/987654321, o número na página da pasta) e registre um projeto seu como projeto central: a service account e o pool são criados nele, enquanto a custom role é criada na organização e vinculada ao nó dela. Os artefatos do Passo 2 carregam essa diferença; aplique com uma identidade que tenha, no nó da organização, Organization Role Administrator (roles/iam.organizationRoleAdmin, para criar a custom role ali) e Organization Administrator (roles/resourcemanager.organizationAdmin, para vinculá-la). Uma identidade que só cria projetos é recusada na role com iam.roles.get; conceda os dois papéis e aplique de novo, o módulo continua de onde parou.

Depois da primeira sincronização do projeto central, todo projeto ativo sob a organização e suas pastas aparece na tabela de contas como um conector próprio, com o caminho da pasta, marcado Discovered project. Um projeto descoberto não precisa de nada implantado: ele é lido pela identidade e pelo External ID do conector central, valida a si mesmo assim que é descoberto e roda a primeira sincronização logo depois, então o ambiente inteiro se conecta a partir de um único registro. Validate all na tabela de contas continua para um projeto que foi recusado nesse meio tempo; o tempo real (Passo 4) é habilitado por projeto. Um projeto que você remover não é registrado de novo; um projeto criado depois aparece na próxima sincronização do projeto central. Uma rotação do External ID do conector central move todos os projetos descobertos junto.

Com um nó de pasta a custom role continua sendo criada na organização (o Google Cloud cria custom roles na organização ou em um projeto, nunca em uma pasta) e vinculada à pasta: o módulo descobre a organização a partir da pasta, o script percorre os pais da pasta, os passos do console a nomeiam. Aplique com uma identidade que tenha Organization Role Administrator na organização e Folder IAM Admin na pasta. A linha de Fix access de um conector com escopo de pasta nomeia a organização como ORGANIZATION_ID, porque a identidade não lê nada acima da pasta: substitua pelo número da organização antes de rodar.

Dia dois

• Settings: o label data-classification em um bucket, um dataset ou uma instância do Cloud SQL declara a sua classificação (pii, pci, phi, secrets, internal), o label public-by-design em uma instância ou em um serviço do Cloud Run declara que ele responde à internet de propósito, e as chaves de label de dono, ambiente e criticidade são as que você define ali, como na AWS.
• Policies & Controls: os policy packs se aplicam aos dois provedores; a biblioteca de controles lista os controles do Google Cloud com as suas referências do CIS; exceções são limitadas no tempo e exigem um aprovador.
• Data Security: defina à mão uma classificação em um store que a inferência errou; o valor manual sobrevive a todas as sincronizações seguintes.
• Reports & Evidence: o PDF executivo, as exportações de postura e de inventário e o pacote de evidências incluem o projeto Google Cloud ao lado das contas AWS.
• Baseline de permissões: as leituras de que a custom role precisa crescem quando a WASViking adiciona uma verificação. O módulo e o script carregam a versão do baseline; quando uma validação encontra a sua role atrás dele, a página do conector mostra a linha gcloud, a lista de contas marca o projeto e um aviso vai aos seus canais por versão. Rode a linha ou aplique o módulo de novo; a WASViking nunca altera a role.
• Diretório do Workspace: dois controles leem o diretório do seu Google Workspace, a verificação em duas etapas em todos os usuários e imposta em todos os administradores, e a página de identidades mostra o selo de MFA de cada pessoa. A Admin SDK não é coberta pela custom role: no Google Admin console, Account, Admin roles, crie uma role com o privilégio de leitura de usuários e atribua à service account do conector, depois habilite a API Admin SDK no projeto. Até lá esses dois controles mostram Not evaluated e o selo mostra n/a; a WASViking guarda contagens e quatro fatos por endereço (duas etapas, imposição, administrador, suspenso), nunca um nome ou um fato de senha. O Access Transparency é verificado quando o Access Approval está inscrito ou quando existe uma entrada de log de Access Transparency no projeto; caso contrário mostra Not evaluated em vez de falhar sobre o que nenhuma API informa.
• Sinais nativos: com o Security Command Center ativado (o tier Standard é gratuito; ative na organização, ou só no projeto quando você não administra a organização) e a API dele habilitada no projeto, os findings ativos contam para os controles de detecção. Com a API do Sensitive Data Protection habilitada, cada inspection job concluído classifica o bucket ou o dataset que inspecionou pelo que encontrou, o que vale mais que o label e o nome. Os dois são lidos pela custom role; uma role criada antes de essas leituras existirem mostra as duas sob Fix access.
• Mais projetos: um conector é um projeto; repita os quatro passos por projeto. O módulo Terraform recebe o project id e o External ID como variáveis, então um segundo projeto é um segundo apply.

Solução de problemas

Removendo um projeto

Remove na tabela de contas interrompe as leituras na hora. O inventário e as evidências são mantidos pela janela de retenção de recursos excluídos definida em Settings, para que os relatórios continuem reproduzíveis, e depois são apagados. Destrua o módulo Terraform (ou apague o pool, a service account e a custom role no console) do seu lado quando terminar; nada do lado da WASViking consegue mantê-los.