Login único (SSO) e 2FA: como proteger os sistemas da empresa

A analista do financeiro pediu demissão na sexta-feira. O RH desativou o e-mail dela na segunda, a TI bloqueou o computador na terça, e três semanas depois alguém percebe que o login dela no sistema de gestão, no portal do banco e no painel do e-commerce continua ativo. Ninguém lembrava que ela tinha acesso a esses lugares, e a senha era a mesma em todos.

A cena se repete com variações: a mesma senha usada num site de compras que vazou, a senha num papel colado no monitor, o fornecedor que ainda entra no portal com o usuário genérico criado "só para aquela semana".

Duas medidas resolvem a maior parte disso: login único (SSO), para que cada pessoa tenha uma identidade só, controlada num lugar só, e autenticação em dois fatores (2FA), para que uma senha vazada não baste para entrar. Este texto explica as duas em linguagem de gestão e mostra o que um sistema, novo ou existente, precisa suportar para adotá-las.

A resposta curta: o que é SSO, o que é 2FA e por que usar os dois

Login único (SSO, de single sign-on) significa que o colaborador entra uma vez, com a conta corporativa que a empresa já administra (normalmente Microsoft 365 ou Google Workspace), e os demais sistemas confiam nessa identidade. O sistema de gestão, o portal do colaborador e o painel de BI deixam de guardar senhas próprias e passam a perguntar ao provedor de identidade "quem é essa pessoa e ela ainda está ativa?".

Autenticação em dois fatores (2FA) exige, além da senha, uma segunda prova: um código de aplicativo no celular, uma confirmação por notificação ou uma chave de segurança. Quem roubou a senha não tem o segundo fator.

Os dois se completam:

• SSO concentra o controle. Uma política de senha, um lugar para ativar o 2FA, um botão para desligar o acesso.
• 2FA protege a porta concentrada. Se tudo depende de uma conta, essa conta precisa ser difícil de invadir.

SSO sem 2FA cria um ponto único de falha. 2FA sem SSO obriga o usuário a configurar o segundo fator em cada sistema, e a adesão cai. A combinação certa é SSO com 2FA exigido no provedor de identidade, e o sistema da empresa recebendo a pessoa já autenticada.

Senhas fracas e reaproveitadas: a porta de entrada

Boa parte dos acessos indevidos a sistemas empresariais não começa com uma invasão técnica sofisticada. Começa com uma senha válida nas mãos erradas. Os caminhos mais comuns:

• Reaproveitamento. O colaborador usa a mesma senha no sistema da empresa e num serviço pessoal. Quando o serviço pessoal vaza, alguém testa a combinação de e-mail e senha em outros lugares.
• Phishing. Um e-mail imitando o banco, a contabilidade ou o próprio sistema leva a uma tela de login falsa.
• Senha compartilhada. O usuário "estoque" ou "caixa" que cinco pessoas usam. Ninguém sabe quem fez o quê, e ninguém troca a senha quando alguém sai.

Política de senha mais rígida, sozinha, piora o problema: quanto mais complexa e frequente a troca, mais a pessoa anota ou reaproveita. A saída é reduzir o número de senhas que cada pessoa precisa ter e tornar a senha insuficiente para entrar.

Senha compartilhada merece atenção especial, porque ela anula qualquer trilha de auditoria. Se você ainda não tem perfis por função e registro de quem fez cada ação, vale ler antes como montar perfis de acesso e trilha de auditoria. SSO resolve quem é a pessoa; perfis resolvem o que ela pode fazer.

Autenticação em dois fatores: opções e usabilidade

Nem todo segundo fator protege igual, e nem todo é igualmente prático. A escolha depende de quem vai usar e de onde.

Alguns cuidados de usabilidade decidem se o 2FA vai ser adotado ou contornado:

• Não peça o segundo fator a cada clique. Peça no login e em ações sensíveis (alterar dados bancários de fornecedor, aprovar pagamento, exportar base de clientes). Dispositivos já confiáveis podem ficar lembrados por um período definido.
• Tenha um caminho de recuperação que não seja o ponto fraco. Se perder o celular faz o suporte desativar o 2FA por telefone sem verificar nada, o atacante liga para o suporte.
• Cuidado com notificação de "aprovar" sem contexto. Usuários cansados de alertas aprovam o que aparece. Exigir que digitem o número exibido na tela reduz esse risco.
• Pense em quem não tem celular corporativo. Operador de chão de fábrica ou de balcão pode precisar de chave física ou de um posto de trabalho com regra própria.

Login único com Microsoft ou Google

Na maioria das empresas brasileiras de pequeno e médio porte, o provedor de identidade já existe e está pago: é a conta do Microsoft 365 (cujo diretório hoje se chama Microsoft Entra ID) ou do Google Workspace. O colaborador já entra no e-mail com essa conta, muitas vezes com 2FA ativado. O SSO aproveita esse cadastro em vez de criar outro.

