Wenden Sie Zero Trust-Prinzipien auf eine Azure Virtual WAN-Bereitstellung an

  • Artikel

Angesichts der Weiterentwicklung der modernen Cloud, mobiler Geräte und anderer Endpunkte reicht es nicht mehr aus, sich nur auf Unternehmens-Firewalls und Perimeternetzwerke zu verlassen. Eine End-to-End Zero Trust-Strategie geht davon aus, dass Sicherheitsverletzungen unvermeidlich sind. Das bedeutet, dass Sie jede Anforderung so überprüfen müssen, als ob sie aus einem unkontrollierten Netzwerk stammt. Die Vernetzung spielt bei Zero Trust nach wie vor eine wichtige Rolle, um Infrastruktur, Anwendungen und Daten zu verbinden und zu schützen. In dem Zero Trust-Modell gibt es drei wichtige Ziele, wenn es um die Sicherung Ihrer Netzwerke geht:

  • Seien Sie bereit, Angriffe zu behandeln, bevor sie auftreten.
  • Minimieren Sie das Ausmaß der Beschädigungen und wie schnell sie sich ausbreiten.
  • Erhöhen Sie die Schwierigkeiten, Ihren Cloud-Fußabdruck zu gefährden.

Azure Virtual WAN ermöglicht eine lobale Transitnetzwerkarchitektur, indem es eine allgegenwärtige Any-to-Any-Konnektivität zwischen global verteilten Sätzen von Cloud-Workloads in virtuellen Netzwerken (VNets), Zweigstellen, SaaS- und PaaS-Anwendungen und Benutzern ermöglicht. Die Einführung eines Zero Trust-Ansatzes in Azure Virtual WAN ist von entscheidender Bedeutung, um sicherzustellen, dass Ihr Backbone sicher und geschützt ist.

Dieser Artikel enthält Schritte zum Anwenden der Prinzipien von Zero Trust auf eine Azure Virtual WAN-Bereitstellung auf folgende Weise:

Zero Trust-Prinzip Definition Erfüllt von
Explizit verifizieren Authentifizieren und autorisieren Sie immer basierend auf allen verfügbaren Datenpunkten. Verwenden Sie Azure Firewall mit TLS-Inspektion (Transport Layer Security), um Risiken und Bedrohungen basierend auf allen verfügbaren Daten zu überprüfen. Die Kontrollen für den bedingten Zugriff sollen die Authentifizierung und Autorisierung durch verschiedene Datenpunkte ermöglichen, und die Azure Firewall führt keine Benutzerauthentifizierung durch.
Geringstmögliche Zugriffsberechtigungen verwenden Beschränken Sie den Benutzerzugriff mit Just-In-Time- und Just-Enough-Access (JIT/JEA), risikobasierten adaptiven Richtlinien und Datenschutz. Der Benutzerzugriff liegt außerhalb des Umfangs der Azure-Netzwerkinfrastrukturbereitstellungen. Der Einsatz von Identitätssäulenlösungen wie Privileged Access Management, Conditional Access und anderen Kontrollen ist der Weg, dieses Prinzip umzusetzen.
Von einer Sicherheitsverletzung ausgehen Minimieren Sie Auswirkungsgrad und Segmentzugriff. Überprüfen Sie die End-to-End-Verschlüsselung, und verwenden Sie Analysen, um für Transparenz zu sorgen, die Bedrohungserkennung voranzutreiben und die Abwehr zu verbessern. Jedes Spoke-VNET hat keinen Zugriff auf andere Spoke-VNets, es sei denn, der Datenverkehr wird durch die in jedem Azure Virtual WAN-Hub integrierte Firewall weitergeleitet. Die Firewall ist standardmäßig auf „Verweigern“ eingestellt und lässt nur Datenverkehr zu, der durch bestimmte Regeln zugelassen ist. Im Falle einer Kompromittierung oder eines Verstoßes gegen eine Anwendung/Workload ist die Ausbreitungsfähigkeit eingeschränkt, da die Azure Firewall eine Verkehrsprüfung durchführt und nur zulässigen Datenverkehr weiterleitet. Nur Ressourcen in derselben Workload sind von der Sicherheitsverletzung in derselben Anwendung betroffen.

Weitere Informationen zur Anwendung der Zero Trust-Prinzipien in einer Azure IaaS-Umgebung finden Sie in der Übersicht Zero Trust-Prinzipien auf die Azure-Infrastruktur anwenden.

Eine Branchendiskussion zu Zero Trust finden Sie in der NIST Special Publication 800-207.

Azure Virtual WAN

