Bewährte Methoden zum Einrichten von Netzwerken für zu Azure migrierte Workloads

Bei der Planung und dem Entwurf für die Migration besteht einer der wichtigsten Schritte neben der Migration selbst im Entwurf und in der Implementierung von Azure-Netzwerken. Dieser Artikel enthält Informationen zu bewährten Methoden für das Netzwerk bei der Migration zu IaaS-Implementierungen (Infrastructure-as-a-Service) und PaaS-Implementierungen (Platform-as-a-Service) in Azure.

Wichtig

Die in diesem Artikel beschriebenen Best Practices und Meinungen basieren auf Azure-Plattform- und -Dienstfeatures, die zu dem Zeitpunkt verfügbar waren, zu dem dieser Artikel verfasst wurde. Features und Funktionen ändern sich im Laufe der Zeit. Nicht alle Empfehlungen sind notwendigerweise auf Ihre Bereitstellung anwendbar. Wählen Sie also diejenigen aus, die für Sie relevant sind.

Entwerfen virtueller Netzwerke

Azure bietet virtuelle Netzwerke mit folgenden Funktionen:

  • Über virtuelle Netzwerke können Azure-Ressourcen privat, direkt und sicher miteinander kommunizieren.
  • Für virtuelle Computer (VMs, virtuelle Maschinen) und Dienste, die mit dem Internet kommunizieren müssen, können Endpunktverbindungen in virtuellen Netzwerken konfiguriert werden.
  • Ein virtuelles Netzwerk ist eine logische Isolierung der dedizierten Azure-Cloud für Ihr Abonnement.
  • In Azure-Abonnements und -Region können jeweils mehrere virtuelle Netzwerke implementiert werden.
  • Jedes virtuelle Netzwerk wird von den anderen virtuellen Netzwerken isoliert.
  • Virtuelle Netzwerke können private und öffentliche IP-Adressen enthalten, die in RFC 1918 definiert sind und in der CIDR-Notation (Classless Interdomain Routing, klassenloses domänenübergreifendes Routing) ausgedrückt werden. Auf öffentliche IP-Adressen, die im Adressraum eines virtuellen Netzwerks angegeben wurden, kann nicht direkt über das Internet zugegriffen werden.
  • Verbindungen zwischen virtuellen Netzwerken können mittels Peering virtueller Netzwerke hergestellt werden. Verbundene virtuelle Netzwerke können sich in der gleichen Region oder in unterschiedlichen Regionen befinden. Von Ressourcen in einem virtuellen Netzwerk kann eine Verbindung mit Ressourcen in anderen virtuellen Netzwerken hergestellt werden, nämlich mit:
  • Standardmäßig leitet Azure Datenverkehr weiter zwischen:
    • Subnetzen innerhalb eines virtuellen Netzwerks
    • Verbundenen virtuellen Netzwerken
    • Lokalen Netzwerken
    • Dem Internet.

Bei der Planung der Topologie eines virtuellen Netzwerks sollten Sie Folgendes berücksichtigen:

  • Anordnung der IP-Adressräume
  • Implementierung einer Hub-and-Spoke-Netzwerktopologie
  • Segmentierung von virtuellen Netzwerken in Subnetze
  • Einrichten von DNS
  • Implementierung von Azure-Verfügbarkeitszonen

Bewährte Methode: Planen eines IP-Adressraums

Wenn Sie virtuelle Netzwerke im Rahmen Ihrer Migration erstellen, ist es wichtig, den IP-Adressraum der virtuellen Netzwerke zu planen.

Der für die einzelnen virtuellen Netzwerke zugewiesene Adressraum darf nicht größer sein als der CIDR-Bereich /16. In virtuellen Netzwerken können 65.536 IP-Adressen verwendet werden. Wenn Sie ein kleineres Präfix als /16 zuweisen, z. B. /15, das 131.072 Adressen aufweist, können die überzähligen IP-Adressen nicht mehr an anderer Stelle verwendet werden. IP-Adressen dürfen keinesfalls verschwendet werden, selbst wenn sie sich in den durch RFC 1918 definierten privaten Bereichen befinden.

Weitere Tipps für die Planung:

  • Der Adressraum virtueller Netzwerke darf sich nicht mit lokalen Netzwerkbereichen überschneiden.
  • Überlappende Adressen können zu Netzwerken führen, mit denen keine Verbindung hergestellt werden kann, und zu einem Routing, das nicht ordnungsgemäß funktioniert.
  • Wenn sich Netzwerke überschneiden, muss das Netzwerk neu entworfen werden.
  • Wenn Sie das Netzwerk nicht umgestalten können, kann die Netzwerkadressenübersetzung (Network Address Translation, NAT) hilfreich sein, sollte aber wenn möglich vermieden werden.

Weitere Informationen:

Bewährte Methode: Implementieren einer Hub-Spoke-Netzwerktopologie

Eine Hub-and-Spoke-Netzwerktopologie dient zur Isolation von Workloads, während Dienste wie Identität und Sicherheit gemeinsam verwendet werden. Der Hub ist ein virtuelles Azure-Netzwerk, das als zentraler Konnektivitätspunkt fungiert. Die Spokes sind virtuelle Netzwerke, die mit dem virtuellen Hubnetzwerk unter Verwendung von Peering eine Verbindung herstellen. Gemeinsame Dienste werden im Hub bereitgestellt, während einzelne Workloads als Spokes bereitgestellt werden.

Beachten Sie folgende Informationen:

  • Durch die Implementierung einer Hub-and-Spoke-Topologie in Azure werden allgemeine Dienste zentralisiert. Bei diesen Diensten kann es sich um Verbindungen mit lokalen Netzwerken, Firewalls und die Isolation zwischen virtuellen Netzwerken handeln. Das virtuelle Hubnetzwerk stellt einen zentralen Konnektivitätspunkt für lokale Netzwerke und einen Ort zum Hosten von Diensten bereit, die von in virtuellen Spoke-Netzwerken gehosteten Workloads genutzt werden.
  • Eine Hub-Spoke-Konfiguration wird in der Regel von größeren Unternehmen eingesetzt. Für kleinere Netzwerke sollte ein einfacherer Entwurf in Betracht gezogen werden, um Kosten zu sparen und die Komplexität zu verringern.
  • Virtuelle Spoke-Netzwerke können zur Isolation von Workloads verwendet werden, wobei die einzelnen Spokes jeweils separat verwaltet werden. Jede Workload kann mehrere Ebenen und mehrere Subnetze umfassen, die mit Azure-Lastenausgleichsmodulen verbunden sind.
  • Virtuelle Hub-and-Spoke-Netzwerke können in verschiedenen Ressourcengruppen und sogar in verschiedenen Abonnements implementiert werden. Wenn Sie eine Peerverbindung zwischen virtuellen Netzwerken in verschiedenen Abonnements herstellen, können die Abonnements demselben oder einem anderen Microsoft Entra-Mandanten zugeordnet sein. Durch diese Zuordnung wird nicht nur eine dezentralisierte Verwaltung der einzelnen Workloads, sondern auch die gemeinsame Nutzung von Diensten im Hub-VNET ermöglicht.

