• Cloud, Guide, Sicurezza
• 24 Aprile 2026

Quando lavoriamo in Azure può capitare una situazione apparentemente strana: siamo Global Administrator, ma non abbiamo accesso alle subscription. Non è un errore, è una scelta precisa di Microsoft Entra ID, dove i ruoli di directory sono separati da quelli di Azure RBAC.

Per colmare temporaneamente questo “gap” esiste Elevate Access. Attivandolo, ci assegniamo il ruolo di User Access Administrator a livello globale, ottenendo visibilità su tutte le risorse e la possibilità di gestire i permessi ovunque. In pratica, possiamo darci accesso a qualsiasi subscription.

Qui però sta il punto: è una funzionalità molto potente e va usata solo quando serve davvero. Pensiamo a scenari di recupero accesso, audit o emergenze. Non è pensata per l’uso quotidiano. Una volta finito, è fondamentale disattivarla subito.

Per la gestione normale, la strada corretta è usare Microsoft Entra Privileged Identity Management, che permette accessi temporanei, tracciati e controllati. Insieme a una buona struttura di RBAC e Management Group, evita completamente la necessità di elevare i privilegi.

Elevate Access è uno strumento di emergenza: utile, ma da usare con disciplina. La vera buona pratica è costruire un ambiente in cui non ci serve quasi mai.

Figura 1: Con Elevate Access il Global Administrator viene esteso al livello root di Azure RBAC, ottenendo la possibilità di gestire gli accessi su tutta la gerarchia delle risorse.

Attivare Elevate Access per ottenere il controllo globale sugli accessi Azure

Per attivare Elevate Access dobbiamo prima accedere al portale di Entra ID con un account che abbia il ruolo di Global Administrator. Se stiamo utilizzando Microsoft Entra Privileged Identity Management, ricordiamoci di attivare il ruolo prima di procedere, altrimenti l’opzione non sarà disponibile.

Navighiamo in Microsoft Entra ID nella sezione Overview e selezioniamo la scheda Properties. Qui troviamo l’impostazione Access management for Azure resources, che rappresenta il punto chiave di tutta la configurazione.

Quando impostiamo il toggle su Yes, stiamo attivando l’elevazione. In modo automatico ci viene assegnato il ruolo di User Access Administrator a livello root, quindi sull’intero tenant. Questo ci permette di assegnare ruoli su tutte le subscription e i management group, anche se in precedenza non avevamo accesso. È importante sottolineare che questa opzione è disponibile solo per chi ha il ruolo di Global Administrator.

Quando invece riportiamo il toggle su No, il sistema rimuove questo ruolo dal nostro account. Torniamo quindi alla situazione standard, dove possiamo operare solo sulle risorse per cui abbiamo esplicitamente ricevuto accesso tramite RBAC.

Figura 2: Elevate Access attivo: il Global Administrator ha ora visibilità e controllo sugli accessi di tutte le subscription e management group del tenant

C’è un aspetto da tenere bene a mente: questa impostazione non è globale. Si applica solo all’utente con cui siamo autenticati in quel momento. Questo significa che non possiamo estendere Elevate Access automaticamente a tutti i Global Administrator, ma ogni utente deve attivarlo in modo esplicito.

Una volta salvata la configurazione, è necessario eseguire sign-out e sign-in per aggiornare il token di accesso. Solo dopo questo passaggio vedremo realmente gli effetti dell’elevazione.

Da questo momento in poi avremo visibilità completa su tutte le subscription e i management group del tenant. Se andiamo nella sezione Access control (IAM), noteremo che il nostro account è stato assegnato al ruolo di User Access Administrator a livello root, confermando che l’elevazione è attiva.

Figura 3: Il ruolo User Access Administrator assegnato a livello Root (Inherited) conferma che Elevate Access è attivo e che i permessi sono propagati su tutta la gerarchia Azure

Monitorare le operazioni di Elevate Access nei log di audit

Quando attiviamo o rimuoviamo Elevate Access, ogni operazione viene tracciata nei log di Microsoft Entra ID. Questo ci permette di verificare rapidamente chi ha elevato l’accesso e quando.

Gli eventi sono visibili sia nei directory audit logs sia negli Azure activity logs, ma i log di Entra risultano più semplici da filtrare ed esportare. Possiamo anche integrarli con soluzioni come Microsoft Sentinel per creare alert automatici su operazioni così sensibili.

Figura 4: I log di audit consentono di tracciare in modo semplice e immediato l’attivazione e la rimozione di Elevate Access

Rilevare Elevate Access con Microsoft Sentinel

Per aumentare la visibilità e intercettare eventuali utilizzi sospetti di Elevate Access, possiamo integrare i log di Microsoft Entra ID con Microsoft Sentinel.

L’idea è semplice: portiamo gli Audit Logs all’interno di Sentinel, così da poterli analizzare e correlare con altri eventi di sicurezza. In questo modo possiamo costruire regole di detection e generare alert automatici ogni volta che qualcuno attiva o rimuove l’elevazione.

La configurazione richiede di collegare Entra a Sentinel tramite il relativo data connector, assicurandoci che i log di audit vengano raccolti correttamente. Una volta fatto, abbiamo a disposizione tutte le informazioni necessarie per monitorare queste operazioni in modo centralizzato.

La configurazione completa di Sentinel esula da questa guida. Per approfondire, trovate una panoramica qui: Introduzione a Microsoft Sentinel – ICT Power

Figura 5: Integrando i log di audit di Entra con Microsoft Sentinel possiamo rilevare e monitorare automaticamente le operazioni di Elevate Access

Creare una regola di rilevamento per Elevate Access

Una volta portati i log in Microsoft Sentinel, possiamo fare il passo successivo: trasformare questi eventi in rilevazioni automatiche.

Nel portale troviamo già un template pronto chiamato Azure RBAC (Elevate Access). Selezionandolo, possiamo creare una regola di tipo scheduled che analizza i log di Microsoft Entra ID e intercetta ogni operazione di elevazione.

Il vantaggio è che non dobbiamo costruire query complesse da zero. Utilizziamo il template, creiamo la regola con le impostazioni di default e iniziamo subito a monitorare questi eventi in modo strutturato.

Da questo momento in poi, ogni attivazione di Elevate Access può generare un evento rilevato da Sentinel, permettendoci di reagire rapidamente e mantenere il controllo su un’operazione così critica.

Figura 6: Il template Azure RBAC (Elevate Access) in Microsoft Sentinel consente di creare rapidamente una regola per rilevare automaticamente le operazioni di elevazione dei privilegi

A questo punto entriamo nel wizard di creazione della regola in Microsoft Sentinel. Come possiamo vedere, il template Azure RBAC (Elevate Access) è già preconfigurato con i parametri principali, inclusa una severità High.

In questo scenario non è necessario complicarsi la vita: possiamo procedere utilizzando le impostazioni di default, che sono già adeguate a rilevare gli eventi di elevazione nei log di Microsoft Entra ID.

L’obiettivo qui non è personalizzare subito la detection, ma attivare rapidamente un meccanismo di monitoraggio efficace. Eventuali ottimizzazioni possono essere fatte in un secondo momento, una volta che abbiamo visibilità sui dati reali.

Figura 7: Il wizard di Sentinel consente di creare rapidamente la regola Azure RBAC (Elevate Access) utilizzando le impostazioni predefinite

Arrivati all’ultimo step del wizard in Microsoft Sentinel, possiamo rivedere rapidamente la configurazione della regola. Qui vediamo tutti i parametri principali, dalla query utilizzata fino alla frequenza di esecuzione.

Se abbiamo seguito il template Azure RBAC (Elevate Access) senza modifiche, la configurazione è già pronta per l’uso. Non resta che confermare e salvare la regola.

Da questo momento Sentinel inizierà a monitorare automaticamente i log di Microsoft Entra ID e a generare eventi ogni volta che viene rilevata un’operazione di Elevate Access.

Figura 8: Con il salvataggio finale attiviamo la regola di Sentinel, che inizierà a rilevare automaticamente gli eventi di Elevate Access nei log

Figura 9: Regola Azure RBAC (Elevate Access) attiva in Sentinel

Analizzare gli incidenti di Elevate Access

Una volta attiva la regola, gli eventi di Elevate Access non rimangono più solo nei log, ma diventano veri e propri incidenti in Microsoft Sentinel.

Nella sezione Incidents possiamo vedere immediatamente quando viene rilevata un’elevazione. Ogni evento viene classificato con una severità, in questo caso High, e contiene tutte le informazioni utili per l’analisi, come l’utente coinvolto, il timestamp e i dettagli dell’operazione.

Questo è il passaggio che fa davvero la differenza: non stiamo più solo monitorando, ma siamo in grado di investigare e reagire. Possiamo aprire l’incidente, analizzarne il contesto e capire rapidamente se si tratta di un’attività legittima o di qualcosa di sospetto.

Figura 10: Gli eventi di Elevate Access vengono trasformati in incidenti in Microsoft Sentinel, permettendo analisi e risposta tempestiva

Investigare un incidente di Elevate Access

Aprendo un incidente in Microsoft Sentinel entriamo nella fase più operativa: l’analisi dettagliata dell’evento di Elevate Access.

Qui possiamo vedere tutte le informazioni rilevanti, dalla timeline dell’incidente fino alle entità coinvolte, come l’utente che ha eseguito l’operazione. Questo ci permette di ricostruire rapidamente il contesto e capire se l’elevazione è stata eseguita per un motivo legittimo o se rappresenta un potenziale rischio.

Il valore di questa vista è proprio nella centralizzazione: non dobbiamo più cercare nei log, ma abbiamo tutto in un unico punto, pronto per essere analizzato e, se necessario, gestito con azioni di risposta.

Figura 11: La vista dettagliata dell’incidente in Sentinel consente di analizzare timeline ed entità per investigare rapidamente un evento di Elevate Access

Conclusioni

Elevate Access è una funzionalità estremamente utile, ma va trattata per quello che è: uno strumento di emergenza. Ci permette di recuperare il controllo e gestire gli accessi a livello globale, ma introduce anche un livello di privilegio molto elevato che deve essere gestito con attenzione.

La vera best practice è usarlo solo quando necessario e affidarci per il resto a un modello basato su RBAC, governance e strumenti come Microsoft Entra Privileged Identity Management.

Integrando i log con Microsoft Sentinel possiamo inoltre fare un passo avanti, passando da una gestione reattiva a un approccio proattivo, in cui ogni operazione sensibile viene monitorata e rilevata automaticamente.