Nettverk opp (til skyen) – ett arkitektsynspunkt

Artikkel
07/16/2023

I denne artikkelen beskriver Ed Fisher, Security & Compliance Architect hos Microsoft, hvordan du optimaliserer nettverket for skytilkobling ved å unngå de vanligste fallgruvene.

Om forfatteren

Skjermbilde av Ed Fisher-bilde.

Jeg er for tiden teknisk sjef i teamet vårt for detaljhandel og forbruksvarer, med fokus på sikkerhet & samsvar. Jeg har jobbet med kunder som har flyttet til Office 365 de siste ti årene. Jeg har jobbet med mindre butikker med en håndfull steder til offentlige etater og bedrifter med millioner av brukere distribuert over hele verden, og mange andre kunder i mellom, med flertallet har titusenvis av brukere, flere steder i ulike deler av verden, behovet for en høyere grad av sikkerhet, og en rekke samsvarskrav. Jeg har hjulpet hundrevis av virksomheter og millioner av brukere med å flytte til skyen trygt og sikkert.

Med en bakgrunn i løpet av de siste 25 årene som inkluderer sikkerhet, infrastruktur og nettverksteknikk, og som har flyttet to av mine tidligere arbeidsgivere til Office 365 før jeg ble med i Microsoft, har jeg vært på din side av tabellen mange ganger, og husker hvordan det er. Selv om ingen kunder noensinne er like, har de fleste lignende behov, og når du bruker en standardisert tjeneste som enhver SaaS- eller PaaS-plattform, pleier de beste tilnærmingene å være de samme.

Det er ikke nettverket – det er slik du (mis)bruker det!

Uansett hvor mange ganger det skjer, vil det aldri overraske meg hvor kreative sikkerhetsteam og nettverksteam som prøver å få tak i hvordan de mener de bør koble til Microsoft-skytjenester. Det finnes alltid noen sikkerhetspolicyer, samsvarsstandarder eller bedre måter de insisterer på å bruke, uten å være villige til å delta i en samtale om hva de prøver å oppnå, eller hvordan det finnes bedre, enklere, mer kostnadseffektive og mer effektive måter å gjøre det på.

Når denne typen ting eskaleres til meg, er jeg vanligvis villig til å ta utfordringen og gå dem gjennom hvordan og hvorfor og få dem til der de trenger å være. Men hvis jeg er helt ærlig, må jeg dele det noen ganger vil jeg bare la dem gjøre det de vil, og komme tilbake for å si at jeg fortalte deg det når de endelig innrømmer at det ikke fungerer. Jeg vil kanskje gjøre det noen ganger, men det gjør jeg ikke. Det jeg gjør er å prøve å forklare alt jeg skal inkludere i dette innlegget. Uavhengig av rollen din, hvis organisasjonen ønsker å bruke Microsoft-skytjenester, er det sannsynligvis litt visdom i det følgende som kan hjelpe deg.

Veiledende prinsipper

La oss starte med noen grunnregler rundt hva vi gjør her. Vi diskuterer hvordan du kobler til skytjenester på en sikker måte for å sikre minimum kompleksitet og maksimal ytelse, samtidig som den opprettholder reell sikkerhet. Ingenting av det følgende er teller til noe av dette, selv om du, eller kunden, ikke får bruke din favoritt proxy-server for alt.

