Présentation de la limitation du débit

Google Cloud Armor offre des fonctionnalités permettant de protéger vos applications Google Cloud contre diverses attaques de couche 3 et de couche 7. Les règles basées sur le taux vous aident à protéger vos applications contre les attaques qui inondent vos instances avec un grand volume de requêtes afin de bloquer l'accès des utilisateurs légitimes.

La limitation du débit peut effectuer les opérations suivantes :

  • Empêcher les clients d'épuiser les ressources de l'application.
  • Protéger vos instances d'application contre les pics irréguliers et imprévisibles du taux de requêtes client.

En outre, lorsqu'une ressource fait l'objet d'un volume élevé de trafic provenant d'un petit nombre de clients, vous pouvez éviter que vos autres clients ne soient affectés par les pics de trafic provenant de ce petit nombre de clients, ce qui permet à vos ressources de traiter autant de requêtes que possible.

Google Cloud Armor propose deux types de règles basées sur le taux :

  1. Règle de limitation : vous pouvez appliquer une limite de nombre maximal de requêtes par client ou pour l'ensemble des clients en limitant les clients individuels à un seuil de nombre de requêtes configuré par l'utilisateur.
  2. Exclusion basée sur le taux : vous pouvez limiter le débit par client pour les requêtes correspondant à une règle, puis temporairement bannir les clients pendant une période prédéfinie si le nombre de requêtes dépasse un seuil configuré par l'utilisateur.

Vous pouvez prévisualiser les effets des règles de limitation du débit dans une stratégie de sécurité en utilisant le mode aperçu et en examinant vos journaux de requêtes.

Identifier les clients pour la limitation du débit

Google Cloud Armor identifie les clients individuels pour la limitation du débit en utilisant les types de clés suivants pour agréger les requêtes et appliquer les limites de débit :

  • ALL (tous) : une clé unique pour tous les clients dont les requêtes satisfont la condition de correspondance de règle.
  • IP (adresse IP) : une clé unique pour chaque adresse IP source cliente dont les requêtes satisfont la condition de correspondance de règle.
  • HTTP-Header (entête HTTP) : une clé unique pour chaque valeur d'entête HTTP unique dont le nom est configuré. La valeur de clé est tronquée aux 128 premiers octets de la valeur d'en-tête. Le type de clé est défini par défaut sur ALL (tous) si aucun en-tête de ce type n'est présent, ou si vous tentez d'utiliser ce type de clé avec un équilibreur de charge proxy TCP ou SSL.
  • XFF-IP : une clé unique pour chaque adresse IP source d'origine du client, c'est-à-dire la première adresse IP dans la liste des adresses IP spécifiées dans l'entête HTTP X-Forwarded-For. Le type de clé est défini par défaut sur l'adresse IP si aucun en-tête n'est présent, si la valeur n'est pas une adresse IP valide ou si vous essayez d'utiliser ce type de clé avec un équilibreur de charge proxy TCP ou SSL.
  • HTTP-COOKIE: clé unique pour chaque valeur de cookie HTTP dont le nom est configuré. La valeur de clé est tronquée aux 128 premiers octets de la valeur du cookie. Le type de clé est défini par défaut sur ALL (tous) si aucun cookie de ce type n'est présent, ou si vous tentez d'utiliser ce type de clé avec un équilibreur de charge proxy TCP ou SSL.

Limiter le trafic

L'action throttle dans une règle vous permet d'appliquer un seuil de nombre de requêtes par client afin de protéger les services de backend. Cette règle applique le seuil de manière à limiter, pour chaque client, le trafic satisfaisant la condition de correspondance de règle. Le seuil est configuré sous la forme d'un nombre spécifique de requêtes dans un intervalle de temps donné.

Par exemple, vous pouvez définir le seuil de requêtes sur 2000 requêtes en 1200 secondes (20 minutes). Si un client envoie 2500 demandes au cours d'une période de 1200 secondes, environ 20 % du trafic du client est limité jusqu'à ce que le volume de requêtes autorisé soit inférieur ou égal au seuil configuré.

