LiteLLM sicher betreiben: Der Proxy darf nicht zum Schlüsselbund werden

LiteLLM sollte in Produktion als privilegierter Vermittler betrieben werden: hinter einem authentifizierenden Gateway oder VPN, mit getrennten Provider-Zugängen und ohne direkt erreichbare Administrationswege. Anwendungen erhalten eigene virtuelle Schlüssel; Master Key, Datenbankzugang und Provider-Geheimnisse bleiben außerhalb ihres Zugriffs.

Damit wird der Proxy nicht zum universellen Schlüsselbund. Wird eine Anwendung oder der Vermittler selbst kompromittiert, begrenzen Netzwerkregeln, schmale Berechtigungen, Budgets und getrennt widerrufbare Zugangsdaten den erreichbaren Teil der Modellinfrastruktur.

1. Den Proxy in eine private Netzwerkzone setzen

Nur das Gateway beziehungsweise der VPN-Zugang darf den LiteLLM-Port erreichen. Dort erfolgen TLS-Terminierung und die Prüfung der Dienst- oder Benutzeridentität; Administrationsoberfläche, Schlüsselverwaltung und Statusendpunkte werden zusätzlich auf ein Management-Netz oder eine eigene administrative Identität beschränkt.

Diese Grenze bleibt auch nach einem Update notwendig. Eine Sicherheitsanalyse zu CVE-2026-42208 beschreibt eine vor der Authentifizierung erreichbare SQL-Injection in den Versionen 1.81.16 bis 1.83.6, nennt 1.83.7 als korrigierte Version und empfiehlt für erreichbare Installationen ein API-Gateway oder VPN sowie projekt- oder anwendungsbezogene Provider-Zugänge. Eine unterstützte, nicht betroffene Version ist daher Pflicht, ersetzt aber keine Netzwerkabschottung.

Auch ausgehende Verbindungen werden begrenzt: auf die verwendeten Provider-Endpunkte, die isolierte PostgreSQL-Datenbank, den Secret Store und festgelegte Telemetrieziele. Die Datenbank nimmt nur Verbindungen des Proxys und benannter Wartungsdienste an; ein kompromittierter Prozess erhält keinen allgemeinen Weg in andere Produktionsnetze.

2. Drei Arten von Schlüsseln konsequent trennen

Der Master Key ist ein Administrationsgeheimnis, kein Anwendungsschlüssel. Nur ein kontrollierter Provisionierungsprozess darf damit virtuelle Schlüssel erzeugen, ändern oder widerrufen. Anwendungscode, Notebooks, Fachprojekt-Pipelines und Client-Geräte erhalten ihn nicht.

Für jede Anwendung und Umgebung wird eine eigene virtuelle Identität angelegt. Die LiteLLM-Dokumentation zu virtuellen Schlüsseln beschreibt Modelllisten, Ablaufzeiten, Ausgabenverfolgung, Budgets sowie TPM- und RPM-Grenzen; außerdem lässt sich der Zugang zu Management-Routen über erlaubte Routen einschränken. Produktions-, Staging- und Entwicklungssysteme teilen deshalb keinen Schlüssel, und Anwendungsschlüssel erhalten ausschließlich die benötigten Modell- und API-Routen.

Provider-Zugänge bilden die dritte Ebene. Soweit der jeweilige Anbieter es unterstützt, bekommt jede Anwendung oder Modellgruppe ein eigenes Projekt, minimale Rechte und ein eigenes Ausgabenlimit. Das Deployment bezieht diese Geheimnisse zur Laufzeit aus einem separaten Secret Store; Klartextwerte gehören weder in die LiteLLM-Konfiguration noch in Images, Repositories oder Deployment-Logs.

3. Budgets und Rate Limits belastbar konfigurieren

Die Minimal-Konfiguration enthält nur benannte Modellrouten und verweist für Master Key, Datenbankadresse und Provider-Zugänge auf die Geheimnisverwaltung. Das freigegebene Container-Image wird auf eine konkrete Version oder einen geprüften Digest fixiert. So verändert ein Neustart nicht unbemerkt den ausgeführten Code.

Jeder virtuelle Schlüssel erhält eine Positivliste erlaubter Modelle, eine Ablaufzeit, ein maximales Budget sowie passende RPM- und TPM-Grenzen. Die Werte ergeben sich aus normaler Last und tolerierbarer Schadenshöhe; pauschale Produktionswerte wären irreführend. Reserven für legitime Spitzen dürfen nicht so groß sein, dass eine fehlerhafte Schleife oder ein gestohlener Schlüssel lange ungebremst Kosten erzeugt.

