Bereitstellung von Private Application Gateway (Vorschau)
Einführung
Historisch haben Application Gateway v2-SKUs und in einem bestimmten Umfang v1 die öffentliche IP-Adressierung benötigt, um die Verwaltung des Diensts zu ermöglichen. Diese Anforderung führte zu mehreren Einschränkungen bei der Verwendung von feinkörnigen Kontrollen in Netzwerksicherheitsgruppen und Routentabellen. Insbesondere wurden die folgenden Herausforderungen beobachtet:
- Alle Application Gateway v2-Bereitstellungen müssen öffentlich zugängliche Front-End-IP-Konfiguration enthalten, um die Kommunikation mit dem Gateway Manager-Diensttag zu ermöglichen.
- Netzwerksicherheitsgruppenzuordnungen erfordern Regeln, um eingehenden Zugriff von GatewayManager und ausgehenden Zugriff auf das Internet zuzulassen.
- Wenn eine Standardroute (0.0.0.0/0) zur Weiterleitung von Datenverkehr an einen anderen Ort als das Internet eingeführt wird, führen Metriken, Überwachung und Aktualisierungen des Gateways zu einem fehlgeschlagenen Status.
Application Gateway v2 kann nun jeden dieser Punkte berücksichtigen, um das Risiko der Datenexfiltration weiter zu eliminieren und den Datenschutz der Kommunikation innerhalb des virtuellen Netzwerks zu kontrollieren. Zu diesen Änderungen gehören die folgenden Funktionen:
- Private IP-Adresse nur Front-End-IP-Konfiguration
- Keine öffentliche IP-Adressressource erforderlich
- Beseitigung des eingehenden Datenverkehrs vom GatewayManager-Diensttag über die Netzwerksicherheitsgruppe
- Möglichkeit zur Definition einer NSG-Regel (Deny All outbound Network Security Group) zur Beschränkung des ausgehenden Datenverkehrs in das Internet
- Möglichkeit zum Überschreiben der Standardroute zum Internet (0.0.0.0/0)
- DNS-Auflösung über definierte Resolver im virtuellen Netzwerk Erfahren Sie mehr, einschließlich privater DNS-Zonen für private Links.
Jedes dieser Features kann unabhängig voneinander konfiguriert werden. So kann beispielsweise eine öffentliche IP-Adresse verwendet werden, um eingehenden Datenverkehr aus dem Internet zuzulassen, und Sie können in der Konfiguration der Netzwerksicherheitsgruppe eine Regel Deny All für ausgehenden Datenverkehr definieren, um die Exfiltration von Daten zu verhindern.
Onboarding in die öffentliche Vorschau
Die Funktionalität der neuen Steuerelemente der privaten IP-Front-End-Konfiguration, die Kontrolle über NSG-Regeln und die Kontrolle über Routentabellen befinden sich derzeit in der öffentlichen Vorschau. Um an der öffentlichen Vorschau teilzunehmen, können Sie sich über das Azure-Portal, PowerShell, CLI oder REST-API anmelden.
Wenn Sie an der Vorschau teilnehmen, werden alle neuen Anwendungsgateways mit der Möglichkeit bereitgestellt, eine beliebige Kombination der NSG-, Routentabellen- oder privaten IP-Konfigurationsfunktionen zu definieren. Wenn Sie sich von der neuen Funktionalität abmelden und zur aktuellen allgemein verfügbaren Funktionalität des Anwendungsgateways zurückkehren möchten, können Sie dies über die Registrierung von der Vorschau aus aufheben.
Weitere Informationen über Previewfunktionen finden Sie unter Vorschaufunktionen in Azure-Abonnement einrichten
Für die Vorschau registrieren
Führen Sie die folgenden Schritte aus, um sich bei der öffentlichen Vorschau für die erweiterten Anwendungsgateway-Netzwerksteuerelemente über das Azure-Portal zu registrieren:
Melden Sie sich beim Azure-Portal an.
Geben Sie im Suchfeld Abonnements ein, und wählen Sie Abonnements aus.
Wählen Sie den Link für den Namen Ihres Abonnements aus.
Wählen Sie im linken Menü unter Einstellungen die Option Previewfunktionen aus.
Es wird eine Liste der verfügbaren Previewfunktionen mit dem jeweiligen aktuellen Registrierungsstatus angezeigt.
Geben Sie in den Previewfunktionen in das Filterfeld EnableApplicationGatewayNetworkIsolation ein, markieren Sie die Funktion, und klicken Sie auf Registrieren.
Hinweis
Die Featureregistrierung kann bis zu 30 Minuten dauern, bis der Übergang vom Registrierungsstatus zum registrierten Status erfolgt.
Weitere Informationen über Previewfunktionen finden Sie unter Vorschaufunktionen in Azure-Abonnement einrichten
Löschen der Registrierung aus der Vorschau
Wenn Sie die öffentliche Vorschau für die erweiterten Anwendungsgateway-Netzwerksteuerelemente über das Portal deaktivieren möchten, führen Sie die folgenden Schritte aus:
Melden Sie sich beim Azure-Portal an.
Geben Sie im Suchfeld Abonnements ein, und wählen Sie Abonnements aus.
Wählen Sie den Link für den Namen Ihres Abonnements aus.
Wählen Sie im linken Menü unter Einstellungen die Option Previewfunktionen aus.
Es wird eine Liste der verfügbaren Previewfunktionen mit dem jeweiligen aktuellen Registrierungsstatus angezeigt.
Geben Sie in den Previewfunktionen in das Filterfeld EnableApplicationGatewayNetworkIsolation ein, markieren Sie die Funktion, und klicken Sie auf Registrierung aufheben.
Regionen und Verfügbarkeit
Die Vorschau des privaten Application Gateway ist für alle öffentlichen Cloudregionen verfügbar, in denen Application Gateway v2 SKU unterstützt wird.
Konfiguration von Netzwerksteuerelementen
Nach der Registrierung in der öffentlichen Vorschau kann die Konfiguration von NSG, Route Table und private IP-Adressen-Front-End-Konfiguration mit beliebigen Methoden ausgeführt werden. Zum Beispiel: REST-API, ARM-Vorlage, Bicep-Bereitstellung, Terraform, PowerShell, CLI oder Portal. Mit dieser öffentlichen Vorschau werden keine API- oder Befehlsänderungen eingeführt.
Ressourcenänderungen
Nachdem Ihr Gateway bereitgestellt wurde, wird automatisch ein Ressourcentag mit dem Namen EnhancedNetworkControl und dem Wert True zugewiesen. Siehe folgendes Beispiel:
Das Ressourcentag ist kosmetischer Natur und dient dazu, zu bestätigen, dass das Gateway mit den Fähigkeiten ausgestattet wurde, eine beliebige Kombination der Funktionen des Private-Only-Gateways zu konfigurieren. Änderungen oder Löschungen des Tags oder Werts ändern keine funktionalen Funktionsweisen des Gateways.
Tipp
Das EnhancedNetworkControl-Tag kann hilfreich sein, wenn bestehende Anwendungs-Gateways vor der Aktivierung der Funktion im Abonnement bereitgestellt wurden und Sie unterscheiden möchten, welches Gateway die neue Funktionalität nutzen kann.
Application Gateway-Subnetz
Das Subnetz „Anwendungsgateway“ ist das Subnetz innerhalb des virtuellen Netzwerks, in dem die Ressourcen des Anwendungsgateways bereitgestellt werden sollen. In der Konfiguration der privaten IP-Adresse am Front-End ist es wichtig, dass dieses Subnetz privat die Ressourcen erreichen kann, die eine Verbindung mit Ihrer verfügbar gemachten App oder Site herstellen möchten.
Internetkonnektivität in ausgehender Richtung
Application Gateway-Bereitstellungen, die nur eine private Front-End-IP-Konfiguration enthalten (also keine öffentliche IP-Front-End-Konfiguration haben, die mit einer Anforderungsroutingregel verbunden ist), sind nicht in der Lage, für das Internet bestimmten Datenverkehr auszugeben. Diese Konfiguration wirkt sich auf die Kommunikation mit Back-End-Zielen aus, die über das Internet öffentlich zugänglich sind.
Um eine ausgehende Konnektivität von Ihrem Application Gateway zu einem Backend-Ziel im Internet zu ermöglichen, können Sie Virtual Network NAT verwenden oder den Datenverkehr an eine virtuelle Appliance weiterleiten, die Zugang zum Internet hat.
Virtual Network NAT bietet Kontrolle darüber, welche IP-Adresse oder welches Präfix verwendet werden soll, sowie konfigurierbare Leerlauftimeouts. Erstellen Sie zum Konfigurieren ein neues NAT-Gateway mit einer öffentlichen IP-Adresse oder einem öffentlichen Präfix, und ordnen Sie es dem Subnetz zu, das das Anwendungsgateway enthält.
Wenn ein virtuelles Gerät für den Internetausgang erforderlich ist, lesen Sie den Abschnitt Route Table Control in diesem Dokument.
Häufige Szenarien, in denen die öffentliche IP-Verwendung erforderlich ist:
- Kommunikation mit Schlüsseltresor ohne Verwendung privater Endpunkte oder Dienstendpunkte
- Für pfx-Dateien, die direkt in Application Gateway hochgeladen werden, ist keine ausgehende Kommunikation erforderlich
- Kommunikation mit Back-End-Zielen über das Internet
- Kommunikation mit internetgerichteten CRL- oder OCSP-Endpunkten
Netzwerksicherheitsgruppe
Netzwerksicherheitsgruppen, die einem Anwendungsgateway-Subnetz zugeordnet sind, erfordern keine eingehenden Regeln mehr für GatewayManager, und sie erfordern keinen ausgehenden Zugriff auf das Internet. Die einzige erforderliche Regel ist Eingehenden Verkehr von AzureLoadBalancer erlauben, um sicherzustellen, dass Integritätssonden das Gateway erreichen können.
Die folgende Konfiguration ist ein Beispiel für den restriktivsten Satz eingehender Regeln, der jeglichen Datenverkehr mit Ausnahme von Azure-Integritätstests verweigert. Zusätzlich zu den definierten Regeln werden explizite Regeln definiert, damit Clientdatenverkehr den Listener des Gateways erreichen kann.
Hinweis
Application Gateway zeigt eine Warnung an und fordert Sie auf, sicherzustellen, dass die Allow LoadBalanceRule angegeben ist, wenn eine DenyAll-Regel versehentlich den Zugriff auf Integritätstests einschränkt.
Beispielszenario
In diesem Beispiel wird die Erstellung einer NSG mithilfe des Azure-Portals mit den folgenden Regeln erläutert:
- Eingehender Datenverkehr an Port 80 und 8080 zu Anwendungsgateway von Clientanforderungen, die aus dem Internet stammen, wird zugelassen
- Aller andere eingehende Datenverkehr wird verweigert
- Ausgehender Verkehr zu einem Back-End-Ziel in einem anderen virtuellen Netzwerk wird zugelassen
- Ausgehender Verkehr zu einem Back-End-Ziel, das über das Internet erreichbar ist, wird zugelassen
- Aller andere ausgehende Datenverkehr wird verweigert
Zuerst erstellen Sie eine Netzwerksicherheitsgruppe. Diese Sicherheitsgruppe enthält Ihre eingehenden und ausgehenden Regeln.
Eingangsregeln
Drei eingehende Standardregeln werden bereits in der Sicherheitsgruppe bereitgestellt. Siehe folgendes Beispiel:
Erstellen Sie als Nächstes die folgenden vier neuen eingehenden Sicherheitsregeln:
- Eingehenden Port 80, TCP, aus dem Internet zulassen (beliebig)
- Eingehenden Port 8080, TCP, aus dem Internet zulassen (beliebig)
- Eingehenden AzureLoadBalancer zulassen
- Allen eingehenden Verkehr verweigern
So erstellen Sie diese Regeln:
- Wählen Sie Eingangssicherheitsregeln
- Wählen Sie Hinzufügen aus
- Geben Sie die folgenden Informationen für jede Regel in den Bereich Eingehende Sicherheitsregel hinzufügen ein.
- Wenn Sie die Informationen eingegeben haben, wählen Sie Hinzufügen aus, um die Regel zu erstellen.
- Die Erstellung jeder Regel dauert einen Moment.
| Regelnr. | Quelle | Quelldiensttag | Source port ranges | Destination | Dienst | Dest-Portbereiche | Protokoll | Aktion | Priority | Name |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Any | * | Any | HTTP | 80 | TCP | Allow | 1028 | AllowWeb | |
| 2 | Any | * | Any | Benutzerdefiniert | 8080 | TCP | Allow | 1029 | AllowWeb8080 | |
| 3 | Diensttag | AzureLoadBalancer | * | Any | Benutzerdefiniert | * | Any | Allow | 1045 | AllowLB |
| 4 | Any | * | Any | Benutzerdefiniert | * | Any | Verweigern | 4095 | DenyAllInbound |
Wählen Sie Aktualisieren aus, um alle Regeln zu überprüfen, wenn die Bereitstellung abgeschlossen ist.
Ausgangsregeln
Drei standardmäßige ausgehende Regeln mit Priorität 65000, 65001 und 65500 werden bereits bereitgestellt.
Erstellen Sie die folgenden drei neuen ausgehenden Sicherheitsregeln:
- TCP 443 von 10.10.4.0/24 zum Back-End-Ziel 203.0.113.1 zulassen
- TCP 80 von Quelle 10.10.4.0/24 zum Ziel 10.13.0.4 zulassen
- DenyAll-Datenverkehrsregel
Diesen Regeln wird jeweils eine Priorität von 400, 401 und 4096 zugewiesen.
Hinweis
- 10.10.4.0/24 ist der Subnetz-Adressraum des Application Gateway.
- 10.13.0.4 ist eine virtuelle Maschine in einem VNet mit Peer-Rechten.
- 203.0.113.1 ist eine Back-End-Ziel-VM.
So erstellen Sie diese Regeln:
- Wählen Sie Ausgehende Sicherheitsregeln
- Wählen Sie Hinzufügen aus
- Geben Sie die folgenden Informationen für jede Regel in den Bereich Ausgehende Sicherheitsregel hinzufügen ein.
- Wenn Sie die Informationen eingegeben haben, wählen Sie Hinzufügen aus, um die Regel zu erstellen.
- Die Erstellung jeder Regel dauert einen Moment.
| Regelnr. | Quelle | IP-Quelladressen/CIDR-Bereiche | Source port ranges | Destination | Ziel-IP-Adressen/CIDR-Bereiche | Dienst | Dest-Portbereiche | Protokoll | Aktion | Priority | Name |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | IP-Adressen | 10.10.4.0/24 | * | IP-Adressen | 203.0.113.1 | HTTPS | 443 | TCP | Allow | 400 | AllowToBackendTarget |
| 2 | IP-Adressen | 10.10.4.0/24 | * | IP-Adressen | 10.13.0.4 | HTTP | 80 | TCP | Allow | 401 | AllowToPeeredVnetVM |
| 3 | Any | * | Any | Benutzerdefiniert | * | Any | Verweigern | 4096 | DenyAll |
Wählen Sie Aktualisieren aus, um alle Regeln zu überprüfen, wenn die Bereitstellung abgeschlossen ist.
NSG dem Subnetz zuordnen
Der letzte Schritt besteht darin, die Netzwerksicherheitsgruppe dem Subnetz zuzuordnen, das Ihr Anwendungsgateway enthält.
Ergebnis:
Wichtig
Seien Sie vorsichtig, wenn Sie DenyAll-Regeln definieren, da Sie versehentlich eingehenden Datenverkehr von Clients verweigern könnten, denen Sie den Zugriff erlauben wollen. Sie können auch versehentlich ausgehenden Datenverkehr an das Back-End-Ziel verweigern, was dazu führt, dass die Back-End-Integrität fehlschlägt und 5XX-Antworten erzeugt.
Routingtabellen-Steuerelement
Im aktuellen Angebot von Application Gateway wird die Zuordnung einer Routentabelle zu einer Regel (oder die Erstellung einer Regel), die als 0.0.0.0/0 mit einem nächsten Hop als virtuelle Appliance definiert ist, nicht unterstützt, um eine ordnungsgemäße Verwaltung von Application Gateway zu gewährleisten.
Nach der Registrierung des Features für die öffentliche Vorschau ist die Möglichkeit, den Datenverkehr an eine virtuelle Appliance weiterzuleiten, jetzt über die Definition einer Routentabellenregel möglich, die 0.0.0.0/0 mit einem nächsten Hop zu virtuellen Geräten definiert.
Erzwungenes Tunneln oder Lernen von 0.0.0.0/0-Route durch BGP-Werbung wirkt sich nicht auf die Integrität des Anwendungsgateways aus und wird für den Datenverkehrsfluss berücksichtigt. Dieses Szenario kann bei Verwendung von VPN, ExpressRoute, Route Server oder Virtual WAN anwendbar sein.
Beispielszenario
Im folgenden Beispiel erstellen wir eine Routentabelle und ordnen sie dem Subnetz des Anwendungsgateways zu, um sicherzustellen, dass der ausgehende Internetzugriff vom Subnetz von einer virtuellen Appliance aus erfolgt. Auf hoher Ebene wird der folgende Entwurf in Abbildung 1 zusammengefasst:
- Das Anwendungs-Gateway befindet sich in einem virtuellen Speichennetz
- Im Hub-Netzwerk befindet sich eine virtuelle Netzwerk-Appliance (eine virtuelle Maschine)
- Eine Routentabelle mit einer Standardroute (0.0.0.0/0) zum virtuellen Gerät ist dem Anwendungsgateway-Subnetz zugeordnet
Abbildung 1: Ausgehender Internetzugriff über virtuelles Gerät
So erstellen Sie eine Routentabelle und ordnen sie dem Subnetz des Anwendungsgateways zu:
- Wählen Sie Routen aus, und erstellen Sie die nächste Hopregel für 0.0.0.0/0, und konfigurieren Sie das Ziel als IP-Adresse Ihrer VM:
- Wählen Sie Subnetze aus, und ordnen Sie die Routentabelle dem Subnetz des Anwendungsgateways zu:
- Überprüfen Sie, ob der Datenverkehr über das virtuelle Gerät läuft.
Einschränkungen / Bekannte Probleme
In der öffentlichen Vorschau sind die folgenden Einschränkungen bekannt.
Konfiguration privater Verbindungen
Die Unterstützung der Konfiguration der privaten Verbindung für das Tunneln des Datenverkehrs durch private Endpunkte zum Anwendungsgateway wird bei einem reinen privaten Gateway nicht unterstützt.
WAF-Ratenbegrenzung
Benutzerdefinierte Ratenbegrenzungsregeln für Application Gateway WAF v2 werden derzeit nicht unterstützt.
Private IP-Frontend-Konfiguration nur mit AGIC
AGIC v1.7 muss verwendet werden, um nur die Unterstützung für private Frontend-IP einzuführen.
Private Endpunkt-Konnektivität über globales VNet-Peering
Wenn das Anwendungsgateway über ein Back-End-Ziel oder einen Schlüsseltresorverweis auf einen privaten Endpunkt verfügt, der über das globale VNet-Peering zugänglich ist, wird der Datenverkehr verworfen, was zu einem fehlerhaften Status führt.
Network Watcher-Integration
Verbindungsproblembehandlung und NSG-Diagnose geben bei der Durchführung von Prüf- und Diagnosetests einen Fehler zurück.
Vorhandene v2-Anwendungsgateways, die vor der Aktivierung der erweiterten Netzwerksteuerung erstellt wurden
Wenn ein Subnetz ein Anwendungsgateway v2-Bereitstellungen teilt, die vor und nach der Aktivierung der erweiterten Netzwerksteuerungsfunktionen erstellt wurden, ist die Netzwerksicherheitsgruppe (Network Security Group, NSG) und die Routingtabellenfunktion auf die vorherige Gatewaybereitstellung beschränkt. Anwendungsgateways, die vor der Aktivierung der neuen Funktionalität bereitgestellt werden, müssen entweder neu bereitgestellt werden, oder neu erstellte Gateways müssen ein anderes Subnetz verwenden, um erweiterte Netzwerksicherheitsgruppen- und Routingtabellenfeatures zu ermöglichen.
- Wenn ein Gateway, das vor der Aktivierung der neuen Funktionalität im Subnetz bereitgestellt wurde, vorhanden ist, werden möglicherweise Fehler angezeigt, wie z. B.
For routes associated to subnet containing Application Gateway V2, please ensure '0.0.0.0/0' uses Next Hop Type as 'Internet': beim Hinzufügen von Routentabelleneinträgen. - Beim Hinzufügen von Netzwerksicherheitsgruppenregeln zum Subnetz wird möglicherweise Folgendes angezeigt:
Failed to create security rule 'DenyAnyCustomAnyOutbound'. Error: Network security group \<NSG-name\> blocks outgoing Internet traffic on subnet \<AppGWSubnetId\>, associated with Application Gateway \<AppGWResourceId\>. This isn't permitted for Application Gateways that have fast update enabled or have V2 Sku.
Unbekannter Back-End-Integritätsstatus
Wenn die Back-End-Integrität unbekannt ist, wird möglicherweise folgender Fehler angezeigt:
- Der Back-End-Integritätsstatus konnte nicht abgerufen werden. Dies geschieht, wenn eine NSG/UDR/Firewall im Subnetz „Anwendungsgateway“ den Datenverkehr an den Ports 65503–65534 im Fall der v1-SKU und an den Ports 65200–65535 im Fall der v2-SKU blockiert oder der im Back-End-Pool konfigurierte FQDN nicht in eine IP-Adresse aufgelöst werden konnte. Weitere Informationen finden Sie hier: https://aka.ms/UnknownBackendHealth.
Dieser Fehler kann ignoriert werden und wird in einer zukünftigen Version geklärt.
Nächste Schritte
- Weitere bewährte Methoden finden Sie unter Azure Security Baseline für Anwendungsgateway.