Diagram that shows a hub and spoke topology.Abbildung 1: Hub-and-Spoke-Topologie

Weitere Informationen:

Bewährte Methode: Entwerfen von Subnetzen

Zur Isolation innerhalb eines virtuellen Netzwerks wird das Netzwerk in mindestens ein Subnetz segmentiert, und jedem Subnetz wird ein Teil des Adressraums des virtuellen Netzwerks zugeordnet.

  • Sie können in jedem virtuellen Netzwerk mehrere Subnetze erstellen.
  • Standardmäßig leitet Azure Netzwerkdatenverkehr zwischen allen Subnetzen in einem virtuellen Netzwerk weiter.
  • Ihre Subnetzentscheidungen basieren auf Ihren technischen und organisatorischen Anforderungen.
  • Subnetze werden mithilfe der CIDR-Notation erstellt.

Achten Sie bei der Wahl des Netzwerkbereichs für Subnetze darauf, dass Azure aus jedem Subnetz fünf IP-Adressen zurückbehält, die nicht verwendet werden können. Wenn Sie also beispielsweise das kleinste verfügbare Subnetz /29 (mit acht IP-Adressen) erstellen, behält Azure fünf Adressen zurück. In diesem Fall stehen somit nur drei verwendbare Adressen zur Verfügung, die Hosts im Subnetz zugewiesen werden können. In den meisten Fällen verwenden Sie /28 als das kleinste Subnetz.

Beispiel:

Die Tabelle enthält ein Beispiel für ein virtuelles Netzwerk mit einem (in Subnetze segmentierten) Adressbereich von 10.245.16.0/20 für eine geplante Migration.

Subnet CIDR Adressen Verwendung
DEV-FE-EUS2 10.245.16.0/22 1019 Front-End- oder Webschicht-VMs
DEV-APP-EUS2 10.245.20.0/22 1019 Logikschicht-VMs
DEV-DB-EUS2 10.245.24.0/23 507 Datenbank-VMs

Weitere Informationen:

Bewährte Methode: Einrichten eines DNS-Servers

Von Azure wird standardmäßig ein DNS-Server hinzugefügt, wenn Sie ein virtuelles Netzwerk bereitstellen. Sie können diesen Server verwenden, um schnell virtuelle Netzwerke zu erstellen und Ressourcen bereitzustellen. Dieser DNS-Server stellt jedoch nur Dienste für die Ressourcen im jeweiligen virtuellen Netzwerk bereit. Wenn Sie mehrere virtuelle Netzwerke miteinander verbinden möchten, benötigen Sie weitere Funktionen zur Namensauflösung. Sie benötigen diese Funktionen auch, um über virtuelle Netzwerke eine Verbindung mit einem lokalen Server herzustellen. Beispielsweise muss Active Directory möglicherweise DNS-Namen zwischen virtuellen Netzwerken auflösen. Stellen Sie zum Auflösen der DNS-Namen Ihren eigenen benutzerdefinierten DNS-Server in Azure bereit.

  • DNS-Server in einem virtuellen Netzwerk können DNS-Abfragen an die rekursiven Resolver in Azure weiterleiten. Durch diese Weiterleitung können Sie Hostnamen innerhalb dieses virtuellen Netzwerks auflösen. Beispielsweise kann ein in Azure ausgeführter Domänencontroller auf DNS-Abfragen für die eigenen Domänen antworten und alle anderen Abfragen an Azure weiterleiten.

  • Durch die DNS-Weiterleitung sind sowohl Ihre lokalen Ressourcen (über den Domänencontroller) als auch die von Azure bereitgestellten Hostnamen (über die Weiterleitung) für die virtuellen Computer sichtbar. Auf die rekursiven Resolver in Azure kann über die virtuelle IP-Adresse 168.63.129.16 zugegriffen werden.

  • Durch die DNS-Weiterleitung wird außerdem eine DNS-Auflösung zwischen virtuellen Netzwerken ermöglicht, sodass lokale Computer von Azure bereitgestellte Hostnamen auflösen können.

    • Zum Auflösen eines VM-Hostnamens muss sich die DNS-Server-VM im selben virtuellen Netzwerk befinden. Ist dies der Fall, können Sie die Server-VM so konfigurieren, dass Hostnamenabfragen an Azure weitergeleitet werden.
    • Da jedes virtuelle Netzwerk ein eigenes DNS-Suffix verwendet, können Sie mithilfe von Regeln für die bedingte Weiterleitung DNS-Abfragen zur Auflösung an das richtige virtuelle Netzwerk senden.
  • Wenn Sie eigene DNS-Server verwenden, können Sie für jedes virtuelle Netzwerk mehrere DNS-Server angeben. Sie können mehrere DNS-Server pro Netzwerkschnittstelle (für Azure Resource Manager) oder pro Clouddienst (für das klassische Bereitstellungsmodell) angeben.

  • Für einen Clouddienst oder eine Netzwerkschnittstelle angegebene DNS-Server haben Vorrang vor DNS-Servern, die für das virtuelle Netzwerk angegeben wurden.

  • In Azure Resource Manager können Sie DNS-Server für ein virtuelles Netzwerk und eine Netzwerkschnittstelle angeben. Es empfiehlt sich jedoch, die Einstellung nur für virtuelle Netzwerke zu verwenden.

    Screenshot that shows DNS servers for a virtual network.Abbildung 2: DNS-Server für ein virtuelles Netzwerk

Weitere Informationen:

Bewährte Methode: Einrichten von Verfügbarkeitszonen

Verfügbarkeitszonen sorgen für höhere Verfügbarkeit, um Ihre Anwendungen und Daten vor Rechenzentrumsausfällen zu schützen. Verfügbarkeitszonen sind eindeutige physische Standorte in einer Azure-Region. Jede Zone besteht aus mindestens einem Rechenzentrum, dessen Stromversorgung, Kühlung und Netzwerkbetrieb unabhängig funktionieren. Zur Gewährleistung der Resilienz sind in allen aktivierten Regionen mindestens drei separate Zonen vorhanden. Die physische Trennung von Verfügbarkeitszonen innerhalb einer Region schützt Anwendungen und Daten vor Ausfällen von Rechenzentren.

