Gestire l’accesso alle risorse tramite Azure AD Entitlement Management

Azure AD Entitlement Management è una importante funzionalità di Identity Governance ed è di cruciale importanza nell’automazione delle richieste di accesso alle risorse.

Il mondo è diventato un posto piuttosto dinamico e questo si riflette anche sul lavoro: nuovi progetti arrivano costantemente e il cambiamento è all’ordine del giorno. Questo dinamismo rende difficile alle aziende e alle organizzazioni, soprattutto quelle più grandi e complesse, di tenere traccia di chi deve avere accesso alle giuste risorse, per il giusto periodo di tempo. Questa difficoltà causa molteplici problemi visibili nell’operatività di tutti i giorni, dai nuovi utenti che non hanno i privilegi corretti per svolgere il loro lavoro, a persone già inserite che dopo aver cambiato ruolo continuano ad avere accesso a risorse per le quali non hanno più ragione di accedere. Non è quindi solo una questione di produttività e di governance ma anche di sicurezza.

Se fino a quando l’azienda era confinata dietro al firewall perimetrale ed il numero di sistemi ed integrazioni era esiguo era ancora praticabile che l’accesso alle risorse fosse governato centralmente dall’IT, adesso è necessario un modello in cui siano i responsabili di reparto ad essere (appunto) responsabili di quali dei loro collaboratori devono accedere a determinate risorse assegnate al loro reparto.

Il tutto viene ulteriormente aggravato dalla collaborazione con gli utenti di altre organizzazioni: spesso gli utenti esterni non sanno quali sono i responsabili delle risorse a cui devono accedere e non sempre sono chiare le regole tramite le quali l’accesso viene assegnato e revocato.

Utilizzando la funzionalità Entitlement Management di Azure AD è possibile governare questi processi autorizzativi tramite la creazione e la pubblicazione di Access Packages.
Un access package è un insieme di risorse e dei relativi privilegi, definiti resource role, tramite i quali gli utenti ottengono accesso alle risorse a loro necessarie per lavorare.
Il processo tramite il quale l’accesso viene approvato, rifiutato oppure revocato quando esso scade è chiamato policy.

Figura 1 – Access Package

Tramite un access package è possibile governare l’accesso delle seguenti risorse:

  • Appartenenza ad un Gruppo di Sicurezza in Azure AD
  • Appartenenza ad un Gruppo di Microsoft 365 / Team
  • Assegnazione di una Enterprise Application in Azure AD, oppure di applicazioni federate tramite SSO
  • Appartenenza ai ruoli di un Site di SharePoint Online (nel caso in cui non sia connesso a un Gruppo di Office 365 / Team)

Ci sono alcune circostanze in cui Entitlement Management non è in grado di gestire l’appartenenza ad un gruppo:

  • Gruppi di Sicurezza dinamici -> in quanto l’appartenenza ad un gruppo dinamico è garantita dalla query che popola il gruppo, Entitlement Management non può aggiungere membri direttamente al gruppo
  • Gruppi di Sicurezza sincronizzati da Active Directory Domain Services tramite AD Connect -> in quanto in un gruppo sincronizzato l’appartenenza al gruppo proviene dal sistema on-premises

È evidente che Entitlement Management è un sistema pensato principalmente per le risorse cloud, questo fatto non ci deve stupire: oramai moltissimi oggetti presenti in Azure AD vivono solo lì e non esiste una controparte on-premises per essi, neanche tramite meccanismi di write-back.

Gli Access Package sono raggruppati in Catalogs: un catalog è l’insieme di risorse alle quali uno o più access packages possono attribuire accesso e rappresentano il confine all’interno del quale è possibile implementare la delega di privilegio.

Figura 2 – Architettura degli Access Packages e loro relazioni

I Global Administrators e gli User Administrators possono agire su Entitlement Management senza restrizioni, ma la piattaforma è pensata per essere utilizzata in maniera distribuita tra differenti ruoli per meglio adattarsi alle necessità dei vari dipartimenti:

  • Catalog Creator: possono creare nuovi catalog e aggiungere ad esso risorse di cui loro sono proprietari. Un Catalog Creator è proprietario dei catalog da lui creati e può designare altri Owner. Un Catalog Creator può visualizzare ed agire solo sui catalog da lui creati.
  • Catalog Owner: possono modificare i catalog esistenti, aggiungendo le risorse di cui sono proprietari (con l’eccezione per i Siti di SharePoint
    non collegati ad un gruppo). Se devono aggiungere una risorsa di cui non sono proprietari devono richiedere assistenza ad un membro dell’IT con i privilegi appropriati.
  • Access Package Manager: possono creare nuovi access package, modificare le assegnazioni dei resource role, modificare le policy ed assegnare e rimuovere gli utenti.
  • Access Package Assignment Manager: possono solo modificare le assegnazioni degli access package già presenti, ad esempio:
    • Assegnare direttamente gli access package
    • Approvare le richieste
    • Rimuovere le assegnazioni dagli access package
    • Analizzare gli errori di assegnazione
    • Riprocessare le assegnazioni

