Limitare l'accesso a un tenant

Le organizzazioni di grandi dimensioni che enfatizzano la sicurezza vogliono passare a servizi cloud come Microsoft 365, ma devono sapere che gli utenti possono accedere solo alle risorse approvate. In genere, le aziende limitano gli indirizzi IP o i nomi di dominio quando vogliono gestire gli accessi. Questo approccio non riesce in un mondo in cui le app Software as a Service (o SaaS) sono ospitate in un cloud pubblico, in esecuzione su nomi di dominio condivisi come outlook.office.com e login.microsoftonline.com. Bloccare questi indirizzi impedirebbe totalmente agli utenti di accedere ad Outlook sul Web invece di limitare il loro accesso alle identità e alle risorse approvate.

La soluzione Microsoft Entra a questa sfida è una funzionalità denominata restrizioni del tenant. Con le restrizioni del tenant, le organizzazioni possono controllare l'accesso alle applicazioni cloud SaaS, in base al tenant di Microsoft Entra, le applicazioni usate per l'accesso Single Sign-On. Ad esempio, è possibile consentire l'accesso alle applicazioni Microsoft 365 dell'organizzazione, impedendo l'accesso alle istanze di altre organizzazioni di queste stesse applicazioni.

Con le restrizioni del tenant, le organizzazioni possono specificare l'elenco di tenant a cui gli utenti della rete possono accedere. Microsoft Entra ID concede quindi solo l'accesso a questi tenant consentiti: tutti gli altri tenant vengono bloccati, anche quelli in cui gli utenti potrebbero essere guest.

Questo articolo è incentrato sulle restrizioni dei tenant per Microsoft 365, ma la funzionalità protegge tutte le app che inviano l'utente all'ID Microsoft Entra per l'accesso Single Sign-On. Se si usano app SaaS con un tenant Microsoft Entra diverso dal tenant usato da Microsoft 365, assicurarsi che tutti i tenant necessari siano consentiti. Ad esempio, negli scenari di collaborazione B2B. Per ulteriori informazioni sulle app cloud SaaS, vedere il Marketplace di Active Directory.

La funzionalità restrizioni del tenant supporta anche il blocco dell'uso di tutte le applicazioni consumer Microsoft (app MSA), ad esempio OneDrive, Hotmail e Xbox.com. Questa funzionalità usa un'intestazione separata per l'endpoint login.live.com ed è descritta in dettaglio alla fine di questo articolo.

Funzionamento

La soluzione globale è composta dai seguenti elementi:

  1. Microsoft Entra ID: se l'intestazione Restrict-Access-To-Tenants: <permitted tenant list> è presente, Microsoft Entra-only rilascia token di sicurezza per i tenant autorizzati.

  2. Infrastruttura server proxy locale: questa infrastruttura è un dispositivo proxy in grado di eseguire l'ispezione TLS (Transport Layer Security). È necessario configurare il proxy per inserire l'intestazione contenente l'elenco dei tenant consentiti nel traffico destinato all'ID Microsoft Entra.

  3. Software client: per supportare le restrizioni del tenant, il software client deve richiedere token direttamente dall'ID Microsoft Entra, in modo che l'infrastruttura proxy possa intercettare il traffico. La funzionalità Restrizioni del tenant è attualmente supportata dalle applicazioni Microsoft 365 basate su browser e dai client Office che usano l'autenticazione moderna come OAuth 2.0.

  4. Autenticazione moderna: i servizi cloud devono usare l'autenticazione moderna per usare restrizioni del tenant e bloccare l'accesso a tutti i tenant non inviati. È necessario configurare i servizi cloud di Microsoft 365 in modo da usare i protocolli di autenticazione moderna per impostazione predefinita. Per le informazioni più recenti sul supporto di Microsoft 365 per l'autenticazione moderna, vedere Aggiornamento dell'autenticazione moderna di Office 365.

Il diagramma seguente illustra il flusso di traffico di alto livello. Le restrizioni del tenant richiedono l'ispezione TLS solo sul traffico verso Microsoft Entra ID, non ai servizi cloud di Microsoft 365. Questa distinzione è importante, perché il volume di traffico per l'autenticazione verso Microsoft Entra ID è in genere molto inferiore rispetto al volume di traffico verso applicazioni SaaS come Exchange Online e SharePoint Online.

Diagram of tenant restrictions traffic flow.

Configurazione di Restrizioni del tenant

