Muster „Gatewayabladung“

Lagern Sie gemeinsam genutzte oder spezielle Dienstfunktionen an einen Gatewayproxy aus. Dieser Ansatz vereinfacht die Anwendungsentwicklung, indem querschnittsbezogene Belange wie die clientseitige TLS-Terminierung im Gateway zentralisiert werden, anstatt sie in allen Diensten zu duplizieren.

Wenn mehrere Dienste Verantwortlichkeiten wie Authentifizierung, Überwachung oder Protokollübersetzung gemeinsam nutzen, reduziert die Konsolidierung dieser Probleme in einem einzelnen Gateway den Aufwand für die Konfiguration pro Dienst und das Bereitstellungsrisiko.

Kontext und Problem

Einige Features werden häufig über mehrere Dienste hinweg verwendet, sodass dafür die entsprechende Konfiguration, Verwaltung und Wartung erforderlich ist. Ein gemeinsam genutzter oder spezialisierter Dienst, den Sie mit jeder Anwendungsbereitstellung verteilen, erhöht den Verwaltungsaufwand und erhöht die Wahrscheinlichkeit eines Bereitstellungsfehlers. Sie müssen alle Updates für ein freigegebenes Feature für alle Dienste bereitstellen, die dieses Feature gemeinsam nutzen.

Sicherheitsaspekte wie Tokenvalidierung, Verschlüsselung und die Verwaltung von TLS-Zertifikaten können erfordern, dass Teammitglieder über hochspezialisierte Fachkenntnisse verfügen. Beispielsweise müssen Sie ohne Gateway ein clientseitiges Zertifikat für jede Anwendungsinstanz konfigurieren und bereitstellen. Sie müssen seinen Ablaufzeitpunkt verfolgen und es in all diesen Instanzen aktualisieren, testen und verifizieren.

Andere gemeinsam genutzte Dienste, z.B. Authentifizierung, Autorisierung, Protokollierung, Überwachung oder Drosselung, können für eine große Zahl von Bereitstellungen schwierig zu implementieren und zu verwalten sein. Die Konsolidierung dieser Art von Funktionalität reduziert den Aufwand und die Wahrscheinlichkeit von Fehlern.

Solution

Entladen Sie einige Funktionen in ein Gateway. Das Gateway behandelt dann übergreifende Bedenken wie clientorientierte Zertifikatverwaltung, Authentifizierung, TLS-Abschluss, Überwachung, Protokollübersetzung und Drosselung im Auftrag von Back-End-Diensten.

Das folgende Diagramm zeigt ein Gateway, das eingehende TLS-Verbindungen beendet und freigegebene Funktionen anwendet. Das Gateway überprüft das Back-End-Zertifikat und verschlüsselt den Datenverkehr über eine separate TLS-Verbindung mit dem Back-End-Dienst erneut.

Diagramm eines Clients, der eine Verbindung mit einem Gateway über TLS herstellt.

Vorteile dieses Musters:

  • Vereinfachen Sie die Entwicklung von Diensten, indem Sie gemeinsame Konfigurationen wie Authentifizierung, Einschränkung und Anforderungsprotokollierung zentralisieren, anstatt sie in jedem Back-End-Dienst zu implementieren. Die Zentralisierung verbessert die Konsistenz und macht Dienstupgrades einfacher.

  • Dedizierte Teams können Features implementieren, für die besondere Kenntnisse erforderlich sind, z.B. im Bereich der Sicherheit. Ihr Kernteam kann sich dann auf die Anwendungsfunktionalität konzentrieren und diese speziellen, aber übergreifenden Anliegen den relevanten Experten überlassen.

  • Sorge für Konsistenz bei der Protokollierung und Überwachung von Anfragen und Antworten. Auch wenn ein Dienst nicht ordnungsgemäß instrumentiert ist, kann das Gateway eine Grundlegende Ebene der Überwachung und Protokollierung bereitstellen.

  • Zentralisiertes CO2-bewusstes Verkehrsmanagement. Ein Gateway kann das Zwischenspeichern, das Einschränken der Rate und das Protokollierungsverhalten basierend auf Signalen der Co2-Intensität in Echtzeit anpassen. Azure API Management bietet diese Funktionen in eingeschränkter Vorschau, in ausgewählten Regionen und klassischen Ebenen (Entwickler, Basic, Standard und Premium). Details zu Verfügbarkeit und Konfiguration finden Sie unter Umweltschonende APIs in Azure API Management.

Probleme und Überlegungen

