KI-Sicherheit auf Plattform- und Systemebene
KI-Sicherheit für Unternehmen und AI-Plattformen
SKAFFON sichert die technische Basis Ihrer KI-Systeme: Daten, Modell-Artefakte, GPU- und Kubernetes-Plattformen, Zugriffe, Schnittstellen und die Überwachung im Betrieb. Wir beginnen mit einem Bedrohungsmodell und leiten daraus konkrete Kontrollen ab.
- Für IT-Leitung, CISO und CTO
- Technische Umsetzung, keine Rechtseinstufung
01Auslöser
Woran Sie merken, dass Ihre KI-Systeme ungeschützt laufen
Meist beginnt es nicht mit einem Angriff, sondern mit einer Frage, die niemand beantworten kann.
- KI-Prototypen sind produktiv gegangen, ohne dass Datenzugriff, Modellherkunft und Schnittstellen sicherheitstechnisch bewertet wurden.
- Beschäftigte nutzen externe KI-Dienste mit Unternehmensdaten, weil es keine freigegebene Alternative gibt.
- Ein privates Sprachmodell soll im eigenen Netz laufen (siehe Private LLMs), und offen ist, wie man es abschottet.
- Eine Auflage verlangt belegbare Maßnahmen für KI-Systeme, zum Beispiel aus NIS2, dem AI Act oder von Kunden.
- Niemand überblickt, welche KI-Systeme mit welchen Daten im Unternehmen laufen.
02Schablone
Sechs Schichten, ein Bedrohungsmodell
Die Schablone gliedert ein KI-System in sechs Schichten. Je Schicht zeigt sie Bedrohung, OWASP-Bezug, technische Kontrollen und Nachweis. Sie ist ein Arbeitsblatt für Workshops: Sie streichen, was nicht zutrifft, und ergänzen, was bei Ihnen hinzukommt.
03
Das Arbeitsblatt: Bedrohung, Kontrolle und Nachweis je Schicht
| Schicht | Typische Bedrohung | OWASP-Bezug (2025) | Technische Kontrollen | Nachweis |
|---|---|---|---|---|
| 1. Daten (Training, Fine-Tuning, Wissensquellen) | Manipulierte oder vergiftete Daten; Abfluss sensibler Daten über Datensätze | LLM04, LLM02 | Herkunft und Integrität der Datensätze prüfen, Zugriff nach Datenklasse, Trennung von Roh- und Freigabedaten, Löschkonzept | Datenherkunfts-Inventar, Rollenmatrix |
| 2. Modelle und Artefakte | Manipulierte Modelle oder Abhängigkeiten aus unsicherer Quelle | LLM03, LLM04 | Modelle und Container wie ausführbaren Code behandeln: Quelle festlegen, Prüfsummen, Signatur, Scan, kontrollierte Registry (siehe DevSecOps und Lieferkette) | Modell-Inventar, Signatur- und Scan-Protokoll |
| 3. Serving und Plattform (GPU, Kubernetes) | Unbefugter Zugriff auf Inferenz-Endpunkte; Ressourcenmissbrauch; Seitenwege zwischen Mandanten | LLM10, LLM02 | Authentifizierung und Autorisierung an der Schnittstelle, Quoten und Ratenbegrenzung, Netzsegmentierung, Isolation je Mandant, Härtung des Clusters (siehe Kubernetes Security und GPU Kubernetes) | Netzdiagramm, Policy-Auszüge, Quotenkonfiguration |
| 4. Anwendung (Prompts, Ausgaben, Werkzeuge) | Prompt Injection; unsichere Weiterverarbeitung von Ausgaben; zu weitreichende Rechte der KI | LLM01, LLM05, LLM06, LLM07 | Trennung von Anweisungen und Daten, Ausgabevalidierung, Rechte für Werkzeuge nach Least Privilege, Freigabe durch Menschen bei folgenreichen Aktionen (Details: LLM Security) | Berechtigungsmatrix der Werkzeuge, Testprotokoll |
| 5. Retrieval (Vektorspeicher, Embeddings) | Zugriff auf Inhalte, die der Nutzer nicht sehen darf; Manipulation des Wissensbestands | LLM08, LLM02 | Rechteprüfung bei der Abfrage, Mandantentrennung im Vektorspeicher, Quellenkontrolle | Zugriffstest-Protokoll |
| 6. Betrieb und Überwachung | Unbemerkter Missbrauch; falsche oder irreführende Ausgaben ohne Korrekturweg | LLM09, LLM10 | Logging mit Datenschutz-Vorgaben, Anomalie-Alarme, Rückkanal für Fehlermeldungen, Notfall-Runbook (Modell abschalten, Zugänge sperren) | Alarm-Testprotokoll, Runbook |
04Schicht 3 im Detail
GPU-Cluster und Inferenz-Endpunkte abschotten
Wer ein Modell selbst betreibt, betreibt auch dessen Angriffsfläche: den Inferenz-Endpunkt, die Knoten, auf denen er läuft, und die Wege zwischen Mandanten. Hier setzen wir an der Plattform an, nicht an der einzelnen Anwendung.
- Authentifizierung und Autorisierung an jeder Schnittstelle
- Quoten und Ratenbegrenzung gegen Ressourcenmissbrauch
- Netzsegmentierung und Isolation je Mandant
- Härtung des Clusters, Nachweis über Netzdiagramm, Policy-Auszüge und Quotenkonfiguration
05Maßstäbe
OWASP, NIST und AI Act: woran sich die Kontrollen ausrichten
Drei Quellen, drei Rollen: Bedrohungskatalog, Managementrahmen, Regulierung. Alle Angaben haben wir am 13. November 2026 an den Originalquellen geprüft.
-
OWASP Top 10 für LLM-Anwendungen
Die aktuelle Ausgabe auf genai.owasp.org ist die „2025 Top 10 Risk & Mitigations for LLMs and Gen AI Apps“. Ihre zehn Einträge: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Supply Chain, LLM04 Data and Model Poisoning, LLM05 Improper Output Handling, LLM06 Excessive Agency, LLM07 System Prompt Leakage, LLM08 Vector and Embedding Weaknesses, LLM09 Misinformation, LLM10 Unbounded Consumption.
-
NIST AI Risk Management Framework
Das AI RMF 1.0 (NIST AI 100-1, 26. Januar 2023) gliedert KI-Risikomanagement in die vier Funktionen Govern, Map, Measure und Manage. Seit 26. Juli 2024 gibt es zusätzlich ein Profil für generative KI (NIST AI 600-1). Laut NIST-Seite wird das Rahmenwerk derzeit überarbeitet.
-
EU AI Act
Der AI Act ist die Verordnung (EU) 2024/1689. Für Hochrisiko-Systeme verlangt Artikel 15 ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit, ausdrücklich auch gegen Datenvergiftung, Modellvergiftung, gezielt manipulierte Eingaben und Angriffe auf Vertraulichkeit.
Termine
AI Act: neue Anwendungszeitpunkte für Hochrisiko-Pflichten
Die Verordnung (EU) 2026/1744 (Digital Omnibus on AI, ausgefertigt am 8. Juli 2026) fasst die Zeitpunkte neu: ab dem 2. Dezember 2027 für Systeme nach Artikel 6 Absatz 2 und Anhang III, ab dem 2. August 2028 für Systeme nach Artikel 6 Absatz 1 und Anhang I. Ob Ihr System unter den AI Act fällt und welche Rolle Sie einnehmen, ist eine rechtliche Frage; wir liefern die technische Umsetzung, bewerten keine Einstufung und stellen keine Konformitätsaussage aus.
06Governance
Aus Richtlinien wird durchsetzbare Technik
Das NIST-Rahmenwerk trennt Governance (Verantwortlichkeiten, Richtlinien) von den operativen Funktionen Map, Measure und Manage. Wir setzen den technisch prüfbaren Anteil um. Entscheidungen über Risikoakzeptanz, Einsatzzweck und Verantwortung bleiben bei Ihrer Geschäftsleitung.
- Inventarpflicht durchsetzen: Nur Modelle aus der freigegebenen Registry laufen im Cluster (Admission-Richtlinie, Richtlinien als Code, zum Beispiel mit OPA oder Kyverno).
- Freigabestufen abbilden: Neues Modell, neue Datenquelle, neues Werkzeug durchlaufen eine definierte Pipeline mit Prüfschritten.
- Messbare Kontrollen: Wirksamkeit lässt sich nur prüfen, wenn Tests wiederholbar sind (Testkatalog, Datum, Ergebnis).
07Ablauf
Vom KI-Inventar zur Übergabe an Ihr Team
- 01
KI-Inventar und Datenflüsse erfassen
Welche KI-Systeme laufen, mit welchen Daten, auf welcher Plattform, über welche Schnittstellen, mit welchen Berechtigungen für Werkzeuge und Dienste.
- 02
Bedrohungsmodell aufstellen
Nach der Schablone oben, abgestimmt auf Ihre Architektur und Ihren Schutzbedarf.
- 03
Technische Kontrollen umsetzen
Zugriff und Identitäten, Netzsegmentierung, Absicherung von GPU-Kubernetes-Plattformen, Schutz von Modell- und Datensätzen, Protokollierung, Richtlinien als Code.
- 04
Governance-Kontrollen technisch ausprägen
Freigabestufen für neue Modelle und Datenquellen, Pflicht-Prüfungen in der Pipeline, Nachweise für Ihre Dokumentation.
- 05
Monitoring einrichten
Logging, Metriken und Alarmierung für Modellbetrieb, Anomalien im Nutzungsverhalten und Ressourcenverbrauch.
- 06
Nachweise übergeben
Konfigurationsstände, Testprotokolle, Runbooks und Einweisung Ihres Teams.
08Verantwortung
Was wir übernehmen und was bei Ihnen bleibt
Das setzen wir technisch um
- Plattform-Härtung, Zugriffe, Segmentierung und Richtlinien als Code.
- Nachweise: Konfigurationsstände, Testprotokolle, Runbooks.
- Ihre Richtlinien und Verantwortlichkeiten, abgebildet in Pipelines und Freigabestufen.
Das liegt nicht bei uns
- Rechtliche Einstufung nach dem AI Act oder ein Gutachten: Dafür brauchen Sie eine Kanzlei.
- Zertifizierung oder Konformitätsbestätigung für Ihr KI-System.
- Ein Werkzeug, das Modelle ohne Konzept und Pflege „absichert“.
- Fairness, Ethik oder inhaltliche Modellbewertung statt technischer Sicherheit.
09Arbeitsweise
Wie wir mit Ihren Daten und Systemen umgehen
Wir arbeiten an Konfigurationen, Architektur und Test- oder Staging-Systemen. Produktive Trainings- und Wissensdaten fassen wir nur an, wo es für eine Maßnahme unvermeidbar ist, befristet und nach Ihrer Freigabe. Änderungen an Plattformen gehen nur über Ihre Änderungsprozesse und IaC-Reviews.
10Vorbereitung
Was wir von Ihnen für den Start brauchen
- Überblick über vorhandene und geplante KI-Systeme, Datenquellen und Schnittstellen.
- Schutzbedarf und gesetzliche Vorgaben; Ihre rechtliche Einordnung zum AI Act, soweit vorhanden.
- Lesender Zugriff auf Plattform-Konfigurationen, Registries und Pipelines; Ansprechpersonen für Daten, Modelle und Betrieb.
- Eine entscheidungsbefugte Person für Maßnahmen und Freigaben.
11Angebot
Wovon der Aufwand bei KI-Sicherheit abhängt
Den Aufwand bestimmen vor allem die Zahl der KI-Systeme und Datenquellen, die Plattformen (GPU-Cluster in der Cloud oder auf Ihrer Hardware, Kubernetes, externe Modell-APIs), die Zahl der Mandanten, die Tiefe der Umsetzung (Bedrohungsmodell, Umsetzung, Betrieb) und der Reifegrad von Registry, Pipelines und Logging. Nach einem Erstgespräch erstellen wir ein Angebot mit klar abgegrenztem Leistungsumfang.
12Angrenzende Themen
Wo die Absicherung einer KI-Anwendung weitergeht
Diese Seite behandelt KI-Sicherheit auf Plattform- und Systemebene. Die Anwendungsebene und der Plattformaufbau haben eigene Seiten.
-
LLM Security, Prompt Injection und RAG-Sicherheit
Absicherung einer konkreten LLM-Anwendung gegen Prompt Injection, Datenabfluss über Retrieval und missbrauchte Werkzeugrechte, einschließlich Evaluations- und Red-Team-Verfahren.
-
KI-Infrastruktur
Aufbau und Betrieb der Plattform selbst.
-
KI-Beratung
Beratung zur Einführung von KI im Unternehmen.
-
Cybersecurity-Überblick
Alle Sicherheitsbereiche von SKAFFON im Überblick.
Einstieg
Welche KI-Systeme laufen bei Ihnen?
Beschreiben Sie Ihre KI-Systeme und Ihr Ziel, wir schlagen einen Einstieg vor.