Netwerken (naar de cloud): het standpunt van één architect

Artikel
07/16/2023

In dit artikel beschrijft Ed Fisher, Security & Compliance Architect bij Microsoft, hoe u uw netwerk optimaliseert voor cloudconnectiviteit door de meest voorkomende valkuilen te vermijden.

Over de auteur

Schermopname van Ed Fisher-foto.

Ik ben momenteel principal technical specialist in ons retail- en consumer goods-team, dat zich richt op beveiliging & compliance. Ik heb de afgelopen tien jaar met klanten gewerkt die naar Office 365 zijn verhuisd. Ik heb gewerkt met kleinere winkels met een handvol locaties voor overheidsinstanties en ondernemingen met miljoenen gebruikers verspreid over de hele wereld, en veel andere klanten daartussen, waarbij de meerderheid tienduizenden gebruikers heeft, meerdere locaties in verschillende delen van de wereld, de behoefte aan een hogere mate van beveiliging en een groot aantal nalevingsvereisten. Ik heb honderden ondernemingen en miljoenen gebruikers geholpen bij het veilig overstappen naar de cloud.

Met een achtergrond in de afgelopen 25 jaar met onder andere beveiliging, infrastructuur en netwerktechniek, en nadat ik twee van mijn vorige werkgevers heb verplaatst naar Office 365 voordat ik bij Microsoft kwam, heb ik vaak aan uw kant van de tafel gestaan en weet ik hoe dat is. Hoewel geen twee klanten ooit hetzelfde zijn, hebben de meeste vergelijkbare behoeften en wanneer u een gestandaardiseerde service gebruikt, zoals een SaaS- of PaaS-platform, zijn de beste benaderingen meestal hetzelfde.

Het is niet het netwerk, het is hoe u het (verkeerd) gebruikt.

Hoe vaak het ook gebeurt, het verbaast me nooit hoe creatieve beveiligingsteams en netwerkteams proberen te krijgen met hoe ze denken dat ze verbinding moeten maken met Microsoft-cloudservices. Er is altijd een beveiligingsbeleid, nalevingsstandaard of een betere manier waarop ze willen gebruiken, zonder dat ze bereid zijn om een gesprek te voeren over wat ze proberen te bereiken, of hoe er betere, eenvoudigere, rendabelere en beter presterende manieren zijn om dit te doen.

Wanneer dit soort dingen naar mij escaleert, ben ik meestal bereid om de uitdaging aan te gaan en hen door het hoe en het waarom te leiden en ze te brengen waar ze moeten zijn. Maar als ik helemaal eerlijk ben, moet ik delen dat ik ze soms gewoon wil laten doen wat ze willen. Misschien wil ik dat soms doen, maar dat doe ik niet. Ik probeer alles uit te leggen wat ik in dit bericht ga opnemen. Ongeacht uw rol, als uw organisatie Microsoft-cloudservices wil gebruiken, is er waarschijnlijk enige wijsheid in wat volgt die u kan helpen.

Richtsnoeren

Laten we beginnen met enkele basisregels over wat we hier doen. We bespreken hoe u veilig verbinding kunt maken met cloudservices om de minimale complexiteit en de maximale prestaties te garanderen, met behoud van echte beveiliging. Niets van wat volgt, gaat daar niet tegen in, zelfs niet als u, of uw klant, uw favoriete proxyserver niet overal voor kunt gebruiken.

