Migrera och modernisera designvägen för nätverk

Den här guiden innehåller en sekvenserad läsväg via designguiden för Azure nätverk för kunder som använder PaaS-tjänster (Platform as a Service), containrar och hanterade databaser. Följ de numrerade stegen för att skapa ett nätverk i flera regioner med säkerhetsnivå som stöder moderna programarkitekturer.

Översikt

Migrera och modernisera projekt går bortom virtuella datorer till Azure interna tjänster: Azure Kubernetes Service (AKS) för containrar, Azure App Service för webbprogram, Azure SQL Database och Azure Cosmos DB för hanterade data och Azure Front Door för global trafikdistribution. Ditt nätverk måste ha stöd för privat anslutning till dessa PaaS-tjänster, aktiva-aktiva distributioner i flera regioner och strikt säkerhetssegmentering mellan programnivåer.

Målarkitekturen använder en topologi med dubbla hubbar som sträcker sig över två Azure regioner. IT-hanterade virtuella hubbar är värd för delade tjänster som Azure Firewall och VPN Gateway. Programteam äger sina virtuella ekernätverk och styr sina egna Private Link undernät för PaaS-anslutning. Trafiken går in via Azure Front Door eller Azure Traffic Manager, passerar hubbens brandvägg för inspektion och når applikationstjänster som körs i isolerade spoke-nätverk.

Den här läsvägen tar dig igenom 14 viktiga artiklar i fem faser. Vägen är längre än vid lift and shift eftersom moderna arkitekturer kräver beslut om ingressmönster, privat anslutning till PaaS, brandväggar för webbapplikationer och DDoS-skydd, beslut som designer som enbart bygger på IaaS kan skjuta upp. Två kontrollpunkter för milstolpe hjälper dig att identifiera när du kan hoppa framåt om din arbetsbelastning inte behöver alla komponenter.

Förutsättningar

  • Läs Azure nätverksplan och designöversikt för orientering om tillgängliga tjänster.
  • Ta reda på vilka PaaS-tjänster dina program riktar in sig på (AKS, App Service, Azure SQL, Azure Cosmos DB eller andra).
  • Avgör om distributionen omfattar flera Azure regioner (aktiv-aktiv eller aktiv-passiv).
  • Identifiera ditt ingressmönster: hanterar ditt program offentlig webbtrafik, mobil API-trafik eller endast intern trafik?

Din lässökväg

Fas 1: Fundament

1. Virtuella nätverk och undernät

Ändra storlek på dina undernät för AKS-nodpooler, App Service Environment (ASE) delegerade undernät och Private Link undernät. När du använder CNI-överlägg (AKS Container Networking Interface) kommer podd-IP-adresser från ett separat överläggs-CIDR och förbrukar inte VNet-undernätsutrymme. Endast nod-IP-adresser kräver undernätsadresser. Planera overlay-nätverkets CIDR-intervall så att det rymmer den mängd poddar du behöver, och tilldela dedikerade undernät för varje typ av tjänst.

2. Planering av IP-adresser

Planera IP-allokering mellan två regioner för en aktiv-aktiv distribution. Dina primära regioner och säkerhetskopieringsregioner behöver icke-överlappande adressutrymmen som stöder VNet-peering och replikering mellan regioner. Allokera tillräckligt stora intervall för att rymma framtida tillägg av spokes.

3. Nätverkssäkerhetsgrupper och programsäkerhetsgrupper

Utforma strikt segmentering så att endast lastbalanserarens trafik når programundernät. Blockera direkt internetåtkomst till programnivåer. Använd programsäkerhetsgrupper (ASG: er) för att tillämpa regler baserat på arbetsbelastningsrollen i stället för enskilda IP-adresser.

Fas 2: Topologi

4. Topologi för nav och eker

Distribuera en topologi med dubbla hubbar för flera regioner. IT-prenumerationen äger båda de virtuella hubbnätverken och hanterar delade tjänster som Azure Firewall, VPN Gateway och DNS-vidarebefordrare. Programteam äger sina virtuella ekernätverk och hanterar Private Link undernät, AKS-kluster och programresurser inom sitt allokerade adressutrymme.

5. Nätverk i flera regioner

