Anwenden von Zero Trust-Prinzipien auf die Segmentierung von Azure-basierter Netzwerkkommunikation

Artikel
06/04/2024

Dieser Artikel bietet Anleitungen zum Anwenden der Prinzipien von Zero Trust für das Segmentieren von Netzwerken in Azure-Umgebungen. Im Folgenden sind die Zero Trust-Prinzipien aufgeführt.

Zero Trust-Prinzip	Definition
Explizit verifizieren	Authentifizieren und autorisieren Sie immer basierend auf allen verfügbaren Datenpunkten.
Geringstmögliche Zugriffsberechtigungen verwenden	Beschränken Sie den Benutzerzugriff mit Just-In-Time- und Just-Enough-Access (JIT/JEA), risikobasierten adaptiven Richtlinien und Datenschutz.
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. Sie können den Auswirkungsbereich von Cyberangriffen minimieren und den Zugriff segmentieren, indem Sie die Netzwerksegmentierung auf verschiedenen Ebenen in Ihrer Azure-Infrastruktur durchführen.

Dieser Artikel ist Teil einer Reihe von Artikeln, die veranschaulichen, wie die Zero Trust-Prinzipien auf Azure-Netzwerke angewendet werden.

Wenn Organisationen wachsen und sich von Kleinunternehmen in große Unternehmen verwandeln, müssen sie häufig von einem einzigen Azure-Abonnement zu mehreren Abonnements wechseln, um Ressourcen für die einzelnen Abteilungen voneinander zu trennen. Es ist wichtig, die Segmentierung Ihres Netzwerks sorgfältig zu planen, um logische Grenzen und eine Isolierung zwischen Umgebungen zu schaffen.

Jede Umgebung, die in der Regel eine separate Abteilung Ihrer Organisation widerspiegelt, sollte über eigene Zugriffsberechtigungen und -richtlinien für bestimmte Workloads verfügen. Benutzer aus Ihrem internen Softwareentwicklerabonnement sollten beispielsweise keinen Zugriff auf die Verwaltung und Bereitstellung von Netzwerkressourcen im Konnektivitätsabonnement haben. Diese Umgebungen benötigen jedoch weiterhin Netzwerkkonnektivität, um die erforderliche Funktionalität für grundlegende Dienste wie Domain Name System (DNS) bereitzustellen, sowie Hybridkonnektivität und die Möglichkeit, andere Ressourcen in verschiedenen virtuellen Azure-Netzwerken (VNets) zu erreichen.

Die Segmentierung Ihrer Azure-Infrastruktur bietet nicht nur Isolierung, sondern kann auch Sicherheitsgrenzen schaffen, die verhindern, dass sich Angreifer über Umgebungen hinweg bewegen und zusätzliche Schäden verursachen (Zero Trust-Prinzip Von einer Sicherheitsverletzung ausgehen).

Referenzarchitektur

Sie können verschiedene Segmentierungsebenen in Azure verwenden, um Ihre Ressourcen vor unbefugtem Zugriff oder böswilligen Angriffen zu schützen. Diese Segmentierungsebenen beginnen auf der Abonnementebene und reichen bis zu den auf VMs ausgeführten Anwendungen. Die Segmentierung schafft eine Grenze, die eine Umgebung von einer anderen trennt, wobei jede Umgebung über eigene Regeln und Richtlinien verfügt. Ausgehend von der Annahme, dass Sicherheitsverletzungen auftreten können, müssen Sie Ihre Netzwerke segmentieren, um deren Ausbreitung zu verhindern.

Azure-Netzwerke verwenden die folgenden Segmentierungsebenen:

Abonnements

