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 Azure Well-Architected verksamhetskritiska arbetsbelastningsserie . 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ålla de routningsfunktioner som krävs för att hantera global trafik i ett program i 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 Azures routningstjänster för att definiera hur var och en kan användas för att optimera olika scenarier.

Designöverväganden

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

• Om programarbetsbelastningen omfattar klientkontroll, till exempel med mobil- eller skrivbordsklientprogram, är det möjligt att tillhandahålla tjänstredundans inom klientroutningslogik.

  • Flera globala routningstekniker, till exempel Azure Front Door och Azure Traffic Manager, kan betraktas 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 cachelagring av gränsenheter och Web Application Firewall funktioner 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 tillsammans med 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å upplever otillgänglighet eller en degraderad tjänst.
    • Felscenarier för global routningstjänst har mycket stor risk att 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 på Azure ger lite värde ändå.

• Redundans för global routningstjänst ger en lösning 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 en aktiv-aktiv distributionsmetod för flera moln övervägas. En aktiv-aktiv-aktiv distributionsmetod för flera moln medför betydande driftskomplexiteter, som 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öjligt måste ett beroende utföras 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 i flera regioner tillhandahålls.
  • Serviceavtalet som tillhandahålls av den valda globala routningstjänsten representerar det maximala uppnåeliga sammansatta serviceavtalet, oavsett hur många distributionsregioner som övervägs.

• När klientkontroll inte är möjligt 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 övervägs.

• 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 ekonomisk gottgörelse 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 driftsminskningar 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 all nödvändig trafikgranskning vidarebefordras begäranden antingen via Microsofts stamnät till lämplig serverdel med befintliga anslutningar eller hanteras från den interna cachen för en gränsnod.
  • Den här metoden är mycket effektiv när det gäller att sprida stora trafikvolymer över serverdelsanslutningarna.

• Tillhandahåller ett inbyggt cacheminne 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 det 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 i 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 serverdelshälsoslutpunkter (URL:er) som anropas med intervall 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 ur en viss gränsnods perspektiv. Felaktiga serverdelar tas därför transparent bort från trafikcirkulationen utan dröjsmål.

• 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.

• Ip-utrymmet för Front Door-serverdelen kan ändras, men Microsoft säkerställer integrering med Azure IP-intervall och tjänsttaggar. Det går 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 konfigurationer för belastningsfördelning:

  • Svarstidsbaserad: standardinställningen som dirigerar trafik till den "närmaste" serverdelen från klienten. baserat på svarstid för begäran.
  • Prioritetsbaserad: användbart 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 klienter 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, utan Traffic Manager returnerar i stället DNS-namnet på en av serverdelarna som poolen har, baserat på konfigurerade regler för den valda trafikroutningsmetoden.
  • Serverdels-DNS-namnet matchas sedan till dess slutliga IP-adress som därefter 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 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 tid.

Azure Standard Load Balancer

Viktigt

Standard Load Balancer mellan regioner är tillgängligt som 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), kantcachelagring 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 tillräckligt. Klientlogik krävs för att dirigera till den redundanta tekniken vid 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 certifikathanteringsupplevelsen 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.
  • Hänsyn bör också tas till direkt routning till en enda regional stämpel snarare än en separat routningstjänst. Även om detta resulterar i en försämrad tjänstnivå är det en mycket enklare designmetod.

Den här bilden 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 i Azure-plattformen bör en aktiv-aktiv-aktiv distributionsmetod för flera moln övervägas, med aktiva distributionsstämplar som finns på 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 metod för flera moln eftersom den medför betydande driftskomplexitet, med olika definitioner av distributionsstämpel och representationer av drifthälsa på de olika molnplattformarna. Denna komplexitet medför i sin tur många återhämtningsrisker inom programmets normala drift, vilket vida uppväger de hypotetiska riskerna med ett globalt plattformsstopp.

• Även om det inte rekommenderas för HTTP-arbetsbelastningar som använder Azure Traffic Manager för global routningsredundans till Azure Front Door bör du överväga att avlasta Web Application Firewall (WAF) för att Application Gateway för acceptabel trafik som flödar via Azure Front Door.
  • Detta medför ytterligare en felpunkt för standard-ingressvägen, en ytterligare komponent för kritisk sökväg för att hantera och skala, 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 acceptabla och inte acceptabla ingressvägar 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 kanter i ett felscenario påverkar den övergripande prestandan, och detta måste justeras efter en acceptabel tjänstnivå eller en minimerande designmetod. För att säkerställa en konsekvent tjänstnivå bör du överväga att avlasta cachelagring av kant 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 maximal nivå av felreducering och en enklare designmetod eftersom de flesta branschledande CDN-leverantörer erbjuder gränsfunktioner som till stor del överensstämmer med de 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 skydda 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 genom Azure Front Door på tjänstnivå, men huvudbaserad 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 verifiera 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 på 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, sprid trafik jämnt över alla anses regionala stämplar för att mest effektivt använda distribuerade resurser.

  • 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 en ersättning till Azure Front Door. Kapacitetsskillnader kommer att driva olika designbeslut för cache- och WAF-funktioner och TLS-certifikathantering.

