Até 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 identidade federada: 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 tem autorização para fazer.
Poderá reconhecer o problema num dia de trabalho normal. Um funcionário precisa de e-mail, de uma aplicação na nuvem, de um sistema de gestão imobiliária, de WiFi interno e de um portal administrativo. Cada serviço tem o seu próprio início de sessão, política de palavras-passe e proprietário de conta. Quando alguém entra, muda de função ou sai, os administradores têm de atualizar vários sistemas e os utilizadores têm de se lembrar de quais credenciais 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 nem 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 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 a nível governamental. Assim, as pessoas que utilizavam múltiplos serviços públicos podiam ter vários conjuntos de dados de início de sessão e podiam não saber qual a conta necessária para uma determinada transação. (Avaliação de autenticação e identidade digital do Governo do Reino Unido)
A lição não é que os sistemas governamentais sejam unicamente complicados. Grandes empresas, organizações de saúde, grupos hoteleiros, operadores 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 palavra-passe, processo de recuperação, modelo de grupo e fluxo de trabalho de desativação.
A autenticação e a autorização são funções 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 funciona da seguinte forma:
Utilizador
|
| autentica-se uma vez
v
Provedor 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 continua a precisar 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, não como um substituto para as permissões da aplicação.
O mesmo princípio aplica-se ao conceber a implementação com e sem fios. O acesso à rede faz parte do património de identidades, pelo que as equipas devem decidir quais os grupos de diretório que podem alcançar determinados perfis de rede, em vez de associar o acesso a uma palavra-passe partilhada.
Para o WiFi de colaboradores e acesso baseado em identidade, a gestão de redes 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 provedor de identidade, uma entidade confiante e uma mensagem de identidade assinada desempenham funções distintas. O provedor de identidade autentica o utilizador, enquanto a entidade confiante, como uma aplicação ou serviço de rede, verifica a informação de identidade resultante.
A autenticação pode utilizar uma palavra-passe, autenticação multifator, condições do dispositivo ou outro método aprovado. O provedor 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 provedor 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. Sem uma sessão, redireciona o utilizador para o fornecedor de identidades.
- O fornecedor de identidades autentica o utilizador. Aplica os controlos configurados, como MFA ou acesso condicional.
- O fornecedor de identidades emite uma mensagem assinada. A integração utiliza comummente 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 as alegações 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 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 fornecer um caminho de tomada de controlo de conta através de uma ligação fidedigna do 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 reivindicaçõ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 conscientes da 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 fácil. O SAML e o OpenID Connect são padrões comuns para SSO empresarial, enquanto o OAuth é essencialmente uma estrutura de autorização para acesso delegado a APIs. Confundir o OAuth com autenticação pode levar as equipas a criar 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 | Aplicações empresariais estabelecidas e baseadas em navegador |
| OpenID Connect | Adiciona uma camada de identidade utilizando tokens | SaaS moderno, serviços web e orientados a 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 interações baseadas em JSON, REST e 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 tem de verificar
Independentemente do padrão, a parte confiante tem de validar o material de identidade recebido antes de criar uma sessão. As verificações fundamentais incluem:
- Emissor: Confirmar que a mensagem veio do fornecedor de identidade esperado.
- Assinatura: Verificar se a mensagem foi assinada pela chave ou certificado de confiança.
- Destinatário (Audience): Verificar se a mensagem se destinava a este serviço.
- Validade: Rejeitar asserções ou tokens expirados.
- Atributos (Claims): Utilizar apenas informações de identidade e de grupo relevantes e validadas.
O provedor de identidade pode centralizar políticas como MFA, acesso condicional, proibição de palavras-passe e pertença a grupos. A aplicação recebe depois as alegações (claims) 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.
Esta 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 são o mesmo controlo.
O Risco de Concentração Introduzido pelo SSO
Uma única conta de fornecedor de identidade comprometida pode expor 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 impacto e as opções de recuperação. As orientações do NCSC sobre a escolha de métodos de autenticação destacam 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 ao phishing, a confiança no dispositivo e o acesso com privilégios mínimos devem provir dos controlos integrados na arquitetura da federação. Um bom concetualização protege o provedor, as sessões que este cria e os processos de recuperação que podem restabelecer o acesso.
Criar camadas em redor do provedor
Os controlos devem cobrir 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 sempre que 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 acesso.
- Identidades de administrador separadas: Mantenha a administração privilegiada separada da atividade diária comum.
- Monitorização de autenticação: Investigue viagens impossíveis, indicadores de reprodução de tokens, falhas repetidas e escalamentos de privilégios inesperados.
- Proteção de recuperação: Trate as redefinições do suporte técnico 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 de SSO empresarial com uma autenticação forte de utilizadores e dispositivos, incluindo MFA ou acesso condicional. Recomenda também o SSO para SaaS porque os controlos centralizados tornam a gestão de utilizadores e grupos mais consistente e evitam que as credenciais sejam sincronizadas em todas as aplicações. O seu princípio de segurança na nuvem sobre identidade e autenticação estabelece 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 ligue ao WiFi não deve precisar de uma palavra-passe partilhada que permaneça válida após a sua saída. Um design suportado por 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. O serviço sem fios aplica, portanto, 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.
A 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 do diretório de alguém que sai da empresa 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 os grupos de diretório para funções de rede distintas, para que os funcionários, prestadores de serviços e administradores não recebam acessos idênticos por predefinição. Mantenha a duração das asserções ou tokens curta, limitando a utilidade de material de identidade desatualizado. Exija MFA no fornecedor de identidade, porque o SSO sem fios não se torna MFA apenas por utilizar SSO.
Registe os eventos de autenticação bem-sucedidos e falhados e ligue cada decisão de identidade à autorização de rede resultante. Teste a renovação de certificados antes da expiração, uma vez que falhas na confiança da federação podem interromper acessos WiFi que, de outro modo, estariam operacionais.
Os locais multi-inquilino exigem um limite separado. Propriedades residenciais, alojamento de estudantes, hotéis e espaços de utilização mista podem oferecer um acesso simples a residentes ou convidados, isolando o tráfego dos inquilinos e os sistemas dos colaboradores. O iPSK pode suportar dispositivos legados, enquanto o SSO da força de trabalho fornece um caminho de identidade distinto para os colaboradores.
O WiFi para convidados também gera decisões sobre consentimento, retenção e perfis de clientes. Este guia de dados de convidados para espaços oferece uma referência útil em conjunto com o design de rede, enquanto o Purple liga a autenticação baseada em identidade à 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 já não precisa de administrar. Um inquérito da Institution of Engineering and Technology de abril de 2024, realizado a 2000 residentes no Reino Unido com 16 ou mais anos, revelou que apenas 20% conseguiam identificar corretamente uma palavra-passe segura. O mesmo inquérito indicou que um quinto reutilizava uma palavra-passe em vários websites ou dispositivos, enquanto 21% utilizavam uma data significativa e 20% utilizavam o nome de um animal de estimação. Revelou também que 38% acreditavam que substituir letras por números melhorava a segurança da palavra-passe, 65% acreditavam que as palavras-passe nunca deviam ser anotadas e 77% achavam que alterações frequentes de palavra-passe aumentavam a segurança. (Inquérito de segurança de palavras-passe da 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 controlos e a rapidez com que os administradores podem agir, embora o phishing e a pauta de contas continuem a ser riscos ativos.
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: A desativação de 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 propriedade mais clara dos direitos de inquilinos e trabalhadores. Em cada caso, o resultado mensurável é um património de credenciais menor, um processamento de saídas de colaboradores mais fiável e provas mais sólidas de quem recebeu acesso a uma aplicação ou função de rede.
Implementar o 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 onde 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-alvo, a expiração e as reivindicações antes de criar uma sessão.
Utilizar uma lista de verificação operacional
- Comece com grupos de autoridade: Aprovisione acessos a partir de grupos de diretório pertencentes à equipa de negócio ou IT adequada.
- Defina regras para mudanças de função: Uma alteração de função deve remover os privilégios antigos, bem como adicionar os novos.
- Processe as saídas centralmente: Desative a identidade organizacional e verifique se as aplicações ligadas e as funções de rede respondem corretamente.
- Proteja os acessos de emergência: Mantenha as contas de emergência separadas da administração comum, monitorize-as atentamente e teste o seu processo de recuperação.
- Separe funcionários e convidados: O SSO de colaboradores pode suportar o acesso de menor privilégio e a sua revogação. A autenticação de convidados não deve herdar as permissões dos funcionários.
- Teste as alterações de confiança: Valide a renovação de certificados, a expiração de tokens, a terminação de sessões e as falhas do fornecedor antes de depender deles 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 espaço pode também precisar de suportar vários fornecedores de rede em vez de substituir a sua infraestrutura sem fios existente. O Purple foi concetualizado para funcionar com Meraki, Aruba, Ruckus, Mist e UniFi. Trate essas capacidades como considerações de implementação e não como substitutos de uma revisão de arquitetura.
A decisão central é saber se a organização consegue explicar, para cada serviço ligado, quem autentica o utilizador, quais os atributos confiados, como são atribuídas as permissões e o que acontece quando a identidade muda. O SSO é uma camada num programa de gestão de identidades e acessos. Não substitui o MFA, o acesso condicional, a monitorização da 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 a WiFi sem palavra-passe, funções de rede baseadas em diretórios e acesso separado para convidados, suportando integrações com 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.
