Gestire l'accesso a un'applicazione

  • Articolo

L'integrazione di un'app nel sistema di gestione delle identità dell'organizzazione comporta problemi nella gestione degli accessi, nella valutazione dell'utilizzo e nella creazione di report. Gli amministratori IT o il personale dell'help desk devono in genere supervisionare l'accesso alle app. L'assegnazione dell'accesso può rientrare in un team IT generale o di divisione, ma idealmente i decision maker aziendali devono essere coinvolti, dando l'approvazione prima che il reparto IT completi il processo.

Altre organizzazioni investono nell'integrazione mediante sistemi automatizzati esistenti di gestione dell'accesso e dell'identità, quali il controllo degli accessi in base al ruolo (RBAC) o il controllo degli accessi in base all'attributo (ABAC). Lo sviluppo mediante integrazione e regole tende a essere specializzato e costoso. Il monitoraggio o la creazione di report in entrambi gli approcci di gestione è di per sé un investimento isolato, complesso e costoso.

In che modo Microsoft Entra ID risulta utile?

Microsoft Entra ID supporta una gestione completa degli accesi per le applicazioni configurate, consentendo alle organizzazioni di ottenere facilmente i criteri di accesso appropriati, ad esempio assegnazione automatica o basata su attributi (scenari di Controllo degli accessi in base agli attributi o Controllo degli accessi in base al ruolo) tramite delega e inclusa la gestione degli amministratori. Con Microsoft Entra ID è possibile ottenere facilmente criteri complessi, combinando più modelli di gestione per una singola applicazione e anche riutilizzare le regole di gestione tra applicazioni con gli stessi destinatari.

Con Microsoft Entra ID, la creazione di report di utilizzo e assegnazione è completamente integrata, consentendo agli amministratori di segnalare facilmente lo stato di assegnazione, gli errori di assegnazione e persino l'utilizzo.

Assegnazione di utenti e gruppi a un'app

L'assegnazione dell'applicazione di Microsoft Entra è incentrata su due modalità di assegnazione principali:

  • Singola assegnazione: un amministratore IT con autorizzazioni di amministratore applicazione cloud può selezionare singoli account utente e concedere loro l'accesso all'applicazione.

  • Assegnazione basata su gruppo (richiede Microsoft Entra ID P1 o P2) Un amministratore IT con autorizzazioni di Amministratore applicazione cloud della directory può assegnare un gruppo all'applicazione. L'accesso utente specifico è determinato dall'appartenenza al gruppo dell'utente nel momento in cui tenta di accedere all'applicazione. In altre parole, un amministratore può creare una regola di assegnazione secondo cui “tutti i membri correnti del gruppo assegnato possono accedere all’applicazione”. Con questa opzione di assegnazione, gli amministratori possono sfruttare le opzioni di gestione dei gruppi di Microsoft Entra, tra cui gruppi dinamici basati sugli attributi, gruppi di sistema esterno (ad esempio, Active Directory locale o Workday) oppure gruppi gestiti dall'amministratore o in modalità self-service. Un singolo gruppo può essere facilmente assegnato a più app, garantendo che le applicazioni con affinità di assegnazione condividano le regole di assegnazione, riducendo la complessità generale della gestione.

    Nota

    Le appartenenze ai gruppi annidati non sono supportate per l'assegnazione alle applicazioni in base al gruppo.

Mediante queste due modalità di assegnazione, gli amministratori possono ottenere qualsiasi approccio di gestione delle assegnazioni.

Richiedere l'assegnazione di utenti per un'app

Con alcuni tipi di applicazioni, è possibile scegliere di richiedere che gli utenti vengano assegnati all'applicazione. In questo modo si impedisce a tutti gli utenti di accedere ad eccezione di quelli assegnati in modo esplicito all'applicazione. Questa opzione è supportata dai tipi di applicazioni seguenti:

  • Applicazioni configurate per l'accesso Single Sign-On (SSO) federato con autenticazione basata su SAML
  • Applicazioni di Application Proxy che usano l'autenticazione preliminare di Microsoft Entra
  • Applicazioni create nella piattaforma applicativa Microsoft Entra, che usano l'autenticazione OAuth 2.0/OpenID Connect dopo che un utente o un amministratore fornisce il consenso per tale applicazione. Alcune applicazioni aziendali offrono un maggiore controllo sugli utenti autorizzati ad accedere.

