Gängige Anwendungsfälle für Sicherheitsrichtlinien

Auf dieser Seite finden Sie gängige Anwendungsfälle für die Sicherheitsrichtlinien von Google Cloud Armor. Die Google Cloud Armor-Sicherheitsrichtlinien können Ihre Anwendung mit Funktionen wie Zulassungslisten und Sperrlisten für IP-Adressen schützen. Außerdem können Sie mit vorkonfigurierten Regeln gängige Webangriffe abwehren.

Zugriff auf Webanwendungen und Dienste steuern

In diesem Abschnitt werden verschiedene Möglichkeiten vorgestellt, wie Sie mit Google 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

Ein typischer Anwendungsfall für das Platzieren von Nutzer-IP-Adressen auf einer Zulassungsliste ist, wenn nur eine bestimmte Gruppe von Nutzern auf Ihren globalen externen Application Load Balancer oder klassischen Application Load Balancer zugreift. Im folgenden Beispiel haben nur Nutzer Ihrer Organisation Zugriff auf die Dienste hinter Ihrem Load-Balancer. Diesen Nutzern wurden von Ihrer Organisation IP-Adressen oder Adressblöcke zugewiesen. Sie können diese IP-Adressen oder CIDR-Bereiche in eine Zulassungsliste einfügen, sodass nur diese Nutzer Zugriff auf den Load-Balancer haben.

Load-Balancer-Zugriff mit einer Zulassungsliste einschränken.
Load-Balancer-Zugriff mit einer Zulassungsliste einschränken (zum Vergrößern klicken).

Sie steuern den Zugriff auf den globalen externen Application Load Balancer oder den klassischen Application Load Balancer, indem Sie eine Zulassungsliste mit Quell-IP-Adressen oder Quell-CIDR-Bereichen konfigurieren, von denen aus der Zugriff auf Ihren Load-Balancer zulässig ist. Im folgenden Abschnitt wird diese Konfiguration näher beschrieben.

In dieser Konfiguration möchten Sie nur Nutzern aus Ihrer Organisation mit IP-Adressen aus einem IP-Bereich den Zugriff auf den globalen externen Application Load Balancer oder den klassischen Application Load Balancer erlauben. Der gesamte andere Traffic soll abgelehnt werden.

Gehen Sie so vor, um diese Konfiguration zu erstellen:

  1. Erstellen Sie eine Google Cloud Armor-Sicherheitsrichtlinie.
  2. Fügen Sie in der Sicherheitsrichtlinie eine Regel hinzu, mit der der Bereich als erste Regel der Zulassungsliste hinzugefügt wird. Diese Regel hat die Beschreibung allow [RANGE], wobei [RANGE] der gewünschte IP-Bereich ist.
  3. Ändern Sie die Standardregel in der Richtlinie von einer allow-Regel in eine deny-Regel. Die Standardregel steuert den Traffic, der keiner der vorangehenden Regeln entspricht. Dies ist die letzte Regel in der Richtlinie. Wenn Sie die Regel von allow in deny ändern, wird der gesamte Traffic blockiert, der nicht aus dem Bereich in der Zulassungsliste stammt.
  4. Verknüpfen Sie diese Richtlinie mit dem globalen externen Application Load Balancer oder dem Back-End-Dienst des klassischen Application Load Balancers.

Wenn Ihre Organisation einen Sicherheitsdrittanbieter zum Bereinigen von Traffic verwendet, können Sie die IP-Adresse des Sicherheitsanbieters auf eine Zulassungsliste setzen. So sorgen Sie dafür, dass nur bereinigter Traffic auf den globalen externen Application Load Balancer oder den klassischen Application Load Balancer und 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.

Load-Balancer-Zugriff mit einer Zulassungsliste einschränken, um den Traffic von einem Sicherheitsdrittanbieter einzuschränken
Load-Balancer-Zugriff mithilfe einer Zulassungsliste einschränken, um Traffic von einem Sicherheitsdrittanbieter einzuschränken (zum Vergrößern klicken).

Zugriff für Nutzer mit bestimmten IP-Adressen über Sperrlisten blockieren

