Trust

Na Salesforce, o Trust é o nosso valor número um. Ela é a base de todas as decisões de arquitetura na plataforma. Para os arquitetos, o Trust é alcançado através de uma parceria única: O Salesforce fornece uma plataforma segura e em conformidade (infraestrutura, metadados e ferramentas para torná-la sua), enquanto você projeta soluções seguras que dependem dessa base.

Esta parceria funciona por meio do Modelo de Responsabilidade Compartilhada, que é um quadro que divide claramente as responsabilidades de segurança:

• A Salesforce é responsável pela segurança da plataforma, incluindo certificações de infraestrutura, patch e conformidade.
• Você é responsável pela segurança na plataforma, incluindo configuração, controles de acesso, código personalizado e governança de dados.

Essa divisão é essencial porque define a responsabilidade arquitetônica. O Salesforce opera uma arquitetura de vários locatários em que milhares de organizações compartilham infraestrutura. A plataforma fornece proteções de segurança fortes no nível da infraestrutura. Suas decisões de arquitetura determinam se suas soluções específicas ganham a confiança das partes interessadas.

O Modelo de responsabilidade compartilhada o coloca no comando de projetar soluções seguras enquanto segurança física, proteção de rede, patch de plataforma e criptografia de infraestrutura são gerenciados para você. Isso permite que você se concentre na criação de soluções seguras baseadas nessa base (por exemplo, gerenciamento de identidade e acesso, proteção de dados, segurança de integração, práticas de desenvolvimento seguras, conformidade e adesão regulatória e recursos de resposta a incidentes).

Negligenciar Trust durante o projeto compõe dívida técnica. Uma estratégia de criptografia ausente se torna um retroajuste caro quando as normas mudam. Uma integração não gerenciada se torna uma vulnerabilidade quando as credenciais são comprometidas. Criar Trust desde o início é consistentemente menos caro do que instalá-lo posteriormente.

Trust abrange quatro dimensões arquitetônicas que trabalham juntas de forma coesa:

• Controles de segurança protegem sistemas e dados
• O gerenciamento de identidade controla o acesso
• As práticas de privacidade respeitam a agência do usuário
• As estruturas de conformidade cumprem obrigações regulatórias

Os arquitetos que projetam para todas as quatro dimensões criam soluções que ganham e mantêm Trust por meio de transparência, controle e resiliência.

Na Era Agentic, o Trust se estende ao contexto confiável no qual os agentes operam. Contexto confiável significa que os agentes acessam dados verificados e controlados com limites de permissão e identidade claros, o que permite que os sistemas de IA justifiquem e atuem em nome dos usuários enquanto mantêm a segurança, a capacidade de auditoria e a conformidade. Projetar contexto confiável é fundamental para a arquitetura do Enterprise do agente.

Esse pilar estabelece a linha de base de segurança da plataforma na qual cada solução do Salesforce depende. O pilar Agent Trust baseia-se nessa linha de base para lidar com riscos únicos para agentes autônomos, incluindo injeção imediata, governança de ações e os dados que os agentes podem acessar durante os tempos de raciocínio. É importante projetar primeiro a linha de base e, em seguida, estratificar controles específicos do agente usando as diretrizes do Agenttic Trust.

Esse pilar se conecta profundamente a outras preocupações de estrutura.

• A confiabilidade depende da infraestrutura que resista a ataques e se recupere de violações.
• A excelência operacional exige pipelines de implantação seguros e recursos de resposta a incidentes.
• A justiça exige o tratamento transparente e ético dos dados e decisões algoritmicas.

Juntos, esses pilares formam uma abordagem unificada e focada em soluções que as organizações podem Trust em suas operações mais sensíveis.

No Modelo de responsabilidade compartilhada, a Salesforce e os arquitetos devem cumprir suas respectivas responsabilidades para manter o Trust. Vamos analisar mais detalhadamente o que cada lado deve proteger.

A Salesforce é responsável por proteger a plataforma e sua infraestrutura global, incluindo:

• Controles de acesso ao data center, vigilância e proteções ambientais
• Para o Hyperforce, o provedor de nuvem subjacente (por exemplo, AWS, Azure ou Google Cloud, dependendo da instância) lida com a segurança do data center físico por meio de responsabilidade delegada. A documentação de infraestrutura e subprocessadores do Salesforce identifica o provedor e os subprocessadores para cada serviço.

• Controles de segurança da camada de rede, incluindo proteção contra DDoS e detecção de ameaças
• Criptografia de tráfego em trânsito (TLS 1.2+) e em repouso (geralmente AES-256)

• Resposta de vulnerabilidade e implantação de patch de plataforma por meio do Salesforce (para obter mais informações sobre avisos de segurança, visite security.salesforce.com)
• Gerenciamento de segurança de infraestrutura e sistema operacional

• Certificações e atestados: O Salesforce mantém a autorização SOC 1/2/3, a ISO 27001/27017/27018, a autorização FedRAMP (no escopo do Government Cloud Plus e do MuleSoft Government Cloud, não a plataforma comercial de vários locatários) e a validação do nível 1 do DSS PCI.
• Apoio à regulamentação: Isso se aplica a serviços elegíveis para a HIPAA com acordos de associados de negócios (BAAs) ou programas de conformidade com o GDPR.
• Para obter mais informações, acesse Trust.salesforce.com e compliance.salesforce.com.

• Arquitetura de isolamento do locatário: Um kernel compartilhado conduzido por metadados particiona os dados e metadados de cada organização por ID da organização, de modo que uma organização não pode acessar os registros de outra organização, embora ambos estejam em execução em uma infraestrutura compartilhada. O kernel impõe a separação em cada consulta, não por meio de uma configuração que você deve manter.
• Criptografia em nível de infraestrutura em repouso e infraestrutura de backup: As licenças de plataforma de base incluem a Criptografia clássica (o AES-128 fornece somente campos de texto personalizados). Shield Platform Encryption requer uma licença separada (AES-256 permite trazer sua própria chave e fornece campos padrão e personalizados, arquivos e anexos).

Esses controles garantem que a plataforma permaneça segura, confiável e em conformidade.

Você é responsável por proteger seus dados, configurações e processos operacionais.

• Identidade e federação: Para Single Sign On (SSO) e autenticação multifator (MFA), você deve verificar a identidade do usuário.
• Restrição de acesso: Tecnicamente, intervalos de IP e horas de login restringem como e quando as identidades se conectam.
• Princípio de privilégio mínimo (PoLP): Use o PoLP para conceder acesso apenas a papéis, perfis e conjuntos de permissões necessários para realizar tarefas de trabalho individuais.
• Gerenciamento de ciclo de vida: Pratique o gerenciamento de ciclo de vida do usuário e acesse diretrizes de recertificação.

• Usar classificação de dados, mascaramento e segurança em nível de objeto/campo/registro
• Impor permissões CRUD e regras de compartilhamento
• Propriedade, teste e implantação de uma estratégia comprovada para restaurar os dados da sua organização, garantindo que a perda de dados ou a recuperação de corrupção permaneçam no seu controle.

• Use autenticação de API (por exemplo, OAuth 2.0 ou JWT) e credenciais nomeadas.
• Habilite usuários de integração dedicados com conjuntos de permissões PoLP para que o acesso de cada integração seja delimitado e audível separadamente de usuários humanos.
• Proteger pontos de extremidade e validação do sistema externo.

• Use o Monitoramento de evento, as trilhas de auditoria e a integração de Informações de segurança e Gerenciamento de evento (SIEM).
• Siga os procedimentos de resposta a incidentes e as análises de segurança.

• Use código personalizado seguro (por exemplo, Apex ou Lightning) e validação de entrada.
• Execute o Apex no modo de usuário para que as permissões de objeto, campo e compartilhamento sejam impostas em código.
• Siga as práticas de prevenção por injeção e desenvolvimento seguro.

• Mantenha a postura de conformidade das soluções.
• Siga as políticas de privacidade/gerenciamento de consentimento e retenção de dados.

Algumas responsabilidades exigem colaboração:

• Resposta a incidentes de segurança: Ambas as partes participam de atividades de detecção e resposta.
• Gerenciamento de vulnerabilidade: O Salesforce corrige a plataforma, os arquitetos corrigem o código personalizado.
• Monitoramento de segurança: Combine sinais de segurança gerados pela plataforma com a análise do arquiteto.
• Certificações de conformidade: O Salesforce certifica a plataforma (por exemplo, SOC, ISO e FedRAMP para Government Cloud); os arquitetos são proprietários do que é criado nele (objetos personalizados, código, integrações e configuração) dentro da condição certificada para fornecer evidência de conformidade para auditorias.
• Federação de Identidade: O Salesforce confia nas declarações feitas pelo provedor de identidade do arquiteto; os arquitetos mantêm a proteção do provedor e o relacionamento Trust entre o provedor e o Salesforce.
• Gerenciamento de chaves: Usando a criptografia de trazer sua própria chave, o Salesforce opera o serviço de criptografia enquanto os arquitetos geram, alternam e revogam o material de chave que protege os dados.

Cada princípio de design, seção de tópico e item da lista de verificação neste documento representa sua responsabilidade como arquiteto. O Modelo de responsabilidade compartilhada define o que você deve projetar e configurar para obter Trust na plataforma Salesforce.

O limite se estende a obrigações regulatórias. O Salesforce mantém as certificações e atestados da plataforma e protege a infraestrutura contra violações. Os arquitetos são responsáveis pelas obrigações associadas aos seus dados e jurisdição (por exemplo: quais leis se aplicam, como os dados são classificados, quais regras de retenção e consentimento os regem e como você detecta e reporta violações dos dados sob seu controle). Em relação às normas regulatórias para suas implementações, os arquitetos devem determinar os números específicos por trás dessas obrigações (por exemplo, períodos de retenção e prazos de notificação) em relação às normas regulatórias para sua implementação, pois elas podem variar de acordo com a jurisdição e mudar ao longo do tempo.

Use esses princípios para orientar suas decisões arquitetônicas quanto à segurança na plataforma.

