Least Privilege, Isolation und Freigaben

Least Privilege, Isolation und Freigaben

0:00 Autorisierung, die im Prompt steht, ist eine Bitte. Autorisierung im Server ist eine Regel. Diesen Satz haben wir am ersten Tag aufgestellt, und heute lösen wir ihn ein. Nach dem Bedrohungsmodell des vorigen Moduls geht es jetzt um die Gegenmaßnahmen — und zwar um die vier, die tatsächlich etwas bewirken: Eingabevalidierung, minimale Rechte, gebundene Bestätigungen und Isolation.

Least Privilege, Isolation und Freigaben

0:24 Dieses Modul ist das praktischste des dritten Tages. Am Ende steht ein gehärteter Server, und wir wiederholen den Angriff aus Modul 14. Wenn er dann immer noch funktioniert, wissen wir, dass die Maßnahme an der falschen Stelle sitzt — und das ist eine sehr lehrreiche Erfahrung. Deshalb ist die Gegenprobe Teil der Übung und nicht optional.

Eingaben validieren und säubern

0:44 Fangen wir mit der Grundlage an. Sie klingt selbstverständlich und wird trotzdem regelmäßig ausgelassen. Die Spezifikation formuliert das als Pflicht, nicht als Empfehlung: Server müssen alle Werkzeugeingaben validieren, Zugriffskontrollen umsetzen, Werkzeugaufrufe begrenzen und Ausgaben säubern. Vier Verben, alle im Server. Nicht im Client, nicht im Schema allein und schon gar nicht im Modell.

1:09 Das ist wichtig, weil die Versuchung groß ist: Das Schema sieht ja aus wie eine Validierung. Es ist eine Formprüfung — mehr nicht. Oben die Formprüfung, unten der Kommentar mit dem, was das Schema nicht leisten kann. Existiert die Anfrage überhaupt? Darf der Aufrufer sie sehen? Passt der Wert zum gewählten Feld? Das sind drei Fragen, die Zustand und Berechtigung betreffen — und die kann kein Schema beantworten, weil es die Welt nicht kennt.

1:36 Die Fußzeile bringt es auf den Punkt: Das Schema begrenzt die Form, der Server entscheidet über Existenz und Berechtigung. Vier Wege, und die ersten drei kennen Sie aus der klassischen Anwendungssicherheit: Suchbegriffe in einer Abfrage, Pfadangaben aus dem erlaubten Verzeichnis heraus, Bezeichner in einer URL. Der vierte ist neu und wird leicht übersehen: Schemareferenzen, die auf eine fremde Adresse zeigen.

2:01 Die Spezifikation verbietet deshalb ausdrücklich, solche Verweise automatisch aufzulösen — und wenn überhaupt, dann nur mit einer Positivliste und ohne private Adressbereiche. Der erste Punkt ist der aus der Definition: Die Prüfung verlässt sich auf das Schema und kennt keine Fachlogik. Der zweite ist ein Klassiker, den die Spezifikation eigens erwähnt: Pfade werden nicht bereinigt, und schon lässt sich aus dem erlaubten Verzeichnis herausklettern.

2:27 Der vierte ist der, der erst am Ende der Kette wirkt: Die Ausgabe wird nicht gesäubert und trägt fremden Text weiter — direkt ins Kontextfenster des Modells.

Least Privilege und getrennte Identitäten

2:36 Kommen wir zur wirksamsten Maßnahme überhaupt. Sie besteht nicht aus einer Prüfung, sondern aus einer Abwesenheit. Least Privilege heißt hier zweierlei. Erstens: Der Agent bekommt nur die Werkzeuge, die der konkrete Auftrag verlangt. Zweitens: Der Server setzt die Berechtigung des aufrufenden Nutzers selbst durch. Und die Spezifikation gibt dafür ausdrücklich grünes Licht — die Werkzeugliste darf sich nach der vorgelegten Autorisierung richten.

