Baseline für hochverfügbare zonenredundante Webanwendung

Diese grundlegende Architektur basiert auf der Grundlegenden Webanwendungsarchitektur und erweitert sie, um detaillierte Anleitungen zum Entwerfen einer sicheren, zonenredundanten und hochverfügbaren Webanwendung in Azure bereitzustellen. Die Architektur macht einen öffentlichen Endpunkt über Azure Application Gateway mit Web Application Firewall verfügbar. Anforderungen werden über Private Link an Azure App Service weitergeleitet. Die App Service-Anwendung verwendet die Integration virtueller Netzwerke und Private Link, um sicher mit Azure PaaS-Diensten wie Azure Key Vault und Azure SQL Database zu kommunizieren.

Aufbau

Abbildung 1: Azure App Service-Basisarchitektur

Laden Sie eine Visio-Datei dieser Architektur herunter.

Komponenten

Viele Komponenten dieser Architektur sind identisch mit der grundlegenden Webanwendungsarchitektur. In der folgenden Liste werden nur die Änderungen an der grundlegenden Architektur hervorgehoben.

• Application Gateway ist ein Layer-7-Lastenausgleich (HTTP/S) und ein Web Traffic Manager. Es verwendet URL-pfadbasiertes Routing, um eingehenden Datenverkehr über Verfügbarkeitszonen zu verteilen, und die Verschlüsselung wird ausgelagert, um die Anwendungsleistung zu verbessern.
• Web Application Firewall (WAF) ist ein cloudnativer Dienst, der Web-Apps vor gängigen Exploits wie der Einschleusung von SQL-Befehlen und Cross-Site Scripting schützt. WAF bietet Einblick in den Datenverkehr zu und von Ihrer Webanwendung, sodass Sie Ihre Anwendung überwachen und schützen können.
• Azure Key Vault ist ein Dienst, der Geheimnisse, Verschlüsselungsschlüssel und Zertifikate sicher speichert und verwaltet. Die Verwaltung vertraulicher Informationen wird zentralisiert.
• Das virtuelle Azure-Netzwerk ist ein Dienst, mit dem Sie isolierte und sichere virtuelle Netzwerke in Azure erstellen können. Für eine Webanwendung auf App Service benötigen Sie ein Subnetz des virtuellen Netzwerks, um private Endpunkte für die netzwerksichere Kommunikation zwischen Ressourcen zu verwenden.
• Private Link ermöglicht Clients den Zugriff auf Azure PaaS (Platform-as-a-Service)-Dienste direkt aus privaten virtuellen Netzwerken aus, ohne öffentliche IP-Adressen zu verwenden.
• Azure DNS ist ein Hostingdienst für DNS-Domänen, der eine Namensauflösung mittels Microsoft Azure-Infrastruktur bietet. Private DNS-Zonen bieten eine Möglichkeit, den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) eines Diensts der IP-Adresse eines privaten Endpunkts zuzuordnen.

Netzwerk

Die Netzwerksicherheit ist der Kern der Basisarchitektur von App Services (siehe Abbildung 2). Auf hoher Ebene stellt die Netzwerkarchitektur Folgendes sicher:

1. Einzelner sicherer Einstiegspunkt für Clientdatenverkehr
2. Netzwerkdatenverkehr wird gefiltert.
3. Daten während der Übertragung werden End-to-End mit TLS verschlüsselt.
4. Die Datenexfiltration wird minimiert, indem der Datenverkehr mithilfe von Private Link in Azure gehalten wird.
5. Netzwerkressourcen werden logisch gruppiert und durch Netzwerksegmentierung voneinander isoliert.

Netzwerkflows

Abbildung 2: Netzwerkarchitektur der Azure App Service-Basisanwendung

Im Folgenden werden der eingehende Flow des Internetverkehrs zur App Service-Instanz und der Flow vom App Service zu den Azure-Diensten beschrieben.

Eingehender Flow

1. Der Benutzer stellt eine Anforderung an die öffentliche IP-Adresse des Application Gateway.
2. Die WAF-Regeln werden ausgewertet. WAF-Regeln wirken sich positiv auf die Zuverlässigkeit des Systems aus, indem sie vor einer Vielzahl von Angriffen wie Cross-Site Scripting (XSS) und Einschleusung von SQL-Befehlen schützen. Azure Application Gateway gibt einen Fehler an den Antragsteller zurück, wenn eine WAF-Regel verletzt wird, und der Verarbeitungsvorgang wird beendet. Wenn keine WAF-Regeln verletzt werden, leitet Application Gateway die Anforderung an den Back-End-Pool weiter, der in diesem Fall die App Service Standarddomäne ist.
3. Die private DNS-Zone privatelink.azurewebsites.net ist mit dem virtuellen Netzwerk verknüpft. Die DNS-Zone verfügt über einen A-Eintrag, der die App Service-Standarddomäne der privaten IP-Adresse des privaten Endpunkts des App Service zuordnet. Mit dieser verknüpften privaten DNS-Zone kann Azure DNS die Standarddomäne in die IP-Adresse des privaten Endpunkts auflösen.
4. Die Anforderung wird über den privaten Endpunkt an eine App Service-Instanz weitergeleitet.

Flow von App Service zu Azure PaaS-Diensten

