KI & AI Hub · Sicherheit & Infrastruktur

Vom Eingabefeld bis zum KI-Modell:
Angriffsflächen, Datenflüsse und Sicherheitswerkzeuge

KI-Systeme sind keine Inseln. Jede Eingabe, jede API, jede Abhängigkeit ist eine potenzielle Angriffsfläche.

Sicherheit beginnt nicht beim Deployment – sie beginnt beim Design. Diese Wissensseite erklärt, wie Angriffe entstehen, wo Daten gefährdet werden und welche Werkzeuge Entwickler und KI-Verantwortliche kennen müssen: von Attack Surface Analysis und Taint-Analyse über SAST, DAST und Fuzzing bis zu Prompt Injection, Guardrails und OpenRouter als KI-Infrastrukturplattform.

Sicherheit ist kein Feature — sie ist eine Eigenschaft, die von Anfang an eingebaut sein muss.

Los geht's ← KI & AI Hub
Geschützter Datenweg vom Eingabefeld über eine Schnittstelle zum Server und KI-Modell; ein Angriff wird gestoppt.
AI generated
Prozess im Überblick

Wie ein kontrollierter Datenfluss Risiken begrenzt

Eingabe aufnehmen

Externe Eingaben als potenziell unsichere Daten behandeln.

Schritte auswählen · Bewegung pausieren

Was bedeutet Sicherheit für KI-Systeme?

Klassische Softwaresicherheit trifft auf neue KI-spezifische Risiken.

KI-Systeme verarbeiten Eingaben von außen, rufen externe Dienste auf und arbeiten oft mit sensiblen Daten. Damit gelten für sie dieselben Sicherheitsprinzipien wie für klassische Software – aber mit neuen Angriffsvektoren, die die Besonderheiten von Sprachmodellen ausnutzen.

⚔️
Klassische Angriffe
SQL-Injection, XSS, Buffer Overflow, unsichere Abhängigkeiten – treffen auch KI-Systeme, die auf konventioneller Software aufbauen.
🤖
KI-spezifische Angriffe
Prompt Injection, Modellextraktion, Trainingsdaten-Vergiftung (Data Poisoning), adversarielle Eingaben – nutzen Eigenschaften von Sprachmodellen aus.
🏗️
Infrastrukturrisiken
Vendor-Abhängigkeiten, unsichere API-Keys, fehlende Observability, Supply-Chain-Angriffe auf Modelle und Bibliotheken.

Bedrohungsmodellierung: Angriffsflächen kennen

Attack Surface Analysis und Threat Modeling – bevor man absichern kann, muss man verstehen, was gefährdet ist.

Attack Surface Analysis · Angriffsflächen-Analyse
🗺️ Alle Einstiegspunkte kennen
Systematische Bestandsaufnahme aller Stellen, über die ein Angreifer eindringen könnte: Eingabefelder, API-Endpunkte, Datei-Uploads, URL-Parameter, Umgebungsvariablen, externe Bibliotheken und Drittanbieter-Dienste. Je größer die Attack Surface, desto mehr potenzielle Schwachstellen. Ziel: die Angriffsfläche so klein wie möglich halten und alle Entry Points zu kennen.
Threat Modeling · Bedrohungsmodellierung
🧩 STRIDE und KI-spezifische Bedrohungen
Strukturierter Prozess zur Identifikation möglicher Bedrohungen und Angriffswege, bevor ein System gebaut oder deployed wird. Bekannte Methode: STRIDE – Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Im KI-Kontext zählen auch Prompt Injection und Trainingsdaten-Manipulation dazu.
🚧
Trust Boundary (Vertrauensgrenze)
Trennt Bereiche mit unterschiedlichem Vertrauensniveau. Alles jenseits der Grenze – Nutzereingaben, externe APIs, geladene Dokumente – gilt als potenziell nicht vertrauenswürdig und muss geprüft werden, bevor es das System beeinflusst.