Ci sono due passaggi iniziali per quanto riguarda Restrizioni del tenant. Per prima cosa bisogna controllare che i client possano connettersi agli indirizzi corretti. In seguito bisogna configurare l'infrastruttura proxy.

URL e indirizzi IP

Per usare le restrizioni del tenant, i client devono essere in grado di connettersi agli URL di Microsoft Entra seguenti per l'autenticazione:

  • login.microsoftonline.com
  • login.microsoft.com
  • login.windows.net

Inoltre, per accedere a Office 365, i client devono potersi connettere ai nomi di dominio completi (FQDN), agli URL e agli indirizzi IP definiti in URL e intervalli di indirizzi IP per Office 365.

Configurazione e requisiti del proxy

Per abilitare Restrizioni del tenant nell'infrastruttura proxy è necessaria la configurazione seguente. Queste indicazioni sono generice, quindi è consigliabile fare riferimento alla documentazione del fornitore del proxy per passaggi di implementazione specifici.

Prerequisiti

  • Il proxy deve poter eseguire l'intercettazione SSL, inserire intestazioni HTTP e filtrare le destinazioni tramite URL/FQDN.

  • I client devono considerare attendibile la catena di certificati presentata dal proxy per le comunicazioni TLS. Ad esempio, se vengono usati certificati da un'infrastruttura a chiave pubblica (PKI) interna, deve essere considerato attendibile il certificato interno dell'autorità di certificazione interna.

  • Le licenze microsoft Entra ID P1 o P2 sono necessarie per l'uso delle restrizioni del tenant.

Impostazione

Per ogni richiesta in uscita a , e login.windows.net, inserire due intestazioni HTTP: Restrict-Access-To-Tenants e Restrict-Access-Context. login.microsoft.comlogin.microsoftonline.com

Nota

Non includere sottodomini *.login.microsoftonline.com nella configurazione del proxy. Questa operazione includerà device.login.microsoftonline.com e interferirà con l'autenticazione del certificato client, usata negli scenari di registrazione del dispositivo e accesso condizionale basato su dispositivo. Configurare il server proxy per escludere device.login.microsoftonline.com e enterpriseregistration.windows.net dall'inserimento di intestazioni e interruzioni TLS.

Le intestazioni devono includere gli elementi seguenti:

  • Per Restrict-Access-To-Tenants, usare un valore di <elenco tenant consentiti>, ovvero un elenco delimitato da virgole contenente i tenant a cui gli utenti possono accedere. Qualsiasi dominio registrato con un tenant può essere usato per identificare il tenant in questo elenco e l'ID directory stesso. Per un esempio di tutti e tre i modi per descrivere un tenant, la coppia nome-valore per consentire Contoso, Fabrikam e Microsoft è simile alla seguente: Restrict-Access-To-Tenants: contoso.com,fabrikam.onmicrosoft.com,72f988bf-86f1-41af-91ab-2d7cd011db47

  • Per Restrict-Access-Context, usare un valore ID di directory singola, dichiarando quale tenant imposta Restrizioni del tenant. Per dichiarare, ad esempio, Contoso come tenant per l'impostazione dei criteri di Restrizioni del tenant, la coppia nome-valore è simile alla seguente: Restrict-Access-Context: 456ff232-35l2-5h23-b3b3-3236w0826f3d. Per ottenere i log per queste autenticazioni, è necessario usare il proprio ID directory. Se si usa un ID di directory diverso dal proprio, i log di accesso *vengono visualizzati nel tenant di un altro utente, con tutte le informazioni personali rimosse. Per altre informazioni, vedere Amministrazione esperienza.

Per trovare l'ID directory:

  1. Accedere all'interfaccia di amministrazione di Microsoft Entra come almeno un lettore globale.
  2. Passare a Panoramica delle> identità.>
  3. Copiare il valore id tenant.

Per verificare che un ID directory o un nome di dominio faccia riferimento allo stesso tenant, usare tale ID o dominio al posto del <tenant> in questo URL: https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration. Se i risultati con il dominio e l'ID corrispondono, viene fatto riferimento allo stesso tenant.

Per impedire agli utenti di inserire la propria intestazione HTTP con tenant non approvati, il proxy deve sostituire l'intestazione Restrict-Access-To-Tenants se è già presente nella richiesta in ingresso.

I client devono essere costretti a usare il proxy per tutte le richieste a login.microsoftonline.com, login.microsoft.come login.windows.net. Ad esempio, se vengono usati file PAC per reindirizzare i client all'uso del proxy, gli utenti finali non devono poter modificare o disabilitare tali file.

