Confidential Architecture

hinweis

Nicht jede Codesphere-Instanz bietet Confidential Compute an. Frage deinen Codesphere-Administrator, ob Confidential Compute auf deiner Instanz verfügbar ist. Siehe Voraussetzungen.

Bei Confidential Compute gilt die gesamte Plattforminfrastruktur als nicht vertrauenswürdig. Das umfasst die Hosts, den Hypervisor, die Orchestrierungsschicht, den Speicher, das Netzwerk sowie die Personen, die diese betreiben. Codesphere schützt die Daten vor dieser Infrastruktur in jedem Zustand:

• In Verwendung. Jeder Service läuft in einer eigenen Confidential-Micro-VM mit verschlüsseltem Speicher.
• Bei der Übertragung. Der Datenverkehr zwischen Confidential Services wird durch ein Service Mesh verschlüsselt.
• Im Ruhezustand. Persistente Daten werden innerhalb der Micro-VM verschlüsselt, bevor sie den Speicher erreichen.

Übersicht

Entsprechende barrierefreie Textbeschreibung

Die Komponenten übernehmen folgende Rollen:

• Nicht vertrauenswürdige Infrastruktur. Hardware, Hypervisor, die Plattform, Speicher und Netzwerk. Sie plant und führt Services aus, sieht Daten jedoch nie im Klartext.
• Confidential-Micro-VM. Die vertrauenswürdige Hülle rund um einen einzelnen Confidential Service.
• Service Mesh. Verschlüsselt und authentifiziert den Datenverkehr zwischen Confidential Services.
• Verschlüsselter Speicher. Persistente Daten werden innerhalb der VM verschlüsselt, bevor sie das Speicher-Backend erreichen.

Confidential-Micro-VMs

In Codesphere läuft jeder Confidential Service in einer eigenen leichtgewichtigen virtuellen Maschine, der sogenannten Micro-VM. Die Micro-VM läuft in der Trusted Execution Environment der Host-CPU und bildet eine vertrauenswürdige Hülle rund um den Confidential Service. Alles darin, vom Gast-Kernel bis zur Anwendung, ist durch Hardware-Speicherverschlüsselung geschützt.

Warum eine virtuelle Maschine

Reguläre Services laufen als Container, also als Prozesse auf einem gemeinsam genutzten Host-Kernel. Kernel-Funktionen wie Namespaces und Cgroups halten sie voneinander getrennt. Der Kernel selbst gehört dem Betreiber, und wer den Kernel kontrolliert, kann den Speicher jedes Services auf dem Host einsehen.

Ein Service besteht aus mehreren Prozessen, die gemeinsam in einer Confidential-Micro-VM zusammengefasst werden, mit:

• einem eigenen, minimalen Gast-Kernel und Userspace
• Speicher, der von der CPU verschlüsselt wird
• einem festen, messbaren Boot-Image

Die Plattform plant und verwaltet den Service weiterhin wie jeden anderen. Funktionen wie Networking und Ressourcenlimits funktionieren weiterhin.

Was der Host sehen kann und was nicht

Der Host führt die Micro-VM weiterhin aus und behält daher eine gewisse Sichtbarkeit.

Der Host kann:

• sehen, dass die VM existiert und wie viel CPU, Speicher und Festplattenkapazität sie nutzt
• verschlüsselten Netzwerkverkehr und dessen Endpunkte sehen
• verschlüsselte Festplattenblöcke sehen
• die VM stoppen, pausieren oder löschen

Der Host kann nicht:

• den Speicher der VM lesen
• entschlüsselte Festplatteninhalte oder Netzwerkverkehr lesen
• das Gast-Image oder den Service ändern, ohne dass die Attestierung fehlschlägt
• über die Container-Runtime Befehle innerhalb der VM ausführen

Service Mesh

Verschlüsselter Speicher schützt Daten innerhalb eines Services. Sobald Daten den Service verlassen, durchqueren sie ein Netzwerk, das zur nicht vertrauenswürdigen Infrastruktur gehört. Confidential Services nehmen daher an einem Service Mesh teil, das den gesamten Datenverkehr zwischen ihnen verschlüsselt und authentifiziert.