Beachten Sie die folgenden Punkte bei Ihrer Entscheidung, wie dieses Muster implementiert werden soll:

  • Hohe Verfügbarkeit und Resilienz. Stellen Sie sicher, dass das Gateway hochverfügbar und robust gegenüber Fehlern ist. Vermeiden Sie einzelne Schwachstellen, indem Sie mehrere Instanzen Ihres Gateways ausführen. Da das Gateway Clientverbindungen beendet und Anforderungstexte puffern kann, sollten Sie berücksichtigen, wie In-Flight-Anforderungen während Instanzfehlern behandelt werden. Verwenden Sie Mechanismen für Verbindungsdrainage oder ein ordnungsgemäßes Herunterfahren, sodass beim Entfernen oder Neustarten einer Gatewayinstanz aktive Sitzungen nicht unterbrochen werden.

  • Kapazität und Skalierung. Stellen Sie sicher, dass das Gateway für die Kapazitäts- und Skalierungsanforderungen Ihrer Anwendung und Endpunkte ausgelegt ist. Stellen Sie sicher, dass das Gateway nicht zu einem Engpass für die Anwendung wird und ausreichend skalierbar ist. Das Gateway muss so ausgelegt werden, dass es Verkehrsspitzen bewältigen kann, nicht nur die durchschnittliche Last. Eine zu knappe Dimensionierung des Gateways zur Kostensenkung beeinträchtigt unmittelbar die Leistung aller dahinterliegenden Dienste.

  • Umfang der Auslagerung. Lagern Sie Funktionen aus, die von mehreren Diensten oder Routen gemeinsam genutzt werden, wenn ihre Zentralisierung den doppelten Implementierungs- und Verwaltungsaufwand reduziert.

  • Trennung der Geschäftslogik. Laden Sie die Geschäftslogik niemals auf das Gateway aus.

  • Transaktionsnachverfolgung. Wenn Sie Transaktionen nachverfolgen müssen, sollten Sie erwägen, Korrelations-IDs für Protokollierungszwecke zu generieren.

  • Latenzaufwand. Das Gateway fügt jeder Anfrage einen Netzwerksprung hinzu. Jede vom Gateway ausgeführte offloaded-Funktion, z. B. TLS-Beendigung, Authentifizierung oder Anforderungsüberprüfung, fügt dem Anforderungspfad Verarbeitungszeit hinzu. Verbindungspooling im Gateway und Keep-Alive-Verbindungen zu Backenddiensten können die Latenzkosten teilweise ausgleichen, indem Verbindungen wiederverwendet werden, anstatt für jede Anfrage neue Verbindungen aufzubauen. Bewerten Sie, ob die kombinierte Latenz des Gateway-Hops und die ausgeladenen Funktionen für die Leistungsziele der Workload akzeptabel sind.

  • Betriebskomplexität. Ein zentrales Gateway konsolidiert die Verwaltung, konzentriert sich aber auch auf die operative Verantwortung. Sie müssen die Gatewaykonfiguration, den Zertifikatlebenszyklus, Richtlinienupdates und Versionsupgrades als gemeinsames Anliegen verwalten. Stellen Sie sicher, dass das für das Gateway zuständige Team über die Kapazität und tools verfügt, um es im Maßstab aller Dienste zu verwalten, die davon abhängig sind.

  • Sicherheitsauswirkungen. Das Gateway ist ein hochwertiges Ziel, da es übergreifende Sicherheitsfunktionen wie Authentifizierung, TLS-Beendigung und Anforderungsüberprüfung zentralisiert. Eine Kompromittierung des Gateways kann alle nachgeschalteten Dienste verfügbar machen. Härten Sie das Gateway, beschränken Sie die Verwaltungsoberfläche, und überwachen Sie sie unabhängig von den back-End-Diensten, die sie schützt, auf anomales Verhalten.

  • Verhinderung von Gatewayumgehungen. Konfigurieren Sie Back-End-Dienste so, dass Anforderungen nur über den vorgesehenen Gatewaypfad akzeptiert werden. Andernfalls können Clients sich direkt mit einem Backend verbinden und dabei die Authentifizierung, Drosselung, Anforderungsprüfung und Protokollierung am Gateway umgehen.

  • Identitätsweitergabe. Definieren Sie, ob jedes Back-End den ursprünglichen Aufrufer, die Workloadidentität des Gateways oder beides autorisiert. Bewahren Sie Aufrufertoken oder vertrauenswürdige Ansprüche nur bei, wenn das Back-End delegierten Benutzerkontext erfordert. Authentifizieren Sie das Gateway immer separat für das Back-End. Behandeln Sie keine nicht überprüften weitergeleiteten Header als Identitätsnachweis.

  • TLS-Wartung. Wenn das Gateway TLS beendet, stellen Sie TLS wieder in das Back-End ein. Leiten Sie den Datenverkehr nicht über unverschlüsselte HTTP weiter. Behandeln Sie alle Netzwerke als nicht vertrauenswürdig. Diese Topologie erfordert weiterhin einen Prozess, um Backend-Zertifikate auszustellen, zu erneuern und zu widerrufen.

  • Weitergeleitete Header und Clientkontext. Wenn das Gateway Clientverbindungen beendet und neue Verbindungen mit Back-End-Diensten herstellt, gehen Informationen wie die Client-IP-Adresse, das ursprüngliche Protokoll und der Hostname verloren, es sei denn, das Gateway leitet sie explizit weiter. Informationen zu Strategien zur Risikominderung finden Sie unter Beibehalten des ursprünglichen HTTP-Hostnamens zwischen einem Reverseproxy und der zugehörigen Back-End-Webanwendung.

