Proteger, reter e provar

🌐 Também em 28 idiomas

English · Español · 日本語 · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Imagem gerada com IA

Traduzido por IA. Ainda não revisado pela comunidade. Ler em inglês

Módulo 6 de 6 do capítulo Qualidade e governança de dados, capítulo 5 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: Consentimento e direito ao esquecimento · Próximo: o próximo capítulo, Dados mestres e identidade

A pergunta que este módulo responde: Como proteger os dados, guardá-los pelo tempo exigido, e provar isso?

Definimos donos e políticas, mantivemos os dados ruins do lado de fora, escrevemos o dicionário, rastreamos a linhagem, classificamos o que importa, aprendemos as leis e modelamos o consentimento. Agora precisamos colocar isso para rodar. Os dados chegam, são usados, copiados e alterados, envelhecem e, um dia, parte deles precisa sair. E um dia alguém vai pedir: prove o que aconteceu.

A governança segue os dados

Não penso na governança como um recurso. Penso no que acontece com os dados do momento em que entram até terminarmos com eles:

Capturar → Classificar → Proteger → Usar → Reter → Excluir → Auditar

Não sete processos técnicos: sete perguntas que a arquitetura precisa responder. Capturar e classificar já cobrimos: manter do lado de fora os erros caros (módulo 2), e saber quais dados são sensíveis (módulo 3). A classificação decide o que acontece em cada etapa seguinte, então este módulo continua dali.

Click to enlarge

Sete perguntas ao longo da vida dos dados. As ferramentas apoiam a política; não a definem.

Proteger: ajuste o controle aos dados

Quem pode vê-los, alterá-los, recebê-los? Devem ser criptografados, mascarados fora da produção, exportáveis, alcançáveis por um agente? É aqui que a segurança do Salesforce passa a fazer parte da governança de dados: compartilhamento, permissões de objeto e de campo, criptografia, mascaramento, acesso das integrações. Esses temas enchem cursos inteiros, então não vou ensiná-los de novo. O ponto de governança: a proteção segue a classificação e a política. Nem todo campo precisa da mesma proteção, nem todo usuário do mesmo acesso, nem todo sistema mais adiante de todos os campos.

Criptografia é um controle, não conformidade

Para dados regulados, a criptografia em repouso pode ser exigida, e minha posição é que o Shield é a resposta para requisitos regulatórios-chave como esse. O Shield Platform Encryption criptografa campos e arquivos em repouso. Mas “criptografamos, então estamos em conformidade” está errado duas vezes. A criptografia é um controle entre acesso, retenção, auditoria, consentimento, monitoramento, minimização e exclusão. E ela tem trade-offs funcionais para os quais você projeta desde o início. Com o esquema probabilístico padrão, um campo criptografado não pode ser usado em cláusulas WHERE, GROUP BY ou ORDER BY de SOQL nem em filtros de gerenciamento de dados; a criptografia determinística abre mão de um pouco de força para que você consiga filtrar pelo campo. Campos criptografados não podem guiar regras de compartilhamento baseadas em critérios, e você não consegue ordenar visualizações de lista por eles (General Shield Platform Encryption Considerations (opens in a new tab); Filter Encrypted Data with Deterministic Encryption (opens in a new tab), em inglês). Então a criptografia não é uma caixa de seleção no fim. É uma decisão de arquitetura. O capítulo de segurança de dados vai mais fundo.

Não copie o risco da produção para o sandbox

A produção está trancada. Aí alguém atualiza um sandbox completo, e desenvolvedores, testadores, terceirizados e integrações de teste passam a ter cópias de dados pessoais reais de que nunca precisaram. O ambiente mudou; a sensibilidade dos dados não. As ferramentas de mascaramento da Salesforce existem exatamente para isso. Note uma mudança: o pacote gerenciado Data Mask chega ao fim do serviço em 31 de dezembro de 2026, e seu sucessor é o Data Mask & Seed (Data Mask (Legacy) (opens in a new tab), em inglês). Mas a ferramenta sustenta a política, e a pergunta vem antes: este ambiente precisa sequer de dados sensíveis reais? Se dados realistas e não sensíveis dão conta dos testes, essa é a melhor resposta.

Usar: permissão não diz respeito só a pessoas

Usuários, integrações, análise, parceiros, automação e agentes, todos usam os dados. O consentimento (módulo 5), a propriedade (módulo 1) e a classificação (módulo 3) se encontram aqui, em tempo de execução. Este usuário deve ver o telefone do Destinatário? Esta integração deve recebê-lo, ou o Snowflake, ou este agente como embasamento? A resposta não pode ser “bom, tecnicamente pode”. Essa é a diferença entre capacidade e governança: a arquitetura decide se deve.