Im Folgenden werden einige weitere Punkte aufgeführt, die bei der Einrichtung von Verfügbarkeitszonen zur berücksichtigen sind:

  • Zonenredundante Dienste replizieren Ihre Anwendungen und Daten in mehreren Verfügbarkeitszonen, um sie vor Single Points of Failure zu schützen.

  • Mit Verfügbarkeitszonen bietet Azure eine Betriebszeit-SLA von 99,99 Prozent für virtuelle Computer.

    Diagram that shows availability zones within an Azure region.

    Abbildung 3: Verfügbarkeitszonen

  • Planen und integrieren Sie Hochverfügbarkeit in Ihre Migrationsarchitektur, indem Sie Ihre Compute-, Speicher-, Netzwerk- und Datenressourcen in eine Zone aufnehmen. Anschließend können Sie sie in anderen Zonen replizieren. Azure-Dienste, die Verfügbarkeitszonen unterstützen, können in zwei Kategorien unterteilt werden:

    • Zonendienste: Sie ordnen eine Ressource einer bestimmten Zone – z B. VMs, verwalteten Datenträgern oder IP-Adressen – zu.
    • Zonenredundante Dienste: Die Ressource wird zonenübergreifend automatisch repliziert, z. B. zonenredundanter Speicher oder Azure SQL-Datenbank.
  • Sie können eine Azure Load Balancer-Standardinstanz mit Workloads mit Internetzugriff oder Anwendungsebenen bereitstellen, um zonale Fehlertoleranz bereitzustellen.

    Diagram that shows a standard Azure load balancer.Abbildung 4: Lastenausgleich

Weitere Informationen:

Entwerfen von Hybridcloudnetzwerken

Für eine erfolgreiche Migration muss eine Verbindung zwischen lokalen Unternehmensnetzwerken und Azure hergestellt werden. Durch diese Verbindung entsteht eine Always-On-Verbindung, die als Hybridcloudnetzwerk bezeichnet wird. In diesem Netzwerk werden den Unternehmensbenutzern Dienste aus der Azure-Cloud bereitgestellt. Es gibt zwei Optionen zum Erstellen dieser Art von Netzwerk:

  • Site-to-Site-VPN: Sie stellen eine Site-to-Site-VPN-Verbindung zwischen Ihrem kompatiblen lokalen VPN-Gerät und einem Azure-VPN-Gateway her, das in einem virtuellen Netzwerk bereitgestellt wird. Jede autorisierte lokale Ressource kann auf virtuelle Netzwerke zugreifen. Die Site-to-Site-Kommunikation wird durch einen verschlüsselten Tunnel über das Internet gesendet.
  • Azure ExpressRoute: Sie stellen eine Azure ExpressRoute-Verbindung zwischen Ihrem lokalen Netzwerk und Azure über einen ExpressRoute-Partner her. Diese Verbindung ist privat, und der Datenverkehr wird nicht über das Internet geleitet.

Weitere Informationen:

Bewährte Methode: Implementieren eines hochverfügbaren Site-to-Site-VPN

Richten Sie zum Implementieren eines Site-to-Site-VPN ein VPN-Gateway in Azure ein.

  • Ein VPN-Gateway ist eine spezifische Art eines Gateways für ein virtuelles Netzwerk. Es sendet verschlüsselten Datenverkehr zwischen einem virtuellen Azure-Netzwerk und einem lokalen Standort über das öffentliche Internet.
  • Ein VPN-Gateway kann verschlüsselten Datenverkehr zwischen virtuellen Netzwerken in Azure über das Microsoft-Netzwerk senden.
  • Ein virtuelles Netzwerk kann jeweils nur über ein einzelnes VPN-Gateway verfügen.
  • Sie können mehrere Verbindungen mit dem gleichen VPN-Gateway herstellen. Wenn Sie mehrere Verbindungen herstellen, wird die für das Gateway zur Verfügung stehende Bandbreite auf alle VPN-Tunnel aufgeteilt.

Jedes Azure-VPN-Gateway umfasst zwei Instanzen in einer Aktiv-Standby-Konfiguration:

  • Bei geplanten Wartungsarbeiten oder ungeplanten Störungen für die aktive Instanz findet ein Failover statt, und es wird automatisch die Standbyinstanz verwendet. Diese Instanz nimmt die Site-to-Site- oder Netzwerk-zu-Netzwerk-Verbindung wieder auf.
  • Der Wechsel verursacht eine kurze Unterbrechung.
  • Bei der geplanten Wartung sollte die Konnektivität innerhalb von 10 bis 15 Sekunden wiederhergestellt werden.
  • Bei ungeplanten Problemen dauert die Verbindungswiederherstellung länger – schlimmstenfalls bis zu anderthalb Minuten.
  • Point-to-Site-VPN-Clientverbindungen mit dem Gateway werden getrennt, und Benutzer müssen die Verbindung von Clientcomputern aus wiederherstellen.

Beim Einrichten eines Site-to-Site-VPN gilt Folgendes:

  • Sie benötigen ein virtuelles Netzwerk, dessen Adressbereich sich nicht mit dem lokalen Netzwerk überschneidet, mit dem das VPN eine Verbindung herstellt.
  • Erstellen Sie ein Gatewaysubnetz im Netzwerk.
  • Wenn Sie ein VPN-Gateway erstellen, geben Sie den Gatewaytyp (VPN) an und legen Sie fest, ob es sich um ein richtlinienbasiertes oder um ein routenbasiertes Gateway handelt. Ein routenbasiertes VPN wird als leistungsstärker und zukunftssicherer angesehen.
  • Erstellen Sie ein lokales Netzwerkgateway und konfigurieren Sie Ihr lokales VPN-Gerät.
  • Erstellen Sie eine Site-to-Site-VPN-Failoververbindung zwischen dem Gateway für virtuelle Netzwerke und dem lokalen Gerät. Die Verwendung eines routenbasierten VPN ermöglicht Aktiv/Passiv- oder Aktiv/Aktiv-Verbindungen mit Azure. Bei der routenbasierten Option werden gleichzeitig Site-to-Site-Verbindungen (von einem beliebigen Computer aus) als auch Point-to-Site-Verbindungen (von einem einzelnen Computer aus) unterstützt.
  • Geben Sie die gewünschte Gateway-SKU an. Diese SKU hängt von Ihren Workloadanforderungen, von Ihrem Durchsatz, von Ihren Features und von Ihren SLAs ab.
  • Das Border Gateway Protocol (BGP) ist ein optionales Feature. Es kann mit Azure ExpressRoute und routenbasierten VPN-Gateways verwendet werden, um Ihre lokalen BGP-Routen auf Ihre virtuellen Netzwerke zu verteilen.

Diagram that shows the connections of a site-to-site VPN.Abbildung 5: Site-to-Site-VPN

Weitere Informationen:

Bewährte Methode: Konfigurieren eines Gateways für VPN-Gateways

