Über den größten Teil der Geschichte der Datenverarbeitung wurden Daten in zwei Zuständen geschützt: ruhend, mit Festplattenverschlüsselung, und bei der Übertragung, mit TLS. Der dritte Zustand, Daten in Verwendung, lag im Klartext im Arbeitsspeicher, sobald eine CPU sie berührte. Jeder mit Kontrolle über den Host, den Hypervisor oder physischem Zugriff auf die Maschine konnte sie lesen. Für regulierte und souveräne Workloads in Europa ist genau diese Lücke das eigentliche Problem.
Confidential Computing schließt sie. In Kombination mit modernen Isolationsprimitiven wie MicroVMs verändert es, was Sie glaubhaft über einen Workload zusichern können: dass der Betreiber der Infrastruktur die Daten nicht lesen kann, dass Sie dies kryptografisch nachweisen können und dass das Ganze nach EU-Recht auf EU-Boden läuft. Dieser Beitrag behandelt beide Hälften dieser Geschichte, die zugrunde liegenden Standards und die Hardware, sowie eine ehrliche Einschätzung, wo die Technologie 2026 tatsächlich steht.
Was Confidential Computing ist
Confidential Computing schützt Daten während ihrer Verarbeitung, indem es sie innerhalb einer hardwarebasierten Trusted Execution Environment (TEE) ausführt. Die TEE verschlüsselt den Arbeitsspeicher transparent und isoliert den Workload von allem außerhalb davon, einschließlich des Host-Betriebssystems, des Hypervisors, anderer Mandanten und des eigenen Personals des Cloud-Betreibers. Das ist Verschlüsselung bei der Verwendung, der fehlende dritte Zustand.
Die praktische Konsequenz ist wichtiger als der Mechanismus. In einer ordnungsgemäß attestierten TEE kann die Instanz, die die Hardware betreibt, Ihren Klartext nicht sehen. Ein Hosting-Anbieter, ein Hyperscaler oder ein internes Plattform-Team wird technisch unfähig, zu lesen, was innerhalb der Enklave läuft, nicht bloß vertraglich daran gehindert. Für Workloads, bei denen das Bedrohungsmodell den Betreiber einschließt, oder bei denen eine ausländische Jurisdiktion diesen Betreiber zwingen könnte, ist dies eine kategorische Verschiebung.
Warum es für Souveränität und DSGVO wichtig ist
Datensouveränität und Datenresidenz sind verschiedene Dinge. Residenz ist, wo Bytes physisch liegen. Souveränität ist, welche Gesetze sie regeln und wer rechtmäßig Zugriff erzwingen kann. EU-Datenresidenz allein hindert ein außereuropäisches Mutterunternehmen nicht daran, extraterritorialen rechtlichen Forderungen zu unterliegen.
Confidential Computing stärkt das Souveränitätsargument auf der technischen Ebene. Wenn Daten innerhalb einer TEE verarbeitet werden und die Entschlüsselungsschlüssel erst nach einer Attestierung gegenüber Schlüsseln freigegeben werden, die sich außerhalb der Kontrolle des Betreibers befinden, kann der Betreiber unabhängig von der ihm zugestellten rechtlichen Forderung keinen lesbaren Klartext herausgeben. Seien Sie präzise hinsichtlich des regulatorischen Status: Keine EU-Datenschutzbehörde hat Confidential Computing bisher als eigenständige zusätzliche Maßnahme nach Artikel 46 Absatz 2 DSGVO anerkannt. Behandeln Sie es als starke Defense-in-Depth, die ein Transfer Impact Assessment materiell verbessert, nicht als Wundermittel für die Compliance. Die ehrliche Darstellung ist die glaubwürdige.
Die Hardware: SEV-SNP, TDX, CCA
Drei CPU-Hersteller liefern heute Confidential Computing auf VM-Ebene aus, wobei jeder eine gesamte virtuelle Maschine schützt, anstatt von Ihnen zu verlangen, Anwendungen für eine kleine Enklave umzuschreiben:
- AMD SEV-SNP (Secure Encrypted Virtualization with Secure Nested Paging) verschlüsselt den VM-Arbeitsspeicher pro Gast und fügt Integritätsschutz hinzu, sodass ein bösartiger Hypervisor den Gast-Arbeitsspeicher nicht umordnen, wiederholen oder manipulieren kann. Breit verfügbar über Server-Plattformen hinweg.
- Intel TDX (Trust Domain Extensions) erstellt hardware-isolierte „Trust Domains” mit verschlüsseltem Arbeitsspeicher und Hypervisor-Isolation sowie integrierter Remote Attestation. Verfügbar auf aktuellen Xeon-Generationen.
- ARM CCA (Confidential Compute Architecture) führt „Realms” ein, hardware-isolierte Umgebungen für Code und Daten. Es ist das jüngste der drei und zielt klar auf das Edge- und ARM-Server-Ökosystem ab, auch wenn die breite Verfügbarkeit gegenüber x86 noch hinterherhinkt.
Das ältere Enklave-Modell, Intel SGX, schützt einen kleinen Ausschnitt einer Anwendung statt einer ganzen VM. Es bleibt für eng abgegrenzte Geheimnisse relevant, ist aber schwerer einzuführen als die obigen Ansätze auf VM-Ebene. Die richtige Wahl hängt von Ihrem Silizium, Ihrem Cloud- oder Hardware-Partner und Ihrem Workload ab, was genau die Art von Entscheidung ist, die eine herstellerneutrale Beratung mit Ihnen treffen sollte und nicht zugunsten eines Produkts.
Attestierung ist der tragende Teil
Eine TEE ist nur dann nützlich, wenn Sie nachweisen können, dass ein Workload innerhalb einer echten, unveränderten Umgebung läuft, bevor Sie ihr Geheimnisse anvertrauen. Dieser Nachweis ist Remote Attestation, und es ist der Teil, den die meisten Teams unterschätzen.
Das herstellerneutrale mentale Modell stammt aus der IETF-RATS-Architektur (RFC 9334), die drei Rollen benennt: Der Attester erzeugt signierte Belege über seine Umgebung, der Verifier prüft diese Belege gegen bekannte, gute Referenzwerte, und die Relying Party gibt Schlüssel oder Daten nur bei einem positiven Ergebnis frei. In der Praxis sieht der Ablauf so aus: Die TEE generiert hardware-signierte Belege, ein Verifier bestätigt die Firmware und die Messwerte, und erst dann gibt ein Key Broker die Geheimnisse frei, die zum Entschlüsseln von Daten oder zum Abrufen eines Modells benötigt werden. Keine gültige Attestierung, keine Schlüssel.
Der Open-Source-Software-Stack
Confidential Hardware benötigt Software, um in Cloud-nativen Umgebungen nutzbar zu sein. Die führende Open-Source-Initiative ist Confidential Containers (CoCo), ein CNCF-Projekt, das jeden Kubernetes-Pod innerhalb seiner eigenen TEE ausführt und Confidential Computing auf Pod-Ebene standardisiert. CoCo umfasst die wichtigsten Hardware-Backends (SEV-SNP, TDX, SGX, IBM Secure Execution) und arbeitet mit dem Trustee-Projekt für die Attestierung zusammen, einschließlich eines Key Broker Service, der die Freigabe von Geheimnissen an eine bestandene Attestierung knüpft. CoCo baut auf Kata Containers auf, das weiter unten behandelt wird, für seine VM-isolierte Laufzeitumgebung. Es gibt weitere offene Implementierungen im selben Bereich, und die Stärke des Ökosystems liegt darin, dass die Muster für Attestierung und Schlüsselfreigabe sich auf gemeinsame Standards zubewegen statt auf die API eines einzelnen Herstellers.
MicroVMs und sichere Isolation
Confidential Computing beantwortet die Frage „Kann der Betreiber dies lesen?”. MicroVMs beantworten eine verwandte, aber eigenständige Frage: „Wenn ein Workload kompromittiert wird, kann er die anderen erreichen?”. Diese ergänzen sich, sie sind nicht austauschbar.
Der Standard-Linux-Container teilt sich den Host-Kernel. Ein einziger Kernel-Ausbruch, etwa CVE-2024-21626 in runc, und der Schadensradius umfasst den gesamten Knoten. Für echten Multi-Tenant- oder nicht vertrauenswürdigen Code ist ein gemeinsamer Kernel eine zu dünne Wand. Die Alternativen:
- Firecracker ist ein minimaler, in Rust geschriebener VMM, eigens für Serverless entwickelt. Er bootet eine MicroVM in etwa 125 ms mit einem Fußabdruck von wenigen MB pro VM, indem er das Gerätemodell auf das Wesentliche reduziert. Bekanntermaßen treibt er AWS Lambda und Fargate an.
- Cloud Hypervisor ist ein weiterer moderner Rust-VMM, mit einem reichhaltigeren Gerätemodell als Firecracker und breiter Hardware-Unterstützung. Er ist das Standard-Backend für Kata Containers.
- Kata Containers lässt VM-taugliche Isolation wie Container wirken: Jeder Pod läuft in einer leichtgewichtigen VM hinter einer Standard-OCI-/Kubernetes-Schnittstelle. Es unterstützt Cloud Hypervisor, Firecracker und QEMU als Backends, sodass Sie den Kompromiss zwischen Isolation und Kompatibilität feinjustieren können.
- gVisor geht einen anderen Weg, einen Userspace-Kernel, der Syscalls abfängt. Keine vollständige VM, geringerer Overhead als bei Virtualisierung, starke Isolation für viele Multi-Tenant-Fälle, mit einigen Kompatibilitätsgrenzen für syscall-intensive Workloads.
Wo jedes hineinpasst
Ordnen Sie das Werkzeug dem Workload zu, nicht dem Hype:
- Multi-Tenant-SaaS und gemeinsam genutztes Kubernetes: Kata Containers oder gVisor, um Mandanten hinter einer harten Grenze einzudämmen.
- Schnell bootende Sandboxes und Serverless-Funktionen: Firecracker, wo Kaltstarts unter einer Sekunde und Dichte dominieren.
- Sichere CI und Ausführung nicht vertrauenswürdigen Codes: MicroVMs, um beliebige Builds oder Kundencode auszuführen, ohne ihnen zu vertrauen.
- Isolierung von KI-Inferenz: eine dedizierte VM-Grenze pro Modell oder pro Mandant, sodass ein kompromittierter Inferenzpfad nicht weiterschwenken kann.
Die beiden Ebenen lassen sich stapeln. Sie können einen Kata- oder CoCo-Pod ausführen, dessen zugrunde liegende VM selbst eine Confidential VM auf SEV-SNP oder TDX ist, und erhalten so sowohl die Betreiber-Blindheit als auch die Mandanten-Isolation aus einer einzigen Bereitstellung.
Confidential AI Inference
Der am schnellsten wachsende Treiber ist KI. Prompts, abgerufene Dokumente oder Feintuning-Daten an ein LLM zu senden, bedeutet, einen Teil Ihres sensibelsten Materials demjenigen offenzulegen, der die Inferenz betreibt. Confidential AI verringert diese Offenlegung.
Die NVIDIA H100 war die erste GPU mit einer Hardware-TEE: Im vertraulichen Modus schützt sie Code und Daten auf der GPU mit verschlüsseltem VRAM und einer On-Die-Vertrauenswurzel, und sie kombiniert sich mit einer Confidential-CPU-VM (SEV-SNP oder TDX), sodass Daten durchgängig über CPU und GPU hinweg verschlüsselt bleiben. Die Attestierung erstreckt sich auf die GPU, sodass eine Relying Party sowohl die CPU- als auch die GPU-Umgebung verifizieren kann, bevor Modellgewichte oder Daten freigegeben werden. Der veröffentlichte Overhead ist moderat, in der Größenordnung weniger Prozentpunkte beim Durchsatz für viele LLM-Inferenz-Workloads, zuzüglich einmaliger Attestierungskosten beim Start. Das Ergebnis: Prompts und Ausgaben bleiben selbst vor dem Host privat, und die Ausführung ist kryptografisch verifizierbar. Für europäische Organisationen, die moderne KI nutzen wollen, ohne regulierte Daten in eine undurchsichtige Umgebung zu schicken, ist dies die Brücke.
Ehrliche Reife und Kompromisse
Das ist mächtig, aber es ist weder kostenlos noch fertig:
- Die Reife variiert stark. SEV-SNP und TDX sind produktionsreif; ARM CCA und Teile des GPU-TEE-Ökosystems sind früher dran. Das Tooling, insbesondere die Attestierungsinfrastruktur, reift noch.
- Attestierung ist operative Arbeit. Verifier, Referenzwerte und Key Broker sind der schwierige Teil, und entweder Sie oder Ihr Partner verantworten sie.
- Der Performance-Overhead ist real, aber meist gering. Planen Sie mit wenigen Prozent, mehr bei speichergebundenen oder I/O-intensiven Mustern, und benchmarken Sie Ihren eigenen Workload.
- Es ist kein Compliance-Häkchen. Es stärkt eine DSGVO- und Souveränitätsposition; es ersetzt keine rechtliche Prüfung, keine Schlüsselverwaltung und keine fundierte Gesamtarchitektur.
- Vertrauensgrenzen verschieben sich, sie verschwinden nicht. Sie vertrauen weiterhin der Vertrauenswurzel des Siliziumherstellers und Ihrer Verifizierungslogik. Wissen Sie, was sich in Ihrer Trusted Computing Base befindet.
FAQ
Ersetzt Confidential Computing die Verschlüsselung ruhender und übertragener Daten? Nein. Es ergänzt den dritten Zustand, in Verwendung, und arbeitet neben den anderen beiden.
Kann der Cloud-Betreiber meine Daten innerhalb einer TEE trotzdem lesen? Bei korrekter Attestierung und externer Schlüsselkontrolle: nein. Der Betreiber kann keinen lesbaren Klartext herausgeben, was der zentrale Souveränitätsvorteil ist.
Brauche ich Confidential Hardware, um MicroVMs zu nutzen? Nein. Firecracker, Cloud Hypervisor, Kata und gVisor bieten starke Isolation auf Standard-Hardware. Confidential Computing ist eine separate Schicht, die Sie obendrauf hinzufügen können.
Ist das von Haus aus DSGVO-konform? Es stärkt die Compliance und Transfer Impact Assessments als Defense-in-Depth, aber keine EU-Datenschutzbehörde hat es als eigenständige zusätzliche Maßnahme bestätigt. Behandeln Sie es als eine von mehreren starken Kontrollen.
Auf welche CPU sollte ich mich standardisieren? Das hängt von Ihrem Stack, Ihren Partnern und Ihrem Workload ab. Wir bewerten SEV-SNP, TDX und CCA anhand Ihrer tatsächlichen Anforderungen, statt eine einzelne Option zu pushen.
Wo Rapid Solutions hineinpasst
Wir sind eine herstellerneutrale Engineering-Beratung und ein Managed-Services-Partner, kein Cloud-Anbieter. Wir konzipieren und betreiben vertrauliche, hardware-isolierte Workloads auf Open-Source-Grundlagen, mit von Grund auf integrierter EU-Datenresidenz und -souveränität, und wir passen uns an den Stack an, den Sie bereits haben, statt Sie an unseren zu binden. Ob Sie SEV-SNP gegen TDX abwägen, Confidential Containers mit ordnungsgemäßer Attestierung aufsetzen, Multi-Tenant-Workloads mit Kata oder Firecracker isolieren oder Confidential AI Inference betreiben, wir helfen Ihnen, es richtig zu machen und nachzuweisen, dass es funktioniert.