• WAF-funktioner bör övervägas 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 om serverdelen blir felaktig.

• På samma sätt som med Azure Front Door bör en anpassad TCP-hälsoslutpunkt definieras för att validera 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 regionala redundansväxlingar på servicenivå. till exempel "hundben", 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 går 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änsenheter när du använder Azure Traffic Manager som en primär global routningstjänst. Om waf-funktioner för gränsen också erbjuds av tjänsten från tredje part bör du överväga att förenkla ingressvä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å ta hänsyn till programleveranstjänster för att säkerställa säker, tillförlitlig och skalbar inkommande trafik.

Det här avsnittet bygger på globala routningsrekommendationer 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.

Designöverväganden

• 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 punkten 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 Web Application Firewall 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äkerhetsriskerna 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 åt. Azure Front Door WAF tillhandahåller till exempel hastighetsbegränsning, geofiltrering och robotskydd, som ännu inte erbjuds inom Application Gateway WAF. Alla stöder dock 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 i alla tjänstintegreringar.

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

• 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. Detta protokollblockering hjälper till att minimera volymtriska attacker 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 till konfigurationen, inklusive vägar och serverdelspooler, är sömlösa och orsakar ingen stilleståndstid 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 upphörande 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 klienter få fel med utgångna certifikat.

• Certifikatuppdateringar resulterar endast i stilleståndstid om Azure Front Door växlas mellan "Hanterad" 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ämningar eller layer 3/4-volymattacker.

  • 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 oäkta 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 för att skydda mot vanliga attacker, geofiltrering, adressblockering, hastighetsbegränsning och signaturmatchning.

  Azure Load Balancer

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

Designrekommendationer

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

• 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 inom 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 justeras efter 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 ger ytterligare effektivitet.

• 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 över Tillgänglighetszoner.
  • Innehå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 den totala kostnaden för lösningen. Cachelagring av statiskt innehåll vid gränsen kan påskynda klientens inläsningstider, vilket ger en bättre användarupplevelse och kan också minska kostnaden för trafik, läsåtgärder och beräkningskraft på berörda serverdelstjänster.

Designöverväganden

• 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 trafik 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 ger inte samma avancerade routnings- och Web Application Firewall-funktioner (WAF) 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 tillhörande kostnad.
    • Pris per månad för körning av regelmotorn (debiteras per begäran på Azure Front Door).
    • Krav för utgående trafik (priset varierar efter mål).

Designrekommendationer

• Genererat statiskt innehåll som storlekskopior 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åde) att använda Azure Front Door för global routning och Web Application Firewall (WAF) rekommenderar vi att du prioriterar användningen av Cachelagringsfunktioner i Azure Front Door om det inte finns luckor.

Virtual Network-integration

Ett verksamhetskritiskt program omfattar vanligtvis krav på 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 den metod 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

Konfiguration 1 när du distribuerar i en Azure-landningszon. ska distribueras i en onlinelandningszon, medan både 2) och 3) ska distribueras i 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, där du får en lämplig användning av virtuella Azure-nätverk och kringliggande Azure-nätverkstjänster för att säkerställa att integreringskraven är optimalt uppfyllda.

Designanmärkningar

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 svå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 gränsnoder till privata programslutpunkter.

• Privat anslutning mellan programkomponenter sker över 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 underordnat program, 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 designflexier. Inga adresserings- och routningsbegränsningar som är associerade med bredare nätverksintegrering.

• Azure Bastion är en helt 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.

  • 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å extern nätverksintegrering 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 uppdateras för att överväga ytterligare adressutrymme, men när ett virtuellt nätverksadressutrymme i ett peer-kopplat nätverk ändrar krävs en synkronisering på peeringlänken, vilket tillfälligt inaktiverar peering.
  • Azure reserverar fem IP-adresser i varje undernät, vilket bör övervägas vid fastställandet av lämpliga storlekar för virtuella programnätverk och 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 storleksanpassas för att ge aggregerad bandbredd på upp till 10 Gbit/s i hubb- och ekernätverk och upp till 20 Gbit/s i Azure Virtual WAN.