Verwenden Sie Sperrlisten, um Sicherheitsrichtlinien für Google Cloud Armor zu erstellen, die Traffic von einer IP-Adresse oder einem CIDR-Bereich sperren. In der folgenden Abbildung enthält die Google 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.

Load-Balancer-Zugriff mit einer Sperrliste einschränken.
Load-Balancer-Zugriff mit einer Sperrliste einschränken (zum Vergrößern klicken).

Benutzerdefinierte Regeln, um basierend auf Parametern der Ebenen 3 bis 7 zu filtern

Verwenden Sie die Sprache für benutzerdefinierte Regeln für Google Cloud Armor, um einen oder mehrere Ausdrücke in der Abgleichsbedingung einer Regel zu definieren. Wenn Google Cloud Armor eine Anfrage erhält, wird die Anfrage anhand dieser Ausdrücke ausgewertet. Wenn eine Übereinstimmung vorliegt, wird die Aktion der Regel wirksam, indem der eingehende Traffic entweder abgelehnt oder zugelassen wird.

Die folgenden Beispiele sind Ausdrücke, die in der Google Cloud Armor-Erweiterung der Common Expression Language (CEL) geschrieben wurden. Weitere Informationen finden Sie in der Referenz zur Sprache für benutzerdefinierte Regeln.

Verwenden Sie zum Definieren von Ausdrücken in einer Regel das gcloud-Flag --expression oder die Google Cloud Console. Weitere Informationen finden Sie unter Sicherheitsrichtlinien, Regeln und Ausdrücke für Google Cloud Armor 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

Sie können Google Cloud Armor verwenden, um einen Cloud CDN-Ursprungsserver vor Angriffen auf die Anwendungsschicht (L7) wie vor SQL Injection (SQLi) und Cross-Site-Scripting (XSS) zu schützen. Inhalte in einem Cache sind statisch und stellen vermutlich kein Risiko in Form eines gezielten Angriffs aus dem Web dar. Der zugrunde liegende Inhaltsursprungsserver kann jedoch eine dynamische Anwendung mit bekannten oder potenziellen Sicherheitslücken bei Webanwendungen sein. Aufgrund Ihrer Sicherheits- oder Compliance-Anforderungen müssen Sie diese Risiken möglicherweise abwehren, um zu verhindern, dass der Ursprungsserver erfolgreich über Sicherheitslücken aus dem Internet angegriffen werden kann.

So wehren Sie die Risiken ab:

  1. Erstellen oder identifizieren Sie einen Back-End-Dienst mit aktiviertem CDN.
  2. Erstellen Sie eine Google Cloud Armor-Sicherheitsrichtlinie.
  3. Erstellen Sie in der Sicherheitsrichtlinie eine oder mehrere Regeln, um L7-Angriffe abzuwehren.
  4. Konfigurieren Sie eines der Ziele der Sicherheitsrichtlinie als den Back-End-Dienst, den Sie in Schritt 1 erstellt oder identifiziert haben.

Sie können auch vorkonfigurierte Regeln verwenden, um gängige Angriffe auf Anwendungsschicht zu erkennen und zu blockieren. Vorkonfigurierte Regeln sind vordefinierte Ausdruckssätze, die Sie einer Google Cloud Armor-Sicherheitsrichtlinie hinzufügen können. Verwenden Sie das gcloud-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.

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:

evaluatePreconfiguredExpr('xss-stable')

Im folgenden Beispiel wird eine vorkonfigurierte Regel verwendet, um SQLi-Angriffe (SQL Injection) abzuwehren:

evaluatePreconfiguredExpr('sqli-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') && evaluatePreconfiguredExpr('sqli-stable')

Verringerung der OWASP-Top-10-Risiken für Hybridarbeitslasten

Google 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.

Die vorkonfigurierten WAF-Regeln von Google Cloud Armor können einer Sicherheitsrichtlinie hinzugefügt werden, um unerwünschte Ebene-7-Anfragen mit SQLi- oder XSS-Versuchen zu erkennen und abzulehnen. Google Cloud Armor erkennt schädliche Anfragen und verwirft sie am Rand der Google-Infrastruktur. Die Anfragen werden nicht an den Back-End-Dienst weitergeleitet, unabhängig davon, wo der Back-End-Dienst bereitgestellt wird.

So schützen Sie eine nicht in Google Cloud gehostete Arbeitslast vor diesen Angriffen am Rand des Google-Netzwerks:

  1. Konfigurieren Sie einen globalen externen Application Load Balancer oder einen klassischen Application Load Balancer mit einem Back-End-Dienst, der eine Internet-NEG als Back-End hat.
  2. Erstellen Sie eine Google Cloud Armor-Sicherheitsrichtlinie.
  3. Fügen Sie der Richtlinie vorkonfigurierte SQLi- und XSS-Regeln hinzu.
  4. Hängen Sie die Sicherheitsrichtlinie an den Backend-Dienst an, den Sie in Schritt 1 erstellt haben.
  5. Sie können Google 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 Frontend für das Proxying, Caching und die Ebene-7-Filterung von Google Cloud Armor verwenden. Bei Verwendung von Internet-NEGs kann sich der Ursprungsserver lokal oder bei einem Infrastruktur-Drittanbieter befinden.

Google Cloud Armor und der Rest der Randinfrastruktur von Google wehren L3/L4-Angriffe ab, warnen vor verdächtigen Ebene-7-Aktivitäten und sind bereit, unerwünschte Ebene-7-Anfragen mit benutzerdefinierten Regeln abzulehnen. Google Cloud Armor-Logging und -Telemetrie für Cloud Logging, Cloud Monitoring und das Security Command Center bieten unabhängig davon, wo sie bereitgestellt werden, umsetzbare Informationen für geschützte Anwendungen.

So aktivieren Sie den Google Cloud Armor-Schutz für externe CDN-Ursprungsserver:

  1. Konfigurieren Sie einen globalen externen Application Load Balancer oder einen klassischen Application Load Balancer mit einem Back-End-Dienst, der eine Internet-NEG als Back-End hat.
  2. Aktivieren Sie Cloud CDN für diesen Backend-Dienst.
  3. Erstellen Sie eine Google Cloud Armor-Sicherheitsrichtlinie.
  4. Hängen Sie die Sicherheitsrichtlinie an den Backend-Dienst an, den Sie in Schritt 1 erstellt haben.
  5. Greifen Sie in Security Command Center, Cloud Logging und Cloud Monitoring auf Google 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

Abhängig von der Anwendungsarchitektur können Sie einen Back-End-Dienst so konfigurieren, dass Anfragen für verschiedene URLs, einschließlich im Cache speicherbarer und nicht speicherbarer Inhalte, verarbeitet werden. Erstellen Sie in solchen Bereitstellungsszenarien Sicherheitsrichtlinien für Google 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 oder fehlerhafter Client, obwohl der Inhalt effizient aus dem Cache bereitgestellt wird, eine große Anzahl von Anfragen generieren, die zu einem Cache-Fehler führen und erfordern, dass der zugrunde liegende Ursprungsserver den angeforderten Inhalt abruft oder generiert. Dies kann begrenzte Ressourcen stark belasten und sich negativ auf die Verfügbarkeit der Anwendung für alle Nutzer auswirken. Sie können eine Google Cloud Armor-Sicherheitsrichtlinie erstellen, die auf die Signatur aller Clients prüft, die das Problem verursachen, und die Anfragen ablehnt, bevor sie den Ursprungsserver erreichen und die Leistung beeinträchtigen.

Gehen Sie dazu so vor:

  1. Erstellen Sie eine Google Cloud Armor-Sicherheitsrichtlinie.

  2. Konfigurieren Sie eine Regel. Diese lehnt beispielsweise den Zugriff auf "/admin" ab:

    request.path.contains("/admin") && !inIpRange(origin.ip, '<allowed_ip_range>')

  3. Hängen Sie die Sicherheitsrichtlinie aus Schritt 1 an den Back-End-Dienst an, für den Cloud CDN aktiviert ist.

Nächste Schritte