Perché l’entitlement management è un problema di architettura, non di IT operations

In uno scenario SC-100 il requisito ricorrente è: “l’organizzazione deve garantire che ogni identità — dipendenti, contractor e partner B2B — abbia solo gli accessi necessari, per il tempo strettamente necessario”. Questo è un problema di governance del ciclo di vita, e la risposta architetturale in ecosistema Microsoft è Microsoft Entra ID Governance (ex Identity Governance), che fornisce entitlement management, access review e lifecycle workflows in modo integrato.

Il valore architetturale non è “assegnare permessi”, ma rendere l’accesso auto-descrittivo, auto-scadente e auto-verificato. Allinea il pilastro Security dell’Azure Well-Architected Framework (least privilege, verifica esplicita) con Operational Excellence (automazione al posto di ticket manuali).

Access package: l’unità di delega governata

L’access package è l’astrazione centrale: raggruppa risorse eterogenee (gruppi Entra, ruoli applicativi enterprise, siti SharePoint, ruoli su Teams) dietro un unico oggetto richiedibile. Un catalog ne definisce il confine di ownership, permettendo di delegare la gestione ai resource owner di business senza dare loro Global Administrator.

Il design ruota attorno alle policy dell’access package:

  • Chi può richiedere — utenti interni, membri di uno specifico gruppo, oppure utenti esterni B2B (anche di tenant non ancora presenti, con onboarding automatico).
  • Approvazione — multi-stage, con approvatori che possono essere il manager (attributo dinamico) o sponsor esterni per i partner.
  • Lifecycle — scadenza automatica dell’assegnazione e access review ricorrente incorporata.

Trade-off chiave: self-service vs controllo centralizzato. Un modello puramente centralizzato (ogni accesso passa dal security team) uccide la produttività e crea shadow IT. Un self-service senza guardrail genera access creep. La raccomandazione architetturale è il self-service governato: l’utente richiede in autonomia dal My Access portal, ma la policy impone approvazione, scadenza e review. La produttività resta al business, il controllo resta nella policy dichiarativa.

Access review: l’antidoto all’access creep

L’access creep è l’accumulo silenzioso di permessi mai revocati quando le persone cambiano ruolo o progetto. Senza review ricorrenti, dopo 18 mesi la superficie di attacco privilegiata esplode. Le access review periodiche sono la contromisura di design:

  • Cadenza ricorrente (mensile/trimestrale) su gruppi, ruoli app, access package e soprattutto ruoli privilegiati PIM.
  • Reviewer = manager, self-review, o owner della risorsa.
  • Auto-apply: le decisioni di rimozione vengono applicate automaticamente, con opzione “remove access if reviewers don’t respond” per evitare il default permissivo.

Per gli utenti B2B la review è ancora più critica: gli ospiti restano spesso attivi dopo la fine della collaborazione. Una review dedicata agli inactive guest (integrabile con i segnali di last sign-in) è la best practice, complementare ai lifecycle workflow che disabilitano/eliminano gli account inattivi.

Separation of duties e integrazione con Conditional Access

La separation of duties (SoD) in entitlement management si esprime come incompatible access packages: se un utente detiene il pacchetto “Approvazione pagamenti”, non può richiedere “Creazione fornitori”. Il sistema blocca la richiesta a monte, prevenendo la concentrazione di privilegi tossici.

La governance da sola stabilisce cosa un’identità può ottenere; Conditional Access stabilisce a quali condizioni quell’accesso è utilizzabile. Il design integrato usa authentication context: un access package a un’app finanziaria assegna un ruolo protetto da un context che Conditional Access aggancia a MFA phishing-resistant + device compliant. Così least privilege (chi/cosa) e verifica esplicita (come/dove) lavorano insieme. Per gli accessi standing privileged, la raccomandazione è PIM con attivazione just-in-time, non assegnazione permanente: l’access package concede l’eleggibilità, PIM concede l’attivazione time-bound con giustificazione e approvazione.

Trappole tipiche d’esame

  • Requisito: partner esterni devono accedere a più risorse con onboarding automatico e scadenza garantita → NON creare guest manualmente né gruppi statici. Usa un access package con policy “for users not in your directory” e review ricorrente: onboarding, approvazione dello sponsor e offboarding sono governati end-to-end.
  • Requisito: prevenire che un utente ottenga due set di permessi in conflitto → NON affidarti a controlli manuali di audit. Configura incompatible access packages (separation of duties) in Entra ID Governance, che blocca la richiesta a monte.
  • Requisito: eliminare permessi accumulati dopo cambi di ruolo → NON basarti su offboarding manuale. Imposta access review ricorrenti con auto-apply e “remove if no response”, non review una tantum.
  • Requisito: accesso privilegiato solo quando serve, con MFA forte → NON assegnare il ruolo in modo permanente. Combina access package (eleggibilità) + PIM (attivazione JIT) e un Conditional Access authentication context per MFA phishing-resistant.
  • Requisito: guest inattivi da mesi ancora attivi → NON limitarti a una policy di password. Usa access review sugli inactive guest più lifecycle workflow basati su last sign-in per disabilitare/rimuovere.