1. App Service stellt eine Anforderung an den DNS-Namen des erforderlichen Azure-Diensts. Die Anforderung kann an Azure Key Vault zum Abrufen eines Geheimnisses, an Azure Storage zum Abrufen einer Veröffentlichungs-ZIP-Datei, an Azure SQL-Datenbank oder an einen anderen Azure-Dienst erfolgen, der Private Link unterstützt. Das App Service-Feature für die Integration virtueller Netzwerke leitet die Anforderung über das virtuelle Netzwerk weiter.
2. Wie in Schritt 3 des eingehenden Flows verfügt die verknüpfte private DNS-Zone über einen A-Eintrag, der die Domäne des Azure-Diensts der privaten IP-Adresse des privaten Endpunkts zuordnet. Mit dieser verknüpften privaten DNS-Zone kann Azure DNS die Domäne in die IP-Adresse des privaten Endpunkts des Dienstes auflösen.
3. Die Anforderung wird über den privaten Endpunkt an den Dienst weitergeleitet.

Eingehender Zugriff auf App Services

Application Gateway ist eine regionale Ressource, die die Anforderungen dieser Basisarchitektur erfüllt. Application Gateway ist ein skalierbarer, regionaler Lastenausgleich der Ebene 7, der Features wie Web Application Firewall und TLS-Auslagerung unterstützt. Beachten Sie die folgenden Punkte, wenn Sie Application Gateway für den Eingang in Azure-App Services implementieren.

• Stellen Sie Application Gateway bereit, und konfigurieren Sie eine WAF-Richtlinie mit einem von Microsoft verwalteten Regelsatz. Entschärfen Sie mit dem Präventionsmodus Webangriffe, die dazu führen könnten, dass ein Ursprungsdienst (in der Architektur App Service) nicht mehr verfügbar ist.
• Implementieren Sie End-to-End-TLS-Verschlüsselung.
• Verwenden Sie private Endpunkte, um eingehenden privaten Zugriff auf Ihren App Service zu implementieren.
• Erwägen Sie die Implementierung der automatischen Skalierung für Application Gateway für die problemlose Anpassung an dynamische Datenverkehrsflüsse.
• Erwägen Sie die Verwendung einer Mindestskalierung der Anzahl der Instanzen von mindestens drei, und verwenden Sie immer alle Verfügbarkeitszonen, die Ihre Region unterstützt. Während Application Gateway auf hochverfügbare Weise bereitgestellt wird, kann die Erstellung einer neuen Instanz bei einem Fehler bis zu sieben Minuten dauern. Die Bereitstellung mehrerer Instanzen über Verfügbarkeitszonen hilft sicherzustellen, dass bei einem Fehler eine Instanz ausgeführt wird, während eine neue Instanz erstellt wird.
• Deaktivieren Sie den Zugriff auf öffentliche Netzwerke auf dem App Service, um die Netzwerkisolation sicherzustellen. In Bicep wird dies erreicht, indem unter properties/siteConfig publicNetworkAccess: 'Disabled' festgelegt wird.

Flow von App Services zu Azure-Diensten

Diese Architektur verwendet die Integration virtueller Netzwerke für den App Service, insbesondere, um Datenverkehr über das virtuelle Netzwerk an private Endpunkte weiterzuleiten. Die Basisarchitektur ermöglicht nicht das gesamte Datenverkehrsrouting, um den gesamten ausgehenden Datenverkehr über das virtuelle Netzwerk zu erzwingen, sondern nur internen Datenverkehr, z. B. datenverkehrsgebunden für private Endpunkte.

Für Azure-Dienste, die keinen Zugriff aus dem öffentlichen Internet benötigen, sollten die privaten Endpunkte aktiviert und die öffentlichen Endpunkte deaktiviert sein. Private Endpunkte werden in dieser Architektur verwendet, um die Sicherheit zu verbessern, indem sie es Ihrem App Service ermöglichen, direkt von Ihrem privaten virtuellen Netzwerk aus eine Verbindung mit Private Link Diensten herzustellen, ohne öffentliche IP-Adressen zu verwenden.

In dieser Architektur sind für Azure SQL Datenbank, Azure Storage und Key Vault öffentliche Endpunkte deaktiviert. Azure-Dienstfirewalls werden nur verwendet, um Datenverkehr von anderen autorisierten Azure-Diensten zuzulassen. Sie sollten andere Azure-Dienste mit privaten Endpunkten konfigurieren, z. B. Azure Cosmos DB und Azure Redis Cache. In dieser Architektur verwendet Azure Monitor keinen privaten Endpunkt, könnte jedoch einen verwenden.

Die Basisarchitektur implementiert eine private DNS-Zone für jeden Dienst. Die private DNS-Zone enthält einen A-Eintrag, der den vollqualifizierten Domänennamen des Diensts der privaten IP-Adresse des privaten Endpunkts zuordnet. Die Zonen sind mit dem virtuellen Netzwerk verknüpft. Private DNS-Zonengruppen stellen sicher, dass die Private Link-DNS-Datensätze automatisch erstellt und aktualisiert werden.

Berücksichtigen Sie die folgenden Punkte, wenn Sie die Integration virtueller Netzwerke und privater Endpunkte implementieren.

