Confidential Computing und Cloud Governance Vertrauliche Datenverarbeitung in TPM-geschützten CPU-Enklaven

Anbieter zum Thema

FTAPI Software GmbH

Datenkategorien, Schutzklassen, Sicherheitszonen: Die Problematik der Cloud-Governance ist längst nicht nur für regulierte Branchen ein Pflichtthema. Viele haben stattdessen einen blinden Fleck: die fehlende Abschottung von privilegierten Plattformebenen.

In Deutschland wächst die Bedeutung von Confidential Computing – nicht nur wegen der strengen Vorgaben der DSGVO, sondern auch wegen der Dominanz hochentwickelter Branchen mit beachtlicher Regulierungstiefe und langen Lieferketten: Automotive, Finanz- und Versicherungsbranche, Gesundheitswesen, Betreiber kritischer Infrastrukturen, teils auch öffentliche Auftraggeber.

Über globale Lieferketten, sensible Kundendaten und Übermittlungen in Drittländer geraten heute selbst vermeintlich „unregulierte“ Cloud-Anwender in denselben Sog aus Compliance- und Souveränitätsfragen wie klassische Hochrisikosektoren. Wer als Zulieferer für regulierte Branchen agiert, bekommt viele identische, von NIS2/DORA‑inspirierten Anforderungen vertraglich „durchgereicht“: Vorgaben aus NIS2/DORA oder sektoralen Cloud‑Policies der Auftraggeber.

Security-Insider Podcast – Folge 103

(Open) Confidential Computing – ohne Vertrauen geht's noch nicht

TEEs: Technisches Fundament sicherer Cloud-Enklaven

Cloud-Enklaven (Confidential Computing) ermöglichen die Verarbeitung hochsensibler Daten in der Public Cloud, ohne dass Cloud-Betreiber, Administratoren oder andere Mandanten Einblick in Daten oder Code erhalten. Confidential Computing bietet Schutz für Daten, KI-Modelle und Softwarecode während der Verarbeitung von Cloud-Arbeitslasten. Möglich wird das durch den Einsatz von Trusted Execution Environments (TEEs), der sogenannten „sicheren Enklaven“. Sie kapseln Code und Daten in einem hardwaregestützten Vertrauensbereich, sodass selbst privilegierte Plattformkomponenten – etwa Hypervisor oder Host-Administratoren – keinen Klartext sehen sollen.

Regulatorisch ist die Enklave heute vor allem „Best Practice“ für besonders schutzwürdige Daten, wird aber schrittweise in sektoralen Vorgaben und Aufsichtsanforderungen konkretisiert. Der praktische Mehrwert liegt weniger in einem abstrakten Compliance-Versprechen als in einem klaren Betriebsmodell: Workloads lassen sich so konzipieren, dass Daten und sensible Teile der Ausführung auch dann abgeschirmt bleiben, wenn man einem klassischen Cloud-Trust-Modell nicht vollständig folgen möchte – etwa weil privilegierte Administrationspfade, Mandantentrennung oder juristische Zugriffsszenarien im Risk Assessment besonders streng ins Gewicht fallen.

Zwischen Schlüsselhoheit und Kontrolle: Was Auditoren wirklich prüfen

In Audits übersetzt sich das in eine sehr konkrete Problemstellung, nämlich die Frage nach der Souveränität als Schutzfaktor für Daten, Modelle und Softwarecode. Ein in Deutschland verankerter Plattform-Layer kann als zusätzliche Vertrauensinstanz wirken, selbst wenn darunter Hardware eines US-Hyperscalers läuft. Das adressiert genau jene Audit-Skepsis, die an Zugriffspfaden, Jurisdiktion, Operator-Modellen und Nachweisbarkeit Anstoß nimmt.

In der Sprache eines Audits kristallisiert sich eine sehr konkrete Prüfspur heraus: Es reicht nicht zu wissen, welcher Tresor im Stack steckt. Entscheidend ist, wer den Schlüssel in der Hand hält, wer Attestierung verantwortet und Richtlinien durchsetzt – und ob sich diese Kontrolle reproduzierbar, nachweisbar und skalierbar in den Betriebsalltag überführen lässt.

Harvest Now, Decrypt Later bedroht Confidential Computing

Confidential Computing und die Quanten-Bedrohung

Zwei Schutzmodelle im Vergleich: Application Enclaves vs. Confidential VMs

Die etablierten Cloud-Plattformen stützen sich aktuell auf eine Reihe alternativer Ansätze. Die Unternehmen haben die Qual der Wahl.

X86-basierte Implementierungen von Confidential-Computing folgen hauptsächlich einem von zwei verbreiteten Schutzmodellen:

