Limitare l'accesso a un tenant

Le organizzazioni di grandi dimensioni che dedicano particolare attenzione alla 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 funziona in un mondo in cui le app SaaS (Software as a Service) 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 offerta da Microsoft Entra per risolvere questo problema è costituita da una funzionalità denominata Restrizioni del tenant. Con questa funzionalità, le organizzazioni possono controllare l'accesso alle applicazioni cloud SaaS in base al tenant di Microsoft Entra usato dalle applicazioni per l'accesso Single Sign-On. Si supponga, ad esempio, di voler consentire l'accesso alle applicazioni Microsoft 365 della propria organizzazione, impedendolo al contempo alle istanze di quelle stesse applicazioni in altre organizzazioni.

Con Restrizioni del tenant, le organizzazioni possono specificare l'elenco dei tenant a cui possono accedere i loro utenti sulla rete. Microsoft Entra ID concede quindi solo l'accesso a questi tenant autorizzati: tutti gli altri tenant vengono bloccati, anche quelli a cui gli utenti potrebbero accedere come guest.

Questo articolo è incentrato su Restrizioni del tenant per Microsoft 365, ma la funzionalità protegge tutte le app che inviano l'utente a Microsoft Entra ID per l'accesso Single Sign-On. Se si usano app SaaS con un tenant di Microsoft Entra diverso da quello usato da Microsoft 365, assicurarsi che tutti i tenant richiesti siano autorizzati. 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 bloccaggio 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, illustrata in dettaglio alla fine di questo articolo.

Funzionamento

La soluzione globale è composta dai seguenti elementi:

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

2. Infrastruttura di 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 a Microsoft Entra ID.

3. Software client: per supportare Restrizioni del tenant, il software client deve richiedere i token direttamente da Microsoft Entra ID, 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: per usare Restrizioni del tenant e bloccare l'accesso a tutti i tenant non autorizzati, i servizi cloud devono usare un'autenticazione moderna. È necessario configurare i servizi cloud di Microsoft 365 in modo da usare i protocolli di autenticazione moderna per impostazione predefinita. Per informazioni più recenti sul supporto di Microsoft 365 per l'autenticazione moderna, leggere il documento aggiornato sull'autenticazione moderna di Office 365.

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

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 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. Questa guida è generica, pertanto è consigliabile consultare la documentazione del fornitore del proxy per i 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.

• Per l'uso di Restrizioni del tenant sono necessarie le licenze Microsoft Entra ID P1 o P2.

Impostazione

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

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. È possibile usare qualsiasi dominio registrato con un tenant per individuare il tenant nell'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,aaaabbbb-0000-cccc-1111-dddd2222eeee

• 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: bbbbcccc-1111-dddd-2222-eeee3333ffff. Per ottenere i log per queste autenticazioni, qui è necessario usare il proprio ID directory. Se si usa un ID 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 Esperienza di amministrazione.

Per trovare il proprio ID directory:

1. Accedere all'interfaccia di amministrazione di Microsoft Entra con almeno il ruolo di Lettore globale.
2. Passare a Identità>Panoramica>Panoramica.
3. Copiare il valore del campo 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 di <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 le proprie intestazioni HTTP con tenant non approvati, il proxy deve sostituire l'intestazione Restrict-Access-To-Tenants se questa è 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.com e 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 consentito per l'istanza di Contoso, viene visualizzato un messaggio di negazione dell'accesso. Il messaggio indica che si sta tentando di accedere a una risorsa appartenente a un'organizzazione non approvata dal reparto IT.

Esperienza di amministrazione

La configurazione di Restrizioni del tenant viene eseguita nell'infrastruttura del proxy aziendale, ma gli amministratori possono accedere direttamente ai relativi report nell'interfaccia di amministrazione di Microsoft Entra. Per visualizzare i report:

1. Accedere all'interfaccia di amministrazione di Microsoft Entra con almeno il ruolo di Lettore globale.
2. Passare a Identità>Panoramica>Restrizioni del tenant.

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 potrebbe contenere informazioni limitate, ad esempio l'ID della directory di destinazione, quando un utente di un tenant diverso da Restricted-Access-Context esegue l'accesso. In questo caso, le informazioni identificabili dall'utente, ad esempio nome e nome dell'entità utente, vengono mascherate per proteggere i dati dell'utente in altri tenant (ad esempio, "{PII Removed}@domain.com" or 00000000-0000-0000-0000-000000000000 al posto di nomi utente e ID oggetto, a seconda dei casi).

Come per gli 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: in questo campo possono essere rimossi i dati personali e il valore può essere impostato su 00000000-0000-0000-0000-000000000000.
• Applicazione
• Stato
• Data
• Data (UTC): UTC corrisponde a Coordinated Universal Time
• Indirizzo IP
• Client
• Nome utente: in questo campo possono essere rimossi i dati personali e il valore può essere 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 sui client Office che supportano attualmente l'autenticazione moderna, vedere il documento aggiornato sull'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 questa soluzione alternativa non si applica a Teams.

La funzionalità Restrizioni del tenant è attualmente supportata nelle applicazioni Microsoft 365 basate su browser come il portale di Office, Yammer, i siti SharePoint e Outlook sul Web. 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. Queste ultime potrebbero bloccare le applicazioni che usano protocolli legacy se contattano login.microsoftonline.com, login.microsoft.com o login.windows.net durante l'autenticazione.

In Outlook per Windows, i clienti potrebbero scegliere di implementare delle restrizioni per impedire 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 di Exchange non predefiniti.

Incompatibilità di Azure RMS e Office Message Encryption