Alleen omdat je kan, betekent niet dat je moet: of om Dr. Ian Malcolm te parafraseren uit de Jurassic Park-film "... Ja, ja, maar je beveiligingsteam was zo bezig met het wel of niet kunnen, dat ze niet ophielden na te denken of ze het moesten doen.
Beveiliging betekent niet complexiteit: u bent niet veiliger omdat u meer geld uitgeeft, meer apparaten doorloopt of op meer knoppen klikt.
Office 365 is toegankelijk via internet: maar dat is niet hetzelfde als Office 365 internet is. Het is een SaaS-service die wordt beheerd door Microsoft en door u wordt beheerd. In tegenstelling tot websites die u op internet bezoekt, kunt u achter het gordijn kijken en kunt u de controles toepassen die u nodig hebt om te voldoen aan uw beleid en uw nalevingsstandaarden, zolang u maar begrijpt dat u uw doelstellingen kunt bereiken, maar u ze misschien op een andere manier moet doen.
Chokepoints zijn slecht, gelokaliseerde onderbrekingen zijn goed: iedereen wil altijd al het internetverkeer voor al zijn gebruikers terugleiden naar een centraal punt, meestal zodat ze het kunnen controleren en beleid kunnen afdwingen, maar vaak omdat het goedkoper is dan het inrichten van internettoegang op al hun locaties, of gewoon hoe ze het doen. Maar die chokepoints zijn precies dat... punten waar het verkeer verstikt. Er is niets mis met voorkomen dat uw gebruikers naar Instagram bladeren of catvideo's streamen, maar behandel uw bedrijfskritieke bedrijfstoepassingsverkeer niet op dezelfde manier.
Als DNS niet tevreden is, is het niet niets gelukkig: het best ontworpen netwerk kan worden verslepen door slechte DNS, of dat nu is door aanvragen te ontvangen naar servers in andere gebieden van de wereld of door de DNS-servers van uw internetprovider of andere openbare DNS-servers te gebruiken die DNS-omzettingsgegevens in de cache opslaan.
Omdat je het vroeger zo deed, betekent dat niet dat je het nu moet doen: technologie verandert voortdurend en Office 365 is geen uitzondering. Het toepassen van beveiligingsmaatregelen die zijn ontwikkeld en geïmplementeerd voor on-premises services of om surfen op het web te beheren, biedt niet hetzelfde beveiligingsniveau en kan een aanzienlijke negatieve invloed hebben op de prestaties.
Office 365 is gemaakt om toegankelijk te zijn via internet: dat is het in een notendop. Het maakt niet uit wat u wilt doen tussen uw gebruikers en uw edge, het verkeer gaat nog steeds via internet zodra het uw netwerk verlaat en voordat het op het onze komt. Zelfs als u Azure ExpressRoute gebruikt om latentiegevoelig verkeer rechtstreeks van uw netwerk naar het onze te routeren, is een internetverbinding absoluut vereist. Accepteer het. Denk er niet over na.

Waar vaak slechte keuzes worden gemaakt

Hoewel er tal van plaatsen zijn waar slechte beslissingen worden genomen in naam van beveiliging, zijn dit de plaatsen die ik het vaakst tegenkom bij klanten. Bij veel klantgesprekken worden deze allemaal tegelijk betrokken.

Onvoldoende resources aan de rand

Er zijn maar weinig klanten die greenfield-omgevingen implementeren en ze hebben jarenlange ervaring met hoe hun gebruikers werken en hoe hun internetuitgang eruitziet. Of klanten nu proxyservers hebben of directe toegang en gewoon uitgaand NAT-verkeer toestaan, ze doen dit al jaren en houden er niet rekening mee hoeveel meer ze door hun edge gaan pompen als ze traditioneel interne toepassingen naar de cloud verplaatsen.

Bandbreedte is altijd een probleem, maar NAT-apparaten hebben mogelijk niet genoeg vermogen om de verhoogde belasting te verwerken en kunnen voortijdig verbindingen sluiten om resources vrij te maken. De meeste clientsoftware die verbinding maakt met Office 365 verwacht permanente verbindingen en een gebruiker die volledig gebruikmaakt van Office 365 kan 32 of meer gelijktijdige verbindingen hebben. Als het NAT-apparaat deze voortijdig verwijdert, reageren deze apps mogelijk niet meer wanneer ze de verbindingen proberen te gebruiken die er niet meer zijn. Wanneer ze opgeven en nieuwe verbindingen tot stand brengen, wordt uw netwerk nog meer belast.

