Application Gateway-Integration

Dieser Artikel führt Sie durch die Konfiguration von Application Gateway mit App Service, indem private Endpunkte zum Schützen des Datenverkehrs verwendet werden. Dieser Artikel erörtert auch Überlegungen zur Verwendung privater Endpunkte und zur Integration mit internen und externen App Service-Umgebungen. Schließlich beschreibt dieser Artikel, wie Sie Zugriffseinschränkungen auf einer Website des Quellcodeverwaltungsmanagers (Source Control Manager, SCM) festlegen.

Integration mit App Service

Sie können einen privaten Endpunkt verwenden, um den Datenverkehr zwischen Application Gateway und Ihrer App Service-App zu sichern. Sie müssen sicherstellen, dass Application Gateway DNS verwenden kann, um die private IP-Adresse der App Service-Apps aufzulösen. Alternativ können Sie die private IP-Adresse im Back-End-Pool verwenden und den Hostnamen in den HTTP-Einstellungen überschreiben.

Application Gateway speichert die Ergebnisse der DNS-Suche zwischen. Wenn Sie vollqualifizierte Domänennamen (FQDNs) verwenden und die private IP-Adresse mithilfe von DNS-Lookup abrufen, müssen Sie möglicherweise das Anwendungsgateway neu starten, wenn die DNS-Aktualisierung oder die Verknüpfung zu einer privaten Azure-DNS-Zone erfolgt ist, nachdem Sie den Back-End-Pool konfiguriert haben.

Um das Anwendungsgateway neu zu starten, beenden und starten Sie es mithilfe der Azure CLI:

Azure CLI

az network application-gateway stop --resource-group myRG --name myAppGw
az network application-gateway start --resource-group myRG --name myAppGw

Erfahren Sie mehr über das Konfigurieren einer App Service-App mit privatem Endpunkt.

Überlegungen zur Verwendung von Dienstendpunkten

Als Alternative zu privaten Endpunkten können Sie Dienstendpunkte verwenden, um den Datenverkehr vom Application Gateway zu sichern. Mithilfe von Dienstendpunkten können Sie dafür sorgen, dass Datenverkehr nur von einem bestimmten Subnetz innerhalb eines virtuellen Azure-Netzwerks zugelassen und alles andere blockiert wird. Im folgenden Szenario verwenden Sie diese Funktion, um sicherzustellen, dass eine App Service-Instanz Datenverkehr nur von einem bestimmten Anwendungsgateway empfangen kann.

Diese Konfiguration umfasst zwei Teile, nebst der Erstellung der App Service-App-Instanz und dem Anwendungsgateway. Der erste Teil besteht darin, Dienstendpunkte im Subnetz des virtuellen Netzwerks zu aktivieren, in dem das Anwendungsgateway bereitgestellt wird. Dienstendpunkte sorgen dafür, dass der gesamte Netzwerkdatenverkehr, der das Subnetz in Richtung App Service verlässt, mit der spezifischen Subnetz-ID gekennzeichnet ist.

Der zweite Teil besteht darin, eine Zugriffseinschränkung für die spezifische Web-App festzulegen, um sicherzustellen, dass nur Datenverkehr zugelassen wird, der mit dieser spezifischen Subnetz-ID gekennzeichnet ist. Sie können die Zugriffseinschränkung je nach Ihren Vorlieben mit verschiedenen Tools konfigurieren.

Mit dem Azure-Portal führen Sie vier Schritte aus, um das Setup von App Service und Application Gateway zu erstellen und zu konfigurieren. Wenn Sie bereits über Ressourcen verfügen, können Sie die ersten Schritte überspringen.

1. Erstellen Sie eine App Service-Instance mithilfe eines der Schnellstarts in der App Service-Dokumentation. Ein Beispiel ist der .NET Core-Schnellstart.
2. Erstellen Sie ein Anwendungsgateway mithilfe des Portal-Schnellstarts, überspringen Sie jedoch den Abschnitt zum Hinzufügen von Back-End-Zielen.
3. Konfigurieren Sie App Service als Back-End in Application Gateway, überspringen Sie jedoch den Abschnitt über das Beschränken des Zugriffs.
4. Erstellen Sie die Zugriffseinschränkung mithilfe von Dienstendpunkten.

Sie können jetzt über Application Gateway auf App Service zugreifen. Wenn Sie versuchen, direkt auf App Service zuzugreifen, sollte der HTTP-Fehler 403 angezeigt werden, der besagt, dass die Web-App Ihren Zugriff blockiert.

Überlegungen zu einer internen App Service-Umgebung

Eine interne App Service-Umgebung ist für das Internet nicht sichtbar. Datenverkehr zwischen der Instanz und einem Anwendungsgateway ist bereits im virtuellen Netzwerk isoliert. Informationen zum Konfigurieren einer internen App Service-Umgebung und dessen Integration in ein Anwendungsgateway mithilfe des Azure-Portals finden Sie in der Schrittanleitung.

Wenn Sie sicherstellen möchten, dass nur Datenverkehr aus dem Application Gateway-Subnetz die App Service-Umgebung erreicht, können Sie eine Netzwerksicherheitsgruppe (NSG) konfigurieren, die sich auf alle Web-Apps in der App Service-Umgebung auswirkt. Für die NSG können Sie den Subnetz-IP-Adressbereich und optional die Ports (80/443) angeben.

