Audit dei ruoli personalizzati Entra ID: admin senza assegnazioni

Audit dei ruoli personalizzati Entra ID: che cosa viene misurato?

Un audit dei ruoli personalizzati Entra ID deve rispondere a tre domande distinte: quali definizioni di autorizzazioni esistono, quali entità le detengono e se tali assegnazioni soddisfano ancora un’esigenza aziendale. Microsoft rappresenta un’assegnazione come un collegamento fra una definizione, un’entità e un ambito. La sola presenza di una definizione personalizzata non dimostra un accesso privilegiato. Microsoft Graph: unifiedRoleAssignment.

Le verifiche di accesso riguardano le assegnazioni; un audit delle definizioni esamina separatamente le autorizzazioni concesse da quelle assegnazioni. Una verifica può tralasciare assegnazioni esterne ai ruoli, alle popolazioni o ai tipi di assegnazione selezionati. Una verifica correttamente mirata può rimuovere l’accesso quando vengono applicati i suoi risultati. Esaminare le assegnazioni lascia anche una domanda separata: la definizione sottostante deve ancora esistere e le sue autorizzazioni sono appropriate? Creare verifiche di accesso ai ruoli, completare e applicare le verifiche.

Questa guida distingue tali domande, fornisce richieste Graph documentate e spiega sette controlli di etc-collector. Non contiene risultati di tenant né operazioni Graph eseguite. L’obiettivo pratico è un insieme di evidenze che consenta a un amministratore di giustificare gli accessi mantenuti, rimuovere assegnazioni superflue e ritirare definizioni personalizzate effettivamente ridondanti senza confondere queste azioni.

Definizioni, ruoli abilitati e titolari

In Graph, isBuiltIn=false identifica una definizione di ruolo personalizzata. isEnabled indica se la definizione è disponibile per l’assegnazione; non dice se qualcuno detiene attualmente quel ruolo. rolePermissions contiene la sua raccolta di autorizzazioni. Microsoft indica che resourceScopes non deve essere usato e che ne è prevista la deprecazione; associate invece l’ambito all’assegnazione. Proprietà di unifiedRoleDefinition.

I ruoli di directory Microsoft Entra governano le risorse Entra; il controllo RBAC delle risorse Azure governa risorse come macchine virtuali e archiviazione. Le loro autorizzazioni non sono intercambiabili. I ruoli di directory personalizzati possono implementare una funzione lavorativa più ristretta di un ruolo predefinito, quindi «personalizzato» non è di per sé un giudizio di sicurezza. Panoramica del controllo RBAC Microsoft Entra.

Per questo audit, mantenete tre categorie di riscontri: complessità delle definizioni, assegnazioni che richiedono una giustificazione e incertezza della raccolta. Si tratta di un metodo di rendicontazione consigliato. Evita di presentare un elenco vuoto di assegnazioni come una compromissione attiva e di sostituire l’analisi delle autorizzazioni con un catalogo di ruoli apparentemente piccolo.

Funzionamento: autorizzazioni e ambito determinano l’esposizione

Il nome di un’autorizzazione segue una struttura composta da spazio dei nomi, entità, insieme di proprietà e azione. Ad esempio, microsoft.directory/applications/credentials/update è un’autorizzazione di directory, e non un’autorizzazione applicativa Graph denominata Application.ReadWrite.All per cui sia stato concesso il consenso. La documentazione Microsoft sulle autorizzazioni privilegiate spiega questa struttura e come tali autorizzazioni possano rendere privilegiato un ruolo predefinito o personalizzato. Ruoli e autorizzazioni privilegiati.

Il catalogo delle autorizzazioni per la registrazione delle applicazioni descrive gli aggiornamenti delle credenziali come modifiche a certificati e segreti di applicazioni a tenant singolo e multitenant. La variante applications.myOrganization limita il sottotipo di applicazione. Distingue inoltre applications/permissions/update, che modifica la configurazione delle autorizzazioni, dalla concessione effettiva del consenso. Conservate queste differenze quando confrontate le definizioni; nomi di azioni simili non sono intercambiabili. Autorizzazioni personalizzate per la registrazione delle applicazioni.

Un percorso condizionale di abuso delle credenziali

Microsoft avverte che un amministratore capace di aggiungere credenziali applicative può impersonare quell’applicazione, le cui autorizzazioni possono superare le sue. Quanto segue è un’inferenza operativa derivata da tale avvertimento e dal modello di ambito dei ruoli personalizzati: un’assegnazione effettiva di aggiornamento delle credenziali con ambito di directory può esporre le registrazioni delle applicazioni di quella directory; un’assegnazione limitata a una registrazione restringe di conseguenza il bersaglio. Delegare le autorizzazioni di gestione delle applicazioni.

La catena così dedotta richiede un’assegnazione effettiva o un’attivazione consentita, una credenziale accettata per l’applicazione bersaglio e autorizzazioni applicative effettive utili. Non concede automaticamente Global Administrator. Non dimostra il controllo di tutte le identità dei carichi di lavoro: una registrazione applicativa locale, un’identità gestita e un’entità servizio di un’applicazione di proprietà esterna sono oggetti diversi. Delega della gestione delle applicazioni, RBAC e identità dei carichi di lavoro.

Un rilevatore che conta le definizioni non può stabilire questa catena. PA_CUSTOM_ROLE_EXCESSIVE verifica il numero di ruoli non predefiniti, e non le loro azioni o gli ambiti delle assegnazioni (azure/privileged-access/roles/custom-role-excessive.go:24). Una sola definizione potente può quindi meritare un’indagine anche quando quel controllo numerico non rileva problemi.

I ruoli amministrativi denominati restano popolazioni distinte

Application Administrator riguarda l’amministrazione delle applicazioni; Exchange Administrator e SharePoint Administrator governano i rispettivi servizi. Security Administrator gestisce la configurazione di sicurezza, mentre Privileged Role Administrator gestisce le assegnazioni dei ruoli e PIM. Sono responsabilità distinte nella documentazione dei ruoli Microsoft, e non cinque nomi per lo stesso privilegio. Riferimento dei ruoli predefiniti.

Consigliamo di chiedere a ogni responsabile di servizio di spiegare le attività che richiedono il suo ruolo, l’ambito necessario e il periodo di accesso previsto. Mantenete visibili i titolari non umani: il nostro articolo correlato su le entità servizio con ruoli amministrativi e privilegi permanenti esamina la responsabilità e il ciclo di vita dei titolari. Completa un inventario delle definizioni senza sostituirlo.

Misurazione: richieste Microsoft Graph documentate

Le richieste seguenti sono copiate dagli esempi HTTP o dalle sintassi di richiesta Learn citati. Ognuna ha il proprio blocco di codice. Sono documentazione, e non istruzioni eseguite su un tenant per questo articolo. In un audit autorizzato, registrate l’ora di raccolta, le autorizzazioni, lo stato della risposta e la paginazione. Seguite ogni @odata.nextLink restituito; classificate una raccolta fallita o incompleta come sconosciuta, e non come zero assegnazioni.

1. Elencare le definizioni e classificare i ruoli personalizzati

L’esempio Learn del provider di directory elenca le definizioni dei ruoli:

GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleDefinitions

La stessa API documenta il filtro di uguaglianza su isBuiltIn. Per la richiesta mostrata, classificate localmente le definizioni restituite usando isBuiltIn=false, conservate gli identificatori e lo stato di abilitazione ed esaminate le raccolte di autorizzazioni. RoleManagement.Read.Directory è un’autorizzazione di lettura supportata; le chiamate delegate richiedono anche un ruolo operatore appropriato. Elencare roleDefinitions.

Consigliamo di conservare la definizione originale accanto alla vostra interpretazione. Un nome visualizzato come «Application Support» non spiega quali azioni di scrittura consenta. Inserite le azioni esatte, il responsabile aziendale e la giustificazione nel registro di audit affinché un futuro revisore possa confrontare autorizzazioni anziché nomi.

2. Distinguere i ruoli predefiniti attivati

L’esempio documentato per directoryRoles è:

GET https://graph.microsoft.com/v1.0/directoryRoles

Questa operazione restituisce i ruoli attivati, e non l’intero insieme delle definizioni predefinite disponibili. L’attivazione di un ruolo di directory in questa API non è neppure una sessione di attivazione PIM di un utente. Riconciliate roleTemplateId dove appropriato anziché considerare intercambiabili gli identificatori di istanza e di definizione. Elencare directoryRoles.

3. Raccogliere le assegnazioni attive

Learn documenta la sintassi di richiesta del provider di directory:

GET /roleManagement/directory/roleAssignments

Usate la radice del servizio v1.0 per quel percorso relativo. Learn fornisce anche questo esempio esatto di filtro ed espansione:

GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?$filter=roleDefinitionId eq '62e90394-69f5-4237-9190-012177145e10'&$expand=principal

Il GUID corrisponde all’esempio Global Administrator di Microsoft, e non a una definizione personalizzata scoperta nel vostro tenant. Per un’indagine su una singola definizione, sostituitelo con l’identificatore di definizione verificato. L’API di elenco supporta $filter, $expand e $select, con RoleManagement.Read.Directory fra le autorizzazioni di lettura. Elencare unifiedRoleAssignments.

Collegate le assegnazioni alle definizioni tramite roleDefinitionId e conservate principalId e directoryScopeId. Le entità supportate comprendono utenti, gruppi a cui possono essere assegnati ruoli ed entità servizio. Un’entità gruppo espansa resta un oggetto gruppo; non rappresenta un conteggio delle persone che ricevono accesso tramite appartenenza. Campi e relazioni delle assegnazioni.

4. Raccogliere separatamente l’idoneità PIM

L’esempio documentato per l’idoneità è:

GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleEligibilityScheduleInstances

L’API restituisce istanze di idoneità e supporta selezione, filtro ed espansione. La sua autorizzazione di lettura con privilegio minimo è RoleEligibilitySchedule.Read.Directory; anche l’accesso delegato richiede un ruolo operatore. Elencare roleEligibilityScheduleInstances.

Consigliamo di conservare separatamente i record attivi e idonei prima di produrre una vista combinata. Fate corrispondere entità, definizione, ambito e date pertinenti. Un elenco attivo vuoto non permette di stabilire se qualcuno resti idoneo, e una risposta sull’idoneità non può dimostrare l’utilizzo storico. Registrate esattamente a quale domanda risponde ogni insieme di dati.

5. Identificare le assegnazioni privilegiate senza nascondere la versione dell’API

La pagina Learn sui ruoli privilegiati fornisce questo esempio facoltativo:

GET https://graph.microsoft.com/beta/roleManagement/directory/roleAssignments?$expand=roleDefinition&$filter=roleDefinition/isPrivileged eq true

Si tratta esplicitamente di una richiesta beta. Non riscrivetela silenziosamente come v1.0 e non suggerite che isPrivileged sia una proprietà documentata dalla risorsa di definizione v1.0 usata sopra. La pagina descrive anche l’etichetta PRIVILEGED nell’interfaccia di amministrazione. Identificazione dei ruoli privilegiati.

Rilevamento: contare assegnazioni, entità distinte e dati sconosciuti

Consigliamo di produrre la seguente scheda per ogni ruolo. Sono campi di rendicontazione dell’audit, e non ulteriori limiti Microsoft:

Per un ruolo abilitato senza assegnazioni raccolte, riconciliate prima gli identificatori e confermate che entrambi i percorsi di raccolta siano riusciti. Poi chiedete al suo responsabile se la definizione abbia una finalità prevista. Descrivetelo come «abilitato senza assegnazioni attive o idonee raccolte», e non come «mai utilizzato». Il predicato UNUSED del collettore verifica le corrispondenze nei dati di input attuali, e non la cronologia delle attività (azure/privileged-access/roles/unused-admin-role.go:36).

Per i conteggi dei titolari, dichiarate se il numero rappresenti record di assegnazione o entità distinte. Il rilevatore condiviso TOO_MANY confronta gli identificatori dei ruoli e conta le voci di assegnazione corrispondenti; non deduplica le persone, non filtra il tipo di entità e non restringe l’ambito (azure/privileged-access/roles/too-many-privileged-roles.go:43). Trattate il risultato come un segnale di triage che richiede questa scheda.

Trasformare un segnale in una decisione verificabile

Consigliamo di dare a ogni riscontro un esito esplicito: mantenere con giustificazione, indagare evidenze incomplete, rimuovere un’assegnazione, restringere un’assegnazione o ritirare una definizione personalizzata. Registrate la persona responsabile della decisione e le evidenze che ha esaminato. Conservate il risultato del rilevatore accanto all’esito per distinguere un’eccezione operativa da un errore di misurazione.

Per un riscontro sul conteggio delle definizioni, chiedete un confronto delle autorizzazioni prima di consigliare un consolidamento. Per un riscontro UNUSED, chiedete i record di raccolta attivi e idonei prima di consigliare il ritiro. Per un riscontro TOO_MANY, chiedete quali entità e ambiti abbiano prodotto il conteggio prima di consigliare una popolazione più piccola. Queste domande seguono i tre predicati descritti sopra; nessuna richiede di inventare un risultato di sfruttamento.

Consigliamo di documentare la regola di conteggio nell’esportazione stessa. Se un’entità compare in più ambiti, spiegate se il rapporto conta separatamente quelle assegnazioni. Se compare un gruppo, etichettate la sua assegnazione come una concessione a un gruppo e riservate un campo separato alle evidenze di appartenenza. Se non è stato possibile raccogliere l’idoneità, indicate come provvisoria la conclusione di assenza. Ciò rende il rapporto utilizzabile da un revisore che non ha effettuato la raccolta.

Scegliete le evidenze di chiusura all’apertura del riscontro. Un’attività di ritiro di una definizione deve terminare con l’assenza della definizione approvata in un nuovo inventario. Un’attività di rimozione di un’assegnazione deve terminare con l’assenza di quella specifica concessione nell’insieme di dati pertinente. Un’eccezione mantenuta deve terminare con una finalità documentata e una data futura di verifica. Sono criteri di accettazione consigliati per l’audit, e non affermazioni su una funzionalità di applicazione automatica.

Microsoft consiglia meno di cinque Global Administrators e meno di dieci assegnazioni di ruoli privilegiati nell’intera organizzazione. Sono raccomandazioni di governance, e non tetti di assegnazione imposti. La pagina citata non stabilisce un limite di due-quattro titolari per ruolo Application, Exchange, Security, SharePoint o Privileged Role Administrator. Le soglie per ruolo del collettore sono valori predefiniti del prodotto. Procedure consigliate per i ruoli Microsoft Entra.

Correzione: ritirare le definizioni ridondanti e governare gli accessi restanti (Remediation)

1. Decidere quali ruoli personalizzati mantenere

Consigliamo di esaminare ogni definizione con il responsabile del servizio: quale operazione esatta la richiede, quale ambito più ristretto funziona e chi risponde delle modifiche future? Consolidate le definizioni ridondanti solo dopo aver confrontato le loro azioni e assegnazioni previste. Mantenete i ruoli personalizzati utili quando implementano l’insieme di autorizzazioni richiesto in modo più preciso di un ruolo predefinito. Selezione dei ruoli con privilegio minimo.

Trattatelo come un registro delle decisioni, e non come una corsa a raggiungere una dimensione arbitraria del catalogo. Per una definizione apparentemente vuota, acquisite gli inventari attivi e idonei, confermate la qualità della raccolta e indagate le dipendenze previste prima di approvare il ritiro. Dove l’accesso resta necessario, date priorità alla riduzione delle azioni superflue di gestione delle credenziali e degli ambiti applicativi ampi. Autorizzazioni personalizzate di registrazione.

2. Rimuovere le assegnazioni superflue, poi eliminare le definizioni personalizzate approvate

Consigliamo di separare le due decisioni di modifica. Rimuovere un’assegnazione riguarda l’accesso di un titolare; ritirare una definizione riguarda il catalogo dei ruoli. L’API di eliminazione Microsoft supporta le definizioni personalizzate, vieta l’eliminazione dei ruoli predefiniti e documenta questa sintassi:

DELETE /roleManagement/directory/roleDefinitions/{id}

È un’operazione di scrittura citata, non eseguita qui. Sostituite {id} solo con l’identificatore della definizione personalizzata approvata. Learn indica RoleManagement.ReadWrite.Directory come autorizzazione API con privilegio minimo e Privileged Role Administrator come ruolo operatore delegato supportato con privilegio minimo. Un’eliminazione riuscita restituisce 204 No Content. Eliminare unifiedRoleDefinition.

Per un ruolo predefinito segnalato da UNUSED, documentate perché non abbia titolari e se l’istanza attivata sia ancora pertinente. Non applicate una procedura di eliminazione delle definizioni personalizzate a ogni risultato UNUSED. Consigliamo di verificare gli inventari di definizioni e assegnazioni dopo la modifica prima di chiuderla.

3. Stabilire popolazioni giustificate e migrare a PIM gli accessi umani adatti

Consigliamo un budget di accesso per ruolo basato sulle mansioni richieste e sulla copertura operativa, con eccezioni esplicite. Valutate le assegnazioni privilegiate aggregate dell’organizzazione rispetto alle indicazioni Microsoft invece di trattare le soglie del collettore come quote Microsoft obbligatorie.

PIM supporta l’attivazione limitata nel tempo e basata sull’approvazione per i ruoli Entra predefiniti e personalizzati. Il suo piano di distribuzione consiglia di testare un progetto pilota, configurare le impostazioni per ogni ruolo e preservare l’accesso di emergenza. Le entità servizio non possono ricevere assegnazioni idonee; possono ricevere assegnazioni attive limitate nel tempo. Il piano Microsoft consiglia due account di emergenza esclusivamente cloud con assegnazioni Global Administrator permanenti. Pianificare una distribuzione PIM.

Per le assegnazioni umane adatte, consigliamo di testare approvazione, MFA, giustificazione e durata rispetto al modello operativo previsto prima della distribuzione. Il nostro articolo su i controlli di approvazione, MFA, giustificazione e durata dell’attivazione PIM copre quella verifica separata della configurazione.

Confermate le licenze prima di adottare il piano: l’uso dei ruoli personalizzati richiede P1 per gli utenti assegnati, mentre PIM richiede P2 o Governance. Le verifiche di accesso delle entità servizio richiedono Workload ID Premium oltre a P2 o Governance. Licenze dei ruoli personalizzati, Licenze PIM e indicazioni sui ruoli, Prerequisiti delle verifiche PIM.

4. Verificare l’accesso e applicare le decisioni

In PIM, selezionate i ruoli Entra e le popolazioni pertinenti, scegliete assegnazioni attive, idonee o entrambe e configurate i revisori responsabili e la gestione delle mancate risposte. Una verifica acquisisce un’istantanea al suo avvio; i gruppi a cui possono essere assegnati ruoli compaiono senza espansione dei membri. Creare verifiche di accesso ai ruoli.

Consigliamo di conservare l’ambito della verifica accanto ai risultati per evitare che «verifica completata» venga confuso con «tutti gli accessi amministrativi verificati». Documentate separatamente le evidenze di appartenenza quando un ruolo viene assegnato a un gruppo. Affidate ai responsabili dei carichi di lavoro una verifica adatta all’identità di servizio invece di presumere che i controlli di attivazione umana la coprano.

L’accesso negato viene rimosso quando si applicano i risultati della verifica, manualmente o tramite l’applicazione automatica configurata. Registrare semplicemente un rifiuto non è il passaggio finale di revoca. Completare le verifiche di accesso ai ruoli.

5. Verificare il risultato con le stesse misure

Consigliamo di ripetere le letture documentate dopo le modifiche, confrontando identificatori di definizione, azioni delle autorizzazioni, ambiti e assegnazioni attive e idonee. Controllate la modifica specifica approvata: un titolare rimosso, un’autorizzazione ristretta o una definizione ritirata. Conservate eccezioni e dati sconosciuti invece di dichiarare riuscito l’audit perché un conteggio è sceso.

Come EtcSec rileva questa situazione

I sette identificatori seguenti esistono nel catalogo. Le loro implementazioni sono state lette in etc-collector al commit b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c. I percorsi seguenti sono relativi a public/internal/audit/detectors/.

CUSTOM usa azure/privileged-access/roles/custom-role-excessive.go:24; UNUSED usa azure/privileged-access/roles/unused-admin-role.go:36. Tutti e cinque i controlli TOO_MANY usano il metodo condiviso Detect() in azure/privileged-access/roles/too-many-privileged-roles.go:43. I loro costruttori individuali too-many-*-admins.go impostano le soglie alla riga 17 e le gravità alla riga 19. Ogni implementazione restituisce un riscontro anche con Count=0; il rilevamento positivo richiede Count>0. Oltre la soglia, CUSTOM e TOO_MANY restituiscono il conteggio completo delle corrispondenze, e non solo l’eccesso.

Le cinque voci TOO_MANY sono Info con peso 0 nel catalogo, sebbene i loro costruttori emettano High, o Critical per Privileged Role Administrator. Questa discrepanza viene conservata esplicitamente. Non aumentate silenziosamente il punteggio del catalogo e non descrivete le gravità di esecuzione come valori del catalogo.

I limiti della raccolta influenzano l’interpretazione

Il provider esaminato combina le assegnazioni attive con l’idoneità raccolta usando entità, ruolo e ambito (public/internal/providers/azure/client.go:1597, :1626, :1784). Il suo inventario dei ruoli combina istanze predefinite attivate con definizioni personalizzate, associando gli identificatori delle definizioni personalizzate a RoleTemplateID e impostando il loro attributo interno IsEnabled=true senza copiare il valore di abilitazione di Graph (client.go:1500).

Le letture delle definizioni personalizzate vengono effettuate al meglio delle possibilità; i percorsi di ruoli e idoneità esaminati non implementano cicli nextLink. Errori HTTP o di analisi dell’idoneità possono restituire una mappa vuota (client.go:404). Di conseguenza, una raccolta dell’idoneità mancante può produrre un risultato UNUSED apparente o sottostimare le popolazioni TOO_MANY. Sono osservazioni statiche del codice, e non errori di tenant riprodotti.

Chiudete l’audit con evidenze separate sulla necessità delle definizioni, sulla giustificazione dei titolari e sulla revoca effettiva. Un risultato entro le soglie è utile, ma la decisione di cui rispondere è se ogni autorizzazione e assegnazione mantenuta abbia ancora una finalità documentata.