Implementieren eines sicheren Hybridnetzwerks

Firewall
Load Balancer
Virtual Machines
Virtual Network

Diese Referenzarchitektur zeigt ein sicheres Hybridnetzwerk, das ein lokales Netzwerk in Azure erweitert. Die Architektur implementiert eine DMZ, auch als Umkreisnetzwerk bezeichnet, zwischen dem lokalen Netzwerk und einem virtuellen Azure-Netzwerk. Sämtlicher eingehender und ausgehender Datenverkehr durchläuft die Azure Firewall.

Sichere Hybrid-Netzwerkarchitektur

Laden Sie eine Visio-Datei dieser Architektur herunter.

Referenzbereitstellung

Bei dieser Bereitstellung werden zwei Ressourcengruppen erstellt: die erste enthält ein simuliertes lokales Netzwerk, und das zweite einen Satz mit Hub-and-Spoke-Netzwerken. Das simulierte lokale Netzwerk und das Hub-Netzwerk werden mit Azure Virtual Network-Gateways verbunden, um eine Site-to-Site-Verbindung zu ermöglichen. Diese Konfiguration weist eine starke Ähnlichkeit mit der Verbindungsherstellung für Ihr lokales Rechenzentrum mit Azure auf.

Der Bereitstellungsvorgang kann bis zu 45 Minuten dauern. Die empfohlene Bereitstellungsmethode ist die unten beschriebene Nutzung der Option über das Portal.

Verwenden Sie die folgende Schaltfläche, um die Referenz mithilfe des Azure-Portals bereitzustellen.

In Azure bereitstellen

Überprüfen Sie nach Abschluss der Bereitstellung die Site-to-Site-Konnektivität, indem Sie sich die neu erstellten Verbindungsressourcen ansehen. Suchen Sie im Azure-Portal nach „Verbindungen“, und achten Sie jeweils auf den Status der einzelnen Verbindungen.

Screenshot: Status von Verbindungen

Auf die IIS-Instanz im Spoke-Netzwerk kann über den virtuellen Computer zugegriffen werden, der sich im simulierten lokalen Netzwerk befindet. Erstellen Sie eine Verbindung mit dem virtuellen Computer, indem Sie den vorhandenen Azure Bastion-Host verwenden, öffnen Sie einen Webbrowser, und navigieren Sie zur Adresse des Netzwerk-Lastenausgleichsmoduls für die Anwendung.

Ausführliche Informationen und zusätzliche Bereitstellungsoptionen finden Sie in den ARM-Vorlagen, die für die Bereitstellung dieser Lösung verwendet werden.

Anwendungsfälle

Für diese Architektur ist eine Verbindung mit Ihrem lokalen Rechenzentrum erforderlich, entweder mithilfe eines VPN-Gateways oder einer ExpressRoute-Verbindung. Typische Einsatzmöglichkeiten für diese Architektur sind:

  • Hybridanwendungen, in denen Workloads teilweise lokal und teilweise in Azure ausgeführt werden.
  • Infrastruktur, die eine differenzierte Kontrolle des aus einem lokalen Rechenzentrum in ein virtuelles Azure-Netzwerk eingehenden Datenverkehrs erfordert.
  • Anwendungen, die ausgehenden Verkehr überwachen müssen. Dies ist ein oftmals auf behördliche Bestimmungen zurückgehendes Erfordernis vieler kommerzieller Systeme und kann dabei helfen, die Offenlegung privater Informationen zu verhindern.

Aufbau