Quando è richiesta l'assegnazione utente, solo gli utenti assegnati all'applicazione (tramite assegnazione utente diretta o in base all'appartenenza al gruppo) potranno eseguire l'accesso. Possono accedere all'app nel portale App personali o usando un collegamento diretto.

Quando l'assegnazione dell'utente non è necessaria, gli utenti non assegnati non visualizzano l'app in App personali, ma possono comunque accedere all'applicazione stessa (approccio noto anche come accesso avviato da SP) oppure possono usare l'URL di accesso utente nella pagina Proprietà dell'applicazione (approccio noto anche come accesso avviato da IDP). Per altre informazioni sulla richiesta di configurazioni di assegnazione utente, vedere Configurare un'applicazione

Questa impostazione non influisce sul fatto che un'applicazione venga visualizzata o meno in App personali. Le applicazioni vengono visualizzate nel portale App personali degli utenti dopo aver assegnato un utente o un gruppo all'applicazione.

Nota

Quando un'applicazione richiede l'assegnazione, il consenso utente per tale applicazione non è consentito. Questo vale anche se il consenso utente per tale app sarebbe stato altrimenti consentito. Assicurarsi di concedere il consenso amministratore a livello di tenant alle app che richiedono l'assegnazione.

Per alcune applicazioni, l'opzione per richiedere l'assegnazione di utenti non è disponibile nelle proprietà dell'applicazione. In questi casi, è possibile usare PowerShell per impostare la proprietà appRoleAssignmentRequired nell'entità servizio.

Determinazione dell'esperienza utente per l'accesso alle app

Microsoft Entra ID offre diversi modi personalizzabili per distribuire applicazioni agli utenti finali dell'organizzazione:

  • App personali di Microsoft Entra
  • Utilità di avvio delle applicazioni di Microsoft 365
  • Accesso diretto alle app federate (service-pr)
  • Collegamenti diretti per applicazioni federate, basate su password o esistenti

È possibile determinare se gli utenti assegnati a un'app aziendale possono visualizzarla in App personali e nell'utilità di avvio delle applicazioni di Microsoft 365.

Esempio: Assegnazione di applicazioni complesse con Microsoft Entra ID

Si tenga in considerazione un'applicazione come Salesforce. In molte organizzazioni, Salesforce viene principalmente usata dai team di vendita e marketing. Spesso, i membri del team di marketing dispongono di privilegi elevati per l'accesso a Salesforce, mentre i membri del team di vendita ha accesso limitato. In molti casi numerosi information worker hanno accesso limitato all'applicazione. ed eventuali eccezioni a tale regola rendono la questione più complessa. Spesso è prerogativa dei team responsabili del marketing o delle vendite concedere a un utente l'accesso o modificare i ruoli indipendentemente da queste regole generiche.

Con Microsoft Entra ID le applicazioni come Salesforce possono essere preconfigurate per l'accesso Single Sign-On (SSO) e il provisioning automatizzato. Dopo aver configurato l'applicazione, un amministratore può intraprendere l'azione singola di creazione e assegnazione ai gruppi appropriati. In questo esempio un amministratore può eseguire le assegnazioni seguenti:

  • gruppi dinamici possono essere definiti in modo da rappresentare automaticamente tutti i membri dei team di marketing e vendita mediante attributi quali reparto o ruolo:

    • In Salesforce, tutti i membri dei gruppi di marketing verrebbero assegnati al ruolo "marketing".
    • In Salesforce, tutti i membri dei gruppi di vendita verrebbero assegnati al ruolo "sales". Un'ulteriore perfezionamento potrebbe prevedere l'utilizzo di più gruppi che rappresentino i team di vendita suddivisi per area assegnati a diversi ruoli in Salesforce.

  • Per abilitare il meccanismo delle eccezioni, è possibile creare un gruppo self-service per ogni ruolo. Ad esempio, è possibile creare come gruppo self-service il gruppo "Eccezione marketing Salesforce". Il gruppo può essere assegnato al ruolo marketing in Salesforce e il team responsabile del marketing può essere definito come proprietario. I membri del team responsabile del marketing potrebbero aggiungere o rimuovere utenti, impostare criteri di join o addirittura approvare o negare le richieste di join dei singoli utenti. Questo meccanismo è supportato attraverso un'appropriata esperienza di un information worker che non richiede una formazione specifica per proprietari o membri.

In questo caso viene effettuato automaticamente il provisioning di tutti gli utenti assegnati a Salesforce. Man mano che vengono aggiunti a gruppi diversi, l'assegnazione di ruolo verrà aggiornata in Salesforce. Gli utenti possono individuare e accedere a Salesforce tramite App personali, client Web di Office o passando alla pagina di accesso di Salesforce dell'organizzazione. Gli amministratori possono visualizzare facilmente lo stato di utilizzo e assegnazione usando la creazione di report di Microsoft Entra ID.

Gli amministratori possono usare l'Accesso condizionale di Microsoft Entra per impostare i criteri di accesso per ruoli specifici. Questi criteri possono includere se l'accesso è consentito all'esterno dell'ambiente aziendale e anche l'autenticazione a più fattori o i requisiti dei dispositivi per ottenere l'accesso in vari casi.

Accesso alle applicazioni Microsoft

Le applicazioni Microsoft, ad esempio Exchange, SharePoint, Yammer e così via, vengono assegnate e gestite in modo leggermente diverso rispetto alle applicazioni SaaS non Microsoft o ad altre applicazioni integrate con Microsoft Entra ID per l'accesso Single Sign-On.

Vi sono tre principali modi con cui un utente può accedere a un'applicazione pubblicata da Microsoft.

  • Per le applicazioni in Microsoft 365 o altre suite a pagamento, agli utenti viene concesso l'accesso tramite assegnazione di licenze direttamente al rispettivo account utente o tramite un gruppo che usa la funzionalità di assegnazione delle licenze basata su gruppo.

  • Per le applicazioni che Microsoft o un’organizzazione non Microsoft pubblica per l'utilizzo gratuito da parte di chiunque, gli utenti possono ottenere l'accesso tramite il consenso utente. Gli utenti accedono all'applicazione con il proprio account di Microsoft Entra aziendale o dell'istituto di istruzione e consentono l'accesso a un set limitato di dati nel proprio account.

  • Per le applicazioni che Microsoft o un’organizzazione non Microsoft pubblica per l'utilizzo gratuito da parte di chiunque, gli utenti possono ottenere l'accesso tramite il consenso dell'amministratore. Ciò significa che un amministratore ha determinato che l'applicazione può essere usata da qualsiasi utente dell'organizzazione e, tale scopo, ha effettuato l'accesso all'applicazione con un ruolo di amministratore ruolo con privilegi ha consentito l'accesso a tutti gli utenti dell'organizzazione.

Alcune applicazioni combinano questi metodi. Ad esempio, alcune applicazioni Microsoft fanno parte di un abbonamento a Microsoft 365, ma richiedono comunque il consenso.

Gli utenti possono accedere alle applicazioni di Microsoft 365 tramite i portali di Office 365. È anche possibile visualizzare o nascondere le applicazioni di Microsoft 365 in App personali con l'attivazione/disattivazione visibilità di Office 365 nelle Impostazioni utente della directory.

Analogamente alle app aziendali, è possibile assegnare utenti a determinate applicazioni Microsoft tramite l'interfaccia di amministrazione di Microsoft Entra o tramite PowerShell.

Impedire l'accesso alle applicazioni tramite account locali

Microsoft Entra ID consente all'organizzazione di configurare l'accesso Single Sign-On per proteggere il modo in cui gli utenti eseguono l'autenticazione alle applicazioni con accesso condizionale, autenticazione a più fattori e così via. Alcune applicazioni hanno un proprio archivio utenti locale e consentono agli utenti di accedere all'applicazione usando credenziali locali o un metodo di autenticazione di backup specifico dell'applicazione, anziché usare l'accesso Single Sign-On. Queste funzionalità dell'applicazione potrebbero essere usate in modo improprio e consentire agli utenti di mantenere l'accesso alle applicazioni anche dopo che non sono più assegnati all'applicazione in Microsoft Entra ID o non possono più accedere a Microsoft Entra ID e potrebbero consentire a utenti malintenzionati di compromettere l'applicazione senza essere visualizzati nei log id di Microsoft Entra. Per assicurarsi che gli accessi a queste applicazioni siano protetti da Microsoft Entra ID:

  • Identificare le applicazioni connesse alla directory per l'accesso Single Sign-On per consentire agli utenti finali di ignorare l'accesso Single Sign-On con credenziali dell'applicazione locale o un metodo di autenticazione di backup. Sarà necessario esaminare la documentazione fornita dal provider di applicazioni per capire se è possibile e quali impostazioni sono disponibili. Quindi, in tali applicazioni disabilitare le impostazioni che consentono agli utenti finali di ignorare l'accesso SSO. Verificare che l'esperienza utente finale è stata protetta aprendo un browser in InPrivate, connettendosi alla pagina di accesso delle applicazioni, fornendo l'identità di un utente nel tenant e verificare che non vi sia alcuna opzione di accesso diversa da Microsoft Entra.
  • Se l'applicazione fornisce un'API per gestire le password utente, rimuovere le password locali o impostare una password univoca per ogni utente usando le API. Ciò impedirà agli utenti finali di accedere all'applicazione con credenziali locali.
  • Se l'applicazione fornisce un'API per gestire gli utenti, configurare il provisioning utenti di Microsoft Entra in tale applicazione per disabilitare o eliminare gli account utente quando gli utenti non rientrano più nell'ambito dell'applicazione o del tenant.

Passaggi successivi