Cos’è l’entitlement management

L’entitlement management è la funzionalità di Microsoft Entra ID Governance che automatizza il ciclo di vita dell’accesso: richiesta, approvazione, assegnazione, scadenza e revisione. L’obiettivo è governare “chi ottiene cosa, con quale approvazione e per quanto tempo” senza che un amministratore assegni manualmente ogni gruppo, app o sito. È lo strumento chiave quando l’accesso deve essere self-service ma controllato, soprattutto in scenari con molti utenti (dipendenti, contractor, partner) e risorse eterogenee.

Rispetto ai gruppi dinamici o all’assegnazione diretta, l’entitlement management aggiunge un livello di policy e governance: workflow di approvazione multi-stadio, giustificazione business, tempi di validità e access review periodiche.

Catalog e access package

Catalog

Il catalog è il contenitore logico delle risorse governabili. In un catalog puoi inserire tre tipi di risorsa:

  • Gruppi (security group e Microsoft 365 group)
  • Applicazioni (enterprise app / service principal con ruoli app)
  • Siti SharePoint Online

Il catalog delimita anche il confine amministrativo e di delega: puoi assegnare catalog owner che gestiscono le risorse e access package manager che creano i pacchetti, senza dover essere Global Administrator. Questo abilita la delega a team applicativi o di business unit.

Access package

L’access package è il bundle che l’utente effettivamente richiede: un insieme di risorse (prese dal catalog) più uno o più ruoli su quelle risorse (es. membro di un gruppo, ruolo “Reader” su un’app, ruolo su un sito SharePoint). Un utente che ottiene il pacchetto riceve in blocco tutti gli accessi definiti; alla scadenza, tutti vengono rimossi automaticamente. È l’unità con cui si ragiona per job function: “Onboarding Progetto X” può racchiudere gruppo Teams, app di ticketing e sito SharePoint di progetto.

Policy: request, approval, scadenza

Ogni access package ha una o più policy che definiscono:

  • Chi può richiedere (utenti della directory, utenti di specifici gruppi, oppure utenti esterni).
  • Approvazione: nessuna, singolo approvatore, oppure multi-stage (es. manager + resource owner). Puoi richiedere giustificazione e impostare fallback approver.
  • Lifecycle / scadenza: durata dell’assegnazione (numero di giorni, data fissa o permanente) e possibilità di rinnovo/extend.
  • Access review integrate: alla policy puoi collegare access review ricorrenti che chiedono a utente, manager o resource owner di riconfermare la necessità dell’accesso. Chi non viene riconfermato perde automaticamente il pacchetto — pilastro dell’approccio least privilege e delle esigenze di compliance.

Puoi definire più policy sullo stesso access package: ad esempio una per i dipendenti interni (auto-approvazione) e una separata per i partner esterni (approvazione obbligatoria + scadenza a 90 giorni).

Accesso per utenti esterni e connected organizations

L’entitlement management gestisce nativamente la collaborazione B2B. Nella policy puoi consentire la richiesta a utenti fuori dalla directory: quando un utente esterno richiede il pacchetto, viene automaticamente creato l’account B2B guest e assegnati gli accessi; alla scadenza, l’entitlement management può anche rimuovere il guest dalla directory.

Per strutturare questo scenario si usano le connected organizations: rappresentano un’organizzazione partner (identificata dal suo tenant Entra ID, da un dominio o da un provider social/SAML) di cui ci si fida. Collegando una connected organization a una policy, si autorizza solo quel bacino di utenti esterni a richiedere il pacchetto, evitando accessi da domini arbitrari.

Trappole tipiche d’esame

  • Scenario: vuoi aggiungere un sito SharePoint a un access package ma non lo trovi nell’elenco → la risorsa deve prima essere aggiunta al catalog; un access package può includere solo risorse già presenti nel proprio catalog.
  • Scenario: l’organizzazione ha licenze Entra ID P1 e vuole usare access package con access review → serve Entra ID P2 (Entra ID Governance): entitlement management, access review e PIM sono feature P2, non P1.
  • Scenario: partner esterni devono avere accesso temporaneo a un progetto senza inviti manuali → crea una connected organization e una policy che consente utenti esterni; il guest B2B viene creato e rimosso automaticamente.
  • Scenario: dipendenti interni devono ottenere l’accesso subito, i partner solo dopo approvazione → due policy separate sullo stesso access package, con impostazioni di richiesta/approvazione diverse.
  • Scenario: serve delegare la gestione dei pacchetti a un team senza dare privilegi globali → usa i ruoli di catalog owner / access package manager, che operano solo entro il catalog delegato.