3:05 Das ist erlaubt, weil Zugangsdaten je Anfrage mitkommen und kein Verbindungszustand sind. Ein Nutzer sieht also nur, was er darf. Die radikale Variante, und in vielen Fällen die richtige: zwei Server statt einem. Links der lesende — Suche, Handbuch, Komponenten, breit verfügbar, ohne Bestätigung. Rechts der schreibende — Status setzen, Frist ändern, nur im Änderungsauftrag verbunden, Bestätigung vor jeder Wirkung. Beide mit eigener Dienstidentität.

3:34 Der Vorteil ist unmittelbar: Solange der Agent nur recherchiert, existiert der schreibende Werkzeugsatz für ihn nicht. Keine Prompt Injection der Welt kann ein Werkzeug aufrufen, das nicht da ist. Vier Folgen, und alle vier kommen aus derselben Quelle. Ein gemeinsamer Schlüssel macht jede Wirkung ununterscheidbar. Das Zielsystem protokolliert einen Dienst und keinen Menschen — damit ist jede nachträgliche Untersuchung eine Rekonstruktion.

4:01 Ein entwendetes Token öffnet alles statt eines Ausschnitts. Und der vierte Punkt wird erst im Ernstfall schmerzhaft klar: Ein Widerruf trifft alle Abläufe gleichzeitig. Sie können den Schlüssel nicht sperren, ohne das ganze Team lahmzulegen. Der erste Punkt hebt den Gewinn der Trennung wieder auf: Der schreibende Werkzeugsatz bleibt dauerhaft verbunden. Dann ist die Trennung nur noch Dokumentation.

4:25 Der zweite ist der Fehler, der am häufigsten in Code-Reviews durchrutscht: Die Berechtigung wird im Client gefiltert, im Server aber nicht geprüft. Das sieht in der Oberfläche korrekt aus und ist keine Sicherheit. Und der vierte beschreibt den Normalverlauf, wenn niemand aufräumt: Die Rechte wachsen mit jedem Sonderfall und schrumpfen nie.

Bestätigung vor wirksamen Aktionen

4:44 Jetzt zu der Maßnahme, über die am meisten geredet und die am schlechtesten umgesetzt wird. Die Spezifikation verlangt, dass ein Mensch Werkzeugaufrufe ablehnen können soll, und empfiehlt, die Eingaben eines Aufrufs vor dem Absenden zu zeigen. Genau darauf kommt es an: die Eingaben, nicht nur den Namen. Technisch läuft die Rückfrage über Elicitation im Muster der Multi Round-Trip Requests, das wir in Modul 4 gesehen haben — der Server antwortet mit einem Zwischenergebnis, und der Client besorgt die Zustimmung.

5:14 Fünf Schritte, und der dritte ist der entscheidende: Die Bestätigung wird an genau diese Aktion gebunden. Der OWASP-Leitfaden für KI-Agenten wird hier sehr konkret und nennt sechs Angaben — Akteur, Werkzeug, Ziel, Parameter, Zeitpunkt und Ablaufdatum. Das klingt nach Bürokratie und ist der Unterschied zwischen einer Freigabe und einem Häkchen. Eine Zustimmung ohne Argumente deckt jeden Wert, auch den, den Sie nie gemeint haben.

5:41 Der erste Satz ist der wichtigste des Kapitels: Wer alles bestätigt, prüft nichts. Das ist keine Charakterfrage, sondern eine Eigenschaft von Aufmerksamkeit. Daraus folgt etwas Unbequemes: Wenige, gut gewählte Bestätigungen sind wirksamer als viele. Wer bei jedem Lesezugriff nachfragt, hat nach zwei Tagen ein Team, das reflexhaft zustimmt — und dann geht die eine wichtige Bestätigung im Rauschen unter.

6:06 Der erste Punkt ist der häufigste Umsetzungsfehler: Die Bestätigung zeigt den Werkzeugnamen, aber nicht die Argumente. Dann bestätigen Sie, dass der Status gesetzt wird — welcher Status, an welcher Anfrage, wissen Sie nicht. Der zweite ist der Bequemlichkeitsfehler: Einmal zugestimmt gilt für die ganze Sitzung. Und der dritte ist der Kernsatz dieses Seminars in seiner negativen Form: Die Zustimmung wird im Prompt erbeten statt im Server erzwungen.

