Sensitive Data Protection no Google Cloud: descubra, inspecione e desidentifique dados no Cloud Storage

Google Cloud Master Journey 2026
Engineering Handbook · Capítulo 10

Como identificar PII, criar templates reutilizáveis, investigar descobertas no BigQuery e produzir cópias seguras antes que dados cheguem a pipelines de analytics e inteligência artificial.

Um bucket não é apenas um diretório com arquivos.

Ele pode conter planilhas exportadas por sistemas internos, documentos enviados por clientes, resultados de integrações, bases históricas, registros financeiros, informações de saúde, números de documentos ou credenciais que nunca deveriam ter chegado ali.

O problema é que nem sempre sabemos exatamente o que está armazenado.

Quando esses dados alimentam dashboards, pipelines de dados, aplicações de inteligência artificial ou modelos de machine learning, o risco deixa de estar restrito ao bucket original. A informação sensível pode se espalhar por novas tabelas, caches, índices vetoriais, logs e ambientes de processamento.

Neste capítulo da minha jornada pelo Google Cloud Arcade, avancei para o laboratório GSP1281 — Enabling Sensitive Data Protection Discovery for Cloud Storage.

Mais do que executar uma sequência de configurações no console, o laboratório apresenta uma arquitetura importante:

Descobrir os dados antes de utilizá-los, investigar o que realmente foi encontrado e transformar o conteúdo antes de disponibilizá-lo para outras cargas de trabalho.

O Sensitive Data Protection é uma plataforma gerenciada do Google Cloud para inspeção, classificação e desidentificação de informações sensíveis. O serviço oferece detectores integrados, detectores personalizados e transformações como mascaramento, redação, substituição, deslocamento de datas e tokenização.

O que você aprenderá

Ao longo deste artigo, vamos entender:

• a diferença entre Discovery, Inspection e De-identification;
• como o Google Cloud identifica diferentes tipos de informações sensíveis;
• por que templates são importantes para consistência;
• como enviar descobertas para o BigQuery;
• como integrar resultados ao Security Command Center;
• como criar uma cópia desidentificada dos arquivos;
• como levar o conhecimento do laboratório para uma arquitetura real de produção.

O objetivo não é simplesmente reproduzir os botões do laboratório.

O objetivo é entender como o serviço pensa.

O problema: dados brutos não deveriam seguir diretamente para consumo

Imagine o seguinte fluxo:

Aplicações
    ↓
Exportações CSV
    ↓
Cloud Storage
    ↓
BigQuery
    ↓
Dashboards e modelos de IA

Esse pipeline parece normal. Porém, uma exportação pode conter:

Nome
CPF
RG
Telefone
E-mail
Endereço
Dados financeiros
Informações médicas
Tokens
Credenciais

Se esses arquivos forem consumidos diretamente, todos os sistemas posteriores precisarão tratar o mesmo risco.

Uma abordagem mais segura adiciona uma fronteira entre o dado recebido e o dado liberado:

Agora existem duas zonas distintas:

Raw Zone
Dados originais, restritos e potencialmente sensíveis.

Sanitized Zone
Dados inspecionados e transformados para consumo.

Essa separação reduz a possibilidade de que uma aplicação de analytics ou inteligência artificial receba informações que não precisa conhecer.

O modelo mental: Discovery, Inspection e De-identification

As três capacidades resolvem problemas diferentes.

Discovery pergunta: onde está o risco?

Discovery fornece uma visão ampla do ambiente.

Ele percorre os recursos selecionados e gera perfis com informações como:

• tipos de dados encontrados;
• nível de sensibilidade;
• nível de risco;
• localização do recurso;
• configurações relacionadas ao acesso;
• informações que ajudam a priorizar investigações.

Inspection pergunta: o que exatamente foi encontrado?

Um job de inspeção analisa um conjunto específico de dados.

Ele procura pelos tipos de informação configurados e produz descobertas detalhadas, incluindo localização, detector responsável e probabilidade de correspondência.

De-identification pergunta: como o valor será transformado?

Após identificar um conteúdo sensível, precisamos decidir o que fazer com ele.

Podemos:

Remover
Mascarar
Substituir
Tokenizar
Criptografar
Generalizar
Deslocar datas

Essa distinção é essencial:

Discovery cria visibilidade. Inspection aprofunda a investigação. De-identification reduz a exposição do conteúdo.

1. Descoberta contínua de dados sensíveis

A primeira tarefa do laboratório foi habilitar o Discovery para o Cloud Storage.

O objetivo era criar uma configuração capaz de analisar os buckets do projeto e produzir data profiles.

Um perfil não é simplesmente uma lista de ocorrências. Ele funciona como um resumo de postura de dados, ajudando a responder:

Quais recursos armazenam informações sensíveis?

Quão sensíveis são esses dados?

Quais tipos de informação foram identificados?

Quem pode acessar o recurso?

Onde precisamos investigar primeiro?

O Discovery pode ser executado imediatamente e também configurado para novas execuções periódicas ou relacionadas a mudanças na configuração. No laboratório, ele foi utilizado para monitorar arquivos do Cloud Storage e orientar as etapas posteriores de inspeção.

Discovery não substitui a inspeção detalhada

O perfil tem como objetivo oferecer visibilidade e priorização.

Ele ajuda a encontrar áreas importantes, mas não deve ser entendido como a última etapa da investigação.

O fluxo esperado é:

Discovery
    ↓
Recurso classificado como sensível
    ↓
Inspection Job direcionado
    ↓
Análise detalhada
    ↓
Remediação ou desidentificação

A prática recomendada é utilizar Discovery para entender o ambiente e executar um job de inspeção quando for necessário investigar um recurso com maior profundidade.

2. InfoTypes: ensinando ao serviço o que procurar

O Sensitive Data Protection usa infoTypes para representar categorias de informações.

Alguns exemplos são:

EMAIL_ADDRESS
PHONE_NUMBER
PERSON_NAME
CREDIT_CARD_NUMBER
STREET_ADDRESS
MEDICAL_RECORD_NUMBER
US_SOCIAL_SECURITY_NUMBER
BRAZIL_CPF_NUMBER
BRAZIL_RG_NUMBER
GCP_CREDENTIALS
AWS_CREDENTIALS

Um infoType não é apenas um nome. Ele está associado a um detector que utiliza regras, padrões e elementos contextuais para avaliar se determinado conteúdo corresponde àquela categoria.

O serviço mantém detectores integrados e também permite criar detectores personalizados com expressões regulares, dicionários e regras contextuais.

Aplicando o conceito ao Brasil

O laboratório trabalha especificamente com:

US_SOCIAL_SECURITY_NUMBER

Em uma aplicação brasileira, poderíamos adaptar a configuração para procurar:

BRAZIL_CPF_NUMBER
BRAZIL_RG_NUMBER
PHONE_NUMBER
EMAIL_ADDRESS
PERSON_NAME
STREET_ADDRESS

Não procure tudo sem necessidade

Selecionar todos os infoTypes pode parecer mais seguro, mas também pode aumentar:

• a quantidade de falsos positivos;
• o tempo de processamento;
• o volume de descobertas;
• o custo da inspeção;
• a dificuldade de analisar os resultados.

A configuração deve refletir o domínio do sistema.

Um sistema clínico pode priorizar:

PERSON_NAME
PHONE_NUMBER
EMAIL_ADDRESS
MEDICAL_RECORD_NUMBER
MEDICAL_DATA
BRAZIL_CPF_NUMBER

Um sistema financeiro pode priorizar:

BRAZIL_CPF_NUMBER
CREDIT_CARD_NUMBER
IBAN_CODE
SWIFT_CODE
BANK_ACCOUNT

Um repositório de código e configuração pode priorizar:

GCP_CREDENTIALS
AWS_CREDENTIALS
AUTH_TOKEN
OAUTH_CLIENT_SECRET
PRIVATE_KEY

A ferramenta deve procurar aquilo que representa risco real naquele contexto.

3. Inspection Templates: configuração como recurso reutilizável

Depois do Discovery, o laboratório reutiliza e modifica um template de inspeção.

Um Inspection Template armazena configurações como:

Quais infoTypes procurar
Qual o limite mínimo de confiança
Quais regras aplicar
Quantas descobertas retornar
Se o conteúdo encontrado deve aparecer nos resultados

Templates evitam que cada job mantenha uma configuração isolada.

Em vez disso, temos:

Política central
    ↓
Template versionado e controlado
    ↓
Vários jobs reutilizando a mesma configuração

Os templates separam as regras de inspeção e transformação da implementação dos jobs. Isso permite reutilização, consistência entre usuários e datasets e atualização centralizada de configurações.

Exemplo conceitual de template para CPF

{
  "inspectTemplate": {
    "displayName": "Inspeção de CPF",
    "description": "Detecta números de CPF antes do uso em analytics e IA.",
    "inspectConfig": {
      "infoTypes": [
        {
          "name": "BRAZIL_CPF_NUMBER"
        }
      ],
      "minLikelihood": "POSSIBLE",
      "includeQuote": false
    }
  },
  "templateId": "brazil-cpf-inspection"
}

Os elementos mais importantes são:

infoTypes
Define o que será procurado.

minLikelihood
Define o nível mínimo de confiança aceito.

includeQuote
Define se o valor encontrado será incluído no resultado.

4. Entendendo o nível de confiança

Detecção de dados sensíveis nem sempre é uma operação binária.

Um conjunto de números pode ser:

• um CPF;
• um identificador interno;
• um código de pedido;
• uma sequência aleatória;
• parte de outro conteúdo.

Por isso, o serviço associa uma probabilidade às descobertas.

Entre os níveis utilizados estão:

VERY_UNLIKELY
UNLIKELY
POSSIBLE
LIKELY
VERY_LIKELY

No laboratório, o limite considerado foi POSSIBLE.

Isso significa que descobertas avaliadas como possíveis, prováveis ou muito prováveis podem ser incluídas.

A escolha envolve um trade-off:

Limite mais baixo
Maior cobertura, porém mais falsos positivos.

Limite mais alto
Maior precisão, porém risco de perder ocorrências reais.

Não existe um valor universalmente correto.

A calibração deve considerar:

• formato do dado;
• qualidade dos arquivos;
• impacto de um falso negativo;
• custo da revisão manual;
• finalidade do pipeline.

5. Inspection Job: investigando um recurso específico

Depois de encontrar um recurso relevante no Discovery, o próximo passo foi executar um job de inspeção direcionado.

O job combina quatro elementos:

Fonte
O local que será analisado.

Escopo
Arquivos, diretórios, tabelas ou tipos selecionados.

Detecção
Template ou configuração com os infoTypes.

Ações
O que fazer após a inspeção.

O Sensitive Data Protection consegue inspecionar diferentes fontes de dados. No Cloud Storage, o job pode analisar formatos selecionados e limitar seu escopo a arquivos, diretórios ou buckets.

Job pontual ou recorrente

Um job pode ser executado imediatamente ou ser associado a um gatilho recorrente.

Um job pontual é adequado para:

Investigar um incidente
Validar uma migração
Analisar uma nova base
Testar uma política

Uma execução recorrente é mais adequada para:

Monitoramento contínuo
Buckets que recebem novos arquivos
Controles de conformidade
Verificação periódica de data lakes

6. Salvando descobertas no BigQuery

No laboratório, os resultados do job de inspeção foram enviados para uma tabela do BigQuery.

Isso transforma as descobertas em dados consultáveis.

Podemos responder perguntas como:

Qual infoType aparece com maior frequência?

Quais arquivos concentram mais ocorrências?

Quais buckets apresentam maior risco?

Quando uma categoria começou a aparecer?

Quais jobs encontraram CPF ou credenciais?

Uma consulta conceitual poderia seguir esta direção:

SELECT
  info_type.name AS info_type,
  COUNT(*) AS total_findings
FROM
  `security_findings.sensitive_data_results`
GROUP BY
  info_type
ORDER BY
  total_findings DESC;

O schema exato depende da tabela produzida pelo job, mas o princípio permanece:

O BigQuery permite tratar descobertas de segurança como um conjunto de dados analisável.

Cuidado com Include quote

Existe uma opção chamada:

Include quote

Quando habilitada, ela permite incluir no resultado o conteúdo que correspondeu ao detector.

Isso é útil durante um laboratório ou investigação controlada porque facilita a validação de falsos positivos.

Porém, em produção, essa opção exige cuidado.

Se o serviço detectar um CPF e gravar o valor completo na tabela de resultados, você terá criado outra cópia da informação sensível.