Wenn Sie ein VPN-Gateway in Azure erstellen, müssen Sie ein spezielles Subnetz namens GatewaySubnet verwenden. Berücksichtigen Sie beim Erstellen dieses Subnetzes die folgenden bewährten Methoden:

  • GatewaySubnet kann eine maximale Präfixlänge von 29 aufweisen (z. B. 10.119.255.248/29). Aktuell wird empfohlen, eine Präfixlänge von 27 zu verwenden (z. B. 10.119.255.224/27).
  • Wenn Sie den Adressraum des Gatewaysubnetzes definieren, verwenden Sie den letzten Teil des Adressraums des virtuellen Netzwerks.
  • Stellen Sie bei Verwendung des Azure-Gatewaysubnetzes keine virtuellen Computer oder anderen Geräte (beispielsweise Azure Application Gateway) im Gatewaysubnetz bereit.
  • Weisen Sie diesem Subnetz keine Netzwerksicherheitsgruppe (NSG) zu. Dadurch wird die Funktion des Gateways beendet.

Bewährte Methode: Implementieren von Azure Virtual WAN für Filialen

Der Netzwerkdienst Azure Virtual WAN bietet für eine mehrere VPN-Verbindungen optimierte und automatisierte Konnektivität zwischen Filialen über Azure.

  • Per Virtual WAN können Sie Branchgeräte für die Kommunikation mit Azure verbinden und konfigurieren. Diese Konfiguration ist manuell oder durch die Nutzung von Geräten eines bevorzugten Anbieters über einen Azure Virtual WAN-Partner möglich.
  • Die Nutzung von Geräten eines bevorzugten Anbieters ermöglicht eine einfache Verwendung, Konnektivität und Konfigurationsverwaltung.
  • Im integrierten Azure Virtual WAN-Dashboard können Sie umgehend Erkenntnisse zur Problembehandlung gewinnen, um Zeit zu sparen. Zudem können Sie auf einfache Weise umfangreiche Site-to-Site-Verbindungen überwachen.

Weitere Informationen: Erfahren Sie mehr über Azure Virtual WAN.

Bewährte Methode: Implementieren von ExpressRoute für unternehmenskritische Verbindungen

Mit dem Azure ExpressRoute-Dienst erweitern Sie Ihre lokale Infrastruktur in die Microsoft-Cloud. Mit ExpressRoute werden private Verbindungen zwischen dem virtuellen Azure-Rechenzentrum und lokalen Netzwerken erstellt. Im Anschluss folgen einige Implementierungsdetails:

  • ExpressRoute-Verbindungen können über ein IP-VPN-Netzwerk (Any-to-Any), ein Point-to-Point-Ethernet-Netzwerk oder über einen Konnektivitätsanbieter hergestellt werden. Diese Verbindungen nutzen nicht das öffentliche Internet.
  • ExpressRoute-Verbindungen bieten mehr Sicherheit und Zuverlässigkeit, höhere Geschwindigkeiten (bis zu 10 GBit/s) sowie gleichbleibende Wartezeiten.
  • ExpressRoute ist nützlich für virtuelle Rechenzentren, weil Kunden von den Konformitätsregeln privater Verbindungen profitieren.
  • Mit ExpressRoute Direct können Sie bei höherem Bandbreitenbedarf eine direkte 100 GBit/s-Verbindung mit Microsoft-Routern herstellen.
  • ExpressRoute verwendet BGP zum Austauschen von Routen zwischen lokalen Netzwerken, Azure-Instanzen und öffentlichen Microsoft-Adressen.

Für die Bereitstellung von ExpressRoute-Verbindungen ist in der Regel ein ExpressRoute-Dienstanbieter erforderlich. Zum schnellen Einstieg wird üblicherweise zunächst eine Site-to-Site-VPN-Verbindung verwendet, um eine Verbindung zwischen dem virtuellen Rechenzentrum und den lokalen Ressourcen herzustellen. Es wird eine Migration zu einer ExpressRoute-Verbindung durchgeführt, wenn eine physische Verbindung mit Ihrem Dienstanbieter eingerichtet wurde.

Weitere Informationen:

Bewährte Methode: Optimieren von ExpressRoute-Routing mit BGP-Communitys

Wenn Sie mehrere ExpressRoute-Verbindungen nutzen, verfügen Sie über mehr als einen Weg zur Herstellung einer Verbindung mit Microsoft. Infolgedessen kann es zu einem suboptimalen Routing kommen. Ihr Datenverkehr benötigt möglicherweise einen längeren Weg, um Microsoft zu erreichen, und Microsoft benötigt möglicherweise länger, um Ihr Netzwerk zu erreichen. Je länger der Netzwerkpfad, desto höher die Latenz. Die Wartezeit wirkt sich direkt auf die Anwendungsleistung und die Benutzerfreundlichkeit aus.

Beispiel:

Schauen wir uns ein Beispiel an:

  • Sie verfügen über zwei Niederlassungen in den USA: eine in Los Angeles und eine in New York City.
  • Die Niederlassungen sind über ein WAN verbunden, wobei es sich entweder um Ihr eigenes Backbonenetzwerk oder die IP-VPN-Verbindung Ihres Dienstanbieters handeln kann.
  • Sie verfügen über zwei ExpressRoute-Verbindungen – eine in der Region West US und eine in der Region East US –, die per WAN verbunden sind. Es sind also zwei Wege zum Herstellen der Verbindung mit dem Microsoft-Netzwerk vorhanden.

Problem:

Nehmen Sie weiter an, dass Sie über eine Azure-Bereitstellung (z. B. Azure App Service) in West US und East US verfügen.

  • Die Benutzer in beiden Niederlassungen sollen auf die nächstgelegenen Azure-Dienste zugreifen, um eine optimale Leistung zu erzielen.
  • Daher sollen Benutzer in Los Angeles eine Verbindung mit der Azure-Region West US und Benutzer in New York eine Verbindung mit der Azure-Region East US herstellen.
  • Diese Verbindung funktioniert für Benutzer an der Ostküste, aber nicht für Benutzer an der Westküste. Das Problem ist Folgendes:
    • Für jede ExpressRoute-Verbindung kündigen wir sowohl das Präfix in der Azure-Region East US (23.100.0.0/16) als auch das Präfix in der Azure-Region West US (13.100.0.0/16) an.
    • Wenn nicht bekannt ist, welches Präfix aus welcher Region stammt, werden die Präfixe gleich behandelt.
    • Bei Ihrem WAN wird möglicherweise davon ausgegangen, dass beide Präfixe näher bei East US als bei West US liegen, und Benutzer aus beiden Niederlassungen werden daher an die ExpressRoute-Verbindung in East US weitergeleitet. Dieses Routing ist für die Benutzer in der Niederlassung in Los Angeles nicht optimal.

Diagram that shows a VPN with a route path through the wrong circuit.Abbildung 6: Nicht optimierte Verbindung über BGP-Communitys

Lösung:

Um das Routing für beide Niederlassungen optimieren zu können, müssen Sie wissen, welches Präfix für die Azure-Region West US und welches Präfix für die Azure-Region East US gilt. Sie können diese Informationen mithilfe von BGP-Communitywerten codieren.

  • Weisen Sie jeder Azure-Region einen eindeutigen BGP-Communitywert zu, wie z. B. 12076:51004 für East US oder 12076:51006 für West US.
  • Damit ist klar, welches Präfix zu welcher Azure-Region gehört, sodass Sie eine bevorzugte ExpressRoute-Leitung konfigurieren können.
  • Da Sie BGP zum Austauschen von Routinginformationen verwenden, können Sie über die lokale Einstellung von BGP das Routing beeinflussen.
  • Im Beispiel wird 13.100.0.0/16 ein lokaler Voreinstellungswert in West US zugewiesen, der höher als der Wert in East US ist. 23.100.0.0/16 wird auch ein lokaler Voreinstellungswert in East US zugewiesen, der höher als der Wert in West US ist.
  • Diese Konfiguration stellt bei Verfügbarkeit beider Pfade zu Microsoft sicher, dass Benutzer in Los Angeles über die westliche Leitung eine Verbindung mit der Region West US herstellen und Benutzer in New York über die östliche Leitung eine Verbindung mit der Region East US.

Diagram that shows a VPN with a route path through the correct circuit.Abbildung 7: Optimierte Verbindung über BGP-Communitys

Weitere Informationen:

Sichere virtuelle Netzwerke

Sie und Microsoft sind gemeinsam für den Schutz virtueller Netzwerke verantwortlich. Microsoft bietet viele Netzwerkfeatures und Dienste, die zum Schutz der Ressourcen dienen. Für die Gestaltung der Sicherheit für virtuelle Netzwerke wird Folgendes empfohlen:

  • Implementieren eines Umkreisnetzwerks
  • Verwenden von Filtern und Sicherheitsgruppen
  • Schützen des Zugriffs auf Ressourcen und IP-Adressen
  • Implementieren eines Angriffsschutzes

Weitere Informationen:

Bewährte Methode: Implementieren eines Azure-Umkreisnetzwerks

Wenngleich Microsoft hohe Investitionen in den Schutz der Cloudinfrastruktur tätigt, müssen Sie ebenfalls für den Schutz Ihrer Clouddienste und Ressourcengruppen sorgen. Ein mehrstufiger Sicherheitsansatz bietet die beste Absicherung. Die Einrichtung eines Umkreisnetzwerks ist ein wichtiger Bestandteil dieser Schutzstrategie.

  • Ein Umkreisnetzwerk schützt die internen Netzwerkressourcen vor einem nicht vertrauenswürdigen Netzwerk.
  • Dabei handelt es sich um die äußerste Schicht, die mit dem Internet verbunden ist. Sie befindet sich normalerweise zwischen dem Internet und der Infrastruktur des Unternehmens, in der Regel mit irgendeiner Art des Schutzes auf beiden Seiten.
  • In einer typischen Unternehmensnetzwerktopologie wird der Kern der Infrastruktur im Umkreisnetzwerk durch mehrere Ebenen von Sicherheitsgeräten stark geschützt: An den Grenzen der einzelnen Stufen befinden sich Sicherheitsgeräte und Stellen zur Durchsetzung von Richtlinien.
  • Die einzelnen Stufen können jeweils eine Kombination der Netzwerksicherheitslösungen enthalten. Hierzu zählen beispielsweise folgende:
    • Firewalls
    • DoS-Schutz (Denial of Service)
    • Angriffserkennungs-/Eindringschutzsysteme (Intrusion Detection and Intrusion Protection Systems, IDS/IPS)
    • VPN-Geräte
  • Die Durchsetzung von Richtlinien im Umkreisnetzwerk kann über Firewallrichtlinien, Zugriffssteuerungslisten (Access Control Lists, ACLs) oder ein spezifisches Routing erfolgen.
  • Eingehender Internetdatenverkehr wird abgefangen und durchläuft eine Kombination von Abwehrlösungen. Durch die Lösungen werden Angriffe und schädlicher Datenverkehr blockiert und legitime Netzwerkanforderungen zugelassen.
  • Der eingehende Datenverkehr kann direkt an Ressourcen im Umkreisnetzwerk weitergeleitet werden. Die Umkreisnetzwerkressource kann dann mit anderen, tiefer im Netzwerk befindlichen Ressourcen kommunizieren und den Datenverkehr nach der Validierung in das Netzwerk weiterleiten.

Hier sehen Sie ein Beispiel für ein Umkreisnetzwerk mit einem einzelnen Subnetz in einem Unternehmensnetzwerk. Das Subnetzumkreisnetzwerk weist zwei Sicherheitsgrenzen auf.

Diagram that shows an Azure Virtual Network perimeter network deployment.Abbildung 8: Bereitstellung eines Umkreisnetzwerks

Weitere Informationen:

Bewährte Methode: Filtern des Datenverkehrs virtueller Netzwerke mit NSGs

Netzwerksicherheitsgruppen (NSG) enthalten mehrere Ein- und Ausgangssicherheitsregeln zum Filtern des Datenverkehrs, der bei Ressourcen ein- bzw. von ihnen ausgeht. Das Filtern des Datenverkehrs kann nach Quell- und Ziel-IP-Adresse, Port und Protokoll erfolgen.

  • NSGs enthalten Sicherheitsregeln, die eingehenden Netzwerkdatenverkehr an verschiedene Typen von Azure-Ressourcen (bzw. von ihnen ausgehenden Netzwerkdatenverkehr) zulassen oder verweigern. Für jede Regel können Sie die Quelle und das Ziel, den Port sowie das Protokoll angeben.
  • NSG-Regeln werden nach Priorität anhand der 5-Tupel-Informationen ausgewertet, um den Datenverkehr zuzulassen oder zu verweigern. Bei den 5-Tupel-Informationen handelt es sich um Angaben zu Quelle, Quellport, Ziel, Zielport und Protokoll.
  • Für vorhandene Verbindungen wird ein Flussdatensatz erstellt. Die Kommunikation wird basierend auf dem Verbindungszustand der Flussdatensätze zugelassen oder verweigert.
  • Durch einen Datenflussdatensatz kann eine NSG zustandsbehaftet sein. Wenn Sie beispielsweise eine Sicherheitsregel für ausgehenden Datenverkehr an eine beliebige Adresse über Port 80 angeben, ist es nicht erforderlich, für die Antwort auf den ausgehenden Datenverkehr eine Sicherheitsregel für eingehenden Datenverkehr anzugeben. Sie müssen nur dann eine Sicherheitsregel für Datenverkehr in eingehender Richtung angeben, wenn die Kommunikation extern gestartet wird.
  • Dies gilt auch für den umgekehrten Fall. Wenn eingehender Datenverkehr über einen Port zugelassen wird, ist es nicht erforderlich, für die Beantwortung des Datenverkehrs über den Port eine Sicherheitsregel für ausgehenden Datenverkehr anzugeben.
  • Vorhandene Verbindungen werden nicht unterbrochen, wenn Sie eine Sicherheitsregel entfernen, die den Datenfluss ermöglicht hat. Datenverkehrsflüsse werden unterbrochen, wenn Verbindungen beendet werden und in beide Richtungen mindestens einige Minuten lang kein Datenverkehr besteht.
  • Erstellen Sie immer so wenige NSGs wie möglich, aber so viele wie nötig.

