Sichere Netzwerke in Azure designen
Nichts ist wie es scheint
Veröffentlicht in Ausgabe 04/2026 - SCHWERPUNKT
Die Migration und der Betrieb von Netzwerken in Microsoft Azure erfordern weit mehr als nur den Austausch physischer Hardware gegen virtuelle Äquivalente. Es handelt sich um einen grundlegenden Wechsel in der Art und Weise, wie Admins Konnektivität definieren, verwalten und absichern. Während On-Premises-Netzwerke durch die Physik von Kabeln, Switches und Layer-2-Protokollen geprägt sind, existiert das Azure-Netzwerk als rein logische Abstraktion. Viele IT-Verantwortliche stehen daher vor der Herausforderung, dass sich über Jahre verinnerlichte Konzepte von VLAN-Tagging bis zur ARP-Tabelle nicht ohne Weiteres in die Cloud übertragen lassen.
In Azure gibt es keine Switches, auf die Sie zugreifen können, und keine physischen Kabel, die Sie patchen. Die Plattform ist im Kern ein Layer-3-Netzwerk, das Layer-2-Funktionalitäten lediglich simuliert, um Kompatibilität für Betriebssysteme sicherzustellen. Daraus entsteht eine technisch perfekte Illusion: Sendet eine VM ein Ethernet-Frame, wird dieses nicht wie gewohnt durch das Netzwerk geflutet. Stattdessen übernimmt eine Softwareschicht die Kontrolle, kapselt das Paket und steuert den Transport über den Backbone, vollständig losgelöst von klassischen Ethernet-Regeln.
Diese Abstraktion hat spürbare Auswirkungen auf Design und Troubleshooting. Das gewohnte "Rufen in den Raum" per Broadcast oder Multicast funktioniert standardmäßig nicht oder zumindest grundlegend anders. Ein klassischer ARP-Request erreicht nicht alle Nachbarn im Subnetz, sondern wird von der Fabric abgefangen und direkt beantwortet.
Die Migration und der Betrieb von Netzwerken in Microsoft Azure erfordern weit mehr als nur den Austausch physischer Hardware gegen virtuelle Äquivalente. Es handelt sich um einen grundlegenden Wechsel in der Art und Weise, wie Admins Konnektivität definieren, verwalten und absichern. Während On-Premises-Netzwerke durch die Physik von Kabeln, Switches und Layer-2-Protokollen geprägt sind, existiert das Azure-Netzwerk als rein logische Abstraktion. Viele IT-Verantwortliche stehen daher vor der Herausforderung, dass sich über Jahre verinnerlichte Konzepte von VLAN-Tagging bis zur ARP-Tabelle nicht ohne Weiteres in die Cloud übertragen lassen.
In Azure gibt es keine Switches, auf die Sie zugreifen können, und keine physischen Kabel, die Sie patchen. Die Plattform ist im Kern ein Layer-3-Netzwerk, das Layer-2-Funktionalitäten lediglich simuliert, um Kompatibilität für Betriebssysteme sicherzustellen. Daraus entsteht eine technisch perfekte Illusion: Sendet eine VM ein Ethernet-Frame, wird dieses nicht wie gewohnt durch das Netzwerk geflutet. Stattdessen übernimmt eine Softwareschicht die Kontrolle, kapselt das Paket und steuert den Transport über den Backbone, vollständig losgelöst von klassischen Ethernet-Regeln.
Diese Abstraktion hat spürbare Auswirkungen auf Design und Troubleshooting. Das gewohnte "Rufen in den Raum" per Broadcast oder Multicast funktioniert standardmäßig nicht oder zumindest grundlegend anders. Ein klassischer ARP-Request erreicht nicht alle Nachbarn im Subnetz, sondern wird von der Fabric abgefangen und direkt beantwortet.
Das logische Netzwerk steuert alles
Um Azure Networking wirklich zu beherrschen, müssen Sie akzeptieren, dass das Konzept eines Netzwerks in der Cloud eine nützliche Illusion ist. Im Kern jedes Azure-Datacenters arbeiten massive Cluster aus physischen Servern, die über eine redundante Clos-Topologie (mehrstufige Schaltarchitektur zur Minimierung von Bandbreitenengpässen) verbunden sind. Diese Schicht bleibt für Sie jedoch vollständig abstrahiert.
Hier greift die Trennung zwischen Physical und Logical Networks. Sendet Ihre VM ein Paket mit der Absenderadresse "10.0.1.5" (Customer Address, CA), ist diese IP im physischen Backbone des Datacenters völlig unbekannt. Das System kapselt das Paket bereits im Host in ein Transportpaket mit der IP-Adresse des physischen Servers (Provider Address, PA). Die Router im Backbone kennen keine einzelnen VMs, sondern ausschließlich die Hosts. Diese Entkopplung erklärt, warum Sie IP-Bereiche frei wählen können, selbst wenn sie sich mit denen anderer Kunden überschneiden.
Der zentrale Akteur ist dabei nicht der Switch im Rack, sondern die Erweiterung der Virtual Filtering Platform (VFP) im Hyper-V-Host. VFP fungiert als programmierbarer vSwitch und arbeitet als Match-Action-Pipeline. Bevor ein Paket die virtuelle Netzwerkkarte (vNIC) der VM verlässt, fängt VFP es ab. An dieser Stelle greifen sämtliche Regeln des Software-defined Networks: Network Security Groups (NSGs), User Defined Routes (UDRs) und NAT-Regeln werden direkt an der Quelle durchgesetzt.
Das erklärt die Effizienz von Azure-Sicherheitsgruppen, denn unerwünschter Traffic verlässt den Host gar nicht erst. Nach der Prüfung kapselt der Host das Paket und transportiert es durch den Tunnel zum Zielhost, wo es entpackt und zugestellt wird. Für die VM verhält sich dieser Prozess wie klassisches Ethernet, für Azure ist es hochgradig orchestriertes Routing.
Dieser Mechanismus entlarvt auch die sogenannte "DHCP-Lüge": In lokalen Netzwerken betreiben Administratoren dedizierte DHCP-Server, die auf Broadcasts reagieren. Da Azure Broadcasts im Overlay-Netzwerk blockiert oder unterdrückt, funktioniert dieses Verfahren dort nicht nativ.
Dennoch steht die VM auf "IP automatisch beziehen". Beim Booten sendet sie einen DHCP-Discover, den der Host-Agent abfängt, noch bevor er das virtuelle Kabel verlässt. Der Agent fragt eine lokale Datenbank ab, die der zentrale Fabric Controller pflegt, ermittelt die für diese MAC-Adresse vorgesehene IP-Adresse und injiziert die Antwort direkt in die VM. Ein klassischer DHCP-Server existiert dabei nicht. Der Vorgang ist ein bewusstes Konstrukt, das sicherstellt, dass die IP-Zuweisung im Backend statisch verankert bleibt, während das Betriebssystem von einer dynamischen Vergabe ausgeht.
Im Zusammenhang mit dieser Kommunikation stoßen Administratoren früher oder später auf eine IP-Adresse, die in keiner eigenen Subnetzdokumentation auftaucht, aber allgegenwärtig ist: "168. 63.129.16". Diese Adresse ist kein Zufall, sondern eine virtuelle öffentliche IP, über die Microsoft zentrale Infrastrukturdienste in jedes VNET einbindet. Sie fungiert als DHCP-Relay, als DNS-Resolver, sofern keine eigenen Server definiert sind, und als Ziel für den Heartbeat des Guest Agents. Auch die Health Probes des "Azure Load Balancer" stammen von dieser Adresse.
Netzwerksegmentierung über VLAN-Grenzen hinaus
Während sich On-Premises-Umgebungen über Jahrzehnte auf VLANs als harte Sicherheitsgrenzen verlassen haben, bricht Azure dieses Prinzip konsequent auf. Ein Virtual Network (VNet) ist keine Broadcast-Domäne, sondern lediglich ein logischer Container für IP-Adressbereiche. Ein Subnetz isoliert in Azure standardmäßig nichts.
Das Grundprinzip lautet "offen per Default". Legen Sie in einem VNet mehrere Subnetze wie Web, App und Datenbank an, können diese unmittelbar und ungehindert miteinander kommunizieren, ganz ohne zusätzliche Router- oder Firewallkonfiguration. Ursache ist die Systemregel "AllowVNetInBound", die in jeder neuen Umgebung aktiv ist. Wer an dieser Stelle keine expliziten Regeln definiert, erzeugt ungewollt ein flaches Netzwerk, in dem sich Angreifer lateral nahezu ungehindert bewegen können.
Die zentrale Antwort auf dieses Verhalten ist die Network Security Group (NSG). Sie fungiert als zustandsbehafteter Paketfilter auf Layer 4 und bildet das Fundament der Azure-Netzwerksicherheit. Der entscheidende Punkt ist ihre Stateful-Eigenschaft: Erlauben Sie eine ausgehende Verbindung vom Webserver zur Datenbank, passieren die Antwortpakete automatisch die eingehende Richtung, ohne dass dafür eine separate Regel notwendig ist.
NSGs lassen sich auf Subnetze anwenden, was für eine grobe Trennung sinnvoll ist. Ihre eigentliche Stärke entfalten sie jedoch direkt an der Netzwerkkarte (vNIC) der VM. Damit wandert die Firewall vom Rand der Infrastruktur direkt an den Workload selbst. Genau hier beginnt Mikrosegmentierung als architektonisches Prinzip.
Starre IP-Regeln durch Rollen ersetzen
IP-Adressen sind in der Cloud nicht stabil. VMs skalieren, werden neu bereitgestellt oder verschoben, IPs ändern sich. NSG-Regeln auf Basis fester IP-Adressen führen deshalb schnell zu hohem Pflegeaufwand und Fehlern. Application Security Groups (ASGs) schaffen hier die notwendige Abstraktion. Statt IP-Adressen zu referenzieren, ordnen Sie VMs logischen Rollen wie "Webserver" oder "Datenbank" zu. Sicherheitsregeln werden damit semantisch lesbar formuliert, etwa: Erlaube Quelle ASG-Webserver zu Ziel ASG-Datenbank auf Port 1433. Starten Sie zusätzliche Webserver und weisen ihnen die entsprechende ASG zu, greifen die Regeln automatisch. Die Sicherheitslogik bleibt stabil, auch wenn sich die Infrastruktur dynamisch verändert.
Definiert Segmentierung die Grenzen im Netzwerk, übernimmt Routing die gezielte Steuerung des Datenverkehrs. Azure bringt hierfür ein funktionales Standardverhalten mit, das sich für komplexere Sicherheits- und Complianceanforderungen gezielt anpassen lässt. Wer die Prioritäten im Software-defined Networking versteht, kann Traffic präzise lenken.
System Routes stellen Konnektivität sicher
Mit dem Erstellen eines virtuellen Netzwerks legt Azure automatisch eine Routingtabelle mit sogenannten System Routes an. Diese sorgen ohne weitere Konfiguration für Basiskonnektivität:
- Traffic innerhalb eines VNet wird direkt geroutet (Local).
- Datenverkehr zu gepeerten VNets fließt automatisch über das Azure-Backbone.
- Traffic ins Internet läuft standardmäßig über das Azure-Internet-Gateway.
Dieses Verhalten ermöglicht sofortige Kommunikation, widerspricht jedoch häufig den Anforderungen größerer Umgebungen, in denen ausgehender Traffic zentral kontrolliert oder inspiziert werden soll.
Für gezielte Steuerung kommen User Defined Routes (UDR) zum Einsatz, in Azure als Route Tables umgesetzt. Sie entsprechen funktional einem Policy-Based Routing. Ein typisches Szenario ist die erzwungene Führung von Internet-Traffic über eine zentrale Firewall oder Network Virtual Appliance (NVA). Durch eine Route für "0.0.0.0/0" mit der "Next Hop Virtual Appliance" überschreiben Sie den direkten Internetpfad und leiten sämtlichen ausgehenden Traffic zur Inspektion um.
Azure entscheidet anhand einer festen Prioritätsregel, welche Route zum Einsatz kommt: dem Longest Prefix Match. Existieren mehrere Routen für ein Ziel, greift immer die Route mit dem spezifischeren Adressbereich. Definieren Sie beispielsweise eine UDR für "0.0.0.0/0" zur Firewall. Parallel existiert jedoch eine System-Route für ein spezifisches Ziel wie "20.1.1.5/32", etwa für einen Service-Endpoint oder VPN-Tunnel. Da "/32" präziser ist als "/0", gewinnt die System Route und umgeht die Firewall. Dieses Verhalten ist beabsichtigt und stellt sicher, dass spezialisierte Pfade bevorzugt werden. Fließt Traffic unerwartet an der Firewall vorbei, liegt die Ursache häufig in einer spezifischeren Route.
Best Practices für Azure-Netze
Wie auch immer Sie Ihr Cloudnetzwerk in Azure umsetzen, folgende Best Practices haben sich bewährt:
- Topologie: Hub & Spoke ist der Standard für zentrale Kontrolle und konsistente Sicherheitsdurchsetzung.
- Subnetting: Planen Sie Subnetze nie kleiner als "/27", um ausreichend Reserve für die fünf von Azure reservierten IP-Adressen zu haben.
- Zero Trust: Ein VNet ist keine Vertrauens- zone. Sichern Sie Workloads konsequent mikrosegmentiert mit NSGs und ASGs ab.
- PaaS-Zugriff: Nutzen Sie Private Link, um Datenbanken und Storage vollständig vom öffentlichen Internet zu isolieren.
- Outbound-Traffic: Setzen Sie auf das NAT Gateway statt auf Loadbalancer, um SNAT Port Exhaustion zuverlässig zu vermeiden.
- Konfigurieren Sie Netzwerke niemals manuell, sondern ausschließlich über Infrastructure-as-Code mit Terraform oder Bicep.
Egress und Ingress gezielt steuern
Azure stellt eine große Anzahl an Netzwerkdiensten bereit. Ohne klare Architektur entstehen schnell unnötige Kosten und Engpässe. Sinnvoll ist eine Einordnung nach Egress beziehungsweise Ingress. Benötigen VMs ausgehenden Internetzugang, erfolgt die Adressübersetzung standardmäßig über eine öffentliche IP-Adresse, häufig die eines Loadbalancers. Eine einzelne öffentliche IP stellt jedoch nur eine begrenzte Anzahl an Ports bereit. Anwendungen mit vielen kurzlebigen Verbindungen stoßen hier schnell an Grenzen, der bekannte Effekt der "SNAT Port Exhaustion" tritt auf.
Das Azure NAT Gateway behebt dieses Problem gezielt. Es bündelt bis zu 16 öffentliche IP-Adressen und verwaltet Ports deutlich effizienter als ein Loadbalancer. Für produktive Workloads mit Internetzugang ist das NAT-Gateway heute eine grundlegende Architekturkomponente.Für eingehenden Traffic (Ingress) entscheidet das Protokoll über das passende Werkzeug:
- Azure Load Balancer (Layer 4): Ein hochperformanter Verteiler für TCP- und UDP-Traffic ohne Paketinspektion. Geeignet für interne Dienste, Datenbank-Cluster und Nicht-HTTP-Workloads.
- Application Gateway und Front Door (Layer 7): Diese Dienste verstehen HTTP(S), terminieren TLS, verarbeiten Cookies und integrieren eine Web Application Firewall. Front Door eignet sich für globale Anwendungen mit verteilten Nutzern, da es Anycast und das weltweite Microsoft-Backbone nutzt. Das Application Gateway ist auf regionale Szenarien innerhalb eines VNet ausgelegt.
Dienste für sichere Kommunikation
Die Azure Firewall ist ein verwalteter, zustandsbehafteter Firewalldienst, der typischerweise im Hub-VNet platziert wird. Der Preis wirkt auf den ersten Blick hoch, relativiert sich jedoch bei Betrachtung der Gesamtbetriebskosten. Der Betrieb eigener Appliances wie FortiGate oder Cisco erfordert in Azure eine aufwendige Hochverfügbarkeitsarchitektur mit Loadbalancern, komplexen User-defined Routes für Failover sowie regelmäßigen Betriebssystem- und Firmwareupdates, oft verbunden mit geplanten Wartungsfenstern.
Die Azure Firewall ist hingegen ein echter Platform-as-a-Service-Dienst. Skalierung erfolgt ohne Eingriff, Hochverfügbarkeit ist garantiert, und Updates laufen transparent im Hintergrund. Der Dienst steht dauerhaft bereit und entlastet den Betrieb erheblich. Zusätzlich bündelt er zentrale Funktionen wie DNS-Proxy, Threat-Intelligence-Feeds und TLS-Inspection für alle angebundenen Spokes. Wer Stabilität und planbaren Betrieb priorisiert, nimmt diese Kosten bewusst in Kauf.
Für die Anbindung an das eigene Rechenzentrum genügt ein VPN-Gateway über das öffentliche Internet häufig für Backups, Testumgebungen oder kleinere Außenstandorte. Für geschäftskritische Workloads wie SAP-Systeme oder große Datenbanken ist ExpressRoute jedoch faktisch alternativlos. Diese private MPLS-Verbindung bietet garantierte Bandbreite und ein definiertes SLA und umgeht das öffentliche Internet vollständig.
Ein häufiges Sicherheitsproblem entsteht durch den Zugriff auf Azure SQL oder Storage Accounts über öffentliche Endpoints. Service-Endpoints halten den Traffic zwar im Microsoft-Backbone, das Ziel bleibt jedoch technisch eine öffentliche Azure-IP, was Firewallregeln unnötig aufweicht. Private Link verfolgt einen anderen Ansatz: Der PaaS-Dienst erhält eine private IP-Adresse direkt aus Ihrem Subnetz, etwa "10.0.2.50". Der Zugriff erfolgt ausschließlich intern, als wäre der Dienst eine reguläre VM im eigenen Netzwerk. Aus Sicht von Zero-Trust-Architekturen ist Private Link klar überlegen, da der Dienst aus dem Internet vollständig verschwindet.
Topologie bestimmt Wartbarkeit
Noch vor dem ersten VNet stehen Sie vor einer grundlegende Architekturentscheidung: Wie sollen Netze miteinander kommunizieren? Wer ohne Konzept beginnt, erzeugt schnell ein unüberschaubares Geflecht aus Peerings, das kaum noch beherrschbar ist. In der Praxis haben sich zwei Architekturmuster etabliert.
Für die große Mehrheit der Unternehmen ist "Hub & Spoke" die sinnvollste Architektur. Ein zentrales VNet dient als Hub und beherbergt gemeinsam genutzte Dienste wie Azure Firewall, VPN- oder ExpressRoute-Gateways, Domaincontroller und Bastion-Hosts. Die einzelnen Workload-Bereiche erhalten eigene VNets als Spokes, die per VNet Peering an den Hub angebunden sind.
Der zentrale Vorteil liegt in der Kontrolle. Regeln für den Datenverkehr zwischen Entwicklungs-, Test- und Produktionsumgebungen werden an einer Stelle durchgesetzt, typischerweise an der Firewall im Hub. Die Verwaltung einzelner Peerings in großer Zahl entfällt.
Für die Kommunikation zwischen zwei Spokes existieren technisch zwei Wege: Zum einen das Routing über den Hub, bei dem User-defined Routes den Traffic über die zentrale Firewall leiten. Dies ermöglicht vollständige Kontrolle und ist die empfohlene Variante. Die Alternative ist direktes Peering zwischen Spokes. Doch diese Variante skaliert schlecht und mit wachsender Anzahl an VNets entsteht ein unüberschaubares Full-Mesh, das kaum noch wartbar ist.
Ab einer bestimmten Größenordnung mit hunderten VNets ist die manuelle Pflege von Peerings nicht mehr praktikabel. Der Azure Virtual Network Manager (AVNM) adressiert genau dieses Problem. Statt einzelne Peerings zu konfigurieren, definieren Sie Net- work Groups, etwa "Alle Produktions-VNETs". AVNM erzeugt daraus automatisch eine Mesh-Topologie, in der alle enthaltenen VNets direkt miteinander verbunden sind. Dieses Modell eignet sich für Szenarien mit höchsten Performanceanforderungen und minimaler Latenz, beispielsweise bei Datenbank-Replikationen, bei denen zentrale Firewallkontrolle nachrangig ist.
Infrastructure-as-Code als Pflicht
Das Azure-Portal erleichtert den Einstieg, ist für produktive Umgebungen jedoch kein tragfähiges Betriebsmodell. Manuell konfigurierte Netzwerke stellen ein erhebliches Risiko dar. Wird eine zentrale Resource Group gelöscht oder fällt eine gesamte Region aus, fehlt jede reproduzierbare Grundlage für den Wiederaufbau. Routingtabellen, Subnetze und NSG-Regeln lassen sich nicht verlässlich aus Erinnerung oder Screenshots rekonstruieren. Innerhalb von Azure existiert kein integrierter Backupmechanismus für Netzwerkkonfigurationen.
Infrastructure-as-Code (IaC) ändert dieses Bild grundlegend. Mit Werkzeugen wie Terraform oder Bicep liegt die gesamte Netzwerktopologie als Code vor. Ein einzelner Befehl genügt, um eine vollständige Umgebung konsistent neu aufzubauen. Disaster Recovery wird damit planbar und automatisierbar. Gleichzeitig löst IaC das Dokumentationsproblem. Statt veralteter Diagramme ist der Code selbst die verbindliche Referenz. Ob ein bestimmter Port geöffnet ist, lässt sich direkt im Repository prüfen.
Darüber hinaus basieren Entwicklungs-, Test- und Produktionsumgebungen auf identischem Code und unterscheiden sich lediglich durch Parameter wie IP-Adressbereiche. Sicherheitsregeln bleiben konsistent. Änderungen unterliegen klaren Prozessen: Anpassungen erfolgen im Code, werden per Pull Request geprüft und anschließend automatisiert ausgerollt. Jeder Eingriff ist revisionssicher nachvollziehbar und im Fehlerfall sofort rückrollbar.
Fazit
Azure Networking ist keine Evolution klassischer Netzwerke, sondern ein grundlegender Paradigmenwechsel. Wer versucht, die Cloud wie ein physisches Rechenzentrum zu betreiben, stößt unweigerlich an Grenzen. Der entscheidende Schritt besteht darin, den Verlust direkter Kontrolle über Layer 1 und Layer 2 nicht als Einschränkung, sondern als Befreiung zu begreifen. Moderne Konzepte wie Software-defined Networking, Private Link und Infrastructure-as-Code verlagern Verantwortung von manueller Konfiguration hin zu klaren, reproduzierbaren Architekturen.
(jp)