Bot-Verwaltung für Google Cloud Armor

Google Cloud Armor und reCAPTCHA Enterprise bieten Tools, mit denen Sie eingehende Anfragen von automatisierten Clients auswerten und darauf reagieren können.

reCAPTCHA Enterprise verwendet erweiterte Risikoanalysetechniken, um zwischen menschlichen Nutzern und automatisierten Clients zu unterscheiden. reCAPTCHA Enterprise bewertet den Nutzer anhand der Konfiguration der reCAPTCHA-WAF-Websiteschlüssel. Anschließend wird ein verschlüsseltes Token mit Attributen ausgegeben, die das damit verbundene Risiko darstellen. Google Cloud Armor entschlüsselt dieses Token inline, ohne eine zusätzliche Anfrage/Antwort an den reCAPTCHA Enterprise-Dienst zu senden. Basierend auf den Tokenattributen können Sie mit Google Cloud Armor die eingehenden Anfragen zulassen, ablehnen, begrenzen oder weiterleiten. Weitere Informationen finden Sie in der Übersicht über die Google Cloud Armor- und reCAPTCHA Enterprise-Integration.

Die Bot-Verwaltung in Google Cloud Armor enthält folgende integrierte Funktionen.

  • Manuelle Identitätsbestätigung (Seite reCAPTCHA-Aufgaben)
    • Sie können nur Endnutzer zulassen, die die manuelle reCAPTCHA Enterprise-Aufgabe meistern, indem Sie Endnutzer zur reCAPTCHA Enterprise-Bewertung weiterleiten.
    • Wir empfehlen, dass Sie einen eigenen reCAPTCHA WAF-Websiteschlüssel erstellen und mit Ihrer Sicherheitsrichtlinie verknüpfen. Weitere Informationen finden Sie unter Implementierung einer reCAPTCHA-Herausforderung.
    • Sie müssen eine Sicherheitsrichtlinienregel konfigurieren, um eine Anfrage für die reCAPTCHA Enterprise-Bewertung weiterzuleiten.
  • Reibungslose reCAPTCHA Enterprise-Bewertung erzwingen
    • Sie können verschiedene Maßnahmen für eingehende Anfragen ergreifen, je nachdem, wie reCAPTCHA das Risiko bewertet, dass die Anfrage von einem Bot stammt. Sie können Sicherheitsrichtlinienregeln schreiben, um den Traffic anhand des Tokenscores und anderer Tokenattribute auszuwerten und zu filtern.
    • Die Bewertung der Google Cloud Armor-Sicherheitsrichtlinie erfolgt am Rand des Google-Netzwerks, sodass Ihre Back-Ends nicht an der Entschlüsselung des Tokens beteiligt sind.
    • Sie müssen zwischen reCAPTCHA-Aktions-Tokens oder Sitzungs-Tokens wählen und dann Ihren eigenen reCAPTCHA-WAF-Websiteschlüssel erstellen, bevor Sie reCAPTCHA Enterprise implementieren. Weitere Informationen finden Sie unter reCAPTCHA-Aktionstokens implementieren und reCAPTCHA-Sitzungstokens implementieren.
    • Sie müssen eine Sicherheitsrichtlinienregel konfigurieren, die reCAPTCHA Enterprise-Tokens auswertet.

Die Botverwaltung von Google Cloud Armor umfasst außerdem folgende Funktionen:

  • Weiterleiten (302)
    • Sie können Anfragen an Ihre konfigurierte alternative URL weiterleiten. Dazu konfigurieren Sie Google Cloud Armor so, dass eine HTTP 302-Antwort an den Client gesendet wird.
  • Anfrage gestalten
    • Sie können benutzerdefinierte Header in statische Anfragen und statische Werte in diese Header einfügen, bevor Sie Anfragen an Ihre Back-Ends weiterleiten.

Anwendungsfälle

In diesem Abschnitt wird beschrieben, wie Sie die Botverwaltungsfunktionen von Google Cloud Armor verwenden können, um das Botrisiko zu minimieren und den Zugriff von automatisierten Clients zu steuern.

Eine manuelle Identitätsbestätigung zur Unterscheidung zwischen berechtigten Nutzern und automatisierten Kunden nutzen

