Nätverk upp (till molnet)– En arkitekts synvinkel

Artikel
07/16/2023

I den här artikeln beskriver Ed Fisher, Security & Compliance Architect på Microsoft, hur du optimerar ditt nätverk för molnanslutning genom att undvika de vanligaste fallgroparna.

Om författaren

Skärmbild av Ed Fisher-fotot.

Jag är för närvarande teknisk specialist i vårt detaljhandels- och konsumentvaruteam med fokus på säkerhet & efterlevnad. Jag har arbetat med kunder som flyttar till Office 365 under de senaste tio åren. Jag har arbetat med mindre butiker med en handfull platser till myndigheter och företag med miljontals användare distribuerade runt om i världen, och många andra kunder däremellan, där majoriteten har tiotusentals användare, flera platser i olika delar av världen, behovet av en högre grad av säkerhet och en mängd efterlevnadskrav. Jag har hjälpt hundratals företag och miljontals användare att flytta till molnet på ett säkert sätt.

Med en bakgrund under de senaste 25 åren som inkluderar säkerhet, infrastruktur och nätverksteknik, och efter att ha flyttat två av mina tidigare arbetsgivare till Office 365 innan jag började på Microsoft, har jag varit på din sida av bordet många gånger och kommer ihåg hur det är. Även om inga två kunder någonsin är likadana har de flesta liknande behov, och när du använder en standardiserad tjänst, till exempel en SaaS- eller PaaS-plattform, tenderar de bästa metoderna att vara desamma.

Det är inte nätverket – det är så du (fel)använder det!

Oavsett hur många gånger det händer misslyckas det aldrig med att förvåna mig hur kreativa säkerhetsteam och nätverksteam försöker få med hur de tycker att de ska ansluta till Microsofts molntjänster. Det finns alltid vissa säkerhetsprinciper, efterlevnadsstandarder eller bättre sätt som de insisterar på att använda, utan att vara villiga att delta i en konversation om vad det är de försöker åstadkomma, eller hur det finns bättre, enklare, mer kostnadseffektiva och mer högpresterande sätt att göra det.

När den här typen av saker eskaleras till mig är jag vanligtvis villig att ta utmaningen och gå igenom hur och varför och få dem dit de behöver vara. Men om jag är helt uppriktig, måste jag dela att ibland vill jag bara låta dem göra vad de kommer att göra, och komma tillbaka för att säga att jag sa till dig så när de äntligen medger att det inte fungerar. Jag kanske vill göra det ibland, men det gör jag inte. Vad jag gör är att försöka förklara allt vad jag ska inkludera i det här inlägget. Oavsett din roll, om din organisation vill använda Microsofts molntjänster, finns det förmodligen viss visdom i vad som följer som kan hjälpa dig.

Riktlinjer

Vi börjar med några grundregler kring vad vi gör här. Vi diskuterar hur du på ett säkert sätt ansluter till molntjänster för att säkerställa minsta komplexitet och högsta prestanda, samtidigt som verklig säkerhet upprätthålls. Inget av det som följer strider mot något av detta, även om du eller kunden inte får använda din favoritproxyserver för allt.