Vous devez définir les paramètres suivants pour contrôler l'action :

  • rate_limit_threshold : nombre autorisé de requêtes, par client, sur un intervalle de temps spécifié. La valeur minimale est 1 et la valeur maximale 10 000.
    • interval_sec : nombre de secondes dans l'intervalle de temps. La valeur doit être 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 ou 3600 secondes.
  • exceed_action: lorsqu'une requête dépasse le rate_limit_threshold, Google Cloud Armor applique exceed_action configuré. Les valeurs possibles pour exceed_action sont les suivantes :
    • deny(status): la requête est refusée et le code d'erreur spécifié est renvoyé. Les valeurs valides sont 403, 404, 429 et 502. Nous vous recommandons d'utiliser le code de réponse 429 (Too Many Requests).
    • redirect: la requête est redirigée pour l'évaluation reCAPTCHA Enterprise ou vers une autre URL, en fonction du paramètre exceed_redirect_options.
  • exceed_redirect_options: lorsque la valeur de exceed_action est redirect, utilisez ce paramètre pour spécifier l'action de redirection :
    • type: saisissez l'action de redirection GOOGLE_RECAPTCHA ou EXTERNAL_302.
    • target: cible de l'URL pour l'action de redirection. Ne s'applique que lorsque le type est EXTERNAL_302.
  • conform_action: action effectuée lorsque le nombre de requêtes est inférieur au rate_limit_threshold. Il s'agit toujours d'une action allow.

Lorsque le taux de trafic d'un client est inférieur ou égal à rate_limit_threshold, les requêtes suivent la conform-action, qui est toujours allow. La requête est autorisée via la règle de sécurité et est autorisée à atteindre sa destination. Lorsque le taux de trafic d'un client dépasse le rate_limit_threshold spécifié, Google Cloud Armor applique le exceed_action, qui peut être deny ou redirect, pour les requêtes supérieures à la limite pour le reste de l'intervalle du seuil.

Exclure des clients en fonction des taux de requêtes

L'action rate_based_ban dans une règle vous permet d'appliquer un seuil par client pour interdire temporairement les clients dépassant la limite en appliquant l'action exceed_action configurée pour toutes les requêtes du client pendant une période configurable. Le seuil est configuré sous la forme d'un nombre spécifique de requêtes dans un intervalle de temps donné. Vous pouvez exclure temporairement le trafic pendant une période configurée par l'utilisateur ('ban_duration_sec'), à condition que le trafic corresponde à la condition de correspondance spécifiée et dépasse le seuil configuré.

Par exemple, vous pouvez définir le seuil de requêtes sur 2000 requêtes en 1200 secondes (20 minutes). Si un client envoie 2 500 requêtes en l'espace de 1 200 secondes, Google Cloud Armor applique le exceed_action au trafic de ce client dépassant le seuil de 2 000 requêtes jusqu'à ce que les 1 200 secondes complètes soient écoulées et pour un nombre supplémentaire de secondes que vous définissez comme période d'interdiction. Si la période d'interdiction est définie sur 3600, par exemple, le trafic du client sera interdit pendant 3600 secondes (une heure) au-delà de la fin de l'intervalle de seuil.

Ces paramètres contrôlent l'action d'une règle rate_based_ban :

  • rate_limit_threshold : nombre autorisé de requêtes, par client, sur un intervalle de temps spécifié. La valeur minimale est 1 requête et la valeur maximale 10 000 requêtes.
    • interval_sec : nombre de secondes dans l'intervalle de temps. La valeur doit être 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 ou 3600 secondes.
  • exceed_action: lorsqu'une requête dépasse le rate_limit_threshold, Google Cloud Armor applique exceed_action configuré. Les valeurs possibles pour exceed_action sont les suivantes :
    • deny(status): la requête est refusée et le code d'erreur spécifié est renvoyé. Les valeurs valides pour le code d'erreur sont 403, 404, 429 et 502. Nous vous recommandons d'utiliser le code de réponse 429 (Too Many Requests).
    • redirect: la requête est redirigée pour l'évaluation reCAPTCHA Enterprise ou vers une autre URL, en fonction du paramètre exceed_redirect_options.
  • exceed_redirect_options: lorsque la valeur de exceed_action est redirect, utilisez ce paramètre pour spécifier l'action de redirection :
    • type: saisissez l'action de redirection GOOGLE_RECAPTCHA ou EXTERNAL_302.
    • target: cible de l'URL pour l'action de redirection. Ne s'applique que lorsque le type est EXTERNAL_302.
  • conform_action: action effectuée lorsque le nombre de requêtes est inférieur au rate_limit_threshold. Il s'agit toujours d'une action allow.
  • ban_duration_sec : nombre supplémentaire de secondes pendant lesquelles un client est banni après l'expiration de la période interval_sec. La valeur doit être 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 ou 3600 secondes.