Gelokaliseerde onderbreking

Al het andere in deze lijst komt neer op één ding: zo snel mogelijk van uw netwerk naar het onze gaan. Het terugleiden van het verkeer van uw gebruikers naar een centraal uitgaand punt, met name wanneer dat uitgaand punt zich in een andere regio bevindt dan uw gebruikers zich bevinden, leidt tot onnodige latentie en heeft invloed op zowel de clientervaring als de downloadsnelheden. Microsoft heeft overal ter wereld aanwezigheidspunten met front-ends voor al onze services en peering met vrijwel elke grote internetprovider, zodat het verkeer van uw gebruikers lokaal wordt doorgestuurd, zodat het snel met minimale latentie in ons netwerk terechtkomt.

DNS-omzettingsverkeer moet het internetuitgangspad volgen

Natuurlijk moet een client DNS gebruiken om een eindpunt te vinden. De DNS-servers van Microsoft evalueren de bron van DNS-aanvragen om ervoor te zorgen dat we het antwoord retourneren dat, in internettermen, het dichtst bij de bron van de aanvraag ligt. Zorg ervoor dat uw DNS zo is geconfigureerd dat aanvragen voor naamomzetting hetzelfde pad hebben als het verkeer van uw gebruikers, zodat u ze geen lokaal uitgaand verkeer geeft, maar naar een eindpunt in een andere regio. Dat betekent dat lokale DNS-servers 'naar de hoofdmap gaan' in plaats van door te sturen naar DNS-servers in externe datacenters. En watch voor openbare en privé-DNS-services, die resultaten van een deel van de wereld in de cache kunnen opslaan en deze kunnen verwerken op aanvragen uit andere delen van de wereld.

Proxy of niet proxy, dat is de vraag

Een van de eerste dingen waar u rekening mee moet houden, is of de verbindingen van gebruikers met Office 365 moeten worden geproxydeert. Dat is makkelijk. proxy niet gebruiken. Office 365 is toegankelijk via internet, maar niet via internet. Het is een uitbreiding van uw kernservices en moet als zodanig worden behandeld. Alles wat u met een proxy wilt doen, zoals DLP of antimalware of inhoudsinspectie, is al beschikbaar in de service en kan op schaal worden gebruikt zonder dat tls-versleutelde verbindingen hoeven te worden gekraakt. Maar als u echt verkeer wilt proxyen dat u anders niet kunt beheren, let dan op onze richtlijnen bij https://aka.ms/pnc en de verkeerscategorieën op https://aka.ms/ipaddrs. We hebben drie categorieën verkeer voor Office 365. Optimaliseren en Toestaan moet echt direct gaan en uw proxy omzeilen. De standaardwaarde kan worden geproxied. De details staan in die documenten... lees ze.

De meeste klanten die erop staan een proxy te gebruiken, wanneer ze daadwerkelijk kijken naar wat ze doen, realiseren zich dat wanneer de client een HTTP CONNECT-aanvraag naar de proxy maakt, de proxy nu gewoon een dure extra router is. De protocollen die worden gebruikt, zoals MAPI en RTC, zijn niet eens protocollen die webproxy's begrijpen, dus zelfs met TLS-cracking krijgt u niet echt extra beveiliging. U krijgt* extra latentie. Zie https://aka.ms/pnc voor meer informatie hierover, waaronder de categorieën Optimaliseren, Toestaan en Standaard voor Microsoft 365-verkeer.

Houd ten slotte rekening met de algehele impact op de proxy en de bijbehorende reactie om die impact op te vangen. Naarmate er steeds meer verbindingen worden gemaakt via de proxy, kan de TCP-schaalfactor worden verlaagd, zodat deze niet zoveel verkeer hoeft te bufferen. Ik heb klanten gezien waar hun proxy's zo overbelast waren dat ze een schaalfactor van 0 gebruikten. Omdat Schaalfactor een exponentiële waarde is en we graag 8 gebruiken, heeft elke vermindering van de waarde schaalfactor een enorme negatieve invloed op de doorvoer.

