Leia sobre nossas agendas de atualização aqui.

Um sistema seguro protege as partes interessadas e os dados de uma organização. As arquiteturas seguras verificam a identidade do usuário, restringem o acesso aos dados apenas às informações necessárias e impedem o comprometimento dos dados.

A Salesforce prioriza o Trust do cliente e a segurança dos dados. A Salesforce Platform garante privacidade e segurança. Informações de desempenho e segurança do sistema em tempo real estão disponíveis no Salesforce Trust.

A proteção dos dados da sua organização e do cliente é a base para criar soluções seguras do Salesforce. Como arquiteto do Salesforce, você é responsável por proteger os dados da sua organização e do cliente usando os recursos de segurança integrados do Salesforce. Considere a distribuição geográfica, o setor, os procedimentos operacionais da empresa e os tipos de dados do cliente ao tomar essas decisões.

Você pode tornar suas soluções mais seguras focando em três áreas: segurança organizacional, segurança da sessão e segurança de dados.

A segurança organizacional protege os sistemas contra acesso não autorizado garantindo que apenas usuários validados e autorizados possam acessar um sistema e apenas os recursos e dados necessários.

Os sinais de que você tem problemas de segurança organizacional incluem:

• Processos ad hoc para ativar ou desativar usuários
• Etapas pouco claras para atualizar a autorização para alterações de papel do usuário ou do sistema
• Dependência do Knowledge institucional de indivíduos para atribuições corretas de segurança do usuário
• Falha de alinhamento com estruturas de segurança estabelecidas ou práticas recomendadas do setor
• Ausência de uma estrutura de governança de dados estruturada e políticas de suporte

Você pode criar melhores controles de segurança organizacionais para suas organizações do Salesforce focando a autenticação e a autorização.

A autenticação é crucial para segurança e gerenciamento de acesso, verificando a identidade dos usuários que tentam acessar seu sistema. Isso se aplica a usuários humanos (funcionários, clientes) e usuários automatizados (sistemas externos, integrações), sendo que cada tipo de usuário requer esquemas de autenticação específicos. Para garantir acesso seguro em todos os pontos de entrada do Salesforce em sua organização, você precisará configurar vários métodos de autenticação.

Para criar fluxos de autenticação seguros no Salesforce:

• Crie usuários do Salesforce com base em indivíduos, não em personas. Os recursos de auditoria integrados do Salesforce são mais eficazes quando cada conta de usuário corresponde a um único indivíduo que acessa a plataforma. O uso de contas de usuário compartilhadas compromete a eficácia dessas auditorias, introduz vulnerabilidades de segurança adicionais, escala o potencial impacto de violações de conta e complica sua capacidade de criar esquemas de autorização eficazes. Isso inclui contas de usuário para usuários de integração.
• Cenários de acesso seguro baseados em UI. A maioria dos usuários humanos requer algum tipo de acesso baseado em IU (geralmente chamado de acesso de login) para uma organização do Salesforce. O Salesforce oferece várias camadas de proteção para esses cenários de login, incluindo:
  • Políticas de senha. Os cibercriminosos costumam ter como alvo nomes de usuário e senhas para obter acesso não autorizado aos aplicativos. Embora a configuração das políticas de senha seja um passo fundamental para proteger o acesso de login, é importante notar que isso sozinho não é suficiente, pois o Salesforce permite substituições por usuário dessas políticas.
  • Autenticação multifator (MFA). O Salesforce requer MFA para todos os logins de usuário baseados em IU. A MFA fornece uma defesa essencial contra vazamentos de credenciais e ataques de força bruta exigindo que os usuários forneçam uma forma adicional de identificação, ou fator, depois de inserir com sucesso seu nome de usuário e senha. Esse fator adicional geralmente assume uma forma física, como um dispositivo móvel, uma chave de segurança ou um marcador biométrico.
  • Sinal único ativado (SSO). Em cenários de SSO, os usuários usam apenas um conjunto de credenciais nos aplicativos de uma organização. O acesso aos sistemas é provisionado e gerenciado de um local central, o que melhora a segurança. O Salesforce pode atuar como um provedor de serviços ou um provedor de identidade em cenários de SSO. Certifique-se de permitir que alguns ou todos os administradores façam login diretamente no Salesforce para que possam resolver interrupções ou problemas com sua implementação de SSO.
  • Etapas após o login. Para alguns casos de uso, você pode exigir que os usuários concluam etapas adicionais antes de acessar seu sistema. Fluxos de login personalizados podem ser implementados para orientar os usuários por essas etapas extras do processo. Os exemplos incluem:
    • Aceitando termos e condições
    • Trabalhando com descoberta de login e cenários de login sem senha
    • Limitar o número de sessões simultâneas do Salesforce por usuário para reduzir a probabilidade de ataques baseados em sessão (consulte segurança da sessão).
    • Conectar-se a serviços de cerca geográfica
