Enterprise
Provisionamento SCIM a partir do seu fornecedor de identidade
Entradas, mudanças e saídas fluem automaticamente a partir do seu IdP — sem administração manual de contas, sem acessos órfãos à espera de se tornarem um resultado de auditoria.
O provisionamento SCIM liga o Ciao ao seu fornecedor de identidade, para que as contas de utilizador sejam criadas, atualizadas e desativadas automaticamente à medida que o seu diretório muda. Ao contrário da administração manual de contas, o SCIM remove o passo humano onde o offboarding falha: quando um utilizador é desativado no seu IdP, a alteração propaga-se para o Ciao, e as ações administrativas envolventes ficam registadas no registo de auditoria apenas de acréscimo que os seus revisores podem inspecionar.
Publicado 2026-07-03 · Última atualização 2026-07-03
Contas órfãs são resultados de auditoria à espera de acontecer
Todas as revisões de acesso as encontram: contas pertencentes a pessoas que mudaram de função ou saíram há meses, ainda ativas porque o desprovisionamento dependia de um pedido que ninguém chegou a submeter. Na maioria das ferramentas SaaS, isso é um problema de exposição. Numa plataforma em que um utilizador com sessão iniciada pode pedir alterações a software de produção, é também um problema de controlo de alterações — uma conta de que ninguém é dono, com capacidade para propor alterações a sistemas em que o seu negócio assenta.
O SCIM existe para remover o passo manual. O seu fornecedor de identidade já é a fonte de verdade sobre quem trabalha aqui e a que grupo pertence; o SCIM faz do Ciao um subscritor dessa verdade, em vez de uma lista separada que um administrador tem de se lembrar de reconciliar.
Os auditores convergiram para a mesma visão: as revisões de acesso que dependem de reconciliação manual acumulam resultados, e a automatização do ciclo de vida é a correção aceite. Se a sua organização já usa SCIM para os seus outros sistemas relevantes, alargá-lo à plataforma que constrói e implementa software é o passo coerente — e se o Ciao for a sua primeira integração SCIM, os passos de lançamento abaixo são deliberadamente conservadores.
O que o provisionamento SCIM cobre
A cobertura abrange os eventos de ciclo de vida que as suas revisões de acesso realmente testam:
- Criação de contas — Os utilizadores atribuídos ao Ciao no seu IdP têm contas provisionadas automaticamente — sem fila de pedidos, sem criação manual.
- Atualizações de atributos — As alterações de nome e perfil fluem a partir do diretório, para que o registo da conta acompanhe a pessoa sem intervenção administrativa.
- Mapeamento de grupos para funções — Os grupos do IdP podem mapear-se para funções do Ciao, para que o controlo de acesso baseado em funções seja orientado pela estrutura de diretório que a sua equipa já governa.
- Desativação — Quando o seu IdP desativa um utilizador, o respetivo acesso ao Ciao é removido como parte do fluxo de ciclo de vida — o passo que o offboarding manual mais frequentemente falha.
- Um registo de auditoria — As alterações de provisionamento são ações administrativas, e as ações administrativas ficam registadas no registo de auditoria apenas de acréscimo, juntamente com pedidos, merges e deploys.
Como funciona um lançamento
1. Comece pelo SSO
O SCIM pressupõe que o SSO via SAML ou OIDC já está implementado, para que a autenticação e o provisionamento partilhem uma única fonte de identidade.
2. Ligue o IdP
Configure a integração SCIM no seu fornecedor de identidade durante o onboarding, com a equipa enterprise a trabalhar junto dos seus engenheiros de identidade.
3. Mapeie grupos para funções
Decida que grupos do IdP correspondem a que funções e âmbitos de projeto no Ciao, e registe o mapeamento — este passa a fazer parte da sua documentação de controlo de acesso.
4. Faça um piloto com um grupo
Atribua um pequeno grupo, e depois verifique se os eventos de criação, atualização e desativação chegam como esperado antes de alargar. Inclua pelo menos uma desativação no piloto — é o evento mais importante e o que as equipas mais frequentemente se esquecem de testar.
5. Verifique no registo de auditoria
Confirme que os eventos de provisionamento aparecem como ações administrativas no registo apenas de acréscimo, para que as suas revisões de acesso tenham evidência em vez de suposições.
SCIM, SSO, RBAC e o registo de auditoria como um único sistema
Estes quatro controlos foram concebidos para serem revistos em conjunto. O SSO responde a como as pessoas se autenticam; o SCIM responde a como as contas passam a existir e deixam de existir; o controlo de acesso baseado em funções responde ao que uma pessoa autenticada pode fazer; e o registo de auditoria apenas de acréscimo regista o que ela efetivamente fez — pedidos, merges, deploys e ações administrativas. Um revisor consegue seguir uma única pessoa desde o grupo de diretório até à função no Ciao e até a uma ação específica registada, que é precisamente a história de rastreabilidade que a maioria dos frameworks de controlo de acesso realmente pede.
Na prática, a combinação muda a textura de uma revisão de acesso. Em vez de entrevistar administradores sobre o que acreditam ter acontecido, o revisor lê o que aconteceu: o evento de diretório, a função resultante, as ações tomadas ao abrigo dela. O tempo de revisão desloca-se da recolha de evidência para o julgamento, que é onde deve estar.
Eventos de ciclo de vida e o seu efeito
Use isto como lista de verificação para o seu piloto: execute cada evento com um utilizador de teste e verifique o efeito.
| Evento de ciclo de vida | O que acontece no Ciao | Onde verificar |
|---|---|---|
| Utilizador atribuído no IdP | Conta provisionada com a função mapeada | Ações administrativas no registo de auditoria |
| Atributos mudam | Registo da conta atualizado a partir do diretório | Detalhe da conta e registo de auditoria |
| Pertença a grupo muda | A função e o âmbito mapeados acompanham o diretório | Configuração de RBAC e registo de auditoria |
| Utilizador desativado no IdP | Acesso ao Ciao removido através do fluxo de ciclo de vida | Registo de auditoria e revisão de acesso |
| Conteúdo do workspace | As apps e o código permanecem propriedade do workspace | Exportação de código disponível a qualquer momento |
Notas de verificação
O provisionamento é um controlo que a sua equipa deve testar, não aceitar por confiança. Durante a avaliação, execute o ciclo de vida de ponta a ponta com um utilizador de teste — atribuir, atualizar, desativar — e observe os resultados no registo de auditoria. Os detalhes de integração para o seu IdP são abordados durante o onboarding, e o dossiê de segurança, disponível a pedido através da página de contacto, documenta a arquitetura de identidade para os revisores que precisam do detalhe por escrito.
Se o seu lançamento tiver restrições pouco comuns — contas partilhadas a eliminar, prestadores de serviços num IdP separado, migrações faseadas — coloque-as por escrito junto da equipa enterprise antes do piloto, para que a configuração seja concebida a partir da sua realidade, em vez de ajustada depois dela.
Perguntas frequentes
Que fornecedores de identidade conseguem controlar o provisionamento SCIM?
O SCIM é um padrão, e os fornecedores de identidade que as empresas normalmente usam — Okta, Microsoft Entra ID e similares — implementam-no. Confirme o seu IdP específico e a configuração junto da equipa enterprise durante o onboarding.
O que acontece ao trabalho de uma pessoa quando é desprovisionada?
O seu acesso é removido; o trabalho não desaparece. As aplicações e o código pertencem ao workspace, com 100% de propriedade do código e exportação para o seu próprio repositório disponível a qualquer momento — fazer o offboarding de uma pessoa nunca deixa o software encalhado.
O SCIM substitui o provisionamento just-in-time?
Resolvem metades diferentes do problema. O JIT cria uma conta no primeiro início de sessão; o SCIM gere o ciclo de vida contínuo, incluindo atualizações e desativação. Muitos lançamentos usam o JIT durante o piloto e o SCIM para a implementação completa.
As ações de provisionamento e desprovisionamento ficam registadas?
Sim. São ações administrativas, registadas no registo de auditoria apenas de acréscimo, juntamente com pedidos, merges e deploys — para que as revisões de acesso possam citar eventos registados em vez de capturas de ecrã.
Como validamos o SCIM antes de o lançar em toda a empresa?
Faça um piloto com um grupo de teste: atribua, altere atributos, mude de grupo, desative, e verifique cada evento no registo de auditoria. A equipa enterprise apoia o piloto, e o dossiê de segurança documenta a arquitetura de identidade em revisão.