In diesem Dokument werden gängige Anwendungsfälle für Google Cloud Armor-Sicherheitsrichtlinien beschrieben. Cloud Armor-Sicherheitsrichtlinien schützen Ihre Anwendung mit Zulassungslisten und Sperrlisten für IP-Adressen sowie mit vorkonfigurierten Regeln, die gängige Webangriffe abwehren.
Verfügbarkeit der Funktion
In der folgenden Tabelle wird die Verfügbarkeit von Cloud Armor-Funktionen basierend auf Ihrer Abo-Stufe und dem Typ des Load Balancers oder Endpunkts, den Sie schützen, zusammengefasst.
| Funktion | Cloud Armor Standard | Cloud Armor Enterprise | Unterstützte Endpunkte |
|---|---|---|---|
| Volumetrischer DDoS-Schutz | Enthalten | Enthalten | Alle externen Load-Balancer, Cloud CDN, Media CDN |
| Regeln für zulässige/abgelehnte IP-Adressen | Enthalten | Enthalten | Externer Application Load Balancer, externer Proxy-Network Load Balancer |
| Vorkonfigurierte WAF-Regeln | Enthalten | Enthalten | Externer Application Load Balancer, externer Proxy-Network Load Balancer |
| Benutzerdefinierte CEL-Regeln | Enthalten | Enthalten | Externer Application Load Balancer, externer Proxy-Network Load Balancer |
| Adaptiver Schutz | Nur Benachrichtigungen | Vollständiger Schutz | Externer Application Load Balancer |
| Bot-Verwaltung | Nicht verfügbar | Enthalten | Externer Application Load Balancer |
| Erweiterter DDoS-Schutz für Netzwerke | Nicht verfügbar | Enthalten | Externer Passthrough-Network Load Balancer, Protokollweiterleitung, VM mit öffentlicher IP-Adresse |
| Sicherheitsrichtlinien für Netzwerk-Edge | Nicht verfügbar | Enthalten | Externer Passthrough-Network Load Balancer, Protokollweiterleitung, VM mit öffentlicher IP-Adresse |
| Threat Intelligence | Nicht verfügbar | Enthalten | Externer Application Load Balancer, externer Proxy-Network Load Balancer |
Beispiele für Sicherheitsrichtlinien
In diesem Abschnitt wird beschrieben, wie Sie mit Cloud Armor-Sicherheitsrichtlinien den Zugriff auf Ihre Anwendungen oder Dienste steuern können.
Zugriff für Nutzer mit bestimmten IP-Adressen über Zulassungslisten gewähren
Mit einer Zulassungsliste für IP-Adressen können Sie Anfragen auf bestimmte IP-Adressen oder CIDR-Bereiche beschränken, z. B. die öffentlichen IP-Adressen Ihrer Niederlassungen. Sie können nur Traffic aus diesen angegebenen Bereichen zulassen.
Sie steuern den Zugriff auf den globalen externen Application Load Balancer oder den klassischen Application Load Balancer, indem Sie eine Zulassungsliste mit Client-IP-Adressen oder Client-CIDR-Bereichen konfigurieren. Im folgenden Abschnitt wird diese Konfiguration beschrieben.
In dieser Konfiguration lassen Sie nur Anfragen von Client-IP-Adressen in einem bestimmten Bereich auf den globalen externen Application Load Balancer oder den klassischen Application Load Balancer zu. Der gesamte andere Traffic soll abgelehnt werden.
Gehen Sie so vor, um diese Konfiguration zu erstellen:
- Erstellen Sie eine Cloud Armor-Sicherheitsrichtlinie.
- Fügen Sie in der Sicherheitsrichtlinie eine Regel hinzu, mit der der Bereich der Zulassungsliste hinzugefügt wird.
Diese Regel hat die Beschreibung
allow [RANGE], wobei[RANGE]der gewünschte IP-Bereich ist. - Ändern Sie die Standardregel in der Richtlinie von einer allow-Regel in eine deny-Regel. Die Standardregel ist die letzte Regel in der Richtlinie und steuert den Traffic, der keiner der vorangehenden Regeln entspricht. Wenn Sie diese Regel in
denyändern, wird der gesamte Traffic blockiert, der nicht im Bereich der Zulassungsliste liegt. - Verknüpfen Sie diese Richtlinie mit dem Backend-Dienst des globalen externen Application Load Balancers oder des klassischen Application Load Balancers.
Wenn Ihre Organisation einen Drittanbieter für die Überprüfung des Traffics einsetzt, können Sie die IP-Adresse des Sicherheitsanbieters zu einer Zulassungsliste hinzufügen, damit nur überprüfter Traffic auf den globalen externen Application Load Balancer oder den klassischen Application Load Balancer und die Back-Ends zugreifen kann.
In der folgenden Abbildung wird der Drittanbieter durch den CIDR-Bereich 192.0.2.0/24 angegeben. Dieser Bereich befindet sich auf einer Zulassungsliste.
Zugriff für Nutzer mit bestimmten IP-Adressen über Sperrlisten blockieren
Verwenden Sie Sperrlisten, um Traffic von bestimmten IP-Adressen oder CIDR-Bereichen abzulehnen.
In der folgenden Abbildung enthält die Cloud Armor-Sicherheitsrichtlinie eine deny-Regel, die den Traffic von der IP-Adresse 198.51.100.1 blockiert, bei der ein böswilliger Nutzer identifiziert wurde.
Benutzerdefinierte Regeln, um basierend auf Parametern der Ebenen 3 bis 7 zu filtern
Definieren Sie Ausdrücke in der Abgleichsbedingung einer Regel mit der Sprache für benutzerdefinierte Regeln für Cloud Armor. Cloud Armor wertet eingehende Anfragen anhand dieser Ausdrücke aus. Wenn eine Anfrage übereinstimmt, wird die Aktion der Regel angewendet, indem der Traffic entweder abgelehnt oder zugelassen wird.
Die folgenden Beispiele sind Ausdrücke, die in der Cloud Armor-Erweiterung der Common Expression Language (CEL) geschrieben wurden. Weitere Informationen finden Sie in der Referenz zur Sprache für benutzerdefinierte Regeln.
Definieren Sie Ausdrücke mit dem Google Cloud CLI-Flag --expression oder derGoogle Cloud Console. Weitere Informationen finden Sie unter Sicherheitsrichtlinien, Regeln und Ausdrücke erstellen.
Im folgenden Beispiel stimmen Anfragen von 2001:db8::/32 (z. B. Ihren Alpha-Testern) in der Region AU mit dem folgenden Ausdruck überein:
origin.region_code == "AU" && inIpRange(origin.ip, '2001:db8::/32')
Das folgende Beispiel stimmt mit Anfragen von 192.0.2.0/24 und mit einem User-Agent überein, der die Strings WordPress enthält:
inIpRange(origin.ip, '192.0.2.0/24') && has(request.headers['user-agent']) && request.headers['user-agent'].contains('WordPress')
Weitere Beispiele finden Sie in der Referenz zur Sprache für benutzerdefinierte Regeln unter Beispielausdrücke.
Schützen Sie Ihre Bereitstellung vor Angriffen auf die Anwendungsschicht und minimieren Sie die OWASP-Top-10-Risiken
Cloud Armor schützt Cloud CDN-Ursprungsserver vor Angriffen auf die Anwendungsschicht (L7) wie vor SQL-Injection (SQLi) und Cross-Site-Scripting (XSS). Inhalte in einem Cache sind statisch und stellen in der Regel kein Risiko in Form eines gezielten Angriffs dar. Der Ursprungsserver kann jedoch eine dynamische Anwendung mit Sicherheitslücken sein. Aufgrund Ihrer Sicherheitsanforderungen müssen Sie diese Risiken möglicherweise abwehren, um zu verhindern, dass der Ursprungsserver erfolgreich über Sicherheitslücken angegriffen werden kann.
So wehren Sie die Risiken ab:
- Erstellen oder identifizieren Sie einen Backend-Dienst mit aktiviertem CDN.
- Erstellen Sie eine Cloud Armor-Sicherheitsrichtlinie.
- Erstellen Sie in der Sicherheitsrichtlinie eine oder mehrere Regeln, um L7-Angriffe abzuwehren.
- Konfigurieren Sie eines der Ziele der Sicherheitsrichtlinie als Back-End-Dienst, den Sie in Schritt 1 erstellt oder identifiziert haben.
Verwenden Sie vorkonfigurierte Regeln, um gängige Angriffe auf Anwendungsebene zu erkennen und zu blockieren.
Vorkonfigurierte Regeln sind vordefinierte Ausdruckssätze, die Sie einer Sicherheitsrichtlinie hinzufügen können. Verwenden Sie das gcloud CLI-Flag --expression oder die Google Cloud Console, um diese Ausdruckssätze einer Regel hinzuzufügen.
Weitere Informationen finden Sie unter Sicherheitsrichtlinien, Regeln und Ausdrücke erstellen.
Eine vorkonfigurierte Regel prüft standardmäßig die ersten 8 KB eines Anfragetexts. Sie können dieses Limit jedoch pro Richtlinie konfigurieren. Weitere Informationen zum Konfigurieren dieses Prüflimits für einen Anfragetext bei Verwendung vorkonfigurierter WAF-Regeln finden Sie unter Beschränkung der Anfragetextprüfung.
Weitere Informationen zu vorkonfigurierten Regeln finden Sie in der Sprachreferenz für benutzerdefinierte Regeln unter Vorkonfigurierte Regeln.
Im folgenden Beispiel wird eine vorkonfigurierte Regel verwendet, um XSS-Angriffe (Cross-Site-Scripting) abzuwehren:
evaluatePreconfiguredWaf('xss-v422-stable')
Im folgenden Beispiel wird eine vorkonfigurierte Regel verwendet, um SQLi-Angriffe (SQL Injection) abzuwehren:
evaluatePreconfiguredWaf('sqli-v422-stable')
Sie können auch vorkonfigurierte Regeln mit anderen Ausdrücken kombinieren. Im folgenden Beispiel wird eine vorkonfigurierte Regel verwendet, um SQLi-Angriffe aus dem IP-Adressbereich 192.0.2.1/24 abzuwehren:
inIpRange(origin.ip, '192.0.2.1/24') && evaluatePreconfiguredWaf('sqli-v422-stable')
Verringerung der OWASP-Top-10-Risiken für Hybridarbeitslasten
Cloud Armor bietet Schutzmaßnahmen für die folgenden Angriffe, unabhängig davon, ob sie in Google Cloud, lokal oder bei einem Drittanbieter bereitgestellt werden:
- SQL-Injection (SQLi)
- Cross-Site-Scripting (XSS)
- Aufnahme lokaler Dateien (Local File Inclusion, LFI)
- Datei-Aufnahme per Fernzugriff (Remote File Inclusion, RFI)
- Codeausführung per Fernzugriff (Remote Code Execution, RCE)
Mit diesen Funktionen können Sie einige der häufigsten Sicherheitsrisiken für Webanwendungen beheben, einschließlich solcher Risiken, die in der OWASP-Top-10-Liste enthalten sind.
Fügen Sie einer Sicherheitsrichtlinie vorkonfigurierte WAF-Regeln hinzu, um unerwünschte Ebene-7-Anfragen wie SQLi- oder XSS-Versuche zu erkennen und abzulehnen. Cloud Armor erkennt schädliche Anfragen und verwirft sie am Rand der Google-Infrastruktur. Anfragen werden nicht an den Backend-Dienst weitergeleitet, unabhängig davon, wo er bereitgestellt wird.
So schützen Sie eine nicht inGoogle Cloudgehostete Arbeitslast vor diesen Angriffen am Rand des Google-Netzwerks:
- Konfigurieren Sie einen globalen externen Application Load Balancer oder einen klassischen Application Load Balancer mit einem Backend-Dienst, der eine Internet-NEG als Backend hat.
- Erstellen Sie eine Cloud Armor-Sicherheitsrichtlinie.
- Fügen Sie der Richtlinie vorkonfigurierte SQLi- und XSS-Regeln hinzu.
- Hängen Sie die Sicherheitsrichtlinie an den Backend-Dienst an, den Sie in Schritt 1 erstellt haben.
- Sie können Cloud Armor-Aktivitäten mithilfe von Cloud Logging, Cloud Monitoring und den Ergebnissen beobachten, die an das Security Command Center gesendet werden.
DDoS-Verteidigung und Ebene-7-Monitoring des externen Cloud CDN-Ursprungsservers
Cloud CDN-Bereitstellungen mit einem externen Ursprungsserver können die Randinfrastruktur von Google als Front-End für das Proxying, Caching und die Ebene-7-Filterung von Cloud Armor verwenden. Bei Verwendung von Internet-NEGs kann sich der Ursprungsserver lokal oder bei einem Infrastruktur-Drittanbieter befinden.
Cloud Armor und die Randinfrastruktur von Google wehren L3- und L4-Angriffe ab, warnen Sie vor verdächtigen Ebene-7-Aktivitäten und lehnen unerwünschte Ebene-7-Anfragen mit benutzerdefinierten Regeln ab. Cloud Armor-Logging und -Telemetrie in Cloud Logging, Cloud Monitoring und Security Command Center bieten unabhängig davon, wo sie bereitgestellt werden, umsetzbare Informationen für geschützte Anwendungen.
So aktivieren Sie den Cloud Armor-Schutz für externe CDN-Ursprungsserver:
- Konfigurieren Sie einen globalen externen Application Load Balancer oder einen klassischen Application Load Balancer mit einem Backend-Dienst, der eine Internet-NEG als Backend hat.
- Aktivieren Sie Cloud CDN für diesen Backend-Dienst.
- Erstellen Sie eine Cloud Armor-Sicherheitsrichtlinie.
- Hängen Sie die Sicherheitsrichtlinie an den Backend-Dienst an, den Sie in Schritt 1 erstellt haben.
- Greifen Sie in Security Command Center, Cloud Logging und Cloud Monitoring auf Cloud Armor-Benachrichtigungen, Logging und Telemetrie zu.
Darüber hinaus können Sie Edge-Sicherheitsrichtlinien verwenden, um im Cache gespeicherte Inhalte zu schützen. Weitere Informationen zu Edge-Sicherheitsrichtlinien finden Sie in der Übersicht über Sicherheitsrichtlinien.
Ebene-7-Zugriffssteuerungen und Cache-Busting-Angriffe
Je nach Anwendungsarchitektur können Sie einen Backend-Dienst so konfigurieren, dass Anfragen für eine Vielzahl von URLs, einschließlich cachefähiger und nicht cachefähiger Inhalte, bearbeitet werden. Erstellen Sie in solchen Bereitstellungsszenarien Sicherheitsrichtlinien für Cloud Armor, die unerwünschten Traffic über bestimmte Anfragepfade ablehnen, aber allen Clients über einen anderen Anfragepfad den Zugriff auf statische Inhalte ermöglichen.
In anderen Situationen kann ein schädlicher Client, obwohl Inhalte aus dem Cache bereitgestellt werden, viele Anfragen generieren, die zu einem Cache-Fehler führen. Bei einem Cache-Fehler muss der Ursprungsserver die Inhalte abrufen oder generieren, was Ressourcen belasten und die Verfügbarkeit beeinträchtigen kann. Erstellen Sie eine Sicherheitsrichtlinie, die auf die Signatur aller Clients prüft, die das Problem verursachen, und die Anfragen ablehnt, bevor sie den Ursprungsserver erreichen.
Gehen Sie dazu so vor:
- Erstellen Sie eine Cloud Armor-Sicherheitsrichtlinie.
Konfigurieren Sie eine Regel. Diese lehnt beispielsweise den Zugriff auf
"/admin"ab:request.path.contains("/admin") && !inIpRange(origin.ip, '<allowed_ip_range>')Fügen Sie die Sicherheitsrichtlinie aus Schritt 1 dem Back-End-Dienst hinzu, für den Cloud CDN aktiviert ist.
Schutz für externe Passthrough-Network Load Balancer
Wenn Sie ein Cloud Armor Enterprise-Abo haben, können Sie den erweiterten DDoS-Netzwerkschutz verwenden, um Ihre externen Passthrough-Network Load Balancer, die Protokollweiterleitung und VMs mit öffentlichen IP-Adressen zu schützen. Diese Funktion bietet eine Inline-Abwehr von L3- und L4-DDoS-Angriffen, die immer aktiv ist.
Weitere Informationen finden Sie unter Erweiterter DDoS-Schutz für Netzwerke – Übersicht.
Nächste Schritte
- Sicherheitsrichtlinien konfigurieren
- Weitere Informationen zur Sprache für benutzerdefinierte Regeln
- WAF-Regeln optimieren