Concedere il ruolo di Global Administrator a chiunque debba “fare qualcosa” in Microsoft 365 è l’errore architetturale più comune — e quello che l’esame MS-102 punisce di più. Il modello corretto parte sempre dal compito e risale al ruolo minimo che lo consente.
Mappare i compiti sui ruoli
| Requisito operativo | Ruolo corretto | Note |
|---|---|---|
| Reset password di utenti standard | Helpdesk Administrator | Non tocca account con ruoli privilegiati |
| Reset password anche di Helpdesk/User Admin | User Administrator | Non può resettare un Global Administrator |
| Assegnare/rimuovere licenze | License Administrator | Non può acquistare: serve Billing Administrator |
| Creare mailbox condivise, regole di trasporto, connettori | Exchange Administrator | Accesso a Exchange Online e relativo EAC |
| Policy di conformità e configurazione dispositivi | Intune Administrator | Endpoint in Microsoft Intune admin center |
| Configurare policy anti-phishing e Safe Links | Security Administrator | Scrittura in Microsoft Defender XDR |
| Leggere incidenti, alert e Secure Score senza modificare | Security Reader | Sola lettura sul perimetro sicurezza |
| Leggere qualunque configurazione del tenant | Global Reader | Sola lettura trasversale, il gemello di Global Administrator |
| Report di utilizzo (Teams, Exchange, OneDrive) | Reports Reader | Nessuna visibilità sugli incidenti di sicurezza |
| eDiscovery, DLP, etichette di sensibilità | Role group in Microsoft Purview | Es. Compliance Data Administrator, eDiscovery Manager |
Il punto chiave: i ruoli Microsoft Entra ID sono direttoria-wide e attraversano i workload; i ruoli specifici del workload vivono dentro il singolo servizio. Exchange Online ha un proprio RBAC (management role group + management scope), Microsoft Defender XDR ha la Unified RBAC, Microsoft Purview usa i role group del portale. Un Exchange Administrator assegnato in Entra ID viene ereditato da Exchange Online, ma il contrario non vale: un role group creato solo in Exchange non appare nel Microsoft 365 admin center.
Restringere l’ambito: unità amministrative
Quando il requisito è “l’IT di Milano deve gestire solo gli utenti di Milano”, la risposta non è un nuovo ruolo ma una unità amministrativa (administrative unit, AU): si popola l’AU con utenti, gruppi o dispositivi (anche via regole dinamiche) e si assegna il ruolo con ambito quell’AU.
Attenzione: non tutti i ruoli sono scopabili su AU. Funzionano User Administrator, Helpdesk/Password/Authentication Administrator, Groups Administrator, License Administrator, Intune Administrator. Exchange Administrator non è scopabile su AU: per limitare un amministratore Exchange a un sottoinsieme di mailbox si usano i management scope del RBAC di Exchange Online. Le restricted management AU aggiungono un livello ulteriore: proteggono gli oggetti contenuti impedendo che ruoli tenant-wide li modifichino, salvo assegnazione esplicita.
Elevazione just-in-time con PIM
Privileged Identity Management (incluso in Microsoft Entra ID P2 / Entra ID Governance) trasforma le assegnazioni permanenti in eleggibili: l’amministratore attiva il ruolo per una finestra limitata, con giustificazione obbligatoria, MFA all’attivazione e, se configurato, approvazione di un secondo soggetto. Ogni attivazione è tracciata nell’audit log e PIM genera alert (es. “troppi Global Administrator”) e access review periodiche.
Pattern d’esame ricorrente: “un amministratore deve poter usare un ruolo privilegiato solo quando serve, con approvazione” → assegnazione eleggibile in PIM con requisito di approvazione, non un’assegnazione permanente né una Conditional Access policy.
Igiene degli account privilegiati
- Mantenere almeno 2 e meno di 5 Global Administrator.
- Account amministrativi dedicati e cloud-only, senza licenze produttività e senza mailbox esposte.
- MFA obbligatoria su tutti gli account privilegiati, preferibilmente phishing-resistant (FIDO2, Windows Hello for Business); Microsoft impone ormai MFA per l’accesso agli admin center.
- Predisporre emergency access account (break-glass) documentati, monitorati e con credenziali phishing-resistant custodite offline.
Trappole tipiche d’esame
- Scenario: un auditor deve vedere impostazioni Exchange, SharePoint e Entra ID senza modificare nulla → Global Reader, non Security Reader (che copre solo il perimetro sicurezza) e non Global Administrator.
- Scenario: un analista SOC deve consultare incidenti e alert in Microsoft Defender XDR e il Secure Score senza cambiare policy → Security Reader; se deve anche configurare le policy, Security Administrator.
- Scenario: l’helpdesk non riesce a resettare la password di un collega che è Billing Administrator → comportamento atteso: Helpdesk Administrator non può agire su account con ruoli privilegiati; serve User Administrator (che comunque non tocca i Global Administrator).
- Scenario: assegnare licenze a nuovi assunti senza altri poteri → License Administrator; per comprare sottoscrizioni serve Billing Administrator.
- Scenario: delegare la gestione utenti di una sola filiale → unità amministrativa + ruolo scopato; se il requisito riguarda le mailbox, si passa ai management scope di Exchange Online, perché l’AU non vale per Exchange Administrator.