Ein Azure-Abonnement ist ein logischer Container zur Bereitstellung von Ressourcen in Azure. Es ist mit einem Azure-Konto in einem Microsoft Entra ID-Mandanten verknüpft und dient als einzelne Abrechnungseinheit für Azure-Ressourcen, die dem Abonnement zugewiesen sind. Ein Azure-Abonnement ist auch eine logische Grenze für den Zugriff auf die im Abonnement enthaltenen Ressourcen. Der Zugriff zwischen Ressourcen in verschiedenen Abonnements erfordert explizite Berechtigungen.
VNETs

Ein Azure-VNet ist ein isoliertes privates Netzwerk, das standardmäßig die Kommunikation zwischen allen darin enthaltenen VMs zulässt. Standardmäßig können VNets nicht mit anderen VNets kommunizieren, es sei denn, Sie erstellen durch Peering, über VPN-Verbindungen (virtuelles privates Netzwerk) oder ExpressRoute Verbindungen zwischen ihnen. Einzelne VNets können als Vertrauensgrenze zum Trennen verschiedener Anwendungen, Workloads, Abteilungen oder Organisationen verwendet werden.

Azure Virtual Network Manager (AVNM) ist ein Netzwerkverwaltungsdienst, mit dem ein einzelnes Verwaltungsteam VNets verwalten und Sicherheitsregeln für mehrere Abonnements global erzwingen kann. Mit AVNM können Sie Netzwerkgruppen definieren, um festzulegen, welche VNets miteinander kommunizieren können. Sie können AVNM auch verwenden, um Änderungen der Netzwerkkonfiguration zu überwachen.
Workloads in einem VNet

Für Workloads innerhalb eines VNet, z. B. VMs oder Platform-as-a-Service (PaaS)-Dienste wie Azure Databricks und App Service, die die VNet-Integration unterstützen, ist die Kommunikation standardmäßig zulässig, da sie in demselben VNet enthalten sind und mithilfe von Netzwerksicherheitsgruppen zusätzlich geschützt werden müssen. Folgende Tools und Dienste sind für die Segmentierung innerhalb eines VNet verfügbar:
- Azure Firewall
  
  Azure Firewall ist ein Dienst, der in einem VNet bereitgestellt wird, um den Datenverkehr zwischen Cloudressourcen, lokalen Umgebungen und dem Internet zu filtern. Mit Azure Firewall können Sie Regeln und Richtlinien zum Zulassen oder Verweigern von Datenverkehr auf Netzwerk- und Anwendungsebene definieren. Sie können auch die erweiterten Features für den Bedrohungsschutz von Azure Firewall nutzen, z. B. IDPS (Intrusion Detection and Prevention System), TLS-Überprüfung (Transport Layer Security) und Threat Intelligence-gestützte Filterung.
- Netzwerksicherheitsgruppe
  
  Eine Netzwerksicherheitsgruppe ist ein Zugriffssteuerungsmechanismus, der den Netzwerkdatenverkehr zwischen Azure-Ressourcen wie VMs in einem VNet filtert. Eine Netzwerksicherheitsgruppe enthält Sicherheitsregeln, die den Datenverkehr auf der Subnetz- oder VM-Ebene in einem VNet zulassen oder verweigern. Netzwerksicherheitsgruppen werden häufig dazu verwendet, die VM-Gruppen in verschiedenen Subnetzen zu segmentieren.
- Anwendungssicherheitsgruppe
  
  Eine Anwendungssicherheitsgruppe ist eine Erweiterung einer Netzwerksicherheitsgruppe, mit der Sie die Netzwerkschnittstellen von VMs basierend auf ihren Rollen und Funktionen gruppieren können. Anschließend können Sie die Anwendungssicherheitsgruppen im großen Stil in einer Netzwerksicherheitsgruppe verwenden, ohne die IP-Adressen von VMs definieren zu müssen.
- Azure Front Door
  
  Azure Front Door ist das moderne Cloud-CDN (Content Delivery Network) von Microsoft, das schnellen, zuverlässigen und sicheren Zugriff zwischen Ihren Benutzer*innen sowie den statischen und dynamischen Webinhalten Ihrer Anwendungen auf der ganzen Welt ermöglicht.

