Gestione degli endpoint di Microsoft 365

La maggior parte delle organizzazioni aziendali con più sedi di office e una rete WAN di connessione richiede la configurazione per la connettività di rete di Microsoft 365. È possibile ottimizzare la rete inviando tutte le richieste di rete attendibili di Microsoft 365 direttamente tramite il firewall, ignorando tutte le operazioni di ispezione o elaborazione a livello di pacchetto aggiuntive. In questo modo si riducono la latenza e i requisiti di capacità perimetrale. Identificare il traffico di rete di Microsoft 365 è il primo passaggio per offrire prestazioni ottimali per gli utenti. Per altre informazioni, vedere Principi di connettività di rete di Microsoft 365.

Microsoft consiglia di accedere agli endpoint di rete di Microsoft 365 e alle relative modifiche in corso usando l'indirizzo IP e il servizio Web URL di Microsoft 365.

Indipendentemente dalla modalità di gestione del traffico di rete di Microsoft 365, Microsoft 365 richiede la connettività Internet. Gli altri endpoint di rete in cui è richiesta la connettività sono elencati in Endpoint aggiuntivi non inclusi nel servizio Web URL e indirizzo IP di Microsoft 365.

Il modo in cui si usano gli endpoint di rete di Microsoft 365 dipende dall'architettura di rete dell'organizzazione aziendale. Questo articolo descrive diversi modi in cui le architetture di rete aziendali possono integrarsi con gli URL e gli indirizzi IP di Microsoft 365. Il modo più semplice per scegliere quali richieste di rete considerare attendibili consiste nell'usare dispositivi SD-WAN che supportano la configurazione automatizzata di Microsoft 365 in ogni sede dell'ufficio.

SD-WAN per l'uscita del ramo locale del traffico di rete microsoft 365 vitale

In ogni sede della succursale è possibile fornire un dispositivo SD-WAN configurato per instradare il traffico per la categoria di endpoint di Microsoft 365 Optimize o le categorie Optimize e Allow direttamente alla rete Microsoft. Altro traffico di rete, tra cui il traffico del data center locale, il traffico generale dei siti Web Internet e il traffico verso gli endpoint di categoria predefiniti di Microsoft 365, viene inviato a un'altra posizione in cui si dispone di un perimetro di rete più consistente.

Microsoft sta lavorando con i provider SD-WAN per abilitare la configurazione automatizzata. Per altre informazioni, vedere Programma Microsoft 365 Networking Partner.

Usare un file PAC per il routing diretto del traffico Microsoft 365 vitale

Usare i file PAC o WPAD per gestire le richieste di rete associate a Microsoft 365 ma che non hanno un indirizzo IP. In genere, le richieste di rete che vengono inviate tramite un dispositivo proxy o perimetrale comportano un aumento della latenza. Mentre TLS Break and Inspect crea la latenza più elevata, altri servizi come l'autenticazione proxy e la ricerca della reputazione possono causare prestazioni scarse e un'esperienza utente errata. Questi dispositivi di rete perimetrale necessitano anche di una capacità sufficiente per elaborare tutte le richieste di connessione di rete. È consigliabile ignorare i dispositivi proxy o di ispezione per le richieste di rete dirette di Microsoft 365.

PowerShell Gallery Get-PacFile è uno script di PowerShell che legge gli endpoint di rete più recenti dal servizio Web URL e indirizzo IP di Microsoft 365 e crea un file PAC di esempio. Lo script può essere modificato in modo da integrarlo con la gestione dei file PAC esistente.

Figura 1 - Perimetro di rete aziendale semplice

Il file PAC viene distribuito nel browser al punto 1 della figura 1. Quando si usa un file PAC per l'uscita diretta del traffico di rete vitale di Microsoft 365, è anche necessario consentire la connettività agli indirizzi IP dietro questi URL nel firewall perimetrale di rete. Questa operazione viene eseguita recuperando gli indirizzi IP per le stesse categorie di endpoint di Microsoft 365 specificate nel file PAC e creando elenchi di controllo di accesso del firewall in base a tali indirizzi. Il firewall è il punto 3 della figura 1.