TLS-inspectie betekent BEVEILIGING! Maar niet echt! Veel klanten met proxy's willen ze gebruiken om al het verkeer te inspecteren, en dat betekent tls 'onderbreken en inspecteren'. Wanneer u dat doet voor een website die wordt geopend via HTTPS (privacyproblemen ondanks), moet uw proxy dat mogelijk doen voor 10 of zelfs 20 gelijktijdige streams gedurende een paar honderd milliseconden. Als er een grote download is of misschien een video, kunnen een of meer van deze verbindingen veel langer duren, maar over het algemeen worden de meeste verbindingen heel snel tot stand gebracht, overgedragen en gesloten. Het uitvoeren van onderbrekingen en inspecteren betekent dat de proxy het dubbele van het werk moet doen. Voor elke verbinding van de client naar de proxy moet de proxy ook een afzonderlijke verbinding maken met het eindpunt. Dus, 1 wordt 2, 2 wordt 4, 32 wordt 64... zie waar ik heen ga? Waarschijnlijk hebt u de grootte van uw proxyoplossing prima voor normaal surfen op internet, maar wanneer u hetzelfde probeert te doen voor clientverbindingen met Office 365, kan het aantal gelijktijdige, langdurige verbindingen groter zijn dan waarvoor u de grootte hebt.

Streamen is niet belangrijk, behalve dat het

De enige services in Office 365 die gebruikmaken van UDP zijn Skype (binnenkort buiten gebruik gesteld) en Microsoft Teams. Teams gebruikt UDP voor het streamen van verkeer, waaronder audio, video en het delen van presentaties. Streamingverkeer is live, bijvoorbeeld wanneer u een onlinevergadering hebt met spraak, video en het presenteren van decks of het uitvoeren van demo's. Deze maken gebruik van UDP omdat als pakketten worden verwijderd of in de juiste volgorde aankomen, dit praktisch onmerkbaar is voor de gebruiker en de stream gewoon kan doorgaan.

Wanneer u uitgaand UDP-verkeer van clients naar de service niet toestaat, kunnen ze terugvallen op het gebruik van TCP. Maar als een TCP-pakket wordt verwijderd, stopt alles totdat de RTO (Retransmission Timeout) verloopt en het ontbrekende pakket opnieuw kan worden verzonden. Als een pakket niet in de juiste volgorde aankomt, stopt alles totdat de andere pakketten aankomen en opnieuw in de juiste volgorde kunnen worden gemonteerd. Beide leiden tot waarneembare haperingen in de audio (herinner je Max Headroom?) en video (heb je ergens op geklikt... Oh, daar is het) en leiden tot slechte prestaties en een slechte gebruikerservaring. En weet je nog wat ik hierboven heb gezegd over proxy's? Wanneer u een Teams-client dwingt om een proxy te gebruiken, dwingt u deze om TCP te gebruiken. Nu veroorzaakt u dus twee keer negatieve gevolgen voor de prestaties.

Split tunneling kan eng lijken

Maar dat is niet zo. Alle verbindingen met Office 365 zijn via TLS. We bieden TLS 1.2 al een tijdje aan en zullen binnenkort oudere versies uitschakelen omdat verouderde clients deze nog steeds gebruiken en dat is een risico.

Het afdwingen van een TLS-verbinding, of 32 daarvan, om via een VPN te gaan voordat ze vervolgens naar de service gaan, voegt geen beveiliging toe. Het voegt latentie toe en vermindert de totale doorvoer. In sommige VPN-oplossingen dwingt het UDP zelfs om via TCP te tunnelen, wat opnieuw een zeer negatieve invloed heeft op streamingverkeer. En, tenzij u TLS-inspectie uitvoert, is er geen upside, allemaal nadeel. Een veelvoorkomend thema onder klanten, nu het merendeel van hun werknemers op afstand is, is dat ze aanzienlijke gevolgen voor de bandbreedte en prestaties ondervinden van het maken van verbinding tussen alle gebruikers via een VPN, in plaats van split tunneling te configureren voor toegang tot de categorie Optimaliseren Office 365 eindpunten.

