Mandantentrennung im C5:2026: OPS-30, OPS-31 und COS-06 nachweisbar umsetzen

Diese Seite behandelt die Trennung der Kundendaten als Schwerpunkt des C5:2026. Das Themengebiet OPS als Ganzes behandelt die Seite Themengebiet OPS; welche neuen Schwerpunkte der Katalog insgesamt setzt, steht auf der Seite C5:2026.

Worum geht es bei der Mandantentrennung im C5:2026?

Der Katalog nennt die „detailliertere Berücksichtigung von Mandantenfähigkeit“ als eine der wesentlichen Änderungen (Abschnitt 1.1). In den Kriterien heißt das Thema „Trennung von Datensätzen“; gemeint ist die Trennung der Kundendaten zwischen verschiedenen Kunden und zwischen Kunden und Anbieter. Drei Kriterien bilden den Kern:

• OPS-30 Richtlinien und Verfahren (neu): Auf Basis einer Risikobeurteilung nach OIS-07 legt der Anbieter Richtlinien fest, die sich auf ein dokumentiertes Cloud-Schichtenmodell stützen. Sie zeigen, welche Schichten der Dienst nutzt, welche Trennungsmaßnahmen je Schicht greifen, eingeteilt nach Vertraulichkeit, Integrität und Verfügbarkeit und nach präventiv, detektiv und reaktiv, wie die Maßnahmen überwacht werden und was bei Abweichungen geschieht (OPS-30.01B).
• OPS-31 Implementierung: Der Anbieter setzt Maßnahmen gegen Bedrohungen der Trennung um, Kundendaten auf gemeinsam genutzten virtuellen und physischen Ressourcen sind „sicher und strikt getrennt“, und die Risikobeurteilung wird bei Bedarf, besonders bei Architekturänderungen, mindestens aber jährlich überprüft (OPS-31.01B bis 03B). Nach der Änderungshistorie ist OPS-31 der Nachfolger von OPS-24 aus C5:2020.
• COS-06 Trennung des Datenverkehrs: Der Datenverkehr der Kunden in gemeinsam genutzten Netzumgebungen ist auf Netzebene nach einem dokumentierten Rahmenwerk getrennt (COS-06.01B). Bei IaaS und PaaS verlangt das erweiternde COS-06.01AC physisch getrennte Netze oder Verschlüsselung nach dem Stand der Technik zusammen mit logischer Trennung. Die übrige Netzsicherheit behandelt das Themengebiet COS.

Dazu kommen Unterkriterien in anderen Gebieten: IAM-07.01B verlangt Trennungsmechanismen, die Kunden voneinander und den Dienst von den übrigen Systemen des Anbieters trennen, IAM-07.02B, dass ein Vorfall an den datenhaltenden Komponenten nicht auf die Komponenten übergreift, die den Zugriff verwalten. OPS-15.01B verlangt Protokolle, die Zugriffe eindeutig auf Mandantenebene zuordnen. COS-05.02B trennt die Orchestrierungsnetze von den Kundennetzen, OPS-34.02B Nr. 4 die Kundendaten in Containern.

Als Beispiel für ein Schichtenmodell nennt der Katalog die CISA Cloud Security Technical Reference Architecture; der Anbieter darf aber eine eigene Kategorisierung verwenden (ergänzende Informationen zu OPS-30). Nicht jede Kombination aus Schutzziel und Maßnahmenart muss für jede Schicht belegt sein; wo das nicht sinnvoll ist, halten Sie es nachvollziehbar in der Richtlinie fest.

Ausgangssituation: ein Dokumentenmanagement für Behörden

Fiktives Beispiel, kein Kunde. Ein Anbieter betreibt ein Dokumentenmanagement als SaaS für Kommunalverwaltungen. Alle Kommunen nutzen dieselbe Anwendung auf der Infrastruktur eines großen Cloud-Anbieters: einen gemeinsamen Kubernetes-Cluster, eine gemeinsame Datenbank mit einer Spalte für die Mandanten-ID, einen gemeinsamen Objektspeicher mit einem Verzeichnis je Mandant und einen gemeinsamen Suchindex. Die Volltextsuche und eine Vorschau-Funktion laufen als eigene Dienste.

So sieht es vor dem Projekt aus:

• Die Mandanten-ID setzt jeder Entwickler in seinen Abfragen selbst; eine zentrale Durchsetzung gibt es nicht.
• Der Suchindex enthält Dokumente aller Mandanten; gefiltert wird erst bei der Ausgabe.
• Für alle Mandanten gilt ein gemeinsamer Datenschlüssel in der Schlüsselverwaltung der Plattform.
• Der jährliche Penetrationstest prüft die Anwendung von außen, aber nicht, ob ein Nutzer einer Kommune Daten einer anderen sehen kann.
• Die Protokolle der Vorschau-Funktion enthalten keine Mandanten-ID.

Die Trennung funktioniert vermutlich. Belegen lässt sie sich so nicht: Es fehlen Schichtenmodell, Risikobeurteilung und Tests, die eine Verletzung der Trennung erkennen würden.

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

Bei einem SaaS liegt die Trennung oberhalb der Infrastruktur beim Anbieter. Die Plattform trennt ihre Kunden voneinander, also den Anbieter von anderen Plattformkunden, nicht die Mandanten des Anbieters untereinander. Für OPS-31 und COS-06 nennt der Katalog korrespondierende Kriterien für Kunden. Unsere Einordnung für das Beispiel:

Welche dieser Kundenkontrollen Sie voraussetzen, gehört als korrespondierende Kundenkontrollen (CUEC) in die Systembeschreibung. Wie Sie die Pflichten der Kunden handhabbar machen, zeigt die Seite Korrespondierende Kriterien.

Arbeitsprodukt: Trennungsmatrix je Cloud-Schicht

OPS-30.01B verlangt Maßnahmen je Schicht, eingeteilt nach Schutzziel und Maßnahmenart. Am einfachsten wird daraus eine Matrix, die gleichzeitig Richtlinie und Prüfgrundlage ist. Ein Ausschnitt für das Beispiel (eigene Kategorisierung der Schichten, eigene Maßnahmen):

V, I, A stehen für Vertraulichkeit, Integrität und Verfügbarkeit (A nach dem englischen „availability“; im Assetregister des Themengebiets AM steht A dagegen für Authentizität). Die Grafik unter diesem Absatz zeigt dieselbe Matrix als Übersicht zum Ausdrucken; die Tabelle enthält einige Einzelheiten mehr. Die Matrix ersetzt nicht die Risikobeurteilung nach OIS-07; sie zeigt, welche Maßnahme welches Risiko adressiert. Kryptografische Trennung muss nach den ergänzenden Informationen zu OPS-31 nicht auf jeder Ressource bestehen, wenn die Risikobeurteilung sie dort nicht verlangt.

Beispiel-Kontrollbeschreibung zu OPS-31

Eine Trennung, die nur behauptet ist, lässt sich nicht prüfen. Die folgende Kontrolle macht sie messbar (eigene Formulierung, kein Katalogtext):

Der Penetrationstest hat hier einen eigenen Zweck: Lässt sich die Wirksamkeit der Trennung wegen einer komplexen Umsetzung nicht mit hinreichender Sicherheit beurteilen, kann der Nachweis nach den ergänzenden Informationen zu OPS-31 auch durch Expertenprüfungen Dritter erbracht werden, etwa Penetrationstests. Für die Netztrennung nennen die ergänzenden Informationen zu COS-06 dasselbe.

Welche Nachweise der Prüfer sehen will

Der Prüfer braucht für die Mandantentrennung zweierlei: die Begründung, warum die Maßnahmen ausreichen, und Belege, dass sie im Zeitraum wirkten. Beispiele aus dem Szenario:

Den Bericht der Plattform werten Sie über das Subdienstleistermanagement aus (siehe Subdienstleisterinventar). Wie Sie Nachweise den Unterkriterien zuordnen, 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).

Welche Lücken zuerst zu schließen sind, ist eine Frage der Maßnahmenplanung.

Kriterien zur Mandantentrennung

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-30, OPS-31 und COS-06 ist unsere Einordnung. Die Spalte „Worum es geht“ ist unsere eigene Kurzbeschreibung, kein Katalogtext; verbindlich ist der Wortlaut der Kriterien im Katalog.

Den Zugriff des eigenen Personals auf Kundendaten nach IAM-07.03B ff. behandelt die Seite Themengebiet IAM.

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).