Separatamente, se si sceglie di eseguire solo il routing diretto per gli endpoint della categoria Optimize, tutti gli endpoint di categoria Consenti inviati al server proxy devono essere elencati nel server proxy per ignorare l'ulteriore elaborazione. Ad esempio, l'interruzione TLS e inspect e l'autenticazione proxy non sono compatibili con gli endpoint di categoria Optimize e Allow. Il server proxy è il punto 2 della figura 1.

La configurazione comune consiste nel consentire senza elaborare tutto il traffico in uscita dal server proxy per gli indirizzi IP di destinazione per il traffico di rete di Microsoft 365 che raggiunge il server proxy. Per informazioni sui problemi relativi all'interruzione e all'ispezione di TLS, vedere Uso di dispositivi di rete o soluzioni di terze parti sul traffico di Microsoft 365.

Esistono due tipi di file PAC generati dallo script Get-PacFile.

Ecco un semplice esempio dell'esecuzione dello script PowerShell:

Get-PacFile -ClientRequestId b10c5ed1-bad1-445f-b386-b919946339a7

Esistono molti parametri che è possibile passare allo script:

Ecco un altro esempio di chiamata dello script di PowerShell con altri parametri:

Get-PacFile -Type 2 -Instance Worldwide -TenantName Contoso -ClientRequestId b10c5ed1-bad1-445f-b386-b919946339a7

L'elaborazione del server proxy ignora il traffico di rete di Microsoft 365

Se i file PAC non vengono usati per il traffico in uscita diretto, si vuole comunque ignorare l'elaborazione nel perimetro di rete configurando il server proxy. Alcuni fornitori di server proxy hanno abilitato la configurazione automatica di questa configurazione, come descritto nel programma Microsoft 365 Networking Partner Program.

Se si esegue questa operazione manualmente, è necessario ottenere i dati della categoria Di ottimizzazione e Consenti endpoint dall'indirizzo IP e dal servizio Web URL di Microsoft 365 e configurare il server proxy per ignorare l'elaborazione. È importante evitare l'interruzione di TLS e controllare e l'autenticazione proxy per gli endpoint di categoria Ottimizza e Consenti.

Gestione delle modifiche per gli URL e gli indirizzi IP di Microsoft 365

Oltre a selezionare la configurazione appropriata per il perimetro di rete, è fondamentale adottare un processo di gestione delle modifiche per gli endpoint di Microsoft 365. Questi endpoint cambiano regolarmente. Se non si gestiscono le modifiche, è possibile che gli utenti vengano bloccati o con prestazioni scarse dopo l'aggiunta di un nuovo indirizzo IP o URL.

Le modifiche apportate agli INDIRIZZI IP e agli URL di Microsoft 365 vengono in genere pubblicate quasi all'ultimo giorno di ogni mese. A volte una modifica viene pubblicata al di fuori di tale pianificazione a causa di requisiti operativi, di supporto o di sicurezza.

Quando viene pubblicata una modifica che richiede di agire perché è stato aggiunto un indirizzo IP o un URL, si dovrebbe prevedere di ricevere un preavviso di 30 giorni dal momento in cui la modifica viene pubblicata fino a quando non è disponibile un servizio Microsoft 365 in tale endpoint. Questa operazione viene riflessa come data di validità. Sebbene l'obiettivo sia questo periodo di notifica, potrebbe non essere sempre possibile a causa di requisiti operativi, di supporto o di sicurezza. Le modifiche che non richiedono un'azione immediata per mantenere la connettività, ad esempio indirizzi IP o URL rimossi o modifiche meno significative, non includono la notifica anticipata. In questi casi non viene specificata alcuna data di validità. Indipendentemente dalla notifica inviata, noi indichiamo la data prevista per l'attivazione del servizio per ogni modifica.

Modifica la notifica usando il servizio web

