Gerenciamento de identidade e acesso – Padrões

Saiba mais sobre Well-Architected Trust → Gerenciamento de identidade e acesso

Padrões

Onde procurar	Qual é a boa aparência
Plataforma \| Arquitetura	✅ Controles de acesso verificam a identidade explicitamente em cada solicitação, independentemente do local ou dispositivo de rede
Plataforma \| Arquitetura	✅ Controles de segurança baseados em identidade substituem pressuposições de Trust baseadas em rede
Plataforma \| Organização	✅ As decisões de acesso consideram quem está solicitando acesso (autenticação), o que ele está autorizado a fazer (autorização) e o contexto (dispositivo, local)
Plataforma \| Documentação	✅ A arquitetura de segurança documenta a identidade como o limite principal do Trust, não o perímetro da rede

Anti-Padrões

Onde procurar	Qual é a aparência ruim
Plataforma \| Arquitetura	⚡️ Presume-se que os usuários na rede corporativa ou na VPN sejam confiáveis e recebam acesso mais amplo com base apenas na posição da rede
Plataforma \| Arquitetura	⚡️ Os controles de acesso dependem do perímetro de rede em vez de da verificação de identidade
Plataforma \| Organização	⚡️ As decisões de acesso não consideram sinais de contexto (dispositivo, local, hora, padrões de comportamento)
Plataforma \| Documentação	A arquitetura de segurança trata a localização da rede como o limite principal Trust

Padrões

Onde procurar	Qual é a boa aparência
Plataforma \| Organização	✅ As soluções aproveitam todas as quatro camadas de acesso do Salesforce: Organização (licenças, recursos), Objeto (CRUD), Campo (FLS), Registro (compartilhamento)
Plataforma \| Organização	✅ O modelo de acesso é projetado de cima para baixo (org → object → field → record) e validado de baixo para cima
Plataforma \| Organização	✅ Os padrões para toda a organização (OWD) são definidos como Privados para objetos que contêm dados confidenciais
Plataforma \| Organização	✅ OWDs definidos como Somente leitura pública estão limitados a objetos de referência (produtos, catálogos de preços) em que uma visibilidade ampla dá suporte aos negócios sem expor risco
Plataforma \| Organização	✅ Restrições no nível da organização (licenças, intervalos de IP, horas de login, permissões de recurso) definem os recursos de linha de base para as populações de usuários
Plataforma \| Organização	✅ Permissões de objeto (por meio de perfis e conjuntos de permissões) controlam o acesso para criar, ler, editar e excluir cada objeto para segmentos de usuário
Plataforma \| Organização	✅ A segurança em nível de campo protege campos confidenciais mesmo quando o acesso ao objeto é concedido
Plataforma \| Organização	✅ O compartilhamento em nível de registro usa hierarquia de papéis e regras de compartilhamento com base em requisitos de negócios documentados
Plataforma \| Organização	✅ O acesso é expandido deliberadamente da linha de base restritiva, não restrito após padrões permissivos

Anti-Padrões

Onde procurar	Qual é a aparência ruim
Plataforma \| Organização	⚡️ O modelo de acesso não utiliza todas as quatro camadas (organização, objeto, campo, registro)
Plataforma \| Organização	⚡️ OWDs são definidos como Leitura/Gravação pública para conveniência durante o desenvolvimento sem planos de restrição
Plataforma \| Organização	OWDs de permissão excessiva definidos cedo tornam-se exponencialmente mais difíceis de restringir à medida que o volume de dados aumenta e os processos de negócios cristalizam
Plataforma \| Organização	⚡️ A segurança em nível de campo não está configurada, dependendo apenas de controles de acesso em nível de objeto ou registro

Padrões