Im KI-Kontext: Nutzerdaten dürfen niemals unkontrolliert als Systeminstruktionen behandelt werden. Das ist der Kern des Schutzes vor Prompt Injection.
Prompt Injection Eingabeprüfung Architektur
🚪
Entry Point (Einstiegspunkt)
Jede Stelle, über die Daten von außen ins System gelangen: Formulare, API-Endpunkte, Datei-Uploads, URL-Parameter, HTTP-Header, externe Feeds. Entry Points sind die primären Angriffsvektoren – Daten, die hier ankommen, haben die Trust Boundary noch nicht passiert und müssen validiert werden.
Eingabe API Validierung

Datenfluss und Taint Analysis

Source, Sink, Sanitizer – die drei Schlüsselbegriffe der Taint-Analyse.

Taint Analysis (Taint-Analyse) verfolgt, wie nicht vertrauenswürdige (tainted) Daten von ihrer Herkunft durch das System fließen, bis sie einen sicherheitskritischen Ort erreichen. Das Konzept ruht auf drei Pfeilern:

⚠️
Schwachstellen-Muster: Ein direkter Datenfluss von einer Source zu einer Sink, ohne zwischengeschalteten Sanitizer, ist eine potenzielle Sicherheitslücke. SAST-Tools wie CodeQL oder Semgrep suchen automatisch nach solchen unsanitisierten Taint-Pfaden.

Sanitizer: Zwei unterschiedliche Konzepte

Der Begriff „Sanitizer" bezeichnet in der Softwaresicherheit zwei grundlegend verschiedene Dinge.

🧹
Input-Sanitizing
Sanitizer Typ 1 · Eingabebereinigung
Bereinigung und Validierung von Eingaben, bevor sie verarbeitet oder gespeichert werden. Ziel: schädliche Inhalte wie SQL-Befehle, Script-Code oder versteckte KI-Anweisungen neutralisieren.

Beispiele: HTML-Encoding (verhindert XSS), Prepared Statements (verhindert SQL-Injection), Prüfung auf versteckte Prompt-Injection-Muster.

Merke: Validierung prüft das Format. Sanitizing bereinigt oder kodiert gefährliche Zeichen.
XSS SQL-Injection Taint Analysis Entry Point
🔍
Runtime Sanitizer
Sanitizer Typ 2 · Laufzeit-Instrumentierung
Compiler-Werkzeuge, die ein Programm zur Laufzeit auf Speicher- und Ausführungsfehler überwachen. Völlig anderes Konzept als Input-Sanitizing.

Bekannte Tools:
• AddressSanitizer (ASan): erkennt Buffer Overflow, Use-After-Free
• MemorySanitizer (MSan): findet nicht initialisierten Speicher
• UndefinedBehaviorSanitizer (UBSan): undefiniertes Verhalten

Besonders wertvoll in Kombination mit Fuzzing.
AddressSanitizer Fuzzing Speichersicherheit Laufzeit
Merkhilfe: Input-Sanitizing schützt das System vor gefährlichen Daten. Runtime Sanitizer schützen das System vor gefährlichem Verhalten im Speicher. Beide heißen „Sanitizer" – aber sie arbeiten auf völlig verschiedenen Ebenen.

Sicherheits-Analysetools: SAST, DAST, Fuzzing

Drei komplementäre Verfahren, die zusammen ein breites Sicherheitsnetz bilden.

