Plattform absichern

Plattform absichern

0:00 Willkommen zu Modul elf. Lotsenhaus kann inzwischen eine Menge: Es beantwortet Fragen aus der Wissensbasis, liest Tickets im Störmelder und ändert sie nach Freigabe sogar. Jede dieser Fähigkeiten ist zugleich eine Tür, und in diesem Modul gehen wir einmal mit den Augen eines Angreifers durch das Haus. Wir bauen ein Bedrohungsmodell, schützen die Plattform im Netz, ändern die Standardwerte, die für ein Heimlabor gedacht sind, und dokumentieren, was trotz allem an Risiko übrig bleibt.

0:28 Das Besondere an KI-Plattformen: Manche Angriffe brauchen kein Passwort, sondern nur ein Dokument. Am Ende probieren Sie genau das im Labor aus, kontrolliert und mit Protokoll.

Plattform absichern

0:39 Der fünfte Tag steht unter einem Satz, der sich durch das ganze Modul zieht: Ein Systemprompt bittet um gutes Benehmen, eine Berechtigung erzwingt es. Viele Teams verlassen sich auf freundlich formulierte Anweisungen an das Modell. Die sind nützlich, aber sie sind keine Sicherheitsmaßnahme. Heute geht es um die technischen Grenzen, die auch dann halten, wenn das Modell sich nicht an die Bitte hält.

Bedrohungsmodell

1:02 Wer etwas absichern will, muss zuerst wissen, wogegen. Deshalb beginnen wir nicht mit Einstellungen, sondern mit einer Landkarte der Angriffsflächen. Die vier Felder zeigen, dass der Login nur eine von mehreren Türen ist. Bei den Benutzern denken die meisten an Eingaben im Chat, aber auch Uploads, geteilte Chats und API-Schlüssel gehören dazu.

1:23 Die Dokumente sind die unterschätzte Fläche, denn alles, was das Modell liest, kann Anweisungen enthalten, die Wissensbasis Richtlinien ebenso wie abgerufene Webseiten. Der externe Modellanbieter sieht jeden Prompt, der zu ihm geht, und seine Ausfälle treffen Lotsenhaus direkt. Und die Werkzeugdienste wie stoermelder-tools handeln im Namen der angemeldeten Person.

1:43 Behalten Sie dieses Bild im Kopf, denn auf den nächsten Folien sehen Sie, wie diese Flächen zusammenspielen. Prompt Injection heißt, dass Text das Verhalten des Modells umlenkt. Der Vergleich zeigt zwei Spielarten, und die rechte ist die gefährlichere. Bei der direkten Variante schreibt eine angemeldete Person die Anweisung selbst in den Chat, meist um Regeln aus dem Systemprompt auszuhebeln.

2:07 Das ist ärgerlich, aber sie bewegt sich innerhalb ihrer eigenen Rechte. Bei der indirekten Variante steckt die Anweisung in einem Inhalt, den das Modell liest, etwa in einem versteckten Absatz im Lieferantenmerkblatt LM-2. Der Angreifer muss dafür nicht angemeldet sein. Und er zielt auf etwas anderes, nämlich auf die Werkzeuge und Daten der Person, die zufällig gerade fragt.

2:29 Diese Tabelle ist eine Inventur der Ausgänge, und die Logik steckt in der rechten Spalte: Jede Gegenmaßnahme ist technisch, keine einzige ist eine Bitte an das Modell. Antworten können Wissen an Personen ohne Recht darauf weitergeben, also regeln Gruppen den Zugriff. Werkzeuge können nach einer Injection Daten nach außen senden, also bleiben sie lesend, und Schreiben braucht eine Freigabe.

2:52 Suchanfragen tragen interne Begriffe zu einem externen Anbieter. Antworten können Links enthalten, an denen Daten hängen. Und Logs speichern oft dieselben Inhalte wie die Chats. Die Fußzeile fasst es zusammen: Jeder Weg braucht eine technische Grenze, ein Satz im Systemprompt ist keine. Die vier Fallen dieses Kapitels sind Denkfehler, keine Konfigurationsfehler.

3:14 Der erste: Man sichert den Login ab und vergisst, dass jedes Dokument in der Wissensbasis Anweisungen enthalten kann. Der zweite: Man behandelt den externen Modellanbieter wie einen Teil des eigenen Hauses, obwohl er jeden Prompt im Klartext sieht. Genau dafür gibt es die Datenklassen. Der dritte betrifft die Reihenfolge: Schreibende Werkzeuge werden freigegeben, bevor jemand getestet hat, was ein präpariertes Dokument damit anstellen kann.