Onde procurar	Qual é a boa aparência
Plataforma \| Organização	✅ A autenticação multifator (MFA) é imposta para todos os usuários que acessam ambientes de produção (obrigatório para acesso à IU)
Plataforma \| Organização	✅ A MFA é estendida a operações privilegiadas, incluindo exportações de dados em massa, alterações de permissão e configuração administrativa
Plataforma \| Organização	✅ Single Sign On (SSO) usa protocolos SAML 2.0 ou OpenID Connect
Plataforma \| Organização	✅ O tempo limite da sessão está configurado adequadamente: 2 horas para usuários padrão, 15 a 30 minutos para administradores e usuários que acessam dados restritos
Plataforma \| Organização	✅ Restrições de IP são aplicadas para perfis administrativos e usuários de integração
Plataforma \| Organização	✅ Horas de login restringem contas de serviço a janelas operacionais esperadas
Plataforma \| Organização	✅ A ativação nativa do dispositivo verifica logins de dispositivos não reconhecidos; restrições de MFA e IP adicionam proteção para contas de alto privilégio
Plataforma \| Organização	✅ Se o SSO estiver habilitado, os usuários administradores aprovados terão acesso de login direto (procedimentos de transparência)
Plataforma \| Organização	✅ O relacionamento entre usuários e entidades que fazem login no Salesforce é de 1:1 (nenhuma conta de usuário compartilhada)
Plataforma \| Organização	✅ O Controle de acesso à API impede que os usuários façam a autenticação por meio de aplicativos conectados não autorizados
Plataforma \| Credenciais nomeadas	✅ Credenciais nomeadas e credenciais externas gerenciam a autenticação centralmente com recursos de rotação
Plataforma \| Credenciais nomeadas	✅ Credenciais nomeadas abstraem detalhes de autenticação do código, habilitando atualizações de credenciais sem alterações de código
Plataforma \| Credenciais nomeadas	✅ As credenciais nunca são integradas a códigos, arquivos de configuração ou controle de versão
Plataforma \| Apex	✅ Métodos que executam autenticação usam credenciais nomeadas para lidar com fluxos de nome de usuário/senha
Plataforma \| Apex	✅ Nenhum nome de usuário ou senha aparece em código em formatos legíveis (nenhum valor ou string embutido em código)
Plataforma \| Aura	✅ Métodos que executam autenticação usam credenciais nomeadas para lidar com fluxos de nome de usuário/senha
Plataforma \| Aura	✅ Nenhum nome de usuário ou senha aparece em código em formatos legíveis
Plataforma \| Componentes da Web Lightning (LWC)	✅ Métodos que executam autenticação usam credenciais nomeadas
Plataforma \| Componentes da Web Lightning (LWC)	✅ Nenhum nome de usuário ou senha aparece no código
Integração \| API	✅ O fluxo do portador JWT do OAuth 2.0 é usado para integrações entre servidores em ambientes confiáveis (preferencial para integrações de produção)
Integração \| API	✅ O fluxo de servidor da Web OAuth 2.0 é usado para integrações entre servidores que exigem contexto do usuário
Integração \| API	✅ O fluxo de dispositivo OAuth 2.0 é usado para dispositivos autônomos; as ferramentas CLI e CI/CD usam fluxo de servidor da Web (`sf org login web`) ou fluxo portador JWT (`sf org login jwt`) — o fluxo de dispositivo foi bloqueado para o aplicativo conectado padrão Salesforce CLI a partir de 28 de agosto de 2025
Integração \| API	✅ O fluxo do OAuth de nome de usuário e senha não é usado; as integrações existentes que dependem dele são migradas para o fluxo de credenciais do cliente ou portador JWT

Anti-Padrões

Onde procurar	Qual é a aparência ruim
Plataforma \| Organização	MFA não é aplicada para acesso ao ambiente de produção
Plataforma \| Organização	⚡️ As configurações de login não estão alinhadas aos requisitos de MFA do Salesforce
Plataforma \| Organização	A MFA não é estendida a operações privilegiadas (exportações em massa, alterações de permissão, configuração administrativa)
Plataforma \| Organização	O tempo limite da sessão não está configurado ou é excessivamente permissivo (>24 horas)
Plataforma \| Organização	Políticas de sessão não diferenciam usuários padrão e administradores/usuários que acessam dados restritos
Plataforma \| Organização	As restrições de IP não são aplicadas a perfis administrativos e usuários de integração
Plataforma \| Organização	⚡️ As contas de serviço não têm horários de login restritos às janelas operacionais esperadas
Plataforma \| Organização	Contas de alto privilégio dependem apenas da ativação do dispositivo, sem restrições de MFA ou IP adicionadas
Plataforma \| Organização	⚡️ Se o SSO estiver habilitado, nenhum usuário administrador aprovado terá acesso de login direto (sem procedimentos de transparência)
Plataforma \| Organização	⚡️ O relacionamento entre usuários e entidades não é 1:1 (existem contas de usuário compartilhadas)
Plataforma \| Organização	⚡️ O Controle de acesso à API não está habilitado
Plataforma \| Credenciais nomeadas	As credenciais são integradas diretamente a códigos, arquivos de configuração ou controle de versão
Plataforma \| Apex	Nomes de usuário e senhas aparecem em código em formatos legíveis
Plataforma \| Apex	A autenticação é tratada ad hoc sem implementação consistente
Plataforma \| Aura	A autenticação é processada ad hoc sem credenciais nomeadas
Plataforma \| Aura	⚡️ Nomes de usuário e senhas aparecem em código
Plataforma \| Componentes da Web Lightning (LWC)	A autenticação é processada ad hoc sem credenciais nomeadas
Plataforma \| Componentes da Web Lightning (LWC)	⚡️ Nomes de usuário e senhas aparecem em código
Plataforma \| Negócios	⚡️ SLAs e requisitos de provisionamento de usuários e desprovisionamento não existem
Integração \| API	Fluxo de OAuth de nome de usuário e senha é usado quando fluxos de OAuth mais seguros estão disponíveis
Integração \| API	⚡️ Escopos do OAuth são excessivamente permissivos (acesso total quando o escopo limitado é suficiente)
Integração \| API	⚡️ As credenciais do cliente (ID do cliente, segredo do cliente) são armazenadas de modo inseguro em arquivos de código ou configuração