• Cenários de acesso seguro baseados em API. Qualquer usuário pode solicitar acesso baseado em API para uma organização do Salesforce. O Salesforce oferece várias camadas de proteção para cenários baseados em API, incluindo:
  • API Access Control. Sem o controle de acesso à API, qualquer pessoa com um conjunto válido de credenciais pode utilizar qualquer aplicativo para se conectar à sua organização, mesmo que o aplicativo conectado não esteja implantado na organização. Os controles de acesso a dados ainda serão aplicados, mas os usuários poderão acessar informações de maneiras não controladas. Por exemplo, um aplicativo pode ser usado para fazer download de grandes volumes de dados ou até mesmo carregar informações corrompidas sem a aprovação de um administrador do sistema.
  • Permissões somente API. Você pode configurar as permissões de usuário apenas de API no Salesforce. Atribua isso como parte de um conjunto de permissões a qualquer personalidade de usuário automatizada ou de integração para bloquear totalmente o acesso baseado em interface do usuário.
  • Certificados e chaves. Os certificados e chaves permitem que o Salesforce valide se as solicitações se originam de empresas ou empresas autorizadas. Você precisará configurar certificados e chaves se quiser usar o SSO com o Salesforce.
  • Aplicativos conectados. Configurar aplicativos conectados no Salesforce permite controlar o acesso do sistema externo ao Salesforce, incluindo protocolos de autenticação obrigatórios, escopo de autorização e comportamento da sessão em uma única definição.
  • Credenciais nomeadas. As credenciais nomeadas permitem controlar pontos de acesso externos e protocolos de autenticação em uma única definição no Salesforce. Use-os para definir e gerenciar com segurança a autenticação para chamadas do Apex, serviços externos e fontes de dados do Salesforce Connect.
• Autenticação de usuários agentes Agentforce. Os agentes do Agentforce, criados com base no Salesforce, usam objetos de agente-usuário com permissões gerenciáveis como os de usuários reais. Ao configurar um agente, alinhe o acesso com cuidado ao papel desempenhado pelo agente, limitando o acesso aos dados apenas ao que é necessário para atender aos usuários finais. Assim como é importante, os agentes podem ser configurados com ações públicas e privadas. Para ações privadas, valide e autentique os usuários finais, mapeando-os para o contexto do agente. Isso permite que o Agente se imite e opere dentro dos controles de acesso do usuário final, mantendo a segurança e Trust.

A lista de padrões e antipadrões abaixo mostra a aparência da arquitetura de autenticação adequada (e ruim) em uma organização do Salesforce. Use-os para validar seus designs antes de criar ou identificar oportunidades para melhorias adicionais.

Para saber mais sobre as ferramentas de autenticação disponíveis no Salesforce, consulte Ferramentas relevantes para segurança.

A autorização define quais recursos, funcionalidades e dados um usuário pode acessar, bem como as ações que ele pode executar com esses recursos depois de terem sido autenticados. Os controles de autorização não são apenas para usuários humanos, eles também precisam ser personalizados para Usuários Agentes do Agentforce, especialmente Agentes que fornecem serviços a usuários finais não autenticados.

Embora restringir quem pode se autenticar em sua organização seja uma primeira etapa crucial, é igualmente vital combinar autenticação forte com autorização robusta. Sem controles de autorização adequados, os usuários podem criar, editar e excluir registros ou acessar a funcionalidade do sistema de maneiras que são prejudiciais para sua empresa e suas partes interessadas. O controle de autorização inadequado também pode dificultar o uso dos sistemas. Ao controlar o que os usuários podem fazer no sistema, você promove níveis mais elevados de Trust, salvaguardando seu sistema e seus usuários.

Para criar esquemas de autorização seguros para o Salesforce:

