Confidential Computing klingt nach Spezialtechnik aus dem Rechenzentrum. Tatsächlich steckt dahinter eine einfache, sehr praktische Frage: Was passiert mit sensiblen Daten in dem Moment, in dem eine Cloud-Anwendung oder ein KI-System sie verarbeitet? Genau dieser Moment war lange die offene Stelle in vielen Sicherheitsmodellen.
Warum das Thema gerade wichtig wird
Cloud-Dienste speichern heute Geschäftsunterlagen, Gesundheitsdaten, Finanzinformationen, Verwaltungsprozesse und Trainings- oder Eingabedaten für KI-Systeme. Klassische Schutzmaßnahmen konzentrieren sich stark auf zwei Zustände: Daten werden verschlüsselt gespeichert, also data at rest, und sie werden beim Transport verschlüsselt, also data in transit. Sobald ein System mit ihnen rechnet, müssen sie jedoch in irgendeiner Form nutzbar werden.
Genau dort setzt Confidential Computing an. Der Ansatz soll Daten auch während der Verarbeitung besser isolieren. Das ist für Europa besonders relevant, weil Unternehmen, Behörden und Dienstleister Cloud- und KI-Angebote nutzen wollen, zugleich aber Datenschutz, Geschäftsgeheimnisse, regulatorische Anforderungen und Abhängigkeiten von Plattformbetreibern ernst nehmen müssen.
Der Punkt ist nicht, dass Confidential Computing Vertrauen überflüssig macht. Der Punkt ist nüchterner: Bestimmte technische Vertrauensannahmen werden kleiner. Betreiber, Administratoren oder andere Workloads sollen weniger Möglichkeiten haben, auf Daten oder Code während der Verarbeitung zuzugreifen. Das kann Cloud-Entscheidungen verändern, ersetzt aber keine saubere Governance.
Was Confidential Computing bedeutet
Confidential Computing bezeichnet Verfahren, bei denen Daten und Code während der Verarbeitung in einer geschützten Ausführungsumgebung isoliert werden. Häufig ist von Trusted Execution Environments, kurz TEEs, Enclaves oder confidential virtual machines die Rede. Die Confidential Computing Consortium beschreibt den Kern als Schutz von data in use, also Daten in Nutzung.
Damit schließt der Ansatz eine Lücke zwischen Verschlüsselung und Verarbeitung. Verschlüsselung schützt Daten auf Festplatten, in Datenbanken, Backups oder Übertragungswegen. Eine Anwendung muss Daten aber lesen, vergleichen, analysieren oder an ein Modell übergeben können. In diesem Moment verlassen sie die rein gespeicherte Form. Confidential Computing versucht, genau diese Verarbeitungsphase technisch abzugrenzen.
Wichtig ist die Formulierung: versucht, abzugrenzen. Kein TEE ist Magie. Schutz hängt von Hardware, Firmware, Hypervisor, Cloud-Konfiguration, Schlüsselverwaltung, Codequalität, Seitenkanalrisiken, Monitoring und Betriebsprozessen ab. Der Nutzen entsteht erst im Zusammenspiel, nicht durch ein Etikett in einer Produktbeschreibung.
Daten in Ruhe, unterwegs und in Nutzung
Die Unterscheidung zwischen drei Datenzuständen ist der beste Einstieg. Data at rest sind Daten, die gespeichert werden: Datenbanken, Objekt-Speicher, Festplatten, Backups. Data in transit sind Daten, die übertragen werden: API-Aufrufe, Webseitenverbindungen, interne Services. Data in use sind Daten, die gerade verarbeitet werden: eine Suche, eine KI-Inferenz, eine Datenbankabfrage, eine statistische Auswertung.
Für die ersten beiden Zustände gibt es etablierte Sicherheitsmuster. Speicherverschlüsselung, TLS, Zertifikate, Zugriffskontrolle und Netzwerksegmentierung sind bekannt, auch wenn sie in der Praxis nicht immer sauber umgesetzt werden. Data in use ist schwieriger, weil Rechenprozesse normalerweise Klartext oder mindestens nutzbare Zwischenzustände benötigen.
Confidential Computing verschiebt die Grenze. Die Daten werden in einer isolierten Umgebung verarbeitet, in der andere Teile des Systems möglichst wenig Einsicht erhalten. Das ist besonders interessant, wenn der Infrastrukturbetreiber nicht identisch mit dem Dateneigentümer ist, etwa bei Public Cloud, ausgelagerten Analyseplattformen oder KI-Diensten mit sensiblen Eingaben.
Wie TEEs, Enclaves und Attestation zusammenspielen
Ein Trusted Execution Environment ist eine technisch abgegrenzte Laufzeitumgebung. Je nach Plattform kann sie durch Prozessorfunktionen, Speicherisolation, verschlüsselte Arbeitsspeicherbereiche und kontrollierte Schnittstellen gestützt werden. Eine Enclave ist eine besonders stark isolierte Ausführungseinheit; confidential virtual machines übertragen das Prinzip auf ganze virtuelle Maschinen.
Der zweite Baustein ist Attestation. Sie soll nachweisen, dass eine bestimmte Software in einer erwarteten, unveränderten und geschützten Umgebung läuft. Vereinfacht gesagt fragt ein System: Läuft wirklich der richtige Code in der richtigen isolierten Umgebung, bevor ich sensible Daten oder Schlüssel freigebe? Ohne solche Nachweise wäre eine Enclave nur ein Versprechen.
Der dritte Baustein ist Schlüsselverwaltung. Daten werden nicht dadurch sicher, dass irgendwo eine geschützte Umgebung existiert. Entscheidend ist, wann Schlüssel ausgegeben werden, wer sie kontrolliert, wie sie rotiert werden, welche Logs entstehen und was bei Fehlern passiert. In guten Architekturen werden Schlüssel erst nach erfolgreicher Attestation freigegeben und bleiben möglichst eng an den erlaubten Zweck gebunden.
Wo der Ansatz praktisch hilft
Ein naheliegendes Feld sind KI-Workloads. Unternehmen möchten Modelle nutzen oder eigene Modelle betreiben, ohne besonders sensible Eingaben, interne Dokumente oder Kundendaten unnötig offenzulegen. Confidential Computing kann helfen, Inferenz oder bestimmte Analyseprozesse stärker zu isolieren. Es löst aber nicht automatisch Fragen wie Datenminimierung, Modelltraining, Protokollierung oder rechtliche Zulässigkeit.
Im Gesundheitsbereich geht es um Laborwerte, Diagnosen, Bilddaten oder Forschungsdaten. Solche Daten sind wertvoll, aber extrem sensibel. Wenn mehrere Einrichtungen Analysen durchführen oder Cloud-Infrastruktur nutzen, kann Confidential Computing ein Baustein sein, um Verarbeitung technisch enger zu kontrollieren. Trotzdem bleiben Einwilligungen, Zweckbindung, Pseudonymisierung und organisatorische Freigaben notwendig.
Auch Finanzdaten, Betrugserkennung, Bonitätsmodelle, öffentliche Verwaltung und europäische Cloud-Strategien profitieren potenziell. Dort entsteht oft ein Spannungsfeld aus Skalierung, moderner Software und hohen Schutzanforderungen. Confidential Computing kann dieses Spannungsfeld nicht auflösen, aber es kann zusätzliche technische Optionen schaffen, wo bisher nur entweder lokale Verarbeitung oder hohes Plattformvertrauen blieb.
Was Confidential Computing nicht löst
Der häufigste Fehler ist Übertreibung. Confidential Computing macht eine Cloud-Anwendung nicht automatisch DSGVO-konform. Es entscheidet nicht, ob Daten überhaupt verarbeitet werden dürfen. Es verhindert keine schlechten Berechtigungen, keine unnötige Datensammlung, keine fehlerhaften Prompts, keine unsicheren Schnittstellen und keine falsche Löschlogik.
Auch der Schutz gegen Angriffe ist begrenzt. TEEs reduzieren bestimmte Zugriffe aus der Infrastrukturumgebung, aber sie sind nicht immun gegen Implementierungsfehler, Seitenkanäle, Schwachstellen in Hardware oder Software, kompromittierte Anwendungscodes und falsche Betriebsprozesse. Wer vertrauliche Verarbeitung plant, muss deshalb Bedrohungsmodelle definieren statt nur eine Funktion einzuschalten.
Ein weiterer Punkt ist Anbieterabhängigkeit. Microsoft und Google dokumentieren Confidential-Computing-Angebote in ihren Cloud-Plattformen; andere Anbieter tun Ähnliches. Diese Dokumentationen sind nützlich, aber nicht neutral. Sie zeigen, wie ein Anbieter den Ansatz implementiert. Die Architekturentscheidung sollte trotzdem prüfen, welche Kontrolle über Schlüssel, Logs, Standorte, Supportzugriffe und Vertragsbedingungen tatsächlich besteht.
Entscheidungshilfe fuer Unternehmen und Behoerden
Eine sinnvolle Prüfung beginnt mit der Datenfrage: Welche Informationen wären kritisch, wenn sie während der Verarbeitung sichtbar würden? Danach kommt die Workload-Frage: Muss die Verarbeitung wirklich in einer externen Cloud oder in einer gemeinsam genutzten Umgebung laufen? Wenn ja, kann Confidential Computing helfen, das technische Risiko zu senken.
Als Nächstes folgt die Architekturfrage. Welche Komponente läuft im geschützten Bereich? Wird nur ein kleiner Dienst isoliert, eine Datenbank, eine VM oder ein kompletter Analyseprozess? Wie wird Attestation geprüft? Wer besitzt die Schlüssel? Welche Daten verlassen die Enclave wieder? Welche Metadaten bleiben sichtbar? Diese Fragen sind wichtiger als die Marketingbezeichnung.
Für kleinere Unternehmen ist ENISAs Cloud-Sicherheitskontext hilfreich: Cloud-Sicherheit besteht aus Identität, Zugriffskontrolle, Vertragsprüfung, Backup, Monitoring, Konfiguration und Risikomanagement. Confidential Computing ist darin ein zusätzlicher Schutzbaustein. Es ist besonders interessant bei sensiblen Verarbeitungen, aber selten der erste Schritt, wenn Grundlagen wie Rechteverwaltung oder Backup-Strategie fehlen.
Fazit
Confidential Computing erweitert das Sicherheitsmodell der Cloud um einen wichtigen Punkt: Daten sollen nicht nur beim Speichern und Übertragen, sondern auch während der Verarbeitung besser geschützt werden. Für KI, Gesundheitsdaten, Finanzprozesse, Verwaltung und europäische Cloud-Entscheidungen ist das mehr als ein Detail.
Der nüchterne Blick bleibt aber entscheidend. Die Technik schafft eine stärkere Isolation und überprüfbarere Verarbeitungsumgebungen, sie ersetzt jedoch keine Datenschutzprüfung, kein gutes Schlüsselmanagement, keine Datenminimierung und keine klare Provider-Governance. Wer das versteht, kann Confidential Computing als Infrastrukturbaustein nutzen, ohne daraus ein Datenschutz-Wundermittel zu machen.
Quellen und weiterführende Informationen
Der Artikel basiert auf offiziellen, institutionellen und technischen Ausgangsquellen. Vendor-Dokumentation wird als Implementierungsbeispiel eingeordnet, nicht als neutraler Wirksamkeitsbeweis.
- Confidential Computing Consortium
- ENISA: Cloud Security Guide for SMEs
- Microsoft Learn: Azure Confidential Computing overview
- Google Cloud: Confidential Computing
Hinweis: Für diesen Artikel wurden KI-gestützte Recherche- und Editierwerkzeuge verwendet. Der Inhalt wurde menschlich redaktionell geprüft. Stand: 16.05.2026.
