Container und Kubernetes im C5:2026: OPS-34 und OPS-35 prüffähig umsetzen

Diese Seite behandelt den Container-Betrieb als Schwerpunkt des C5:2026. Das Themengebiet OPS als Ganzes, darunter Schwachstellenscans und Patch-Management, behandelt die Seite Themengebiet OPS; welche neuen Schwerpunkte der Katalog insgesamt setzt, steht auf der Seite C5:2026.

Worum geht es bei Containern im C5:2026?

Der Katalog nennt Container-Management ausdrücklich als einen der neuen Schwerpunkte (Abschnitt 1.1). Kern sind zwei neue Basiskriterien im Gebiet OPS: OPS-34 „Container-Management - Richtlinien und Verfahren“ und OPS-35 „Containermanagement - Implementierung“. OPS-34.01B verlangt Vorgaben für den gesamten Container-Lebenszyklus mit mindestens fünf Stationen: Erstellung, Test und Validierung von Images, ihre Aufbewahrung und ihr Abruf, Bereitstellung und Verwaltung der Container, ihr Betrieb und die Außerbetriebnahme von Images und Containern. OPS-35 verlangt, dass der Anbieter diese Vorgaben technisch und organisatorisch umsetzt und pflegt.

OPS-34.02B listet neun Aspekte, die die Richtlinie entlang des Lebenszyklus abdecken muss. Die meisten verweisen auf Kriterien anderer Gebiete, OPS-34 bündelt sie für Container:

• Inventar der Container nach einem dokumentierten Prozess (AM-02, AM-03, AM-09),
• Bedarf an Schutz vor Schadsoftware beurteilen (OPS-05),
• Protokollierung und Überwachung entlang des Lebenszyklus (OPS-10, OPS-12),
• Trennung der Kundendaten auf Basis einer Risikobeurteilung (OPS-30),
• Zugriff auf den Container-Host nach Rollen- und Rechtemodell (IAM-01, IAM-06),
• Verschlüsselung gespeicherter und übertragener Daten, soweit möglich (CRY-01),
• Netzsicherheit, etwa das Erkennen unerwarteter Datenflüsse (COS-01, COS-03),
• Änderungen an Containern und Images nach einem geregelten Prozess (DEV-03),
• Härtung nach Branchenstandards, damit keine unnötigen Dienste laufen (PSS-11).

Beim Host-Zugriff und bei der Verschlüsselung schreibt der Katalog „sollte“, die übrigen Punkte formuliert er als feste Anforderung. Dazu kommen Container-Bezüge an anderen Stellen: IAM-06.08B verlangt, die Aktivitäten privilegierter Nutzer an Containern und Images nach OPS-10 zu protokollieren, COS-05.02B trennt die Netze, über die der Anbieter Workloads erstellt und orchestriert, von den Netzen der Kunden. Der Begriff Kubernetes steht nicht im Katalog; die Kriterien sind technikneutral und gelten für jede Orchestrierung.

Ausgangssituation: ein HR-SaaS auf verwaltetem Kubernetes

Fiktives Beispiel, kein Kunde. Ein Anbieter betreibt eine Software für Personalverwaltung und Gehaltsabrechnung für mittelständische Unternehmen. Der Dienst besteht aus rund 40 Microservices in einem verwalteten Kubernetes-Cluster eines großen Cloud-Anbieters, dazu eine verwaltete Datenbank und eine Container-Registry desselben Anbieters. Images entstehen in einer Build-Pipeline, ein GitOps-Werkzeug spielt sie in den Cluster ein. Das Plattformteam hat fünf Personen.

So sieht es vor dem Projekt aus:

• Basis-Images ziehen die Teams selbst aus öffentlichen Registries, jedes Team mit eigenem Stand.
• In der Registry liegen mehrere tausend Images, auch solche ohne laufenden Container; welches Image in Produktion läuft, zeigt nur der Cluster selbst.
• Zwei Administratoren haben Cluster-Admin-Rechte über ein statisches Konfigurationsfile; ihre Befehle am Cluster werden nicht gesondert protokolliert.
• Für Fehlersuchen öffnen Entwickler gelegentlich eine Shell in laufenden Produktivcontainern.
• Es gibt keine schriftliche Regel, wann ein Image gelöscht wird.

Technisch ist das ein üblicher Aufbau. Für die Prüfung fehlt die Richtlinie nach OPS-34, und ohne sie kann der Prüfer weder die Angemessenheit noch, bei Typ 2, die Wirksamkeit über den Zeitraum beurteilen.

Wer ist wofür verantwortlich: Anbieter, Plattform, Kunde?

Bei verwaltetem Kubernetes betreibt die Plattform die Steuerungsebene des Clusters, der Anbieter alles, was er darauf ausrollt. Die Kriterien OPS-34 und OPS-35 richten sich an den Anbieter; korrespondierende Kriterien für Kunden nennt der Katalog dort nicht. Unsere Einordnung für das Beispiel:

Nutzen Sie für die Plattform die Carve-out-Methode, liegen deren Kontrollen außerhalb Ihrer Prüfung, die Verantwortung für die Kriterien bleibt bei Ihnen (siehe C5-Scope). Lassen Sie Kunden eigene Container betreiben, etwa als PaaS, kommt PSS-11 hinzu: Kunden müssen die Auswahl von Images einschränken können, bereitgestellte Images brauchen Herkunftsangaben und eine Härtung nach Branchenstandards. Nach den ergänzenden Informationen ist PSS-11 für SaaS typischerweise nicht anwendbar; das begründen Sie in der Systembeschreibung.

Beispiel-Kontrollbeschreibung zur Image-Freigabe (OPS-34, OPS-35)

Die ersten drei Stationen des Lebenszyklus lassen sich in einer Kontrolle zusammenfassen: Kein Image kommt in die Produktion, das nicht gebaut, geprüft und freigegeben wurde. Unsere Beispiel-Kontrolle für den Anbieter oben (eigene Formulierung, kein Katalogtext):

Die Signatur ist nach dem Katalog ein erweiterndes Zusatzkriterium (OPS-34.01AC Nr. 1); für die Basis genügt eine andere wirksame Freigabe. Wir empfehlen sie trotzdem, weil die Zulassungsregel im Cluster sie technisch durchsetzt und der Nachweis dann automatisch entsteht. Wer sie aufnimmt, muss auch den Signaturschlüssel nach CRY-10 sicher speichern (siehe Themengebiet CRY). Die Scans selbst gehören zu OPS-25; wie eine Scan-Kontrolle aussieht, zeigt die Seite Themengebiet OPS.

Welche Nachweise der Prüfer sehen will

Container-Nachweise entstehen fast vollständig maschinell, in Pipeline, Registry und Cluster. Wichtig ist, dass Sie sie über den ganzen Prüfungszeitraum aufbewahren; ein Cluster zeigt nur den aktuellen Zustand. Beispiele aus dem Szenario:

Welche Nachweise Sie wann für welches Unterkriterium vorhalten, gehört in ein Nachweisregister; wie Sie es führen, zeigt die Seite Nachweise und Dokumentation.

Mögliche Lücken: Ursache, Wirkung, Abhilfe

Die folgenden Lücken folgen aus dem Wortlaut der Kriterien und dem Szenario. Ist ein Unterkriterium nicht erfüllt, gilt das Kriterium als nicht erfüllt, und der Prüfer berichtet die Abweichung (Abschnitte 3.4.12 und 3.4.13).

In welcher Reihenfolge Sie solche Lücken schließen, ist eine Frage der Maßnahmenplanung über alle Gebiete.

Kriterien mit Container-Bezug

Titel nach der deutschen Fassung 1.1.0, Zählung der Unterkriterien nach Abschnitt 5 (B = Basis, AS = verschärfend, AC = erweiternd). Die Auswahl außerhalb von OPS-34 und OPS-35 ist unsere Einordnung. Die Spalte „Worum es geht“ ist unsere eigene Kurzbeschreibung, kein Katalogtext; verbindlich ist der Wortlaut der Kriterien im Katalog.

Wie Zusatzkriterien wie OPS-34.01AC in den Prüfungsumfang kommen, erklärt die Seite C5-Kriterienkatalog. OPS-34 und OPS-35 sind in C5:2026 ohne Vorgänger neu; aus C5:2020 gibt es dafür keine Kontrollen, die Sie umnummerieren könnten.

Bezug zu ISO/IEC 27001:2022 Anhang A

Die folgende Zuordnung ist unsere eigene, nicht amtliche Einordnung nach Thema. Das BSI hat für C5:2026 noch keine Kreuzreferenz veröffentlicht, und auch eine amtliche Tabelle zeigt nach dem Katalog nur thematische Nähe, keine Erfüllung (Abschnitt 3.3). Die Kurzbezeichnungen sind unsere.