Confidential Computing für klassifizierte Workloads: Enklaven und Attestierung

Klassifizierte Daten waren historisch gesehen in zwei ihrer drei Zustände geschützt. Verschlüsselung im Ruhezustand schützt sie auf der Festplatte; Verschlüsselung bei der Übertragung schützt sie auf dem Übertragungsweg. Der dritte Zustand – Daten in Verwendung, entschlüsselt in CPU-Register und RAM, um tatsächlich verarbeitet werden zu können – war stets die Achillesferse. Jeder Code mit ausreichenden Privilegien auf dem Host, einschließlich des Betriebssystems, des Hypervisors und eines Cloud-Betreibers mit physischem Zugriff auf den Speicherbus, kann diesen Klartext lesen. Confidential Computing schließt diese Lücke, indem die Workload innerhalb einer hardwareisolierten Trusted Execution Environment (TEE) ausgeführt wird, in der die CPU den Speicher verschlüsselt und für alles außerhalb der Enklave unlesbar hält. Für klassifizierte Workloads verändert dies grundlegend, wem vertraut werden muss – und diese Veränderung ist der eigentliche Kern.

Das Problem der Daten in Verwendung und das Bedrohungsmodell von Confidential Computing

Die grundlegende Prämisse von Confidential Computing ist eine verringerte Trusted Computing Base. In einer herkömmlichen Cloud-Bereitstellung ist der Mieter gezwungen, dem gesamten Stack unterhalb der Anwendung zu vertrauen: dem Gast-OS-Kernel, dem Hypervisor, der Host-Firmware, der Cloud-Steuerungsebene und den Personen, die das Rechenzentrum betreiben. Jedes dieser Elemente stellt einen möglichen Zugang zum Klartext während des Workload-Betriebs dar. Für eine Geheimhaltungsstufe „Secret" oder eine sensible Compartment-Workload ist diese Vertrauensfläche nicht akzeptabel.

Eine TEE kehrt das Modell um. Die CPU selbst erzwingt eine Isolationsgrenze, indem sie den Speicher der Enklave mit Schlüsseln verschlüsselt, die innerhalb des Hardware-Sicherheitsmoduls des Prozessors erzeugt und gespeichert werden und niemals der Software offengelegt werden. Das Host-Betriebssystem kann die Enklave planen, ihr Seiten zuweisen und sie beenden – aber es kann nicht lesen, was darin enthalten ist. Ein von einem Angreifer kompromittierter Hypervisor oder ein böswilliger Administrator, der einen Debugger anfügt oder den physischen Speicher ausliest, sieht nur Chiffretext. Der Vertrauensbereich schrumpft auf zwei Elemente: die Hardware des Siliziumherstellers und den Code, den Sie bewusst in die Enklave laden.

Genau diese Eigenschaft ermöglicht es Verteidigungsorganisationen, die Unterbringung sensibler Workloads auf Infrastruktur zu erwägen, die sie nicht physisch kontrollieren. Dies macht eine kommerzielle Region allein noch nicht für klassifizierte Daten akkreditiert – dafür sind die vollständigen Kontrollmaßnahmen erforderlich, die wir in unserer Analyse der Zero-Trust-Architektur für Militärnetzwerke erörtern –, aber es entfernt den Betreiber aus dem Vertrauensbereich für Daten in Verwendung, was die Risikoabwägung wesentlich verändert.

Trusted Execution Environments: SGX, SEV-SNP, TDX und CCA

Es gibt zwei architektonische Familien von TEEs, und die Wahl zwischen ihnen ist die erste und folgenreichste Entwurfsentscheidung.

Prozessbasierte Enklaven (Intel SGX). Software Guard Extensions schneidet einen kleinen, anwendungsdefinierten Speicherbereich – die Enklave – aus einem Prozess heraus und dichtet ihn von allem anderen ab, einschließlich des Kernels. Die Trusted Computing Base ist minimal: Nur der Code, den Sie in die Enklave legen, wird als vertrauenswürdig eingestuft, nicht das umgebende Betriebssystem. Der Nachteil ist, dass die Anwendung in vertrauenswürdige und nicht vertrauenswürdige Hälften aufgeteilt werden muss, mit einer kontrollierten Aufrufschnittstelle zwischen ihnen, und der Enklavenspeicher ist begrenzt. SGX ist das richtige Werkzeug, wenn Sie die kleinstmögliche Angriffsfläche rund um eine spezifische Geheimnisverarbeitungsroutine wünschen – einen Schlüsselverpackungsdienst, einen kryptografischen Signierer oder eine kleine Richtlinien-Engine.

VM-weite Vertraulichkeit (AMD SEV-SNP, Intel TDX, Arm CCA). Secure Encrypted Virtualization with Secure Nested Paging, Trust Domain Extensions und Arm's Confidential Compute Architecture Realms schützen jeweils eine gesamte virtuelle Maschine. Der Speicher des Gastes wird transparent verschlüsselt und integritätsgeschützt, der Hypervisor wird aus dem Vertrauensbereich entfernt, aber die Workload darin läuft unverändert. Eine bestehende klassifizierte Anwendung kann ohne Code-Änderungen in eine vertrauliche VM überführt werden. Die Trusted Computing Base ist größer – sie umfasst das gesamte Gast-Betriebssystem –, aber die Adoptionskosten sind erheblich geringer. Für die meisten Verteidigungs-Workloads, die eher migriert als neu entwickelt werden, ist VM-weite Vertraulichkeit die pragmatische Wahl.