Esperienza utente

In questa sezione viene illustrata l'esperienza per utenti finali e amministratori.

Esperienza utente finale

Un utente di esempio si trova nella rete Contoso ma tenta di accedere online all'istanza Fabrikam di un'applicazione SaaS condivisa come Outlook. Se Fabrikam è un tenant non inviato per l'istanza di Contoso, l'utente visualizza un messaggio di negazione dell'accesso. Il messaggio di rifiuto indica che si sta tentando di accedere a una risorsa appartenente a un'organizzazione non approvata dal reparto IT.

Screenshot of tenant restrictions error message, from April 2021.

Esperienza di amministrazione

Mentre la configurazione delle restrizioni del tenant viene eseguita nell'infrastruttura proxy aziendale, gli amministratori possono accedere direttamente ai report sulle restrizioni del tenant nell'interfaccia di amministrazione di Microsoft Entra. Per visualizzare i report:

  1. Accedere all'interfaccia di amministrazione di Microsoft Entra come almeno un lettore globale.
  2. Passare a Restrizioni del tenant di Panoramica>delle identità.>

L'amministratore per il tenant specificato come tenant Restricted-Access-Context può usare questo report per visualizzare gli accessi bloccati a causa dei criteri di Restrizioni del tenant, inclusi l'ID della directory di destinazione e le identità usate. Gli accessi sono inclusi se nelle impostazioni del tenant la restrizione di accesso è impostata sul tenant dell'utente o sul tenant della risorsa.

Il report può contenere informazioni limitate, ad esempio l'ID directory di destinazione, quando un utente che si trova in un tenant diverso dal tenant con accesso limitato-contesto accede. In questo caso, le informazioni identificabili dall'utente, ad esempio nome e nome dell'entità utente, vengono mascherate per proteggere i dati utente in altri tenant (ad esempio, "{PII Removed}@domain.com" or 00000000-0000-0000-0000-000000000000 al posto di nomi utente e ID oggetto in base alle esigenze).

Analogamente ad altri report nell'interfaccia di amministrazione di Microsoft Entra, è possibile usare i filtri per specificare l'ambito del report. È possibile usare filtri per intervalli di tempo, utenti, applicazioni, client o stati specifici. Se si seleziona il pulsante Colonne è possibile scegliere di visualizzare i dati con qualsiasi combinazione dei campi seguenti:

  • Utente : questo campo può rimuovere i dati personali, in cui il relativo valore è impostato su 00000000-0000-0000-0000-000000000000.
  • Applicazione
  • Stato
  • Data
  • Data (UTC) - dove UTC è Coordinated Universal Time
  • Indirizzo IP
  • Client
  • Nome utente : questo campo può avere dati personali rimossi, in cui il relativo valore è impostato su {PII Removed}@domain.com
  • Location
  • ID tenant di destinazione

Supporto tecnico di Microsoft 365

Le applicazioni Microsoft 365 devono soddisfare due criteri per supportare completamente la funzionalità Restrizioni del tenant:

  1. Il client usato supporta tecniche di autenticazione moderne.
  2. L'autenticazione moderna è abilitata come protocollo di autenticazione predefinito per il servizio cloud.

Per le informazioni più recenti su cui i client di Office attualmente supportano l'autenticazione moderna, vedere Aggiornamento dell'autenticazione moderna di Office 365. Questa pagina include anche collegamenti a istruzioni su come abilitare l'autenticazione moderna in tenant Exchange Online e Skype for Business Online specifici. SharePoint Online abilità già l'autenticazione moderna per impostazione predefinita. Teams supporta solo l'autenticazione moderna e non supporta l'autenticazione legacy, quindi questo problema di bypass non si applica a Teams.

Le applicazioni basate su browser di Microsoft 365, ad esempio il portale di Office, Yammer, i siti di SharePoint e Outlook sul Web, supportano attualmente le restrizioni dei tenant. I client che richiedono molte risorse (Outlook, Skype for Business, Word, Excel, PowerPoint e così via) possono applicare restrizioni del tenant solo quando si usa l'autenticazione moderna.

I client Outlook e Skype for Business che supportano l'autenticazione moderna potrebbero comunque essere in grado di usare protocolli legacy nei tenant in cui l'autenticazione moderna non è abilitata, ignorando in modo efficace le restrizioni del tenant. Le restrizioni del tenant potrebbero bloccare le applicazioni che usano protocolli legacy se contattano login.microsoftonline.com, login.microsoft.como login.windows.net durante l'autenticazione.