Bare fordi du kan, betyr ikke at du bør: Eller å omskrive Dr. Ian Malcolm fra Jurassic Park filmen "... Ja, ja, men sikkerhetsteamet ditt var så opptatt av hvorvidt de kunne at de ikke sluttet å tenke på om de skulle.»
Sikkerhet betyr ikke kompleksitet: Du er ikke sikrere bare fordi du bruker mer penger, ruter gjennom flere enheter eller klikker på flere knapper.
Office 365 er tilgjengelig via Internett: Men det er ikke det samme som Office 365 er Internett. Det er en SaaS-tjeneste som administreres av Microsoft og administreres av deg. I motsetning til nettsteder du besøker på Internett, får du faktisk kikke bak gardinen, og kan bruke kontrollene du trenger for å oppfylle dine retningslinjer og dine samsvarsstandarder, så lenge du forstår at selv om du kan oppfylle målene dine, må du kanskje bare gjøre dem på en annen måte.
Chokepoints er dårlige, lokaliserte breakouts er gode: Alle ønsker alltid å backhaul all sin Internett-trafikk for alle sine brukere til et sentralt punkt, vanligvis slik at de kan overvåke det og håndheve politikk, men ofte fordi det er enten billigere enn å klargjøre Internett-tilgang på alle sine steder, eller det er bare hvordan de gjør det. Men de chokepoints er akkurat det ... punkter der trafikken kveles. Det er ikke noe galt med å hindre brukerne i å surfe på Instagram eller strømme kattevideoer, men ikke behandle den driftskritiske forretningsprogramtrafikken på samme måte.
Hvis DNS ikke er fornøyd, er det ikke noe som er fornøyd: Det best utformede nettverket kan hamstreres av dårlig DNS, enten det er ved å gjenta forespørsler til servere i andre områder av verden eller ved hjelp av INTERNETT-leverandørens DNS-servere eller andre offentlige DNS-servere som bufrer DNS-oppløsningsinformasjon.
Bare fordi det er slik du pleide å gjøre det, betyr det ikke at det er slik du bør gjøre det nå: Teknologien endres hele tiden, og Office 365 er ikke noe unntak. Bruk av sikkerhetstiltak som ble utviklet og distribuert for lokale tjenester eller for å kontrollere nettsurfing, vil ikke gi samme sikkerhetssikringsnivå, og kan ha en betydelig negativ innvirkning på ytelsen.
Office 365 ble bygget for å nås via Internett: Det er det i et nøtteskall. Uansett hva du vil gjøre mellom brukerne og kanten, går trafikken fortsatt over Internett når den forlater nettverket og før det kommer inn på vårt. Selv om du bruker Azure ExpressRoute til å rute noe ventetidssensitiv trafikk fra nettverket direkte til vårt, er Internett-tilkobling helt nødvendig. Godta det. Ikke overtenk det.

Der dårlige valg ofte gjøres

Mens det er mange steder hvor dårlige beslutninger tas i sikkerhetens navn, er dette de jeg møter oftest med kunder. Mange kundesamtaler involverer alle disse samtidig.

Utilstrekkelige ressurser på kanten

Svært få kunder distribuerer greenfield-miljøer, og de har mange års erfaring med hvordan brukerne arbeider og hvordan utgående Internett er. Enten kunder har proxy-servere eller tillater direkte tilgang og bare NAT utgående trafikk, de har gjort det i årevis, og ikke vurdere hvor mye mer de kommer til å begynne å pumpe gjennom kanten som de flytter tradisjonelt interne programmer ut til skyen.

Båndbredde er alltid en bekymring, men NAT-enheter har kanskje ikke nok hestekrefter til å håndtere den økte belastningen og kan begynne å lukke tilkoblinger for tidlig for å frigjøre ressurser. Mesteparten av klientprogramvaren som kobles til Office 365 forventer vedvarende tilkoblinger, og en bruker bruker fullt ut Office 365 kan ha 32 eller flere samtidige tilkoblinger. Hvis NAT-enheten slipper dem for tidlig, kan det hende at disse appene ikke svarer når de prøver å bruke tilkoblingene som ikke lenger er der. Når de gir opp og prøver å etablere nye tilkoblinger, legger de enda mer belastning på nettverksutstyret.

Lokalisert utbryter

Alt annet i denne listen kommer ned til én ting – å gå av nettverket og inn på vårt så raskt som mulig. Backhauling brukernes trafikk til et sentralt utgående punkt, spesielt når det utgående punktet er i et annet område enn brukerne er i, introduserer unødvendig ventetid og påvirker både klientopplevelsen og nedlastingshastigheter. Microsoft har punkter av tilstedeværelse over hele verden med frontendepunkt for alle våre tjenester og nodefordeling etablert med praktisk talt alle store Internett-leverandørleverandører, så ruting brukernes trafikk ut lokalt sikrer at det kommer raskt inn i nettverket vårt med minimal ventetid.

DNS-oppløsningstrafikk bør følge utgående internettbane

For at en klient skal kunne finne et endepunkt, må den selvfølgelig bruke DNS. Microsofts DNS-servere evaluerer kilden til DNS-forespørsler for å sikre at vi returnerer svaret som er, i Internett-termer, nærmest kilden til forespørselen. Kontroller at DNS er konfigurert slik at navneløsingsforespørsler går ut samme bane som brukernes trafikk, slik at du ikke gir dem lokal utgående trafikk, men til et endepunkt i et annet område. Det betyr å la lokale DNS-servere «gå til rot» i stedet for å videresende til DNS-servere i eksterne datasentre. Og se opp for offentlige og private DNS-tjenester, som kan bufre resultater fra en del av verden og tjene dem til forespørsler fra andre deler av verden.

Hvis du vil proxy eller ikke til proxy, er det spørsmålet

