Pacchetti di accesso Entra Entitlement Management: pilota governato

Che cosa sono i pacchetti di accesso Entra Entitlement Management?

I pacchetti di accesso Entra Entitlement Management trasformano un'attività aziendale definita in una richiesta di accesso governata. Un primo pacchetto utile risponde a domande pratiche: quali risorse servono per questa attività, chi è responsabile della decisione, chi può richiedere l'accesso e quando deve terminare l'assegnazione? Iniziate con un progetto i cui proprietari delle risorse possano spiegare queste risposte e aiutare a verificarle.

Microsoft descrive un pacchetto come un insieme di accessi alle risorse regolato da criteri, all'interno di un catalogo. Gruppi, applicazioni aziendali e siti SharePoint Online sono risorse supportate. I criteri definiscono idoneità, approvazione e durata dell'assegnazione. I cataloghi delimitano la delega. I pacchetti possono servire dipendenti o utenti esterni. Questi concetti provengono dalla panoramica di Entitlement Management su Microsoft Learn.

L'assenza di un pacchetto è un'osservazione di configurazione da approfondire. Non dimostra che la vostra organizzazione sia priva di governance degli accessi. Potreste già disporre di un servizio di richiesta documentato, dell'approvazione dei proprietari delle risorse e di procedure affidabili di rimozione. Valutate questo processo rispetto all'esigenza aziendale prima di decidere se Entitlement Management lo migliorerebbe.

Come funziona: delimitare il progetto pilota governato

Considerate un team di progetto che necessita di un ruolo applicativo specifico e dell'accesso ai documenti del progetto. È uno scenario illustrativo di pianificazione, non un rilievo misurato in un tenant. Annotate gli utenti previsti, le risorse, i livelli di autorizzazione, l'approvatore e la condizione di fine prima di aprire la procedura guidata. Chiedete a ogni proprietario di risorsa di confermare che l'accesso proposto sia sufficiente per l'attività e non più ampio del necessario.

Mantenete il pilota abbastanza circoscritto da poter spiegare ogni autorizzazione inclusa. Evitate di raggruppare accessi non correlati solo perché le risorse appartengono allo stesso reparto. Registrate la persona responsabile della manutenzione del pacchetto e quella responsabile di ogni risorsa. Queste responsabilità possono spettare a persone diverse; il passaggio di consegne conta quando una risorsa cambia o un progetto termina.

La panoramica colloca esplicitamente i pacchetti accanto ad altri meccanismi di assegnazione. Sono adatti ad attività a tempo limitato, accessi soggetti ad approvazione e scenari di collaborazione; non sostituiscono tutti i metodi di assegnazione esistenti. Confrontate il pilota con l'appartenenza ordinaria ai gruppi e con il processo esistente di richiesta di servizio. Scegliete il meccanismo che consente al proprietario di approvare l'accesso corretto e dimostrarne la rimozione. Microsoft Learn: quando usare i pacchetti di accesso.

L'appartenenza dinamica e l'accesso governato rispondono anche a domande operative diverse. La selezione basata sugli attributi può identificare una popolazione, mentre un criterio del pacchetto definisce come quella popolazione riceve un diritto specifico. Il nostro articolo sul ritiro dell'operatore memberOf tratta l'appartenenza dinamica e le dipendenze dell'assegnazione automatica di Entitlement Management. Usatelo per esaminare la logica di assegnazione esistente prima di progettare un pilota basato sulle richieste, senza presumere che una migrazione di regole di gruppo fornisca prove di approvazione o scadenza.

Verificare le licenze e i prerequisiti amministrativi

I requisiti di licenza della panoramica Learn citano Microsoft Entra ID Governance o Microsoft Entra Suite per gli utenti dell'organizzazione e indicano che alcune funzionalità possono operare con Microsoft Entra ID P2. Considerateli una verifica delle licenze per singola funzionalità, anziché un'istruzione universale di acquistare un abbonamento specifico.

La tabella dei fondamenti delle licenze di Governance elenca le richieste self-service degli utenti, i gruppi, le applicazioni, i siti SharePoint, i responsabili gerarchici o approvatori specifici e la scadenza delle assegnazioni sotto P2, oltre che Governance e Suite. In quella tabella, i criteri di assegnazione automatica e gli sponsor dei profili utente come approvatori richiedono Governance o Suite. I prodotti Governance hanno anche abbonamenti prerequisiti; la governance degli ospiti ha considerazioni di fatturazione separate. Verificate le funzionalità previste e la popolazione idonea rispetto alla documentazione Learn attuale prima di abilitare il pilota. Non deducete il diritto d'uso dalla semplice presenza di una licenza in qualche punto del tenant.

Concentrate il primo test su utenti umani e risorse di progetto ordinarie. Se in seguito aggiungete funzionalità avanzate, riesaminate licenze e autorizzazioni delegate invece di mantenere le ipotesi del pilota. Registrate la decisione sulle licenze accanto al progetto del pacchetto, affinché il prossimo responsabile comprenda quali scelte siano state deliberate.

Rilevamento: stabilire se i pacchetti sono assenti

Nel Microsoft Entra admin center, esaminate ID Governance > Entitlement management > Access package, il percorso documentato nella guida alla creazione. Confermate la directory e la vostra visibilità prima di interpretare una vista vuota. Conservate la data di osservazione, l'osservatore e l'ambito insieme all'inventario.

Per un inventario tramite API, Microsoft documenta la seguente richiesta in List accessPackages:

GET https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/accessPackages

L'API restituisce i pacchetti che il chiamante può leggere nei cataloghi. La tabella delle autorizzazioni indica EntitlementManagement.Read.All come autorizzazione OAuth con privilegi minimi per l'accesso delegato e applicativo; i chiamanti delegati necessitano anche di un ruolo supportato. Per i chiamanti che usano soltanto un'applicazione, Microsoft supporta anche l'assegnazione di un ruolo appropriato al posto di quell'autorizzazione applicativa; Catalog reader è un'opzione con privilegi inferiori. L'accesso specifico a un catalogo può limitare ciò che il chiamante vede. Una risposta vuota riuscita consente quindi di concludere che i pacchetti sono assenti nell'intero tenant solo se l'ambito della raccolta copre i suoi cataloghi. Completate l'enumerazione, incluso qualsiasi collegamento di continuazione restituito, prima di registrare un inventario come completo.

La documentazione della risorsa Graph accessPackage descrive il catalogo del pacchetto, i criteri di assegnazione e le relazioni con i ruoli delle risorse. Elencare gli oggetti pacchetto è una verifica di esistenza; esaminare separatamente tali relazioni è necessario per valutare se un pacchetto rappresenti l'accesso previsto.

La richiesta sopra è un metodo di ispezione documentato, non una query eseguita su un tenant cliente per questo articolo. Conservate lo stato effettivo, l'ambito della raccolta e la risposta del vostro audit autorizzato. Un errore di autenticazione, un errore di autorizzazione, un'esecuzione interrotta o un ambito non verificato devono figurare nelle prove come limiti della raccolta. Nessuno giustifica scrivere «nessun pacchetto configurato».

Correzione: creare il pacchetto e provarne il ciclo di vita (Remediation)

1. Selezionare il catalogo e i ruoli delle risorse

Seguite il flusso di creazione Learn: selezionate New access package, inserite nome e descrizione in Basics e scegliete il catalogo. Identity Governance Administrator, catalog owner o access package manager possono creare pacchetti nel proprio ambito autorizzato. Gli access package managers usano risorse già presenti nel catalogo; non possono aggiungervi risorse. In Resource roles, selezionate le risorse e i ruoli previsti.

Scegliete deliberatamente il catalogo e indicate il proprietario responsabile nel registro del pilota. Usate una descrizione che permetta al richiedente di riconoscere l'attività aziendale. Fate esaminare i ruoli selezionati ai proprietari delle risorse prima di proseguire. Il ruolo di proprietario di un gruppo è sostanzialmente diverso dall'appartenenza e un ruolo di amministratore dell'applicazione può essere superfluo per il normale lavoro di progetto. Esaminate l'autorizzazione effettiva, non soltanto il nome visualizzato della risorsa.

2. Definire i richiedenti e gli approvatori

In Requests, configurate gli utenti idonei e le impostazioni di approvazione del criterio iniziale. Richiedete l'approvazione per il pilota, scegliete l'approvatore designato e richiedete una giustificazione della richiesta. Se usate l'opzione del responsabile gerarchico, configurate un'alternativa per i casi in cui manchi tale informazione. In Who can request access, selezionate Self per questo pilota in cui l'utente richiede l'accesso. Questi controlli sono documentati nelle impostazioni di approvazione della guida alla creazione.

Preferite una popolazione pilota chiaramente definita a un ambito ampio di richieste. Chiedete all'approvatore quali informazioni gli servano per decidere e se possa riconoscere una richiesta inappropriata. Eseguite il test con un utente idoneo e uno fuori ambito. Registrate le decisioni attese prima del test per distinguere un difetto del criterio da un requisito frainteso.

Per la collaborazione esterna, esaminate anche l'accesso condizionale degli ospiti e le impostazioni di collaborazione esterna. L'articolo tratta la protezione degli accessi degli ospiti, gli inviti, la visibilità e i controlli del ciclo di vita. Usatelo per inquadrare i controlli che circondano la popolazione esterna; l'approvazione del pacchetto da sola non documenta quella revisione più ampia.

3. Configurare la scadenza prima di creare il pacchetto

In Lifecycle, selezionate una scadenza dell'assegnazione per data o durata e decidete se le estensioni sono consentite e richiedono approvazione. Esaminate la configurazione in Review + create, quindi selezionate Create per creare il pacchetto e il criterio iniziale. Questi sono i passaggi di creazione documentati.

Scegliete la condizione di fine in base alla tempistica aziendale dell'attività. Per il pilota, usate un'assegnazione di test che possa raggiungere la scadenza programmata durante la finestra di verifica. Concordate i tempi con il proprietario della risorsa. Documentate come verranno gestite le estensioni legittime e chi le deciderà. Evitate di lasciare un'assegnazione permanente solo perché verificare la scadenza richiede più coordinamento.

4. Verificare l'accesso fornito, poi l'accesso dopo la scadenza

La guida Microsoft alla gestione delle assegnazioni documenta Assignments, i dettagli delle singole assegnazioni e i filtri di stato Delivering ed Expired. Gli errori di fornitura possono essere analizzati tramite la voce corrispondente in Requests. Usate queste viste per raccogliere prove dello stato effettivo dell'assegnazione di test.

Inviate la richiesta del pilota attraverso il percorso di approvazione configurato. Registrate il richiedente, il criterio selezionato, la decisione, l'identificatore dell'assegnazione e l'ora di fine prevista. Verificate che l'utente di test riceva il ruolo di risorsa previsto e possa svolgere l'attività consentita. Provate anche un'operazione significativa che l'utente non dovrebbe poter eseguire. Un accesso riuscito, da solo, dice poco sull'adeguatezza del ruolo assegnato.

Dopo la scadenza programmata, acquisite l'assegnazione scaduta e verificate di nuovo l'accesso alle risorse. Confrontate l'appartenenza, l'assegnazione applicativa e la capacità dell'utente di svolgere l'attività con le prove precedenti. Se l'accesso permane, esaminate le altre concessioni prima di affermare che il pacchetto ha fallito o che la scadenza ha rimosso tutto l'accesso effettivo. Lo stesso utente potrebbe avere un diritto separato che il vostro pilota non intendeva rimuovere.

Conservate entrambe le osservazioni nel registro del pilota. «Pacchetto creato» è una tappa di configurazione; «accesso approvato fornito, poi assegnazione scaduta e accesso previsto alle risorse ritirato» è l'esito di verifica che cercate di stabilire. Questo articolo non sostiene che un test del genere sia già riuscito in alcun tenant.

Come EtcSec rileva questa configurazione

Il rilevatore AZ_ENTITLEMENT_MANAGEMENT di etc-collector di EtcSec valuta l'esistenza dei pacchetti raccolti attraverso AzureAccessPackagesProbed e AzureAccessPackagesCount. Il metodo Detect() esaminato presenta questi rami:

Il Count: 1 del rilievo è il numero di rilievi a livello di tenant, non un conteggio degli utenti interessati o dei criteri mancanti. Un risultato nil non convalida la selezione delle risorse, gli approvatori, l'ambito delle richieste, le licenze, la scadenza o la rimozione. Il rilevatore controlla l'esistenza, non la qualità dei criteri. Un rilievo di assenza non dimostra nemmeno che manchino tutti i processi alternativi di governance.

Usate il risultato per avviare l'indagine appropriata: copertura della raccolta per Info, valutazione aziendale e delle licenze per Medium e revisione separata del ciclo di vita quando i pacchetti esistono già. Conservate le prove di fornitura e scadenza del pilota insieme all'audit, affinché la revisione successiva possa distinguere un rilievo di esistenza risolto da una governance degli accessi dimostrata.