Die Architektur umfasst die folgenden Komponenten.

  • Lokales Netzwerk. Ein privates lokales Netzwerk innerhalb einer Organisation.

  • Virtuelles Azure-Netzwerk. Das virtuelle Netzwerk hostet die Anwendung und weitere Ressourcen, die in Azure ausgeführt werden.

  • Gateway: Das Gateway stellt Verbindungen zwischen den Routern im lokalen Netzwerk und dem virtuellen Netzwerk bereit. Das Gateway befindet sich in einem eigenen Subnetz.

  • Azure Firewall. Die Azure Firewall ist eine verwaltete Firewall, die als Dienst eingesetzt wird. Die Firewallinstanz befindet sich in einem eigenen Subnetz.

  • Virtuelle Netzwerkrouten. Virtuelle Netzwerkrouten definieren den IP-Datenverkehrsfluss innerhalb des virtuellen Azure-Netzwerks. Es gibt zwei benutzerdefinierte Routingtabellen, wie im Diagramm oben dargestellt.

    • Im Gatewaysubnetz wird der an das Subnetz der Webschicht (10.0.1.0/24) gesendete Datenverkehr über die Azure Firewall-Instanz weitergeleitet.
    • Da es im Subnetz in der Webschicht keine Route für den Adressraum des VNET gibt, die auf Azure Firewall verweist, können Instanzen in der Webschicht direkt miteinander kommunizieren (d. h. nicht über Azure Firewall).

    Hinweis

    Je nach den Anforderungen Ihrer VPN-Verbindung können Sie BGP-Routen (Border Gateway Protocol) konfigurieren, um die Weiterleitungsregeln zu implementieren, die Datenverkehr zurück durch das lokale Netzwerk leiten.

  • Netzwerksicherheitsgruppen. Verwenden Sie Sicherheitsgruppen, um den Netzwerkdatenverkehr im virtuellen Netzwerk zu beschränken. Bei der Bereitstellung in dieser Referenzarchitektur lässt beispielsweise das Subnetz der Webschicht TCP-Datenverkehr aus dem lokalen und dem virtuellen Netzwerk zu, die Geschäftsschicht lässt Datenverkehr aus der Webschicht zu, und die Datenschicht lässt Datenverkehr aus der Geschäftsschicht zu.

  • Bastion. Azure Bastion ermöglicht Ihnen, sich über SSH oder RDP (Remotedesktopprotokoll) bei den VMs im virtuellen Netzwerk anzumelden, ohne die VMs direkt im Internet verfügbar zu machen. Mit Bastion können Sie die VMs im virtuellen Netzwerk verwalten.

Empfehlungen

Die folgenden Empfehlungen gelten für die meisten Szenarios. Sofern Sie keine besonderen Anforderungen haben, die Vorrang haben, sollten Sie diese Empfehlungen befolgen.

Empfehlungen für die Zugriffssteuerung

Verwenden Sie die rollenbasierte Zugriffssteuerung in Azure (Azure Role-Based Access Control, Azure RBAC), um die Ressourcen in Ihrer Anwendung zu verwalten. Ziehen Sie die Erstellung der folgenden benutzerdefinierten Rollen in Erwägung:

  • Eine DevOps-Rolle mit Berechtigungen zum Verwalten der Infrastruktur für die Anwendung, zum Bereitstellen der Anwendungskomponenten und zum Überwachen und Neustarten von VMs.

  • Eine zentrale IT-Administratorrolle zum Verwalten und Überwachen von Netzwerkressourcen.

  • Eine IT-Sicherheitsadministratorrolle zum Verwalten der sicheren Netzwerkressourcen, wie etwa der Firewall.

Die DevOps- und IT-Administratorrollen sollten keinen Zugriff auf die Firewallressourcen haben. Dieser sollte auf die IT-Sicherheitsadministratorrolle beschränkt sein.

Empfehlungen für Ressourcengruppen

Azure-Ressourcen wie VMs, virtuelle Netzwerke und Lastenausgleichsmodule können durch Zusammenfassung in Ressourcengruppen ganz einfach verwaltet werden. Weisen Sie jeder Ressourcengruppe Azure-Rollen zu, um den Zugriff einzuschränken.

Es empfiehlt sich, die folgenden Ressourcengruppen zu erstellen:

  • Eine Ressourcengruppe, die das virtuelle Netzwerk (ohne die VMs), die Netzwerksicherheitsgruppen und die Gatewayressourcen für die Verbindung mit dem lokalen Netzwerk enthält. Weisen Sie dieser Ressourcengruppe die zentrale IT-Administratorrolle zu.
  • Eine Ressourcengruppe, die die VMs für die Azure Firewall-Instanz und benutzerdefinierten Routen für das Gatewaysubnetz enthält. Weisen Sie dieser Ressourcengruppe die IT-Sicherheitsadministratorrolle zu.
  • Getrennte Ressourcengruppen für jede Logikschicht, die das Lastenausgleichsmodul und die VMs enthalten. Beachten Sie, dass diese Ressourcengruppen nicht die Subnetze für die einzelnen Schichten enthalten sollten. Weisen Sie dieser Ressourcengruppe die DevOps-Rolle zu.

Netzwerkempfehlungen

Um eingehenden Datenverkehr aus dem Internet zuzulassen, fügen Sie der Azure Firewall eine Regel für die Zielnetzwerk-Adressübersetzung (Destination Network Address Translation, DNAT) hinzu.

  • Zieladresse = öffentliche IP-Adresse der Firewallinstanz
  • Übersetzte Adresse = private IP-Adresse innerhalb des virtuellen Netzwerks

Die Beispielbereitstellung leitet Internetdatenverkehr für Port 80 an das Lastenausgleichsmodul der Webschicht.