• Aplicar zero trust em todas as camadas. Nunca presuma Trust com base na localização da rede, na familiaridade do usuário ou na origem do sistema. Verifique cada solicitação de acesso explicitamente com autenticação, autorização e criptografia nas camadas de dados, aplicativo, integração e infraestrutura. A arquitetura de vários locatários significa que você compartilha a infraestrutura com milhares de organizações, portanto, a rede em que sua solução é executada não é um perímetro que você pode tratar como confiável. Verifique cada solicitação com base em seus próprios méritos (identidade, autorização e contexto) em vez de confiar nele quanto ao local de origem.
• Concedem privilégio mínimo por padrão. Conceda o nível mínimo de acesso necessário para cada usuário, integração e processo automatizado realizar sua finalidade. Comece com as configurações mais restritivas (padrões organizacionais privados (OWDs) e permissões mínimas) e expanda deliberadamente com base em requisitos de negócios documentados. Use o modelo de acesso de quatro camadas (organização → objeto → campo → registro) para que cada camada restrinja ainda mais as camadas acima.
• Implementar defesa em profundidade. Camada vários controles de segurança para que a falha de um controle não comprometa todo o sistema. Combine controles preventivos (por exemplo, políticas de imposição de CRUD/FLS e Segurança da transação que bloqueiam operações), controles detetivos (por exemplo, Monitoramento de evento) e controles responsivos (por exemplo, autenticação e notificação de etapa de Segurança da transação). Projete cada camada como se as camadas adjacentes pudessem falhar. Lembre-se de que a segurança em nível de campo protege dados mesmo quando as regras de compartilhamento são muito permissivas.
• Integrar a segurança por design. Integre a modelagem de ameaças, os requisitos de segurança e a validação de controle em cada fase da arquitetura do conceito inicial à evolução contínua. Realize a modelagem de ameaça Spoofing, Impedimento, Repudiation, Divulgação de informações, Negativo de serviço e Elevação de privilégio (STRIDE) antes do início da compilação. A segurança define a seleção de tecnologia e as decisões de design.
• Introdução à segurança na automação. Crie controles de segurança em pipelines automatizados, modelos de configuração e padrões de plataforma. O Salesforce Code Analyzer em CI/CD captura vulnerabilidades antes da implementação. Configuração como código aplica linhas de base de segurança. A segurança integrada garante consistência e permite que a segurança seja dimensionada com a complexidade da solução.
• Design para privacidade. Incorpore princípios de privacidade da fase inicial da arquitetura. Projeto para minimização de dados (coletar apenas dados necessários), limitação de finalidade (restringir o acesso por função de trabalho), gerenciamento de consentimento (impor consentimento granular específico da finalidade) e direitos de sujeito de dados (habilitar o acesso, a correção, a exclusão e a portabilidade dos fluxos de trabalho para serem concluídos dentro dos cronogramas regulatórios).
• Design para rastreabilidade. Torne cada ação consequente atribuível e reconstruível após o fato antes de depender de detectar anomalias nele. Certifique-se de que as alterações em dados, permissões e ajustes sejam capturadas em trilhas de auditoria, histórico de campo e registros de evento e preserve esses registros em armazenamento resistente a adulterações. A rastreabilidade é a pré-condição para detecção, análise forense e responsabilidade. Lembre-se de que não é possível investigar o que nunca foi registrado.
• Design para resposta a incidentes. Projetado para capacidade de detecção por meio do Monitoramento de evento e para intervenção em tempo real por meio de políticas de Segurança da transação. Habilite uma resposta rápida por meio de procedimentos documentados e limites de isolamento. Dê suporte à recuperação por meio de recursos de backup e preservação forense. Teste as respostas por meio de exercícios de mesa e simulações de falha.

Os arquitetos são responsáveis por proteger soluções na plataforma que a Salesforce fornece.

As cargas de trabalho que interagem com o Salesforce são executadas cada vez mais fora da plataforma principal: serviços de integração, aplicativos personalizados e clientes autônomos costumam chamar APIs do Salesforce, geralmente em nome de um usuário. Para acelerar esse padrão, o Salesforce expõe os recursos da plataforma como APIs, ferramentas e comandos (por exemplo, o Salesforce Headless 360). Independentemente de quem opera esses aplicativos, o arquiteto é o proprietário do limite de Trust em que eles se encontram com o Salesforce para determinar como eles autenticam, que identidade e permissões eles carregam, quais segredos eles mantêm e quais dados atravessam o limite.

Os princípios a seguir se aplicam a qualquer plataforma de integração contêinerizada (por exemplo, MuleSoft CloudHub).

Quando um cliente externo se autentica como um usuário nomeado, o modelo de segurança da plataforma do Salesforce é aplicado automaticamente: permissões de objeto, segurança em nível de campo e regras de compartilhamento são impostas exatamente como estão no navegador. A autenticação por usuário define o escopo de cada chamada às permissões desse indivíduo e preserva a trilha de auditoria, o que significa que revogar o token de um usuário remove imediatamente a capacidade do cliente de agir em seu nome. Prefira isso em vez de uma conta de serviço compartilhada sempre que o trabalho for feito para um usuário específico.

Projete o limite defensivamente, porque um cliente que tem tokens para muitos usuários concentra Trust e se torna um proxy de alto valor para um atacante: um único token OAuth roubado pode alcançar dados em todos os usuários que o cliente atende. Isso não é hipotético. O incidente de Salesloft Drift de 2025 viu os invasores roubarem tokens OAuth e usá-los para acessar dados do Salesforce em centenas de organizações.

• Propagar identidade do usuário, não agrupe. Use a autenticação por usuário ou o OAuth 2.0 Token Exchange para transportar a identidade de um usuário entre saltos de serviço (consulte Identidade e autenticação do agente), de modo que os compromissos sejam delimitados para o contexto de um usuário, em vez de todos.
• Tratar credenciais do cliente OAuth e tokens de atualização como o destino principal. Armazene-os em uma loja de segredos gerenciados, faça a rotação com frequência e mantenha os designs para revogação imediata. Monitore o uso da API para os padrões anômalos que sinalizam um atacante proxy.
• Minimizar o escopo em ambos os lados. Restrinja os escopos de OAuth do aplicativo cliente externo (ECA) e as permissões do Salesforce do usuário de integração ao mínimo necessário para que um cliente comprometido não possa dinamizar para dados não relacionados.
• Gerencie o limite por meio de aplicativos cliente externos. Os ECAs definem como um aplicativo externo autentica, quais fluxos são permitidos e quais escopos se aplicam: projete novas integrações em relação a eles (consulte Arquitetura de autenticação).

Tenha cuidado quando um cliente é executado como Usuário agente ou Usuário de integração: essas identidades podem operar em um contexto elevado, muitas vezes contra sistemas externos que não respeitam os controles de acesso do Salesforce, portanto, usar a disciplina de permissão e monitoramento descritas acima é o que mantém esse limite de poder.

Quando as integrações são executadas em uma plataforma contêinerizada, o isolamento no nível do contêiner é considerado em si um controle de segurança: cada aplicativo é executado em um contêiner dedicado sem tempo de execução ou memória compartilhados entre os aplicativos.

Esse isolamento fornece:

• Imposição de fronteira do locatário: Aplicativos comprometidos não podem acessar dados ou recursos de aplicativos vizinhos que compartilham o mesmo ambiente. Cada contêiner tem um sistema de arquivos isolado e um espaço de processo. Imponha o isolamento de rede por meio de ajustes de firewall e TLS e restrinja explicitamente o tráfego de saída em vez de depender de padrões permissivos.
• Defesa em profundidade: O isolamento do contêiner adiciona uma camada de segurança além dos controles no nível do aplicativo. Mesmo que o código do aplicativo tenha vulnerabilidades, os limites do contêiner limitam o raio de explosão.
• Segmentação de conformidade: Cargas de trabalho reguladas (por exemplo, PCI e HIPAA) podem ser isoladas em contêineres dedicados, impedindo a combinação com cargas de trabalho fora de conformidade.

Os arquitetos que estão projetando ambientes de vários aplicativos devem contar com o isolamento de contêiner para impor a separação de tarefas e domínios de segurança. As integrações de serviços financeiros que processam dados do titular do cartão devem ser executadas em contêineres separados das integrações de marketing, mesmo dentro do mesmo ambiente.

O tráfego entre contêineres deve ser criptografado e o TLS mútuo (mTLS) deve ser aplicado quando uma estrutura regulatória exigir autenticação em ambos os lados:

Como funciona:

• Configure contextos de TLS para habilitar o TLS mútuo (mTLS) opcional para conexões de entrada quando necessário.
• Use SSL em nível de plataforma com autenticação de certificado de cliente para proteger a comunicação entre serviços de plataforma e réplicas.
• Configure contextos de TLS para habilitar o mTLS quando exigido por estruturas regulatórias.
• Gerencie certificados por meio da loja de certificados da plataforma para que o ciclo de vida e a revogação permaneçam centralizados.
• Imponha limites de isolamento de rede que impeçam o tráfego não autorizado entre contêineres.

Criptografar o tráfego na camada da plataforma fornece defesa em profundidade para dados em trânsito. Mesmo que o HTTPS da camada de aplicativo esteja configurado incorretamente, o tráfego do contêiner permanecerá criptografado.

Os contêineres que se conectam a sistemas locais por meio de VPN devem arquitetar para proteção de dados em trânsito:

• Criptografia de túnel: Encaminhe todo o tráfego entre contêineres e sistemas locais por meio de túneis VPN criptografados. Isso se aplica independentemente do TLS de camada de aplicativo. A defesa em profundidade garante que haja criptografia dupla para dados confidenciais.
• Imposição da segmentação de rede: As políticas de túnel de VPN restringem quais redes locais os contêineres podem alcançar. Contêineres comprometidos não podem dinamizar para sistemas internos não autorizados além das redes permitidas por VPN.
• Prova de conformidade: A criptografia de VPN é um dos mecanismos aceitos para proteger dados em trânsito de e para ambientes de nuvem. Auditores que revisam controles HIPAA, PCI-DSS ou SOX esperam criptografia documentada em trânsito para integrações híbridas.

Os arquitetos devem projetar políticas de VPN que impõem o acesso de rede de privilégio mínimo. Os contêineres de integração de marketing não devem ser roteados para sistemas financeiros internos, mesmo que ambos sejam acessíveis por VPN.

Domínios intuitivos (por exemplo, URLs personalizados para APIs de integração) exigem que os arquitetos gerenciem certificados TLS como âncoras Trust:

Domínios intuitivos (por exemplo, URLs personalizados para APIs de integração) exigem que os arquitetos gerenciem certificados TLS como âncoras Trust.

• Automação do ciclo de vida do certificado: Implemente a renovação e a implantação automatizadas de certificado. Certificados expirados quebram o Trust de integração; clientes rejeitam conexões com erros de validação de certificado.
• Planejamento de revogação de certificado: Projete procedimentos de rotação de certificado para incidentes de segurança. Chaves privadas comprometidas exigem reemissão e implantação rápida de certificados em todas as regiões.
• Configuração do pacote de criptografia: Configurações TLS mais antigas (TLS 1.0/1.1 e criptografia fraca) falham em auditorias de conformidade. Imponha o TLS 1.2+ (requisito mínimo) e alinhe as configurações de certificado e cliente às políticas de segurança organizacionais.
• Registro de transparência do certificado: Certificados TLS modernos são enviados para registros públicos de Transparência de certificado (CT) por Autoridades de certificação (CA). Cada registro de CT retorna um carimbo de data e hora do certificado assinado (SCT), uma prova criptográfica de registro, que a CA integra ao certificado por meio de uma extensão X.509v3. Os arquitetos devem monitorar registros de CT para emissão de certificado não autorizada em relação aos domínios, usando serviços como crt.sh ou alerta automatizado.

A gestão incorreta do certificado afeta diretamente a postura Trust:

• Certificados expirados: Causar falhas de autenticação que aparecem como interrupções. O monitoramento deve incluir o envio de alertas dentro de 30 dias antes da expiração para permitir que os fluxos de trabalho de renovação comecem.
• Certificados autoassinados: Divida cadeias Trust para clientes externos. Integrações de produção exigem certificados assinados por autoridades de certificação (CA) confiáveis.
• Despansão do certificado Wildcard: Refere-se a certificados curingas muito largos (por exemplo, *.company.com) que criam um raio de explosão grande se forem comprometidos. Certificados de escopo estreito têm preferência por domínio de integração.

As regiões de implantação do contêiner devem estar alinhadas aos requisitos de conformidade e residência de dados.

