Hub-and-Spoke-Netzwerktopologie

Die Hub-and-Spoke-Netzwerktopologie ist die empfohlene Azure-Netzwerkarchitektur für Unternehmensumgebungen. Sie besteht aus einem zentralen Hub-VNet, das gemeinsam genutzte Netzwerkdienste hostet, und mehreren Spoke-VNets, die einzelne Workloads hosten. Spokes werden über VNet-Peering mit dem Hub verbunden. Diese Topologie zentralisiert Sicherheitskontrollen, reduziert die Netzwerkkomplexität und lässt sich beim Hinzufügen neuer Workloads effizient skalieren.

Das Hub-VNet ist das zentrale Netzwerk, mit dem alle Spoke-VNets verbunden sind. Es enthält typischerweise:

• Azure Firewall – zentrale Überprüfung des ausgehenden sowie des Ost-West-Datenverkehrs
• VPN Gateway oder ExpressRoute Gateway – Konnektivität mit dem lokalen Netzwerk
• Azure Bastion – sicherer RDP-/SSH-Zugriff auf VMs ohne öffentliche IP-Adressen
• Private Zonen von Azure DNS – zentrale Auflösung privater DNS-Namen
• Ressourcen zur Netzwerküberwachung – Verbindungsmonitore und Flow Logs

Jedes Spoke-VNet hostet einen einzelnen Workload oder eine Gruppe eng zusammengehöriger Workloads. Beispiele: Spoke 1 – Produktionswebanwendung; Spoke 2 – Datenanalyseplattform; Spoke 3 – Entwicklungs-/Testumgebung. Die Isolierung von Workloads in separaten Spokes schafft eine Netzwerkgrenze zwischen ihnen. Wird ein Workload kompromittiert, kann der Angreifer nicht direkt in das VNet eines anderen Workloads wechseln, ohne die Hub-Firewall zu passieren.

Hub- und Spoke-VNets werden über VNet-Peering verbunden. Dieses stellt eine private Verbindung mit geringer Latenz bereit, ohne den Datenverkehr über das öffentliche Internet zu leiten. Sie müssen Peerings in beiden Richtungen erstellen: vom Hub zum Spoke und vom Spoke zum Hub. Der Datenverkehr zwischen Spokes wird nicht direkt weitergeleitet, sondern läuft über den Hub. Dadurch kann die Hub-Firewall die Kommunikation zwischen den Spokes überprüfen und steuern.

Standardmäßig erzwingt VNet-Peering nicht, dass der Datenverkehr über die Azure Firewall geleitet wird – er wird direkt zwischen den VNets geroutet. Um Datenverkehr zwischen Spokes sowie von Spokes ins Internet über die Hub-Firewall zu überprüfen, müssen Sie in jedem Spoke-Subnetz User Defined Routes (UDRs) konfigurieren, die das Standardgateway (0.0.0.0/0) auf die private IP-Adresse der Firewall verweisen. Dadurch wird sichergestellt, dass der gesamte ausgehende Datenverkehr der Spokes von der zentralisierten Firewall gefiltert wird.

Azure Firewall im Hub-VNet stellt zentrale Netzwerksicherheit für alle Spokes bereit. Sie unterstützt:

• Netzwerkregeln – Zulassen oder Blockieren nach IP-Adresse, Port und Protokoll
• Anwendungsregeln – Zulassen oder Blockieren nach FQDN und HTTP-Kategorie
• DNAT-Regeln – Übersetzen eingehender öffentlicher IP-Adressen in private IP-Adressen von Backends
• Threat Intelligence – Blockieren des Datenverkehrs zu und von bekannten schädlichen IP-Adressen und Domänen

Eine einzelne Azure Firewall kann alle Spoke-VNets bedienen. Dadurch werden die Kosten und der Verwaltungsaufwand für die Bereitstellung einzelner Firewalls pro Spoke reduziert.