3:40 Und der vierte: Logs gelten als harmlos. Dabei können sie dieselben Daten enthalten wie die Chats selbst und brauchen denselben Schutz.

Web- und Netzwerkschutz

3:48 Open WebUI gehört in ein privates Netz. Trotzdem holt es Daten von außen, ruft Webseiten ab und lädt Bilder. Genau an dieser Grenze setzt das nächste Kapitel an. Server-Side Request Forgery, kurz SSRF, lässt sich mit einem Botengang erklären. Jemand kommt nicht selbst ins Archiv, also schickt er einen Boten, der dort ein- und ausgehen darf.

4:11 Übertragen heißt das: Eine Person bringt den Server dazu, eine Adresse abzurufen, die sie selbst gar nicht erreicht, etwa die Datenbank lh-db oder einen internen Metadatendienst. Open WebUI sperrt solche Abrufe auf private Adressen standardmäßig. Die Sperre gilt für Webabruf, Retrieval, Webhooks und das Laden entfernter Bilder.

4:32 Wichtig für ältere Installationen: Der Schalter hieß früher anders. Wer Konfigurationen übernimmt, sollte also prüfen, ob der alte Name noch irgendwo steht. Diese Zeilen aus der Produktionskonfiguration wirken unscheinbar, aber jede schließt eine konkrete Lücke. Die ersten beiden legen fest, unter welcher Adresse Lotsenhaus erreichbar ist und von welcher Webseite aus ein Browser es überhaupt ansprechen darf.

4:57 Dann wird nur noch dem eigenen Reverse Proxy geglaubt, wenn er die Herkunft einer Anfrage weiterreicht. Die Cookie-Einstellungen sorgen dafür, dass die Sitzung nur verschlüsselt übertragen wird, und berücksichtigen die Anmeldung über Keycloak. Darunter folgen Sicherheitsheader für den Browser, die SSRF-Sperre und das Verbot, Weiterleitungen blind zu folgen.

5:17 Die Fußzeile ist der eigentliche Grund für diese Folie: Ohne diese Werte steht vieles schlicht offen. Geheimnisse zu rotieren ist gute Praxis, aber jedes Secret hat eigene Nebenwirkungen, und genau die zeigt die rechte Spalte. Tauschen Sie den zentralen Schlüssel der Plattform, enden alle Sitzungen, und MCP-Verbindungen müssen neu verbunden werden.

5:37 Ein anderer Schlüssel macht gespeicherte OAuth-Tokens unlesbar. Das Client-Secret für Keycloak muss auf beiden Seiten gleichzeitig getauscht werden, sonst kann sich niemand anmelden. Nach dem Tausch des Anbieterschlüssels lohnt ein Blick in die Modellliste, und ein neues Datenbankpasswort verlangt einen Neustart aller Instanzen.

5:56 Planen Sie Rotationen deshalb wie kleine Wartungsfenster. Und setzen Sie den zentralen Schlüssel fest, sonst erzeugt jede neue Instanz ihren eigenen. Vier Fallen, die alle an der Netzwerkgrenze lauern. Bleibt die Liste vertrauenswürdiger Proxys auf dem Stern, kann jeder Client behaupten, von einer beliebigen Adresse zu kommen, und Auditlog wie Sperren werden wertlos.

6:18 Beim Cookie-Attribut SameSite widersprechen sich zwei Seiten der Doku. Die eine empfiehlt strict, die andere lax für SSO. Das ist kein Grund zum Raten, sondern zum Testen mit Keycloak im Labor. Wer die SSRF-Sperre für ein einzelnes Intranet-Wiki aufhebt, öffnet damit auch den Weg zu lh-db und lh-redis. Und eine Anmeldung über vertrauenswürdige Header ohne Proxy, der fremde Header entfernt, lässt jeden als jeden auftreten.

Plattform härten

6:44 Viele Standardwerte von Open WebUI sind für jemanden gedacht, der die Plattform allein zu Hause betreibt. Bei rund neunhundert Beschäftigten sieht die Rechnung anders aus. Dieser Block stammt aus lotsenhaus-betrieb und setzt die Governance-Entscheidungen aus den ersten Modulen in Konfiguration um. Die Grundidee: Alles, was nicht gebraucht wird, ist aus. Niemand registriert sich selbst, neue Konten warten zunächst auf Freischaltung.

