Cos'è la gestione dell'accesso privilegiato in Azure?
L'accesso privilegiato Azure è l'insieme di identità, ruoli, policy e workflow che controllano il potere amministrativo in Microsoft Entra ID, Microsoft 365, Azure e i servizi collegati. In Microsoft Entra ID, ruoli come Amministratore Globale, Amministratore di Ruolo Privilegiato, Amministratore dell'Accesso Condizionale, Amministratore della Sicurezza e Amministratore delle Applicazioni possono modificare le impostazioni di sicurezza, assegnare privilegi, gestire applicazioni o creare percorsi di accesso duraturi.
Questo rende l'accesso privilegiato un problema del piano di controllo del tenant. Un'identità privilegiata compromessa può modificare le policy di Accesso Condizionale, aggiungere o modificare assegnazioni di ruolo, registrare applicazioni, alterare i metodi di autenticazione e indebolire i controlli su cui i difensori fanno affidamento durante la risposta a un incidente.
Privileged Identity Management (PIM) riduce l'esposizione permanente permettendo agli amministratori di usare assegnazioni idonee e attivazione a tempo invece di mantenere ruoli potenti sempre attivi. PIM non è solo una funzionalità dell'interfaccia. È un modello di controllo: attivare solo quando necessario, richiedere un'autenticazione più forte o un'approvazione quando appropriato, registrare il motivo, e rivedere il ruolo dopo l'uso.
Come fallisce l'accesso privilegiato Azure
Gli stessi fallimenti dell'accesso privilegiato ricorrono nei tenant reali:
- troppi Amministratori Globali
- assegnazioni di ruolo permanenti dove basterebbero assegnazioni idonee
- account admin senza copertura di autenticazione forte
- account di emergenza che esistono ma non vengono monitorati né testati
- service principal e applicazioni privilegiate esclusi dalle revisioni degli admin umani
- PIM distribuito per alcuni ruoli ma non per quelli che interessano gli attaccanti
- esclusioni di Accesso Condizionale che rimuovono gli account admin dal percorso di controllo previsto
Il rischio non dipende solo dal numero di amministratori. Un tenant con pochi Amministratori Globali può restare esposto se quelle identità sono permanenti, phishabili, riutilizzate per il lavoro quotidiano, o escluse dalle policy. Un tenant con molti amministratori con ambito ristretto può essere più sicuro se ogni ruolo è giustificato, idoneo, monitorato e protetto con autenticazione forte.
Perché Amministratore Globale è diverso
Microsoft documenta Amministratore Globale come un ruolo altamente privilegiato che può leggere e modificare quasi tutte le impostazioni amministrative in Microsoft Entra ID, con poche eccezioni, e che può anche leggere e modificare quasi tutte le impostazioni amministrative di Microsoft 365. Amministratore Globale può anche elevare l'accesso in alcuni scenari. Questo lo distingue da un ruolo operativo ristretto come Amministratore Utenti o Lettore di Report.
Usa il ruolo con il minor privilegio in grado di completare l'attività. Se il lavoro riguarda il consenso alle applicazioni, un cambiamento dell'Accesso Condizionale, l'amministrazione di Exchange o un'indagine di sicurezza, assegna il ruolo che corrisponde al compito invece di ricorrere di default ad Amministratore Globale. Questo riduce il raggio d'impatto quando un account, una sessione o un workflow di approvazione fallisce.
La catena di attacco
Passo 1 - Enumerare l'accesso privilegiato
Un attaccante con visibilità in lettura sulla directory spesso inizia enumerando ruoli di directory, membri dei ruoli, gruppi privilegiati, applicazioni e service principal. Cerca account con potere permanente, autenticazione debole, o proprietari inattivi.
Passo 2 - Puntare al percorso admin più debole
Il bersaglio più facile potrebbe non essere l'ovvio Amministratore Globale. Potrebbe essere un Amministratore di Ruolo Privilegiato obsoleto, un proprietario di applicazione con permessi app ampi, un account di emergenza con scarso monitoraggio, o un account admin escluso dall'Accesso Condizionale a causa di un'interruzione passata.
Passo 3 - Convertire l'accesso in persistenza
Una volta ottenuto l'accesso privilegiato, l'attaccante può provare ad aggiungere un'altra assegnazione di ruolo, cambiare i metodi di autenticazione, indebolire una policy, creare una credenziale applicativa, o aggiungere un percorso di permessi per un service principal. Il percorso di persistenza dipende dai ruoli detenuti dall'identità compromessa.
Passo 4 - Nascondersi nell'amministrazione legittima
I cambiamenti privilegiati sono spesso rari ma legittimi. Gli attaccanti ne traggono vantaggio quando il tenant non ha una baseline su chi attiva PIM, chi approva le richieste, quali account dovrebbero essere permanenti, e quali applicazioni possono detenere un privilegio elevato.
Rilevamento
Eventi dei log di audit di Entra ID
Monitora i cambiamenti amministrativi che alterano il piano di controllo del tenant:
| Area operativa | Cosa esaminare |
|---|---|
| Assegnazioni di ruolo | Nuovi membri aggiunti a ruoli privilegiati, in particolare Amministratore Globale e Amministratore di Ruolo Privilegiato |
| Attività PIM | Attivazioni, approvazioni, richieste negate, e cambiamenti alle impostazioni del ruolo |
| Metodi di autenticazione | Cambiamenti ai metodi di autenticazione degli utenti privilegiati |
| Accesso Condizionale | Creazione, modifica, eliminazione di policy, o cambiamenti alle esclusioni |
| Applicazioni | Nuove registrazioni app, nuove credenziali, nuovi proprietari, e consenso ad alto privilegio |
| Account di emergenza | Qualsiasi accesso, cambio credenziale, o cambio ruolo |
Segnali di attività PIM
PIM dovrebbe rendere il privilegio più osservabile. Esamina:
- attivazioni fuori dagli orari lavorativi o dalle finestre di manutenzione normali
- attivazioni per ruoli che l'utente non usa normalmente
- attivazioni senza una giustificazione utile dove la giustificazione è richiesta
- approvazioni da parte di un approvatore inatteso
- attivazioni ripetute da account che mostrano anche segnali di rischio di accesso
- assegnazioni permanenti create dopo un rollout di PIM
Limiti del rilevamento
Non trattare un singolo evento di audit come prova di compromissione. Un'assegnazione di ruolo potrebbe far parte di un progetto legittimo. L'alert dovrebbe includere contesto: attore, target, ruolo, tipo di assegnazione, durata dell'attivazione, percorso di approvazione, dispositivo, posizione, livello di rischio, e se l'utente svolge normalmente quel ruolo.
Rimedio
L'obiettivo non è eliminare tutta l'amministrazione. L'obiettivo è eliminare il privilegio permanente non necessario e rendere l'accesso privilegiato esplicito, a tempo, fortemente autenticato e verificabile.
1. Ridurre il numero di Amministratori Globali
Elenca tutte le assegnazioni di Amministratore Globale e classifica ogni account:
- amministratore umano normale
- account di accesso di emergenza
- account di servizio o identità di automazione
- account obsoleto
- identità esterna o guest
- proprietario sconosciuto
Gli amministratori umani normali di solito non dovrebbero avere bisogno di un Amministratore Globale attivo permanente. Convertili in ruoli più ristretti o assegnazioni idonee tramite PIM dove licenza e operatività lo consentono. Tieni separata l'eccezione dell'accesso di emergenza invece di trattarla come un modello amministrativo di routine.
2. Configurare le impostazioni di ruolo di PIM
Per i ruoli ad alto valore, configura deliberatamente le impostazioni PIM:
- assegnazione idonea invece che permanente attiva per gli admin normali
- durata dell'attivazione adeguata al ruolo
- contesto di autenticazione MFA o Accesso Condizionale all'attivazione dove richiesto
- approvazione per i ruoli particolarmente sensibili
- giustificazione aziendale e informazioni di ticket dove il processo richiede tracciabilità
- notifiche al team proprietario del ruolo
- revisioni di accesso regolari per le assegnazioni permanenti e idonee
Le impostazioni di ruolo PIM di Microsoft supportano controlli come approvazione, giustificazione, informazioni di ticket, e durata dell'assegnazione. Le informazioni di ticket sono un campo informativo, non una validazione automatica rispetto a un sistema di ticketing, quindi non presumere che da sole provino l'autorizzazione del cambiamento.
3. Proteggere correttamente gli account di accesso di emergenza
Gli account di accesso di emergenza sono intenzionalmente diversi. Microsoft raccomanda due o più account di accesso di emergenza solo cloud per gli scenari break-glass, e la guida Microsoft indica che quelle assegnazioni di Amministratore Globale dovrebbero essere attive permanenti anziché idonee in PIM. Questo evita che una dipendenza da PIM blocchi il tenant durante un'interruzione.
Questa eccezione non significa controlli deboli. Gli account di emergenza devono essere solo cloud, protetti con autenticazione resistente al phishing quando possibile, archiviati in modo sicuro, monitorati a ogni accesso, e convalidati regolarmente. Non devono essere usati per l'amministrazione ordinaria.
4. Imporre un'autenticazione forte per gli utenti privilegiati
Richiedi un'autenticazione forte per utenti e ruoli privilegiati. Per i ruoli a maggior valore, preferisci metodi resistenti al phishing dove licenza, supporto dei dispositivi e operatività lo consentono. Verifica anche che gli admin non aggirino la policy tramite posizioni attendibili, gruppi esclusi, account di test obsoleti, o workflow legacy.
5. Includere applicazioni e service principal
L'accesso privilegiato non è solo umano. Rivedi i service principal, le registrazioni app, le credenziali, i proprietari, e i permessi delle applicazioni. Un tenant può avere un elenco pulito di Amministratori Globali e comunque avere un percorso applicativo in grado di leggere dati della directory, modificare oggetti, o mantenere persistenza.
Frequenza di revisione e ownership
L'accesso privilegiato deve avere un proprietario e una frequenza di revisione. PIM riduce l'accesso permanente, ma non dimostra automaticamente che ogni assegnazione idonea sia ancora giustificata. Almeno una volta per ciclo di revisione, confronta ogni assegnazione di ruolo privilegiato con il modello operativo attuale: chi possiede il ruolo, quale attività lo richiede, se l'assegnazione dovrebbe restare idonea, se le impostazioni di attivazione sono ancora sufficientemente rigorose, e se l'utente appartiene ancora alla popolazione admin.
Rivedi anche i cambiamenti dopo migrazioni, fusioni, risposta a incidenti, uso dell'accesso di emergenza, e onboarding SaaS importanti. Questi sono i momenti in cui i percorsi admin temporanei diventano spesso permanenti.
Convalida dopo il rollout di PIM
Dopo la pulizia, convalida la sicurezza effettiva invece della sola esistenza della policy:
- conferma che gli admin normali siano idonei, non attivi permanentemente, per i ruoli ad alto valore
- conferma che gli account di emergenza siano le uniche eccezioni intenzionali di Amministratore Globale permanente
- esegui un'attivazione controllata e conferma che MFA, approvazione, durata e logging si comportino come previsto
- rivedi i log di audit per nuove assegnazioni di ruolo dopo la pulizia
- verifica che l'Accesso Condizionale non escluda involontariamente account privilegiati
- rivedi i service principal e le registrazioni app per privilegi equivalenti ai ruoli admin
- conferma che gli alert scattino sull'accesso di un account di emergenza e sull'assegnazione di un ruolo privilegiato
Un buon test di convalida chiede: se questa password o sessione admin viene rubata oggi, quale privilegio ottiene immediatamente l'attaccante, e quali controlli aggiuntivi deve soddisfare prima di esercitare più privilegio?
Come EtcSec rileva questo
EtcSec verifica la configurazione dell'accesso privilegiato Azure a ogni scansione e si concentra sulle condizioni che trasformano un account compromesso in controllo totale del tenant.
PA_TOO_MANY_GLOBAL_ADMINS identifica i tenant con un numero eccessivo di Amministratori Globali.
PA_PERMANENT_ADMIN_ASSIGNMENTS segnala le assegnazioni privilegiate permanenti che dovrebbero essere riviste per la conversione ad accesso idoneo.
PA_PIM_NOT_ENABLED individua i tenant in cui il controllo dell'accesso privilegiato just-in-time è assente o inefficace.
PA_GLOBAL_ADMIN_NOT_MFA identifica gli account Amministratore Globale senza copertura di autenticazione forte.
Controlli correlati
Rivedi l'accesso privilegiato insieme a Sicurezza delle identità Azure: perché l'MFA da solo non basta, Azure Identity Protection: bloccare le credenziali trapelate, Lacune dell'Accesso Condizionale Azure: bypass MFA con password rubate, Account guest Azure: la superficie di attacco dimenticata del tuo tenant, e App Azure con privilegi eccessivi nel tenant. Il privilegio admin permanente raramente è l'unico problema in un tenant.
Riferimenti principali
Esplora le pagine di identity security collegate a questo tema