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:

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

Google Cloud Armor wendet den Grenzwert der Ratenbegrenzung auf jedes verknüpfte Back-End an. Wenn Sie beispielsweise zwei Back-End-Dienste haben und eine Ratenbegrenzungsregel mit einem Grenzwert von 1.000 Anfragen pro Minute konfigurieren, kann jeder Back-End-Dienst 1.000 Anfragen pro Minute empfangen, bevor Google Cloud Armor die Regelaktion anwendet.

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: 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 ist standardmäßig ALL, wenn kein solcher Header vorhanden ist oder wenn Sie versuchen, diesen Schlüsseltyp mit einem externen Proxy-Network 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 IP-Adressen, die im HTTP-Header X-Forwarded-For angegeben ist. Als Schlüsseltyp wird standardmäßig „IP-Adresse“ verwendet, wenn kein solcher Header vorhanden ist, der Wert keine gültige IP-Adresse ist oder wenn Sie versuchen, diesen Schlüsseltyp mit einem externen Proxy-Network Load Balancer zu verwenden.
HTTP_COOKIE: Ein eindeutiger Schlüssel für jeden HTTP-Cookie-Wert, dessen Name konfiguriert ist. Der Schlüsselwert wird auf die ersten 128 Byte des Cookiewerts gekürzt. Wenn kein Cookie vorhanden ist oder Sie versuchen, diesen Schlüsseltyp mit einem externen Proxy-Network Load Balancer zu verwenden, ist der Schlüsseltyp standardmäßig auf ALLE eingestellt.
HTTP_PATH: Der URL-Pfad der HTTP-Anfrage. Der Schlüsselwert wird auf die ersten 128 Byte gekürzt.
SNI Die Servernamensangabe (Server Name Indication) in der TLS-Sitzung der HTTPS-Anfrage. Der Schlüsselwert wird auf die ersten 128 Byte gekürzt. Der Schlüsseltyp wird in einer HTTP-Sitzung standardmäßig auf ALL gesetzt.
REGION_CODE: Das Land oder die Region, von der die Anfrage stammt.
TLS_JA3_FINGERPRINT: JA3-TLS/SSL-Fingerabdruck, wenn der Client über HTTPS, HTTP/2 oder HTTP/3 eine Verbindung herstellt. Falls nicht verfügbar, wird standardmäßig der Schlüsseltyp ALL verwendet. Weitere Informationen zu JA3 finden Sie in der Referenz zur Regelsprache.
USER_IP: Die IP-Adresse des ursprünglichen Clients, die in den unter userIpRequestHeaders konfigurierten Headern enthalten ist und deren Wert von einem Upstream-Proxy ausgefüllt wird. Wenn keine userIpRequestHeaders-Konfiguration vorhanden ist oder eine IP-Adresse nicht daraus aufgelöst werden kann, wird der Schlüsseltyp standardmäßig auf IP gesetzt. Weitere Informationen finden Sie in der Referenz zur Regelsprache.

Sie können die vorherigen Schlüssel einzeln verwenden oder die Ratenbegrenzung basierend auf einer Kombination von bis zu drei Schlüsseln anwenden. Sie können mehrere HTTP-HEADER- oder HTTP-COOKIE-Schlüssel sowie jeweils nur einen der anderen Schlüsseltypen verwenden. Weitere Informationen finden Sie unter Ratenbegrenzung auf Basis mehrerer Schlüssel.

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 19, 30, 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 Schwellenwert pro Client erzwingen, um Clients, die das Limit überschreiten, vorübergehend zu sperren. Dazu wenden Sie die konfigurierte exceed_action für alle Anfragen vom Client in einem 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 19, 30, 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_threshold_count: Dies ist die Anzahl der Anfragen pro Client, bei denen Google Cloud Armor Anfragen sperrt. Wenn angegeben, wird der Schlüssel für die konfigurierte ban_duration_sec gesperrt, wenn die Anzahl der Anfragen, die rate_limit_threshold_count überschreiten, auch diesen ban_threshold_count überschreitet.
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 Backend-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_count verfolgen. In diesem Modus wird der Client nur dann für die konfigurierte ban_duration_sec gesperrt, wenn die Anfragerate den konfigurierten Wert für ban_threshold_count überschreitet. Wenn die Anfragerate den Wert ban_threshold_count nicht überschreitet, werden die Anfragen weiter auf rate_limit_threshold gedrosselt. Zum Zweck von ban_threshold_count wird die Gesamtzahl der Anfragen vom Client gezählt, die aus allen eingehenden Anfragen vor der Drosselung bestehen.

Standard-Sicherheitsrichtlinie für die Ratenbegrenzung

Wenn Sie eine Standard-Sicherheitsrichtlinie während der Erstellung des Load-Balancers konfigurieren, beträgt der Standardschwellenwert 500 Anfragen pro 1-Minuten-Intervall (rate_limit_threshold und interval_sec von 500 bzw. 60). Wenn Sie einen anderen Schwellenwert auswählen möchten, empfehlen wir die folgenden Schritte zur Feinabstimmung Ihrer Parameter:

Aktivieren Sie Cloud Logging und fragen Sie die maximale Anzahl von Anfragen ab, die pro IP-Adresse und pro Minute über einen Tag oder länger bei Ihrem durch Google Cloud Armor geschützten Back-End-Dienst eingegangen sind.

Angenommen, Sie glauben, dass 99 % des eingehenden Netzwerktraffics nicht von der Ratenbegrenzungsregel betroffen sein sollten. In diesem Szenario empfehlen wir, den Grenzwert für die Ratenbegrenzung auf das 99. Perzentil der maximalen Anzahl von Anfragen pro IP-Adresse und pro Minute der Verteilung festzulegen, die aus den Cloud Logging-Daten generiert wird.
Wenn Sie weiterhin feststellen, dass Standardregeln für die Ratenbegrenzung legitimen Traffic blockieren, führen Sie die folgenden zusätzlichen Schritte aus:
1. Aktivieren Sie das Caching (Cloud CDN oder Media CDN).
2. Erhöhen Sie das Drosselungszeitintervall (Anfragen, die innerhalb mehrerer Minuten statt innerhalb von 60 Sekunden empfangen wurden).
3. Sie können Clients sperren, um die Auswirkungen von Angriffen nach der ersten Wave weiter zu reduzieren. Mit der Aktion rate_based_ban von Google Cloud Armor können Sie dies erreichen, indem Sie alle Clients sperren, die die Limits innerhalb eines benutzerdefinierten Zeitfensters zu häufig überschreiten. Beispielsweise können Clients, die die Limits innerhalb einer Minute zehnmal überschreiten, für 15 Minuten gesperrt werden.

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

Ratenbegrenzung konfigurieren