Ratenbegrenzung – Übersicht

Google Cloud Armor bietet Funktionen zum Schutz Ihrer Google Cloud-Anwendungen vor einer Vielzahl von Ebene-3- und Ebene-7-Angriffen. Mithilfe von ratenbasierten Regeln können Sie Ihre Anwendungen vor einer zu großen Anzahl an Anfragen schützen, die Ihre Instanzen überlasten und den Zugriff für legitime Nutzer blockieren würden.

Mit der Ratenbegrenzung ist Folgendes möglich:

  • Sie verhindert, dass für einen bestimmten Client die Anwendungsressourcen aufgebraucht werden.
  • Sie schützt Ihre Anwendungsinstanzen vor unregelmäßigen und unvorhersehbaren Spitzen von Clientanfragen.

Darüber hinaus können Sie damit, wenn eine Ressource ein hohes Trafficvolumen von einer kleinen Anzahl an Clients bewältigen muss, verhindern, dass andere Clients von hohen Trafficspitzen dieser kleinen Anzahl an Clients betroffen sind. Ihre Ressourcen können so beliebig viele Anfragen bewältigen.

Google Cloud Armor bietet zwei Arten von ratenbasierten Regeln:

  1. Drosselung: Sie können damit ein maximales Anfragelimit pro Client oder für alle Clients erzwingen. Dazu drosseln Sie einzelne Clients auf einen vom Nutzer konfigurierten Grenzwert.
  2. Ratenbasierte Sperre: Sie können damit für Anfragen, die einer clientspezifischen Regel entsprechen, Ratenbegrenzungen festlegen und diese Clients dann für einen bestimmten konfigurierten Zeitraum vorübergehend sperren, wenn sie einen vom Nutzer konfigurierten Grenzwert überschreiten.

Die Auswirkungen der Ratenbegrenzungsregeln in einer Sicherheitsrichtlinie lassen sich in der Vorschau prüfen. Dazu rufen Sie den Vorschaumodus auf und werten die Anfragelogs aus.

Clients für die Ratenbegrenzung ermitteln

Google Cloud Armor ermittelt einzelne Clients für die Ratenbegrenzung mithilfe der folgenden Schlüsseltypen zum Aggregieren von Anfragen und zum Erzwingen von Ratenbegrenzungen:

  • ALL: Ein einzelner Schlüssel für alle Clients, deren Anfragen die Bedingung der Regel erfüllen.
  • IP: Dies ist ein einzelner Schlüssel für jede Quell-IP-Adresse des Clients, deren Anfragen die Bedingung für den Regelabgleich erfüllen.
  • HTTP-HEADER: Dies ist ein eindeutiger Schlüssel für jeden eindeutigen HTTP-Header-Wert, dessen Name konfiguriert ist. Der Schlüsselwert wird auf die ersten 128 Byte des Headerwerts gekürzt. Der Schlüsseltyp wird standardmäßig auf ALL gesetzt, wenn kein solcher Header vorhanden ist oder wenn Sie versuchen, diesen Schlüsseltyp mit einem TCP-Proxy- oder SSL-Proxy-Load-Balancer zu verwenden.
  • XFF-IP: Ein eindeutiger Schlüssel für jede ursprüngliche Quell-IP-Adresse des Clients, d. h. die erste IP-Adresse in der Liste der im HTTP-Header X-Forwarded-For angegebenen IP-Adressen. Der Schlüsseltyp ist standardmäßig die IP-Adresse, wenn kein solcher Header vorhanden ist, wenn der Wert keine gültige IP-Adresse ist oder wenn Sie versuchen, diesen Schlüsseltyp mit einem TCP-Proxy-Load-Balancer oder SSL-Proxy-Load-Balancer zu verwenden.
  • HTTP-COOKIE: Ein eindeutiger Schlüssel für jeden HTTP-Cookiewert, dessen Name konfiguriert ist. Der Schlüsselwert wird auf die ersten 128 Byte des Cookiewerts gekürzt. Der Schlüsseltyp wird standardmäßig auf ALL gesetzt, wenn kein solcher Cookie vorhanden ist oder wenn Sie versuchen, diesen Schlüsseltyp mit einem TCP-Proxy- oder SSL-Proxy-Load-Balancer zu verwenden.

Traffic drosseln

Mit der Aktion throttle in einer Regel können Sie pro Client einen Anfragegrenzwert erzwingen, um Back-End-Dienste zu schützen. Diese Regel erzwingt den Grenzwert, um den Traffic von allen Clients zu begrenzen, die die Bedingungen in der Regel erfüllen. Als Grenzwert wird eine bestimmte Anzahl an Anfragen in einem festgelegten Zeitintervall festgelegt.

Beispielsweise können Sie den Anfragegrenzwert auf 2.000 Anfragen innerhalb von 1.200 Sekunden (20 Minuten) festlegen. Wenn ein Client dann innerhalb von 1.200 Sekunden 2.500 Anfragen sendet, werden etwa 20 % des Clienttraffics gedrosselt, bis das zulässige Anfragevolumen den konfigurierten Grenzwert erreicht oder übersteigt.

