Confidential Computing

Confidential Computing bezeichnet den Schutz von Daten während ihrer Verarbeitung: Anwendung und Daten laufen in einer hardwarebasierten, isolierten und nachprüfbaren Ausführungsumgebung (Trusted Execution Environment, TEE), auf die weder das Betriebssystem des Hosts noch der Cloud-Betreiber noch ein Administrator mit Root-Rechten zugreifen kann.

Verschlüsselung gab es lange nur für zwei Zustände von Daten: auf der Festplatte (at rest) und auf dem Weg durchs Netz (in transit). Sobald ein Programm mit den Daten rechnet, liegen sie im Arbeitsspeicher im Klartext. Genau dort setzt Confidential Computing an. Der Prozessor verschlüsselt den Speicherbereich der geschützten Umgebung mit Schlüsseln, die nur er kennt, und weist jeden Zugriff von außen ab. Wer den physischen Server kontrolliert, sieht nur Rauschen.

Für Geschäftsführer und CTOs im Mittelstand ist das Thema aus zwei Gründen relevant geworden. Erstens laufen immer mehr sensible Workloads bei einem Hyperscaler, und die Frage, wer dort technisch mitlesen kann, ist eine Frage von Datenschutz und Haftung. Zweitens rücken KI-Agenten in den Alltag, die mit Postfach, Kalender, Kundendaten und Zahlungsmitteln arbeiten. Dass ein Anbieter verspricht, nicht hinzusehen, ist eine Vertragszusage. Dass er technisch nicht hinsehen kann, ist eine Architekturentscheidung. Confidential Computing ist der Versuch, aus dem Versprechen einen Beweis zu machen.

Die drei Zustände von Daten im Vergleich

Die folgende Tabelle ordnet die drei Schutzebenen ein. Sie ergänzen sich, keine ersetzt die andere.

Der Punkt „in use" war jahrzehntelang die offene Flanke. Wer einen Server kontrolliert, konnte den Arbeitsspeicher jederzeit auslesen. In einer Public Cloud ist dieser „Wer" ein fremdes Unternehmen mit eigenen Administratoren, eigenem Rechtsrahmen und eigenen Behördenkontakten.

So funktioniert die Technik

Trusted Execution Environments und Enklaven

Ein TEE ist ein durch den Prozessor abgeschotteter Bereich. Die CPU verwaltet dafür eigene Schlüssel in der Hardware, verschlüsselt den zugehörigen Arbeitsspeicher auf dem Weg zum RAM-Riegel und entschlüsselt ihn erst wieder innerhalb des Chips. Das Host-Betriebssystem kann die geschützten Seiten zwar verwalten, also zuweisen oder auslagern, aber nicht lesen. Zwei Bauformen haben sich durchgesetzt:

• Enklaven auf Prozessebene. Ein einzelnes Programm oder ein Teil davon läuft in einem geschützten Speicherbereich. Der Rest der Anwendung, das Betriebssystem und der Hypervisor bleiben außen vor. Intel SGX (Software Guard Extensions) ist das bekannteste Beispiel. Der Ansatz ist präzise, verlangt aber, dass Software eigens für die Enklave geschrieben oder mit Hilfsbibliotheken angepasst wird.
• Confidential VMs. Eine ganze virtuelle Maschine samt Gastbetriebssystem liegt verschlüsselt im Speicher. Der Hypervisor startet und stoppt sie, kann aber nicht in sie hineinschauen. Für Betreiber ist das der pragmatische Weg, weil bestehende Anwendungen ohne Codeänderung umziehen können.

Die Hardware: Intel, AMD, Arm, NVIDIA

Confidential Computing ist an Prozessorfunktionen gebunden. Drei Architekturen dominieren:

• Intel SGX und TDX. SGX schützt einzelne Enklaven innerhalb eines Prozesses und ist heute vor allem auf Xeon-Serverprozessoren verfügbar. TDX (Trust Domain Extensions) ist Intels Antwort auf den VM-Ansatz: Eine „Trust Domain" ist eine komplette virtuelle Maschine mit eigenem, hardwareverschlüsseltem Speicher.
• AMD SEV-SNP. Secure Encrypted Virtualization gibt es seit der ersten EPYC-Generation. Die Ausbaustufe SEV-SNP (Secure Nested Paging) ergänzt Integritätsschutz gegen Angriffe eines bösartigen Hypervisors, etwa Speicher-Remapping oder das Wiedereinspielen alter Speicherinhalte. SEV-SNP ist die Basis der meisten Confidential VMs bei Azure und Google Cloud.
• Arm CCA. Die Confidential Compute Architecture ist Teil von Armv9-A und führt „Realms" ein, eine vierte Sicherheitswelt neben Normal World, Secure World und Root World. Die Realm Management Extension isoliert Realms vom Hypervisor. Details stehen auf der Arm-Seite zur Confidential Compute Architecture.
• NVIDIA Confidential Computing. Mit den H100-GPUs wurde der Schutz auf Grafikprozessoren ausgedehnt. Der Datenpfad zwischen Confidential VM und GPU ist verschlüsselt, was Training und Inferenz von KI-Modellen mit vertraulichen Daten erst praktikabel macht.

Remote Attestation: der eigentliche Kern

Verschlüsselter Speicher allein beweist nichts. Du brauchst eine Antwort auf die Frage, ob dein Code tatsächlich in einem echten TEE läuft und nicht in einer Umgebung, die nur so tut. Das leistet die Remote Attestation. Der Prozessor erzeugt einen kryptografisch signierten Bericht über den Zustand der Umgebung: welche Firmware geladen ist, welche Messwerte (Hashes) das Gastsystem oder die Enklave hat, welcher Chip signiert. Der Bericht lässt sich über die Zertifikatskette des Herstellers prüfen.

Erst dieser Nachweis macht das Modell rund. Ein Key-Management-System kann beispielsweise Schlüssel nur dann herausgeben, wenn ein gültiger Attestierungsbericht vorliegt, der genau die freigegebene Software beschreibt. Läuft eine manipulierte Version, bleibt der Schlüssel weg. AWS baut genau darauf: Nitro Enclaves verknüpfen Attestierungsdokumente mit Schlüsselrichtlinien in AWS KMS, wie in der Nitro-Enclaves-Dokumentation beschrieben.

Wer dahintersteht: das Confidential Computing Consortium

Der Begriff ist kein Marketingwort eines einzelnen Anbieters. 2019 gründeten Intel, Microsoft, Google, Arm, Red Hat, AMD und weitere Unternehmen unter dem Dach der Linux Foundation das Confidential Computing Consortium (CCC). Es definiert Confidential Computing als „den Schutz von Daten in Verwendung durch Berechnung in einer hardwarebasierten, attestierten Trusted Execution Environment" und pflegt Open-Source-Projekte wie das Open Enclave SDK, Enarx oder Intels SGX-SDK für Linux. Für dich als Entscheider bedeutet das: Die Definition ist herstellerübergreifend abgestimmt, und wenn ein Anbieter „Confidential" auf ein Produkt schreibt, kannst du gegen diese Definition prüfen, ob Attestierung und Hardwareisolation wirklich vorhanden sind.

Angebote der großen Cloud-Anbieter

Alle drei großen Hyperscaler bieten Confidential Computing als buchbares Produkt an, mit unterschiedlichen Schwerpunkten.

• Azure Confidential Computing. Microsoft hat das breiteste Portfolio: Confidential VMs auf AMD SEV-SNP und Intel TDX, SGX-basierte Enklaven, Confidential Containers auf AKS, Confidential GPUs mit NVIDIA H100 sowie verwaltete Dienste wie Azure Confidential Ledger und das Attestierungswerkzeug Microsoft Azure Attestation. Die Azure-Dokumentation übernimmt die CCC-Definition wörtlich.
• Google Cloud Confidential VMs. Google startete 2020 mit AMD SEV und unterstützt heute SEV, SEV-SNP, Intel TDX und NVIDIA Confidential Computing für GPUs. Die Attestierung läuft über eine virtuelle TPM und Googles Attestation-Dienst. Confidential GKE Nodes bringen das Modell in Kubernetes. Die Übersicht steht in der Google-Cloud-Dokumentation.
• AWS Nitro Enclaves. Amazon geht einen anderen Weg. Statt auf Prozessorerweiterungen zu setzen, schneidet der Nitro-Hypervisor von einer bestehenden EC2-Instanz CPU-Kerne und Speicher ab und startet darin eine Enklave ohne persistenten Speicher, ohne Netzwerk und ohne interaktiven Zugang. Kommunikation läuft ausschließlich über einen lokalen Socket zur Elterninstanz. Das funktioniert auf Intel-, AMD- und Graviton-Instanzen gleichermaßen, verlangt aber einen eigenen Anwendungsschnitt.

Europäische Anbieter ziehen nach. OVHcloud, IONOS und Scaleway haben Confidential-VM-Angebote auf AMD-Basis im Programm oder angekündigt; der Reifegrad schwankt. Wer eine Lösung sucht, die ohne US-Anbieter auskommt, sollte konkret nach Attestierungsdienst, Schlüsselverwaltung und unterstützten Prozessorgenerationen fragen.

Warum KI-Agenten das Thema neu aufladen

Ein klassischer SaaS-Dienst sieht die Daten, die du ihm gibst. Ein persönlicher KI-Agent, der Mails liest, Formulare ausfüllt und mit hinterlegter Kreditkarte bucht, sieht sehr viel mehr: den ganzen digitalen Alltag einer Person oder eines Unternehmens. Die Frage, ob der Betreiber der Agenten-Infrastruktur mitlesen kann, wird damit zur Kernfrage.

Ein Realbeispiel liefert Meta. Am 8. September 2026 stellte der Konzern seinen Agenten Muse vor, der pro Nutzer in einer eigenen „Secure VM" in der Cloud läuft, flankiert von einem separaten Sentinel-Agenten, der jede ausgehende Aktion freigeben muss. In der Ankündigung heißt es weiter, noch in diesem Jahr werde eine „Muse Confidential VM" folgen, bei der die gesamte VM inklusive Daten und Gesprächen mit einem Schlüssel verschlüsselt ist, den nur die Nutzerin oder der Nutzer hält, sodass auch Meta keinen Zugriff hat. Das ist eine Ankündigung, kein ausgeliefertes Produkt. Ob Meta den Attestierungsprozess offenlegt, wer die Schlüssel tatsächlich verwaltet und ob unabhängige Prüfer Einblick bekommen, war zum Stand 30. September 2026 nicht veröffentlicht. Der Vorgang zeigt aber, wohin sich der Markt bewegt: Isolation pro Nutzer und hardwaregestützte Vertraulichkeit werden zum Verkaufsargument, nicht mehr zur Fußnote.

Für dein Unternehmen ist die Übertragung naheliegend. Wenn du Agenten auf Kundendaten, Verträgen oder Kalkulationen arbeiten lässt, lautet die Frage an jeden Anbieter: Läuft mein Agent in einer attestierten TEE, wer hält den Schlüssel, und kann ich den Attestierungsbericht selbst prüfen?

DSGVO, Datensouveränität und der CLOUD Act

Confidential Computing löst keine rechtlichen Fragen, verschiebt aber die technische Ausgangslage. Der CLOUD Act verpflichtet US-Unternehmen, auf behördliche Anordnung Daten herauszugeben, auch wenn sie in Rechenzentren außerhalb der USA liegen. Ein Anbieter kann jedoch nur herausgeben, was er lesen kann. Liegt der Schlüssel für eine Confidential VM allein beim Kunden und läuft die Attestierung gegen vom Kunden kontrollierte Richtlinien, erhält die Behörde im besten Fall verschlüsselte Speicherseiten. Juristen streiten darüber, wie belastbar dieses Argument in der Praxis ist; technisch ist es jedenfalls der stärkste Hebel, den ein Kunde eines US-Hyperscalers derzeit hat.

Aus DSGVO-Sicht ist Confidential Computing eine technische und organisatorische Maßnahme nach Artikel 32. Sie senkt das Risiko unbefugten Zugriffs durch den Auftragsverarbeiter und seine Beschäftigten. Sie ersetzt weder den Auftragsverarbeitungsvertrag noch die Rechtsgrundlage der Verarbeitung noch eine Transfer-Folgenabschätzung bei Drittlandübermittlungen. Wer sie richtig einsetzt, kann sie aber in genau diesen Dokumenten als Argument für ein angemessenes Schutzniveau anführen.

In der Debatte um Digitale Souveränität ist Confidential Computing deshalb zweischneidig. Es macht die Nutzung von US-Clouds für sensible Daten vertretbarer und nimmt so Druck von der Frage nach europäischen Alternativen. Gleichzeitig kommt die Hardware fast ausschließlich von US-Herstellern (Intel, AMD, NVIDIA) oder einem britischen Unternehmen in japanischem Besitz (Arm). Die Wurzel des Vertrauens liegt im Chip, und den baut niemand in Europa.

Grenzen und Risiken

Seitenkanalangriffe

Ein TEE schützt den Speicherinhalt, nicht jedes physikalische Nebengeräusch der Berechnung. Forscher haben seit 2018 eine Reihe von Angriffen gegen Intel SGX demonstriert, darunter Foreshadow (eine Spectre-Variante), Plundervolt (Manipulation der Versorgungsspannung) und SGAxe (Auslesen von Attestierungsschlüsseln). Gegen AMD SEV wurden Angriffe über den Speicher-Controller und die Fehlerbehandlung des Hypervisors gezeigt. Die Hersteller haben mit Microcode-Updates und den neuen Generationen (SEV-SNP, TDX) reagiert, aber die Kategorie bleibt. Wer Confidential Computing einsetzt, muss Firmware-Updates ernst nehmen und Attestierungsrichtlinien regelmäßig auf den aktuellen Stand heben.

Vertrauen in den Hersteller

Die Sicherheit des Modells hängt an der Zertifikatskette des Chipherstellers. Wer Intel, AMD oder Arm nicht vertraut, für den ist auch die Attestierung wertlos. Confidential Computing verschiebt Vertrauen also vom Cloud-Betreiber zum Prozessorhersteller. Für viele Unternehmen ist das ein Fortschritt, weil ein Chiphersteller keinen operativen Zugang zum Rechenzentrum hat. Ein Nullpunkt an Vertrauen ist es nicht.

Komplexität der Attestierung

In der Praxis ist Attestierung das, woran Projekte scheitern. Attestierungsberichte müssen erzeugt, gegen Referenzwerte geprüft, versioniert und bei jedem Update der Software neu freigegeben werden. Anbieter wie Microsoft und Google bieten dafür verwaltete Dienste an, die das Problem erleichtern, aber wieder einen Vertrauensanker beim Cloud-Betreiber setzen. Wer die Prüfung selbst betreiben will, braucht Personal, das die Zertifikatsketten und Messwerte versteht.

Abgrenzung zur homomorphen Verschlüsselung

Homomorphe Verschlüsselung erlaubt Rechenoperationen direkt auf verschlüsselten Daten, ohne sie jemals zu entschlüsseln. Sie braucht keine spezielle Hardware und keinen Vertrauensanker im Chip. Der Preis ist Rechenaufwand, der je nach Verfahren um Größenordnungen über dem Klartext liegt, und eine stark eingeschränkte Menge praktikabler Operationen. Für gezielte Berechnungen, etwa statistische Auswertungen über Datensätze mehrerer Parteien, ist sie heute einsetzbar; für eine ganze Anwendung oder ein Sprachmodell nicht. Confidential Computing entschlüsselt die Daten dagegen im Chip und arbeitet mit nahezu normaler Geschwindigkeit. Beide Ansätze gehören zur Familie der Privacy Enhancing Technologies und lassen sich kombinieren.

Praxis für den Mittelstand

Der Einstieg ist einfacher, als das Thema klingt. Confidential VMs kosten bei den großen Anbietern nur einen moderaten Aufschlag gegenüber Standard-Instanzen und laufen mit unverändertem Betriebssystem und unveränderter Software. Ein sinnvolles Vorgehen in vier Schritten:

1. Workloads klassifizieren. Nicht alles braucht ein TEE. Kandidaten sind Systeme mit Gesundheits-, Finanz- oder Personaldaten, Schlüsselverwaltung, Lizenzserver, Preiskalkulationen und alle KI-Anwendungen, die mit Kundendaten arbeiten.
2. Mit Confidential VMs anfangen. Der Umzug einer bestehenden VM auf eine SEV-SNP- oder TDX-Instanz ist der Schritt mit dem besten Verhältnis von Aufwand zu Wirkung. Enklaven auf Prozessebene lohnen sich später für eng begrenzte, hochsensible Komponenten.
3. Schlüssel selbst halten. Ohne kundenverwaltete Schlüssel (Customer Managed Keys, idealerweise mit Attestierungsbindung) bleibt der Betreiber der Herr des Systems. Prüfe, ob dein Anbieter Schlüsselfreigabe nur gegen gültige Attestierung unterstützt.
4. Attestierung in den Betrieb einbauen. Ein Attestierungsbericht, den niemand prüft, ist Dekoration. Definiere, wer die Referenzwerte pflegt und was passiert, wenn ein Bericht abweicht.

Genauso wichtig ist die Frage, was Confidential Computing nicht abdeckt. Ein Angreifer, der über eine Schwachstelle in deiner Anwendung eindringt, sitzt innerhalb der Enklave und sieht alles. Ein Mitarbeiter mit legitimen Zugriffsrechten ebenfalls. Sichere Softwareentwicklung, Rechtekonzepte und Protokollierung bleiben Pflicht.

Ausblick

Drei Entwicklungen werden das Thema in den kommenden Jahren prägen. Erstens verlagert sich Confidential Computing von der CPU auf Beschleuniger: Nach NVIDIAs H100 folgen weitere GPU-Generationen mit verschlüsseltem Datenpfad, und damit wird vertrauliches KI-Training und vertrauliche Inferenz zur Standardoption. Zweitens ziehen KI-Agenten das Thema in den Massenmarkt. Metas Ankündigung der Muse Confidential VM ist ein Signal, dass Anbieter persönlicher Agenten mit hardwaregestützter Vertraulichkeit um Vertrauen werben. Drittens rücken Attestierung und Schlüsselhoheit in den Fokus von Regulierern und Einkaufsabteilungen. Die Frage „Kann der Anbieter meine Daten sehen?" lässt sich künftig mit einem Attestierungsbericht statt mit einem Vertragsanhang beantworten.

Für den Mittelstand ist die realistische Erwartung: Confidential Computing wird zur Ausstattung wie heute Festplattenverschlüsselung. Der Wettbewerbsvorteil liegt nicht im Einsatz an sich, sondern darin, früh zu wissen, welche eigenen Daten und Prozesse ihn wirklich brauchen.

Häufige Fragen

Ersetzt Confidential Computing die klassische Verschlüsselung?

Nein. Verschlüsselung at rest und in transit bleibt Pflicht. Confidential Computing schließt die dritte Lücke, den Schutz während der Verarbeitung im Arbeitsspeicher. Erst alle drei Ebenen zusammen ergeben eine durchgehende Schutzkette.

Muss ich meine Software umschreiben?

Für Confidential VMs in der Regel nicht. Die virtuelle Maschine läuft mit unverändertem Betriebssystem und unveränderten Anwendungen; der Prozessor übernimmt die Speicherverschlüsselung. Enklaven auf Prozessebene wie Intel SGX oder AWS Nitro Enclaves verlangen dagegen einen eigenen Anwendungsschnitt und Anpassungen im Code.

Kann der Cloud-Anbieter mit Confidential Computing wirklich nichts mehr sehen?

Er kann den Arbeitsspeicher der geschützten Umgebung nicht im Klartext lesen. Ob er die Daten trotzdem erreicht, hängt davon ab, wer die Schlüssel hält, ob die Attestierung gegen vom Kunden kontrollierte Richtlinien läuft und ob der Anbieter selbst den Attestierungsdienst betreibt. Ohne kundenverwaltete Schlüssel bleibt ein Restzugriff möglich.

Was ist der Unterschied zu homomorpher Verschlüsselung?

Homomorphe Verschlüsselung rechnet direkt auf verschlüsselten Daten, ohne Hardware-Vertrauensanker, dafür mit erheblichem Rechenaufwand und eingeschränkten Operationen. Confidential Computing entschlüsselt die Daten innerhalb eines abgeschotteten Prozessorbereichs und arbeitet mit fast normaler Geschwindigkeit, setzt aber Vertrauen in den Chiphersteller voraus.