Azure Virtual WAN ist ein Netzwerkdienst, der viele Netzwerk-, Sicherheits- und Routingfunktionen auf einer einzigen Bedienoberfläche vereint. Die Hauptfeatures umfassen Folgendes:

  • Erweiterte Routing-Funktionen
  • „Bump-in-the-Wire“-Sicherheitsintegration über Azure Firewall oder unterstützte Network Virtual Appliances (NVAs) im Hub
  • Verschlüsseltes ExpressRoute

Ein Zero Trust-Ansatz für Azure Virtual WAN erfordert die Konfiguration mehrerer zugrunde liegender Dienste und Komponenten aus der zuvor aufgeführten Zero Trust-Prinziptabelle. Hier ist eine Liste der Schritte und Aktionen:

  • Stellen Sie Azure Firewall- oder unterstützte Next Generation Firewall (NGFW)-NVAs in jedem Virtual WAN-Hub bereit.
  • Konfigurieren Sie das Routing zwischen VNets und lokalem Brench-Routing, um eine Zero-Trust-Umgebung zu schaffen, indem Sie den gesamten Datenverkehr zur Überprüfung an Sicherheits-Appliances in den Hubs senden. Konfigurieren Sie das Routing, um Filterung und Schutz für bekannte Bedrohungen bereitzustellen.
  • Stellen Sie sicher, dass keine Ressourcen in den Spokes direkten Zugriff auf das Internet haben.
  • Bieten Sie Anwendungsmikrosegmentierung in Spoke-Netzwerken zusammen mit einer Ein-/Austritts-Mikroperimeter-Strategie.
  • Sorgen Sie für Beobachtbarkeit von Netzwerksicherheitsereignissen.

Referenzarchitektur

Das folgende Diagramm zeigt eine allgemeine Referenzarchitektur, die eine häufig bereitgestellte Umgebung und die Anwendung der Prinzipien von Zero Trust auf Azure Virtual WAN veranschaulicht.

Abbildung der Referenzarchitektur für Azure Virtual Desktop

Azure Virtual WAN kann in den Typen Basic und Standard bereitgestellt werden. Für die Anwendung von Zero Trust-Prinzipien für Azure Virtual WAN mit Azure Firewall oder einer NGFW ist der Typ „Standard“ erforderlich.

Die Referenzarchitektur von Azure Virtual WAN mit gesicherten Hubs umfasst Folgendes:

  • Ein einziges logisches virtuelles WAN.
  • Zwei gesicherte virtuelle Hubs, einer pro Region.
  • Eine Instanz von Azure Firewall Premium, die in jedem Hub bereitgestellt wird.
  • Mindestens eine Azure Firewall Premium-Richtlinie.
  • Point-to-Site (P2S) und Site-to-Site (S2S) VPN- und ExpressRoute-Gateways.
  • Mit P2S, S2S und ExpressRoute verbundene Zweigstellen.
  • Ein VNET für gemeinsam genutzte Dienste, das zentrale Infrastrukturressourcen enthält, die nicht in einem Virtual WAN-Hub bereitgestellt werden können, wie z. B. benutzerdefinierte DNS-VMs oder Azure DNS Private Resolver, Active Directory Domain Services (AD DS)-Domänencontroller, Azure Bastion und andere gemeinsam genutzte Ressourcen.
  • Workload-VNets mit Azure Application Gateway, Azure Web Application Firewall (WAF) und privaten Endpunkten bei Bedarf.

Azure Virtual WAN unterstützt die Integration einer begrenzten Anzahl von Firewalls von Drittanbietern in seinen Hubs als Alternative zur nativen Azure Firewall. In diesem Artikel wird nur Azure Firewall beschrieben. Was im VNet-Shared Services-Spoke in der Referenzarchitektur enthalten ist, ist nur ein Beispiel dafür, was Sie bereitstellen könnten. Microsoft verwaltet Azure Virtual WAN-Hubs und Sie können darin nichts anderes installieren als das, was Azure Firewall und unterstützte NVAs ausdrücklich zulassen.

Diese Referenzarchitektur richtet sich nach den Architekturprinzipien, die im Cloud Adoption Framework-Artikel für Virtuelle WAN-Netzwerktopologie beschrieben werden.

Routing-Sicherheit

Die Sicherung der Routing-Weitergabe und Isolierung der lokalen Umgebung ist ein kritisches Sicherheitselement, das verwaltet werden muss.

Neben der Datenverkehr-Segmentierung ist die Routing-Sicherheit ein wichtiger Bestandteil jedes Netzwerksicherheitsdesigns. Routing-Protokolle sind ein integraler Bestandteil der meisten Netzwerke, einschließlich Azure. Sie müssen Ihre Infrastruktur vor den mit Routing-Protokollen verbundenen Risiken wie Fehlkonfigurationen oder böswilligen Angriffen schützen. Das für VPN oder ExpressRoute verwendete BGP-Protokoll bietet sehr umfangreiche Möglichkeiten, Ihr Netzwerk vor unerwünschten Routing-Änderungen zu schützen, einschließlich der Ankündigung zu spezifischer oder zu breite Routings.