7:10 Admins lesen keine fremden Chats, Inhalte werden nicht mit der Community geteilt, direkte Verbindungen und das Durchreichen an die API bleiben gesperrt, und normale Nutzer dürfen keine eigenen Werkzeuge anlegen. Wichtig ist die erste Zeile und die Fußzeile dazu. Manche Werte speichert Open WebUI nach dem ersten Start in der Datenbank, und dann gewinnt dieser Wert.

7:31 Erst die erste Zeile sorgt dafür, dass die Datei das letzte Wort behält. Diese Tabelle zeigt, wie viele Voreinstellungen eher großzügig gemeint sind. Das Muster: Fast alles betrifft die Macht der Administratoren. Standardmäßig sehen Admins alle Chats, umgehen Freigaben für Wissen und Modelle und dürfen alle Chats exportieren.

7:52 In einem Unternehmen ist das keine reine Technikfrage, sondern etwas, das mit dem Betriebsrat geregelt gehört. Das Teilen mit der Community braucht intern niemand. Das Durchreichen an die API bleibt aus, wie es ist. Und die Gültigkeit der Anmeldetoken von vier Wochen wird kürzer gesetzt. Die Fußzeile setzt den Ton: Das Recht, Werkzeuge anzulegen, gilt in der Security Policy als gleichwertig zu root.

8:17 Jetzt eine Ebene tiefer, beim Container selbst. Der rote Faden dieser Schritte: Was der Prozess nicht darf, kann auch ein kompromittierter Prozess nicht. Deshalb läuft das Image nicht als root, sondern mit eigener Benutzer- und Gruppenkennung. Die Produktionseinstellung bleibt aktiv, damit die API-Dokumentation nicht öffentlich erreichbar ist. Jeder Dienst bekommt Grenzen für Speicher und Rechenzeit.

8:42 Codeausführung im Chat ist aus, solange niemand sie braucht. Und ungenutzte Plugins werden abgeschaltet. Die Fußzeile verhindert dabei ein Missverständnis: Dieser Schalter stoppt nur Tools und Functions. Angebundene OpenAPI- und MCP-Server laufen weiter, die müssen Sie gesondert betrachten. Härten ist kein einmaliger Akt, und diese Tabelle beschreibt den laufenden Prozess dahinter.

9:07 Der wichtigste Satz steht ganz oben: Sicherheitskorrekturen erhält nur der aktuelle Stand. Wer eine alte Version festhält, bleibt mit bekannten Lücken allein. Also beobachtet das Plattformteam die Advisories und den Changelog, prüft jede Meldung gegen Lotsenhaus und spielt Updates erst auf der Testinstanz, dann in Produktion ein, mit Sicherung davor.

9:28 Dazu kommen alle Bausteine drumherum, vom Basis-Image über den Proxy bis zu Ollama, jeweils in eigenem Takt. Die Fußzeile zeigt, dass das keine Theorie ist: Ende September 2026 erschienen gleich mehrere Advisories. Vier Fallen, die zeigen, wie leicht Härtung an Details scheitert. Die erste kennen Sie schon: Signup ist in der Datei abgeschaltet, aber ein gespeicherter Wert in der Datenbank überstimmt sie. Die zweite ist ein klassisches Eigentor.

9:55 Wer das Anmeldeformular abschaltet, sperrt auch das Notfallkonto notfall-admin aus, und genau das braucht man, wenn die zentrale Anmeldung ausfällt. Die dritte betrifft Werkzeugrechte für alle Pilotnutzer, obwohl Werkzeugcode mit den Rechten des Servers läuft. Und die vierte ist organisatorisch. Ohne Testsystem werden Updates aufgeschoben, Monat um Monat, und die Lücken bleiben offen. Ein Testsystem ist deshalb selbst eine Sicherheitsmaßnahme.

Restrisiken dokumentieren

10:22 Nicht jedes Risiko lässt sich beseitigen. Was übrig bleibt, muss jemand bewusst tragen, mit Namen und Datum. Darum geht es in diesem Kapitel. Ein Systemprompt ist so etwas wie ein Schild an der Bürotür mit der Aufschrift „Bitte nicht eintreten“. Er sagt, was gewünscht ist, aber er schließt nicht ab. Er kann umgangen werden, und er kann ausgelesen werden. Die OWASP Top 10 for LLM Applications in der Fassung 2026 haben dafür eine eigene Kategorie, die Hidden Context Exposure.

