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.

Google Cloud Armor applique le seuil de limitation du débit à chaque backend associé. Par exemple, si vous disposez de deux services de backend et que vous configurez une règle de limitation du débit avec un seuil de 1 000 requêtes par minute, chaque service de backend peut recevoir 1 000 requêtes par minute avant que Google Cloud Armor applique l'action de la règle.

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: une clé unique pour chaque valeur d'en-tê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" si aucun en-tête de ce type n'est présent, ou si vous essayez d'utiliser ce type de clé avec un équilibreur de charge réseau proxy externe.
• XFF_IP: clé unique pour chaque adresse IP source d'origine du client, c'est-à-dire la première adresse IP de la liste d'adresses IP spécifiée dans l'en-tête HTTP X-Forwarded-For. Le type de clé est défini par défaut sur "Adresse IP" si aucun en-tête de ce type 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 réseau proxy externe.
• HTTP_COOKIE: une 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 TOUS si aucun cookie de ce type n'est présent ou si vous essayez d'utiliser ce type de clé avec un équilibreur de charge réseau proxy externe.
• HTTP_PATH: le chemin d'URL de la requête HTTP. La valeur de clé est tronquée aux 128 premiers octets.
• SNI: indique le nom du serveur dans la session TLS de la requête HTTPS. La valeur de clé est tronquée aux 128 premiers octets. Le type de clé par défaut est ALL sur une session HTTP.
• REGION_CODE: pays ou région d'où provient la requête.
• TLS_JA3_FINGERPRINT: empreinte TLS/SSL JA3 si le client se connecte à l'aide de HTTPS, HTTP/2 ou HTTP/3. Si ce type de clé n'est pas disponible, il est défini par défaut sur ALL. Pour plus d'informations sur JA3, consultez la documentation de référence sur le langage de règles.
• USER_IP: adresse IP du client d'origine, incluse dans les en-têtes configurés sous userIpRequestHeaders et dont la valeur est renseignée par un proxy en amont. En l'absence de configuration userIpRequestHeaders ou si une adresse IP ne peut pas être résolue à partir de celle-ci, le type de clé est défini par défaut sur IP. Pour en savoir plus, consultez la documentation de référence sur le langage de règles.

Vous pouvez utiliser les clés précédentes individuellement ou appliquer une limitation du débit sur la base d'une combinaison de trois clés maximum. Vous pouvez utiliser plusieurs clés HTTP-HEADER ou HTTP-COOKIE, et une seule clé de chaque autre type. Pour en savoir plus, consultez la section Limitation du débit basée sur plusieurs clés.

Remarque :Les données des clés de limitation du débit sont classées en tant que données de service, qui sont traitées comme décrit dans l'Avis de confidentialité de Google Cloud. Les données des clés de limitation du débit ne sont pas traitées comme des données client. Si votre charge de travail est soumise à des régimes réglementaires ou à d'autres exigences de conformité qui nécessitent Access Transparency ou l'approbation des accès, examinez les types de clés dont les valeurs peuvent contenir des informations sensibles.

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 10, 30, 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 afin d'exclure temporairement les clients qui dépassent la limite. Pour ce faire, vous appliquez la règle exceed_action configurée à 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 10, 30, 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_threshold_count: nombre de requêtes par client auquel Google Cloud Armor interdit les requêtes. Si elle est spécifiée, la clé est interdite pour le ban_duration_sec configuré lorsque le nombre de requêtes qui dépassent rate_limit_threshold_count dépasse également ce ban_threshold_count.
• 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_count. Dans ce mode, le client n'est exclu pour la règle ban_duration_sec configurée que si le taux de requêtes dépasse le paramètre ban_threshold_count configuré. Si le taux de requêtes ne dépasse pas la valeur ban_threshold_count, les requêtes continuent d'être limitées à rate_limit_threshold. Pour les besoins de ban_threshold_count, le nombre total de requêtes du client, c'est-à-dire toutes les requêtes entrantes avant limitation, est comptabilisé.

Règle de sécurité de la limitation du débit par défaut

Lorsque vous configurez une stratégie de sécurité par défaut Lors de la création de l'équilibreur de charge, le seuil par défaut est de 500 requêtes pendant chaque intervalle d'une minute (unrate_limit_threshold etinterval_sec sur500 et60, respectivement). Si vous souhaitez sélectionner un autre seuil, nous vous recommandons d'effectuer les étapes suivantes pour ajuster vos paramètres:

1. Activez Cloud Logging et interrogez le nombre maximal de requêtes arrivées par adresse IP et par minute sur une journée ou plus sur votre service de backend protégé par Google Cloud Armor.

   Par exemple, supposons que 99% du trafic réseau que vous recevez ne doive pas être affecté par la règle de limite de débit. Dans ce scénario, nous vous recommandons de définir votre seuil de limite de débit sur le 99e centile du nombre maximal de requêtes par adresse IP et par minute de distribution générée à partir des données Cloud Logging.

2. Si vous remarquez toujours des règles de limitation du débit par défaut bloquant le trafic légitime, envisagez les étapes supplémentaires suivantes:

   1. Activer la mise en cache (Cloud CDN ou Media CDN).
   2. Augmentez l'intervalle de temps limité (requêtes reçues toutes les plusieurs minutes, au lieu de toutes les 60 secondes).
   3. Vous pouvez exclure les clients afin de réduire davantage l'impact d'une attaque après la première vague. L'action rate_based_ban de Google Cloud Armor vous permet de réaliser cette opération en interdisant tous les clients qui dépassent les limites trop de fois dans une fenêtre spécifiée par l'utilisateur. Par exemple, les clients qui dépassent les limites 10 fois en une minute peuvent être interdits pendant 15 minutes.

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.

Journalisation

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.

Étapes suivantes

• Configurer la limitation du débit