Confidential Computing im C5:2026: Architektur festlegen und Attestierung belegen

Diese Seite behandelt Confidential Computing als Schwerpunkt des C5:2026. Das Themengebiet OPS als Ganzes behandelt die Seite Themengebiet OPS, Kryptorichtlinie und Schlüsselmanagement die Seite Themengebiet CRY.

Worum geht es bei Confidential Computing im C5:2026?

Confidential Computing schützt Daten während der Verarbeitung. Der Katalog übernimmt die Begriffsbestimmung des Confidential Computing Consortium: Berechnungen laufen in einem hardwarebasierten, zertifizierten Trusted Execution Environment (TEE), einem isolierten Teil des Prozessors oder Chips, in dem nur autorisierter Code läuft und dessen Daten Code von außen weder lesen noch verändern kann (ergänzende Informationen zu OPS-32). Mit der Attestierung prüft man, ob TEE und Anwendung darin vertrauenswürdig sind.

C5:2026 regelt das in zwei neuen Kriterien. Beide beginnen mit derselben Bedingung: „Wenn der Cloud-Dienst Funktionen für Confidential Computing umfasst“ (OPS-32.01B, OPS-33.01B).

• OPS-32 Richtlinien und Verfahren: Die Richtlinie beschreibt Zweck und Umfang, die verfügbaren Techniken, welche Teile des Cloud-Stacks mit welcher Technik geschützt sind und wo ein Zugriff Dritter möglich ist, die beteiligten Lieferanten und die Nutzung von TEEs oder sicheren Enklaven (OPS-32.01B). Kunden bekommen diese Informationen nach PSS-01 (OPS-32.02B). Als Sicherheitsanforderung gilt: Weder der Anbieter noch eine andere unbefugte Stelle darf auf die Kundendaten oder die Schlüssel zu ihrem Schutz zugreifen, und die Algorithmen folgen der Kryptorichtlinie (OPS-32.03B).
• OPS-33 Remote-Attestierung: Der Anbieter bietet Remote-Attestierung an, verankert in vertrauenswürdiger Hard- und Software, mit einer Schnittstelle, über die Kunden die Integrität der Attestierung prüfen können (OPS-33.01B bis 03B).

Das erweiternde Zusatzkriterium OPS-32.01AC verlangt ein dokumentiertes technisches Rahmenwerk mit acht Punkten, unter anderem Dokumentation aller Schnittstellen, Remote-Attestierung von TEE und Code, Überwachung, regelmäßige Penetrationstests nach OPS-22 und Aktualisierung der Trusted Computing Base. OPS-33.01AC verlangt, die verfügbaren Attestierungsstufen festzulegen und Kunden mitzuteilen.

Gelten OPS-32 und OPS-33 für meinen Dienst?

Bieten Sie Ihren Kunden Confidential Computing als Funktion an, etwa vertrauliche Rechenumgebungen, gelten beide Kriterien. Bieten Sie nichts davon an, sind sie nicht anwendbar; das begründen Sie in der Systembeschreibung. Nach Abschnitt 3.4.3 kann sich die Begründung aus der Natur des Dienstes oder aus Ihren Grundsätzen, Verfahren und Maßnahmen ergeben; wie Sie Ausschlüsse im Scope festhalten, zeigt die Seite C5-Scope.

Offen ist der Fall dazwischen: Sie nutzen vertrauliche virtuelle Maschinen der Plattform nur intern, etwa für einen Dienst, der besonders schützenswerte Daten verarbeitet, und werben damit gegenüber Kunden. Ob der Dienst dann „Funktionen für Confidential Computing umfasst“, entscheidet der Wortlaut nicht ausdrücklich. Unsere Empfehlung: Wer den Schutz gegenüber Kunden als Eigenschaft des Dienstes zusagt, sollte ihn auch nach OPS-32 und OPS-33 belegen können. Klären Sie die Einordnung früh mit dem Prüfer.

Ausgangssituation: eine Analyseplattform mit vertraulichen Rechenumgebungen

