MHC-06 Container-Sicherheit und Confidential Computing

Auf einen Blick

Operativer Nutzen

Stellt sicher, dass nur unveränderte, geprüfte Container-Images laufen, und schützt besonders sensible Daten sogar während der Verarbeitung — auch gegenüber einem Angreifer mit Zugriff auf die darunterliegende Infrastruktur.

Betroffene Richtlinie

Richtlinie zur sicheren Entwicklung und zum sicheren Betrieb (Container- und Cloud-Betrieb).

Abhängigkeiten

keine Vorbedingung; setzt eine Container-/Cloud-Plattform voraus; wirkt zusammen mit MHC-02 (Herkunft der Images) und MHC-04 (Identitäten).

Aufwandstreiber

hängt von der Zahl der Container-Workloads und davon ab, ob Confidential Computing in der genutzten Plattform verfügbar ist. Der konkrete Aufwand richtet sich nach den Ressourcen der Organisation.

Primäre Kennzahl

Anteil der produktiv betriebenen Container aus signierten, vor dem Start geprüften Images; ergänzend Abdeckung von Confidential Computing bei den als besonders schutzbedürftig klassifizierten Workloads.

Berührte Standards (ohne Erfüllungsanspruch)

ISO/IEC 27002 A.5.23/A.8.31; C5:2026 OPS-32 bis OPS-35; NIST SP 800-190; Confidential Computing Consortium.

Control-Statement

Container laufen nur aus signierten, vor dem Start geprüften Images aus kontrollierten Quellen, mit Durchsetzung über die Plattform. Weiterführende Härtung (Stufe Managed): Für die als besonders schutzbedürftig klassifizierten Workloads werden geschützte Ausführungsumgebungen (Confidential Computing) mit Echtheitsnachweis (Remote-Attestation) eingesetzt; die Klassifikation ist dokumentiert.

MHC-06 umfasst zwei unterschiedlich reife und unterschiedlich breit anwendbare Schutzebenen: Container-Sicherheit als breite Basisanforderung für containerisierte Workloads und Confidential Computing als weiterführende Härtung für besonders schutzbedürftige Workloads, Mandantentrennung, regulierte Datenverarbeitung oder Infrastruktur mit erhöhtem Vertrauensrisiko. Beide werden hier gemeinsam behandelt, sollten in der Umsetzung aber getrennt geplant, bewertet und nachgewiesen werden.

Zweck und Bedrohungsbezug

Container werden oft aus öffentlich verfügbaren Basis-Images zusammengesetzt. Ist ein solches Image manipuliert, läuft der Schadcode unbemerkt mit. AI erleichtert es Angreifern, manipulierte Images und passende Schwachstellen zu finden. Zudem sind in geteilten Cloud-Umgebungen Daten zwar bei Übertragung und Speicherung verschlüsselt, während der Verarbeitung im Arbeitsspeicher aber grundsätzlich einsehbar — ein Angreifer mit Zugriff auf die Infrastruktur könnte sie dort abgreifen. Schutzziel ist, nur unveränderte, geprüfte Container auszuführen und besonders sensible Daten auch während der Verarbeitung zu schützen.

Wirkung in den Regelwerken

Auf diese Controls und Anforderungen wirkt das MHC. Die Einstufung zeigt, wie stark das jeweilige Control unter KI-gestützten Angriffen an Wirkung verliert.

Alle 93 Controls in der Analysematrix · Alle 23 Anforderungen der Bausteinfamilie

Reifegrad-Pfad

Initial

Container-Images signiert; Schwachstellen-Scan vor dem Deployment.

Defined

Durchsetzung über Admission-Controller im Betrieb; Einsatzfälle für Confidential Computing benannt und dokumentiert.

Managed

Confidential Computing produktiv für die als besonders schutzbedürftig klassifizierten Workloads; Remote-Attestation automatisiert.

Messung und Audit-Nachweis

Kennzahl

Anteil der produktiven Container aus signierten, vor dem Start geprüften Images (Zielwert: vollständig); zusätzlich Abdeckung von Confidential Computing bei den als hochsensibel eingestuften Workloads.

Nachweis

Konfiguration des Admission-Controllers, Signatur- und Scan-Protokolle, Attestation-Nachweise der geschützten Umgebungen.

Nachweislogik (in Anlehnung an ISO/IEC 27001, Clause 9)

dokumentiert? — Betriebsrichtlinie, Plattformkonfiguration; verantwortlich? — Plattform-/Betriebsleitung; Häufigkeit? — bei jedem Deployment, Scans fortlaufend; Toleranz? — kein produktiver Container ohne gültige Signatur und Prüfung.

Typische Fehler

• Images werden zwar signiert, aber die Signatur wird beim Start nicht geprüft — die Signatur ist dann wirkungslos.
• Der Admission-Controller ist vorhanden, läuft aber nur im Warnmodus; nicht erlaubte Images werden gemeldet, aber nicht blockiert.
• Confidential Computing wird pauschal für alles gefordert, obwohl es nur für wenige hochsensible Workloads nötig ist — unnötiger Aufwand.
• Gelagerte Images werden nach dem ersten Scan nie erneut geprüft; neu bekannt gewordene Schwachstellen bleiben unentdeckt.

Abgrenzung und Restrisiko

Abgrenzung

betrifft die Integrität der Container und den Schutz von Daten in der Verarbeitung; die Herkunft der enthaltenen Komponenten behandelt MHC-02, die Trennung mehrerer Mandanten MHC-07.

Restrisiko

Confidential Computing schützt die Verarbeitung, nicht jedoch Fehler in der Anwendung selbst; geschützte Ausführungsumgebungen sind nicht überall verfügbar und können die Leistung beeinflussen.

Anwendbarkeit

Container-Sicherheit ist Basisanforderung bei containerisierten Workloads; Confidential Computing ist kontextabhängig und im Statement of Applicability häufig als N/A zu begründen. Beide Schutzebenen sind getrennt zu planen, zu bewerten und nachzuweisen.

ISO/IEC 27002:2022 (mittelbar)

A.5.23 Informationssicherheit für die Nutzung von Cloud-Diensten; A.8.31 Trennung von Entwicklungs-, Test- und Betriebsumgebungen.

Framework

C5:2026 OPS-34/35 (Container Management), OPS-32/33 (Confidential Computing), PSS-11; NIST SP 800-190; Confidential Computing Consortium; Image-Signatur über Sigstore/cosign.

Umsetzung im Detail

Organisatorische und technische Umsetzung, Umsetzungsbeispiele und die Priorisierung im Gesamtprogramm beschreibt der Implementation Guide.

Implementation Guide (PDF)Zum MHC-Katalog

Quelle: MRIS Implementation Guide (ISO/IEC 27001), Fassung 2.0. Lizenz CC BY-SA 4.0. © 2026 Richard Peddi.