Mit den folgenden Parametern steuern Sie die Aktion:

  • rate_limit_threshold: Die Anzahl der Anfragen pro Client, die innerhalb eines bestimmten Zeitintervalls zulässig sind. Der Wert muss zwischen 1 und dem maximalen Wert 10.000 liegen.
    • interval_sec: Die Anzahl der Sekunden im Zeitintervall. Der Wert muss 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 oder 3600 Sekunden sein.
  • exceed_action: Wenn eine Anfrage den rate_limit_threshold überschreitet, wendet Google Cloud Armor den konfigurierten exceed_action an. Folgende Werte sind für exceed_action möglich:
    • deny(status): Die Anfrage wird abgelehnt und der angegebene Fehlercode wird zurückgegeben (gültige Werte sind 403, 404, 429 und 502). Wir empfehlen die Verwendung des Antwortcodes 429 (Too Many Requests).
    • redirect: Die Anfrage wird entweder für die reCAPTCHA Enterprise-Prüfung oder anhand des Parameters exceed_redirect_options an eine andere URL weitergeleitet.
  • exceed_redirect_options: Wenn die exceed_action den Wert redirect hat, geben Sie mit diesem Parameter die Weiterleitungsaktion an:
    • type: Geben Sie für die Weiterleitungsaktion entweder GOOGLE_RECAPTCHA oder EXTERNAL_302 ein.
    • target: URL-Ziel für die Weiterleitungsaktion. Gilt nur, wenn der type EXTERNAL_302 ist.
  • conform_action: Dies ist die Aktion, die ausgeführt wird, wenn die Anzahl der Anfragen unter dem rate_limit_threshold liegt. Dies ist immer eine allow-Aktion.

Wenn die Trafficrate eines Clients den rate_limit_threshold nicht überschreitet, folgen Anfragen der conform-action, die immer eine allow-Aktion ist. Die Anfrage wird über die Sicherheitsrichtlinie zugelassen und darf ihr Ziel erreichen. Wenn die Trafficrate eines Clients den angegebenen rate_limit_threshold überschreitet, wendet Google Cloud Armor für Anfragen, die den Grenzwertintervall überschreiten die exceed_action an, die entweder deny oder redirect sein kann.

Clients anhand von Anfrageraten sperren

Mit der Aktion rate_based_ban in einer Regel können Sie einen Grenzwert pro Client durchsetzen, um Clients, die das Limit überschreiten, vorübergehend zu sperren. Wenden Sie dazu die konfigurierte exceed_action für alle Anfragen des Clients für einen konfigurierbaren Zeitraum an. Als Grenzwert wird eine bestimmte Anzahl an Anfragen in einem festgelegten Zeitintervall festgelegt. Sie können Traffic für einen vom Nutzer konfigurierten Zeitraum ('ban_duration_sec') vorübergehend sperren, sofern der Traffic der angegebenen Übereinstimmungsbedingung entspricht und den konfigurierten Grenzwert überschreitet.

Beispielsweise können Sie den Anfragegrenzwert auf 2.000 Anfragen innerhalb von 1.200 Sekunden (20 Minuten) festlegen. Wenn ein Client innerhalb von 1.200 Sekunden 2.500 Anfragen sendet, wendet Google Cloud Armor die exceed_action auf den Traffic dieses Clients an, der den Grenzwert von 2.000 Anfragen überschreitet, bis die vollen 1.200 Sekunden verstrichen sind und für eine zusätzliche Anzahl von Sekunden, die Sie als Sperrzeit festlegen. Wenn für die Dauer der Sperre der Wert 3600 festgelegt ist, wird der Traffic vom Client beispielsweise für 3.600 Sekunden (eine Stunde) nach Ablauf des Grenzwertintervalls gesperrt.

Die folgenden Parameter steuern die Aktion einer rate_based_ban-Regel:

  • rate_limit_threshold: Die Anzahl der Anfragen pro Client, die innerhalb eines bestimmten Zeitintervalls zulässig sind. Der Mindestwert beträgt 1 Anfrage und der Höchstwert 10.000 Anfragen.
    • interval_sec: Die Anzahl der Sekunden im Zeitintervall. Der Wert muss 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 oder 3600 Sekunden sein.
  • exceed_action: Wenn eine Anfrage den rate_limit_threshold überschreitet, wendet Google Cloud Armor den konfigurierten exceed_action an. Folgende Werte sind für exceed_action möglich:
    • deny(status): Die Anfrage wird abgelehnt und der angegebene Fehlercode wird zurückgegeben. Gültige Werte für den Fehlercode sind 403, 404, 429 und 502. Wir empfehlen die Verwendung des Antwortcodes 429 (Too Many Requests).
    • redirect: Die Anfrage wird entweder für die reCAPTCHA Enterprise-Prüfung oder anhand des Parameters exceed_redirect_options an eine andere URL weitergeleitet.
  • exceed_redirect_options: Wenn die exceed_action den Wert redirect hat, geben Sie mit diesem Parameter die Weiterleitungsaktion an:
    • type: Geben Sie für die Weiterleitungsaktion entweder GOOGLE_RECAPTCHA oder EXTERNAL_302 ein.
    • target: URL-Ziel für die Weiterleitungsaktion. Gilt nur, wenn der type EXTERNAL_302 ist.
  • conform_action: Dies ist die Aktion, die ausgeführt wird, wenn die Anzahl der Anfragen unter dem rate_limit_threshold liegt. Dies ist immer eine allow-Aktion.
  • ban_duration_sec: Dies ist die zusätzliche Anzahl an Sekunden, für die ein Client nach Ablauf des Zeitraums von interval_sec gesperrt wird. Der Wert muss 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 oder 3600 Sekunden sein.

