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) : il s'agit de la clé 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é.
  • XFF-IP : une seule unique pour chaque adresse IP source d'origine du client, comme spécifié dans X-Forwarded-Header.

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 refusé 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 10 et la valeur maximale est 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 rate_limit_threshold, Google Cloud Armor refuse les requêtes et renvoie le code de réponse HTTP spécifié. Pour les règles throttle, nous vous recommandons d'utiliser le code de réponse 429 (Trop de requêtes).
  • conform_action : il s'agit toujours d'une action allow. Il s'agit de l'action à effectuer lorsque le nombre de requêtes est inférieur au rate_limit_threshold.

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 immédiatement envoyée au service de backend. Lorsque le taux de trafic d'un client dépasse le paramètre rate_limit_threshold spécifié, les requêtes dépassant la limite sont bloquées pour le reste de l'intervalle de seuil. Le code d'erreur de refus est défini dans le paramètre exceed-action.

Exclure des clients en fonction des taux de requêtes

L'action rate_based_ban d'une règle vous permet d'appliquer un seuil par client afin de protéger les services de backend et d'exclure temporairement les clients qui dépassent la limite en rejetant 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 qui satisfait la condition de correspondance de règle et qui 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 2500 requêtes en 1200 secondes, le trafic de ce client qui dépasse le seuil de 2000 requêtes est bloqué jusqu'à ce que les 1200 secondes complètes soient écoulées et pendant un nombre de secondes supplémentaire que vous définissez en tant que durée de la 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 10 et la valeur maximale est 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 : Il s'agit toujours d'une action deny. Lorsque le taux de trafic d'un client dépasse le rate_limit_threshold spécifié, le client est banni (toutes les requêtes entrantes sont refusées) pour le reste de l'intervalle de seuil et pour le nombre de secondes spécifié dans leban-duration.
  • conform_action : il s'agit toujours d'une action allow. Il s'agit de l'action à effectuer lorsque le nombre de requêtes est inférieur au rate_limit_threshold.
  • 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é, le client est banni (toutes les requêtes entrantes sont refusées) pendant le reste de l'intervalle défini par le seuil et pendant les ban-duration_sec prochaines secondes, que le seuil soit dépassé ou non. Le code d'erreur de refus est extrait de la exceed- action configurée.

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 comptabilité (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.

Étape suivante