Das folgende Diagramm zeigt die Referenzarchitektur für die Ebenen der Segmentierung.

Die durchgezogenen roten Linien im Diagramm stellen die Segmentierungsebenen zwischen Folgendem dar:

Azure-Abonnements
VNets in einem Abonnement
Subnetze in einem VNet
Internet und ein VNet

Das Diagramm zeigt auch eine Reihe von VNets, die von AVNM verwaltet werden und sich über mehrere Azure-Abonnements erstrecken können.

Was ist in diesem Artikel enthalten?

Zero Trust-Prinzipien werden in der gesamten Referenzarchitektur innerhalb der Azure-Cloud angewendet. In der folgenden Tabelle werden die Empfehlungen für die Segmentierung von Netzwerken in dieser Architektur gemäß dem Zero Trust-Prinzip Von einer Sicherheitsverletzung ausgehen beschrieben.

Schritt	Task
1	Segmentieren innerhalb der einzelnen VNets
2	Verbinden mehrerer VNets durch Peering
3	Verbinden mehrerer VNets in einer Hub-and-Spoke-Konfiguration

Schritt 1: Segmentieren innerhalb der einzelnen VNets

Innerhalb eines einzelnen VNet in einem Azure-Abonnement verwenden Sie Subnetze, um eine Trennung und Segmentierung von Ressourcen zu erzielen. In einem VNet kann es beispielsweise ein Subnetz für Datenbankserver, ein anderes für Webanwendungen und ein dediziertes Subnetz für eine Instanz von Azure Firewall oder Azure Application Gateway mit Web Application Firewall geben. Standardmäßig ist die gesamte Kommunikation zwischen Subnetzen in einem VNet aktiviert.

Zum Isolieren von Subnetzen können Sie Netzwerksicherheitsgruppen oder Anwendungssicherheitsgruppen anwenden, um bestimmten Netzwerkdatenverkehr basierend auf IP-Adressen, Ports oder Protokollen zuzulassen oder zu verweigern. Das Entwerfen und Verwalten von Netzwerksicherheitsgruppen und Anwendungssicherheitsgruppen kann jedoch auch zu zusätzlichem Verwaltungsaufwand führen.

Diese Abbildung zeigt eine allgemeine und empfohlene Konfiguration für eine Anwendung mit drei Ebenen. Die Konfiguration umfasst separate Subnetze für jede Ebene und die Verwendung von Netzwerk- und Anwendungssicherheitsgruppen zum Erstellen von Segmentierungsgrenzen zwischen den einzelnen Subnetzen.

Sie können Ressourcen auch segmentieren, indem Sie den Datenverkehr zwischen Subnetzen mithilfe von benutzerdefinierten Routen (User-Defined Routes, UDRs) weiterleiten, die auf eine Azure Firewall-Instanz oder ein virtuelles Netzwerkgerät (Network Virtual Appliance, NVA) eines Drittanbieters verweisen. Azure Firewall und NVAs bieten auch die Möglichkeit, Datenverkehr mithilfe von Layer 3- bis Layer 7-Kontrollen zuzulassen oder zu verweigern. Die meisten dieser Dienste bieten erweiterte Filterfunktionen.

Weitere Informationen finden Sie im Leitfaden unter Muster 1: Einzelnes virtuelles Netzwerk.

Schritt 2: Verbinden mehrerer VNets durch Peering

Standardmäßig ist die Kommunikation zwischen VNets mit einem einzigen Azure-Abonnement oder über mehrere Abonnements hinweg nicht zulässig. Mehrere VNets, die jeweils zu verschiedenen Entitäten gehören, verfügen über eigene Zugriffssteuerungen. Sie können mithilfe von VNet-Peering eine Verbindung miteinander oder mit einem zentralen Hub-VNet herstellen, wobei der gesamte Datenverkehr von Azure Firewall oder einer Drittanbieter-NVA überprüft wird.