• Siga o princípio do privilégio mínimo. Adote o princípio de privilégio mínimo (PoLP) atribuindo aos usuários apenas as permissões necessárias para suas tarefas. Para seguir esse princípio, crie conjuntos de permissões granulares e modulares. Isso permite controles de acesso sofisticados por meio de grupos de conjuntos de permissões, permitindo o gerenciamento preciso de permissões, incluindo a capacidade de mutir, de definir datas de expiração e muito mais. Alinhe suas unidades funcionais de sistemas com funcionalidades de negócios para definir permissões granulares e grupos de conjuntos de permissões eficazes. Lembre-se de que as permissões se aplicam ao acesso a metadados no Salesforce. Para obter detalhes sobre como configurar o PoLP para acesso a dados do Salesforce, consulte Compartilhamento e visibilidade.
• Pense sobre o acesso do usuário em termos de personas, não indivíduos. Pensar em autorização (ou segurança em geral) em termos de usuários individuais não configurará seu sistema em escala e evoluirá. Em vez disso, projete e gerencie personas que representam grupos de usuários. As soluções seguras do Salesforce usam indivíduos para autenticação e personas para autorização. Ao definir configurações de segurança para personas distintas, você obtém controle granular sobre o acesso e os privilégios em seu modelo de segurança, o que minimiza a necessidade de refatoramento no longo prazo. Inclua as personalidades de segurança que você define em suas normas de design e documentação.
• Controle o acesso do usuário aos metadados usando conjuntos de permissões e grupos de conjuntos de permissões. Conjuntos de permissões e grupos de conjuntos de permissões controlam o que os usuários de metadados podem acessar e o que eles podem fazer com esses metadados. Para aprender mais sobre metadados do Salesforce, consulte Metadados versus dados. Configure atribuições de aplicativo, ativações de licença de recurso, acesso a pacotes gerenciados, permissões do sistema, acesso CRUD e acesso em nível de campo por meio de conjuntos de permissões e grupos de conjuntos de permissões. Inclua esse acesso em suas normas de design e documentação.
• Use padrões organizacionais (OWDs) e compartilhamento para controlar o acesso aos dados dos usuários. Os dados e metadados são entidades distintas no Salesforce, exigindo controles de acesso separados para cada uma. Use OWDs e ferramentas de compartilhamento integradas para configurar o acesso a dados do Salesforce (registros, arquivos e documentos individuais). Para obter mais detalhes, consulte Segurança de dados.
• Use escopos do OAuth para controlar o acesso para aplicativos conectados. Ao configurar um aplicativo conectado, você define o escopo ou as permissões de acesso que os usuários do aplicativo terão para os recursos do Salesforce. Para obter mais informações sobre o gerenciamento de tokens OAuth, consulte Gerenciamento de sessão.
• Crie um usuário do Salesforce para cada integração. Para cumprir o princípio de privilégio mínimo, crie um único usuário de integração do Salesforce para cada integração. Isso permite que você atribua acesso a dados específicos, melhorando o controle sobre as operações, garantindo o rastreamento da transação e minimizando o impacto de possíveis violações de segurança.
• Implemente contas únicas com o PoLP para todos os usuários Agentes. Cada Usuário Agente do Agentforce deve ser único e não reutilizado entre vários Agentes. As permissões para essas contas devem cumprir estritamente o princípio de privilégio mínimo. Lembre-se de que as ações executadas por um usuário agente podem operar em um contexto de segurança elevado no Salesforce ou em sistemas externos que não respeitam os controles de acesso do Salesforce. Isso pode levar a Ações acessarem ou revelarem informações confidenciais aos usuários.
• Minimize o uso de perfis e migre quaisquer controles de acesso dos perfis. Os perfis permitem limitar o acesso a intervalos de IP de login, horas de login e recursos específicos da interface de usuário legada do Salesforce Classic (especificamente tipos de registro padrão e atribuições de layout de página). Qualquer outra funcionalidade atualmente em perfis deve ser migrada para funcionalidades equivalentes em conjuntos de permissões e grupos de conjuntos de permissões. A funcionalidade em seus perfis vinculados aos recursos da interface do usuário do Salesforce Classic deve ser direcionada para correção.

A lista de padrões e antipadrões abaixo mostra a aparência das práticas de autorização adequadas (e ruins) em uma organização do Salesforce. Use-os para validar seus designs antes de criar ou identificar oportunidades para melhorias adicionais.

Para saber mais sobre as ferramentas de autorização disponíveis no Salesforce, consulte Ferramentas relevantes para segurança.

Esta tabela mostra uma seleção de padrões para procurar (ou criar) em sua organização e antipadrões para evitar ou direcionar para remediação.

✨ Descubra mais padrões para segurança organizacional no Explorador de padrões e antipadrões.

Uma sessão é a série de solicitações e respostas associadas a um usuário ao longo de um período de tempo. Uma sessão é iniciada quando um usuário se autentica com sucesso no Salesforce. A segurança de sessão é a prática de configurar seu sistema para evitar acesso não autorizado e violações de dados, evitando interferência de sessão ou sequestro.

Todas as atividades do usuário no seu sistema ocorrem no contexto de uma sessão, portanto, é essencial considerar como as sessões são iniciadas, o que pode ocorrer durante uma sessão, quais dispositivos os usuários usarão (e devem) e como detectar e responder a comportamentos de sessão suspeitos ou anômalos.

