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: Dies ist der 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 einzelner Schlüssel für jeden eindeutigen HTTP-Header-Wert, dessen Name konfiguriert ist.
  • XFF-IP: Dies ist ein einzelner Schlüssel für jede ursprüngliche Quell-IP-Adresse des Clients, wie in X-Forwarded-Header angegeben.

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 abgelehnt, 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 Mindestwert ist 10 und der maximale Wert 10.000.
    • 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 Wert für rate_limit_threshold überschreitet, lehnt Google Cloud Armor die Anfrage ab und gibt den festgelegten HTTP-Antwortcode zurück. Für throttle-Regeln empfehlen wir die Verwendung des Antwortcodes 429 (zu viele Anfragen).
  • conform_action: Dies ist immer eine allow-Aktion. Diese Aktion wird ausgeführt, wenn die Anzahl der Anfragen unter dem Wert für rate_limit_threshold liegt.

Wenn die Trafficrate eines Clients den Wert von rate_limit_threshold nicht überschreitet, folgen Anfragen der conform-action, die immer allow ist. Die Anfrage wird sofort an den Back-End-Dienst gesendet. Wenn die Trafficrate eines Clients den angegebenen Wert für rate_limit_threshold übersteigt, werden Anfragen, die das Limit überschreiten, für den Rest des Grenzwertintervalls blockiert. Der Fehlercode für das Ablehnen wird im Parameter exceed-action festgelegt.

Clients anhand von Anfrageraten sperren

Mit der Aktion rate_based_ban in einer Regel können Sie einen Grenzwert pro Client erzwingen, um Back-End-Dienste zu schützen und um Clients, die das Limit überschreiten, vorübergehend zu sperren. Dabei werden alle Anfragen vom Client für einen konfigurierbaren Zeitraum abgelehnt. Als Grenzwert wird eine bestimmte Anzahl an Anfragen in einem festgelegten Zeitintervall festgelegt. Sie können Traffic vorübergehend sperren, der die angegebene Bedingung erfüllt 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, wird der Traffic von diesem Client blockiert, wenn die Grenze von 2.000 Anfragen überschritten wird. Dies gilt solange, bis die 1.200 Sekunden und zusätzliche Sekunden, die Sie als Dauer der Sperrung festgelegt haben, verstrichen sind. 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 ist 10 und der maximale Wert 10.000.
    • 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: Dies ist immer eine deny-Aktion. Wenn die Trafficrate eines Clients den angegebenen Wert von rate_limit_threshold überschreitet, wird der Client für den Rest des Grenzwertintervalls und für die Anzahl der Sekunden, die für ban-duration festgelegt sind, gesperrt, d. h. alle eingehenden Anfragen werden abgelehnt.
  • conform_action: Dies ist immer eine allow-Aktion. Diese Aktion wird ausgeführt, wenn die Anzahl der Anfragen unter dem Wert für rate_limit_threshold liegt.
  • 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 festgelegten Wert für rate_limit_threshold überschreitet, wird der Client für den Rest des Grenzwertintervalls und für die nächsten ban-duration_sec Sekunden gesperrt, d. h. alle eingehenden Anfragen werden abgelehnt, unabhängig davon, ob der Grenzwert überschritten wird oder nicht. Der Fehlercode für die Ablehnung wird von der konfigurierten exceed- action übernommen.

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.

Nächste Schritte