Wenn die Anfragerate eines Clients unter dem Grenzwert der Ratenbegrenzung liegt, kann die Anfrage sofort an den Back-End-Dienst weitergeleitet werden. Wenn die Trafficrate eines Clients den angegebenen rate_limit_threshold überschreitet, wendet Google Cloud Armor die exceed_action auf alle eingehenden Anfragen des Clients für den Rest des Grenzwertintervalls und für die nächsten ban-duration_sec Sekunden an, unabhängig davon, ob der Grenzwert überschritten wird oder nicht.

Mit dieser Konfiguration besteht die Möglichkeit, dass Begrüßungsclients zufällig gesperrt weren, die nur gelegentlich die zulässige Anfragerate überschreiten. Um dies zu verhindern und um nur Clients zu sperren, die die Anfragerate häufig überschreiten, können Sie optional die gesamten Clientanfragen anhand des zusätzlichen, vorzugsweise größeren Grenzwerts ban_threshold verfolgen. In diesem Modus wird der Client nur dann für die konfigurierten ban_duration Sekunden gesperrt, wenn die Anfragerate den konfigurierten Wert für ban-threshold überschreitet. Wenn die Anforderungsrate ban-threshold nicht überschreitet, werden die Anfragen weiter auf rate_limit_threshold gedrosselt. Für ban_threshold wird die Gesamtzahl der Anfragen vom Client gezählt. Diese ergibt sich aus allen eingehenden Anfragen vor der Drosselung.

Erzwingung von Schwellenwerten

Die konfigurierten Grenzwerte für Drosselung und ratenbasierte Sperren werden separat in jeder Google Cloud-Region erzwungen, in der Ihre HTTP(S)-Back-End-Dienste bereitgestellt sind. Wenn Ihr Dienst beispielsweise in zwei Regionen bereitgestellt wird, begrenzt jede der beiden Regionen die Rate für alle Schlüssel auf den konfigurierten Grenzwert. Daher kann Ihr Back-End-Dienst ein regionsübergreifendes, aggregiertes Trafficvolumen erhalten, das doppelt so hoch wie der konfigurierte Grenzwert ist. Wenn der konfigurierte Grenzwert auf 5.000 Anfragen festgelegt ist, erhält der Back-End-Dienst möglicherweise 5.000 Anfragen aus einer Region und 5.000 Anfragen aus der zweiten Region.

Für die IP-Adresse des Schlüsseltyps kann jedoch davon ausgegangen werden, dass Traffic von derselben Client-IP-Adresse an die Region weitergeleitet wird, die Ihrer Region am nächsten liegt. In diesem Fall kann die Ratenbegrenzung auf der Ebene des Back-End-Dienstes erzwungen werden, unabhängig von den Regionen, in denen der Dienst bereitgestellt wird.

Beachten Sie, dass die erzwungenen Ratenbegrenzungen ungefähre Werte sind und im Vergleich mit den konfigurierten Grenzwerten möglicherweise nicht genau sind. Außerdem kann es in seltenen Fällen aufgrund des internen Routingverhaltens vorkommen, dass die Ratenbegrenzung in mehr Regionen als in den Regionen, in denen Sie Bereitstellungen vorgenommen haben, erzwungen wird. Dies hat Einfluss auf die Genauigkeit der Begrenzung. Deshalb empfehlen wir, die Ratenbegrenzung nur zur Minderung des Missbrauchsrisikos oder zur Aufrechterhaltung der Anwendungs- und Dienstverfügbarkeit zu nutzen, jedoch nicht zur Erzwingung strenger Kontingent- oder Lizenzanforderungen.

Logging

Cloud Logging erfasst den Namen der Sicherheitsrichtlinie, die Priorität der Ratenbegrenzungsregel zum Abgleich, die Regel-ID, die zugehörige Aktion und weitere Informationen in Ihren Anfragelogs. Weitere Informationen zum Logging finden Sie unter Anfrage-Logging verwenden.

Einbindung in reCAPTCHA Enterprise

Sie können die Ratenbegrenzung auf einige reCAPTCHA Enterprise-Ressourcen anwenden, um den Missbrauch von Tokens zu verhindern und die Wiederverwendung von Tokens zu begrenzen. Zu diesen Ressourcen gehören Aktionstokens, Sitzungstokens und Ausnahme-Cookies. Weitere Informationen zur Verwendung der Ratenbegrenzung mit reCAPTCHA Enterprise finden Sie in der Übersicht zur Bot-Verwaltung.

Nächste Schritte