Sicher verwaltete Webanwendungen

App Service
Application Gateway
SQL-Datenbank
VPN Gateway
Web Application Firewall

Dieses Szenario ermöglicht einen Überblick über die Bereitstellung sicherer Anwendungen mit der Azure App Service-Umgebung (ASE). Um den Zugriff auf Anwendungen über das Internet zu beschränken, werden der Azure Application Gateway-Dienst und die Web Application Firewall verwendet. Dieser Artikel enthält auch eine Anleitung zu Continuous Integration und Continuous Deployment (CI/CD) für App Service-Umgebungen mit Azure DevOps.

Dieses Szenario wird häufig in Branchen wie dem Bankwesen und der Versicherungsbranche verwendet, in denen die Kunden neben der Sicherheit auf Anwendungsebene auch auf die Sicherheit auf Plattformebene achten. Zur Veranschaulichung dieser Konzepte verwenden wir eine Anwendung, mit der Benutzer Kostenabrechnungen einreichen können.

Relevante Anwendungsfälle

Erwägen Sie dieses Szenario für folgende Anwendungsfälle:

  • Erstellen einer Azure-Web-App, bei der zusätzliche Sicherheit erforderlich ist.
  • Es wird ein dedizierter Mandant anstelle von App Service-Plänen für freigegebene Mandanten bereitgestellt.
  • Verwenden Sie Azure DevOps mit einer internen Application Service-Umgebung mit Lastenausgleich (häufig auch als ILB ASE bezeichnet).

Aufbau

Beispielszenarioarchitektur für die sichere ILB-ASE-Bereitstellung

Die Daten durchlaufen das Szenario wie folgt:

  1. HTTP/HTTPS-Anforderungen gelangen zuerst zum Application Gateway.
  2. Optional (nicht im Diagramm dargestellt) können Sie die Authentifizierung von Azure Active Directory (Azure AD) für die Web-App aktivieren. Nachdem der Datenverkehr zum ersten Mal beim Application Gateway eingetroffen ist, wird der Benutzer aufgefordert, Anmeldeinformationen für die Authentifizierung mit der Anwendung anzugeben.
  3. Benutzeranforderungen durchlaufen den internen Lastenausgleich (ILB) der ASE, die wiederum den Datenverkehr an die Web-App „Expenses“ (Ausgaben) weiterleitet.
  4. Der Benutzer fährt dann mit der Erstellung einer Kostenabrechnung fort.
  5. Bei der Erstellung der Kostenabrechnung wird die bereitgestellte API-App aufgerufen, um den Namen und die E-Mail-Adresse des Benutzers abzurufen.
  6. Die erstellte Kostenabrechnung wird in der Azure SQL-Datenbank gespeichert.
  7. Um eine kontinuierliche Bereitstellung zu ermöglichen, wird Code in die Azure DevOps-Instanz eingecheckt.
  8. Für die Build-VM ist der Azure DevOps-Agent installiert, der es der Build-VM ermöglicht, die Bits für die Web-App zur Bereitstellung in der ASE per Pullvorgang abzurufen (da die Build-VM in einem Subnetz in demselben virtuellen Netzwerk bereitgestellt wird).

Komponenten

  • Die App Service-Umgebung verfügt über eine vollständig isolierte dedizierte Umgebung für den sicheren Betrieb der Anwendung mit umfangreicher Skalierung. Da sich die ASE und die darauf ausgeführten Workloads hinter einem virtuellen Netzwerk befinden, bietet sie darüber hinaus eine zusätzliche Sicherheits- und Isolationsebene. Die Anforderung einer hohen Skalierung und Isolation hat dazu geführt, dass die ILB ASE ausgewählt wurde.
  • Für diese Workload wird der Tarif „App Service (isoliert)“ verwendet, bei dem die Anwendung in einer privaten dedizierten Umgebung in einem Azure-Rechenzentrum ausgeführt wird, für die virtuelle Computer der Dv2-Serie mit schnelleren Prozessoren, SSD-Speicher und einem doppelt so hohen Arbeitsspeicher-zu-Kern-Verhältnis wie bei „Standard“ genutzt werden.
  • Azure App Services-Web-App und API-App hosten Webanwendungen und RESTful-APIs. Diese werden im Tarif „Isoliert“ gehostet, der auch die automatische Skalierung, benutzerdefinierte Domänen usw. bietet, jedoch in einem dedizierten Tarif.
  • Azure Application Gateway ist ein Lastenausgleich für Webdatenverkehr, der auf Layer 7 durchgeführt wird und den an die Webanwendung fließenden Datenverkehr verwaltet. Er ermöglicht die SSL-Abladung. Hiermit wird für die Webserver, die die Web-App hosten, der zusätzliche Aufwand für die Entschlüsselung des Datenverkehrs beseitigt.
  • Die Web Application Firewall (WAF) ist ein Feature von Application Gateway. Die Aktivierung der WAF in Application Gateway trägt zur weiteren Erhöhung der Sicherheit bei. Die WAF verwendet OWASP-Regeln, um die Webanwendung vor Angriffen wie Cross-Site-Scripting, Sitzungsübernahmen und der Einschleusung von SQL-Befehlen zu schützen.
  • Azure SQL-Datenbank wurde ausgewählt, da der Großteil der Daten in dieser Anwendung relationale Daten sind (einige Daten liegen als Dokumente und Blobs vor).
  • Über Azure-Netzwerk wird eine Vielzahl von Netzwerkfunktionen in Azure bereitgestellt. Außerdem können die Netzwerke mittels Peering mit anderen virtuellen Netzwerken in Azure kombiniert werden, oder die Verbindung kann mit lokalen Rechenzentren über ExpressRoute oder Site-to-Site hergestellt werden. In diesem Fall wird ein Dienstendpunkt im virtuellen Netzwerk aktiviert, um sicherzustellen, dass die Daten nur zwischen dem virtuellen Azure-Netzwerk und der SQL-Datenbankinstanz ausgetauscht werden.
  • Azure DevOps wird als Hilfe für Teams verwendet, die während vieler Sprints zusammenarbeiten und Features von Azure DevOps nutzen, mit denen die „agile Entwicklung“ unterstützt wird. Darüber hinaus können hiermit Build- und Releasepipelines erstellt werden.
  • Es wurde eine Azure-Build-VM erstellt, damit der installierte Agent den jeweiligen Build abrufen und die Web-App in der ASE-Umgebung bereitstellen kann.