Bewährte Methode: Schützen von Datenverkehr in Nord-Süd- und Ost-West-Richtung

Beim Schutz virtueller Netzwerke müssen Angriffsvektoren berücksichtigt werden. Beachten Sie folgende Punkte:

  • Durch die ausschließliche Verwendung von Subnetz-NSGs wird Ihre Umgebung vereinfacht, aber nur der Datenverkehr in Ihr Subnetz abgesichert. Dieser Datenverkehr wird als Nord-Süd-Datenverkehr bezeichnet.
  • Der Datenverkehr zwischen virtuellen Computern im selben Subnetz wird Ost-West-Datenverkehr genannt.
  • Sie sollten unbedingt beide Schutzformen nutzen. So wird ein Hacker, der von außen Zugriff erlangt, gestoppt, wenn er versucht, Computer im gleichen Subnetz anzugreifen.

Verwenden von Diensttags für NSGs

Ein Diensttag steht für eine Gruppe von IP-Adresspräfixen. Die Verwendung eines Diensttags macht die Erstellung von NSG-Regeln weniger komplex.

  • Bei der Erstellung von Regeln können Sie Diensttags anstelle spezifischer IP-Adressen nutzen.
  • Microsoft verwaltet die Adresspräfixe, die einem Diensttag zugeordnet sind, und aktualisiert das Diensttag automatisch, wenn sich die Adressen ändern.
  • Sie können kein eigenes Diensttag erstellen und auch nicht angeben, welche IP-Adressen in einem Tag enthalten sind.

Diensttags ersparen Ihnen die manuelle Arbeit beim Zuweisen einer Regel zu Gruppen von Azure-Diensten. Wenn Sie beispielsweise einem Subnetz mit Webservern den Zugriff auf Azure SQL-Datenbank ermöglichen möchten, können Sie eine Ausgangsregel für Port 1433 erstellen und das Diensttag Sql verwenden.

  • Dieses Sql-Tag gibt die Adresspräfixe der Azure SQL-Datenbank- und Azure SQL Data Warehouse-Dienste an.
  • Wenn Sie Sql als Wert angeben, wird der Datenverkehr für SQL zugelassen oder verweigert.
  • Falls Sie den Zugriff auf Sql nur für eine bestimmte Region bereitstellen möchten, können Sie die betreffende Region angeben. Wenn Sie den Zugriff auf Azure SQL-Datenbank beispielsweise nur für die Region „USA, Osten“ bereitstellen möchten, können Sie Sql.EastUS für das Diensttag angeben.
  • Das Tag steht für den Dienst, aber nicht für bestimmte Instanzen des Diensts. Beispielsweise steht das Tag für den Azure SQL-Datenbank-Dienst, aber nicht für eine bestimmte SQL-Datenbank oder einen bestimmten SQL-Server.
  • Alle Adresspräfixe, für die dieses Tag steht, werden auch durch das Internet-Tag repräsentiert.

Weitere Informationen:

Bewährte Methode: Verwenden von Anwendungssicherheitsgruppen

Mit Anwendungssicherheitsgruppen können Sie die Netzwerksicherheit als natürliche Erweiterung einer Anwendungsstruktur konfigurieren.

  • Gruppieren Sie virtuelle Computer und definieren Sie Netzwerksicherheitsrichtlinien anhand von Anwendungssicherheitsgruppen.
  • Anwendungssicherheitsgruppen ermöglichen Ihnen die bedarfsabhängige Wiederverwendung Ihrer Sicherheitsrichtlinie, ohne dass Sie explizite IP-Adressen manuell warten müssen.
  • Anwendungssicherheitsgruppen übernehmen die komplexe Verarbeitung expliziter IP-Adressen und mehrerer Regelsätze, sodass Sie sich auf Ihre Geschäftslogik konzentrieren können.

Beispiel:

Diagram that shows an example application security group.

Abbildung 9: Beispiel für eine Anwendungssicherheitsgruppe

Netzwerkschnittstelle Anwendungssicherheitsgruppe
NIC1 AsgWeb
NIC2 AsgWeb
NIC3 AsgLogic
NIC4 AsgDb

In der Tabelle oben gehört jede Netzwerkschnittstelle nur einer Anwendungssicherheitsgruppe an, aber tatsächlich kann eine Schnittstelle mehreren Gruppen angehören, wenn sie den Azure-Grenzwerten entspricht. Keiner der Netzwerkschnittstellen ist eine NSG zugeordnet. NSG1 ist beiden Subnetzen zugeordnet und enthält die folgenden Regeln:

Regelname Zweck Details
Allow-HTTP-Inbound-Internet Datenverkehr aus dem Internet an die Webserver wird zugelassen. Eingehender Datenverkehr aus dem Internet wird durch die Standardsicherheitsregel DenyAllInbound verweigert, daher ist keine zusätzliche Regel für die Anwendungssicherheitsgruppen AsgLogic oder AsgDb erforderlich. Priorität: 100

Quelle: internet

Quellport: *

Ziel: AsgWeb

Zielport: 80

Protokoll: TCP

Zugriff: Allow
Deny-Database-All Die Standardsicherheitsregel AllowVNetInBound erlaubt die gesamte Kommunikation zwischen Ressourcen im gleichen virtuellen Netzwerk. Diese Regel wird benötigt, um den Datenverkehr von allen Ressourcen zu verweigern. Priorität: 120

Quelle: *

Quellport: *

Ziel: AsgDb

Zielport: 1433

Protokoll: All

Zugriff: Deny
Allow-Database-BusinessLogic Datenverkehr von der Anwendungssicherheitsgruppe AsgLogic an die Anwendungssicherheitsgruppe AsgDb wird zugelassen. Da die Priorität für diese Regel höher ist als die Priorität der Regel Deny-Database-All, wird diese Regel zuerst verarbeitet. Datenverkehr von der Anwendungssicherheitsgruppe AsgLogic wird zugelassen und jeglicher andere Datenverkehr wird blockiert. Priorität: 110

Quelle: AsgLogic

Quellport: *

Ziel: AsgDb

Zielport: 1433

Protokoll: TCP

Zugriff: Allow

Regeln, in denen eine Anwendungssicherheitsgruppe als Quelle oder Ziel angegeben ist, werden nur auf Netzwerkschnittstellen angewendet, bei denen es sich um Mitglieder der Anwendungssicherheitsgruppe handelt. Wenn die Netzwerkschnittstelle keiner Anwendungssicherheitsgruppe angehört, wird die Regel nicht auf die Netzwerkschnittstelle angewendet, auch wenn die Netzwerksicherheitsgruppe dem Subnetz zugeordnet ist.

Weitere Informationen:

Bewährte Methode: Sicherer Zugriff auf PaaS unter Verwendung von Azure VNET-Dienstendpunkten

Durch Azure VNET-Dienstendpunkte werden Ihr privater VNET-Adressraum und die Identität über eine direkte Verbindung auf Azure-Dienste erweitert.

  • Endpunkte ermöglichen es Ihnen, kritische Ressourcen von Azure-Diensten auf Ihre virtuellen Netzwerke zu beschränken und so zu schützen. Der Datenverkehr aus Ihrem virtuellen Netzwerk an den Azure-Dienst wird vollständig über das Backbone-Netzwerk von Azure abgewickelt.
  • Der private VNET-Adressraum kann sich überlappen und darf nicht zur eindeutigen Identifizierung von Datenverkehr aus einem virtuellen Netzwerk verwendet werden.
  • Nach der Aktivierung von Dienstendpunkten in Ihrem virtuellen Netzwerk können Sie Azure-Dienstressourcen schützen, indem Sie ihnen eine VNET-Regel hinzufügen. Durch diese Hinzufügung wird die Sicherheit verbessert, da der Ressourcenzugriff über das öffentliche Internet verhindert und nur Datenverkehr aus Ihrem virtuellen Netzwerk zugelassen wird.

Diagram that shows virtual network service endpoints.Abbildung 10: Dienstendpunkte

Weitere Informationen:

Bewährte Methode: Steuern öffentlicher IP-Adressen

Öffentliche IP-Adressen in Azure können virtuellen Computern, Lastenausgleichsmodulen, Application Gateways und VPN-Gateways zugeordnet werden.

  • Anhand öffentlicher IP-Adressen können Internetressourcen in eingehender Richtung mit Azure-Ressourcen und Azure-Ressourcen in ausgehender Richtung mit dem Internet kommunizieren.
  • Öffentliche IP-Adressen werden mit einer Basic-SKU oder einer Standard-SKU erstellt. Standard-SKUs können jedem Dienst zugewiesen werden, werden jedoch für virtuelle Computer, Lastenausgleichsmodule und Anwendungsgateways konfiguriert.
  • Für eine öffentliche IP-Adresse der SKU „Basic“ wird nicht automatisch eine NSG konfiguriert. Sie können eine eigene SKU konfigurieren und Regeln zum Steuern des Zugriffs zuweisen. IP-Adressen der Standard-SKU umfassen eine Netzwerksicherheitsgruppe und standardmäßig zugewiesene Regeln.
  • Als bewährte Methode dürfen VMs nicht mit einer öffentlichen IP-Adresse konfiguriert werden.
    • Wenn Sie einen geöffneten Port benötigen, sollte dieser nur für Webdienste geöffnet werden (beispielsweise Port 80 oder 443).
    • Standard-Remoteverwaltungsports wie SSH (22) und RDP (3389) sollten wie alle übrigen Ports mithilfe von NSGs auf „Verweigern“ festgelegt werden.
  • Eine bessere Methode besteht darin, virtuelle Computer hinter Azure Load Balancer oder Azure Application Gateway zu platzieren. Wenn Sie anschließend Zugriff auf Remoteverwaltungsports benötigen, können Sie den Just-In-Time-VM-Zugriff in Microsoft Defender für Cloud verwenden.

Weitere Informationen:

Nutzen von Azure-Sicherheitsfeatures für Netzwerke

Azure verfügt über Sicherheitsfeatures auf Plattformebene wie Azure Firewall, Azure Web Application Firewall (WAF) und Azure Network Watcher.

Bewährte Methode: Bereitstellen von Azure Firewall

Azure Firewall ist ein verwalteter, cloudbasierter Netzwerksicherheitsdienst, der zum Schutz Ihrer VNET-Ressourcen beiträgt. Es handelt sich hierbei um eine vollständig zustandsbehaftete verwaltete Firewall mit integrierter Hochverfügbarkeit und uneingeschränkter Cloudskalierbarkeit.

Diagram that shows Azure Firewall for a virtual network.Abbildung 11: Azure Firewall

Im Anschluss folgen einige Punkte, die beachtet werden müssen, wenn Sie den Dienst bereitstellen:

  • Von Azure Firewall können Richtlinien zur Anwendungs- und Netzwerkkonnektivität für Abonnements und virtuelle Netzwerke zentral erstellt, erzwungen und protokolliert werden.
  • Azure Firewall verwendet eine statische öffentliche IP-Adresse für Ihre virtuellen Netzwerkressourcen. Externe Firewalls können Datenverkehr aus Ihrem virtuellen Netzwerk identifizieren.
  • Azure Firewall ist für Protokollierung und Analyse vollständig in Azure Monitor integriert.
  • Beim Erstellen von Azure Firewall-Regeln empfiehlt sich die Verwendung der FQDN-Tags.
    • Ein FQDN-Tag stellt eine Gruppe von FQDNs dar, die bekannten Microsoft-Diensten zugeordnet sind.
    • Sie können ein FQDN-Tag verwenden, um den erforderlichen ausgehenden Netzwerkdatenverkehr über die Firewall zuzulassen.
  • Um beispielsweise den Netzwerkdatenverkehr von Windows Update manuell über Ihre Firewall zuzulassen, müssen Sie mehrere Anwendungsregeln erstellen. Mit FQDN-Tags erstellen Sie eine Anwendungsregel und schließen das Windows Update-Tag ein. Wenn diese Regel festgelegt wurde, kann der Netzwerkdatenverkehr an Microsoft Windows Update-Endpunkte über Ihre Firewall verlaufen.

Weitere Informationen:

Bewährte Methode: Bereitstellen der Web Application Firewall

Webanwendungen sind zunehmend Ziele böswilliger Angriffe, die allgemein bekannte Sicherheitslücken ausnutzen. Zu den Exploits gehören üblicherweise Angriffe durch Einschleusung von SQL-Befehlen oder Angriffe durch websiteübergreifende Skripts. Es kann schwierig sein, Angriffe im Anwendungscode zu verhindern. Hierzu können rigorose Wartungs-, Patch- und Überwachungsmaßnahmen auf mehreren Ebenen der Anwendungstopologie erforderlich sein.

Die Web Application Firewall (WAF) ist ein Feature von Azure Application Gateway, das die Sicherheitsverwaltung erheblich vereinfacht und Anwendungsadministratoren bei Maßnahmen zum Schutz vor Bedrohungen und Angriffen unterstützt. Sie können schneller auf Sicherheitsrisiken reagieren, wenn Sie bekannte Schwachstellen an einem zentralen Ort patchen, anstatt einzelne Webanwendungen separat zu schützen. Bereits vorhandene Anwendungsgateways lassen sich problemlos in eine Web Application Firewall-fähige Application Gateway-Instanz konvertieren.

Weitere Hinweise zur WAF:

  • Die WAF bietet zentralisierten Schutz Ihrer Webanwendungen vor allgemeinen Exploits und Sicherheitsrisiken.
  • Sie müssen keine Codeänderungen vornehmen, um die WAF verwenden zu können.
  • Sie kann gleichzeitig mehrere Web-Apps schützen (hinter Application Gateway).
  • WAF ist in Microsoft Defender für Cloud integriert.
  • Sie können WAF-Regeln und Regelgruppen an Ihre Anwendungsanforderungen anpassen.
  • Es empfiehlt sich, eine WAF vor jeder Anwendung zu verwenden, auf die über das Web zugegriffen werden kann. Dies gilt auch für Anwendungen auf virtuellen Azure-Computern oder in Azure App Service.

Weitere Informationen:

Bewährte Methode: Implementieren von Network Watcher

Network Watcher bietet Tools zur Überwachung von Ressourcen und der Kommunikation in einem virtuellen Azure-Netzwerk. So können Sie beispielsweise die Kommunikation zwischen einem virtuellen Computer und einem Endpunkt (beispielsweise einem anderen virtuellen Computer oder FQDN) überwachen. Darüber hinaus können Sie Ressourcen und Ressourcenbeziehungen in einem virtuellen Netzwerk anzeigen oder Probleme mit Netzwerkdatenverkehr diagnostizieren.

Screenshot that shows Azure Network Watcher.

Abbildung 12: Network Watcher

Im Anschluss finden Sie einige weitere Details:

  • Mithilfe von Network Watcher können Sie Netzwerkprobleme überwachen und diagnostizieren, ohne sich bei VMs anmelden zu müssen.
  • Sie können mithilfe von Warnungen die Paketerfassung auslösen und in Echtzeit Zugriff auf Leistungsinformationen auf Paketebene erhalten. Wenn Sie ein Problem feststellen, können Sie dieses detailliert untersuchen.
  • Als eine bewährte Methode sollten Sie Network Watcher zum Überprüfen von NSG-Datenflussprotokollen verwenden.
    • Mit NSG-Datenflussprotokollen in Network Watcher können Sie Informationen zu ein- und ausgehendem IP-Datenverkehr über eine NSG anzeigen.
    • Datenflussprotokolle werden im JSON-Format geschrieben.
    • Datenflussprotokolle geben Aufschluss über regelspezifische aus- und eingehende Datenflüsse sowie über die Netzwerkschnittstelle (NIC) für den Datenfluss. Sie zeigen 5-Tupel-Informationen zum Datenfluss und zeigen an, ob der Datenverkehr zugelassen oder verweigert wurde.

Weitere Informationen:

Verwenden von Partnertools im Azure Marketplace

Für komplexere Netzwerktopologien können Sie Sicherheitsprodukte von Microsoft-Partnern in bestimmten virtuellen Netzwerkgeräten (Network Virtual Appliances, NVAs) verwenden.

  • Eine virtuelles Netzwerkgerät ist ein virtueller Computer, der eine Netzwerkfunktion wie z. B. Firewall oder WAN-Optimierung übernimmt.
  • Durch virtuelle Netzwerkappliances werden VNET-Sicherheits- und Netzwerkfunktionen gestärkt. Sie können bereitgestellt werden für:
    • Hoch verfügbare Firewalls
    • Eindringschutz
    • Angriffserkennung
    • WAFs
    • WAN-Optimierung.
    • Routing.
    • Lastenausgleich.
    • VPN.
    • Zertifikatverwaltung.
    • Microsoft Entra ID.
    • Mehrstufige Authentifizierung.
  • NVAs sind von Anbietern im Azure Marketplace erhältlich.

Bewährte Methode: Implementieren von Firewalls und NVAs im Hubnetzwerken

Im Hub wird das Umkreisnetzwerk (mit Zugriff auf das Internet) für gewöhnlich per Azure Firewall, über eine Firewallfarm oder über eine WAF verwaltet. Die folgende Tabelle enthält eine Gegenüberstellung dieser Firewalloptionen:

Firewalltyp Details
WAFs Webanwendungen sind üblich, aber sie weisen häufig Sicherheitsrisiken und potenzielle Exploits auf. WAFs sind für die Erkennung von Angriffen auf Webanwendungen (HTTP/HTTPS) konzipiert. Im Gegensatz zu herkömmlichen Firewalls weisen WAFs bestimmte Features auf, die den internen Webserver vor Bedrohungen schützen.
Azure Firewall Azure Firewall verwendet genau wie NVA-Firewallfarmen einen allgemeinen Verwaltungsmechanismus und eine Gruppe von Sicherheitsregeln, um in Spoke-Netzwerken gehostete Workloads zu schützen. Azure Firewall hilft dabei, den Zugriff auf lokale Netzwerke zu steuern und verfügt über integrierte Skalierbarkeit.
Firewalls mit virtuellen Netzwerkappliances NVA-Firewallfarmen verfügen genau wie Azure Firewall über einen allgemeinen Verwaltungsmechanismus und eine Gruppe von Sicherheitsregeln, um in Spoke-Netzwerken gehostete Workloads zu schützen. NVA-Firewalls helfen beim Steuern des Zugriffs auf lokale Netzwerke, und sie können manuell hinter einem Lastenausgleichsmodul skaliert werden.

Eine NVA-Firewall verfügt über weniger spezialisierte Software als ein WAF, muss aber einen umfassenderen Anwendungsbereich filtern und alle Arten von ein- oder ausgehendem Datenverkehr überprüfen.

Es wird empfohlen, eine Gruppe von Azure-Firewalls (oder NVAs) für Datenverkehr aus dem Internet zu verwenden und eine andere für Datenverkehr mit lokalem Ursprung. Die Verwendung einer einzigen Gruppe von Firewalls für den gesamten Datenverkehr stellt ein Sicherheitsrisiko dar, da sie keinen Sicherheitsperimeter zwischen den beiden Arten von Netzwerkdatenverkehr bietet. Separate Firewallebenen vereinfachen die Überprüfung von Sicherheitsregeln und ermöglichen eine eindeutige Zuordnung von Regeln zu eingehenden Netzwerkanforderungen.

Weitere Informationen:

Nächste Schritte

Informieren Sie sich über weitere Best Practices: