Best Practices für Konnektoren
Diese Seite fasst zusammen, was sich im Betrieb bewährt hat. Die Regeln stehen nach Wichtigkeit, die erste ist die, die am häufigsten vergessen wird und am meisten kostet.
1. Standardregel sofort auf verweigert
Abschnitt betitelt „1. Standardregel sofort auf verweigert“Ein Konnektor ist erst dann sauber abgegrenzt, wenn seine Standardregel gesetzt ist. Solange das nicht geschehen ist, entscheidet nicht Ihre Absicht darüber, wer hinter den Konnektor sieht, sondern der Zufall des Konfigurationsstands. Bei einer ERP-Anbindung geht es dabei um sämtliche Kunden, Belege und Personaldaten, die das Dienstkonto sehen kann.
Setzen Sie die Standardregel deshalb im selben Arbeitsschritt auf verweigert, in dem Sie den Konnektor anlegen, und geben Sie erst danach gezielt frei.
2. Wenige Werkzeuge statt vieler
Abschnitt betitelt „2. Wenige Werkzeuge statt vieler“Der Werkzeug-Katalog eines Konnektors wird dem Modell bei jeder einzelnen Nachricht mitgeschickt. Er ist keine einmalige Investition, sondern eine laufende Miete auf jeden Chat.
Die Grössenordnung ist erheblich: Ein umfangreicher Konnektor kann über hundert Werkzeuge anbieten und damit einen beträchtlichen Teil des verfügbaren Kontexts belegen, bevor die erste Frage gestellt ist. Auf den Anwendungsfall beschränkt, bleibt davon oft nur ein kleiner Bruchteil übrig.
Der zweite Effekt ist mindestens so wichtig: Je mehr ähnlich klingende Werkzeuge im Katalog stehen, desto häufiger greift das Modell zum falschen. Ein schmaler Katalog liefert nicht nur günstigere, sondern auch verlässlichere Antworten.
Schalten Sie Werkzeuge deshalb einzeln und auf Nachfrage frei, nicht vorsorglich.
3. Ein Werkzeug, das es nicht gibt, kann nicht aufgerufen werden
Abschnitt betitelt „3. Ein Werkzeug, das es nicht gibt, kann nicht aufgerufen werden“Die verlässlichste Sicherheitsmassnahme ist Weglassen. Ein Modell kann kein Werkzeug versehentlich aufrufen, das gar nicht existiert, und keine Anweisung in einem Dokument kann eines herbeireden.
Eine nur lesende Brücke zu einem Fachsystem führt das vor, siehe Muster C: Es gibt dort bewusst kein Werkzeug für eingreifende Aktionen. Deshalb steht auch nirgends eine Regel, die verhindern müsste, dass jemand einen Server aus dem Chat neu startet. Es geht schlicht nicht.
Genau daran messen Sie einen fremden Konnektor: Welche Werkzeuge exponiert er, und gibt es einen Nur-Lese-Modus? Wenn ein fertiger Server neben dem Lesen auch eingreifende Aktionen anbietet und sich das nicht abschalten lässt, ist ein eigener schmaler Konnektor oft die schnellere Lösung als die Diskussion darüber, wer ihn benutzen darf.
4. Getrennte Dienstkonten statt eines Generalschlüssels
Abschnitt betitelt „4. Getrennte Dienstkonten statt eines Generalschlüssels“Ein Zugangsschlüssel erbt die Rechte seines Kontos im Quellsystem. Ein Schlüssel für alle bedeutet also: die weitesten Rechte für alle, und die Trennung hängt allein an unserer Software.
Legen Sie stattdessen mehrere schmale Dienstkonten an, je eines pro Rechteprofil, und fahren Sie pro Konto eine eigene Instanz des Konnektors. Genau so ist Muster A gebaut: mehrere Instanzen derselben Brücke, je ein eigenes Konto im Zielsystem, je ein eigenes Rechteprofil. Ist eine Freigabe im Panel einmal zu weit gesetzt, sieht eine Person immer noch nur das, was ihr Dienstkonto sehen darf.
Der Nebeneffekt ist ebenfalls wertvoll: Im Protokoll des Quellsystems ist erkennbar, aus welchem Profil eine Abfrage kam.
5. Die Datengrenze gehört ins Quellsystem
Abschnitt betitelt „5. Die Datengrenze gehört ins Quellsystem“Die Versuchung ist gross, eine Grenze im Prompt zu ziehen: „Frage keine Lohndaten ab.“ Das ist keine Grenze, das ist eine Bitte.
Auch eine Filterung auf Argumentebene trägt nicht weit. Viele Werkzeuge nehmen freie Suchausdrücke oder Filterbedingungen entgegen. Was dort alles möglich ist, lässt sich von aussen nicht zuverlässig beurteilen, und jede Filterregel ist ein Wettlauf gegen Formulierungen, an die niemand gedacht hat.
Verlässlich sind nur zwei Ebenen: die Rechte des Kontos im Quellsystem, also das, was das Konto hinter dem Schlüssel dort überhaupt sehen darf, und die Werkzeug-Ebene, weil ein nicht vorhandenes Werkzeug nichts liefern kann. Ziehen Sie die Grenze dort, und behandeln Sie den Prompt als Bequemlichkeit, nicht als Kontrolle.
6. Anmeldung pro Person schlägt Dienstkonto
Abschnitt betitelt „6. Anmeldung pro Person schlägt Dienstkonto“Wenn ein System einen personenbezogenen Zugang über eine Schnittstelle anbietet, nehmen Sie ihn. Dann kennt das Zielsystem die anfragende Person, und ihre dortigen Rechte gelten unverändert. Sie müssen nichts nachbauen, nichts nachpflegen, und ein Rechtewechsel im Quellsystem wirkt sofort auch im Chat.
Eine Anbindung an Ihre Dateiablage funktioniert typischerweise so, siehe Muster B. Der Preis dafür ist, dass jede Person sich einmal verbinden muss und dass die Abstufung dann im Zielsystem gepflegt wird. Das ist der richtige Tausch: Eine feinere Grenze im Zielsystem ist mehr wert als eine gröbere Grenze davor.
Ein Dienstkonto ist die Notlösung für Systeme ohne diese Möglichkeit. Es ist nicht schlecht, aber es verlangt die Regeln 1, 4 und 8 mit Nachdruck.
7. Schlüssel nur als Referenz
Abschnitt betitelt „7. Schlüssel nur als Referenz“Tragen Sie Zugangsdaten niemals im Klartext in die Konfiguration ein, sondern ausschliesslich als Referenz auf einen hinterlegten Schlüssel.
Das ist keine Formsache. Ein Klartextwert in der Konfiguration wäre für jeden lesbar, der die Konfiguration einsehen darf, und würde in Exporten und Sicherungen der Einstellungen mitlaufen.
Behandeln Sie einen einmal hinterlegten Schlüssel deshalb als nicht mehr einsehbar: Ändern heisst überschreiben, und wer den Wert braucht, holt ihn aus dem Quellsystem, nicht aus der Plattform.
8. Pro Person genau eine Instanz desselben Konnektors
Abschnitt betitelt „8. Pro Person genau eine Instanz desselben Konnektors“Mehrere Instanzen desselben Konnektors exponieren identische Werkzeugnamen. Sind bei einer Person zwei davon freigegeben, passiert zweierlei: Der Katalog liegt doppelt im Kontext und kostet bei jeder Nachricht doppelt, und das Modell muss zwischen zwei gleich benannten Werkzeugen raten. Beides ist vermeidbar.
Geben Sie deshalb pro Person genau eine Instanz frei. Braucht jemand ein anderes Rechteprofil, wechseln Sie die Freigabe, statt eine zweite hinzuzufügen. Prüfen Sie danach im Panel, was für diese Person tatsächlich anliegt.
9. Kontextgrösse aktiv managen
Abschnitt betitelt „9. Kontextgrösse aktiv managen“Der Werkzeug-Katalog ist nur die eine Hälfte. Die andere sind die Ergebnisse der Aufrufe. Eine unbedachte Abfrage über die ganze Gerätelandschaft oder eine ungefilterte Trefferliste aus dem ERP füllt den Kontext, verdrängt den Gesprächsverlauf und macht die Antwort schlechter, nicht besser.
Vier Stellschrauben helfen:
- Obergrenzen für die Länge von Werkzeug-Ergebnissen setzen und stehen lassen. Wirkt eine Antwort abgeschnitten, ist das der Schutz bei der Arbeit.
- Konnektoren mit gestuften Antworten bevorzugen. Eine gut gebaute Detailabfrage lädt zuerst nur die Stammdaten und holt umfangreiche Abschnitte erst auf ausdrückliche Anforderung. Das spart bei jeder einzelnen Frage.
- Für Fragen über viele Objekte ein Auswertungswerkzeug statt vieler Einzelabfragen. Zehn Einzelabfragen kosten zehn Ergebnisse im Kontext, eine Auswertung kostet eines.
- Bei werkzeugschweren Agenten den Katalog nicht komplett in jeden Prompt schreiben. Werkzeug-Definitionen lassen sich auch erst bei Bedarf nachladen. Das lohnt sich erst bei sehr vielen Werkzeugen.
10. Konnektoren ausserhalb der EU kennzeichnen
Abschnitt betitelt „10. Konnektoren ausserhalb der EU kennzeichnen“Ein Konnektor führt Daten aus Ihrer Instanz zu einem Anbieter. Liegt dieser Anbieter ausserhalb der EU, ist das eine Aussage über Ihre Datenhaltung, die Sie nicht stillschweigend treffen sollten.
Das gilt auch dann, wenn der Anbieter eine europäische Instanz betreibt: Sobald Daten Ihren eigenen Stack verlassen, ist das eine Verarbeitung bei einem Dritten, und die Rechtslage richtet sich nach dessen Sitz. Ein solcher Konnektor kann eine völlig richtige Entscheidung sein, aber es muss eine bewusste sein.
Deshalb enthält der Auslieferungszustand einer neuen Installation keinen vorkonfigurierten Konnektor. Was angeschlossen wird, entscheiden Sie.
Führen Sie eine kurze Liste, welcher Konnektor Daten wohin gibt, benennen Sie Nicht-EU-Anbindungen ausdrücklich gegenüber Ihren Nutzern und in Ihrer Datenschutzdokumentation, und behaupten Sie für solche Konnektoren nicht, alles bleibe in Europa.
Checkliste vor der Freigabe eines neuen Konnektors
Abschnitt betitelt „Checkliste vor der Freigabe eines neuen Konnektors“Gehen Sie diese Punkte durch, bevor die erste Person den Konnektor benutzt:
- Die Liste der exponierten Werkzeuge ist vollständig gelesen und verstanden.
- Alles, was nicht gebraucht wird, ist abgeschaltet oder gar nicht erst vorhanden.
- Es gibt einen Nur-Lese-Modus, oder es ist begründet, warum Schreiben nötig ist.
- Das Dienstkonto im Quellsystem hat genau die Rechte, die es braucht, und nicht mehr.
- Die Datengrenze ist im Quellsystem gezogen, nicht im Prompt.
- Zugangsdaten stehen ausschliesslich als Referenz in der Konfiguration, nie im Klartext.
- Für den Konnektor greifen Freigaben pro Rolle und Gruppe, oder es ist begründet, warum die Rechte im Zielsystem genügen.
- Die Standardregel steht auf verweigert.
- Die Freigaben sind gesetzt, und pro Person ist nur eine Instanz freigegeben.
- Die Verbindung zum Konnektor ist geprüft.
- Eine Testperson mit engen Rechten sieht nachweislich weniger als eine mit weiten.
- Bei einem Anbieter ausserhalb der EU ist das dokumentiert und kommuniziert.
- Ein Blick ins Protokoll zeigt die erwarteten Aufrufe und Entscheide.