• Verwenden Sie den Leitfaden zur Konfiguration von DNS-Zonen für Azure-Dienste, um private DNS-Zonen zu benennen.
• Konfigurieren Sie Dienstfirewalls, um sicherzustellen, dass eine Verbindung zum Speicherkonto, zum Schlüsseltresor, zur SQL-Datenbank und zu anderen Azure-Diensten nur privat hergestellt werden kann.
  • Legen Sie die Standard-Netzwerkzugriffsregel für das Speicherkonto fest, um den gesamten Datenverkehr zu verweigern.
  • Aktivieren Sie Key Vault für Private Link.
  • Verweigern Sie den öffentlichen Netzwerkzugriff auf Azure SQL.

Segmentierung und Sicherheit des virtuellen Netzwerks

Das Netzwerk in dieser Architektur verfügt über separate Subnetze für die Application Gateway, App Service-Integrationskomponenten und private Endpunkte. Jedes Subnetz verfügt über eine Netzwerksicherheitsgruppe, die den eingehenden und ausgehenden Datenverkehr für diese Subnetze auf das erforderliche Limit beschränkt. Die folgende Tabelle zeigt eine vereinfachte Ansicht der NSG-Regeln, die die Baseline jedem Subnetz hinzufügt. Die Tabelle enthält den Regelnamen und die Funktion.

Berücksichtigen Sie die folgenden Punkte, wenn Sie die Segmentierung und Sicherheit virtueller Netzwerke implementieren.

• Aktivieren Sie DDoS Protection sollte für das virtuelle Netzwerk mit einem Subnetz, das Teil einer Application Gateway-Instanz mit einer öffentlichen IP-Adresse ist.
• Fügen Sie nach Möglichkeit jedem Subnetz eine NSG hinzu. Sie sollten die strengsten Regeln verwenden, die eine vollständige Lösungsfunktionalität ermöglichen.
• Verwenden Sie Anwendungssicherheitsgruppen. Mit Anwendungssicherheitsgruppen können Sie NSGs gruppieren und so die Regelerstellung für komplexe Umgebungen vereinfachen.

Ein mögliches Beispiel für das Schema eines virtuellen Subnetzes:

Referenz: Azure-Samples\app-service-baseline-implementation

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie in der Überblick über die Säule „Zuverlässigkeit“.

Die grundlegende App Services-Architektur konzentriert sich auf zonenbezogene Redundanz für wichtige regionale Dienste. Verfügbarkeitszonen sind physisch getrennte Standorte in einer Region. Sie bieten zonenbasierte Redundanz für unterstützende Dienste, wenn zwei oder mehr Instanzen in unterstützenden Regionen bereitgestellt werden. Wenn in einer Zone Ausfallzeiten auftreten, sind die anderen Zonen möglicherweise nicht betroffen.

Die Architektur stellt außerdem sicher, dass genügend Instanzen der Azure-Dienste vorhanden sind, um die Nachfrage zu decken. Die folgenden Abschnitte enthalten Anleitungen zur Zuverlässigkeit für wichtige Dienste in der Architektur. Auf diese Weise helfen Verfügbarkeitszonen Ihnen, Zuverlässigkeit zu erreichen, indem Sie Hochverfügbarkeit und Fehlertoleranz bereitstellen.

Application Gateway

Stellen Sie Azure Application Gateway v2 in einer zonenredundanten Konfiguration bereit. Erwägen Sie die Verwendung einer Mindestskalierung der Anzahl der Instanzen von mindestens drei, um bei einem Fehler die Startzeit von sechs bis sieben Minuten für eine Instanz von Application Gateway zu vermeiden.

App-Dienste

• Stellen Sie mindestens drei Instanzen von App Services mit Unterstützung für Verfügbarkeitszonen bereit.
• Implementieren Sie Endpunkte zur Integritätsprüfung in Ihren Apps, und konfigurieren Sie die App Service-Integritätsprüfung, um Anforderungen an fehlerhafte Instanzen umzuleiten. Weitere Informationen zur App Service-Integritätsprüfung finden Sie unter Überwachen von App Service-Instanzen mit der Integritätsprüfung. Weitere Informationen zum Implementieren von Endpunkten für die Integritätsprüfung in ASP.NET-Anwendungen finden Sie unter Integritätsprüfungen in ASP.NET Core.
• Stellen Sie übermäßige Kapazität für die Behandlung von Zonenfehlern bereit.

SQL-Datenbank

• Stellen Sie Azure SQL-Datenbank in den Tarifen „Universell“, „Premium“ und „Unternehmenskritisch“ mit aktivierter Zonenredundanz bereit. Die Tarife „Universell“, „Premium“ und „Unternehmenskritisch“ unterstützen Zonenredundanz in Azure SQL DB.
• Konfigurieren Sie SQL-Datenbanksicherungen zur Verwendung von zonenredundantem Speicher (ZRS) oder geozonenredundantem Speicher (GZRS).

Blob Storage

• Zonenredundanter Speicher (ZRS) in Azure repliziert Ihre Daten synchron in drei Verfügbarkeitszonen der Region. Erstellen Sie Standard-ZRS- oder Standard-GZRS-Speicherkonten, um sicherzustellen, dass die Daten über Verfügbarkeitszonen hinweg repliziert werden.
• Erstellen Sie separate Speicherkonten für Bereitstellungen, Webressourcen und andere Daten, damit Sie die Konten getrennt verwalten und konfigurieren können.

