Equipes que concentram dados sensíveis em BigQuery e Cloud Storage no Google Cloud esbarram em um limite estrutural do IAM: a política de identidade define quem pode chamar uma operação, mas não impede que uma credencial válida copie dados para um destino fora do ambiente. Quando uma conta de serviço é comprometida, o atacante opera com permissão legítima e o registro de auditoria mostra uma operação autorizada. A ação prioritária para quem ainda não adotou o recurso é implantar VPC Service Controls começando em modo dry run: mapear o tráfego real dos serviços de dados antes de bloquear qualquer saída, e só então aplicar o perímetro onde ele muda o jogo da defesa.
O VPC Service Controls cria uma fronteira lógica em torno de projetos e serviços gerenciados. Dentro do perímetro, a comunicação flui normalmente; para fora dele, as operações de serviço são negadas por padrão. Trata-se de um controle de contexto, independente do IAM, e a própria recomendação do Google é usar os dois em camadas, para que uma única decisão de permissão não seja a última linha de defesa dos dados.
Como o perímetro funciona
Um service perimeter envolve os projetos que você listar e protege os serviços explicitamente incluídos, como Cloud Storage, BigQuery e Bigtable. A documentação oficial do Google Cloud explica que a ferramenta protege contra ação acidental ou direcionada de entidades externas ou internas e minimiza o risco de exfiltração a partir de serviços como Cloud Storage e BigQuery. Na prática: uma cópia entre dois buckets do mesmo perímetro é executada; se um dos buckets está fora, a operação falha mesmo com o IAM autorizando a identidade.
As exceções são explícitas e bidirecionais. Regras de ingress controlam quem está fora do perímetro e pode acessar recursos de dentro; regras de egress autorizam, pontualmente, operações de dentro para fora. Níveis de acesso classificam as requisições por atributos como faixa de IP, identidade e tipo de credencial, o que mantém o perímetro utilizável em cenários híbridos com VPN ou Cloud Interconnect e no acesso vindourante da internet.
Para orientar a decisão de arquitetura, vale separar as perguntas que cada camada responde:
| Camada | Pergunta que responde | Falha que cobre |
|---|---|---|
| IAM | Esta identidade pode executar esta operação? | Excesso de permissão por identidade |
| Perímetro de serviço | Este destino está dentro da fronteira de dados? | Cópia autorizada para fora do ambiente |
| Controle de saída de rede | Este tráfego pode sair da rede? | Uso de APIs de terceiros na internet |
A ameaça que o perímetro corta
A exfiltração por serviços legítimos de nuvem é técnica consolidada, não hipótese de ameaça. O MITRE ATT&CK cataloga a exfiltração para serviços de armazenamento em nuvem como a técnica T1567.002, com registros de grupos que usam ferramentas de sincronização de arquivos e contas de armazenamento controladas pelos próprios atacantes. O catálogo do MITRE serve de lista de verificação para a equipe mapear quais desses caminhos o perímetro realmente corta e quais continuam abertos, inclusive porque o perímetro age sobre serviços gerenciados do Google Cloud e não sobre APIs de terceiros na internet.
O caso de uso mais direto é a credencial roubada. Uma chave de conta de serviço vazada em repositório ou pipeline dá ao atacante uma identidade funcional; o perímetro não impede o roubo, mas impede que aquela identidade copie dados para um destino fora da fronteira. O ataque perde o canal de saída mais cômodo e ganha atrito observável em log. Incidentes contra custódia de ativos em nuvem, como o caso Slim Spider, mostram o custo de um ambiente sem fronteira de dados definida.
O perímetro também cobre o insider malicioso e o código comprometido: um notebook de análise ou um job que tentasse gravar em um bucket público externo recebe negativa, mesmo rodando com permissões de escrita legítimas no projeto. E, como o controle funciona no nível da organização por padrão, com políticas com escopo por pasta ou projeto, a operação multi-conta herda a fronteira sem depender de disciplina individual de cada equipe de produto.
Implantação em cinco passos
O roteiro abaixo evita a quebra de produção e produz a evidência de que a política cabe ao ambiente real:
- Inventarie projetos e serviços de dados. Liste datasets do BigQuery, buckets do Cloud Storage e instâncias do Bigtable que concentram informações reguladas ou propriedade intelectual. O perímetro protege apenas o que está declarado nele.
- Crie o perímetro em modo dry run. O objetivo desta fase é monitorar as requisições aos serviços protegidos sem bloquear o acesso; cada violação potencial aparece em log antes de virar incidente de disponibilidade.
- Classifique as violações registradas. Nos Cloud Audit Logs, separe o tráfego em três categorias: legítimo, legítimo a revisar (integrações com parceiros, pipelines externos) e desconhecido. O desconhecido merece investigação, não exceção automática.
- Formalize exceções com regras de ingress e egress. Autorize por identidade e destino específicos, com data de revisão. Exceções amplas por projeto recriam, dentro da nova camada, o problema que ela existe para resolver.
- Ative a aplicação efetiva por etapas. Comece pelo perímetro de menor risco, atravesse um ciclo completo de operação, incluindo jobs noturnos, restores e procedimentos de emergência, e só então replique o modelo para os perímetros críticos.
Sinais a monitorar
Aplicado o perímetro, a detecção passa a ter sinais próprios, distintos do ruído comum de permissões:
- Negativas de operação envolvendo contas de serviço fora da janela de operação do negócio.
- Tentativas de acesso vindas de redes fora dos níveis de acesso configurados.
- Regras de egress recém-criadas, alvo clássico de persistência após comprometimento inicial.
- Acessos inesperados a perímetros-isca, projetos sem carga de trabalho incluídos justamente para denunciar reconhecimento.
Esse monitoramento complementa, e não substitui, a integridade dos registros de nuvem: sem logs confiáveis, o perímetro vira caixa-preta na investigação. A mesma lógica de separação vale para a recuperação, tema do guia sobre backups em conta separada, que detalha como isolar a custódia dentro da nuvem.
Prioridades P1 e P2
P1: perímetro em dry run sobre os projetos com dados sujeitos a LGPD ou PCI DSS, com revisão semanal das violações registradas; retirada das chaves de conta de serviço de longa duração dos projetos incluídos no perímetro, substituindo-as por credenciais de curta duração; definição formal de quem pode criar regra de egress e por quanto tempo.
P2: níveis de acesso por IP e identidade para o acesso externo legítimo; extensão do perímetro às redes on-premises via Cloud Interconnect ou VPN autorizada; implantação de perímetros-isca para detecção ativa de reconhecimento; uso do VIP restrito para que chamadas aos serviços compatíveis não transitem pela internet.
Limites a declarar
O perímetro não bloqueia APIs de terceiros na internet: uploads diretos para serviços externos seguem exigindo controle de saída na camada de rede. O controle mira dados, não metadados; nomes de recursos e configurações podem circular por caminhos sem checagem do perímetro, e a recomendação do fabricante é manter a governança de metadados no IAM, incluindo papéis personalizados. Declarar esses limites na política interna evita que a equipe trate o recurso como solução completa de prevenção de perda de dados e mantém claras as camadas que continuam necessárias.