Networking (per il cloud): il punto di vista di un progettista

Articolo
07/16/2023

In questo articolo, Ed Fisher, Security & Compliance Architect di Microsoft, descrive come ottimizzare la rete per la connettività cloud evitando le insidie più comuni.

Informazioni sull'autore

Screenshot della foto di Ed Fisher.

Attualmente sono uno specialista tecnico principale del nostro team retail e consumer goods, con particolare attenzione alla sicurezza & conformità. Ho lavorato con clienti che si spostano a Office 365 negli ultimi dieci anni. Ho lavorato con negozi più piccoli con una manciata di sedi ad agenzie governative e aziende con milioni di utenti distribuiti in tutto il mondo, e molti altri clienti in mezzo, con la maggior parte di decine di migliaia di utenti, più località in varie parti del mondo, la necessità di un livello più elevato di sicurezza e una moltitudine di requisiti di conformità. Ho aiutato centinaia di aziende e milioni di utenti a passare al cloud in modo sicuro e sicuro.

Con un background negli ultimi 25 anni che include sicurezza, infrastruttura e ingegneria di rete, e dopo aver spostato due dei miei precedenti datori di lavoro a Office 365 prima di entrare in Microsoft, sono stato sul tuo lato del tavolo un sacco di volte, e ricordare com'è. Anche se nessun cliente è mai lo stesso, la maggior parte ha esigenze simili e quando si usa un servizio standardizzato come qualsiasi piattaforma SaaS o PaaS, gli approcci migliori tendono ad essere gli stessi.

Non è la rete, è il modo in cui lo usi (male)!

Indipendentemente dal numero di volte in cui si verifica, non manca mai di stupirmi del modo in cui i team di sicurezza e i team di rete creativi cercano di ottenere il modo in cui pensano di connettersi ai servizi cloud Microsoft. Esistono sempre alcuni criteri di sicurezza, standard di conformità o modi migliori in cui insistono sull'uso, senza essere disposti a partecipare a una conversazione su ciò che stanno cercando di realizzare o su come esistono modi migliori, più facili, più convenienti e più efficienti per farlo.

Quando questo genere di cose viene inoltrato a me, di solito sono disposto a prendere la sfida e camminare attraverso le modalità e i motivi e arrivare a dove hanno bisogno di essere. Ma se sono completamente franco, devo condividere che a volte voglio solo lasciarli fare quello che faranno, e tornare a dirti che te l'ho detto quando finalmente ammettono che non funziona. Potrei voler farlo a volte, ma non lo faccio. Quello che faccio è cercare di spiegare tutto ciò che ho intenzione di includere in questo post. Indipendentemente dal ruolo dell'utente, se l'organizzazione vuole usare i servizi cloud Microsoft, probabilmente esiste una certa saggezza in ciò che segue che può essere utile.

Principi

Iniziamo con alcune regole di base su ciò che stiamo facendo qui. Viene illustrato come connettersi in modo sicuro ai servizi cloud per garantire la complessità minima e le prestazioni massime, mantenendo al tempo stesso la sicurezza reale. Nessuno di ciò che segue è in contrasto con tutto ciò, anche se tu o il tuo cliente non userai il tuo server proxy preferito per tutto.

Solo perché puoi, non significa che dovresti: o parafrasare il dottor Ian Malcolm del film di Jurassic Park "... Sì, sì, ma il team di sicurezza era così preoccupato di sapere se poteva o meno che non si fermava a pensare se dovesse."
Sicurezza non significa complessità: non si è più sicuri solo perché si spende più denaro, si instrada attraverso più dispositivi o si fa clic su più pulsanti.
Office 365 è accessibile tramite Internet: ma non è la stessa cosa di Office 365 è Internet. Si tratta di un servizio SaaS gestito da Microsoft e amministrato dall'utente. A differenza dei siti Web visitati su Internet, in realtà si arriva a sbirciare dietro il sipario, e può applicare i controlli necessari per soddisfare i criteri e gli standard di conformità, a condizione che si capisce che mentre è possibile raggiungere i vostri obiettivi, si può solo dover farlo in un modo diverso.
I punti di strozzatura sono pessimi, i breakout localizzati sono buoni: tutti vogliono sempre eseguire il backhaul tutto il traffico Internet per tutti i loro utenti fino a un punto centrale, in genere in modo che possano monitorarlo e applicare i criteri, ma spesso perché è più economico del provisioning dell'accesso a Internet in tutte le loro posizioni, o è proprio come lo fanno. Ma quei punti di soffocamento sono esattamente questo... punti in cui il traffico si soffoca. Non c'è niente di male nell'impedire agli utenti di navigare su Instagram o trasmettere video per gatti, ma non trattare il traffico delle applicazioni aziendali cruciali allo stesso modo.
Se il DNS non è soddisfatto, non è niente di felice: la rete progettata meglio può essere ostacolata da un DNS scadente, che si tratti di richieste ricorsiva a server in altre aree del mondo o usando i server DNS del provider di servizi Internet o altri server DNS pubblici che memorizzano nella cache le informazioni sulla risoluzione DNS.
Solo perché è così che lo si faceva, non significa che è così che si dovrebbe fare ora: la tecnologia cambia costantemente e Office 365 non fa eccezione. L'applicazione di misure di sicurezza sviluppate e distribuite per i servizi locali o per controllare la navigazione Web non garantisce lo stesso livello di sicurezza e può avere un impatto negativo significativo sulle prestazioni.
Office 365 è stato creato per l'accesso tramite Internet: questo è tutto in poche parole. Indipendentemente da ciò che si vuole fare tra gli utenti e il bordo, il traffico passa ancora attraverso Internet una volta che lascia la rete e prima che arrivi sul nostro. Anche se si usa Azure ExpressRoute per instradare il traffico sensibile alla latenza dalla rete direttamente alla rete, la connettività Internet è assolutamente necessaria. Accettalo. Non esagerare.

Dove spesso si fanno scelte sbagliate

Anche se ci sono molti posti in cui vengono prese decisioni sbagliate in nome della sicurezza, questi sono quelli che incontro più spesso con i clienti. Molte conversazioni con i clienti coinvolgono tutti questi elementi contemporaneamente.

Risorse insufficienti nell'area perimetrale

Pochissimi clienti stanno distribuendo ambienti greenfield e hanno anni di esperienza con il funzionamento degli utenti e l'uscita internet. Che i clienti dispongano di server proxy o consentano l'accesso diretto e semplicemente il traffico in uscita NAT, lo fanno da anni e non considerano quanto di più inizieranno a pompare attraverso il proprio edge mentre spostano le applicazioni tradizionalmente interne nel cloud.

La larghezza di banda è sempre un problema, ma i dispositivi NAT potrebbero non avere abbastanza potenza per gestire l'aumento del carico e potrebbero iniziare a chiudere prematuramente le connessioni per liberare risorse. La maggior parte del software client che si connette a Office 365 prevede connessioni persistenti e un utente che utilizza completamente Office 365 può avere 32 o più connessioni simultanee. Se il dispositivo NAT li rilascia prematuramente, tali app potrebbero non rispondere quando tentano di usare le connessioni che non sono più presenti. Quando si arrendono e cercano di stabilire nuove connessioni, mettono ancora più carico sull'ingranaggio di rete.

Breakout localizzato

Tutto il resto in questo elenco si riduce a una cosa: scendere dalla rete e accedere al nostro il più rapidamente possibile. Il backhauling del traffico degli utenti verso un punto di uscita centrale, soprattutto quando tale punto di uscita si trova in un'altra area rispetto a quella in cui si trovano gli utenti, introduce una latenza non necessaria e influisce sia sull'esperienza client che sulla velocità di download. Microsoft ha punti di presenza in tutto il mondo con front-end per tutti i nostri servizi e peering stabiliti praticamente con ogni isp principale, quindi il routing del traffico degli utenti in locale garantisce che entri rapidamente nella nostra rete con latenza minima.

Il traffico di risoluzione DNS deve seguire il percorso di uscita Internet

Naturalmente, per consentire a un client di trovare qualsiasi endpoint, deve usare DNS. I server DNS microsoft valutano l'origine delle richieste DNS per assicurarsi di restituire la risposta che, in termini Internet, è più vicina all'origine della richiesta. Assicurarsi che il DNS sia configurato in modo che le richieste di risoluzione dei nomi esercino lo stesso percorso del traffico degli utenti, in modo da non concedere loro l'uscita locale, ma verso un endpoint in un'altra area. Ciò significa consentire ai server DNS locali di "passare alla radice" anziché inoltrarsi ai server DNS nei data center remoti. E watch per i servizi DNS pubblici e privati, che possono memorizzare nella cache i risultati di una parte del mondo e servirli alle richieste provenienti da altre parti del mondo.

Per eseguire il proxy o non per il proxy, questa è la domanda

Uno dei primi aspetti da considerare è se eseguire il proxy delle connessioni degli utenti a Office 365. Quello è facile; non eseguire il proxy. Office 365 è accessibile tramite Internet, ma non è Internet. Si tratta di un'estensione dei servizi principali e deve essere considerata come tale. Qualsiasi operazione che un proxy deve eseguire, ad esempio DLP o antimalware o ispezione del contenuto, è già disponibile nel servizio e può essere usata su larga scala e senza la necessità di violare le connessioni crittografate TLS. Tuttavia, se si vuole eseguire il proxy del traffico che non è possibile controllare in altro modo, prestare attenzione alle linee guida all'indirizzo e alle https://aka.ms/pnc categorie di traffico in https://aka.ms/ipaddrs. Sono disponibili tre categorie di traffico per Office 365. Ottimizza e Consenti dovrebbe davvero andare direttamente e ignorare il proxy. Il valore predefinito può essere sottoposto a proxy. I dettagli sono in questi documenti... leggerli.

La maggior parte dei clienti che insistono sull'uso di un proxy, quando effettivamente esaminano ciò che stanno facendo, si rendono conto che quando il client effettua una richiesta HTTP CONNECT al proxy, il proxy è ora solo un router aggiuntivo costoso. I protocolli in uso, ad esempio MAPI e RTC, non sono nemmeno protocolli che i proxy Web comprendono, quindi anche con il cracking TLS non si ottiene alcuna sicurezza aggiuntiva. Si sta* ottenendo una latenza aggiuntiva. Per altre informazioni https://aka.ms/pnc , vedere le categorie Optimize, Allow e Default per il traffico di Microsoft 365.

Si consideri infine l'impatto complessivo sul proxy e la risposta corrispondente per gestire tale impatto. Man mano che si eseguono sempre più connessioni tramite il proxy, il fattore di scala TCP potrebbe diminuire in modo da non dover memorizzare nel buffer così tanto traffico. Ho visto i clienti in cui i proxy erano così sovraccarichi che usavano un fattore di scala di 0. Poiché Fattore di scala è un valore esponenziale e si vuole usare 8, ogni riduzione del valore del fattore di scala ha un impatto negativo enorme sulla velocità effettiva.

Ispezione TLS significa SICUREZZA! Ma non proprio! Molti clienti con proxy vogliono usarli per controllare tutto il traffico, il che significa che TLS "si rompe e ispeziona". Quando si esegue questa operazione per un sito Web a cui si accede tramite HTTPS (nonostante i problemi di privacy), il proxy potrebbe dover eseguire questa operazione per 10 o anche 20 flussi simultanei per poche centinaia di millisecondi. Se è presente un download di grandi dimensioni o un video coinvolto, una o più di queste connessioni possono durare molto più a lungo, ma nel complesso, la maggior parte di queste connessioni stabilisce, trasferisce e chiude molto rapidamente. Se si esegue un'interruzione e un controllo, il proxy deve eseguire il doppio del lavoro. Per ogni connessione dal client al proxy, il proxy deve anche effettuare una connessione separata all'endpoint. Quindi, 1 diventa 2, 2 diventa 4, 32 diventa 64...vedere dove sto andando? Probabilmente la soluzione proxy è stata ridimensionata correttamente per la navigazione web tipica, ma quando si tenta di eseguire la stessa operazione per le connessioni client a Office 365, il numero di connessioni simultanee e di lunga durata può essere un ordine di grandezza maggiore di quello per cui si è dimensionate.

Lo streaming non è importante, ad eccezione del fatto che è

Gli unici servizi in Office 365 che usano UDP sono Skype (presto ritirato) e Microsoft Teams. Teams usa UDP per lo streaming del traffico, tra cui la condivisione di audio, video e presentazioni. Il traffico in streaming è live, ad esempio quando si sta tenendo una riunione online con voce, video e presentazione di mazzi o si eseguono demo. Questi usano UDP perché se i pacchetti vengono eliminati o arrivano fuori ordine, è praticamente inosservabile per l'utente e il flusso può semplicemente continuare.

Quando non si consente il traffico UDP in uscita dai client al servizio, possono tornare all'uso di TCP. Ma se un pacchetto TCP viene eliminato, tutto si arresta fino alla scadenza del timeout di ritrasmissione (RTO) e il pacchetto mancante può essere ritrasmesso. Se un pacchetto arriva fuori ordine, tutto si arresta fino all'arrivo degli altri pacchetti e può essere riassemblato in ordine. Entrambi portano a glitch percepibili nell'audio (ricorda Max Headroom?) e video (hai fatto clic su qualcosa... oh, c'è) e portare a prestazioni scadenti e un'esperienza utente non valida. E ricordi cosa ho messo sopra sui proxy? Quando si forza un client di Teams a usare un proxy, è necessario forzarlo a usare TCP. Quindi ora si stanno causando effetti negativi sulle prestazioni due volte.

Split tunneling può sembrare spaventoso

Ma non lo è. Tutte le connessioni a Office 365 sono tramite TLS. TLS 1.2 è disponibile da un po' di tempo e presto disabiliterà le versioni precedenti perché i client legacy le usano ancora e questo è un rischio.

Forzare una connessione TLS, o 32 di esse, a passare una VPN prima di passare al servizio non aggiunge sicurezza. Aggiunge la latenza e riduce la velocità effettiva complessiva. In alcune soluzioni VPN, forza anche UDP a eseguire il tunneling tramite TCP, il che avrà un impatto molto negativo sul traffico in streaming. E, a meno che non si stia eseguendo l'ispezione TLS, non c'è alcun lato negativo, tutto a dispendioso. Un tema molto comune tra i clienti, ora che la maggior parte della forza lavoro è remota, è che stanno vedendo un impatto significativo sulla larghezza di banda e sulle prestazioni derivanti dalla connessione di tutti gli utenti usando una VPN, invece di configurare il tunneling diviso per l'accesso alla categoria Optimize Office 365 endpoint.

È una soluzione semplice per eseguire il tunneling diviso ed è uno che dovresti fare. Per altre informazioni, vedere Ottimizzare la connettività Office 365 per gli utenti remoti tramite split tunneling VPN.

I peccati del passato

Molte volte, il motivo per cui vengono effettuate scelte sbagliate deriva da una combinazione di (1) non sapendo come funziona il servizio, (2) cercando di rispettare i criteri aziendali scritti prima di adottare il cloud e (3) team di sicurezza che potrebbero non essere facilmente convinti che ci sia più di un modo per raggiungere i loro obiettivi. Speriamo che quanto sopra, e i collegamenti seguenti, aiuterà con il primo. La sponsorizzazione dei dirigenti potrebbe essere necessaria per superare il secondo. La risoluzione degli obiettivi dei criteri di sicurezza, anziché i relativi metodi, è utile per il terzo. Dall'accesso condizionale alla moderazione del contenuto, dalla prevenzione della perdita dei dati alla protezione delle informazioni, dalla convalida degli endpoint alle minacce zero-day: qualsiasi obiettivo finale che un criterio di sicurezza ragionevole può avere può essere raggiunto con ciò che è disponibile in Office 365 e senza alcuna dipendenza da ingranaggi di rete locali, tunnel VPN forzati e interruzioni e controlli TLS.

Altre volte, l'hardware ridimensionato e acquistato prima che l'organizzazione iniziasse a passare al cloud semplicemente non può essere ridimensionato per gestire i nuovi modelli di traffico e carichi. Se è veramente necessario instradare tutto il traffico attraverso un singolo punto di uscita e/o proxy, è necessario prepararsi ad aggiornare le apparecchiature di rete e la larghezza di banda di conseguenza. Monitorare attentamente l'utilizzo in entrambi, poiché l'esperienza non diminuisce lentamente man mano che un numero maggiore di utenti esegue l'onboarding. Tutto va bene fino a quando non viene raggiunto il punto di ribaltamento, poi tutti soffrono.

Eccezioni alle regole

Se l'organizzazione richiede restrizioni del tenant, è necessario usare un proxy con interruzione TLS e controllare per forzare il traffico attraverso il proxy, ma non è necessario forzare tutto il traffico attraverso di esso. Non si tratta di una proposta totale o nulla, quindi prestare attenzione a ciò che deve essere modificato dal proxy.

Se si vuole consentire lo split tunneling, ma si usa anche un proxy per il traffico Web generale, assicurarsi che il file PAC definisca ciò che deve essere diretto e come si definisce il traffico interessante per ciò che passa attraverso il tunnel VPN. I file PAC di esempio sono disponibili in https://aka.ms/ipaddrs che semplificano la gestione.

Conclusione

Decine di migliaia di organizzazioni, tra cui quasi tutte le Fortune 500, usano Office 365 tutti i giorni per le loro funzioni cruciali. Lo fanno in modo sicuro, e lo fanno su Internet.

Indipendentemente dagli obiettivi di sicurezza in gioco, esistono modi per raggiungerli che non richiedono connessioni VPN, server proxy, interruzioni e controlli TLS o uscita Internet centralizzata per far uscire il traffico degli utenti dalla rete e verso il nostro il più rapidamente possibile, il che offre le migliori prestazioni, indipendentemente dal fatto che la rete sia la sede centrale dell'azienda, un ufficio remoto o l'utente che lavora a casa. Le linee guida sono basate su come vengono creati i servizi Office 365 e per garantire un'esperienza utente sicura ed efficiente.