Anwendungen in Microsoft Azure App Service mit NGINX Plus absichern

NGINX | 03. Oktober 2018

Der Aufstieg des Cloud-Computings – und insbesondere von Platform-as-a-Service-(PaaS-) und Container-as-a-Service-(CaaS-)Angeboten – verändert die Art und Weise, wie Unternehmen ihre Geschäftsanwendungen bereitstellen und betreiben. Eine der größten Herausforderungen bei der Entwicklung von Cloud-Anwendungen besteht darin, vollständig verwaltete Cloud-Dienste auszuwählen, die Kosten und zeitaufwendige betriebliche Aufgaben reduzieren, ohne die Sicherheit zu beeinträchtigen.

In diesem Blogbeitrag erfahren Sie, wie Sie Anwendungen in Microsoft Azure App Service hosten und mit NGINX Plus absichern, um Angriffe aus dem Internet zu verhindern.

Kurzer Überblick über Microsoft Azure App Service

Microsoft Azure App Service ist eine vollständig verwaltete Plattform für Unternehmen, mit der Organisationen Web-, API- und mobile Apps in Microsoft Azure bereitstellen können, ohne die zugrunde liegende Infrastruktur verwalten zu müssen, wie in Abbildung 1 dargestellt. Azure App Service bietet die folgenden Hauptfunktionen:

  • Web Apps ermöglicht Ihnen, Web-Apps in verschiedenen Sprachen und Frameworks (ASP.NET, Node.js, Java, PHP und Python) bereitzustellen und auszuführen. Darüber hinaus lassen sich damit skalierbare und zuverlässige Webanwendungen mithilfe der Internet Information Services (IIS) verwalten. Hierfür stehen umfassende Funktionen zur Anwendungsverwaltung zur Verfügung (Überwachung, Wechsel von der Staging- zur Produktionsumgebung, Löschen bereitgestellter Anwendungen usw.). Außerdem wird eine Docker-Laufzeitumgebung bereitgestellt, mit der Webanwendungen unter Linux in Containern ausgeführt werden können.
  • API Apps bietet Tools für die Bereitstellung von REST-APIs mit Unterstützung für CORS (Cross-Origin Resource Sharing). Azure API Apps lassen sich ohne Codeänderungen problemlos mit Azure Active Directory, Single Sign-On (SSO) über soziale Netzwerke oder OAuth absichern.
  • Mobile Apps ermöglichen die schnelle Bereitstellung mobiler Backend-Dienste, die wichtige Funktionen wie Authentifizierung, Pushbenachrichtigungen, Benutzerverwaltung, Cloudspeicher usw. unterstützen.

Abbildung 1: Azure App Service

Mit Azure App Service bietet Microsoft eine leistungsstarke und schnelle Möglichkeit, Webanwendungen in der Cloud auszuführen. Entwickler können ihre Anwendungen lokal mit ASP.NET, Java, Node.js, PHP und Python entwickeln und sie mit Microsoft Visual Studio oder der Azure CLI ganz einfach in Azure App Service bereitstellen. DevOps-Teams können außerdem die Continuous-Deployment-Funktion von Azure App Service nutzen, um Anwendungsversionen schnell und zuverlässig in mehreren Umgebungen bereitzustellen.

Anwendungen in Azure App Service können auf andere in Azure bereitgestellte Ressourcen zugreifen oder über VPNs Verbindungen zu lokalen Unternehmensressourcen herstellen.

Grundlegendes zu Azure App Service-Umgebungen

Grundsätzlich ist eine mit Azure App Service erstellte Anwendung direkt über das Internet erreichbar und einer Subdomain von azurewebsites.net zugeordnet. Für mehr Sicherheit können Sie Ihre App durch SSL-Terminierung oder mit Authentifizierungs- und Autorisierungsprotokollen wie OAuth2 oder OpenID Connect (OIDC) schützen. Es ist jedoch nicht möglich, das Netzwerk mit detaillierten Sicherheitsregeln für ausgehenden und eingehenden Datenverkehr anzupassen oder Middleware wie eine Web Application Firewall (WAF) einzusetzen, um böswillige Angriffe oder Exploits aus dem Internet abzuwehren.

Wenn Sie sensible Anwendungen in Azure App Service ausführen und schützen möchten, können Sie Azure App Service Environments (ASEs) verwenden. Eine ASE ist eine isolierte Umgebung, die in einem virtuellen Netzwerk bereitgestellt wird und ausschließlich für die Anwendungen eines einzelnen Kunden vorgesehen ist. Dadurch erhalten Sie mehr Kontrolle über den ein- und ausgehenden Netzwerkdatenverkehr Ihrer Anwendungen.