Você pode criar a segurança da sessão no Salesforce focando três chaves: gerenciamento de sessão, acesso ao dispositivo e detecção e resposta de ameaças.

As sessões são iniciadas quando um usuário se autentica com sucesso e obtém acesso ao Salesforce. Essas sessões permitem que a plataforma associe solicitações e respostas específicas a esse usuário específico.

O protocolo HTTPS facilita a comunicação entre um cliente de front-end e a Salesforce Platform. Os clientes podem incluir navegadores, aplicativos móveis, aplicativos locais etc. HTTPS é um protocolo sem estado, o que significa que cada comunicação é discreta e não está relacionada a nenhuma comunicação anterior ou futura.

Essa abordagem sem estado acelera as comunicações de rede e elimina erros causados por links quebrados entre pacotes. No entanto, os aplicativos da Web ainda precisam de um modo de acompanhar a identidade de cada usuário e outras informações relacionadas em várias interações de resposta e solicitação. O Salesforce, como a maioria dos aplicativos da Web, realiza isso usando sessões e tokens.

• As sessões permitem que o Salesforce associe solicitações e respostas aos usuários. Depois que um usuário é autenticado, a plataforma envia um ID de sessão de volta ao aplicativo cliente, que inclui esse ID com qualquer solicitação do usuário (como navegar, pesquisar e enviar dados).
• Os tokens permitem que usuários e aplicativos conectados confirmem sua identidade uma vez e usem um token de acesso exclusivo a partir de então. Os tokens têm uma vida útil limitada e fornecem acesso apenas a recursos específicos (consulte Autorização para obter mais informações sobre a configuração dos níveis de acesso). Os tokens permitem acesso a recursos autorizados sem exigir que os usuários façam login.

Se as sessões e os tokens não forem protegidos adequadamente, os agentes ruins poderão interferir neles e personificar usuários ou executar código mal-intencionado no seu sistema.

Para criar gerenciamento de sessão seguro para o Salesforce:

• Entenda como o Salesforce classifica tipos de sessão. Identifique e mapeie tipos de sessão aprovados para personas de usuário de segurança e registre-os na sua documentação.
• Controle como as sessões podem se originar e para onde o tráfego da sessão pode ir. Depois de identificar os tipos de sessões que várias personalidades de usuário têm permissão para iniciar, configure controles para bloquear sessões originadas de origens ou contextos não aprovados. O Salesforce oferece várias maneiras de controlar as origens e o tráfego da sessão, incluindo:
  • Proteção de sessão integrada. O Salesforce habilita automaticamente proteções organizacionais para atividades mal-intencionadas baseadas em sessão, incluindo script entre sites, falsificação de solicitações entre sites, sniffing de conteúdo, clickjacking e muito mais. Essas proteções nunca devem ser desabilitadas; algumas não podem ser desabilitadas.
  • Domínios e intervalos de IP. Todas as organizações do Salesforce têm Meu domínio habilitado por padrão, o que cria um subdomínio específico da empresa para acesso ao Salesforce. Você pode personalizar ou alterar o nome associado a uma organização por meio do Meu domínio. Além disso, o Salesforce oferece suporte a outras configurações de domínio para sites do Experience Cloud e outras páginas de aplicativos. Nota: Se os usuários precisarem acessar o Salesforce de trás de um firewall da empresa, adicione os domínios obrigatórios às listas de permissões do firewall. Você pode configurar intervalos de IP de login e intervalos de IP confiáveis para controlar solicitações de login e sessão de entrada para o Salesforce.
  • Horas de login. Se determinadas personalidades de usuário tiverem horários de funcionamento definidos, você poderá restringir a capacidade delas de acessar o Salesforce fora dos horários de login definidos.
