Gruppi Privilegiati Nidificati Entra ID, Gruppi Assegnabili a Ruoli e Ospiti nei Gruppi di Sicurezza

Cosa Sono i Gruppi Assegnabili a Ruoli e i Gruppi Privilegiati Nidificati in Entra ID

Gruppi privilegiati nidificati Entra ID, gruppi assegnabili a ruoli: questa ricerca composta copre uno degli angoli meno auditati del controllo degli accessi di Microsoft Entra ID — il privilegio nidificato tramite gruppi assegnabili a ruoli, e un ospite che si infila in un gruppo di sicurezza per appartenenza anziché per invito, formando insieme un percorso silenzioso verso Amministratore Globale che la maggior parte dei tenant non ha mai mappato.

Un gruppo assegnabile a ruoli è un gruppo di sicurezza con la proprietà isAssignableToRole impostata su true (oppure «I ruoli di Microsoft Entra possono essere assegnati a questo gruppo» impostato su Sì nel portale). Assegnare un ruolo Microsoft Entra a un gruppo anziché a singoli utenti permette a un'organizzazione di gestire l'appartenenza ai ruoli tramite modifiche all'appartenenza al gruppo anziché tramite chiamate ripetute all'API di assegnazione dei ruoli. Secondo la documentazione Microsoft, la creazione di gruppi assegnabili a ruoli richiede Microsoft Entra ID P1 o P2, la proprietà isAssignableToRole è immutabile una volta creato il gruppo, un gruppo assegnabile a ruoli non può usare l'appartenenza dinamica, e un tenant può avere al massimo 500 gruppi assegnabili a ruoli. Microsoft «protegge» inoltre specificamente i proprietari dei gruppi assegnabili a ruoli per ridurre il rischio di elevazione dei privilegi sull'oggetto gruppo stesso.

I gruppi privilegiati nidificati descrivono un gruppo membro di un altro gruppo che porta ruoli Entra privilegiati o accesso a risorse — la stessa logica del «percorso verso Domain Admin» che esiste in Active Directory on-prem (vedi nidificazione pericolosa di gruppi in Active Directory), applicata alla directory cloud. Microsoft blocca esplicitamente la versione più ovvia di questo: un gruppo non può essere membro attivo di un gruppo assegnabile a ruoli. Ciò che Microsoft consente — e che la maggior parte dei tenant non ha considerato — è che un gruppo sia membro idoneo di un gruppo assegnabile a ruoli tramite Privileged Identity Management (PIM) per i gruppi.

