MLOps Security: Sichere Pipelines für KI-Entwicklung

Warum ML-Pipelines eigene Sicherheitsanforderungen haben

In der klassischen Softwareentwicklung ist der Quellcode das zentrale Artefakt. In ML-Projekten entsteht das Verhalten eines Systems dagegen aus dem Zusammenspiel von Code, Daten, Hyperparametern und trainierten Gewichten. Daraus ergeben sich Besonderheiten:

• Daten sind Teil der Logik: Wer Trainingsdaten verändern kann, verändert das Modell, ohne eine Zeile Code anzufassen.
• Experimentierumgebungen sind offen: Notebooks, gemeinsam genutzte GPU-Server und Experiment-Tracking-Werkzeuge sind oft auf schnelles Ausprobieren ausgelegt, nicht auf Zugriffsschutz.
• Modelle sind Binärartefakte: Trainierte Modelle lassen sich nicht lesen oder per Code-Review prüfen; ihre Integrität muss über Herkunftsnachweise und Tests sichergestellt werden.
• Modelle sind schützenswertes Eigentum: Sie bündeln Know-how und teilweise Trainingsdaten, die sich unter Umständen aus dem Modell rekonstruieren lassen.

Sicherheitsmaßnahmen entlang der Pipeline

1. Datenerfassung und -aufbereitung

• Datenquellen dokumentieren und Rohdaten schreibgeschützt ablegen
• Datensätze versionieren und mit Prüfsummen versehen, damit jede Modellversion auf einen eindeutigen Datenstand zurückführbar ist
• Personenbezogene Daten minimieren, pseudonymisieren oder, wo möglich, durch synthetische Daten ersetzen (Art. 25 DSGVO)
• Statistische Prüfungen auf Ausreißer und auffällige Verteilungsänderungen als Frühwarnung vor Datenvergiftung

2. Entwicklung und Training

• Notebook- und Trainingsumgebungen mit Authentifizierung, getrennten Projekten und ohne direkten Zugriff auf Produktivdaten betreiben, wo das nicht erforderlich ist
• Zugangsdaten nicht in Notebooks oder Konfigurationsdateien speichern, sondern über einen Secrets-Manager einbinden
• Abhängigkeiten pinnen, aus einem internen Paketspiegel beziehen und auf Schwachstellen scannen
• Externe Basismodelle nur in sicheren Formaten und nach Prüfung verwenden
• Trainingsläufe protokollieren: Code-Commit, Datenversion, Parameter, Umgebung

3. Modell-Registry und Freigabe

• Nur Modelle aus einer zentralen Registry bereitstellen, nie direkt aus einer Entwicklungsumgebung
• Modelle bei der Registrierung signieren und die Signatur vor der Bereitstellung prüfen
• Freigabeprozess mit definierten Prüfungen: Qualitätsmetriken, Tests auf Verzerrungen, Robustheitstests gegen manipulierte Eingaben
• Schreibrechte auf die Registry eng begrenzen und Änderungen nachvollziehbar protokollieren

4. Bereitstellung und Inferenz

• Inferenz-Endpunkte hinter Authentifizierung und Ratenbegrenzung betreiben, um Missbrauch und das systematische Abfragen zur Modellextraktion zu erschweren
• Eingaben validieren und bei Sprachmodellen zusätzlich Schutz vor Prompt Injection und Ausgabefilter vorsehen
• Modell-Container nach dem Prinzip minimaler Rechte betreiben und regelmäßig aktualisieren

5. Betrieb und Überwachung

• Modellleistung und Eingabedaten auf Drift überwachen; plötzliche Veränderungen können auf Angriffe oder fehlerhafte Datenquellen hindeuten
• Inferenzanfragen protokollieren, unter Beachtung des Datenschutzes, und in das zentrale Sicherheitsmonitoring einbinden
• Ein Rollback auf eine frühere, geprüfte Modellversion vorbereiten und testen

Rahmenwerke und Orientierungshilfen

Das NIST Secure Software Development Framework (SP 800-218) wurde mit SP 800-218A um Praktiken für generative KI und Basismodelle ergänzt. Die von der britischen NCSC und der US-Behörde CISA herausgegebenen „Guidelines for secure AI system development“, die auch das BSI mitgezeichnet hat, gliedern Empfehlungen nach Design, Entwicklung, Bereitstellung und Betrieb. Für die Bedrohungsanalyse eignen sich MITRE ATLAS und die OWASP Top 10 for LLM Applications. Für Anbieter von Hochrisiko-KI verlangt der EU AI Act unter anderem Datenqualität, Protokollierung, technische Dokumentation sowie Robustheit und Cybersicherheit (Art. 10 bis 15). Eine gut aufgesetzte MLOps-Pipeline liefert viele dieser Nachweise fast automatisch.

Einstieg für kleinere Teams

Nicht jedes Team braucht sofort eine vollständige MLOps-Plattform. Ein sinnvoller Anfang sind drei Maßnahmen: Daten und Modelle versionieren, Modelle nur über eine Registry mit Freigabe bereitstellen und Zugangsdaten konsequent aus Notebooks entfernen. Darauf lassen sich Signaturen, automatisierte Tests und Monitoring schrittweise aufbauen.

Fazit

MLOps Security macht nachvollziehbar, welches Modell mit welchen Daten entstanden ist und wer es freigegeben hat, und schützt jede Stufe vor Manipulation. SecTepe unterstützt Entwicklungsteams mit Architektur-Reviews und Penetrationstests für ML-Plattformen und Inferenzschnittstellen.

Häufige Fragen

Was ist der Unterschied zwischen MLOps Security und DevSecOps?

DevSecOps sichert Code und Build-Prozesse ab. MLOps Security erweitert das um Trainingsdaten, Modellartefakte, Experimentierumgebungen und KI-spezifische Angriffe wie Datenvergiftung oder Modellextraktion.

Brauchen wir MLOps Security, wenn wir nur fertige KI-APIs nutzen?

Nur eingeschränkt. Wer keine Modelle trainiert oder anpasst, konzentriert sich auf sichere Integration, Zugangsdaten und Anbieterbewertung. Sobald Sie Modelle feinabstimmen oder eigene Daten für Retrieval einbinden, werden Pipeline-Themen relevant.