• Residência de dados do RGPD: O GDPR exige a proteção adequada para dados pessoais que saem da União Europeia (UE), mas não a implantação da UE como tal. A implantação de integrações em uma região da UE mantém o processamento de dados e computação de contêiner dentro dos limites regulatórios, o que é a maneira mais direta de cumprir esse requisito. Transferências que ocorrem fora da UE permanecem permitidas sob uma decisão de adequação, cláusulas contratuais padrão (SCCs) ou regras corporativas vinculantes (BCRs).
• Legislações de localização de dados: Os países com requisitos de localização de dados incluem: Rússia (Lei Federal 152-FZ e armazenamento obrigatório) e China (PIPL/CSL para CIIOs), que podem exigir a implantação de contêineres no país. A Lei DPDP de 2023 da Índia usa uma abordagem de lista negra que não impõe um mandato geral de armazenamento no país. As transferências de dados são permitidas para qualquer país, a menos que sejam especificamente restritas por uma notificação do governo. Os arquitetos devem entender as normas específicas da jurisdição.
• Mecanismos de transferência de dados transfronteiras: Quando uma implantação multarregional é necessária, mas os dados precisam cruzar fronteiras, os arquitetos devem implementar SCCs, BCRs ou outros mecanismos de transferência legal.
• Alinhamento da certificação de conformidade: As regiões de implantação do contêiner devem corresponder às certificações de conformidade do Salesforce. As cargas de trabalho autorizadas pelo FedRAMP exigem implantação regional dos EUA. Para integrações certificadas por HITRUST, você deve verificar se a região de implantação está dentro de um escopo de certificação HITRUST ativo.

As decisões de implantação regional são responsabilidades do arquiteto que afetam diretamente a conformidade regulatória. As equipes financeiras podem exigir a implantação apenas dos EUA para integrações controladas por SOX. As equipes de saúde podem exigir regiões certificadas pelo HITRUST para processar informações de saúde pessoais (PHI).

Os contêineres exigem acesso a credenciais, chaves de API e chaves de criptografia. Os arquitetos devem projetar processos de gerenciamento de segredos que impeçam a exposição:

• Sem segredos embutidos em código: Nunca integre credenciais em arquivos de código de aplicativo ou configuração implantados em contêineres. Use lojas de segredos gerenciadas pela plataforma.
• Injeção secreta gerenciada pela plataforma: Resolva segredos no tempo de execução do armazenamento gerenciado da plataforma (em vez de persisti-los no sistema de arquivos) e marque os valores de configuração que contêm credenciais como protegidos para que não sejam expostos em registros ou no console.
• Rotação de segredos: Projete integrações para lidar com segredos alternados com facilidade. Os padrões de atualização de token OAuth, fluxos de trabalho de rotação de chave de API e alterações de senha do banco de dados não devem exigir a reimplantação do contêiner.
• Acesso de segredos de privilégio mínimo: Conceda aos contêineres acesso apenas aos segredos necessários para sua função. As integrações de marketing não devem acessar as credenciais do sistema financeiro mesmo quando compartilham o mesmo ambiente.

Segredos expostos são incidentes de segurança de integração comuns. Os arquitetos devem projetar segredos que lidam com processos que podem sobreviver a revisões de código, registros, mensagens de erro e painéis de monitoramento sem vazamento de credenciais.

Os aplicativos no limite do Salesforce geram eventos de auditoria que cumprem os requisitos de registro de conformidade:

• Registro de solicitação/resposta: Registra solicitações da API, respostas e decisões de roteamento. As equipes de conformidade usam esses registros para auditorias de acesso para determinar quem acessou quais dados em que momento.
• Erro e registro de exceção: Captura eventos de segurança (por exemplo, falhas de autenticação, negações de autorização e certificados inválidos) nos registros do contêiner. A integração do SIEM habilita o monitoramento de segurança em tempo real.
• Políticas de retenção de log: Os arquitetos devem configurar períodos de retenção que atendam aos requisitos regulatórios. Esses mínimos são definidos por regulamentação, diferem por estrutura e mudam ao longo do tempo, portanto, devem ser derivados de uma fonte de conformidade bem mantida que verifica cada número em relação à regulamentação aplicável, em vez de valores de codificação permanente.
• Criptografia de registro e controles de acesso: Os registros de auditoria podem conter metadados confidenciais. Os registros devem ser criptografados em repouso e controlados pelo acesso apenas para pessoal de segurança/conformidade autorizado. O registro insuficiente impede a investigação de incidentes e falha nas auditorias de conformidade. Os arquitetos devem equilibrar a verbosidade do registro (por exemplo, impacto no desempenho e custos de armazenamento) com as necessidades de conformidade e investigação de segurança.

A modelagem de ameaças deve fazer parte do projeto de suas soluções, em vez de uma etapa separada que ocorre antes ou depois dela. Assim que você tiver um design candidato para pensar, precisará modelar suas possíveis ameaças e revisitar o modelo conforme o design evolui, de modo que a segurança moldará a arquitetura em vez de ser adaptada posteriormente. Enquanto o Salesforce gerencia a segurança da infraestrutura (por exemplo, proteção de rede, endurecimento do SO e gerenciamento de vulnerabilidade), você deve identificar riscos da camada de aplicativos em sua configuração, integrações e código personalizado. Aplique a estrutura STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) aos vetores de ameaça específicos do Salesforce listados abaixo. Identifique os limites de Trust em que os dados cruzam sistemas, redes ou níveis de privilégio.

Aplique a estrutura STRIDE a estas considerações de modelagem de ameaças específicas do Salesforce:

• Os fluxos de dados multi-organização criam limites de Trust adicionais que exigem autenticação e autorização explícitas em cada passagem.
• As integrações externas usam APIs e middleware, potencialmente introduzindo vetores de ataque que ignoram os controles de segurança da plataforma.
• Os componentes personalizados do Apex e do Lightning exigem análise de codificação segura para implementação de injeção, XSS e controle de acesso.
• Os sites do Experience Cloud expandem a superfície de ataque para usuários não autenticados ou levemente autenticados.
• O código de terceiros e ISV (por exemplo, pacotes gerenciados, listagens do AgentExchange, aplicativos conectados, conectores de terceiros, bibliotecas JavaScript do lado do cliente e os serviços de IA externos que seus agentes chamam) é um vetor da cadeia de suprimentos que atravessa o limite do Trust, no momento da instalação ou no tempo de execução.

O código de terceiros e ISV faz parte do seu limite de Trust.

Os pacotes gerenciados ou as listagens do AgentExchange são executados dentro da sua organização com as permissões que você concede a eles, assim, sua postura de segurança se torna sua postura de segurança no momento em que você os instala. A Revisão de segurança do Salesforce verifica cada pacote listado antes que ele chegue ao AppExchange ou ao AgentExchange; você é o proprietário de tudo após esse gate:

• Avaliar o pacote em relação à sua própria classificação de dados e condição de risco
• Conceder a ele a quantidade mínima de privilégios de que sua funcionalidade documentada exige
• Manter a atualização com as versões do editor
• E monitorar sua atividade por meio dos mesmos controles de Monitoramento de evento e auditoria que você aplica ao seu próprio código.

Aplique controles de segurança a cada camada da pilha de soluções. Lembre-se de que comprometer uma camada não deve expor todo o sistema.

Projete cada camada como se as camadas acima e abaixo pudessem falhar. Lembre-se de que vários controles independentes criam resiliência.

O Zero Trust elimina o Trust implícito com base na posição da rede ou no estado de autenticação anterior. Cada solicitação deve ser autenticada e autorizada de modo independente.

Aplicar a Trust zero a:

• Acesso do usuário por meio de verificação contínua com MFA, políticas de sessão e acesso condicional com base no contexto (por exemplo, IP, dispositivo, tempo e comportamento)
• Integração de conexões por meio da validação de token OAuth em cada chamada, TLS mútuo baseado em certificado e listagem de permissões de IP
• Comunicação entre sistemas através de autenticação explícita, que também se aplica a sistemas internos confiáveis
• Acesso a dados por meio da aplicação CRUD e FLS em todas as consultas e operações, independentemente do contexto de chamada

O Inventário de ativos de segurança é uma entrada de design de segurança: você só pode modelar ameaças, aplicar privilégio mínimo a e monitorar uma superfície de ataque que tenha sido enumerada inicialmente, portanto, rastrear seus ativos relevantes para a segurança pertence às decisões de design que dependem disso. Isso é diferente do gerenciamento de configuração operacional que a Excelência operacional cobre (por exemplo, configurações da organização de controle de versão e detecção de desvio de configuração para estabilidade operacional). Em outras palavras, a preocupação aqui é mais limitada: quais ativos apresentam riscos de segurança e por quê?

Mantenha um inventário atual de todos os ativos relevantes para a segurança, incluindo objetos personalizados que armazenam dados confidenciais, integrações do sistema externo, APIs voltadas para o público, contas privilegiadas, concessões de acesso de produção e pacotes instalados com permissões elevadas.

Seu inventário de ativos de segurança deve incluir:

• Objetos e campos personalizados contendo dados confidenciais ou restritos
• Pontos de extremidade de integração e mecanismos de autenticação
• Usuários com privilégios elevados (por exemplo, Modificar todos os dados, Visualizar todos os dados e Gerenciar usuários)
• Usuários de integração somente de API e seus escopos de permissão
• Aplicativos cliente externos (ECA) e seus escopos de OAuth, junto com qualquer aplicativo conectado legado que ainda esteja presente na organização
• Pacotes do AgentExchange instalados e suas concessões de permissão
• Sites do Experience Cloud e seus modelos de autenticação e compartilhamento externos
• Classes do Apex personalizadas com modos de compartilhamento elevados
• Preste atenção especial às classes legadas: código compilado na API versão 66.0 ou anterior, que omite uma declaração de compartilhamento como padrão "sem compartilhamento" (por exemplo, modo do sistema, ignorando o acesso ao registro do usuário em execução). Lembre-se de que, da versão 67.0 da API (Summer '26), uma declaração omitida usa como padrão "com compartilhamento" e operações de banco de dados são executadas no modo de usuário. No entanto, as classes existentes mantêm o comportamento antigo até serem recompiladas na v67.0 (ou posterior), de modo que as classes não declaradas adiantadas de versões anteriores permanecem silenciosamente elevadas.

É sua responsabilidade projetar e configurar controles de identidade que impõem o privilégio mínimo.

Vamos analisar mais detalhadamente como projetar e configurar corretamente os controles usando o PoLP.

O Salesforce aplica o controle de acesso por meio de quatro camadas distintas: organização, objeto, campo e registro. Você deve projetar soluções que aproveitem todas as quatro camadas deliberadamente. O controle de acesso principal é baseado em concessão, o que significa que o acesso é additivo e os usuários precisam concedê-lo em cada camada para alcançar um registro. Não há uma regra generalizada "negar substituições permite" na plataforma principal, portanto, não é possível desativar uma negação direcionada para desfazer o acesso a uma concessão ampla que já foi concedida.

camadas superiores permissivas não custam sua capacidade de restringir, mas aumentam o esforço: Ampliar padrões para toda a organização ou permissões de objeto cedo significa contar com a segurança em nível de campo e ajustes de compartilhamento para bloquear o acesso que nunca deveria ter sido concedido.

As regras de restrição e as permissões de silenciamento são duas exceções integradas que subtraem o acesso, mas cada uma tem um escopo limitado: regras de restrição para filtragem no nível do registro e silenciamento para permissões concedidas em um grupo de conjuntos de permissões, não uma camada de negação generalizada.

Defina OWDs como Privado para objetos que contêm dados confidenciais. Abrir OWDs para Somente leitura pública, e muito menos leitura/gravação pública, expõe registros amplamente e erode sua capacidade de restringir o acesso mais tarde sem uma rearquitetura potencialmente significativa. A dívida Trust mais comum em organizações maduras resulta de OWDs permissivos estabelecidos durante a implementação inicial.

A camada de registro segue um modelo de concessão e restrição, geralmente ilustrado como uma pirâmide de compartilhamento: Os OWDs definem a linha de base restritiva e a hierarquia de papéis, as regras de compartilhamento e o compartilhamento manual dão acesso aberto de cima para cima. Dois controles invertem esse fluxo para remover o acesso em vez de concedê-lo, e ambos valem a pena projetar deliberadamente.

• As regras de restrição filtram o que os usuários podem ver nos registros aos quais eles já têm acesso, de modo que os usuários com acesso a objeto amplo ainda veem apenas o subconjunto que uma regra permite.
• As permissões de silenciamento subtraem permissões específicas dentro de um grupo de conjuntos de permissões para que você possa montar o acesso de grupos reutilizáveis e então remover o que uma determinada população não deveria ter.
• Entre em contato com essas regras quando apenas camadas baseadas em concessão forçariam você a fornecer ou fragmentar o acesso em muitos conjuntos de permissões estreitos.

Imponha a MFA (autenticação multifator) para todos os usuários que fazem login em ambientes de produção por meio da interface do usuário, que o Salesforce determina como um requisito de plataforma. Esse requisito não se estende ao acesso somente de API: integrações que usam fluxos de portador JWT ou credenciais do cliente estão isentas, portanto, você precisa proteger essas integrações com restrições de gerenciamento de certificado e IP. Estenda os requisitos de MFA a operações privilegiadas.

Para SSO (logon único), os protocolos SAML 2.0 ou OpenID Connect são preferidos. Configure políticas de sessão para balancear segurança e usabilidade:

• Tempo limite da sessão: Configure tempos limite de sessão adequados aos níveis de privilégio do usuário ( tempos limite mais curtos para contas de alto privilégio reduzem os riscos de sessões sem assistência).
• Restrições de IP: Imponha restrições para perfis administrativos e usuários de integração.
• Horas de login: Restrinja as contas de serviço às janelas operacionais esperadas.
• Ativação do dispositivo: Conte com a ativação de dispositivo nativa do Salesforce (verificação de identidade para logins de dispositivos não reconhecidos) e adicione restrições de MFA e IP para contas de alto privilégio. A postura nativa do dispositivo Trust é imposta por meio de um provedor de identidade externo.
• Bloqueio de IP da sessão: Bloqueie sessões para o endereço IP do qual elas se originam para que um ID de sessão roubado não possa ser reproduzido de outro local de rede. Isso aperta a segurança, mas aumenta o atrito para usuários móveis e pode interromper integrações automatizadas. Quando o bloqueio não for viável, aplique Intervalos de IP de login estrito no nível de perfil com "Impor intervalos de IP de login em cada solicitação" como o controle compensatório.
• Sessões de alta garantia: Exija um nível de segurança de sessão de Alta garantia, por meio de Políticas de nível de segurança da sessão e Políticas de acesso, para operações confidenciais (como acessar relatórios ou gerenciar intervalos de IP), de modo que um login de rotina não possa alcançar ações de alto impacto por si só. No Lightning Experience, não há suporte para aumentar uma sessão padrão para Alta garantia reavaliando a MFA, portanto, esteja ciente de que os usuários da sessão padrão serão bloqueados da operação de garantia em vez de serem solicitados a elevar.
• Proteção de cookies de sessão: Exija o atributo HttpOnly para que os scripts não possam ler o cookie de ID da sessão e bloqueie as sessões para o domínio em que foram usadas inicialmente para evitar o sequestro de sessão.
• Acesso somente de API para usuários de integração: Restrinja a integração e as contas de serviço à autenticação somente de API com a permissão Usuário apenas de API para que eles não possam fazer login por meio da interface do usuário. Para novas compilações, atribua o perfil Acesso mínimo – Integrações apenas de API com a licença de usuário de Integração do Salesforce; o perfil de Integração de sistemas somente de API do Salesforce mais antigo está indisponível em organizações provisionadas da versão Spring '24 em diante, portanto, projete novas integrações com base no perfil atual, em vez do descontinuado.

Para autenticação de API, selecione fluxos OAuth 2.0 adequados ao padrão de integração:

• Fluxo do portador JWT: Use isso para integrações entre servidores que são executadas como um usuário de integração (com base em certificado, preferencial para ambientes confiáveis).
• Fluxo de servidor da Web (código de autorização, com PKCE): Use isso para aplicativos da Web que exigem autorização do usuário e para integrações entre servidores que precisam manter um contexto de usuário específico (armazenar tokens de atualização no lado do servidor para evitar avisos repetidos do navegador).
• Make Authorization-Code Flow Replay-Safe: Imponha a PKCE para que um código de autorização interceptado não possa ser resgatado por ninguém, exceto pelo cliente que o solicitou, e faça a rotação dos tokens de atualização, emitindo um novo em cada uso e invalidando o anterior, de modo que um token de atualização roubado tenha uma janela de validade estreita. Reutilização de um token descontinuado compromete os sinais.
• Fluxo de credenciais e código de autorização de identidade autônoma (com PKCE): Use isso para clientes autênticos autônomos sem navegador que devem ser executados no contexto de um usuário específico. O fluxo de servidor da Web baseado em redirecionamento presume um navegador que esses clientes não têm.
• Fluxo do dispositivo (para dispositivos sem cabeçalho): Observe que, a partir de 28 de agosto de 2025, o Salesforce bloqueou permanentemente o Fluxo de dispositivo do OAuth 2.0 para o aplicativo conectado padrão do Salesforce CLI. Use o Fluxo de servidor da Web (web de login da organização sf) ou o Fluxo do portador JWT ( jwt de login da organização sf) em vez disso para ferramentas de CLI e CI/CD.

Não use o Fluxo de nome de usuário e senha. O Salesforce o bloqueou por padrão para organizações criadas na versão Summer '23 ou posterior e publicou planos de descontinuação em vigor para esse fluxo. Integrações existentes que ainda dependem do Fluxo de nome de usuário e senha devem migrar para o Fluxo do portador JWT ou o Fluxo de credenciais do cliente agora, em vez de tratar a migração como um débito técnico adiado.

Esses fluxos são configurados no registro do aplicativo que representa sua integração. A partir da versão Spring '26, o Salesforce está movendo esse registro de Aplicativos conectados para Aplicativos cliente externos (ECA): criar novos aplicativos conectados é desabilitado por padrão, e a ECA é a construção com base na qual criar novas integrações. Os aplicativos conectados existentes permanecem instalados; no entanto, depois que uma organização é migrada, eles não lidam mais com a autenticação, portanto, considere a migração ao auditar como as integrações se autenticam, em vez de tratar os aplicativos conectados como o modelo permanente.

Além de escolher um fluxo de autenticação, crie uma governança distinta para a qual os aplicativos podem se conectar:

• Um registro por integração: Registre um aplicativo cliente externo dedicado para cada nova integração e um aplicativo conectado distinto para cada aplicativo existente. Escopo definido apenas para os escopos de OAuth que cada integração exige, em vez de compartilhar um registro amplo entre muitos, um registro dedicado mantém o acesso de cada integração independentemente auditável e revogável.
• Preautorize o acesso explicitamente (recomendado): Defina a política Usuários autorizados do aplicativo cliente externo como "Os usuários aprovados pelo administrador são pré-autorizados" para que um administrador conceda acesso por meio de perfis e conjuntos de permissões em vez de permitir que os usuários se autorizem. Os administradores configuram isso diretamente em Configuração, e é o controle recomendado do Salesforce para determinar quem pode se conectar.
• Controle de acesso à API (mais rígido, baseado em lista de permissões): Para controles mais rígidos, o Controle de acesso à API limita usuários aprovados pelo administrador apenas a aplicativos conectados na lista de permissões. A ativação exige uma solicitação ao Suporte ao cliente da Salesforce, portanto, planeje essa etapa ao projetá-la, em vez de tratá-la como uma configuração de autoatendimento.

Nunca integre credenciais em código, arquivos de configuração ou controle de versão. Use credenciais nomeadas e credenciais externas para gerenciar a autenticação centralmente com recursos de rotação.

Diferentemente da autenticação de usuário tradicional, os agentes exigem modelos de identidade distintos, e o modelo certo depende de o agente atender funcionários ou usuários externos. Projetar a identidade corretamente é a base da segurança do agente: ele determina quais dados o agente pode acessar e quais ações o agente pode alcançar.

Vamos analisar mais detalhadamente os agentes internos e externos. nts.

• Agentes de funcionários (internos): Execute tarefas no contexto do usuário conectado. Elas herdam as licenças do usuário, os conjuntos de permissões, a segurança em nível de campo e as regras de compartilhamento, de modo que nenhuma identidade de agente separada seja provisionada e a estrutura de segurança existente rege o que o agente pode fazer.
• Agentes do cliente (externos): Interaja por meio de canais públicos e execute como Usuários agentes dedicados, usuários de integração especializados, não usuários convidados do site público. Executar como usuários de integração dedicados permite que o agente realize ações de back-end e acesse dados (o que perfis de convidado não autenticados não podem fazer), enquanto ainda está vinculado por permissões explícitas de privilégio mínimo. Ao criar um agente do cliente, provisione um novo Usuário agente com acesso mínimo e conceda apenas as permissões específicas de que suas ações exigem.

Quando o trabalho de um agente abrange vários serviços, propague a identidade do usuário em cada salto de serviço em vez de recuar para uma identidade de convidado ou compartilhada. O fluxo do Salesforce OAuth 2.0 Token Exchange oferece suporte a:

Um cliente apresenta o token de provedor de identidade existente do usuário e um manipulador de troca de token do Apex o mapeia para um usuário do Salesforce e emite um token de acesso do Salesforce, de modo que o contexto do usuário original segue a solicitação em vez de recolher para uma conta de serviço. Monitore a atividade do agente por meio do Monitoramento de evento, usando a identidade de usuário do agente para detectar comportamento anômalo.

A escolha do modelo certo depende de quem inicia a conexão e em qual contexto o trabalho deve ser executado.

Cenários de conexão comuns são mapeados para abordagens recomendadas da seguinte maneira:

Projete hierarquias de papéis em torno de necessidades de acesso a dados (que os usuários precisam de acesso a registros de propriedade de outros) e não o gráfico de relatórios de gerenciamento. Permita que a profundidade da hierarquia de papéis siga relacionamentos de acesso a dados genuínos em vez de adicionar níveis que não concedam acesso adicional, pois cada nível adiciona sobrecarga de cálculo de compartilhamento, uma consideração que tem mais peso em organizações com configurações privadas de OWD e grandes volumes de dados.

Conjuntos de permissões e grupos de conjuntos de permissões reduzem a necessidade de proliferação de perfil fornecendo acesso flexível e complementar. Conceda acesso funcional por meio de conjuntos de permissões e grupos de conjuntos de permissões, em vez de perfis, que mantêm o acesso additivo e auditável. Os perfis continuam necessários: junto com as restrições de IP e horas de login, eles controlam a atribuição de layout de página, os padrões de tipo de registro e a visibilidade do aplicativo. Trate perfis como uma parte durável do modelo de acesso, em vez de uma construção para eliminar.

As políticas de segurança da transação não fazem parte da linha de base, são um recurso complementar que complementa o modelo de autorização principal: os controles de identidade, papel, perfil, conjunto de permissões e compartilhamento acima já estabelecem uma postura de autorização segura por conta própria, e a Segurança da transação adiciona a avaliação contextual em tempo real. Configure políticas para detectar e bloquear comportamento anômalo, incluindo downloads de dados em massa que excedem padrões normais, logins de geografias inesperadas e alterações de permissão fora de janelas de alteração.

Os controles de segurança têm compensações de disponibilidade que são uma responsabilidade arquitetônica. Uma restrição de IP excessivamente ampla pode bloquear usuários legítimos durante uma mudança de rede, e uma política de Segurança da transação ajustada com agressividade demais pode bloquear a atividade comercial válida. Portanto, defina o escopo desses controles para o risco real, coloque-os no modo somente monitor antes de aplicá-los e projete um caminho transparente para quando um controle falhar.

Sua responsabilidade: Projete a hierarquia de papéis, crie conjuntos de permissões, configure políticas de segurança da transação.

O controle de acesso baseado em papel tradicional) concede permissões com base no papel de um usuário. O ABAC (controle de acesso baseado em atributo) toma decisões de autorização com base nos atributos dos dados, do usuário e do contexto.

