Nätverk och anslutning för verksamhetskritiska arbetsbelastningar i Azure

Nätverk är ett grundläggande område för ett verksamhetskritiskt program, med tanke på den rekommenderade globalt distribuerade aktiva-aktiva designmetoden.

Det här designområdet utforskar olika avsnitt om nätverkstopologi på programnivå, med tanke på nödvändiga anslutningar och redundant trafikhantering. Mer specifikt belyser den viktiga överväganden och rekommendationer som är avsedda att ligga till grund för utformningen av en säker och skalbar global nätverkstopologi för ett verksamhetskritiskt program.

Viktigt!

Den här artikeln är en del av den verksamhetskritiska arbetsbelastningsserien Azure Well-Architected. Om du inte är bekant med den här serien rekommenderar vi att du börjar med vad som är en verksamhetskritisk arbetsbelastning?

Global trafikroutning

Användning av flera aktiva regionala distributionsstämplar kräver en global routningstjänst för att distribuera trafik till varje aktiv stämpel.

Azure Front Door, Azure Traffic Manager och Azure Standard Load Balancer tillhandahåller de routningsfunktioner som krävs för att hantera global trafik i ett program med flera regioner.

Alternativt kan du överväga teknik för global routning från tredje part. De här alternativen kan nästan sömlöst växlas in för att ersätta eller utöka användningen av Azure-interna globala routningstjänster. Populära alternativ är routningstekniker från CDN-leverantörer.

I det här avsnittet beskrivs de viktigaste skillnaderna i Azure-routningstjänster för att definiera hur var och en kan användas för att optimera olika scenarier.

Utformningsbeaktanden

• En routningstjänst som är bunden till en enda region representerar en enskild felpunkt och en betydande risk för regionala avbrott.

• Om programarbetsbelastningen omfattar klientkontroll, till exempel med mobila eller stationära klientprogram, är det möjligt att tillhandahålla tjänstredundans inom klientroutningslogik.

  • Flera globala routningstekniker, till exempel Azure Front Door och Azure Traffic Manager, kan övervägas parallellt för redundans, med klienter som är konfigurerade att redundansväxla till en alternativ teknik när vissa felvillkor uppfylls. Introduktionen av flera globala routningstjänster medför betydande komplexitet kring funktioner för cachelagring av kanter och brandväggar för webbprogram samt certifikathantering för SSL-avlastning och programvalidering för inkommande sökvägar.
  • Tekniker från tredje part kan också övervägas, vilket ger global routningsåterhämtning till alla nivåer av Azure-plattformsfel.

• Kapacitetsskillnader mellan Azure Front Door och Traffic Manager innebär att om de två teknikerna placeras bredvid varandra för redundans krävs en annan ingressväg eller designändringar för att säkerställa att en konsekvent och acceptabel servicenivå upprätthålls.

• Azure Front Door och Azure Traffic Manager är globalt distribuerade tjänster med inbyggd redundans och tillgänglighet i flera regioner.

  • Hypotetiska felscenarier med en skala som är tillräckligt stor för att hota den globala tillgängligheten för dessa motståndskraftiga routningstjänster utgör en bredare risk för programmet när det gäller sammanhängande och korrelerade fel.
    • Felscenarier av den här skalan orsakas endast av delade grundläggande tjänster, till exempel Azure DNS eller Microsoft Entra ID, som fungerar som globala plattformsberoenden för nästan alla Azure-tjänster. Om en redundant Azure-teknik tillämpas är det troligt att den sekundära tjänsten också kommer att uppleva otillgänglighet eller en degraderad tjänst.
    • Scenarier med globala routningstjänstfel kommer med stor sannolikhet att avsevärt påverka många andra tjänster som används för viktiga programkomponenter via beroenden mellan tjänster. Även om en teknik från tredje part används kommer programmet sannolikt att vara i ett feltillstånd på grund av den bredare effekten av det underliggande problemet, vilket innebär att routning till programslutpunkter i Azure ger lite värde ändå.

• Global routningstjänstredundans ger en åtgärd för ett extremt litet antal hypotetiska felscenarier, där effekten av ett globalt avbrott är begränsad till själva routningstjänsten.

  För att ge bredare redundans till globala avbrottsscenarier kan du överväga en aktiv-aktiv distributionsmetod för flera moln. En multimolnbaserad aktiv-aktiv distributionsmetod medför betydande driftskomplexiteter, vilket utgör betydande återhämtningsrisker, vilket sannolikt vida överväger de hypotetiska riskerna med ett globalt avbrott.

• För scenarier där klientkontroll inte är möjlig måste ett beroende tas på en enda global routningstjänst för att tillhandahålla en enhetlig startpunkt för alla aktiva distributionsregioner.

  • När de används isolerat representerar de en enskild felpunkt på tjänstnivå på grund av globala beroenden, även om inbyggd redundans och tillgänglighet för flera regioner tillhandahålls.
  • Serviceavtalet som tillhandahålls av den valda globala routningstjänsten representerar det maximala uppnåeliga sammansatta SLO:t, oavsett hur många distributionsregioner som övervägs.

• När klientkontroll inte är möjlig kan operativa åtgärder anses definiera en process för migrering till en sekundär global routningstjänst om ett globalt avbrott inaktiverar den primära tjänsten. Att migrera från en global routningstjänst till en annan är vanligtvis en lång process som varar i flera timmar, särskilt när DNS-spridning beaktas.

• Vissa globala routningstjänster från tredje part tillhandahåller ett serviceavtal på 100 %. Det historiska och uppnåeliga serviceavtalet som tillhandahålls av dessa tjänster är dock vanligtvis lägre än 100 %.

  • Även om dessa tjänster ger ekonomiska skadestånd för otillgänglighet, kommer det av liten betydelse när effekterna av otillgänglighet är betydande, till exempel med säkerhetskritiska scenarier där mänskligt liv i slutändan står på spel. Teknikredundans eller tillräckliga åtgärdsåtgärder bör därför fortfarande övervägas även när det annonserade juridiska serviceavtalet är 100 %.

Azure Front Door

• Azure Front Door tillhandahåller global HTTP/S-belastningsutjämning och optimerad anslutning med hjälp av Anycast-protokollet med delad TCP för att dra nytta av Microsofts globala stamnätverk.

  • Ett antal anslutningar underhålls för var och en av serverdelsslutpunkterna.
  • Inkommande klientbegäranden avslutas först vid den gränsnod som är närmast den ursprungliga klienten.
  • Efter nödvändig trafikkontroll vidarebefordras begäranden antingen via Microsofts stamnät till rätt serverdel med befintliga anslutningar eller hanteras från den interna cachen för en kantnod.
  • Den här metoden är effektiv när det gäller att sprida stora trafikvolymer över serverdelsanslutningarna.

• Tillhandahåller en inbyggd cache som hanterar statiskt innehåll från kantnoder. I många användningsfall kan detta också eliminera behovet av ett dedikerat nätverk för innehållsleverans (CDN).

• Azure Web Application Firewall (WAF) kan användas på Azure Front Door, och eftersom den distribueras till Azure-nätverksgränsplatser runt om i världen, inspekteras varje inkommande begäran som levereras av Front Door vid nätverksgränsen.