Het is een eenvoudige oplossing om split tunneling uit te voeren en het is een oplossing die u moet doen. Raadpleeg Office 365-connectiviteit optimaliseren voor externe gebruikers met vpn-split tunneling voor meer informatie.

De zonden van het verleden

Vaak komt de reden waarom er slechte keuzes worden gemaakt, voort uit een combinatie van (1) niet weten hoe de service werkt, (2) het naleven van bedrijfsbeleid dat is geschreven voordat de cloud werd aangenomen, en (3) beveiligingsteams die misschien niet gemakkelijk kunnen worden overtuigd dat er meer dan één manier is om hun doelen te bereiken. Hopelijk helpen het bovenstaande en de onderstaande koppelingen bij de eerste. Executive sponsorship kan nodig zijn om voorbij de tweede te komen. Het bereiken van de doelstellingen van het beveiligingsbeleid, in plaats van hun methoden, helpt bij de derde. Van voorwaardelijke toegang tot inhoudsbeheer, DLP tot informatiebeveiliging, eindpuntvalidatie tot zero-day-bedreigingen: elk einddoel dat een redelijk beveiligingsbeleid kan hebben, kan worden bereikt met wat beschikbaar is in Office 365, en zonder enige afhankelijkheid van on-premises netwerkapparatuur, geforceerde VPN-tunnels en TLS-onderbrekingen en -inspectie.

Andere keren kan hardware die was aangepast en aangeschaft voordat de organisatie naar de cloud ging, eenvoudigweg niet omhoog worden geschaald om de nieuwe verkeerspatronen en belasting te verwerken. Als u echt al het verkeer via één uitgaand punt en/of proxy moet routeren, moet u erop voorbereid zijn om de netwerkapparatuur en bandbreedte dienovereenkomstig te upgraden. Bewaak het gebruik van beide zorgvuldig, omdat de ervaring niet langzaam afneemt naarmate meer gebruikers onboarden. Alles gaat goed totdat het kantelpunt is bereikt, dan lijdt iedereen.

Uitzonderingen op de regels

Als uw organisatie tenantbeperkingen vereist, moet u een proxy met TLS-onderbreking gebruiken en inspecteren om verkeer via de proxy af te dwingen, maar u hoeft niet al het verkeer erdoor te dwingen. Het is geen alles of niets voorstel, dus let op wat er moet worden gewijzigd door de proxy.

Als u split tunneling wilt toestaan, maar ook een proxy gebruikt voor algemeen webverkeer, moet u ervoor zorgen dat uw PAC-bestand definieert wat direct moet gaan en hoe u interessant verkeer definieert voor wat door de VPN-tunnel gaat. We bieden voorbeelden van PAC-bestanden aan, https://aka.ms/ipaddrs waardoor dit eenvoudiger te beheren is.

Conclusie

Tienduizenden organisaties, waaronder bijna alle Fortune 500, gebruiken dagelijks Office 365 voor hun bedrijfskritieke functies. Dat doen ze veilig en via internet.

Ongeacht welke beveiligingsdoelen u in het spel hebt, er zijn manieren om deze te bereiken waarvoor geen VPN-verbindingen, proxyservers, TLS-onderbrekingen en -inspectie of gecentraliseerde internetuitgang nodig zijn om het verkeer van uw gebruikers zo snel mogelijk van uw netwerk en naar het onze te krijgen, wat de beste prestaties biedt, ongeacht of uw netwerk het hoofdkantoor van het bedrijf is, een extern kantoor of een gebruiker die thuis werkt. Onze richtlijnen zijn gebaseerd op hoe de Office 365-services worden gebouwd en om een veilige en performante gebruikerservaring te garanderen.