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 débit vous aident à protéger vos applications contre les attaques qui inondent vos instances avec un grand volume de requêtes et bloquent 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.

Cloud Armor propose deux types de règles basées sur le débit :

  • 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.
  • Exclusion basée sur le débit : Vous pouvez limiter le débit par client pour les requêtes correspondant à une règle, puis temporairement exclure les clients pendant une période prédéfinie si le nombre de requêtes dépasse un seuil configuré par l'utilisateur.

Lorsque vous configurez une règle avec une action d'exclusion basée sur le débit, vous ne pouvez pas la remplacer ultérieurement par une action de limitation du débit. Toutefois, lorsque vous configurez une règle avec une action de limitation, vous pouvez la remplacer ultérieurement par une action d'exclusion basée sur le débit. Pour en savoir plus, consultez Transformer une règle de limitation du débit en règle d'exclusion basée sur le débit.

Cloud Armor applique le seuil de limitation du débit à chaque backend associé. Par exemple, si vous avez 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 Cloud Armor n'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

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 (toutes) : une clé unique pour toutes les requêtes qui 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 tentez d'utiliser ce type de clé avec un équilibreur de charge réseau proxy externe.
  • 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'en-tête HTTP X-Forwarded-For. Le type de clé est défini par défaut sur l'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 : 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 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 réseau proxy externe.
  • HTTP_PATH : 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é est défini par défaut sur ALL pour une session HTTP.
  • REGION_CODE : pays ou région d'origine de la requête.
  • TLS_JA4_FINGERPRINT : empreinte JA4 TLS/SSL si le client se connecte à l'aide de HTTPS, HTTP/2 ou HTTP/3. Si ce n'est pas le cas, le type de clé est défini par défaut sur ALL. Pour en savoir plus sur JA4, consultez la documentation de référence sur le langage des règles.
  • TLS_JA3_FINGERPRINT : empreinte JA3 TLS/SSL si le client se connecte à l'aide de HTTPS, HTTP/2 ou HTTP/3. Si ce n'est pas le cas, le type de clé est défini par défaut sur ALL.
  • 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. S'il n'y a pas 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 des règles.

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

Choisir entre les règles de limitation du débit et les règles d'exclusion basées sur le débit

Les règles de limitation du débit rate-based ban et throttle de Cloud Armor diffèrent dans la façon dont elles gèrent le trafic dépassant le seuil configuré.

  • rate_based_ban : lorsque le débit de requêtes dépasse le seuil défini, Cloud Armor bloque toutes les requêtes ultérieures provenant de la source ou de la cible de ces requêtes pendant une période spécifiée.
  • throttle : au lieu de bloquer tout le trafic, la limitation restreint le nombre de requêtes à un maximum défini. La limitation du débit permet à une partie du trafic de passer, mais à un débit contrôlé qui empêche la surcharge.

La règle la plus appropriée dépend de vos besoins spécifiques et du type de trafic que vous traitez. Par exemple, si vous êtes victime d'une attaque DDoS, une exclusion basée sur le débit peut être plus appropriée pour bloquer rapidement le trafic malveillant. En revanche, si vous constatez une augmentation soudaine du trafic légitime, la limitation peut être une meilleure option pour maintenir la disponibilité du service tout en évitant la surcharge.

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 la 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 2 000 requêtes en 1 200 secondes (20 minutes). Si un client envoie 2 500 requêtes au cours d'une période de 1 200 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é.

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

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

  • rate_limit_threshold_count : nombre de requêtes autorisé par client dans un intervalle de temps spécifié. La valeur minimale est 1 et la valeur maximale 1 000 000.
    • interval_sec : nombre de secondes dans l'intervalle de temps. La valeur doit être 10, 30, 60, 120, 180, 240, 300, 600, 900, 1 200, 1 800, 2 700 ou 3 600 secondes.
  • exceed_action : lorsqu'une requête dépasse le seuil rate_limit_threshold_count, Cloud Armor applique la valeur exceed_action configurée. Les valeurs possibles pour exceed_action sont les suivantes :
    • deny(status) : la requête est refusée et le code d'état spécifié est renvoyé. Les valeurs valides sont 403 Forbidden, 404 Page Not Found, 429 Too Many Requests et 502 Bad Gateway. Nous vous recommandons d'utiliser le code d'état 429 Too Many Requests.
    • redirect : la requête est redirigée pour l'évaluation reCAPTCHA 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 protocole de transport type est défini sur EXTERNAL_302.
  • conform_action : action effectuée lorsque le nombre de requêtes est inférieur au rate_limit_threshold_count. Il s'agit toujours d'une action allow.

Exclure des clients en fonction du débit des requêtes

L'action rate_based_ban dans une règle vous permet d'appliquer un seuil par client pour exclure 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 2 000 requêtes en 1 200 secondes (20 minutes). Si un client envoie 2 500 requêtes en l'espace de 1 200 secondes, 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 soient écoulées et pour un nombre supplémentaire de secondes que vous définissez comme période d'exclusion. Si la période d'exclusion est définie sur 3600, par exemple, le trafic du client sera exclu pendant 3 600 secondes (une heure) au-delà de la fin de l'intervalle du seuil.

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 débit de trafic d'un client dépasse le rate_limit_threshold_count spécifié, Cloud Armor applique le exceed_action à toutes les requêtes entrantes du client pour le reste de l'intervalle de seuil et pour les ban_duration_sec secondes suivantes, que le seuil soit dépassé ou non.

Avec cette configuration, il est possible d'exclure accidentellement des clients autorisés qui ne dépassent qu'occasionnellement le débit de requêtes autorisé. Pour éviter cela et n'exclure que les clients qui dépassent fréquemment le débit 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 pendant les ban_duration_sec configurées que si le débit de requêtes dépasse le ban_threshold_count configuré. Si le débit de requêtes ne dépasse pas ban_threshold_count, les requêtes continuent d'être limitées à rate_limit_threshold_count. Pour les besoins de ban_threshold_count, le total des requêtes du client est compté (cela inclut toutes les requêtes entrantes avant la limitation).

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

  • rate_limit_threshold_count : nombre de requêtes par client autorisé dans 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 seuil rate_limit_threshold_count, Cloud Armor applique la valeur exceed_action configurée. Les valeurs possibles pour exceed_action sont les suivantes :
    • deny(status) : la requête est refusée et le code d'état spécifié est renvoyé. Les valeurs valides sont 403 Forbidden, 404 Page Not Found, 429 Too Many Requests et 502 Bad Gateway. Nous vous recommandons d'utiliser le code d'état 429 Too Many Requests.
    • redirect : la requête est redirigée pour l'évaluation reCAPTCHA 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 : type de l'action de redirection, GOOGLE_RECAPTCHA ou EXTERNAL_302.
    • target : cible de l'URL pour l'action de redirection. Cette URL cible ne s'applique que lorsque type est défini sur EXTERNAL_302.
  • conform_action : action effectuée lorsque le nombre de requêtes est inférieur au rate_limit_threshold_count. Il s'agit toujours d'une action allow.
  • ban_threshold_count : nombre de requêtes par client autorisé dans un intervalle de temps spécifié, au-delà duquel Cloud Armor exclut les requêtes. Si elle est spécifiée, la clé est exclue pendant les ban_duration_sec configurées lorsque le nombre de requêtes qui dépassent le rate_limit_threshold_count dépasse également ce ban_threshold_count.
    • ban_threshold_interval_sec : nombre de secondes dans l'intervalle de temps pour votre ban_threshold_count. La valeur ban_threshold_interval_sec doit être 10, 30, 60, 120, 180, 240, 300, 600, 900, 1200, 1800, 2700 ou 3600 secondes.
  • ban_duration_sec : nombre supplémentaire de secondes pendant lesquelles un client est exclu après l'expiration de la période interval_sec. La valeur ban_duration_sec doit être 60, 120, 180, 240, 300, 600, 900, 1 200, 1 800, 2 700 ou 3 600 secondes.

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 (valeurs de rate_limit_threshold_count et interval_sec définies sur 500 et 60, 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 qui sont arrivées par adresse IP et par minute sur une journée ou plus sur votre service de backend protégé par Cloud Armor.

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

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

    1. Activer la mise en cache (Cloud CDN ou Media CDN).
    2. Augmenter l'intervalle de temps de la limitation (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 Cloud Armor vous permet d'exclure 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 exclus pendant 15 minutes.

Application des seuils

Les seuils configurés pour la limitation du débit et les exclusions basées sur le débit 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 applique le seuil de limitation de débit configuré à chaque clé. 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 5 000 requêtes, le service de backend peut recevoir 5 000 requêtes provenant de la première région et 5 000 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.

La limitation du débit basée sur REGION_CODE tient compte de la région d'origine de la requête et non de la région des backends dans le service de backend, quel que soit leur type. Les backends incluent des groupes d'instances, tout type de groupe de points de terminaison du réseau (NEG) compatible avec les équilibreurs de charge et les buckets Cloud Storage. Vous trouverez les backends compatibles dans la présentation des règles de sécurité.

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 Utiliser la journalisation des requêtes.

Cloud Armor avec Cloud Service Mesh

Vous pouvez configurer des stratégies de sécurité des services internes pour votre maillage de services afin d'appliquer une limitation de débit globale côté serveur par client. Cela vous permet de partager équitablement la capacité disponible de votre service et de réduire le risque de surcharge de vos services par des clients malveillants ou au comportement inapproprié. Vous associez une stratégie de sécurité à une stratégie de point de terminaison Cloud Service Mesh pour appliquer la limitation du débit au trafic entrant côté serveur. Toutefois, vous ne pouvez pas configurer de stratégie de sécurité Google Cloud Armor si vous utilisez le routage du trafic TCP. Pour en savoir plus sur l'utilisation de Cloud Armor avec Cloud Service Mesh, consultez Configurer la limitation du débit avec Cloud Armor.

Étape suivante