Effiziente Leistung

Leistungseffizienz ist die Fähigkeit Ihrer Workload, auf effiziente Weise eine den Anforderungen der Benutzer entsprechende Skalierung auszuführen. Weitere Informationen finden Sie unter Übersicht über die Säule „Leistungseffizienz“.

In den folgenden Abschnitten wird die Skalierbarkeit für wichtige Komponenten in dieser Architektur erläutert.

Application Gateway

• Implementieren Sie die automatische Skalierung für Application Gateway, um den Bedarf zu erfüllen.
• Legen Sie die maximale Anzahl der Instanzen auf eine Zahl fest, die höher ist als die erwartete Anforderung. Ihnen werden nur die von Ihnen verwendeten Kapazitätseinheiten in Rechnung gestellt.
• Legen Sie eine Mindestanzahl der Instanzen fest, die kleine Spitzen im Datenverkehr verarbeiten kann. Sie können die durchschnittliche Compute-Einheit-Nutzung verwenden, um ihre Mindestanzahl der Instanzen zu berechnen.
• Befolgen Sie die Anleitung zur Größenanpassung des Application Gateway Subnetzes.

App Service

• Verwenden Sie Standard- oder höhere Pläne mit drei oder mehr Workerinstanzen, um Hochverfügbarkeit zu gewährleisten.
• Aktivieren Sie die Autoskalierung, um ein Hoch- oder Runterskalieren je nach Bedarf sicherzustellen.
• Erwägen Sie, ein Supportticket zu öffnen, um die maximale Anzahl von Workern auf das Doppelte der Anzahl der Instanzen zu erhöhen, wenn Ihr App Service konsistent die Hälfte der maximalen Anzahl von Instanzen verwendet. Die maximale Anzahl von Instanzen beträgt standardmäßig bis zu 30 für einen Premium-App Service-Plan und 10 für einen Standard-Plan.
• Erwägen Sie die Bereitstellung mehrerer Stempel der Anwendung, wenn Ihr App Service die Obergrenzen erreicht.
• Wählen Sie den richtigen Azure App Service-Plan aus, der Ihren Workloadanforderungen entspricht.
• Fügen Sie Azure CDN zu Azure App Service hinzu, um statische Inhalte bereitzustellen.
• Berücksichtigen Sie App Service-Umgebung, wenn „Noisy Neighbors“ (Beeinträchtigungen durch andere Mandanten) ein Problem darstellen.

SQL Server

Das Skalieren von Datenbankressourcen ist ein komplexes Thema, das außerhalb des Bereichs dieser Architektur liegt. Berücksichtigen Sie beim Skalieren Ihrer Datenbank die folgenden Ressourcen:

• Dynamisches Skalieren von Datenbankressourcen bei minimaler Downtime
• Erweitern mit Azure SQL-Datenbank
• Verwenden von schreibgeschützten Replikaten zum Lesen schreibgeschützter Abfrageworkloads

Weitere Hinweise zur Skalierbarkeit

• Überprüfen Sie Abonnementlimits und -kontingente, um sicherzustellen, dass die Dienste an die Nachfrage angepasst werden können.
• Erwägen Sie das Zwischenspeichern für die folgenden Arten von Daten, um die Leistung und Skalierbarkeit zu verbessern:
  • Semistatische Transaktionsdaten
  • Sitzungszustand
  • HTML-Ausgabe Dies kann in Anwendungen nützlich sein, die eine komplexe HTML-Ausgabe rendern.

Sicherheit

Die App Service-Basisarchitektur konzentriert sich auf wichtige Sicherheitsempfehlungen für Ihre Web-App. Es ist wichtig zu verstehen, wie Verschlüsselung und Identität auf jeder Ebene funktionieren, um Ihre Workload zu schützen.

App Service

• Deaktivieren lokaler Authentifizierungsmethoden für FTP- und SCM-Standortbereitstellungen
• Deaktivieren Sie das Remotedebuggen.
• Verwenden Sie die neueste TLS-Version.
• Aktivieren Sie Microsoft Defender für den App-Service.
• Verwenden Sie aktuelle Versionen der unterstützten Plattformen, Programmiersprachen, Protokolle und Frameworks.
• Erwägen Sie App Service-Umgebung, wenn Sie eine höhere Isolation oder einen sicheren Netzwerkzugriff benötigen.

Verschlüsselung

Eine Produktions-Web-App muss Daten während der Übertragung mithilfe von HTTPS verschlüsseln. Das HTTPS-Protokoll basiert auf Transport Layer Security (TLS) und verwendet öffentliche und private Schlüssel für die Verschlüsselung. Sie müssen ein Zertifikat (X.509) in Key Vault speichern und Application Gateway die Berechtigung zum Abrufen des privaten Schlüssels erteilen. Für ruhende Daten führen einige Dienste automatisch Datenverschlüsselung durch, andere ermöglichen eine Anpassung.

Daten während der Übertragung

In der Basisarchitektur werden Daten, die in App Service vom Benutzer zur Web-App übertragen werden, verschlüsselt. Der folgende Workflow beschreibt, wie Verschlüsselung auf hoher Ebene funktioniert.

1. Der Benutzer sendet eine HTTPS-Anforderung an die Web-App.
2. Die HTTPS-Anforderung erreicht das Anwendungsgateway.
3. Das Anwendungsgateway verwendet ein Zertifikat (X.509) in Key Vault, um eine sichere TLS-Verbindung mit dem Webbrowser des Benutzers herzustellen. Das Application Gateway entschlüsselt die HTTPS-Anforderung, damit die Web Application Firewall sie untersuchen kann.
4. Das Anwendungsgateway erstellt eine TLS-Verbindung mit App Service, um die Benutzeranforderung erneut zu verschlüsseln. App Service bietet native Unterstützung für HTTPS, sodass Sie App Service kein Zertifikat hinzufügen müssen. Das Anwendungsgateway sendet den verschlüsselten Datenverkehr an App Service. App Service entschlüsselt den Datenverkehr, und die Web-App verarbeitet die Anforderung.

Beachten Sie beim Konfigurieren der Daten während der Übertragung die folgenden Empfehlungen.

• Erstellen Sie Ihr Zertifikat oder laden Sie es in den Schlüsseltresor hoch. Die HTTPS-Verschlüsselung erfordert ein Zertifikat (X.509). Sie benötigen ein Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle für Ihre benutzerdefinierte Domäne.
• Speichern Sie den privaten Schlüssel im Zertifikat in Key Vault.
• Befolgen Sie die Anleitung unter Gewähren der Berechtigung für Anwendungen für den Zugriff auf einen Azure-Schlüsseltresor mithilfe von Azure RBAC und Verwaltete Identitäten für Azure-Ressourcen, um Application Gateway Zugriff auf den privaten Zertifikatschlüssel bereitzustellen. Verwenden Sie keine Key Vault-Zugriffsrichtlinien, um Zugriff bereitzustellen. Zugriffsrichtlinien ermöglichen Ihnen nur, allgemeine Berechtigungen zu gewähren, jedoch keine für bestimmte Werte.
• Aktivieren Sie die End-to-End-Verschlüsselung. App Service ist der Back-End-Pool für das Anwendungsgateway. Wenn Sie die Back-End-Einstellung für den Back-End-Pool konfigurieren, verwenden Sie das HTTPS-Protokoll über den Back-End-Port 443.

Ruhende Daten

• Verschlüsseln Sie vertrauliche Daten in Azure SQL-Datenbank mithilfe einer transparenten Datenverschlüsselung. Transparente Daten verschlüsseln die gesamte Datenbank, alle Sicherungen und Transaktionsprotokolldateien und erfordern keine Änderungen an Ihrer Webanwendung.
• Minimieren Sie die Latenz bei der Datenbankverschlüsselung. Um die Verschlüsselungslatenz zu minimieren, platzieren Sie die zu schützenden Daten in einer eigenen Datenbank, und aktivieren Sie die Verschlüsselung nur für diese Datenbank.
• Grundlegendes zur integrierten Verschlüsselungsunterstützung. Azure Storage verschlüsselt ruhende Daten automatisch mithilfe der serverseitigen Verschlüsselung (256-Bit-AES). Azure Monitor verschlüsselt ruhende Daten automatisch mithilfe der von Microsoft verwalteten Schlüssel (MMKs).

Identitäts- und Zugriffsverwaltung

Die App Service-Baseline konfiguriert die Authentifizierung und Autorisierung für Benutzeridentitäten (Benutzer) und Workloadidentitäten (Azure-Ressourcen) und implementiert das Prinzip der geringsten Rechte.

Benutzeridentitäten

• Verwenden Sie den integrierten Authentifizierungsmechanismus für App Service („EasyAuth“). EasyAuth vereinfacht die Integration von Identitätsanbietern in Ihre Web-App. Es übernimmt die Authentifizierung außerhalb Ihrer Web-App, sodass Sie keine wesentlichen Codeänderungen vornehmen müssen.
• Konfigurieren Sie die Antwort-URL für die benutzerdefinierte Domäne. Sie müssen die Web-App an https://<application-gateway-endpoint>/.auth/login/<provider>/callback umleiten. Ersetzen Sie <application-gateway-endpoint> entweder durch die öffentliche IP-Adresse oder den benutzerdefinierten Domänennamen, der Ihrem Anwendungsgateway zugeordnet ist. Ersetzen Sie <provider> durch den verwendeten Authentifizierungsanbieter, z. B. „mei“ für Microsoft Entra ID. Sie können die Azure Front-Dokumentation verwenden, um diesen Flow mit Application Gateway einzurichten oder Einrichten von Application Gateway.

Workloadidentitäten

• Verwenden Sie die verwaltete Identität für Workloadidentitäten. Dank verwalteter Identität müssen Entwickler keine Anmeldeinformationen mehr verwalten.
• Verwenden Sie benutzerseitig zugewiesene verwaltete Identitäten. Eine systemseitig zugewiesene Identität kann dazu führen, dass Infrastructure-as-Code-Bereitstellungen basierend auf den Racebedingungen und der Reihenfolge der Vorgänge fehlschlagen. Sie können benutzerseitig zugewiesene verwaltete Identitäten verwenden, um einige dieser Bereitstellungsfehlerszenarien zu vermeiden. Weitere Informationen finden Sie unter Verwaltete Identitäten.

Optimaler Betrieb