Anteckning

När du distribuerar i en Azure-landningszon bör du vara medveten om att alla nödvändiga anslutningar till lokala nätverk bör 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 nätverksdesign för nav och ekrar.

• 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 programattackytan 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 accepteras eller minimeras 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 över 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 har rätt storlek 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 programmets nätverks-IP-adressutrymme inte överlappar andra nätverk på lokala platser eller 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 det stöder en rikare funktionsuppsättning.

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

  • Prioritera användningen av Azure CNI-nätverks-plugin-programmet 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 tillförlitlighets- och tillgänglighetskraven 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.

  Anteckning

  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 proxied privata anslutningar för att komma åt dataplanet för Azure-resurser eller utföra hanteringsåtgärder.

Internet-utgående

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

1. Direkt användarinteraktion för program.
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ållbar prestanda upprätthålls, vilket belyser viktiga utgående krav för tjänster som rekommenderas i en verksamhetskritisk kontext.

Designanmärkningar

• 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 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änsblädderingar eller genom att använda en mer skalbar NAT-lösning som 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 volymer av internetutgång medför 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 hålls flöden längre, vilket ökar trycket på SNAT-portinventeringen.

• NAT-gatewayen kan inte tillhandahålla zonisolering direkt. 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 Internet-bundna 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 på att kontrollera och inspektera utgående Internettrafik.

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

Anteckning

När du distribuerar i en Azure-landningszon bör du överväga att använda den grundläggande plattformen 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 störningar i grannen.

• När brandväggshanteraren distribueras i en Virtual WAN miljö bör du överväga 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 programprincipens autonomi.

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 för kommunikation mellan zoner och mellan regioner har en betydande inverkan på övergripande prestanda och tillförlitlighet, som kommer att utforskas genom överväganden och rekommendationer i det här avsnittet.

Designanmärkningar

• Programdesignmetoden för ett verksamhetskritiskt program stöder användningen 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 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 givet begränsningar för routning mellan zoner och "ljusets hastighet", men detta bör bara ha betydelse för hyperkänsliga arbetsbelastningar.

• Tillgänglighetszoner behandlas som logiska entiteter inom kontexten för en enskild 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.

• Kommunikation mellan zoner inom en region medför en dataöverföringsavgift per GB bandbredd.

• Med programscenarier som är mycket trafikintensiva 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.

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

  • Vilken dataöverföringshastighet som gäller 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 koppla samman olika Azure-regioner direkt 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 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äst trafik 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 fördröjnings- och tillförlitlighetsrisker. Utökar rollen för Express Route och associerade gatewaykomponenter från Azure/lokalt till att även omfatta Azure/Azure-anslutningar.

• När svarstid 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 mycket trafikintensiva mellan komponenter bör 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 zonindelad redundans upprätthålls på nivån för en inkapslad distributionsstämpel i stället för en enda programkomponent.

• Behandla om möjligt 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 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 ingressvä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 Nolltillit modell. Den 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 nätverkssäkerhetsgrupper (NSG) på antingen undernäts- eller nätverksgränssnittsnivå, ACL (service Access Control Lists) och nätverksprinciper när du använder Azure Kubernetes Service (AKS).

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

Designanmärkningar

• 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.
  • Azure CNI-nätverk (Container Networking Interface): AKS-klustret är integrerat i ett befintligt virtuellt nätverk och dess noder, poddar och tjänster har tagit 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 direktanslutning från och till poddar. Olika nodpooler kan distribueras till olika undernät.

  Anteckning

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

• Som standard är poddar icke-isolerade och accepterar trafik från alla källor och kan skicka trafik till alla mål. en podd kan kommunicera med alla andra poddar i ett visst Kubernetes-kluster. Kubernetes säkerställer ingen 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 ä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 principen 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ätverksprinciper i ett befintligt AKS-kluster.
  • Leveransen av nätverksprinciper är konsekvent oavsett om Azure eller Calico används.
  • Calico tillhandahåller en mer omfattande funktionsuppsättning, inklusive stöd för windows-noder och har stöd för Både Azure CNI och Kubenet.

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

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

Designrekommendationer

• Konfigurera en NSG på 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 Nolltillit 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 validerar 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äkerhetsrisker 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 Azure CNI-nätverks-plugin-programmet och överväg Kubenet för scenarier med ett begränsat antal tillgängliga IP-adresser för att passa programmet inom ett begränsat adressutrymme.

    • AKS stöder användning av både Azure CNI och Kubenet. Den 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 bör 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.

Nästa steg

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

Hälsomodellering och observerbarhet