19. Nov. 2025
Operationalisierung von KI-Lösungen: Security-by-Design
PoCs und MVPs zeigen, was möglich ist – im Produkt zählt eine sichere Umsetzung, gerade vor dem Hintergrund zunehmender Hackerangriffe. Security-by-Design wird dadurch zur geschäftskritischen Voraussetzung. Ohne sie drohen Ausfälle, Datenabflüsse, Vertrauensverlust und Compliance-Verstöße.
Im dritten Teil unserer Blog-Serie zeigen wir wie Security-by-Design in KI-Lösungen effektiv umgesetzt werden kann. Basierend auf einem Fundament an Best-Practices werden abhängig vom individuellen Bedrohungsszenario Security-Maßnahmen abgeleitet und umgesetzt. Des Weiteren geben wir einen Leitfaden mit den relevantesten Best-Practices zu den in der Blog-Serie adressierten Themen.
Sicherheitsanforderungen im MLOps-Kontext
Sicherheitsanforderungen an Software-Lösungen sind vielseitig wie z.B. in NIS 2 [1] definiert, u.a. Zugangskontrollen, Datenverschlüsselung, und Sicherheit der Software-Lieferkette (Supply-Chain). Diese sind auch für KI-Lösungen relevant.
Daneben geht Sicherheit in KI-Lösungen weit über die klassischen Ziele Vertraulichkeit, Integrität und Verfügbarkeit hinaus. Hinzu kommen z.B. Datenintegrität, Schutz geistigen Eigentums der Modelle (z.B. vor Model-Diebstahl) sowie Privatsphäre (z.B. Membership-Inference) und sichere Schnittstellen. Aktive Bedrohungen reichen vom Data- und Model-Poisoning über Inference- und Exfiltrationsangriffe bis zu Prompt Injection– und Missbrauchsszenarien bei angebundenen Sprachmodellen [2]. Angreifer verfolgen dabei vielfältige Ziele wie Verfügbarkeit, Integrität, Privatsphäre, gezielten Missbrauch oder Kompromittierung der Lieferkette [2].
Praxisbeispiel für ein sicherheitsrelevantes Assistenzsystem:
Für einen öffentlichen Träger implementieren wir ein Assistenzsystem, das den Zugriff auf Daten von Nutzern auf verschiedenen Hierarchieebenen erlaubt. Es werden teils sensible und nutzerbezogene Daten verarbeitet. Das System hat >70.000 Nutzer*innen Deutschlandweit. Es ist an verschiedene interne Datenbanken angeschlossen und kann mittels Retrieval Augmented Generation (RAG) auf diese zugreifen.
Prompt Injection:
Ein LLM könnte durch eine geschickt formulierte Anfrage auf interne Daten einer anderen eigentlich geschützten Datenquelle zugreifen. Ohne Schutzmaßnahmen könnten so sensible Daten preisgegeben werden.
Security-by-Design im Lebenszyklus
Security muss über den gesamten ML-Lebenszyklus verankert werden – von der Datenerhebung und -bereitstellung über Training und Modellmanagement bis hin zu Produktion und Decommissioning. Bereits in frühen Projektphasen sind klare Governance-Regeln, Verantwortlichkeiten und RBAC-Policies (Role-Based Access Control) festzulegen: Im Praxisbeispiel: Wo sind welche Arten von Daten abgespeichert, sind diese sensibel, sind etwa Secrets außerhalb eines Secret Stores gespeichert? Welche Person ist verantwortlich für welche Datenbank/Collection? Wer darf welche Daten sehen, Modelle registrieren, fine-tunen oder Produktionsendpunkte aufrufen?
Praxis-Tipp: Werkzeuge wie Model-Registries (u.a. in ML-Flow, Azure Databricks) mit Nutzerverwaltung, Versionskontrolle, Signaturen und nachvollziehbarer Provenienz sowie Secrets-Manager gehören zur Standard-Ausstattung und wurden auch im Beispiel mittels MLFlow umgesetzt. Diese organisatorischen und technischen Maßnahmen unterstützen zudem die Einhaltung von Vorschriften und Standards (z.B. Pflichten aus der DSGVO, dem EU-AI-Act oder ISO/IEC 42001 für KI-Managementsysteme).
Genauer: diese Registries stärken die Sicherheit, indem sie strenges Rollen- und Rechtemanagement nach dem Least-Privilege-Prinzip auf Modelle, Versionen und Aktionen wie Registrieren, Promoten oder Löschen erzwingen. Sie sichern die Integrität durch Versionierung, unveränderliche Artefakte und Hash-basierte Referenzen, sodass Manipulationen sichtbar werden und sich zuverlässig rückgängig machen lassen, und sie liefern eine klare Provenienz vom Code über Daten und Features bis zum trainierten Modell. Gleichzeitig schaffen sie mit vollständigen Audit-Trails und definierten Stage-Gates von Staging bis Produktion eine belastbare Change- und Release-Governance, inklusive Reviews und automatisierten Policy-Prüfungen etwa für Qualitätsmetriken, Bias-Checks oder Security-Scans. Sie fördern zudem die Trennung von Pflichten durch klare Verantwortlichkeiten für Registrierung, Freigabe und Nutzung, was Schattenmodelle und Wildwuchs verhindert.
Technische Verteidigungslinien
Gute Praxis ist, mehrere unabhängige Schutzschichten zu kombinieren. Wichtige Maßnahmen, grob geordnet nach dem Aufwand, sie umzusetzen, sind:
- Netzwerksegmentierung & Isolation: Kubernetes-Namespaces, Network Policies und mTLS trennen Mandanten und Services voneinander.
Diese Kubernetes-Mechanismen isolieren Ressourcen – RBAC-Rollen und NetworkPolicies sind Namespace-bezogen – und reduzieren seitliche Bewegungen im Cluster [3]. D.h. Angreifer können sich weniger einfach auf gleicher Ebene im Cluster ausbreiten. - Least Privilege: Ein generell gültiges Prinzip: Zugriffsrechte so restriktiv wie möglich vergeben.
- Signierte Artefakte: Daten, Modelle und Container-Images mit kryptographischen Signaturen versehen. Das verhindert unautorisierte Modifikationen und erhöht die Nachvollziehbarkeit. Hier gibt es unterschiedliche Möglichkeiten, mit ansteigendem Implementierungsaufwand. Ein erster Schritt vor signierten Artefakten wäre das Tagging um die richtige Version zu finden.
- Tests aller Endpunkte mittels Unit und Integrationstest
- Unterschiedliche Konfigurationen für Test und Production: Bei extensiven Lasttests für das oben genannte Assistenzsystem verwenden wir anderen Identityprovider für Tests, der nur im Staging aktiv sein darf. In Production wird dieser durch den eigentlichen Identityprovider ersetzt.
- Runtime-Monitoring, Anomaly Detection und Alerting: Kontinuierliches Überwachen der Systemmetriken (CPU, Speicher, Anfrage-Raten) wie im Beispiel mittels eines Setups aus Prometheus, Grafana und Jaeger.
Frühwarnungen bei Abweichungen helfen hier, Angriffe oder Fehlverhalten zu entdecken. - Verschlüsselung: Daten sowohl im Ruhezustand als auch während der Übertragung konsequent verschlüsseln.
Im Beispielprojekt wurden je nach Projektphase und damit einhergehender Bedrohungssituation unterschiedliche Aspekte iterativ umgesetzt. Zunächst wurde mit der Verschlüsselung von API Keys begonnen, danach wurden heiklere, nutzerbezogene Daten verschlüsselt und schlussendlich alle Daten.
Beispiele für technische Abwehr:
- Ein Angreifer versucht, ein Modell nachzubauen, indem er die Inferenz-API massiv abfragt. Mit Rate Limiting, Anomalie-Erkennung und Auditing wird der Versuch früh erkannt.
- Ein konkreteres Beispiel, das mehrere Verteidigungsmechanismen kombiniert, ist im Folgenden skizziert: Ein Angreifer versucht, den LLM-Assistenten dazu zu bringen, eine interne Cloud-IP-Adresse aufzurufen und Zugangstokens zu stehlen. Das verhindern wir, indem wir ausgehende Verbindungen stark begrenzen: Diese Adresse ist blockiert und Internetzugriffe laufen nur über einen geprüften Gateway mit Filter. Der Kubernetes-Pod auf dem die entsprechende Software ausgeführt wird hat nur minimale Rechte, liest keine Secrets, läuft nicht als Root und sein Dateisystem ist schreibgeschützt. Es starten nur signierte Container-Images; die Attacke wird in Tests nachgestellt, in Staging geübt und in Produktion unterbunden. Monitoring meldet ungewöhnliche Verbindungen, Schlüssel sind sicher im KMS gespeichert – der Angriff scheitert und wird sauber protokolliert.
Schutz externer Integrationen
Besonderes Augenmerk gilt Schnittstellen zu externen Modellen und Diensten (z. B. Chatbots, Retrieval-APIs, Drittanbieter-LLMs). Diese Komponenten sind anfällig für Prompt-Injection-Angriffe, bei denen Angreifer versuchen, das Modell zu unerwünschten Aktionen zu verleiten – etwa dem Aufruf interner APIs oder der Ausgabe sensibler Daten.
Um solche Risiken zu minimieren, helfen Guardrails und Filtermechanismen wie Output-Filter, Content-Moderation (Blocklist/Allowlist) oder Prompt-Sanitization, die schädliche oder manipulative Eingaben früh abfangen.
Die verschiedenen Hoster bieten unterschiedliche Möglichkeiten an, Safeguards der Modelle zu konfigurieren. Häufig bilden diese schon einen großen Teil der gewünschten Funktionalität ab. In manchen Fällen ist es Ratsam, den Content, den die Nutzer an das Modell schicken, vorab zu prüfen, wenn gewisse Inhalte nicht bei Modelprovidern landen sollen.
Jedes externe Modell oder jeder Datentransfer sollte zudem einem Risiko-Review unterzogen werden (Datenschutz, Trainingsdaten-Rechte, SLA-/Vertragsklauseln).
Am Beispiel:
Das Assistenzsystem greift auf eine interne Kundendatenbank zu. Ohne Prompt-Sanitization könnte ein externer Nutzer durch geschicktes Prompting sensible Daten auslesen. Automatisierte Sicherheitstests (Fuzzing, Adversarial-Prompts, Red-Teaming) helfen, solche Risiken früh zu erkennen. Daher ist es ratsam, automatisierte Sicherheitstests direkt in die CI/CD-Pipeline zu integrieren. Die Ergebnisse fließen in Monitoring-Dashboards (hier z. B. Grafana/Prometheus) und Fehler-Tracking-Systeme (im vorliegenden System Sentry) ein – so werden ungewöhnliches Verhalten, Fehlkonfigurationen oder Prompt-Injection-Versuche frühzeitig sichtbar.[4]
Schutz der Modelle und Daten
Der direkte Schutz der KI-Modelle erfordert eigene Maßnahmen: Zugriffskontrolle auf Modellregistrierung, Rate Limiting und Request Auditing an den Inferenz-APIs reduzieren Diebstahlversuche. Anomalie-Erkennung kann auffällige Anfrage-Muster melden. Wo sinnvoll, kommen Techniken wie Differential Privacy (Schutz individueller Trainingsdaten), Wasserzeichen/Watermarking und verschlüsselte Inferenz (z.B. Confidential Computing) zum Einsatz.
Wichtig sind regelmäßige Backups der Modelle und Metadaten sowie Snapshots der Umgebung, um diese im Notfall wiederherstellen zu können. Unveränderbare Audit-Logs aller wichtigen Aktionen sichern die Nachvollziehbarkeit über die Zeit.
Security als kontinuierlicher Prozess
Security als andauernder Prozess ist für uns ein klarer Wettbewerbsvorteil: Sie schafft verlässliche Guardrails, damit Teams schneller und sicherer liefern. Automatisierte Verifikation und etablierte Standards (z. B. ISO/IEC 42001, 27001) sorgen für Transparenz, verkürzen Audits und stärken Vertrauen bei Kunden und Partnern. Gleichzeitig bleiben wir compliant mit Vorgaben wie dem EU-AI-Act, reduzieren Risiken und senken dauerhaft Betriebskosten. Gemeinsam mit Ihnen bauen wir diesen Reifegrad pragmatisch und iterativ aus – nachvollziehbar, skalierbar und mit Fokus auf nachhaltige Ergebnisse.
Leitfaden für MLOps – Best Practices und Lessons Learned
Die erfolgreichen Operationalisierungserfahrungen aus den vergangenen Artikeln fassen wir hier in Kernpunkten zusammen. Sie richten sich an technische Entscheider, MLOps- und DevOps-Verantwortliche, die KI-Anwendungen zuverlässig in Produktion bringen wollen:
1. Security – Best Practices
- Security by Design
- Daten- & Modellschutz
- Sichere Infrastruktur & CI/CD
- Monitoring & Incident Response
2. Backup und Versionierung
- Umfassende Backups
- Versionskontrolle für Modelle
- Infrastruktur-Backup
- Pipeline- & Log-Backup
3. Kostenoptimierung
- Prompt-Caching & Antwortbegrenzung
- Kontinuierliches Monitoring
- Kombinierte Maßnahmen
4. Maintenance
- Korrektiv, adaptiv & perfektionierend
- Vorbeugend
- Retraining-Strategien
5. Skalierung
- Frühe Lasttests
- Beobachtungssystem
- Autoscaling-Strategien
- Kosten-Effizienz im Blick
- Isolation & Governance
6. Monitoring
- Monitoring-Systeme
- Visualisierung
Die gelungene Operationalisierung von KI-Lösungen erfordert weit mehr als nur ein gut trainiertes Modell. Erst das Zusammenspiel aus durchdachten Prozessen, klarer Governance, robuster Architektur und einem kontinuierlichen Fokus auf Sicherheit macht KI-Systeme im Produktivbetrieb wirklich belastbar. Wer Security by Design von Anfang an mitdenkt und die beschriebenen Best Practices konsequent umsetzt, schafft die Grundlage für skalierbare, wartbare und vertrauenswürdige Anwendungen – und macht KI zu einem langfristig verlässlichen Bestandteil der digitalen Wertschöpfung.
Autoren
Dr. Simon Stieber
Dr. Richard Nordsieck