Die Säule „Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Übersicht über die Säule „Optimaler Betrieb“.

Die Bereitstellung für die Basisanwendung App Service folgt den Anweisungen in CI/CD für Azure Web-Apps mit Azure Pipelines. Zusätzlich zu dieser Anleitung berücksichtigt die App Services-Basisarchitektur, dass die Anwendung und das Bereitstellungsspeicherkonto netzwerksicher sind. Die Architektur verweigert den öffentlichen Zugriff auf App Service. Dies bedeutet, dass Sie keine Bereitstellung von außerhalb des virtuellen Netzwerks durchführen können. Die Baseline zeigt Ihnen, wie Sie den Anwendungscode im virtuellen Netzwerk mithilfe von selbstgehosteten Bereitstellungs-Agents bereitstellen. Der folgende Bereitstellungsleitfaden konzentriert sich auf die Bereitstellung des Anwendungscodes und nicht auf die Bereitstellung von Infrastruktur- oder Datenbankänderungen.

Abbildung 3: Bereitstellen von Azure App Service Anwendungen

Bereitstellungsablauf

1. Im Rahmen der Releasepipeline sendet die Pipeline eine Auftragsanforderung für die selbstgehosteten Agents in der Auftragswarteschlange. Die Auftragsanforderung richtet sich an den Agent, um das Buildartefakt der Veröffentlichungs-ZIP-Datei in ein Azure Storage-Konto hochzuladen.

2. Der selbstgehostete Bereitstellungs-Agent übernimmt die neue Auftragsanforderung durch Abruf. Der Auftrag und das Buildartefakt werden heruntergeladen.

3. Der selbstgehostete Bereitstellungs-Agent lädt die ZIP-Datei über den privaten Endpunkt des Speicherkontos in das Speicherkonto hoch.

4. Die Pipeline wird fortgesetzt, und ein verwalteter Agent übernimmt einen nachfolgenden Auftrag. Der verwaltete Agent führt einen CLI-Aufruf aus, um die appSetting WEBSITE_RUN_FROM_PACKAGE auf den Namen der neuen Veröffentlichungs-ZIP-Datei für den Stagingslot zu aktualisieren.

   az webapp config appsettings set -g MyResourceGroupName -n MyUniqueApp --slot staging --settings WEBSITE_RUN_FROM_PACKAGE=UriToNewZip
   

5. Azure App Service ruft die neue ZIP-Veröffentlichungsdatei über den privaten Endpunkt des Speicherkontos aus dem Speicher ab. Die Staginginstanz wird mit dem neuen Paket neu gestartet, da WEBSITE_RUN_FROM_PACKAGE auf einen anderen Dateinamen festgelegt wurde.

6. Die Pipeline wird fortgesetzt und führt alle Buildakzeptanztests aus oder wartet auf die Genehmigung. Wenn die Tests erfolgreich sind oder die Genehmigung erteilt wird, tauscht die Pipeline die Staging- und Produktionsslots aus.

Hinweise zur Bereitstellung

Im Folgenden werden wichtige Bereitstellungsanleitungen für die Basisarchitektur hervorgehoben.

• Verwenden Sie Aus Paketdatei ausführen, um Bereitstellungskonflikte zu vermeiden. Wenn Sie Ihre App direkt aus einem Paket in Azure App Service ausführen, werden die Dateien im Paket nicht in das Verzeichnis „wwwroot“ kopiert. Stattdessen wird das eigentliche ZIP-Paket direkt als schreibgeschütztes Verzeichnis wwwroot eingebunden. Dadurch werden Dateisperrkonflikte zwischen Bereitstellung und Runtime vermieden, und es wird sichergestellt, dass jederzeit nur vollständig bereitgestellte Apps ausgeführt werden.
• Fügen Sie Versionsnummern in die bereitgestellten ZIP-Paketdateien ein. Wenn die appSetting WEBSITE_RUN_FROM_PACKAGE auf das Bereitstellungspaket mit einem anderen Dateinamen aktualisiert wird, übernimmt App Services automatisch die neue Version und startet den Dienst neu.
• Verwenden Sie Bereitstellungsslots für resiliente Codebereitstellungen.
• Erwägen Sie die Verwendung einer Mischung aus verwalteten und selbstgehosteten Agents.
  • Verwenden Sie selbstgehostete Agents, um die ZIP-Paketdatei über den privaten Endpunkt in das Speicherkonto hochzuladen. Der Agent initiiert die Kommunikation mit der Pipeline über Abrufe, sodass es nicht erforderlich ist, das Netzwerk für einen eingehenden Anruf zu öffnen.
  • Verwenden Sie verwaltete Agents für die anderen Aufträge in der Pipeline.
• Automatisieren Sie Infrastrukturbereitstellungen mit Infrastructure-as-Code (IaC).
• Testen Sie durch eine fortlaufende Überprüfung der Workload die Leistung und Ausfallsicherheit der gesamten Lösung, beispielsweise mit Diensten wie Azure Load Testing und Azure Chaos Studio.

Konfiguration

Anwendungen erfordern sowohl Konfigurationswerte als auch Geheimnisse. Verwenden Sie die folgende Anleitung für die Konfiguration und die Geheimnisverwaltung.

