Warum eine unabhängige Schicht für Confidential Computing nötig ist

Zusammenfassung

Confidential Computing gegenüber dem Cloud-Anbieter (CSP) ist eine binäre Eigenschaft. Entweder können der CSP und seine Administratoren Ihre Daten strukturell nicht lesen, oder sie können es. Es gibt kein „größtenteils vertraulich“ und keine „teilweise Attestierung“. Der gesamte Zweck der Technologie besteht darin, den Cloud-Anbieter aus der Vertrauensgrenze zur Laufzeit zu entfernen. Und die Beweiskette, die das belegt, verläuft entweder über Parteien, die vom Anbieter unabhängig sind, oder eben nicht.

Ob das gelingt, hängt von der Verifikation ab. Sie müssen unabhängig und mit in Hardware verankerten Nachweisen belegen können, dass die Workload, die auf Ihren Daten läuft, exakt der von Ihnen vorgesehene Code ist und auf einer vertrauenswürdigen Laufzeitumgebung läuft. Cloud-Anbieter, sowohl die Hyperscaler als auch die wachsende Zahl regionaler und kleinerer Anbieter, die nun Confidential Computing vermarkten, liefern die Primitive auf Silizium-Ebene wie Confidential VMs und zunehmend Confidential Container. Sie liefern sie jedoch in einem Stack, in dem der Prüfer und die geprüfte Partei dieselbe sind und in dem der Quellcode, der zum Reproduzieren der Attestierungs-Referenzwerte nötig wäre, weder Kunden noch Auditoren zur Verfügung steht.

Jeder anbietereigene Attestierungsablauf hängt letztlich von genau diesem Anbieter ab, jeder Stack ist proprietär, und keiner integriert sich durchgehend in die Kubernetes- und Infrastructure-as-Code-Schicht, auf der produktive Cloud-Workloads tatsächlich laufen. Gemessen an der binären Sicht auf Confidential Computing steht das auf der falschen Seite der Linie: nicht vertraulich.

Die Produkte von Edgeless Systems sind so konzipiert, dass sie auf der richtigen Seite landen: unabhängige, vom Kunden überprüfbare Attestierung, verankert in quelloffenem, reproduzierbar gebautem Code und in Kubernetes integriert, so wie cloud-native Systeme gedacht sind.

Die Entscheidung, die Sie wirklich treffen

Wenn Sie Confidential Computing in der Cloud einsetzen, beantworten Sie eine Frage: Wer darf diese Daten lesen? Der Kernzweck von Confidential Computing ist es, den CSP, sein Rechenzentrumspersonal, die Hypervisor-Betreiber und die gemeinsam genutzte Infrastrukturschicht vollständig von dieser Liste zu streichen, nicht nur teilweise. Die zugrunde liegende Technologie ist klar definiert: hardwaregestützte Trusted Execution Environments (AMD SEV-SNP, Intel TDX), Speicherverschlüsselung zur Laufzeit und Remote Attestation, die CSPs als Primitive anbieten. Die Technologie ist solide. Die Frage ist, ob die Art ihrer Bereitstellung die binäre Eigenschaft bewahrt, für die die Technologie geschaffen wurde, oder sie stillschweigend in eine schwächere Aussage verwandelt, für die der CSP weiterhin selbst bürgen kann.

Confidential Computing erfolgreich einzuführen ist allerdings keine Frage des Umlegens eines VM-Schalters. Die Entscheidung teilt sich in zwei schwierigere Fragen:

1. Auf wessen Wort muss ich mich verlassen, dass der richtige Code auf der richtigen Hardware läuft? Die Frage der Attestierung.
2. Wie integriere ich das in den Rest meiner Cloud, in Kubernetes, Key-Management, Storage, IaC und Identity, ohne alles um ein herstellerspezifisches SDK herum neu zu bauen? Die Frage der Integration.

Die CSP-eigenen Angebote für Confidential Computing beantworten beide Fragen nur unzureichend. Die folgenden zwei Säulen erklären, warum.

Säule 1: Attestierung muss unabhängig von der Partei sein, die sie ausschließt

Das Bedrohungsmodell, das Organisationen für Confidential Computing interessiert, beginnt mit einer Festlegung: Der CSP darf nicht Teil unserer Trusted Computing Base sein. Jede daraus folgende Aussage, ob Datenschutz, Souveränität, regulatorische Compliance oder Multi-Party-Trust, hängt davon ab.

Attestierung ist der Mechanismus, der diese Aussage überprüfbar macht. Eine Workload misst sich selbst, die Hardware signiert die Messwerte mit einem Schlüssel, den der CSP nicht fälschen kann, und der Dateneigentümer oder ein in seinem Auftrag handelnder Auditor prüft diese Messwerte gegen bekannte, korrekte Referenzwerte für den Code, der laufen soll. Die Vertrauenskette endet beim Silizium-Hersteller, nicht beim Cloud-Anbieter.

Das funktioniert nur, wenn zwei Voraussetzungen erfüllt sind:

• Die Referenzwerte werden unabhängig festgelegt. Wenn Sie nicht genau wissen, welches Binary laufen soll, ist die Attestierung nur eine signierte Quittung für „irgendetwas“. Dafür muss der Quellcode der Workload öffentlich und ihre Builds müssen reproduzierbar sein, damit Sie oder Ihr Auditor aus dem Quellcode neu bauen und denselben Hash erhalten, den die Attestierung meldet. Die Produkte von Edgeless Systems sind quelloffen und reproduzierbar gebaut; die Confidential-Computing-Stacks der Cloud-Anbieter sind es nicht.
• Der Verifikationspfad hängt nicht von der Partei ab, die Sie ausschließen. Wenn der CSP die Nachweise abruft, durch seinen eigenen Verifikationsdienst laufen lässt und Ihnen ein „sieht gut aus“ zurückgibt, haben Sie ihn nicht ausgeschlossen. Sie haben ihn gebeten, sich selbst zu kontrollieren.

Wie der BSI C5:2026 Attestierung bewertet

Das Update 2026 des BSI-Kriterienkatalogs C5 (Cloud Computing Compliance Criteria Catalogue) führt explizite Kriterien für Confidential Computing ein. OPS-32 verlangt ein dokumentiertes technisches Rahmenwerk mit TEEs, Hardware-Attestierungen und Key-Management und hält ausdrücklich fest, dass „weder der Cloud-Anbieter noch eine andere unbefugte Partei in der Lage sein darf, auf die Daten des Cloud-Kunden oder die zu ihrem Schutz verwendeten Schlüssel zuzugreifen“ (OPS-32.03B). OPS-33 verlangt anschließend, dass Remote Attestation „auf kryptografischen Mitteln beruht, die in vertrauenswürdiger Hard- und Software verankert sind“ (OPS-33.02B), und dass der Cloud-Anbieter „eine Schnittstelle bereitstellt, über die der Kunde die Integrität der Remote Attestation überprüfen kann“ (OPS-33.03B).

OPS-33.01AC bewertet vier Betriebsszenarien danach, wo die Attestierungsnachweise verifiziert werden. Die Einstufung ist eindeutig:

Die meisten CSP-eigenen Umsetzungen von Confidential Computing fallen standardmäßig in Szenario 3 oder 4. Die C5-Einstufung verwendet abgestufte Begriffe, „weak“ und „strong“, doch die binäre Sicht ist schärfer: In Szenario 4 verifiziert sich der CSP selbst, und Sie können das Ergebnis nicht nutzen, um zu beweisen, dass der CSP Ihre Daten nicht lesen kann. Das Versprechen von Confidential Computing gegenüber dem CSP ist in diesem Szenario nicht teilweise erfüllt, es ist gar nicht erfüllt. Die Szenarien 1 und 2, die einzigen mit dem Ergebnis „very strong“, sind die einzigen, in denen die verifizierende Schicht unabhängig vom Anbieter ist. Genau das liefern Contrast und Privatemode AI strukturell: Nachweise, die direkt von der TEE abgerufen und vom Kunden verifiziert werden (oder vom Contrast Coordinator in seinem Auftrag, selbst eine vertrauliche, attestierbare Workload), gegen Referenzwerte, die der Kunde aus Open Source ableiten kann.

Säule 2: Eine vertrauliche Schicht muss sich in die von Ihnen genutzte Cloud integrieren

Confidential Computing, wie Cloud-Anbieter es heute bereitstellen, ist ein Primitiv: eine VM, die im Speicher verschlüsselt ist, mit Hardware-Attestierung. Doch Organisationen wechseln nicht wegen VMs in die Cloud. Sie wechseln wegen der Schicht darüber: Managed Kubernetes, Infrastructure as Code, Identity, Key-Management, Observability, GitOps. Eine vertrauliche Schicht, die diese Realität ignoriert, erzwingt eine unattraktive Wahl zwischen Sicherheit und Betreibbarkeit.

Durchgehender Schutz für ein cloud-natives Deployment erfordert mehr als eine Confidential VM. In der Praxis bedeutet das:

• Vertraulichkeit während der Verarbeitung. Workloads laufen in CVMs mit hardwareverankerter Attestierung, eine Grundvoraussetzung, die CSPs bereits bieten.
• Vertraulichkeit bei Speicherung und Übertragung, an die Attestierung gekoppelt. Container-Images, Secrets und persistenter Zustand werden mit Schlüsseln verschlüsselt, die erst nach erfolgreicher Attestierung freigegeben werden; der Pod-zu-Pod-Verkehr wird automatisch per mTLS mit Identitäten abgesichert, die die Attestierungsinstanz ausstellt. Keine separaten Abläufe, keine separaten SDKs.
• Attestierung auf Workload-Ebene. Jeder Pod wird einzeln vermessen und gegen eine Runtime-Policy verifiziert, die das exakte Container-Image, die Konfiguration und die zugelassenen Code-Pfade festlegt. Der Dateneigentümer verifiziert all das, bevor er sensible Daten sendet. Ohne diese Schicht hat die Attestierung nichts Konkretes, woran sie sich binden kann: Sie bestätigt, dass eine Confidential VM lief, aber nicht, dass der Code, der Ihre Daten verarbeitet, der von Ihnen vorgesehene war, oder dass nichts anderes daneben zugelassen wurde. Was wie eine Vertraulichkeitszusage aussieht, schrumpft zu einer signierten Quittung für „irgendetwas lief in einer CVM“, und das begründet gegenüber keiner Partei Vertraulichkeit, auch nicht gegenüber dem CSP. Genau diese Eigenschaft verlangen regulatorische Rahmenwerke wie die deutsche Gematik-VAU-Spezifikation für ePA-Workloads, und vertrauliche KI-Dienste wie Privatemode AI setzen sie konstruktionsbedingt voraus.
• Cloud-native, deklarative Integration. Vertrauliche Pods werden über eine Kubernetes RuntimeClass und Standard-Annotationen ausgewählt. Bestehende Helm-Charts, Kustomize-Overlays, ArgoCD-Pipelines und IaC-Tools funktionieren unverändert.
• Dasselbe Modell in jeder Cloud. Der Ansatz von Edgeless funktioniert auf Bare Metal, auf Managed-Kubernetes-Diensten mit hybriden Bare-Metal-Knoten und über AMD SEV-SNP und Intel TDX hinweg. Die proprietären CC-Angebote der Cloud-Anbieter, ob Hyperscaler oder regional, haben jeweils ihren eigenen Attestierungsablauf, ihr eigenes Muster zur Schlüsselfreigabe und ihr eigenes SDK; sich für eines zu entscheiden ist ebenso eine Frage der Portabilität wie der Sicherheit.

Wo anbietereigene Angebote aufhören

Die folgende Tabelle fasst zusammen, wo die Lücke liegt. Die CSPs liefern das Silizium und die VM. Was fehlt, ist die verifizierende, integrierende Schicht darüber. Ohne diese Schicht ist die Workload zwar im Speicher verschlüsselt, doch die binäre Sicherheitseigenschaft „der CSP kann diese Daten nicht lesen“ gilt nicht wirklich, weil der CSP weiterhin den Verifikationspfad kontrolliert, der das beweisen würde.

Was Edgeless Systems liefert

Contrast: vertrauliches Kubernetes, durchgängig. Ein quelloffenes Confidential-Computing-Framework, das jeden Pod in seiner eigenen CVM ausführt, ihn gegen ein kryptografisches Manifest attestiert und ein Service Mesh mit mTLS bereitstellt, das in der Attestierung verankert ist. Bestehende Container laufen unverändert. Reproduzierbare Builds ermöglichen es jedem Auditor, Referenzwerte unabhängig zu ermitteln. Contrast läuft auf Bare Metal und auf Managed Kubernetes mit hybriden Bare-Metal-Knoten.

Privatemode AI: ein vertraulicher SaaS, gebaut auf Contrast. Es ist ein gehosteter GenAI-Inferenzdienst, den Kunden über eine OpenAI- und Anthropic-kompatible API nutzen. Es ist keine Kubernetes-Schicht, die Sie ausrollen, sondern ein SaaS, den Sie aufrufen. Das Besondere ist die vertrauliche Schicht darunter: Der gesamte Dienst läuft auf Contrast, jeder Inferenz-Worker wird vom Client einzeln attestiert, bevor ein Prompt gesendet wird, und Prompts und Antworten bleiben selbst vor Edgeless Systems und der zugrunde liegenden Infrastruktur vertraulich. Privatemode AI ist der Beleg dafür, dass mit Contrast als Fundament selbst ein SaaS-Anbieter von den Daten seiner eigenen Kunden ausgeschlossen werden kann.

Beide Produkte verfolgen denselben Ansatz bei der Attestierung: quelloffen, reproduzierbar gebaut, in Hardware verankert und vom Kunden überprüfbar. Contrast ist die cloud-native vertrauliche Schicht für Kubernetes-Workloads. Privatemode AI ist das, was diese Schicht für eine der Workloads ermöglicht, bei denen der Ausschluss des Anbieters nicht länger optional ist: GenAI-Inferenz.

Das Fazit

Confidential Computing ist eine binäre Eigenschaft. Die Vertraulichkeitszusage gilt entweder auf eine Weise, die der Kunde verifizieren kann, unabhängig von den Parteien, die die Workload betreiben, oder sie gilt nicht. Cloud-Anbieter stellen die zugrunde liegenden Primitive bereit, können aber nicht zugleich die Partei sein, die sie verifiziert. Und die Angebote, die sie darüberlegen, selbst die, die weiter oben im Stack ansetzen, sind proprietär und an eine einzige Cloud gebunden, was Verifikation und Portabilität wieder in die Hände des Anbieters legt. Beide Lücken zu schließen, Verifikation und Integration, dafür sind die Produkte von Edgeless Systems gebaut. Um auf der überprüfbaren Seite dieser Linie zu landen und es einem Auditor, einer Regulierungsbehörde oder einem Kunden zu beweisen, muss jedes Glied der Verifikationskette unabhängig von den Parteien sein, die Sie ausschließen wollen: vom verifizierten Code über die Referenzwerte, gegen die er geprüft wird, bis zum kryptografischen Nachweis selbst.