Der beste Weg, Ihr Netzwerk zu schützen, besteht darin, Ihre lokalen Geräte mit geeigneten Routing-Richtlinien und Routing-Karten zu konfigurieren, um sicherzustellen, dass nur zulässige Präfixe von Azure in Ihr Netzwerk weitergegeben werden. Sie können zum Beispiel Folgendes:

  • Blockieren Sie eingehende Präfixe, die zu allgemein sind.

    Wenn Azure aufgrund einer Fehlkonfiguration damit beginnt, generische Präfixe wie 0.0.0.0/0 oder 10.0.0.0/8 zu senden, könnte es Datenverkehr anziehen, der sonst möglicherweise in Ihrem lokalen Netzwerk verbleibt.

  • Blockieren Sie eingehende Präfixe, die zu spezifisch sind.

    Unter bestimmten Umständen erhalten Sie möglicherweise einige lange IPv4-Präfixe von Azure (Netzwerkpräfixlänge 30 bis 32), die normalerweise in anderen, weniger spezifischen Präfixen enthalten und daher nicht erforderlich sind. Durch das Weglassen dieser Präfixe wird verhindert, dass Ihre lokalen Routingtabellen unnötig groß werden.

  • Blockieren Sie eingehende Präfixe, die nicht in Azure vorhanden sind, es sei denn, Sie verwenden Azure als Transitnetzwerk.

    Wenn Sie Azure nicht zum Transport des Datenverkehrs zwischen Ihren lokalen Standorten verwenden (z. B. mit Technologien wie ExpressRoute Global Reach), würde ein von Azure angekündigtes lokales Präfix auf eine Routingschleife hinweisen. Nur die Verwendung von Azure-Präfixen in Ihren lokalen Routern würde Sie vor solchen Routing-Schleifen schützen.

  • Blockieren Sie ausgehende Präfixe, die nicht lokal sind.

    Wenn Sie Ihr lokales Netzwerk nicht für die Übertragung zwischen Azure-Regionen verwenden, sollten Sie Azure kein Präfix mitteilen, das Sie nicht lokal verwenden. Wenn Sie dies nicht tun, besteht die Gefahr, dass Routing-Schleifen entstehen, insbesondere angesichts der Tatsache, dass eBGP-Implementierungen in den meisten Routern alle Präfixe auf nicht bevorzugten Links neu ankündigen. Dies hat zur Folge, dass Azure-Präfixe an Azure zurückgesendet werden, es sei denn, Sie haben eBGP-Mehrpfad konfiguriert.

Logische Architektur

Azure Virtual WAN ist eine Sammlung von Hubs und Diensten, die innerhalb eines Hubs verfügbar sind. Sie können so viele virtuelle WANs bereitstellen, wie Sie benötigen. In einem Virtual WAN-Hub gibt es mehrere Dienste wie VPN, ExpressRoute, Azure Firewall oder eine integrierte NVA eines Drittanbieters.

Das folgende Diagramm zeigt die logische Architektur der Azure-Infrastruktur für eine Azure Virtual WAN-Bereitstellung, wie im Cloud Adoption Framework dargestellt.

Abbildung der Komponenten der Azure Virtual WAN-Topologie und von Azure-Abonnements

Der Großteil der Ressourcen ist im Konnektivitätsabonnement enthalten. Sie stellen alle Virtual WAN-Ressourcen in einer einzigen Ressourcengruppe im Konnektivitätsabonnement bereit, auch wenn Sie über mehrere Regionen hinweg bereitstellen. Azure VNet-Spokes befinden sich in den Zielzonenabonnements. Wenn Sie die Azure Firewall-Richtlinie Vererbung und Hierarchie verwenden, müssen sich die übergeordnete Richtlinie und die untergeordnete Richtlinie in derselben Region befinden. Sie können eine Richtlinie, die Sie in einer Region erstellt haben, weiterhin auf einen gesicherten Hub in einer anderen Region anwenden.

Was ist in diesem Artikel enthalten?

In diesem Artikel werden die Schritte zur Anwendung der Prinzipien von Zero Trust in der gesamten Azure Virtual WAN-Referenzarchitektur beschrieben.