Die folgende Abbildung zeigt eine VNet-Peeringverbindung zwischen zwei VNets und die Verwendung von Azure Firewall auf beiden Seiten der Verbindung.

Ein Hub-VNet enthält in der Regel freigegebene Komponenten wie Firewalls, Identitätsanbieter, Hybridkonnektivitätskomponenten usw. Die UDR-Verwaltung wird einfacher, da das Hinzufügen bestimmter Präfix-UDRs für die Mikrosegmentierung nur erforderlich wäre, wenn VNet-interner Datenverkehr erforderlich ist. Da das VNet jedoch über eigene Grenzen verfügt, sind bereits Sicherheitskontrollen vorhanden.

Weitere Informationen finden Sie in den folgenden Leitfäden:

Schritt 3: Verbinden mehrerer VNets in einer Hub-and-Spoke-Konfiguration

Wenn Sie mehrere VNets in einer Hub-and-Spoke-Konfiguration haben, müssen Sie überlegen, wie Sie Ihren Netzwerkdatenverkehr für diese Grenzen segmentieren:

Internetgrenze
Grenze zum lokalen Netzwerk
Grenzen zu globalen Azure-Diensten

Internetgrenze

Das Schützen von Internetdatenverkehr ist eine grundlegende Priorität bei der Netzwerksicherheit, die das Verwalten von eingehendem Datenverkehr aus dem Internet (nicht vertrauenswürdig) und ausgehendem Datenverkehr an das Internet (vertrauenswürdig) von Ihren Azure-Workloads umfasst.

Microsoft empfiehlt für eingehenden Datenverkehr aus dem Internet die Verwendung eines einzigen Einstiegspunkts. Außerdem empfiehlt Microsoft dringend, eingehenden Datenverkehr über eine Azure PaaS-Ressource wie Azure Firewall, Azure Front Door oder Azure Application Gateway zu leiten. Diese PaaS-Ressourcen bieten mehr Funktionen als eine VM mit einer öffentlichen IP-Adresse.

Azure Firewall

Diese Abbildung zeigt, wie Azure Firewall in einem eigenen Subnetz als zentraler Einstiegspunkt und Segmentierungsgrenze für den Datenverkehr zwischen dem Internet und einer Workload mit drei Ebenen in einem Azure VNet fungiert.

Weitere Informationen finden Sie in der Dokumentation zum Microsoft Azure Well-Architected Framework unter Azure Firewall.

Azure Front Door

Azure Front Door kann als Grenze zwischen dem Internet und den in Azure gehosteten Diensten fungieren. Azure Front Door unterstützt die Private Link-Konnektivität mit Ressourcen wie dem internen Lastenausgleich (Internal Load Balancing, ILB) für den VNet-Zugriff, Speicherkonten für statische Websites und Blob Storage sowie Azure App Services. Azure Front Door wird in der Regel für Bereitstellungen im großen Stil verwendet.

Azure Front Door ist mehr als nur ein Lastenausgleichsdienst. Die Azure Front Door-Infrastruktur verfügt über integrierten DDoS-Schutz (Distributed Denial of Service, verteilter Denial-of-Service-Angriff). Wenn die Zwischenspeicherung aktiviert ist, können Inhalte von POP-Standorten (Point of Presence) abgerufen werden, anstatt ständig auf Back-End-Server zuzugreifen. Wenn der Cache abläuft, ruft Azure Front Door die angeforderte Ressource ab und aktualisiert den Cache. In diesem Szenario greifen Endbenutzer nicht auf ihre Server zu. Stattdessen verwendet Azure Front Door Split TCP, um zwei separate Verbindungen bereitzustellen. Dies verbessert nicht nur die Endbenutzererfahrung, sondern verhindert zudem, dass böswillige Akteure direkt auf Ressourcen zugreifen.