Budgets funktionieren nur mit angebundener Datenbank. Laut der offiziellen Beschreibung der Budgetregeln werden die Ausgaben aus PostgreSQL gelesen; bei einem Betrieb ohne Datenbank greift auch das globale Budget nicht, und Anfragen laufen über den gesetzten Grenzwert hinaus weiter. Die Datenbankverbindung ist deshalb Bestandteil der Schutzfunktion und muss überwacht werden.

4. Die Schutzwirkung mit Negativtests abnehmen

Ein erfolgreicher Modellaufruf belegt nur die Funktion. Die Abnahme muss vor allem zeigen, dass unerlaubte Wege scheitern. Sämtliche Prüfungen beginnen in Staging mit Testkonten und niedrigen Limits.

1. Eine TCP-Verbindung aus einem nicht autorisierten Netz zum internen Proxy-Port muss scheitern; erreichbar bleibt nur der Gateway- oder VPN-Endpunkt.
2. Ein Aufruf von /v1/models ohne Zugangsdaten und mit einem widerrufenen virtuellen Schlüssel darf keine Modellliste liefern.
3. Ein Anwendungsschlüssel fordert ein nicht freigegebenes Modell sowie eine Management-Route an. Beide Aufrufe müssen abgewiesen und als Ereignis erfasst werden.
4. Ein kontrollierter Lasttest überschreitet RPM oder TPM. Danach wird geprüft, ob weitere Anfragen begrenzt werden und das Monitoring den Vorgang erfasst.
5. Ein kleines Staging-Budget wird ausgeschöpft. Kostenpflichtige Aufrufe müssen anschließend ausbleiben; parallel wird ein Ausfall der Datenbank simuliert, ohne daraus einen offenen Produktionspfad zu machen.
6. Repository, Deployment-Artefakte, Container-Umgebung und Logs werden auf eingebettete Master- und Provider-Schlüssel geprüft.

Ein synthetischer Request kontrolliert regelmäßig den vollständigen Weg über Gateway, Proxy und einen begrenzten Testzugang. Direkte Provider-Aufrufe oder ein Weg am Gateway vorbei sind kein zulässiger Fallback, weil sie Authentifizierung, Budgetierung und Protokollierung umgehen würden.

5. Anomalien erkennen und Schlüssel rotieren

Das Monitoring trennt mindestens Aufrufe und Kosten nach virtuellem Schlüssel, Team, Modell und Provider. Hinzu kommen Fehlerrate, abgewiesene Authentifizierungen und Rate-Limit-Ereignisse. Auffällig sind neue Quellnetze, erstmals verwendete Modelle, abrupte Kosten- oder Tokenanstiege sowie administrative Änderungen außerhalb eines freigegebenen Fensters.

Schwellenwerte werden pro Workload aus der eigenen Grundlast abgeleitet: Ein nächtlicher Batch hat ein anderes Muster als ein interaktiver Assistent. Authorization-Header und Schlüsselwerte werden vollständig aus Logs entfernt. Prompt- und Antwortinhalte sollten nur gespeichert werden, wenn Zweck, Zugriff, Aufbewahrung und Datenschutz geklärt sind; für viele Alarme genügen Schlüssel-ID, Modell, Zeitpunkt, Kosten, Status und Quellidentität.

Der Rotationsplan nennt für jedes Geheimnis Eigentümer, Zweck, Umgebung, Ablauf und Widerrufsweg. Bei regulärer Rotation wird zuerst ein gleich oder enger berechtigter Provider-Schlüssel erzeugt, als neue Secret-Version ausgerollt und mit einem synthetischen Request geprüft. Erst danach wird der alte Schlüssel beim Anbieter widerrufen; virtuelle Anwendungsschlüssel und der Master Key werden getrennt behandelt.

Ein Leak-Verdacht, eine kritische Proxy-Lücke oder ein Artefakt unklarer Herkunft löst die Rotation sofort aus. Abgeschlossen ist sie erst, wenn alte Secret-Versionen deaktiviert, laufende Jobs und Caches berücksichtigt, der Widerruf beim Anbieter geprüft und das Inventar aktualisiert wurden. So bleibt LiteLLM ein kontrollierter Vermittler, dessen Kompromittierung nicht automatisch sämtliche Modellkonten freilegt.

Lesen Sie auch:

• KI-Agenten sicher ausführen: Die Sandbox allein reicht nicht
• SAFE oder Wandeldarlehen: Der schnellere Vertrag kann später teurer werden
• Microsoft und HUMAIN schicken Ingenieure zum Kunden – das Modell ist der Engpass