Den Werkzeugserver eines anderen betreiben
Einen fremden Werkzeugserver einzubinden dauert etwa eine Minute. Das ist der gesamte Wert einer Standardschnittstelle — und zugleich der Grund, warum wir heute eine Prüfliste haben: Eine Komponente, die trivial hinzuzufügen ist, ist eine Komponente, die niemand prüft.
Die Minute, die uns Sorgen macht
Ein Werkzeugserver für einen verbreiteten Dienst lässt sich einem laufenden System hinzufügen, indem man einen Befehl und einen Paketnamen in eine Konfigurationsdatei schreibt. Es ist dieselbe Bequemlichkeit, die Paketmanager gebracht haben, mit derselben Folge: Der Prüfschritt, den früher der Aufwand erzwang, ist verschwunden.
Bei uns waren zwei in einer Entwicklungsumgebung, bevor jemand es ansprach. Keiner war bösartig, beide waren in Ordnung. Der Punkt ist, dass niemand entschieden hatte, dass sie in Ordnung sind — denn sie hinzuzufügen fühlte sich nicht an wie das Hinzufügen einer Abhängigkeit.
Eine Werkzeugbeschreibung ist eine Eingabe
Das ist der Teil, den man leicht übersieht. Ein Werkzeugserver beschreibt seine Werkzeuge in Text, und dieser Text geht in den Kontext des Modells, wo er als Hinweis darauf gelesen wird, was zu tun ist. Eine Beschreibung ist damit nicht nur Metadatum, sondern ein Anweisungskanal von dem, der den Server geschrieben hat, zum Modell.
Hou und Kollegen veröffentlichten Anfang 2025 eine Übersicht zum Umfeld und zu den Sicherheitsfragen des Protokolls, die Bedrohungen über den Lebenszyklus eines Servers behandelt. Der Befund, nach dem wir am meisten handeln, betrifft die Beschreibungen — weil es ein Kanal ist, der nicht wie einer aussieht.
| Prüfung vor dem Betrieb | Was sie ausschließt |
|---|---|
| Werkzeugbeschreibungen vollständig lesen | Anweisungen versteckt in Metadaten |
| Version per Digest festlegen | Einen Server, der sich unter einem ändert |
| Mit eigenen Zugangsdaten betreiben | Ein Werkzeug erreicht fremde Daten |
| Kein Netz über den deklarierten Host hinaus | Abfluss über ein Werkzeug |
Was wir prüfen
Wir lesen jede Werkzeugbeschreibung, als wäre sie Nutzereingabe, denn im maßgeblichen Sinne ist sie das. Wir legen die Version fest und spiegeln das Paket, genau wie bei Modellartefakten. Wir geben dem Server eigene Zugangsdaten mit dem engsten Umfang, den seine Werkzeuge brauchen, und begrenzen sein ausgehendes Netz auf den Host, mit dem er sprechen soll.
Nichts davon ist raffiniert, und alles davon wird standardmäßig übersprungen — das ist das Argument dafür, es aufzuschreiben. Eine Prüfliste von zehn Minuten ist der Unterschied zwischen einer geprüften Komponente und einer, die in einer Konfigurationsdatei ankam.
Was wir ablehnen
Jeden Server, der weitergehende Rechte will als sein erklärter Zweck — häufiger als es sein sollte und meist nicht bösartig: Ein Server mit Lesezugriff verlangt ein Token, das auch schreibt, weil sich das leichter dokumentieren ließ.
Jeden Server, den wir nicht in eigener Infrastruktur betreiben können. Ein gehosteter Werkzeugendpunkt bedeutet, dass Kundendaten zu einem Dritten gehen, mit dem wir keinen Vertrag haben — eine Datenschutzfrage, lange bevor sie eine Sicherheitsfrage ist, und die Prüfung, die die meisten Kandidaten ausgeschlossen hat.
Die, die wir selbst schreiben
Weiterhin die meisten. Ein Werkzeug, das das Auftragssystem eines Kunden abfragt, sind ein paar Dutzend Zeilen gegen eine API, die wir ohnehin verstehen — und es zu schreiben geht schneller, als einen Allzweckserver zu bewerten, der mehr kann, als wir wollen.
Die Ausnahmen sind wirklich allgemeine Dinge: ein Dateisystemserver für eine Sandbox, ein Suchwerkzeug über öffentliche Dokumentation. Die übernehmen wir und behandeln sie mit den obigen Prüfungen; das Verhältnis liegt stabil bei etwa neun eigenen zu einem übernommenen.
Der Punkt mit den Zugangsdaten
Ist ein Werkzeugserver kompromittiert oder schlicht fehlerhaft, kann er genau das, was seine Zugangsdaten erlauben. Das ist die ganze Sicherheitsgeschichte — und es heißt, dass die Prüfung eines Servers weit weniger wiegt als der Umfang des Tokens, das wir ihm geben.
Wir hatten das anfangs andersherum. Viel Aufmerksamkeit floss in das Lesen von Quelltext und fast keine in die Frage, was er erreichen kann. Das ist genau verkehrt: Der Quelltext ist eine Momentaufnahme, die sich mit der nächsten Version ändert, und der Rechteumfang ist die Eigenschaft, die unabhängig davon hält.
Was wir Kunden sagen
Dass jedes Werkzeug in ihrem System aufgelistet ist — mit dem, was es kann, und den Zugangsdaten, die es hält — und dass die Liste kurz genug zum Lesen ist. Hat ein System vierzig Werkzeuge, hat niemand vierzig Werkzeuge geprüft, und die ehrliche Antwort ist, die Zahl zu senken statt alle zu beschreiben.
Wir sagen ihnen außerdem, dass das Hinzufügen eines Werkzeugs ein Deployment ist und keine Konfigurationsänderung. Es geht wie jede andere Komponente durch die Prüfung — was genau das verlangsamt, was der Standard schnell gemacht hat, und diese Reibung ist beabsichtigt.
Was wir nicht behaupten
Wir behaupten nicht, unsere Prüfungen fingen einen entschlossenen Angriff. Sie fangen einen überfordernden Server, eine Version, die sich unter uns geändert hat, und eine in einer Beschreibung versteckte Anweisung. Ein gut gemachter Lieferkettenangriff auf einen weit verbreiteten Server ist nichts, was eine Zehn-Minuten-Liste adressiert.
Wir behaupten auch nicht, eigene Werkzeuge zu schreiben sei allgemein sicherer. Für uns ist es sicherer, weil wir Umfang und Oberfläche kontrollieren — und ein Team ohne die Kapazität, ein Dutzend kleiner Server zu pflegen, entschiede sich mit gutem Grund anders.