5 Gründe, warum Sie sich jetzt mit Confidential Computing beschäftigen müssen

Cloud und künstliche Intelligenz sind zum Fundament der digitalen Wirtschaft geworden. Gleichzeitig verschärfen geopolitische Spannungen, regulatorische Anforderungen und neue Cyberrisiken die Frage, wer tatsächlich Kontrolle über sensible Daten besitzt.

Denn Daten sind heute zwar während der Speicherung und Übertragung meist gut geschützt. Sobald sie verarbeitet werden, entsteht jedoch eine entscheidende Sicherheitslücke: Daten, Schlüssel, Modelle und Zwischenergebnisse müssen dem ausführenden System zugänglich sein – und damit potenziell auch Cloud-Administratoren, Managementsystemen oder kompromittierten Infrastrukturkomponenten.

Confidential Computing soll genau diese Lücke schließen. Fünf Gründe, warum Unternehmen das Thema jetzt auf ihre Agenda setzen sollten.

Authoren:

Dr. Philipp Müller
Andreas Dirscherl

1. Geopolitik ist zu einem Faktor der IT-Architektur geworden

Sanktionen, Exportkontrollen, internationale Rechtsordnungen und konzentrierte Lieferketten können aus einer gewöhnlichen Cloud-Abhängigkeit innerhalb kurzer Zeit ein strategisches Risiko machen.

Dabei genügt es nicht, dass Daten in Deutschland oder Europa gespeichert werden. Entscheidend ist, wer technisch auf die Systeme zugreifen, Änderungen vornehmen, Schlüssel verwenden oder einen kritischen Prozess unterbrechen kann. Auch ein europäischer Speicherort schafft keine vollständige Souveränität, wenn ein externer Administrator weiterhin Zugriff auf Hostsystem, Managementebene oder Arbeitsspeicher besitzt.

Digitale Souveränität bedeutet deshalb mehr als Datenlokalisierung. Sie verlangt kontrollierbare Abhängigkeiten: Unternehmen müssen nachvollziehen können, welche Eingriffsmöglichkeiten ein Anbieter besitzt, wie diese begrenzt werden und ob Anwendungen und Prozesse im Ernstfall auf eine andere Plattform übertragen werden können.

2. KI macht „Data in Use“ zum geschäftskritischen Schutzbereich

KI-Systeme benötigen Kontext. Sie greifen auf Dokumente, Quellcode, Kundendaten, Gesundheitsinformationen, technische Zeichnungen, Kommunikationsarchive oder operative Sensordaten zu. Dadurch entsteht eine hochkonzentrierte Repräsentation des Wissens einer Organisation.

Während Training und Inferenz befinden sich nicht nur die Ausgangsdaten in Verarbeitung. Auch Prompts, Embeddings, Modellgewichte, Gradienten, Checkpoints und Zwischenergebnisse liegen zeitweise in CPU- oder GPU-Speichern vor. Hinzu kommen Treiber, Orchestrierungsplattformen, Vektordatenbanken und Monitoring-Systeme. Jede beteiligte Komponente erweitert den potenziellen Vertrauensbereich.

Das macht die Infrastruktur selbst zu einem Teil der Informations-Governance. Wer proprietäre oder regulierte Daten mit KI verarbeiten möchte, muss daher beantworten können, ob der Infrastrukturbetreiber technisch auf diese Daten und Modelle zugreifen könnte – unabhängig davon, ob er dies vertraglich darf.

Verantwortung lässt sich nicht an den Cloud-Anbieter auslagern

Regelwerke wie DORA und NIS2 sowie die europäischen Anforderungen an Cloud-Souveränität erhöhen die Verantwortung für Risiken aus ausgelagerten IT-Leistungen. Unternehmen bleiben für ihre Daten und Prozesse verantwortlich, auch wenn diese von einem Dienstleister verarbeitet werden.

Verträge, Zertifizierungen und privilegierte Zugriffskontrollen bleiben wichtig. Sie reduzieren Risiken und schaffen Verantwortlichkeit. Sie entfernen aber nicht automatisch den technischen Zugriffspfad.

Die entscheidende Frage lautet deshalb nicht nur: „Darf der Anbieter auf unsere Daten zugreifen?“ Sondern: „Könnte der Anbieter – oder jemand, der ihn kompromittiert, unter Druck setzt oder rechtlich verpflichtet – während der Verarbeitung auf unsere Daten zugreifen?“

Confidential Computing verlagert die Diskussion damit von versprochenem Verhalten zu technisch begrenzten Fähigkeiten.

4. Confidential Computing ist nicht gleich Confidential Computing

Für den Schutz von Daten während der Verarbeitung haben sich drei grundsätzliche Ansätze entwickelt. Sie lösen unterschiedliche Probleme und können miteinander kombiniert werden.

Verschlüsseltes Rechnen: FHE und MPC 

Fully Homomorphic Encryption ermöglicht definierte Berechnungen direkt auf verschlüsselten Daten. Bei Secure Multi-Party Computation wird eine Berechnung auf mehrere Parteien verteilt, ohne dass eine Partei sämtliche Eingangsdaten kennen muss.

Dieser Ansatz bietet eine besonders starke mathematische Trennung. Er eignet sich vor allem für klar abgegrenzte Berechnungen und organisationsübergreifende Analysen. Für komplexe Anwendungen, interaktive SaaS-Produkte oder umfangreiche KI-Pipelines sind Rechenaufwand, Datenvolumen und notwendige Anwendungsanpassungen jedoch häufig noch erheblich.