SEV-SNP und TDX fügten eine Funktion hinzu, die der ersten Generation von SGX fehlte und die für klassifizierte Daten von besonderer Bedeutung ist: Speicher-Integritätsschutz, der sich gegen einen Angreifer richtet, der verschlüsselte Seiten wiederholt oder neu zuordnet, anstatt sie lediglich zu lesen. Jede für klassifizierte Zwecke ausgewählte TEE muss sowohl Vertraulichkeit als auch Integrität gewährleisten; Vertraulichkeit allein lässt die Workload anfällig für aktive Speicherkorruptionsangriffe vom Host.

Remote-Attestierung: Den Nachweis über die Enklave erbringen, bevor man ihr vertraut

Hardware-Isolierung ist notwendig, aber nicht ausreichend. Die Partei, die die klassifizierten Daten hält – oder den Schlüssel, der sie entschlüsselt –, benötigt den Beweis, dass die Enklave, mit der sie kommunizieren wird, echte TEE-Hardware ist, die genau den erwarteten Code ausführt, und kein Emulator, kein manipuliertes Image oder keine herabgestuftes-Mikrocode-Plattform, die vorgibt, sicher zu sein. Dieser Beweis ist die Remote-Attestierung, und sie ist der Mechanismus, der Confidential Computing vertrauenswürdig und nicht bloß plausibel macht.

Wie ein Attestierungsablauf funktioniert

Wenn eine Enklave startet, misst die CPU den geladenen Code und die Konfiguration in einem Hardware-Register und erzeugt auf Anfrage ein signiertes Quote-Dokument: eine Struktur, die diese Messungen, die Security-Version-Nummern der TEE und eine Signatur enthält, die auf einen im Silizium bei der Fertigung eingebetteten Schlüssel zurückführt. Die Enklave sendet dieses Quote-Dokument an einen Prüfer – einen Dienst, den der Dateneigentümer kontrolliert oder dem er vertraut. Der Prüfer validiert die Signaturkette bis zum Root-Zertifikat des Herstellers, bestätigt, dass die Plattform auf aktuellem, nicht zurückgerufenem Mikrocode läuft, und vergleicht die gemeldeten Messungen mit einer Erlaubnisliste von Code, dem er zu vertrauen bereit ist. Nur wenn alle Prüfungen bestanden sind, autorisiert der Prüfer den nächsten Schritt.

Die entscheidende technische Disziplin hierbei ist die reproduzierbare Messung. Das Enklave- oder Gast-Image muss deterministisch erstellt werden, sodass seine Messung jedes Mal bit-für-bit identisch ist, da die Attestierungsrichtlinie eine Erlaubnisliste exakter Messwerte ist. Ein nicht reproduzierbarer Build bedeutet eine sich ständig ändernde Messung, was Betreiber dazu zwingt, in die Kardinalssünde des Lockerns der Richtlinie zu verfallen, bis sie fast alles akzeptiert – womit der Zweck zunichte gemacht wird. Behandeln Sie die Start-Messung als Release-Artefakt, das neben den Firmware- und Mikrocode-Versionen, von denen es abhängt, aufgezeichnet und versioniert wird.

Attestierungsrichtlinie als eigentliche Sicherheitsgrenze

Die Hardware übernimmt die Kryptografie, aber die Richtlinie trifft die Entscheidung, und eine schwache Richtlinie macht starke Hardware wirkungslos. Eine verteidigungsgerechte Attestierungsrichtlinie besagt explizit: welche TEE-Typen akzeptiert werden; die Mindestversion der Trusted Computing Base mit Security-Version-Nummern-Prüfungen, die nach einer Schwachstellen-Offenlegung zurückgerollten Mikrocode ablehnen; den genauen Satz zulässiger Code-Messungen; sowie Aktualitätsanforderungen, sodass ein altes Quote-Dokument nicht wiederholt werden kann. Das häufigste Versagensmuster in realen Bereitstellungen ist keine defekte Enklave – es ist eine übermäßig permissive Richtlinie, die Messungen akzeptiert, die sie nicht sollte, oder die den Widerrufsstatus der Plattform nie prüft. Die Attestierung ist nur so gut wie die Regeln, die der Prüfer durchsetzt.

Schlüsselfreigabe: Geheimnisse an eine verifizierte Umgebung binden

Attestierung wird operativ nützlich, wenn sie den Zugang zu Geheimnissen steuert. Das Muster ist die attestierungsgebundene Schlüsselfreigabe: Der Schlüsselverwaltungsdienst ist so konfiguriert, dass ein klassifizierter Datenverschlüsselungsschlüssel nur nach Bestätigung einer bestandenen Attestierung durch den Prüfer ausgehändigt wird. Die Enklave fordert den Schlüssel an, legt frische Nachweise vor, und der KMS gibt den verpackten Schlüssel über einen Kanal frei, der innerhalb der TEE endet, sodass der Klartext-Schlüssel außerhalb der Enklave niemals existiert. Ein nicht attestierter Host, eine herabgestufte Plattform oder ein manipuliertes Image erhält schlicht niemals das Material, das es zur Entschlüsselung benötigt.

