Traditionelle Traffic-Regeln entscheiden typischerweise basierend auf Host, Pfad, Methode und Header. In modernem API-Traffic liegt der eigentliche Entscheidungswert jedoch meist im JSON-Body. Die Rolle eines Benutzers, die Tenant-Identität, der Transaktionstyp, der Betrag, der Produktcode oder der GraphQL-Operationsname erscheinen möglicherweise überhaupt nicht in der URL.
Dies lässt dem Operator zwei schlechte Optionen. Entweder wird zusätzliche Routing- und Sicherheitslogik in den Anwendungscode verlagert, oder der ADC bleibt blind auf Header- und Pfadebene. Keiner dieser Ansätze ist für moderne API-Sicherheit angemessen.
In Services, die JWT verwenden, besteht dasselbe Problem im Token. Nur der Authorization-Header-Wert ist an der Oberfläche sichtbar; die für die Entscheidung benötigte Rolle, Gruppe, Tenant oder Scope ist im JWT-Payload gespeichert. Wenn diese Felder nicht gelesen werden können, kann die Traffic-Richtlinie keinen Identitätskontext verwenden.
Das richtige Modell besteht darin, den JSON-Body und JWT-Inhalt zu einem nativen Bestandteil der Ausdruckssprache zu machen. JSONPath-Abfragen sollten neben Traffic-Bedingungen, Sicherheitsregeln, Log-Anreicherung und Datenmaskierungsaktionen verwendbar sein — alles an derselben Stelle.
TR7 JSON-Path-Operationen liefert dieses Modell: JSONQUERY, JWTHEADER und JWTPAYLOAD binden API-Inhalt an ADC- und WAAP-Entscheidungen.
TR7 liest JSON-Inhalt über die FX-Ausdrucks-Engine und trägt ihn in Traffic-Regeln, Sicherheitskontrollen, Log-Anreicherung und Antwortbearbeitung ein.
JSONQUERY zielt auf bestimmte Felder im Anfrage- oder Antwort-Body mit einem JSONPath-Ausdruck ab. Diese Felder können dann als Traffic-Bedingungen, ACL-Eingaben oder Log-Werte verwendet werden.
Header- und Payload-Felder in einem JWT können mit derselben JSONPath-Semantik gelesen werden. Rolle, Scope, Tenant oder Benutzeridentität können in Traffic-Entscheidungen eingebracht werden.
Werte im Body werden zu Bedingungen so natürlich wie Pfad- oder Header-Prüfungen. Aktionen können basierend auf `$.tenant_id`, `$.user.role` oder `$.operationName` genauso wie jeder andere Ausdruck ausgewählt werden.
Sensible JSON-Felder können auf der Antwortseite maskiert oder ersetzt werden. Data-Leak-Prevention wird nicht nur in Logs, sondern direkt am an den Client zurückgegebenen Body angewendet.
JSON-Path-Operationen verbindet JSON-Body und JWT-Inhalt mit den Regel-, Sicherheits-, Log- und Maskierungsschichten von TR7.
JSONQUERY fragt direkt verschachtelte JSON-Felder im Body ab. Ausdrücke wie `$.user.role`, `$.items[0].sku` oder `$.payment.amount` können als Regelbedingungen ausgewertet werden. Operatoren können auf Entscheidungsdaten reagieren, die nie in der URL oder in Headern auftauchen. Dies ermöglicht es, API-Traffic nach seinem tatsächlichen Inhaltskontext zu verwalten.
TR7 kann ein aus JSON gelesenes Feld als Bedingung einer Traffic-Regel verwenden. Beispielsweise kann Traffic basierend auf dem `tenant_id`-Wert an verschiedene Backend-Pools geroutet werden. Wenn der `role`-Wert nicht akzeptabel ist, kann die Anfrage abgelehnt werden. Body-bewusste Traffic-Policy wird ohne Modifikation des Anwendungscodes etabliert.
Die JWTPAYLOAD-Funktion kann Claim-Felder im Token lesen. Benutzerrolle, Gruppe, Scope, Tenant oder Anwendungsidentität können so in die Traffic-Entscheidung einbezogen werden. Dies verhindert, dass der Authorization-Header nur als roher Token behandelt wird. TR7 wandelt Token-Inhalt in ein Policy-Signal um.
Die JWTHEADER-Funktion kann Token-Header-Felder lesen. Algorithmus-, Key-ID- oder Token-Typ-Metadaten-Prüfungen können durchgeführt werden. Diese Informationen können in Sicherheitsregeln, Log-Einträgen oder Szenarien mit bedingtem Zugriff verwendet werden. Der Token wird zu einem prüfbaren Objekt, nicht nur zu einem Durchgangswert.
Einige Anwendungen tragen JSON-ähnliche Datenstrukturen in benutzerdefinierten Header-Feldern. TR7 kann diese Felder auch innerhalb der Ausdrucks-Engine als parseable Signale behandeln. Strukturierte Daten in Headern — nicht nur im Body — werden Teil der Regelauswertung. Diese Flexibilität ist wichtig in Legacy-Integrationsszenarien.
In API-Gateway-Szenarien können Werte wie `operation`, `tenant`, `region` oder `product` im Body als Routing-Signale dienen. TR7 kann Traffic basierend auf diesen Feldern an verschiedene Backend-Pools weiterleiten. Dies ermöglicht Multi-Anwendungs- oder Multi-Tenant-Trennung unter einem einzigen Endpunkt. Routing-Logik muss nicht in den Anwendungscode eingebettet werden.
Ausgewählte Felder aus dem JSON-Body oder JWT können zu Log-Zeilen hinzugefügt werden. Benutzer-E-Mail, Tenant-Identität, Transaktionstyp oder Risikoscore können als dedizierte Felder im Log erscheinen. Dies stärkt die SIEM-Korrelation. Das Extrahieren nur der benötigten Felder statt des vollständigen Body-Loggings unterstützt auch die Datenminimerung.
TR7 kann sensible Werte im JSON-Antwort-Body mit Maskierungs- oder Ersetzungsaktionen schützen. Kartennummern, nationale IDs, Patienten-IDs, E-Mail-Adressen oder ähnliche Felder können per Regex oder Pfad gezielt angesprochen werden. Dies reduziert das Datenleck-Risiko ohne Code-Änderungen vom Anwendungsteam zu erfordern. Es arbeitet schichtweise neben der Fähigkeit zur Maskierung sensibler Daten.
Erlaubte oder erforderliche Felder im JSON-Body können an eine Sicherheitsrichtlinie gebunden werden. Unbekannte Felder, fehlende erforderliche Parameter oder übermäßig verschachtelte Strukturen können blockiert werden. Dies reduziert API-Schema-Drift und die Injection-Angriffsfläche. JSON-Inhaltsinspektion geht über negative Sicherheitssignaturen hinaus.
Tief verschachtelte oder übermäßig viele Schlüssel enthaltende JSON-Payloads können Anwendungs- und Parser-Ressourcen erschöpfen. TR7 kann Limits wie JSON-Verschachtelungstiefe und Schlüsselanzahl als Sicherheitsrichtlinie durchsetzen. Dies reduziert die Auswirkung von API-DoS-Versuchen und unerwarteten Body-Strukturen. Limits können pro Endpunkt-Sensitivität angepasst werden.
Wenn JSON nicht geparst werden kann, wird die Anfrage nicht als vertrauenswürdiger API-Body behandelt. TR7 kann Anfragen mit fehlerhaftem JSON ablehnen oder loggen, bevor sie an das Backend weitergeleitet werden. Dies reduziert unerwartete Parse-Fehler auf der Anwendungsebene. Es bietet auch Sichtbarkeit zur Unterscheidung zwischen Angriffstraffic und fehlerhaften Clients.
Ein JSONQUERY-Ergebnis kann zusammen mit String-, Regex-, Map-, Listen-, IP- oder Hash-Funktionen verwendet werden. Beispielsweise wird ein Tenant-Wert aus JSON extrahiert, in einer Map-Tabelle nachgeschlagen, und das Ergebnis steuert eine Routing- oder Block-Entscheidung. Dies macht die JSON-Abfrage zu einem Teil der Policy-Engine, nicht nur zu einem eigenständigen Helfer. Komplexe API-Entscheidungen können im visuellen Regel-Editor ausgedrückt werden.
JSON-Operationen werden zusammen mit Body-Pufferung, Parse-Fehlerbehandlung, JWT-Feldverhalten, Log-Minimierung, Antwortbearbeitung und Leistungslimits betrieben.
Der Body muss lesbar sein, bevor eine JSON-Abfrage ausgeführt werden kann. Body-bewusste Regeln erfordern daher mehr Verarbeitung als Header-Only-Regeln. Sie sollten nur auf Endpunkten angewendet werden, wo sie tatsächlich benötigt werden.
Wenn JSON nicht geparst werden kann, kann die Policy eine Ablehnung, einen Log-Eintrag oder eine andere Aktion erzeugen. Wenn ein API-Endpunkt JSON erwartet, sollte ein fehlerhafter Payload nicht an das Backend weitergeleitet werden. Dieses Verhalten verbessert die Endpunktsicherheit.
JWT-Inhalt lesen und den Token verifizieren sind nicht dieselbe Operation. Wenn JWT-Claim-Werte in Traffic-Entscheidungen verwendet werden sollen, muss die Signaturverifizierung und Trust-Source-Policy separat konfiguriert werden. Andernfalls kann ein Angreifer falsche Claims erstellen.
Nur die erforderlichen Felder statt des vollständigen JSON-Body zu loggen ist der sicherere Ansatz. Felder wie Tenant, Operation oder Status können geloggt werden; sensible Felder sollten maskiert werden. Dies balanciert SIEM-Sichtbarkeit mit Datenschutz.
JSON-Maskierung von Antworten arbeitet am Body, daher sind Antwortgröße und Content-Type wichtig. Leistungs- und Speicherauswirkungen bei sehr großen Antworten sollten geplant werden. Korrektes Targeting von Endpunkten und Feldern ist erforderlich, um sensiblen Datenschutz effektiv anzuwenden.
JSON-Parsing und Pfad-Abfragen kosten mehr als Header-Prüfungen. Wenn mehrere JSON-Abfragen innerhalb derselben Anfrage verwendet werden, ist die Wiederverwendung von Ergebnissen wichtig. Regeln sollten so gestaltet sein, dass unnötiges wiederholtes Parsing nicht auftritt.
Eine SaaS-API kann Traffic von mehreren Tenants auf einem einzelnen Endpunkt empfangen. TR7 kann das `$.tenant_id`-Feld lesen und Traffic für jeden Tenant an den richtigen Backend-Pool weiterleiten.
Der Rollen- oder Scope-Wert innerhalb eines Authorization-Tokens kann gelesen werden. Der Zugriff auf Admin-Pfade kann auf Benutzer beschränkt werden, deren Token den erforderlichen Claim-Wert trägt.
Kartennummern, Identitätsnummern oder in einer API-Antwort zurückgegebene Benutzerdaten können maskiert werden. TR7 reduziert die Exposition sensibler Felder in ausgehenden Antworten ohne Code-Änderungen in der Anwendung zu erfordern.
Wenn ein JSON-erwartender Endpunkt einen fehlerhaften Body erhält, kann TR7 die Anfrage frühzeitig ablehnen. Dies reduziert Anwendungs-Parse-Fehler und verkleinert die Angriffsfläche.
Statt den vollständigen Body zu loggen, werden nur Felder wie `operationName`, `tenant` und `userId` extrahiert. SIEM-Korrelation verbessert sich und Datenminimerung wird gewahrt.
JSONQUERY, JWTHEADER und JWTPAYLOAD wandeln JSON-Body-Felder und JWT-Claims in Regelbedingungen, Log-Einträge und Maskierungsaktionen um. Lassen Sie uns eine Live-Einrichtung auf Ihren eigenen Services durchführen.