Pipeline seguro com RGPD: anonimizar DCP antes do armazenamento
Atualizado para 2026
Você etiquetou suas colunas de DCP no dbt. Você configurou o mascaramento dinâmico no Snowflake. Você se sente em conformidade com o RGPD.
Seus dados de origem ainda chegam ao armazém sem mascaramento. O mascaramento é aplicado no momento da consulta. O conteúdo sem mascarar fica no seu esquema bruto. Qualquer pessoa com acesso a esse esquema pode lê-lo. Seus modelos dbt rodaram antes de as políticas de mascaramento existirem. Tabelas ingeridas antigas nunca foram mascaradas.
A lacuna entre "temos políticas de mascaramento" e "nosso pipeline está seguro" é onde as violações do RGPD acontecem.
Consulte nossa visão geral de conformidade para ver como o anonym.legal apoia as obrigações do RGPD.
Como os pipelines ELT expõem DCP
O padrão Extract-Load-Transform (ELT) é agora a norma. Ele carrega primeiro os dados de origem no armazém. As transformações vêm depois. Os passos são assim:
- Extração: Sistemas de origem exportam todos os campos. Salesforce CRM, pagamentos Stripe, suporte Intercom — tudo sai.
- Carga: Dados de origem chegam ao esquema de ingestão do armazém. Snowflake, BigQuery, Redshift funcionam da mesma forma. Cada campo de DCP está incluído.
- Transformação: Modelos dbt limpam e unem os dados para análise.
A camada de ingestão contém informações pessoais completas. Nomes, endereços de e-mail, números de telefone, detalhes de pagamento, texto de tickets de suporte. Em muitas equipes, engenheiros e analistas têm acesso ao esquema bruto. Eles podem consultar essas tabelas a qualquer momento.
O mascaramento baseado em tags no Snowflake ajuda no momento das consultas — mas apenas para modelos downstream corretamente configurados. Ele não mascara tabelas ingeridas antigas. Ele não bloqueia consultas diretas ao esquema. Cada modelo e painel precisa ser etiquetado. Esse fardo cresce com o esquema.
Anonimizar antes de carregar
Anonimizar DCP no nível do pipeline remove o risco da camada de ingestão. Faça isso antes que o conteúdo chegue ao armazém.
Abordagem ETL (anonimização pré-carga):
- Extrair dos sistemas de origem
- Passar por uma etapa de anonimização
- Carregar saída limpa no armazém
O armazém nunca recebe DCP sem mascaramento. O esquema de ingestão contém apenas conteúdo limpo. Modelos downstream, painéis e consultas diretas trabalham com saída limpa.
Você tem dois caminhos principais.
Opção 1 — Integração de API:
Para sistemas com webhooks ou exportações em streaming, roteie as entradas pela API do anonym.legal primeiro. Tickets de suporte saindo do Intercom passam pela API antes do armazém. Exportações do Stripe fazem o mesmo.
POST /api/anonymize
{
"text": "O cliente João Silva (joao@example.com) relatou...",
"entities": ["PERSON", "EMAIL_ADDRESS", "PHONE_NUMBER"],
"method": "replace"
}
Opção 2 — Pré-processamento em lote:
Para exportações de arquivos CSV/JSON diários ou semanais, processe arquivos em lote antes de carregar.
Estrutura DAG do Airflow:
extract_task >> anonymize_batch_task >> load_to_warehouse_task
A tarefa de anonimização envia arquivos e recupera versões limpas. A tarefa de carga cuida do resto.
Consulte nossa página de práticas de segurança para detalhes sobre subprocessadores e fluxos de dados.
O que as tags de coluna dbt fazem e não fazem
O dbt permite etiquetar colunas de DCP:
models:
- name: stg_customers
columns:
- name: email
tags: ['pii', 'email']
- name: full_name
tags: ['pii', 'personal_data']
As tags permitem:
- Documentar onde vivem os DCP
- Acionar políticas de mascaramento downstream (requer configuração no nível do armazém)
- Rastrear linhagem com ferramentas como Secoda
As tags não permitem:
- Mascarar tabelas ingeridas no esquema bruto
- Bloquear consultas diretas às tabelas
- Anonimizar no momento do carregamento
- Mascarar dados antigos retroativamente
As tags de coluna dbt são uma ferramenta de governança. Elas mostram onde estão os DCP. Elas não aplicam as "medidas técnicas adequadas" que o Artigo 32 do RGPD exige.
A lacuna do mascaramento dinâmico do Snowflake
O mascaramento dinâmico do Snowflake oculta o conteúdo de colunas dos usuários no momento das consultas. É um controle poderoso para casos de uso em produção. Mas tem limites claros.
Limites principais:
- Cada nova coluna precisa de uma política explícita
- Mudanças de esquema podem deixar novas colunas sem mascaramento até atualizar as políticas
- Papéis SYSADMIN e ACCOUNTADMIN geralmente conseguem contornar o mascaramento
- Trabalhos de importação frequentemente rodam com privilégios elevados que ignoram o mascaramento
- Dados antigos carregados antes das políticas existirem são armazenados em texto claro — as políticas se aplicam na leitura, não na escrita
Mascaramento no momento das consultas não é suficiente. Os dados devem estar limpos antes de serem armazenados.
Documentação de conformidade
O princípio de responsabilidade do RGPD exige provas. Palavras não bastam. Para equipes de engenharia, isso significa registros escritos.
Registro de atividades de tratamento (RAT): Documente que as informações de clientes são anonimizadas antes de serem carregadas no armazém analítico. A etapa de anonimização é uma atividade de tratamento sob o RGPD.
Notas sobre medidas técnicas: Anote quais tipos de entidades seu pipeline processa. Anote o método de anonimização usado. Os registros de processamento em lote fornecem isso automaticamente.
Linhagem de dados: Secoda ou a linhagem embutida do dbt pode mostrar que as tabelas de origem passam por uma etapa de anonimização antes de chegar aos modelos analíticos. Esse é o seu rastro de auditoria.
Registro de fornecedores: O serviço de anonimização é um subprocessador. Seu DPA e política de privacidade devem estar no seu registro de fornecedores.
Passos de implementação
Para um pipeline com dbt e Snowflake:
Passo 1: Auditar a camada bruta
Encontre quais tabelas contêm informações pessoais. Consulte suas tags de coluna dbt ou seu catálogo para tabelas etiquetadas como DCP.
Passo 2: Definir o escopo de anonimização
Para cada tabela de origem, decida quais colunas contêm DCP. Então decida quais precisam de anonimização e quais precisam de pseudonimização. Corpo do ticket de suporte: anonimizar. ID do pedido: pseudonimizar para manter chaves de junção. Timestamp: manter para análise de séries temporais.
Passo 3: Escolher um caminho de implementação
Equipe pequena com exportações em lote: processamento de arquivos em lote antes de carregar. Equipe de engenharia disponível: integração de API no Airflow ou Prefect.
Passo 4: Testar e validar
Execute a anonimização em uma amostra antes de ir para produção. Verifique se os modelos dbt ainda funcionam. Alguns modelos fazem junções por e-mail. Esses precisam de valores de substituição consistentes. A pseudonimização mantém as chaves de junção. A supressão as quebra.
Passo 5: Processar tabelas antigas
Conteúdo carregado antes de a anonimização ser implementada precisa de processamento retroativo. Exportar, anonimizar, recarregar. É uma operação única por tabela.
Conclusão
O mascaramento baseado em tags mostra onde vivem os DCP. Ele não impede usuários com acesso ao esquema de lê-los. Para conformidade real com o RGPD, os DCP devem estar limpos antes de chegar ao armazém. Isso torna a camada de ingestão tão segura quanto a camada de produção.
Isso é mais difícil do que etiquetar colunas. Mas é o que "medidas técnicas adequadas" realmente significa.