Mudanças de segurança em Salesforce estão travando admins solo — o que observar
Bloqueios automáticos por uso de VPN anônima estão deixando administradores únicos sem acesso às próprias orgs — e expondo uma lacuna de governança
As novas políticas de segurança de Salesforce começaram a bloquear administradores legítimos que acessam orgs via VPNs anônimas, criando um problema sério para quem é o único admin de uma org ou sandbox.
O endurecimento era esperado. O fallback, não
Salesforce vem endurecendo a postura de segurança da plataforma após uma sequência ruim de incidentes em 2025. A direção é correta e era previsível. O problema é que parte dessas mudanças começou a derrubar usuários legítimos — especialmente administradores que são o único admin de uma org ou de um sandbox.
O caso mais barulhento envolve o bloqueio automático de sessões originadas a partir de VPNs anônimas — serviços de VPN comerciais voltados ao consumidor final, não soluções corporativas gerenciadas. Quando o sistema identifica esse tipo de conexão, o comportamento relatado pela comunidade tem sido bastante agressivo:
- O usuário é congelado;
- Os tokens OAuth associados são revogados;
- O acesso só retorna após abertura de caso via telefone com o suporte.
Para quem tem uma estrutura razoável de TI, isso é um incômodo gerenciável. Para quem é o único admin de uma org de produção ou de um sandbox, vira um problema sério: não existe um segundo administrador disponível para descongelar o usuário rapidamente, e o tempo de resolução passa a depender inteiramente do canal de suporte.
O que está em jogo tecnicamente
Essa iniciativa faz parte de um pacote maior de mudanças de segurança previsto para 2026, que inclui também ajustes em MFA resistente a phishing e outras políticas de autenticação. Os detalhes de cada item ainda merecem leitura cuidadosa da documentação oficial e validação em sandbox antes de qualquer recomendação fechada para clientes.
O ponto técnico mais importante a entender: o gatilho não é "usar VPN". É usar um IP classificado como anonimizador. Essa distinção importa. Afeta principalmente:
- Admins e devs que trabalham de casa ou em redes públicas com VPN pessoal sempre ligada;
- Consultores que acessam várias orgs de clientes a partir do mesmo notebook;
- Orgs Developer Edition, trial e sandboxes mantidos por uma única pessoa;
- Pipelines e integrações que autenticam via OAuth a partir de IPs considerados anônimos.
Leitura editorial: intenção correta, execução questionável
A intenção de Salesforce é defensável. Depois do que aconteceu em 2025, agir com mão pesada faz sentido do ponto de vista de gestão de risco. O que pesa contra é o desenho do fallback.
Revogar tokens e congelar o usuário sem um caminho self-service de recuperação transfere todo o custo operacional para o cliente e para o suporte. Em orgs com governança madura, isso é absorvível. Em orgs pequenas, com um único admin, vira incidente.
Esse é o ponto que a comunidade está pressionando — e com razão. O volume de reclamações sugere que há boa chance de Salesforce ajustar o comportamento do bloqueio nas próximas semanas. Vale acompanhar a IdeaExchange e os comunicados oficiais.
O que dá para fazer agora
Enquanto o comportamento não estabiliza, algumas medidas práticas já cabem em qualquer projeto:
- Garanta no mínimo dois usuários com perfil System Administrator ativos em toda org — incluindo sandboxes de longa duração. Isso não é paranoia, é governança básica.
- Documente um "admin reserva" no runbook do cliente, com credenciais e MFA devidamente configurados e testados.
- Evite logar em orgs onde você é o único admin com VPN anônima ativa, até que o comportamento esteja completamente mapeado.
- Trate sandbox como ambiente descartável: metadados devem viver em Git, não no próprio sandbox. Se o sandbox travar, o problema precisa ser apenas de acesso, não de perda de trabalho.
- Audite integrações OAuth críticas e mapeie de onde os tokens são gerados — para entender a exposição real a uma eventual revogação em massa.
Não é uma mudança que exige pânico. Mas exige atenção e, principalmente, exige que você não seja o único ponto de falha na administração de nenhuma org que importe.
O endurecimento da segurança era necessário, mas o desenho do bloqueio cria risco operacional real em orgs com um único administrador, que são muito mais comuns do que se imagina em pequenos e médios clientes. Isso força uma conversa de governança que muitos projetos vinham adiando: redundância de admins, gestão de identidade, ambientes descartáveis e versionamento de metadados. Para consultores e arquitetos, é uma oportunidade clara de revisar runbooks com clientes antes que o problema aconteça em produção.
A direção de segurança do Salesforce está correta. MFA, bloqueio de IPs anônimos, restrição de sessões via VPN — tudo isso faz sentido em ambientes corporativos com times de TI, políticas de rede documentadas e um plano de contingência para quando alguém perde acesso.
O problema não é a intenção. É o fallback.
Quando um admin solo, responsável único por uma org de produção, cai em um bloqueio automático por usar VPN num aeroporto ou home office — e não tem um segundo administrador cadastrado, nem um processo de recuperação definido — o Salesforce não entregou uma camada de segurança. Entregou um ponto único de falha com cara de proteção.
Isso é um problema de design de governança, não de política de segurança. E a lacuna existe porque boa parte das implementações — especialmente em PMEs e orgs departamentais — nunca foram estruturadas para ter redundância administrativa. Ninguém planejou para esse cenário porque o próprio ciclo de venda e implantação raramente inclui essa conversa.
O que eu recomendo a qualquer arquiteto ou admin que leia isso: antes de qualquer outra coisa, verifique se sua org tem ao menos dois System Administrators ativos com métodos de MFA distintos. Documente o processo de recuperação de acesso. Se você é o único admin, você não tem governança — você tem dependência.
O Salesforce vai continuar endurecendo o modelo de segurança ao longo do roadmap de 2026. Isso é fato. Quem não estruturar o básico de resiliência administrativa vai continuar sendo pego de surpresa — e vai chamar de bug o que é, na verdade, consequência de uma arquitetura incompleta.
Garanta pelo menos dois System Administrators ativos em toda org e sandbox. Documente um admin reserva no runbook do cliente. Evite logar em orgs onde você é o único admin usando VPN anônima até o comportamento estar claro. Mantenha metadados versionados em Git, nunca apenas no sandbox. Revise integrações OAuth críticas e mapeie a origem dos tokens para antecipar impactos de revogação. Acompanhe a documentação oficial e a IdeaExchange para mudanças no comportamento do bloqueio.
O gatilho do bloqueio é o uso de IPs classificados como anonimizadores, não VPN em geral — VPNs corporativas tendem a não ser afetadas, mas isso deve ser confirmado caso a caso. O processo de recuperação relatado pela comunidade envolve abertura de caso por telefone, o que pode levar horas. Em orgs com um único admin, o risco operacional é alto. Detalhes específicos do comportamento ainda podem mudar conforme Salesforce responde ao feedback público, então evite tratar qualquer mitigação como definitiva sem validar na documentação oficial e em um sandbox controlado.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.