LLM-Sicherheit

LLM-Sicherheit ist die spezialisierte Disziplin zum Schutz von Anwendungen, die auf Large Language Models basieren, vor einer einzigartigen Klasse von Bedrohungen, die in der traditionellen Softwaresicherheit nicht existierten. Da Organisationen KI-Chatbots, autonome Agenten und LLM-gestützte Workflows in großem Maßstab einsetzen, wird das Verstehen und Adressieren LLM-spezifischer Schwachstellen zu einer kritischen betrieblichen Anforderung.

Warum LLMs einen neuen Sicherheitsansatz erfordern

Traditionelle Anwendungssicherheit geht von einer klaren Grenze zwischen Code (Anweisungen) und Daten (Benutzereingaben) aus. Eingabevalidierung, parametrisierte Abfragen und Ausgabekodierung funktionieren, indem sie diese Grenze strukturell durchsetzen.

Large Language Models lassen diese Grenze verschwimmen. Sie verarbeiten alles — Entwickleranweisungen, Benutzernachrichten, abgerufene Dokumente, Tool-Ausgaben — als einen einheitlichen Strom natürlichsprachlicher Tokens. Das Modell kann nicht zuverlässig zwischen einem System-Prompt und einer bösartigen Benutzereingabe unterscheiden, die so gestaltet ist, dass sie wie einer aussieht. Diese fundamentale Eigenschaft schafft Angriffsflächen ohne Äquivalent in traditioneller Software.

Zusätzlich sind LLMs fähige, werkzeugnutzende Agenten. Ein verwundbarer Chatbot ist nicht nur ein Inhaltsrisiko — er kann ein Angriffsvektor für die Exfiltration von Daten, die Ausführung nicht autorisierter API-Aufrufe und die Manipulation verbundener Systeme sein.

Die OWASP LLM Top 10

Das Open Worldwide Application Security Project (OWASP) veröffentlicht die LLM Top 10 — die branchenübliche Referenz für kritische LLM-Sicherheitsrisiken:

LLM01 — Prompt Injection: Bösartige Eingaben oder abgerufene Inhalte überschreiben LLM-Anweisungen. Siehe Prompt Injection .

LLM02 — Unsichere Ausgabeverarbeitung: LLM-generierte Inhalte werden in nachgelagerten Systemen (Web-Rendering, Codeausführung, SQL-Abfragen) ohne Validierung verwendet, was XSS, SQL-Injection und andere sekundäre Angriffe ermöglicht.

LLM03 — Trainingsdatenvergiftung: Bösartige Daten, die in Trainingsdatensätze eingefügt werden, verursachen Verschlechterung des Modellverhaltens oder führen Hintertüren ein.

LLM04 — Model Denial of Service: Rechenintensive Eingaben verursachen übermäßigen Ressourcenverbrauch und beeinträchtigen die Dienstverfügbarkeit.

LLM05 — Supply-Chain-Schwachstellen: Kompromittierte vortrainierte Modelle, Plugins oder Trainingsdaten führen Schwachstellen vor der Bereitstellung ein.

LLM06 — Offenlegung sensibler Informationen: LLMs offenbaren vertrauliche Daten aus Trainingsdaten, System-Prompts oder abgerufenen Dokumenten. Siehe Datenexfiltration (KI-Kontext) .

LLM07 — Unsicheres Plugin-Design: Mit LLMs verbundene Plugins oder Tools fehlt eine ordnungsgemäße Autorisierung, was Eskalationsangriffe ermöglicht.

LLM08 — Übermäßige Handlungsbefugnis: LLMs, denen übermäßige Berechtigungen oder Fähigkeiten gewährt werden, können erheblichen Schaden anrichten, wenn sie manipuliert werden.

LLM09 — Übermäßiges Vertrauen: Organisationen versäumen es, LLM-Ausgaben kritisch zu bewerten, wodurch Fehler oder erfundene Informationen Entscheidungen beeinflussen können.

LLM10 — Modelldiebstahl: Unbefugter Zugriff auf oder Replikation proprietärer LLM-Gewichte oder -Fähigkeiten.

Bereit, Ihr Geschäft zu erweitern?

Starten Sie heute Ihre kostenlose Testversion und sehen Sie innerhalb weniger Tage Ergebnisse.

Demo anfragen Anmelden

Zentrale LLM-Sicherheitskontrollen

Privilegientrennung und minimale Autorisierung

Die wirkungsvollste einzelne Kontrolle: Begrenzen Sie, worauf Ihr LLM zugreifen und was es tun kann. Ein Kundenservice-Chatbot benötigt keinen Zugriff auf die Personaldatenbank, Zahlungsabwicklungssysteme oder Admin-APIs. Die Anwendung von Least-Privilege-Prinzipien begrenzt den Explosionsradius eines erfolgreichen Angriffs dramatisch.

System-Prompt-Sicherheit

System-Prompts definieren das Chatbot-Verhalten und enthalten oft geschäftssensible Anweisungen. Sicherheitsüberlegungen umfassen:

• Keine Geheimnisse, API-Schlüssel oder Zugangsdaten in System-Prompts einbinden
• Prompts so gestalten, dass sie gegen Überschreibungsversuche resistent sind
• Das Modell explizit anweisen, Prompt-Inhalte nicht preiszugeben
• Prompt-Vertraulichkeit als Teil regelmäßiger Sicherheitsbewertungen testen (siehe System Prompt Extraction )

Eingabe- und Ausgabevalidierung

Obwohl kein Filter narrensicher ist, reduziert die Validierung von Eingaben die Angriffsfläche:

• Häufige Injection-Muster und anweisungsähnliche Formulierungen in Benutzereingaben kennzeichnen und blockieren
• Modellausgaben validieren, bevor sie an nachgelagerte Systeme übergeben werden
• Strukturierte Ausgabeformate (JSON-Schemas) verwenden, um Modellantworten einzuschränken

RAG-Pipeline-Sicherheit

Retrieval-Augmented Generation führt neue Angriffsflächen ein. Sichere RAG-Implementierungen erfordern:

• Strenge Kontrollen darüber, wer Inhalte zu indizierten Wissensdatenbanken hinzufügen kann
• Inhaltsvalidierung vor der Indizierung
• Alle abgerufenen Inhalte als potenziell nicht vertrauenswürdig behandeln
• Überwachung auf RAG Poisoning -Versuche

Laufzeit-Guardrails

Mehrschichtige Laufzeit-Guardrails bieten Defense-in-Depth über die Modell-Ebenen-Ausrichtung hinaus:

• Content-Moderationsfilter sowohl für Eingaben als auch Ausgaben
• Verhaltensanomaliedetektion
• Ratenbegrenzung und Missbrauchsprävention
• Audit-Logging für forensische Analysen

Regelmäßige Sicherheitstests

LLM-Angriffstechniken entwickeln sich schnell weiter. KI-Penetrationstests und KI-Red-Teaming sollten regelmäßig durchgeführt werden — mindestens vor größeren Änderungen und jährlich als Baseline-Bewertungen.

Verwandte Begriffe

• Prompt Injection — die kritischste LLM-Schwachstelle
• OWASP LLM Top 10 — das umfassende LLM-Sicherheitsrisiko-Framework
• AI Red Teaming — systematische adversarielle Sicherheitstests
• RAG Poisoning — Angriffe zur Kontaminierung von Wissensdatenbanken
• AI Penetration Testing — strukturierte Sicherheitsbewertungen für KI-Systeme