Definire i criteri dell'organizzazione per gestire l'accesso alle applicazioni nell'ambiente
Dopo aver identificato una o più applicazioni per cui si intende usare Microsoft Entra ID per gestirne l'accesso, annotare i criteri dell'organizzazione per determinare quali utenti devono avere accesso e altri vincoli che il sistema deve fornire.
Selezionare le applicazioni e i relativi ruoli nell'ambito
Le organizzazioni con requisiti di conformità o piani di gestione dei rischi sono dotate di applicazioni sensibili o critiche per l'azienda. Se l'applicazione è un'applicazione esistente nell'ambiente, è possibile che siano già stati definiti i criteri di accesso per chi "deve avere accesso" a questa applicazione. In caso contrario, potrebbe essere necessario rivolgersi a vari stakeholder, ad esempio ai membri del team di conformità e gestione dei rischi, per assicurarsi che i criteri usati per automatizzare le decisioni di accesso siano appropriati allo scenario in uso.
Raccogliere i ruoli e le autorizzazioni forniti da ogni applicazione. Alcune applicazioni possono avere un solo ruolo, ad esempio un'applicazione con solo il ruolo "Utente". Delle applicazioni più complesse potrebbero avere più ruoli da gestire tramite Microsoft Entra ID. Questi ruoli dell'applicazione in genere impongono ampi vincoli sull'accesso che un utente con quel ruolo ha all'interno dell'applicazione. Ad esempio un'applicazione con un utente amministratore può avere due ruoli, "Utente" e "Amministratore". Altre applicazioni possono anche basarsi su appartenenze a gruppi o attestazioni per controlli di ruolo più granulari che possono essere forniti all'applicazione da Microsoft Entra ID nel provisioning o attestazioni rilasciate usando protocolli SSO di federazione o scritti in AD come appartenenza a un gruppo di sicurezza. Infine, potrebbero esserci ruoli specifici dell'applicazione che non vengono visualizzati in Microsoft Entra ID, ad esempio l'applicazione non consente di definire gli amministratori in Microsoft Entra ID, ma si basa sulle proprie regole di autorizzazione per identificare gli amministratori. SAP Cloud Identity Services ha un solo ruolo, Utente, disponibile per l'assegnazione.
Nota
Se si usa un'applicazione della raccolta di applicazioni Microsoft Entra che supporta il provisioning, Microsoft Entra ID potrebbe importare ruoli definiti nell'applicazione e aggiornare automaticamente il manifesto dell'applicazione con i ruoli dell'applicazione dopo la configurazione del provisioning.
Selezionare i ruoli e i gruppi con appartenenza che devono essere regolati in Microsoft Entra ID. In base ai requisiti di conformità e gestione dei rischi, le organizzazioni spesso assegnano priorità a quei ruoli o gruppi dell'applicazione che consentono l'accesso privilegiato o l'accesso alle informazioni riservate.
Definire i criteri dell'organizzazione con i prerequisiti utente e altri vincoli per l'accesso a un'applicazione
In questa sezione verranno determinati i criteri dell'organizzazione che si intende utilizzare per stabilire l'accesso all'applicazione. È possibile registrarlo come tabella in un foglio di calcolo, ad esempio
| Ruolo app | Prerequisito per l'accesso | Responsabili approvazione | Durata predefinita dell'accesso | Separazione dei vincoli dei compiti | Criteri di accesso condizionale |
|---|---|---|---|---|---|
| Vendite Ovest | Membro del team di vendita | responsabile utente | Revisione annuale | Non è possibile avere accesso a Vendite Est | Autenticazione a più fattori (MFA) e dispositivo registrato necessario per l'accesso |
| Vendite Ovest | Qualsiasi dipendente al di fuori delle vendite | responsabile del reparto vendite | 90 giorni | N/D | Autenticazione a più fattori e dispositivo registrato necessario per l'accesso |
| Vendite Ovest | Rappresentante vendite non dipendente | responsabile del reparto vendite | 30 giorni | N/D | Autenticazione a più fattori necessaria per l'accesso |
| Vendite Est | Membro del team di vendita | responsabile utente | Revisione annuale | Non è possibile avere accesso a Vendite Ovest | Autenticazione a più fattori e dispositivo registrato necessario per l'accesso |
| Vendite Est | Qualsiasi dipendente al di fuori delle vendite | responsabile del reparto vendite | 90 giorni | N/D | Autenticazione a più fattori e dispositivo registrato necessario per l'accesso |
| Vendite Est | Rappresentante vendite non dipendente | responsabile del reparto vendite | 30 giorni | N/D | Autenticazione a più fattori necessaria per l'accesso |
Se si ha già una definizione di ruolo dell'organizzazione, vedere come eseguire la migrazione di un ruolo aziendale per altre informazioni.
Identificare se sono presenti prerequisiti, standard che un utente deve soddisfare prima di poter accedere a un'applicazione. Ad esempio, in circostanze normali, solo i dipendenti a tempo pieno o i dipendenti di un reparto o di un centro di costo specifico dovrebbero avere il permesso ad accedere a una determinata applicazione del reparto. Inoltre, è possibile richiedere i criteri di gestione entitlement per un utente di un altro reparto che richiede l'accesso per avere uno o più responsabili di approvazione aggiuntivi. Anche se la presenza di più fasi di approvazione può rallentare il processo complessivo di accesso di un utente, queste fasi aggiuntive assicurano che le richieste di accesso siano appropriate e le decisioni siano responsabili. Ad esempio le richieste di accesso da parte di un dipendente possono avere due fasi di approvazione, prima da parte dal responsabile dell'utente richiedente e in secondo luogo da uno dei proprietari delle risorse responsabili dei dati contenuti nell'applicazione.
Stabilire per quanto tempo un utente cui è stata concessa l'autorizzazione ad accedere può mantenere l'accesso e quando tale accesso può essere revocato. Nel caso di molte applicazioni, un utente potrebbe mantenere l'accesso illimitato fino a quando non fa più parte dell'organizzazione. In alcune situazioni l'accesso potrebbe essere associato a determinati progetti o attività cardine in modo che, al loro termine, l'accesso venga rimosso automaticamente. In alternativa, se solo pochi utenti usano un'applicazione tramite un criterio, è possibile configurare revisioni trimestrali o annuali dell'accesso di ciascuno tramite i criteri, in modo che sia presente una supervisione a cadenza regolare.
Se l'organizzazione sta regolando l'accesso già con un modello di ruolo aziendale, pianificare l'inserimento di tale modello di ruolo aziendale in Microsoft Entra ID. Potrebbe essere disponibile un ruolo aziendale definito che assegna l'accesso in base alla proprietà di un utente, ad esempio la posizione o il reparto. Tali processi possono garantire che gli utenti non abbiano più accesso alla fine, quando l'accesso non è più necessario, anche nel caso in cui non esista una data di fine del progetto prestabilita.
Verificare se sono presenti vincoli di separazione dei compiti. Ad esempio, è possibile avere un'applicazione con due ruoli dell'app, Vendite Ovest e Vendite Est e assicurarsi che un utente possa avere un solo territorio di vendita alla volta. Includere un elenco di coppie di ruoli dell'app incompatibili per l'applicazione, in modo che, se un utente ha un ruolo, non sia autorizzato a richiedere il secondo ruolo.
Selezionare i criteri di accesso condizionale appropriati per l'accesso all'applicazione. Si consiglia di analizzare le applicazioni e raggrupparle in applicazioni che presentano gli stessi requisiti di risorse per gli stessi utenti. Se si tratta della prima applicazione SSO federata in fase di integrazione con Microsoft Entra ID Governance per la governance delle identità, potrebbe essere necessario creare un nuovo criterio di accesso condizionale per esprimere vincoli, ad esempio i requisiti per l'autenticazione a più fattori (MFA) o l'accesso basato sulla posizione. È possibile configurare gli utenti per accettare le condizioni per l'utilizzo. Vedere Pianificare una distribuzione dell'accesso condizionale per altre considerazioni su come definire i criteri di accesso condizionale.
Stabilire come gestire le eccezioni ai criteri. Ad esempio un'applicazione potrebbe essere generalmente disponibile solo per i dipendenti designati, ma un revisore o un fornitore potrebbe richiedere l'accesso temporaneo per un progetto specifico. In alternativa, un dipendente in trasferta potrebbe richiedere l'accesso da un'area geografica solitamente bloccata perché l'organizzazione non ha alcuna presenza in tale area geografica. In queste situazioni è possibile scegliere di avere anche un criterio di gestione entitlement per l'approvazione che può avere fasi diverse o un limite di tempo diverso o un responsabile approvazione diverso. Un fornitore che ha eseguito l'accesso come utente guest nel tenant di Microsoft Entra potrebbe non avere un responsabile, pertanto le richieste di accesso potrebbero essere approvate da uno sponsor della propria organizzazione o da un proprietario della risorsa o da un responsabile della sicurezza.
Poiché i criteri dell'organizzazione per chi deve avere accesso vengono esaminati dagli stakeholder, è possibile iniziare a integrare l'applicazione con Microsoft Entra ID. In questo modo in un passaggio successivo si è pronti a distribuire i criteri approvati dall'organizzazione per l'accesso su Microsoft Entra ID Governance.