Fiktives Beispiel, kein Kunde. Ein Anbieter betreibt eine Plattform, auf der Forschungseinrichtungen und Pharmaunternehmen pseudonymisierte Gesundheitsdaten gemeinsam auswerten, ohne die Rohdaten einander offenzulegen. Die Auswertungen laufen in vertraulichen virtuellen Maschinen eines großen Cloud-Anbieters; die TEE-Technik liefert der Prozessorhersteller. Die Schlüssel zu den Datensätzen gibt ein eigener Schlüsseldienst des Anbieters erst frei, wenn die Attestierung der Rechenumgebung erfolgreich war. Kunden wählen im Portal eine „vertrauliche Auswertung“; Confidential Computing ist damit eine Funktion des Dienstes.

So sieht es vor dem Projekt aus:

• Das Portal zeigt Kunden ein grünes Häkchen „Attestierung erfolgreich“. Die Nachweise dahinter prüft nur der Schlüsseldienst des Anbieters.
• Die Betriebsdokumentation beschreibt die vertraulichen Maschinen, aber nicht, welche Teile des Stacks außerhalb des TEE laufen: Speicher, Netz, Schlüsseldienst, Protokollierung.
• Der Schlüsseldienst läuft selbst in einer normalen virtuellen Maschine; zwei Administratoren könnten die Freigaberegeln ändern.
• Firmware- und Mikrocode-Aktualisierungen der Plattform kommen ohne eigene Bewertung in den Betrieb.

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

Die Hardware stammt vom Prozessorhersteller, die vertraulichen Maschinen betreibt die Plattform, die Zusage an die Kunden macht der Anbieter. OPS-32 und OPS-33 richten sich an den Anbieter; korrespondierende Kriterien für Kunden nennt der Katalog dort nicht. Unsere Einordnung für das Beispiel:

Die Lieferanten nach OPS-32.01B Nr. 4 überschneiden sich mit den Subdienstleistern Ihres Berichts; ein gemeinsames Subdienstleisterinventar vermeidet doppelte Listen. Dass Kunden Nachweise selbst prüfen, ist kein Katalogkriterium für Kunden; setzen Sie es voraus, gehört es als korrespondierende Kundenkontrolle (CUEC) in die Systembeschreibung.

Welche Varianten der Remote-Attestierung unterscheidet der Katalog?

Der Katalog stuft in den ergänzenden Informationen zu OPS-33.01AC vier Varianten ein. Je mehr der Kunde selbst in einer Umgebung seines Vertrauens prüft, desto stärker gilt die Attestierung. Ruft der Anbieter die Nachweise ab, prüft sie in einem eigenen Dienst und gibt nur das Ergebnis zurück, liefert das nach dem Katalog eine schwache Attestierung. Das grüne Häkchen im Beispiel entspricht dieser schwachen Variante. Gibt der Anbieter zusätzlich die Nachweise heraus und der Kunde prüft sie selbst, stuft der Katalog die Variante als sehr stark ein. Die Schnittstelle für Kunden ist in jedem Fall Pflicht (OPS-33.03B); die Stufen festzulegen und mitzuteilen ist erweiternd (OPS-33.01AC).

Beispiel-Kontrollbeschreibung zu OPS-32.03B und OPS-33

Im Beispiel hängt die Zusage an die Kunden an einer Stelle: Der Schlüssel zu einem Datensatz darf nur in eine attestierte Umgebung gelangen. Unsere Beispiel-Kontrolle (eigene Formulierung, kein Katalogtext):

Damit die Anforderung aus OPS-32.03B auch gegenüber dem eigenen Personal hält, muss der Schlüsseldienst selbst geschützt sein, etwa in einem eigenen TEE oder einem Hardware-Sicherheitsmodul mit Freigaberegeln, die niemand allein ändern kann. Das ist unsere Empfehlung; wie der Anbieter die Anforderung erfüllt, lässt der Katalog offen.

Welche Nachweise der Prüfer sehen will

Bei Confidential Computing muss der Prüfer zwei Dinge nachvollziehen: dass die Architektur hält, was die Richtlinie verspricht, und dass die Attestierung im Betrieb wirkt. Beispiele aus dem Szenario:

Wie Sie diese Nachweise den Unterkriterien zuordnen und für den Zeitraum vorhalten, 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 mit Bezug zu Confidential Computing

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

OPS-32 und OPS-33 sind in C5:2026 ohne Vorgänger neu.

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