Verfahren Bedeutung Zeitpunkt Stärke Schwäche
SAST
Static Application Security Testing		 Analysiert Quellcode ohne Ausführung Früh im Code Findet Taint-Pfade, SQL-Injection, XSS im Code Kein Laufzeitverhalten sichtbar
DAST
Dynamic Application Security Testing		 Testet laufende Anwendung von außen Staging / Pre-Prod Findet Laufzeitfehler, Auth-Probleme Kein Quellcode-Zugang nötig – aber auch kein Einblick
Fuzzing
Fuzz-Testing		 Zufallseingaben provozieren Abstürze Laufend / CI Findet unerwartete Grenzfälle und Speicherfehler Braucht Runtime Sanitizer für Sichtbarkeit
🔎
SAST – Statische Analyse
Analysiert Quellcode auf Schwachstellen ohne Programmausführung. Findet Taint-Pfade (Source→Sink ohne Sanitizer), Konfigurationsfehler und Muster. Bekannte Tools: SonarQube, Semgrep, CodeQL.
🏃
DAST – Dynamische Analyse
Testet eine laufende Anwendung von außen, ähnlich einem echten Angreifer. Sendet manipulierte Anfragen, prüft Antworten auf Schwachstellen. Bekannte Tools: OWASP ZAP, Burp Suite. Im KI-Kontext: kann auch Prompt-Injection-Muster und Modell-Endpunkte testen.
🎰
Fuzzing – Zufälliges Testen
Überflutet Schnittstellen automatisch mit zufälligen, malformierten Eingaben, um Abstürze und Schwachstellen zu provozieren. In Kombination mit Runtime Sanitizern (ASan/MSan) besonders effektiv. Im KI-Kontext: Adversarial Fuzzing testet die Robustheit der Eingabeverarbeitung.

Prinzipien sicherer Architektur

Vier Grundprinzipien, die Schaden begrenzen, wenn etwas schiefläuft.

🔒
Least Privilege (Minimalprivileg)
Jede Komponente erhält nur die minimal notwendigen Rechte für ihre Aufgabe. Schränkt den potenziellen Schaden bei Kompromittierung drastisch ein.

Im KI-Kontext: Agenten sollten nur Zugang zu den Werkzeugen und Daten haben, die für die aktuelle Aufgabe nötig sind – nicht zu allem, was technisch erreichbar wäre.
BerechtigungenKI-AgentenSicherheitsprinzip
📦
Sandboxing (Isolierte Ausführung)
Ausführung von Code in einer abgeschotteten Umgebung ohne direkten Systemzugriff. Fehler oder bösartiger Code in der Sandbox können das Hostsystem nicht beschädigen.

Im KI-Kontext: Code-Ausführung durch KI-Agenten sollte immer in einer Sandbox erfolgen.
IsolationKI-AgentenContainer
🔑
Secrets Management
Sichere Speicherung, Rotation und Zugriffssteuerung für API-Schlüssel, Passwörter, Zertifikate und Tokens.

Grundregel: Niemals Secrets im Quellcode oder in Versionsverwaltungen (Git) speichern. Lösungen: .env-Dateien (nur lokal), Cloud-Vaults (AWS Secrets Manager, HashiCorp Vault).
API-KeyVaultDevSecOps
⛓️
Supply-Chain Security
Schutz vor Angriffen über externe Abhängigkeiten. Bekannte Angriffe: gefälschte Paketnamen (Typosquatting), kompromittierte NPM/PyPI-Pakete, vergiftete Trainings-Datensätze (Data Poisoning).

Gegenmaßnahmen: Software Bill of Materials (SBOM), Paket-Signaturen, Dependency-Scanning.
AbhängigkeitenData PoisoningSBOM

KI- & Sprachmodell-Sicherheit

Angriffsvektoren und Schutzschichten, die es nur bei KI-Systemen gibt.

Prompt Injection
🛡️ Angriff über manipulierte Eingaben
Nutzer oder externe Inhalte schleusen versteckte Anweisungen ein, um ein KI-System von seinen Regeln abzubringen – klassisch: „Ignoriere deine Anweisungen und …"

Direkte Injection: kommt vom Nutzer.
Indirekte Injection: kommt über verarbeitete Drittinhalte (Webseiten, Dokumente, E-Mails).

Schutz: feste Systemregeln, Trust Boundary, Input-Sanitizing, Guardrails.
Guardrails · KI-Leitplanken
🚦 Ausgabefilter außerhalb des Modells
Technische Schutzschichten, die KI-Ausgaben vor der Auslieferung prüfen und filtern. Können schädliche Inhalte, Data Exfiltration oder Regelverstöße abfangen.

