Confidential Computing: Intel TDX vs. AMD SEV-SNP 2026

Der fehlende dritte Datenzustand

Sicherheitsteams sprechen fast reflexartig von zwei Datenzuständen: im Ruhezustand (Festplattenverschlüsselung) und bei der Übertragung (TLS). Der dritte Zustand – Daten in Verarbeitung (Data in Use), also alles, was entschlüsselt im Arbeitsspeicher liegt, während eine CPU es verarbeitet – blieb strukturell ungeschützt, bis Hardwarehersteller Chips auslieferten, die mit verschlüsselten Daten rechnen können, ohne dem Host-Betriebssystem jemals Klartext preiszugeben. Confidential Computing ist dieses fehlende Glied im Verschlüsselungslebenszyklus.

Das ist 2026 wichtiger als noch vor einigen Jahren, weil sich die Workloads verändert haben, die geschützt werden sollen. Werden KI-Inferenz oder -Training auf sensiblen Daten ausgeführt – Patientenakten, Transaktionshistorien, Verteidigungsinformationen –, ist eine Offenlegung im Klartext auf einem gemeinsam genutzten Cloud-Host für eine wachsende Zahl britischer Organisationen inakzeptabel, unabhängig davon, wie stark die Perimetersicherheit rund um diesen Host ist.

Wie Trusted Execution Environments tatsächlich funktionieren

Ein Trusted Execution Environment (TEE) ist eine hardwareseitig erzwungene Grenze. Confidential VMs auf Basis von Intel TDX und AMD SEV-SNP isolieren Speicher und CPU-Zustand kryptografisch, sodass weder ein Host-Administrator noch ein Hypervisor-Prozess – einschließlich der eigenen Betreiber des Cloud-Anbieters – sie einsehen oder verändern kann. Das Vertrauensmodell wird damit praktisch umgekehrt: Statt dem Cloud-Betreiber vertraut man dem Silizium.

Der Nachweismechanismus ist die kryptografische Attestierung. Bevor einem Workload vertraut wird, signiert die Plattform einen Bericht mit Plattformidentität, Firmware-Messwerten und einer vom Verifizierer bereitgestellten Nonce. So kann eine entfernte Partei bestätigen, dass der Workload echten, unveränderten Code innerhalb eines echten TEE ausführt – und nicht in einer gefälschten oder manipulierten Umgebung.

• •Speicherverschlüsselung – individuelle Schlüssel pro VM verhindern, dass der Host den RAM des Gastes auslesen kann
• •Isolation des CPU-Zustands – Register und Ausführungszustand sind vor dem Hypervisor abgeschirmt
• •Attestierungsberichte – signierter Nachweis von Plattformidentität und Code-Integrität
• •Hardwaregeschützte virtuelle TPMs – bescheinigen den Zustand der VM und unterstützen gehärtetes Schlüsselmanagement wie BitLocker auf Azure Confidential VMs

Intel TDX vs. AMD SEV-SNP: die technischen Details

Intel TDX nutzt Multi-Key Total Memory Encryption (MKTME), um jeder Trust Domain einen eigenen AES-128-XTS-Schlüssel zuzuweisen und deren Speicher sowohl vom Hypervisor als auch vom Host-Betriebssystem zu isolieren. Da TDX keinen dedizierten Sicherheitsprozessor besitzt, läuft die Attestierung in zwei Schritten: Das TDX-Modul erzeugt mithilfe des Befehls SEAMREPORT einen Bericht, und eine Quoting Enclave – selbst eine SGX-Enklave – signiert ihn zu einem Vertrauensnachweis (Quote), den eine entfernte Gegenstelle prüfen kann. Wer Plattformen dafür spezifiziert, sollte das zugrunde liegende Silizium verstehen; Intel-Xeon-6-Prozessoren sind die aktuelle Generation mit TDX-Unterstützung (TDX gab es bereits bei Xeon Scalable der 5. Generation).

AMD SEV-SNP geht architektonisch einen anderen Weg und ergänzt Secure Nested Paging, um hypervisorbasierte Angriffe auf die Seitentabellen des Gastes zu unterbinden. Es verschlüsselt den Speicher zur Laufzeit, strukturiert die Seitentabellen so um, dass der Host sie weder lesen noch manipulieren kann, und führt eine Attestierung beim Start ein, die die Integrität des Gastspeichers ab dem Booten der VM verifiziert. Auf Hardwareseite ist dies der Confidential-Computing-Funktionsumfang, der in AMD-EPYC-Turin-Prozessoren integriert ist.

In der Praxis sind die beiden keine austauschbaren Optionen – sie passen zu unterschiedlichen Risikoprofilen. AMD SEV-SNP wird wegen seines geringeren Performance-Overheads für CPU-lastige Workloads in der Finanzdienstleistungsbranche und im Gesundheitswesen im Allgemeinen bevorzugt, während Intel TDX eher bei Behörden-, Verteidigungs- und Hochsicherheits-KI-Workloads die Nase vorn hat, wo sein Attestierungsmodell als die stärkere Absicherung gilt.

Performance-Overhead in der Praxis

Confidential Computing gibt es nicht umsonst, und der Overhead hängt stark vom Profil des Workloads ab – ein Detail, das die meisten Erklärtexte komplett auslassen. Speziell bei AMD SEV-SNP verzeichnen CPU-intensive Workloads rund 2–5 % Overhead, während speicherintensive Anwendungen 5–10 % langsamer laufen – Ausdruck des zusätzlichen Aufwands, den Speicher bei jedem Zugriff zu verschlüsseln und zu prüfen.

Eine separate empirische Analyse von AMD SEV-SNP ergab allein durch die Verschlüsselung einen Overhead beim Speicherzugriff von bis zu 7 %, wobei die Speicherlatenz bei manchen Zugriffsmustern auf das bis zu 5-Fache stieg. Noch auffälliger: Worst-Case-Szenarien mit exzessiven Kontextwechseln und Speicherkopiervorgängen zeigten Overhead-Spitzen von bis zu 400 % – ein Wert, der speziell für dieses pathologische Muster gilt, nicht für typische Workloads im stabilen Dauerbetrieb.

Die praktische Konsequenz: Gehen Sie nicht von einem pauschalen Overhead-Prozentsatz aus. Datenbank- oder virtualisierungslastige Workloads mit häufigen Kontextwechseln müssen vor der Migration einem Benchmark unterzogen werden, weil sie am äußersten Ende dieser Spanne liegen, während einfache CPU-gebundene Analyse- oder Inferenzjobs deutlich näher an einstelligen Werten liegen.

Kostenfolgen für britische Käufer

Kein großer Anbieter veröffentlicht eine konkrete GBP-Preisliste für Confidential-Instanzen, doch Branchenschätzungen zufolge sind Confidential VMs in der Public Cloud rund 15–25 % teurer als vergleichbare Standardinstanzen. Dieser Aufpreis muss gegen das abgewogen werden, was er bringt: eine technische, prüfbare Antwort auf die Frage „Kann Ihr Anbieter unsere Daten lesen?“ – zunehmend genau die Frage, die Aufsichtsbehörden und Kunden tatsächlich stellen.

Speziell bei Bedenken hinsichtlich grenzüberschreitenden Vertrauens sollten britische Käufer bei den Anbietern auf eine lokale Attestierung drängen – also einen Attestierungsdienst in einer selbst gewählten Region nutzen (Azure Attestation etwa läuft in regionalen Instanzen) und bei Bedarf eine private Anbindung an die Attestierungs-Endpunkte sicherstellen (zum Beispiel über AWS PrivateLink), statt einen standardmäßigen globalen Attestierungs-Endpunkt zu akzeptieren. So wird vermieden, dass eine unnötige Vertrauensabhängigkeit vom Ausland in ein ansonsten souveränes Deployment gelangt.

UK-Compliance: DSGVO und Branchenregulierung

Confidential Computing liefert britischen Organisationen etwas, das Artikel 32 DSGVO schon immer verlangt, aber selten bekommen hat: technische, überprüfbare Nachweise für die Sicherheit der Verarbeitung statt eines vertraglichen Versprechens. Attestierungsberichte liefern Prüfern den kryptografischen Beweis, dass ein Workload in einer isolierten, unveränderten Umgebung lief – ein wesentlich belastbareres Compliance-Artefakt als die Standard-Geschäftsbedingungen eines Cloud-Anbieters.

Am stärksten wirkt sich das in regulierten Branchen aus. NHS-Einrichtungen, die KI auf Gesundheitsdaten anwenden, FCA-regulierte Finanzunternehmen, die Transaktionshistorien verarbeiten, und Verteidigungsprojekte im MOD-Umfeld teilen dasselbe Grundproblem: Sie müssen Rechenleistung auf Daten anwenden, die zu sensibel sind, um sie einem Drittanbieter-Host im Klartext offenzulegen. Sowohl die Pflichten aus den NIS Regulations als auch – für britische Unternehmen, die KI-Systeme in die EU liefern – die Compliance mit dem EU AI Act profitieren davon, dass TEE-basierte Attestierung den Prüfaufwand für regulierte Workloads senkt. Ist der Schutz von Daten in Verarbeitung Teil eines umfassenderen Sicherheitsreviews, lohnt es sich, ihn mit dem Leitfaden zu unseren Cybersecurity-Lösungen zu kombinieren, der den Rest des Stacks abdeckt.

Praktische Umsetzung: Schritte und Fallstricke

Die Migration eines sensiblen Workloads folgt typischerweise einem ähnlichen Muster: Workload und regulatorischen Treiber identifizieren, TDX oder SEV-SNP wählen – je nachdem, ob die Stärke der Attestierung oder ein geringerer Overhead wichtiger ist –, die Confidential-VM-Instanz in der gewählten Cloud bereitstellen und die Prüfung der Attestierung in die Deployment-Pipeline integrieren, statt sie als einmalige Kontrolle zu behandeln. Auf Azure lässt sich dies mit einem hardwaregeschützten virtuellen TPM kombinieren, um den Zustand der VM zu bescheinigen und gehärtetes Schlüsselmanagement wie BitLocker zu unterstützen.

Unterhalb der VM-Abstraktion sind TDX und SEV-SNP CPU-Primitive für hardwaregestützte vertrauliche Virtualisierung – sie erzwingen auf Hardwareebene eine Trennung zwischen der Systemsoftware und der Confidential VM selbst. Das bedeutet, dass der Gast-Kernel so gebaut oder konfiguriert sein muss, dass er in diesem isolierten Modus läuft, statt als Drop-in-Image behandelt zu werden. AMD SEV-SNP strukturiert insbesondere die Seitentabellen des Gastes so um, dass der Host keinen Zugriff hat, und attestiert beim Booten die Integrität des Gastspeichers. Die gemessene Boot-Kette – Firmware plus initialer Kernel-Zustand – wird dadurch Teil dessen, was tatsächlich verifiziert wird, und nicht erst nachträglich angeflanscht. Die Integration des virtuellen TPM, die auf Azure Confidential VMs für Schlüsselmanagement im Stil von BitLocker genutzt wird, ist selbst ein Berührungspunkt auf Ebene des Gastbetriebssystems und nichts, was transparent unterhalb des Betriebssystems geschieht.

Die Fallstricke sind eher operativer als konzeptioneller Natur. Attestierung fügt einen Prüfschritt hinzu, der automatisiert und überwacht werden muss, statt nur einmal beim Deployment zu laufen. Das Debugging wird tatsächlich schwieriger: Host-Tools, mit denen sich früher der Gastspeicher zur Fehlersuche inspizieren ließ, können schlicht nicht in eine verschlüsselte Enklave hineinsehen – das verändert, wie Incident Response und Performance-Diagnose funktionieren. Bestehende Sicherheits- und Monitoring-Agents benötigen zudem oft TEE-fähige Versionen, da herkömmliche hostbasierte Tools keinen Einblick in das haben, was sie eigentlich schützen sollen. Organisationen, die Confidential VMs in der Cloud gegen einen On-Premises- oder Hybrid-Aufbau mit TEE-fähigen CPUs abwägen, sollten die Optionen durchgehen, wenn sie einen Server konfigurieren.

• •Kosten: Confidential VMs verursachen einen Aufpreis von 15–25 % gegenüber Standardinstanzen in der Public Cloud – eigene On-Premises-Hardware mit TEE-fähigen CPUs (Xeon 6, EPYC Turin) vermeidet diesen wiederkehrenden Aufpreis bei regulierten Workloads im Dauerbetrieb, erfordert dafür aber eine Vorabinvestition in Hardware
• •Kontrolle über die Attestierung: On-Premises-Deployments behalten die gesamte Attestierungskette und die Referenzwerte der Firmware-Messungen im eigenen Haus; Public Cloud bedeutet, dem Attestierungsdienst des Anbieters zu vertrauen, sofern man nicht auf einem Attestierungsdienst in einer selbst gewählten Region besteht, erreichbar über eine private Anbindung wie AWS PrivateLink
• •Prüfaufwand: Beide Modelle erzeugen dieselben kryptografischen Attestierungsberichte als Nachweis nach Artikel 32 DSGVO, doch On-Premises beseitigt jede Frage grenzüberschreitender Datenresidenz vollständig – relevant für Workloads im MOD-Umfeld oder des NHS
• •Workload-Eignung: Intel TDX (stärkere Attestierung, bevorzugt für Behörden/Verteidigung/Hochsicherheits-KI) oder AMD SEV-SNP (geringerer Overhead, bevorzugt für Finanz-/Gesundheitswesen) passend zum Workload wählen – unabhängig davon, ob er in der Public Cloud oder On-Premises betrieben wird

Confidential AI und die Zukunft nach 2026

Der deutlichste Treiber hinter der Dynamik von Confidential Computing Mitte 2026 ist KI auf sensiblen Daten. Inferenz- oder Trainings-Workloads auf regulierten Datensätzen auszuführen, ohne dem Cloud-Anbieter Klartext offenzulegen, entwickelt sich vom Nice-to-have zur Grundanforderung – und genau dieser Anwendungsfall treibt die Einführung von TDX und SEV-SNP in britischen Cloud-Deployments am schnellsten voran.

Beim Umfang ist Nüchternheit angebracht: Confidential Computing ist hochwirksam gegen die häufigste Datenschutzsorge in der Cloud – den Zugriff des Anbieters selbst auf Kundendaten –, hinterlässt aber Restrisiken, die weiterhin ergänzende Kontrollen wie Netzwerksicherheit, Zugriffsmanagement und Endpoint-Schutz erfordern. Es schließt eine bestimmte, bislang offene Lücke im Verschlüsselungslebenszyklus; den Rest eines Sicherheitsprogramms ersetzt es nicht.

Quellen

Jede Zahl in diesem Artikel lässt sich auf die folgenden Quellen zurückführen.

• •Stealth Cloud – ausführliche Analyse zu Confidential Computing und Umfang des Bedrohungsmodells
• •Onidel – Performance-Overhead und Workload-Eignung von AMD SEV-SNP vs. Intel TDX
• •Red Hat – Quoting Enclave und Attestierungsarchitektur von Intel TDX
• •Microsoft Azure Docs – FAQ zu Confidential VMs, Funktionsvergleich TDX/SEV-SNP
• •Ian Klatzco – Funktionsweise der kryptografischen Attestierung
• •Ubuntu – Erläuterung des Vertrauensmodells von Confidential Computing
• •ServerMall – Mandantenisolation per TEE und Anwendungsfälle für regulierte Workloads
• •Sekyourity Blog – Details zu den Hardware-Primitiven von AMD SEV-SNP und Intel TDX
• •1C Confidential VMs (YouTube) – empirische Werte zum Overhead bei Speicher und Kontextwechseln