Klassische ADC- und Firewall-ACL-Logik wurde lange auf IP, Subnetz, Port und Protokoll aufgebaut. Dieses Modell reicht für einfache Netzwerkzugangskontrolle aus, aber moderner Web-, API-, Bot- und WAAP-Verkehr ist nicht so einfach.
Beim heutigen Treffen einer Entscheidung reicht es nicht, nur „Was ist die Quell-IP?“ zu fragen. Aus welchem Land kommt die Anfrage? Von welchem ASN? Welchen Path steuert sie an? Welches Cookie ist vorhanden? Welche Rolle ist im JWT eingetragen? Sieht das Header-Set wie ein echter Browser aus? Ist der TLS-Fingerabdruck verdächtig? Wie viele WAAP-Scorepunkte hat diese Anfrage erhalten? Wie hat die Bot-Engine diesen Benutzer klassifiziert?
In den meisten Produkten leben diese Signale an separaten Orten. Die Routing-Regel ist an einem Ort, der WAAP-Score an einem anderen, die Bot-Entscheidung woanders, Header-Umschreiben noch woanders und Rate-Limiting abermals woanders. Dies verkompliziert den Betrieb und produziert inkonsistente Entscheidungen.
Das größere Problem ist, dass komplexe Bedingungen in der Regel Code erfordern. Das Schreiben einer Regel wie „wenn dieser Header vorhanden ist, dieses Cookie fehlt, der Path mit /api/ beginnt, der WAAP-Score über 5 liegt, aber die Quelle kein bekannter Bot ist“ erfordert in den meisten Produkten Skripte, proprietäre Policy-Sprachen oder anbieterspezifische Programmierung.
Die Smart ACL Conditions-Schicht von TR7 ADC löst dieses Problem: Verkehrsentscheidungen werden aus der Benutzeroberfläche mit 60+ Kriterien, Smart Function Chains und AND/OR/NOT-Gruppen definiert. Die Regel wird nicht nur zu einer IP-Liste, sondern zu einer Entscheidungsstruktur, die die Bedeutung des Verkehrs liest.
TR7 behandelt ACL-Bedingungen als grundlegende Einheit von Anwendungs- und Sicherheitsentscheidungen — nicht als Netzwerkadressfilter.
Die Smart ACL Engine geht weit über IP und Port hinaus. Quell-IP, Land, Stadt, Ziel-IP, Zielport, HTTP-Methode, URL, Path, Query, Header, Cookie, Anfrage-Body, Antwort-Body, TLS SNI, TLS-Cipher, TLS-Protokoll, JA3-Fingerabdruck, WAAP-Angriffs-ID, WAAP-Angriffsgruppe, Bot-Klasse, Blacklist-Kategorie und Cache-Status können alle als Bedingungen verwendet werden. Dies ermöglicht Sicherheits- und Routing-Entscheidungen im vollen Anwendungskontext.
Eine ACL kann allein verwendet oder in logischen Gruppen mit anderen ACLs kombiniert werden. Eine innere Gruppe arbeitet mit AND oder OR; eine Bedingung kann invertiert werden, um NOT-Verhalten zu erhalten. Beispiel: „Path beginnt mit /login“ AND „Quellland nicht in der Allow-Liste“ AND „Bot-Score ist hoch“ ABER „Kein bekannter Bot“ — diese Struktur macht komplexe Sicherheitsrichtlinien lesbar.
TR7 Smart Functions wandeln rohe Verkehrswerte in handlungsrelevante Inputs um. Base64-Dekodierung, JSON-Path-Abfrage, JWT-Header/Payload-Parsing, XML-Abfrage, Regex-Match, String-Ersetzung, Lowercase/Uppercase, Digest, IP-Maske, IP-to-Country und Map/List-Lookup-Operationen können alle verkettet werden. Die ACL fragt nicht mehr nur „stimmt dieser Header-Wert überein?“; sie parst JSON innerhalb des Headers, extrahiert einen JWT-Claim oder fragt ein Feld innerhalb des Body ab.
Häufig verwendete Bedingungen werden einmal definiert und über verschiedene Regeln hinweg wiederverwendet. Integrierte oder benutzerdefinierte ACLs wie „Ist es eine statische Dateiendung?“, „Ist ein Auth-Cookie vorhanden?“, „Ist es ein Cache-Hit?“ oder „Wurde es vom WAAP blockiert?“ können über viele Regeln hinweg geteilt werden. Dieses Muster reduziert Regelwiederholungen, zentralisiert Änderungen und senkt das Risiko von Betriebsfehlern.
Smart ACL Conditions wandeln Verkehrssignale in lesbare Bedingungen und durchsetzbare Aktionen über mehr als 60 Kriterien um.
TR7 kann Bedingungen gegen Path, Path+Query, vollständige URL und HTTP-Methode schreiben. Matchtypen können Präfix, Suffix, Teilstring oder Regex sein. Anfragen, die mit /api/ beginnen, der /admin-Path, die POST-Methode oder spezifische URL-Muster, die einen Query-String enthalten, werden alle innerhalb einer einzigen ACL-Definition ausgedrückt.
Anfrage-Header, Antwort-Header, Benutzer-Cookies und Cookies vom Backend können alle innerhalb einer ACL verwendet werden. Routenauswahl basierend auf dem X-Tenant-ID-Header, Weiterleitung zum Login wenn das session_id-Cookie fehlt, Bot-Prüfung basierend auf User-Agent-Inhalt und benutzerdefiniertes Sicherheitsverhalten basierend auf einem Antwort-Cookie werden alle auf dieser Schicht geschrieben.
ACL-Kriterien sind nicht auf Quell-IP oder CIDR beschränkt. Länder-, Stadt- und ASN-basierte Bedingungen können ebenfalls definiert werden. Zugangsbeschränkung auf bestimmte Länder, benutzerdefiniertes Routing für Benutzer aus bestimmten Städten, zusätzliche Verifizierung für Verkehr von bestimmten ASNs oder eine aggressivere Bot-Richtlinie für Rechenzentrum-ASNs werden alle unterstützt.
TLS-SNI, TLS-Cipher, TLS-Protokoll, SNI-Präsenz und JA3-Fingerabdruck-Signale können in Bedingungen einbezogen werden. Clients mit TLS 1.0 einen niedrigeren Vertrauensscore zuweisen, Verbindungen ohne SNI ablehnen, Verkehr der einem bekannten schlechten JA3-Fingerabdruck entspricht zu CAPTCHA senden oder Clients mit schwachen Ciphern in den Überwachungsmodus setzen — all das ist ausdrückbar.
Die ACL kann auf gesampeltem Inhalt aus dem Anfrage- oder Antwort-Body operieren. String- oder Regex-Matching innerhalb des Body wird unterstützt. Prüfung von Transaktionen mit hohem Wert innerhalb eines JSON-Body, Erfassen eines bestimmten Musters in einem Formularfeld, Hinzufügen eines Headers wenn ein bestimmter Marker im Antwort-Body vorhanden ist, oder Rate-Limiting basierend auf API-Payload-Inhalt — all das ist möglich.
Mit Smart Functions können JSON-, XML- und JWT-Inhalte in ACL-Bedingungen umgewandelt werden. JWT payload.role == "admin", transaction.amount > 10000 in einem JSON-Body, Prüfen ob ein bestimmter Path in XML existiert oder Verifizieren des Algorithmus in einem JWT-Header sind alles Bedingungen, die erhebliche Flexibilität für API-Sicherheit und Zugriffsrichtlinien bieten.
Die Smart ACL Engine kann auch WAAP-Entscheidungen als Bedingungen verwenden: WAAP-Angriffs-ID, WAAP-Angriffsgruppe, WAAP-Score, ob der WAAP die Anfrage blockiert hat, ob sie als WAAP-Angriff markiert wurde. CAPTCHA zeigen wenn der WAAP-Score 5+ ist, Anfragen in der SQL-Injection-Gruppe in ein spezielles Log-Format routen oder WAAP-Befunde im Monitor-Modus an ein separates Backend senden sind Beispielszenarien.
Browser-, Mobil-, Bot- und User-Agent-Klassifizierungen können innerhalb einer ACL verwendet werden. Mobilbenutzer an ein mobiles Backend senden, ein niedrigeres Rate-Limit für bot-markierten Verkehr anwenden, Ausnahmen für bekannte Suchmaschinen gewähren und ein anderes Sicherheitsprofil für Nicht-Browser-Clients anwenden können alle definiert werden.
Die ACL Engine kann Verkehrsvolumen- und Größensignale verwenden: Anfragegröße, Antwortgröße, Frontend-Verbindungsanzahl, Anfragerate, Sitzungsrate, Antwortzeit, Anzahl aktiver Backend-Server und HTTP-Statuscode. Neuen Verkehr zu einem Fallback-Pool verschieben, wenn die Anzahl aktiver Backends auf 1 sinkt, oder einen bestimmten Endpunkt cachen, wenn die Antwortzeit steigt, werden beide durch diese Kriterien ausgedrückt.
Map- und listenbasiertes Matching wird unterstützt. Es wird für große IP-Listen, Domain-Listen, URL-Listen, Kunden-ID-Listen oder benutzerdefinierte Schlüssel-Wert-Tabellen verwendet. Unterschiedliches Routing basierend auf einer VIP-Kundenliste, Blockieren von IPs auf einer Sperrliste oder Anwenden einer CORS-Richtlinie basierend auf einer Partner-Domain-Liste werden alle mit diesem Muster verwaltet.
IP-Reputation oder Blacklist-Kategorien können in Bedingungen einbezogen werden. Botnet-, Proxy-, Tor-, Malware- oder Spam-Kategorien können an unterschiedliche Verhaltensweisen gebunden werden. CAPTCHA für eine Open-Proxy-Kategorie-IP bereitstellen, Tor-Exit-Nodes in den Überwachungsmodus setzen oder IPs in der Malware-Kategorie direkt ablehnen sind Beispielanwendungen.
TR7 stellt mehrere gebräuchliche ACLs gebrauchsfertig bereit: Ist es eine statische Dateiendung, Ist ein Auth-Cookie vorhanden, Ist es ein Cache-Hit, Wurde es vom WAAP blockiert. Diese integrierten ACLs verhindern, dass Operatoren ihre am häufigsten benötigten Bedingungen neu schreiben müssen, und halten Regelsets schlanker.
In Edge Cases, bei denen Standard-UI-Kriterien nicht ausreichen, kann ein erfahrener Benutzer eine manuelle Bedingung schreiben. Dies bewahrt die visuelle Regel-Engine von TR7, bietet aber einen Notausgang für Flexibilität. Dieser Modus ist nicht für den täglichen Gebrauch gedacht — er ist für fortgeschrittene Operationen und benutzerdefinierte Integrationen vorgesehen.
Benutzerbasierte Anfragerate, Verbindungsrate und Fehlerrate-Werte können innerhalb einer ACL verwendet werden. In Kombination mit einem JWT-Claim, Cookie, Header oder Benutzer-ID können Mandanten- oder benutzerbasierte Rate-Limit-Richtlinien aufgebaut werden.
Verschiedene Verhaltensweisen können ausgelöst werden, basierend darauf, ob eine Anfrage oder Antwort ein Cache-Hit ist. Auth-Cookie-Präsenz oder HTTP-Auth-Werte können ebenfalls in der ACL Engine verwendet werden. Dies vereint AAM- und ADC-Verhalten unter derselben Regellogik.
Smart ACL Conditions ist nicht nur Regelsyntax — es umfasst Bedingungsgruppen-Struktur, Matchtypen, Update-Modell und Body-Sampling-Limits.
Smart ACL-Bedingungen werden in Gruppen definiert. Bedingungen innerhalb einer Gruppe werden mit AND oder OR kombiniert. Eine Bedingung kann invertiert werden, um NOT-Verhalten zu erhalten. Äußere Gruppen bilden eine breitere logische Struktur. Dieser Ansatz bricht komplexe Richtlinien in kleine, lesbare Teile auf.
Jede ACL wird durch eine eindeutige ID identifiziert. Regeln referenzieren diese ID. Dieselbe ACL kann in verschiedenen Verkehrsregeln, Rate-Limit-Richtlinien, Redirect-Regeln oder Sicherheitsaktionen wiederverwendet werden. Wenn die ACL sich ändert, wird die Aktualisierung automatisch an alle gebundenen Regeln weitergegeben.
Verschiedene Matchtypen werden für textbasierte Bedingungen unterstützt: Präfix-Match, Suffix-Match, Teilstring-Match, Regex-Match und Groß-/Kleinschreibungs-sensitives oder -insensitives Matching. Diese Flexibilität deckt sowohl einfache als auch komplexe Regelstrukturen ab.
Smart Functions können einzeln oder verkettet verwendet werden. Beispiel: JWT-Payload parsen, Rollenfeld extrahieren, in Kleinbuchstaben umwandeln, gegen eine bestimmte Liste vergleichen. Dies wandelt rohe Verkehrsdaten in bedeutungsvolle Entscheidungs-Inputs um.
Anfrage- und Antwort-Body-Inspektion operiert über eine gesampelte Inhaltsgröße. Dies bietet ein ausgewogenes Modell zwischen Performance und Inhaltsbewusstsein. Für sehr große Bodies werden dedizierte Body-Modifikations- oder Maskierungs-Fähigkeiten separat verwendet.
Smart ACL-Bedingungen können auf verschiedenen Schichten verwendet werden. Regeln auf der L7-Seite können bei einer Konfigurationsänderung einen Soft-Reload erfordern. Regeln auf der L3-Firewall-Seite werden durch ihren eigenen Firewall-Sync-Zyklus angewendet. Nicht jede Änderung wird durch denselben Mechanismus angewendet — ein schichtspezifisches Update-Modell gilt.
Gebräuchliche Endungen für statische Inhaltserkennung werden sofort verfügbar geliefert: .css, .js, .jpg, .png, .svg, .woff, .pdf, .mp4, .webp, .docx, .xlsx und ähnliche Dateitypen. Dies wird häufig in Cache-, Log-Reduzierungs- und Rate-Limit-Ausnahme-Szenarien verwendet.
Einige Smart Functions arbeiten direkt mit der integrierten Traffic Engine; einige spezialisierte Funktionen laufen durch eine zusätzliche Konverter-Schicht. Dies gibt JSON-, XML-, JWT- und benutzerdefinierten String-Operationen eine breitere Ausdrucksfläche.
In einer API-Schicht erhalten Admin-Benutzer ein höheres Limit und reguläre Benutzer ein niedrigeres. Smart ACL liest das Rollenfeld aus dem JWT-Payload und wählt die Rate-Limit-Richtlinie entsprechend aus. JWTPAYLOAD(role) == admin → hohes Rate-Limit; sonst → Standard-Rate-Limit.
Eine Anfrage wird vom WAAP als verdächtig markiert, aber nicht klar genug, um direkt blockiert zu werden. Smart ACL bewertet den WAAP-Score und die Bot-Klasse gemeinsam. Wenn wafScore >= 5 AND NOT knownBot, wird CAPTCHA präsentiert.
Mobilbenutzer werden zu einem Backend und Desktop-Benutzer zu einem anderen gerouted. Smart ACL verwendet den User Agent und das Mobile-Klassifizierungssignal. mobile == true → mobiles Backend; mobile == false → Desktop-Backend.
Eine benutzerdefinierte Map bekannter schädlicher Client-Fingerabdrücke wird als ACL definiert. Wenn der eingehende TLS-Fingerabdruck mit dieser Liste übereinstimmt, wird der Verkehr blockiert oder zu CAPTCHA gesendet. ja3 in bad_fingerprint_list → deny / captcha.
In einer Finanz-API wird der Überweisungsbetrag aus dem JSON-Body gelesen. Wenn der Betrag einen definierten Schwellenwert überschreitet, wird auf der AAM-Seite zusätzliche MFA ausgelöst oder die Transaktion zu einem separaten Backend gerouted. JSONQUERY(transaction.amount) > 10000 → Step-up MFA.
Verkehr aus bestimmten Ländern ist normalerweise erlaubt, aber wenn derselbe Verkehr von einem Hosting-ASN kommt und der WAAP-Score erhöht ist, wird eine zusätzliche Challenge angewendet. country in allowedCountries AND asn in hostingProviders AND wafScore >= 4 → challenge.
Sicherheit, Routing und Rate-Limiting in einer Regel-Engine — über 60+ Kriterien, Smart Function Chains und AND/OR/NOT-Gruppen. Lassen Sie uns ein Live-Setup in Ihrer eigenen Umgebung durchgehen.