Padrões

Onde procurar	Qual é a boa aparência
Plataforma \| Organização	✅ A profundidade da hierarquia de papéis é de 5 a 7 níveis no máximo (evitando sobrecarga de desempenho e complexidade de solução de problemas)
Plataforma \| Organização	✅ Conjuntos de permissões e grupos de conjuntos de permissões fornecem acesso flexível e complementar sem proliferação de perfil
Plataforma \| Organização	✅ Conjuntos de permissões concedem acesso a funções de trabalho específicas, solicitações ou privilégios elevados temporários
Plataforma \| Organização	✅ Grupos de conjuntos de permissões combinam conjuntos de permissões relacionados com recursos de silenciamento para exceções
Plataforma \| Organização	✅ Todo o acesso funcional é concedido por meio de conjuntos de permissões e grupos de conjuntos de permissões (não perfis), proporcionando flexibilidade conforme os papéis do trabalho evoluem
Plataforma \| Organização	✅ Políticas de segurança da transação estendem a autorização com avaliação contextual em tempo real
Plataforma \| Organização	✅ Políticas de segurança da transação detectam e bloqueiam comportamento anômalo (download de dados em massa que excede padrões, login de geografias inesperadas, alterações de permissão fora das janelas de alteração)
Plataforma \| Organização	✅ As restrições de IP são configuradas para operações altamente confidenciais ou acesso a dados
Plataforma \| Organização	✅ Um usuário de integração somente de API exclusivo é configurado para cada integração
Plataforma \| Apex	✅ Todos os códigos que acessam dados impõem CRUD e FLS usando os métodos WITH USER_MODE, WITH SYSTEM_MODE ou Security.stripInaccessible().
Plataforma \| Apex	✅ Consultas SOQL usam palavras-chave WITH USER_MODE ou WITH SYSTEM_MODE explicitamente com base nos requisitos de negócios
Plataforma \| Apex	✅ As operações DML usam Security.stripInaccessible() para imposição de acesso antes de inserir/atualizar/insert operações
Plataforma \| Apex	✅ As instruções DML do banco de dados declaram o modo do usuário ou do sistema explicitamente para operações de dados
Plataforma \| Apex	✅ Operações de banco de dados usam métodos stripInaccessible() para filtrar resultados de consulta e subconsulta
Plataforma \| Apex	✅ Palavras-chave de compartilhamento (com compartilhamento, sem compartilhamento, compartilhamento herdado) são usadas adequadamente com base nos requisitos de segurança dos negócios
Plataforma \| Padrões de design	✅ Casos de uso para conceder privilégios elevados (Modificar todos os dados, Visualizar todos os dados) são claramente documentados com a justificativa comercial

Anti-Padrões