Diese Abbildung zeigt, wie Azure Front Door die Segmentierung zwischen Internetbenutzern und Azure-Ressourcen bereitstellt, die sich in Speicherkonten befinden können.

Weitere Informationen finden Sie in der Dokumentation zum Azure Well-Architected Framework unter Azure Front Door.

Azure Application Gateway

Beim Interneteinstiegspunkt kann es sich auch um eine Kombination von Eingangspunkten handeln. Beispielsweise kann HTTP/HTTPS-Datenverkehr über eine Application Gateway-Instanz eingehen, die durch Web Application Firewall oder Azure Front Door geschützt ist. Nicht-HTTP/HTTPS-Datenverkehr wie RDP/SSH kann über Azure Firewall oder ein NVA eingehen. Sie können diese beiden Elemente zusammen verwenden, um eine umfassendere Überprüfung zu ermöglichen und den Datenverkehrsfluss mithilfe von UDRs zu steuern.

Diese Abbildung zeigt eingehenden Internetdatenverkehr und die Verwendung von Application Gateway mit Web Application Firewall für HTTP/HTTPS-Datenverkehr und einer Azure Firewall-Instanz für allen anderen Datenverkehr.

Folgende zwei Szenarien werden empfohlen:

Platzieren einer Azure Firewall-Instanz oder eines NVA parallel zu einer Application Gateway-Instanz
Platzieren einer Azure Firewall-Instanz oder eines NVA nach einer Application Gateway-Instanz, um Datenverkehr vor dem Erreichen des Ziels zusätzlich zu überprüfen

Weitere Informationen finden Sie in der Dokumentation zum Microsoft Azure Well-Architected Framework unter Azure Application Gateway.

Nachfolgend finden Sie weitere allgemeine Muster für Internetdatenverkehrsflüsse.

Eingehender Datenverkehr mit mehreren Schnittstellen

Ein Ansatz umfasst die Verwendung mehrerer Netzwerkschnittstellen auf VMs, wenn NVAs eingesetzt werden: eine Schnittstelle für nicht vertrauenswürdigen Datenverkehr (extern) und eine weitere Schnittstelle für vertrauenswürdigen Datenverkehr (intern). Im Hinblick auf den Datenverkehrsfluss müssen Sie den eingehenden Datenverkehr von der lokalen Umgebung über UDRs an das NVA weiterleiten. Eingehender Datenverkehr aus dem Internet, der vom NVA empfangen wird, muss über eine Kombination von statischen Routen im Gastbetriebssystem des NVA und UDRs an die Zielworkload im entsprechenden VNet oder Subnetz weitergeleitet werden.

Ausgehender Datenverkehr und UDRs

Für Datenverkehr, der von Ihrem VNet an das Internet gesendet wird, können Sie eine UDR mithilfe einer Routingtabelle mit dem ausgewählten NVA als nächstem Hop anwenden. Um die Komplexität zu verringern, können Sie Azure Firewall oder ein NVA innerhalb Ihres Azure Virtual WAN-Hubs bereitstellen und Internetsicherheit mit Routingabsicht aktivieren. Dadurch wird sichergestellt, dass sowohl Nord-Süd-Datenverkehr (ein- und ausgehender Datenverkehr eines Netzwerkbereichs) als auch Ost-West-Datenverkehr (Datenverkehr zwischen Geräten innerhalb eines Netzwerkbereichs) an Nicht-Azure-VIPs (virtuelle IP-Adressen) überprüft wird.

Ausgehender Datenverkehr und eine Standardroute

