Implementar um programa de sensibilização para dez mil colaboradores acarreta um custo que quase ninguém coloca em cima da mesa no início: criar e manter dez mil contas. Cada admissão, cada saída, cada mudança de área é mais um utilizador para dar entrada numa plataforma a mais, com mais uma palavra-passe que o colaborador vai esquecer. O início de sessão parece um pormenor menor até se multiplicar pelo número de efetivos de um grande grupo, e aí deixa de ser menor.
O SSO elimina esse atrito, mas costuma ser vendido como uma caixa de verificação (“tem SSO? sim”) sem explicar o que acontece na realidade entre o momento em que o colaborador clica e o momento em que entra no programa. Esse “o que acontece na realidade” é o que decide se a integração se resolve numa tarde ou se transforma num projeto de semanas. O DBIR da Verizon coloca ano após ano as credenciais roubadas entre os principais vetores de acesso inicial às organizações, por isso reduzir o número de palavras-passe que cada colaborador gere não é apenas comodidade, mas superfície de ataque que diminui.
O que o SSO resolve (e o que não resolve) numa plataforma de sensibilização
O single sign-on (SSO) é o mecanismo pelo qual um colaborador acede à plataforma com as mesmas credenciais empresariais que já usa para as restantes ferramentas, sem criar nem memorizar um nome de utilizador e uma palavra-passe próprios da plataforma. A autenticação não é resolvida pela plataforma: é delegada no fornecedor de identidade (IdP) da organização, que já sabe quem é essa pessoa.
É exatamente isso que resolve, e convém ser preciso quanto ao limite. O SSO responde à pergunta ”esta pessoa é quem diz ser?” no momento do acesso. Não responde a ”esta pessoa deveria existir na plataforma?”. Essa segunda pergunta (a criação, a desativação e a atualização das contas) é aprovisionamento, e é um problema distinto que se resolve com outra peça. Confundir os dois é a causa mais comum de uma implementação “com SSO” continuar a esconder trabalho manual.
Como funciona o fluxo de autenticação SSO de ponta a ponta?
A norma que sustenta a maioria destas integrações é o SAML 2.0. No SAML existem dois intervenientes: o fornecedor de identidade (IdP), que é o sistema empresarial onde reside a identidade do colaborador, e o fornecedor de serviço (SP), que neste caso é a plataforma de sensibilização. O fluxo de ponta a ponta, quando o colaborador parte da plataforma, é assim:
- O colaborador entra na plataforma e esta deteta que não há uma sessão ativa.
- A plataforma (SP) reencaminha o navegador para o IdP empresarial com um pedido de autenticação assinado.
- O IdP autentica o colaborador com as suas próprias regras: palavra-passe, segundo fator, políticas de acesso condicional, o que a organização tiver configurado.
- Se a autenticação for válida, o IdP devolve ao navegador uma asserção SAML assinada, um documento que afirma “esta pessoa é quem diz ser, e estes são os seus atributos”.
- A plataforma valida a assinatura dessa asserção face ao certificado do IdP, lê os atributos e abre a sessão.
O colaborador vê apenas uma coisa: clica e entra. Toda a troca do pedido, da asserção e da validação da assinatura ocorre em milissegundos e sem que tenha de escrever nada. O outro ponto de partida possível é o inverso, quando o colaborador parte do portal empresarial (IdP-initiated) e daí salta para a plataforma já autenticado, mas a mecânica da asserção assinada é a mesma.
O que importa para quem avalia a plataforma é que a confiança não assenta numa palavra-passe partilhada entre dois sistemas, mas em criptografia: o SP confia no IdP porque pode verificar a sua assinatura, não porque guarda um segredo. É essa a razão pela qual o SSO é mais seguro do que replicar palavras-passe, e é a mesma lógica de delegar no sistema certo que aplicamos quando explicamos porque nos integramos por API e não por agente.
SSO e aprovisionamento de utilizadores são a mesma coisa?
Não, e mantê-los separados é o que permite ao programa escalar sem trabalho manual. O SSO autentica; o aprovisionamento cria, atualiza e desativa as contas. Um colaborador só se pode autenticar por SSO se a sua conta já existir na plataforma, por isso o aprovisionamento é o passo prévio que há que resolver à parte.
O aprovisionamento resolve-se de duas formas sem dar entrada de contas à mão, e não são equivalentes. A que sustenta o programa ao longo do tempo é a sincronização a partir do diretório: a plataforma liga-se ao diretório empresarial, por LDAP ou importando de Microsoft Entra ID ou Google, e mantém a lista de colaboradores alinhada com a fonte de verdade da organização. Quando alguém entra ou sai da empresa, a alteração propaga-se sem que o responsável do programa tenha de mexer em nada.
A outra opção, mais simples para arrancar, é importar a lista manualmente a partir de um ficheiro CSV, quando não se pretende ligar todo o diretório. Serve para o arranque inicial, mas é uma fotografia de um momento e não reflete as entradas nem as saídas posteriores. A desativação, além disso, é o caso que mais importa do ponto de vista da segurança: um colaborador que saiu da empresa mas continua com a conta ativa é uma falha.
Por isso o aprovisionamento baseado no diretório, onde a desativação do colaborador no sistema empresarial arrasta o seu estado na plataforma, é o que fecha essa falha pela raiz. É o mesmo princípio de fonte de verdade única para a lista que está por trás de como funciona a sincronização de diretório com o Microsoft Entra ID (antes Azure AD).
O que torna uma integração SSO “automática” e não um projeto de semanas?
A diferença entre uma integração de uma tarde e uma que dura semanas não está na norma (o SAML é o mesmo para todos) mas em quanto da montagem depende de trocar ficheiros de configuração à mão. Uma integração automática reduz essa montagem a três coisas resolvidas de forma cuidada:
- Troca de metadados em vez de configuração manual. O IdP e a plataforma descrevem-se mutuamente com um ficheiro de metadados normalizado (URL, certificados, identificadores). Carregar esses metadados de um lado para o outro substitui o copiar e colar de campos avulsos, que é onde surgem os erros difíceis de diagnosticar.
- Mapeamento explícito de atributos. A asserção do IdP transporta atributos (nome, correio eletrónico, área, talvez o país da filial) e a plataforma tem de saber a que campo vai cada um. Definir esse mapeamento uma vez, com critério, é o que evita ter de o ajustar sempre que entra um novo colaborador.
- Um IdP por tenant quando há várias organizações. Num grupo com filiais, cada uma pode ter o seu próprio fornecedor de identidade. Uma arquitetura multi-tenant permite que cada filial ligue o seu IdP sem interferir com as demais, algo que se torna necessário quando se sustenta um programa multilingue com sede em Espanha e filiais na América Latina.
Quando estas três coisas estão resolvidas, acrescentar o SSO deixa de ser um marco de projeto e passa a ser um passo de configuração. O colaborador nunca vê nada disto, que é precisamente o objetivo.
Como é que o SSO se encaixa na arquitetura da SMARTFENSE?
A SMARTFENSE resolve a autenticação delegando-a no fornecedor de identidade de cada organização. A plataforma suporta autenticação universal por SAML 2.0, o que lhe permite integrar-se com qualquer IdP que fale a norma, e além disso importa e autentica colaboradores diretamente a partir de Microsoft Entra ID e Google, e admite autenticação a partir de Auth0. O aprovisionamento é coberto pela outra via: sincronização de utilizadores por diretório LDAP e importação a partir desses mesmos fornecedores, de modo a que a lista de colaboradores se mantenha alinhada com a fonte de verdade da organização.
Para os casos que precisam de ir além do que a configuração resolve (automatizar admissões e saídas com lógica própria, ou ligar a lista a outro sistema interno), a plataforma expõe uma API REST documentada com OAuth 2.0 e JSON para gestão de utilizadores e resultados. A lista completa destas integrações de identidade e diretório está na página de integrações da plataforma, e a forma como os colaboradores são geridos uma vez lá dentro vê-se em utilizadores e grupos inteligentes.
O resultado, visto a partir da operação do programa, é que a equipa responsável não administra palavras-passe nem dá entrada de contas à mão: a identidade é resolvida pelo sistema que já a detinha, e a plataforma ocupa-se do que é seu, que é medir e mudar o comportamento das pessoas.
Perguntas frequentes
SSO significa que a SMARTFENSE guarda as palavras-passe dos meus colaboradores?
Não. Com o SSO a plataforma nunca vê nem armazena a palavra-passe empresarial. A autenticação ocorre no fornecedor de identidade da organização, que devolve uma asserção assinada; a plataforma apenas verifica essa assinatura para abrir a sessão.
Posso usar o SSO sem sincronizar todo o meu diretório?
Sim. A autenticação por SSO e o aprovisionamento de contas são peças independentes. Pode autenticar-se por SAML e carregar a lista importando-a a partir de um ficheiro CSV, ou sincronizar o diretório por LDAP para manter alinhadas admissões e saídas. São decisões separadas.
O que acontece quando um colaborador sai da empresa?
Se o aprovisionamento for baseado no diretório, a desativação do colaborador no sistema empresarial propaga-se à plataforma e o seu acesso é encerrado sem intervenção manual. Este é o ponto que mais convém resolver por sincronização e não pela criação de contas ao momento.
O SSO serve para um grupo com várias filiais?
Sim. Uma arquitetura multi-tenant permite que cada filial ligue o seu próprio fornecedor de identidade de forma independente, mantendo o programa unificado ao nível do grupo mas com a autenticação de cada organização resolvida em separado.
Quanto tempo demora uma integração SSO?
Depende de a montagem assentar na troca de metadados e num mapeamento de atributos definido uma vez, ou em configuração manual campo a campo. Com a primeira, acrescentar o SSO é um passo de configuração; com a segunda, prolonga-se por causa dos erros difíceis de diagnosticar.
Se estás a avaliar como levar o teu programa de sensibilização a toda a organização sem acrescentar mais uma palavra-passe nem dar entrada de contas à mão, a plataforma da SMARTFENSE resolve a autenticação e o aprovisionamento apoiando-se na identidade que a tua organização já administra.
Deixe um comentário