• App-Enklaven (Engl. Application Enclaves): feingranulare Abschottung innerhalb einer Anwendung, zum Beispiel mit Intel SGX;

• VM-Isolierung (Confidential VMs) die gesamte virtuelle Maschine als Vertrauensgrenze, zum Beispiel AMD SEV-SNP oder Intel TDX.

Intel SGX ist bei den hyperskalaren Clouds wie ein Schließfach im Banktresor: für klar definierte, kompakte Wertgegenstände gedacht und unzugänglich für das Bankpersonal. Die Technologie setzt auf besonders abgeschottete, feingranulare Schutzräume. Selbst privilegierte Softwarepfade des Betriebssystems können hier nicht „hineinsehen“. Microsoft Azure beschreibt SGX-Enklaven als Bereiche, in denen Daten und Code „nicht einmal mit einem Debugger“ einsehbar sein sollen.

AMD SEV/SEV-SNP stärkt im Gegensatz dazu die VM-Boundary gegenüber dem Host und Hypervisor. SEV ist in der Cloud vor allem als Mechanismus für hardwaregestützte Speicherverschlüsselung auf VM-Ebene präsent. Dieser Ansatz lässt sich mit einem gepanzerten Geldtransporter vergleichen: Die gesamte VM wird zur Schutzdomäne gegenüber dem Virtualisierungs-Stack, was aber zugleich bedeutet, dass das Sicherheitsniveau im Inneren weiterhin stark vom Guest-OS und dessen Hardening abhängt.

Das ist genau der Charme des VM-Ansatzes: Viele Workloads lassen sich näher am „Lift-and-Shift“-Denken absichern, ohne dass Teams ihr Anwendungsdesign zwingend in SGX-typische Trusted/Untrusted-Zonen zerlegen müssen. Gleichzeitig zeigt Azure mit SEV-SNP und Intel TDX, dass das Feld längst mehr als zwei technische Grundbausteine kennt – und dass Provider je nach Bedrohungsmodell (Hypervisor-Misstrauen, Mandantentrennung, Operator-Risiko) unterschiedliche TEE-Varianten einpreisen.

Sollte das OS in der VM kompromittiert sein, entsteht ein anderes Risikoprofil als bei einer sehr engen, prozessnahen Enklave. Für AMD in der Cloud ist Google ein gut dokumentiertes Referenzbeispiel. Googles Confidential VMs auf der Basis von AMD SEV kombinieren hardwarebasierte Memory-Verschlüsselung über den AMD Secure Processor mit Boot-Time-Attestation über Googles vTPM. In Azure Confidential VMs setzt Microsoft wahlweise auf AMD SEV-SNP oder Intel TDX. Auf diesen Technologien können dann Plattformen aufsetzen, um diese TEEs betrieblich beherrschbarer und ggf. Multicloud-fähig machen.

Über x86 hinaus: neue TEE-Architekturen für KI und Spezial-Workloads

Das TEE-Feld über x86 hinaus: Arm CCA (Realms), RISC-V-TEEs und GPU-basierte Confidential-Computing-Ansätze wie beispielsweise Nvidia CC für KI‑Workloads auf Hopper/H100 erweitern das Spektrum von Optionen für vertrauenswürdiges Cloud-Computing erheblich.

Daneben existieren provider-spezifische Enklavenmodelle wie AWS Nitro Enclaves, die keinen Anspruch auf Anbieterneutralität erheben (siehe weiter unten). Während Nitro als generalistischer Sicherheitsbaustein gedacht ist, fokussieren Enclaive und andere deutsche Anbieter wie Edgeless Systems stark auf vertrauenswürdige künstliche Intelligenz (Engl. Confidential AI). Hier geht es um den Schutz des KI-Modells als IP (geistiges Eigentum) und Schutz der Nutzdaten vor der Neugier des Cloud-Providers sowohl während der Lernphase als auch während der Inferenz.

Multicloud-Enklaven als Betriebsmodell

Die Enclaive GmbH aus Berlin positioniert ihre Lösung als eine Schicht, die Confidential-Workloads über mehrere TEE-Welten hinweg orchestriert und standardisiert – ausdrücklich auf Basis von Intel SGX/TDX, AMD SEV und Arm-CCA. Intel SGX kann, nüchtern betrachtet, anspruchsvoll sein: SDKs, Toolchains, Programmiermodelle, saubere Grenzziehung zwischen vertrauenswürdigem und nicht-vertrauenswürdigem Code. Enclaive positioniert sich hier als eine Schaltzentrale, welche die Komplexität – mit vorbildlicher Souveränität – beherrschbar macht.

