• Cloud, Guide, Microsoft 365
• 9 Giugno 2026

Quando un tenant Microsoft Intune è ancora piccolo, la gestione amministrativa tende a essere abbastanza lineare: pochi amministratori, poche policy, qualche applicazione, un numero contenuto di dispositivi e una struttura operativa ancora gestibile a vista. Poi l’ambiente cresce e arrivano più sedi, più team IT, gruppi di help desk, fornitori esterni, amministratori locali, team di sicurezza e, in alcuni casi, anche società diverse all’interno dello stesso gruppo. A quel punto il tema non è più solo creare una configuration policy o distribuire un’applicazione. Il vero problema diventa capire chi può vedere cosa, chi può modificare cosa e fino a dove può spingersi un amministratore all’interno del tenant.

In Microsoft Intune questa esigenza viene gestita attraverso il modello RBAC, acronimo di Role-Based Access Control. All’interno di questo modello, gli Scope Tags hanno un ruolo molto importante, anche se spesso vengono percepiti come una semplice opzione da compilare durante la creazione di una policy. In realtà non sono un dettaglio, anzi, gli Scope Tags sono uno degli strumenti principali per separare la gestione amministrativa degli oggetti Intune e costruire un modello di delega più sicuro, più leggibile e più facile da governare nel tempo.

In questo articolo vedremo cosa sono gli Scope Tags, come funzionano, dove si inseriscono nel modello RBAC di Intune, quali errori evitare e come testarli attraverso una demo pratica. L’obiettivo non è solo capire dove si clicca nella console, ma soprattutto comprendere quando ha senso usarli e quali benefici possono portare nella gestione quotidiana di un tenant Microsoft Intune.

Il problema che gli Scope Tags provano a risolvere

Immaginiamo un’azienda con una sede centrale e alcune sedi territoriali. Il team centrale gestisce le policy di sicurezza comuni, le baseline, la compliance, le applicazioni corporate e la governance complessiva del tenant. I team locali, invece, devono poter lavorare solo su alcuni dispositivi e su alcune configurazioni legate alla propria sede. Senza una delega ben progettata, il rischio è quello di assegnare permessi troppo ampi. Un amministratore locale potrebbe vedere policy che non dovrebbe modificare, intervenire su configurazioni pensate per tutta l’azienda o gestire dispositivi che non fanno parte del proprio perimetro operativo. L’alternativa opposta è accentrare tutto sul team centrale. All’inizio può sembrare la scelta più sicura, ma nel tempo diventa poco sostenibile. Ogni modifica, anche banale, passa sempre dallo stesso gruppo di persone. Il tenant resta formalmente sotto controllo, ma operativamente diventa un collo di bottiglia.

Gli Scope Tags servono proprio a trovare un equilibrio: consentire la delega amministrativa, ma dentro un perimetro chiaro. Non decidono a chi viene applicata una policy, non sostituiscono i gruppi Microsoft Entra ID e non sono filtri di assegnazione. Il loro scopo è controllare la visibilità amministrativa degli oggetti Intune. Questa distinzione è fondamentale: se voglio ad esempio applicare una policy solo ai dispositivi Windows della sede di Roma, userò gli assignment verso gruppi utenti o dispositivi, eventualmente insieme agli Assignment Filters. Se invece voglio che solo il team IT di Roma possa vedere e gestire quella policy nella console di Microsoft Intune, allora entrano in gioco gli Scope Tags.

Cosa sono gli Scope Tags

Uno Scope Tag è un’etichetta amministrativa che può essere associata a oggetti Intune come applicazioni, configuration profiles, compliance policies, script, remediation, dispositivi e altri elementi gestiti dalla piattaforma. Il concetto di fondo è semplice: un amministratore può vedere e gestire gli oggetti Intune che hanno almeno uno Scope Tag compatibile con la sua role assignment, sempre nei limiti dei permessi concessi dal ruolo assegnato. Facciamo un esempio:

Creo uno Scope Tag chiamato LOC-Roma e lo assegno ad alcune policy e ad alcuni dispositivi. Poi creo una role assignment per il gruppo Intune Roma Admins e associo a quella role assignment lo Scope Tag
LOC-Roma. A quel punto gli amministratori presenti nel gruppo Intune Roma Admins, a parità di permessi concessi dal ruolo, potranno lavorare sugli oggetti marcati con lo Scope Tag
LOC-Roma. Se una policy non ha quel tag, non rientra nel loro perimetro amministrativo.

Il punto fondamentale è che lo Scope Tag non assegna il permesso da solo, il permesso arriva dal ruolo Intune, mentre lo Scope Tag limita il contesto in cui quel permesso può essere esercitato.

RBAC in Intune: ruolo, gruppi e tag devono lavorare insieme

Per capire davvero gli Scope Tags, bisogna leggere il modello RBAC di Microsoft Intune nel suo insieme. Quando assegniamo un ruolo amministrativo in Intune, non stiamo semplicemente dicendo “questo utente può fare questa cosa“. In realtà stiamo combinando più elementi che, insieme, definiscono il perimetro effettivo dell’amministratore.

• Il primo elemento è il ruolo, che definisce quali azioni sono consentite. Ad esempio: leggere una policy, modificarla, crearla, cancellarla, assegnarla o eseguire azioni remote sui dispositivi
• Il secondo elemento è l’Admin Group, cioè il gruppo che contiene gli amministratori che ricevono quel ruolo
• Il terzo elemento è lo Scope Group, che definisce quali utenti o dispositivi rientrano nel perimetro gestibile dall’amministratore
• Il quarto elemento è lo Scope Tag, che definisce quali oggetti Intune sono visibili e gestibili dall’amministratore

La differenza tra Scope Groups e Scope Tags può creare confusione; quindi, faccio chiarezza su questo punto. Lo Scope Group riguarda il perimetro amministrativo di utenti e dispositivi. In pratica, indica su quali utenti o dispositivi l’amministratore può operare e quali gruppi può utilizzare come target, in base ai permessi ricevuti. Lo Scope Tag, invece, riguarda gli oggetti Intune: policy, applicazioni, script, profili, dispositivi e, più in generale, gli oggetti che supportano questo tipo di classificazione amministrativa. Un amministratore potrebbe quindi avere il permesso di gestire i configuration profiles, ma solo per i dispositivi inclusi nello Scope Group associato alla propria delega e solo sui profili che hanno uno Scope Tag compatibile. Ad esempio, lo Scope Group potrebbe essere chiamato “Dispositivi Roma” e lo Scope Tag “LOC-Roma”. È dunque la combinazione di ruolo, Admin Group, Scope Group e Scope Tag a determinare il perimetro reale della delega amministrativa.

Figura 1: Schema concettuale di RBAC e Scope Tags in Microsoft Intune

Scope Tags e Default Scope Tag

Ogni tenant Microsoft Intune include uno Scope Tag predefinito chiamato Default. Questo tag viene assegnato automaticamente agli oggetti che supportano gli Scope Tags e ai quali non è stato associato alcun tag personalizzato. Il Default Scope Tag agisce quindi come una classificazione di fallback: evita che gli oggetti supportati rimangano privi di un tag, ma non rappresenta necessariamente il perimetro centrale del tenant né attribuisce all’oggetto un significato amministrativo particolare.

