Enterprise
Provisioning SCIM dal tuo identity provider
Nuovi arrivati, cambi di ruolo e chi se ne va fluiscono automaticamente dal tuo IdP — nessuna amministrazione manuale degli account, nessun accesso orfano in attesa di diventare un rilievo di audit.
Il provisioning SCIM collega Ciao al tuo identity provider così gli account utente vengono creati, aggiornati e disattivati automaticamente man mano che la tua directory cambia. A differenza dell'amministrazione manuale degli account, SCIM rimuove il passaggio umano dove l'offboarding fallisce: quando un utente viene disattivato nel tuo IdP, la modifica si propaga a Ciao, e le azioni amministrative circostanti finiscono nel registro di controllo append-only che i tuoi revisori possono ispezionare.
Pubblicato 2026-07-03 · Ultimo aggiornamento 2026-07-03
Gli account orfani sono rilievi di audit in attesa di accadere
Ogni revisione degli accessi li trova: account appartenenti a persone che hanno cambiato ruolo o se ne sono andate mesi fa, ancora attivi perché il deprovisioning dipendeva da un ticket che nessuno ha mai depositato. Nella maggior parte degli strumenti SaaS questo è un problema di esposizione. In una piattaforma dove un utente autenticato può richiedere modifiche al software di produzione, è anche un problema di controllo dei cambiamenti — un account che nessuno possiede, con la capacità di proporre modifiche a sistemi su cui la tua azienda gira.
SCIM esiste per rimuovere il passaggio manuale. Il tuo identity provider è già la fonte di verità su chi lavora qui e a quale gruppo appartiene; SCIM rende Ciao un abbonato a quella verità invece di un elenco separato che un amministratore deve ricordarsi di riconciliare.
Gli auditor sono convergenti sulla stessa visione: le revisioni degli accessi che dipendono dalla riconciliazione manuale raccolgono rilievi, e l'automazione del ciclo di vita è la correzione accettata. Se la tua organizzazione già esegue SCIM per gli altri suoi sistemi rilevanti, estenderlo alla piattaforma che costruisce e distribuisce software è la mossa coerente — e se Ciao sarebbe la tua prima integrazione SCIM, i passaggi di rollout sotto sono deliberatamente conservativi.
Cosa copre il provisioning SCIM
La copertura si estende sugli eventi del ciclo di vita che le tue revisioni degli accessi testano realmente:
- Creazione dell'account — Gli utenti assegnati a Ciao nel tuo IdP ottengono account provisionati automaticamente — nessuna coda di richiesta, nessuna creazione manuale.
- Aggiornamenti degli attributi — I cambiamenti di nome e profilo fluiscono dalla directory, così il record dell'account segue la persona senza intervento amministrativo.
- Mappatura da gruppo a ruolo — I gruppi IdP possono mappare a ruoli Ciao, così il controllo degli accessi basato sui ruoli è guidato dalla struttura della directory che il tuo team già governa.
- Disattivazione — Quando il tuo IdP disattiva un utente, il suo accesso a Ciao viene rimosso come parte del flusso del ciclo di vita — il passaggio che l'offboarding manuale più spesso perde.
- Un registro di audit — Le modifiche al provisioning sono azioni amministrative, e le azioni amministrative vengono registrate nel registro di controllo append-only insieme a prompt, merge e deploy.
Come funziona un rollout
1. Parti dall'SSO
SCIM presuppone che l'SSO tramite SAML o OIDC sia già in atto, così autenticazione e provisioning condividono un'unica fonte di identità.
2. Collega l'IdP
Configura l'integrazione SCIM nel tuo identity provider durante l'onboarding, con il team enterprise che lavora insieme ai tuoi ingegneri di identità.
3. Mappa i gruppi ai ruoli
Decidi quali gruppi IdP corrispondono a quali ruoli e ambiti di progetto Ciao, e registra la mappatura — diventa parte della tua documentazione sul controllo degli accessi.
4. Pilota con un gruppo
Assegna un piccolo gruppo, poi verifica che gli eventi di creazione, aggiornamento e disattivazione atterrino come previsto prima di espandere. Includi almeno una disattivazione nel pilot — è l'evento che conta di più e quello che i team più spesso dimenticano di testare.
5. Verifica nel registro di controllo
Conferma che gli eventi di provisioning appaiano come azioni amministrative nel registro append-only, così le tue revisioni degli accessi hanno prove invece di presunzioni.
SCIM, SSO, RBAC e il registro di controllo come un unico sistema
Questi quattro controlli sono progettati per essere revisionati insieme. L'SSO risponde a come le persone si autenticano; SCIM risponde a come gli account nascono e cessano di esistere; il controllo degli accessi basato sui ruoli risponde a cosa può fare una persona autenticata; e il registro di controllo append-only registra cosa hanno effettivamente fatto — prompt, merge, deploy e azioni amministrative. Un revisore può tracciare una singola persona dal gruppo della directory al ruolo Ciao a un'azione specifica registrata, che è la storia di tracciabilità che la maggior parte dei framework di controllo degli accessi sta realmente chiedendo.
In pratica, la combinazione cambia la texture di una revisione degli accessi. Invece di intervistare gli amministratori su cosa credono sia successo, il revisore legge cosa è successo: l'evento della directory, il ruolo risultante, le azioni intraprese sotto di esso. Il tempo di revisione si sposta dalla raccolta di prove al giudizio, che è dove appartiene.
Eventi del ciclo di vita e il loro effetto
Usa questo come checklist per il tuo pilot: esegui ogni evento con un utente di test e verifica l'effetto.
| Evento del ciclo di vita | Cosa succede in Ciao | Dove verificarlo |
|---|---|---|
| Utente assegnato nell'IdP | Account provisionato con il ruolo mappato | Azioni amministrative nel registro di controllo |
| Gli attributi cambiano | Il record dell'account viene aggiornato dalla directory | Dettaglio dell'account e registro di controllo |
| L'appartenenza al gruppo cambia | Il ruolo e l'ambito mappati seguono la directory | Configurazione RBAC e registro di controllo |
| Utente disattivato nell'IdP | L'accesso a Ciao viene rimosso tramite il flusso del ciclo di vita | Registro di controllo e revisione degli accessi |
| Contenuto del workspace | App e codice restano di proprietà del workspace | Esportazione del codice disponibile in qualsiasi momento |
Note di verifica
Il provisioning è un controllo che il tuo team dovrebbe testare, non dare per fede. Durante la valutazione, esegui il ciclo di vita end-to-end con un utente di test — assegna, aggiorna, disattiva — e osserva i risultati nel registro di controllo. Le specifiche di integrazione per il tuo IdP sono coperte durante l'onboarding, e il security pack, disponibile su richiesta tramite la pagina dei contatti, documenta l'architettura dell'identità per i revisori che hanno bisogno del dettaglio per iscritto.
Se il tuo rollout ha vincoli insoliti — account condivisi da eliminare, appaltatori su un IdP separato, migrazioni graduali — mettili per iscritto al team enterprise prima del pilot, così la configurazione è progettata contro la tua realtà piuttosto che aggiustata dopo.
Domande frequenti
Quali identity provider possono guidare il provisioning SCIM?
SCIM è uno standard, e gli identity provider che le imprese tipicamente gestiscono — Okta, Microsoft Entra ID e simili — lo implementano. Conferma il tuo IdP specifico e la configurazione con il team enterprise durante l'onboarding.
Cosa succede al lavoro di una persona quando viene deprovisionata?
Il suo accesso viene rimosso; il lavoro non svanisce. Applicazioni e codice appartengono al workspace, con il 100% di proprietà del codice ed esportazione sul tuo repository disponibile in qualsiasi momento — l'offboarding di una persona non lascia mai il software abbandonato.
SCIM sostituisce il provisioning just-in-time?
Risolvono metà diverse. JIT crea un account al primo accesso; SCIM gestisce il ciclo di vita continuo inclusi aggiornamenti e disattivazione. Molti rollout usano JIT durante il pilot e SCIM per il deploy completo.
Le azioni di provisioning e deprovisioning sono registrate?
Sì. Sono azioni amministrative, registrate nel registro di controllo append-only insieme a prompt, merge e deploy — così le revisioni degli accessi possono citare eventi registrati piuttosto che screenshot.
Come validiamo SCIM prima di distribuirlo in tutta l'azienda?
Pilota con un gruppo di test: assegna, cambia attributi, sposta gruppi, disattiva, e verifica ogni evento nel registro di controllo. Il team enterprise supporta il pilot, e il security pack documenta l'architettura dell'identità sotto revisione.