Ein Layer wie Enclaive sitzt „oberhalb“ verschiedener Cloud-Anbieter. Dadurch kann ein Team eine Enklaven-Architektur heute auf einem Hyperscaler betreiben und morgen auf einen deutschen Provider wechseln, ohne die Sicherheitslogik von Grund auf neu zu entwerfen. Im Kontrast dazu sind viele Enklaven-Modelle stark an ein Ökosystem gebunden – etwa Nitro Enclaves an AWS.

Souveräne Schlüsselverwaltung statt Hyperscaler-Lock-in

NIST-Standards ebnen Weg zu quantensicheren Enklaven

Anbieterlandschaft für Confidential Computing in Europa

Edgeless Systems
Edgeless Systems aus Bochum liefert Software-Infrastruktur, um Cloud-Instanzen zu „Confidential Clusters“ zu verbinden. Das Produkt Constellation wird als „Always-Encrypted Kubernetes“ positioniert. Sie ermöglicht einen Kubernetes-Betrieb, bei dem Verschlüsselung „in use“ nicht als Sonderfall gedacht ist, sondern als Normalzustand – attraktiv für Teams, die Kubernetes in einer deutschen Region betreiben und dennoch Ende-zu-Ende-Schutz auch während der Verarbeitung wünschen.

T Cloud (T-Systems)
Die T Cloud bzw. ehemals Open Telekom Cloud bietet Elastic Cloud Server (ECS) auf der Basis von Intel SGX (Software Guard Extensions) in seinen Rechenzentren in Magdeburg und Biere. Damit lassen sich hardwareverschlüsselte Enklaven aufbauen, in denen Code und Daten selbst gegenüber dem Cloud-Betreiber abgeschirmt bleiben sollen – ein typischer Ansatz für Workloads, bei denen „privilegierter Zugriff“ als Risiko bereits in der Threat-Model-Diskussion ausgeschlossen wird.

Stackit (Schwarz IT)
Stackit – Cloud-Anbieter der Lidl/Kaufland-Gruppe – positioniert Confidential Servers und Confidential Kubernetes als eine Lösung für den deutschen Mittelstand. Die Argumentation ist meist zweigleisig: technische Isolation durch Verschlüsselung während der Verarbeitung plus organisatorische und rechtliche Einbettung in ein stark auf digitale Souveränität ausgerichtetes Angebot in deutschen Rechenzentren. Stackit setzt hierbei auf die SEV-Technologie von AMD (Secure Encrypted Virtualization).

OVHcloud mit Securitee
Der französische Cloud-Anbieter OVHcloud betreibt einen großen Rechenzentrums-Hub in Limburg an der Lahn. Dort bekommen Unternehmen Bare-Metal-Server mit Intel SGX von OVHcloud in Partnerschaft mit Securitee angeboten. Bare-Metal-Clouds bieten häufig mehr Kontrolle über Low-Level-Konfiguration, Attestierungs-Workflows und Enklaven-Betrieb als virtualisierte Cluster. OVHcloud stellt die Hardware- und Cloud-Infrastruktur für Confidential Computing bereit. Securitee baut auf dieser Infrastruktur eine Confidential-Computing-PaaS-Schicht auf, die TEEs und Enklaven kapselt, um sie in einer Self‑Service-Bereitstellung zu orchestrieren und zu überwachen. So erhalten Entwickler fertige Funktionen für Laufzeitverschlüsselung, Attestation und Policy-Management, ohne selbst die Low-Level-SGX-Details beherrschen zu müssen.

Ionos
Ionos bietet Enterprise-Cloud-Services mit Hosting in Deutschland und adressiert ausdrücklich Workloads mit erhöhten Compliance-Anforderungen. Confidential-Computing-Funktionen sind in diesem Narrativ kein Selbstzweck, sondern ein Baustein, um Schutzprofile für sensible Datenverarbeitung konsistenter umzusetzen – insbesondere, wenn interne Governance (Audit-Trail, Rollenmodelle, Schlüsselverwaltung, Nachweisführung) genauso wichtig ist wie die Technik selbst.