Schritt Task Es gelten die Zero Trust-Prinzipien
1 Erstellen Sie eine Azure Firewall-Richtlinie. Explizit verifizieren
Von einer Sicherheitsverletzung ausgehen
2 Wandeln Sie Ihre Azure Virtual WAN-Hubs in gesicherte Hubs um. Explizit verifizieren
Von einer Sicherheitsverletzung ausgehen
3 Schützen Sie Ihren Datenverkehr. Explizit verifizieren
Von einer Sicherheitsverletzung ausgehen
4 Sichern Sie Ihre Spoke-VNets. Von einer Sicherheitsverletzung ausgehen
5 Überprüfen Sie Ihre Verwendung der Verschlüsselung. Von einer Sicherheitsverletzung ausgehen
6 Sichern Sie Ihre P2S-Benutzer. Von einer Sicherheitsverletzung ausgehen
7 Konfigurieren Sie Überwachung, Prüfung und Verwaltung. Von einer Sicherheitsverletzung ausgehen

Sie müssen die Schritte 1 und 2 der Reihe nach ausführen. Die weiteren Schritte können in beliebiger Reihenfolge durchgeführt werden.

Schritt 1: Erstellen Sie eine Azure Firewall-Richtlinie

Für eigenständige Azure Firewall-Bereitstellungen in einer klassischen Hub-and-Spoke-Architektur muss mindestens eine Azure-Richtlinie in Azure Firewall Manager erstellt und den Azure Virtual WAN-Hubs zugeordnet werden. Diese Richtlinie muss vor der Umstellung eines Hubs erstellt und verfügbar gemacht werden. Sobald die Richtlinie definiert ist, wird sie in Schritt 2 auf Azure Firewall-Instanzen angewendet.

Azure Firewall-Richtlinien können in einer übergeordneten-untergeordneten Hierarchie angeordnet werden. Für ein klassisches Hub-and-Spoke-Szenario oder ein verwaltetes Azure Virtual WAN sollten Sie eine Stammrichtlinie mit einem gemeinsamen Satz IT-weiter Sicherheitsregeln definieren, um Datenverkehr zuzulassen oder zu verweigern. Anschließend könnte für jeden Hub eine untergeordnete Richtlinie definiert werden, um hubspezifische Regeln durch Vererbung zu implementieren. Dieser Schritt ist optional. Wenn die Regeln, die auf jeden Hub angewendet werden müssen, identisch sind, kann eine einzelne Richtlinie angewendet werden.

Für Zero Trust ist eine Premium Azure Firewall-Richtlinie erforderlich und sollte die folgenden Einstellungen enthalten:

  • DNS Proxy – Sie sollten Azure Firewall als benutzerdefinierten DNS-Server für Spoke-VNets konfigurieren, der das echte DNS schützt, das sich in einem Shared-Service-Spoke oder vor Ort befindet. Azure- Firewalls fungieren als DNS-Proxy, überwachen den UDP-Port 53 und leiten DNS-Anfragen an die in den Richtlinieneinstellungen angegebenen DNS-Server weiter. Für jeden Spoke müssen Sie einen DNS-Server auf der Ebene des virtuellen Netzwerks konfigurieren, der auf die interne IP-Adresse der Azure Firewall im Virtual WAN Hub verweist. Sie sollten dem benutzerdefinierten DNS keinen Netzwerkzugriff von Spokes und Verzweigungen gewähren.

  • Für die folgenden Szenarien sollte die TLS-Inspektion aktiviert werden:

    • Ausgehende TLS-Inspektion zum Schutz vor bösartigem Datenverkehr, der von einem internen Client, der in Azure gehostet wird, an das Internet gesendet wird.

    • Ost-West-TLS-Inspektion, um Datenverkehr einzubeziehen, der zu oder von lokalen Zweigstellen und zwischen Virtual WAN-Spokes geht, wodurch Ihre Azure-Workloads vor potenziellem bösartigem Datenverkehr geschützt werden, der aus Azure gesendet wird.

  • Intrusion Detection and Prevention System (IDPS) sollte im Modus „Alert and Deny“ aktiviert sein.

  • Threat Intelligence sollte im Modus „Alert and Deny“ aktiviert sein.

Im Rahmen der Richtlinienerstellung müssen Sie die erforderlichen DNAT-Regeln (Destination Network Address Translation), Netzwerkregeln und Anwendungsregeln erstellen, um nur die Netzwerkflüsse für explizit zugelassenen Datenverkehr zu aktivieren. Um die TLS-Inspektion für ausgewählte Ziele zu aktivieren, muss in der entsprechenden Anwendungsregel die Einstellung „TLS-Inspektion“ aktiviert sein. Beim Erstellen von Regeln in Regelsammlungen sollten Sie das restriktivste „Ziel“ und den „Zieltyp“ verwenden.

Schritt 2: Wandeln Sie Ihre Azure Virtual WAN-Hubs in gesicherte Hubs um.