Bara för att du kan, betyder det inte att du borde: Eller att parafrasera Dr. Ian Malcolm från Jurassic Park-filmen "... Ja, ja, men ditt säkerhetsteam var så upptagna med om de kunde eller inte att de inte stannade för att tänka om de skulle göra det."
Säkerhet innebär inte komplexitet: Du är inte säkrare bara för att du spenderar mer pengar, dirigerar genom fler enheter eller klickar på fler knappar.
Office 365 nås via Internet: Men det är inte samma sak som Office 365 är Internet. Det är en SaaS-tjänst som hanteras av Microsoft och administreras av dig. Till skillnad från webbplatser som du besöker på Internet får du faktiskt kika bakom kulisserna och kan tillämpa de kontroller du behöver för att uppfylla dina policyer och dina efterlevnadsstandarder, så länge du förstår att även om du kan uppfylla dina mål, kan du bara behöva göra dem på ett annat sätt.
Chokepoints är dåliga, lokaliserade breakouts är bra: Alla vill alltid backhaul all sin Internettrafik för alla sina användare till någon central punkt, vanligtvis så att de kan övervaka det och genomdriva policyer, men ofta för att det antingen är billigare än att etablera Internetåtkomst på alla sina platser, eller det är bara hur de gör det. Men dessa chokepoints är precis så... punkter där trafiken stryps. Det är inget fel med att hindra användarna från att bläddra till Instagram eller strömma kattvideor, men behandla inte din verksamhetskritiska affärsprogramtrafik på samma sätt.
Om DNS inte är nöjd är inget lyckligt: Det bäst utformade nätverket kan hamstras av dålig DNS, oavsett om det är genom att upprepa begäranden till servrar i andra delar av världen eller använda internetleverantörens DNS-servrar eller andra offentliga DNS-servrar som cachelagrar DNS-matchningsinformation.
Bara för att det var så du brukade göra det betyder det inte att det är så du ska göra det nu: Tekniken förändras hela tiden och Office 365 är inget undantag. Att tillämpa säkerhetsåtgärder som har utvecklats och distribuerats för lokala tjänster eller för att kontrollera webbsurfning kommer inte att ge samma säkerhetsnivå och kan ha en betydande negativ inverkan på prestandan.
Office 365 har skapats för att nås via Internet: Det är det i ett nötskal. Oavsett vad du vill göra mellan användarna och gränsen går trafiken fortfarande över Internet när den lämnar ditt nätverk och innan den hamnar på vår. Även om du använder Azure ExpressRoute för att dirigera viss svarstidskänslig trafik från ditt nätverk direkt till vårt, är Internetanslutning absolut nödvändigt. Acceptera det. Tänk inte för mycket på det.

Där dåliga val ofta görs

Även om det finns många platser där dåliga beslut fattas i säkerhetens namn, är det dessa som jag oftast stöter på med kunder. Många kundkonversationer omfattar alla dessa samtidigt.

Otillräckliga resurser vid gränsen

Väldigt få kunder distribuerar miljöerna på grönområden, och de har många års erfarenhet av hur deras användare arbetar och hur deras internetutgång ser ut. Oavsett om kunderna har proxyservrar eller tillåter direkt åtkomst och helt enkelt NAT-utgående trafik, har de gjort det i flera år och överväger inte hur mycket mer de kommer att börja pumpa genom gränsen när de flyttar traditionellt interna program ut till molnet.

Bandbredd är alltid ett problem, men NAT-enheter kanske inte har tillräckligt med hästkrafter för att hantera den ökade belastningen och kan börja stänga anslutningar i förtid för att frigöra resurser. De flesta klientprogram som ansluter till Office 365 förväntar sig beständiga anslutningar och en användare som fullt ut använder Office 365 kan ha 32 eller fler samtidiga anslutningar. Om NAT-enheten släpper dem i förtid kan dessa appar sluta svara när de försöker använda de anslutningar som inte längre finns där. När de ger upp och försöker upprätta nya anslutningar lägger de ännu mer belastning på nätverksutrustningen.

Lokaliserad gruppsession

Allt annat i den här listan handlar om en sak – att komma bort från ditt nätverk och till vårt så snabbt som möjligt. Backhauling av användarnas trafik till en central utgående punkt, särskilt när den utgående punkten är i en annan region än användarna befinner sig i, medför onödig svarstid och påverkar både klientupplevelsen och nedladdningshastigheten. Microsoft har närvaropunkter över hela världen med klientdelar för alla våra tjänster och peering som upprättats med praktiskt taget alla större Internetleverantör, så routning av användarnas trafik lokalt säkerställer att den kommer in i vårt nätverk snabbt med minsta svarstid.

DNS-matchningstrafik bör följa Internets utgående sökväg

För att en klient ska kunna hitta en slutpunkt måste den naturligtvis använda DNS. Microsofts DNS-servrar utvärderar källan för DNS-begäranden för att säkerställa att vi returnerar svaret som i Internettermer är närmast källan för begäran. Kontrollera att DNS är konfigurerat så att namnmatchningsbegäranden går ut på samma sökväg som användarnas trafik, så att du inte ger dem lokal utgående trafik utan till en slutpunkt i en annan region. Det innebär att låta lokala DNS-servrar "gå till roten" i stället för att vidarebefordra till DNS-servrar i fjärranslutna datacenter. Och watch för offentliga och privata DNS-tjänster, som kan cachelagra resultat från en del av världen och betjäna dem till förfrågningar från andra delar av världen.

Till proxy eller inte till proxy är det frågan

En av de första sakerna att tänka på är om proxyanvändares anslutningar till Office 365. Den är lätt; proxy. Office 365 nås via Internet, men det är inte Internet. Det är en förlängning av dina kärntjänster och bör behandlas som sådana. Allt du kanske vill att en proxyserver ska göra, till exempel DLP eller program mot skadlig kod eller innehållsgranskning, är redan tillgängligt för dig i tjänsten och kan användas i stor skala och utan att behöva knäcka TLS-krypterade anslutningar. Men om du verkligen vill proxytrafik som du inte kan styra på annat sätt bör du vara uppmärksam på vår vägledning på https://aka.ms/pnc och trafikkategorierna på https://aka.ms/ipaddrs. Vi har tre trafikkategorier för Office 365. Optimera och Tillåt bör verkligen gå direkt och kringgå proxyn. Standardvärdet kan vara proxierat. Informationen finns i dokumenten... läsa dem.

De flesta kunder som insisterar på att använda en proxy, när de faktiskt tittar på vad de gör, kommer att inse att när klienten gör en HTTP CONNECT-begäran till proxyn är proxyn nu bara en dyr extra router. De protokoll som används som MAPI och RTC är inte ens protokoll som webbproxyservrar förstår, så även med TLS-sprickbildning får du egentligen ingen extra säkerhet. Du får * extra svarstid. Mer https://aka.ms/pnc information finns i kategorierna Optimera, Tillåt och Standard för Microsoft 365-trafik.

Slutligen bör du överväga den övergripande effekten på proxyn och dess motsvarande svar för att hantera den effekten. När fler och fler anslutningar görs via proxyn kan det minska TCP-skalningsfaktorn så att den inte behöver buffrar så mycket trafik. Jag har sett kunder där deras proxyservrar var så överbelastade att de använde en skalningsfaktor på 0. Eftersom Scale Factor är ett exponentiellt värde och vi vill använda 8, är varje minskning av skalningsfaktorvärdet en enorm negativ inverkan på dataflödet.

TLS-inspektion innebär SÄKERHET! Men inte riktigt! Många kunder med proxyservrar vill använda dem för att inspektera all trafik, vilket innebär att TLS "bryts och inspekteras". När du gör det för en webbplats som nås via HTTPS (trots sekretessproblem) kan proxyn behöva göra det i 10 eller till och med 20 samtidiga strömmar under några hundra millisekunder. Om det finns en stor nedladdning eller kanske en video kan en eller flera av dessa anslutningar pågå mycket längre, men på det hela taget upprättar, överför och stänger de flesta av dessa anslutningar mycket snabbt. Att göra avbrott och inspektera innebär att proxyn måste göra dubbelt så mycket arbete. För varje anslutning från klienten till proxyn måste proxyn också upprätta en separat anslutning tillbaka till slutpunkten. Så, blir 1 2, 2 blir 4, 32 blir 64 ... se vart jag ska? Du har förmodligen storlek på din proxylösning bra för typisk webbsurfning, men när du försöker göra samma sak för klientanslutningar till Office 365 kan antalet samtidiga, långlivade anslutningar vara storleksordningar större än vad du har storlek för.

Direktuppspelning är inte viktigt, förutom att det är

De enda tjänsterna i Office 365 som använder UDP är Skype (snart tillbaka) och Microsoft Teams. Teams använder UDP för strömmande trafik, inklusive ljud, video och presentationsdelning. Strömmande trafik är live, till exempel när du har ett onlinemöte med röst-, video- och presentationsdäck eller utför demonstrationer. Dessa använder UDP eftersom om paket tas bort eller tas emot i fel ordning är det praktiskt taget onoterbart av användaren och strömmen kan bara fortsätta.

När du inte tillåter utgående UDP-trafik från klienter till tjänsten kan de återgå till att använda TCP. Men om ett TCP-paket tas bort stoppas allt tills timeouten för återöverföring (RTO) upphör att gälla och det saknade paketet kan överföras på nytt. Om ett paket tas emot i fel ordning stoppas allt tills de andra paketen tas emot och kan sättas ihop på nytt i ordning. Båda leder till märkbara problem i ljudet (kom ihåg Max Headroom?) och video (klickade du på något ... oh, där är det) och leder till dålig prestanda och en dålig användarupplevelse. Och minns du vad jag satte upp ovan om proxyservrar? När du tvingar en Teams-klient att använda en proxy tvingar du den att använda TCP. Nu orsakar du alltså negativa prestandaeffekter två gånger.

Delade tunnlar kan verka skrämmande

Men det är det inte. Alla anslutningar till Office 365 är över TLS. Vi har erbjudit TLS 1.2 ett tag nu och kommer snart att inaktivera äldre versioner eftersom äldre klienter fortfarande använder dem och det är en risk.

Att tvinga en TLS-anslutning, eller 32 av dem, att gå över ett VPN innan de sedan går till tjänsten ökar inte säkerheten. Den lägger till svarstid och minskar det totala dataflödet. I vissa VPN-lösningar tvingar den till och med UDP till tunnel genom TCP, vilket återigen kommer att ha en mycket negativ inverkan på strömmande trafik. Och om du inte gör TLS-inspektion, finns det ingen uppsida, all nackdel. Ett mycket vanligt tema bland kunderna, nu när de flesta av deras anställda är fjärranslutna, är att de ser betydande bandbredds- och prestandaeffekter från att få alla sina användare att ansluta med hjälp av ett VPN, i stället för att konfigurera delade tunnlar för åtkomst till kategorin Optimera Office 365 slutpunkter.

Det är en enkel lösning att göra delade tunnlar och det är en som du bör göra. Mer information finns i Optimera Office 365 anslutning för fjärranvändare med delade VPN-tunnlar.

Det förflutnas synder

Många gånger kommer orsaken till att dåliga val görs från en kombination av (1) som inte vet hur tjänsten fungerar, (2) försöker följa företagets principer som skrevs innan molnet infördes, och (3) säkerhetsteam som kanske inte är lätta att övertyga om att det finns mer än ett sätt att uppnå sina mål. Förhoppningsvis ovanstående, och länkarna nedan, kommer att hjälpa till med den första. Verkställande sponsring kan krävas för att komma förbi den andra. Att ta itu med säkerhetspolicyernas mål, snarare än deras metoder, hjälper till med den tredje. Från villkorlig åtkomst till innehållsmoderering, DLP till informationsskydd, slutpunktsvalidering till nolldagarshot – alla slutmål som en rimlig säkerhetsprincip kan ha kan uppnås med det som är tillgängligt i Office 365 och utan något beroende av lokal nätverksutrustning, tvingad VPN-tunnlar och TLS-avbrott och inspektion.

Andra gånger kan maskinvara som har storleksanpassats och köpts innan organisationen började flytta till molnet helt enkelt inte skalas upp för att hantera de nya trafikmönstren och belastningarna. Om du verkligen måste dirigera all trafik genom en enda utgående punkt, och/eller proxy, bör du vara beredd att uppgradera nätverksutrustning och bandbredd i enlighet med detta. Övervaka användningen på båda, eftersom upplevelsen inte minskar långsamt när fler användare registreras. Allt är bra tills tipping point har nåtts, då lider alla.

Undantag till reglerna

Om din organisation kräver klientbegränsningar måste du använda en proxy med TLS-avbrott och inspektera för att tvinga viss trafik via proxyn, men du behöver inte tvinga all trafik genom den. Det är inte ett allt- eller inget-förslag, så var uppmärksam på vad som behöver ändras av proxyn.

Om du ska tillåta delade tunnlar men även använda en proxy för allmän webbtrafik ska du se till att PAC-filen definierar vad som måste gå direkt samt hur du definierar intressant trafik för vad som går via VPN-tunneln. Vi erbjuder PAC-exempelfiler på https://aka.ms/ipaddrs som gör det enklare att hantera.

Sammanfattning

Tiotusentals organisationer, inklusive nästan alla Fortune 500, använder Office 365 varje dag för sina verksamhetskritiska funktioner. De gör det på ett säkert sätt, och de gör det via Internet.

Oavsett vilka säkerhetsmål du har i spel finns det sätt att uppnå dem som inte kräver VPN-anslutningar, proxyservrar, TLS-avbrott och kontroll eller centraliserad Internetutgång för att få användarnas trafik från nätverket och vidare till vårt så snabbt som möjligt, vilket ger bästa prestanda, oavsett om nätverket är företagets huvudkontor, ett fjärranslutet kontor eller den användaren som arbetar hemma. Vår vägledning baseras på hur Office 365 tjänster skapas och för att säkerställa en säker och högpresterande användarupplevelse.