Sie können eine Anfrage an reCAPTCHA Enterprise weiterleiten, um den End-Client zu bewerten und bei Bedarf manuelle Identitätsbestätigungen ohne zusätzliche reCAPTCHA Enterprise-Implementierung bereitzustellen. Wenn menschliche Nutzer dieselbe Signatur (z. B. URL-Pfade oder andere L7-Signaturen) wie ein Bot oder ein missbräuchliches System verwenden, bietet diese Aktion eine Möglichkeit, um zu beweisen, dass sie ein Mensch sind. Nur Nutzer, die die Prüfung bestehen, können Zugriff auf Ihren Dienst erhalten.

Folgendes Diagramm zeigt, wie eine manuelle Herausforderung unterscheidet, ob eine Anfrage von einem Menschen oder einem automatisierten Client stammt:

Beispiel für die Weiterleitung zu reCAPTCHA
Beispiel für die Weiterleitung zu reCAPTCHA (zum Vergrößern klicken)

Angenommen, ein Nutzer Maya und ein Bot durchsuchen beide die Anmeldeseite (/login.html) auf Ihrer Website. Wenn Sie Zugriff auf Maya gewähren möchten, ohne Zugriff auf den Bot zu gewähren, können Sie eine Sicherheitsrichtlinienregel mit dem erweiterten Übereinstimmungsausdruck request.path.matches("/login.html") konfigurieren, mit einer redirect-Aktion vom TypGOOGLE_RECAPTCHA. Das End-to-End-Erlebnis sieht so aus:

  1. Ein Endnutzer besucht Ihre Website zum ersten Mal.
  2. Google Cloud Armor wertet die Anfrage aus und leitet sie an reCAPTCHA Enterprise weiter.
  3. reCAPTCHA Enterprise antwortet mit einer HTML-Seite, auf der das reCAPTCHA Enterprise-JavaScript eingebettet ist.
  4. Wenn die Antwort gerendert wird, wird das eingebettete JavaScript ausgeführt, um den Nutzer zu bewerten und bei Bedarf manuelle Identitätsbestätigungen bereitzustellen.
    • Wenn der Nutzer die Bewertung besteht, gibt reCAPTCHA Enterprise ein Ausnahme-Cookie aus, das vom Browser automatisch an jede nachfolgende Anfrage an dieselbe Website angehängt wird, bis das Cookie abläuft.
    • Andernfalls gibt reCAPTCHA Enterprise kein Ausnahme-Cookie aus.

In diesem Beispiel durchläuft nur Maya die reCAPTCHA Enterprise-Bewertung und erhält ein Ausnahme-Cookie, das Zugriff auf Ihre Website erhält.

Wenn Sie manuelle Herausforderungen verwenden, empfehlen wir, einen eigenen reCAPTCHA-WAF-Websiteschlüssel zu erstellen und der Sicherheitsrichtlinie zuzuordnen. Auf diese Weise können Sie reCAPTCHA Enterprise-Messwerte, die dem Websiteschlüssel zugeordnet sind, anzeigen und ein Sicherheitsmodell trainieren, das speziell für den Websiteschlüssel gilt. Weitere Informationen finden Sie unter Schlüssel für reCAPTCHA-WAF-Website erstellen.

Wenn Sie keinen Websiteschlüssel erstellen und verknüpfen, verwendet reCAPTCHA Enterprise während der Bewertung einen von Google verwalteten Websiteschlüssel. Sie können keine reCAPTCHA-Messwerte aufrufen, die mit Websiteschlüsseln verknüpft sind, die Ihnen nicht gehören, einschließlich von Google verwalteter Websiteschlüssel.

reCAPTCHA Enterprise-Prüfung erzwingen

Wenn ein reCAPTCHA Enterprise-Token mit einer eingehenden Anfrage verknüpft ist, wertet Google Cloud Armor die Anfrage aus und wendet die konfigurierte Aktion basierend auf den einzelnen Attributen im Token an.

reCAPTCHA Enterprise-Tokens

reCAPTCHA Enterprise gibt zwei Arten von Tokens aus: Aktions- und Sitzungstokens. Beide Tokentypen geben für jede Anfrage einen Score auf Basis der Interaktionen mit Ihrer Website zurück. Beide Tokentypen enthalten Attribute, einschließlich eines Scores, das das mit dem Nutzer verbundene Risiko darstellt.

Bevor Sie Regeln für Sicherheitsrichtlinien konfigurieren, müssen Sie festlegen, ob Aktionstokens, Sitzungstokens oder beides verwendet werden sollen. Wir empfehlen Ihnen, die Dokumentation zu reCAPTCHA Enterprise zu lesen, um Ihre Entscheidung zu treffen. Weitere Informationen finden Sie im Anwendungsfall für reCAPTCHA Enterprise.

