Condividi tramite

Integrazione di applicazioni con Microsoft Entra ID e definizione di una baseline di accesso esaminato

  • Articolo

Dopo aver stabilito i criteri per chi deve avere accesso a un'applicazione, è possibile connettere l'applicazione all'ID Microsoft Entra e quindi distribuire i criteri per gestire l'accesso.

Microsoft Entra ID Governance può essere integrato con molte applicazioni, tra cui applicazioni note come SAP R/3, SAP S/4HANA e quelle che usano standard come OpenID Connessione, 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 venga usato 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 sono in grado di 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 che usano la governance delle identità senza soddisfare 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 verifica di accesso 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

In genere questo processo di integrazione di un'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 Connessione. Per altre informazioni sugli strumenti e sul processo, vedere Individuare ed eseguire la migrazione dell'autenticazione dell'applicazione all'ID Microsoft Entra.

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, ad esempio per riassegnare il contenuto creato da un dipendente che ha lasciato il proprio responsabile.

  1. Controllare se l'applicazione è presente nell'elenco di applicazioni aziendali o nell'elenco delle registrazioni delle app. Se l'applicazione è già presente nel tenant, passare al passaggio 5 in questa sezione.

  2. Se l'applicazione è un'applicazione SaaS non già registrata nel tenant, verificare se l'applicazione è disponibile nella raccolta di applicazioni per le applicazioni che possono essere integrate per l'accesso SSO federato. Se si trova nella raccolta, usare le esercitazioni per integrare l'applicazione con Microsoft Entra ID.

    1. Seguire l'esercitazione per configurare l'applicazione per l'accesso Single Sign-On federato con Microsoft Entra ID.
    2. se l'applicazione supporta il provisioning, configurare l'applicazione per il provisioning.
    3. 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.

  3. 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 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 Connessione OpenID
      SAML 2.0 Registrare l'applicazione e configurare l'applicazione con gli endpoint SAML e il certificato di Microsoft Entra ID
      SAML 1.1 Aggiungere un'applicazione basata su SAML

    • 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 l'accesso SSO SAML
      Autenticazione integrata di Windows (IWA) Distribuire il proxy dell'applicazione, configurare un'applicazione per l'accesso Single Sign-On integrato autenticazione di Windows e impostare le regole del firewall per impedire l'accesso agli endpoint dell'applicazione, ad eccezione del proxy.
      Autenticazione basata su intestazione Distribuire il proxy dell'applicazione e configurare un'applicazione per l'accesso SSO basato su intestazione

  4. Se l'applicazione ha più ruoli, ogni utente ha un solo ruolo nell'applicazione e l'applicazione si basa su Microsoft Entra ID per inviare il ruolo specifico dell'applicazione di un utente come attestazione di un utente che accede all'applicazione, quindi configurare tali ruoli dell'app nell'ID Microsoft Entra nell'applicazione e quindi assegnare ogni utente al ruolo 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 potrebbe avere più ruoli contemporaneamente, è possibile implementare l'applicazione per controllare i gruppi di sicurezza, nelle attestazioni del token o disponibili tramite Microsoft Graph, anziché usare i ruoli dell'app dal manifesto dell'app per il controllo di accesso.

  5. Se l'applicazione supporta il provisioning, configurare il provisioning di utenti e gruppi assegnati dall'ID Microsoft Entra 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.

  6. Se l'applicazione usa Microsoft Graph per eseguire query sui gruppi da Microsoft Entra ID, fornire il consenso alle applicazioni per avere le autorizzazioni appropriate per la lettura dal tenant.

  7. Impostare l'accesso all'applicazione solo per gli 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 esiste già nell'ambiente in uso, è possibile che gli utenti abbiano ottenuto l'accesso in passato tramite processi manuali o fuori banda e che gli utenti debbano ora essere esaminati per avere conferma che l'accesso è ancora necessario e appropriato in futuro. È 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 di tutti gli utenti che sono stati esaminati almeno una volta, per assicurarsi che tali utenti siano autorizzati per l'accesso continuo.

  1. Seguire la procedura descritta in Preparazione per una verifica di accesso dell'accesso degli utenti a un'applicazione.
  2. Se l'applicazione non usa microsoft Entra ID o AD, ma supporta un protocollo di provisioning o ha un database SQL o LDAP sottostante, inserire eventuali utenti esistenti e creare assegnazioni di ruolo dell'applicazione.
  3. 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.
  4. Se l'applicazione usava gruppi di sicurezza di Active Directory, è necessario esaminare l'appartenenza a tali gruppi di sicurezza.
  5. 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.
  6. 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 ID oppure spostare l'appartenenza dal gruppo AD al gruppo Microsoft Entra e annidare il gruppo scritto come unico membro del gruppo AD.
  7. 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.

Passaggi successivi