Tecnicamente, o sistema da empresa conversa com o provedor por um protocolo padrão. Os dois que importam:

• OpenID Connect (OIDC). Construído sobre o OAuth 2.0, é o padrão mais usado em aplicações web e mobile recentes. O usuário é redirecionado para a tela de login da Microsoft ou do Google e volta ao sistema com um token assinado que diz quem ele é.
• SAML 2.0. Mais antigo, baseado em XML, comum em sistemas corporativos e exigido por alguns clientes grandes. Faz o mesmo papel com outro formato.

Para o gestor, a regra prática é: um sistema novo deve suportar OIDC, e SAML se houver chance de clientes corporativos exigirem. Quem implementa precisa validar a assinatura do token, conferir o emissor e o público a que ele se destina, e nunca aceitar o e-mail informado pelo usuário como prova de identidade.

Há também uma decisão de autorização: o provedor diz quem a pessoa é, mas quem decide o que ela pode fazer? Duas abordagens comuns:

• Perfis no próprio sistema, vinculados ao usuário que chega pelo SSO. Mais flexível para regras de negócio finas.
• Grupos do diretório (por exemplo, "Financeiro" ou "Compras" no Entra ID ou no Google) que o sistema traduz em perfis. Mais simples de administrar: mudar a pessoa de grupo muda o acesso em todos os sistemas.

Muitas vezes o melhor é combinar: o grupo define o perfil base, e o sistema guarda exceções e limites (alçada de aprovação, filiais visíveis).

Desligamento do funcionário em um clique

Esse é o ganho que mais aparece no dia a dia. Sem SSO, desligar alguém exige lembrar de cada sistema em que a pessoa tinha conta. Com SSO, desativar a conta corporativa impede novos logins em todos os sistemas integrados.

Há três detalhes que separam o "em teoria" do "na prática":

1. Sessões já abertas. Desativar a conta impede o próximo login, mas uma sessão aberta pode continuar válida até expirar. O sistema precisa ter sessões de duração razoável e, de preferência, consultar o provedor periodicamente ou aceitar um aviso de revogação.
2. Provisionamento automático. O padrão SCIM permite que o provedor de identidade crie, altere e desative usuários nos sistemas automaticamente. O suporte a SCIM para aplicações próprias varia de provedor para provedor e de plano para plano, então confirme antes de contar com ele. Sem ele, o usuário é criado no primeiro login, mas a desativação depende de o sistema perceber que a conta sumiu.
3. Acessos fora do SSO. Tokens de integração, chaves de API e usuários técnicos criados em nome da pessoa continuam funcionando depois que ela sai. Eles precisam ter dono, validade e inventário. O artigo sobre erros comuns de segurança em APIs trata de tokens sem expiração e de revogação.

O desligamento ideal vira uma rotina do RH: a data de saída dispara a desativação da conta corporativa, e o resto acompanha. A trilha de auditoria registra quando cada acesso foi encerrado, o que também ajuda a demonstrar o controle sobre quem acessa dados pessoais, parte das medidas de segurança que a LGPD exige de quem trata esses dados.

Acessos de clientes e parceiros

SSO corporativo resolve a equipe interna. Clientes, fornecedores, representantes e contadores externos não estão no seu diretório, e não devem estar. Ferramentas como Keycloak e Auth0 ajudam aqui, como comparamos em Keycloak, Auth0 ou login próprio. Para eles, as opções são:

• Contas próprias do sistema com 2FA, para portais de cliente e de fornecedor. O cadastro precisa de convite com validade, confirmação de e-mail e, de preferência, aplicativo autenticador como segundo fator.
• Login com a conta do próprio parceiro. Quando o cliente é uma empresa que também usa Microsoft ou Google, o sistema pode aceitar o provedor dele (federação). Ele administra quem da equipe dele entra, e você define o que essa empresa pode ver.

Dois cuidados valem para todos os externos: todo acesso tem prazo (contrato encerrado, acesso encerrado) e todo acesso é revisado periodicamente por alguém interno que responde pela relação.

Para a equipe interna, um bom ponto de partida é concentrar a entrada num lugar só. Um portal do colaborador ou intranet com SSO vira a porta de acesso a comunicados, documentos e atalhos para os demais sistemas, todos com a mesma identidade.

O que exigir de um sistema novo

Ao contratar ou especificar um sistema sob medida, inclua estes itens no escopo. Eles custam pouco no início e muito para adaptar depois.