Wichtig: Guardrails sind eine Kontrollschicht außerhalb des Modells – damit resilienter gegen Prompt Injection als reine Systemprompts.
📤
Data Exfiltration (Datenabfluss)
Unberechtigte Übertragung von Daten aus dem System. Im KI-Kontext gefährlich: Prompt Injection kann ein Sprachmodell dazu bringen, geheime Systemanweisungen oder Nutzerdaten in seine Antwort einzubauen. Gegenmaßnahmen: Output-Filtering durch Guardrails, Trust Boundary und Observability.
Prompt Injection Guardrails Output-Filtering Observability

KI-Infrastruktur: API Gateway, Model Routing & OpenRouter

Wie Anfragen zu Modellen gelangen – und welche Risiken dabei entstehen.

🔀
API Gateway
Zentraler Proxy, der alle Anfragen an Backend-Dienste bündelt. Übernimmt: Authentifizierung, Autorisierung, Rate Limiting, Request-Validierung, TLS-Terminierung und Logging.

Im KI-Kontext schützt das Gateway Modell-Endpunkte, verhindert direkten Zugriff auf Backends und ermöglicht Model Routing.
ProxyRate LimitingAuthentifizierungModel Routing
🔀
Model Routing
Mechanismus, der eingehende Anfragen automatisch an das am besten geeignete KI-Modell weiterleitet – basierend auf Aufgabentyp, Kosten, Latenz oder Sicherheitsanforderungen.

Einfache Anfragen gehen an schnelle, günstige Modelle; komplexe an leistungsfähigere. Plattformen wie OpenRouter implementieren Model Routing als Dienst über mehrere Anbieter hinweg.
OpenRouterKostenLatenzAPI Gateway
🌐
OpenRouter – KI-Infrastrukturplattform
Routing · Modellzugang · Datenschutz · Kosten · Ausfallsicherheit · Vendor-Abhängigkeit
OpenRouter bietet Zugang zu Hunderten von KI-Modellen verschiedener Anbieter (OpenAI, Anthropic, Mistral, Meta, Google u.a.) über eine einheitliche API-Schnittstelle.
🔀 Routing
Anfragen gehen automatisch an das verfügbare Modell – mit Fallback bei Ausfall eines Providers.
💰 Kosten
Verbrauchsbasierte, transparente Preise pro Token. Kostenvergleich über Anbieter hinweg möglich.
🔒 Datenschutz
Logging kann deaktiviert werden – aber Drittanbieter-Risiko bleibt. Datenschutzprüfung vor Produktiveinsatz nötig.
🛡️ Ausfallsicherheit
Fallback auf alternative Modelle bei Provider-Ausfall möglich – aber OpenRouter selbst bleibt Single Point of Failure.
⚠️ Vendor-Abhängigkeit
Ausfälle oder Preisänderungen bei OpenRouter oder den dahinterliegenden Providern treffen alle Anwendungen gleichzeitig.
✅ Empfehlung
Für Produktion: Fallback-Strategie einplanen, Datenschutz prüfen und Vendor-Abhängigkeit dokumentieren.

Observability: Sehen, was passiert

Was man nicht beobachtet, kann man nicht schützen.

Observability · Beobachtbarkeit
📡 Logs, Metriken, Traces – die drei Säulen
Fähigkeit, den internen Zustand eines Systems anhand seiner Ausgaben zu verstehen – ohne das System direkt zu inspizieren.

Logs: Protokoll von Ereignissen (was ist wann passiert?)
Metriken: Zahlen über Zeit (Latenz, Tokenverbrauch, Fehlerquote)
Traces: Anfragen durch das gesamte System verfolgen (welche Komponenten, wie lange?)
📝
Was gehört geloggt?
Eingaben (anonymisiert), Modellantworten, Tokenverbrauch, Latenz, Fehler, Rate-Limit-Treffer und ungewöhnliche Anfragemuster.
🚨
Sicherheitsereignisse
Prompt-Injection-Versuche, ungewöhnlich lange Anfragen, verdächtige Ausgaben und Rate-Limit-Überschreitungen als Sicherheitsereignisse markieren.
💸
Kostenkontrolle
Im KI-Kontext ist Observability auch Kostenschutz: Unerwartete Spitzen im Tokenverbrauch können auf Missbrauch oder fehlerhafte Prompts hinweisen.