La Figura 3 rappresenta una gerarchia di delega in Entitlement Management illustrando i vari oggetti che è possibile delegare nei ruoli qui sopra esposti.

Figura 3 – Esempio di delegazione in Entitlement Management

Per poter utilizzare Entitlement Management è necessario avere a disposizione la licenza Azure Active Directory Premium P2, oppure un’offerta che la comprende come Enteprise Mobility + Security E5 oppure Microsoft 365 E5.

Uso di Entitlement Management – dimostrazione

Per dimostrare il funzionamento di Entitlement Management abbiamo creato uno scenario fittizio, descritto qui di seguito:

Nella nostra Organizzazione esiste un reparto Marketing, composto da

  • Manuel è il capo del Marketing ed è quindi il Catalog Creator: lui creerà il catalogo ed inserirà (o farà inserire all’IT) le risorse di cui è responsabile.
  • Mario e Simone sono rispettivamente i responsabili dei dipartimenti di Customer Satisfaction e Campaigns, sono quindi degli Access Package Managers: loro saranno delegati da Manuel a creare gli access package per gli scopi dei loro progetti.
  • Luca e Xin sono due dipendenti del reparto Marketing e possono essere assegnati a progetti differenti in base alla loro mansione.

Tutti gli utenti del reparto Marketing fanno parte di un gruppo dinamico in Azure AD chiamato MarketingUsers e popolato da una query che inserisce nel gruppo tutti gli utenti con attributo Department = Marketing.

Il reparto Marketing ha assegnato queste risorse:

  • SPO Sites (noncollegati a Gruppi di Microsft 365):
    • Product Launches
    • Customer Survey
  • Teams:
    • Marketing Team
    • Customer Satisfaction
  • Applications:
    • Company ERP

Le risorse devono essere assegnate agli utenti in questo modo:

  • Customer Satisfaction-> Customer Survey, Marketing Team, Customer Satisfaction, Company ERP
  • Campaigns-> Product Launches, Marketing Team, Company ERP

Per cominciare è necessario delegare a Manuel il ruolo di Catalog Creator, per fare ciò un Global Admin dovrà portarsi sul portale di amministrazione di Azure AD
https://aad.portal.azure.com -> andare su Identity Governance -> Settings -> premere Modify -> Catalog creators ed aggiungere l’utente desiderato

Figura 4 – Delega ad un Catalog Creator

Per assicurarsi che il Catalog Creator possa accedere al pannello di amministrazione di Azure AD è necessario verificare che non sia stata modificata l’impostazione “Restrict access to Azure AD administrazion portal“. La trovate sotto “User Settings” nel portale di amministrazione e, in linea generale, vi raccomando di non restringere l’accesso al portale di amministrazione in quanto gli utenti normali non possono fare in ogni caso alcuna modifica e le directory sono pensate per essere contenitori di dati pubblici (con poche eccezioni come le credenziali che sono in ogni caso mascherate).

Figura 5 – Restrizione portale amministrazione AAD

Ora che Manuel è Catalog Creator può loggarsi nel portale e procedere alla creazione del suo catalog. Notate che nonostante esista un catalog di default, Manuel non lo può vedere perché non ne è Owner.

Figura 6 – Creazione del Catalog

Ecco come si presenta il Catalog appena creato, senza risorse assegnate. Il pulsante Resources, evidenziato nella Figura 7, è il posto da dove Manuel gestirà le risorse del suo catalog.

Figura 7 – Catalogo appena creato

Manuel potrà aggiungere al catalogo solo risorse di cui è proprietario, siccome non è proprietario dell’AppCompany ERP” riceverà un errore e dovrà chiedere al supporto IT di aggiungerla per suo conto.

Figura 8 – Errore aggiunta App: non sei l’owner

Potrà poi proseguire aggiungendo le risorse mancanti

Figura 9 – Aggiunta risorse

Ecco come si presenterà il suo Catalog, una volta aggiunte tutte le risorse desiderate

Figura 10 – Aggiunte tutte le risorse

È il momento per Manuel (riferitevi sempre all’avatar dell’utente in alto a destra nelle immagini per comprendere, in questa demo, quale utente sta lavorando sul portale) di delegare gli Access Package Managers

Figura 11 – Delega degli Access Package Managers

A questo punto il lavoro del Catalog Creator è terminato e gli Access Package Manager possono iniziare il processo di creazione degli Access Packages.
Adesso nel portale è loggato Mario che procederà alla creazione del primo Access Package

Figura 12 – Creazione del primo Access Package

Assegnare un nome ed una descrizione al Access Package ed inserirlo in un Catalog. Gli unici catalog che verranno visualizzati saranno quelli per il quale l’Access Package Manager è stato delegato.

