Mit Google Cloud Armor, Load-Balancing und Cloud CDN programmierbare globale Front-Ends bereitstellen

Last reviewed 2024-04-04 UTC

Dieses Dokument bietet eine Referenzarchitektur für eine Webanwendung, die in Google Cloud gehostet wird. Die Architektur verwendet ein globales Frontend, das Best Practices von Google Cloud umfasst, um die Bereitstellung Ihrer Internetanwendungen zu skalieren, zu sichern und zu beschleunigen. Die Architektur umfasst Support für Cloud Build sowie Tools für Continuous Integration (CI) und Continuous Delivery (CD) von Drittanbietern wie Jenkins und GitLab. Diese Architektur ist für Entwickler und Anwendungsinhaber gedacht, die ihre Anwendung mit einem Load-Balancer skalieren und ihre Anwendungen vor DDoS- (Distributed Denial of Service) und webbasierten Angriffen mit einem Web Application Firewall (WAF).

Architektur

Das folgende Diagramm zeigt die Architektur, die in diesem Dokument beschrieben wird.

Architektur der Webanwendung.

In dieser Architektur erfolgt das Load Balancing der Anwendung mit globalen externen Application Load Balancern, die HTTP- und HTTPS-Traffic auf mehrere Backend-Instanzen und über mehrere Regionen hinweg verteilen. Cloud CDN beschleunigt das Internet Anwendungen mithilfe der Edge Points of Presence (PoPs) von Google und arbeitet mit dem globalen externen Application Load Balancer zusammen, um Inhalte für Nutzer bereitzustellen. Die Back-Ends werden durch Google Cloud Armor-Sicherheitsrichtlinien geschützt, die eine Layer-7-Filterung durch Scrubbing eingehender Anfragen für häufige Webangriffe oder andere Layer-7-Attribute ermöglichen, um Traffic zu blockieren, bevor und die Back-End-Dienste mit Load Balancing erreicht. Der Schutz vor volumetrischen DDoS-Angriffen ist standardmäßig aktiviert.

Wenn ein Nutzer Inhalte von Ihrem Dienst anfordert, wird diese Anfrage an das Globale Frontend für internetorientierte Anwendungen gesendet, die vom Cloudübergreifenden Netzwerk angeboten wird. Die Anfrage wird von Google Cloud Armor-Sicherheitsrichtlinien ausgewertet, beginnend mit den Edge-Sicherheitsrichtlinien von Google Cloud Armor. Wenn die Anfrage zulässig ist und von Cloud CDN erfüllt werden kann, wird der Inhalt aus dem Google Cloud Armor-Cache abgerufen und an den Nutzer zurückgesendet. Wenn die Anfrage zu einem Cache-Fehler führt, wird sie von Back-End-Richtlinien ausgewertet und dann gemäß den Regeln der Richtlinie von Ihrem Back-End-Server abgelehnt oder erfüllt.

Architekturkomponenten