È possibile usare l'indirizzo IP e il servizio Web URL di Microsoft 365 per ottenere la notifica delle modifiche. È consigliabile chiamare il metodo Web /version una volta all'ora per controllare la versione degli endpoint in uso per connettersi a Microsoft 365. Se la versione cambia rispetto alla versione in uso, bisogna ottenere i dati più recenti sugli endpoint dal metodo web /endpoints e ottenere facoltativamente le differenze dal metodo web /changes. Non è necessario chiamare i metodi Web /endpoints o /changes se non sono state apportate modifiche alla versione trovata.

Per altre informazioni, vedere Indirizzo IP e servizio Web URL di Microsoft 365.

Notifica delle modifiche tramite feed RSS

L'indirizzo IP e il servizio Web URL di Microsoft 365 forniscono un feed RSS che è possibile sottoscrivere in Outlook. Sono disponibili collegamenti agli URL RSS in ognuna delle pagine specifiche dell'istanza del servizio Microsoft 365 per gli URL e gli indirizzi IP. Per altre informazioni, vedere Indirizzo IP e servizio Web URL di Microsoft 365.

Modificare la notifica e la revisione dell'approvazione usando Power Automate

Comprendiamo che l'elaborazione manuale delle modifiche mensili degli endpoint di rete potrebbe comunque essere necessaria. È possibile usare Power Automate per creare un flusso che notifica tramite posta elettronica ed eventualmente esegue un processo di approvazione per le modifiche quando gli endpoint di rete di Microsoft 365 presentano modifiche. Al termine della revisione, il flusso può inviare tramite posta elettronica le modifiche al proprio team di gestione di firewall e server proxy.

Per informazioni su un esempio e un modello di Power Automate, vedere Usare Power Automate per ricevere un messaggio di posta elettronica per le modifiche apportate agli URL e agli indirizzi IP di Microsoft 365.

Domande frequenti sugli endpoint di rete di Microsoft 365

Vedere queste domande frequenti sulla connettività di rete di Microsoft 365.

Come si invia una domanda?

Selezionare il collegamento nella parte inferiore per indicare se l'articolo è stato utile o meno e inviare altre domande. I feedback vengono monitorati e le domande vengono aggiornate in base a quelle poste con più frequenza.

Come si determina la posizione del tenant?

Il miglior modo di determinare la posizione del tenant è usare la nostra mappa dei data center.

Il peering con Microsoft è eseguito in modo adeguato?

Le posizioni di peering sono descritte in modo più dettagliato nella pagina dedicata al peering con Microsoft.

Con oltre 2500 relazioni di peering ISP a livello globale e 70 punti di presenza, il passaggio dalla rete dell'utente alla nostra dovrebbe essere immediato. Può essere utile dedicare qualche minuto ad assicurarsi che la relazione di peering dell'ISP sia ottimale. Ecco alcuni esempi di passaggi di peering di buono e scarso livello verso la rete dell'utente.

Sono presenti richieste di rete per indirizzi IP non inclusi nell'elenco pubblicato, occorre consentire loro l'accesso?

Vengono forniti solo gli indirizzi IP per i server Microsoft 365 a cui è necessario eseguire il routing diretto. Non si tratta di un elenco completo degli indirizzi IP per cui si vedranno richieste di rete. Verranno visualizzate le richieste di rete a Microsoft e a indirizzi IP di proprietà di terze parti, non pubblicati. Questi indirizzi IP vengono generati dinamicamente o gestiti in modo da impedire avvisi tempestivi in caso di modifica. Se il firewall non consente l'accesso in base ai nomi di dominio completi per le richieste di rete, usare un file PAC o WPAD per gestire le richieste.

Visualizzare un indirizzo IP associato a Microsoft 365 su cui si vogliono ottenere altre informazioni?