Wann dieses Muster verwenden

Verwenden Sie dieses Muster in folgenden Fällen:

  • Eine Anwendungsbereitstellung hat ein gemeinsames Problem, z. B. TLS-Zertifikate oder Verschlüsselung.
  • Ein Feature, das in allen Anwendungsbereitstellungen üblich ist, kann unterschiedliche Ressourcenanforderungen aufweisen, z. B. Speicherressourcen, Speicherkapazität oder Netzwerkverbindungen.
  • Sie möchten die Verantwortung für Probleme wie Netzwerksicherheit, Drosselung oder andere Netzwerkgrenzen in ein spezielleres Team verschieben.

Dieses Muster ist möglicherweise nicht geeignet, wenn:

  • Das Gateway muss dienstspezifische Logik- oder Routingregeln enthalten, die Änderungen am Back-End-Dienst eng an Gatewaykonfigurationsänderungen gekoppelt haben. Die Kopplung der Gatewayebene mit internen Diensten bedeutet, dass Back-End-Updates die erneute Bereitstellung des Gateways erzwingen und die Bereitstellungsunabhängigkeit verringern können.
  • Die ausgelagerte Aufgabe ist ressourcenschonend und die Workload ist latenzempfindlich. Der zusätzliche Netzwerksprung über das Gateway ist möglicherweise nicht gerechtfertigt, wenn der Aufwand den Vorteil der Zentralisierung überwiegt.
  • Die Zentralisierung von Belangen in einem gemeinsam genutzten Gateway führt zu einem Engpass im Änderungsmanagement. Wenn der Veröffentlichungszyklus des Gatewayteams langsamer als die Dienstteams ist, kann das Entladen Updates für Zertifikate, Authentifizierungsrichtlinien oder Netzwerkregeln verzögern.

Arbeitslastgestaltung

Ein Architekt sollte evaluieren, wie das Gateway-Offloading-Muster im Design seiner Workloads verwendet werden kann, um die Ziele und Prinzipien zu erreichen, die in den Säulen des Azure Well-Architected Framework behandelt werden. Beispiel:

Säule So unterstützt dieses Muster die Säulenziele
Zuverlässigkeitsentwurfsentscheidungen helfen Ihrer Arbeitsauslastung, ausfallsicher zu werden und sicherzustellen, dass sie nach auftreten eines Fehlers wieder in einen voll funktionsfähigen Zustand versetzt wird. Die Auslagerung dieser Verantwortung auf ein Gateway reduziert die Komplexität des Anwendungscodes auf Back-End-Knoten. In einigen Fällen ersetzt die Auslagerung die Funktionalität vollständig durch eine zuverlässige, von der Plattform bereitgestellte Funktion.

- RE:01 Einfachheit und Effizienz
Sicherheitsdesignentscheidungen tragen dazu bei, die Vertraulichkeit, Integrität und Verfügbarkeit der Daten und Systeme Ihrer Workload sicherzustellen. Durch das Hinzufügen eines Gateways zum Anforderungsfluss können Sie Steuerelemente wie Webanwendungsfirewalls und TLS-Clientrichtlinien zentralisieren. Alle von der Plattform bereitgestellten ausgelagerten Funktionen bieten bereits erhöhte Sicherheit.

- SE:06 Netzwerksteuerungen
- SE:08 Härtungsressourcen
Die Kostenoptimierung konzentriert sich auf die Erhaltung und Verbesserung der Kapitalrendite Ihres Workloads. Mit diesem Muster können Sie Kosten von Ressourcen, die pro Knoten ausgegeben würden, in die Gateway-Implementierung umleiten. Die Kosten im zentralisierten Verarbeitungsmodell sind häufig niedriger als die des verteilten Modells.

- CO:14 Konsolidierung
Operational Excellence hilft, Arbeitsauslastungsqualität durch standardisierte Prozesse und Teamzusammenhalt zu liefern. In diesem Muster sind die Konfiguration und die Wartung der ausgelagerten Funktionalität mit einer einzigen Stelle verknüpft, anstatt eine Verwaltung über mehrere Knoten hinweg zu erfordern. Diese Zentralisierung standardisiert die Anwendung querschnittsbezogener Aspekte und macht routinemäßige sowie Ad-hoc-Änderungen im Betrieb konsistent und vorhersehbar.

