Der Schlüssel, der nicht da ist

Seit ein paar Wochen hat ein KI-Agent seine Hände im Backend von Paylo. Das echte System, keine Sandbox: Er liest die Produktionsdatenbank, verfolgt eine Rückerstattung, die zu knapp ausfiel, schreibt den Fix und liefert ihn aus. Es ist das fähigste Paar Hände, mit dem ich je gearbeitet habe, und an den meisten Tagen hat er sich seinen Platz verdient, bevor ich meinen ersten Kaffee ausgetrunken habe.

Dann bot er eines Abends, fast beiläufig, an, ein Produktions-Secret zurückzusetzen. Er hätte es gekonnt. Nichts hätte ihn aufgehalten. Und mir wurde klar, mit jener besonderen Klarheit, die sich spät in der Nacht einstellt, dass zwischen meinem gesamten Backend und einer einzigen schlechten Anweisung nur das gute Benehmen des Agenten stand.

Mein Sicherheitsmodell war eine Stimmung.

Der Schieberegler, nach dem alle greifen

Der Instinkt, wenn einem das auffällt, ist, zum Regler zu greifen. Bequemlichkeit am einen Ende, Sicherheit am anderen, dazwischen ein Schieberegler. Sperrt man mehr ab, bewegt man sich Richtung Sicherheit und bezahlt mit Reibung. Lockert man, bewegt man sich Richtung Geschwindigkeit und bezahlt mit Angriffsfläche. Jeder, der je einen Zugriffsantrag gestellt oder drei Tage auf eine Berechtigung gewartet hat, weiß genau, wo dieser Regler meistens landet, und wie wenig Freude beide Seiten daran haben.

Fast hätte ich dasselbe getan. Bestätigungen einbauen. Ihn vor allem Gefährlichen fragen lassen. Genauer hinschauen. All das läuft auf dasselbe hinaus: die gefährliche Macht genau dort zu lassen, wo sie war, und Aufsicht darüberzulegen. Die Macht, das gesamte Backend umzuschreiben, läge weiterhin auf meinem Rechner, eine clevere Anweisung oder einen kompromittierten Prozess von ihrer Verwendung entfernt. Ich würde nur versprechen, besser aufzupassen.

Das Problem mit dem besseren Aufpassen ist, dass es genau bis zu dem Moment funktioniert, in dem man nicht aufpasst.

Was wirklich falsch war

Das eigentliche Problem war, dass ein einziger Zugangsschlüssel alles konnte.

Ein einzelnes Token im Schlüsselbund meines Rechners konnte die Datenbank lesen, Code deployen, Secrets rotieren und die Schlüssel lesen, die sich als meine eigenen Server ausgeben. „Lass den Agenten nachsehen, wie viele Bestellungen ein Shop hat“ und „lass den Agenten still mein Backend ersetzen“ waren mechanisch dieselbe Zugriffsstufe. Die Reichweite der kleinsten Aufgabe war die Reichweite der größten Katastrophe.

Sobald man es so sieht, ergibt der Schieberegler keinen Sinn mehr. Die Frage war, warum ein routinemäßiger Lesezugriff und eine totale Kompromittierung aus demselben Becher tranken.

Zwei Türen statt eines Reglers

Also hörten wir auf zu schieben und fingen an zu trennen.

Die Daten bekamen ihre eigene Tür: eine schmale Datenbankrolle, die Zeilen lesen und schreiben kann und sonst nichts. Sie kann die Struktur der Datenbank nicht verändern, die Secrets nicht lesen, die Interna der Authentifizierung nicht anfassen und ist nirgendwo Administrator. Sie spricht direkt mit den Daten und weiß nicht einmal, dass der Rest des Systems existiert.

Die Infrastruktur, die gefährliche Hälfte, bekam eine ganz andere Tür, und diese Tür wurde vom Gelände geschafft. Das mächtige Token liegt überhaupt nicht mehr auf meinem Rechner. Ich habe es ausgeloggt. Deploys passieren jetzt in einem Continuous-Integration-Runner, wo der Schlüssel in einem Tresor liegt, den der Agent nicht lesen kann. Der Agent kann weiterhin Code ausliefern: Er schreibt die Änderung, committet sie und zieht einen Hebel, der dem Runner sagt, dass er deployen soll. Der Runner hält den Schlüssel. Der Agent hält immer nur den Hebel.

Nichts wurde langsamer. Der Agent liest die Datenbank im selben Atemzug wie immer. Er deployt weiterhin, mehrmals pro Abend. Von meinem Platz aus ist die Bequemlichkeit unberührt. Was sich geändert hat, liegt darunter, wo man es nicht spürt, bis man es braucht.

Der Test ist, was passiert, wenn es schiefgeht

Hier kommt der Teil, der mich tatsächlich schlafen lässt.

Stell dir das Schlimmste vor. Eine versteckte Anweisung in irgendwelchen Daten, die der Agent liest, macht ihn feindselig, oder der Rechner selbst wird kompromittiert. Vorher lag der Hauptgewinn in Reichweite: der Generalschlüssel. Eine Hintertür deployen, die Identität des Servers stehlen, die Secrets rotieren und sich tief genug eingraben, um die Aufräumaktion zu überleben. Eine schlechte Nacht, Totalverlust.

Jetzt ist das Mächtigste, was von diesem Rechner aus erreichbar ist, das Passwort zu einer Datenbankrolle, die Daten anfassen kann und sonst nichts. Das ist nicht nichts. Aber es ist überlebbar, und vor allem lässt es sich mit einer einzigen Zeile beheben. Ein Befehl rotiert das Passwort, und der Eindringling ist ausgesperrt, ohne je etwas deployt, einen Schlüssel gestohlen oder sich einen Rückweg offengelassen zu haben. Ein gestohlener Generalschlüssel ist ein Vorfall, von dem man sich eine Woche lang erholt. Ein gestohlenes, eng begrenztes Passwort ist ein Satz, den man einmal tippt.

Die Sicherheit beruht jetzt darauf, dass der gefährliche Schlüssel nicht im Gebäude ist.

Der Kompromiss, richtig verstanden

Wir sprechen von Bequemlichkeit und Sicherheit als Gegensätzen, weil sie es, als Regler gedacht, auch sind. Jede Raste in die eine Richtung ist eine Raste weg von der anderen, und so wird das ganze Gespräch zu einer Verhandlung darüber, wie viel Schmerz man hinnimmt.

Aber der Regler ist das falsche Instrument. Das meiste, was sich wie ein Zielkonflikt zwischen beiden anfühlt, ist in Wirklichkeit der Preis dafür, einen einzigen Zugangsschlüssel die gesamte Spanne von trivial bis katastrophal abdecken zu lassen. Teilt man diesen Schlüssel entlang der Linie, an der die Gefahr tatsächlich verläuft, löst sich die Spannung größtenteils auf. Die bequemen Dinge bleiben bequem, weil sie nie die gefährlichen Dinge waren. Die gefährlichen Dinge werden dorthin verlegt, wo eine Routineaufgabe sie nie erreichen kann.

Sicherheit kauft man mit der Disziplin, im Voraus zu entscheiden, was das Schlimmste ist, das erreichbar sein darf, und dafür zu sorgen, dass man es überleben kann. Begrenze die Macht auf die Aufgabe. Halte den Generalschlüssel vom Rechner fern. Baue so, dass der Explosionsradius eines Fehlers ein Passwort ist, das du rotieren kannst, und nicht ein Unternehmen, das du neu aufbauen musst.