Para a maioria dos requisitos, o modelo de compartilhamento principal expressa o acesso totalmente. Entre em contato com ABAC dedicado quando o acesso precisar seguir uma classificação de dados que não pode ser expressa por compartilhamento por registro: O Data 360 ABAC fornece isso por meio de marcações e anotações.

O Data 360 ABAC opera por meio de:

• Políticas baseadas em marcas que definem regras de acesso com base em marcas aplicadas a objetos de dados (por exemplo, informações de identificação pessoal (PII), marcas financeiras, de saúde e confidenciais).
• As Anotações são aplicadas aos objetos de dados para apoiar decisões de autorização baseadas em políticas.
• Política padrão "Permitir tudo" para organizações novas e existentes que devem ser excluídas explicitamente para habilitar políticas de governança granular.

Seu principal uso arquitetônico é impor classificação de dados – consulte Classificação de dados em Proteção de dados e privacidade para ver como os níveis de classificação conduzem à imposição de ABAC.

Esse nível de granularidade traz um custo operacional. O compartilhamento principal responde à pergunta "Quem pode ver esse registro e por quê?" de um conjunto pequeno e inspetível de regras (OWDs, hierarquia de papéis e regras de compartilhamento), enquanto a ABAC deriva suas respostas no momento da avaliação da combinação de marcas de dados, atributos do usuário e contexto, de modo que o acesso eficaz fica mais difícil de raciocinar e de auditar conforme as políticas e as marcas se acumulam.

Impor a capacidade de auditoria como um requisito de design: aplique marcas de modo consistente, mantenha o conjunto de políticas pequeno e nomeado para a classificação que ele impõe e preserve a capacidade de reconstruir por que um usuário atingiu um determinado registro. Reserve o ABAC para casos conduzidos por classificação que não podem ser expressos genuinamente por compartilhamento por registro, em vez de tratá-lo como uma substituição geral para o modelo baseado em propriedade.

Identifique e proteja contas com privilégios elevados, incluindo administradores do sistema, usuários de integração e contas de processo automatizadas. Essas contas são alvos de alto valor para invasores.

Aplique controles aprimorados a contas de impacto crítico.

• Exigir MFA resistente a phishing
• Restringir intervalos de IP de login a locais administrativos conhecidos
• Habilitar alertas de login e notificações de alteração de permissão
• Realize análises periódicas de acesso com atestado documentado para contas de alto privilégio em que a frequência seja determinada pelos requisitos de conformidade e tolerância de risco da organização
• Manter procedimentos de vidro quebrado para acesso de emergência e auditoria pós-uso

Para contas de integração e serviço:

• Aplicar fluxos do OAuth; nunca fluxos de nome de usuário e senha
• Impor restrições de IP
• Implementar agendas de rotação de credenciais
• Monitore padrões de uso de API anomálicos por meio do Monitoramento de evento

Sua responsabilidade: Identifique contas críticas, aplique controles aprimorados e faça análises trimestrais.

Projete processos automatizados para provisionar usuários com o acesso inicial adequado, ajustar permissões conforme os papéis evoluem e descontinuar o provisionamento imediatamente quando o acesso não for mais necessário.

Implemente um Sistema para gerenciamento de identidade entre domínios (SCIM) para provisionamento automatizado de provedores de identidade. O provisionamento preciso SAML ou OpenID Connect é uma alternativa que cria um usuário no primeiro login, mas não desativa o provisionamento de usuários. Em outras palavras, o SCIM é a base do ciclo de vida, não uma opção contra ele.

O ciclo de vida da identidade inclui:

• Provisionamento: Crie contas com acesso de linha de base que corresponda à função de trabalho, que é acionada por eventos do sistema de RH.
• Ajustes de acesso: Conceda permissões adicionais à medida que os papéis se expandem e revogue permissões quando os papéis mudam.
• Recertificação periódica: Revise e valide o acesso trimestralmente.
• Desprovisionamento: Revogue o acesso imediatamente quando o emprego terminar ou os papéis não precisarem mais de acesso ao Salesforce.

Implemente processos de recertificação de acesso quando os gerentes revisarem e validarem periodicamente as permissões de suas equipes. A frequência de revisão é baseada nos requisitos de risco e conformidade.

Sua responsabilidade: Implemente SCIM, projete fluxos de trabalho de provisionamento e realize uma nova certificação trimestral.

A separação de dados em várias organizações às vezes é vista como meramente uma decisão de custo ou residência. Em termos arquitetônicos, é uma compensação de segurança, e as consequências de governança pertencem ao seu design de acesso.

O isolamento é o principal benefício. Organizações separadas fornecem o limite mais forte possível entre conjuntos de dados. Não há um modelo de compartilhamento coletivo e nenhum fluxo de permissões entre locatários, mas há uma linha regulatória clara para jurisdições que exigem um. Esse mesmo limite fragmenta a governança. Cada controle de acesso que você precisa manter apenas uma vez em uma única organização (por exemplo, design de conjunto de permissões, hierarquia de papéis, endurecimento de conta de impacto crítico, linhas de base de Verificação de integridade, Monitoramento de evento e correlação de SIEM) agora é multiplicado por organização, o que significa que deve manter a consistência em todas elas. O desvio entre organizações cria sua própria superfície de ataque porque uma permissão que é apertada em uma organização e perdida em outra cria uma inconsistência que os invasores podem encontrar e explorar. Integrações entre organizações adicionam limites de Trust autenticados que não existiam antes. Cada integração entre organizações é uma conexão que você precisa proteger e monitorar.

É por isso que é importante ponderar o benefício do isolamento em relação ao multiplicador de governança antes de dividir uma organização. Reserve várias organizações para casos em que um mandato de localização permanente ou o requisito de isolamento contratual de um cliente não podem ser atendidos de verdade em uma única organização. Quando você o adota, precisa projetar o modelo de acesso, o monitoramento e as linhas de base de configuração para serem aplicadas de maneira idêntica em cada organização desde o início.

Sua responsabilidade: Trate uma decisão de várias organizações como uma compensação de segurança, não apenas um custo. Quando a integração entre organizações for necessária, aplique os controles de acesso, o monitoramento e as linhas de base de Verificação de integridade de forma consistente em cada organização e proteja cada integração entre organizações como um limite de Trust.

É sua responsabilidade classificar dados, configurar a criptografia e projetar controles de privacidade.

Vamos analisar mais detalhadamente como proteger adequadamente os dados e a privacidade.

Para classificar adequadamente seus dados, você precisa conhecer seus dados. A tarefa arquitetônica abrangente é entender seu domínio de negócios e manter um dicionário de dados que cataloga quais dados você contém, o que eles significam e onde os dados confidenciais estão. Você só pode classificar ou proteger dados que identificou primeiro.

Estabeleça um esquema de classificação de dados que impulsione os controles de proteção adequados. Um rótulo de classificação não protege nada sozinho. É a entrada aos controles que você aplica, assim, cada classificação atribuída deve ser mapeada para uma decisão concreta de criptografia, acesso, retenção ou monitoramento. As decisões de classificação tomadas durante a modelagem de dados influenciam diretamente os requisitos de criptografia, os controles de acesso, as políticas de retenção e as obrigações de conformidade.

No Salesforce, usamos um esquema de quatro níveis que fornece uma estrutura que você pode adaptar aos requisitos regulatórios e às necessidades de negócios da sua organização. Muitas empresas usam modelos semelhantes alinhados aos padrões do setor (por exemplo, ISO 27001 e NIST). Sua implementação específica deve refletir suas obrigações de conformidade (por exemplo, HIPAA, PCI DSS, GDPR e normas do setor) e contexto de negócios.

Aplique a classificação no nível do campo. Um único registro de Conta pode conter campos públicos (por exemplo, nomes da empresa), campos confidenciais (por exemplo, receitas da empresa) e campos Restrito (por exemplo, números de previdência social). A segurança em nível de campo deve refletir essas distinções.

A classificação se torna aplicável por meio do controle de acesso baseado em atributo, que lê as marcas atribuídas e aplica regras de acesso. Esta é uma camada acionada por metadados que complementa as regras de compartilhamento e OWD.

Alinhar o ABAC ao seu esquema de classificação permite que a plataforma:

• Restrinja o acesso aos dados marcados como Restrito ou Confidencial da classificação em si, em vez de de uma regra de compartilhamento mantida por objeto.
• Adapte o acesso conforme a classificação de um registro muda ao longo do tempo. Um registro recém-marcado como Regulado herda acesso mais rígido sem uma alteração de regra manual.
• Combine atributos de dados (por exemplo, classificação e confidencialidade) com atributos de usuário (por exemplo, departamento e limpeza) e contexto (por exemplo, hora e local) em uma única decisão de autorização.

Crie políticas da ABAC para se alinhar a esse esquema de modo que a classificação de um campo como Restrito seja o ato que conduz seus controles de acesso e mantém a imposição ancorada à classificação em vez de manter regras de compartilhamento separadamente.

Sua responsabilidade: Defina o esquema de classificação, treine modeladores de dados, classifique campos durante o design, configure controles e alinhe políticas ABAC aos níveis de classificação para que as marcas promovam a imposição.

IniciarIniciar com as informações que a plataforma já fornece para cada organização. Dados em repouso são criptografados por padrão. O Hyperforce aplica criptografia em nível de volume que protege todo o volume de armazenamento com uma única chave de propriedade e gerenciada pelo Salesforce. Essa linha de base está sempre ativa e transparente para sua solução, mas opera no nível de volume (não por campo), portanto, escolher o que criptografar e controlar dentro do ciclo de vida da chave depende da plataforma, não de você.

Quando essa linha de base não puder cumprir uma obrigação de conformidade, contratual ou de classificação de dados, use o Shield Platform Encryption. Especificamente, quando você precisa de um dos três itens que a criptografia em nível de volume não fornece:

• Controle do ciclo de vida da chave para que você mesmo possa gerar, alternar e revogar o material de chave
• Seletividade sobre quais campos padrão, campos personalizados, arquivos e anexos são criptografados em repouso
• A capacidade de tornar os dados inacessíveis ao Salesforce.

Dados restritos e dados que estão sob mandatos de controle de chave regulatória explícitos (por exemplo, HIPAA, PCI DSS e GDPR) são os acionadores normais. A linha de base já cobre a proteção em nível de infraestrutura de tudo o mais.

O Shield Platform Encryption criptografa no nível do campo e oferece dois esquemas que trocam a segurança pela capacidade de consulta.

