Übersicht über die Ratenbegrenzung für Dienste

Mit Richtlinien zur Ratenbegrenzung für Dienste können Sie die Verfügbarkeit von Diensten für vertrauenswürdige Clients aufrechterhalten, die möglicherweise eine übermäßige Menge an Ressourcen verbrauchen. Die Richtlinien erreichen dies, indem sie bei Dienstüberlastungen den wichtigen Client-Traffic priorisieren und Clients drosseln, die vordefinierte Grenzwerte überschreiten.

Sie können Richtlinien zur Ratenbegrenzung für Dienste mit anderen Arten der Ratenbegrenzung kombinieren, z. B. mit Cloud Armor-Sicherheitsrichtlinien, die nicht vertrauenswürdige Clients explizit sperren, um Missbrauch zu verhindern. Weitere Informationen zu Sicherheits richtlinien finden Sie unter der Übersicht über Sicherheitsrichtlinien und der Übersicht über die Ratenbegrenzung von Cloud Armor.

Sie hängen Richtlinien zur Ratenbegrenzung für Dienste an die Weiterleitungsregeln unterstützter Load Balancer oder an Secure Web Proxy-Gatewayressourcen an. Weitere Informationen zur Verwendung von Richtlinien zur Ratenbegrenzung für Dienste mit Secure Web Proxy-Instanzen finden Sie unter Richtlinien zur Ratenbegrenzung für Dienste konfigurieren.

Unterstützte Ziele

Richtlinien zur Ratenbegrenzung für Dienste sind für die folgenden Ziele verfügbar:

  • Regionale interne Application Load Balancer
  • Sicherer Web-Proxy

Reihenfolge der Anfragenfilterung

Richtlinien zur Ratenbegrenzung für Dienste sind nur eine Art von Filter, die auf Anfragen angewendet wird. Das folgende Diagramm zeigt die Reihenfolge, in der die Filter angewendet werden:

Reihenfolge der Auswertung für die Filterung von Anfragen.
Reihenfolge der Auswertung für die Anfragenfilterung (zum Vergrößern klicken)

Regeln

Jede Richtlinie zur Ratenbegrenzung für Dienste enthält eine Liste von HTTP-Regeln. Jede Regel gibt eine Übereinstimmungsbedingung und eine Reihe von Aktionen zur Ratenbegrenzung an. Wenn eine Anfrage die Übereinstimmungsbedingungen der Regel erfüllt, wird sie anhand eines oder mehrerer Ihrer konfigurierten Ratenbegrenzungskontingente ausgewertet.

Übereinstimmungsbedingungen

Die Übereinstimmungsbedingungen und ihre Attribute sind wie folgt. Jedes Attribut kann mit einem genauen String, einem Präfix, einem Suffix oder einem Teilstring übereinstimmen:

  • Source: die Quelle der Anfrage.
    • principal: eine Liste von Identitäten, die aus dem Zertifikat des Clients abgeleitet wurden. Eine Übereinstimmung liegt vor, wenn ein Prinzipal mit der Regel übereinstimmt. Weitere Informationen zur Verwendung von Prinzipalen für die Ratenbegrenzung für Dienste finden Sie unter Prinzipale für die Ratenbegrenzung für Dienste verwenden.
  • Destination: das Ziel der Anfrage. Wenn Sie mehrere Attribute angeben, werden sie mit einem logischen AND-Operator kombiniert.
    • header_set: eine Liste von HTTP-Headern. Eine Übereinstimmung liegt vor, wenn alle Header in header_set mit der Regel übereinstimmen.
    • hosts: eine Liste von HTTP-Hosts. Eine Übereinstimmung liegt vor, wenn die Anfrage an einen der angegebenen Hosts in der Liste gesendet wird.
    • paths: eine Liste von URL-Pfaden. Eine Übereinstimmung liegt vor, wenn die Anfrage einen der angegebenen Pfade in der Liste verwendet.
    • methods: eine Liste gültiger HTTP-Methoden (z. B. GET oder POST). Eine Übereinstimmung liegt vor, wenn die Anfrage eine der angegebenen Methoden in der Liste verwendet.

Die Attribute für Quelle und Ziel werden mit einem logischen AND-Operator kombiniert, um zu ermitteln, ob eine Regel mit einer Anfrage übereinstimmt. Wenn Sie also eine Quelle und ein Ziel angeben, muss eine Anfrage mit beiden übereinstimmen, um die Übereinstimmungsbedingungen zu erfüllen. Außerdem stimmen leere Regeln mit allen Anfragen überein.

Regelauswertungsreihenfolge

Regeln werden in der Reihenfolge ausgewertet, in der sie in der Richtlinie definiert sind. Die erste Regel, die mit einer Anfrage übereinstimmt, wendet ihre Aktionen zur Ratenbegrenzung auf die Anfrage an. Weitere Regeln werden nicht ausgewertet. Wenn eine Regel mehrere Aktionen zur Ratenbegrenzung hat und einer dieser Aktionen den konfigurierten Grenzwert überschreitet, wird die Anfrage gedrosselt.

Ratenbegrenzungskontingente

Sie konfigurieren ein oder mehrere Ratenbegrenzungskontingente, die jeweils einen oder mehrere Ratenbegrenzungsschlüssel haben. Wenn eine Anfrage die Übereinstimmungsbedingungen einer Regel erfüllt, wird sie anhand eines oder mehrerer Ihrer konfigurierten Ratenbegrenzungskontingente ausgewertet. Anschließend wendet das Kontingent seinen konfigurierten Ratenbegrenzungsschlüssel an, um einzelne Clients zu identifizieren und das Limit durchzusetzen.