On-Chip- und Enklaven-Technologien: TEEs

Trusted Execution Environments wie Intel SGX oder TDX und AMD SEV-SNP schützen Speicher und Ausführung durch hardwarebasierte Grenzen. Viele Anwendungen lassen sich mit überschaubaren Anpassungen und nahezu nativer Performance betreiben.

Die Sicherheit hängt allerdings von Prozessor, Firmware, Attestierung und den umgebenden Ein- und Ausgabepfaden ab. GPUs, Treiber, Managementsysteme oder Monitoring können außerhalb der geschützten Grenze liegen. Die französische Cybersicherheitsbehörde ANSSI bewertet TEEs deshalb als wertvolle zusätzliche Schutzschicht, aber nicht allein als ausreichenden Schutz vor gezielten Angriffen eines feindlichen Administrators.

Server-Isolation mit Operator Shielding

Der dritte Ansatz stellt einem Kunden dedizierte physische Server und Beschleuniger zur Verfügung und entfernt gleichzeitig die administrativen Zugriffspfade des Betreibers.

Dazu gehören unter anderem ein verifizierter Netzwerkstart, ein unveränderliches Betriebssystem, kundenseitig kontrollierte Schlüssel, deklarative Änderungen über GitOps sowie der Verzicht auf SSH, Shell-Zugänge und Remote-Konsolen. Auch Wartung, physischer Zugriff und die Bereinigung von Daten werden in das Schutzmodell einbezogen.

Dieser Ansatz unterstützt herkömmliche containerisierte Anwendungen und dedizierte GPUs mit hoher Performance. Dafür entstehen eine höhere Mindestkapazität, eine gröbere Skalierung und besondere Anforderungen an den Betriebsprozess.

5. Sealed Cloud macht Vertrauen zu einer Eigenschaft der Architektur

Sealed Cloud setzt den dritten Ansatz konsequent um. Das zentrale Prinzip lautet: Der Betreiber soll nicht lediglich versprechen, auf privilegierte Zugriffe zu verzichten. Die Plattform wird so konstruiert, dass diese Zugriffspfade im normalen Betrieb nicht existieren.

Der Schutz entsteht aus vier ineinandergreifenden Dimensionen:

• Kryptografisch: Daten, Kommunikation, Identitäten und Artefakte werden geschützt; Schlüssel werden nur in den freigegebenen Kundensegmenten verfügbar.
• Architektonisch: Ein unveränderliches Betriebssystem, verifizierter Netzwerkstart und deklarative Änderungen ersetzen interaktive Administratorzugriffe.
• Physisch: Dedizierte Server und GPUs, deaktivierte Hardware-Managementschnittstellen sowie kontrollierte Wartungsprozesse reduzieren Mandanten- und Betreiberzugriffe.
• Organisatorisch: Infrastrukturbetreiber, Kundenbetrieb und unabhängige Prüfer erhalten klar getrennte Aufgaben und Berechtigungen.

Der Anbieter kann weiterhin Rechenzentrum, Hardware, Verfügbarkeit und Plattformdienste betreiben. Er besitzt jedoch keinen routinemäßigen Zugang zu Klartextdaten, Anwendungsschlüsseln oder dem Zustand geschützter Workloads.

Gleichzeitig bleibt die Plattform cloud-native: Standardisierte Container, Kubernetes-Schnittstellen und deklarative Konfigurationen reduzieren den Anpassungsaufwand und unterstützen die Portabilität. Dedizierte Beschleuniger machen das Modell besonders für proprietäre und regulierte KI-Anwendungen interessant.

Sealed Cloud ist damit nicht pauschal die beste Lösung für jede Berechnung. Für eng begrenzte Funktionen kann FHE oder MPC die stärkere mathematische Trennung bieten. Wenn maximale Shared-Cloud-Elastizität im Vordergrund steht, kann eine TEE die passendere Wahl sein.

Wenn jedoch ein breiter, konventioneller oder GPU-basierter Workload betrieben werden soll und der Infrastrukturbetreiber nicht Teil des Vertrauensbereichs sein darf, bietet Sealed Cloud das umfassendste Schutzmodell: nicht allein durch Verschlüsselung, sondern durch die Kombination aus dedizierter Hardware, Architektur, Kryptografie und überprüfbaren Betriebsprozessen.

Der richtige Einstieg

Unternehmen sollten nicht mit einer allgemeinen Produktdemo beginnen, sondern mit einer Data-in-Use-Analyse für einen konkreten, sensiblen Workload:

1. Wo liegen Daten, Schlüssel und Modelle während der Verarbeitung im Klartext vor?
2. Welche Administrator-, Management-, Firmware-, Wartungs- und Monitoring-Pfade existieren?
3. Welche Akteure müssen vom Zugriff ausgeschlossen werden?
4. Welcher der drei Ansätze passt zum tatsächlichen Bedrohungsmodell?
5. Wie lassen sich Sicherheit, Performance, Wiederherstellung, Portabilität und Kosten in einem Proof of Concept überprüfen?

Die Entscheidungsschwelle ist einfach: Ist ein Workload zu wichtig, um ihn gegenüber dem Anbieter offenzulegen – aber gleichzeitig zu wichtig, um ihn von modernen Cloud- und KI-Möglichkeiten auszuschließen –, dann ist er ein Kandidat für Sealed Cloud.

Denn Kontrolle ist weder ein Standortversprechen noch eine Vertragsklausel. Kontrolle ist eine Designentscheidung.