Proteger, reter e provar

🌐 Também em 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · 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 com IA. Ainda não revisto pela comunidade. Ler em inglês

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

A pergunta que este módulo responde: Como proteger os dados, guardá-los durante o tempo exigido, e prová-lo?

Definimos donos e políticas, mantivemos os dados maus lá fora, escrevemos o dicionário, rastreámos a linhagem, classificámos o que importa, aprendemos as leis e modelámos o consentimento. Agora temos de pôr isto a funcionar. Os dados chegam, são usados, copiados e alterados, envelhecem e, um dia, parte deles tem de sair. E um dia alguém vai pedir: prove o que aconteceu.

A governação segue os dados

Não penso na governação como uma funcionalidade. Penso no que acontece aos dados desde o momento em que entram até terminarmos com eles:

Capturar → Classificar → Proteger → Usar → Reter → Eliminar → Auditar

Não são sete processos técnicos: são sete perguntas a que a arquitetura tem de responder. Capturar e classificar já tratámos: manter lá fora os erros caros (módulo 2), e saber que dados são sensíveis (módulo 3). A classificação decide o que acontece em cada etapa seguinte, por isso este módulo continua a partir daí.

Click to enlarge

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

Proteger: ajuste o controlo aos dados

Quem os pode ver, alterar, receber? Devem ser encriptados, mascarados fora da produção, exportáveis, alcançáveis por um agente? É aqui que a segurança do Salesforce passa a fazer parte da governação de dados: partilha, permissões de objeto e de campo, encriptação, mascaramento, acesso das integrações. Estes temas enchem cursos inteiros, por isso não os vou voltar a ensinar. O ponto de governação: a proteção segue a classificação e a política. Nem todos os campos precisam da mesma proteção, nem todos os utilizadores do mesmo acesso, nem todos os sistemas a jusante de todos os campos.

A encriptação é um controlo, não conformidade

Para dados regulados, a encriptação em repouso pode ser exigida, e a minha posição é que o Shield é a resposta para requisitos regulatórios-chave como esse. O Shield Platform Encryption encripta campos e ficheiros em repouso. Mas «encriptámos, por isso estamos em conformidade» está errado duas vezes. A encriptação é um controlo entre acesso, retenção, auditoria, consentimento, monitorização, minimização e eliminação. E tem trade-offs funcionais para os quais se projeta desde o início. Com o esquema probabilístico por defeito, um campo encriptado não pode ser usado em cláusulas WHERE, GROUP BY ou ORDER BY de SOQL nem em filtros de gestão de dados; a encriptação determinística abdica de um pouco de força para que consiga filtrar pelo campo. Os campos encriptados não podem orientar regras de partilha baseadas em critérios, e não consegue ordenar vistas 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). Por isso a encriptação não é uma caixa de verificação no fim. É uma decisão de arquitetura. O capítulo de segurança de dados vai mais a fundo.

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

A produção está trancada. Depois alguém atualiza uma sandbox completa, e programadores, testadores, subcontratados 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 isto. Note uma mudança: o pacote gerido Data Mask chega ao fim do serviço a 31 de dezembro de 2026, e o 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 chegam para os testes, essa é a melhor resposta.

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

Utilizadores, 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) encontram-se aqui, em tempo de execução. Este utilizador deve ver o telefone do Destinatário? Esta integração deve recebê-lo, ou o Snowflake, ou este agente como fundamentação? A resposta não pode ser «bem, tecnicamente pode». Essa é a diferença entre capacidade e governação: 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 a decidiu; havia armazenamento disponível, por isso os dados ficaram. Mas guardar dados custa armazenamento e desempenho, alarga a exposição de privacidade e segurança, acrescenta obrigações de descoberta, e dá-lhe mais sítios onde procurar quando alguém pede para ser esquecido. Para cada categoria importante: porquê guardar, durante quanto tempo, o que faz começar a contar o prazo, há um mínimo legal ou um máximo de privacidade, e o que acontece no fim: arquivar, eliminar, desidentificar?

E arquivar não é o mesmo que resolver a retenção. «Arquivámos.» O requisito de retenção desapareceu? O requisito de privacidade? A segurança? Mudou onde vivem os dados, não o que são. Um arquivo precisa de controlos de acesso, regras de retenção e de eliminação, descoberta e auditoria. Mova dados pessoais para um arquivo de que toda a gente se esquece, e a governação acabou de piorar.

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

A eliminação não serve só para pedidos individuais de privacidade. Os dados chegam ao fim do prazo de retenção; registos 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, eliminar o registo no Salesforce não basta quando há cópias a viver noutros sítios.