Figura 13 – Nome e selezione del Catalog

Aggiungere quindi le applicazioni necessarie all’Access Package ed assegnare i ruoli specifici. Gli utenti otterranno l’accesso specificato quando verranno approvati a questo Access Package. Solo le applicazioni presenti nel Catalog sono selezionabili.

Figura 14 – Aggiunta applicazioni e definizione ruoli

È arrivato il momento di definire le policy tramite le quale gli utenti richiederanno accesso all’Access Package.
In questo esempio solo gli utenti che fanno parte del gruppo dinamico MarketingUsers potranno richiedere l’assegnazione di questo Access Package e non servirà l’approvazione, la richiesta verrà quindi approvata automaticamente dal sistema.

Figura 15 – First Policy Customer Satisfaction

L’assegnazione di questo Access Package scade dopo 6 mesi e gli utenti possono estendere l’accesso prima della scadenza. Abbiamo deciso di non creare una Access Review per controllare periodicamente l’appartenenza dei membri.

Figura 16 – Lifecycle settings

Infine, controllare le scelte fatte e procedere alla creazione della policy.

Figura 17 – Rivedere e creare la policy per gli utenti interni

In maniera simile a quanto appena fatto da Mario, anche Simone procederà alla creazione di un suo Access Package. A differenza della precedente Policy in questo caso Simone ha deciso che per ottenere accesso al Package sarà necessario fornire una giustificazione ed ottenere la sua approvazione.

Figura 18 – Policy Access Package Customer Surveys

Adesso è possibile provare la funzionalità dalla parte dell’utente: portandosi su https://myaccess.microsoft.com l’utente potrà visualizzare gli Access Packages ai quali può richiedere accesso.

In questo esempio Luca richiederà accesso all’Access Package “Customer Satisfaction Access Package” premendo sul pulsante “+ Request access

Figura 19 – Richiesta Access Package

Verrà richiesta la Business justification, come configurato da Policy ed opzionalmente l’utente potrà richiedere il package per un periodo di tempo specifico, ad esempio fino alla scadenza della sua assegnazione per quel progetto.

Figura 20 – Assegnazione per un tempo determinato

Una volta inviata la richiesta di approvazione inizierà il processo tramite il quale essa verrà approvata. Siccome la Policy di questo Access Package non ha approvatori esso verrà automaticamente approvato dal sistema e entrerà nel processo di delivery: in base al numero di risorse assegnate la durata di questo passo può variare.

Figura 21 – Delivery in corso

Una volta processata la richiesta il sistema, tramite una e-mail, informa l’utente che l’accesso è disponibile.

Figura 22 – E-mail di Benvenuto

Lo stato è anche consultabile nella tab “Request history” del portale MyAccess.

Figura 23 – Stato richiesta nel portale MyAccess

Gli Access Package Managers potranno consultare e gestire l’appartenenza agli Access Package tramite le tab “Assignments” e “Requests” dal portale di Identity Governance.

Figura 24 – Gestire le assegnazioni dal portale ELM

Per terminare la dimostrazione ci rimane da illustrare il processo di approvazione quando una richiesta è configurata per essere approvata da un moderatore: per fare ciò Xin richiederà l’Access Package Survey Campaigns” che era stato configurato da Simone per richiedere l’approvazione.
Come si può notare dalla Figura 25 esso rimane nello stato “Pending approval

Figura 25 – Richiesta Access Package con moderazione

Simone dovrà quindi accedere al MyAccess, rivedere ed infine approvare la richiesta.

Figura 26 – Simone approva la richiesta

Una volta approvata, il flusso procede come già visto in precedenza.

Figura 27 – Richiesta approvata in consegna

Conclusioni

Azure AD Entitlement Management è una importante funzionalità di Identity Governance ed è di cruciale importanza nell’automazione delle richieste di accesso alle risorse. Data la velocità con la quale si muovono le organizzazioni oggi non è più pensabile di gestire tali accessi tramite processi manuali siano essi cartacei oppure informatizzati. Un semplice ticket per richiedere l’accesso ad una risorsa (come spesso vediamo nelle organizzazioni) non è una funzionalità di Entitlement Management, è solamente un processo cartaceo trasformato in un qualcosa di digitale, non è un processo nato digitalmente.

È quindi importante che le Organizzazioni, per sfruttare le opportunità offerte dal cloud, facciano una riflessione profonda sui loro processi e li trasformino alla luce delle nuove tecnologie.

Alla pagina What is Azure AD entitlement management? è disponibile la documentazione ufficiale del prodotto e molte risorse video per guidare i delegati nelle loro funzioni.

Se siete interessati ad estendere le funzionalità di Entitlement Management ai Guest Account potete consultare l’articolo Gestire l’accesso dei Guest Account alle risorse tramite Azure AD Entitlement Management