Mit ASEs können Sie Web-, API-, Mobil- oder Funktions-Apps in einer sichereren Umgebung und mit sehr hoher Skalierbarkeit bereitstellen, wie in Abbildung 2 dargestellt.

Abbildung 2: NGINX ModSecurity WAF filtert den Datenverkehr für eine Azure ASE

Erstellen einer neuen ASE v2

Es gibt zwei Versionen der ASE: ASE v1 und ASE v2. In diesem Beitrag geht es um ASE v2.

Sie können eine neue ASE v2 manuell über das Azure-Portal oder automatisch mithilfe von Azure Resource Manager erstellen.

Beim Erstellen einer neuen ASE müssen Sie zwischen zwei Bereitstellungstypen wählen:

  • Eine externe ASE stellt die in der ASE gehosteten Anwendungen über eine öffentliche IP-Adresse bereit.
  • Eine ILB-ASE stellt die in der ASE gehosteten Anwendungen über eine private IP-Adresse bereit, auf die nur innerhalb Ihres virtuellen Azure-Netzwerks zugegriffen werden kann. Der interne Endpunkt wird in Azure als interner Lastenausgleich (Internal Load Balancer, ILB) bezeichnet.

Im folgenden Beispiel wählen wir eine ILB ASE, um den Zugriff über das Internet zu verhindern. Daher sind die in unserer ASE bereitgestellten Anwendungen nur von virtuellen Computern (VMs) aus zugänglich, die im selben Netzwerk ausgeführt werden. Mit den folgenden beiden Befehlen werden über Azure Resource Manager und die Azure CLI eine neue ILB ASE v2 bereitgestellt:

$ azure config mode arm$ azure group deployment create my-resource-group my-deployment-name --template-uri https://raw.githubusercontent.com/azure/azure-quickstart-templates/master/201-web-app-asev2-ilb-create/azuredeploy.json

Zugriff auf Apps in einer öffentlich zugänglichen ASE absichern

Wenn Ihre App hingegen über das Internet erreichbar sein soll, müssen Sie sie vor böswilligen Angreifern schützen, die versuchen könnten, in Ihrer Anwendung gespeicherte vertrauliche Informationen zu stehlen.

Um Anwendungen auf Layer 7 in einer ASE abzusichern, haben Sie zwei Hauptoptionen:

(Sie können stattdessen einen benutzerdefinierten Application Delivery Controller [ADC] mit WAF-Funktionen verwenden, dieser Anwendungsfall wird hier jedoch nicht behandelt.)

Die Wahl der Lösung hängt von Ihren Sicherheitsanforderungen ab. Einerseits bietet Azure Application Gateway eine schlüsselfertige Lösung zur Durchsetzung von Sicherheitsrichtlinien, bei der Sie die zugrunde liegende Infrastruktur nicht selbst verwalten müssen. Andererseits erhalten Sie durch die Bereitstellung von NGINX Plus auf VMs einen leistungsstarken Stack mit mehr Kontrolle und Flexibilität für die präzise Abstimmung Ihrer Sicherheitsregeln.

Die Entscheidung zwischen Azure Application Gateway und NGINX Plus für den Lastenausgleich und die Absicherung von Anwendungen, die innerhalb einer ASE erstellt wurden, setzt ein gutes Verständnis der Funktionen voraus, die die jeweilige Lösung bietet. Azure Application Gateway eignet sich zwar für einfache Anwendungsfälle, bietet bei komplexen Anwendungsfällen jedoch viele Funktionen nicht, die in NGINX Plus standardmäßig enthalten sind.

Die folgende Tabelle vergleicht die Unterstützung von Lastverteilungs- und Sicherheitsfunktionen in Azure Application Gateway und NGINX Plus. Weitere Informationen zu den Funktionen von NGINX Plus finden Sie unterhalb der Tabelle.

Funktion Azure Application Gateway NGINX PlusAbwehrfunktion Anwendungsschicht (Layer 7) Anwendungsschicht (Layer 7)HTTP-fähig ✅ ✅HTTP/2-fähig ❌ ✅WebSocket-fähig ❌ ✅SSL-Terminierung ✅ ✅Routing-Funktionen Einfache Entscheidung anhand der Anfrage-URL oder Cookie-basierter Sitzungsaffinität Erweiterte Routing-FunktionenIP-adressbasierte Zugriffssteuerungslisten ❌ (müssen in Azure auf Web-App-Ebene definiert werden) ✅Endpunkte Beliebige interne Azure-IP-Adresse, öffentliche Internet-IP-Adresse, Azure-VM oder Azure Cloud Service Beliebige interne Azure-IP-Adresse, öffentliche Internet-IP-Adresse, Azure-VM oder Azure Cloud ServiceAzure-VNet-Unterstützung Sowohl internetseitige als auch interne (VNet-)Anwendungen Sowohl internetseitige als auch interne (VNet-)AnwendungenWAF ✅ ✅Volumetrische Angriffe Teilweise TeilweiseProtokollangriffe Teilweise TeilweiseAngriffe auf Anwendungsebene ✅ ✅HTTP-Basisauthentifizierung ❌ ✅JWT-Authentifizierung ❌ ✅OpenID Connect SSO ❌ ✅

