Sobre este conteúdo
Este artigo aprofunda DSPM (Data Security Posture Management) além do básico de descoberta — classificação contextual com IA, lineage entre data lakes e priorização por blast radius. Para o panorama comparativo de CSPM/CWPP/DSPM, veja CSPM, DSPM e SSPM.
Neste artigo
Por que DSPM evoluiu
A primeira geração de DSPM (2021-2022) resolveu um problema visível: descobrir dados sensíveis em cloud storage e banco transacional, usando regex e algumas heurísticas. Funcionava em casos simples — bucket S3 com .csv aberto, banco MySQL com coluna chamada cpf.
Três deslocamentos forçaram a evolução para o que hoje se chama DSPM avançado (ou DSPM de segunda geração):
- Dados migraram para data lakes: Snowflake, Databricks Unity Catalog, BigQuery, Iceberg/Delta passaram a ser o repositório dominante. Regex sobre arquivos em S3 não cobre uma view materializada de Snowflake com 50 milhões de linhas.
- Volume virou contexto: achar PII por padrão deixou de ser interessante porque encontra-se PII em milhares de lugares. O que importa é distinguir PII sensível e exposta de PII operacional e controlada.
- Lineage tornou-se prático: Snowflake Access History, BigQuery audit logs, Databricks Unity Catalog passaram a expor o grafo de origem e propagação. DSPM passou a poder cruzar exposição com lineage e priorizar.
Classificação com IA: além do regex
Regex consegue achar "123.456.789-00" em um campo chamado cpf. Falha em três cenários comuns:
| Cenário | Por que regex falha | O que DSPM avançado faz |
|---|---|---|
CPF colado em campo notes sem rótulo | Padrão correto mas no campo errado | NER (Named Entity Recognition) identifica entidade em texto livre |
| Mesma coluna em produção (sensível) e em dataset CGU (público) | Regex não vê contexto | Classificação considera grants, tags do warehouse, origem por lineage |
| Embedding de PII em vetor (LLM ou similarity search) | Não há padrão textual | Detecção semântica via embeddings — algumas plataformas verificam reconstruibilidade |
Os motores de DSPM avançado tipicamente combinam três camadas: regex + dicionários (rápido, baseline), modelos NER fine-tuned (NLP), e classificadores semânticos baseados em embeddings. O resultado é uma classificação contextual: o mesmo CPF é classificado diferente conforme onde mora, quem acessa e de onde veio.
Lineage de dados: o grafo que faltava
Lineage é o grafo de origem e propagação. Exemplo: "a tabela analytics.cust_2026 veio do JOIN entre raw.customers e raw.orders, foi materializada por job às 03h, é lida pelo dashboard X e exportada para o sandbox Y todo domingo".
Em segurança importa porque expõe shadow data: dados sensíveis que vazaram para zonas menos protegidas. Sem lineage, um vazamento em sandbox de analytics não é rastreável ao dado de origem; com lineage, você sabe imediatamente que aquele snapshot continha PII de 200 mil clientes e qual job o gerou — informação crítica para notificação LGPD/GDPR.
Snowflake
ACCESS_HISTORY views expõem lineage column-level. DSPM consome via service account e cruza com classificação.
Databricks
Unity Catalog mantém lineage de tabelas e notebooks. DSPM lê via REST API ou Delta sharing.
BigQuery
Audit logs em Cloud Logging mais Dataplex Data Lineage. DSPM correlaciona consultas, jobs e tabelas-destino.
Shadow data e dumps fora do escopo
O maior achado de DSPM em quase toda implementação é a categoria de shadow data: cópias de produção em sandboxes, dumps em buckets pessoais, snapshots de banco em DEV. Por padrão eles não aparecem em inventário corporativo, mas existem e contêm os mesmos dados sensíveis. Três fontes típicas:
- Backups esquecidos: dump.sql em /tmp/, snapshots de RDS antigos não-versionados, exports csv em buckets criados ad-hoc para um projeto que terminou.
- Cópias para analytics/ML: equipe de data science precisa de amostra de produção; em vez de anonimizar, copia-se "só para teste".
- Compartilhamento externo descontrolado: Snowflake data share para parceiro, link de drive externo, GitHub Actions com export para Slack.
DSPM moderno descobre essas zonas via varredura de toda a conta cloud (não só os data stores principais), prioriza pela combinação de classificação + exposição, e idealmente integra com remediação automática (IaC para fechar bucket, revogar share).
Priorização contextual de achados
O erro clássico é tratar todo dataset com PII como prioridade igual. Priorização contextual usa quatro dimensões multiplicadas:
| Dimensão | Como medir | Por que importa |
|---|---|---|
| Sensibilidade | Classe de dado: PII menor < cartão < saúde < autenticação | Multas LGPD/GDPR/HIPAA crescem com a classe |
| Volume | Número de registros (ou ordem de magnitude) | Impacto regulatório e reputacional cresce com volume |
| Exposição | Quem pode acessar: público > toda org > squad > DBA | Probabilidade de vazamento varia com superfície |
| Blast radius | Lineage: quantos sistemas/relatórios dependem | Quebrar acesso pode interromper negócio |
A fila de remediação resultante respeita risco real e não puro volume. Sem essas quatro dimensões, o DSPM gera 5.000 achados que ninguém remedia. Com elas, gera uma fila de 50 ações que efetivamente reduzem exposição.
Integração com IR, DLP e governança
DSPM cresce em valor quando alimenta outras peças:
- SIEM/SOAR: alertas de mudança de exposição (bucket fica público, grant em produção concedido a guest) vão para playbook de IR.
- DLP: classificação descoberta por DSPM alimenta políticas DLP (Purview, Symantec, Forcepoint). Não precisa configurar manualmente "o que é confidencial".
- Governança de dados (Collibra, Alation): DSPM enriquece o catálogo com classificação automática — economiza meses de trabalho manual.
- Pipeline LGPD/GDPR: mapeamento de tratamentos por finalidade fica mais simples quando você sabe onde os dados estão e quem acessa.
Roadmap de implementação
Mapear data stores prioritários
Cloud storage (S3, Blob, GCS), bancos transacionais, lakehouse (Snowflake/Databricks/BigQuery). Habilite leitura de metadados via service account — não precisa exfiltrar dados.
Classificar e calibrar
Rode classificação automática. Revise top-200 achados com data owners. Isso calibra o modelo e estabelece base de confiança.
Habilitar lineage
Integre com Snowflake Access History, BigQuery audit logs, Databricks Unity Catalog. Sem lineage, priorização por blast radius é chute.
Priorizar e remediar
Aplique as quatro dimensões. Atacar as top-50 exposições antes de mexer no resto. Documente padrões de remediação para reaproveitar.
Integrar com SIEM/DLP/governança
Alertas de mudança de exposição vão para IR. Classificação alimenta DLP. Catálogo de governança recebe enriquecimento automático.
Cobrir shadow data
Varra contas inteiras, não só data stores conhecidos. Dumps em buckets pessoais, snapshots em DEV — onde o achado é mais surpreendente, geralmente.
Perguntas frequentes
Por que DSPM clássico (só regex) não é mais suficiente?
Regex acha PII no campo certo, mas falha em campos notes/descrição, ignora contexto (PII operacional vs. exposta) e não pega embeddings semânticos. DSPM avançado combina padrões + NER + classificadores semânticos + lineage para classificação contextual.
O que é lineage de dados e por que importa?
Grafo de origem e propagação. Em segurança expõe shadow data: dados sensíveis que vazaram para zonas menos protegidas. Sem lineage, vazamento em sandbox não é rastreável; com lineage, identifica-se imediatamente o dataset de origem e quantos registros eram.
DSPM moderno cobre Snowflake, Databricks, BigQuery?
Sim — esse é o ponto de inflexão. Plataformas modernas (Wiz, Cyera, Sentra, BigID, Symmetry, IBM Guardium DSPM) cobrem data lakes como cidadãos de primeira classe: leem schema, classificam colunas, mapeiam grants e detectam exposições.
DSPM substitui DLP?
Não. DLP atua em movimento (e-mail, endpoint, gateway) e bloqueia em tempo real. DSPM atua em repouso (cloud storage, data lakes) e descobre/classifica/mapeia exposição. Em programas modernos, ambos coexistem.
Como priorizar achados de DSPM?
Quatro dimensões multiplicadas: sensibilidade × volume × exposição × blast radius (via lineage). Sem isso, DSPM gera 5.000 alertas que ninguém ataca; com isso, 50 ações que reduzem risco real.
Como começar com DSPM avançado?
Mapeie data stores prioritários → classifique e calibre → habilite lineage → priorize e remedie top exposições → integre com SIEM/DLP/governança → cubra shadow data.
Referências
- Gartner — Innovation Insight for Data Security Posture Management
- Snowflake — Access History documentation — docs.snowflake.com
- Databricks — Unity Catalog Lineage — docs.databricks.com
- Google Cloud — Dataplex Data Lineage — cloud.google.com/dataplex
- ANPD — Guia de Orientação para Definições dos Agentes de Tratamento