• Überprüfen Sie niemals Geheimnisse wie Kennwörter oder Zugriffsschlüssel in der Quellcodeverwaltung.
• Verwenden Sie Azure Key Vault zum Speichern von Schlüsseln.
• Verwenden Sie App Service Configuration für Ihre Anwendungskonfiguration. Wenn Sie die Konfiguration aus Ihrer Anwendungskonfiguration externalisieren müssen oder Featureflags unterstützen möchten, sollten Sie Azure App Configuration verwenden.
• Verwenden Sie Key Vault Verweise in App Service Configuration, um Geheimnisse in Ihrer Anwendung sicher verfügbar zu machen.
• Falls Sie unterschiedliche Einstellungen für Produktion und Staging benötigen, können Sie Anwendungseinstellungen erstellen, die fest bei einem Slot verbleiben und nicht getauscht werden. Wenn Sie einen Bereitstellungsslot tauschen, werden die App-Einstellungen standardmäßig ebenfalls getauscht.
• Legen Sie lokale Umgebungsvariablen für die lokale Entwicklung fest, oder nutzen Sie Anwendungsplattformfeatures. App Services Configuration macht App-Einstellungen als Umgebungsvariablen verfügbar. Mit Visual Studio können Sie beispielsweise Umgebungsvariablen in Startprofilen festlegen. Außerdem können Sie App-Einstellungen und Benutzergeheimnisse verwenden, um lokale Anwendungseinstellungen und Geheimnisse zu speichern.

Überwachung

Überwachung ist die Sammlung und Analyse von Daten, die aus IT-Systemen abgerufen werden. Das Ziel der Überwachung ist die Beobachtbarkeit auf mehreren Ebenen, um die Integrität und Sicherheit von Web-Apps nachzuverfolgen. Die Beobachtbarkeit ist eine wichtige Facette der App Service-Basisarchitektur.

Um Ihre Web-App zu überwachen, müssen Sie Metriken und Protokolle aus Ihrem Anwendungscode, Ihrer Infrastruktur (Runtime) und der Plattform (Azure-Ressourcen) sammeln und analysieren. Weitere Informationen finden Sie unter Azure-Aktivitätsprotokoll, Azure-Ressourcenprotokolle und Anwendungsprotokolle.

Überwachen der Plattform

Plattformüberwachung ist die Sammlung von Daten aus den Azure-Diensten in Ihrer Architektur. Beachten Sie die folgenden Anleitungen zur Plattformüberwachung.

• Fügen Sie eine Diagnoseeinstellung für jede Azure-Ressource hinzu. Jeder Azure-Dienst verfügt über einen anderen Satz von Protokollen und Metriken, die Sie erfassen können. Verwenden Sie die folgende Tabelle, um die Metriken und Protokolle zu ermitteln, die Sie sammeln möchten.

  Azure-Ressource	Beschreibungen der Metriken und Protokolle
  Application Gateway	Beschreibungen der Application Gateway-Metriken und -Protokolle
  Web Application Firewall	Beschreibungen der Web Application Firewall-Metriken und -Protokolle
  App Service	Beschreibungen der App Service-Metriken und -Protokolle
  Azure SQL-Datenbank	Beschreibung der Azure SQL-Datenbankmetriken und -protokolle
  CosmosDB	Beschreibungen der Azure Cosmos DB-Metriken und -Protokolle
  Key Vault	Beschreibungen der Key Vault-Metriken und -Protokolle
  Blob Storage	Beschreibungen der Azure Blob Storage-Metriken und -Protokolle
  Application Insights	Beschreibungen der Application Insights-Metriken und -Protokolle
  Öffentliche IP-Adresse	Beschreibungen der Metriken und Protokolle der öffentlichen IP-Adresse

• Verstehen Sie die Kosten für das Sammeln von Metriken und Protokollen. Im Allgemeinen gilt: Je mehr Metriken und Protokolle Sie sammeln, desto teurer ist dies. Weitere Informationen finden Sie unter Kostenberechnungen und Optionen für Log Analytics und Preise für den Log Analytics-Arbeitsbereich.

• Erstellen von Warnungen Sie sollten Warnungen für alle Azure-Ressourcen in der Architektur erstellen und Aktionen konfigurieren, um Probleme zu beheben. Wählen Sie zunächst allgemeine und empfohlene Warnungsregeln aus, und ändern Sie sie im Laufe der Zeit nach Bedarf. Weitere Informationen finden Sie unter

  • Übersicht über Azure Monitor-Warnungen
  • Application Gateway-Warnungen
  • App Service-Warnungen
  • Azure SQL-Datenbank-Warnungen
  • Blob Storage-Warnungen
  • Key Vault-Warnungen

Application Gateway

Application Gateway überwacht standardmäßig die Integrität der Ressourcen in seinem Back-End-Pool. Verwenden Sie die Application Gateway Access-Protokolle, um Informationen wie den Zeitstempel, den HTTP-Antwortcode und den URL-Pfad zu sammeln. Weitere Informationen finden Sie unter Application Gateway-Standardintegritätstest und Back-End-Integritäts- und Diagnoseprotokolle.

App Service

App Service verfügt über integrierte Überwachungstools, die Sie für eine verbesserte Beobachtbarkeit aktivieren sollten. Wenn Ihre Web-App bereits über Telemetrie- und Überwachungsfeatures („Prozessinterne Instrumentierung“) verfügt, sollte sie weiterhin auf App Service funktionieren.

