Teams, die Workloads verwalten, verlassen sich für den Kundenzugriff häufig auf vollständig qualifizierte Domänennamen (FQDNs). FQDNs werden in der Regel mit der Transport Layer Security (TLS) Server Name Indication (SNI) kombiniert. Wenn bei diesem Ansatz öffentliche Kunden über das öffentliche Internet oder Unternehmenskunden intern auf einen Workload zugreifen, kann das Routing zur Anwendung festen Pfaden folgen und verschiedene Sicherheits- oder Dienstqualitätsstufen (QoS) aufweisen.
Die folgende Architektur zeigt einen Ansatz zur Differenzierung der Behandlung des Datenverkehrs auf der Grundlage des Domain Name System (DNS) und der Tatsache, ob der Kunde aus dem Internet oder aus einem Unternehmensnetz stammt.
Aufbau
Laden Sie eine Visio-Datei dieser Architektur herunter.
In den folgenden Abschnitten werden zwei Konfigurationen beschrieben: ein öffentlicher Internet-Workflow und ein privater Workflow. Kombinieren Sie die beiden Arbeitsabläufe, um eine Split-Brain-Hosting-Architektur zu implementieren.
Öffentlicher Internet-Workflow
Laden Sie eine Visio-Datei dieser Architektur herunter.
Kunden senden eine Anfrage für die Anwendung app.contoso.com über das öffentliche Internet.
Eine Azure-DNS-Zone ist für die Domain contoso.com konfiguriert. Die entsprechenden canonical name (CNAME) Einträge sind für die Azure Front Door Endpunkte konfiguriert.
Externe Kunden greifen auf die Webanwendung über Azure Front Door zu, das als globaler Load Balancer und Web Application Firewall (WAF) fungiert.
Innerhalb von Azure Front Door wird
app.contoso.comals FQDN über Routen auf einem konfigurierten Endpunkt zugewiesen. Azure Front Door hostet auch die TLS SNI-Zertifikate für die Anwendungen.Hinweis
Azure Front Door unterstützt keine selbstsignierten Zertifikate.
Azure Front Door leitet die Anfragen an die konfigurierte Ursprungsgruppe weiter, basierend auf dem
HostHTTP-Header des Kunden.Die Ursprungsgruppe ist so konfiguriert, dass sie über die öffentliche IP-Adresse des Application Gateway auf die Azure Application Gateway-Instanz verweist.
Eine Netzwerksicherheitsgruppe (NSG) ist auf dem AppGW-Subnetz konfiguriert, um den eingehenden Zugriff auf Port 80 und Port 443 vom AzureFrontDoor.Backend Diensttag zu erlauben. Der NSG erlaubt keinen eingehenden Verkehr auf Port 80 und Port 443 vom Internet Diensttag.
Hinweis
Das AzureFrontDoor.Backend Diensttag beschränkt den Datenverkehr nicht nur auf Ihre Instanz von Azure Front Door. Die Validierung erfolgt in der nächsten Phase.
Die Application Gateway-Instanz hat einen -Listener an Port 443. Der Verkehr wird auf der Grundlage des im Listener angegebenen Hostnamens an das Backend weitergeleitet.
Um sicherzustellen, dass der Datenverkehr von Ihrem Azure Front Door-Profil stammt, konfigurieren Sie eine benutzerdefinierte WAF-Regel, um den
X-Azure-FDIDHeader-Wert zu überprüfen.Azure generiert einen eindeutigen Bezeichner für jedes Azure Front Door-Profil. Der eindeutige Bezeichner ist der Wert Front Door ID, der sich auf der Übersichtsseite des Azure-Portals befindet.
Der Datenverkehr erreicht die Rechenressource, die in Application Gateway als Back-End-Pool konfiguriert ist.
Privatwirtschaftlicher Workflow
Laden Sie eine Visio-Datei dieser Architektur herunter.
Kunden initiieren eine Anforderung für die Anwendung app.contoso.com von einer lokalen Umgebung aus.
Anwendungs-FQDNs werden beim lokalen DNS-Anbieter konfiguriert. Dieser DNS-Anbieter kann ein lokaler Windows Server Active Directory DNS-Server oder eine andere Partnerlösung sein. Die DNS-Einträge für jeden der Anwendungs-FQDNs werden so konfiguriert, dass sie auf die private IP-Adresse der Application Gateway-Instanz verweisen.
Eine Azure ExpressRoute-Schaltung oder ein Site-to-Site-VPN erleichtert den Zugriff auf Application Gateway.
Ein NSG ist auf dem AppGW-Subnetz konfiguriert, um eingehende private Anfragen von lokalen Kundennetzwerken zuzulassen, aus denen der Verkehr stammt. Diese Konfiguration stellt sicher, dass andere Quellen des privaten Datenverkehrs die private IP-Adresse des Application Gateway nicht direkt erreichen können.
Application Gateway hat einen Listener, der auf Port 80 und Port 443 konfiguriert ist. Der Verkehr wird auf der Grundlage des im Listener angegebenen Hostnamens an das Backend weitergeleitet.
Nur der private Netzwerkverkehr erreicht den Rechner, der in Application Gateway als Back-End-Pool konfiguriert ist.
Komponenten
DNS: Für einen öffentlichen Internet-Workflow müssen Sie eine öffentliche Azure DNS-Zone mit dem richtigen CNAME des Azure Front Door-Endpunkts FQDN konfigurieren. Auf der privaten (Unternehmens-)Seite konfigurieren Sie den lokalen DNS-Anbieter (Windows Server Active Directory DNS oder eine Partnerlösung) so, dass jeder Anwendungs-FQDN auf die private IP-Adresse von Application Gateway verweist.
Azure DNS Private Resolver: Sie können DNS Private Resolver für die Auflösung von On-Premises-Kunden verwenden. Unternehmenskunden können diese Split-Brain-DNS-Lösung nutzen, um Zugang zu Anwendungen zu erhalten, ohne das öffentliche Internet zu durchqueren.
Azure Front Door: Azure Front Door ist ein globaler Load Balancer und eine WAF, die eine schnelle und sichere Bereitstellung von Webanwendungen für Kunden auf der ganzen Welt ermöglicht. In dieser Architektur leitet Azure Front Door externe Kunden an die Application Gateway-Instanz weiter und bietet Caching- und Optimierungsoptionen zur Verbesserung der Kundenerfahrung.
Anwendungs-Gateway: Application Gateway ist ein regionaler Load Balancer und WAF, der hohe Verfügbarkeit, Skalierbarkeit und Sicherheit für Webanwendungen bietet. In dieser Architektur leitet das Application Gateway externe und interne Kundenanfragen an den Backend-Rechner weiter und schützt die Webanwendung vor gängigen Webangriffen.
Sowohl Azure Front Door als auch Application Gateway bieten WAF-Funktionen, aber der private Workflow in dieser Lösung nutzt Azure Front Door nicht. Daher nutzen beide Architekturen die WAF-Funktionalität von Application Gateway.
ExpressRoute: Sie können ExpressRoute verwenden, um Ihre lokalen Netzwerke mit Hilfe eines Konnektivitätsanbieters über eine private Verbindung mit der Microsoft Cloud zu verbinden. In dieser Architektur können Sie ExpressRoute verwenden, um private Konnektivität zu Application Gateway für Kunden vor Ort zu ermöglichen.
Alternativen
Als alternative Lösung können Sie Azure Front Door entfernen und stattdessen den öffentlichen Azure DNS-Eintrag auf die öffentliche IP-Adresse von Application Gateway verweisen. Basierend auf den Anforderungen dieser Architektur müssen Sie Caching und Optimierung am Eintrittspunkt in Azure durchführen. Daher kommt die Alternativlösung für dieses Szenario nicht in Frage. Weitere Informationen finden Sie unter Kostenoptimierung.
Laden Sie eine Visio-Datei dieser Architektur herunter.
Andere mögliche Alternativen für den öffentlichen Eingangsverkehr in dieser Architektur sind:
Azure Traffic Manager: Traffic Manager ist ein DNS-basierter Verkehrslenkungsdienst, der den Datenverkehr auf verschiedene Regionen und Endpunkte verteilt. Sie können Traffic Manager anstelle von Azure Front Door verwenden, um externe Kunden an die nächstgelegene Application Gateway-Instanz weiterzuleiten. Azure Front Door bietet jedoch Funktionen wie WAF-Funktionen, Caching und Sitzungsaffinität. Traffic Manager bietet diese Funktionen nicht.
Azure Load Balancer: Azure Load Balancer ist ein Netzwerk-Load-Balancer, der hohe Verfügbarkeit und Skalierbarkeit für Transmission Control Protocol (TCP) und User Datagram Protocol (UDP) Verkehr bietet. Sie können Load Balancer anstelle von Application Gateway verwenden, um externe und interne Kundenanfragen an Back-End-Webserver weiterzuleiten. Application Gateway bietet jedoch Funktionen wie WAF-Funktionen, Secure Sockets Layer (SSL)-Terminierung und Cookie-basierte Sitzungsaffinität. Load Balancer bietet diese Funktionen nicht.
Szenariodetails
Dieses Szenario löst das Problem des Hostings einer Webanwendung, die sowohl externen als auch internen Kunden dient. Diese Architektur stellt sicher, dass der Datenverkehr je nach Herkunft des Kunden einen geeigneten Weg nimmt. Diese Architektur:
Bietet schnellen und zuverlässigen Zugang über das Internet zu einer Webanwendung für Nicht-Unternehmenskunden in aller Welt.
Bietet Unternehmenskunden die Möglichkeit, auf eine Anwendung zuzugreifen, ohne das öffentliche Internet zu durchqueren.
Schützt eine Webanwendung vor gängigen Webangriffen und bösartigem Datenverkehr.
Mögliche Anwendungsfälle
Verwenden Sie diese Architektur für Szenarien, die Folgendes erfordern:
Split-Brain DNS: Diese Lösung verwendet Azure Front Door für externe Kunden und Application Gateway für interne Kunden, mit unterschiedlichen DNS-Einträgen für jeden Dienst. Dieser Ansatz trägt zur Optimierung der Netzwerkleistung, Sicherheit und Verfügbarkeit für verschiedene Kunden bei.
Skalierbarkeit der Anwendung: Bei dieser Lösung wird ein Application Gateway verwendet, das den Datenverkehr auf konfigurierte Backend-Rechenressourcen verteilen kann. Dieser Ansatz trägt zur Verbesserung der Anwendungsleistung und -verfügbarkeit bei und unterstützt die horizontale Skalierung.
Ü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 unter Erstellen einer Checkliste zur Überprüfung der Zuverlässigkeit.
Identifizieren Sie Fehlerpunkte: In dieser DNS-Architektur mit zwei Gehirnen hängt die Zuverlässigkeit von der korrekten Funktion der Schlüsselkomponenten ab, wie z. B. Azure Front Door, Application Gateway und DNS-Konfigurationen. Sie müssen potenzielle Fehlerquellen identifizieren, z. B. Fehlkonfigurationen, Probleme mit SSL-Zertifikaten oder Kapazitätsüberlastungen.
Bewertung der Auswirkungen: Sie müssen die Auswirkungen von Misserfolgen abschätzen. Für externe Kunden könnte jede Unterbrechung von Azure Front Door, das als Gateway dient, den globalen Zugang beeinträchtigen. Für interne Kunden könnte jede Unterbrechung des Application Gateway den Unternehmensbetrieb beeinträchtigen.
Umsetzung von Minderungsstrategien: Um Risiken zu minimieren, sollten Sie Redundanz in mehreren Verfügbarkeitszonen implementieren, Integritätstests für die Echtzeitüberwachung verwenden und die korrekte Konfiguration des DNS-Routings für externen und internen Datenverkehr sicherstellen. Stellen Sie sicher, dass Sie Ihre DNS-Einträge regelmäßig aktualisieren und einen Plan für die Notfallwiederherstellung haben.
Monitor kontinuierlich: Um den Zustand Ihres Systems im Auge zu behalten, nutzen Sie die Funktionen von Azure Monitor. Richten Sie Warnmeldungen für Anomalien ein und halten Sie einen Plan für die Reaktion auf Zwischenfälle bereit, um potenzielle Probleme sofort zu beheben.
Halten Sie sich an diese Grundsätze, um ein robustes und zuverlässiges System zu gewährleisten, das Herausforderungen standhält und die Kontinuität der Dienste aufrechterhält.
Sicherheit
Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Sicherheit.
Verwenden Sie den Zero-Trust-Ansatz: Wenden Sie in der Split-Brain-DNS-Einrichtung den Ansatz Zero Trust an. Überprüfen Sie explizit die Identität eines Kunden, unabhängig davon, ob er aus dem Internet oder einem Unternehmensnetzwerk kommt. Dieser Ansatz stellt sicher, dass nur vertrauenswürdige Einrichtungen autorisierte Aktionen durchführen.
Implementierung: Implementieren Sie Microsoft Entra ID für eine zuverlässige Identitätsverwaltung. Verwenden Sie Microsoft Entra Conditional Access-Richtlinien, um strenge Zugriffskontrollen auf der Grundlage von Kundenkontext, Gerätezustand und Standort durchzusetzen.
Bewertung der Sicherheitseffizienz: Bewerten Sie die Wirksamkeit der Sicherheitsmaßnahmen für Ihren Dual-Access-Workload durch die Implementierung:
Defensive Investitionen: Bewerten Sie regelmäßig die Effektivität von Azure Front Door und Application Gateway. Sicherstellen, dass sie einen sinnvollen Schutz gegen Bedrohungen bieten.
Einschränkung des Blastradius: Sorgen Sie dafür, dass Sie Sicherheitsverletzungen in einem begrenzten Rahmen halten. Trennen Sie zum Beispiel externe und interne Verkehrsströme wirksam voneinander.
Angenommen, ein Verstoß: Erkennen Sie an, dass Angreifer Sicherheitskontrollen umgehen können. Bereiten Sie sich auf solche Szenarien vor.
Umsetzung von Sicherheitsmaßnahmen: Implementierung von Netzwerksegmentierung, Mikrosegmentierung und NSGs. Gehen Sie davon aus, dass sich ein Angreifer Zugang verschaffen könnte, und entwerfen Sie entsprechend kompensierende Kontrollen.
Integrieren Sie diese Sicherheitsprinzipien in Ihre Split-Brain-DNS-Architektur, um ein robustes und widerstandsfähiges System zu schaffen, das den internen und externen Zugriff auf Ihren Workload schützt.
Andere Sicherheitsverbesserungen
Anwendungs-Gateway: Sie können eine WAF auf Application Gateway verwenden, um Ihre Webanwendungen vor gängigen Web-Schwachstellen und Exploits zu schützen. Sie können auch Azure Private Link verwenden, um von Application Gateway aus sicher auf Ihre Back-End-Anwendungsserver zuzugreifen, ohne sie dem öffentlichen Internet auszusetzen.
Azure Firewall: Sie können dem virtuellen Hub-Netzwerk eine Azure Firewall hinzufügen und Azure Firewall Threat Intelligence verwenden, um bösartigen Datenverkehr von bekannten bösartigen IP-Adressen und Domänen zu blockieren. Sie können auch Azure Firewall als DNS-Proxy verwenden, um DNS-Verkehr abzufangen und zu überprüfen und DNS-Filterregeln anzuwenden.
Azure Front Door: Sie können Azure Web Application Firewall verwenden, um Ihre Webanwendungen vor gängigen Web-Schwachstellen und Exploits am Rand zu schützen. Sie können auch Private Link mit dem Azure Front Door Premium Tier verwenden, um sicher auf Ihre Back-End-Anwendungsserver von Azure Front Door zuzugreifen, ohne sie dem öffentlichen Internet auszusetzen.
Kostenoptimierung
Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Kostenoptimierung.
Back-End-Berechnung: Viele Faktoren wie die Auswahl der SKUs, die Anzahl der Replikate und die Region bestimmen die Kosten für den Betrieb von Backend-Rechendiensten. Stellen Sie sicher, dass Sie alle Elemente einer Rechenressource berücksichtigen, bevor Sie die beste Option für Ihre Arbeitslast auswählen.
Anwendungs-Gateway: Die Kosten für Application Gateway hängen von der Anzahl der Instanzen, der Größe der Instanzen und der Menge der verarbeiteten Daten ab. Sie können die Kosten optimieren, indem Sie autoscaling verwenden, um die Anzahl der Instanzen an die Verkehrsnachfrage anzupassen. Sie können auch zonenredundante SKUs über Verfügbarkeitszonen hinweg bereitstellen, um den Bedarf an zusätzlichen Instanzen für hohe Verfügbarkeit zu reduzieren.
Azure Front Door: Die Kosten für Azure Front Door hängen von der Anzahl der Routing-Regeln, der Anzahl der HTTP- oder HTTPS-Anfragen und der Menge der übertragenen Daten ab. Sie können Azure Front Door Standard Tier oder Premium Tier verwenden, um eine einheitliche Erfahrung mit Azure Content Delivery Network, Azure Web Application Firewall und Private Link zu erhalten. Sie können auch die Funktion der Azure Front Door Rules Engine verwenden, um das Verkehrsmanagement anzupassen und die Leistung und Kosten zu optimieren.
Wenn Ihr Szenario keinen globalen Zugriff oder die zusätzlichen Funktionen von Azure Front Door erfordert, können Sie diese Lösung nur mit Application Gateway verwenden. Sie können alle öffentlichen DNS-Einträge auf die öffentliche IP-Adresse verweisen, die auf den Application Gateway-Listenern konfiguriert ist.
Unter finden Sie ein Beispiel für diese Lösung, das die typische Verwendung der Komponenten in dieser Architektur annähernd wiedergibt. Passen Sie die Kosten an Ihr Szenario an.
Beitragende
Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:
Hauptautor:
- Troy Hite | Senior Cloud Solution Architect
Andere Mitwirkende:
- Mays Algebary | Senior Azure Networking Global Blackbelt
- Adam Torkar | Senior Azure Networking Global Blackbelt
- Michael McKechney | Principal Azure Technology Specialist
Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.
Nächste Schritte
- Konfigurieren der Application Gateway-Infrastruktur
- End-to-End-TLS mit Azure Front Door
- Fügt der Azure Front Door-Instanz eine benutzerdefinierte Domäne hinzu
- Was bedeutet Geofilterung auf einer Domain für Azure Front Door