Im Mittelpunkt des Zero Trust-Ansatzes für Azure Virtual WAN steht das Konzept des Secured Virtual WAN Hub (Secure Hub). Ein sicherer Hub ist ein Azure Virtual WAN-Hub mit integrierter Azure Firewall. Die Verwendung unterstützter Sicherheitsgeräte von Drittanbietern wird als Alternative zu Azure Firewall unterstützt, wird in diesem Artikel jedoch nicht beschrieben. Mit diesen virtuellen Appliances können Sie den gesamten Nord-Süd-, Ost-West- und Internetverkehr überprüfen.

Wir empfehlen Azure Firewall Premium für Zero Trust und konfigurieren es mit der in Schritt 1 beschriebenen Premium-Richtlinie.

Hinweis

Die Verwendung des DDoS-Schutzes wird mit einem sicheren Hub nicht unterstützt.

Weitere Informationen finden Sie unter Installieren von Azure Firewall in einem Virtual WAN-Hub.

Schritt 3: Schützen Sie Ihren Datenverkehr.

Nachdem Sie alle Ihre Azure Virtual WAN-Hubs auf sichere Hubs aktualisiert haben, müssen Sie Routing-Absicht und -Richtlinien für Zero-Trust-Prinzipien konfigurieren. Diese Konfiguration ermöglicht es der Azure Firewall in jedem Hub, Datenverkehr zwischen Spokes und Branches im selben Hub und über Remote-Hubs hinweg anzuziehen und zu prüfen. Sie sollten Ihre Richtlinien so konfigurieren, dass sowohl „Internetverkehr“ als auch „privater Datenverkehr“ über die Azure Firewall oder die NVA Ihres Drittanbieters gesendet werden. Die Option „Inter-Hub“ muss ebenfalls aktiviert sein. Im Folgenden sehen Sie ein Beispiel.

Beispiel für die Azure Firewall-Routingrichtlinie

Wenn die Routing-Richtlinie „Privater Datenverkehr“ aktiviert ist, wird der VNet-Datenverkehr in und aus dem Virtual WAN Hub, einschließlich Datenverkehr zwischen Hubs, an die Azure Firewall oder NVA des nächsten Hops weitergeleitet, die in der Richtlinie angegeben wurde. Benutzer mit Role-Based Access Control (RBAC)-Berechtigungen könnten die Virtual WAN-Routenprogrammierung für Spoke-VNets überschreiben und eine benutzerdefinierte User Defined Route (UDR) zuordnen, um die Hub-Firewall zu umgehen. Um diese Sicherheitslücke zu verhindern, sollten RBAC-Berechtigungen zum Zuweisen von UDRs zu Spoke-VNet-Subnetzen auf zentrale Netzwerkadministratoren beschränkt und nicht an die Zielzonenbesitzer der Spoke-VNets delegiert werden. Um einen UDR einem VNet oder Subnetz zuzuordnen, muss ein Benutzer über die Rolle Netzwerkmitwirkender oder eine benutzerdefinierte Rolle mit der Aktion oder Berechtigung „Microsoft.Network/routeTables/join/action“ verfügen.

Hinweis

In diesem Artikel wird Azure Firewall hauptsächlich für die Kontrolle des Internetverkehrs und des privaten Datenverkehrs betrachtet. Für den Internetverkehr kann ein unterstütztes Sicherheits-NVA eines Drittanbieters oder ein Security as a Service (SECaaS)-Drittanbieter verwendet werden. Für privaten Datenverkehr können von Drittanbietern unterstützte Sicherheits-NVAs als Alternative zu Azure Firewall verwendet werden.

Hinweis

Benutzerdefinierte Routingtabellen in Azure Virtual WAN können nicht in Verbindung mit Routing-Absichten und -Richtlinien verwendet werden und sollten nicht als Sicherheitsoption betrachtet werden.

Schritt 4: Sichern Sie Ihre Spoke-VNets.

Jeder Azure Virtual WAN-Hub kann über ein oder mehrere VNets verfügen, die mit VNet-Peering verbunden sind. Basierend auf dem Zielzonen-Modell im Cloud Adoption Framework enthält jedes VNet eine Landing Zone-Workload, Anwendungen und Dienste, die eine Organisation unterstützen. Azure Virtual WAN verwaltet die Verbindung, die Routenweitergabe und -zuordnung sowie das ausgehende und eingehende Routing, kann sich jedoch nicht auf die Intra-VNet-Sicherheit auswirken. In jedem Spoke-VNET müssen die Zero-Trust-Prinzipien entsprechend der in Wenden Sie Zero Trust-Prinzipien auf ein virtuelles Spoke-Netzwerk an veröffentlichten Leitfaden und anderen Artikeln je nach Ressourcentyp, z. B. virtuelle Maschinen und Speicher, angewendet werden. Berücksichtigen Sie die folgenden Elemente:

Da der Hub in Azure Virtual WAN von Azure gesperrt und verwaltet wird, können dort keine benutzerdefinierten Komponenten installiert oder aktiviert werden. Einige Ressourcen, die normalerweise innerhalb des Hubs bereitgestellt werden, müssen in einem klassischen Hub-and-Spoke-Modell in einem oder mehreren Spokes platziert werden, die als gemeinsam genutzte Ressourcennetzwerke fungieren. Beispiel:

  • Azure Bastion:Azure Bastion unterstützt Azure Virtual WAN, muss jedoch in einem virtuellen Spoke-Netzwerk bereitgestellt werden, da der Hub von Azure eingeschränkt und verwaltet wird. Über den Azure Bastion-Spoke können Benutzer auf Ressourcen in anderen VNets zugreifen, hierfür ist jedoch eine IP-basierte Verbindung erforderlich, die mit der Azure Bastion-Standard-SKU verfügbar ist.
  • Benutzerdefinierte DNS-Server: DNS-Serversoftware kann auf jeder virtuellen Maschine installiert werden und als DNS-Server für alle Spokes in Azure Virtual WAN fungieren. Der DNS-Server muss in einem Spoke-VNet installiert werden, das alle anderen Spokes direkt bedient, oder über die DNS-Proxy-Funktion der Azure Firewall, die in den Virtual WAN-Hub integriert ist.
  • Azure Private DNS Resolver: Die Bereitstellung eines Azure Private DNS Resolver wird in einem der Spoke-VNets unterstützt, die mit Virtual WAN-Hubs verbunden sind. Azure Firewall, das in den Virtual WAN Hub integriert ist, kann diese Ressource als benutzerdefiniertes DNS verwenden, wenn Sie die DNS-Proxy-Funktion aktivieren.
  • Private Endpoints: Dieser Ressourcentyp ist kompatibel mit Virtual WAN, muss jedoch in einem Spoke-VNet bereitgestellt werden. Dadurch wird Konnektivität zu jedem anderen virtuellen Netzwerk oder Zweig bereitgestellt, der mit demselben Virtual WAN verbunden ist, sofern die integrierte Azure Firewall den Datenfluss zulässt. Anweisungen zum Sichern des Datenverkehrs zu Private Endpoints mithilfe der in einen Virtual WAN-Hub integrierten Azure Firewall finden Sie unter Sicherer Datenverkehr für private Endpunkte in Azure Virtual WAN.
  • Azure Private DNS Zone (Links): Dieser Ressourcentyp befindet sich nicht in einem virtuellen Netzwerk, sondern muss mit diesem verlinkt sein, um ordnungsgemäß zu funktionieren. Private DNS-Zonen können nicht mit Virtual WAN-Hubs verknüpft werden. Stattdessen sollten sie mit dem Spoke-VNet verbunden werden, das benutzerdefinierte DNS-Server oder einen Azure Private DNS Resolver (empfohlen) enthält, oder direkt mit den Spoke-VNets, die die DNS-Einträge aus dieser Zone benötigen.

Schritt 5: Überprüfen Sie Ihre Verschlüsselung

Azure Virtual WAN bietet einige Funktionen zur Verkehrsverschlüsselung über seine eigenen Gateways für den Datenverkehr, der in das Microsoft-Netzwerk gelangt. Wann immer möglich, sollte die Verschlüsselung basierend auf dem Gateway-Typ aktiviert werden. Berücksichtigen Sie das folgende Standardverhalten der Verschlüsselung:

  • Das Virtual WAN S2S VPN-Gateway bietet Verschlüsselung bei Verwendung einer IPsec/IKE (IKEv1 und IKEv2) VPN-Verbindung.

  • Das Virtual WAN P2S VPN-Gateway bietet Verschlüsselung bei der Verwendung einer Benutzer-VPN-Verbindung über OpenVPN oder IPsec/IKE (IKEv2).

  • Das Virtual WAN ExpressRoute-Gateway bietet keine Verschlüsselung, daher gelten dieselben Überlegungen wie beim eigenständigen ExpressRoute-Gateway.

    • Nur für ExpressRoute-Schaltkreise, die zusätzlich zu ExpressRoute Direct bereitgestellt werden, ist es möglich, die von der Plattform bereitgestellte MACsec-Verschlüsselung zu nutzen, um die Verbindungen zwischen Ihren Edge-Routern und den Edge-Routern von Microsoft zu sichern.

    • Die Verschlüsselung könnte mithilfe einer IPsec/IKE VPN-Verbindung von Ihrem lokalen Netzwerk zu Azure über das private Peering einer Azure ExpressRoute-Verbindung hergestellt werden. Routing Intent and Policies unterstützt diese Konfiguration jetzt, wobei zusätzliche Konfigurationsschritte erforderlich sind, wie unter Encrypted ExpressRoute erläutert.

  • Für Software-Defined WAN (SD-WAN)-Geräte und NVAs von Drittanbietern, die in den Virtual WAN Hub integriert sind, müssen bestimmte Verschlüsselungsfunktionen gemäß der Dokumentation des Anbieters überprüft und konfiguriert werden.

