Em 2021, o Governo do Reino Unido tinha cerca de 121 soluções de single sign-on separadas, demonstrando por que razão o SSO é mais do que uma funcionalidade de conveniência. O SSO é a consolidação de identidades federadas: centraliza a autenticação através de um fornecedor de identidade de confiança, enquanto cada aplicação mantém o controlo sobre o que um utilizador autenticado está autorizado a fazer.
Poderá reconhecer o problema no seu dia a dia de trabalho. Um funcionário precisa de aceder ao e-mail, a uma aplicação na nuvem, a um sistema de gestão imobiliária, ao WiFi interno e a um portal de administração. Cada serviço tem o seu próprio início de sessão, política de palavras-passe e responsável de conta. Quando alguém entra, muda de função ou sai da empresa, os administradores têm de atualizar vários sistemas, e os utilizadores têm de se lembrar de quais as credenciais que pertencem a cada serviço.
Essa é a razão prática pela qual as organizações procuram a explicação sobre SSO. A questão não é apenas como reduzir o número de ecrãs de início de sessão. É como criar um plano de controlo de identidade fiável sem enfraquecer as permissões ao nível da aplicação ou introduzir um alvo central mais perigoso.
Por que razão a identidade fragmentada cria problemas reais de acesso
A experiência do Governo do Reino Unido oferece um ponto de partida útil. Uma avaliação do padrão de serviço do GOV.UK em 2021 estimou que o governo central tinha aproximadamente 121 soluções de SSO diferentes porque as equipas de serviço tinham construído sistemas de autenticação separados em vez de utilizarem uma plataforma de identidade partilhada para todo o governo. As pessoas que utilizavam múltiplos serviços públicos podiam, portanto, ter vários conjuntos de dados de início de sessão e podiam não saber qual a conta necessária para uma transação específica. (Avaliação de autenticação e identidade digital do Governo do Reino Unido)
A lição não é que os sistemas governamentais sejam excecionalmente complicados. Grandes empresas, organizações de saúde, grupos hoteleiros, gestores imobiliários e redes do setor público enfrentam o mesmo padrão. Cada aplicação pode criar um silo de identidade e cada silo pode desenvolver as suas próprias regras de palavras-passe, processos de recuperação, modelos de grupo e fluxos de trabalho de desativação de acessos.
Autenticação e autorização são tarefas diferentes
A autenticação responde a: “Quem é você?” A autorização responde a: “Ao que pode aceder aqui?” O SSO consolida a primeira questão através de um fornecedor de identidade de confiança. A aplicação de destino continua a decidir se essa identidade pode ver registos, administrar um sistema, aderir a um segmento de rede ou utilizar uma funcionalidade específica.
Um modelo mental útil é apresentado do seguinte modo:
Utilizador
|
| autentica-se uma vez
v
Fornecedor de identidade
|
| envia informação de identidade fidedigna
v
Aplicação ou rede
|
| aplica permissões locais
v
Sessão autorizada
Esta distinção é importante durante os processos de entrada, mobilidade e saída de colaboradores. Uma identidade central pode ser desativada quando uma pessoa sai, enquanto cada serviço ligado ainda necessita de um modelo de autorização claro e de uma forma fiável de remover permissões.
Regra prática: Trate o SSO como uma forma de controlar a identidade centralmente, e não como um substituto para as permissões da aplicação.
O mesmo princípio aplica-se ao projetar a implantação com e sem fios. O acesso à rede faz parte do ecossistema de identidade, pelo que as equipas devem decidir quais os grupos do diretório que podem aceder a determinados privilégios de rede, em vez de associar o acesso a uma palavra-passe partilhada.
Para o WiFi de colaboradores e acesso com reconhecimento de identidade, a solução de rede baseada em identidade da Purple mostra como a política de rede pode ser ligada à identidade individual em vez de uma credencial comum. O resultado é uma relação mais clara entre uma pessoa, o seu estado no diretório e o acesso que recebe.
Como funciona o Single Sign-On na federação empresarial
Numa federação empresarial, um fornecedor de identidade, uma entidade confiante e uma mensagem de identidade assinada desempenham funções distintas. O fornecedor de identidade autentica o utilizador, enquanto a entidade confiante, como uma aplicação ou serviço de rede, verifica as informações de identidade resultantes.
A autenticação pode utilizar uma palavra-passe, autenticação multifator, condições do dispositivo ou outro método aprovado. O fornecedor emite então uma asserção ou token assinado para o serviço solicitado. O serviço valida essa mensagem e cria a sua própria sessão, garantindo que as credenciais permanecem no fornecedor de identidade.
O fluxo de federação
- O utilizador solicita um serviço. Abre uma aplicação, portal administrativo ou serviço de rede protegido.
- O serviço verifica se existe uma sessão ativa. Caso não exista, redireciona o utilizador para o fornecedor de identidades.
- O fornecedor de identidades autentica o utilizador. Aplica os controlos configurados, tais como MFA ou acesso condicional.
- O fornecedor de identidades emite uma mensagem assinada. A integração utiliza habitualmente uma asserção SAML ou um token OpenID Connect.
- O serviço valida a mensagem. Verifica o emissor, a assinatura, o público-alvo, a expiração e os atributos relevantes.
- A aplicação cria a sua própria sessão. Associa a identidade verificada às permissões locais e regista o evento de autenticação.
A validação protege a relação de confiança. O NCSC (National Cyber Security Centre do Reino Unido) aconselha que as asserções SAML recebidas através de redes não confiáveis devem ser verificadas em relação à autoridade de certificação esperada. Uma asserção não verificada pode criar um caminho para a usurpação de conta através de uma ligação fidedigna com o fornecedor de identidade. (Orientação do NCSC sobre gestão de identidades e acessos)
Uma verificação de identidade válida concede uma identidade autenticada, não todas as permissões no serviço de destino. A aplicação deve consumir apenas as alegações necessárias para a autorização e, em seguida, aplicar as suas próprias regras de função e recursos. Esta separação também permite que o mesmo padrão de federação suporte aplicações de colaboradores, portais administrativos e serviços de rede com reconhecimento de identidade.
SAML, OIDC e OAuth no contexto empresarial
Assim que o modelo de federação estiver claro, a seleção do protocolo torna-se mais simples. O SAML e o OpenID Connect são padrões comuns para SSO empresarial, enquanto o OAuth é primariamente uma estrutura de autorização para acesso delegado a APIs. Confundir o OAuth com autenticação pode levar as equipas a construir um fluxo de identidade que não responde à questão de segurança que possuem.
| Norma | Papel prático | Adequação típica |
|---|---|---|
| SAML | Troca asserções de identidade assinadas | Empresas consolidadas e aplicações baseadas em navegador |
| OpenID Connect | Adiciona uma camada de identidade utilizando tokens | SaaS moderno, serviços orientados para a web e dispositivos móveis |
| OAuth | Delega o acesso a recursos protegidos | Acesso a API em nome de um utilizador ou serviço |
O SAML surge frequentemente em software empresarial maduro porque utiliza um modelo de federação de navegador bem estabelecido. O OIDC é geralmente mais natural para serviços modernos concebidos em torno de JSON, REST e interações baseadas em tokens. A escolha certa depende do que a aplicação suporta e de como o serviço valida as informações de identidade.
O que o serviço deve verificar
Independentemente da norma, a entidade confiante deve validar o material de identidade recebido antes de criar uma sessão. As verificações fundamentais incluem:
- Emissor: Confirme que a mensagem provém do fornecedor de identidade esperado.
- Assinatura: Verifique se a mensagem foi assinada pela chave ou certificado de confiança.
- Público-alvo: Confirme que a mensagem se destinava a este serviço.
- Validade: Rejeite asserções ou tokens expirados.
- Atributos (Claims): Utilize apenas informações de identidade e de grupo relevantes e validadas.
O fornecedor de identidade pode centralizar políticas como MFA, acesso condicional, bloqueio de palavras-passe e pertença a grupos. A aplicação recebe depois as alegações necessárias para a sua própria decisão de autorização, em vez de manter uma cópia completa do processo de autenticação do utilizador.
Essa separação é útil ao integrar plataformas como o Microsoft Entra ID, Okta ou Google Workspace. O fornecedor gere a política de autenticação, enquanto a aplicação ligada permanece responsável pelo seu modelo de acesso e controlos de sessão. Para os operadores de rede que estão a avaliar a integração do Okta para acesso baseado em RADIUS, aplica-se o mesmo princípio: a validação de identidade e a autorização de rede devem funcionar em conjunto, mas não constituem o mesmo controlo.
O risco de concentração que o SSO introduz
Uma única conta comprometida do fornecedor de identidade pode dar acesso a vários serviços ligados em simultâneo. O SSO reduz a proliferação de palavras-passe, enquanto concentra a confiança no fornecedor de identidade, tornando-o num plano de controlo de elevado valor. Como tal, as organizações precisam de avaliar como a federação afeta o seu raio de ação de um ataque e as suas opções de recuperação. A orientação do NCSC sobre a escolha de métodos de autenticação destaca esta concentração de confiança como um risco que exige uma avaliação deliberada.
O SSO consolida os eventos de início de sessão. A resistência a phishing, a confiança no dispositivo e o acesso com privilégios mínimos devem provir dos controlos integrados na arquitetura de federação. Um concetualização sólida protege o fornecedor, as sessões que este cria e os processos de recuperação que podem restaurar o acesso.
Criar camadas em torno do fornecedor
Os controlos devem abranger o início de sessão de rotina e os caminhos menos visíveis utilizados durante a recuperação de conta:
- MFA forte para utilizadores privilegiados: Utilize métodos resistentes a phishing onde o ambiente os suporte, especialmente para administradores.
- Acesso condicional: Avalie o estado do dispositivo, a localização, o risco da sessão e outros sinais disponíveis antes de conceder o acesso.
- Identidades de administrador separadas: Mantenha a administração privilegiada separada da atividade diária comum.
- Monitorização da autenticação: Investigue viagens impossíveis, indicadores de repetição de tokens, falhas repetidas e escalamentos de privilégios inesperados.
- Proteção do restabelecimento: Trate as redefinições da assistência técnica e as contas de emergência como operações de identidade sensíveis, sujeitas a aprovação e monitorização.
O NCSC recomenda a combinação do SSO empresarial com uma autenticação forte de utilizadores e dispositivos, incluindo MFA ou acesso condicional. Também recomenda o SSO para SaaS porque os controlos centralizados tornam a gestão de utilizadores e grupos mais consistente e impedem que as credenciais sejam sincronizadas em todas as aplicações. O seu princípio de segurança na nuvem sobre identidade e autenticação define esta abordagem.
O SSO reduz o número de credenciais que precisa de governar. Deixa a credencial e a sessão que governam os serviços ligados a exigir uma proteção forte.
As equipas de rede devem separar a identidade dos colaboradores da identidade dos convidados. Uma federação de colaboradores pode suportar o acesso com privilégios mínimos e a revogação imediata. A autenticação de convidados não deve herdar os privilégios do diretório de funcionários apenas porque ambos os fluxos utilizam um Captive Portal ou infraestrutura sem fios.
WiFi sem palavra-passe e acesso à rede baseado em diretório
Um funcionário que se liga ao WiFi não deve precisar de uma palavra-passe partilhada que continua válida após a sua saída. Uma arquitetura assente em diretório começa com a autenticação através do fornecedor de identidade da organização e, em seguida, mapeia a identidade ou grupo verificado para uma função de rede. Assim, o serviço sem fios aplica as mesmas decisões de vínculo laboral e de acesso utilizadas noutros locais, em vez de manter uma lista separada de palavras-passe de WiFi.
O Purple suporta este modelo para WiFi empresarial através de integrações com o Microsoft Entra ID, Google Workspace e Okta. A sua abordagem de WiFi sem palavra-passe evita credenciais partilhadas e a gestão de RADIUS no local. As alterações no diretório podem acionar o aprovisionamento ou a revogação. A pertença a um grupo por parte de um colaborador determina o acesso à rede, enquanto a desativação da conta de diretório de um funcionário cessante pode remover esse acesso sem ter de esperar que alguém altere uma palavra-passe comum.
Aplicar controlos de federação à rede
O fornecedor de identidade, a política de rede e a monitorização devem concordar sobre a mesma decisão de acesso. Mapeie grupos de diretório para funções de rede distintas, garantindo que funcionários, prestadores de serviços e administradores não recebem acessos idênticos por predefinição. Mantenha as validades de asserção ou de token curtas, limitando a utilidade de dados de identidade antigos. Exija MFA no fornecedor de identidade, pois o SSO sem fios não se torna MFA apenas por utilizar SSO.
Registe os eventos de autenticação bem-sucedidos e com falhas, e ligue cada decisão de identidade à respetiva autorização de rede. Teste a renovação de certificados antes da sua expiração, uma vez que as falhas de confiança na federação podem interromper o acesso a uma rede WiFi que, de outro modo, estaria operacional.
Os locais multi-inquilino exigem uma fronteira separada. Propriedades residenciais, alojamento estudantil, hotéis e locais de uso misto podem oferecer um acesso simples a residentes ou convidados, isolando ao mesmo tempo o tráfego dos inquilinos e os sistemas dos funcionários. O iPSK pode suportar dispositivos legados, enquanto o SSO para colaboradores fornece um caminho de identidade distinto para a equipa.
O WiFi de convidados também exige decisões sobre consentimento, retenção e perfis de clientes. Este guia de dados de convidados para estabelecimentos fornece uma referência útil juntamente com o design da rede, enquanto a Purple liga a autenticação baseada em identidade com a experiência de acesso sem fios.
Resultados mensuráveis para empresas e espaços no Reino Unido
Um caso de negócio prático para SSO começa com as credenciais que uma organização deixa de precisar de administrar. Um inquérito da Institution of Engineering and Technology de abril de 2024 a 2.000 residentes no Reino Unido com 16 ou mais anos revelou que apenas 20% conseguia identificar corretamente uma palavra-passe segura. O mesmo estudo relatou que um quinto reutilizava a palavra-passe em vários websites ou dispositivos, enquanto 21% utilizava uma data significativa e 20% utilizava o nome de um animal de estimação. Revelou também que 38% acreditava que substituir letras por números melhorava a segurança da palavra-passe, 65% acreditava que as palavras-passe nunca deviam ser anotadas e 77% achava que alterações frequentes de palavra-passe aumentavam a segurança. (Inquérito de segurança de palavras-passe do IET)
Estes resultados mostram os limites de pedir aos utilizadores que criem e memorizem credenciais separadas para cada aplicação e rede. A identidade centralizada altera o local onde a organização aplica os controlos e a rapidez com que os administradores podem agir, embora o phishing e o comprometimento de contas continuem a ser riscos reais.
Para um operador, os resultados são práticos:
- Menos credenciais não geridas: Os utilizadores criam, memorizam e reutilizam menos palavras-passe de aplicações individuais.
- Política coerente: O fornecedor de identidade pode aplicar MFA, acesso condicional e restrições de palavra-passe em todos os serviços ligados.
- Revogação mais rápida: Desativar uma identidade organizacional pode tornar-se a ação central de remoção de acesso, desde que os serviços ligados processem corretamente as alterações do ciclo de vida.
- Pistas de auditoria mais claras: Os registos podem associar a identidade de uma pessoa às decisões de autenticação e autorização de rede.
- Menos administração duplicada: As equipas mantêm a política de identidade de forma centralizada em vez de recriarem controlos equivalentes em cada serviço.
O valor vai além da redução dos pedidos de início de sessão. Um prestador de cuidados de saúde pode atribuir acessos por função, um grupo hoteleiro pode separar os serviços de funcionários e de hóspedes, e um gestor imobiliário pode manter uma titularidade mais clara das permissões de inquilinos e trabalhadores. Em cada caso, o resultado mensurável é uma menor quantidade de credenciais, um processamento de saídas de colaboradores mais fiável e provas mais robustas sobre quem recebeu acesso a uma aplicação ou função de rede.
Implementar SSO sem criar novos riscos
Uma implementação segura começa com o modelo de identidade, não com o botão de início de sessão. Escolha SAML ou OIDC quando se adequarem à aplicação, em vez de copiar palavras-passe para uma aplicação ou plataforma de rede. Estabeleça o fornecedor de identidade como a autoridade de autenticação e, em seguida, faça com que cada serviço ligado valide o emissor, a assinatura, o público, a expiração e as alegações antes de criar uma sessão.
Utilizar uma lista de verificação operacional
- Comece com grupos de autoridade: Aprovisione o acesso a partir de grupos de diretório pertencentes à equipa de negócio ou IT adequada.
- Defina regras de mobilidade interna: Uma alteração de função deve remover privilégios antigos, bem como adicionar novos.
- Processa as saídas centralmente: Desative a identidade organizacional e verifique se as aplicações e funções de rede associadas respondem corretamente.
- Proteja o acesso de emergência: Mantenha as contas de emergência separadas da administração corrente, monitorize-as atentamente e teste o seu processo de recuperação.
- Separe colaboradores de convidados: O SSO de colaboradores pode suportar o acesso de menor privilégio e a revogação de acessos. A autenticação de convidados não deve herdar permissões de funcionários.
- Teste alterações de confiança: Valide a renovação de certificados, expiração de tokens, terminação de sessões e falhas do fornecedor antes da utilização em produção.
- Reveja a monitorização: Confirme que os eventos de autenticação, ações administrativas e decisões de autorização de rede estão disponíveis para investigação.
Um local também pode precisar de suportar vários fornecedores de rede em vez de substituir a sua infraestrutura sem fios existente. O Purple foi concebido para funcionar com a Meraki, Aruba, Ruckus, Mist e UniFi, e o seu modelo de implementação declarado é medido em semanas e não em meses. Trate essas capacidades como considerações de implementação, e não como substitutos para a revisão da arquitetura. Para uma visão mais ampla sobre como os fornecedores de tecnologia descrevem as salvaguardas de segurança, a página de confiança e controlos da AdManage.ai oferece um ponto de comparação útil.
A decisão central é se a organização consegue explicar, para cada serviço ligado, quem autentica o utilizador, quais as alegações confiadas, como as permissões são atribuídas e o que acontece quando a identidade muda. O SSO é uma camada num programa de gestão de identidades e acessos. Não substitui a MFA, o acesso condicional, a monitorização de autenticação, os controlos de recuperação ou a governação do ciclo de vida.
A Purple liga a identidade da força de trabalho ao WiFi sem palavra-passe, funções de rede baseadas em diretório e acesso de convidados separado, suportando integrações com Microsoft Entra ID, Google Workspace e Okta. Visite a Purple para avaliar como o seu modelo de rede baseado em identidade se pode adequar ao seu ambiente sem fios existente e à implementação de SSO.