• Login por OpenID Connect com Microsoft Entra ID e Google Workspace, e SAML 2.0 se houver clientes corporativos.
• Possibilidade de desligar o login por senha local para usuários internos, deixando só o SSO.
• 2FA nativo (aplicativo autenticador, e chave de segurança ou passkey para perfis críticos) para quem não entra por SSO.
• Segundo fator em ações sensíveis, configurável por perfil.
• Mapeamento de grupos do diretório para perfis do sistema.
• Provisionamento por SCIM ou, no mínimo, rotina que desativa usuários ausentes no diretório.
• Sessões com expiração definida e revogação imediata pelo administrador.
• Usuários técnicos e tokens de integração com dono, validade e lista de permissões.
• Trilha de auditoria de logins, falhas, mudanças de perfil e desativações.
• Bloqueio após tentativas falhas e alerta para login de local ou dispositivo incomum.
• Nenhum usuário genérico compartilhado: cada pessoa, um login.

Se o sistema atual não atende a boa parte da lista, isso não obriga a trocá-lo. Muitas vezes dá para colocar uma camada de autenticação na frente dele ou adaptar o módulo de login, sem mexer no resto.

Implantando sem travar a operação

Ligar SSO e 2FA para todo mundo numa segunda-feira de manhã é a receita para o suporte parar. Um roteiro mais seguro:

1. Inventário. Liste os sistemas, quem acessa cada um, como é o login hoje e quais têm usuários genéricos.
2. Arrume a casa no provedor de identidade. Contas sem uso desativadas, grupos por função criados, 2FA exigido na conta corporativa.
3. Comece por um grupo piloto que usa os sistemas todo dia e tem paciência para reportar problemas, como TI e administrativo.
4. Rode SSO e senha local em paralelo por um período curto, com data marcada para desligar a senha local.
5. Comunique antes: o que muda, por que, como configurar o aplicativo autenticador e a quem pedir ajuda.
6. Prepare a recuperação: o procedimento para quem perdeu o celular, com verificação de identidade.
7. Elimine os usuários genéricos, um por um, com login individual para cada pessoa.
8. Expanda por área e só então desligue de vez o login por senha local para internos.
9. Revise acessos periodicamente, especialmente de externos e de perfis administrativos.

O prazo depende do número de sistemas e de quanto cada um precisa ser adaptado; só o inventário dá uma estimativa honesta.

Perguntas frequentes

Pequena empresa precisa de login único e autenticação em dois fatores?

Sim, e costuma ser a que mais ganha, porque raramente tem alguém dedicado a controlar acessos. Se a empresa já usa Microsoft 365 ou Google Workspace, o provedor de identidade já está pago, e o login único aproveita esse cadastro. A autenticação em dois fatores exigida na conta corporativa protege de uma vez todos os sistemas integrados.

Código por SMS é seguro como segundo fator?

Código por SMS é melhor do que só senha, mas é a opção mais fraca entre os segundos fatores comuns, porque fica vulnerável à troca fraudulenta de chip e a páginas falsas. Para equipes internas, aplicativo autenticador é um padrão razoável. Para administradores e para quem aprova pagamentos, chave de segurança ou passkey protege melhor.

Qual a diferença entre OpenID Connect e SAML?

Os dois protocolos fazem o mesmo papel: o sistema passa a confiar na identidade confirmada pelo provedor, como Microsoft ou Google. O OpenID Connect é mais recente, construído sobre o OAuth 2.0, e é o mais usado em aplicações web e mobile. O SAML 2.0 é mais antigo, baseado em XML, e ainda exigido por alguns clientes corporativos grandes.

Dá para colocar login único num sistema antigo?

Depende de como o sistema foi construído, mas raramente é preciso trocá-lo inteiro. Muitas vezes dá para colocar uma camada de autenticação na frente do sistema antigo ou adaptar apenas o módulo de login para aceitar OpenID Connect. O mesmo trabalho costuma eliminar os usuários genéricos compartilhados e criar uma trilha de auditoria dos acessos.

O que acontece com quem está logado quando a conta corporativa é desativada?

Desativar a conta corporativa impede novos logins, mas uma sessão já aberta pode continuar válida até expirar. Por isso o sistema precisa de sessões com duração razoável, revogação imediata pelo administrador e, de preferência, consulta periódica ao provedor de identidade. Tokens de integração e chaves de API ligados à pessoa também precisam ser revogados à parte.

Como a Pervian Tech trabalha autenticação

Na Pervian Tech, autenticação é decidida na arquitetura do software, não acrescentada no fim. Começamos entendendo onde estão as identidades da sua empresa (Microsoft, Google ou outro diretório), quem são os usuários externos e quais ações exigem proteção extra. A partir daí, desenhamos o login por SSO, o 2FA, o mapeamento de perfis e a rotina de desligamento junto com o resto do sistema.

Também adaptamos sistemas existentes, com SSO, fim dos usuários compartilhados e trilha de auditoria. Outros temas de proteção de dados estão na categoria Segurança e LGPD.

Cada projeto é sob medida e o investimento é sob consulta, definido depois de um diagnóstico inicial gratuito. Se desligar o acesso de quem saiu ainda depende da memória de alguém, conte como funciona hoje.