Het ontwerppad voor netwerken migreren en moderniseren

Deze handleiding biedt een gesequentieerd leestraject via de Azure Netwerkontwerphandleiding voor klanten die PaaS-services (Platform as a Service) gebruiken, containers en beheerde databases. Volg de genummerde stappen voor het bouwen van een netwerk met meerdere regio's met beveiligingslagen dat moderne toepassingsarchitecturen ondersteunt.

Overview

Migratie- en moderniseringsprojecten gaan verder dan virtuele machines en maken de overstap naar systeemeigen Azure-services: Azure Kubernetes Service (AKS) voor containers, Azure App Service voor webtoepassingen, Azure SQL Database en Azure Cosmos DB voor beheerde gegevensopslag, en Azure Front Door voor wereldwijde verkeersverdeling. Uw netwerk moet private connectiviteit met deze PaaS-services, multiregion active-active-implementaties en strikte beveiligingssegmentatie tussen applicatielagen ondersteunen.

Uw doelarchitectuur maakt gebruik van een dual-hub-topologie die twee Azure regio's beslaat. Door IT beheerde hub-VNets bevatten gedeelde services, zoals Azure Firewall en VPN Gateway. Toepassingsteams zijn eigenaar van hun spoke-VNets en beheren hun eigen Private Link subnetten voor PaaS-connectiviteit. Verkeer komt binnen via Azure Front Door of Azure Traffic Manager, passeert een firewallinspectie in de hub en bereikt applicatieservices die draaien in geïsoleerde spokes.

Dit leestraject leidt u door 14 essentiële artikelen in vijf fasen. Het traject is langer dan lift and shift, omdat moderne architecturen beslissingen vereisen over patronen voor inkomend verkeer, private PaaS-connectiviteit, webapplicatiefirewalls en DDoS-beveiliging die ontwerpen die uitsluitend op IaaS zijn gebaseerd, kunnen uitstellen. Met twee mijlpaalcontrolepunten kunt u bepalen wanneer u vooruit kunt gaan als uw workload niet alle onderdelen nodig heeft.

Prerequisites

  • Lees het Azure netwerkplan en ontwerpoverzicht voor oriëntatie op beschikbare services.
  • Weten welke PaaS-services uw toepassingen targeten (AKS, App Service, Azure SQL, Azure Cosmos DB of anderen).
  • Bepaal of uw implementatie meerdere Azure regio's omvat (actief-actief of actief-passief).
  • Identificeer uw toegangsbeheerpatroon: dient uw toepassing openbaar webverkeer, mobiel API-verkeer of verkeer dat alleen intern is?

Uw leespad

Fase 1: Basisbeginselen

1. Virtuele netwerken en subnetten

Maak de grootte van uw subnetten voor AKS-knooppuntgroepen, App Service Environment (ASE) gedelegeerde subnetten en Private Link subnetten. Wanneer u AKS Container Networking Interface (CNI) Overlay gebruikt, komen IP-adressen van pods uit een afzonderlijke overlay CIDR en verbruiken geen VNet-subnetruimte. Alleen knooppunt-IP's vereisen subnetadressen. Plan uw overlay-CIDR-bereik zodanig dat het ruimte biedt voor de schaal van pods, en wijs voor elk servicetype een afzonderlijk subnet toe.

2. PLANNING van IP-adressen

Plan IP-toewijzing in twee regio's voor een actief-actieve implementatie. Uw primaire en back-upregio's hebben niet-overlappende adresruimten nodig die ondersteuning bieden voor VNet-peering en replicatie tussen regio's. Wijs voldoende grote bereiken toe om toekomstige toevoegingen van spokes op te vangen.

3. Netwerkbeveiligingsgroepen en toepassingsbeveiligingsgroepen

Ontwerp strikte segmentatie zodat alleen load balancer-verkeer toepassingssubnetten bereikt. Directe internettoegang tot toepassingslagen blokkeren. Gebruik toepassingsbeveiligingsgroepen (ASG's) om regels toe te passen op basis van de workloadrol in plaats van afzonderlijke IP-adressen.

Fase 2: Topologie

4. Hub-and-spoke-topologie

Implementeer een dual-hub-topologie voor meerdere regio's. Het IT-abonnement is eigenaar van zowel hub-VNets als beheert gedeelde services, zoals Azure Firewall, VPN Gateway en DNS-doorstuurservers. Toepassingsteams zijn eigenaar van hun spoke-VNets en beheren Private Link subnetten, AKS-clusters en toepassingsbronnen binnen hun toegewezen adresruimte.

5. Netwerken met meerdere regio's

Ontwerp een actief-actieve implementatie in primaire en back-upregio's. Configureer VNet-peering tussen hubs in meerdere regio's, stel failoverroutering in en plan op storingen in één regio. Beide regio's dienen tegelijkertijd verkeer, waarbij Azure Front Door aanvragen distribueert op basis van latentie en statustests.

Note

Mijlpaal: Topologie voltooid. Uw dual-hub-topologie met meerdere regio's is ingericht. Als uw toepassing alleen intern is met geen internetgerichte eindpunten, kunt u verdergaan naar stap 9 (uitgaande internettoegang) en doorgaan vanaf daar.

Wat u overslaat: Stap 6-8 omvat toegang tot inkomend internet, levering en prestaties van toepassingen en privétoegang van PaaS. Overslaan is veilig als uw workload geen openbare eindpunten en geen Private Link vereisten heeft.

Belangrijk: Zelfs interne toepassingen hebben vaak Private Link (stap 8) nodig als ze verbinding maken met Azure SQL, Azure Storage, Azure Key Vault of andere PaaS-services via privé-eindpunten. Als uw toepassing gebruikmaakt van een van deze services, voert u stap 8 uit voordat u stap 9 overslaat.

Resterende artikelen: Zes artikelen na het overslaan (stap 9-14), vergeleken met negen artikelen zonder overslaan (stap 6-14).

Fase 3: Connectiviteit

6. Inkomend internetverkeer

Klantgerichte verkeerspatronen bepalen de externe vorm van uw architectuur. Gebruik Azure Front Door voor webtoepassingen die globale taakverdeling, caching en Web Application Firewall (WAF) nodig hebben. Gebruik Azure Traffic Manager voor mobiele of API-toepassingen waarbij DNS-gebaseerde routering met statustests voldoende is.

7. Levering en prestaties van toepassingen

Kies tussen Azure Front Door en Azure Traffic Manager op basis van uw toepassingstype. Webtoepassingen profiteren van de Laag 7-mogelijkheden van Front Door: TLS-offload, caching, routering op basis van URL's en geïntegreerde WAF. Mobiele en API-back-ends maken gebruik van Traffic Manager voor failover op DNS-niveau met lagere overhead.

8. Privétoegang van PaaS

Maak Private Link subnetten in elk spoke-VNet voor PaaS-serviceconnectiviteit. Toepassingsteams beheren hun eigen privé-eindpunten: AKS haalt containerinstallatiekopieën op via Private Link, web-apps maken verbinding met Azure SQL via privé-eindpunten en geen PaaS-verkeer gaat via het openbare internet. Wijs een subnet per spoke toe voor Private Link resources.

Note

Mijlpaal: Connectiviteit voltooid. Uw ingress en privé-PaaS-connectiviteit zijn geconfigureerd.

Resterende stappen: Uitgaand verkeer (stap 9), Azure Firewall (stap 10), Web Application Firewall (stap 11), DDoS-beveiliging (stap 12), DNS-beveiliging (stap 13) en netwerkbewaking (stap 14), goed voor in totaal 6 artikelen.

Essentieel voor alle implementaties: Stappen 9-10 (uitgaand verkeer en Azure Firewall) zijn van toepassing op elke moderniseringsimplementatie. Uw hubfirewall beheert al het uitgaande verkeer en biedt gecentraliseerde inspectie, ongeacht of uw workload openbaar of alleen intern is.

Alleen openbare eindpunten: Stap 11-12 (WAF- en DDoS-beveiliging) zijn alleen van toepassing als uw toepassing openbare eindpunten beschikbaar maakt via Azure Front Door, Application Gateway of een openbare Load Balancer. Uitsluitend interne workloads kunnen deze twee artikelen overslaan en verdergaan met stap 13 (DNS-beveiliging).

9. Uitgaande internettoegang

Routeer al het uitgaande spoke-verkeer naar de hubfirewall met behulp van User-Defined Routes (UDR's). De hubfirewall fungeert als het SNAT-punt (Source Network Address Translation) voor alle uitgaande verbindingen. IT beheert de firewallregels centraal, zodat applicatieteams uitgaande beperkingen niet kunnen omzeilen.

Fase 4: Beveiliging

10. Azure Firewall

Configureer Azure Firewall in beide hub-VNets als het DNAT-punt (SNAT en Destination Network Address Translation). Al het inkomend verkeer passeert de firewall voordat de toepassingslaag wordt bereikt. Gebruik firewallbeleid om oost-westverkeer tussen spokes en noord-zuid verkeer naar internet te beheren.

11. Web Application Firewall

WAF implementeren op Azure Front Door of Azure Application Gateway voor uw webtoepassingen. WAF beschermt tegen Open Web Application Security Project (OWASP) Top 10 bedreigingen, SQL-injectie, scripting op meerdere sites en andere HTTP-laagaanvallen. Gebruik beheerde regelsets en voeg aangepaste regels toe voor de specifieke patronen van uw toepassing.

12. DDoS-beveiliging

Schakel Azure DDoS Protection in voor alle openbare IP-resources. DDoS Protection biedt altijd ingeschakelde verkeersbewaking, automatische aanvalsbeperking en garanties voor kostenbeveiliging. Combineer DDoS Protection met WAF voor gelaagde verdediging tegen volumetrische en toepassingslaagaanvallen.

13. DNS-beveiliging en privénaamomzetting

Configureer openbare DNS-zones voor uw klantgerichte domeinen met CNAME-records die verwijzen naar Azure Front Door- of Traffic Manager-eindpunten. Pas Role-Based Access Control (RBAC) toe op DNS-zones, zodat alleen geautoriseerde teams records kunnen wijzigen. Schakel DNS-beveiligingsextensies (DNSSEC) in voor zones waarvoor cryptografische validatie is vereist.

Fase 5: Bewerkingen

14. Netwerkbewaking en waarneembaarheid

Productiegereedheid vereist bewaking vanaf dag één. Schakel Azure Network Watcher in voor connectiviteitsdiagnose, netwerk Performance Monitor voor latentietracering en stroomlogboeken voor verkeersanalyse. Applicatieteams bewaken hun eigen AKS- en ASE-workloads. Het platformteam bewaakt de hubinfrastructuur en connectiviteit tussen regio's.

Voorwaardelijke artikelen

Neem deze artikelen op basis van uw specifieke vereisten op:

Condition Artikel Wanneer moet ik opnemen?
Hybride co-existentie Hybride connectiviteit Uw gemoderniseerde toepassingen moeten tijdens de overgangsperiode naast on-premises systemen bestaan
VM-beheerderstoegang nodig Toegang voor ontwikkelaars en beheerders Uw omgeving bevat VM's die beveiligde RDP-/SSH-toegang nodig hebben naast PaaS-workloads
Grote beheerde omgeving Gecentraliseerd netwerkbeheer U beheert een VNet-omgeving met meerdere abonnementen met meerdere teams die gecentraliseerde beleidsafdwinging nodig heeft
cloudoverschrijdend Connectiviteit tussen regio's en meerdere clouds Uw architectuur vereist expliciete privéconnectiviteit tussen regio's, behalve wat netwerken voor meerdere regio's bieden
Zeer kleine werkbelasting Platte netwerktopologie U hebt één workload die de complexiteit van hub-and-spoke-topologie niet rechtvaardigt

Overzicht

Door dit leespad te volgen, heeft u een netwerkarchitectuur voor PaaS-werkbelastingen ontworpen met meerdere regio's en meerdere beveiligingslagen. Uw ontwerp bevat een dual-hubtopologie met door IT beheerde gedeelde services, actief-actief multiregion met Azure Front Door of Azure Traffic Manager, Private Link connectiviteit voor PaaS-services, gecentraliseerde firewallinspectie voor alle verkeersstromen, WAF- en DDoS-beveiliging voor openbare eindpunten en DNS met RBAC en DNSSEC. Deze architectuur ondersteunt moderne toepassingspatronen terwijl gecentraliseerde beveiligingsgovernance behouden blijft.

Validatiecontrolelijst

Gebruik deze controlelijst om te controleren of uw moderniseringsnetwerkontwerp is voltooid:

  • Topologie met twee hubs uitgerold over de primaire en backupregio’s.
  • Niet-overlappende adresruimten toegewezen aan zowel regio's als toekomstige spokes.
  • Azure Front Door of Azure Traffic Manager, geconfigureerd voor globale inkomende toegang, als uw workload openbaar toegankelijk is.
  • Private Link subnetten ingericht in elk spoke-VNet dat als host fungeert voor PaaS-afhankelijkheden.
  • Gebruikersgedefinieerde routes leiden uitgaand spoke-verkeer via de hub-firewall.
  • Azure Firewall ingezet in beide hub-VNets voor inspectie van inkomend verkeer, oost-westverkeer en uitgaand verkeer.
  • WAF-beleid dat is toegepast op openbare webeindpunten, indien van toepassing.
  • DDoS Protection ingeschakeld voor openbare IP-resources, indien van toepassing.
  • DNS-zones en privé-DNS-resolutie die zijn geconfigureerd voor privé-eindpunten.
  • Network Watcher, stroomlogboeken en bewaking van connectiviteit tussen regio's ingeschakeld.

Volgende stappen 

  • Last updated on