Noe av det første du må vurdere, er om proxy-brukernes tilkoblinger skal Office 365. Den er enkel; ikke proxy. Office 365 er tilgjengelig via Internett, men det er ikke Internett. Det er en utvidelse av kjernetjenestene dine og bør behandles som sådan. Alt du kanskje vil at en proxy skal gjøre, for eksempel DLP eller beskyttelse mot skadelig programvare eller innholdsinspeksjon, er allerede tilgjengelig for deg i tjenesten, og kan brukes i stor skala og uten å måtte knekke TLS-krypterte tilkoblinger. Men hvis du virkelig ønsker å proxy trafikk som du ellers ikke kan kontrollere, ta hensyn til vår veiledning på https://aka.ms/pnc og kategoriene av trafikk på https://aka.ms/ipaddrs. Vi har tre kategorier med trafikk for Office 365. Optimaliser og Tillat bør virkelig gå direkte og omgå proxyen. Standardinnstillingen kan være utsatt. Detaljene er i disse dokumentene ... lese dem.

De fleste kunder som insisterer på å bruke en proxy, når de faktisk ser på hva de gjør, innser at når klienten foretar en HTTP CONNECT-forespørsel til proxyen, er proxyen nå bare en dyr ekstra ruter. Protokollene i bruk som MAPI og RTC er ikke engang protokoller som nettproxyer forstår, så selv med TLS-sprekking får du egentlig ikke noen ekstra sikkerhet. Du* får ekstra ventetid. Se https://aka.ms/pnc mer om dette, inkludert kategoriene Optimaliser, Tillat og Standard for Microsoft 365-trafikk.

Til slutt bør du vurdere den generelle innvirkningen på proxyen og dens tilsvarende svar for å håndtere denne virkningen. Etter hvert som flere og flere tilkoblinger utføres gjennom proxyen, kan det redusere TCP Scale Factor slik at den ikke trenger å bufre så mye trafikk. Jeg har sett kunder hvor proxyene deres var så overbelastet at de brukte en skalafaktor på 0. Siden Scale Factor er en eksponentiell verdi og vi liker å bruke 8, er hver reduksjon i scale factor-verdien en stor negativ innvirkning på gjennomstrømmingen.

TLS-inspeksjon betyr SIKKERHET! Men egentlig ikke! Mange kunder med proxyer ønsker å bruke dem til å inspisere all trafikk, og det betyr at TLS «bryter og inspiserer». Når du gjør dette for et nettsted som er tilgjengelig via HTTPS (personvernproblemer til tross) må proxyen kanskje gjøre dette i 10 eller til og med 20 samtidige strømmer i noen hundre millisekunder. Hvis det er en stor nedlasting eller kanskje en video involvert, kan en eller flere av disse tilkoblingene vare mye lenger, men de fleste av disse tilkoblingene etablerer, overfører og lukker svært raskt. Hvis du gjør pause og inspiserer, betyr det at proxyen må gjøre det dobbelte av arbeidet. Proxyen må også opprette en separat tilkobling tilbake til endepunktet for hver tilkobling fra klienten til proxyen. Så, 1 blir 2, 2 blir 4, 32 blir 64 ... se hvor jeg skal? Du har sannsynligvis tilpasset proxy-løsningen helt fint for vanlig nettsurfing, men når du prøver å gjøre det samme for klienttilkoblinger til Office 365, kan antallet samtidige, langvarige tilkoblinger være størrelsesrekkefølger som er større enn det du har størrelse på.

Strømming er ikke viktig, bortsett fra at det er

De eneste tjenestene i Office 365 som bruker UDP, er Skype (snart tilbaketrukket) og Microsoft Teams. Teams bruker UDP for strømming av trafikk, inkludert lyd, video og presentasjonsdeling. Strømming av trafikk er direkte, for eksempel når du har et nettmøte med tale, video og presentasjon av presentasjoner eller demonstrasjoner. Disse bruker UDP fordi hvis pakker slippes eller kommer ut av drift, er det praktisk talt uoversiktlig for brukeren, og strømmen kan bare fortsette.

Når du ikke tillater utgående UDP-trafikk fra klienter til tjenesten, kan de falle tilbake til å bruke TCP. Men hvis en TCP-pakke slippes, stopper alt til tidsavbruddet for overføring (RTO) utløper, og den manglende pakken kan overføres på nytt. Hvis en pakke kommer ut av drift, stopper alt til de andre pakkene ankommer og kan settes sammen igjen i rekkefølge. Begge fører til merkbare feil i lyden (husk Max Headroom?) og video (klikket du noe ... oh, der er det) og føre til dårlig ytelse og en dårlig brukeropplevelse. Og husker du hva jeg satte opp ovenfor om proxyer? Når du tvinger en Teams-klient til å bruke en proxy, tvinger du den til å bruke TCP. Så nå forårsaker du negative ytelseseffekter to ganger.