Wie Sie sehen, fungieren sowohl NGINX Plus als auch Azure Application Gateway als ADCs mit Layer-7-Lastverteilungsfunktionen und einer WAF, die einen starken Schutz vor gängigen Web-Schwachstellen und Exploits gewährleistet.

NGINX Plus bietet mehrere zusätzliche Funktionen, die Azure Application Gateway nicht bietet:

  • URL-Umschreibung und -Weiterleitung – Mit NGINX Plus können Sie die URL einer Anfrage umschreiben, bevor Sie sie an einen Backend-Server weiterleiten. So können Sie den Speicherort von Dateien oder Anfragepfade ändern, ohne die den Clients angezeigte URL zu ändern. Sie können Anfragen auch weiterleiten. Beispielsweise können Sie alle HTTP-Anfragen an einen HTTPS-Server weiterleiten.
  • Verbindungs- und Ratenbegrenzungen – Sie können mehrere Grenzwerte zur Steuerung des Datenverkehrs zu und von Ihren NGINX Plus-Instanzen konfigurieren. Dazu gehören Begrenzungen für die Anzahl eingehender Verbindungen, die Rate eingehender Anfragen, die Verbindungen zu Backend-Knoten und die Datenübertragungsrate von NGINX Plus zu Clients.
  • Unterstützung für HTTP/2 und WebSocket – NGINX Plus unterstützt HTTP/2 und WebSocket auf der Anwendungsschicht (Layer 7). Azure Application Gateway bietet diese Unterstützung nicht; stattdessen unterstützt Azure Load Balancer beide Protokolle auf der Netzwerkschicht (Layer 4), auf der TCP und UDP arbeiten.

Für zusätzliche Sicherheit können Sie Azure DDoS Protection bereitstellen, um Bedrohungen auf den Schichten 3 und 4 abzuwehren und so die von Azure Application Gateway oder NGINX Plus bereitgestellten Funktionen zur Bedrohungsabwehr auf Schicht 7 zu ergänzen.

NGINX Plus mit Azure App Service zum Schutz von Anwendungen verwenden

Abbildung 3 zeigt, wie NGINX Plus und Azure App Service kombiniert werden können, um eine sichere Umgebung für den Betrieb von Geschäftsanwendungen in der Produktion bereitzustellen. Diese Bereitstellungsstrategie nutzt NGINX Plus für den Lastenausgleich und die WAF-Funktionen.

Abbildung 3: NGINX Plus verteilt den Datenverkehr auf Anwendungen in einer Azure ASE

Die Bereitstellung umfasst die folgenden Komponenten:

  • Azure Virtual Network (VNet) – Stellt ein virtuelles Netzwerk in der Azure-Cloud dar, das Ihrer Organisation vorbehalten ist. Es bietet eine logische Isolierung, die es Azure-Ressourcen ermöglicht, innerhalb eines virtuellen Netzwerks sicher miteinander zu kommunizieren. Hier haben wir zwei Subnetze definiert: Internal für Webanwendungen, die nicht direkt über das Internet erreichbar sind, und Waf für NGINX Plus und die zugrunde liegende Infrastruktur.
  • Azure App Service Environment – Diese Beispielbereitstellung verwendet zwei Beispiel-Webanwendungen – Web-App 1 und Web-App 2 –, um zu veranschaulichen, wie verschiedene Webanwendungen mit NGINX Plus abgesichert und deren Lasten verteilt werden können. In NGINX Plus verteilen Sie Anfragen auf verschiedene Webanwendungen, indem Sie separate upstream-Blöcke konfigurieren, und führen mithilfe von location-Blöcken ein inhaltsbasiertes Routing anhand des URI durch. Im Folgenden sehen Sie die minimale NGINX Plus-Konfiguration, mit der dieses Ziel erreicht wird (hier werden alle Anfragen an dieselbe Upstream-Gruppe weitergeleitet):
upstream backend {    server IP-address-of-your-ASE-ILB;
}