Einige Methoden umfassen die Verwaltung einer Standardroute (0.0.0.0/0) mit verschiedenen Methoden. Aufgrund der Durchsatzmenge, die von der Azure-Infrastruktur unterstützt werden kann und die meist deutlich höher ist und mehr Resilienz bietet, wird allgemein empfohlen, Exitpunkte und Überprüfungen mit Azure Firewall oder NVAs für ausgehenden Datenverkehr von Azure zu verwenden. In diesem Fall kann durch Konfigurieren einer Standardroute in den UDRs von Workloadsubnetzen die Weiterleitung von Datenverkehr zu diesen Exitpunkten erzwungen werden. Möglicherweise möchten Sie auch den ausgehenden Datenverkehr von der lokalen Umgebung an Azure als Exitpunkt weiterleiten. Verwenden Sie in diesem Fall Azure Route Server in Kombination mit einem NVA, um eine Standardroute zur lokalen Umgebung mit dem Border Gateway Protocol (BGP) anzukündigen.

Es gibt spezielle Fälle, in denen Sie den gesamten ausgehenden Datenverkehr an die lokale Umgebung zurückleiten müssen, indem eine Standardroute über BGP angekündigt wird. Dadurch wird erzwungen, dass Datenverkehr aus dem VNet über Ihr lokales Netzwerk zur Überprüfung an eine Firewall getunnelt wird. Dieser letzte Ansatz ist am wenigsten empfehlenswert, da die Latenz höher ist und keine von Azure bereitgestellten Sicherheitskontrollen verfügbar sind. Diese Methode wird häufig von Regierungsbehörden und Institutionen im Bankwesen verwendet, die spezifische Anforderungen an die Datenverkehrsüberprüfung innerhalb ihrer lokalen Umgebung haben.

Hinsichtlich der Skalierung ist hierbei Folgendes zu beachten:

Für ein einzelnes VNet können Sie streng an die Layer 4-Semantik angelehnte Netzwerksicherheitsgruppen oder eine Azure Firewall-Instanz, die sowohl der Layer 4- als auch der Layer 7-Semantik entspricht, verwenden.
Für mehrere VNets kann weiterhin eine einzelne Azure Firewall-Instanz verwendet werden, sofern diese erreichbar ist. Alternativ können Sie Azure Firewall in jedem virtuellen Netzwerk bereitstellen und Datenverkehr mit UDRs weiterleiten.

Für große verteilte Unternehmensnetzwerke können Sie weiterhin das Hub-and-Spoke-Modell verwenden und Datenverkehr mit UDRs weiterleiten. Dies kann jedoch den Verwaltungsaufwand erhöhen und dazu führen, dass Grenzwerte für das VNet-Peering gelten. Einfacher ist es, zu diesem Zweck Azure Virtual WAN zu verwenden, eine Azure Firewall-Instanz im virtuellen Hub bereitzustellen und die Routingabsicht für Internetsicherheit zu aktivieren. Dadurch werden Standardrouten für alle Spokes und Zweignetzwerke eingefügt und Internetdatenverkehr zur Überprüfung an Azure Firewall gesendet. Privater Datenverkehr an RFC 1918-Adressblöcke wird an die Azure Firewall-Instanz oder das NVA gesendet, die bzw. das als nächster Hop im Azure Virtual WAN-Hub festgelegt ist.

Grenze zum lokalen Netzwerk

Zu den wichtigsten Methoden zum Herstellen der Konnektivität mit lokalen Netzwerken in Azure zählen IPsec-Tunnel (Internetprotokoll), ExpressRoute-Tunnel oder softwaredefinierte WAN-Tunnel (SD-WAN). In der Regel verwenden Sie eine Azure-Site-to-Site (S2S)-VPN-Verbindung für kleinere Workloads, die weniger Bandbreite erfordern. Für Workloads, die einen dedizierten Dienstpfad und einen höheren Durchsatz erfordern, empfiehlt Microsoft ExpressRoute.

Diese Abbildung zeigt die verschiedenen Methoden für die Verbindung zwischen einer Azure-Umgebung und einem lokalen Netzwerk.