Reter: guardar tudo para sempre não é neutro

Muitas organizações têm uma política de retenção acidental: para sempre. Ninguém decidiu isso; havia armazenamento disponível, então os dados ficaram. Mas guardar dados custa armazenamento e desempenho, amplia a exposição de privacidade e segurança, acrescenta obrigações de descoberta, e lhe dá mais lugares para procurar quando alguém pede para ser esquecido. Para cada categoria importante: por que guardar, por quanto tempo, o que dispara o relógio, há um mínimo legal ou um máximo de privacidade, e o que acontece no fim: arquivar, excluir, desidentificar?

E arquivar não é o mesmo que resolver a retenção. “Arquivamos.” O requisito de retenção sumiu? O requisito de privacidade? A segurança? Você mudou onde os dados vivem, não o que eles são. Um arquivo precisa de controles de acesso, regras de retenção e de exclusão, descoberta e auditoria. Mova dados pessoais para um arquivo de que todo mundo se esquece, e a governança acabou de piorar.

Excluir: o ciclo de vida precisa de uma saída

A exclusão não serve só para pedidos individuais de privacidade. Os dados chegam ao fim do prazo de retenção; registros temporários sobrevivem ao seu uso; arquivos expiram; um processo desidentifica depois de um tempo definido. Seja o que for que a política diga, a arquitetura precisa de uma saída, não de capturar → armazenar → armazenar mais → armazenar para sempre. E, como mostrou o módulo 5, excluir o registro no Salesforce não basta quando há cópias vivendo em outros lugares.

O histórico também é dado

Às vezes o valor atual não basta. A razão social de um parceiro, a classificação de um cliente, um status de consentimento, um atributo financeiro: o negócio ou um regulador pode precisar saber o que era antes, quando mudou e quem mudou. Esse histórico é dado, e precisa de sua própria decisão de retenção.

O histórico de campos padrão acompanha até 20 campos por objeto e guarda as mudanças por até 18 meses, e por até 24 meses só pela API, com o Data Loader ou queryAll() (Field History Tracking Overview (opens in a new tab), em inglês). E, para campos de texto longo, ele registra só que o campo foi editado, não o que dizia: uma lacuna, se essa é a sua evidência. O Field Audit Trail, parte do Shield ou comprado à parte, acompanha até 200 campos por objeto e guarda o histórico até você excluí-lo, num arquivo que você acessa pela API (Field Audit Trail (opens in a new tab), em inglês). Minha posição: o histórico de campos padrão é o default; use o Field Audit Trail quando uma regulação ou obrigação de conformidade exigir um histórico mais longo e comprovável. Não porque “auditoria soa bem”.

Auditar e monitorar não são a mesma coisa

O histórico de campos responde a perguntas sobre mudanças em campos selecionados. Perguntas mais amplas (quem fez login, quem exportou dados, quais APIs foram chamadas, quem viu o quê) são monitoramento, e isso é o Event Monitoring. Na minha experiência ele normalmente é necessário em clientes mais regulados, e eis minha posição mais forte neste capítulo: configure-o antes de precisar dele, e canalize os eventos para um repositório, como o Splunk ou outro SIEM, com antecedência.

Eis por quê. Os arquivos de log de eventos são guardados por 1 dia sem o complemento, e só para alguns tipos de evento; 30 dias por padrão com o Shield ou o complemento Event Monitoring, e até 365 dias se você estender a retenção (Event Monitoring FAQ (opens in a new tab), em inglês). O que for mais antigo some, a menos que você tenha exportado. E os logs pagos não podem ser recuperados para nenhum período anterior ao início do seu contrato (mesmo FAQ): comprar o complemento depois do incidente não traz o passado de volta. Então uma das piores conversas que um arquiteto pode ter é assim: “Conseguimos ver o que aconteceu seis meses atrás?” “Não.” “Por que não?” “Não estávamos capturando.” Você não quer dar de cara com um problema e então descobrir que não vinha capturando e guardando esses eventos. A essa altura, a resposta simplesmente sumiu.

Click to enlarge

Configure antes de precisar.

Mas não vá para o extremo de “registrar tudo”. O que você está tentando provar? Quais eventos importam, quem precisa deles, por quanto tempo, quem pode ler os logs, e os próprios logs podem conter dados sensíveis? Registrar cria dados, e esses dados também precisam de governança. E as evidências precisam de um dono: quem é dono do repositório, revisa os alertas, verifica se a retenção funciona, percebe que o feed falhou em silêncio três meses atrás? Tecnologia sem dono não é governança; voltamos ao proprietário, ao data steward e ao custodiante do módulo 1.

Prove o controle, não só a configuração

“Os dados do Destinatário estão disponíveis só para as equipes atribuídas à parada.” Como sabemos? A configuração de segurança mostra o que deveria acontecer. As evidências operacionais (quem de fato os acessou, exportações incomuns, uma integração puxando esses dados, controles de acesso alterados) mostram o que aconteceu. Uma boa governança muitas vezes precisa das duas.

Além do exame: o que a IA muda. À medida que os agentes passam de responder a agir, a governança precisa de evidências do que o agente viu, do que decidiu ou gerou, e do que fez, e de quem ou o que o iniciou, sob qual política. Os mecanismos de registro vão mudar; o requisito não: se uma ação autônoma importa, projete agora como você vai reconstruí-la depois.

Steve Trucking: o ciclo de vida num campo

Pegue o telefone do Destinatário. Capturar: ele chega no manifesto do parceiro; verifique se é utilizável onde o processo precisa dele. Classificar: dado pessoal. Proteger: só pessoas e sistemas com necessidade operacional o recebem, e as equipes o veem só nas suas próprias paradas, no dia. Usar: a equipe coordena a entrega; o sistema de mensagens o usa para uma finalidade aprovada; um agente o usa só se a política permitir. Reter: pelo tempo que a política de negócio e de privacidade aprovada disser. Excluir ou desidentificar: quando esse prazo terminar ou chegar um pedido válido, em cada cópia do panorama. Auditar: guarde a evidência de que os controles e as ações aconteceram.

Agora pegue o código de um centro de distribuição. Capture-o com precisão, classifique-o como dado de referência não sensível, proteja-o com acesso operacional comum, use-o amplamente, guarde-o pelo tempo que o negócio precisar, e audite as mudanças se elas importarem. Mesmo ciclo de vida, controles diferentes. É para isso que serve a classificação.

A governança nunca termina

Surge uma nova regulação. Um novo sistema ou integração cria mais uma cópia. Uma equipe inventa mais um campo. Uma nova plataforma entra em produção. Um agente ganha acesso. Uma regra de retenção muda. Chega um novo Parceiro varejista. A arquitetura se move, e a governança se move com ela. O objetivo não são dados perfeitos, controles infinitos ou um documento de governança que ninguém lê. São decisões deliberadas sobre os dados, construídas dentro da arquitetura.

O que um arquiteto decide aqui

• Que controles de proteção cada categoria de dados recebe, com base na classificação, na política e no uso real, incluindo os trade-offs da criptografia.
• Por quanto tempo os dados e o histórico deles são guardados, o que dispara o relógio, e o que acontece no fim.
• Quando o histórico de campos padrão basta e quando uma regulação pede o Field Audit Trail.
• Quais eventos são capturados, onde as evidências são guardadas além da retenção da plataforma, e quem é dono delas.
• Como a arquitetura prova, depois do fato, as ações importantes de pessoas, integrações e agentes.

Este capítulo começou com uma ideia: a governança é projetada dentro da org, não escrita ao lado dela. Os donos definem a política e os arquitetos a aplicam. Mantenha os dados ruins do lado de fora onde isso importa. Saiba o que seus dados significam, de onde vieram e quão sensíveis são. Respeite as leis, modele o consentimento, controle para onde vão os dados pessoais. Proteja, retenha e exclua conforme a política. E capture as evidências antes que alguém as peça, porque seis meses depois de um incidente é uma péssima hora para descobrir que as evidências só existiam por trinta dias.

Para saber mais

• Salesforce Help, General Shield Platform Encryption Considerations (opens in a new tab) e Filter Encrypted Data with Deterministic Encryption (opens in a new tab) (em inglês), consultados em 2026-10-14.
• Salesforce Help, Field History Tracking Overview (opens in a new tab) (em inglês), consultado em 2026-10-14.
• Salesforce Help, Field Audit Trail (opens in a new tab) (em inglês), consultado em 2026-10-14.
• Salesforce Help, Salesforce Event Monitoring Frequently Asked Questions (opens in a new tab) (em inglês), consultado em 2026-10-14.
• Salesforce Help, Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (opens in a new tab) (em inglês), consultado em 2026-10-14.