Início de sessão único via SAML e OIDC

Toda a ferramenta que guarda as suas próprias palavras-passe é uma ferramenta que o seu processo de offboarding pode não apanhar. Para uma plataforma em que um utilizador com sessão iniciada pode pedir alterações a software de produção, esse risco é mais agudo do que num produto de dashboard: uma conta órfã não é apenas uma questão de exposição de dados, mas também uma questão de controlo de alterações. As revisões de segurança têm razão em colocar o SSO perto do topo da lista de requisitos.

O SSO move a autenticação do Ciao para trás do fornecedor de identidade que já governa. As revisões de acesso acontecem num só lugar, a política de MFA é aplicada de forma consistente, e o processo de entradas, mudanças e saídas que os seus auditores já aceitam alarga-se para cobrir o desenvolvimento assistido por IA sem um repositório de contas paralelo para reconciliar.

Há um benefício mais discreto para as pessoas que fazem o trabalho: menos uma palavra-passe, menos um ritual de início de sessão, e acesso que surge logo no primeiro dia porque o diretório — e não uma fila de pedidos — é a fonte de verdade. Os controlos que tornam o caminho seguro no caminho conveniente são os controlos que as pessoas realmente seguem, e o SSO é o exemplo mais claro na pilha de identidade.

O provisionamento just-in-time cria uma conta Ciao na primeira vez que um utilizador inicia sessão através do seu IdP. Isso remove o passo manual no onboarding e evita que contas pré-criadas fiquem por usar. O que o JIT não faz é desprovisionar: um utilizador que nunca mais inicia sessão continua a precisar que o seu acesso seja removido no IdP, e a automatização do ciclo de vida é melhor tratada pelo SCIM. A maioria das implementações enterprise usa SSO com JIT para a chegada e SCIM para todo o ciclo de vida — a página do SCIM cobre essa segunda metade.

Durante a avaliação, teste explicitamente o percurso JIT: atribua um utilizador de teste no IdP, inicie sessão uma vez, e confirme que a conta chega com a função que o seu mapeamento previa. O teste de cinco minutos diz-lhe mais do que qualquer diagrama de arquitetura.

A duração da sessão, a frequência de reautenticação e as regras de step-up pertencem ao fornecedor de identidade, onde a sua equipa de segurança já as afina, e o SSO significa que as sessões do Ciao seguem a política que o seu IdP aplica no início de sessão. O MFA funciona da mesma forma: aplique-o na política do IdP que governa o acesso ao Ciao, com MFA opcional disponível também do lado da plataforma. O resultado prático para os revisores é uma única superfície de política a auditar, em vez de definições de sessão por ferramenta que se desalinham ao longo do tempo.

Quando a sua política muda — sessões mais curtas, regras de step-up mais rígidas — muda-a uma vez, no IdP, e o acesso ao Ciao segue-a sem uma auditoria paralela de definições do lado da plataforma.

As afirmações de identidade são fáceis de verificar: configure uma ligação de teste durante a avaliação e observe o início de sessão, a criação de contas JIT e o mapeamento de funções a acontecer contra o seu próprio IdP. O dossiê de segurança, disponível a pedido através da página de contacto, documenta a arquitetura de identidade por escrito, e os relatórios SOC 2 Type II sob NDA cobrem os controlos de gestão de acesso auditados por trás dela.