Sobald der Datenverkehr über eines der Gateways oder ein SD-WAN/NVA in die Azure-Netzwerkinfrastruktur gelangt ist, gibt es keinen spezifischen Virtual WAN-Dienst oder eine spezielle Virtual WAN-Funktion, die Netzwerkverschlüsselung bereitstellt. Wenn der Datenverkehr zwischen einem Hub und seinem virtuellen Netzwerk sowie von Hub zu Hub unverschlüsselt ist, müssen Sie bei Bedarf eine Verschlüsselung auf Anwendungsebene verwenden.

Hinweis

Virtual WAN-Spokes unterstützen keine VNet-zu-VNet-Verschlüsselung mit Azure VPN Gateway, da ein Spoke erforderlich ist, um das Remote-Gateway des Virtual WAN-Hubs zu verwenden.

Schritt 6: Sichern Sie Ihre P2S-Benutzer

Azure Virtual WAN ist ein Netzwerkdienst, der viele Netzwerk-, Sicherheits- und Routingfunktionen auf einer einzigen Bedienoberfläche vereint. Aus Sicht der Benutzeridentität besteht der einzige Berührungspunkt mit Virtual WAN in der Authentifizierungsmethode, die verwendet wird, um eine Benutzer-P2S VPN zu ermöglichen. Es stehen mehrere Authentifizierungsmethoden zur Verfügung, wir empfehlen jedoch die Befolgung der allgemeinen Zero-Trust-Prinzipien Microsoft Entra-Authentifizierung. Mit Microsoft Entra ID können Sie verlangen, dass Mehrstufige Authentifizierung (MFA) und Bedingter Zugriff Zero Trust-Prinzipien auf Clientgeräte und Benutzeridentitäten anwenden.

Hinweis

Die Microsoft Entra-Authentifizierung ist nur für Gateways verfügbar, die das OpenVPN-Protokoll verwenden, das nur für OpenVPN-Protokollverbindungen unterstützt wird und den Azure VPN-Client erfordert.

Azure Virtual WAN und Azure Firewall bieten keine Datenverkehrsweiterleitung und -filterung basierend auf Benutzerkonto- oder Gruppennamen, aber es ist möglich, verschiedenen Benutzergruppen unterschiedliche Pools von IP-Adressen zuzuweisen. Anschließend können Sie Regeln für die integrierte Azure Firewall definieren, um Benutzer oder Gruppen basierend auf ihrem zugewiesenen P2S-IP-Adresspool einzuschränken.

Wenn Sie Ihre P2S-Benutzer anhand der Netzwerkzugriffsanforderungen in verschiedene Gruppen einteilen, empfehlen wir, sie auf Netzwerkebene zu differenzieren und sicherzustellen, dass sie nur auf eine Teilmenge des internen Netzwerks zugreifen können. Sie können mehrere IP-Adresspools für Azure Virtual WAN erstellen. Weitere Informationen finden Sie unter Konfigurieren von Benutzergruppen und IP-Adresspools für P2S-Benutzer-VPNs.

Schritt 7: Konfigurieren Sie Überwachung, Prüfung und Verwaltung

Azure Virtual WAN bietet mit Azure Monitor umfassende Überwachungs- und Diagnosefunktionen. Zusätzliche Details und Topologie können über ein gezieltes, vorgefertigtes Überwachungsdashboard im Azure-Portal mit dem Namen Azure Monitor Insights for Virtual WAN aufgerufen werden. Diese Überwachungstools sind nicht sicherheitsspezifisch. Die in jedem Virtual WAN-Hub bereitgestellte Azure Firewall bietet den Integrationspunkt für Zero Trust und Sicherheitsüberwachung. Sie müssen Diagnose und Protokollierung für Azure Firewall genauso konfigurieren wie Azure Firewalls außerhalb von Virtual WAN.