Utforma en aktiv-aktiv distribution i primära regioner och säkerhetskopieringsregioner. Konfigurera VNet-peering mellan olika regioner mellan hubbar, konfigurera redundansroutning och planera för fel i en region. Båda regionerna hanterar trafik samtidigt, där Azure Front Door distribuerar förfrågningar baserat på svarstid och hälsokontroller.

Note

Milstolpe: Topologin är klar. Topologin med dubbla hubbar med flera regioner finns på plats. Om ditt program endast är internt utan internetuppkopplade slutpunkter kan du gå vidare till steg 9 (Utgående internetåtkomst) och fortsätta därifrån.

Det här hoppar du över: Steg 6–8 omfattar ingress via Internet, programleverans och prestanda samt privat Åtkomst till PaaS. Det är säkert att hoppa över om din arbetsbelastning inte har några offentliga slutpunkter och inga Private Link krav.

Viktigt: Även interna program behöver ofta Private Link (steg 8) om de ansluter till Azure SQL, Azure Storage, Azure Key Vault eller andra PaaS-tjänster via privata slutpunkter. Om ditt program använder någon av dessa tjänster slutför du steg 8 innan du hoppar över till steg 9.

Återstående artiklar: Sex artiklar efter att ha hoppat över (steg 9–14), jämfört med nio artiklar utan att hoppa över (steg 6–14).

Fas 3: Anslutning

6. Internetingress

Kundriktade trafikmönster avgör arkitekturens externa form. Använd Azure Front Door för webbprogram som behöver global belastningsutjämning, cachelagring och Web Application Firewall (WAF). Använd Azure Traffic Manager för mobila program eller API-program där DNS-baserad routning med hälsoavsökningar räcker.

7. Leverans och prestanda för program

Välj mellan Azure Front Door och Azure Traffic Manager baserat på din programtyp. Webbprogram drar nytta av Funktionerna i Front Door Layer 7: TLS-avlastning, cachelagring, URL-baserad routning och integrerad WAF. Mobila serverdelar och API-serverdelar använder Traffic Manager för redundans på DNS-nivå med lägre omkostnader.

8. Privat åtkomst till PaaS

Skapa Private Link-subnät i varje spoke-VNet för anslutning till PaaS-tjänster. Programteam hanterar sina egna privata slutpunkter: AKS hämtar containeravbildningar via Private Link, webbappar ansluter till Azure SQL via privata slutpunkter och ingen PaaS-trafik passerar det offentliga Internet. Dedikera ett undernät per spoke för Private Link-resurser.

Note

Milstolpe: Anslutningen har slutförts. Din ingress och privata PaaS-anslutning är konfigurerade.

Återstående steg: utgående trafik (steg 9), Azure Firewall (steg 10), Web Application Firewall (steg 11), DDoS-skydd (steg 12), DNS-säkerhet (steg 13) och nätverksövervakning (steg 14), sammanlagt 6 artiklar.

Väsentligt för alla driftsättningar: Steg 9–10 (utgående trafik och Azure Firewall) gäller för alla moderniseringsdriftsättningar. Hubbens brandvägg styr all utgående trafik och ger centraliserad kontroll oavsett om din arbetsbelastning är offentlig eller endast intern.

Endast offentliga slutpunkter: Steg 11–12 (WAF- och DDoS-skydd) gäller endast om ditt program exponerar offentliga slutpunkter via Azure Front Door, Application Gateway eller en offentlig Load Balancer. Endast interna arbetsbelastningar kan hoppa över dessa två artiklar och gå vidare till steg 13 (DNS-säkerhet).

9. Utgående internetåtkomst

Dirigera all utgående trafik från ekernätverket till hubbens brandvägg med hjälp av användardefinierade vägar (UDR). Hubbens brandvägg fungerar som punkt för källnätverksadressöversättning (SNAT) för all utgående trafik. IT hanterar brandväggsreglerna centralt, så att programteamen inte kan kringgå utgående kontroller.

Fas 4: Säkerhet

10. Azure Firewall

Konfigurera Azure Firewall i båda hubb-VNeten som punkt för SNAT (Source Network Address Translation) och DNAT (Destination Network Address Translation). All inkommande trafik passerar genom brandväggen innan den når programnivån. Använd brandväggspolicyer för att styra öst-väst-trafik mellan spokes och nord-syd-trafik till internet.

11. Web Application Firewall

Distribuera WAF på Azure Front Door eller Azure Application Gateway för dina webbprogram. WAF skyddar mot Open Web Application Security Project (OWASP) de 10 främsta hoten, SQL-inmatning, skriptkörning mellan webbplatser och andra HTTP-lagerattacker. Använd hanterade regeluppsättningar och lägg till anpassade regler för programmets specifika mönster.

12. DDoS-skydd

Aktivera Azure DDoS Protection för alla offentliga IP-resurser. DDoS Protection ger kontinuerlig trafikövervakning, automatisk attackbegränsning och garantier för kostnadsskydd. Kombinera DDoS Protection med WAF för lagerskydd mot volym- och programnivåattacker.

13. DNS-säkerhet och matchning av privata namn

Konfigurera offentliga DNS-zoner för dina kundinriktade domäner med CNAME-poster som pekar på Azure Front Door eller Traffic Manager-slutpunkter. Tillämpa Role-Based Access Control (RBAC) på DNS-zoner så att endast auktoriserade team kan ändra poster. Aktivera DNS-säkerhetstillägg (DNSSEC) för zoner som kräver kryptografisk validering.

Fas 5: Åtgärder

14. Nätverksövervakning och observerbarhet

Produktionsberedskap kräver övervakning från dag ett. Aktivera Azure Network Watcher för anslutningsdiagnostik, Nätverks Performance Monitor för svarstidsspårning och flödesloggar för trafikanalys. Programteam övervakar sina egna AKS- och ASE-arbetsbelastningar. Plattformsteamet övervakar hubbinfrastruktur och anslutningar mellan regioner.

Villkorsstyrda artiklar

Inkludera dessa artiklar baserat på dina specifika krav:

Tillstånd Artikel När ska inkluderas
Hybridsamexistens Hybridanslutning Dina moderniserade program måste samexistera med lokala system under övergångsperioden
Administratörsåtkomst för virtuella datorer krävs Utvecklar- och administratörsåtkomst Din egendom innehåller virtuella datorer som behöver säker RDP-/SSH-åtkomst tillsammans med PaaS-arbetsbelastningar
Stor styrd egendom Centraliserad nätverkshantering Du hanterar en VNet-egendom med flera prenumerationer och flera team som behöver centraliserad principframtvingande
Molnövergripande Anslutningar mellan regioner och flera moln Din arkitektur kräver explicita privata anslutningar mellan regioner utöver vad nätverk i flera regioner ger
Mycket liten arbetsbelastning Platt nätverkstopologi Du har en enskild arbetsbelastning som inte motiverar den komplexitet som en hub-and-spoke-topologi innebär

Sammanfattning

Genom att följa den här läsvägen har du utformat en nätverksarkitektur i flera regioner med säkerhetsnivå för PaaS-arbetsbelastningar. Din design omfattar topologi med dubbla hubbar med IT-hanterade delade tjänster, aktiv-aktiv multiregion med Azure Front Door eller Azure Traffic Manager, Private Link anslutning för PaaS-tjänster, centraliserad brandväggskontroll för alla trafikflöden, WAF- och DDoS-skydd för offentliga slutpunkter och DNS med RBAC och DNSSEC. Den här arkitekturen stöder moderna programmönster samtidigt som centraliserad säkerhetsstyrning upprätthålls.

Checklista för verifiering

Använd den här checklistan för att bekräfta att din moderniseringsnätverksdesign är klar:

  • Topologi med dubbla hubbar distribueras i primära regioner och säkerhetskopieringsregioner.
  • Icke-överlappande adressutrymmen som allokerats för både regioner och framtida ekrar.
  • Azure Front Door eller Azure Traffic Manager konfigurerade för global ingress, om din arbetsbelastning är offentlig.
  • Private Link-subnät etablerade i varje spoke-VNet som är värd för PaaS-beroenden.
  • Användardefinierade rutter skickar utgående trafik från spoke via hubbens brandvägg.
  • Azure Firewall distribueras i båda de virtuella hubbnätverken för ingress, öst-väst och utgående inspektion.
  • WAF-principer som tillämpas på offentliga webbslutpunkter, om tillämpligt.
  • DDoS Protection aktiverat på offentliga IP-resurser, om tillämpligt.
  • DNS-zoner och privat DNS-upplösning konfigurerade för privata slutpunkter.
  • Network Watcher, flödesloggar och övervakning av anslutningar mellan regioner är aktiverade.

Nästa steg

  • Last updated on