Microsoft Azure (Germany West Central)
Microsoft Azure gilt als einer der Taktgeber im Markt für Confidential-Computing. Redmond behandelt das Thema als ein durchgängiges Sicherheitsprinzip im Rahmen einer Ende-zu-Ende-Architektur – vom Silizium bis zur Plattformschicht. Die Lösung setzt genau dort an, wo Audits und forensische Anforderungen häufig am meisten Reibung verursachen: bei Nachweisbarkeit, Unveränderlichkeit und Schutz während der Verarbeitung. Ein Beispiel ist das Azure Confidential Ledger, das auf manipulationsresistente Protokollierung zielt und damit Prozesse unterstützt, in denen Integrität und Beweiswert von Logdaten oder Transaktionsereignissen nicht verhandelbar sind. Ein weiteres Beispiel ist Azure SQL Always Encrypted mit Enklaven: Sensible Daten sind kryptografisch geschützt, aber bestimmte Abfragen und Operationen werden durch Enklaven so erweitert, dass Sicherheit und Funktionalität nicht zwangsläufig gegeneinander ausgespielt werden müssen. Technologisch stützt sich Azure auf mehrere TEE-Varianten und spielt seine Stärke vor allem in der Integrationsbreite aus: Je nach Workload-Profil können Enklaven auf Intel SGX oder auf AMDs VM-orientierten Mechanismen wie SEV-SNP basieren. Dadurch lassen sich unterschiedliche Bedrohungsmodelle und Migrationsrealitäten abbilden – von hochgranularen Schutzdomänen für besonders kritische Logik bis hin zu VM-weiten Schutzansätzen, die bestehende Systeme mit weniger Eingriffen in Code und Betriebsprozesse in ein „Confidential“-Zielbild überführen. In Frankfurt bekommen Unternehmen ein Portfolio an Sicherheitslösungen, mit dem sich Confidential Computing als Betriebskonzept skalieren lässt – technisch, organisatorisch und, wenn sauber umgesetzt, auditierbar.

Google Cloud
In den deutschen Google-Cloud-Regionen Frankfurt (europe-west3) und Berlin (europe-west10), wo viele Unternehmen ihre produktiven Standard-Workloads verorten, lassen sich Confidential VMs als reguläre Compute-Engine-Instanzen nutzen. Google setzt bei seinen Confidential VMs primär auf hardwaregestützte Speicherverschlüsselung auf VM-Ebene. Anders als bei Intel-SGX-Ansätzen, die häufig eine fein granulare Enklavenlogik innerhalb der Anwendung modellieren und damit spürbar in Architektur und Code eingreifen können, bleibt Googles Betriebsmodell näher am klassischen „Lift-and-Shift“: Bestehende Systeme können oft ohne grundlegende Neustrukturierung in eine vertraulichere Ausführungsumgebung überführt werden – inklusive der typischen Tooling-Kette aus Images, Autoscaling, Monitoring und Logging. Google koppelt das Konzept an überprüfbare Start- und Integritätsmechanismen, darunter die Attestierung beim Boot über vTPM-basierte Nachweise. Welche Zonen und Maschinentypen Confidential-VM-Funktionen unterstützen, hängt von Region, Machine Series und verfügbarer TEE-Variante ab – Google verweist dafür explizit auf die unterstützten Konfigurationen und Zonentabellen. In Frankfurt ist in der Compute-Engine-Regionstabelle neben AMD SEV (Secure Encrypted Virtualization) teils auch AMD SEV-SNP (Secure Nested Paging) als Option ausgewiesen. SEV‑SNP führt zusätzliche Mechanismen wie die Reverse Map Table (RMP), VM‑seitige Integritätsprüfungen und erweiterte Attestation ein.

AWS Nitro Enclaves
AWS fährt wie so oft einen eigenen Weg: Nitro Enclaves sind isolierte, stark eingeschränkte Ausführungsumgebungen auf Basis des Nitro-Stacks von AWS. Der Anbieter beschreibt sie als separate, gehärtete, und stark eingeschränkte (Engl.: highly-constrained) VMs: ohne persistente Speicherung, ohne interaktiven Zugang, ohne externes Networking; Kommunikation läuft nur über lokale Socket-Konnektivität zur Parent-Instanz.

Scontain (Scone)
Scone (Secure Container Environment) aus Dresden ist auf Linux-Container in Intel-SGX-Enklaven spezialisiert. In Forschung und Industrie wird Scone dann genutzt, wenn Container-Workloads sowohl in Edge- als auch in Cloud-Szenarien abgesichert werden sollen und wenn die Granularität von SGX – also der Schutz „innerhalb“ eines Systems – einen Vorteil bietet.

Confidential Computing ist ein auditierbares Betriebskonzept

Die deutsche Confidential-Computing-Landschaft umfasst heute ein breites Spektrum an Cloud-, Plattform- und Softwarelösungen – von Infrastruktur-Providern bis hin zu spezialisierten Software-Layern, die Cloud-Enklaven für Unternehmen praxisnah nutzbar machen.

Das Autorenduo Anna Kobylinska und Filipe Pereira Martins arbeitet für McKinley Denali, Inc., USA.

(ID:50723743)