Per Outlook per Windows, i clienti potrebbero scegliere di implementare restrizioni che impediscono agli utenti finali di aggiungere account di posta elettronica non approvati ai propri profili. Ad esempio, vedere l'impostazione di criteri di gruppo Impedisci l'aggiunta di account exchange non predefiniti.

Incompatibilità di Azure RMS e Office Message Encryption

Le funzionalità di Azure Rights Management Service (RMS) e Office Message Encryption non sono compatibili con le restrizioni del tenant. Queste funzionalità si basano sulla firma degli utenti in altri tenant per ottenere chiavi di decrittografia per i documenti crittografati. Poiché le restrizioni del tenant bloccano l'accesso ad altri tenant, la posta crittografata e i documenti inviati agli utenti da tenant non attendibili non sono accessibili.

Test in corso

Se si desidera provare la funzionalità Restrizioni del tenant prima di implementarla in tutta l'organizzazione, sono disponibili due opzioni: un approccio basato su host con uno strumento come Fiddler o una pianificazione per fasi delle impostazioni del proxy.

Fiddler per un approccio basato su host

Fiddler è un proxy di debug Web gratuito che può essere usato per acquisire e modificare il traffico HTTP/HTTPS, include l'inserimento di intestazioni HTTP. Per configurare il test di Restrizioni del tenant con Fiddler, eseguire la procedura seguente:

  1. Scaricare e installare Fiddler.

  2. Configurare Fiddler per decrittografare il traffico HTTPS, in base alla documentazione della Guida di Fiddler.

  3. Configurare Fiddler per inserire le intestazioni Restrict-Access-To-Tenants e Restrict-Access-Context con regole personalizzate:

    1. Nello strumento Fiddler Web Debugger selezionare il menu Regole e selezionare Personalizza regole per aprire il file CustomRules.

    2. Aggiungere le righe seguenti all'interno della OnBeforeRequest funzione . Sostituire List of tenant identifiers> with a domain registered with your tenant (Ad <esempio, contoso.onmicrosoft.com). Sostituire <l'ID> directory con l'identificatore GUID microsoft Entra del tenant. È necessario includere l'identificatore GUID corretto affinché i log vengano visualizzati nel tenant.

     // Allows access to the listed tenants.
       if (
           oSession.HostnameIs("login.microsoftonline.com") ||
           oSession.HostnameIs("login.microsoft.com") ||
           oSession.HostnameIs("login.windows.net")
       )
       {
           oSession.oRequest["Restrict-Access-To-Tenants"] = "<List of tenant identifiers>";
           oSession.oRequest["Restrict-Access-Context"] = "<Your directory ID>";
       }
    
     // Blocks access to consumer apps
       if (
           oSession.HostnameIs("login.live.com")
       )
       {
           oSession.oRequest["sec-Restrict-Tenant-Access-Policy"] = "restrict-msa";
       }
    

    Se è necessario consentire più tenant, separare i vari nomi di tenant con le virgole. Ad esempio:

    oSession.oRequest["Restrict-Access-To-Tenants"] = "contoso.onmicrosoft.com,fabrikam.onmicrosoft.com";

  4. Salvare e chiudere il file CustomRules.

Dopo aver configurato Fiddler, è possibile acquisire il traffico accedendo al menu File e selezionando Capture Traffic (Acquisisci traffico).

Implementazione per fasi delle impostazioni del proxy

A seconda delle funzionalità dell'infrastruttura proxy, potrebbe essere possibile preparare l'implementazione delle impostazioni agli utenti. Per considerazioni, vedere le opzioni generali seguenti:

  1. Usare file PAC per indirizzare gli utenti di test a un'infrastruttura di proxy di test, mentre gli utenti normali continuano a utilizzare l'infrastruttura del proxy di produzione.
  2. Alcuni server proxy potrebbero supportare configurazioni diverse usando i gruppi.

Per informazioni dettagliate, consultare la documentazione del proprio server proxy.

Blocco delle applicazioni consumer

Le applicazioni di Microsoft che supportano account consumer e account aziendali, ad esempio OneDrive, possono talvolta essere ospitate nello stesso URL. Ciò significa che gli utenti che devono accedere a tale URL a scopo lavorativo hanno accesso anche a esso per uso personale. Questa opzione potrebbe non essere consentita in base alle linee guida operative.