Delt tunnelering kan virke skummelt

Men det er det ikke. Alle tilkoblinger til Office 365 er over TLS. Vi har tilbudt TLS 1.2 en stund nå, og vil deaktivere eldre versjoner snart fordi eldre klienter fortsatt bruker dem, og det er en risiko.

Å tvinge en TLS-tilkobling, eller 32 av dem, til å gå over et VPN før de deretter går til tjenesten, legger ikke til sikkerhet. Den legger til ventetid og reduserer den generelle gjennomstrømmingen. I noen VPN-løsninger tvinger den til og med UDP til å tunnelere gjennom TCP, noe som igjen vil ha en svært negativ innvirkning på strømming av trafikk. Og med mindre du gjør TLS inspeksjon, det er ingen oppside, alle ulemper. Et svært vanlig tema blant kundene, nå som mesteparten av arbeidsstyrken er fjern, er at de ser betydelige båndbredde- og ytelseseffekter fra å få alle brukerne til å koble seg til ved hjelp av et VPN, i stedet for å konfigurere delt tunnelering for tilgang til Optimaliser kategori Office 365 endepunkter.

Det er en enkel løsning for å gjøre delt tunnelering, og det er en du bør gjøre. Hvis du vil ha mer informasjon, må du se gjennom Optimaliser Office 365 tilkobling for eksterne brukere ved hjelp av VPN-delt tunnelering.

Fortidens synder

Mange ganger kommer grunnen til at dårlige valg er gjort fra en kombinasjon av (1) uten å vite hvordan tjenesten fungerer, (2) prøver å følge selskapets policyer som ble skrevet før de tok i bruk skyen, og (3) sikkerhetsteam som kanskje ikke er lett overbevist om at det er mer enn én måte å oppnå sine mål på. Forhåpentligvis vil det ovennevnte, og koblingene nedenfor, hjelpe med den første. Executive sponsing kan være nødvendig for å komme forbi den andre. Adressering av sikkerhetspolicyenes mål, i stedet for deres metoder, hjelper med den tredje. Fra betinget tilgang til sensur av innhold, DLP til informasjonsbeskyttelse, endepunktvalidering til nulldagstrusler – ethvert sluttmål en rimelig sikkerhetspolicy kan ha, kan oppnås med det som er tilgjengelig i Office 365, og uten avhengighet av lokalt nettverksutstyr, tvunget VPN-tunneler og TLS-brudd og -inspeksjon.

Andre ganger kan ikke maskinvare som ble størrelsen og kjøpt før organisasjonen begynte å flytte til skyen, skaleres opp for å håndtere de nye trafikkmønstrene og belastningene. Hvis du virkelig må rute all trafikk gjennom ett enkelt utgående punkt, og/eller proxy, må du være forberedt på å oppgradere nettverksutstyr og båndbredde tilsvarende. Overvåk bruken nøye på begge, ettersom opplevelsen ikke vil avta sakte etter hvert som flere brukere om bord. Alt er bra til vippepunktet er nådd, så lider alle.

Unntak fra reglene

Hvis organisasjonen krever leierbegrensninger, må du bruke en proxy med TLS-brudd og undersøke for å tvinge trafikk gjennom proxyen, men du trenger ikke å tvinge all trafikk gjennom den. Det er ikke et alt eller ingenting forslag, så vær oppmerksom på hva som må endres av proxy.

Hvis du skal tillate delt tunnelering, men også bruke en proxy for generell nettrafikk, må du sørge for at PAC-filen definerer hva som må gå direkte, samt hvordan du definerer interessant trafikk for hva som går gjennom VPN-tunnelen. Vi tilbyr pac-eksempelfiler som https://aka.ms/ipaddrs gjør dette enklere å administrere.

Konklusjon

Titusenvis av organisasjoner, inkludert nesten alle Fortune 500, bruker Office 365 hver dag til sine driftskritiske funksjoner. De gjør det sikkert, og de gjør det via Internett.

Uansett hvilke sikkerhetsmål du har i spill, finnes det måter å oppnå dem på som ikke krever VPN-tilkoblinger, proxy-servere, TLS-brudd og undersøking, eller sentralisert utgående Internett for å få brukernes trafikk av nettverket og videre til vårt så raskt som mulig, noe som gir den beste ytelsen, uansett om nettverket er selskapets hovedkvarter, et eksternt kontor, eller den brukeren som arbeider hjemme. Veiledningen vår er basert på hvordan Office 365-tjenestene bygges og for å sikre en sikker og fungerende brukeropplevelse.