• Aktivieren Sie die automatische Instrumentierung. App Service verfügt über eine Instrumentierungserweiterung, die Sie ohne Codeänderungen aktivieren können. Sie erhalten Sichtbarkeit der Anwendungsleistungsüberwachung (Application Performance Monitoring, APM). Weitere Informationen finden Sie unter Überwachen der Leistung von Azure App Service.
• Aktivieren Sie verteilte Ablaufverfolgung. Die automatische Instrumentierung bietet eine Möglichkeit, verteilte Cloudsysteme über verteilte Ablaufverfolgung und einen Leistungsprofiler zu überwachen.
• Verwenden Sie die codebasierte Instrumentierung für benutzerdefinierte Telemetriedaten. Azure-Anwendung Insights unterstützt auch die codebasierte Instrumentierung für benutzerdefinierte Anwendungstelemetriedaten. Fügen Sie ihrem Code das Application Insights SDK hinzu, und verwenden Sie die Application Insights-API.
• Aktivieren Sie App Service Protokolle. Die App Service-Plattform unterstützt vier zusätzliche Protokolle, die Sie zur Unterstützung der Problembehandlung aktivieren sollten. Bei diesen Protokollen handelt es sich um Anwendungsprotokolle, Webserverprotokolle, detaillierte Fehlermeldungen und die Ablaufverfolgung von Anforderungsfehlern.
• Verwenden Sie strukturierte Protokollierung. Fügen Sie Ihrem Anwendungscode eine strukturierte Protokollierungsbibliothek hinzu. Aktualisieren Sie Ihren Code, um Schlüssel-Wert-Paare zu verwenden, und aktivieren Sie Anwendungsprotokolle in App Service, um diese Protokolle in Ihrem Log Analytics-Arbeitsbereich zu speichern.
• Aktivieren Sie die App Service-Integritätsprüfung. Die Integritätsprüfung leitet Anforderungen von fehlerhaften Instanzen weg und ersetzt die fehlerhaften Instanzen. Ihr App Service-Plan muss zwei oder mehr Instanzen verwenden, damit Integritätsprüfungen funktionieren.

Datenbank

• Verwenden Sie Datenbankerkenntnisse. Für Azure SQL Datenbanken sollten Sie SQL Insights in Azure Monitor konfigurieren. Database Insights verwendet dynamische Verwaltungssichten, um die Daten offenzulegen, die Sie zur Überwachung der Integrität, zur Diagnose von Problemen und zur Leistungsoptimierung benötigen. Informationen zu Azure SQL-Datenbank finden Sie unter Überwachen von Azure SQL-Datenbank mit Azure Monitor.
• Wenn Ihre Architektur Cosmos DB enthält, müssen Sie nichts aktivieren oder konfigurieren, um Cosmos DB-Erkenntnisse zu verwenden.

Governance

Web-Apps profitieren von Azure Policy, indem sie Architektur- und Sicherheitsentscheidungen erzwingen. Azure Policy kann die Bereitstellung (1) verweigern oder (2) die einfache Erkennung (Überwachung) von Konfigurationsabweichungen von Ihrem bevorzugten gewünschten Zustand erschweren. Dies hilft Ihnen, IaC-Bereitstellungen (Infrastructure-as-Code) oder Änderungen im Azure-Portal abzufangen, die von der vereinbarten Architektur abweichen. Sie sollten alle Ressourcen in Ihrer Architektur unter Azure Policy-Governance platzieren. Verwenden Sie nach Möglichkeit integrierte Richtlinien oder Richtlinieninitiativen, um wesentliche Netzwerktopologie, Dienstfeatures, Sicherheits- und Überwachungsentscheidungen zu erzwingen. Beispiel:

• Der App Service muss den Zugriff über öffentliche Netzwerke deaktivieren
• App Service sollte die Integration virtueller Netzwerke verwenden.
• App Service sollte Azure Private Link verwenden, um eine Verbindung mit PaaS-Diensten herzustellen.
• Für App Service sollten lokale Authentifizierungsmethoden für FTP- und SCM-Standortbereitstellungen deaktiviert sein.
• Für App Service-Apps sollte das Remotedebuggen deaktiviert sein.
• App Service-Apps sollten die neueste TLS-Version verwenden
• Microsoft Defender für App Service muss aktiviert sein.
• Web Application Firewall (WAF) muss für Application Gateway aktiviert sein.

Weitere integrierte Richtlinien für wichtige Dienste wie Application Gateway- und Netzwerkkomponenten, App Service, Key Vault und Überwachung finden Sie hier. Es ist möglich, benutzerdefinierte Richtlinien zu erstellen oder Communityrichtlinien (z. B. in Azure-Zielzonen) zu verwenden, wenn integrierte Richtlinien Ihre Anforderungen nicht vollständig erfüllen. Bevorzugen Sie integrierte Richtlinien, wenn sie verfügbar sind.

Nächste Schritte

Zugehörige Ressourcen

• Leitfaden zu Private Link in Virtual WAN
• Hochskalieren einer App in Azure App Service
• Migrieren von App Service zur Unterstützung von Verfügbarkeitszonen
• Skalierung von Application Gateway v2 und WAF v2