È possibile effettuare il provisioning e il deprovisioning degli utenti in modo affidabile? Una checklist per le applicazioni self-hosted
Una checklist pratica per verificare la creazione degli account, le modifiche alle autorizzazioni, la disattivazione e i casi limite prima di adottare o gestire un'applicazione self-hosted.
Considera il ciclo di vita degli account un processo operativo
Il provisioning degli utenti non si limita alla creazione di un account. Può comprendere anche l'aggiornamento degli account e la loro disattivazione o eliminazione: è la definizione generale riportata da [OneLogin](https://www.onelogin.com/learn/what-is-user-provisioning-and-deprovisioning/).
Per un'applicazione self-hosted, verifica ogni fase con il metodo di gestione degli account che hai scelto. Non dare per scontato che l'applicazione supporti la sincronizzazione delle directory, un determinato provider di identità o una specifica modalità di disattivazione. Controlla questi dettagli nella documentazione ufficiale aggiornata dell'applicazione e del provider di identità.
- Creazione dell'account e primo accesso
- Assegnazione e modifica di ruoli o gruppi
- Disattivazione o eliminazione
- Gestione degli asset collegati all'account
Mappa le modalità con cui gli account vengono creati
Documenta il percorso effettivo di creazione degli account. Potrebbe prevedere l'inserimento manuale da parte di un amministratore, l'accettazione di inviti o un'integrazione documentata con una directory: sono opzioni da verificare, non funzionalità da presumere.
Per ciascun percorso, individua chi avvia l'azione, quali informazioni servono e quali prove confermano che l'account è pronto all'uso. Verifica nella documentazione dell'applicazione o tramite un test controllato cosa accade agli inviti non accettati o inviati a un indirizzo errato.
- Indica la fonte autorevole degli attributi di identità, come nome e indirizzo email.
- Stabilisci come un amministratore può verificare che un account sia stato creato correttamente.
- Prova il percorso documentato prima di basare la progettazione su un processo automatizzato.
Verifica ruoli, gruppi e mappature
Un accesso riuscito non dimostra che le autorizzazioni siano gestite correttamente. Se l'accesso è assegnato tramite ruoli dell'applicazione, gruppi del provider di identità o una mappatura tra i due, verifica il percorso dall'assegnazione di origine alle autorizzazioni effettive nell'applicazione.
Prova poi una modifica: per esempio, una persona che cambia gruppo, perde un gruppo o riceve un ruolo senza una mappatura. Il risultato atteso dipende dalle regole della tua organizzazione; accerta il comportamento dell'applicazione con la documentazione ufficiale e test controllati.
- Prova un nuovo utente con il livello minimo di accesso necessario.
- Modifica un'assegnazione e controlla le autorizzazioni risultanti nell'applicazione.
- Verifica cosa accade quando un'assegnazione manca o è ambigua, senza presumere un comportamento predefinito.
Verifica cosa comporta la disattivazione
La disattivazione o l'eliminazione di un account potrebbe non risolvere ogni questione relativa agli accessi. In un test controllato, verifica il comportamento documentato per sessioni browser attive, credenziali API, token personali e account collegati. Non dedurre che la disattivazione revochi automaticamente ogni sessione o credenziale.
Tieni separato lo stato dell'account dagli asset a esso associati. Un utente che lascia l'organizzazione potrebbe essere titolare di record, attività pianificate, integrazioni o contenuti di cui altre persone hanno ancora bisogno. Definisci se questi elementi debbano essere trasferiti, conservati, rimossi o sottoposti a revisione, e chi debba approvare l'azione.
- Prova, in un ambiente controllato, un nuovo accesso e l'effetto sulle sessioni già attive.
- Fai l'inventario delle credenziali e degli account collegati; verifica la procedura documentata per la loro revoca.
- Controlla se l'eliminazione dell'account è reversibile e se influisce sui contenuti o sulla cronologia di audit.
- Assegna un responsabile e un percorso di approvazione per gli asset dell'utente che lascia l'organizzazione.
Gestisci le eccezioni senza creare account non controllati
Collaboratori esterni, utenti temporanei, amministratori, account di servizio e account di accesso di emergenza potrebbero non rientrare nel flusso ordinario. Decidi come creare, verificare e rimuovere ciascuna categoria prima che le eccezioni si accumulino.
Per ogni account fuori dal processo ordinario, definisci un responsabile, uno scopo, gli accessi consentiti e una data di revisione o una condizione per la rimozione. Per gli account di emergenza, documenta come proteggerli e come verificare il loro utilizzo secondo le indicazioni adeguate all'applicazione e alla tua organizzazione.
- Indica quali categorie sono gestite dalla fonte di identità principale.
- Assegna a ogni account non personale un responsabile umano e uno scopo documentato.
- Definisci una data di revisione o di scadenza per gli accessi temporanei.
- Includi le eccezioni nelle revisioni degli accessi e nelle procedure per le uscite.
Prova i casi di errore e le modifiche alle identità
Un ciclo di vita che funziona solo in condizioni ideali non è un processo affidabile. In test controllati, esamina ritardi, interruzioni e modifiche alle identità. L'esito dipende dall'integrazione e dall'applicazione: consulta la documentazione ufficiale per stabilire cosa dovrebbe accadere e confrontalo con ciò che osservi.
Presta attenzione alla corrispondenza delle identità. Un utente rinominato, un indirizzo email modificato, un'identità duplicata o un account ricreato potrebbe essere associato a un'identità esistente, rifiutato o trattato come una nuova persona. Non presumere quale identificativo sia autorevole: verifica le regole prima di applicarle agli account reali.
- Esamina, se la configurazione lo consente in sicurezza, cosa accade quando un processo di sincronizzazione è ritardato o sospeso.
- Usa account di test per verificare i casi di utente rinominato, indirizzo modificato, duplicato e identità eliminata e poi ricreata.
- Verifica come vengono segnalati i tentativi non riusciti e chi controlla che lo stato finale sia corretto.
Crea una matrice di test ripetibile
La matrice di seguito è un piano di verifica, non un'affermazione sulle funzionalità supportate da una particolare applicazione. Microsoft Learn offre [indicazioni per pianificare una distribuzione del provisioning automatico degli utenti in Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/identity/app-provisioning/plan-auto-user-provisioning); consulta anche la documentazione ufficiale della specifica applicazione e del provider di identità per i passaggi pertinenti.
Esegui i test prima dell'adozione, dopo modifiche sostanziali alle mappature o alle integrazioni e, quando opportuno, durante le revisioni periodiche degli accessi. Mantieni le identità di test separate dagli utenti di produzione e registra risultato atteso, risultato osservato, prove e responsabile delle attività successive.
- Usa una riga per ogni scenario del ciclo di vita: creazione, modifica dell'accesso, uscita o riattivazione.
- Per ogni scenario, registra il metodo documentato, l'esito atteso, l'esito osservato e le eventuali discrepanze.
- Collega alla matrice i test sui casi di errore e sulle modifiche alle identità descritti nella sezione precedente.
Assegna le responsabilità e valuta il modello di hosting
Assegna un responsabile a ogni fase. Gli amministratori delle identità possono gestire identità di origine e assegnazioni ai gruppi, mentre gli amministratori dell'applicazione possono gestire ruoli locali, contenuti e integrazioni. Metti per iscritto i punti di contatto tra queste responsabilità, l'approvazione delle eccezioni e il processo di escalation.
L'hosting gestito può ridurre il lavoro sull'infrastruttura, ma non determina da solo come un'applicazione effettui il provisioning degli utenti né come la tua organizzazione governi gli accessi. Airbip offre la distribuzione gestita delle applicazioni a catalogo come workload Docker sui server cloud Airbip, con instradamento e automazione TLS, controlli DNS, gestione del ciclo di vita dei servizi e backup configurabili. Queste funzionalità infrastrutturali non vanno confuse con un'integrazione per il provisioning degli utenti. Verifica separatamente le funzioni specifiche dell'applicazione e scegli un modello di distribuzione adatto ai requisiti di identità, sicurezza e operatività.
- Indica chi gestisce la fonte di identità, le autorizzazioni nell'applicazione e le eccezioni relative agli account.
- Definisci chi revisiona gli accessi e chi risolve le discrepanze di provisioning.
- Documenta chi gestisce i dati e le integrazioni di proprietà di un utente che lascia l'organizzazione.
- Confronta le opzioni di distribuzione gestita e autogestita con i tuoi requisiti: l'hosting non elimina la responsabilità della gestione degli accessi e dei dati.
Domande frequenti
Cosa comprende il provisioning degli utenti?
Può comprendere la creazione e l'aggiornamento degli account, oltre alla loro disattivazione o eliminazione. I passaggi effettivi dipendono dall'applicazione e dal metodo di gestione degli account.
Un'integrazione con un provider di identità gestisce automaticamente tutto il ciclo di vita?
Non darlo per scontato. Verifica nella documentazione sia del provider sia dell'applicazione quali passaggi sono supportati e quali richiedono un'azione separata.
L'hosting gestito si assume la responsabilità degli accessi degli utenti?
Non necessariamente. L'hosting può occuparsi di attività infrastrutturali; verifica le funzionalità dell'applicazione e definisci chi gestisce identità, autorizzazioni e dati.
Fonti e approfondimenti
- Plan an automatic user provisioning deployment for Microsoft Entra ID — Microsoft Learn
- What is User Provisioning & Deprovisioning? — OneLogin