Lorsque le taux de requêtes d'un client est inférieur au seuil de limitation du débit, la requête peut immédiatement être transmise au service de backend. Lorsque le taux de trafic d'un client dépasse le rate_limit_threshold spécifié, Google Cloud Armor applique le exceed_action à toutes les requêtes entrantes du client pour le reste de l'intervalle de seuil et pour les prochaines ban-duration_sec secondes, que le seuil soit dépassé ou non.

Avec cette configuration, il est possible de bannir accidentellement les clients de bienvenue qui ne dépassent qu'occasionnellement le taux de requêtes autorisé. Pour éviter cela et n'exclure que les clients qui dépassent fréquemment le taux de requêtes, vous pouvez éventuellement suivre le nombre total de requêtes client avec une configuration de seuil supplémentaire (de préférence plus longue) appelée ban_threshold. Dans ce mode, le client n'est interdit pendant les secondes configurées dans ban_duration que si le taux de requêtes dépasse le ban-threshold configuré. Si le taux de requêtes ne dépasse pas ban-threshold, les requêtes continuent d'être limitées à rate_limit_threshold. Pour les besoins de ban_threshold, le total des requêtes du client est compté (cela inclut toutes les requêtes entrantes avant la limitation).

Application des seuils

Les seuils configurés pour la limitation de débit et les exclusions basées sur le taux sont appliqués indépendamment dans chacune des régions Google Cloud où vos services de backend HTTP(S) sont déployés. Par exemple, si votre service est déployé dans deux régions, chacune des deux régions limite le débit de chaque clé au seuil configuré. Votre service de backend peut donc rencontrer des volumes de trafic agrégés entre plusieurs régions correspondant au double du seuil configuré. Si le seuil configuré est défini sur 5000 requêtes, le service de backend peut recevoir 5000 requêtes provenant de la première région et 5000 requêtes provenant de la deuxième région.

Toutefois, pour le type de clé correspondant à l'adresse IP, il est raisonnable de supposer que le trafic provenant d'une même adresse IP client sera dirigé vers la région la plus proche de la région dans laquelle vos backends sont déployés. Dans ce cas, la limitation du débit peut être considérée comme appliquée au niveau du service de backend, quelles que soient les régions dans lesquelles le service est déployé.

Il est important de noter que les limites de débit appliquées sont approximatives et peuvent ne pas strictement correspondre aux seuils configurés. De plus, dans de rares cas, en raison du comportement de routage interne, il est possible que la limitation du débit soit appliquée dans plus de régions que les seules régions dans lesquelles vous effectuez le déploiement, ce qui affecte la justesse. Pour ces raisons, nous vous recommandons de n'utiliser la limitation du débit que pour vous protéger contre les abus ou maintenir la disponibilité des applications et des services, et non pour appliquer des quotas stricts ou des exigences de licence.

Logging

Cloud Logging enregistre le nom de la règle de sécurité, la priorité de la règle de limitation de débit correspondante, l'ID de règle, l'action associée ainsi que d'autres informations dans vos journaux de requêtes. Pour en savoir plus sur la journalisation, consultez la section Utiliser la journalisation des requêtes.

Intégration à reCAPTCHA Enterprise

Vous pouvez appliquer une limitation de débit à certaines ressources reCAPTCHA Enterprise afin de limiter l'utilisation abusive et la réutilisation des jetons. Ces ressources incluent les jetons d'action, les jetons de session et les cookies d'exception. Pour en savoir plus sur la limitation du débit avec reCAPTCHA Enterprise, consultez la présentation de la gestion des bots.

Étape suivante