Alternativen

Die ASE kann normale Web-Apps unter Windows ausführen, oder die innerhalb der ASE bereitgestellten Web-Apps werden – wie in diesem Beispiel – jeweils als Linux-Container ausgeführt. ASE wurde ausgewählt, um diese als Container ausgeführten Einzelinstanzanwendungen zu hosten. Es gibt auch Alternativen. Berücksichtigen Sie beim Entwerfen Ihrer Lösung die unten beschriebenen Überlegungen.

  • Azure Service Fabric: Wenn Ihre Umgebung größtenteils Windows-basiert ist, Ihre Workloads in erster Linie auf .NET Framework basieren und Sie noch nicht erwägen, auf .NET Core umzusteigen, sollten Sie Service Fabric verwenden, um Windows Server-Container zu unterstützen und bereitzustellen. Darüber hinaus unterstützt Service Fabric C#- oder Java-APIs für die Programmierung. Für die Entwicklung nativer Microservices können die Cluster als Windows- oder Linux-Cluster bereitgestellt werden.
  • Azure Kubernetes Service (AKS) ist ein Open-Source-Projekt und eine Orchestrierungsplattform, die besser zum Hosten komplexer Anwendungen mit mehreren Containern geeignet ist, für die üblicherweise eine Microservice-basierte Architektur verwendet wird. AKS ist ein verwalteter Azure-Dienst, der die Komplexität der Bereitstellung und Konfiguration eines Kubernetes-Clusters abstrahiert. Allerdings sind für den Support und die Wartung der Kubernetes-Plattform noch umfangreiche Kenntnisse erforderlich, sodass das Hosting einer Reihe von Einzelinstanz-Webanwendungen in Containern unter Umständen nicht die beste Option ist.

Andere Optionen für die Datenschicht:

  • Azure Cosmos DB: Wenn die Mehrheit der Daten im nicht-relationalen Format vorliegt, ist Cosmos DB eine gute Alternative. Dieser Dienst bietet eine Plattform für die Ausführung anderer Datenmodelle. Hierzu zählen etwa Mongo DB, Cassandra, Graphdaten oder ein einfacher Tabellenspeicher.

Überlegungen

Bei der Verwendung von Zertifikaten in der ILB ASE sind einige Besonderheiten zu beachten. Der eigentliche Trick besteht darin, ein Zertifikat zu generieren, das mit einem vertrauenswürdigen Stamm verbunden ist, ohne dass eine Zertifikatsignieranforderung erforderlich ist, die von dem Server generiert wird, auf dem das Zertifikat schließlich gespeichert wird. Bei IIS besteht beispielsweise der erste Schritt darin, eine CSR von Ihrem IIS-Server zu generieren und diese dann an die Zertifizierungsstelle zu senden, die das SSL-Zertifikat ausstellt.

Sie können keine Zertifikatsignieranforderung über den internen Lastenausgleich (ILB) einer ASE ausstellen. In diesem Fall verwenden Sie dieses Verfahren.

Das oben genannte Verfahren ermöglicht es Ihnen, den Besitznachweis für einen DNS-Namen anstelle einer Zertifikatsignieranforderung zu verwenden. Wenn Sie über einen DNS-Namespace verfügen, können Sie einen speziellen DNS-TXT-Eintrag einfügen. Der obige Dienst überprüft, ob der Eintrag vorhanden ist. Wenn er gefunden wird, weiß der Dienst, dass Sie der Besitzer des DNS-Servers sind, da Sie über den richtigen Eintrag verfügen. Basierend auf diesen Informationen stellt er ein Zertifikat aus, das unter einem vertrauenswürdigen Stamm registriert ist und das Sie dann in Ihren ILB hochladen können. Für die einzelnen Zertifikatspeicher in den Web-Apps sind keine weiteren Schritte erforderlich, da Sie im ILB über ein vertrauenswürdiges SSL-Stammzertifikat verfügen.