In molti ambienti, tuttavia, il tag Default viene lasciato sugli oggetti senza una strategia precisa. Con il tempo, il tenant può così ritrovarsi con alcune policy correttamente classificate attraverso tag personalizzati e molte altre ancora associate al contenitore generico Default. Non si tratta necessariamente di una configurazione errata, ma deve essere una scelta consapevole e coerente con il modello di delega adottato.

Ad esempio, un’azienda potrebbe decidere di mantenere sul Default Scope Tag gli oggetti amministrati esclusivamente dal team centrale, oppure utilizzarlo temporaneamente per quelli non ancora classificati. Si tratta però di una convenzione interna: in un ambiente strutturato è importante stabilire con chiarezza quali oggetti possono rimanere sul tag Default e quali devono essere associati a uno Scope Tag specifico.

Un altro comportamento da conoscere riguarda la creazione e la modifica delle policy. Alcune tipologie di policy potrebbero non mostrare la pagina Scope Tags se nel tenant non è stato ancora creato alcun tag personalizzato oltre al Default. In questo caso non si tratta di un problema di licenza o di autorizzazioni: è sufficiente creare almeno uno Scope Tag personalizzato perché l’opzione venga visualizzata nelle tipologie di policy che la supportano.

Oggetti supportati e limiti da conoscere

Gli Scope Tags possono essere associati a molti oggetti di Microsoft Intune, ma non a tutti. In generale, sono supportati per le tipologie di oggetto delle quali il tenant può contenere più istanze, come applicazioni, policy, profili, script e role assignment. Esistono però alcune eccezioni documentate, al momento non supportano gli Scope Tags:

• Corporate Device Identifiers
• Windows Autopilot devices
• Device compliance locations
• dispositivi gestiti tramite Jamf

Questo aspetto è particolarmente importante negli ambienti che utilizzano Windows Autopilot. Il fatto che i dispositivi registrati nel servizio Autopilot non supportino direttamente gli Scope Tags non significa che non sia possibile delegare le altre attività collegate al processo. Significa, però, che gli Scope Tags non offrono una copertura uniforme su tutti gli oggetti coinvolti e che il modello di delega deve tenere conto di questa limitazione.

Un comportamento specifico riguarda inoltre le applicazioni e gli eBook acquisiti tramite Apple Volume Purchase Program, oggi integrato in Apple Business Manager o Apple School Manager: questi oggetti ereditano gli Scope Tags assegnati al relativo token VPP.

È necessario considerare anche alcuni limiti numerici: è possibile associare fino a 100 Scope Tags all’assegnazione di un ruolo e fino a 100 Scope Tags a un singolo oggetto Intune. Si tratta di limiti piuttosto elevati, ma avvicinarsi a queste soglie sarebbe probabilmente il segnale di un problema organizzativo più che tecnico. Un oggetto associato a decine di tag diventa difficile da interpretare, mentre una role assignment con troppi Scope Tags rende meno immediato ricostruire il perimetro effettivo dell’amministratore.

Gli Scope Tags dovrebbero semplificare la governance e rendere più leggibile la delega amministrativa, non aggiungere un ulteriore livello di complessità.

Demo pratica: delegare la gestione al team IT di una sede

Passiamo ora dalla teoria alla pratica e vediamo, passo dopo passo, come utilizzare gli Scope Tags per delegare una parte della gestione di Microsoft Intune. Lo scenario è volutamente semplice, così da isolare il comportamento di RBAC, Scope Groups e Scope Tags senza introdurre variabili che renderebbero più difficile interpretare il risultato.

Immaginiamo un tenant Microsoft Intune gestito da un team centrale e da un piccolo team IT locale responsabile della sede di Roma. Il team centrale mantiene il controllo dell’intero ambiente, mentre gli amministratori locali devono poter operare esclusivamente all’interno del proprio perimetro. In particolare, il team IT di Roma dovrà:

• visualizzare e gestire solo gli oggetti Intune associati alla propria sede
• lavorare esclusivamente sui dispositivi inclusi nel proprio Scope Group
• non vedere né modificare le policy riservate al team centrale
• non assegnare policy o applicazioni a gruppi esterni al proprio perimetro amministrativo

Naturalmente, tutte queste operazioni resteranno limitate ai permessi concessi dal ruolo Intune che assegneremo al team locale. Per preparare e verificare la demo utilizzeremo due account distinti. L’account amministrativo principale verrà usato per creare i gruppi, lo Scope Tag e le role assignment. L’account [email protected], che inizialmente è un normale utente del tenant, riceverà invece i permessi amministrativi esclusivamente tramite Intune RBAC e rappresenterà l’amministratore delegato della sede di Roma.

Gli elementi utilizzati nella demo saranno i seguenti:

Tabella 1: Oggetti utilizzati nella demo di delega amministrativa

Per rendere immediatamente visibile l’effetto della delega, utilizzeremo anche due dispositivi di test: uno incluso in GRP-Intune-Roma-Devices e uno lasciato fuori dal gruppo. In questo modo potremo verificare non solo quali policy vede l’amministratore locale, ma anche su quali dispositivi può effettivamente operare. Per la demo creeremo entrambi i gruppi come normali Microsoft Entra security groups con membership di tipo Assigned. Non è necessario abilitare l’opzione Microsoft Entra roles can be assigned to the group, perché i permessi verranno assegnati attraverso il modello RBAC di Intune e non tramite un ruolo Microsoft Entra.

In un ambiente di produzione, il gruppo dei dispositivi potrebbe anche utilizzare una membership dinamica, purché basata su attributi affidabili e governati. Per il gruppo degli amministratori è invece preferibile mantenere una membership assegnata e controllata esplicitamente, così da sapere sempre quali account ricevono i permessi amministrativi. L’uso di gruppi statici nella demo rende inoltre più semplice verificare il comportamento della configurazione e distinguere con chiarezza ciò che rientra nel perimetro di Roma da ciò che deve rimanerne escluso.

Preparazione dei gruppi

Prima di configurare la delega in Microsoft Intune, prepariamo i gruppi necessari in Microsoft Entra ID. Creiamo innanzitutto il gruppo di sicurezza GRP-Intune-Roma-Admins, che conterrà gli account amministrativi ai quali vogliamo delegare la gestione della sede di Roma. Nel nostro esempio aggiungiamo come membro l’account [email protected]. Questo account è inizialmente un normale utente del tenant e riceverà i permessi amministrativi esclusivamente attraverso una role assignment di Intune.

Creiamo poi il gruppo di sicurezza GRP-Intune-Roma-Devices, destinato a contenere i dispositivi che rientrano nel perimetro operativo del team di Roma e, al suo interno, aggiungiamo uno dei dispositivi di test già registrati e gestiti da Microsoft Intune. Per rendere più chiaro il risultato della demo utilizzeremo due dispositivi:

• un dispositivo incluso nel gruppo GRP-Intune-Roma-Devices
• un secondo dispositivo lasciato fuori dal gruppo

In questo modo potremo verificare chiaramente quali dispositivi rientrano nello Scope Group assegnato all’amministratore delegato e quali, invece, restano al di fuori del suo perimetro amministrativo. Come anticipato, entrambi i gruppi possono essere creati come normali Microsoft Entra security groups con membership di tipo Assigned e non è necessario abilitare l’opzione Microsoft Entra roles can be assigned to the group, perché i permessi verranno assegnati tramite il modello RBAC di Intune e non attraverso un ruolo Microsoft Entra.

Figura 2: Gruppi Microsoft Entra ID utilizzati nella demo

Creazione dello Scope Tag

Adesso è il momento di mettere le mani in Microsoft Intune, apriamo dunque il Microsoft Intune admin center con l’account amministrativo principale e raggiungiamo il percorso Tenant administration > Roles.

Attenzione: la creazione, la modifica e l’eliminazione degli Scope Tags richiedono un account con il ruolo Microsoft Entra che sia almeno Intune Administrator. Gli amministratori ai quali un tag viene assegnato tramite Intune RBAC possono utilizzarlo nel proprio perimetro, ma non modificarlo o rimuoverlo dalla lista principale degli Scope Tags.

Figura 3: Accesso alla sezione Roles dal Microsoft Intune admin center

Apriamo quindi la sezione Scope Tags e selezioniamo Create.

Figura 4: Sezione Scope Tags in Microsoft Intune

Nella pagina Basics assegniamo un nome al nuovo tag. Per questa demo utilizzeremo LOC-Roma. Possiamo inoltre compilare il campo Description con una descrizione che renda immediatamente comprensibile lo scopo del tag (facoltativo, ma consigliato). Dopo aver compilato i campi, selezioniamo Next.

Figura 5: Creazione dello Scope Tag LOC-Roma

Nella pagina Assignments possiamo associare lo Scope Tag a uno o più gruppi contenenti dispositivi. Selezioniamo Add groups, scegliamo GRP-Intune-Roma-Devices e confermiamo con Select. Questa configurazione consente a Microsoft Intune di assegnare automaticamente lo Scope Tag “LOC-Roma” ai dispositivi che appartengono al gruppo “GRP-Intune-Roma-Devices“, evitando di doverli classificare manualmente uno alla volta.

Attenzione: è importante non confondere questo passaggio con la configurazione dello Scope Group, che verrà eseguita successivamente all’interno della role assignment. In questa schermata non stiamo ancora definendo quali dispositivi potrà gestire l’amministratore con la delega: stiamo soltanto applicando automaticamente lo Scope Tag ai dispositivi presenti nel gruppo. L’associazione del gruppo in questa fase è facoltativa. Uno Scope Tag può essere creato anche senza configurare un’assegnazione automatica e può successivamente essere applicato manualmente agli oggetti Intune che devono rientrare in quel perimetro amministrativo. Occorre inoltre considerare che le assegnazioni automatiche degli Scope Tags sovrascrivono i tag assegnati manualmente ai dispositivi. Se uno stesso dispositivo appartiene a più gruppi associati a tag differenti, riceverà tutti gli Scope Tags derivanti dalle assegnazioni automatiche. Per questo motivo è importante utilizzare gruppi con membership chiare e in linea con il modello di delega progettato.

Figura 6: Assegnazione dello Scope Tag ai dispositivi Roma

Una volta aggiunto il gruppo, proseguiamo nuovamente con Next.

Figura 7: Gruppo dispositivi associato allo Scope Tag

Nella pagina Review + create controlliamo il nome, la descrizione e il gruppo associato. Se la configurazione è corretta, selezioniamo Create per completare la creazione dello Scope Tag.

Figura 8: Revisione della configurazione dello Scope Tag

A questo punto lo Scope Tag LOC-Roma esiste e può essere associato ai dispositivi e agli altri oggetti Intune supportati. La sua creazione, però, non assegna ancora alcun permesso agli amministratori, per completare la delega dobbiamo ora creare una role assignment, collegando il ruolo Intune, il gruppo degli amministratori, lo Scope Group e lo Scope Tag appena configurato.

Figura 9: Conferma della creazione e assegnazione dello Scope Tag

Creazione del role assignment

Dopo aver creato lo Scope Tag, possiamo configurare la role assignment, cioè l’assegnazione che collega un ruolo Intune al gruppo degli amministratori e ne delimita il perimetro attraverso Scope Groups e Scope Tags. Per questa demo utilizzeremo due ruoli built-in:

• Policy and Profile Manager, che consentirà all’amministratore delegato di creare, modificare, assegnare ed eliminare configuration profiles e compliance policies
• Read Only Operator, che permetterà di visualizzare i dispositivi e le altre informazioni di Intune comprese nel perimetro della delega, senza poterle modificare

La seconda assegnazione è necessaria perché il ruolo Policy and Profile Manager non include il permesso Managed devices – Read e, utilizzato da solo, non è quindi sufficiente per mostrare correttamente anche l’esperienza di consultazione dei dispositivi.

Attenzione: occorre però considerare che Read Only Operator è un ruolo di lettura piuttosto ampio: non consente modifiche, ma permette di consultare informazioni relative a dispositivi, utenti, configurazioni, applicazioni, enrollment e altre aree della piattaforma. Per una demo didattica come questa è una scelta ottima per mostrare il risultato finale; in un ambiente di produzione sarebbe preferibile creare un ruolo custom contenente esclusivamente i permessi realmente necessari.

Iniziamo dalla role assignment del ruolo Policy and Profile Manager. Nel Microsoft Intune admin center raggiungiamo il percorso Tenant administration > Roles > All roles e apriamo il ruolo.

Figura 10: Selezione del ruolo Policy and Profile Manager

Entriamo nella sezione Assignments e selezioniamo Assign.

Figura 11: Avvio della role assignment dal ruolo selezionato

Nella pagina Basics inseriamo un nome, ad esempio Roma – Policy and Profile Management; se volete inserite una descrizione (facoltativo). Infine, proseguiamo con Next.

Figura 12: Configurazione del nome della role assignment

Nella pagina Admin Groups selezioniamo Add groups e aggiungiamo il gruppo GRP-Intune-Roma-Admins, che contiene gli account che riceveranno i permessi definiti dal ruolo. Nel nostro esempio, al suo interno è presente l’utente [email protected], che rappresenta l’amministratore con delega della sede di Roma. Dopo aver selezionato il gruppo, proseguiamo con Next.

Figura 13: Selezione dell’Admin Group

Nella pagina Scope Groups selezioniamo Add groups e aggiungiamo GRP-Intune-Roma-Devices. Lo Scope Group definisce il perimetro di utenti e dispositivi sul quale gli amministratori presenti nell’Admin Group possono operare. Inoltre, quando assegneranno una policy, potranno utilizzare come target soltanto i gruppi compresi nel perimetro della role assignment.