Agora o dado existe em:

Arquivo original
+
Tabela de descobertas

Em produção, a decisão mais segura costuma ser:

{
  "includeQuote": false
}

Quando o conteúdo precisar ser visualizado, a tabela de resultados deverá ter:

• IAM restrito;
• auditoria;
• retenção definida;
• criptografia apropriada;
• acesso temporário;
• finalidade claramente documentada.

7. Publicando resultados no Security Command Center

Outra ação configurada no laboratório foi a publicação dos resultados no Security Command Center.

O BigQuery é excelente para investigação analítica.

O Security Command Center atende a outro objetivo: centralizar findings de segurança.

Assim, a equipe pode correlacionar dados sensíveis com outros problemas, como:

Buckets públicos
Permissões excessivas
Ausência de criptografia esperada
Configurações vulneráveis
Recursos expostos

Essa correlação é importante porque o risco não depende apenas do conteúdo.

Considere dois buckets contendo CPF:

Bucket A
Privado, criptografado e acessível por duas identidades controladas.

Bucket B
Acessível publicamente e compartilhado com várias contas.

O tipo de dado é o mesmo.

O risco não é.

Segurança de dados é a combinação entre sensibilidade, exposição, controle de acesso e contexto de uso.

8. De-identification Templates: definindo como transformar

Encontrar dados sensíveis não resolve o problema.

Precisamos decidir o que fazer com eles.

Um De-identification Template armazena as transformações aplicadas às descobertas.

Entre as possibilidades estão:

Redação

Remove completamente o conteúdo.

Entrada:
CPF: 123.456.789-00

Saída:
CPF:

Substituição pelo infoType

Troca o conteúdo pelo nome da categoria.

Entrada:
CPF: 123.456.789-00

Saída:
CPF: BRAZIL_CPF_NUMBER

Mascaramento

Preserva parte do formato.

Entrada:
123.456.789-00

Saída:
***.***.***-00

Substituição por valor fixo

Entrada:
iury@example.com

Saída:
[email-protegido]

Pseudonimização ou tokenização

Substitui o valor por outro identificador, que pode ou não permitir reversão, dependendo da técnica utilizada.

Entrada:
123.456.789-00

Saída:
customer_8f71a9

Deslocamento de datas

Mantém relações temporais sem preservar necessariamente a data original.

Entrada:
1990-04-10

Saída:
1990-06-18

O serviço suporta transformações reversíveis e não reversíveis. Para reidentificar conteúdo posteriormente, é necessário utilizar um método reversível e proteger adequadamente a chave criptográfica.

9. Exemplo de substituição pelo infoType

Uma transformação simples e útil é substituir cada ocorrência pelo nome do detector.

{
  "deidentifyConfig": {
    "infoTypeTransformations": {
      "transformations": [
        {
          "infoTypes": [
            {
              "name": "BRAZIL_CPF_NUMBER"
            },
            {
              "name": "EMAIL_ADDRESS"
            },
            {
              "name": "PHONE_NUMBER"
            }
          ],
          "primitiveTransformation": {
            "replaceWithInfoTypeConfig": {}
          }
        }
      ]
    }
  },
  "inspectConfig": {
    "infoTypes": [
      {
        "name": "BRAZIL_CPF_NUMBER"
      },
      {
        "name": "EMAIL_ADDRESS"
      },
      {
        "name": "PHONE_NUMBER"
      }
    ]
  }
}

Resultado conceitual:

Antes:

Iury possui o CPF 123.456.789-00.
O contato é iury@example.com e o telefone é (83) 99999-9999.

Depois:

Iury possui o CPF BRAZIL_CPF_NUMBER.
O contato é EMAIL_ADDRESS e o telefone é PHONE_NUMBER.

10. Criando uma cópia desidentificada

Na última etapa do laboratório, um novo job foi configurado para:

1. ler arquivos do bucket de entrada;
2. ignorar um caminho específico;
3. detectar informações sensíveis;
4. aplicar o template de desidentificação;
5. escrever o resultado em outro bucket.

O fluxo é:

Um detalhe importante:

O serviço não altera nem remove os arquivos originais.

Ele cria cópias transformadas em outro local.

Isso é positivo porque preserva a origem, mas exige governança.

