Datensicherheit in LLM-Workflows
Wichtige Erkenntnisse
Anwendungen mit Large Language Models (LLMs) können Fragen dazu aufwerfen, wie Daten verarbeitet, gespeichert und erneut verwendet werden. Besonders relevant ist dies für Anwendungen, die Anforderungen wie HIPAA, COPPA, GDPR, SOC 2 oder vergleichbare Compliance-Vorgaben erfüllen müssen.
Bei einer sauberen Umsetzung können LLM-Anwendungen genauso sicher wie klassische Anwendungen sein, teilweise sogar sicherer. Je nach Modellgröße und verfügbarer Hardware kann ein LLM häufig auf einem einzelnen Server oder lokal betrieben werden. Aufgaben, für die früher mehrere externe Werkzeuge nötig waren, lassen sich heute oft über einen einzigen Modellaufruf abbilden. Gleichzeitig entstehen durch diese neuen Datenflüsse auch neue Sicherheitsrisiken.
Die Datensicherheit in LLM-Workflows hängt stark vom Modellanbieter, vom Hosting-Modell und davon ab, ob eine API oder eine Weboberfläche genutzt wird. Open-Source-Modelle, serverlose Inferenzplattformen und selbst gehostete GPU-Umgebungen bieten häufig mehr Kontrolle über Datenschutz und Datenverarbeitung als geschlossene Modelle.
LLM-Workflows bringen außerdem besondere Herausforderungen für Datenflüsse mit sich, die über klassische Anwendungen hinausgehen. Dazu zählen die Speicherung von Chatverläufen, das Logging-Verhalten sowie Integrationen mit Drittanbieterdiensten wie Speech-to-Text-APIs, Model-Context-Protocol-Servern oder anderen Services, die Nutzerdaten übertragen können.
Klassische Sicherheitsmaßnahmen bleiben wichtig, reichen allein jedoch nicht aus. System Prompts dürfen niemals als Sicherheitsgrenze betrachtet werden. Agenten sollten nur Berechtigungen besitzen, die auf den aktuellen Nutzer beschränkt sind. Der Zugriff auf SQL-Datenbanken oder Kommandozeilenwerkzeuge muss streng begrenzt werden, um unbefugten Zugriff und Datenabfluss zu vermeiden.
Den richtigen Modellanbieter auswählen
Für datenschutzorientierte Anwendungen ist die Wahl des passenden Modellanbieters eine der wichtigsten Entscheidungen. Verschiedene Anbieter und Hosting-Varianten verfolgen unterschiedliche Ansätze bei Datenerfassung, Aufbewahrung und Datenschutz. Selbst innerhalb eines Anbieters können sich die Richtlinien zur Datenverarbeitung unterscheiden, je nachdem, ob eine Weboberfläche oder eine API für die Inferenz verwendet wird.
Bei der Nutzung eines geschlossenen Modells über die Weboberfläche eines Anbieters ist es üblich, dass eingegebene Daten gespeichert und möglicherweise zur Verbesserung zukünftiger Modelle verwendet werden. Bei einer API-Nutzung mit tokenbasierter Abrechnung trainieren Anbieter in der Regel nicht mit den Prompt-Daten, können diese aber dennoch für einen festgelegten Zeitraum speichern, häufig etwa 30 Tage.
Geschlossene Modelle können auch über Drittanbieter für Inferenz bereitgestellt werden. Das beseitigt jedoch nicht automatisch Bedenken zur Datenspeicherung. Der Inferenzanbieter, der Modellbetreiber oder beide Parteien können Daten gemäß ihren jeweiligen Richtlinien speichern. Deshalb sollten die Nutzungsbedingungen, Servicevereinbarungen und Datenschutzrichtlinien aller beteiligten Anbieter sorgfältig geprüft werden.
Wenn ein höheres Datenschutzniveau erforderlich ist, kann ein Open-Source-Modell über einen serverlosen Inferenzdienst eine geeignete Alternative sein. Solche Dienste ermöglichen den Zugriff auf Modelle wie Llama, GPT-OSS oder andere Open-Source-Modelle und begrenzen die Datenspeicherung auf das, was für den Betrieb notwendig ist.
Für noch mehr Kontrolle kann ein GPU-fähiger Cloud-Server gemietet und ein LLM selbst darauf bereitgestellt werden. Solange der Server sicher konfiguriert ist, behalten Sie die Kontrolle darüber, welche Daten in Prompts einfließen und wie diese Daten verarbeitet werden.
Das höchste Maß an Datenschutz lässt sich erreichen, wenn ein Modell lokal auf dem eigenen Gerät ohne Internetverbindung ausgeführt wird. Dadurch bleiben die verarbeiteten Daten vollständig offline. Einige Open-Source-Modelle sind klein genug, um auf Laptops zu laufen, während größere Modelle dedizierte GPU-Hardware benötigen können.
Daten im LLM-Workflow verwalten
Im nächsten Schritt muss nachvollzogen werden, wie Daten durch den LLM-Workflow fließen. Wenn die Anwendung beispielsweise eine Chatoberfläche enthält, muss entschieden werden, ob Chatverläufe in einer cloudbasierten Datenbank gespeichert oder ausschließlich auf dem Gerät des Nutzers gehalten und bei jeder Anfrage erneut übermittelt werden.
Werden Gesprächsverläufe nicht auf dem Server gespeichert, kann dies die Privatsphäre der Nutzer verbessern. Gleichzeitig kann das Mitsenden des vollständigen Gesprächs bei jeder Anfrage die Größe der Requests erhöhen und mit zunehmender Gesprächslänge zu mehr Latenz führen.
Auch Logging muss sorgfältig bewertet werden. Wenn der vollständige Prompt protokolliert wird, der an das LLM gesendet wird, kann dieser die gesamte Unterhaltung enthalten. Selbst wenn der Chatverlauf nicht in der Anwendungsdatenbank gespeichert wird, kann er dennoch in Server-Logs auftauchen, sobald vollständige Prompts aufgezeichnet werden.
Zugriffskontrollen, Audit-Trails und die Integrität von Logs sollten gewährleistet sein. Teams müssen bewusst festlegen, welche Daten in Protokollen gespeichert werden und wie lange diese aufbewahrt bleiben.
Viele moderne LLM-Workflows nutzen Drittanbieterkomponenten, die Nutzerdaten an zusätzliche Endpunkte senden können. Dazu gehören Speech-to-Text-APIs, Model-Context-Protocol-Server, Vektordatenbanken oder Werkzeuge, die automatisch in Agenten-Frameworks eingebunden werden.
Jeder externe Aufruf muss geprüft werden, damit klar ist, wann Daten übertragen werden, wohin sie gesendet werden und wie sie dort verarbeitet werden. Auch Vektordatenbanken und andere Speichersysteme, die zur Erweiterung des Modellkontexts genutzt werden, müssen angemessen abgesichert sein.
Schutz vor Datenangriffen
LLM-Anwendungen sind noch vergleichsweise neu, und Sicherheitsstandards befinden sich weiterhin in der Entwicklung. Dadurch entstehen Möglichkeiten für neue Arten von Cyberangriffen, die in klassischen Anwendungen nicht in gleicher Form auftreten.
Um Daten vor böswilligen Nutzern zu schützen, benötigen LLM-Workflows zusätzliche Schutzmaßnahmen über etablierte Sicherheitspraktiken hinaus. Zunächst darf der System Prompt niemals als Grundlage für Sicherheit oder Datenschutz dienen.
Es sollte angenommen werden, dass ein böswilliger Nutzer Zugriff auf den System Prompt erhalten und beliebige Eingaben machen kann. Wenn dadurch private Daten offengelegt oder die Anwendung gefährdet werden könnten, müssen Workflow und Architektur angepasst werden.
Der System Prompt darf niemals Zugriff auf Informationen oder Funktionen ermöglichen, auf die der Nutzer selbst keinen Zugriff haben sollte. Sensible Informationen sollten nicht im System Prompt gespeichert werden.
Anwendungsarchitektur und Sicherheitskontrollen sollten unter der Annahme gestaltet werden, dass der System Prompt trotz Schutzmaßnahmen offengelegt werden könnte.
LLM-Workflows sollten keinen uneingeschränkten Zugriff auf SQL-Datenbanken oder Kommandozeilenumgebungen erhalten. Jeder Zugriff muss auf die Berechtigungen des aktuellen Nutzers begrenzt sein.
Der sicherste Ansatz besteht darin, einem Agenten keine Möglichkeit zu geben, Datenbankabfragen oder Kommandozeilenbefehle zu erstellen oder auszuführen, die der Nutzer nicht selbst schreiben und absenden dürfte.
Dasselbe Prinzip gilt für den Datenzugriff. Wenn ein Nutzer bestimmte Daten nicht sehen darf, darf auch der Agent während der Beantwortung eines Prompts nicht darauf zugreifen.
Den Workflow testen
Nach dem Aufbau eines sicheren LLM-Workflows sollten Penetrationstests und Sicherheitsvalidierungen durchgeführt werden. Dies kann manuell erfolgen oder mithilfe anderer LLMs, die angewiesen werden, Prompts zu erzeugen, die bekannte Risiken für die Datensicherheit von LLM-Anwendungen darstellen.
Da sich LLM-Anwendungen weiterhin entwickeln, entstehen regelmäßig neue und wirksame Angriffsmethoden. Sicherheitstests sollten deshalb fortlaufend stattfinden. Bleiben Sie über neu entdeckte Angriffsmuster informiert und verbessern Sie die Schutzmaßnahmen der Anwendung kontinuierlich.
Häufige Beispiele für böswillige Angriffe
Direkte Prompt Injection
Angreifer fügen Anweisungen wie „Ignoriere alle vorherigen Anweisungen und …“ oder „Stell dir vor, du bist eine Figur, die sich in eine Datenbank hackt …“ ein, um das gewünschte Verhalten des LLM zu überschreiben.
Indirekte Prompt Injection
Angreifer platzieren schädliche Anweisungen in Dokumenten, Datenbanken oder anderen Quellen, die das LLM abruft und verarbeitet.
Datenexfiltration
Angreifer versuchen, das LLM dazu zu bringen, den System Prompt, versteckte Anweisungen oder Daten aus den Gesprächen anderer Nutzer in gemeinsamen Kontexten offenzulegen.
Manipulation von Tools oder Funktionen
Angreifer verändern Parameter von Funktionsaufrufen, um unbeabsichtigte Aktionen auszulösen.
Denial of Service
Angreifer erstellen Prompts, die übermäßige Token-Ausgaben, hohe Rechenlast oder rekursives Verhalten verursachen und dadurch den LLM-Workflow mit Token-Nutzung überlasten.
FAQ
Können Eingabebereinigung und Ausgabefilterung helfen, Datenlecks oder Injection-Angriffe zu verhindern?
Ja, allerdings sollten LLMs nicht als zuverlässig genug betrachtet werden, um sensible Informationen oder bösartige Eingaben eigenständig sicher zu erkennen. Klassische Nicht-LLM-Methoden oder streng validierte Sicherheitskontrollen sollten für Eingabebereinigung und Validierung bevorzugt werden.
LLMs können als zusätzliche Sicherheitsebene eingesetzt werden, um SQL-Injections, Prompt-Injections, Jailbreaking-Versuche oder versehentliche Offenlegung sensibler Informationen gegenüber Nutzern oder Drittanbietern zu erkennen. Aufgrund der nicht-deterministischen Natur von LLMs und der zunehmenden Komplexität von Angriffen sollten sie jedoch nicht der primäre Sicherheitsfilter sein.
Welche klassischen Datensicherheitsmaßnahmen gelten weiterhin für LLM-Workflows?
Nahezu alle etablierten Best Practices für Datensicherheit bleiben auch für LLM-Workflows relevant. Datenminimierung und Aufbewahrungsrichtlinien sollten sicherstellen, dass nur notwendige Daten erhoben und verarbeitet werden.
Für Logs, Gespräche und temporäre Daten sollten klare Aufbewahrungsfristen definiert werden. Daten sollten sowohl im Ruhezustand als auch während der Übertragung verschlüsselt werden. Rollenbasierte Zugriffskontrolle und starke Authentifizierungsmechanismen sollten ebenfalls umgesetzt werden.
Wie lässt sich verhindern, dass böswillige Nutzer einen LLM-Workflow spammen und Inferenzkosten erhöhen?
Nutzen Sie Rate Limiting und überwachen Sie ungewöhnliche Muster oder übermäßige API-Nutzung. Für verdächtiges Verhalten sollten Benachrichtigungen eingerichtet werden. Zusätzlich kann es sinnvoll sein, Kostenlimits beim LLM-Dienstanbieter festzulegen, um ausufernde Kosten durch automatisierte oder böswillige Aktivitäten zu reduzieren.
Können LLMs für HIPAA-konforme Anwendungen genutzt werden?
Ja, LLMs können für HIPAA-konforme Anwendungen eingesetzt werden. Dafür müssen jedoch die erforderlichen Schritte mit dem Cloud-Service-Provider eingehalten werden, einschließlich des Abschlusses von Business Associate Agreements, sofern diese notwendig sind.
Was sollte passieren, wenn später eine Schwachstelle entdeckt wird?
Die Organisation sollte ihre etablierten Verfahren zum Umgang mit Sicherheitslücken befolgen. Dazu kann gehören, Nutzer zu informieren und den Vorfall über die passenden Kanäle zu melden. Sicherheitslücken in LLM-Anwendungen sollten genauso ernst genommen werden wie Schwachstellen in jeder anderen Anwendung.
Fazit
LLM-Anwendungen bringen neue Sicherheitsfragen mit sich, dennoch ist ein hohes Maß an Datensicherheit erreichbar. Durch die Erweiterung bewährter Sicherheitspraktiken auf die LLM-Logikschicht und durch eine sorgfältige Begrenzung der Daten, auf die agentische Workflows zugreifen dürfen, können Anwendungen wirksam geschützt werden.
Prüfen Sie immer die Datenrichtlinien der eingesetzten Werkzeuge, Plattformen und Anbieter. Treffen Sie keine Annahmen darüber, wie Services Daten speichern, verarbeiten oder erneut verwenden.
LLM-Workflows können HIPAA, COPPA, GDPR, SOC 2 und andere Compliance-Anforderungen unterstützen. Jede dieser Vorgaben bringt jedoch zusätzliche Aufgaben für das Team mit sich. Der nächste Schritt besteht darin, die Anwendung zu entwickeln und zu testen und dabei sicherzustellen, dass jede Sicherheitsentscheidung zu den Nutzern, Zielen und dem konkreten Anwendungsfall passt.