10:53 Gemeint ist: Systemprompts, abgerufene Dokumente und Werkzeugantworten gehören zur Angriffsfläche, auch wenn die Nutzer sie nie sehen. Die Konsequenz ist so einfach wie wichtig. Wer was darf, regeln Rollen, Gruppen und Freigaben, und zwar technisch. Der Systemprompt beschreibt nur das gewünschte Verhalten. Die OWASP-Liste ist hier kein Lehrbuchkapitel, sondern ein Fragenkatalog für Lotsenhaus.

11:18 Das Prinzip: Jede Kategorie wird in eine konkrete Prüffrage übersetzt, die sich im Labor beantworten lässt. Bei Prompt Injection ist es das präparierte LM-2. Bei zu viel Handlungsspielraum ist es die Frage, ob ein Modell ohne Freigabe Tickets ändern kann. Bei Fehlinformation prüfen wir, ob der Richtlinienlotse den Widerspruch zwischen den beiden Fassungen von RL-07 bemerkt. So wird aus einer abstrakten Liste ein Testplan.

11:44 Die Fußzeile ergänzt, dass die Vergiftung von Daten und Modellen bereits im Modul zur Wissensbasis mitgeprüft wird. So sieht ein vollständiger Eintrag im Risikoregister aus, am Beispiel der indirekten Prompt Injection über die Wissensbasis. Die Logik dahinter ist eine Kette. Erst das Risiko, dann die Maßnahmen, die es verkleinern: Nur lh-wissen lädt hoch, der Richtlinienlotse hat keine Werkzeuge, Quellen sind Pflicht.

12:11 Was danach bleibt, steht ehrlich darunter. Eine manipulierte Datei kann Antworten verfälschen, bis es jemand merkt. Die Bewertung begründet, warum das tragbar ist. Und dann die beiden Felder, die am häufigsten fehlen: wer das Risiko trägt und wann es wieder geprüft wird. Die Fußzeile bringt es auf den Punkt. Vier Fallen beim Umgang mit Restrisiken.

12:32 Die erste ist die bequemste: Vertrauliche Regeln oder gar Zugangsdaten landen im Systemprompt, in der Hoffnung, dass sie dort niemand findet. Die zweite ist die OWASP-Liste als Abhakübung. Eine Kategorie ist erst geprüft, wenn jemand den Angriff im Labor tatsächlich versucht hat. Die dritte betrifft die Zuständigkeit. Das Plattformteam kennt die Technik, aber das Risiko tragen muss die fachlich verantwortliche Person, denn sie kennt den Schaden.

12:58 Und die vierte Falle: Ein Werkzeug bekommt Schreibrechte, und niemand erneuert die Freigabe, obwohl sich die Bewertung damit grundlegend geändert hat.

Übung

13:08 Jetzt wechseln Sie die Seite. In dieser Übung greifen Sie Lotsenhaus im Labor an und schreiben die Lücken ehrlich auf. Diese Übung ist kein Hackerwettbewerb. Geübt wird, Angriffe über Inhalte und Werkzeuge zu erkennen, ihre Wirkung zu belegen und daraus Maßnahmen und tragbare Restrisiken abzuleiten. Der Angriff selbst ist vorbereitet: das manipulierte Lieferantenmerkblatt LM-2, ausschließlich auf der Laborinstanz.

13:33 Eigene Angriffstexte gegen echte Systeme sind ausdrücklich tabu. Fertig sind Sie, wenn Ihr Protokoll beide Angriffe mit ihrem Ergebnis zeigt, für jeden eine technische Maßnahme nennt und zwei Restrisiken mit Verantwortung im Register stehen. Ein Angriff, der nicht funktioniert hat, ist dabei genauso ein Ergebnis. Er muss nur ebenso sauber dokumentiert werden.

13:55 Der Ablauf hat drei Phasen. Zuerst beobachten: LM-2 kommt in eine Test-Wissensbasis, und Sie stellen dem Richtlinienlotsen eine ganz harmlose Frage dazu. Notieren Sie, ob die versteckte Anweisung die Antwort verändert und ob die Quelle angezeigt wird. Dann der Ernstfall: Ein Assistent mit Zugriff auf stoermelder-tools liest dasselbe Dokument. Löst das eine Änderung an SM-4711 aus?

14:19 Zuletzt das Absichern, mit einer technischen Maßnahme je Angriff und zwei Einträgen im Register samt OWASP-Kategorie. Das Ergebnis wandert nach lotsenhaus-betrieb, denn im nächsten Modul wird daraus ein Teil der Sicherheitstests für die Abnahme.