• Controle atividades que exigem segurança em nível de sessão adicional. Por padrão, as sessões podem ter dois tipos de níveis de segurança: padrão e de alta garantia. Use esses níveis de segurança para controlar como os usuários podem e não podem realizar atividades, como acessar relatórios e painéis ou gerenciar as configurações de segurança em uma organização do Salesforce. As políticas de segurança em nível de sessão podem exigir que os usuários criem sessões de alta garantia para realizar operações ou impedir que os usuários realizem operações confidenciais.
• Controle atividades que exigem permissões baseadas em sessão adicionais. O Salesforce oferece suporte a ativações de permissão baseadas em sessão para permitir temporariamente aos usuários autorização maior ou acesso a permissões durante uma determinada sessão. Você pode ativar e desativar permissões baseadas em sessão por meio de APIs do Salesforce ou Fluxo.
• Gerencie sessões de usuário inativas por meio de tempos limite. Encerrar sessões inativas é uma parte importante do gerenciamento da segurança da sessão. Isso ajuda a proteger seu sistema quando, por exemplo, um usuário deixa uma sessão do Salesforce aberta em uma guia do navegador, mas está ativamente trabalhando em outro aplicativo, ou quando o dispositivo móvel de um usuário está conectado ao Salesforce, mas está sem assistência. O Salesforce tem um tempo limite de inatividade da sessão padrão de duas horas. Você pode aumentar ou diminuir os níveis de tempo limite de inatividade da sessão, mas aumentar os tempos limite deve ser feito apenas com uma justificativa convincente e bem documentada.
• Gerencie sessões de aplicativo conectado por meio da configuração de token. Ao configurar um aplicativo conectado, você também define o escopo, ou nível de autorização, que será concedido aos usuários que acessam o Salesforce por meio do aplicativo conectado. Esse escopo é aplicado no nível da sessão por meio de tokens OAuth, que são emitidos depois que um usuário de um aplicativo conectado autentica com sucesso. Você pode controlar por quanto tempo um token deve durar por meio das políticas de atualização de token. Os administradores da organização podem revogar os tokens manualmente por usuário e por organização, se necessário.

A lista de padrões e antipadrões abaixo mostra como é o gerenciamento de sessão adequado (e ruim) em uma organização do Salesforce. Use-os para validar seus designs antes de criar ou identificar oportunidades para melhorias adicionais.

Para saber mais sobre as ferramentas de gerenciamento de sessão disponíveis no Salesforce, consulte Ferramentas relevantes para segurança.

No contexto atual, um dispositivo é qualquer peça de equipamento eletrônico que uma pessoa usará para acessar o Salesforce, como uma estação de trabalho de desktop, laptop, tablet ou telefone celular.

Dispositivos portáteis oferecem aos usuários a flexibilidade de acessar o Salesforce de qualquer lugar. No entanto, essa conveniência pode introduzir vetores de ataque adicionais para atores mal-intencionados. Esses vetores de ameaça variam de táticas simples, como surf em um local público para roubar credenciais, a métodos mais sofisticados, como instalar malware em um dispositivo ou criar uma rede Wi-Fi pública falsa para interceptar transmissões de dados. Por isso, proteger dispositivos, especialmente dispositivos portáteis, é essencial para a segurança geral do sistema.

Para proteger o acesso ao dispositivo para o Salesforce:

• Use as soluções de aplicativo móvel fornecidas pela Salesforce. Faça com que os usuários em dispositivos móveis que precisam acessar o Salesforce usem os aplicativos Salesforce disponíveis para iOS e Android. Se as necessidades de negócios exigirem uma solução móvel personalizada, você deve usar o Salesforce Mobile SDK, que fornece métodos para autenticação e autorização seguras.
• Projete o uso de dispositivos móveis no gerenciamento de sessão. Níveis de segurança da sessão, tempos limite da sessão e outros controles de contexto da sessão devem levar em conta qualquer acesso previsto dos usuários em dispositivos móveis. Considere quais dispositivos devem e não devem ter permissão para acessar o Salesforce e quais tipos de usuários devem ter acesso a sessões móveis. Inclua padrões de acesso móvel na sua documentação de personalidade de segurança. Para obter mais informações sobre este tópico, consulte Gerenciamento de sessão.
• Aumentar a segurança em nível de dispositivo com a tecnologia Gerenciamento de dispositivos móveis (MDM). Os aplicativos Salesforce para iOS e Android são compatíveis com muitos pacotes de MDM populares. Você pode configurar controles de acesso adicionais para o aplicativo Salesforce em dispositivos de usuário por meio da sua solução de MDM preferida.
• Aumentar a segurança em nível de aplicativo com a tecnologia Gerenciamento de aplicativo móvel (MAM). A tecnologia MAM oferece suporte a controles no nível do aplicativo em dispositivos móveis. O Salesforce oferece um complemento pago MAM para aplicativos móveis do Salesforce.

A lista de padrões e antipadrões abaixo mostra como é o gerenciamento de dispositivos adequado (e ruim) em uma organização do Salesforce. Use-os para validar seus designs antes de criar ou identificar oportunidades para melhorias adicionais.

Para saber mais sobre as ferramentas de gerenciamento de dispositivos disponíveis na Salesforce, consulte Ferramentas relevantes para segurança.