A criptografia probabilística é um esquema forte e padrão, mas os campos que são criptografados com ela não podem ser usados em critérios de filtro, classificação ou funções agregadas (por exemplo, funções MAX(), MIN() e COUNT_DISTINCT().

A criptografia determinística permite a filtragem de correspondência exata em relatórios, modos de exibição de lista e cláusulas SOQL WHERE, com diferenciação entre maiúsculas e minúsculas, com menor intensidade porque o mesmo texto simples sempre produz o mesmo texto criptografado.

Recomendamos criptografar com o esquema probabilístico por padrão e reservar a criptografia determinística para os campos específicos que você deve filtrar ou classificar. Avalie essas compensações durante o design de modelagem de dados, incluindo impactos em referências de campo de fórmula, agregação de relatório e operações SOQL.

Chaves controladas pelo cliente vêm em duas formas distintas:

• O Traga sua própria chave (BYOK) permite gerar material de chave fora do Salesforce (usando suas próprias bibliotecas de criptografia, sistema de gerenciamento de chaves corporativas ou módulo de segurança de hardware) e fornecê-lo à plataforma.
• O Serviço de chave somente em cache mantém sua chave de criptografia de dados em um serviço de chave que você controla. O Salesforce o busca sob demanda, em vez de armazená-lo.

Ambos os formulários permitem que você faça a rotação e destrua material de chave conforme sua própria agenda. A destruição do material de chave torna os dados protegidos irrecuperáveis, o que é um controle eficiente e deliberado, em vez de uma rotina. Também é importante documentar seus procedimentos de rotação e revogação de chave.

Todas as integrações devem usar TLS 1.2 ou superior (a Salesforce Platform impõe isso), mas você precisa implementar a autenticação mútua baseada em certificado para integrações que lidam com dados restritos (usando sua própria configuração).

Sua responsabilidade: Decida onde a linha de base no nível do volume da plataforma é suficiente e onde uma obrigação de conformidade, contratual ou de classificação justifica o Shield Platform Encryption, selecione esquemas de criptografia, escolha e execute uma estratégia de chave controlada pelo cliente e implemente autenticação baseada em certificado para integrações confidenciais.

Proteja dados confidenciais em ambientes que não sejam de produção usando estratégias que impedem que dados restritos entrem em sandboxes.

• A cópia parcial de sandbox exclui Dados restritos das atualizações de sandbox.
• As regras de mascaramento de dados confundem valores de campo confidenciais em sandboxes usando padrões que preservam as características dos dados.
• A geração de dados sintéticos aplica-se a ambientes de desenvolvimento que nunca exigem dados de produção.
• Os modelos de sandbox definem quais objetos e campos incluir em cada tipo de sandbox.

Projetar para testes de conformidade é uma responsabilidade arquitetônica. Crie ciclos de desenvolvimento e teste em dados sintéticos com características realistas para que as equipes possam validar em condições semelhantes a produção enquanto os dados regulamentados permanecem dentro do limite de produção.

Sua responsabilidade: Projetar estratégia de sandbox, configurar regras do Data Mask, gerar dados de teste sintéticos.

Projete soluções que respeitam a privacidade do usuário por meio de decisões arquitetônicas.

• Minimizar dados: Colete dados necessários apenas para fins comerciais declarados. Desafiar cada adição de campo perguntando "Que decisão arquitetônica exige esses dados?" Lembre-se de que os dados mais seguros são aqueles que você nunca coleta.
• Limitação de finalidade: Projete padrões de acesso a dados que aplicam a limitação de finalidade tecnicamente. Use conjuntos de permissões e regras de compartilhamento para restringir o acesso aos dados com base na finalidade de uma função de trabalho. Por exemplo, os usuários de marketing não devem acessar os detalhes do caso de suporte, a menos que seu trabalho o exija.
• Gerenciamento de consentimento: Implemente o rastreamento de consentimento no nível individual para marketing, análise e processamento de dados opcional. Projete fluxos de trabalho de retirada de consentimento que se propagam entre sistemas integrados. Em outras palavras, o consentimento é granular e específico da finalidade.
• Direitos dos titulares de dados: Crie fluxos de trabalho para solicitações de acesso (por exemplo, fornecer cópias de dados), correção (por exemplo, corrigir imprecisões), apagamento (por exemplo, excluir dados quando for legalmente permitido) e portabilidade (por exemplo, exportar para um formato legível por máquina). Projete esses fluxos de trabalho para serem concluídos dentro do prazo de resposta que cada estrutura de regulação impõe. Esses prazos variam de acordo com a jurisdição e são alterados periodicamente, portanto, é importante parametrizar o SLA do fluxo de trabalho de uma fonte de conformidade mantida e confirmar cada janela em relação à regulamentação aplicável (em vez de codificar um único valor).

Sua responsabilidade: Projete modelos de dados com minimização, configure o acesso por finalidade, implemente fluxos de trabalho de consentimento, crie automação de direitos de sujeito de dados.

A residência de dados é uma decisão arquitetônica que você toma antes do provisionamento, não uma configuração que você alterna depois. O Hyperforce oferece implantação regional, mas existe apenas uma região onde o Salesforce opera uma, e a residência de uma organização é fixa no provisionamento. Sua responsabilidade é estabelecer onde cada categoria de dados deve residir, confirmar se uma região adequada está disponível e projetar os mecanismos de transferência de dados que legitimamente cruzam fronteiras.

Em vez de usar o armazenamento no país como padrão, é importante classificar suas obrigações de residência antes de começar.:

• Localização obrigatória. Um pequeno conjunto de jurisdições exige que determinados dados permaneçam dentro das fronteiras nacionais (às vezes, isso se aplica apenas a setores regulamentados). Quando o Salesforce não opera em uma região no país, o armazenamento nativo não pode cumprir o mandato sozinho, portanto, você precisa de uma sobreposição de residência de dados ou uma organização separada para esses dados. Como essa lista pode mudar, é importante confirmar o mandato específico em relação ao regulamento em vigor.
• Quadros baseados em responsabilidade. A maioria dos regimes não impõe um mandato de localização. Eles são atendidos por um hub regional com um mecanismo de transferência transfronteiras adequado. Nesses casos, a decisão é baseada em qual região minimiza a latência e simplifica a conformidade.

Quando os dados atravessam uma borda, o ponto é a conscientização antes da configuração. Em outras palavras, você precisa saber quais transferências ocorrem e em que base legal, então projete o acesso para que os dados sejam regulados de ponta a ponta. Onde existem, as decisões de adequação têm o menor atrito. Regras corporativas vinculantes (BCRs) e cláusulas contratuais padrão (SCCs) cobrem a maioria das transferências restantes. Use consentimento explícito apenas como um último recurso.

Combine o mecanismo de transferência com acesso a registro restritivo (por exemplo, OWDs privados e compartilhamento no escopo de finalidade) para que uma transferência permitida não se torne excessivamente ampla. Os mapas de fluxo de dados de documento mostram onde cada categoria de dados se origina, passa e reside. Revise-os quando as normas ou as disponibilidades regionais mudarem.

Sua responsabilidade: Classifique obrigações de residência por categoria de dados, confirme a disponibilidade regional antes do provisionamento, selecione mecanismos de transferência (adequação, CCOs/SCCs) para fluxos transfronteiriços e documente mapas de fluxo de dados.

É sua responsabilidade projetar soluções que mantenham a postura de conformidade fornecida pela plataforma.

Essa orientação é direcional. Os requisitos regulatórios variam de acordo com a jurisdição e mudam ao longo do tempo. Você sempre deve verificar obrigações específicas em relação à regulamentação aplicável (por exemplo, estatuto aplicável, autoridade de supervisão ou documentação de conformidade do Salesforce) para sua implantação.

A Salesforce mantém extensas certificações de conformidade (disponíveis em Trust.salesforce.com e compliance.salesforce.com): SOC 2 Tipo II, ISO 27001, FedRAMP (para ofertas do Government Cloud), HIPAA, PCI DSS e certificações regionais. Essas certificações cobrem as responsabilidades da Salesforce para infraestrutura de plataforma e serviços compartilhados.

As certificações de plataforma reduzem seu fardo de conformidade, mas não eliminam sua responsabilidade arquitetônica. Seus objetos personalizados, Apex code, integrações e configurações devem manter a postura de conformidade fornecida pela plataforma.

Sua responsabilidade: Projete soluções que mantêm a postura de conformidade, documente como a arquitetura atende aos requisitos regulatórios.

• Habilite Shield Platform Encryption para todos os campos que contêm informações de saúde protegidas (PHI).
• Para conformidade com a HIPAA, habilite a Trilha de auditoria de campo com políticas de retenção para cumprir o requisito de registro da HIPAA. Confirme o período atual em relação ao regulamento regulador.
• Configure o Monitoramento de evento para detectar padrões de acesso PHI não autorizados.
• Implemente todas as proteções técnicas exigidas pela regra de segurança HIPAA, incluindo controles de acesso, registro de auditoria e segurança de transmissão.

• Implemente a segregação de deveres (SoD) por meio de designs de conjunto de permissões para evitar que usuários únicos criem e aprovem transações financeiras.
• Para ambientes de PCI, evite armazenar números de conta primários completos (PAN) no Salesforce para minimizar o escopo de conformidade do DSS de PCI.
• Quando possível, use a tokenização de gateway de pagamento.

• Para o GDPR e o LGPD, projete o gerenciamento de consentimento que capture o consentimento de adesão granular específico de finalidade.
• O CCPA/CPRA segue um modelo de recusa. Forneça mecanismos claros para recusar a venda ou o compartilhamento de informações pessoais em vez de consentimento granular baseado em finalidade.
• Crie fluxos de trabalho de direitos de sujeito de dados concluídos dentro do prazo de resposta de cada estrutura e confirmados em relação à regulamentação aplicável.
• Implemente a automação de retenção de dados que limpa os dados quando o consentimento expira.

• Use o Salesforce Government Cloud para cargas de trabalho do governo regulamentadas.
• Implemente controles NIST 800-53 mapeados para a configuração do Salesforce.
• Habilite o monitoramento contínuo por meio do Monitoramento de evento que é roteado para a infraestrutura SIEM do governo.

Sua responsabilidade: Configure o Shield, a Trilha de auditoria de campo, a segregação de tarefas, o gerenciamento de consentimento e a retenção de dados com base nos requisitos regulatórios.

As normas de proteção de dados e privacidade variam significativamente entre jurisdições, e as obrigações específicas mudam rapidamente, portanto, esse nível requer tomada de decisão, em vez de uma tabela de cada país.

As duas alavancas arquitetônicas são a residência e a transferência transfronteiriça, abrangidas pela Proteção de Dados e Privacidade.

Para cumprir essas normas, você deve:

• Classificar onde cada categoria de dados deve residir
• Confirme se há uma região adequada antes do provisionamento
• Projete um mecanismo de transferência legal para dados que cruzam uma fronteira.

Para obter mais informações, confira Residência e soberania de dados para obter mais detalhes sobre a estrutura de decisão.

Tudo além disso é considerado um ponto no tempo (por exemplo, qual modelo de consentimento uma jurisdição usa, o prazo para uma solicitação de sujeito de dados, a janela para notificar reguladores ou indivíduos afetados após uma violação e o período mínimo de retenção para registros de auditoria). Esses números são definidos por normas, diferem por estrutura e são alterados nas agendas dos reguladores.

Não os codifique aqui. Você precisa determinar as próximas etapas com base na regulamentação aplicável à sua implantação (ou uma fonte de conformidade mantida que cite uma) e dimensionar seu projeto para a janela mais estreita em sua pegada operacional.

Aqui estão as consequências arquitetônicas duráveis que pertencem ao design.

• Um prazo de data-assunto-solicitação medido em dias de dígitos únicos não pode ser cumprido por um processo manual ad-hoc, portanto, você precisa automatizar o cumprimento de DSR ao operar em qualquer jurisdição de prazo curto. Use o Experience Cloud para admissão, o Service Cloud para rastreamento de caso, o Centro de privacidade para descoberta e o Fluxo para processamento.
• Uma janela de notificação de violação é muito estreita para improvisar, portanto, você precisa criar o fluxo de trabalho de resposta de violação com antecedência. Determine regras de anomalia de Monitoramento de evento, papéis pré-atribuídos, notificações de regulador e sujeito de dados pré-classificadas e um caminho de escalação que presuma o prazo mais rígido dentro de sua pegada. Notificações individuais geralmente são acionadas por uma determinação de alto risco, portanto, você precisa incluir uma avaliação de risco no fluxo de trabalho.
• Algumas jurisdições exigem ou recomendam a retenção no país de registros de auditoria, com mínimos que abrangem vários anos, portanto, você precisa dimensionar a retenção de SIEM para o mínimo mais longo dentro de sua pegada e confirmar se os registros podem sair da jurisdição.

Sua responsabilidade: Projete residência e transferência por proteção de dados e privacidade, automatize fluxos de trabalho de DSR e resposta a violações para o prazo mais rígido em sua pegada e confirme cada número específico da jurisdição em relação à regulamentação aplicável, em vez de um valor escrito neste guia.

Projetado para validação de conformidade contínua em vez de preparação de auditoria de ponto no tempo.

• A Verificação de integridade de segurança avalia a configuração em relação às linhas de base de segurança do Salesforce e fornece pontuações de risco. Execute verificações regularmente para monitorar a conformidade com as recomendações de linha de base de segurança do Salesforce. Mantenha pontuações de 80% ou mais (bandas Muito bom ou Excelente).
• O Monitoramento de evento captura registros detalhados de atividade do usuário, chamadas à API, eventos de autenticação e padrões de acesso a dados. Encaminhe arquivos de log de evento para SIEM externo para retenção de longo prazo que exceda os limites de retenção nativos.
• A Segurança de transação avalia eventos em relação a apólices em tempo real e pode bloquear eventos, exigir um aumento na MFA ou notificá-lo de violações de apólices.

É importante automatizar verificações de conformidade nos pipelines de implementação para validar se as implementações não enfraquecem os modelos de permissão, desabilitam as configurações de auditoria ou introduzem configurações fora de conformidade.

Sua responsabilidade: Execute a Verificação de integridade trimestralmente, encaminhe o Monitoramento de evento para o SIEM, configure políticas de segurança da transação e automatize a validação de conformidade no CI/CD.

Projete estratégias de trilha de auditoria baseadas em requisitos de conformidade, necessidades de investigação e obrigações de retenção.

Para ambientes regulados, implemente o Monitoramento de evento com integração de SIEM externa para retenção de registro de longo prazo e correlação entre sistemas. Crie políticas de Trilha de auditoria de campo que abranjam todos os campos restritos e confidenciais sujeitos a requisitos regulatórios de manutenção de registros.

Sua responsabilidade: Habilite a Trilha de auditoria de campo para campos confidenciais, encaminhe o Monitoramento de evento para o SIEM e configure as políticas de segurança da transação.

É sua responsabilidade integrar a segurança ao longo do desenvolvimento, não como uma reflexão posterior.

Integre práticas de segurança na fase de desenvolvimento mais antiga possível. A modelagem de ameaças durante a fase da arquitetura evita vulnerabilidades no nível do design. Os requisitos de segurança capturados junto com os requisitos funcionais impedem que você trate a segurança como uma reflexão posterior.

Os defeitos de segurança custam significativamente mais para serem remediados quando são descobertos em produção, em vez de durante as fases de design ou desenvolvimento. Uma falha de segurança em nível de design que é capturada durante a revisão da arquitetura pode levar apenas uma conversa para corrigir. No entanto, quando a mesma falha é encontrada em produção, ela requer rearquitetura, migração de dados, remediação de conformidade e possível notificação de violação.

É por isso que praticamos a segurança de turno à esquerda, que se concentra em:

• Modelagem de ameaças antes da finalização do design
• Requisitos de segurança em histórias de usuário
• Treinamento de codificação segura para desenvolvedores
• Análise estática integrada a IDEs
• Revisões de código focadas em segurança
• Teste de segurança automatizado em CI/CD
• Validação de segurança antes da implementação da produção

Sua responsabilidade: Realize a modelagem de ameaças, treine desenvolvedores, integre o Analisador de código ao CI/CD e exija revisões de código sensíveis à segurança.

É importante projetar defesas contra vulnerabilidades comuns em um contexto do Salesforce. Vamos dar uma olhada mais de perto em como mapear para o Top 10 OWASP de 2025 no Salesforce.

• A01:2025 - Controle de acesso quebrado: Imponha programaticamente a segurança CRUD e em nível de campo (FLS) em todos os acessos a dados do Apex.
  • Na API versão 67.0 ou posterior, o Apex é executado no contexto do usuário por padrão, o que significa que as permissões do usuário atual e o FLS são impostos durante a execução do código.
    • WITH SECURITYENFORCED foi removido, o que causa um erro de compilação. Substitua qualquer uso existente por WITH USER_MODE. A plataforma aplica o acesso na IU padrão.
  • Na API versão 66.0 ou anterior, o modo do sistema é o padrão. Use WITH USERMODE em consultas SOQL ou Security.stripInaccessible() para operações DML.
• A01:2025 - APIs de dados no lado do cliente: O Lightning Data Service e a API da IU aplicam automaticamente o FLS, o CRUD e o compartilhamento do usuário em execução, de modo que um componente criado com base neles herda o privilégio mínimo por padrão.
  • Essa proteção é perdida quando um componente chama um Apex personalizado. O Apex imperativo impõe o acesso apenas quando é executado no modo de usuário, de modo que uma classe declarada sem compartilhamento atua como uma escape hatch que silenciosamente ignora o modelo.
  • Use o Lightning Data Service e a API da IU para acesso a dados.
  • Você deve reafirmar CRUD, FLS e compartilhamento para cada chamada imperativa do Apex de um componente.
• A02:2025 - Configuração incorreta de segurança: Monitore o desvio de configuração das linhas de base de segurança usando a Verificação de integridade.
  • Desabilite o acesso de Usuário convidado em sites do Experience Cloud (a menos que isso seja explicitamente exigido em uma justificativa comercial documentada).
• A05:2025 - Injeção: A categoria Injeção de 2025 abrange a injeção SOQL/SOSL e o script entre sites (XSS).
  • Para a injeção de consulta, use variáveis bind para todas as consultas dinâmicas. Nunca concatene a entrada do usuário diretamente em strings de consulta. Os mecanismos de consulta parametrizados da plataforma eliminam o risco de injeção quando usados corretamente.
  • As injeções SOQL ou SOSL têm o escopo definido para uma leitura que revela registros ou campos que o chamador não deve conseguir alcançar expandindo as condições de consulta. Como esses idiomas leem dados enquanto as gravações são executadas em operações DML separadas, isso cria um risco de controle de acesso e confidencialidade, pois se compõe quando as permissões de objeto e campo não são impostas na consulta.
  • Para XSS, os Componentes da Web Lightning fornecem proteção automática por meio do mecanismo de renderização do LWC.
  • Para componentes do Aura e do Visualforce, é necessário aplicar funções de codificação de plataforma (por exemplo, HTMLENCODE, JSENCODE e URLENCODE) ao renderizar conteúdo dinâmico.

Sua responsabilidade: Imponha CRUD/FLS no código personalizado, aplique funções de codificação, use variáveis bind e monitore o desvio de configuração.

Projete pipelines CI/CD com portões de segurança em cada estágio. A segurança deve ser automatizada para ser dimensionada com a velocidade de desenvolvimento.

Vamos analisar mais detalhadamente os estágios de segurança do pipeline.

• O controle de origem usa regras de proteção de filial com revisões de código obrigatórias. Não há confirmações diretas para ramificações principais ou confirmações assinadas.
• A análise estática usa o Salesforce Code Analyzer, que incorpora PMD, ESLint e RetireJS para detectar padrões de injeção, XSS e inseguros.
• A escaneamento de segurança usa ferramentas SAST e detecção de segredos para evitar confirmações de credenciais e verificação de vulnerabilidade de dependência.
• A validação de permissão usa técnicas de comparação automatizadas para revisar alterações de permissão em relação às linhas de base de segurança, que enviam alertas sobre expansão de privilégio.
• Os portões de implementação interrompem a implementação em descobertas de segurança críticas que exigem a aprovação da equipe de segurança para alterações de extensão de permissão.
• O monitoramento pós-implementação usa alertas de Monitoramento de evento para comportamento anômalo após implantações.

Sua responsabilidade: Integre o Analisador de código ao CI/CD, configure a proteção de ramificação, implemente portões de implementação e valide permissões automaticamente.

Os testes de segurança abrangentes incluem várias técnicas que lidam com diferentes classes de vulnerabilidade. Vamos analisar em mais detalhes cada estratégia.

• A análise estática executa o Salesforce Code Analyzer em IDEs do desenvolvedor para feedback imediato e em pipelines CI/CD como portões automatizados. A análise estática identifica vulnerabilidades no código-fonte sem executar o aplicativo.
• O Teste de penetração realiza testes de penetração para aplicativos personalizados expostos a usuários não confiáveis, especialmente sites do Experience Cloud e APIs voltadas para o público.
  • Para o AppExchange e a Revisão de segurança do AgentExchange, relatórios de análise estáticos são sempre necessários.
  • Um relatório de verificação dinâmica (teste de penetração) é necessário quando a solução integra um aplicativo ou serviço da Web de terceiros.
  • O teste de penetração simula técnicas de invasores contra aplicativos ativos.
• Testes de unidade focados na segurança Escrevem testes do Apex que validam a imposição do controle de acesso executando como usuários com diferentes perfis de permissão. É importante verificar se a imposição de CRUD/FLS bloqueia o acesso não autorizado.
• A escaneamento de dependência monitora pacotes do AgentExchange e bibliotecas JavaScript quanto a vulnerabilidades conhecidas. É importante assinar os avisos de segurança para pacotes instalados.

Sua responsabilidade: Execute o Analisador de código, realize testes de penetração, escreva testes de unidade de segurança e verifique dependências.

No Salesforce, a resposta a incidentes de segurança e dados foca a detecção, a contenção e a recuperação de violações, acesso não autorizado e destruição de dados maliciosos. As equipes de resposta a incidentes trabalham junto com dois pilares vizinhos que têm responsabilidades adjacentes:

• Excelência operacional abrange o mecanismo operacional de gerenciamento de incidentes (por exemplo, níveis de gravidade, rotação na chamada, escalação e revisão pós-incidente)
• A fidelidade abrange a recuperação de disponibilidade em relação às metas de RTO e RPO, incluindo a estratégia de backup e recuperação de desastres.

Como arquiteto, é sua responsabilidade projetar para detecção, resposta e recuperação de incidentes de segurança.

A capacidade de detecção é uma qualidade arquitetônica para a qual você deve projetar explicitamente. Sem monitoramento abrangente, os incidentes de segurança podem permanecer não detectados por períodos prolongados.

É importante implementar a detecção por meio de vários canais.

• O Monitoramento de evento captura registros de evento brutos que cobrem logins, exportações de relatórios e dados, alterações de permissões e chamadas à API. Você precisa identificar quais eventos são anômalos, o que requer políticas de Segurança da transação ou correlação SIEM sobre os logs que você configura para determinar a lógica de detecção.
• As políticas de segurança da transação avaliam eventos em tempo real e bloqueiam ações suspeitas. Você precisa configurar essas políticas.
• A Trilha de auditoria de configuração rastreia as alterações administrativas que a plataforma fornece, mas você precisa monitorá-las.
• O registro de aplicativo personalizado captura eventos relevantes para a segurança no Apex que você precisa implementar.

Encaminhe registros de Monitoramento de evento para plataformas SIEM para correlação com a telemetria de segurança corporativa. Projete regras de alerta que detectam padrões suspeitos enquanto também minimizam falsos positivos por meio de linhas de base comportamentais.

Sua responsabilidade: Encaminhe o Monitoramento de evento para o SIEM, configure políticas de segurança da transação, implemente o registro personalizado e estabeleça linhas de base comportamentais.

É importante documentar decisões arquitetônicas que dão suporte à resposta de incidentes antes da ocorrência de incidentes.

• Os limites de isolamento projetam soluções para isolar componentes comprometidos sem interromper funções de negócios críticas. Você precisa configurar a revogação do conjunto de permissões, as alterações de restrição de IP e o encerramento da sessão para fornecer recursos de isolamento rápido.
• A preservação forense usa o Monitoramento de evento para fornecer registros de atividade detalhados (funcionalidade da plataforma). A Trilha de auditoria de campo preserva o histórico de alterações de dados com base em sua configuração. Projete os logs para o armazenamento imutável para que os invasores não possam modificar sua arquitetura.
• Os procedimentos de recuperação documentam processos de recuperação testados para tipos comuns de incidentes. É importante validar a integridade do backup regularmente. Você precisa conhecer seu Objetivo de tempo de recuperação (RTO) e Objetivo de ponto de recuperação (RPO) para cenários de incidente de segurança.
• Os fluxos de trabalho de comunicação projetam mecanismos de notificação que funcionam durante incidentes (por exemplo, canais de comunicação fora da banda, modelos predefinidos e procedimentos de escalação que não dependem de sistemas potencialmente comprometidos).
• O canal de divulgação de vulnerabilidade é para sites do Experience Cloud voltados para o público. Ele oferece aos pesquisadores externos uma maneira documentada e monitorada de relatar problemas de segurança a você por meio de uma política de divulgação publicada no padrão RFC 9116 security.txt. Um relatório externo costuma ser o primeiro sinal de um incidente, portanto, é importante estabelecer esse caminho de entrada como parte da arquitetura pela qual você é responsável.

Sua responsabilidade: Procedimentos de isolamento de documento, roteamento de registros para armazenamento externo imutável, teste de procedimentos de recuperação trimestralmente, estabelecimento de comunicação fora da banda e publicação de um canal de divulgação de vulnerabilidade para sites voltados para o público.

No Salesforce, é importante preparar os recursos de resposta para cenários específicos da plataforma.

• As contas de usuário comprometidas são detectadas por meio de anomalias de login do Event Monitoring (por exemplo, geografia inesperada, horários incomuns e novos dispositivos). Quando as contas são comprometidas, congelar o usuário, forçar a redefinição de credenciais, revisar a Trilha de auditoria de configuração e os registros de acesso aos dados para determinar o período de compromisso.
• A exfilação de dados em massa é detectada por meio de exportações de relatórios de Monitoramento de evento e anomalias de acesso ao volume de dados da API. Quando ocorrer a exfiltragem de dados, revogue sessões imediatamente, restrinja permissões e identifique registros e níveis de classificação afetados.
• Implantação não autorizada de código é detectada por meio do monitoramento de implantação e alterações de configuração da Trilha de auditoria de configuração. Quando código não autorizado é implementado, reverta imediatamente a implantação e audite todas as alterações da credencial da implantação comprometida.
• A escalonagem de privilégio é detectada por meio do monitoramento da Trilha de auditoria de configuração para alterações de permissão que estão fora das janelas de alteração aprovadas. Quando ocorrer o escalonamento de privilégio, revogue imediatamente os privilégios escalonados e audite as atividades que foram realizadas com acesso elevado.

Sua responsabilidade: Documente procedimentos de resposta para cenários específicos da plataforma, configure o monitoramento para detectar cada cenário, teste procedimentos por meio de exercícios de mesa.

Após um incidente, é importante realizar uma revisão pós-incidente sem estimativa focada em melhorias arquitetônicas. Você precisa documentar o que aconteceu, por que os controles existentes falharam para evitar ou detectar o incidente e quais alterações arquitetônicas são necessárias para reduzir riscos futuros.

Objetivos de revisão pós-incidente:

• Determine a linha do tempo do incidente e as técnicas do invasor.
• Identifique as falhas de controle que habilitaram o incidente.
• Documente todas as falhas arquitetônicas que o incidente revelou.
• Priorize a remediação baseada na redução do risco.
• Compartilhe as lições aprendidas entre equipes.
• Atualize as regras de detecção e os procedimentos de resposta.

É importante rastrear métricas de incidentes ao longo do tempo para determinar o tempo médio para detectar (MTTD), o tempo médio para responder (MTTR) e o escopo do impacto.

Sua responsabilidade: Realize uma revisão pós-incidente oportuna, documente melhorias em ADRs, acompanhe tendências de MTTD e MTTR e compartilhe as lições aprendidas.

Use essa lista de verificação durante revisões de arquitetura, antes da implementação de produção e periodicamente para avaliação contínua. Cada item representa suas responsabilidades como um arquiteto do Salesforce.

Responsabilidade compartilhada

• Documente tudo o que a Salesforce protege (por exemplo, infraestrutura, plataforma e certificações de conformidade).
• Documente tudo o que você precisa proteger (por exemplo, configuração, acesso, código personalizado e governança de dados).
• Identifique áreas de responsabilidade compartilhada (por exemplo, resposta a incidentes, gerenciamento de vulnerabilidade e monitoramento).
• Comunique as responsabilidades às partes interessadas e às equipes de implementação da forma mais clara e concisa possível.

Arquitetura de segurança

• Conclua a modelagem de ameaças usando a metodologia STRIDE antes de começar a criar.
• Aplique controles de defesa em profundidade a camadas de dados, aplicativo, identidade e integração.
• Implemente princípios de Trust zero que exigem verificação explícita para cada solicitação de acesso.
• Mantenha o inventário do ativo de segurança atual que cobre dados confidenciais, integrações, APIs e contas privilegiadas.
• Documente decisões de arquitetura de segurança em ADRs, incluindo análise de ameaças e justificativa de controle.
• Proteja clientes autônomos e em nome deles na fronteira do Salesforce Trust propagando identidades por usuário em vez de tokens de grupo.
• Armazene, faça a rotação e as credenciais de OAuth de escopo de privilégio mínimo por meio de aplicativos cliente externos.
• Para integrações contêinerizadas, aplique o isolamento do contêiner como um limite de segurança, criptografe o tráfego de VPN entre contêineres e híbrido com mTLS (quando a estrutura o exigir) e alinhe regiões de implantação com as certificações de conformidade e residência de dados

Gerenciamento de identidade e acesso

• Defina OWDs como Privado para objetos que contêm dados confidenciais.
• Reserve Somente leitura pública para objetos em que o acesso de leitura amplo é um requisito documentado.
• Imponha a MFA para todo o acesso à IU de produção e chaves de segurança de hardware para contas privilegiadas. Integrações somente de API que usam as credenciais de cliente ou portador JWT estão isentas.
• Implemente o SSO usando SAML 2.0 ou OpenID Connect com autenticação IdP forte.
• Use OAuth 2.0 (portador JWT preferencial) para todas as autenticações de API. Nunca use o OAuth 2.0 para credenciais integradas.
• Conceda acesso por meio de conjuntos de permissões baseados em requisitos de privilégio mínimo documentados.
• Aplique controles aprimorados a contas de impacto crítico (por exemplo, restrição de IP, alertas de login e análises periódicas de acesso).
• Realize análises periódicas de acesso usando a certificação documentada para contas de alto privilégio em que a frequência seja determinada pelos requisitos de conformidade e tolerância de risco da organização.
• Automatize o ciclo de vida da identidade por meio de provisionamento SCIM e detecção de conta dormente de 90 dias.
• Execute agentes funcionários no contexto do usuário conectado e provisione usuários agentes dedicados e com menos privilégios para agentes do cliente. Nunca faça isso para um usuário convidado do site público.
• Implemente o JWT para autenticação do agente usando identificadores de definição de bot e instância do agente.
• Defina políticas ABAC alinhadas aos padrões de classificação de dados e marcação de metadados consistentes.

Proteção de Dados e Privacidade

• Classifique todos os dados e aplique controles de proteção adequados a cada nível de classificação.
• Habilite o Shield Platform Encryption para dados restritos usando gerenciamento de chave documentado.
• Exigir o TLS 1.2+ para todas as integrações com autenticação baseada em certificado para dados restritos.
• Impedir que dados restritos entrem em ambientes que não sejam de produção por meio de mascaramento ou exclusão.
• Implemente o gerenciamento de consentimento com fluxos de trabalho de extração e rastreamento por finalidade granulares.
• Crie fluxos de trabalho de direitos de sujeito de dados que sejam concluídos dentro do prazo de resposta de cada estrutura reguladora. Eles devem ser dimensionados para a janela mais estreita em sua pegada operacional e parametrizados por jurisdição de uma fonte de conformidade mantida em que cada número é confirmado em relação à regulamentação regulatória.
• Documente os requisitos de residência de dados e valide o alinhamento da região do Hyperforce.

Conformidade e adesão regulatória

• Valide as certificações de plataforma que atendem aos requisitos regulatórios do seu setor.
• Habilite o Monitoramento de evento com roteamento SIEM para retenção que exceda os limites de retenção nativos.
• Configure a Trilha de auditoria de campo para cobrir campos restritos para garantir que a retenção atenda aos mínimos regulamentares.
• Mantenha as pontuações de Verificação de integridade de segurança de 80% ou mais (banda Muito bom ou Excelente) e documente quaisquer exceções.
• Automatize a validação de conformidade para pipelines de CI/CD que falham durante violações críticas.
• Implemente políticas de segurança da transação para detecção e resposta de anomalia em tempo real.

Ciclo de vida do desenvolvimento seguro

• Realize a modelagem de ameaça durante a fase de design (antes de fazer investimentos de construção significativos).
• Imponha CRUD/FLS em todos os ambientes do Apex.
• Considere a imposição automática de modo de usuário para a API versão 67.0 ou posterior ou use WITH USERMODE ou stripInaccessible() para a API versão 66.0 ou anterior.
• Não use WITH SECURITYENFORCED, que foi removido na API versão 67.0.
• Execute o Salesforce Code Analyzer em CI/CD quando descobertas críticas bloquearem a implantação.
• Exigir revisões de código por revisores sensíveis à segurança para todas as alterações de produção.
• Realize testes de penetração para todos os aplicativos voltados para o público e sites do Experience Cloud.
• Valide e limpe todas as entradas do usuário que impedem a injeção em contextos SOQL, SOSL e HTML.

Resposta a incidentes de segurança

• Projete regras de alerta de Monitoramento de evento para detectar padrões suspeitos por meio de linhas de base comportamentais.
• Encaminhe registros para armazenamento externo imutável para preservação forense.
• Documente e teste os procedimentos de resposta a incidentes para cenários específicos da plataforma.
• Realize análises pós-incidente impecáveis com ADRs para capturar melhorias arquitetônicas.
• Acompanhe métricas de MTTD e MTTR para identificar lacunas de detecção e resposta.

Compartilhe seu feedback sobre o Framework bem-construído.