Le funzionalità Azure Rights Management Service (Azure RMS) e Office Message Encryption non sono compatibili con Restrizioni del tenant. Queste funzionalità si basano sull'accesso degli utenti ad altri tenant per ottenere chiavi di decrittografia per i documenti crittografati. Poiché Restrizioni del tenant blocca 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, utilizzabile per acquisire e modificare il traffico HTTP/HTTPS, che 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, come indicato nella relativa documentazione di aiuto.

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 Rules (Regole) e selezionare Customize Rules (Personalizza regole) per aprire il file CustomRules.

   2. Aggiungere le righe seguenti all'interno della funzione OnBeforeRequest. Sostituire <List of tenant identifiers> con un dominio registrato con il tenant, ad esempio contoso.onmicrosoft.com. Sostituire <directory ID> con l'identificatore GUID di Microsoft Entra del proprio tenant. È necessario includere l'identificatore GUID corretto per consentire la visualizzazione dei log 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 di proxy, potrebbe essere possibile eseguire un'implementazione per fasi delle impostazioni agli utenti. Di seguito sono indicate due opzioni generali da tenere in considerazione:

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.

Bloccaggio delle applicazioni consumer

Le applicazioni Microsoft che supportano account consumer e account aziendali, come OneDrive, possono talvolta essere ospitate nello stesso URL. Ciò significa che gli utenti che devono accedere a un URL per scopi di lavoro hanno accesso a tale URL anche per uso personale. Questa opzione potrebbe non essere consentita dalle linee guida operative.

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

1. Il bloccaggio di login.live.com ha l'effetto di bloccare l'uso di account personali in scenari guest B2B, il che può interferire con l'accesso dei visitatori e con la collaborazione.
2. Per la distribuzione di Autopilot è necessario l'uso di login.live.com. Gli scenari di Intune e Autopilot possono non riuscire quando login.live.com è 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 non sono più utilizzabili.

Configurazione per le app consumer

Anche se l'intestazione Restrict-Access-To-Tenants funziona come elenco elementi consentiti, il blocco di account Microsoft (MSA) funziona come segnale di negazione, indicando alla piattaforma per 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 o firewall aziendale menzionato nella sezione Configurazione e requisiti del proxy di questo articolo. Il valore dell'intestazione deve essere restrict-msa. Quando l'intestazione è presente e un'app consumer tenta di autorizzare direttamente l'accesso di un utente, il tentativo di accesso viene bloccato.

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

Elementi bloccati e non bloccati dall'intestazione

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

1. Traffico senza utenti 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 a login.live.com per accedere a un tenant di risorse.
   1. Questo accesso viene controllato tramite l'intestazione Restrict-Access-To-Tenants per consentire o negare l'accesso a tale tenant di risorse.
3. Autenticazione "pass-through", usata da molte app di Azure e Office.com, in cui le app usano Microsoft Entra ID per consentire agli utenti consumer di accedere a un contesto consumer.
   1. Questo accesso viene controllato anche tramite l'intestazione Restrict-Access-To-Tenants per consentire o negare l'accesso allo speciale tenant "pass-through" (f8cdef31-a31e-4b4a-93e4-5f571e91255a). Se questo tenant non risulta incluso nell'elenco Restrict-Access-To-Tenants di domini consentiti, Microsoft Entra ID impedisce agli account consumer di accedere a queste app.

Piattaforme che non supportano l'interruzione e l'ispezione di TLS

La funzionalità Restrizioni del tenant dipende dall'inserimento di un elenco di tenant consentiti nell'intestazione HTTPS. Questa dipendenza richiede l'interruzione e l'ispezione del traffico con TLSI (Transport Layer Security Inspection). Per gli ambienti in cui il lato client non è in grado di interrompere e ispezionare il traffico per aggiungere intestazioni, Restrizioni del tenant non funziona.

Si prenda ad esempio Android 7.0 e versioni successive. In Android è stata modificata la modalità di gestione delle autorità di certificazione attendibili (CA) in modo da fornire impostazioni predefinite più sicure per il traffico sicuro delle app. Per altre informazioni, vedere l'articolo sulle modifiche alle autorità di certificazione attendibili in Android Nougat.

In conformità con la raccomandazione di Google, le app client Microsoft ignorano i certificati utente per impostazione predefinita. Questi criteri non consentono a tali app di funzionare con Restrizioni del tenant, poiché i certificati usati dal proxy di rete vengono installati nell'archivio dei certificati utente, che le app client non considerano attendibili.

Per tali ambienti che non sono in grado di interrompere e ispezionare il traffico per aggiungere i parametri di Restrizioni del tenant nell'intestazione, altre funzionalità di Microsoft Entra ID possono fornire protezione. Nell'elenco seguente sono riportate altre informazioni sulle funzionalità di Microsoft Entra.

• Accesso condizionale: consentire solo l'uso di dispositivi gestiti/conformi
• Accesso condizionale: gestire l'accesso per utenti guest/esterni
• Collaborazione B2B: limitare le regole in uscita in base all'accesso tra tenant per gli stessi tenant elencati nel parametro "Restrict-Access-To-Tenants"
• Collaborazione B2B: limitare gli inviti agli utenti B2B per gli stessi domini elencati nel parametro "Restrict-Access-To-Tenants"
• Gestione applicazioni: limitare il consenso utente per le applicazioni
• Intune: applicare criteri di protezione delle app tramite Intune per limitare l'utilizzo delle app gestite all'UPN dell'account che ha registrato il dispositivo: controllare la sezione Consentire solo gli account dell'organizzazione configurati nelle app.

Tuttavia, alcuni scenari specifici possono essere gestiti solo tramite Restrizioni del tenant.

Passaggi successivi

• Informazioni sull'autenticazione moderna aggiornata di Office 365
• Vedere URL e intervalli di indirizzi IP per Office 365