O histórico também são dados

Às vezes o valor atual não basta. A denominação social de um parceiro, a classificação de um cliente, um estado de consentimento, um atributo financeiro: o negócio ou um regulador pode precisar de saber o que era antes, quando mudou e quem o mudou. Esse histórico são dados, e precisa da 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 durante até 18 meses, e 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, nos campos de texto longo, regista 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é o eliminar, num arquivo a que acede pela API (Field Audit Trail (opens in a new tab), em inglês). A minha posição: o histórico de campos padrão é o ponto de partida; 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 monitorizar não são o mesmo

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

Eis porquê. Os ficheiros de log de eventos são guardados durante 1 dia sem o extra, e só para alguns tipos de evento; 30 dias por defeito com o Shield ou o extra Event Monitoring, e até 365 dias se alargar a retenção (Event Monitoring FAQ (opens in a new tab), em inglês). O que for mais antigo desaparece, a menos que o tenha exportado. E os logs pagos não podem ser recuperados para nenhum período anterior ao início do seu contrato (mesmas FAQ): comprar o extra depois do incidente não traz o passado de volta. Por isso, uma das piores conversas que um arquiteto pode ter é assim: «Conseguimos ver o que aconteceu há seis meses?» «Não.» «Porque não?» «Não estávamos a capturar.» Não quer dar de caras com um problema e só então descobrir que não andava a capturar e a guardar esses eventos. A essa altura, a resposta simplesmente desapareceu.

Click to enlarge

Configure antes de precisar.

Mas não vá para o extremo de «registar tudo». O que está a tentar provar? Que eventos importam, quem precisa deles, durante quanto tempo, quem pode ler os logs, e os próprios logs podem conter dados sensíveis? Registar cria dados, e esses dados também precisam de governação. E as evidências precisam de um dono: quem é dono do repositório, revê os alertas, verifica se a retenção funciona, repara que o feed falhou em silêncio há três meses? Tecnologia sem dono não é governação; voltamos ao proprietário, ao data steward e ao custodiante do módulo 1.

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

«Os dados do Destinatário estão disponíveis só para as equipas atribuídas à paragem.» Como sabemos? A configuração de segurança mostra o que deveria acontecer. As evidências operacionais (quem lhes acedeu de facto, exportações invulgares, uma integração a ir buscar esses dados, controlos de acesso alterados) mostram o que aconteceu. Uma boa governação precisa muitas vezes das duas.

Além do exame: o que a IA muda. À medida que os agentes passam de responder a agir, a governação 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 que política. Os mecanismos de registo vão mudar; o requisito não: se uma ação autónoma importa, projete agora como a vai reconstruir depois.

Steve Trucking: o ciclo de vida num campo

Pegue no telefone do Destinatário. Capturar: 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 equipas veem-no só nas suas próprias paragens, no dia. Usar: a equipa coordena a entrega; o sistema de mensagens usa-o para uma finalidade aprovada; um agente usa-o só se a política o permitir. Reter: durante o tempo que a política de negócio e de privacidade aprovada disser. Eliminar 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 controlos e as ações aconteceram.

Agora pegue no 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 durante o tempo que o negócio precisar, e audite as mudanças se importarem. O mesmo ciclo de vida, controlos diferentes. É para isso que serve a classificação.

A governação nunca termina

Surge uma nova regulação. Um novo sistema ou integração cria mais uma cópia. Uma equipa 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 retalhista. A arquitetura move-se, e a governação move-se com ela. O objetivo não são dados perfeitos, controlos infinitos ou um documento de governação que ninguém lê. São decisões deliberadas sobre os dados, construídas dentro da arquitetura.

O que um arquiteto decide aqui

• Que controlos de proteção recebe cada categoria de dados, com base na classificação, na política e no uso real, incluindo os trade-offs da encriptação.
• Durante quanto tempo são guardados os dados e o seu histórico, o que faz começar a contar o prazo, e o que acontece no fim.
• Quando basta o histórico de campos padrão e quando uma regulação pede o Field Audit Trail.
• Que eventos são capturados, onde são guardadas as evidências para além da retenção da plataforma, e quem é dono delas.
• Como a arquitetura prova, depois do facto, as ações importantes de pessoas, integrações e agentes.

Este capítulo começou com uma ideia: a governação é projetada dentro da org, não escrita ao lado dela. Os donos definem a política e os arquitetos aplicam-na. Mantenha os dados maus lá fora onde isso importa. Saiba o que os 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 elimine conforme a política. E capture as evidências antes de alguém as pedir, porque seis meses depois de um incidente é uma péssima altura para descobrir que as evidências só existiam durante 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.