Depois da execução, existirão pelo menos dois conjuntos:

Dados originais
Acesso altamente restrito.

Dados desidentificados
Liberados apenas para usos compatíveis com a transformação.

Não devemos concluir automaticamente que o bucket de saída pode se tornar público.

A desidentificação reduz o risco, mas o resultado ainda precisa ser avaliado.

11. Por que excluir determinados caminhos

O laboratório utiliza uma expressão para ignorar um diretório chamado:

ignore

Esse mecanismo pode ser útil para excluir:

Arquivos temporários
Backups
Logs técnicos
Conteúdo já processado
Diretórios de saída
Dados fora do escopo

Em uma arquitetura real, excluir o diretório de saída também ajuda a evitar reprocessamento.

Sem essa separação, um pipeline mal configurado poderia produzir:

Arquivo original
Arquivo desidentificado
Arquivo desidentificado novamente
Arquivo desidentificado pela terceira vez

Uma estrutura mais clara seria:

gs://empresa-raw/incoming/
gs://empresa-raw/quarantine/
gs://empresa-sanitized/approved/
gs://empresa-security/findings/

Cada local deve possuir finalidade e política de acesso próprias.

12. Como o Sensitive Data Protection pensa

Podemos resumir o modelo do serviço desta forma:

Detector
O que procurar.

Template
Como procurar ou transformar.

Job
Onde e quando executar.

Action
O que fazer após a execução.

Finding
O que foi encontrado.

Data Profile
Qual é a postura geral do recurso.

Transformation
Como reduzir a exposição do valor.

Essa decomposição é importante porque evita acoplamento.

Um mesmo template pode ser reutilizado por:

Job de inspeção manual
Job recorrente
Pipeline de ingestão
Aplicação síncrona
Processo de sanitização
Auditoria de segurança

A configuração deixa de ser um conjunto de cliques isolados e passa a representar uma política de proteção de dados.

13. Do laboratório para uma arquitetura de produção

O GSP1281 utiliza o console para apresentar os conceitos.

Em produção, eu evoluiria a solução para cinco zonas.

Landing Zone

Recebe dados recém-chegados.

Não deve ser consumida diretamente.

Quarantine Zone

Armazena arquivos que precisam de investigação ou transformação.

Sanitized Zone

Contém versões desidentificadas.

Approved Zone

Contém dados que passaram pela política e não exigiram transformação.

Findings Zone

Mantém metadados de inspeção e auditoria.

14. Sanitização antes de IA e RAG

Esse padrão se torna ainda mais importante com inteligência artificial.

Considere um sistema RAG:

Documentos
    ↓
Extração de texto
    ↓
Chunking
    ↓
Embeddings
    ↓
Banco vetorial
    ↓
Modelo generativo

Se o documento original possui CPF, telefone ou prontuário, a informação pode aparecer em:

Texto extraído
Chunks
Metadados
Embeddings
Cache
Logs
Prompt
Resposta do modelo

Sanitizar apenas a resposta final é tarde demais.

A proteção deve ocorrer antes do chunking e da geração de embeddings:

Esse é um dos usos mais relevantes do conhecimento apresentado pelo laboratório.

Dados que o modelo não precisa conhecer não deveriam entrar no contexto do modelo.

15. Discovery não é prevenção

Uma distinção arquitetural importante:

Discovery encontra dados que já estão armazenados.

Inspeção síncrona pode impedir que eles sejam armazenados.

Para cargas em lote, podemos utilizar jobs sobre o Cloud Storage.

Para aplicações que recebem dados em tempo real, a API também permite inspecionar ou desidentificar conteúdo antes da persistência.

O fluxo preventivo seria:

Esse modelo permite impedir proativamente que informações sensíveis entrem no armazenamento de backend.

16. IAM: quem pode configurar, inspecionar e visualizar?

A ferramenta não substitui o controle de acesso.

Uma arquitetura madura separa responsabilidades.

Administrador da política
Cria e atualiza templates.

Executor
Dispara jobs ou pipelines.

Analista de segurança
Visualiza findings.

Aplicação consumidora
Acessa apenas dados sanitizados.

Auditor
Consulta histórico e evidências.

O princípio é:

O serviço deve receber somente as permissões necessárias para ler a origem e gravar o destino definido.

Para jobs que criam cópias desidentificadas em projetos ou buckets separados, o agente do serviço precisa ter permissões específicas de leitura no bucket de entrada e criação de objetos no bucket de saída.

17. Observabilidade e operação

Uma solução real precisa responder:

O job terminou?

Quantos arquivos foram processados?

Quais arquivos falharam?

Quanto dado foi inspecionado?

Quantas descobertas foram produzidas?

Qual transformação foi aplicada?

O bucket de saída recebeu todos os arquivos?

O custo aumentou de forma inesperada?

Uma estratégia operacional pode combinar:

Cloud Monitoring
Estado e métricas.

Pub/Sub
Notificações de conclusão.

BigQuery
Análise histórica.

Security Command Center
Findings centralizados.

Cloud Logging
Auditoria e diagnóstico.

18. Custos e escopo

Inspeção de dados possui custo associado ao volume analisado.

Por isso, produção exige decisões sobre:

Frequência
Escopo
Tipos de arquivo
Amostragem
InfoTypes
Diretórios excluídos
Retenção dos resultados

Algumas práticas úteis:

1. Não escanear novamente arquivos imutáveis sem necessidade.
2. Separar dados novos de dados já processados.
3. Selecionar infoTypes relevantes.
4. Usar filtros de caminho e tipo de arquivo.
5. Definir periodicidade proporcional ao risco.
6. Monitorar volume e custo.
7. Testar a configuração em uma amostra controlada.

Mais inspeção não significa automaticamente mais segurança.

Uma política eficiente precisa encontrar o equilíbrio entre:

Cobertura
Precisão
Latência
Custo
Capacidade de investigação

19. Google Cloud e AWS: comparação de arquitetura

Para quem trabalha em ambientes multicloud, o serviço mais próximo na AWS é o Amazon Macie.

A principal diferença arquitetural observada é que o Sensitive Data Protection reúne descoberta, inspeção e diferentes formas de desidentificação na mesma plataforma. O Macie é fortemente orientado à descoberta, classificação e geração de findings; a transformação dos dados costuma ser construída com outros componentes.

20. Como eu aplicaria em ambientes reais

Plataformas SaaS e opera??es internas

Em projetos que recebem documentos ou bases de clientes, a arquitetura poderia aplicar:

Upload
    ↓
Quarentena
    ↓
Inspeção
    ↓
Classificação
    ↓
Desidentificação
    ↓
Liberação

Isso seria especialmente importante antes de utilizar dados em:

• dashboards;
• treinamento de modelos;
• busca semântica;
• RAG;
• ambientes de demonstração;
• suporte técnico;
• compartilhamento com parceiros.

Plataformas institucionais

Em um sistema de gestão de projetos e obras, documentos podem conter:

Dados de fornecedores
Documentos pessoais
Contatos
Informações financeiras
Planilhas
Contratos
Relatórios

O Discovery ajudaria a mapear o que está armazenado.

Jobs direcionados poderiam investigar buckets específicos.

Cópias desidentificadas poderiam ser usadas em:

Indicadores públicos
Bases de pesquisa
Ambientes de homologação
Treinamentos
Demonstrações
Relatórios analíticos

Assim, o mesmo dado pode atender a diferentes finalidades sem que todos os consumidores recebam o conteúdo original.

21. O que eu faria diferente em produção

O laboratório é ideal para compreender o serviço, mas uma implementação real exigiria alguns ajustes.

Evitaria incluir quotes por padrão

O conteúdo encontrado não deveria ser replicado na tabela de findings sem necessidade clara.

Criaria templates por domínio

finance-inspection
health-inspection
identity-inspection
credentials-inspection

Separaria os buckets

raw
quarantine
sanitized
approved

Automatizaria a infraestrutura

Templates, permissões, buckets, datasets e integrações deveriam ser gerenciados como código sempre que possível.

Adicionaria critérios de liberação

Um arquivo só seguiria para consumo depois de receber um estado explícito:

APPROVED
SANITIZED
REJECTED
MANUAL_REVIEW

Criaria métricas operacionais

Percentual de arquivos com findings
Tempo médio de processamento
Quantidade por infoType
Falhas por formato
Volume inspecionado
Custo por execução