È importante non confondere questo passaggio con l’assegnazione automatica dello Scope Tag eseguita in precedenza. In questa schermata non stiamo applicando un tag ai dispositivi: stiamo definendo quali utenti e dispositivi rientrano nel perimetro gestibile dall’amministratore con delega. Se una policy utilizza anche un gruppo di esclusione, quel gruppo deve essere compreso negli Scope Groups della role assignment oppure essere annidato in uno dei gruppi già inclusi. In caso contrario, l’amministratore delegato non potrà utilizzarlo correttamente nell’assegnazione. Proseguiamo selezionando Next.

Figura 14: Selezione dello Scope Group

Nella pagina Scope Tags selezioniamo quello creato in precedenza: LOC-Roma. Per farlo, facciamo click su Select scope tags, selezioniamo dalla lista LOC-Roma e confermiamo con il pulsante Select. Ricordo che questo Scope Tags definirà il perimetro degli oggetti Intune visibili e gestibili.

Attenzione: lo Scope Tag determina quali oggetti Intune rientrano nella visibilità amministrativa dell’utente delegato. Questo non significa che l’amministratore possa eseguire qualsiasi operazione sugli oggetti con tag LOC-Roma: le azioni consentite dipendono sempre dai permessi inclusi nel ruolo Policy and Profile Manager. Nel nostro scenario, l’amministratore potrà quindi gestire i configuration profiles e le compliance policies che hanno lo Scope Tag “LOC-Roma“, operando nel perimetro definito dallo Scope Group “GRP-Intune-Roma-Devices“.

Figura 15: Selezione dello Scope Tag nella role assignment

Una volta selezionato lo Scope Tag, proseguiamo con Next.

Figura 16: Scope Tag selezionato per la role assignment

Nella pagina Review + create controlliamo il ruolo, l’Admin Group, lo Scope Group e lo Scope Tag selezionati. Se la configurazione è corretta, scegliamo Create per completare la role assignment.

Figura 17: Revisione della role assignment Policy and Profile Manager

Figura 18: Conferma della creazione della role assignment

A questo punto ripetiamo la stessa procedura sul ruolo Read Only Operator, utilizzando gli stessi elementi:

• Admin Group: GRP-Intune-Roma-Admins
• Scope Group: GRP-Intune-Roma-Devices
• Scope Tag: LOC-Roma

Per rendere immediatamente riconoscibile anche questa assegnazione, possiamo chiamarla, ad esempio Roma – Read Only Operations e il risultato finale sarà il seguente:

Figura 19: Role assignment per il ruolo Read Only Operator

Figura 20: Role assignment configurate per il team Roma

A questo punto abbiamo costruito la delega: il gruppo GRP-Intune-Roma-Admins, che contiene l’admin della sede di Roma [email protected], ha il ruolo Policy and Profile Manager e Read Only Operator, ma limitato ai dispositivi del gruppo GRP-Intune-Roma-Devices e agli oggetti Intune marcati con lo Scope Tag chiamato LOC-Roma.

Applicazione dello Scope Tag a una policy

Abbiamo ora predisposto tutti gli elementi necessari per la delega: il gruppo degli amministratori, il gruppo dei dispositivi, le role assignment e lo Scope Tag LOC-Roma. Il passaggio successivo consiste nell’applicare il tag a una policy che dovrà essere visibile e gestibile dal team IT di Roma. Per questa demo utilizzeremo il profilo WinGet Configuration, creato per distribuire alcune configurazioni di WinGet e già trattato nell’articolo ICT Power WinGet: distribuzione e governance con Microsoft Intune.

Nel Microsoft Intune admin center raggiungiamo Devices > Configuration e apriamo la policy WinGet Configuration.

Figura 21: Apertura della policy WinGet Configuration

All’interno della pagina della policy apriamo Properties, individuiamo la sezione Scope tags e selezioniamo Edit.

Figura 22: Modifica degli Scope Tags della policy

A questo punto, espandiamo Select scope tags, selezioniamo quello creato in precedenza (LOC-Roma), rimuoviamo quello di Default, e infine confermiamo con Select.

Questa modifica fa rientrare la policy nel perimetro amministrativo associato allo Scope Tag LOC-Roma. Gli amministratori inclusi nella relativa role assignment potranno quindi visualizzarla e gestirla nei limiti dei permessi concessi dal ruolo Policy and Profile Manager. È importante ricordare che lo Scope Tag non modifica gli assignment della policy e non determina su quali dispositivi verrà applicata. Gli eventuali destinatari continueranno a essere definiti dai gruppi configurati nella sezione Assignments. In questo passaggio stiamo modificando esclusivamente la visibilità e la gestione amministrativa dell’oggetto.

Rimuoviamo intenzionalmente il tag Default per rendere più chiaro il risultato della demo. Se mantenessimo sulla policy sia Default sia LOC-Roma, l’oggetto potrebbe rientrare nel perimetro degli amministratori associati a uno qualsiasi dei due tag, sempre in base alle rispettive role assignment e ai permessi concessi dai ruoli.

Figura 23: Selezione dello Scope Tag LOC-Roma sulla policy

Dopo la modifica, nella sezione Scope tags della policy sarà quindi presente soltanto LOC-Roma, mentre quello di Default non sarà più presente. Selezioniamo Review + save per verificare la configurazione.

Figura 24: Verifica dello Scope Tag applicato alla policy

Confermiamo le modifiche con Save per salvare la configurazione.

Figura 25: Salvataggio della modifica alla policy

Da questo momento la policy WinGet Configuration è associata allo Scope Tag “LOC-Roma“. Nel test con l’account delegato verificheremo che sia visibile e gestibile, mentre le policy associate esclusivamente al tag Default o ad altri Scope Tags resteranno fuori dal suo perimetro amministrativo.

Esperienza dell’amministratore

Arriviamo ora alla parte più interessante della demo: osservare il Microsoft Intune admin center dal punto di vista dell’amministratore con la delega. Apriamo una nuova sessione del browser, preferibilmente in modalità InPrivate, e accediamo con l’account [email protected].

Attenzione: prima di eseguire il test è importante verificare che questo account non abbia ruoli Microsoft Entra privilegiati, come Global Administrator o Intune Administrator, e che non riceva ulteriori role assignment Intune oltre a quelle configurate per la demo. I permessi assegnati da più ruoli e gruppi sono infatti cumulativi e potrebbero ampliare il perimetro visibile, falsando il risultato. Nel nostro scenario, l’account riceve esclusivamente i ruoli Policy and Profile Manager e Read Only Operator, entrambi associati allo Scope Group “GRP-Intune-Roma-Devices” e allo Scope Tag “LOC-Roma“.

Apriamo Devices > Configuration e nell’elenco dei configuration profiles è visibile la policy WinGet Configuration, perché sono soddisfatte entrambe le condizioni necessarie:

• la role assignment dell’amministratore contiene lo Scope Tag “LOC-Roma“
• il ruolo Policy and Profile Manager concede i permessi necessari per leggere e gestire quel tipo di oggetto

Le policy associate esclusivamente allo Scope Tag “Default” o a qualsiasi altro tag non presente nelle role assignment dell’amministratore non vengono invece mostrate. Questo è il primo risultato tangibile della demo: lo Scope Tag determina quali oggetti Intune entrano nella visibilità dell’amministratore, mentre il ruolo stabilisce quali operazioni può eseguire su quegli oggetti. Non si tratta quindi di un semplice filtro grafico applicato alla console, l’oggetto è effettivamente fuori dal perimetro amministrativo dell’utente delegato.

Figura 26: Visibilità della policy con l’account delegato

Passiamo ora alla sezione Devices > All devices. i due dispositivi inclusi nel gruppo GRP-Intune-Roma-Devices sono visibili all’amministratore perché:

• rientrano nello Scope Group della role assignment
• hanno ricevuto automaticamente lo Scope Tag “LOC-Roma” attraverso l’assegnazione configurata durante la creazione del tag

Gli altri dispositivi, lasciati fuori dal gruppo e non associato allo Scope Tag “LOC-Roma“, non rientrano invece nel perimetro dell’amministratore con la delega, anche se continuano a essere presente e gestito nello stesso tenant Microsoft Intune.

In questa demo l’account può consultare le informazioni del dispositivo grazie al ruolo Read Only Operator, ma non dispone dei permessi necessari per eseguire le azioni remote operative utilizzate nell’esempio, come sincronizzazione, riavvio o retire. Se volessimo delegare anche operazioni come sincronizzazione, riavvio, retire o altre azioni remote, dovremmo assegnare un ruolo con i relativi permessi oppure creare un ruolo custom basato sul principio del privilegio minimo. Questo passaggio mostra bene che Scope Group e Scope Tag definiscono il perimetro, ma le operazioni realmente disponibili dipendono sempre dai permessi inclusi nel ruolo.

Figura 27: Dispositivi visibili nel perimetro dell’amministratore con la delega

Come ultimo test, apriamo la policy WinGet Configuration e proviamo a modificarne gli Assignments. L’amministratore con la delega può utilizzare come target solo i gruppi compresi negli Scope Groups delle proprie role assignment. Nel nostro scenario può quindi assegnare la policy al gruppo “GRP-Intune-Roma-Devices” e non può invece utilizzarla per raggiungere un gruppo globale o un gruppo relativo a un’altra sede che non sia stato incluso nel proprio perimetro amministrativo.

Figura 28: Verifica del targeting consentito alla policy

Questo comportamento evita che un amministratore locale possa gestire correttamente una policy, ma assegnarla accidentalmente a utenti o dispositivi esterni alla propria area di competenza. I tre test mostrano quindi i diversi livelli della delega:

• il ruolo stabilisce quali operazioni sono consentite
• lo Scope Tag determina quali oggetti Intune sono visibili
• lo Scope Group delimita gli utenti, i dispositivi e i gruppi che possono essere gestiti o utilizzati come target

Cosa succede quando l’amministratore crea una nuova policy

Possiamo completare la demo verificando cosa succede quando è l’amministratore con la delega a creare un nuovo oggetto in Microsoft Intune. Restando collegati con l’account [email protected], creiamo un nuovo configuration profile. Il ruolo Policy and Profile Manager gli concede i permessi necessari per eseguire questa operazione, mentre la role assignment ne limita il perimetro amministrativo. Durante la configurazione, l’amministratore può utilizzare esclusivamente gli Scope Tags presenti nelle proprie role assignment. Nel nostro scenario ha a disposizione soltanto LOC-Roma e non può quindi associare alla policy il tag “Default“, o un altro tag al quale non è stato autorizzato.

Quando un amministratore crea un nuovo oggetto, Microsoft Intune gli assegna automaticamente tutti gli Scope Tags associati al suo contesto amministrativo. La nuova policy creata da [email protected] riceverà quindi automaticamente lo Scope Tag “LOC-Roma” e continuerà a essere visibile all’account che l’ha creata. Possiamo verificarlo aprendo le proprietà del nuovo profilo e controllando la sezione Scope tags.

Figura 29: Scope Tags applicati a una nuova policy creata dall’amministratore con la delega

Questo comportamento evita che un amministratore crei una policy che, subito dopo il salvataggio, risulti esterna al proprio perimetro e non sia più visibile nella console. La stessa logica richiede però attenzione quando un account riceve più Scope Tags attraverso una o più role assignment. In quel caso, tutti i tag assegnati all’amministratore vengono applicati automaticamente al nuovo oggetto. La policy potrebbe quindi diventare visibile a più team amministrativi, purché questi dispongano di una role assignment con almeno uno Scope Tag corrispondente e dei permessi necessari per gestire quel tipo di oggetto. Per questo motivo è importante evitare di assegnare agli amministratori più tag del necessario, una configurazione troppo ampia non aumenta soltanto ciò che l’utente può vedere: può ampliare automaticamente anche il perimetro di visibilità degli oggetti che creerà in futuro.

Risultato atteso della demo

Al termine della demo avremo verificato concretamente cinque aspetti del modello RBAC di Microsoft Intune:

• il ruolo Intune stabilisce quali operazioni può eseguire l’amministratore, ad esempio leggere, creare, modificare o assegnare una policy
• lo Scope Tag determina quali oggetti Intune rientrano nella sua visibilità amministrativa. Nel nostro esempio, una policy associata a LOC-Roma è visibile al team di Roma, mentre una policy che non ha alcuno Scope Tag compatibile con le sue role assignment rimane fuori dal suo perimetro
• lo Scope Group delimita gli utenti e i dispositivi sui quali l’amministratore può operare
• l’amministratore con delega può utilizzare come target soltanto i gruppi compresi nel perimetro delle proprie role assignment
• quando l’amministratore crea un nuovo oggetto, Microsoft Intune applica automaticamente gli Scope Tags associati al suo contesto amministrativo

La demo permette, quindi, di osservare la delega da due prospettive diverse: con l’account amministrativo centrale vediamo l’intero tenant e configuriamo ruoli, gruppi e tag; con l’account delegato vediamo invece il perimetro effettivo risultante dalla combinazione di ruolo, Admin Group, Scope Group e Scope Tag. È proprio il confronto tra le due esperienze a rendere immediato il funzionamento degli Scope Tags. Non si tratta di una semplice etichetta applicata agli oggetti, ma di uno degli elementi che determinano concretamente ciò che un amministratore può vedere e gestire all’interno del tenant.

Figura 30: Vista dell’ambiente con account amministrativo centrale

Figura 31: Vista dell’ambiente con account amministratore con delega

Comportamenti da conoscere prima di usarli in produzione

La demo mostra il funzionamento essenziale degli Scope Tags in uno scenario volutamente semplice. In un ambiente di produzione, però, le configurazioni tendono a sovrapporsi: gli amministratori possono appartenere a più gruppi, ricevere più ruoli e lavorare su oggetti condivisi tra team diversi. Prima di adottare gli Scope Tags come base del proprio modello di delega è quindi importante conoscere alcuni comportamenti che, se trascurati, possono produrre risultati più permissivi di quelli previsti.

Role assignment senza Scope Tags

Se una role assignment non contiene alcuno Scope Tag, l’amministratore può vedere tutti gli oggetti compatibili con i permessi concessi dal ruolo. In pratica, dal punto di vista della visibilità, un amministratore senza Scope Tags si comporta come se avesse accesso a tutti i tag presenti nel tenant. Questa configurazione può essere corretta per un team centrale che deve amministrare l’intero ambiente, ma sarebbe normalmente troppo permissiva per un team locale, un help desk o un fornitore esterno. Per questo motivo, ogni role assignment priva di Scope Tags dovrebbe essere una scelta esplicita, motivata e documentata, non il risultato di una configurazione lasciata incompleta.

Amministratori con ruoli Microsoft Entra elevati

Gli Scope Tags fanno parte del modello RBAC di Intune, ma non limitano i permessi derivanti dai ruoli amministrativi di Microsoft Entra. In particolare, un account con il ruolo Intune Administrator mantiene accesso amministrativo completo a Microsoft Intune indipendentemente dagli Scope Tags associati alle eventuali role assignment Intune. Per gli account privilegiati bisogna quindi adottare controlli separati, come account amministrativi dedicati, attivazione just-in-time tramite Privileged Identity Management, autenticazione a più fattori resistente al phishing, Conditional Access e processi di approvazione per le attività più sensibili.

Gli Scope Tags sono uno strumento di delega amministrativa, non una barriera con cui limitare un amministratore Entra già dotato di privilegi completi.

Scope Tags e oggetti condivisi

Uno dei punti più delicati nella progettazione riguarda gli oggetti condivisi tra più sedi o business unit. Pensiamo a una security baseline Windows, una policy di Microsoft Defender, una compliance policy aziendale o una configurazione comune di BitLocker. Questi oggetti possono essere assegnati a dispositivi appartenenti a sedi diverse, ma la loro gestione dovrebbe spesso rimanere centralizzata.

Il fatto che una policy venga applicata ai dispositivi di Roma non significa necessariamente che il team IT di Roma debba poterla modificare. Una cosa è il target della policy, definito dagli assignment; un’altra è il team che ne mantiene la responsabilità amministrativa. Assegnare a una policy centrale tutti gli Scope Tags delle sedi la renderebbe visibile a tutti i relativi team e, se i ruoli lo consentono, anche modificabile. Una soluzione più ordinata consiste nell’utilizzare un tag dedicato, ad esempio GLOBAL oppure SHARED-Central, associandolo esclusivamente alle role assignment del team responsabile.

In questo modo la policy può continuare a essere distribuita ai dispositivi di Roma, Milano e Napoli, mentre la sua gestione rimane nelle mani del team centrale. Se il team centrale utilizza intenzionalmente una role assignment senza Scope Tags, continuerà comunque a vedere tutti gli oggetti. Un tag dedicato può però rimanere utile per classificare gli oggetti condivisi e rendere più leggibile il modello di governance.

La regola da ricordare è semplice: Scope Tags e assignment non devono necessariamente coincidere. Una policy può essere distribuita a molti dispositivi, ma gestita da un solo team.

Comportamento dei permessi con più role assignment

Un altro aspetto delicato riguarda gli amministratori che ricevono più role assignment. È uno scenario piuttosto comune. Lo stesso account può appartenere al gruppo del team centrale, a quello di una sede, a un gruppo di progetto e magari anche a un gruppo temporaneo creato per un’attività specifica. I permessi assegnati attraverso gruppi e role assignment sono cumulativi e non esiste un meccanismo di deny con cui sottrarre un’autorizzazione concessa altrove. Nel comportamento predefinito di Intune, quando un amministratore appartiene a più role assignment che utilizzano Scope Tags differenti ma condividono la stessa categoria di permessi, la piattaforma combina le autorizzazioni ricevute. Immaginiamo, ad esempio, che un amministratore riceva:

• accesso in sola lettura alle applicazioni con Scope Tag GLOBAL
• accesso completo alle applicazioni con Scope Tag LOC-Roma

Poiché entrambe le role assignment utilizzano la stessa categoria di permessi, in questo caso Mobile Apps, Intune può combinarle. Il risultato è che l’amministratore potrebbe ricevere i permessi completi sulle applicazioni di entrambi i perimetri, anche se sul tag GLOBAL era stato previsto un accesso esclusivamente in lettura. È proprio questo comportamento a rendere insufficiente l’analisi della singola role assignment. Per conoscere i permessi effettivi di un amministratore bisogna considerare tutte le assegnazioni e tutti i gruppi ai quali appartiene.

Scoped permissions: la novità importante del 2026

Nel marzo 2026 Microsoft ha introdotto in public preview una nuova impostazione opt-in chiamata Scoped permissions. Con questo comportamento, i permessi di ogni role assignment restano confinati nel contesto del relativo Scope Tag, invece di essere combinati con quelli provenienti da altre assegnazioni che condividono la stessa categoria. Riprendendo l’esempio precedente, l’amministratore conserverebbe:

• accesso in sola lettura alle applicazioni con Scope Tag GLOBAL
• accesso completo alle applicazioni con Scope Tag LOC-Roma

I due livelli di autorizzazione rimarrebbero quindi separati e coerenti con il modello progettato. Si tratta di un cambiamento importante, perché rende il comportamento di Intune più vicino a quello che molti amministratori si aspettano quando configurano ruoli differenti su perimetri differenti. Microsoft ha inoltre indicato che questa logica diventerà il comportamento predefinito per tutti i tenant in una futura release.

L’attivazione richiede però particolare attenzione. Scoped permissions è un’impostazione tenant-wide e l’operazione non può essere annullata. Prima di abilitarla è necessario utilizzare il Permissions Assessment Report, disponibile nel percorso Tenant administration > Roles > Settings. Il report confronta i permessi attuali, risultanti dalla combinazione delle role assignment, con quelli che verrebbero applicati dopo l’attivazione di Scoped permissions. Per ciascun gruppo interessato mostra i ruoli coinvolti, gli Scope Tags, le risorse e le eventuali riduzioni delle autorizzazioni.

Il report può essere generato più volte ed esportato in Excel, permettendo di correggere le role assignment e informare gli amministratori interessati prima di modificare il comportamento del tenant. L’attivazione può essere eseguita da un account con ruolo Intune Administrator oppure, soluzione preferibile, attraverso un ruolo Intune personalizzato che includa l’autorizzazione Organization – Update. In un nuovo tenant ha senso valutare questa impostazione fin dalla progettazione iniziale, ma non abilitarla senza un’analisi preventiva solo perché l’ambiente è ancora vuoto. In un tenant già operativo deve invece essere trattata come una vera modifica di governance, preceduta da assessment, test e comunicazione ai team coinvolti.

Figura 32: Impostazioni di Scoped permissions e Permissions Assessment Report

Scope Tags ed Endpoint analytics

Gli Scope Tags vengono utilizzati anche dai Device scopes di Endpoint analytics. Questa funzionalità permette di filtrare alcuni report e visualizzare dati, insight e raccomandazioni relativi esclusivamente a un determinato sottoinsieme di dispositivi. I custom device scopes sono supportati nei report:

• Startup performance
• Work from anywhere
• Application reliability
• Battery health

Un team locale potrebbe, ad esempio, analizzare i tempi di avvio o l’affidabilità delle applicazioni esclusivamente sui dispositivi associati allo Scope Tag della propria sede. Ogni custom device scope può essere basato su un solo Scope Tag. Per includere dispositivi che appartengono a più tag è necessario creare un nuovo Scope Tag che comprenda l’intero insieme desiderato. Esistono inoltre alcuni limiti operativi:

• è possibile salvare fino a 100 custom device scopes
• possono essere attivi contemporaneamente fino a 20 custom device scopes
• l’elaborazione iniziale può richiedere fino a 24 ore
• sono necessari almeno 10 dispositivi per popolare i report supportati

Se lo Scope Tag utilizzato da un custom device scope viene eliminato, il device scope smette di funzionare e deve essere modificato utilizzando un tag valido oppure rimosso. Non è quindi uno strumento pensato per creare micro-segmentazioni temporanee, ma può essere molto utile quando gli Scope Tags rappresentano perimetri amministrativi stabili, come sedi, business unit o società del gruppo.

Naming convention

Gli Scope Tags sono semplici da creare e, proprio per questo, possono diventare rapidamente disordinati. In molti tenant si trovano tag nati per esigenze temporanee, nomi poco chiari, abbreviazioni difficili da interpretare, duplicati e oggetti che nessuno sa più se siano ancora utilizzati. Una naming convention semplice e coerente aiuta a capire immediatamente il perimetro rappresentato dal tag.

Tabella 2: Esempi di naming convention per Scope Tags

Non esiste una convenzione universalmente corretta, l’importante è che il formato scelto sia comprensibile, documentato e applicato in modo uniforme. Anche il campo Description, che spesso passa in secondo piano, dovrebbe essere sempre compilato; non serve una descrizione estesa, è sufficiente indicare il perimetro, il team proprietario e lo scopo per cui il tag è stato creato.

Errori comuni

Dopo aver visto come funziona il modello, possiamo riepilogare alcuni errori che ricorrono più spesso negli ambienti aziendali:

• utilizzare gli Scope Tags come se fossero gruppi di distribuzione. Una policy viene applicata attraverso gli assignment verso utenti o dispositivi, non attraverso il tag
• lasciare role assignment senza Scope Tags senza averne valutato le conseguenze. In questo caso l’amministratore può vedere tutti gli oggetti compatibili con i permessi del ruolo
• assegnare ruoli troppo ampi a team che dovrebbero svolgere attività limitate. Uno Scope Tag può ridurre il perimetro, ma non corregge un ruolo progettato male. Se un team deve soltanto leggere informazioni e fare troubleshooting, non dovrebbe ricevere permessi di creazione, modifica o eliminazione non necessari
• applicare i tag locali agli oggetti globali. Una policy centrale deve poter essere distribuita ai dispositivi delle sedi senza diventare automaticamente modificabile dai relativi team locali
• non provare la configurazione con un account delegato reale. Verificare il tenant soltanto con un Global Administrator o un Intune Administrator non permette di osservare il comportamento effettivo di RBAC e Scope Tags
• non controllare le appartenenze multiple ai gruppi amministrativi. I permessi sono cumulativi e una membership dimenticata può ampliare la visibilità o le operazioni disponibili
• utilizzare gruppi sovrapposti per l’assegnazione automatica dei tag senza valutarne l’effetto. Se un dispositivo appartiene a più gruppi associati a Scope Tags differenti, riceve tutti i tag risultanti; inoltre, l’assegnazione automatica sovrascrive quella manuale

Infine, un errore frequente è non documentare il modello. Dopo alcuni mesi diventa difficile ricostruire perché un tag è stato creato, quali role assignment lo utilizzano e quale team ne sia responsabile.

Audit e controllo delle modifiche

Una volta configurato il modello, è necessario monitorarne l’utilizzo e le modifiche. Gli Audit logs di Microsoft Intune registrano le attività che producono cambiamenti nella piattaforma, tra cui creazione, modifica, eliminazione, assegnazione e azioni remote. È possibile consultarli dal percorso Tenant administration > Audit logs.

Figura 33: Audit logs di Microsoft Intune

In un modello RBAC ben governato, questi log permettono di ricostruire chi ha modificato una policy, chi ha aggiornato una role assignment, chi ha cambiato gli Scope Tags di un oggetto e quando è avvenuta l’operazione. Per gli ambienti più strutturati, i log possono essere instradati in modo continuativo verso i servizi di Azure Monitor attraverso Reports > Diagnostics settings e da qui è possibile:

• archiviarli in un Azure Storage account
• inviarli a Log Analytics per query, monitoraggio e alert
• trasmetterli ad Azure Event Hubs per integrarli con un SIEM o con soluzioni esterne

È importante distinguere questo meccanismo dall’esportazione manuale disponibile nella pagina degli audit log. Le Diagnostics settings servono a configurare il routing continuativo dei dati verso i servizi Azure. Quando più team operano nello stesso tenant, il valore dell’audit non consiste soltanto nel sapere che una configurazione è cambiata, ma nel poter ricostruire chi l’ha modificata, quando e su quale oggetto.

Multi Admin Approval e modifiche RBAC

Un ulteriore livello di protezione può essere introdotto tramite Multi Admin Approval. Questa funzionalità permette di definire access policy che richiedono l’approvazione di un secondo account amministrativo prima che una modifica venga applicata. L’amministratore che invia la richiesta non può approvarla autonomamente, anche se appartiene al gruppo degli approver. Multi Admin Approval può proteggere diverse categorie di risorse, tra cui:

• applicazioni
• compliance policies
• configuration policies create tramite Settings Catalog
• script PowerShell per dispositivi Windows
• azioni wipe, retire e delete sui dispositivi
• modifiche al modello RBAC
• alcune configurazioni del tenant, come le device categories

Nel contesto degli Scope Tags, il tipo di policy Role-based access control è particolarmente rilevante perché protegge le modifiche ai ruoli e alle role assignment, comprese variazioni ai permessi, agli Admin Groups e ai gruppi associati. Una modifica RBAC può cambiare il perimetro amministrativo di un intero team. Richiedere una seconda approvazione riduce quindi il rischio che un errore operativo o un account compromesso possa ampliare i privilegi senza controllo.

Questa protezione deve però essere configurata con attenzione. Se si abilita una access policy per il tipo Role prima di aver predisposto correttamente i gruppi degli approver e le relative role assignment, si può creare una situazione di blocco: anche le modifiche RBAC necessarie a completare la configurazione di Multi Admin Approval richiederebbero un’approvazione che gli approver non sono ancora autorizzati a fornire. Per evitare questo problema è opportuno:

• predisporre prima i gruppi degli approver
• assegnare loro i permessi Intune necessari
• verificare che il gruppo approver sia incluso in almeno una role assignment
• soltanto dopo creare la access policy che protegge le modifiche RBAC