Nachdem Sie ermittelt haben, welchen Tokentyp Sie nutzen möchten, implementieren Sie reCAPTCHA Enterprise für das Token, das mit einer Anfrage verknüpft werden soll. Informationen zum Implementieren von Tokens in reCAPTCHA Enterprise finden Sie unter reCAPTCHA Enterprise-Aktionstoken implementieren und reCAPTCHA Enterprise-Sitzungstoken implementieren.

Verwenden Sie schließlich die Sprache der Google Cloud Armor-Regeln, um Sicherheitsrichtlinienregeln zu konfigurieren und reCAPTCHA Enterprise-Tokens auszuwerten, die mit der Anfrage verknüpft sind.

Folgende Abbildung zeigt den Ablauf der reCAPTCHA Enterprise-Tokenerzwingung.

reCAPTCHA-Tokens erzwingen
Ablauf zum Erzwingen des reCAPTCHA-Tokens (zum Vergrößern anklicken)

Weiterleitung (302-Antwort)

Sie können mit einer URL-basierten Weiterleitungsaktion Anfragen extern an einen anderen Endpunkt weiterleiten. Dazu geben Sie ein Weiterleitungsziel in Form einer URL an. Google Cloud Armor leitet die Anfrage dann durch Senden einer HTTP 302-Antwort an den Client weiter.

Anfrage gestalten

Google Cloud Armor kann benutzerdefinierte Anfrageheader mit statischen benutzerdefinierten Werten einfügen, bevor die Anfragen an Ihre Anwendung weitergeleitet werden. Mit dieser Option können Sie verdächtige Anfragen zur alternativen nachgelagerten Verarbeitung taggen, wie die Bereitstellung eines Honeypots, oder zur zusätzlichen Analyse und Überwachung. Beachten Sie, dass dieser Aktionsparameter einer vorhandenen allow-Aktion hinzugefügt werden muss.

Wenn Sie außerdem einen Header-Namen auswählen, der bereits in der Anfrage vorhanden ist, einschließlich der Standard-HTTP-Header, wird der ursprüngliche Wert in diesem Header durch den benutzerdefinierten Wert überschrieben, der der Google Cloud Armor-Regel zur Verfügung gestellt wird.

Integration in Ratenbegrenzung

Google Cloud Armor-Regeln zur Ratenbegrenzung sind mit Bot-Verwaltungsfunktionen kompatibel. Sie können beispielsweise eine Anfrage für die reCAPTCHA Enterprise-Bewertung oder eine andere URL weiterleiten, wenn die Anzahl der Anfragen den konfigurierten Schwellenwert überschreitet. Darüber hinaus können Sie Clients für die Ratenbegrenzung basierend auf reCAPTCHA Enterprise-Ausnahme-Cookies oder -Tokens identifizieren, um Anfragen zu drosseln oder zu sperren, die dasselbe Cookie oder Token mit einer Ratenbegrenzung verwenden, die den Nutzer-konfigurierten Schwellenwert überschreiten.

Ratenbegrenzung für Cookies oder Tokens auf reCAPTCHA Enterprise-Ausnahme

Aus Sicherheitsgründen empfehlen wir, Ratenbegrenzungsregeln zu konfigurieren, um Tokenmissbrauch durch mehrere Verwendungen pro eindeutigem reCAPTCHA-Aktions-Token, Sitzungs-Token oder Ausnahme-Cookie zu verhindern. Die folgende Tabelle zeigt, wie Sie ein reCAPTCHA Enterprise-Ausnahme-Cookie oder -Token als Schlüssel in einer Ratenbegrenzungsregel identifizieren können.

Ressource enforce_on_key enforce_on_key_name
Ausnahme-Cookie HTTP-COOKIE recaptcha-ca-e
Aktionstoken HTTP-HEADER X-Recaptcha-Token
Sitzungstoken HTTP-COOKIE recaptcha-ca-t

Sie können Anfragen drosseln oder Clients sperren, die vom selben Ausnahme-Cookie oder Token abhängen und den konfigurierten Schwellenwert überschreiten. Weitere Informationen zu Ratenbegrenzungsparametern finden Sie unter Ratenbegrenzung anwenden.

Beispiele für die Ratenbegrenzung