Sorgen Sie dafür, dass selbstsignierte oder intern ausgestellte SSL-Zertifikate funktionieren, wenn Sie sichere Aufrufe zwischen Diensten ausführen möchten, die in der ILB-ASE ausgeführt werden. Dies ist eine weitere zu erwägende Lösung dafür, wie die ILB ASE mit einem intern ausgestellten SSL-Zertifikat funktionieren und die interne Zertifizierungsstelle in den vertrauenswürdigen Stammspeicher geladen werden kann.

Berücksichtigen Sie beim Bereitstellen der ASE die folgenden Einschränkungen, wenn Sie einen Domänennamen für die ASE auswählen. Nicht zulässige Domänennamen:

  • net
  • azurewebsites.net
  • p.azurewebsites.net
  • nameofthease.p.azurewebsites.net

Darüber hinaus dürfen sich der für Apps verwendete benutzerdefinierte Domänenname und der von der ILB-ASE verwendete Domänenname nicht überschneiden. Für eine ILB-ASE mit dem Domänennamen „contoso.com“ können Sie keine benutzerdefinierten Domänennamen für beispielsweise folgende Apps verwenden:

  • www.contoso.com
  • abcd.def.contoso.com
  • abcd.contoso.com

Wählen Sie eine Domäne für die ILB-ASE aus, die keinen Konflikt mit diesen benutzerdefinierten Domänennamen verursacht. Sie können in diesem Beispiel z. B. „contoso-internal.com“ für die Domäne Ihrer ASE verwenden, da sie keinen Konflikt mit benutzerdefinierten Domänennamen, die auf „.contoso.com“ enden, verursacht.

Ein weiterer zu berücksichtigender Punkt betrifft DNS. Damit Anwendungen innerhalb der ASE miteinander kommunizieren können, z. B. eine mit einer API kommunizierende Webanwendung, müssen Sie DNS für Ihr virtuelles Netzwerk konfigurieren, das die ASE enthält. Sie können entweder Ihr eigenes DNS oder private Azure DNS-Zonen verwenden.

Verfügbarkeit

Skalierbarkeit

Sicherheit

Resilienz

Bereitstellen des Szenarios

In diesem Tutorial wird Schritt für Schritt beschrieben, wie Sie die einzelnen Komponenten manuell bereitstellen. Außerdem enthält dieses Tutorial eine .NET-Beispielanwendung, mit der eine einfache Contoso-Kostenabrechnung durchgeführt wird.

Preise

Hier können Sie die Betriebskosten für dieses Szenario ermitteln. Alle Dienste sind im Kostenrechner vorkonfiguriert. Wenn Sie wissen möchten, welche Kosten für Ihren spezifischen Anwendungsfall entstehen, passen Sie die entsprechenden Variablen an Ihren voraussichtlichen Datenverkehr an.

Auf der Grundlage des zu erwartenden Datenverkehrsaufkommens haben wir drei exemplarische Kostenprofile erstellt:

  • Klein: Dieses Preisbeispiel stellt die Komponenten dar, die zum Erstellen des Ausgangs für eine Instanz auf niedriger Produktionsebene erforderlich sind. Hierbei gehen wir von einer geringen Anzahl von Benutzern (wenige Tausend pro Monat) aus. Die App nutzt eine einzelne Instanz einer Standard-Web-App, die für die automatische Skalierung ausreicht. Alle anderen Komponenten werden auf einen Basic-Tarif skaliert, um die Kosten möglichst gering zu halten und trotzdem sicherzustellen, dass SLA-Support und ausreichend Kapazität vorhanden ist, um eine Workload auf Produktionsebene verarbeiten zu können.
  • Mittel: Dieses Preisbeispiel stellt die Komponenten einer Bereitstellung mittlerer Größe dar. Hier gehen wir davon aus, dass ca. 100.000 Benutzer das System im Laufe eines Monats verwenden. Der erwartete Datenverkehr wird über eine einzelne App-Dienstinstanz mit einem mittleren Standard-Tarif verarbeitet. Außerdem werden dem Rechner mittlere Cognitive Services-Tarife und Suchdiensttarife hinzugefügt.
  • Groß: Dieses Preisbeispiel stellt eine Anwendung mit hohen Anforderungen und einer Größenordnung von mehreren Millionen Benutzern pro Monat sowie mit Daten im Terabyte-Bereich dar. Auf dieser Nutzungsebene mit hoher Leistung müssen Web-Apps im Premium-Tarif in mehreren Regionen bereitgestellt werden, und der Einsatz von Traffic Manager ist erforderlich. Die Daten umfassen die folgenden Komponenten: Speicher, Datenbanken und CDN (konfiguriert für Daten im Terabyte-Bereich).