Gestire l'accesso eseguendo la migrazione di un modello di ruolo aziendale a Microsoft Entra ID Governance
Il controllo degli accessi in base al ruolo fornisce un framework per la classificazione di utenti e risorse IT. Questo framework consente di rendere esplicita la relazione e i diritti di accesso appropriati in base a tale classificazione. Ad esempio, assegnando a un utente attributi che specificano il titolo di lavoro degli utenti e le assegnazioni di progetto, all'utente può essere concesso l'accesso agli strumenti necessari per il lavoro e i dati dell'utente che l'utente deve contribuire a un determinato progetto. Quando l'utente presuppone un processo diverso e diverse assegnazioni di progetto, la modifica degli attributi che specificano il titolo di lavoro e i progetti dell'utente bloccano automaticamente l'accesso alle risorse necessarie solo per la posizione precedente degli utenti.
In Microsoft Entra ID è possibile usare modelli di ruolo in diversi modi per gestire l'accesso su larga scala tramite la governance delle identità.
- È possibile usare i pacchetti di accesso per rappresentare i ruoli dell'organizzazione nell'organizzazione, ad esempio "rappresentante vendite". Un pacchetto di accesso che rappresenta il ruolo dell'organizzazione include tutti i diritti di accesso che un rappresentante potrebbe in genere richiedere, tra più risorse.
- Le applicazioni possono definire i propri ruoli. Ad esempio, se si dispone di un'applicazione di vendita e tale applicazione include il ruolo app "venditore" nel manifesto, è possibile includere tale ruolo dal manifesto dell'app in un pacchetto di accesso. Le applicazioni possono anche usare gruppi di sicurezza in scenari in cui un utente potrebbe avere più ruoli specifici dell'applicazione contemporaneamente.
- È possibile usare i ruoli per delegare l'accesso amministrativo. Se si dispone di un catalogo per tutti i pacchetti di accesso necessari per le vendite, è possibile assegnare un utente responsabile di tale catalogo assegnando loro un ruolo specifico del catalogo.
Questo articolo illustra come modellare i ruoli dell'organizzazione, usando i pacchetti di accesso alla gestione entitlement, in modo da poter eseguire la migrazione delle definizioni dei ruoli a Microsoft Entra ID per applicare l'accesso.
Migrazione di un modello di ruolo aziendale
La tabella seguente illustra in che modo i concetti nelle definizioni dei ruoli dell'organizzazione con cui si ha familiarità con altri prodotti corrispondono alle funzionalità della gestione entitlement.
Ad esempio, un'organizzazione può avere un modello di ruolo aziendale esistente simile alla tabella seguente.
| Nome ruolo | Autorizzazioni fornite dal ruolo | Assegnazione automatica al ruolo | Assegnazione basata su richiesta al ruolo | Separazione dei controlli dei compiti |
|---|---|---|---|---|
| Venditore | Membro del team di vendita | Sì | No | None |
| Sales Solution Manager | Autorizzazioni del ruolo dell'app Salesperson e Solution Manager nell'applicazione Sales | None | Un venditore può richiedere, richiede l'approvazione del manager e la revisione trimestrale | Il richiedente non può essere un Responsabile account vendite |
| Sales Account Manager | Autorizzazioni del ruolo dell'app Salesperson e Account Manager nell'applicazione Sales | None | Un venditore può richiedere, richiede l'approvazione del manager e la revisione trimestrale | La richiesta non può essere un Sales Solution Manager |
| Supporto per le vendite | Stesse autorizzazioni di un venditore | None | Qualsiasi non addetto alla vendita può richiedere, richiede l'approvazione del responsabile e la revisione trimestrale | Il richiedente non può essere un venditore |
Questo può essere rappresentato in Microsoft Entra ID Governance come catalogo di pacchetti di accesso contenente quattro pacchetti di accesso.
| Pacchetto di accesso | Ruoli risorsa | Criteri | Pacchetti di accesso incompatibili |
|---|---|---|---|
| Venditore | Membro del team di vendita | Assegnazione automatica | |
| Sales Solution Manager | Ruolo dell'app Solution Manager nell'applicazione Sales | Basato su richiesta | Sales Account Manager |
| Sales Account Manager | Ruolo dell'app Account Manager nell'applicazione Sales | Basato su richiesta | Sales Solution Manager |
| Supporto per le vendite | Membro del team di vendita | Basato su richiesta | Venditore |
Le sezioni successive illustrano il processo di migrazione, creando gli artefatti Microsoft Entra ID e Microsoft Entra ID Governance per implementare l'accesso equivalente di un modello di ruolo aziendale.
Connessione le app a cui fanno riferimento le autorizzazioni nei ruoli dell'organizzazione a Microsoft Entra ID
Se i ruoli dell'organizzazione vengono usati per assegnare autorizzazioni che controllano l'accesso alle app SaaS non Microsoft, alle app locali o alle proprie app cloud, sarà necessario connettere le applicazioni a Microsoft Entra ID.
Per consentire a un pacchetto di accesso che rappresenta un ruolo aziendale di fare riferimento ai ruoli di un'applicazione come autorizzazioni da includere nel ruolo, per un'applicazione con più ruoli e supporta standard moderni, ad esempio SCIM, è necessario integrare l'applicazione con Microsoft Entra ID e assicurarsi che i ruoli dell'applicazione siano elencati nel manifesto dell'applicazione.
Se l'applicazione ha un solo ruolo, è comunque necessario integrare l'applicazione con l'ID Microsoft Entra. Per le applicazioni che non supportano SCIM, Microsoft Entra ID può scrivere utenti nella directory esistente o nel database SQL di un'applicazione o aggiungere utenti di AD in un gruppo di Active Directory.
Popolare lo schema di Microsoft Entra usato dalle app e per le regole di ambito utente nei ruoli dell'organizzazione
Se le definizioni di ruolo includono istruzioni nel formato "tutti gli utenti con questi valori di attributo vengono assegnati automaticamente al ruolo" o "gli utenti con questi valori di attributo sono autorizzati a richiedere", sarà necessario assicurarsi che tali attributi siano presenti in Microsoft Entra ID.
È possibile estendere lo schema di Microsoft Entra e quindi popolare tali attributi da AD locale, tramite Microsoft Entra Connessione o da un sistema HR, ad esempio Workday o SuccessFactors.
Creare cataloghi per la delega
Se la manutenzione continua dei ruoli viene delegata, è possibile delegare l'amministrazione dei pacchetti di accesso creando un catalogo per ogni parte dell'organizzazione a cui si delega.
Se sono disponibili più cataloghi da creare, è possibile usare uno script di PowerShell per creare ogni catalogo.
Se non si prevede di delegare l'amministrazione dei pacchetti di accesso, è possibile mantenere i pacchetti di accesso in un unico catalogo.
Aggiungere risorse ai cataloghi
Dopo aver identificato i cataloghi, aggiungere le applicazioni, i gruppi o i siti inclusi nei pacchetti di accesso che rappresentano i ruoli dell'organizzazione ai cataloghi.
Se si dispone di molte risorse, è possibile usare uno script di PowerShell per aggiungere ogni risorsa a un catalogo.
Creare pacchetti di accesso corrispondenti alle definizioni dei ruoli dell'organizzazione
Ogni definizione di ruolo aziendale può essere rappresentata con un pacchetto di accesso in tale catalogo.
È possibile usare uno script di PowerShell per creare un pacchetto di accesso in un catalogo.
Dopo aver creato un pacchetto di accesso, collegare uno o più ruoli delle risorse nel catalogo al pacchetto di accesso. Rappresenta le autorizzazioni del ruolo dell'organizzazione.
Inoltre, si creeranno criteri per l'assegnazione diretta, come parte di tale pacchetto di accesso che può essere usato per tenere traccia degli utenti che hanno già assegnazioni di ruolo dell'organizzazione.
Creare assegnazioni di pacchetti di accesso per singole assegnazioni di ruolo dell'organizzazione esistenti
Se alcuni utenti dispongono già di appartenenze ai ruoli dell'organizzazione, che non riceveranno tramite assegnazione automatica, è necessario creare assegnazioni dirette per tali utenti ai pacchetti di accesso corrispondenti.
Se si hanno molti utenti che necessitano di assegnazioni, è possibile usare uno script di PowerShell per assegnare ogni utente a un pacchetto di accesso. In questo modo gli utenti verranno collegati ai criteri di assegnazione diretta.
Aggiungere criteri a tali pacchetti di accesso per l'assegnazione automatica
Se la definizione del ruolo aziendale include una regola basata sugli attributi dell'utente da assegnare e rimuovere automaticamente l'accesso in base a tali attributi, è possibile rappresentarlo usando un criterio di assegnazione automatica. Un pacchetto di accesso può avere al massimo un criterio di assegnazione automatica.
Se sono presenti molte definizioni di ruolo ognuna con una definizione di ruolo, è possibile usare uno script di PowerShell per creare ogni criterio di assegnazione automatica in ogni pacchetto di accesso.
Impostare i pacchetti di accesso come incompatibili per la separazione dei compiti
Se si dispone di una separazione dei vincoli dei compiti che impediscono a un utente di assumere un ruolo aziendale quando ne ha già un altro, è possibile impedire all'utente di richiedere l'accesso nella gestione entitlement contrassegnando tali combinazioni di pacchetti di accesso come incompatibili.
Per ogni pacchetto di accesso che deve essere contrassegnato come incompatibile con un altro, è possibile usare uno script di PowerShell per configurare i pacchetti di accesso come incompatibili.
Aggiungere criteri per accedere ai pacchetti per consentire agli utenti di richiedere
Se gli utenti che non hanno già un ruolo aziendale possono richiedere e essere approvati per assumere un ruolo, è anche possibile configurare la gestione entitlement per consentire agli utenti di richiedere un pacchetto di accesso. È possibile aggiungere altri criteri a un pacchetto di accesso e in ogni criterio specificare quali utenti possono richiedere e chi deve approvare.
Configurare le verifiche di accesso nei criteri di assegnazione dei pacchetti di accesso
Se i ruoli dell'organizzazione richiedono una revisione regolare dell'appartenenza, è possibile configurare verifiche di accesso ricorrenti nei criteri di assegnazione diretta e basati sulle richieste.