A detecção de ameaças é o processo de identificar padrões de comportamento em seu sistema que podem indicar atividade mal-intencionada. Isso pode incluir volumes maiores que a média de dados sendo baixados ou um usuário modificando campos contendo dados confidenciais em vários registros em um período menor que a média. As respostas a ameaças podem incluir expiração da sessão automatizada, alerta e outras notificações.

A meta da detecção de ameaças é identificar e responder a possíveis problemas o mais rapidamente possível. Realizar ações com base na detecção de ameaças em tempo real pode impedir o comportamento mal-intencionado em seu caminho. O Salesforce oferece o monitoramento de evento em tempo real como um complemento ou como parte do Salesforce Shield. Use uma dessas soluções se você tiver aplicativos altamente confidenciais ou precisar de recursos robustos de detecção e resposta de ameaças em tempo real.

Para criar uma estratégia eficaz de detecção e resposta de ameaças para suas soluções do Salesforce:

• Use recursos de auditoria integrados. O Salesforce oferece uma variedade de ferramentas integradas para ajudar a rastrear e auditar alterações na sua organização. Por exemplo, a Trilha de auditoria de configuração permite visualizar o histórico de auditoria de ações administrativas. O Salesforce rastreia alterações no nível do campo por um período de tempo limitado por padrão, mas você pode ativar o Rastreamento de histórico de campo para exibir alterações de campo por até 18 meses na IU e até 24 meses por meio da API. Além disso, você pode ativar a Trilha de auditoria de campo para reter um histórico de auditoria para alterações no nível de campo indefinidamente (até que você exclua os dados manualmente).
• Estabelecer revisões periódicas de auditoria. A auditoria é crucial para identificar alterações anômalas que a detecção de ameaças em tempo real pode perder. Considere um cenário em que um usuário com acesso legítimo exclui consistentemente um pequeno número de registros diariamente durante um período prolongado. Como esse usuário tem credenciais de login válidas, autorização adequada para excluir registros e não está excluindo um grande volume de registros de uma só vez, é improvável que a atividade seja detectada como uma ameaça em tempo real. No entanto, uma equipe de auditoria revisando relatórios de atividades do usuário identificaria claramente essa tendência de exclusão excessiva de registro por um único usuário ao longo do tempo, facilitando a solução. Como parte de suas políticas de governança, estabeleça intervalos regulares para auditar o histórico de login, a atividade da sessão do usuário e o uso do aplicativo conectado.
• Desenvolva uma estratégia de resposta a ameaças e inclua-a em suas políticas de segurança. Crie uma estratégia de resposta à ameaça que abranja:
  • Definições de tipo de resposta às ameaças (por exemplo, alertas e automações) e quaisquer grupos de partes interessadas. Para obter mais informações sobre a criação de mensagens ou alertas, consulte Erros e notificações.
  • Categorias específicas para alterações em tempo real ou atividades que podem ser consideradas ameaças e o tipo de resposta associado para cada uma
  • Uma lista clara de todas as respostas a ameaças automatizadas (como revogar tokens, encerrar sessões, desativar contas de usuário ou bloquear o acesso a recursos) e acionadores de automação

O Monitoramento de evento fornece os dados necessários para aplicar esse princípio habilitando a detecção e resposta a ameaças em tempo real. A Segurança da transação aplica as ações conduzidas pela política da sua empresa, e os tipos de evento dão suporte ao monitoramento do acesso do usuário e do aplicativo ao longo do tempo.

O serviço nativo de Detecção de ameaças do Salesforce usa modelos estatísticos e de aprendizado de máquina para identificar comportamento suspeito. Esse serviço gera eventos específicos que protegem contra ataques cibernéticos e acesso a dados suspeitos.

A Segurança da transação leva a segurança um passo adiante, pois fornece uma estrutura que intercepta os principais eventos que ocorrem na sua organização e aplica as ações conduzidas pela política da sua empresa. Isso transforma o Monitoramento de evento de uma ferramenta de registro em um componente importante de uma defesa de segurança automatizada.

A lista de padrões e antipadrões abaixo mostra como é a detecção e resposta adequadas (e ruins) de ameaças em uma organização do Salesforce. Use-os para validar seus designs antes de criar ou identificar oportunidades para melhorias adicionais.

Para saber mais sobre as ferramentas de automação de detecção, alerta e resposta de ameaças disponíveis no Salesforce, consulte Ferramentas relevantes para segurança.

Esta tabela mostra uma seleção de padrões para procurar (ou criar) em sua organização e antipadrões para evitar ou direcionar para remediação.

✨ Descubra mais padrões para segurança da sessão no explorador de padrões e antipadrões.