Multi Admin Approval non sostituisce un modello RBAC ben progettato, ma aggiunge un controllo efficace sulle operazioni più sensibili e riduce la possibilità che una singola identità amministrativa possa modificare autonomamente il perimetro di gestione del tenant.

Troubleshooting: l’amministratore non vede una policy

Uno dei casi più comuni è l’amministratore che segnala di non vedere una policy, un’applicazione o un dispositivo. In questi casi conviene procedere con ordine:

• la prima cosa da controllare è il ruolo: l’amministratore ha davvero i permessi necessari per leggere o gestire quel tipo di oggetto?
• poi bisogna verificare il gruppo amministrativo: l’account è membro del gruppo usato nella role assignment?
• il terzo controllo riguarda lo Scope Tag: l’oggetto che l’amministratore non vede ha almeno uno Scope Tag in comune con la role assignment dell’amministratore?
• poi bisogna guardare lo Scope Group: se il problema riguarda utenti o dispositivi, questi rientrano nei gruppi gestibili dall’amministratore?
• infine, bisogna verificare se l’oggetto supporta gli Scope Tags e se l’amministratore riceve permessi da altre role assignment

In molti casi il problema è banale: la policy è rimasta con il tag Default, mentre l’amministratore ha solo il tag custom (nella nostra demo, ad esempio, LOC-Roma). Dal punto di vista di Intune, quella policy è fuori perimetro.

Troubleshooting: l’amministratore vede troppo

Il problema opposto rispetto a un oggetto non visibile è più delicato: un amministratore riesce a vedere o gestire risorse che, secondo il modello progettato, dovrebbero restare fuori dal suo perimetro. Il primo controllo da fare riguarda le role assignment prive di Scope Tags. Quando un’assegnazione non contiene tag, l’amministratore può vedere tutti gli oggetti compatibili con i permessi concessi dal relativo ruolo. È quindi sufficiente una sola role assignment configurata in questo modo per ampliare la visibilità oltre quanto previsto. Se le assegnazioni risultano correttamente delimitate, bisogna verificare anche gli altri elementi che concorrono a determinare i permessi effettivi:

• controllare se l’account appartiene a più Admin Groups e riceve quindi ulteriori ruoli o role assignment. I permessi concessi da assegnazioni diverse sono cumulativi e non esiste un meccanismo di deny che possa annullare un’autorizzazione ricevuta altrove
• verificare gli Scope Tags applicati agli oggetti. Una policy associata a più tag può essere visibile a tutti i team amministrativi che dispongono di almeno un tag corrispondente e dei necessari permessi sul tipo di risorsa
• controllare l’assegnazione automatica degli Scope Tags ai dispositivi. Se i gruppi utilizzati sono troppo ampi o sovrapposti, un dispositivo può ricevere più tag ed entrare nel perimetro di più team
• verificare se l’amministratore dispone di un ruolo Microsoft Entra privilegiato, come Intune Administrator, che non viene limitato dal modello RBAC e dagli Scope Tags di Intune
• analizzare il comportamento applicato dal tenant alle role assignment multiple, verificando se utilizza ancora la combinazione predefinita dei permessi oppure se sono già state abilitate le Scoped permissions

Il troubleshooting non dovrebbe quindi fermarsi alla singola role assignment; per ricostruire il perimetro di un amministratore è necessario considerare tutti i gruppi di appartenenza, tutti i ruoli ricevuti e tutti gli Scope Tags associati agli oggetti.

Best practices

La progettazione degli Scope Tags dovrebbe partire dal modello organizzativo e non dalla console di Intune. Prima di creare i tag bisogna stabilire quali team devono amministrare il tenant, quali attività possono svolgere e quali oggetti, utenti e dispositivi devono rientrare nel loro perimetro. Solo dopo aver definito questi requisiti ha senso tradurli in ruoli, Admin Groups, Scope Groups e Scope Tags.

In genere è preferibile utilizzare pochi tag, con nomi chiari e uno scopo facilmente riconoscibile. Un tag per ogni sede, business unit o provider può essere coerente con il modello organizzativo; creare un tag per ogni singola policy, invece, produrrebbe quasi sempre una granularità difficile da mantenere. Gli oggetti globali dovrebbero essere classificati attraverso un perimetro dedicato e non associati automaticamente a tutti i tag locali solo perché vengono distribuiti a dispositivi appartenenti a più sedi. Come abbiamo visto, il target di una policy e il team che può amministrarla sono due aspetti distinti.

Anche le role assignment prive di Scope Tags dovrebbero essere limitate ai casi in cui è realmente necessaria una visibilità completa del tenant. Queste assegnazioni devono essere documentate e sottoposte a revisioni periodiche, soprattutto quando riguardano account esterni o team con responsabilità circoscritte. La verifica finale deve sempre essere eseguita con un account che rappresenti realmente l’amministratore delegato. Accedere soltanto con un Global Administrator o un Intune Administrator non permette di osservare l’esperienza risultante dall’applicazione di Intune RBAC.

Infine, il modello non può essere considerato definitivo. Cambiano i team, le responsabilità, i fornitori e gli oggetti presenti nel tenant. Un’assegnazione corretta oggi può diventare troppo permissiva o non più necessaria tra alcuni mesi. È quindi consigliabile prevedere una revisione periodica che includa almeno:

• appartenenza degli account agli Admin Groups;
• ruoli e permessi effettivamente necessari;
• role assignment prive di Scope Tags;
• Scope Tags applicati agli oggetti;
• gruppi utilizzati per l’assegnazione automatica dei tag;
• tag non più utilizzati o privi di un proprietario;
• account che ricevono più role assignment sovrapposte.

Conclusioni

Gli Scope Tags permettono di separare i perimetri amministrativi, ridurre la visibilità non necessaria e delegare attività operative senza estendere l’accesso all’intero ambiente. Proprio perché non producono un risultato immediatamente visibile sui dispositivi, vengono spesso considerati un aspetto secondario della gestione di Microsoft Intune ma in realtà diventano fondamentali quando il tenant non è più amministrato da un solo team.

Il loro valore emerge soprattutto quando sedi, business unit, help desk, team di sicurezza o fornitori diversi devono lavorare nello stesso tenant mantenendo responsabilità distinte. Da soli, però, non sono sufficienti. Una delega corretta nasce dalla combinazione di ruolo, Admin Group, Scope Group e Scope Tag, accompagnata da una gestione rigorosa dei privilegi Microsoft Entra, dal controllo degli audit log e dalla revisione periodica delle assegnazioni.

Funzionalità come Multi Admin Approval e Scoped permissions possono rafforzare ulteriormente questo modello, ma non possono compensare una progettazione poco chiara o ruoli più ampi del necessario. In un tenant piccolo gli Scope Tags possono sembrare un elemento trascurabile. In un ambiente strutturato rappresentano invece una delle basi per mantenere la gestione di Microsoft Intune ordinata, delegabile e coerente con il principio del privilegio minimo.

Il momento migliore per progettarli è prima che la crescita del tenant trasformi una gestione centralizzata e informale in un insieme di accessi difficili da ricostruire e ancora più difficili da correggere.