1. Verificare se l'indirizzo IP è incluso in un intervallo pubblicato più ampio usando un calcolatore CIDR, come questi per IPv4 o IPv6. Ad esempio, 40.96.0.0/13 include l'indirizzo IP 40.103.0.1 nonostante 40.96 non corrisponda a 40.103.
2. Scoprire se l'indirizzo IP appartiene a un partner eseguendo una query whois. Se è di proprietà di Microsoft, potrebbe essere un partner interno. Molti endpoint di rete partner sono elencati come appartenenti alla categoria predefinita , per cui gli indirizzi IP non vengono pubblicati.
3. L'indirizzo IP potrebbe non far parte di Microsoft 365 o di una dipendenza. La pubblicazione di endpoint di rete Microsoft 365 non include tutti gli endpoint di rete Microsoft.
4. Controllare il certificato. Con un browser, connettersi all'indirizzo IP usando HTTPS://< IP_ADDRESS> e controllare i domini elencati nel certificato per comprendere quali domini sono associati all'indirizzo IP. Se si tratta di un indirizzo IP di proprietà di Microsoft e non nell'elenco degli indirizzi IP di Microsoft 365, è probabile che l'indirizzo IP sia associato a una rete CDN Microsoft, ad esempio MSOCDN.NET o a un altro dominio Microsoft senza informazioni IP pubblicate. Se il dominio specificato nel certificato è uno di quelli di cui dovrebbe essere elencato l'indirizzo IP, informare Microsoft.

Alcuni URL di Microsoft 365 puntano ai record CNAME anziché ai record A nel DNS. Cosa bisogna fare con i record CNAME?

I computer client necessitano di un record DNS A o AAAA che includa uno o più indirizzi IP per connettersi a un servizio cloud. Alcuni URL inclusi in Microsoft 365 mostrano record CNAME anziché record A o AAAA. Questi record CNAME sono intermedi e potrebbero essere diversi in una catena. Verranno sempre risolti in un record A o AAAA per un indirizzo IP. Si consideri, ad esempio, la serie seguente di record DNS, che in definitiva si risolvono nell'indirizzo IP IP_1:

serviceA.office.com -> CNAME: serviceA.domainA.com -> CNAME: serviceA.domainB.com -> A: IP_1

Questi reindirizzamenti CNAME sono un aspetto normale del DNS, e sono trasparenti per il computer client e per i server proxy. Vengono usati per il bilanciamento del carico, le reti di distribuzione del contenuto, la disponibilità elevata e la mitigazione degli eventi imprevisti del servizio. Microsoft non pubblica i record CNAME intermedi, sono soggetti a modifiche in qualsiasi momento e non è necessario configurarli come consentito nel server proxy.

Un server proxy convalida l'URL iniziale, che nell'esempio precedente è serviceA.office.com e questo URL verrà incluso nella pubblicazione di Microsoft 365. Il server proxy richiede la risoluzione DNS di tale URL a un indirizzo IP e riceve nuovamente IP_1. Non convalida i record di reindirizzamento CNAME intermedi.

Le configurazioni hardcoded o l'uso di un elenco di indirizzi consentiti basato su FQDN di Microsoft 365 indiretti non sono consigliati e non supportati da Microsoft. Sono noti per causare problemi di connettività dei clienti. Le soluzioni DNS bloccate nel reindirizzamento CNAME o che altrimenti risolvono erroneamente le voci DNS di Microsoft 365 possono essere risolte tramite server d'inoltro DNS con ricorsione DNS abilitata o tramite hint radice DNS. Molti prodotti perimetrali di rete di terze parti integrano in modo nativo l'endpoint Microsoft 365 consigliato per includere un elenco di utenti consentiti nella configurazione usando l'indirizzo IP di Microsoft 365 e il servizio Web URL.

Perché tra i nomi di dominio Microsoft sono presenti nomi come nsatc.net o akadns.net?

Microsoft 365 e altri servizi Microsoft usano diversi servizi di terze parti, ad esempio Akamai e MarkMonitor, per migliorare l'esperienza di Microsoft 365. Per continuare a offrire la migliore esperienza possibile, questi servizi potrebbero essere modificati in futuro. I domini di terze parti possono ospitare contenuto, ad esempio una rete CDN, o ospitare un servizio, ad esempio un servizio di gestione del traffico geografico. Alcuni dei servizi attualmente in uso includono:

MarkMonitor è in uso quando vengono visualizzate richieste che includono *.nsatc.net. Questo servizio fornisce protezione dei nomi di dominio e monitoraggio per proteggere da comportamenti dannosi.

ExactTarget è in uso quando vengono visualizzate le richieste a *.exacttarget.com. Questo servizio fornisce gestione dei collegamenti di posta elettronica e monitoraggio per proteggere da comportamenti dannosi.

Akamai è in uso quando sono presenti richieste che includono uno degli FQDN seguenti. Questo servizio offre servizi di rete di CDN e instradamento geografico del DNS.

*.akadns.net
*.akam.net
*.akamai.com
*.akamai.net
*.akamaiedge.net
*.akamaihd.net
*.akamaized.net
*.edgekey.net
*.edgesuite.net

È necessario avere la connettività minima possibile per Microsoft 365

Poiché Microsoft 365 è una suite di servizi creati per funzionare su Internet, le promesse di affidabilità e disponibilità si basano su molti servizi Internet standard disponibili. Ad esempio, i servizi Internet standard come DNS, CRL e RETI CDN devono essere raggiungibili per usare Microsoft 365, così come devono essere raggiungibili per usare la maggior parte dei servizi Internet moderni.

La famiglia di prodotti Microsoft 365 è suddivisa in quattro aree di servizio principali che rappresentano i tre carichi di lavoro principali e un set di risorse comuni. Queste aree di servizio possono essere usate per associare i flussi di traffico a una particolare applicazione, tuttavia, dato che le funzionalità utilizzano spesso endpoint in più carichi di lavoro, queste aree di servizio non possono essere usate in modo efficace per limitare l'accesso.

Oltre ai servizi internet di base, esistono servizi di terza parte usati solo per integrare determinate funzionalità. Anche se questi servizi sono necessari per l'integrazione, sono contrassegnati come facoltativi nell'articolo Endpoint di Microsoft 365. Ciò significa che la funzionalità di base del servizio continua a funzionare se l'endpoint non è accessibile. Qualsiasi endpoint di rete necessario ha l'attributo obbligatorio impostato su true. Qualsiasi endpoint di rete facoltativo ha l'attributo obbligatorio impostato su false e l'attributo notes descrive in dettaglio la funzionalità mancante prevista se la connettività è bloccata.

Se si sta tentando di usare Microsoft 365 e si stanno individuando servizi di terze parti non accessibili, si vuole assicurarsi che tutti gli FQDN contrassegnati come obbligatori o facoltativi in questo articolo siano consentiti tramite il proxy e il firewall.

Come si blocca l'accesso ai servizi consumer Microsoft?

La funzionalità di restrizioni del tenant supporta ora 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. Per altre informazioni, vedere Usare le restrizioni del tenant per gestire l'accesso alle applicazioni cloud SaaS.

Il firewall richiede indirizzi IP e non può elaborare gli URL. Come si configura per Microsoft 365?

Microsoft 365 non fornisce gli indirizzi IP di tutti gli endpoint di rete necessari. Alcuni sono disponibili solo come URL e sono catalogati come predefiniti. Gli URL nella categoria predefinita necessari devono essere consentiti tramite un server proxy. Se non si dispone di un server proxy, esaminare come sono state configurate le richieste Web per gli URL digitati dagli utenti nella barra degli indirizzi di un Web browser; l'utente non fornisce neanche un indirizzo IP. Gli URL di categoria predefiniti di Microsoft 365 che non forniscono indirizzi IP devono essere configurati nello stesso modo.

Articoli correlati

Servizio Web URL e indirizzo IP di Microsoft 365

Intervalli IP del data center di Microsoft Azure

Spazio IP pubblico di Microsoft

Requisiti dell'infrastruttura di rete per Microsoft Intune

URL e intervalli di indirizzi IP per Microsoft 365

Principi della connettività di rete di Microsoft 365