Onde procurar	Qual é a aparência ruim
Plataforma \| Organização	A hierarquia de papéis é mais profunda que 5 a 7 níveis, criando uma sobrecarga de desempenho em cálculos de compartilhamento e solução de problemas de complexidade
Plataforma \| Organização	A hierarquia de papéis concede acesso amplo sem justificativa comercial
Plataforma \| Organização	Perfis são clonados repetidamente para pequenas variações de permissão, criando dezenas de perfis com distinções obscuras
Plataforma \| Organização	Perfis contêm controles de acesso para metadados (deve usar conjuntos de permissões)
Plataforma \| Organização	Políticas de segurança da transação não são implementadas para detectar comportamento anômalo
Plataforma \| Organização	As restrições de IP não são configuradas para operações altamente confidenciais ou acesso a dados
Plataforma \| Organização	Usuários somente de API não são configurados ou são compartilhados entre várias integrações
Plataforma \| Organização	⚡️ As permissões Visualizar todos os dados ou Modificar todos os dados são concedidas sem justificativa documentada
Plataforma \| Apex	⚡️ Consultas SOQL/SOSL e operações DML são executadas no modo do sistema padrão sem verificações de acesso explícitas
Plataforma \| Apex	⚡️ A imposição de CRUD e FLS é inconsistente ou ausente
Plataforma \| Apex	⚡️ SOQL depende de WITH SECURITY_ENFORCED, que foi removido e agora causa um erro de compilação (substituído por WITH USER_MODE)
Plataforma \| Apex	⚡️ Palavras-chave de compartilhamento são usadas de modo inconsistente ou não são usadas de modo algum
Plataforma \| Padrões de design	⚡️ Os casos de uso para conceder permissões elevadas não são claramente documentados

Padrões

Onde procurar	Qual é a boa aparência
Plataforma \| Data 360	✅ RBAC (papéis, perfis, conjuntos de permissões) controla o acesso à plataforma (quem pode usar o Data 360), ABAC controla o acesso aos dados (que dados eles veem com base em atributos)
Plataforma \| Data 360	✅ Os agentes de IA são executados no contexto do usuário solicitante (em nome dele), portanto, as consultas geradas pelo agente são restritas pelo acesso desse usuário, em vez de serem executadas com acesso no nível do sistema
Plataforma \| Documentação	✅ A taxonomia de classificação de dados é documentada com definições de atributo, regras de imposição e justificativa de negócios

Anti-Padrões

Onde procurar	Qual é a aparência ruim
Plataforma \| Data 360	⚡️ O acesso que deve seguir a classificação de dados é forçado por meio da hierarquia de papéis e do compartilhamento, que não pode expressá-lo, em vez de alcançar o controle de acesso baseado em atributo
Plataforma \| Data 360	⚡️ Desvio de FLS: usuários sem acesso em nível de campo recuperam dados por meio de consultas API ou SOQL que não impõem FLS
Plataforma \| Data 360	⚡️ Os agentes de IA consultam dados sem executar no contexto do usuário responsável pela solicitação; as consultas geradas pelo agente ignoram os controles de acesso em nível de objeto, campo e registro
Plataforma \| Data 360	⚡️ O contexto de execução do agente não inclui atributos de usuário em nome; os agentes operam com acesso no nível do sistema
Plataforma \| Documentação	A taxonomia de classificação de dados não está documentada; as definições de atributo variam conforme a equipe criando uma imposição inconsistente

Padrões

Onde procurar	Qual é a boa aparência
Plataforma \| Organização	✅ Contas de impacto crítico (administradores do sistema, usuários de integração, contas de processo automatizadas) são identificadas e rastreadas no inventário de ativos
Plataforma \| Organização	✅ Contas de impacto crítico representam metas de alto valor devido a privilégios elevados que fornecem acesso amplo à plataforma
Plataforma \| Organização	✅ Chaves de segurança de hardware ou aplicativos autenticadores são necessários para MFA (não SMS, que é vulnerável à troca de SIM)
Plataforma \| Organização	✅ Os intervalos de IP de login são restritos a locais administrativos conhecidos
Plataforma \| Organização	✅ Alertas de login e notificações de alteração de permissão estão habilitados
Plataforma \| Organização	✅ As análises de acesso trimestrais são realizadas com uma atestada documentada
Plataforma \| Organização	✅ Existem procedimentos de detecção de vidro para acesso de emergência com auditoria pós-utilização
Integração \| Contas de serviço	✅ Fluxos OAuth são usados para contas de integração e serviço (nunca nome de usuário e senha)
Integração \| Contas de serviço	✅ Restrições de IP são impostas para usuários de integração
Integração \| Contas de serviço	✅ As agendas de rotação de credenciais são implementadas (trimestral ou por apólice)
Integração \| Contas de serviço	✅ Padrões de uso de API anômalos são monitorados por meio do Monitoramento de evento
Integração \| Contas de serviço	✅ Cada integração tem uma conta de serviço dedicada com o mínimo de permissões necessárias (não compartilhado “usuário de integração” com acesso amplo)
Integração \| Contas de serviço	✅ As contas de serviço aplicam o privilégio mínimo com rigor, pois operam sem supervisão