Neben Schlüsseltypen können Sie die folgenden Kontingentattribute konfigurieren:

  • Testlauf: Im Testlaufmodus wird die Regel ausgewertet und die Übereinstimmungen werden erfasst, aber die Regelaktion wird nicht angewendet. So können Sie Ihre Regeln zur Ratenbegrenzung testen, ohne Clients zu drosseln oder den Produktions-Traffic zu beeinträchtigen.
  • Nutzerüberschreibungen: Sie können die Standardlimits für Anfragen für bestimmte Schlüsselwerte überschreiben. Wenn Sie beispielsweise ein Kontingent mit einem Standardlimit von 100 Anfragen pro Minute und Client haben und dieses Kontingent den Schlüsseltyp SOURCE_IP verwendet, können Sie das Limit für eine bestimmte IP-Adresse überschreiben und stattdessen ein Limit von 200 Anfragen pro Minute festlegen.

Schlüsseltypen

Sie können einzelne Clients für die Ratenbegrenzung identifizieren, indem Sie die folgenden Schlüsseltypen verwenden, um Anfragen zu aggregieren und Ratenbegrenzungen durchzusetzen:

  • ALL: Ein einzelner Schlüssel für alle Anfragen, die die Übereinstimmungsbedingung der Regel erfüllen.
  • SOURCE_IP: Ein eindeutiger Schlüssel für jede Client-IP-Adresse, deren Anfragen die Übereinstimmungsbedingung der Regel 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. Wenn kein solcher Header vorhanden ist, wird der Schlüsseltyp standardmäßig auf ALLE gesetzt.
  • HTTP_PATH: Der URL-Pfad der HTTP-Anfrage. Der Schlüsselwert wird auf die ersten 128 Byte gekürzt.
  • PRINCIPAL: Ein String, der eine Identität darstellt, die aus dem Zertifikat des Clients abgeleitet wurde. Der einzige unterstützte Prinzipaltyp ist CLIENT_CERT_COMMON_NAME.

Sie können in jeder Regel einen oder mehrere Schlüsseltypen angeben. Wenn Sie mehrere Schlüsseltypen angeben, wird die gesamte Kombination von Schlüsseln für jeden Client als eindeutiger Schlüssel verwendet. Sie können beispielsweise eine Kombination aus SOURCE_IP und HTTP_PATH verwenden, um Ratenbegrenzungen für die Häufigkeit festzulegen, mit der eine bestimmte IP-Adresse auf einen bestimmten Endpunkt zugreifen kann.

Prinzipale für die Ratenbegrenzung für Dienste verwenden

Um die Quelle des Traffics mit hoher Granularität zu identifizieren, können Sie Richtlinien zur Ratenbegrenzung für Dienste basierend auf Identitäten konfigurieren, die aus dem Zertifikat eines Clients abgeleitet wurden. Für diese Methode muss mTLS im Frontend auf dem Load Balancer aktiviert sein. Das Attribut „Common Name des Clientzertifikats“ (CLIENT_CERT_COMMON_NAME) wird als Prinzipal-Selektor für die Identifizierung verwendet.

Wenn kein Prinzipal-Selektor für die Identifizierung angegeben ist, wird CLIENT_CERT_URI_SAN als Standard-Prinzipal-Selektor verwendet. Das bedeutet, dass die URI-SANs des Clientzertifikats bei Entscheidungen zur Ratenbegrenzung ausgewertet werden.

Damit die prinzipalbasierte Ratenbegrenzung funktioniert, müssen die folgenden Bedingungen erfüllt sein:

  • mTLS im Frontend muss aktiviert sein. Wenn mTLS im Frontend nicht aktiviert ist, legt der Client kein Zertifikat vor. Daher finden prinzipalbasierte Regeln in der Richtlinie zur Ratenbegrenzung für Dienste keine Zertifikatsinformationen, die ausgewertet werden können. Eine Regel, die CLIENT_CERT_URI_SAN prüft, sieht beispielsweise einen leeren Wert.

  • Es muss ein gültiges Clientzertifikat vorhanden sein. Auch wenn mTLS aktiviert ist, wird ein Clientzertifikat nicht für die Ratenbegrenzung verwendet, wenn die Verbindung mit einem fehlenden oder ungültigen Zertifikat hergestellt wurde. Dieses Szenario tritt ein wenn der mTLS-Clientvalidierungsmodus auf den permissiven Modus gesetzt ist ALLOW_INVALID_OR_MISSING_CLIENT_CERT. Auch in diesem Fall finden prinzipalbasierte Regeln in der Richtlinie zur Ratenbegrenzung für Dienste keine Zertifikatsinformationen, die ausgewertet werden können. Eine Regel, die CLIENT_CERT_URI_SAN prüft, sieht beispielsweise einen leeren Wert.

Auswirkungen von Größenbeschränkungen für Attribute

Entscheidungen zur Ratenbegrenzung sind von der Größe der Attribute des Clientzertifikats abhängig. Eine Anfrage wird abgelehnt , wenn ein Attribut die Größenbeschränkung überschreitet und die Richtlinie so konfiguriert ist, dass dieses Attribut validiert wird.

Eine Ablehnung kann auftreten, wenn die Richtlinie anhand von CLIENT_CERT_COMMON_NAME validiert wird und der Betreff des Zertifikats (der den Common Name enthält) die Größenbeschränkung überschreitet.

Nächste Schritte