server {
    location / {
        proxy_set_header Host $host;
        proxy_pass http://backend;
    }
}
  • NGINX Plus – Verteilt HTTP(S)-Verbindungen auf mehrere Webanwendungen. Die Bereitstellung von NGINX Plus auf einer VM bietet Ihnen mehr Kontrolle über die Infrastruktur als andere Azure-Dienste. Beispielsweise können Sie bei einer VM das Betriebssystem (Linux oder Windows) auswählen, das in einem isolierten virtuellen Netzwerk ausgeführt wird. Azure-VMs sind tatsächlich für alle Linux-Distributionen verfügbar, die NGINX Plus unterstützt (mit Ausnahme von Amazon Linux, aus naheliegenden Gründen).
  • Azure-VM-Skalierungsgruppen – VM-Skalierungsgruppen sind eine Azure-Computeressource, mit der Sie eine Gruppe identischer VMs bereitstellen und verwalten können. Sie können die Größe der VM konfigurieren und die VM dem richtigen VNet zuweisen. Für alle VMs, die innerhalb der Skalierungsgruppe ausgeführt werden, übernimmt ein Azure Load Balancer den Lastenausgleich und stellt die TCP-Konnektivität zwischen den VM-Instanzen bereit. Dabei basiert jede VM in der Skalierungsgruppe auf dem im Azure Marketplace verfügbaren NGINX Plus-Image. Skalierungsgruppen sind für eine echte automatische Skalierung ausgelegt.

Azure unterstützt außerdem Ressourcengruppen als einfache Möglichkeit, die Azure-Ressourcen für eine Anwendung logisch zu gruppieren. Die Verwendung einer Ressourcengruppe hat keine Auswirkungen auf das Infrastrukturdesign und die Topologie. Daher werden Ressourcengruppen hier nicht dargestellt.

Hochverfügbarkeit und automatische Skalierung von NGINX Plus mit Azure-VM-Skalierungsgruppen

Eine Azure-VM-Skalierungsgruppe bietet Ihnen die Vorteile der Virtualisierung und ermöglicht Ihnen, jederzeit zu skalieren, ohne die für die Skalierung erforderliche physische Hardware kaufen und warten zu müssen. Sie sind jedoch weiterhin für die Wartung der VM verantwortlich und müssen Aufgaben wie Konfiguration, Einspielen von Patches und Sicherheitsupdates sowie Installation der darauf ausgeführten Software übernehmen.

In der in Abbildung 4 dargestellten Architektur werden NGINX Plus-Instanzen für aktive/aktive Hochverfügbarkeit innerhalb einer Azure-VM-Skalierungsgruppe bereitgestellt. Eine Aktiv/Aktiv-Konfiguration ist besonders vorteilhaft, da alle NGINX Plus-VMs eingehende, von Azure Load Balancer weitergeleitete Anforderungen verarbeiten können und so kosteneffiziente Kapazität bereitstellen.

Abbildung 4: Azure-VM-Skalierungsgruppe mit Azure Load Balancer zur Lastverteilung des Datenverkehrs auf NGINX Plus

Mit Azure-VM-Skalierungsgruppen können Sie außerdem ganz einfach die automatische Skalierung von NGINX Plus-Instanzen auf Grundlage der durchschnittlichen CPU-Auslastung einrichten. In diesem Fall müssen Sie darauf achten, die NGINX Plus-Konfigurationsdateien zu synchronisieren. Zu diesem Zweck können Sie die Funktion zur gemeinsamen Nutzung der NGINX Plus-Konfiguration verwenden, wie im NGINX Plus-Administratorhandbuch beschrieben.

Zusammenfassung

Durch den Einsatz von Azure App Service für Ihre Cloudanwendungen und NGINX Plus vor Ihren Web-Apps, APIs und mobilen Backends können Sie die Last für diese Anwendungen weltweit verteilen und sie absichern. Wenn Sie NGINX Plus in Verbindung mit Azure App Service verwenden, erhalten Sie eine vollständig lastverteilte Infrastruktur mit einem hohen Maß an Schutz vor Exploits und Angriffen aus dem Internet. Dies gewährleistet eine robuste Architektur, mit der sich geschäftskritische Anwendungen sicher in einer Produktionsumgebung betreiben lassen.

Ressourcen

Übersicht über Web-Apps (Microsoft)
Einführung in App Service-Umgebungen (Microsoft)
Erstellen eines Anwendungsgateways mit einer Web Application Firewall über das Azure-Portal (Microsoft)
Funktionsvergleich zwischen NGINX Open Source und NGINX Plus (NGINX)
HTTP-Lastverteilung (NGINX)

Gastautor Cedric Derue ist Solution Architect und Microsoft MVP bei Altran. Gastautor Vincent Thavonekham ist Microsoft Regional Director und Azure MVP bei VISEO.


Teilen

Ähnliche Blogbeiträge

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
NGINX | 23.08.2022

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln

Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
NGINX | 08.09.2021

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen

Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
NGINX | 16.08.2021

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet

Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
NGINX | 12.12.2018

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77

Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.

Ankündigung von NGINX Plus R16
NGINX | 05.09.2018

Ankündigung von NGINX Plus R16

NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
NGINX | 13.10.2016

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing

Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.