Zentralisiertes DNS ist in einer Hub-and-Spoke-Architektur entscheidend. Stellen Sie private Zonen von Azure DNS bereit, die mit dem Hub-VNet verknüpft sind, und konfigurieren Sie die Spoke-VNets so, dass sie die DNS-Server des Hubs verwenden (oder das von Azure bereitgestellte DNS mit automatischer Registrierung). Dadurch können VMs in allen Spokes gegenseitig ihre Namen sowie die Namen von Azure-PaaS-Diensten über private Endpunkte mit einer konsistenten DNS-Konfiguration auflösen.

Ein wesentlicher Vorteil von Hub-and-Spoke besteht darin, dass die Konnektivität mit dem lokalen Netzwerk im Hub zentralisiert ist. Ein einzelnes VPN Gateway oder ExpressRoute Gateway im Hub-VNet stellt die Verbindung aller Spoke-Workloads zu lokalen Systemen bereit. Spoke-Workloads benötigen keine eigenen Gateways, sondern greifen über das Hub-Gateway und das Peering auf lokale Ressourcen zu. Das reduziert Kosten und Komplexität erheblich.

Hub-and-Spoke lässt sich auf natürliche Weise skalieren: Das Hinzufügen eines neuen Workloads bedeutet, ein neues Spoke-VNet zu erstellen, es per Peering mit dem Hub zu verbinden und die UDR anzuwenden, um den Datenverkehr über die Hub-Firewall zu leiten. Die Hub-Dienste (Firewall, Gateway, DNS, Bastion) werden von allen Spokes gemeinsam genutzt. Azure Virtual WAN ist der verwaltete Hub-and-Spoke-Dienst von Microsoft, der Peering, Routing und Gatewayverwaltung für sehr große Bereitstellungen mit vielen Spoke-VNets automatisiert.

Ein flaches Netzwerk (ein einzelnes großes VNet mit allen Ressourcen in Subnetzen) ist anfangs einfacher, wird aber bei zunehmender Größe schwierig zu verwalten und abzusichern. In einem flachen Netzwerk verwenden alle Workloads denselben Adressraum und werden lediglich durch NSGs voneinander getrennt. Hub-and-Spoke bietet eine stärkere Isolierung (VNet-Grenzen lassen sich schwerer überwinden als NSG-Regeln), zentrale Sicherheitskontrollen und eine klarere Governance, da jeder Spoke unabhängig verwaltet werden kann.

Die wichtigsten Kosten von Hub-and-Spoke zusätzlich zu den Workload-Ressourcen sind:

• Azure Firewall – Abrechnung pro Bereitstellungsstunde zuzüglich einer Gebühr für die Datenverarbeitung
• VPN-/ExpressRoute-Gateway – Abrechnung pro Gateway-Stunde zuzüglich Bandbreitenkosten
• VNet-Peering – Abrechnung pro GB der über Peering-Verbindungen übertragenen Daten

Trotz dieser Kosten ist die Zentralisierung von Diensten im Hub in der Regel günstiger, als in jedem Spoke separate Firewalls, Gateways und DNS-Server bereitzustellen.

Testen Sie Ihr Verständnis der Konzepte aus Microsoft Azure Fundamentals (AZ-900), die in dieser Lektion behandelt wurden.

In dieser Lektion haben Sie gelernt: Die Hub-and-Spoke-Topologie zentralisiert gemeinsam genutzte Netzwerkdienste (Firewall, Gateway, DNS) in einem Hub-VNet, während sich die Workloads in separaten Spoke-VNets befinden. VNet-Peering verbindet die Spokes mit dem Hub, wobei UDRs den Datenverkehr über die Hub-Firewall leiten. Die Topologie lässt sich durch die gemeinsame Nutzung von Plattformdiensten über alle Spokes hinweg effizient skalieren. Als Nächstes untersuchen wir das Design von Identität und Zugriff in Unternehmen mit RBAC und Privileged Identity Management.