Alcune organizzazioni tentano di risolvere questo problema bloccando login.live.com per impedire l'autenticazione degli account personali. Questa correzione presenta diversi svantaggi:

  1. Il blocco login.live.com blocca l'uso di account personali in scenari guest B2B, che possono intrudere i visitatori e la collaborazione.
  2. Autopilot richiede l'uso di login.live.com per la distribuzione. Gli scenari di Intune e Autopilot possono avere esito negativo quando login.live.com viene bloccato.
  3. I dati di telemetria dell'organizzazione e gli aggiornamenti di Windows che si basano sul servizio login.live.com per gli ID dispositivo cessano di funzionare.

Configurazione per le app consumer

Sebbene l'intestazione Restrict-Access-To-Tenants funzioni come elenco di elementi consentiti, il blocco account Microsoft (MSA) funziona come segnale di negazione, indicando alla piattaforma account Microsoft di non consentire agli utenti di accedere alle applicazioni consumer. Per inviare questo segnale, l'intestazione sec-Restrict-Tenant-Access-Policy viene inserita nel traffico che visita login.live.com usando lo stesso proxy aziendale o il firewall, come indicato nella sezione relativa alla configurazione e ai requisiti del proxy di questo articolo. Il valore dell'intestazione deve essere restrict-msa. Quando l'intestazione è presente e un'app consumer tenta di accedere direttamente a un utente, l'accesso viene bloccato.

Al momento, l'autenticazione alle applicazioni consumer non viene visualizzata nei log di amministrazione, perché login.live.com è ospitata separatamente dall'ID Microsoft Entra.

Cosa fa l'intestazione e non blocca

I restrict-msa criteri bloccano l'uso delle applicazioni consumer, ma consentono diversi altri tipi di traffico e autenticazione:

  1. Traffico senza utente per i dispositivi. Questa opzione include il traffico per Autopilot, Windows Update e i dati di telemetria dell'organizzazione.
  2. Autenticazione B2B degli account consumer. Gli utenti con account Microsoft invitati a collaborare con un tenant eseguono l'autenticazione per login.live.com per accedere a un tenant di risorse.
    1. Questo accesso viene controllato usando l'intestazione per consentire o negare l'accesso Restrict-Access-To-Tenants al tenant della risorsa.
  3. Autenticazione "pass-through", usata da molte app di Azure e Office.com, in cui le app usano l'ID Microsoft Entra per consentire agli utenti consumer di accedere a un contesto consumer.
    1. Questo accesso viene controllato anche usando l'intestazione Restrict-Access-To-Tenants per consentire o negare l'accesso al tenant speciale "passthrough" (f8cdef31-a31e-4b4a-93e4-5f571e91255a). Se questo tenant non viene visualizzato nell'elenco Restrict-Access-To-Tenants dei domini consentiti, Microsoft Entra ID impedisce agli account consumer di accedere a queste app.

Piattaforme che non supportano l'interruzione TLS ed esaminano

Le restrizioni del tenant dipendono dall'inserimento di un elenco di tenant consentiti nell'intestazione HTTPS. Questa dipendenza richiede l'ispezione TLSI (Transport Layer Security Inspection) per interrompere e controllare il traffico. Per gli ambienti in cui il lato client non è in grado di interrompere e controllare il traffico per aggiungere intestazioni, le restrizioni del tenant non funzionano.

Si prenda l'esempio di Android 7.0 e versioni successive. Android ha modificato il modo in cui gestisce le autorità di certificazione attendibili (CA) per fornire impostazioni predefinite più sicure per il traffico sicuro delle app. Per altre informazioni, vedere Modifiche alle autorità di certificazione attendibili in Android Nougat.

Seguendo la raccomandazione di Google, le app client Microsoft ignorano i certificati utente per impostazione predefinita. Questo criterio rende tali app non in grado di funzionare con le restrizioni del tenant, poiché i certificati usati dal proxy di rete vengono installati nell'archivio certificati utente, che le app client non considerano attendibili.

Per tali ambienti che non possono interrompere e controllare il traffico per aggiungere i parametri delle restrizioni del tenant nell'intestazione, altre funzionalità di Microsoft Entra ID possono fornire protezione. L'elenco seguente fornisce altre informazioni su tali funzionalità di Microsoft Entra.

Tuttavia, alcuni scenari specifici possono essere coperti solo usando le restrizioni del tenant.

Passaggi successivi