Traditionelles Rate Limiting wird üblicherweise als Anfragenzählung pro IP-Adresse angewendet. Dieses Modell ist einfach, aber NAT, Carrier-Netzwerke, gemeinsame Egress-Punkte und anonyme Gateways können legitime Benutzer und Missbrauchsquellen in denselben Bucket einordnen. Hoher Traffic von einer einzelnen IP ist nicht immer ein Angriff; gleichermaßen ist verteilter Traffic mit geringem Volumen nicht immer unschuldig.
Anwendungsverhalten ist nicht einheitlich. Ein kurzer Ausbruch von Asset-Anfragen während eines Seitenladens ist normal, aber dieselbe Rate auf einem Zahlungs-, Login- oder API-Endpoint kann auf Missbrauch hinweisen. Ein flaches "N Anfragen pro Minute"-Modell kann sowohl die Benutzererfahrung beeinträchtigen als auch echte Angriffe übersehen.
Credential Stuffing, Kontoaufzählung und Bot-Muster können nicht allein aus rohen Anfragenzählungen gelesen werden. Eine große Anzahl fehlgeschlagener Login-Versuche auf einem Authentifizierungs-Endpoint mag im Gesamttraffic niedrig erscheinen. Zähler, die nicht mit Benutzername, Sitzung, API-Key, benutzerdefiniertem Header oder Antwortverhalten korreliert werden, verlieren ihren Sicherheitskontext.
Ressourcenschutz ist ein separates Anliegen. Selbst wenn verteilte Clients Anfragen mit einer niedrigen pro-Client-Rate senden, kann die aggregierte Last einen Connection-Pool, eine Suchinfrastruktur oder eine Datei-Download-Kapazität eines Backends erschöpfen. Rate Limiting wird nicht nur benötigt, um einen Angreifer zu stoppen, sondern um Backend-Kapazität fair und kontrolliert zu verteilen.
TR7s Ansatz hebt Rate Limiting von einem stumpfen IP-basierten Schwellenwert zu einer kontrollierten Sicherheitsrichtlinie, die über Benutzer-, Endpoint-, Sitzungs-, API-Key-, Composite-Key- und Bandbreitendimensionen angewendet werden kann.
TR7 implementiert Rate Limiting als mehrdimensionale WAAP-Kontrolle, die um Scope, Counter-Modell und Aktionsauswahl herum konzipiert ist, die zusammenarbeiten.
TR7 verfolgt Anfrage-, Verbindungs-, Fehler- und Bandbreitenraten innerhalb eines konfigurierbaren Zeitfensters. Verschiedene Fensterlängen ermöglichen die unabhängige Auswertung von kurzlebigen Spitzen und anhaltender hoher Last.
Verschiedene Scopes können mit IP, IP und User-Agent, Benutzername, API-Key, Cookie, Header oder Composite-Keys erstellt werden. Dies ermöglicht präziseres Erfassen von Missbrauch ohne legitime Benutzer hinter derselben IP zu bestrafen.
Eine Richtlinie kann die Anfrage verweigern, eine temporäre Blockierung anwenden, zur CAPTCHA-Verifikation weiterleiten oder eine Bandbreitenkappe auferlegen. Nicht jeder Verstoß wird mit demselben Antwortniveau behandelt.
Zähler werden innerhalb des Datenpfades gepflegt — zur Entscheidungszeit ist kein externer Datenbankaufruf erforderlich. Multi-Instance-Deployments werden durch Counter-Synchronisierung unterstützt, was eine konsistente Richtliniendurchsetzung in verteilten Setups ermöglicht.
TR7 Rate Limiting deckt verschiedene Missbrauchsszenarien ab — von vorgefertigten Bot-Richtlinien bis zu benutzerdefinierten Composite-Keys — durch ein einziges Verwaltungsmodell.
TR7 wird mit vorgefertigten Richtlinien für gängige Bot- und Missbrauchsszenarien geliefert. Das `bot_rateLimit`-Profil kann HTTP 429 bei 300 Anfragen pro Minute pro IP zurückgeben. `bot_rateLimitStrict` kann nach 100 Anfragen pro Minute eine 5-minütige temporäre Blockierung anwenden. `bot_rateLimitCaptcha` kann nach 150 Anfragen pro Minute zu einem selbst gehosteten CAPTCHA-Fluss weiterleiten.
Der `requests`-Typ verfolgt die rohe Anfragerate. `failedAuthAttempts` behandelt fehlgeschlagene Authentifizierungsversuche mit einem dedizierten Zähler. `riskScore` kann Entscheidungen basierend auf einem Bot- oder Verhaltens-Score treffen. `static` wird für bedingungslose Kontrollen verwendet, wie z.B. obligatorisches CAPTCHA auf einem bestimmten Ablauf.
Der `global`-Scope überwacht die aggregierte Last über einen gesamten Service. Die `ip`-, `ip+ua`-, `username`- und `composite`-Scopes erstellen gezieltere Limits. Die Composite-Struktur kann einen benutzerdefinierten Header, Cookie, API-Key oder ein Feld aus dem Request-Body kombinieren, um einen benutzerdefinierten Counter-Key zu erzeugen. Diese Flexibilität ermöglicht es B2B-API- und Multi-Tenant-Anwendungen, echte Nutzungslimits genauer widerzuspiegeln.
Ein Service-Pool kann mehrere Rate-Limiting-Richtlinien gleichzeitig aktiv haben. Beispielsweise kann dieselbe Anfrage sowohl einer IP-bezogenen DDoS-Kappe als auch einem benutzerbezogenen Fair-Use-Limit unterliegen. Jede Richtlinie verfolgt ihren eigenen unabhängigen Zähler. Diese Struktur ermöglicht ein mehrschichtiges Schutzmodell anstelle eines einzelnen Schwellenwerts.
Wenn die `block`-Aktion ausgelöst wird, wird der betroffene Key für die konfigurierte Dauer in der Block-Tabelle gehalten. Dies verhindert, dass ein Angreifer einen kurzen Ausbruch erzeugt und dann nach dem Verlangsamen sofort zurückkehrt. Die `blockDuration` wird pro Richtlinie festgelegt. Dieses Modell bietet stärkere Kontrolle gegen intensive Bot-Wellen und wiederkehrende Missbrauchsquellen.
Die `captcha`-Aktion kann Traffic, der den Schwellenwert überschritten hat oder als riskant eingestuft wird, zu einem Verifikationsfluss weiterleiten, anstatt ihn vollständig abzuschneiden. Der Standardanbieter ist `tr7Standard`. Bei erfolgreicher Verifikation wird die Anfrage des Benutzers fortgesetzt. Dieser Ansatz bietet eine ausgewogenere Alternative zur Blockierung in Szenarien, in denen das Trennen echter Benutzer von Automatisierung die Priorität ist.
TR7 kann neben Anfragenzählungen auch eingehende und ausgehende Bandbreitenraten verfolgen. Mit der `bwLimit`-Aktion kann Traffic, der einer bestimmten Bedingung entspricht, unter eine eigene Bandbreitenkappe gestellt werden. Dies ist nützlich für Datei-Download-Endpoints, Endpoints, die große Antworten erzeugen, oder hohen Datenverbrauch aus einer einzigen Quelle — das Backend verfügbar halten ohne es vollständig abzuschneiden.
Informationen wie der Benutzername aus einer AAM-Sitzung können als Rate-Limiting-Key verwendet werden. Dies ermöglicht es, jedem Benutzer nach dem Login ein separates Fair-Use-Limit zuzuweisen. Kostenlose und kostenpflichtige Pläne, interne und externe Benutzergruppen oder verschiedene Rollenebenen können jeweils durch unterschiedliche Limits gesteuert werden. Dies bietet präzisere Kontrolle in API- und Portal-Szenarien, in denen IP-basierte Limits nicht ausreichen.
Damit Rate-Limiting-Richtlinien wirksam sind, müssen Counter-Laufzeit, Tabellengröße, Cluster-Synchronisierung, Observability und Rollback-Verhalten alle mit operativer Klarheit verwaltet werden.
Verschiedene Scopes arbeiten mit unterschiedlichen Tabellengrößen. Der globale Scope verwendet einen einzigen Key, während IP- und Composite-Scopes eine viel größere Anzahl von Einträgen halten können. Lange Keys wie IP kombiniert mit User-Agent können mehr Speicher verbrauchen, daher sollte die Scope-Auswahl gegen das erwartete Traffic-Profil getroffen werden.
Counter-Synchronisierung über Instanzen hinweg wird in Cluster-Deployments unterstützt. Instanzen, die denselben Richtlinien-Key teilen, können sich gegenseitig entdecken und Counter-Zustand austauschen. Dies macht es einem Angreifer schwerer, ein Limit zu umgehen, indem er in einer lastverteilten Umgebung zwischen Instanzen wechselt.
Stabiles Tabellen-Naming, das an die Richtlinienidentität gebunden ist, hilft, den Counter-Zustand über Reload-Zyklen hinweg zu bewahren. Wenn dieselbe Richtlinie unter demselben Namen fortgesetzt wird, werden Zähler nicht unnötigerweise zurückgesetzt. Dies reduziert das Risiko, dass während Wartungs- oder Konfigurationsaktualisierungen eine Sicherheitslücke entsteht.
Rate-Limiting-Richtlinien werden vor dem Deployen durch Schema-Validierung geprüft. Ungültige Scope-, Trigger-Typ- oder Aktionsdefinitionen können nicht in die Produktionskonfiguration eintreten. Diese Prüfung reduziert das Risiko, dass eine fehlkonfigurierte Sicherheitsregel den Live-Traffic stört.
Bot-Richtlinie, Konto-Lockout-Regeln und WAAP-Entscheidungen können alle gleichzeitig auf derselben Anfrage ausgeführt werden. Prioritätsreihenfolge und Match-Verhalten werden durch Konfiguration gesteuert. Rate Limiting arbeitet daher nicht isoliert, sondern als Teil der breiteren WAAP-Entscheidungspipeline.
Bei jedem Trigger können Regel-ID, Aktion, Key und Rateninformationen protokolliert werden. Diese Datensätze können für Vorfall-Analyse und Berichterstellung an ein SIEM weitergeleitet werden. Betriebsteams können die am häufigsten ausgelösten Keys, die verkehrsreichsten Endpoints und Blockierungstrends im Laufe der Zeit überwachen.
Organisationen, die B2B-APIs anbieten, können gleichzeitig ein per-Benutzer-Plan-Limit und eine per-IP-Missbrauchskappe durchsetzen. TR7 führt eine benutzerbezogene Fair-Use-Richtlinie und eine IP-bezogene harte Kappe parallel aus.
Eine hohe Anzahl fehlgeschlagener Zugangsdaten-Eingaben auf einem Authentifizierungsbildschirm kann ein Brute-Force-Indikator sein. TR7 kann Fehler mit einem kombinierten Benutzername- und IP-Key verfolgen und eskalierte Aktionen anwenden — zunächst CAPTCHA, dann eine temporäre Sperre.
Ein kurzer Ausbruch von Anfragen auf Produktseiten kann normal sein, aber dasselbe Muster auf einem Zahlungsendpoint ist ein Risiko. TR7 kann Endpoint-Bedingungen und verschiedene Zeitfenster verwenden, um Checkout-Missbrauch zu begrenzen, ohne die Seiten-Lade-Erfahrung zu beeinträchtigen.
Eine einzelne Quelle kann durch Hochvolumen-Downloads die I/O-Kapazität eines Backends erschöpfen. TR7 verwendet die Bandwidth-Limit-Rule, um diesen Traffic bedingt zu deckeln und den Service für andere Benutzer verfügbar zu halten.
Mehrschichtige Rate-Richtlinie über IP-, Benutzer-, API-Key- und Bandbreitendimensionen. Lassen Sie uns einen Live-Setup auf Ihren eigenen Services durchführen.