--- schema_version: "1" id: 008b8b05446d3b3b1398a708642ece5585c1b28d342e40d03bea4a1b76219072 title: Padrões de proteção de dados collection: architect version: current locale: pt-br portal_url: https://docs.salesforce.com/architect/current/pt-br/well-architected/guides/trust-data-protection-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/trust-data-protection-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: d9dc374f1695dfc0b06c4e52f0d6dc733316d41ff13a06fa60ec97589b40b734 products: - Estrutura bem arquitetada - Architect Site Content Repo --- # Padrões de proteção de dados
Saiba mais sobre Well-Architected [Trust](/docs/architect/pt-br/well-architected/guide/trust.html) → [Proteção de dados e privacidade](/docs/architect/pt-br/well-architected/guide/trust.html#data-protection-and-privacy) ## Classificação de dados **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Esquema de classificação de dados | ✅ Esquema de classificação documentado com níveis (público, interno, confidencial, restrito)
✅ Exemplos de negócios fornecidos para cada nível de classificação
✅ Esquema de classificação alinhado a obrigações regulatórias (HIPAA, PCI DSS, GDPR)
✅ Modeladores de dados treinados para aplicar a classificação de modo consistente durante o design
✅ Novos campos classificados como parte do processo de modelagem de dados, não retroativamente | | Classificação em nível de campo | ✅ Classificação aplicada no nível do campo, não apenas no nível do objeto
✅ Campos em um único objeto podem ter classificações diferentes
✅ A segurança em nível de campo reflete as distinções de classificação
✅ Dados não classificados usam como padrão o nível mais alto de proteção adequado
✅ Classificação gera controles de proteção (criptografia, acesso, retenção) | | Objetos e campos personalizados | ✅ Todos os objetos personalizados têm classificação de dados documentada
✅ Campos confidenciais (salário, SSN, PHI, dados de pagamento) classificados como Confidencial ou Restrito
✅ Campos públicos (nome da empresa, site da Web) documentados como públicos
✅ Metadados de classificação capturados nas descrições de campo
✅ Classificação revisada durante revisões de código e ARB | | Objetos padrão | ✅ Campos de objeto padrão avaliados em relação ao esquema de classificação
✅ Shield Platform Encryption ativado para campos padrão restritos
✅ Segurança em nível de campo aplicada a campos padrão confidenciais
✅ Relatórios e modos de exibição de lista filtrados para evitar a exposição de campos padrão confidenciais | | Dados de integração | ✅ Dados fluindo por integrações classificadas antes da implementação
✅ Sensibilidade de dados do sistema externo avaliada e documentada
✅ Pontos de extremidade de integração que lidam com autenticação baseada em certificado de uso de dados restrito
✅ Classificação de dados preservada entre limites do sistema | | Mapeamento de conformidade | ✅ Campos PHI HIPAA identificados e marcados como Restrito
✅ Dados do titular do cartão PCI evitados no Salesforce quando possível, tokenizados por meio do gateway de pagamento para redução de escopo; quando precisarem ser armazenados, use Campos personalizados criptografados sob controles PCI DSS
✅ Dados pessoais do GDPR identificados e sujeitos a controles de privacidade
✅ Dados financeiros SOX classificados e sujeitos à segregação de tarefas | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Proteção uniforme | ⚡️ A mesma proteção aplicada a todos os campos independentemente da sensibilidade
Dados de baixo valor sobreprotegidos (gastando recursos) enquanto dados de alto valor estão subprotegidos
⚡️ Informações públicas da empresa tratadas da mesma forma que dados de cartão de pagamento ou PHI
⚡️ Cada campo criptografado "apenas para ser seguro" sem justificativa de classificação | | Classificação retroativa | Dados classificados após a implantação na produção
Dados confidenciais descobertos por meio de auditorias de conformidade, em vez de análises de design
Dados classificados apenas após incidentes de segurança
⚡️ "Descobriremos a classificação mais tarde" é o padrão durante o desenvolvimento | | Classificação apenas no nível do objeto | ⚡️ Objetos inteiros classificados uniformemente quando os campos têm sensibilidade diferente
⚡️ Acesso em nível de objeto concedido sem segurança em nível de campo para campos confidenciais
⚡️ Presume-se que todos os campos nos objetos Conta ou Contato tenham a mesma classificação
Permissões de objeto usadas como o único controle de acesso para objetos de sensibilidade mista | | Knowledge tribal | ⚡️ Classificação indocumentada, existente apenas no Knowledge de pessoas-chave
⚡️ Os desenvolvedores dependem de "apenas saber" quais campos são confidenciais
⚡️ Nenhum esquema de classificação escrito está acessível a todos os modeladores de dados
⚡️ Novos membros da equipe integrados sem treinamento de classificação | ## Criptografia **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Criptografia em repouso | ✅ Todos os dados criptografados no nível da infraestrutura por meio do Hyperforce
✅ Shield Platform Encryption ativado para dados restritos
✅ Esquema de criptografia (probabilístico, determinístico, determinístico com diferenciação de maiúsculas e minúsculas) selecionado com base nos requisitos de consulta e exclusividade
✅ Compromissos de criptografia avaliados durante o design do modelo de dados | | Estratégia da Shield Platform Encryption | ✅ Criptografia probabilística usada para a maioria dos campos Restrito (suporta todas as operações de consulta)
✅ Criptografia determinística usada para campos que exigem cláusulas WHERE de correspondência exata ou exclusividade
✅ Determinística com diferenciação de maiúsculas e minúsculas usada quando a distinção de maiúsculas e minúsculas é importante para a lógica de negócios
✅ Comportamento de campo criptografado testado antes da implementação de produção
✅ Referências de campo de fórmula a campos criptografados tratados adequadamente (movido para o Apex se necessário) | | Gerenciamento de chaves | ✅ Procedimentos de rotação de chave documentados e automatizados
✅ Cenários de destruição-chave testados durante exercícios de recuperação de desastres
✅ Chaves gerenciadas pelo cliente (BYOK) avaliadas quanto à conformidade exigindo controle de chave explícito
✅ Principais procedimentos de revogação documentados
✅ Ciclo de vida da chave de criptografia gerenciado de acordo com os requisitos de conformidade | | Criptografia em trânsito | ✅ TLS 1.2 ou superior exigido para todas as integrações
✅ Autenticação mútua baseada em certificado para integrações que lidam com dados restritos
✅ Cabeçalhos HSTS configurados para sites do Experience Cloud para evitar downgrade de protocolo
✅ Expiração do certificado TLS monitorada e renovação automatizada configurada
✅ Criptografia fraca e protocolos desabilitados | | Código e configuração | ✅ Credenciais nunca integradas a códigos, arquivos de configuração ou controle de versão
✅ Credenciais nomeadas e credenciais externas usadas para gerenciar a autenticação centralmente
✅ Recursos de rotação de credenciais integrados à arquitetura
✅ Autenticação abstrata de credenciais nomeadas do código, habilitando atualizações sem alterações de código | | Pacotes do AppExchange | ✅ Requisitos de segurança do pacote avaliados antes da instalação
✅ Campos criptografados acessíveis a pacotes apenas quando justificados pela empresa
✅ Padrões de acesso a dados do pacote monitorados por meio do Monitoramento de evento
✅ Pacotes que exigem acesso a dados restritos sujeitos a revisão aprimorada | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Criptografia sem avaliação | ⚡️ Criptografia probabilística habilitada em todos os campos sem teste
⚡️ Relatórios críticos encontrados na produção falharam porque os campos criptografados não podem ser agregados
Criptografia habilitada em fontes de campo de fórmula sem entender o impacto
Campos usados em consultas SOQL LIKE criptografados sem alternar para criptografia determinística | | Credenciais integradas | Credenciais integradas em código, configurações personalizadas ou controle de versão
Chaves de API, senhas e certificados embutidos em código em classes do Apex
⚡️ Credenciais confirmadas em repositórios de controle de código-fonte
Credenciais armazenadas em metadados personalizados ou configurações personalizadas sem criptografia | | Protocolos fracos ou legados | ⚡️ TLS 1.0 ou 1.1 aceito (descontinuado e vulnerável)
Fluxo do OAuth de nome de usuário e senha permitido quando o portador JWT está disponível
Certificados autoassinados aceitos em integrações de produção
⚡️ Validação de certificado desabilitada "para que a integração funcione" | | Sem gerenciamento de chave | ⚡️ Shield Platform Encryption ativado sem procedimentos de rotação de chave
⚡️ Nenhum cenário de destruição de chave documentado
⚡️ Chaves padrão usadas sem avaliar a conformidade de chaves gerenciadas pelo cliente
⚡️ Procedimentos de revogação e rotação de chave nunca testados | | Sobre-criptografia | Dados de classificação pública ou interna criptografados, adicionando custo sem benefício
⚡️ Shield Platform Encryption ativado em todos os campos, criando complexidade desnecessária
⚡️ BYOK usado quando a conformidade não o exige (adiciona sobrecarga operacional)
Criptografia obrigatória quando a classificação de dados não justificar isso | ## Mascaramento de dados **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Estratégia de sandbox | ✅ Dados restritos nunca entram em ambientes de desenvolvimento ou teste
✅ Cópia de sandbox parcial exclui objetos e campos restritos
✅ Modelos de sandbox definem quais objetos e campos incluir por tipo de ambiente
✅ Data Mask configurado para sandboxes que exigem dados semelhantes a produção | | Regras do Data Mask | ✅ Regras do Data Mask ofuscam campos confidenciais enquanto preservam as características dos dados
✅ Os padrões mantêm a integridade referencial (a mesma entrada produz a mesma saída mascarada)
✅ Endereços de email mascarados, mas permanecem em formato válido para teste
✅ Números de telefone mascarados, mas permanecem em formato válido
✅ Datas alternadas consistentemente mantendo relacionamentos relativos
✅ Campos numéricos aleatórios dentro de intervalos realistas | | Dados sintéticos | ✅ Ambientes de desenvolvimento usam geração de dados sintéticos
✅ Dados sintéticos têm características realistas que permitem testes eficientes
✅ Nenhum dado de produção é necessário para desenvolvimento
✅ Geração de dados de teste automatizada em pipelines de desenvolvimento | | Ambientes não de produção | ✅ Dados de produção nunca copiados para organizações de desenvolvedor pessoais
✅ Captura de tela e demonstrações usam dados mascarados ou sintéticos
✅ Os ambientes de treinamento usam dados sintéticos ou dados de produção altamente mascarados
✅ Acesso do prestador de serviço e do fornecedor a dados não de produção restrito à classificação Somente uso comercial | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Dados de produção em sandboxes | ⚡️ Sandboxes completos atualizados com dados de produção desmascarados para desenvolvimento
Dados restritos copiados para sandboxes do desenvolvedor para conveniência
⚡️ Desenvolvedores concederam acesso amplo a sandboxes de dados de produção
Sandboxes atualizados com dados confidenciais "porque o teste é mais fácil com dados reais" | | Sem dados sintéticos | Dados de produção baseados apenas em todos os testes
⚡️ Sem geração de dados sintéticos para ambientes de desenvolvimento
⚡️ Presume-se que "Precisamos de dados reais" sem avaliar alternativas sintéticas
Dados de teste manuais criados quando a geração pode ser automatizada | ## Privacidade por design **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Minimizar dados | ✅ Apenas dados necessários para fins comerciais declarados coletados
✅ Cada adição de campo contestada com "Qual decisão arquitetônica exige esses dados?"
✅ Dados que não atendem mais ao propósito da coleção removidos
✅ Campos opcionais claramente marcados e não obrigatórios sem justificativa comercial
✅ Retenção de dados históricos alinhada à base legal, não "manter tudo para sempre" | | Limitação de finalidade | ✅ Conjuntos de permissões restringem o acesso a dados com base no propósito da função de trabalho
✅ Os usuários de marketing não podem acessar detalhes do caso de suporte sem justificativa documentada
✅ Os usuários de vendas não podem acessar históricos de atendimento ao cliente, a menos que o trabalho exija isso
✅ O acesso a dados multifuncionais requer aprovação e monitoramento explícitos
✅ Propósito do acesso a dados documentado nas descrições do conjunto de permissões | | Gerenciamento de consentimento | ✅ Consentimento capturado no nível individual para marketing, análise, processamento opcional
✅ O consentimento é granular (específico da finalidade), não binário
✅ Fluxos de trabalho de retirada de consentimento se propagam entre sistemas integrados
✅ Decisões de consentimento rastreadas com carimbo de data e hora, versão e mecanismo
✅ Interface do usuário de consentimento explica claramente ao que o usuário está consentindo | | Direitos de sujeito de dados | ✅ Fluxos de trabalho de solicitação de acesso fornecem cópias de dados dentro do prazo definido pela regulamentação reguladora para sua implantação
✅ Fluxos de trabalho de correção corrigem imprecisões com a trilha de auditoria
✅ Fluxos de trabalho de exclusão excluem dados quando permitido legalmente (considerando obrigações de retenção)
✅ Fluxos de trabalho de portabilidade exportam dados em formato legível por máquina
✅ Fluxos de trabalho de direitos de sujeito de dados testados regularmente para validar linhas do tempo
✅ Automação de fluxo de trabalho garante que as linhas do tempo regulatórias sejam atendidas de modo consistente | | Controles de privacidade | ✅ Controles de privacidade impostos tecnicamente, não apenas por meio da política
✅ Regras de compartilhamento implementam a limitação de finalidade
✅ A segurança em nível de campo protege atributos confidenciais
✅ Trilhas de auditoria capturam eventos relevantes para privacidade
✅ Controles de privacidade validados em pipelines CI/CD | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Coletar tudo | ⚡️ Abordagem "Coletar todos os dados possíveis, talvez precisemos dele algum dia"
Campos adicionados sem finalidade de negócio documentada
Dados mantidos indefinidamente sem justificativa de retenção
Dados opcionais coletados tornando campos obrigatórios | | Consentimento entre blocos | ⚡️ Consentimento único "concordo com os termos" para todos os fins
⚡️ Consentimento de marketing combinado à entrega de serviço em uma única caixa de seleção
⚡️ Consentimento feito com tudo ou nada quando as finalidades são separáveis
⚡️ Consentimento enterrado em termos e condições de 20 páginas | | Apólice sem imposição | ⚡️ Política de privacidade descreve práticas ideais que não são aplicadas tecnicamente
⚡️ Treinamento do usuário baseado em para evitar acesso a dados impróprio
Princípios de privacidade documentados sem implementar controles técnicos
Presume-se a conformidade da política sem monitoramento e validação | | Solicitações manuais de sujeito de dados | ⚡️ Solicitações de GDPR/CCPA processadas por meio de pedidos de TI manuais que levam meses
⚡️ Nenhum procedimento documentado para acesso, correção, exclusão e portabilidade
⚡️ A janela de solicitação e conclusão que os regulamentos reguladores definem para sua implementação estão ausentes
⚡️ Fluxos de trabalho de solicitação encontrados durante auditorias não existem | | Compartilhamento de dados excessivo | ⚡️ Acesso a dados amplo concedido entre departamentos sem justificativa de finalidade
⚡️ O Marketing permitiu acesso aos detalhes do caso de suporte
⚡️ Vendas permitiram acesso a históricos de atendimento ao cliente sem necessidade documentada
⚡️ Leitura/Gravação pública OWD usada para objetos que contêm dados pessoais | ## Residência de dados **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Implantação regional do Hyperforce | ✅ Organização provisionada na região do Hyperforce que atende aos requisitos de residência de dados
✅ O armazenamento e o processamento de dados ocorrem dentro dos limites geográficos necessários
✅ Requisitos regionais documentados e validados antes do provisionamento
✅ Requisitos de várias regiões tratados por meio da arquitetura de várias organizações, quando necessário | | Mapeamento de fluxo de dados | ✅ O fluxo de dados mapeia o documento em que os dados são originados, transitados e residem
✅ Transferências de dados no exterior identificadas e avaliadas em relação às normas
✅ Cláusulas contratuais padrão ou regras corporativas vinculantes para transferências internacionais
✅ Caminhos de trânsito de dados avaliados quanto à conformidade de residência, não apenas local de armazenamento | | Escopo de residência de dados | ✅ Local de armazenamento de dados (qual região do Hyperforce)
✅ Local de processamento de dados (compute regiões)
✅ Local de armazenamento de backup
✅ Local de armazenamento da trilha de registro e auditoria
✅ Caminhos de trânsito de integração avaliados para movimentação de dados entre países | | Arquitetura de várias organizações | ✅ Arquitetura de várias organizações usada quando os requisitos regulatórios não podem ser atendidos em uma só organização
✅ Cada organização provisionada na região apropriada para seus dados
✅ Os padrões de integração respeitam as restrições de residência de dados
✅ Compromissos de complexidade operacional documentados em ADRs | | Validação de conformidade | ✅ Requisitos de residência de dados documentados por jurisdição
✅ Seleção de região do Hyperforce validada em relação aos requisitos antes do provisionamento
✅ Auditorias periódicas confirmam que os dados permanecem dentro dos limites obrigatórios
✅ Alterações nas normas de residência acionam a revisão da arquitetura | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Supervisão de residência | Violações de residência de dados descobertas durante auditorias de conformidade
⚡️ Organizações provisionadas sem avaliar os requisitos regionais
⚡️ Presume-se que "nuvem é nuvem" sem considerar as normas de localização de dados
⚡️ Jurisdições adicionadas sem revisar obrigações de residência | | Trânsito ignorando a residência | ⚡️ Apenas o local de armazenamento considerado enquanto os caminhos de trânsito são ignorados
⚡️ Dados roteados por regiões fora dos limites de conformidade
⚡️ middleware de integração usado em regiões sem conformidade
⚡️ Backups armazenados em regiões diferentes dos dados primários | | Multiorganização desnecessária | ⚡️ Arquitetura de várias organizações usada quando uma única organização com regiões do Hyperforce é suficiente
⚡️ Complexidade operacional, custos de licenciamento e sobrecarga de integração multiplicados sem necessidade regulatória
⚡️ Multi-organização implementada "apenas para ser segura" sem um requisito de conformidade específico
⚡️ Multiorganização usada por padrão quando a classificação de dados e os controles de acesso são suficientes |