Anti-Padrões

Onde procurar	Qual é a aparência ruim
Plataforma \| Organização	Contas de impacto crítico (administrador, integração, automação) não são identificadas, rastreadas ou inventariadas
Plataforma \| Organização	⚡️ Os administradores do sistema usam MFA baseada em SMS em vez de chaves de segurança de hardware ou aplicativos autenticadores
Plataforma \| Organização	Contas de impacto crítico não têm restrições de IP ou hora de login
Plataforma \| Organização	⚡️ Nenhum alerta é configurado para alterações de login ou permissão em contas privilegiadas
Plataforma \| Organização	⚡️ O acesso à conta de impacto crítico nunca é revisado ou revisado de modo irregular (não trimestral)
Plataforma \| Organização	⚡️ Não há procedimentos de acesso de emergência
Integração \| Contas de serviço	⚡️ Uma única conta “Usuário da API” é compartilhada entre várias integrações com a permissão Modificar todos os dados
Integração \| Contas de serviço	⚡️ As contas de serviço usam autenticação de nome de usuário e senha quando o OAuth está disponível
Integração \| Contas de serviço	As credenciais da conta de serviço usam senhas estáticas inalteradas por anos (sem rotação)
Integração \| Contas de serviço	⚡️ As contas de serviço têm privilégios excessivos além do que a integração exige
Integração \| Contas de serviço	Padrões de uso de API anômalos para contas de serviço não são monitorados

Padrões

Onde procurar	Qual é a boa aparência
Plataforma \| Processo	✅ O ciclo de vida de identidade inclui: Provisionamento (criar com acesso de linha de base), Ajuste de acesso (conceder/revogar conforme os papéis mudam), Recertificação periódica (validação trimestral), Desprovisionamento (revogação imediata)
Plataforma \| Organização	✅ SCIM (Sistema para gerenciamento de identidade entre domínios) é implementado para provisionamento automatizado de provedores de identidade
Plataforma \| Processo	✅ O provisionamento cria contas com função de trabalho de correspondência de acesso de linha de base, acionada por eventos do sistema de RH
Plataforma \| Processo	✅ O ajuste de acesso concede permissões adicionais à medida que papéis se expandem e revoga permissões quando os papéis mudam
Plataforma \| Processo	✅ A nova certificação periódica ocorre trimestralmente, em que os gerentes revisam e validam o acesso para suas equipes
Plataforma \| Processo	✅ O desprovisionamento revoga o acesso imediatamente quando o emprego termina ou quando o papel não requer mais o Salesforce
Plataforma \| Organização	✅ A detecção automatizada identifica usuários que não fizeram login em 90 dias e aciona fluxos de trabalho de revisão de acesso
Plataforma \| Organização	✅ O provisionamento preciso (JIT) cria usuários automaticamente usando SSO quando apropriado

Anti-Padrões

Onde procurar	Qual é a aparência ruim
Plataforma \| Organização	⚡️ O provisionamento SCIM não é implementado apesar de ter integração do provedor de identidade
Plataforma \| Processo	⚡️ Novos usuários são criados manualmente sem procedimentos de integração padrão
Plataforma \| Processo	⚡️ O acesso inicial do usuário é inconsistente ou baseado em copiar usuários existentes
Plataforma \| Processo	⚡️ Alterações de acesso para alterações de papel ou transferências estão atrasadas ou incompletas
Plataforma \| Processo	⚡️ A desativação está atrasada; os funcionários antigos mantêm o acesso após o encerramento (não a desativação no mesmo dia)
Plataforma \| Organização	⚡️ Não há automação para provisionamento de usuários (apenas criação manual de usuários)
Plataforma \| Processo	⚡️ Não há campanhas de recertificação de acesso (nenhuma revisão trimestral ou anual)
Plataforma \| Processo	⚡️ O acesso desnecessário identificado durante a recertificação não é removido
Plataforma \| Processo	A nova certificação de acesso não é rígida para contas privilegiadas, acesso entre organizações e usuários externos
Plataforma \| Organização	⚡️ Contas dormientes (sem login em mais de 90 dias) se acumulam sem revisão ou desativação