Isolation, Begrenzung und Notbremse

6:33 Bleibt die letzte Verteidigungslinie: die Begrenzung dessen, was überhaupt erreichbar ist. Isolation begrenzt, was ein Agent und seine Werkzeuge erreichen können — Dateisystem, Netzwerk, Prozesse. Die MCP-Dokumentation empfiehlt für lokale Server ausdrücklich Sandboxing mit minimalen Vorgaberechten und plattformüblichen Mitteln wie Containern.

6:54 Und sie geht weiter: Clients, die einen lokalen Server mit einem Klick einrichten, müssen vorher den vollständigen Befehl zeigen — ohne Kürzung, mit allen Argumenten. Vier Mittel mit klarer Zuordnung. Sandbox oder Container gegen den Zugriff jenseits des Arbeitsbereichs. Netzwerkregeln gegen den Abfluss an unbekannte Ziele.

7:15 Rate Limits je Identität gegen kaskadierende Fehler — und übrigens auch gegen Kostenangriffe, die OWASP als eigene Bedrohung führt. Und der Kill Switch dagegen, dass ein Fehllauf bis zum Ende läuft. Die Fußzeile nennt die einfachste Variante für lokale Server: stdio nutzen, dann ist der Zugriff ohnehin auf den Client begrenzt.

7:35 Im Vorfall zählt nicht, wer zuständig wäre, sondern wer abschalten darf. Das ist ein Unterschied, der erst dann auffällt, wenn es eilt. Ein Kill Switch ohne benannte Person ist ein Knopf ohne Hand. Dazu gehören die Wiederanlaufbedingungen — wann darf es weitergehen, und wer entscheidet das. Und ohne Protokoll lässt sich hinterher nichts rekonstruieren, was uns zurück zu Modul 13 führt.

8:00 Der erste Punkt beschreibt den Normalzustand in der Entwicklung: Der Server läuft mit den vollen Rechten des Entwicklerkontos. Das ist bequem und wandert erfahrungsgemäß in den Betrieb. Der dritte ist ein Detail mit Folgen: Der Kill Switch stoppt den Agenten, nicht seine laufenden Werkzeuge. Und der vierte ist die Falle, in die jedes Seminar und jede Testumgebung tappt: Die Isolation wird für den Übungsbetrieb abgeschaltet und bleibt es.

Übung

8:25 Jetzt setzen wir um — und machen anschließend die Gegenprobe. Die Gegenprobe ist der eigentliche Inhalt der Übung. Sie führen den Angriff aus Modul 14 erneut aus und weisen nach, welche Maßnahme ihn jetzt stoppt. Nicht welche ihn stoppen sollte — welche es tut. Der Unterschied zwischen diesen beiden Formulierungen ist in der Sicherheitsarbeit der wichtigste überhaupt.

8:48 Vier Dinge: lesende und schreibende Werkzeuge trennen, Berechtigung je Nutzer im Server prüfen, Bestätigung mit Argumenten vor jeder Änderung, und dann der Nachweis. Und der Hinweis auf der Folie ist ernst gemeint: Wenn der Angriff weiterhin gelingt, ist die Maßnahme im Prompt gelandet statt im Server. Das ist kein Vorwurf — es passiert häufig, weil der Prompt die naheliegende Stelle ist. Es ist nur eben die falsche.

9:13 Der erste Punkt ist der, den man im Code sieht und der trotzdem nichts bewirkt: Die Trennung erfolgt logisch im Code, nicht in der Berechtigung. Zwei Funktionen in derselben Datei mit denselben Rechten sind nicht getrennt. Der dritte ist der, auf den ich bestehe: Der Nachweis besteht aus einem Durchlauf und nicht aus einer Behauptung.

9:31 Und der vierte ist die Gegenprobe in die andere Richtung, die man nicht vergessen darf: Nach der Härtung muss der Server für den Normalfall noch benutzbar sein. Sicherheit, die die Arbeit verhindert, wird abgeschaltet.