Infine, gli ospiti nei gruppi di sicurezza sono un problema distinto dalla governance degli inviti agli ospiti. Questo articolo non riguarda chi può invitare un ospite (vedi Account Guest Azure: la Superficie di Attacco Dimenticata per quell'angolazione) — riguarda un account ospite che finisce per essere membro di un gruppo di sicurezza che porta accesso o idoneità a un ruolo, tramite nidificazione o una regola di appartenenza dinamica, senza che nessuno abbia esplicitamente deciso di concedere qualcosa a quell'ospite.

Gruppi Privilegiati Nidificati Entra ID Assegnabili a Ruoli: La Catena di Escalation

Passo 1 — Un gruppo non privilegiato viene nidificato come membro idoneo

PIM per i gruppi consente a un amministratore di configurare assegnazioni idonee in due direzioni: o gli utenti vengono aggiunti attivamente a un gruppo e il gruppo stesso viene reso idoneo per un ruolo, oppure un ruolo viene assegnato attivamente a un gruppo e gli utenti vengono resi idonei all'appartenenza a quel gruppo — e, secondo la stessa documentazione Microsoft su PIM per i gruppi, anche un gruppo può essere configurato come membro idoneo di un altro gruppo, incluso uno assegnabile a ruoli. Poiché la restrizione di appartenenza attiva sui gruppi assegnabili a ruoli blocca solo l'appartenenza diretta e permanente, un gruppo a privilegio inferiore può essere configurato come membro idoneo di un gruppo assegnabile a ruoli senza violare tale restrizione.

Passo 2 — Nessun flusso di approvazione viene applicato all'attivazione

PIM per i gruppi supporta gli stessi controlli di policy di PIM per i ruoli Entra: richiedere l'approvazione, imporre l'MFA all'attivazione, richiedere una giustificazione aziendale e limitare la durata massima di attivazione. Quando questi controlli non sono configurati — che è la postura predefinita in molti tenant che hanno adottato PIM per i gruppi senza rafforzarlo — qualsiasi membro del gruppo di livello inferiore può autoattivare la propria appartenenza idonea al gruppo privilegiato ed ereditare il ruolo portato da quel gruppo (Amministratore Globale, Amministratore di Ruolo Privilegiato, Amministratore delle Applicazioni, e così via — vedi Accesso Privilegiato Azure: Troppi Admin Globali sul perché un accesso Amministratore Globale permanente e facilmente raggiungibile è già un riscontro comune).

Passo 3 — Un ospite si infila attraverso lo stesso gruppo

Il gruppo nidificato del Passo 1 raramente è nato come gruppo «privilegiato» — spesso è un team di progetto, un gruppo di accesso alle applicazioni, o un gruppo con una regola di appartenenza dinamica ampia. Se un account ospite è stato aggiunto a quel gruppo (direttamente, o perché la regola dinamica del gruppo è stata scritta più ampiamente del previsto — per esempio corrispondendo su attributi che non escludono in modo affidabile userType eq Guest; vedi il ritiro dell'operatore di regola di gruppo dinamico memberOf per come queste regole stanno già cambiando), l'ospite eredita lo stesso percorso idoneo verso il gruppo assegnabile a ruoli di qualsiasi utente membro. Nessuno ha esplicitamente valutato se «questo ospite dovrebbe essere idoneo per Amministratore Globale» — la nidificazione del gruppo ha preso quella decisione implicitamente.

Account ospite
  -> membro del gruppo di sicurezza "Project-Falcon" (appartenenza dinamica o manuale)
      -> "Project-Falcon" è membro idoneo di "Tier0-Admins" (gruppo assegnabile a ruoli)
          -> a "Tier0-Admins" è attivamente assegnato il ruolo Amministratore Globale
              -> l'ospite autoattiva la propria appartenenza idonea (nessuna approvazione richiesta)
                  -> l'ospite ora detiene Amministratore Globale per la finestra di attivazione

Lo strumento di valutazione EntraFalcon di Compass Security documenta la stessa debolezza sottostante da un'angolazione di valutazione offensiva: segnala qualsiasi gruppo che non sia assegnabile a ruoli, né sincronizzato da on-premises, né collocato in un'Unità Amministrativa a Gestione Ristretta come gruppo privilegiato «non protetto» (ID del riscontro GRP-005 nei loro report), perché nessuna di queste tre proprietà è garantita per un gruppo che diventa privilegiato solo transitivamente, tramite nidificazione.

Rilevamento

Qui il rilevamento significa trovare i gruppi assegnabili a ruoli, trovare cosa è nidificato in modo idoneo al loro interno, e trovare gli ospiti nell'albero di gruppi che li alimenta — nulla di tutto ciò compare come un singolo avviso per impostazione predefinita.

# Microsoft Graph — enumerare i gruppi assegnabili a ruoli
GET https://graph.microsoft.com/v1.0/groups?$filter=isAssignableToRole eq true&$select=id,displayName,membershipRuleProcessingState

# Microsoft Graph — ospiti transitivamente presenti in un gruppo specifico
GET https://graph.microsoft.com/v1.0/groups/{group-id}/transitiveMembers/microsoft.graph.user?$filter=userType eq 'Guest'

// Sentinel / Log Analytics — modifiche di appartenenza al gruppo che alimentano una watch-list di ID di gruppi privilegiati
AuditLogs
| where OperationName in ("Add member to group", "Add owner to group")
| where TargetResources[0].id in (privilegedGroupIds)
| project TimeGenerated, OperationName, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName), Target = tostring(TargetResources[0].displayName)

Remediation

1. Inventariate tutti i gruppi assegnabili a ruoli con la query Graph isAssignableToRole eq true sopra riportata — non fidatevi della memoria del tenant su «i gruppi creati per questo». Assegnate un proprietario a ciascuno e rimuovete i proprietari che non necessitano più di quell'accesso, poiché la stessa guida Microsoft segnala la proprietà non governata come il principale rischio di elevazione su questi oggetti.
2. Richiedete approvazione e MFA all'attivazione per ogni assegnazione idonea PIM per i gruppi che termina in un gruppo assegnabile a ruoli, e impostate una durata massima di attivazione limitata anziché lasciarla aperta.
3. Vietate la nidificazione di gruppi verso gruppi assegnabili a ruoli dove non è operativamente necessaria. La stessa guida Microsoft raccomanda di limitare o evitare i gruppi nidificati per i percorsi di elevazione dei ruoli, perché ogni livello di nidificazione aggiunge proprietari di gruppo che possono gestire indirettamente chi raggiunge il ruolo, che lo intendessero o meno.
4. Verificate le regole di appartenenza dinamica che alimentano qualsiasi gruppo in una catena privilegiata, e rendete esplicita l'esclusione degli ospiti (userType -ne "Guest") anziché darla per scontata — un gruppo assegnabile a ruoli in sé non può usare l'appartenenza dinamica, ma i gruppi nidificati sotto di esso sì, ed è esattamente lì che una regola troppo ampia causa danni.
5. Eseguite revisioni degli accessi sull'appartenenza dei gruppi assegnabili a ruoli e sulle catene di appartenenza idonea, non solo sulle assegnazioni di ruolo dirette — una revisione trimestrale limitata a «chi detiene Amministratore Globale» non rileverà un ospite due livelli di nidificazione più sotto.
6. Rimuovete gli ospiti dai gruppi di sicurezza a cui non avrebbero mai dovuto unirsi. Se la presenza di un ospite in un gruppo si spiega solo con «la regola dinamica lo ha intercettato» o «qualcuno lo ha aggiunto al gruppo sbagliato», trattatelo come un incidente da chiudere, non come un dettaglio di configurazione da annotare per dopo.

Questi controlli si integrano in una revisione più ampia — vedi come auditare la sicurezza di Microsoft Entra ID per collocare l'igiene di gruppi e PIM rispetto ad accesso condizionale, MFA e permessi delle applicazioni.

Come EtcSec Rileva Questo

L'audit Azure/Entra ID di EtcSec verifica esattamente questa catena: Gruppi Nidificati con Accesso Privilegiato (AZ_GROUP_NESTED_PRIVILEGED) segnala i gruppi che raggiungono un gruppo assegnabile a ruoli tramite nidificazione idonea o transitiva, Gruppi Assegnabili a Ruoli (AZ_GROUP_ROLE_ASSIGNABLE) inventaria ogni gruppo isAssignableToRole e la sua postura di proprietà/approvazione, e Utenti Ospiti nei Gruppi di Sicurezza (AZ_GROUP_GUEST_IN_SECURITY) fa emergere gli account ospite presenti nei gruppi di sicurezza, sia che siano stati invitati direttamente sia che abbiano ottenuto l'appartenenza tramite nidificazione o una regola dinamica. Controlli correlati — Ruolo Admin Assegnato a un Gruppo (PA_GROUP_ASSIGNED_ADMIN) e Gruppi Privilegiati Senza Monitoraggio delle Modifiche (AZ_GROUP_PRIVILEGED_CHANGES) — estendono lo stesso audit alle assegnazioni di ruolo ai gruppi e al fatto che le modifiche di appartenenza su tali gruppi vengano effettivamente registrate e riviste.