Verwenden Sie die Tunnelerzwingung für den gesamten ausgehenden Internetdatenverkehr durch Ihr lokales Netzwerk, indem Sie einen Site-zu-Site-VPN-Tunnel verwenden, und nutzen Sie für die Weiterleitung ins Internet die Netzwerkadressenübersetzung (Network Address Translation, NAT). Dadurch wird die versehentliche Offenlegung jeglicher vertraulicher Informationen verhindert, die in Ihrer Datenschicht gespeichert sind, und zugleich die Untersuchung und Überwachung des gesamten ausgehenden Verkehrs ermöglicht.

Blockieren Sie nicht den gesamten Internetverkehr aus den Logikschichten, da diese Schichten dadurch auch an der Verwendung von Azure PaaS-Diensten gehindert werden, die öffentliche IP-Adressen benötigen, wie etwa die VM-Diagnoseprotokollierung, das Herunterladen von VM-Erweiterungen sowie weitere Funktionen. Für Azure-Diagnose ist außerdem erforderlich, dass Komponenten Lese- und Schreibzugriff auf ein Azure Storage-Konto besitzen.

Überprüfen Sie, ob der ausgehende Internetdatenverkehr ordnungsgemäß zwangsweise getunnelt wird. Wenn Sie eine VPN-Verbindung mit dem Routing- und RAS-Dienst auf einem lokalen Server verwenden, setzen Sie ein Tool wie WireShark ein.

Verwenden Sie ggf. Application Gateway oder Azure Front Door für die SSL-Beendigung.

Überlegungen zur Skalierbarkeit

Weitere Informationen über die Bandbreitengrenzwerte von VPN Gateway finden Sie unter Gateway-SKUs. Für größere Bandbreiten können Sie das Upgrade auf ein ExpressRoute-Gateway in Erwägung ziehen. ExpressRoute stellt bis zu 10 Gb/s Bandbreite mit geringerer Latenz als eine VPN-Verbindung zur Verfügung.

Weitere Informationen zur Skalierbarkeit von Azure-Gateways finden Sie im Abschnitt mit den Überlegungen zur Skalierbarkeit in Implementieren einer sicheren Hybrid-Netzwerkarchitektur mit Azure und lokalem VPN und Implementieren einer Hybrid-Netzwerkarchitektur mit Azure ExpressRoute.

Überlegungen zur Verfügbarkeit

Wenn Sie Azure ExpressRoute verwenden, um eine Verbindung zwischen dem virtuellen und dem lokalen Netzwerk bereitzustellen, konfigurieren Sie ein VPN-Gateway zur Failoverbereitstellung für den Fall, dass die ExpressRoute-Verbindung nicht verfügbar ist.

Spezifische Informationen zum Aufrechterhalten der Verfügbarkeit von VPN- und ExpressRoute-Verbindungen finden Sie in den Überlegungen zur Verfügbarkeit in Implementieren einer sicheren Hybrid-Netzwerkarchitektur mit Azure und lokalem VPN und Implementieren einer Hybrid-Netzwerkarchitektur mit Azure ExpressRoute.

Überlegungen zur Verwaltbarkeit

Wenn die Gatewaykonnektivität zwischen Ihrem lokalen Netzwerk und Azure unterbrochen ist, können Sie die VMs im virtuellen Azure-Netzwerk weiterhin über Azure Bastion erreichen.

Das Subnetz jeder einzelnen Schicht in der Referenzarchitektur wird durch NSG-Regeln geschützt. Möglicherweise müssen Sie eine Regel zum Öffnen von Port 3389 für RDP-Zugriff (Remote Desktop Protocol) auf Windows-VMs oder Port 22 für SSH-Zugriff (Secure Shell) auf Linux-VMs erstellen. Andere Verwaltungs- und Überwachungstools erfordern möglicherweise Regeln zum Öffnen zusätzlicher Ports.

Wenn Sie die Konnektivität zwischen Ihrem lokalen Rechenzentrum und Azure mithilfe von ExpressRoute bereitstellen, verwenden Sie das Azure Connectivity Toolkit (AzureCT) für die Überwachung und Problembehandlung von Verbindungsproblemen.

Weitere Informationen zum Überwachen und Verwalten von VPN- und ExpressRoute-Verbindungen finden Sie im Artikel Erweitern eines lokalen Netzwerks per VPN.

Sicherheitshinweise

Diese Referenzarchitektur implementiert mehrere Sicherheitsebenen.

Routen aller lokalen Benutzeranforderungen durch eine Azure Firewall