Während Azure-VPN-Verbindungen mehrere Tunnel unterstützen können, wird ExpressRoute häufig für größere Unternehmensnetzwerke konfiguriert, die eine höhere Bandbreite und private Verbindungen über einen Konnektivitätspartner erfordern. Bei ExpressRoute ist es möglich, dasselbe VNet mit mehreren Leitungen zu verbinden. Für Segmentierungszwecke ist dies jedoch oft nicht ideal, da es VNets, die nicht miteinander verbunden sind, die Kommunikation ermöglicht.

Eine Segmentierungsmethode besteht darin, kein Remotegateway in Spoke-VNets zu verwenden oder die BGP-Routenverteilung zu deaktivieren, wenn Sie Routingtabellen verwenden. In diesem Fall können Sie Hubs, die über NVAs und Firewalls mit ExpressRoute verbunden sind, weiterhin segmentieren. Für Spokes, die mit Hubs gepeert sind, können Sie in den VNet-Peeringeigenschaften festlegen, dass kein Remotegateway verwendet werden soll. Auf diese Weise werden Spokes nur die direkt verbundenen Hubs, aber keine lokalen Routen mitgeteilt.

Ein weiterer neuer Ansatz zum Segmentieren von ein- und ausgehendem Datenverkehr der lokalen Umgebung ist die Verwendung von SD-WAN-Technologien. Sie können Ihre Zweigstellenstandorte in Azure SD-WAN erweitern, indem Sie NVAs von Drittanbietern in Azure verwenden, um die Segmentierung basierend auf SD-WAN-Tunneln aus verschiedenen Verzweigungen innerhalb der NVA-Appliances vorzunehmen. Sie können Azure Route Server verwenden, um die Adresspräfixe für die SD-WAN-Tunnel in die Azure-Plattform für eine Hub-and-Spoke-Topologie einzufügen.

Für eine virtuelle WAN-Topologie können Sie das SD-WAN-NVA eines Drittanbieters direkt im virtuellen Hub integrieren. Sie können auch BGP-Endpunkte verwenden, um die Verwendung von SD-WAN-Lösungen zu ermöglichen, indem Tunnel von dem im virtuellen Hub integrierten NVA erstellt werden.

Für beide Modelle können Sie ExpressRoute verwenden, um die zugrunde liegende private oder öffentliche Konnektivität mit privatem Peering oder Microsoft-Peering zu segmentieren. Aus Sicherheitsgründen wird eine Standardroute in der Regel über ExpressRoute angekündigt. Dadurch wird erzwungen, dass der gesamte Datenverkehr aus dem VNet zur Überprüfung an Ihr lokales Netzwerk getunnelt wird. Ebenso kann Datenverkehr, der über das VPN und ExpressRoute eingeht, zur weiteren Überprüfung an ein NVA gesendet werden. Dies gilt auch für ausgehenden Datenverkehr von Azure. Diese Methoden sind bei kleineren Umgebungen mit einer oder zwei Regionen einfach zu verwenden.

Für große, verteilte Netzwerke können Sie auch Azure Virtual WAN verwenden, indem Sie die Überprüfung von privatem Datenverkehr anhand der Routingabsicht aktivieren. Dadurch wird der gesamte Datenverkehr an eine private IP-Adresse des NVA zur Überprüfung weitergeleitet. Wie bei den obigen Methoden ist die Verwaltung deutlich einfacher, wenn Ihre Umgebung mehrere Regionen umfasst.

Der andere Ansatz mit Azure Virtual WAN besteht darin, benutzerdefinierte Routingtabellen für Isolationsgrenzen zu verwenden. Sie können benutzerdefinierte Routen erstellen und für diese Routingtabellen nur die gewünschten VNets zuordnen und verteilen. Diese Funktion kann derzeit jedoch nicht mit einer Routingabsicht kombiniert werden. Zum Isolieren von Verzweigungen können Sie Bezeichnungen zuweisen, um der jeweiligen Bezeichnung Verzweigungen zuzuordnen. Sie können die Verteilung an die Standardbezeichnung auch für einzelne Hubs deaktivieren. Derzeit können Sie einzelne Verzweigungen in Azure nicht separat auf einem einzigen Hub isolieren. Beispielsweise können Sie SD-WAN nicht von ExpressRoute isolieren. Es ist jedoch möglich, die Verteilung an die Standardbezeichnung für einen gesamten Hub zu deaktivieren.