Azure Firewall bietet die folgenden Überwachungstools, die Sie verwenden sollten, um die Sicherheit und die korrekte Anwendung der Zero Trust-Prinzipien sicherzustellen:

  • Azure Firewall Policy Analytics bietet Einblicke, zentralisierte Sichtbarkeit und Kontrolle für Azure Firewall. Sicherheit erfordert, dass geeignete Firewall-Regeln vorhanden und wirksam sind, um die interne Infrastruktur zu schützen. Das Azure-Portal fasst Details zu „potenziellen bösartigen Quellen“ zusammen, die von den IDPS- und Threat Intelligence-Funktionen der Firewall-Engine generiert werden.

  • Azure Firewall Workbook bietet einen flexiblen Bereich für die Azure Firewall-Datenanalyse. Sie können Einblicke in Azure Firewall-Ereignisse gewinnen, mehr über Ihre Anwendung und Netzwerkregeln erfahren und Statistiken für Firewall-Aktivitäten über URLs, Ports und Adressen hinweg anzeigen. Wir empfehlen Ihnen dringend, regelmäßig die IDPS-Protokollstatistiken zu überprüfen und auf der Registerkarte Untersuchungen den verweigerten Datenverkehr, Quell- und Zielströme sowie den Threat Intelligence-Bericht zu überprüfen, um Firewall-Regeln zu überprüfen und zu optimieren.

Azure Firewall lässt sich auch in Microsoft Defender für Cloud und Microsoft Sentinel integrieren. Wir empfehlen Ihnen dringend, beide Tools richtig zu konfigurieren und sie für Zero Trust auf folgende Weise aktiv zu nutzen:

  • Mit der Integration von Microsoft Defender für Cloud können Sie den Gesamtstatus der Netzwerkinfrastruktur und Netzwerksicherheit an einem Ort visualisieren, einschließlich der Azure-Netzwerksicherheit für alle VNets und virtuellen Hubs, die über verschiedene Regionen in Azure verteilt sind. Auf einen Blick können Sie die Anzahl der Azure Firewalls, Firewall-Richtlinien und Azure-Regionen sehen, in denen Azure Firewalls bereitgestellt werden.
  • Eine Microsoft Sentinel Lösung für die nahtlose Azure Firewall-Integration ermöglicht die Erkennung und Abwehr von Bedrohungen. Nach der Bereitstellung ermöglicht die Lösung eine integrierte, anpassbare Bedrohungserkennung auf Basis von Microsoft Sentinel. Die Lösung umfasst außerdem eine Arbeitsmappe, Erkennungen, Suchabfragen und Playbooks.

Schulung für Administrator*innen

Die folgenden Schulungsmodule vermitteln Ihrem Team die erforderlichen Fähigkeiten, um Zero Trust-Prinzipien auf Ihre Azure Virtual WAN-Bereitstellung anzuwenden.

Einführung in Azure Virtual WAN

Training Einführung in Azure Virtual WAN
Beschreiben Sie, wie Sie mithilfe softwaredefinierter Azure Virtual WAN-Netzwerkdienste ein Weitverkehrsnetzwerk (WAN) aufbauen.

Start >

Einführung in Azure Firewall

Training Einführung in Azure Firewall
Beschreiben Sie, wie Azure Firewall Azure VNet-Ressourcen schützt, einschließlich der Azure Firewall-Funktionen, Regeln, Bereitstellungsoptionen und Verwaltung mit Azure Firewall Manager.

Start >

Einführung in Azure Firewall Manager

Training Einführung in Azure Firewall Manager
Beschreiben Sie, ob Sie Azure Firewall Manager verwenden können, um eine zentrale Verwaltung von Sicherheitsrichtlinien und Routen für Ihre cloudbasierten Sicherheitsperimeter bereitzustellen. Außerdem evaluieren Sie, ob Azure Firewall Manager zum Schutz Ihrer cloudbasierten Perimeter beitragen kann.

Start >

Entwerfen und Implementieren von Netzwerksicherheit

Training Entwerfen und Implementieren von Netzwerksicherheit
Sie erfahren, wie Sie Netzwerksicherheitslösungen wie Azure DDoS, Netzwerksicherheitsgruppen, Azure Firewall und Web Application Firewall entwerfen und implementieren.

Start >

Weitere Trainings zur Sicherheit in Azure finden Sie in den folgenden Ressourcen im Microsoft-Katalog:
Sicherheit in Azure

Nächste Schritte

Lesen Sie diese zusätzlichen Artikel zur Anwendung von Zero Trust-Prinzipien auf Azure:

References

Unter diesen Links erfahren Sie mehr über die verschiedenen in diesem Artikel erwähnten Dienste und Technologien.

Azure Virtual WAN

Sicherheitsbasispläne

Überprüfung des Well-Architected Framework

Azure-Sicherheit

Technische Illustrationen

Sie können die in diesem Artikel verwendeten Abbildungen herunterladen. Verwenden Sie die Visio-Datei, um diese Abbildungen für Ihren eigenen Gebrauch zu ändern.

PDF | Visio

Für weitere technische Illustrationen klicken Sie hier.