Manteria os dados originais altamente restritos

A existência de uma versão sanitizada não elimina a necessidade de proteger a origem.

22. Erros de interpretação que devemos evitar

“O arquivo foi inspecionado, então está seguro”

Inspeção gera informação.

Ela não corrige automaticamente permissões ou exposição.

“Não houve finding, então não existe dado sensível”

Nenhum detector possui contexto perfeito.

A configuração pode estar incompleta, o formato pode não ser compatível ou o limite de confiança pode estar alto demais.

“Mascarar parte do valor sempre anonimiza”

Dependendo do conjunto de dados, outros campos podem permitir reidentificação.

“Dados desidentificados podem ser públicos”

A desidentificação reduz risco, mas não transforma automaticamente qualquer base em conteúdo público.

“Discovery substitui controles de acesso”

Discovery identifica e classifica.

IAM continua sendo responsável por controlar quem acessa o recurso.

23. Checklist para produção

Antes de implantar uma solução semelhante, eu validaria:

[ ] Quais dados sensíveis esperamos encontrar?
[ ] Quais infoTypes representam o domínio?
[ ] Quais recursos entram no escopo?
[ ] Quais caminhos devem ser excluídos?
[ ] Qual é o limite de confiança adequado?
[ ] Findings podem incluir o conteúdo detectado?
[ ] Quem pode visualizar os resultados?
[ ] Qual transformação será aplicada?
[ ] A transformação precisa ser reversível?
[ ] Onde as chaves criptográficas serão armazenadas?
[ ] O bucket de saída está separado da origem?
[ ] Quem pode acessar os dados originais?
[ ] Quem pode acessar os dados sanitizados?
[ ] Como o job será monitorado?
[ ] Qual é a política de retenção?
[ ] Como o custo será acompanhado?
[ ] O processo está documentado e auditável?

25. Relevância para engenharia de cloud

Embora o laboratório esteja inserido na jornada do Google Cloud Arcade, os conceitos ultrapassam a ferramenta.

Eles aparecem em decisões reais sobre:

Data lakes
Pipelines de analytics
Sistemas clínicos
Sistemas financeiros
Machine learning
RAG
Ambientes de homologação
Compartilhamento de datasets
Governança de dados
Resposta a incidentes

Um engenheiro de cloud não deve pensar apenas em:

Onde armazenar?

Como escalar?

Quanto custa?

Também precisa perguntar:

O que está sendo armazenado?

Quem pode acessar?

Esse dado precisa permanecer identificável?

Ele deveria chegar ao próximo sistema?

Como descobriremos quando algo inadequado for enviado?

O que levo deste laboratório

O principal aprendizado do GSP1281 não foi encontrar um número de documento dentro de um arquivo.

Foi entender que segurança de dados pode ser organizada como um pipeline.

Descobrir
    ↓
Classificar
    ↓
Investigar
    ↓
Transformar
    ↓
Liberar
    ↓
Monitorar

Discovery oferece visão ampla.

Inspection oferece profundidade.

De-identification permite utilizar dados sem expor necessariamente seus valores originais.

BigQuery transforma findings em evidência analisável.

Security Command Center conecta o risco dos dados à postura geral de segurança.

E os templates transformam configurações pontuais em políticas reutilizáveis.

O dado mais seguro não é apenas aquele que está criptografado. É aquele cuja existência, sensibilidade, finalidade e acesso são conhecidos.

Próximo capítulo

No próximo passo da jornada, a evolução natural é sair da execução manual e projetar uma solução automatizada:

Como impedir que dados sensíveis cheguem ao seu pipeline de IA

Vamos transformar o conhecimento deste laboratório em uma arquitetura de produção com:

Landing zone
Quarentena
Inspeção automática
Desidentificação
Buckets sanitizados
BigQuery
Vertex AI
RAG
IAM
Observabilidade
Infraestrutura como código

Esse será o ponto em que a série deixa de apenas registrar um laboratório e começa a construir uma referência prática de engenharia para ambientes reais.

Referências oficiais

• Sensitive Data Protection documentation
• Sensitive Data Protection infoTypes reference
• Templates overview
• Inspecting storage
• De-identifying data in Cloud Storage
• Sensitive Data Protection actions
• Security Command Center integration