Grenzen zu globalen Azure-Diensten

In Azure sind die meisten Dienste standardmäßig über das globale Azure-WAN zugänglich. Dies gilt auch für den öffentlichen Zugriff auf Azure PaaS-Dienste. Azure Storage verfügt beispielsweise über eine integrierte Firewall, die den Zugriff auf VNets einschränken und den öffentlichen Zugriff blockieren kann. Häufig ist jedoch eine differenziertere Steuerung erforderlich. Bei der typischen Einstellung wird eine private Verbindung mit virtuellen Azure-IP-Adressen (VIPs) hergestellt, anstatt die bereitgestellten standardmäßigen öffentlichen IP-Adressen zu verwenden.

Die am häufigsten verwendete Methode zum Einschränken des Zugriffs auf PaaS-Ressourcen ist die Verwendung von Azure Private Link. Wenn Sie einen privaten Endpunkt erstellen, wird dieser in Ihr VNet eingefügt. Azure verwendet diese private IP-Adresse, um Datenverkehr für die betreffende PaaS-Ressource zu tunneln. Azure ordnet dem privaten Endpunkt mithilfe von privaten Azure DNS-Zonen einen DNS-A-Eintrag und der Private Link-PaaS-Ressource einen CNAME-Eintrag zu.

Dienstendpunkte bieten eine alternative Methode zum Herstellen einer Verbindung mit PaaS-VIPs. Sie können Diensttags auswählen, um Verbindungen mit allen PaaS-Ressourcen innerhalb dieses Tags zuzulassen und private Konnektivität mit der PaaS-Ressource bereitzustellen.

Eine weitere verbreitete Methode ist die Verwendung von Microsoft-Peering für ExpressRoute. Wenn Sie aus der lokalen Umgebung eine Verbindung mit PaaS-VIPs herstellen möchten, können Sie Microsoft-Peering einrichten. Sie können die BGP-Community für die zu verwendenden VIPs auswählen, die dann über den Microsoft-Peeringpfad angekündigt wird.

Weitere Informationen finden Sie in den folgenden Leitfäden:

Zusammenfassung zur Segmentierung

Die folgende Tabelle enthält eine Zusammenfassung der verschiedenen Ebenen und Sicherheitsmethoden für die Segmentierung.

Zwischen	Standardverhalten	Kommunikation durch	Segmentierungssicherheitsmethoden
Abonnements	Keine Kommunikation	- VNet-Peering - VPN-Gateways	Azure Firewall
VNETs	Keine Kommunikation	- VNet-Peering - VPN-Gateways	Azure Firewall
Workloads in Subnetzen innerhalb eines VNet	Offene Kommunikation	N/V	- Netzwerksicherheitsgruppen - Anwendungssicherheitsgruppen
Internet und ein VNet	Keine Kommunikation	- Load Balancer - Öffentliche IP-Adresse - Application Gateway - Azure Front Door	- Azure Application Gateway mit Web Application Firewall – Azure Firewall - Azure Front Door mit Web Application Firewall
Internet und lokale Netzwerke	Keine Kommunikation	- Azure-S2S-VPN - IPSec-Tunnel - ExpressRoute-Tunnel - SD-WAN-Tunnel	Azure Firewall
Internet und VMs in einem VNet	Keine Kommunikation, wenn die VMs nur über private IP-Adressen verfügen	Zuweisen einer öffentlichen IP-Adresse zur VM	Lokale VM-Firewall

Empfohlene Schulung

Nächste Schritte

Weitere Informationen zum Anwenden von Zero Trust auf Azure-Netzwerke finden Sie unter:

References

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

Freigeben über