La limitation de débit traditionnelle est généralement appliquée comme un nombre de requêtes par adresse IP. Ce modèle est simple, mais le NAT, les réseaux opérateurs, les points de sortie partagés et les passerelles anonymes peuvent placer des utilisateurs légitimes et des sources d'abus dans le même panier. Un trafic élevé depuis une seule IP n'est pas toujours une attaque ; de même, un trafic distribué à faible volume n'est pas toujours innocent.
Le comportement applicatif n'est pas uniforme. Une courte rafale de requêtes d'assets lors du chargement d'une page est normale, mais le même taux sur un endpoint de paiement, de connexion ou d'API peut signaler un abus. Un modèle plat de "N requêtes par minute" peut à la fois nuire à l'expérience utilisateur et manquer de vraies attaques.
Le credential stuffing, l'énumération de comptes et les patterns de bots ne peuvent pas être lus à partir des seuls comptages bruts de requêtes. Un grand nombre de tentatives de connexion échouées sur un endpoint d'authentification peut sembler faible dans le trafic total. Des compteurs non corrélés au nom d'utilisateur, à la session, à la clé API, au header personnalisé ou au comportement de réponse perdent leur contexte de sécurité.
La protection des ressources est un problème distinct. Même lorsque des clients distribués envoient des requêtes à un faible taux par client, la charge agrégée peut épuiser le pool de connexions d'un backend, son infrastructure de recherche ou sa capacité de téléchargement de fichiers. La limitation de débit est nécessaire non seulement pour stopper un attaquant, mais pour distribuer la capacité du backend de manière équitable et contrôlée.
L'approche de TR7 fait passer la limitation de débit d'un seuil grossier basé sur l'IP à une politique de sécurité contrôlée applicable selon les dimensions utilisateur, endpoint, session, clé API, clé composite et bande passante.
TR7 implémente la limitation de débit comme un contrôle WAAP multidimensionnel conçu autour du périmètre, du modèle de compteur et de la sélection d'action fonctionnant ensemble.
TR7 suit les taux de requêtes, de connexions, d'erreurs et de bande passante dans une fenêtre temporelle configurable. Des durées de fenêtre différentes permettent d'évaluer indépendamment les pics de courte durée et la charge élevée soutenue.
Différents périmètres peuvent être créés en utilisant l'IP, l'IP et le user agent, le nom d'utilisateur, la clé API, le cookie, le header ou des clés composites. Cela permet de détecter les abus plus précisément sans pénaliser les utilisateurs légitimes derrière la même IP.
Une politique peut refuser la requête, appliquer un blocage temporaire, rediriger vers une vérification CAPTCHA ou imposer un plafond de bande passante. Chaque violation n'est pas traitée avec le même niveau de réponse.
Les compteurs sont maintenus dans le chemin des données — aucun appel à une base de données externe n'est nécessaire au moment de la décision. Les déploiements multi-instances sont pris en charge via la synchronisation des compteurs, permettant une application cohérente des politiques dans les configurations distribuées.
TR7 Rate Limiting couvre différents scénarios d'abus — des politiques de bots préconfigurées aux clés composites personnalisées — via un modèle de gestion unique.
TR7 est livré avec des politiques préconfigurées pour les scénarios courants de bots et d'abus. Le profil `bot_rateLimit` peut retourner HTTP 429 à 300 requêtes par minute par IP. `bot_rateLimitStrict` peut appliquer un blocage temporaire de 5 minutes après 100 requêtes par minute. `bot_rateLimitCaptcha` peut rediriger vers un flux CAPTCHA auto-hébergé après 150 requêtes par minute.
Le type `requests` suit le taux brut de requêtes. `failedAuthAttempts` gère les tentatives d'authentification échouées avec un compteur dédié. `riskScore` peut prendre des décisions basées sur un score de bot ou comportemental. `static` est utilisé pour des contrôles inconditionnels tels que le CAPTCHA obligatoire sur un flux spécifique.
Le périmètre `global` surveille la charge agrégée sur l'ensemble d'un service. Les périmètres `ip`, `ip+ua`, `username` et `composite` créent des limites plus ciblées. La structure composite peut combiner un header personnalisé, un cookie, une clé API ou un champ du corps de la requête pour produire une clé de compteur personnalisée. Cette flexibilité permet aux applications B2B API et multi-locataires de refléter plus précisément les limites d'utilisation réelles.
Un pool de services peut avoir plusieurs politiques de limitation de débit actives en même temps. Par exemple, la même requête peut être soumise à la fois à un plafond DDoS à périmètre IP et à une limite d'utilisation équitable à périmètre utilisateur. Chaque politique suit son propre compteur indépendant. Cette structure permet un modèle de protection en couches plutôt qu'un seul seuil.
Lorsque l'action `block` se déclenche, la clé affectée est maintenue dans la table de blocage pendant la durée configurée. Cela empêche un attaquant de générer une courte rafale puis de revenir immédiatement après avoir ralenti. Le `blockDuration` est défini par politique. Ce modèle offre un contrôle plus fort contre les vagues intenses de bots et les sources d'abus répétées.
L'action `captcha` peut rediriger le trafic ayant dépassé le seuil ou signalé comme risqué vers un flux de vérification plutôt que de le couper entièrement. Le fournisseur par défaut est `tr7Standard`. Après vérification réussie, la requête de l'utilisateur se poursuit. Cette approche offre une alternative plus équilibrée au blocage dans les scénarios où séparer les vrais utilisateurs de l'automatisation est la priorité.
TR7 peut suivre les taux de bande passante entrants et sortants en plus des comptages de requêtes. Avec l'action `bwLimit`, le trafic correspondant à une condition spécifique peut être placé sous son propre plafond de bande passante. C'est utile pour les endpoints de téléchargement de fichiers, les endpoints produisant de grandes réponses, ou la consommation de données à volume élevé depuis une seule source — maintenant le backend disponible sans le couper entièrement.
Des informations telles que le nom d'utilisateur d'une session AAM peuvent être utilisées comme clé de limitation de débit. Cela permet d'assigner une limite d'utilisation équitable distincte à chaque utilisateur après connexion. Les plans gratuits et payants, les groupes d'utilisateurs internes et externes, ou différents niveaux de rôle peuvent chacun être gouvernés par des limites différentes. Cela fournit un contrôle plus précis dans les scénarios d'API et de portail où les limites basées sur l'IP sont insuffisantes.
Pour que les politiques de limitation de débit soient efficaces, la durée de vie des compteurs, la taille des tables, la synchronisation en cluster, l'observabilité et le comportement de rollback doivent tous être gérés avec clarté opérationnelle.
Différents périmètres fonctionnent avec des tailles de table différentes. Le périmètre global utilise une seule clé tandis que les périmètres IP et composite peuvent contenir un nombre beaucoup plus grand d'entrées. Les clés longues telles que IP combinée avec le user agent peuvent consommer plus de mémoire, la sélection du périmètre doit donc être effectuée en fonction du profil de trafic attendu.
La synchronisation des compteurs entre instances est prise en charge dans les déploiements en cluster. Les instances partageant la même clé de politique peuvent se découvrir mutuellement et échanger l'état des compteurs. Cela rend plus difficile pour un attaquant de contourner une limite en changeant d'instance dans un environnement à charge distribuée.
Un nommage stable des tables lié à l'identité de la politique aide à préserver l'état des compteurs entre les cycles de rechargement. Lorsque la même politique continue sous le même nom, les compteurs ne sont pas réinitialisés inutilement. Cela réduit le risque d'ouverture d'une faille de sécurité lors des maintenances ou des mises à jour de configuration.
Les politiques de limitation de débit passent par une validation de schéma avant d'être déployées. Les définitions invalides de périmètre, de type de déclencheur ou d'action ne peuvent pas entrer dans la configuration de production. Cette vérification réduit le risque qu'une règle de sécurité mal configurée perturbe le trafic en production.
La politique de bot, les règles de verrouillage de compte et les décisions WAAP peuvent toutes s'exécuter simultanément sur la même requête. L'ordre de priorité et le comportement de correspondance sont gouvernés par la configuration. La limitation de débit fonctionne donc non pas isolément mais comme partie du pipeline de décision WAAP plus large.
À chaque déclenchement, l'identifiant de règle, l'action, la clé et les informations de taux peuvent être journalisés. Ces enregistrements peuvent être transmis à un SIEM pour l'analyse d'incidents et le reporting. Les équipes opérationnelles peuvent surveiller les clés les plus fréquemment déclenchées, les endpoints les plus sollicités et les tendances de blocage au fil du temps.
Les organisations qui proposent des API B2B peuvent appliquer simultanément une limite de plan par utilisateur et un plafond d'abus par IP. TR7 exécute en parallèle une politique d'utilisation équitable à périmètre utilisateur et un plafond dur à périmètre IP.
Un grand nombre de saisies d'identifiants échouées sur un écran d'authentification peut être un indicateur de brute-force. TR7 peut suivre les échecs en utilisant une clé combinée nom d'utilisateur et IP et appliquer des actions escaladées — CAPTCHA d'abord, puis verrouillage temporaire.
Une courte rafale de requêtes sur des pages produits peut être normale, mais le même pattern sur un endpoint de paiement est un risque. TR7 peut utiliser des conditions d'endpoint et différentes fenêtres temporelles pour limiter l'abus lors du checkout sans dégrader l'expérience de chargement des pages.
Une seule source peut consommer la capacité I/O d'un backend via des téléchargements à volume élevé. TR7 utilise le Bandwidth Limit Rule pour limiter conditionnellement ce trafic, maintenant le service disponible pour les autres utilisateurs.
Politique de débit multi-couche selon les dimensions IP, utilisateur, clé API et bande passante. Laissez-nous vous guider dans une configuration en direct sur vos propres services.