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

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:

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.

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 Routenrichtlinien und Routenkarten zu konfigurieren, um sicherzustellen, dass nur zulässige Präfixe von Azure in Ihr Netzwerk übertragen 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.

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.

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 zur Einbeziehung des Datenverkehrs, der zu oder von Zweigstellen vor Ort und zwischen Virtual WAN Spokes geht. Dadurch werden Ihre Azure-Workloads vor potenziell schädlichem Datenverkehr geschützt, der von innerhalb von 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.

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.

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.

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:

• Mikrosegmentierung:: Auch wenn Azure Virtual WAN ausgehenden Datenverkehr anzieht und filtert, ist die Verwendung von Netzwerksicherheitsgruppen (NSGs) und Anwendungssicherheitsgruppen (ASGs) zur Regulierung erforderlich Intra-VNet-Flüsse werden weiterhin empfohlen.

• Lokale DMZ: Eine in der zentralen Firewall im Azure Virtual WAN Hub erstellte DNAT-Regel sollte eingehenden Nicht-http- oder https-Verkehr filtern und zulassen. Eingehender HTTP- oder https-Datenverkehr sollte von einem lokalen Azure Application Gateway und der zugehörigen Web Application Firewall verwaltet werden.

  Obwohl sichere virtuelle Azure Virtual WAN-Hubs Azure DDoS Protection noch nicht unterstützen, ist die Verwendung von DDoS zum Schutz von Endpunkten mit Internetzugriff in Spoke-VNets möglich und wird dringend empfohlen. Weitere Informationen finden Sie unter Bekannte Probleme mit Azure Firewall Manager und Vergleich von virtuellem Hubnetzwerken und geschütztem virtuellen Hubs.

• Erweiterte Erkennung und Schutz von Bedrohungen: Siehe Wenden Sie Zero Trust-Prinzipien auf ein virtuelles Spoke-Netzwerk an. Die Elemente innerhalb des Spokes müssen mit Bedrohungsschutztools wie Microsoft Defender for Cloud geschützt werden.

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 in einem klassischen Hub-and-Spoke-Modell eingesetzt werden, müssen in einer oder mehreren Spokes platziert werden, die als gemeinsam genutzte Ressourcennetzwerke fungieren. Zum Beispiel:

• Azure Bastion: Azure Bastion unterstützt Azure Virtual WAN, muss aber in einem virtuellen Spokenetzwerk bereitgestellt werden, da der Hub eingeschränkt ist und von Azure 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. Routingabsichten und Routingrichtlinien unterstützen diese Konfiguration jetzt mit zusätzlichen Konfigurationsschritten, die erforderlich sind, wie in Verschlüsseltes 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.

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 eine Multi-Faktor-Authentifizierung (MFA) und bedingten Zugriff verlangen und Zero-Trust-Prinzipien auf Clientgeräte und Benutzeridentitäten anwenden.

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.

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.

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.

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.

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:

• Azure IaaS – Übersicht
  • Azure Storage
  • Virtuelle Computer
  • Spoke virtuelle Netzwerke
  • Virtuelle Hubnetzwerke
• Azure Virtual Desktop
• IaaS-Anwendungen in Amazon Web Services
• Microsoft Sentinel und Microsoft Defender XDR

References

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

Azure Virtual WAN

• Übersicht zu Azure Virtual WAN
• So konfigurieren Sie Virtual WAN-Hub-Routing-Richtlinien
• Installieren einer Azure Firewall-Instanz in einem Virtual WAN-Hub
• Was ist ein geschützter virtueller Hub?
• So konfigurieren Sie Virtual WAN-Hub-Routing-Richtlinien
• Tutorial: Schützen Ihres virtuellen Hubs mit Azure Firewall Manager
• Tutorial: Sichern Sie Ihren virtuellen Hub mithilfe von Azure PowerShell
• Freigeben eines Private Link-Diensts über Virtual WAN
• Verwalten des sicheren Zugriffs auf Ressourcen in Spoke-VNETs für P2S-Clients

Sicherheitsbasispläne

• Azure Firewall
• Azure Firewall Manager

Überprüfung des Well-Architected Framework

• Azure Firewall

Azure-Sicherheit

• Einführung in Azure-Sicherheit
• Implementierungsanleitungen für Zero Trust
• Übersicht über Microsoft Cloud Security Benchmark
• Erstellen der ersten Verteidigungsebene mit Azure-Sicherheitsdiensten
• Referenzarchitekturen für Microsoft-Cybersicherheit

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.