Angenommen, Sie verwenden manuelle Herausforderungen nur für ausgewählte URLs (z. B. /login.html) auf Ihrer Website. Konfigurieren Sie dazu Sicherheitsrichtlinienregeln so:

  • Regel 1: Wenn mit der Anfrage ein gültiges Ausnahme-Cookie verknüpft ist und die Anzahl der Verwendungszwecke des Ausnahme-Cookies unter Ihrem definierten Schwellenwert liegt, lassen Sie die Anfrage zu.
  • Regel 2: Anfrage für eine reCAPTCHA Enterprise-Bewertung weiterleiten.
Grafik: Beispiel für eine reCAPTCHA Enterprise-Weiterleitung.
Manuelle Herausforderungen erzwingen (zum Vergrößern anklicken)

Zweitens: Sie verwenden auf Ihrer Website nur Aktions- und/oder Sitzungstokens. Sie können beispielsweise Aktionstokens verwenden, um wichtige Nutzeraktionen wie /login.html zu schützen. Führen Sie dazu auf der Grundlage des Scores aus dem Aktionstoken folgende Aktionen aus:

  • Regel 1: Wenn der Score des Aktionstokens höher ist als ein vordefinierter Schwellenwert (z. B. 0.8), wird die Anfrage zugelassen, wenn die Anzahl der Verwendungen für das Aktionstoken unter Ihrem definierten Wert liegt.
  • Regel 2: Anfrage ablehnen.
Beispiel für eine reCAPTCHA Enterprise-Aktion.
Erzwingen der Bewertung von reCAPTCHA Enterprise-Aktionstoken (zum Vergrößern klicken)
)

Sie können ähnliche Sicherheitsrichtlinienregeln konfigurieren, um die reCAPTCHA Enterprise-Sitzungstoken-Bewertung zu erzwingen.

Nehmen wir nun an, Sie kombinieren Aktions- oder Sitzungstokens mit manuellen Herausforderungen für ausgewählte URLs (z. B. /login.html) auf Ihrer Website und möchten Aktionen basierend auf dem Ergebnis des Aktionstoken ausführen. Außerdem möchten Sie dem Nutzer eine zweite Möglichkeit bieten, Aufgaben zu lösen, wenn der Scoreö nicht zufriedenstellend ist. Konfigurieren Sie dazu die Sicherheitsrichtlinienregeln so:

  • Regel 1: Wenn der Score des Aktionstokens höher ist als ein vordefinierter Schwellenwert (z. B. 0.8), wird die Anfrage zugelassen, wenn die Anzahl der Verwendungen für das Aktionstoken unter Ihrem definierten Wert liegt.
  • Regeln 2 und 3: Wenn der Score des Aktionstokens höher ist als ein anderer vordefinierter Schwellenwert (z. B. 0.5), leiten Sie die Anfrage für die reCAPTCHA Enterprise-Bewertung weiter, es sei denn, es gibt ein gültiges Ausnahme-Cookie. Die Anfrage wird angehängt und die Anzahl der Verwendungszwecke des Ausnahme-Cookies liegt unter dem definierten Schwellenwert.
  • Regel 4: Anfrage ablehnen.
Grafik: Beispiel für reCAPTCHA Enterprise-Aktion und -Weiterleitung.
Erzwingen Sie die reCAPTCHA Enterprise-Aktionstoken-Bewertung mit manuellen Aufgaben (zum Vergrößern klicken)

Sie können ähnliche Sicherheitsrichtlinienregeln konfigurieren, um die reCAPTCHA Enterprise-Sitzungstoken-Bewertung mit manuellen Herausforderungen zu erzwingen.

Wenn Sie die Ratenbegrenzungsregeln nicht wie oben konfigurieren, legt Google Cloud Armor kein Limit für die Anzahl der Verwendungen für jedes reCAPTCHA-Ausnahme-Cookie, Aktions-Token und Sitzungs-Token fest. Für Aktionstokens empfehlen wir die Verwendung eines niedrigen Schwellenwerts (z. B. 1) und eines hohen Zeitintervalls (z. B. 30 Minuten, da Aktionstokens 30 Minuten lang gültig sind). Wir empfehlen Ihnen, den Schwellenwert anhand Ihrer Trafficstatistiken abzuleiten.

Beschränkungen

  • Die Botverwaltung von Google Cloud Armor unterstützt den globalen Modus für den externen HTTP(S)-Load-Balancer (Vorschau) nicht. Wenn Sie die Bot-Verwaltung mit einem HTTP(S)-Load-Balancer konfigurieren möchten, verwenden Sie den globalen externen HTTP(S)-Load-Balancer (klassisch). Weitere Informationen finden Sie unter Betriebsmodi.

Nächste Schritte