A segurança de dados é a prática de proteger seus dados contra acesso não autorizado, corrupção ou exclusão acidental. A segurança de dados envolve proteger dados em trânsito e em repouso.

Uma forte segurança de dados minimiza os riscos e possíveis danos decorrentes de acesso não autorizado ao seu sistema. A segurança de dados inadequada torna os sistemas vulneráveis a violações de dados, o que pode afetar seriamente os clientes e sua empresa. Portanto, proteger seus dados é fundamental para criar arquiteturas seguras.

Melhorar a segurança de dados começa com uma compreensão clara do que é considerado como dados no Salesforce, junto com sua classificação. Os registros individuais, arquivos e documentos armazenados em uma organização do Salesforce são seus dados. Para obter mais informações sobre a distinção entre metadados e dados, consulte Bases da Arquitetura do Salesforce.

Você pode criar segurança de dados mais forte em suas soluções do Salesforce focando o compartilhamento e a visibilidade, bem como o uso de criptografia.

Nota: Ao projetar para segurança de dados, lembre-se de levar em conta a privacidade dos dados, bem como o arquivo e a limpeza, pois ambos os conceitos afetarão a segurança geral dos dados das suas soluções.

Identifique e classifique todos os dados armazenados na Salesforce Platform com base em sua confidencialidade (por exemplo, público, interno, confidencial, restrito). Defina uma clara política de classificação de dados que descreva como cada tipo de dados deve ser tratado e protegido. Implemente controles de segurança adequados, como segurança em nível de campo, criptografia e mascaramento de dados, para aplicar a política e proteger dados confidenciais contra acesso ou exposição não autorizados. Revise e audite essas classificações e controles regularmente para garantir que eles permaneçam alinhados aos requisitos de negócios e conformidade.

O compartilhamento e a visibilidade envolvem configurar seu sistema para controlar como os usuários acessam dados no Salesforce. É importante notar que o compartilhamento e a visibilidade controlam quais registros individuais um usuário pode acessar, mas essas configurações sozinhas não controlam, por fim, o que um usuário pode fazer com um registro específico ou quais campos específicos nesse registro estão visíveis. As permissões para realizar operações de dados (como CRUD) são atribuídas aos usuários por meio de controles de acesso a metadados, que podem ser configurados para um usuário no nível de objeto e campo individual. Para obter mais informações sobre isso, consulte Autorização.

Ações do Agentforce podem expor dados a usuários autenticados e anônimos que normalmente não têm acesso direto. Ao criar Agentes do Agentforce, considere cuidadosamente e documente todas as Ações atribuídas ao agente. Para cada Ação, você deve entender:

• Quais dados as Ações podem acessar.
• Em qual contexto de segurança as Ações são executadas.
• Se as Ações têm recuperação do Knowledge ou outros recursos que podem incorporar dados confidenciais ou restritos na sessão do agente.

Para configurar o compartilhamento e a visibilidade efetivos no Salesforce:

• Projete acesso em torno de funções de trabalho significativas. Crie uma matriz de segurança que mapeie suas personas de usuário para as funções de negócios que eles devem executar. Use esse modelo como base para projetar seu compartilhamento e visibilidade. Para obter mais informações sobre a identificação de funções de negócios significativas, consulte Unidades funcionais.
• Escolha o caminho mais simples para aplicar o princípio do privilégio mínimo. Ao aplicar o princípio do privilégio mínimo ao projetar esquemas de compartilhamento e visibilidade, faça-o da maneira mais simples possível. Evite restrições de dados e esquemas de compartilhamento excessivamente projetados, que podem causar problemas a jusante na capacidade de manutenção, escalabilidade e adaptabilidade do sistema. Em vez disso, aproveite o compartilhamento de dados em camadas flexível no Salesforce para configurar regras detalhadas para acesso do usuário no nível de dados.
• Definir padrões internos para toda a organização (OWDs) como Somente leitura pública, a menos que sua empresa trate de dados confidenciais, use Privado. Os OWDs controlam o nível de privilégio "menos" que os usuários terão no nível de dados. Não é possível restringir o acesso abaixo do nível da OWD. Embora OWDs privados possam parecer ideais em todos os casos de uso, os usuários de negócios muitas vezes podem replicar inadvertidamente um OWD mais permissivo por meio de esquemas de compartilhamento complexos. Além disso, OWDs privados podem fazer com que os usuários criem dados duplicados. Cálculos de compartilhamento (e recálculos recalculatórios) podem levar um tempo significativo para serem concluídos, dependendo do volume de dados e da discrepância entre pai e filho ou propriedade – OWDs privadas exacerbam isso. É importante observar que os OWDs não controlam as permissões CRUD e a visibilidade em nível de campo. Escolha apenas um OWD de Privado quando for justificado por necessidades de negócios — na maioria das vezes, essas justificativas estarão relacionadas à conformidade.
• Definir padrões de toda a organização (OWDs) externos como Privados, a menos que você tenha um motivo comercial convincente para permitir maior acesso. Os OWDs externos se aplicam a usuários que acessam dados do Salesforce de sites, portais e assim por diante do Experience Cloud. Isso permite que você configure linhas de base de OWD separadas para usuários internos e externos, para permitir diferentes tipos de privilégio "menos". Sempre defina o OWD para usuários externos como Privado. As exceções para um nível mais aberto devem ser claramente justificadas pelas necessidades de negócios.

A lista de padrões e antipadrões abaixo mostra o compartilhamento e a visibilidade adequados (e ruins) em uma organização do Salesforce. Use-os para validar seus designs antes de criar ou identificar oportunidades para melhorias adicionais.

Para saber mais sobre ferramentas de compartilhamento e visibilidade do Salesforce, consulte Ferramentas relevantes para segurança.

A criptografia converte dados legíveis em um formato codificado indeciferível. Os dados criptografados podem ser descriptografados ou traduzidos de volta para sua forma original por meio de uma chave. Como resultado, a criptografia está entre os métodos mais eficazes para proteger dados em repouso e em trânsito, garantindo que, mesmo que partes não autorizadas acessem os dados, eles não serão legíveis.

Para projetar o uso adequado da criptografia em suas soluções do Salesforce:

• Sempre criptografe adequadamente os dados em trânsito. O Salesforce utiliza a Segurança de camada de transporte (TLS) para todas as sessões que ocorrem em um navegador compatível com o Salesforce e exige que as chamadas de saída usando HTTPS atendam a padrões de segurança específicos. As APIs da plataforma também usam HTTPS por padrão. Além disso, os dados enviados entre um site do Salesforce Experience Cloud ou um portal e sua organização do Salesforce relacionada são criptografados em trânsito por padrão. Se você usa os serviços de email integrados do Salesforce, há níveis padrão para a Segurança de camada de transporte (TLS) que o Salesforce usa para enviar e tentar entregar emails. Você deve, no mínimo, garantir que as configurações da organização não sejam inferiores às configurações padrão, a menos que tenha uma justificativa comercial clara. Com base na classificação e na confidencialidade dos seus dados, considere aproveitar uma conexão de rede privada com o Salesforce por meio do AWS Direct Connect ou do Salesforce Private Connect. Isso garante que seus dados não passem pela Internet pública, mas fluam com segurança por uma conexão de rede privada para acesso de usuário e integrações.
• Se a empresa o exigir, criptografe dados em repouso. O Salesforce oferece diferentes maneiras de criptografar dados em repouso.
  • Hyperforce. Os dados são criptografados em repouso em organizações que usam o Hyperforce. A criptografia é gerenciada para a sua organização pelo Salesforce. Você não pode criar (ou destruir) suas próprias chaves de criptografia.
  • Salesforce Shield. O Salesforce Shield permite criptografar dados em repouso em uma organização do Salesforce em camadas adicionais, incluindo as camadas de aplicativo e banco de dados. Com o Shield, você tem recursos de gerenciamento completos para as chaves de criptografia do seu locatário, incluindo opções robustas de "Traga sua própria chave" (BYOK). Você também pode criptografar dados não estruturados (incluindo arquivos, anexos, índices de pesquisa e eventos). As instâncias baseadas no Hyperforce oferecem a opção de usar um gerenciador de chaves externo, permitindo que você traga seu próprio AWS KMS. Com esse recurso, você mantém o controle total sobre as chaves de criptografia no KMS que são usadas para criptografar e descriptografar os dados armazenados no Salesforce, reforçando a segurança e alinhando-as aos requisitos de conformidade da sua organização.

A lista de padrões e antipadrões abaixo mostra o uso adequado (e ruim) da criptografia em uma organização do Salesforce. Use-os para validar seus designs antes de criar ou identificar oportunidades para melhorias adicionais.

Para saber mais sobre as ferramentas de criptografia disponíveis no Salesforce, consulte Ferramentas relevantes para segurança.

Esta tabela mostra uma seleção de padrões para procurar (ou criar) em sua organização e antipadrões para evitar ou direcionar para remediação.

✨ Descubra mais padrões para segurança de dados no Padrão & Anti-Padrão Explorador.

Ajude-nos a manter o Salesforce Well-Architected relevante para você; faça nossa pesquisa para fornecer feedback sobre esse conteúdo e diga-nos o que você gostaria de ver em seguida.