Progettare l’autorizzazione in Azure significa decidere chi può fare cosa, dove e per quanto tempo. Su AZ-305 la domanda non è “come assegno un ruolo”, ma “dato questo requisito di sicurezza e operatività, quale modello di accesso minimizza il rischio mantenendo l’agilità”. La risposta ruota attorno a tre leve architetturali: Azure RBAC, Microsoft Entra Privileged Identity Management (PIM) e l’identity governance (access review, entitlement management). Diamo per acquisiti i meccanismi base — cosa siano un ruolo eligible o una access review — e concentriamoci sulle decisioni di design e sui trade-off.

RBAC: built-in vs custom e scelta dello scope

Un’assegnazione RBAC è la tripletta security principal + role definition + scope. In fase di design il vincolo dominante è il least privilege del pilastro Security del Well-Architected Framework, ma va bilanciato con il costo di manutenzione.

Built-in vs custom role. Parti sempre da un built-in (Reader, Contributor, Owner, o ruoli mirati come Virtual Machine Contributor, Storage Blob Data Reader). Un custom role si giustifica solo quando nessun built-in aderisce: un sottoinsieme ristretto di Actions/DataActions, o l’esclusione di operazioni sensibili con NotActions. Il trade-off è chiaro: ogni custom role va manutenuto al comparire di nuovi resource provider e operazioni, e hai un limite di 5.000 custom role per tenant. Regola di design: preferisci built-in granulari a un Contributor generico; scendi a custom role solo per chiudere il gap residuo, e definiscilo allo scope AssignableScopes più stretto possibile.

Scelta dello scope ed ereditarietà. Lo scope è gerarchico — management group → subscription → resource group → resource — e le assegnazioni si ereditano verso il basso. Assegnare in alto amplifica il raggio d’azione: un Contributor sul management group tocca tutte le subscription figlie. In un contesto di landing zone (Cloud Adoption Framework) questa gerarchia è la spina dorsale del design: ruoli di piattaforma sui management group Platform, ruoli di workload sulle subscription applicative, il resource group come unità di collaborazione del singolo workload. Applica separation of duties: chi gestisce networking e policy centrali non deve avere Owner sui workload, e viceversa. Ricorda che deny assignment e resource lock non sono RBAC ma vi interagiscono — un lock CanNotDelete frena anche un Owner distratto.

PIM: da standing access a just-in-time a scala

A livello architetturale PIM non è “attivare un ruolo on-demand”, ma la strategia per eliminare lo standing access sui ruoli ad alto impatto in un tenant enterprise. La decisione di design è quali ruoli rendere eligible, a quale scope e con quali controlli.

PIM copre due domini con trade-off diversi. Per i ruoli Entra ID (Global Administrator, Security Administrator) il rischio è tenant-wide: imponi approvazione, MFA e activation brevi, e valuta break-glass account esclusi da PIM per il recovery. Per i ruoli risorsa Azure puoi assegnare l’eligibilità direttamente sui management group, così l’ereditarietà propaga il just-in-time su intere gerarchie di subscription senza replicare la configurazione. Design tipico: eligibilità con approver sugli Owner di subscription di produzione, activation di poche ore, alert sulle attivazioni anomale, e ruoli permanenti solo a basso privilegio (Reader). Il trade-off è UX vs rischio: introduci frizione controllata dove il blast radius è massimo. PIM richiede Entra ID P2.

Identity governance: entitlement management a scala enterprise

Il least privilege degrada nel tempo (role creep): la governance ne chiude il ciclo di vita, e in ottica architect il fulcro è l’entitlement management più che la singola review.

  • Access package: raggruppano gruppi, app e ruoli con policy di richiesta/approvazione/scadenza differenziate per popolazione. Progetta pacchetti distinti per dipendenti interni e per partner B2B tramite connected organizations, ciascuno con approver e review propri: è la risposta ai requisiti di onboarding/offboarding a scala.
  • Access review ricorrenti sulle assegnazioni privilegiate e sulle membership, con esito automatico, per soddisfare la ricertificazione periodica richiesta dalla compliance.

Regola di design trasversale: assegna gli accessi tramite gruppi Entra ID (o gruppi role-assignable), mai a utenti singoli. Semplifica audit, review e automazione, e rende la landing zone governabile.

Trappole tipiche d’esame

  • “Ambiente multi-subscription: il team di piattaforma deve gestire il networking di tutte le landing zone, ma non deve toccare i workload applicativi” → ruolo (built-in o custom) sui management group Platform/Connectivity, non Owner ereditato che violerebbe la separation of duties.
  • “Gli Owner di produzione devono essere just-in-time, con approvazione, su decine di subscription, minimizzando la configurazione” → PIM per ruoli Azure con eligibilità sul management group padre, sfruttando l’ereditarietà; non configurare subscription per subscription.
  • “Serve concedere a un gruppo di partner esterni un set coerente di app e gruppi, con approvazione e scadenza automatica, gestito dal loro referente” → entitlement management con access package e connected organization; non inviti guest manuali né assegnazioni dirette.
  • “Un requisito impone un ruolo con esattamente due data action sul blob storage e nient’altro” → custom role con i soli DataActions, AssignableScopes ristretto; non allargare a Storage Blob Data Contributor.
  • “Riduci il numero di custom role da manutenere senza perdere granularità” → ricomponi con built-in granulari combinati su scope diversi; il custom role è debito operativo da limitare.
  • “Gli accessi privilegiati vanno ricertificati ogni trimestre dai rispettivi owner” → access review ricorrenti sui ruoli PIM (Entra ID P2), con auto-apply dell’esito; non controlli manuali.