Wie Services dem Mesh beitreten

Jede Confidential VM enthält einen Proxy-Sidecar, der den gesamten ein- und ausgehenden Datenverkehr des Services verarbeitet. Der Service kommuniziert nur mit seinem lokalen Proxy. Der Proxy verschlüsselt den Datenverkehr und sendet ihn an den Proxy des empfangenden Services, der ihn entschlüsselt und weiterleitet.

Entsprechende barrierefreie Textbeschreibung

Mutual TLS zwischen Services

Der gesamte Datenverkehr zwischen Confidential Services verwendet Mutual TLS (mTLS). Beide Seiten legen ihr Zertifikat vor und verifizieren die Gegenseite, bevor Daten fließen.

• Der Datenverkehr ist von einer Micro-VM zur anderen verschlüsselt. Der Betreiber sieht nur verschlüsselte Pakete und deren Endpunkte.
• Der Host oder ein nicht attestierter Service kann dem Mesh nicht beitreten, sich nicht als anderer Service ausgeben und den Datenverkehr nicht lesen.
• Die Anwendung muss nicht geändert werden. Sie kommuniziert wie gewohnt mit anderen Services, und das Mesh verschlüsselt die Verbindung auf der Leitung.

Datenverkehr, der das Mesh verlässt

Das Mesh deckt nur den Datenverkehr zwischen Confidential Services ab. Plane jeden anderen Pfad explizit ein.

• Ingress aus dem Internet. Öffentlicher Datenverkehr muss innerhalb einer Micro-VM entschlüsselt werden. Wird TLS an einem Router außerhalb der TEE terminiert, kann der Betreiber Anfragen im Klartext lesen.
• Egress zu externen Services. Das Mesh deckt keine Aufrufe an externe APIs oder Datenbanken ab. Verwende TLS und verifiziere das Serverzertifikat.
• Nicht-Confidential-Services. Datenverkehr zu regulären Services verlässt die Vertrauensgrenze. Die empfangende Seite ist nicht geschützt, behandle sie daher wie einen externen Service.

Verschlüsselung im Ruhezustand

Auf die Festplatte geschriebene Daten landen auf Speicher, der vom Betreiber kontrolliert wird. Confidential Services verschlüsseln persistente Daten mit LUKS (Linux Unified Key Setup) innerhalb der Micro-VM, bevor sie das Speicher-Backend erreichen.

1. Das Speicher-Backend bindet ein Volume als Block-Gerät an die Micro-VM an.
2. Der Gast entsperrt das Volume mit seinem Festplattenverschlüsselungsschlüssel.
3. Der Gast mountet das entschlüsselte Gerät, und der Service liest und schreibt Dateien wie gewohnt.

Entsprechende barrierefreie Textbeschreibung

Die gesamte Ver- und Entschlüsselung erfolgt innerhalb der TEE. Das Speicher-Backend, der Host und jeder Snapshot des rohen Volumes enthalten nur Chiffretext.

Vergleich mit regulären Services

	Regulärer Service	Confidential Service
Isolationsgrenze	Gemeinsam genutzter Host-Kernel	Eigener Kernel in einer verschlüsselten VM
Speicher	Vom Host lesbar	Verschlüsselt, vom Host nicht lesbar
Netzwerkverkehr zwischen Services	Auf der Leitung lesbar	Mit mTLS über das Mesh verschlüsselt
Daten auf der Festplatte	Vom Speicherbetreiber lesbar	Mit LUKS innerhalb der VM verschlüsselt
Start	Schnell	Langsamer, aufgrund von VM-Boot und Attestierung
Ressourcen-Overhead	Minimal	Zusätzlicher Speicher pro Service für den Gast-Kernel
Debugging-Zugriff	Vollständig	Eingeschränkt
Hardware	Beliebiger Host	Hosts mit TEE-Unterstützung

Für die praktischen Auswirkungen siehe Einschränkungen und Stolperfallen.