- OE:02 Standardisieren von Vorgängen
Performance Efficiency hilft Ihrem Workload durch Optimierungen bei Skalierung, Daten und Code, die Anforderungen effizient zu erfüllen . Durch das Hinzufügen eines Offloadgateways zum Anforderungsprozess können Sie weniger Ressourcen pro Knoten verwenden, da die Funktionalität am Gateway zentralisiert ist. Sie können die Implementierung der ausgelagerten Funktionalität unabhängig vom Anwendungscode optimieren. Ausgelagerte, von der Plattform bereitgestellte Funktionen sind wahrscheinlich bereits hochleistungsfähig.

- PE:03 Dienste auswählen

Wenn dieses Muster Kompromisse innerhalb einer Säule einführt, sollten Sie sie gegen die Ziele der anderen Säulen berücksichtigen.

Example

Azure Application Gateway WAF_v2 können dieses Muster für eine regionale Webanwendung implementieren. Das Gateway beendet CLIENT-TLS-Verbindungen, wendet WAF- und Routingrichtlinien an und richtet neue TLS-Verbindungen mit den Back-End-Diensten ein. Dieses Design hält gemeinsame Belange der Anfragenverarbeitung aus dem Backend-Anwendungscode heraus.

Anwendungsgateway mit TLS-Offloading

Das folgende Diagramm zeigt, wie das Anwendungsgateway eingehende TLS-Verbindungen beendet, den Datenverkehr überprüft und filtert und erneut verschlüsselt, bevor es an einen Back-End-Pool über TLS weitergeleitet wird.

Diagramm, das zeigt, wie das Anwendungsgateway eingehende TLS von Clients beendet, WAF- und Routingregeln angewendet und Datenverkehr über TLS in einen Back-End-Pool erneut verschlüsselt.

Diese Architektur verwendet die folgenden Anwendungsgateway-Komponenten, um gemeinsam genutzte Funktionen zu entladen und Back-End-Datenverkehr erneut zu verschlüsseln:

  • HTTPS-Listener. Ein HTTPS-Listener auf Port 443 akzeptiert eingehende TLS-Verbindungen von Clients.
  • TLS-Zertifikat. Ein PFX-Zertifikat, das aus Azure Key Vault stammt, wird an den HTTPS-Listener angefügt. Application Gateway entschlüsselt eingehenden Datenverkehr, um ihn zu prüfen und weiterzuleiten, und verschlüsselt ihn anschließend erneut, bevor es ihn an den Back-End-Pool weiterleitet. Back-End-Server benötigen weiterhin Zertifikate für die erneut verschlüsselten Verbindungen, aber in vielen Fällen können plattformverwaltete Zertifikate verwendet werden.
  • Back-End-Pool. Ein Back-End-Pool definiert den Satz von HTTPS-Servern, die den erneut verschlüsselten Datenverkehr empfangen. Back-End-Ziele können virtuelle Computer, Azure Virtual Machine Scale Sets, IP-Adressen oder Azure App Service Instanzen sein. Beschränken Sie den Back-End-Zugriff, sodass Clients das Anwendungsgateway und seine WAF-Richtlinie nicht umgehen können, indem sie eine direkte Verbindung herstellen.
  • Back-End-HTTP-Einstellungen. Legen Sie das Back-End-Protokoll auf HTTPS und den Port zum TLS-Port des Back-Ends fest, z. B. 443. Konfigurieren Sie die Zertifikatvertrauensstellung und einen Hostnamen, der dem Back-End-Zertifikat entspricht. Konfigurieren Sie für eine private Zertifizierungsstelle das vertrauenswürdige Stammzertifikat. Ausführliche Informationen finden Sie unter End-to-End TLS mit der v2-SKU.
  • Routingregel. Eine Anforderungsweiterleitungsregel ordnet den Listener dem Back-End-Pool und den Back-End-HTTP-Einstellungen zu. Pfadbasierte Regeln können verschiedene URL-Pfade an verschiedene Back-End-Pools weiterleiten.
  • WAF-Richtlinie. Die Richtlinie definiert die verwalteten und benutzerdefinierten Regeln, die verwendet werden, um Anforderungen zu prüfen, einschließlich aller Geomatch-Regeln.

Da das Anwendungsgateway den Datenverkehr entschlüsselt, kann er Anforderungsinhalte auf intelligentes Routing überprüfen, HTTP-Header und URLs neu schreiben und WAF-Regeln anwenden. Anschließend wird der Datenverkehr erneut verschlüsselt, bevor Anforderungen an das Back-End weitergeleitet werden.

Anleitungen zur Konfiguration finden Sie unter End-to-End TLS-Verschlüsselung mit Dem Anwendungsgateway.

Unterstützende Technologien

Die folgenden Azure-Dienste können Ihnen bei der Implementierung dieses Musters helfen:

Nächste Schritte

  • Last updated on