Ein zentraler Node-Proxy kann das Provider-Budget eines ganzen Monats über Nacht aufbrauchen, wenn ein kompromittierter Service-Key auf eine freizügige Completion-Route trifft und der Proxy Routing-Angaben des Aufrufers – wie provider=openai und model=$OPENAI_CHAT_MODEL im Request-Body – vertraut.
In unserem laufenden System ruft AcmeSupportApp das Gateway im Auftrag des Tenants t_acme_prod auf; das Gateway leitet die Anfrage an $OPENAI_CHAT_MODEL, $ANTHROPIC_CHAT_MODEL oder $LLAMA_CHAT_MODEL weiter, und ein gemeinsam genutzter semantischer Cache befindet sich in Gateway-Nähe, um bei wiederholten Prompts Token einzusparen.
Bei dem Fehler handelt es sich nicht um einen raffinierten Angriff auf das Modell selbst. Der Angreifer benötigt lediglich einen Key, der die (derzeit eher oberflächliche) Prüfung besteht, und sendet dann eine große Anzahl von Anfragen mit langen Prompts und hohen Ausgabelimits; das Gateway leitet diese weiter, da vor Beginn des Provider-Aufrufs kein verbindliches Budget pro Tenant reserviert wurde.
Wenn der Proxy zudem die ungefilterte Ausgabe des Providers an den Aufrufer zurückgibt, kann derselbe kompromittierte Key unsichere Inhalte in nachgelagerte Ticket-Antworten einschleusen, da an der Gateway-Grenze keine Richtlinien für den generierten Text durchgesetzt werden.
Welche Instanz hätte angesichts dieses Ablaufs die allererste Anfrage ablehnen können – noch bevor Kosten entstanden oder unsichere Ausgaben erzeugt wurden?
Das Gateway ist die einzige Komponente, die sowohl die Identität des Aufrufers als auch die Wahl des Providers gleichzeitig erkennt. Daher können wir hier AcmeSupportApp an t_acme_prod binden und Modelle oder Routen außerhalb dieses Geltungsbereichs ablehnen, noch bevor ein Provider-Key verwendet wird.
Jeder anderen Station in der Kette fehlt eine entscheidende Information. Der Provider sieht nur die Provider-Zugangsdaten des Gateways und kann daher die Tenants innerhalb unserer Plattform nicht unterscheiden; ein Cache sieht nur einen aus dem Anfrageinhalt abgeleiteten Key und kann daher nicht kontrollieren, wer Ausgaben tätigen darf oder welches Modell ein Aufrufer erreichen kann.
Nicht vertrauenswürdige Daten gelangen an mehreren Punkten in das System, selbst wenn die TLS-Verbindung korrekt ist. Request-Header können falsche Identitätsangaben enthalten, wenn wir vom Aufrufer bereitgestellte Tenant-IDs akzeptieren; der Request-Body kann falsche Angaben zu Routing und Modellauswahl enthalten, wenn wir diese berücksichtigen; und die Antwort des Providers ist eine nicht vertrauenswürdige Ausgabe, die gegen Richtlinien verstoßende Inhalte oder strukturierte Felder enthalten kann, welche das Schema verletzen. Hier ist der Anfragepfad mit den markierten Vertrauensgrenzen und Durchsetzungspunkten dargestellt.
Dieses Diagramm veranschaulicht die praktische Rahmenbedingung, auf der der weitere Verlauf dieses Kurses aufbaut. Nur das Gateway kann den Aufrufer authentifizieren, eine anfragespezifische Richtlinie (Policy) auswerten, Kontingente bei einem gemeinsamen Zähler reservieren sowie Prüfungen für Eingaben und gestreamte Ausgaben durchführen, bevor die Antwort an das System des Aufrufers zurückgegeben wird.
Ein Gateway verhält sich auch unter Angriffen berechenbar, wenn an jedem Durchsetzungspunkt ein eindeutiger Ablehnungscode verwendet wird, der noch vor dem nächsten rechenintensiven Schritt generiert wird. Wir verwenden für den gesamten Kurs ein einheitliches Schema für Ablehnungscodes, damit Protokolle, Warnmeldungen und das Client-Verhalten über verschiedene Anbieter hinweg konsistent bleiben.
Fehlende, ungültige, widerrufene oder kompromittierte Zugangsdaten des Aufrufers führen zur Antwort 401 Unauthorized.
Fordert ein authentifizierter Aufrufer eine Route oder ein Modell an, das nicht auf seiner Zulassungsliste (Allowlist) steht, erfolgt die Antwort 403 Forbidden; das Gateway lehnt die Anfrage ab, noch bevor ein Anbieter-Host kontaktiert wird.
Bei Erschöpfung des Ratenlimits oder des Token- und Kostenkontingents wird 429 Too Many Requests (inklusive Retry-After-Header) zurückgegeben, da der Client eine eindeutige Vereinbarung zum Wiederholungsverhalten (Backoff) benötigt und Wiederholungsversuche nicht zu einer Erhöhung der Kosten führen dürfen.
Kann das Gateway die Regeln nicht zuverlässig durchsetzen – etwa weil der Speicher für die gemeinsamen Zähler nicht erreichbar ist oder ein aktiver Circuit Breaker die Prüfungen blockiert –, gibt es 503 Service Unavailable zurück, anstatt die Anfrage zuzulassen und Kosten ohne Zuordnungsmöglichkeit zu verursachen.
Überschreitet der Aufruf beim Anbieter das Timeout des Gateways, gibt dieses 504 Gateway Timeout zurück und streamt keine Teilausgaben als erfolgreiche Antwort.
Wird eine strukturierte Ausgabe verlangt und schlägt die Schema-Validierung der Anbieterantwort fehl, gibt das Gateway 422 Unprocessable Content zurück, damit ein nachgelagerter Parser nicht mit nicht vertrauenswürdigen Feldern arbeiten muss.
Im eingangs beschriebenen Szenario muss die erste Ablehnung bereits bei der Authentifizierung und Richtlinienprüfung am Gateway erfolgen – noch vor der Kontingentreservierung und dem Aufruf des Anbieters. Dies ist notwendig, da nachgelagerte Instanzen nicht mehr über die Informationen verfügen, die zur Zuordnung von Kosten und Berechtigungen zu t_acme_prod erforderlich sind, sobald die Anfrage bereits an den Anbieter weitergeleitet wurde.