• Azure Front Door skyddar programslutpunkter mot DDoS-attacker med Azure DDoS Protection Basic. Azure DDoS Standard ger ytterligare och mer avancerade skydds- och identifieringsfunktioner och kan läggas till som ytterligare ett lager i Azure Front Door.

• Azure Front Door erbjuder en fullständigt hanterad certifikattjänst. Aktiverar TLS-anslutningssäkerhet för slutpunkter utan att behöva hantera certifikatets livscykel.

• Azure Front Door Premium stöder privata slutpunkter, vilket gör att trafik kan flöda från Internet direkt till virtuella Azure-nätverk. Detta skulle eliminera behovet av att använda offentliga IP-adresser på det virtuella nätverket för att göra serverdelarna tillgängliga via Azure Front Door Premium.

• Azure Front Door förlitar sig på hälsoavsökningar och slutpunkter för serverdelshälsa (URL:er) som anropas på intervallbasis för att returnera en HTTP-statuskod som återspeglar om serverdelen fungerar normalt, med ett HTTP 200-svar (OK) som återspeglar en felfri status. Så snart en serverdel visar en status som inte är felfri slutar gränsnoden att skicka begäranden dit från en viss kantnods perspektiv. Felaktiga serverdelar tas därför transparent bort från trafikcirkulationen utan fördröjning.

• Stöder endast HTTP/S-protokoll.

• Azure Front Door WAF och Application Gateway WAF ger en något annorlunda funktionsuppsättning, men både stöder inbyggda och anpassade regler och kan ställas in för att fungera i antingen identifieringsläge eller förebyggande läge.

• Front Door-serverdelens IP-utrymme kan ändras, men Microsoft säkerställer integrering med Azure IP-intervall och tjänsttaggar. Det är möjligt att prenumerera på Azure IP-intervall och tjänsttaggar för att ta emot meddelanden om ändringar eller uppdateringar.

• Azure Front Door har stöd för olika belastningsdistributionskonfigurationer:

  • Svarstidsbaserad: standardinställningen som dirigerar trafik till den "närmaste" serverdelen från klienten. baserat på svarstid för begäran.
  • Prioritetsbaserad: användbar för aktiv-passiva installationer, där trafik alltid måste skickas till en primär serverdel om den inte är tillgänglig.
  • Viktad: gäller för kanariedistributioner där en viss procentandel av trafiken skickas till en specifik serverdel. Om flera serverdelar har samma vikter tilldelade används svarstidsbaserad routning.

• Som standard använder Azure Front Door svarstidsbaserad routning som kan leda till situationer där vissa serverdelar får mycket mer inkommande trafik än andra, beroende på var klienterna kommer ifrån.

• Om en serie klientbegäranden måste hanteras av samma serverdel kan sessionstillhörighet konfigureras på klientdelen. Den använder en cookie på klientsidan för att skicka efterföljande begäranden till samma serverdel som den första begäran, förutsatt att serverdelen fortfarande är tillgänglig.

Azure Traffic Manager

• Azure Traffic Manager är en DNS-omdirigeringstjänst.

  • Den faktiska nyttolasten för begäran bearbetas inte, men i stället returnerar Traffic Manager DNS-namnet på en av serverdelarna som poolen har, baserat på konfigurerade regler för den valda trafikroutningsmetoden.
  • Serverdelens DNS-namn matchas sedan till den slutliga IP-adressen som sedan anropas direkt av klienten.

• DNS-svaret cachelagras och återanvänds av klienten under en angiven TTL-period (Time-To-Live), och begäranden som görs under den här perioden går direkt till serverdelsslutpunkten utan Traffic Manager-interaktion. Eliminerar det extra anslutningssteget som ger kostnadsfördelar jämfört med Front Door.

• Eftersom begäran görs direkt från klienten till serverdelstjänsten kan alla protokoll som stöds av serverdelen utnyttjas.

• Precis som i Azure Front Door förlitar sig Azure Traffic Manager också på hälsoavsökningar för att förstå om en serverdel är felfri och fungerar normalt. Om ett annat värde returneras eller inget returneras identifierar routningstjänsten pågående problem och stoppar routningsbegäranden till den specifika serverdelen.

  • Men till skillnad från Med Azure Front Door är den här borttagningen av felaktiga serverdelar inte omedelbar eftersom klienter fortsätter att skapa anslutningar till den felaktiga serverdelen tills DNS TTL upphör att gälla och en ny serverdelsslutpunkt begärs från Traffic Manager-tjänsten.
  • Även när TTL upphör att gälla finns det dessutom ingen garanti för att offentliga DNS-servrar respekterar det här värdet, så DNS-spridning kan faktiskt ta mycket längre tid att utföra. Det innebär att trafiken kan fortsätta att skickas till den felaktiga slutpunkten under en längre tidsperiod.

Azure Standard Load Balancer

Viktigt!

Standardlastbalanserare mellan regioner är tillgänglig i förhandsversion med tekniska begränsningar. Det här alternativet rekommenderas inte för verksamhetskritiska arbetsbelastningar.

Designrekommendationer

• Använd Azure Front Door som den primära globala trafikroutningstjänsten för HTTP/S-scenarier. Azure Front Door är starkt förespråkat för HTTP/S-arbetsbelastningar eftersom det ger optimerad trafikroutning, transparent redundans, privata serverdelsslutpunkter (med Premium SKU), gränscachelagring och integrering med Web Application Firewall (WAF).

• För programscenarier där klientkontroll är möjlig använder du routningslogik på klientsidan för att överväga redundansscenarier där den primära globala routningstekniken misslyckas. Två eller flera globala routningstekniker bör placeras parallellt för extra redundans, om serviceavtalet för enskilda tjänster inte räcker. Klientlogik krävs för att dirigera till den redundanta tekniken i händelse av ett globalt tjänstfel.

  • Två distinkta URL:er bör användas, där en tillämpas på var och en av de olika globala routningstjänsterna för att förenkla den övergripande certifikathanteringsmiljön och routningslogik för en redundansväxling.
  • Prioritera användningen av routningstekniker från tredje part som sekundär redundanstjänst, eftersom detta minskar det största antalet globala felscenarier och de funktioner som erbjuds av branschledande CDN-leverantörer möjliggör en konsekvent designmetod.
  • Man bör också tänka på direkt routning till en enda regional stämpel i stället för en separat routningstjänst. Även om detta resulterar i en försämrad tjänstnivå representerar det en mycket enklare designmetod.

Den här avbildningen visar en redundant global lastbalanserare med klientredundans med Azure Front Door som primär global lastbalanserare.

Viktigt!

För att verkligen minska risken för globala fel på Azure-plattformen bör du överväga en aktiv-aktiv distributionsmetod för flera moln, med aktiva distributionsstämplar som finns i två eller flera molnleverantörer och redundanta routningstekniker från tredje part som används för global routning.

Azure kan effektivt integreras med andra molnplattformar. Vi rekommenderar dock starkt att du inte tillämpar en multimolnmetod eftersom den medför betydande driftskomplexitet, med olika definitioner av distributionsstämpel och representationer av drifthälsa på de olika molnplattformarna. Denna komplexitet i sin tur medför många återhämtningsrisker inom programmets normala drift, vilket vida uppväger de hypotetiska riskerna med ett globalt plattformsfel.

• Även om det inte rekommenderas för HTTP-arbetsbelastningar som använder Azure Traffic Manager för global routningsredundans till Azure Front Door kan du överväga att avlasta Brandvägg för webbaserade program (WAF) till Application Gateway för acceptabel trafik som flödar via Azure Front Door.
  • Detta medför ytterligare en felpunkt för standardsökvägen, en ytterligare komponent för kritisk sökväg för hantering och skalning, och medför även ytterligare kostnader för att säkerställa global hög tillgänglighet. Det förenklar dock felscenariot avsevärt genom att ge konsekvens mellan de acceptabla och inte acceptabla ingressvägarna via Azure Front Door och Azure Traffic Manager, både när det gäller WAF-körning men även privata programslutpunkter.
  • Förlusten av cachelagring av gränsen i ett felscenario påverkar den övergripande prestandan, och detta måste justeras med en acceptabel tjänstnivå eller en mildrande designmetod. För att säkerställa en konsekvent tjänstnivå bör du överväga att avlasta edge-cachelagring till en CDN-provider från tredje part för båda sökvägarna.

Vi rekommenderar att du överväger en global routningstjänst från tredje part i stället för två globala Routningstjänster i Azure. Detta ger den maximala nivån av felreducering och en enklare designmetod eftersom de flesta branschledande CDN-leverantörer erbjuder gränsfunktioner som till stor del överensstämmer med den som erbjuds av Azure Front Door.

Azure Front Door

• Använd azure Front Door-hanterade certifikattjänsten för att aktivera TLS-anslutningar och ta bort behovet av att hantera certifikatlivscykler.

• Använd Azure Front Door Web Application Firewall (WAF) för att ge skydd vid gränsen mot vanliga webbexploateringar och sårbarheter, till exempel SQL-inmatning.

• Använd den inbyggda Azure Front Door-cachen för att hantera statiskt innehåll från kantnoder.

  • I de flesta fall eliminerar detta också behovet av ett dedikerat nätverk för innehållsleverans (CDN).

• Konfigurera programplattformens ingresspunkter för att verifiera inkommande begäranden via rubrikbaserad filtrering med X-Azure-FDID för att säkerställa att all trafik flödar genom den konfigurerade Front Door-instansen. Överväg även att konfigurera IP-ACL med hjälp av Front Door-tjänsttaggar för att verifiera trafik som kommer från Azure Front Door-serverdelens IP-adressutrymme och Azure-infrastrukturtjänster. Detta säkerställer att trafiken flödar via Azure Front Door på tjänstnivå, men rubrikbaserad filtrering krävs fortfarande för att säkerställa användningen av en konfigurerad Front Door-instans.

• Definiera en anpassad TCP-hälsoslutpunkt för att validera kritiska underordnade beroenden inom en regional distributionsstämpel, inklusive dataplattformsrepliker, till exempel Azure Cosmos DB i exemplet som tillhandahålls av den grundläggande referensimplementeringen. Om ett eller flera beroenden blir felaktiga bör hälsoavsökningen återspegla detta i svaret som returneras så att hela den regionala stämpeln kan tas ur omlopp.

• Se till att hälsoavsökningssvar loggas och mata in alla driftdata som exponeras av Azure Front Door i den globala Log Analytics-arbetsytan för att underlätta en enhetlig datamottagare och en enda driftvy i hela programmet.

• Om inte arbetsbelastningen är extremt svarstidskänslig sprider du trafiken jämnt över alla som anses vara regionala stämplar för att använda distribuerade resurser på ett effektivast sätt.

  • För att uppnå detta anger du parametern "Svarstidskänslighet (ytterligare svarstid)" till ett värde som är tillräckligt högt för att tillgodose svarstidsskillnader mellan de olika regionerna i serverdelarna. Se till att det finns en tolerans som är acceptabel för programarbetsbelastningen när det gäller den övergripande svarstiden för klientbegäran.

• Aktivera inte sessionstillhörighet om det inte krävs av programmet, eftersom det kan ha en negativ inverkan på trafikfördelningens balans. Med ett helt tillståndslöst program kan alla begäranden hanteras av någon av de regionala distributionerna om den rekommenderade verksamhetskritiska programdesignmetoden följs.

Azure Traffic Manager

• Använd Traffic Manager för icke HTTP/S-scenarier som ersättning till Azure Front Door. Funktionsskillnader påverkar olika designbeslut för cache- och WAF-funktioner och TLS-certifikathantering.

• WAF-funktioner bör beaktas inom varje region för Traffic Manager-ingresssökvägen med hjälp av Azure Application Gateway.

• Konfigurera ett lämpligt lågt TTL-värde för att optimera den tid som krävs för att ta bort en felaktig serverdelsslutpunkt från cirkulationen i händelse av att serverdelen blir felaktig.

• På samma sätt som med Azure Front Door bör en anpassad TCP-hälsoslutpunkt definieras för att verifiera kritiska underordnade beroenden inom en regional distributionsstämpel, vilket bör återspeglas i svaret från hälsoslutpunkter.

  För Traffic Manager bör dock ytterligare hänsyn tas till regional redundans på servicenivå. till exempel "dog legging", för att minska den potentiella fördröjningen i samband med borttagning av en felaktig serverdel på grund av beroendefel, särskilt om det inte är möjligt att ange en låg TTL för DNS-poster.

• Du bör tänka på CDN-leverantörer från tredje part för att uppnå cachelagring av gränsen när du använder Azure Traffic Manager som en primär global routningstjänst. Om edge WAF-funktioner också erbjuds av tjänsten från tredje part bör du överväga att förenkla ingresssökvägen och eventuellt ta bort behovet av Application Gateway.

Tjänster för programleverans

Nätverkets ingresssökväg för ett verksamhetskritiskt program måste också överväga tjänster för programleverans för att säkerställa säker, tillförlitlig och skalbar inkommande trafik.

Det här avsnittet bygger på rekommendationer för global routning genom att utforska viktiga funktioner för programleverans, med tanke på relevanta tjänster som Azure Standard Load Balancer, Azure Application Gateway och Azure API Management.

Utformningsbeaktanden

• TLS-kryptering är viktigt för att säkerställa integriteten för inkommande användartrafik till ett verksamhetskritiskt program, där TLS-avlastning endast tillämpas vid tidpunkten för en stämpels ingress för att dekryptera inkommande trafik. TLS-avlastning Kräver den privata nyckeln för TLS-certifikatet för att dekryptera trafik.

• En brandvägg för webbprogram ger skydd mot vanliga webbexploateringar och sårbarheter, till exempel SQL-inmatning eller skript mellan webbplatser, och är viktigt för att uppnå maximal tillförlitlighet för ett verksamhetskritiskt program.

• Azure WAF ger ett out-of-the-box-skydd mot de 10 främsta OWASP-sårbarheterna med hjälp av hanterade regeluppsättningar.

  • Anpassade regler kan också läggas till för att utöka den hanterade regeluppsättningen.
  • Azure WAF kan aktiveras i antingen Azure Front Door, Azure Application Gateway eller Azure CDN (för närvarande i offentlig förhandsversion).
    • Funktionerna som erbjuds på var och en av tjänsterna skiljer sig något. Azure Front Door WAF tillhandahåller till exempel hastighetsbegränsning, geofiltrering och robotskydd, som ännu inte erbjuds i Application Gateway WAF. De stöder dock alla både inbyggda och anpassade regler och kan ställas in för att fungera i identifieringsläge eller förebyggande läge.
    • Översikten för Azure WAF säkerställer att en konsekvent WAF-funktionsuppsättning tillhandahålls för alla tjänstintegreringar.

• WAF-tekniker från tredje part, till exempel NVA:er och avancerade ingresskontrollanter i Kubernetes, kan också anses ge säkerhetsriskskydd som är nödvändiga.

• Optimal WAF-konfiguration kräver vanligtvis finjustering, oavsett vilken teknik som används.

  Azure Front Door

• Azure Front Door accepterar endast HTTP- och HTTPS-trafik och bearbetar endast begäranden med ett känt Host huvud. Den här protokollblockeringen hjälper till att minimera volymattacker som sprids över protokoll och portar samt DNS-förstärkning och TCP-förgiftningsattacker.

• Azure Front Door är en global Azure-resurs så konfigurationen distribueras globalt till alla gränsplatser.

  • Resurskonfigurationen kan distribueras i stor skala för att hantera hundratusentals begäranden per sekund.
  • Uppdateringar av konfigurationen, inklusive vägar och serverdelspooler, är sömlösa och orsakar inte avbrott under distributionen.

• Azure Front Door tillhandahåller både en fullständigt hanterad certifikattjänst och en bring-your-own-certificate-metod för de klientriktade SSL-certifikaten. Den fullständigt hanterade certifikattjänsten ger en förenklad driftsmetod och hjälper till att minska komplexiteten i den övergripande designen genom att utföra certifikathantering inom ett enda område i lösningen.

• Azure Front Door roterar automatiskt "hanterade" certifikat minst 60 dagar före certifikatets giltighetstid för att skydda mot utgångna certifikatrisker. Om självhanterade certifikat används ska uppdaterade certifikat distribueras senast 24 timmar innan det befintliga certifikatet upphör att gälla, annars kan klienterna få fel med utgångna certifikat.

• Certifikatuppdateringar resulterar endast i stilleståndstid om Azure Front Door växlas mellan "Hanterat" och "Använd ditt eget certifikat".

• Azure Front Door skyddas av Azure DDoS Protection Basic, som är integrerat i Front Door som standard. Detta ger alltid på trafikövervakning, realtidsreducering och skyddar även mot vanliga Layer 7 DNS-frågeöversvämmningar eller layer 3/4-volymer.

  • Dessa skydd hjälper till att upprätthålla Azure Front Door-tillgänglighet även när du utsätts för en DDoS-attack. DDoS-attacker (Distributed Denial of Service) kan göra en målresurs otillgänglig genom att överbelasta den med illegitim trafik.

• Azure Front Door tillhandahåller även WAF-funktioner på global trafiknivå, medan Application Gateway WAF måste tillhandahållas inom varje regional distributionsstämpel. Funktionerna omfattar brandväggsregler som skyddar mot vanliga attacker, geofiltrering, adressblockering, hastighetsbegränsning och signaturmatchning.

  Azure Load Balancer

• Azure Basic Load Balancer SKU backas inte upp av ett serviceavtal och har flera kapacitetsbegränsningar jämfört med Standard SKU.

Designrekommendationer

• Utför TLS-avlastning på så få platser som möjligt för att upprätthålla säkerheten samtidigt som du förenklar livscykeln för certifikathantering.

• Använd krypterade anslutningar (t.ex. HTTPS) från den punkt där TLS-avlastning sker till de faktiska programserverdelarna. Programslutpunkter visas inte för slutanvändare, så Azure-hanterade domäner, till exempel azurewebsites.net eller cloudapp.net, kan användas med hanterade certifikat.

• För HTTP(S)-trafik kontrollerar du att WAF-funktionerna tillämpas i ingresssökvägen för alla offentligt exponerade slutpunkter.

• Aktivera WAF-funktioner på en enda tjänstplats, antingen globalt med Azure Front Door eller regionalt med Azure Application Gateway, eftersom detta förenklar konfigurationens finjustering och optimerar prestanda och kostnader.

  Konfigurera WAF i förebyggande läge för att direkt blockera attacker. Använd endast WAF i identifieringsläge (dvs. endast loggning men inte blockera misstänkta begäranden) när prestandastraffet för förebyggande läge är för högt. Den underförstådda ytterligare risken måste vara helt förstådd och anpassad till de specifika kraven i arbetsbelastningsscenariot.

• Prioritera användningen av Azure Front Door WAF eftersom det ger den rikaste Azure-inbyggda funktionsuppsättningen och tillämpar skydd på den globala gränsen, vilket förenklar den övergripande designen och ökar effektiviteten.

• Använd endast Azure API Management när du exponerar ett stort antal API:er för externa klienter eller olika programteam.

• Använd Azure Standard Load Balancer SKU för alla interna trafikdistributionsscenarion inom mikrotjänstarbetsbelastningar.

  • Tillhandahåller ett serviceavtal på 99,99 % när det distribueras mellan tillgänglighetszoner.
  • Tillhandahåller viktiga funktioner som diagnostik eller regler för utgående trafik.

• Använd Azure DDoS Network Protection för att skydda offentliga slutpunkter som finns i varje virtuellt programnätverk.

Cachelagring och leverans av statiskt innehåll

Särskild behandling av statiskt innehåll som bilder, JavaScript, CSS och andra filer kan ha en betydande inverkan på den övergripande användarupplevelsen samt på den totala kostnaden för lösningen. Cachelagring av statiskt innehåll vid gränsen kan påskynda klientbelastningstiderna, vilket ger en bättre användarupplevelse och kan också minska kostnaden för trafik, läsåtgärder och databehandlingskraft på berörda serverdelstjänster.

Utformningsbeaktanden

• Allt innehåll som en lösning gör tillgängligt via Internet genereras inte dynamiskt. Program hanterar både statiska tillgångar (bilder, JavaScript, CSS, lokaliseringsfiler osv.) och dynamiskt innehåll.
• Arbetsbelastningar med statiskt innehåll som används ofta drar stor nytta av cachelagring eftersom det minskar belastningen på serverdelstjänster och minskar svarstiden för innehållsåtkomst för slutanvändare.
• Cachelagring kan implementeras internt i Azure med antingen Azure Front Door eller Azure Content Delivery Network (CDN).
  • Azure Front Door tillhandahåller azure-inbyggda cachelagringsfunktioner och routningsfunktioner för att dela upp statiskt och dynamiskt innehåll.
    • Genom att skapa lämpliga routningsregler i Azure Front Door /static/* kan trafiken omdirigeras transparent till statiskt innehåll.
  • Mer komplexa cachelagringsscenarier kan implementeras med hjälp av Azure CDN-tjänsten för att upprätta ett fullständigt nätverk för innehållsleverans för betydande statiska innehållsvolymer.
    • Azure CDN-tjänsten kommer sannolikt att vara mer kostnadseffektiv, men tillhandahåller inte samma avancerade routnings- och waf-funktioner (Web Application Firewall) som rekommenderas för andra områden i en programdesign. Det ger dock ytterligare flexibilitet att integrera med liknande tjänster från tredjepartslösningar, till exempel Akamai och Verizon.
  • När du jämför Azure Front Door- och Azure CDN-tjänsterna bör följande beslutsfaktorer utforskas:
    • Kan nödvändiga cachelagringsregler utföras med hjälp av regelmotorn.
    • Storleken på det lagrade innehållet och den associerade kostnaden.
    • Pris per månad för körningen av regelmotorn (debiteras per begäran på Azure Front Door).
    • Krav på utgående trafik (priset varierar beroende på mål).

Designrekommendationer

• Genererat statiskt innehåll som storleksanpassade kopior av bildfiler som aldrig eller bara sällan ändras kan också dra nytta av cachelagring. Cachelagring kan konfigureras baserat på URL-parametrar och med varierande cachelagringstid.
• Separera leveransen av statiskt och dynamiskt innehåll till användare och leverera relevant innehåll från en cache för att minska belastningen på serverdelstjänster för att optimera prestanda för slutanvändare.
• Med tanke på den starka rekommendationen (nätverks- och anslutningsdesignområdet ) att använda Azure Front Door för global routning och WEB Application Firewall (WAF) rekommenderar vi att du prioriterar användningen av Azure Front Door-cachelagringsfunktioner om det inte finns luckor.

Virtual Network-integration

Ett verksamhetskritiskt program omfattar vanligtvis krav för integrering med andra program eller beroende system, som kan finnas i Azure, ett annat offentligt moln eller lokala datacenter. Den här programintegrering kan utföras med offentliga slutpunkter och Internet eller privata nätverk via nätverksnivåintegrering. I slutändan kommer metoden med vilken programintegrering uppnås att ha en betydande inverkan på lösningens säkerhet, prestanda och tillförlitlighet och påverkar designbeslut inom andra designområden.

Ett verksamhetskritiskt program kan distribueras inom en av tre övergripande nätverkskonfigurationer, som avgör hur programintegrering kan ske på nätverksnivå.

1. Offentligt program utan företagsnätverksanslutning.
2. Offentligt program med företagsnätverksanslutning.
3. Privat program med företagsnätverksanslutning.

Varning

När du distribuerar i en Azure-landningszon, konfiguration 1. bör distribueras i en onlinelandningszon, medan både 2) och 3) ska distribueras inom en Corp. Ansluten landningszon för att underlätta integrering på nätverksnivå.

I det här avsnittet går vi igenom de här scenarierna för nätverksintegrering, lager i lämplig användning av Azure Virtual Networks och omgivande Azure-nätverkstjänster för att säkerställa att integreringskraven uppfylls optimalt.

Designöverväganden

Inga virtuella nätverk

• Den enklaste designmetoden är att inte distribuera programmet i ett virtuellt nätverk.

  • Anslutningen mellan alla Azure-tjänster som anses vara övervägd tillhandahålls helt och hållet via offentliga slutpunkter och Microsoft Azure-stamnätet. Anslutningen mellan offentliga slutpunkter som finns i Azure passerar bara Microsofts stamnät och går inte via det offentliga Internet.
  • Anslutning till externa system utanför Azure tillhandahålls av det offentliga Internet.

• Den här designmetoden använder "identitet som en säkerhetsperimeter" för att ge åtkomstkontroll mellan de olika tjänstkomponenterna och den beroende lösningen. Detta kan vara en acceptabel lösning för scenarier som är mindre säkerhetskänsliga. Alla programtjänster och beroenden är tillgängliga via en offentlig slutpunkt, vilket gör dem sårbara för ytterligare attackvektorer som är inriktade på att få obehörig åtkomst.

• Den här designmetoden gäller inte heller för alla Azure-tjänster, eftersom många tjänster, till exempel AKS, har ett hårt krav för ett underliggande virtuellt nätverk.

Isolerade virtuella nätverk

• För att minska riskerna med onödiga offentliga slutpunkter kan programmet distribueras i ett fristående nätverk som inte är anslutet till andra nätverk.

• Inkommande klientbegäranden kräver fortfarande att en offentlig slutpunkt exponeras för Internet, men all efterföljande kommunikation kan finnas i det virtuella nätverket med hjälp av privata slutpunkter. När du använder Azure Front Door Premium går det att dirigera direkt från kantnoder till privata programslutpunkter.

• Privata anslutningar mellan programkomponenter sker i virtuella nätverk, men alla anslutningar med externa beroenden förlitar sig fortfarande på offentliga slutpunkter.

  • Anslutning till Azure-plattformstjänster kan upprättas med privata slutpunkter om det stöds. Om det finns andra externa beroenden i Azure, till exempel ett annat nedströmsprogram, tillhandahålls anslutningen via offentliga slutpunkter och Microsoft Azure-stamnätet.
  • Anslutning till externa system utanför Azure tillhandahålls av det offentliga Internet.

• För scenarier där det inte finns några krav på nätverksintegrering för externa beroenden ger distribution av lösningen i en isolerad nätverksmiljö maximal designflexiering. Inga adresserings- och routningsbegränsningar som är associerade med bredare nätverksintegrering.

• Azure Bastion är en fullständigt plattformshanterad PaaS-tjänst som kan distribueras i ett virtuellt nätverk och ger säker RDP/SSH-anslutning till virtuella Azure-datorer. När du ansluter via Azure Bastion behöver virtuella datorer inte någon offentlig IP-adress.

• Användningen av virtuella programnätverk medför betydande distributionskomplexiteter i CI/CD-pipelines, eftersom både dataplanet och kontrollplanets åtkomst till resurser som finns i privata nätverk krävs för att underlätta programdistributioner.

  • En säker privat nätverkssökväg måste upprättas för att CI/CD-verktyg ska kunna utföra nödvändiga åtgärder.
  • Privata byggagenter kan distribueras i virtuella programnätverk för proxyåtkomst till resurser som skyddas av det virtuella nätverket.

Anslutna virtuella nätverk

• För scenarier med krav på integrering av externa nätverk kan virtuella programnätverk anslutas till andra virtuella nätverk i Azure, en annan molnleverantör eller lokala nätverk med hjälp av en mängd olika anslutningsalternativ. Vissa programscenarier kan till exempel överväga integrering på programnivå med andra verksamhetsspecifika program som hanteras privat i ett lokalt företagsnätverk.

• Programnätverksdesignen måste anpassas till den bredare nätverksarkitekturen, särskilt när det gäller ämnen som adressering och routning.

• Överlappande IP-adressutrymmen i Azure-regioner eller lokala nätverk skapar stor konkurrens när nätverksintegrering övervägs.

  • En virtuell nätverksresurs kan dock uppdateras för att överväga ytterligare adressutrymme, men när ett virtuellt nätverksadressutrymme för ett peer-kopplat nätverk ändrar en synkronisering på peeringlänken krävs, vilket tillfälligt inaktiverar peering.
  • Azure reserverar fem IP-adresser inom varje undernät, vilket bör beaktas vid fastställandet av lämpliga storlekar för virtuella programnätverk och omfattade undernät.
  • Vissa Azure-tjänster kräver dedikerade undernät, till exempel Azure Bastion, Azure Firewall eller Azure Virtual Network Gateway. Storleken på dessa tjänstundernät är mycket viktig eftersom de bör vara tillräckligt stora för att stödja alla aktuella instanser av tjänsten med tanke på framtida skalningskrav, men inte så stora att de i onödan slösar bort adresser.

• När lokal eller molnöverskridande nätverksintegrering krävs erbjuder Azure två olika lösningar för att upprätta en säker anslutning.

  • En ExpressRoute-krets kan vara storleksanpassad för att ge bandbredder på upp till 100 Gbit/s.
  • Ett virtuellt privat nätverk (VPN) kan vara storleksanpassat för att tillhandahålla aggregerad bandbredd på upp till 10 Gbit/s i hubb- och ekernätverk och upp till 20 Gbit/s i Azure Virtual WAN.

Kommentar

När du distribuerar i en Azure-landningszon bör du vara medveten om att alla nödvändiga anslutningar till lokala nätverk ska tillhandahållas av implementeringen av landningszonen. Designen kan använda ExpressRoute och andra virtuella nätverk i Azure med hjälp av antingen Virtual WAN eller en nav-och-eker-nätverksdesign.

• Införandet av ytterligare nätverksvägar och resurser medför ytterligare tillförlitlighet och driftsöverväganden för programmet för att säkerställa att hälsan upprätthålls.

Designrekommendationer

• Vi rekommenderar att verksamhetskritiska lösningar distribueras i virtuella Azure-nätverk där det är möjligt för att ta bort onödiga offentliga slutpunkter, vilket begränsar programangreppsytan för att maximera säkerhet och tillförlitlighet.

  • Använd privata slutpunkter för anslutning till Azure-plattformstjänster. Tjänstslutpunkter kan övervägas för tjänster som inte stöder Private Link, förutsatt att dataexfiltreringsrisker är acceptabla eller minimerade via alternativa kontroller.

• För programscenarier som inte kräver företagsnätverksanslutning behandlar du alla virtuella nätverk som tillfälliga resurser som ersätts när en ny regional distribution utförs.

• När du ansluter till andra Azure- eller lokala nätverk bör virtuella programnätverk inte behandlas som tillfälliga eftersom det skapar betydande komplikationer när det gäller peering av virtuella nätverk och virtuella nätverksgatewayresurser. Alla relevanta programresurser i det virtuella nätverket bör fortsätta att vara tillfälliga, med parallella undernät som används för att underlätta blågröna distributioner av uppdaterade regionala distributionsstämplar.

• I scenarier där företagsnätverksanslutning krävs för att underlätta programintegrering via privata nätverk ska du se till att IPv4-adressutrymmet som används för regionala virtuella programnätverk inte överlappar andra anslutna nätverk och är korrekt storleksanpassat för att underlätta nödvändig skalning utan att behöva uppdatera den virtuella nätverksresursen och medföra driftstopp.

  • Vi rekommenderar starkt att du endast använder IP-adresser från adressallokeringen för privat Internet (RFC 1918).
    • Överväg att använda IPv6 för miljöer med begränsad tillgänglighet för privata IP-adresser (RFC 1918).
    • Om användning av offentlig IP-adress krävs kontrollerar du att endast ägda adressblock används.
  • Anpassa till organisationens planer för IP-adressering i Azure för att säkerställa att ip-adressutrymmet för programnätverk inte överlappar andra nätverk på lokala platser eller i Azure-regioner.
  • Skapa inte onödigt stora virtuella programnätverk för att säkerställa att IP-adressutrymmet inte slösas bort.

• Prioritera användningen av Azure CNI för AKS-nätverksintegrering, eftersom den stöder en rikare funktionsuppsättning.

  • Överväg Kubenet för scenarier med en begränsad tillgänglig IP-adress för att passa programmet inom ett begränsat adressutrymme.

  • Prioritera användningen av Azure CNI-nätverksinsticksprogrammet för AKS-nätverksintegrering och överväg Kubenet för scenarier med ett begränsat antal tillgängliga IP-adresser. Mer information finns i Nätverksprinciper för mikrosegmentering och kubernetes.

• För scenarier som kräver lokal nätverksintegrering prioriterar du användningen av Express Route för att säkerställa säker och skalbar anslutning.

  • Se till att den tillförlitlighetsnivå som tillämpas på Express Route eller VPN helt uppfyller programkraven.
  • Flera nätverkssökvägar bör anses ge ytterligare redundans vid behov, till exempel korsanslutna ExpressRoute-kretsar eller användning av VPN som en mekanism för redundansanslutning.

• Se till att alla komponenter på kritiska nätverksvägar är i linje med kraven på tillförlitlighet och tillgänglighet för associerade användarflöden, oavsett om hanteringen av dessa sökvägar och tillhörande komponent levereras av programteamet för centrala IT-team.

  Kommentar

  När du distribuerar i en Azure-landningszon och integrerar med en bredare nätverkstopologi för organisationen bör du överväga nätverksvägledningen för att säkerställa att det grundläggande nätverket är i linje med Microsofts bästa praxis.

• Använd Azure Bastion eller proxierade privata anslutningar för att komma åt dataplanet för Azure-resurser eller utföra hanteringsåtgärder.

Utgående Internettrafik

Internetutgång är ett grundläggande nätverkskrav för ett verksamhetskritiskt program för att underlätta extern kommunikation inom ramen för:

1. Direkt interaktion mellan programanvändare.
2. Programintegrering med externa beroenden utanför Azure.
3. Åtkomst till externa beroenden som krävs av De Azure-tjänster som används av programmet.

I det här avsnittet beskrivs hur utgående internet kan uppnås samtidigt som säkerhet, tillförlitlighet och hållbara prestanda upprätthålls, vilket belyser viktiga krav på utgående tjänster som rekommenderas i en verksamhetskritisk kontext.

Designöverväganden

• Många Azure-tjänster kräver åtkomst till offentliga slutpunkter för att olika hanterings- och kontrollplansfunktioner ska fungera som avsett.

• Azure tillhandahåller olika metoder för direkt utgående internetanslutning, till exempel Azure NAT-gateway eller Azure Load Balancer, för virtuella datorer eller beräkningsinstanser i ett virtuellt nätverk.

• När trafik inifrån ett virtuellt nätverk färdas ut till Internet måste NAT (Network Address Translation) äga rum. Det här är en beräkningsåtgärd som inträffar i nätverksstacken och som därför kan påverka systemets prestanda.

• När NAT sker i liten skala bör prestandapåverkan vara försumbar, men om det finns ett stort antal problem med utgående begäranden kan nätverksproblem uppstå. De här problemen kommer vanligtvis i form av portöverbelastning för käll-NAT (eller SNAT).

• I en miljö med flera klientorganisationer, till exempel Azure App Service, finns det ett begränsat antal utgående portar tillgängliga för varje instans. Om dessa portar tar slut kan inga nya utgående anslutningar initieras. Det här problemet kan åtgärdas genom att minska antalet privata/offentliga gräns blädderingar eller genom att använda en mer skalbar NAT-lösning, till exempel Azure NAT Gateway.

• Förutom NAT-begränsningar kan utgående trafik också omfattas av nödvändiga säkerhetsinspektioner.

  • Azure Firewall tillhandahåller lämpliga säkerhetsfunktioner för att skydda nätverkets utgående trafik.

  • Azure Firewall (eller motsvarande NVA) kan användas för att skydda Kubernetes utgående krav genom att ge detaljerad kontroll över utgående trafikflöden.

• Stora mängder internetutgående kommer att medföra avgifter för dataöverföring.

Azure NAT Gateway

• Azure NAT Gateway stöder 64 000 anslutningar för TCP och UDP per tilldelad utgående IP-adress.

  • Upp till 16 IP-adresser kan tilldelas till en enda NAT-gateway.
  • En standardtidsgräns för TCP-inaktivitet på 4 minuter. Om tidsgränsen för inaktivitet ändras till ett högre värde kommer flöden att hållas längre, vilket ökar trycket på SNAT-portinventeringen.

• NAT-gatewayen kan inte tillhandahålla zonindelad isolering. För att få zonredundans måste ett undernät som innehåller zonindelade resurser justeras med motsvarande zonindelade NAT-gatewayer.

Designrekommendationer

• Minimera antalet utgående Internetanslutningar eftersom detta påverkar NAT-prestanda.

  • Om ett stort antal internetbundna anslutningar krävs kan du överväga att använda Azure NAT Gateway för att abstrahera utgående trafikflöden.

• Använd Azure Firewall där det finns krav för att styra och inspektera utgående Internettrafik.

  • Kontrollera att Azure Firewall inte används för att inspektera trafik mellan Azure-tjänster.

Kommentar

När du distribuerar i en Azure-landningszon bör du överväga att använda den grundläggande plattformens Azure Firewall-resurs (eller motsvarande NVA). Om ett beroende används för en central plattformsresurs för utgående Internet bör tillförlitlighetsnivån för resursen och den associerade nätverkssökvägen vara nära anpassad till programkraven. Driftdata från resursen bör också göras tillgängliga för programmet för att informera om potentiella operativa åtgärder i felscenarier.

Om det finns storskaliga krav som är associerade med utgående trafik bör du överväga en dedikerad Azure Firewall-resurs för ett verksamhetskritiskt program för att minska riskerna med att använda en centralt delad resurs, till exempel scenarier med bullriga grannar.

• När du distribuerar i en Virtuell WAN-miljö bör du tänka på Firewall Manager för att tillhandahålla centraliserad hantering av dedikerade Program Azure Firewall-instanser för att säkerställa att organisationens säkerhetsstatus observeras via globala brandväggsprinciper.
• Se till att inkrementella brandväggsprinciper delegeras till programsäkerhetsteam via rollbaserad åtkomstkontroll för att möjliggöra självbestämmande för programprinciper.

Anslutningar mellan zoner och mellan regioner

Även om programdesignen starkt förespråkar oberoende regionala distributionsstämplar, kan många programscenarier fortfarande kräva nätverksintegrering mellan programkomponenter som distribueras inom olika zoner eller Azure-regioner, även om det bara är under försämrade tjänstförhållanden. Metoden med vilken kommunikation mellan zoner och mellan regioner uppnås har en betydande inverkan på övergripande prestanda och tillförlitlighet, som kommer att utforskas genom överväganden och rekommendationer i det här avsnittet.

Designöverväganden

• Programdesignmetoden för ett verksamhetskritiskt program stöder användning av oberoende regionala distributioner med zonredundans som tillämpas på alla komponentnivåer i en enda region.

• En tillgänglighetszon (AZ) är en fysiskt separat datacenterplats i en Azure-region, vilket ger fysisk och logisk felisolering upp till nivån för ett enda datacenter.

  En svarstid för tur och retur på mindre än 2 ms garanteras för kommunikation mellan zoner. Zoner kommer att ha en liten svarstidsavvikelse givet varierande avstånd och fibervägar mellan zoner.

• Tillgänglighetszonens anslutning beror på regionala egenskaper, och därför kan trafik som kommer in i en region via en gränsplats behöva dirigeras mellan zoner för att nå målet. Detta lägger till en ~1ms-2ms svarstid med tanke på begränsningar för routning mellan zoner och "ljusets hastighet", men detta bör bara ha ett lager för hyperkänsliga arbetsbelastningar.

• Tillgänglighetszoner behandlas som logiska entiteter inom ramen för en enda prenumeration, så olika prenumerationer kan ha en annan zonmappning för samma region. Zon 1 i Prenumeration A kan till exempel motsvara samma fysiska datacenter som zon 2 i prenumeration B.

• Med programscenarier som är extremt pratsamma mellan programkomponenter kan spridning av programnivåer mellan zoner medföra betydande svarstider och ökade kostnader. Det går att minimera detta i designen genom att begränsa en distributionsstämpel till en enda zon och distribuera flera stämplar i de olika zonerna.

• Kommunikation mellan olika Azure-regioner medför en större dataöverföringsavgift per GB bandbredd.

  • Den tillämpliga dataöverföringshastigheten beror på kontinenten i de azure-regioner som anses vara aktuella.
  • Databläddringskontinenter debiteras med en betydligt högre hastighet.

• Express Route- och VPN-anslutningsmetoder kan också användas för att ansluta olika Azure-regioner direkt tillsammans för vissa scenarier eller till och med olika molnplattformar.

• För tjänster till tjänstkommunikation kan Private Link användas för direkt kommunikation med hjälp av privata slutpunkter.

• Trafik kan hårfästas via Express Route-kretsar som används för lokal anslutning för att underlätta routning mellan virtuella nätverk i en Azure-region och mellan olika Azure-regioner inom samma geografiska område.

  • Hårfästningstrafik via Express Route kringgår kostnader för dataöverföring som är associerade med peering för virtuella nätverk, så kan användas som ett sätt att optimera kostnaderna.
  • Den här metoden kräver ytterligare nätverkshopp för programintegrering i Azure, vilket medför risker för svarstid och tillförlitlighet. Utökar rollen för Express Route och associerade gatewaykomponenter från Azure/lokalt till att även omfatta Azure/Azure-anslutningar.

• När svarstid på undermillisekunder krävs mellan tjänster kan närhetsplaceringsgrupper användas när de stöds av de tjänster som används.

Designrekommendationer

• Använd peering för virtuella nätverk för att ansluta nätverk inom en region och mellan olika regioner. Vi rekommenderar starkt att du undviker hårfästning i Express Route.

• Använd Private Link för att upprätta kommunikation direkt mellan tjänster i samma region eller mellan regioner (tjänst i region A som kommunicerar med tjänsten i region B.

• För programarbetsbelastningar som är extremt pratsamma mellan komponenter kan du överväga att begränsa en distributionsstämpel till en enda zon och distribuera flera stämplar i de olika zonerna. Detta säkerställer att zonredundans bibehålls på nivån för en inkapslad distributionsstämpel i stället för en enda programkomponent.

• Om möjligt behandlar du varje distributionsstämpel som oberoende och frånkopplad från andra stämplar.

  • Använd dataplattformstekniker för att synkronisera tillstånd mellan regioner i stället för att uppnå konsekvens på programnivå med direkta nätverkssökvägar.
  • Undvik "hundbenstrafik" mellan olika regioner om det inte behövs, även i ett felscenario. Använd globala routningstjänster och hälsoavsökningar från slutpunkt till slutpunkt för att ta en hel stämpel ur cirkulationen om en enda kritisk komponentnivå misslyckas, i stället för att dirigera trafik på den felaktiga komponentnivån till en annan region.

• För scenarier med känsliga program med hypersvarstid prioriterar du användningen av zoner med regionala nätverksgatewayer för att optimera nätverksfördröjningen för inkommande sökvägar.

Nätverksprinciper för mikrosegmentering och Kubernetes

Mikrosegmentering är ett mönster för nätverkssäkerhetsdesign som används för att isolera och skydda enskilda programarbetsbelastningar, med principer som tillämpas för att begränsa nätverkstrafiken mellan arbetsbelastningar baserat på en Nulta pouzdanost modell. Det används vanligtvis för att minska nätverksangreppsytan, förbättra intrångskontrollen och stärka säkerheten genom principdrivna nätverkskontroller på programnivå.

Ett verksamhetskritiskt program kan framtvinga nätverkssäkerhet på programnivå med hjälp av nätverkssäkerhetsgrupper (NSG) på antingen undernäts- eller nätverksgränssnittsnivå, tjänståtkomstkontrollistor (ACL) och nätverksprinciper när du använder Azure Kubernetes Service (AKS).

Det här avsnittet utforskar den optimala användningen av dessa funktioner och ger viktiga överväganden och rekommendationer för att uppnå mikrosegmentering på programnivå.

Designöverväganden

• AKS kan distribueras i två olika nätverksmodeller:

  • Kubenet-nätverk: AKS-noder är integrerade i ett befintligt virtuellt nätverk, men poddar finns i ett virtuellt överläggsnätverk på varje nod. Trafik mellan poddar på olika noder dirigeras via kube-proxy.
  • CNI-nätverk (Azure Container Networking Interface): AKS-klustret är integrerat i ett befintligt virtuellt nätverk och dess noder, poddar och tjänster tog emot IP-adresser från samma virtuella nätverk som klusternoderna är anslutna till. Detta är relevant för olika nätverksscenarier som kräver direkt anslutning från och till poddar. Olika nodpooler kan distribueras till olika undernät.

  Kommentar

  Azure CNI kräver mer IP-adressutrymme jämfört med Kubenet. Korrekt planering och storleksändring av nätverket krävs. Mer information finns i Azure CNI-dokumentationen.

• Poddar är som standard icke-isolerade och accepterar trafik från alla källor och kan skicka trafik till valfri destination. en podd kan kommunicera med alla andra poddar i ett visst Kubernetes-kluster. Kubernetes säkerställer inte någon isolering på nätverksnivå och isolerar inte namnområden på klusternivå.

• Kommunikationen mellan poddar och namnområden kan isoleras med hjälp av nätverksprinciper. Nätverksprincip är en Kubernetes-specifikation som definierar åtkomstprinciper för kommunikation mellan poddar. Med hjälp av nätverksprinciper kan en ordnad uppsättning regler definieras för att styra hur trafik skickas/tas emot och tillämpas på en samling poddar som matchar en eller flera etikettväljare.

  • AKS stöder två plugin-program som implementerar Nätverksprincip, Azure och Calico. Båda plugin-program använder Linux IPTables för att framtvinga de angivna principerna. Mer information finns i Skillnader mellan Azure- och Calico-principer och deras funktioner .
  • Nätverksprinciper står inte i konflikt eftersom de är additiva.
  • För att ett nätverksflöde mellan två poddar ska tillåtas måste både utgående princip på källpodden och ingressprincipen på målpodden tillåta trafiken.
  • Nätverksprincipfunktionen kan bara aktiveras vid instansiering av kluster. Det går inte att aktivera nätverksprincip i ett befintligt AKS-kluster.
  • Leveransen av nätverksprinciper är konsekvent oavsett om Azure eller Calico används.
  • Calico tillhandahåller en rikare funktionsuppsättning, inklusive stöd för windows-noder och stöder Både Azure CNI och Kubenet.

• AKS stöder skapandet av olika nodpooler för att separera olika arbetsbelastningar med hjälp av noder med olika maskinvaru- och programvaruegenskaper, till exempel noder med och utan GPU-funktioner.

  • Att använda nodpooler ger ingen isolering på nätverksnivå.
  • Nodpooler kan använda olika undernät i samma virtuella nätverk. NSG:er kan användas på undernätsnivå för att implementera mikrosegmentering mellan nodpooler.

Designrekommendationer

• Konfigurera en NSG för alla övervägt undernät för att tillhandahålla en IP-ACL för att skydda ingresssökvägar och isolera programkomponenter baserat på en Nulta pouzdanost modell.

  • Använd Front Door-tjänsttaggar i NSG:er på alla undernät som innehåller programserverdelar som definierats i Azure Front Door, eftersom detta verifierar att trafiken kommer från ett legitimt IP-adressutrymme för Azure Front Door-serverdelen. Detta säkerställer trafikflöden via Azure Front Door på tjänstnivå, men huvudbaserad filtrering krävs fortfarande för att säkerställa användningen av en viss Front Door-instans och för att även minska säkerhetsriskerna för "IP-förfalskning".

  • Offentlig Internettrafik bör inaktiveras på RDP- och SSH-portar i alla tillämpliga NSG:er.

  • Prioritera användningen av Plugin-programmet för Azure CNI-nätverket och överväg Kubenet för scenarier med ett begränsat antal tillgängliga IP-adresser som passar programmet inom ett begränsat adressutrymme.

    • AKS stöder användning av både Azure CNI och Kubenet. Det här nätverksvalet väljs vid distributionstillfället.
    • Plugin-programmet för Azure CNI-nätverk är ett mer robust och skalbart nätverksinsticksprogram och rekommenderas för de flesta scenarier.
    • Kubenet är ett enklare plugin-program för nätverk och rekommenderas för scenarier med ett begränsat antal tillgängliga IP-adresser.
    • Mer information finns i Azure CNI .

• Funktionen Nätverksprincip i Kubernetes ska användas för att definiera regler för inkommande och utgående trafik mellan poddar i ett kluster. Definiera detaljerade nätverksprinciper för att begränsa och begränsa kommunikation mellan poddar.

  • Aktivera nätverksprincip för Azure Kubernetes Service vid distributionstillfället.
  • Prioritera användningen av Calico eftersom det ger en rikare funktionsuppsättning med bredare communityimplementering och support.

Gå vidare

Granska övervägandena för att kvantifiera och observera programmets hälsa.

Hälsomodellering och observerbarhet