Das obige Diagramm enthält die folgenden Komponenten:

  • Globaler externer Application Load Balancer: Dieser Application Load Balancer ist ein proxybasierter Layer-7-Load Balancer, mit dem Sie Ihre Dienste ausführen und skalieren können. Der Application Load Balancer verteilt HTTP- und HTTPS-Traffic an Back-Ends, die auf einer Vielzahl von Google Cloud-Plattformen gehostet werden. Der Application Load Balancer hat die folgenden Features:

    • Konfigurierbares Backend: Diese Architektur verwendet zwei verwaltete Instanzgruppen (Managed Instance Groups, MIGs) in verschiedenen Regionen. Sie können jedoch jedes Backend konfigurieren, das der globale externe Application Load Balancer unterstützt. Sie können denselben Load Balancer für GKE-, Cloud Run-, Cloud Run Functions- und App Engine-Anwendungen sowie für lokal und in anderen Clouds gehostete Anwendungen mit einer anderen Backend-Konfiguration verwenden. Weitere Informationen finden Sie unter Application Load Balancer.
    • Traffic-Aufteilung: Sie können den Application Load Balancer für die Traffic-Verwaltung verwenden, einschließlich der Verwaltung von Software-Versionen, indem Sie verschiedene Nutzer an verschiedene Backend-Server senden. Bei der in diesem Dokument beschriebenen Architektur gibt es eine einfache 60/40-Trafficaufteilung. Sie können diese Aufteilung jedoch ändern, um komplexere Traffic-Verwaltungsschemas zu erstellen. Informationen zu zusätzlichen Konfigurationsoptionen finden Sie unter den konfigurierbaren Zeitüberschreitungen und Wiederholungsversuchen und bestimmen Sie Ihren bevorzugten Balancing-Modus.

  • Cloud CDN: Die Cloud CDN-Plattform fungiert als Cache. Es wird mit dem Ursprungsserver bereitgestellt, um die vollständige Suite der Cloud CDN-Features einschließlich QUIC und HTTP/2 sowie Routing- und Caching-Steuerelemente bereitzustellen. Dieser Ansatz ermöglicht es Ihrer Anwendung, global zu skalieren, ohne die Leistung zu beeinträchtigen. Außerdem können Sie damit die Kosten für Bandbreite und Frontend-Computing senken. Die Standardkonfiguration, die das globale Frontend verwendet, basiert auf den Best Practices für die Inhaltsübermittlung und Best Practices für Websicherheit für Cloud CDN.

  • Google Cloud Armor: Diese Komponente enthält DDoS-Schutz- und WAF-Regeln. Die Architektur hat die folgende grundlegende Google Cloud Armor-Konfiguration, die zur Vermeidung gängiger Bedrohungsvektoren beiträgt:

Verwendete Produkte

In dieser Referenzarchitektur werden die folgenden Google Cloud-Produkte verwendet:

Designaspekte

Dieser Abschnitt enthält eine Anleitung zum Verwenden dieses Dokuments als Ausgangspunkt für die Entwicklung einer Architektur, die Ihren spezifischen Anforderungen an Sicherheit, Zuverlässigkeit, operative Effizienz, Kosten und Leistung entspricht.

Sicherheit, Datenschutz und Compliance

In diesem Abschnitt werden zusätzliche Faktoren beschrieben, die Sie berücksichtigen sollten, wenn Sie diese Referenzarchitektur zum Bereitstellen der Webanwendung verwenden.

Sicherheits-Baseline einrichten

Zur weiteren Verbesserung Ihrer Sicherheit ist die in diesem Dokument beschriebene Architektur auch mit dem Unternehmensgrundlagen-Blueprint kompatibel. Der Blueprint unterstützt Organisationen, die Google Cloud verwenden, um eine sichere Referenz für alle zukünftigen Arbeitslasten zu schaffen, einschließlich der Einrichtung von Identity and Access Management (IAM) und Cloud Key Management. Service und Security Command Center.

Nutzerdaten mit Cloud CDN schützen

In dieser Architektur empfehlen wir, nutzerspezifische Inhalte nicht im Cache zu speichern. Legen Sie für das Caching von HTML- (text/html)- und JSON- (application/json)-Inhaltstypen explizite Cache-Steuerungsheader in der Cloud CDN-Antwort fest. Achten Sie darauf, die Daten eines Nutzers nicht im Cache zu speichern und für alle Nutzer bereitzustellen.

Zugriff auf die Anwendung mit IAP steuern

Die Architektur ist auch mit Identity-Aware Proxy (IAP) kompatibel. IAP überprüft die Identität eines Nutzers und bestimmt dann, ob dieser Nutzer auf eine Anwendung zugreifen darf. Um IAP für den Application Load Balancer für den globalen externen Modus oder den klassischen Modus zu aktivieren, aktivieren Sie IAP in den Backend-Diensten des Load-Balancers. Eingehende HTTP-/HTTPS-Anfragen werden von Google Cloud Armor ausgewertet, bevor sie zum Load-Balancing vom Application Load Balancer gesendet werden. Wenn Google Cloud Armor eine Anfrage blockiert, wertet IAP die Anfrage nicht aus. Wenn Google Cloud Armor eine Anfrage zulässt, wertet IAP diese Anfrage aus. Die Anfrage wird blockiert, wenn IAP die Anfrage nicht authentifiziert. Weitere Informationen finden Sie unter Google Cloud Armor in andere Google-Produkte integrieren.

Kostenoptimierung

Als allgemeine Richtlinie kann die Verwendung von Cloud CDN in Verbindung mit Google Cloud Armor die Auswirkungen von Gebühren für ausgehenden Datentransfer minimieren.

Cloud CDN

Statische Objekte, die aus dem Cache an den Client bereitgestellt werden, durchlaufen nicht den Load-Balancer. Eine effektive Caching-Strategie kann die Menge der vom Load-Balancer verarbeiteten ausgehenden Daten reduzieren und Ihre Kosten senken.

Google Cloud Armor

Mit Google Cloud Armor können Sie die Kosten senken, indem Sie verhindern, dass Ihrem Konto unerwünschter Traffic in Rechnung gestellt wird. Von Google Cloud Armor blockierte Anfragen generieren keine Antwort von Ihrer Anwendung, wodurch die Menge der vom Load-Balancer verarbeiteten ausgehenden Daten reduziert wird. Die Auswirkungen auf Ihre Kosten hängen vom Prozentsatz des unerwünschten Traffics ab, der von den implementierten Google Cloud Armor-Sicherheitsrichtlinien blockiert wird.

Die endgültigen Kosten können auch abhängig davon variieren, wie viele Dienste oder Anwendungen Sie schützen möchten, die Anzahl Ihrer Google Cloud Armor-Richtlinien und -Regeln, die Cache-Füllung und den ausgehenden Traffic und das Datenvolumen. Weitere Informationen nachstehend:

Bereitstellung

Verwenden Sie das Terraform-Beispiel, um diese Referenzarchitektur bereitzustellen. Weitere Informationen finden Sie in der Datei README. Der Ordner web_app_protection_example enthält die Datei (main.tf). Der Code in dieser Datei erstellt die in diesem Dokument beschriebene Architektur und bietet zusätzliche Unterstützung für die automatische Bereitstellung.

Die Ordnerstruktur im Terraform-Ordner sieht so aus:

  • Quellcode-Repository: The Web Application Protection Example ist Teil des Repositorys Web Application and API Protection (WAAP).
  • CD und CI: Der Build-Ordner enthält die folgenden beschreibenden Dateien für Jenkins, GitLab und Cloud Build:
    • Jenkins: Dieses Repository enthält die Jenkins-Datei, die die Regeln enthält, die von der Pipeline ausgeführt werden.
    • GitLab: Dieses Repository enthält eine .gitlab-ci-YAML-Datei, die die Regeln enthält, die von der GitLab-Pipeline ausgeführt werden.
    • Cloud Build: Dieses Repository enthält die Cloud Build-Datei, die die Regeln basierend auf Zweignamen enthält.
  • Das Repository enthält eine Option für die Bereitstellung in mehreren Umgebungen (Produktion und Entwicklung). Weitere Informationen finden Sie in der Datei README.

Wenn Sie eine Änderung an einem Zweig vornehmen, auf dem Ihre Pipeline basiert, lösen diese Änderungen eine Pipeline-Ausführung aus und die Änderungen werden nach Abschluss in einen neuen Release eingebunden. Wenn Sie das Toolkit zum ersten Mal abrufen, wird die Lösung in das ausgewählte Google Cloud-Projekt geladen.

Nächste Schritte

Mehr über die Best Practices für die in dieser Referenzarchitektur verwendeten Google Cloud-Produkte erfahren:

Beitragende

Autoren:

Weitere Beitragende: