SCIM e provisioning automatico degli account
Come SCIM crea, modifica e disattiva gli account delle applicazioni quando Lei arriva, cambia ruolo o lascia l'azienda, e cosa deve fare.
In 30 secondi
- Dove succede
- A ogni arrivo, cambio di ruolo o uscita, in tutte le applicazioni collegate alla directory aziendale.
- Cosa vuole l'attaccante
- Usare un account dimenticato, che nessuno sorveglia, per entrare nei sistemi.
- Il riflesso
- Avvisare in tempo l'arrivo, il cambio di ruolo o l'uscita, non creare account al di fuori del circuito ufficiale e restituire tutti i propri accessi.
- Se è già successo
- Se ha aperto un account fuori dal circuito o ha conservato un accesso dopo un cambio di ruolo, lo segnali al team informatico, in modo che venga collegato o chiuso.
Di cosa si tratta
In un'azienda ogni dipendente ha account in numerose applicazioni: posta elettronica, archiviazione di file e altri strumenti. Quando qualcuno arriva, cambia ruolo o se ne va, questi account vanno creati, modificati o chiusi. Se la chiusura avviene a mano, può essere dimenticata, e l'account di chi se n'è andato resta aperto.
SCIM (System for Cross-domain Identity Management) è una specifica che offre alle applicazioni un modo comune di ricevere queste operazioni dalla directory aziendale1. Questa scheda spiega che cosa SCIM automatizza, che cosa non copre e che cosa devono fare il dipendente e il suo responsabile perché il circuito funzioni.
Domande dirette
Che cos'è SCIM, in pratica?
È un linguaggio comune tra la directory e le applicazioni. Senza di esso, ogni applicazione ha i propri indirizzi di accesso, il proprio modo di descrivere un utente e il proprio schema di dati. SCIM fornisce uno schema utente comune per far entrare, uscire e spostare le persone tra le applicazioni1. Il servizio di provisioning di Microsoft Entra ID si collega all'endpoint SCIM 2.0 messo a disposizione dal fornitore dell'applicazione per creare, modificare ed eliminare utenti2.
Che cosa cambia la directory per un'uscita?
La directory diventa la fonte di verità. Il provisioning automatico comprende la creazione degli account, ma anche il loro mantenimento e la loro rimozione quando cambiano lo stato o il ruolo1. Può disattivare automaticamente gli account nelle applicazioni giuste quando le persone lasciano il team o l'organizzazione1. Mantiene inoltre aggiornati gli account in base alle modifiche della directory o del sistema delle risorse umane1.
In che modo riduce gli account fantasma?
Perché la chiusura non dipende più dalla memoria di qualcuno. Tra le motivazioni Microsoft cita la rimozione immediata delle identità dalle principali applicazioni SaaS quando una persona se ne va1. Quando una persona esce dal perimetro del provisioning, anche se viene rimossa dall'applicazione, il servizio disattiva il suo account nell'applicazione di destinazione2. Ciò presuppone però che l'applicazione sia collegata, come illustrano le insidie più sotto.
Qual è il mio ruolo, se tutto è automatico?
L'automatismo parte dalla directory. Se la directory non sa che Lei se ne va o che cambia reparto, non si attiva nulla. L'informazione deve arrivarvi in tempo, e a innescarla sono il dipendente e il suo responsabile.
1Come funziona1 min
Il servizio di provisioning lavora per cicli. Un primo ciclo interroga tutti gli utenti e i gruppi dell'origine, poi cicli incrementali elaborano soltanto ciò che è cambiato dall'ultimo punto di riferimento registrato2. Se un utente non ha un account corrispondente nell'applicazione, ne viene creato uno. Se ce l'ha, viene aggiornato2.
L'uscita segue diversi casi previsti. Un utente disattivato o eliminato nel «cestino» della directory viene disattivato nell'applicazione di destinazione. Per un'applicazione SCIM, disattivare equivale a richiedere che la proprietà «active» sia falsa2. Trenta giorni dopo l'eliminazione nella directory, l'utente viene eliminato definitivamente e il servizio invia allora una richiesta di eliminazione all'applicazione2. Un utente i cui gruppi o diritti cambiano può inoltre uscire dal perimetro, e ciò vale come uscita dall'applicazione2. Con i gruppi dinamici, la rapidità della rimozione dipende da quanto velocemente il gruppo rivaluta i propri membri2.
Tutto viene registrato nei log di provisioning, che annotano le letture e le scritture eseguite sui sistemi di origine e di destinazione2.
2Cosa fa Lei1 min
- Avvisi in anticipo. Comunichi al suo responsabile e alle risorse umane il suo arrivo, il cambio di ruolo o l'uscita con la data esatta, perché è la modifica della directory a far partire tutto il resto.
- Responsabili: dichiarate i cambi di ruolo come le uscite. Un cambio di ruolo può richiedere di togliere accessi, non solo di aggiungerne1.
- Non crei account al di fuori del circuito ufficiale: nessuna iscrizione personale a un servizio con l'indirizzo aziendale, nessun account aperto a mano nell'interfaccia di amministrazione di un'applicazione senza informare il team informatico. Un account simile non è collegato alla directory, quindi nessuno lo chiuderà automaticamente.
- Restituisca i suoi accessi prima di andarsene: badge, chiavi di sicurezza, dispositivi e ogni accesso ricevuto attraverso un canale diverso dal suo account abituale.
- Attivi l'autenticazione a più fattori sugli account che restano aperti. La CISA mette le chiavi di sicurezza in cima ai metodi e i codici via SMS o e-mail all'ultimo posto7.
3Le insidie2 min
Applicazione non collegata
Un'applicazione del catalogo supporta o il provisioning manuale o il provisioning automatico. In modalità manuale non esiste un connettore automatico: gli account si creano a mano, per esempio nel portale di amministrazione dell'applicazione o tramite un file di foglio di calcolo1. Per queste applicazioni l'uscita richiede un'azione umana. Un'applicazione creata a partire da una semplice registrazione OIDC non è abilitata al provisioning automatico3.
Modifiche fatte direttamente nell'applicazione
Il servizio ignora le modifiche fatte nelle applicazioni esterne e non le annulla: si basa su ciò che cambia nella directory3. Un account creato o modificato localmente sfugge quindi al circuito. Microsoft indica che il provisioning può anche individuare gli account esistenti in un'applicazione, compresi quelli locali o orfani1. MITRE raccomanda di rimuovere gli account orfani, per esempio quelli senza proprietario, durante audit periodici e di disattivare automaticamente gli account dopo un periodo di inattività, per esempio 30 giorni4.
Account locali, account condivisi, password
Il provisioning delle password non è supportato3. Alcune applicazioni on-premises non sono federate con la directory e richiedono password locali3. Un account condiviso o una password locale nota a chi se ne va non si chiude con l'uscita del titolare: va cambiata o eliminata a mano.
Tempi ed errori
L'intervallo tra due cicli non è configurabile3. Quando un errore impedisce di modificare un utente, l'operazione viene ritentata al ciclo successivo e un amministratore deve consultare i log per trovarne la causa2. Se la maggior parte delle chiamate fallisce, per esempio per credenziali di amministrazione non valide, il lavoro entra in quarantena, con cicli rallentati a uno al giorno, e viene poi disattivato dopo più di quattro settimane2. Un'uscita può quindi non essere riportata in tempo senza che nessuno se ne accorga.
Token e sessioni che sopravvivono
Secondo MITRE, un attaccante che controlla un account cloud può creare credenziali aggiuntive di lunga durata per restarvi, e queste credenziali possono aggirare controlli come l'autenticazione a più fattori5. Le fonti citate qui non dicono se una sessione aperta si interrompa non appena un account SCIM viene disattivato. Sul lato dell'applicazione, OWASP indica che, quando una sessione termina, l'applicazione deve invalidarla sia lato client sia lato server, e che il lato server è il più importante e obbligatorio dal punto di vista della sicurezza6. Raccomanda inoltre un timeout di inattività e un timeout assoluto per tutte le sessioni6. Quando un dipendente se ne va, il team informatico deve quindi verificare i token di accesso, le password delle applicazioni e le sessioni, oltre all'account stesso.
Scheda
- Identificativo
- CP-205
- Ala
- 3. Protocolli e difesa
- Competenza Brain
- Controllare gli accessi (control_access)
- Riflesso Brain
- cr-028
- Schema
- G3 · Sezione anatomica
- Lingue
- de, en, es, fr, it
- Fonti
- 7 fonti verificate il 3 novembre 2026
Fonti7 fonti
- Microsoft, «What is app provisioning in Microsoft Entra ID?». https://learn.microsoft.com/en-us/entra/identity/app-provisioning/user-provisioning (consultato il 3 novembre 2026)
- Microsoft, «How Application Provisioning works in Microsoft Entra ID». https://learn.microsoft.com/en-us/entra/identity/app-provisioning/how-provisioning-works (consultato il 3 novembre 2026)
- Microsoft, «Known issues for provisioning in Microsoft Entra ID». https://learn.microsoft.com/en-us/entra/identity/app-provisioning/known-issues (consultato il 3 novembre 2026)
- MITRE ATT&CK, «User Account Management, Mitigation M1018 - Enterprise | MITRE ATT&CK®». https://attack.mitre.org/mitigations/M1018/ (consultato il 3 novembre 2026)
- MITRE ATT&CK, «Valid Accounts: Cloud Accounts, Sub-technique T1078.004 - Enterprise | MITRE ATT&CK®». https://attack.mitre.org/techniques/T1078/004/ (consultato il 3 novembre 2026)
- OWASP, «Session Management - OWASP Cheat Sheet Series». https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html (consultato il 3 novembre 2026)
- CISA, «Require Multifactor Authentication | CISA». https://www.cisa.gov/audiences/small-and-medium-businesses/secure-your-business/require-multifactor-authentication (consultato il 3 novembre 2026)
Cita questo articolo
Brain, «SCIM e provisioning automatico degli account», Cyberpedia, 2026. https:/
BibTeX
@misc{brain_cp205_it_2026,
author = {Brain},
title = {SCIM e provisioning automatico degli account},
year = {2026},
howpublished = {Cyberpedia},
url = {https://startbrain.io/cyberpedia/it/articles/scim-provisioning-automatico-uscite/},
note = {CC BY 4.0}
}