Die benutzerdefinierte Route im Gatewaysubnetz blockiert alle Benutzeranforderungen, die nicht aus dem lokalen Netzwerk stammen. Die Route übergibt zulässige Anforderungen an die Firewall, und diese werden an die Anwendung weitergeleitet, wenn sie aufgrund der Firewallregeln zulässig sind. Sie können weitere Routen hinzufügen, achten Sie jedoch darauf, dass diese nicht nicht unabsichtlich die Firewall umgehen oder Verwaltungsdatenverkehr für das Verwaltungssubnetz blockieren.

Verwenden Sie NSGs, um den Datenverkehr zwischen Logikschichten zu blockieren/übergeben

Der Datenverkehr zwischen den Schichten wird mithilfe von NSGs eingeschränkt. Die Geschäftsschicht blockiert jeglichen Verkehr, der nicht aus der Webschicht stammt, und die Datenschicht blockiert jeglichen Verkehr, der nicht aus der Geschäftsschicht stammt. Wenn bei Ihnen das Erfordernis besteht, die NSG-Regeln zu erweitern, um einen breiteren Zugriff auf diese Schichten zuzulassen, wägen Sie diese Erfordernisse gegen die Sicherheitsrisiken ab. Jeder neue eingehende Kommunikationsweg stellt eine Gelegenheit für die zufällige oder absichtliche Offenlegung von Daten oder Beschädigung von Anwendungen dar.

DevOps-Zugriff

Verwenden Sie Azure RBAC, um die Vorgänge einzuschränken, die DevOps auf den einzelnen Ebenen ausführen kann. Verwenden Sie beim Erteilen von Berechtigungen den Ansatz der geringsten Rechte. Protokollieren Sie alle Verwaltungsvorgänge, und führen Sie regelmäßig Überwachungen durch, um sicherzustellen, dass alle Konfigurationsänderungen auf Planung beruhen.

Kostenbetrachtung

Verwenden Sie den Azure-Preisrechner, um die voraussichtlichen Kosten zu ermitteln. Weitere Überlegungen finden Sie im Microsoft Azure Well-Architected Framework unter Grundsätze der Kostenoptimierung.

Hier sind die Überlegungen zu den Kosten für die Dienste angegeben, die in dieser Architektur verwendet werden.

Azure Firewall

In dieser Architektur wird Azure Firewall im virtuellen Netzwerk bereitgestellt, um den Datenverkehr zwischen dem Subnetz des Gateways und dem Subnetz, in dem die Logikschicht ausgeführt wird, zu steuern. Bei diesem Ansatz ist Azure Firewall kostengünstig, weil eine gemeinsame Lösung für mehrere Workloads verwendet wird. Hier sind die Preismodelle für Azure Firewall angegeben:

  • Festpreis pro Bereitstellungsstunde.
  • Verarbeitete Daten pro GB zur Unterstützung der automatischen Skalierung.

Im Vergleich zu virtuellen Netzwerkgeräten (Network Virtual Appliances, NVAs) können Sie mit Azure Firewall Kosten in Höhe von bis zu 30 - 50 % sparen. Weitere Informationen finden Sie in der Gegenüberstellung von Azure Firewall und NVA.

Azure Bastion

Mit Azure Bastion wird per RDP und SSH eine sichere Verbindung mit Ihrem virtuellen Computer hergestellt, ohne dass auf dem virtuellen Computer eine öffentliche IP-Adresse konfiguriert werden muss.

Die Bastion-Abrechnung ist mit einem einfachen virtuellen Low-Level-Computer vergleichbar, der als Jumpbox konfiguriert ist. Im Vergleich mit einer Jumpbox ist Bastion kostengünstiger, da Bastion über integrierte Sicherheitsfeatures verfügt und keine zusätzlichen Kosten für Speicher und die Verwaltung eines separaten Servers anfallen.

Virtuelles Azure-Netzwerk

Azure Virtual Network ist kostenlos. Mit jedem Abonnement können bis zu 50 virtuelle Netzwerke in allen Regionen erstellt werden. Der gesamte Datenverkehr, der innerhalb der Grenzen einer Virtual Network-Instanz entsteht, ist kostenlos. Für die Kommunikation zwischen zwei virtuellen Computern im gleichen VNET fallen also keine Kosten an.

Interner Lastenausgleich

Der grundlegende Lastenausgleich zwischen virtuellen Computern in demselben virtuellen Netzwerk ist kostenlos.

Bei dieser Architektur werden interne Lastenausgleichsmodule verwendet, um einen Lastenausgleich für Datenverkehr innerhalb eines virtuellen Netzwerks vorzunehmen.

Nächste Schritte