Um Datenverkehr an eine einzelne Web-App zu isolieren, müssen Sie IP-basierte Zugriffseinschränkungen verwenden, da Dienstendpunkte nicht mit einer App Service-Umgebung funktionieren. Bei der IP-Adresse muss es sich um die private IP-Adresse des Anwendungsgateways handeln.

Überlegungen zu einer externen App Service-Umgebung

Eine externe App Service-Umgebung verfügt über einen öffentlichen Lastenausgleich wie mandantenfähige App Service-Apps. Dienstendpunkte funktionieren nicht für eine App Service-Umgebung. Mit der App Service-Umgebung können Sie IP-basierte Zugriffseinschränkungen über die öffentliche IP-Adresse des Anwendungsgateways verwenden. Um eine externe App Service-Umgebung über das Azure-Portal erstellen, können Sie diesen Schnellstart verwenden.

Sie können auch private Endpunkte zu Apps hinzufügen, die in einer externen App Service-Umgebung gehostet werden.

Überlegungen zu einer Kudu/SCM-Website

Die SCM-Website, auch als Kudu bekannt, ist eine für jede Web-App vorhandene Administratorwebsite. Es ist nicht möglich, einen Reverseproxy für die SCM-Website zu verwenden. Wahrscheinlich wollen Sie auch einzelne IP-Adressen oder ein bestimmtes Subnetz sperren.

Wenn Sie die gleichen Zugriffseinschränkungen verwenden möchten wie für die Hauptwebsite, können Sie die Einstellungen mithilfe des folgenden Befehls erben:

Azure CLI

az webapp config access-restriction set --resource-group myRG --name myWebApp --use-same-restrictions-for-scm-site

Wenn Sie individuelle Zugriffseinschränkungen für die SCM-Website hinzufügen möchten, können Sie das --scm-site-Flag verwenden:

Azure CLI

az webapp config access-restriction add --resource-group myRG --name myWebApp --scm-site --rule-name KudoAccess --priority 200 --ip-address 208.130.0.0/16

Überlegungen zur Verwendung der Standarddomäne

Das Konfigurieren von Application Gateway, um den Hostnamen zu überschreiben und die Standarddomäne von App Service (in der Regel azurewebsites.net) zu verwenden, ist die einfachste Möglichkeit, die Integration zu konfigurieren. Es ist nicht erforderlich, eine benutzerdefinierte Domäne und ein Zertifikat in App Service zu konfigurieren.

Dieser Artikel erläutert die allgemeinen Überlegungen beim Überschreiben des ursprünglichen Hostnamens. In App Service gibt es zwei Szenarien, in denen Sie bei dieser Konfiguration Vorsicht walten lassen müssen.

Authentifizierung

Wenn Sie das Authentifizierungsfeature in App Service verwenden (auch als einfache Authentifizierung bezeichnet), leitet Ihre App in der Regel zur Anmeldeseite um. Da App Service den ursprünglichen Hostnamen der Anforderung nicht kennt, erfolgt die Umleitung für den Standarddomänennamen und führt in der Regel zu einem Fehler.

Um die Standardumleitung zu umgehen, können Sie die Authentifizierung so konfigurieren, dass sie einen weitergeleiteter Header überprüft und die Umleitungsdomäne an die ursprüngliche Domäne anpasst. Application Gateway verwendet einen Header namens X-Original-Host. Mithilfe der dateibasierten Konfiguration zum Konfigurieren der Authentifizierung können Sie App Service so konfigurieren, dass er sich an den ursprünglichen Hostnamen anpasst. Fügen Sie der Konfigurationsdatei diese Konfiguration hinzu:

JSON

{
    ...
    "httpSettings": {
        "forwardProxy": {
            "convention": "Custom",
            "customHostHeaderName": "X-Original-Host"
        }
    }
    ...
}

Sitzungsaffinität

Bei Bereitstellungen mit mehreren Instanzen stellt die Sitzungsaffinität sicher, dass Clientanforderungen für die Lebensdauer der Sitzung an dieselbe Instanz weitergeleitet werden. Die Sitzungsaffinität kann so konfiguriert werden, dass die Cookiedomäne vom Reverseproxy an den eingehenden Header angepasst wird. Durch Konfigurieren des Sitzungsaffinitätsproxys auf TRUE sucht die Sitzungsaffinität nach X-Original-Host oder X-Forwarded-Host und passt die Cookiedomäne an die Domäne in diesem Header an. Als empfohlene Vorgehensweise beim Aktivieren des Sitzungsaffinitätsproxys sollten Sie Ihre Zugriffseinschränkungen auf der Site konfigurieren, um sicherzustellen, dass der Datenverkehr von Ihrem Reverseproxy stammt.

Sie können auch clientAffinityProxyEnabled mit dem folgenden Befehl konfigurieren:

Azure CLI

az resource update --resource-group myRG --name myWebApp --resource-type "Microsoft.Web/sites" --set properties.clientAffinityProxyEnabled=true

Nächste Schritte

Weitere Informationen zur App Service-Umgebung finden Sie in der Dokumentation zur App Service-Umgebung.

In der Dokumentation zum Azure Web Application-Firewall finden Sie Informationen zur Azure Web Application Firewall in Application Gateway, mit der Sie Ihre App noch sicherer machen können.

Um eine sichere, resiliente Website mit einer benutzerdefinierten Domäne in App Service entweder mittels Azure Front Door oder Application Gateway bereitzustellen, lesen Sie dieses Tutorial.