Integrazione di applicazioni con Microsoft Entra ID e definizione di una baseline di accesso esaminato
Dopo aver stabilito i criteri per chi deve avere accesso a un'applicazione, è possibile connettere l'applicazione a Microsoft Entra ID e quindi distribuire i criteri per controllare l'accesso.
Microsoft Entra ID Governance può essere integrato con molte applicazioni, tra cui SAP R/3, SAP S/4HANA e quelli che usano standard come OpenID Connect, SAML, SCIM, SQL, LDAP, SOAP e REST. Grazie a questi standard, è possibile usare Microsoft Entra ID con molte applicazioni SaaS e applicazioni locali comuni, incluse le applicazioni sviluppate dall'organizzazione. Questo piano di distribuzione illustra come connettere l'applicazione all'ID Microsoft Entra e abilitare l'uso delle funzionalità di governance delle identità per tale applicazione.
Affinché Microsoft Entra ID Governance possa essere utilizzato per un'applicazione, l'applicazione deve prima essere integrata con Microsoft Entra ID e rappresentata nella directory. Un'applicazione integrata con Microsoft Entra ID significa che è necessario soddisfare uno dei due requisiti seguenti:
- L'applicazione si basa sull'ID Microsoft Entra per l'accesso SSO federato e microsoft Entra ID controlla il rilascio dei token di autenticazione. Se Microsoft Entra ID è l'unico provider di identità per l'applicazione, solo gli utenti assegnati a uno dei ruoli dell'applicazione in Microsoft Entra ID possono accedere all'applicazione. Gli utenti che perdono l'assegnazione del ruolo applicazione non possono più ottenere un nuovo token per accedere all'applicazione.
- L'applicazione si basa su elenchi di utenti o gruppi forniti all'applicazione dall'ID Microsoft Entra. Questo adempimento può essere eseguito tramite un protocollo di provisioning, ad esempio SCIM, tramite l'applicazione che esegue query su Microsoft Entra ID tramite Microsoft Graph o l'applicazione che usa AD Kerberos per ottenere le appartenenze ai gruppi di un utente.
Se nessuno di questi criteri viene soddisfatto per un'applicazione, ad esempio quando l'applicazione non si basa su Microsoft Entra ID, è comunque possibile usare Identity Governance. Tuttavia, potrebbero esserci alcune limitazioni nell'uso della governance delle identità se non vengono rispettati i criteri. Ad esempio, gli utenti che non si trovano nell'ID Microsoft Entra o che non sono assegnati ai ruoli dell'applicazione in Microsoft Entra ID, non verranno inclusi nelle verifiche di accesso dell'applicazione, fino a quando non vengono assegnati ai ruoli dell'applicazione. Per altre informazioni, vedere Preparazione per una revisione dell'accesso degli utenti a un'applicazione.
Integrare l'applicazione con Microsoft Entra ID per garantire che solo gli utenti autorizzati possano accedere all'applicazione
L'integrazione di un processo di applicazione inizia quando si configura l'applicazione in modo che si basi su Microsoft Entra ID per l'autenticazione utente, con una connessione al protocollo SSO (Single Sign-On) federato e quindi si aggiunge il provisioning. I protocolli più comunemente usati per l'accesso SSO sono SAML e OpenID Connect. Altre informazioni sugli strumenti e sul processo per individuare ed eseguire la migrazione dell'autenticazione dell'applicazione a Microsoft Entra ID.
Successivamente, se l'applicazione implementa un protocollo di provisioning, è necessario configurare Microsoft Entra ID per effettuare il provisioning degli utenti all'applicazione, in modo che Microsoft Entra ID possa segnalare all'applicazione quando un utente ha concesso l'accesso o l'accesso di un utente è stato rimosso. Questi segnali di provisioning consentono all'applicazione di apportare correzioni automatiche, come ad esempio riassegnare il contenuto creato da un dipendente che ha lasciato l'azienda al suo manager.
Verificare se l'applicazione è presente nell'elenco delle applicazioni aziendali o nell'elenco delle registrazioni delle app. Se l'applicazione è già presente nel locatario, vai al passaggio 5 di questa sezione.
Se l'applicazione è un'applicazione SaaS non già registrata nel tenant, verificare la presenza di applicazioni disponibili nella raccolta di applicazioni che può essere integrata per l'accesso SSO federato. Se è presente nella raccolta, usare le esercitazioni per integrare l'applicazione con Microsoft Entra ID.
- Seguire l'esercitazione per configurare l'applicazione con SSO federato tramite Microsoft Entra ID.
- se l'applicazione supporta il provisioning, configurare l'applicazione per il provisioning.
- Al termine, passare alla sezione successiva di questo articolo. Se l'applicazione SaaS non è presente nella raccolta, chiedere al fornitore SaaS di eseguire l'onboarding di.
Se si tratta di un'applicazione privata o personalizzata, è anche possibile selezionare un'integrazione dell'accesso Single Sign-On più appropriata in base alla posizione e alle funzionalità dell'applicazione.
Se questa applicazione si trova in SAP Business Technology Platform (BTP), configurare l'integrazione di Microsoft Entra con SAP Cloud Identity Services. Per ulteriori informazioni, vedere Integrazione SSO di Microsoft Entra con SAP BTP e Gestione dell'accesso a SAP BTP.
Se l'applicazione si trova nel cloud pubblico e supporta l'accesso Single Sign-On, configurare l'accesso Single Sign-On direttamente da Microsoft Entra ID all'applicazione.
L'applicazione supporta Passaggi successivi OpenID Connect Aggiungere un'applicazione OAuth OpenID Connect SAML 2.0 Registrare e configurare l'applicazione con gli endpoint SAML e il certificato di Microsoft Entra ID SAML 1.1 Aggiungere un'applicazione basata su SAML Se si tratta di un'applicazione SAP che usa l'interfaccia utente grafica SAP, integrare Microsoft Entra per l'accesso Single Sign-On usando l'integrazione con SAP Secure Login Service o integrazione con Microsoft Entra Private Access.
In caso contrario, se si tratta di un'applicazione ospitata in locale o IaaS che supporta l'accesso Single Sign-On, configurare l'accesso Single Sign-On da Microsoft Entra ID all'applicazione tramite il proxy dell'applicazione.
L'applicazione supporta Passaggi successivi SAML 2.0 Distribuire il proxy dell'applicazione e configurare un'applicazione per SAML SSO Autenticazione integrata di Windows (IWA) Distribuire il proxy dell'applicazione , configurare un'applicazione per l'autenticazione integrata Windows SSO e impostare le regole del firewall per impedire l'accesso agli endpoint dell'applicazione, ad eccezione del proxy. Autenticazione basata su intestazioni Distribuire il proxy dell'applicazione e configurare un'applicazione per l'SSO basato su intestazioni
Se l'applicazione si trova in SAP BTP, è possibile usare i gruppi di Microsoft Entra per mantenere l'appartenenza a ogni ruolo. Per altre informazioni sull'assegnazione dei gruppi alle raccolte di ruoli BTP, vedere Gestione dell'accesso a SAP BTP.
Se la tua applicazione ha più ruoli, ogni utente ha un solo ruolo specifico nell'applicazione, e l'applicazione si basa su Microsoft Entra ID per inviare il ruolo specifico dell'applicazione di un utente come attestazione quando un utente accede all'applicazione, quindi configura questi ruoli dell'applicazione in Microsoft Entra ID e assegna ogni utente al ruolo dell'applicazione. È possibile usare l'interfaccia utente dei ruoli dell'app per aggiungere tali ruoli al manifesto dell'applicazione. Se si usano le librerie di autenticazione Microsoft, è disponibile un esempio di codice per l'uso dei ruoli dell'app all'interno dell'applicazione per il controllo di accesso. Se un utente potesse avere più ruoli contemporaneamente, potresti voler implementare l'applicazione per controllare i gruppi di sicurezza, nelle attestazioni del token o disponibili tramite Microsoft Graph, anziché utilizzare i ruoli dell'app definiti nel manifesto per il controllo degli accessi.
Se l'applicazione supporta il provisioning, configurare il provisioning degli utenti e dei gruppi assegnati da Microsoft Entra ID a tale applicazione. Se si tratta di un'applicazione privata o personalizzata, è anche possibile selezionare l'integrazione più appropriata in base alla posizione e alle funzionalità dell'applicazione.
Se questa applicazione si basa su SAP Cloud Identity Services, configura il provisioning degli utenti tramite SCIM nei servizi SAP Cloud Identity Services.
L'applicazione supporta Passaggi successivi SAP Cloud Identity Services Configurare l'ID Microsoft Entra per provisionare gli utenti in SAP Cloud Identity Services Se questa applicazione si trova nel cloud pubblico e supporta SCIM, configurare il provisioning degli utenti tramite SCIM.
L'applicazione supporta Passaggi successivi SCIM Configurare un'applicazione con SCIM per il provisioning degli utenti Se questa applicazione usa Active Directory, configurare il writeback dei gruppi e aggiornare l'applicazione in modo da usare i gruppi creati dall'ID Microsoft Entra, o annidare i gruppi creati dall'ID Microsoft Entra nei gruppi di sicurezza esistenti delle applicazioni di Active Directory.
L'applicazione supporta Passaggi successivi Kerberos Configurare il writeback dei gruppi di Microsoft Entra Cloud Sync in AD, creare gruppi in Microsoft Entra ID e effettuare il writeback di questi gruppi in AD In caso contrario, se si tratta di un'applicazione ospitata in locale o IaaS e non è integrata con AD, configurare il provisioning per tale applicazione, tramite SCIM o al database o alla directory sottostante dell'applicazione.
L'applicazione supporta Passaggi successivi SCIM configurare un'applicazione con l'agente di provisioning per le app basate su SCIM locali account utente locali, memorizzati in un database SQL configurare un'applicazione con l'agente di provisioning per le applicazioni basate su SQL locale account utenti locali, archiviati in una directory LDAP configurare un'applicazione con l'agente di provisioning per le applicazioni basate su LDAP locale account utenti locali, gestiti tramite API SOAP o REST configurare un'applicazione con l'agente di provisioning utilizzando il connettore Servizi Web account utente locali, gestiti tramite un connettore MIM configurare un'applicazione con l'agente di provisioning con un connettore personalizzato SAP ECC con NetWeaver AS ABAP 7.0 o versione successiva configurare un'applicazione con l'agente di provisioning con un connettore di servizi Web configurato da SAP ECC
Se l'applicazione usa Microsoft Graph per eseguire query sui gruppi da Microsoft Entra ID, consenso alle applicazioni per avere le autorizzazioni appropriate per la lettura dal tenant.
Imposta che l'accesso all'applicazione sia consentito solo agli utenti assegnati all'applicazione. Questa impostazione impedisce agli utenti di visualizzare inavvertitamente l'applicazione in MyApps e di tentare di accedere all'applicazione, prima dell'abilitazione dei criteri di accesso condizionale.
Eseguire una verifica di accesso iniziale
Se si tratta di una nuova applicazione che l'organizzazione non ha usato in precedenza e pertanto nessuno ha accesso preesistente o se è già stata eseguita la verifica di accesso per questa applicazione, passare alla sezione successiva .
Tuttavia, se l'applicazione era già nell'ambiente in uso, gli utenti potrebbero aver ottenuto l'accesso in passato tramite processi manuali o fuori banda. È consigliabile esaminare gli utenti per verificare che l'accesso sia ancora necessario e appropriato. È consigliabile eseguire una verifica di accesso degli utenti che hanno già accesso all'applicazione, prima di abilitare i criteri per consentire a più utenti di richiedere l'accesso. Questa revisione imposta una baseline in cui tutti gli utenti vengono esaminati almeno una volta per assicurarsi che siano autorizzati per l'accesso continuo.
- Segui i passaggi descritti in Preparazione per una revisione dell'accesso degli utenti a un'applicazione.
- Se l'applicazione non usa l'ID Microsoft Entra o AD, ma supporta un protocollo di provisioning o ha un database SQL o LDAP sottostante, inserire qualsiasi utenti esistenti e creare assegnazioni di ruolo dell'applicazione.
- Se l'applicazione non usa Microsoft Entra ID o AD e non supporta un protocollo di provisioning, ottenere un elenco di utenti dall'applicazione e creare assegnazioni di ruolo dell'applicazione per ognuna di esse.
- Se l'applicazione usava gruppi di sicurezza di Active Directory, è necessario esaminare l'appartenenza a tali gruppi di sicurezza.
- Se l'applicazione ha una propria directory o database e non è stata integrata per il provisioning, una volta completata la verifica, potrebbe essere necessario aggiornare manualmente il database interno o la directory dell'applicazione per rimuovere gli utenti che sono stati negati.
- Se l'applicazione usa i gruppi di sicurezza di Active Directory e tali gruppi sono stati creati in Active Directory, al termine della revisione, è necessario aggiornare manualmente i gruppi di Active Directory per rimuovere le appartenenze di tali utenti che sono stati negati. Successivamente, per aver negato i diritti di accesso rimossi automaticamente, è possibile aggiornare l'applicazione in modo da usare un gruppo di Active Directory creato in Microsoft Entra ID e riscritto in Microsoft Entra IDoppure spostare l'appartenenza dal gruppo AD al gruppo Microsoft Entra e annidare il gruppo riscritto come unico membro del gruppo AD.
- Dopo aver completato la verifica e aver aggiornato l'accesso all'applicazione o se nessun utente ha accesso, continuare con i passaggi successivi per distribuire i criteri di accesso condizionale e di gestione entitlement per l'applicazione.
Ora che si dispone di una baseline che garantisce che l'accesso esistente sia stato esaminato, è possibile distribuire i criteri dell'organizzazione per l'accesso continuo e le nuove richieste di accesso.