Dies kehrt die übliche Beziehung zwischen Identität und Autorisierung um. Anstatt einen Schlüssel freizugeben, weil ein Aufrufer einen Berechtigungsnachweis vorlegt, der gestohlen werden könnte, wird der Schlüssel freigegeben, weil die Laufzeitumgebung ihre Integrität kryptografisch nachgewiesen hat. Für Workloads, die Daten über Grenzen hinweg bewegen müssen, fügt sich dies sauber in die Kontrollen ein, die wir in unserem Beitrag über domänenübergreifende Lösungen für die Verteidigung beschreiben: Die Enklave, die den Transfer durchführt, kann aufgefordert werden, ihre Attestierung nachzuweisen, bevor ihr jemals Daten einer höheren Geheimhaltungsstufe anvertraut werden.

Cloud-Bereitstellungsmuster für klassifizierte Workloads

Alle großen staatlichen Cloud-Regionen bieten inzwischen vertrauliche VM-SKUs auf Basis von SEV-SNP oder TDX sowie verwaltete Enklave- und Attestierungsdienste an. Drei Bereitstellungsmuster treten in klassifizierten und sensiblen Programmen wiederholt auf.

Vertrauliche Datenverarbeitung. Die Workload, die klassifizierte Daten berührt – eine Analyse, eine Fusionsmaschine, ein Modell-Inferenzdienst –, läuft vollständig innerhalb vertraulicher VMs. Daten werden verschlüsselt angeliefert, Schlüssel werden nur an attestierte Enklaven freigegeben, und die entschlüsselten Daten existieren ausschließlich im geschützten Speicher. Dies ist das Lift-and-Shift-Muster: Bestehende Anwendungen erhalten Schutz für Daten in Verwendung mit minimalen Änderungen, wobei der Cloud-Betreiber ohne Umstrukturierung aus dem Vertrauensbereich entfernt wird.

Vertrauliches Schlüsselmanagement und -vermittlung. Eine kleine SGX-artige Enklave fungiert als Vertrauensanker: Sie hält Verpackungsschlüssel, führt die Attestierungsüberprüfung für andere Workloads durch und vermittelt Datenverschlüsselungsschlüssel an attestierte vertrauliche VMs. Die Konzentration der sensibelsten Logik in einer minimalen Enklave hält die Trusted Computing Base für die Schlüsselverarbeitung klein, selbst wenn die Massen-Workloads als vollständige vertrauliche VMs laufen.

Vertrauliche Mehrparteien- und Koalitionsberechnung. Zwei Organisationen, die keine Rohdaten austauschen können – Koalitionspartner oder Behörden auf unterschiedlichen Geheimhaltungsstufen –, tragen jeweils verschlüsselte Eingaben zu einer vertraulichen VM bei, die ein gemeinsames Ergebnis berechnet. Da keine Partei, einschließlich des Hosts, die Eingaben der anderen lesen kann, wird die Enklave zu neutralem Boden. Attestierung ermöglicht es jedem Beitragenden, genau zu überprüfen, welcher Code seine Daten verarbeiten wird, bevor er sie freigibt.

Restrisiken und operative Disziplin

Confidential Computing verengt die Bedrohungsfläche erheblich, beseitigt sie aber nicht vollständig. Seitenkanal-Angriffe auf TEEs sind ein aktives Forschungsgebiet, und mehrere haben Mikrocode-Mitigationen erfordert – weshalb die Durchsetzung von Security-Version-Nummern in der Attestierungsrichtlinie keine optionale Maßnahme ist. Der Enklaven-Code selbst liegt innerhalb des Vertrauensbereichs, sodass eine Schwachstelle dort eine Schwachstelle in der geschützten Workload ist; eine minimale Trusted Computing Base begrenzt den Schadensradius. Und die Silizium-Lieferkette wird letztlich als vertrauenswürdig eingestuft. Nichts davon widerlegt das Modell, aber es definiert die operative Disziplin: Mikrocode umgehend patchen, die Enklave klein halten, kontinuierlich neu attestieren statt nur beim Start, und jede Attestierungsentscheidung zur Prüfung in unveränderlichem Speicher protokollieren.

Confidential Computing ist eine starke Kontrollmaßnahme innerhalb einer umfassenderen akkreditierten Architektur, kein Ersatz für die Akkreditierung. Es gehört neben Datenresidenzkontrollen, einer Betriebsgenehmigung auf dem richtigen Einstufungsniveau, überprüftem Schlüsselmanagement sowie den Zero-Trust-Netzwerk- und domänenübergreifenden Kontrollen, die an anderer Stelle in dieser Reihe behandelt werden. Was es einzigartig bietet, ist auditierbarer Schutz für Daten in Verwendung – der Zustand, der bis vor Kurzem schlicht als exponiert vorausgesetzt wurde.