Confidential Computing: Warum „wir schauen nicht hin“ nicht mehr ausreicht

Regulierte Branchen stehen zunehmend vor einer neuen Anforderung an ihre Cloud-Sicherheit: Sie sollen gegenüber Prüfern belegen, dass ihr Anbieter auf die verarbeiteten Daten nicht zugreifen kann. Dass er es nicht tut, sichert er mit Auftragsverarbeitungsvertrag, Zertifizierung und Auditbericht zu. Dass er es nicht könnte, ließ sich bislang technisch nicht erzwingen. Confidential Computing schließt den Zugriff technisch aus und macht diesen Ausschluss belegbar.

Wie konkret diese Anforderung inzwischen ist, zeigt DORA. Die technischen Standards dazu verlangen ausdrücklich Regeln für die „Verschlüsselung von Daten, die gerade verwendet werden, soweit erforderlich“. Gemeint ist die Verarbeitung selbst, nicht nur die Speicherung und die Übertragung (Delegierte Verordnung (EU) 2024/1774, Artikel 6).

Diese Verschlüsselung ließ sich in einer herkömmlichen virtuellen Maschine kaum umsetzen. Der Grund ist nicht Nachlässigkeit, sondern Technik. Für die Verarbeitung muss der Prozessor die Daten unverschlüsselt im Arbeitsspeicher vorhalten, und das gilt für jede virtualisierte Umgebung. Der Schutz an dieser einen Stelle blieb deshalb organisatorisch: Zugriffskontrollen, dokumentierte Prozesse und regelmäßige Audits.

Confidential Computing verschiebt genau diese Stelle von organisatorischen Maßnahmen in die Hardware. Aus „wir schauen nicht hin“ wird „wir können nicht hinschauen“. Das lässt sich nachweisen.

Für wen ist Confidential Computing relevant?

Confidential Computing setzt dort an, wo Zusicherungen nicht mehr genügen. Die Technik muss den Schutz sensibler Daten erzwingen und Dritten belegen können, dass sie es tut. Im Vordergrund stehen dabei drei Bereiche.

Regulierte Branchen wie Finanzwirtschaft, Versicherungen und Gesundheitswesen führen den Nachweis gegenüber Aufsicht und Wirtschaftsprüfung. Gefordert ist dort beides: der technische Schutz kritischer Workloads und der Beleg, dass er wirkt. Prozessdokumentation allein genügt nicht. Die Anforderung stammt dabei nicht nur aus DORA. Auch NIS-2 verlangt „Konzepte und Verfahren für den Einsatz von Kryptografie“. Betroffen sind wesentliche und wichtige Einrichtungen, vom Energieversorger bis zum IT-Dienstleister.

Die öffentliche Verwaltung verarbeitet Daten von Bürgerinnen und Bürgern, die sich den Verarbeiter nicht aussuchen können. Wer Souveränität zusagt, muss den Nachweis selbst führen. Die Zusicherung des Cloud-Anbieters genügt dafür nicht.

Plattformanbieter und Softwarehersteller stehen gegenüber ihren eigenen Kunden in der Pflicht: Sie verarbeiten fremde Daten in eigener Verantwortung. Den Betrieb können sie auslagern, die Verantwortung nicht.

AMD SEV-SNP: Verschlüsselung auf Hardwareebene

Für die IONOS Confidential VMs setzen wir auf AMD SEV-SNP, eine Sicherheitstechnologie moderner AMD-Prozessoren. Das Prinzip ist einfach, die Konsequenz weitreichend: Jede Confidential VM erhält vom Prozessor einen eigenen VM Encryption Key. Dieser Schlüssel verlässt den Chip nie. Er ist für den Hypervisor, die Virtualisierungsschicht des Hosts, nicht zugänglich, ebenso nicht für andere Prozesse auf derselben Maschine. Der gesamte Arbeitsspeicher der VM ist für jeden außerhalb der VM verschlüsselt und unlesbar.

AMD SEV-SNP beschreibt zwei Schutzwirkungen: Secure Encrypted Virtualization (SEV) steht für die Verschlüsselung des Arbeitsspeichers, Secure Nested Paging (SNP) für den Schutz seiner Integrität. Denn Vertraulichkeit allein genügt nicht. Speicherinhalte könnten auch unbemerkt verändert, umgeleitet oder durch einen älteren Stand ersetzt werden. Solche Manipulationsversuche erkennt die Hardware und blockiert sie.

Confidential Computing bei IONOS: End-to-End Zero Trust

Verschlüsselter Arbeitsspeicher ist die Grundlage, nicht die ganze Kette. Wer bestimmt, welche Software in der VM startet, bestimmt auch, was mit den entschlüsselten Daten geschieht. End-to-End Zero Trust heißt deshalb: Auch Image und Attestierung kommen ohne Vertrauen in uns aus. Zur Verschlüsselung kommen drei weitere Komponenten, die ineinandergreifen. Zusammen ergeben sie Souveränität im technischen Sinn.

Das eigene Image: Nach dem Prinzip „bring your own image“ kommt das Betriebssystem nicht von uns. Kundinnen und Kunden bringen ihr Image selbst mit, inklusive Startprozess.

Der gemessene Start: Ein eigenes Image nützt allerdings nur, wenn feststeht, dass genau dieses gestartet wurde. Deshalb berechnet der Prozessor beim Start einen kryptografischen Fingerabdruck des gesamten Software-Stands und stellt darüber einen signierten, fälschungssicheren Attestation Report aus. Einbezogen sind Firmware, Kernel, Startprozess und Startparameter.

Die Attestierung: Den Attestation Report kann ein Attestation Service mit vorab hinterlegten Erwartungswerten vergleichen. Erst bei exakter Übereinstimmung gibt er die Schlüssel für die verschlüsselten Datenträger frei; andernfalls startet die VM nicht.

Der Nachweis entsteht damit vor der Verarbeitung, nicht im Nachhinein. Technisch ist die Attestierung optional. Sie ist aber der Unterschied zwischen einem Schutz, den man annimmt, und einem, den man belegen kann.

Diese Kontrolle verlangt Eigenleistung: Image, Schlüssel und Attestierung liegen auf Kundenseite und damit auch die Verantwortung. Eine Confidential VM ersetzt deshalb keine herkömmliche VM. Sie ist die richtige Wahl dort, wo der Nachweis den Aufwand wert ist.

Warum es darauf ankommt, wer attestiert

Die Prüfung des Attestation Reports verdient einen genaueren Blick. Denn ein Nachweis ist nur so viel wert wie seine Quelle: Entscheidend ist nicht nur, ob attestiert wird, sondern auch, durch wen. Darüber wird in der Diskussion um Confidential Computing selten gesprochen: Je höher die Anforderungen, desto klarer sollten Infrastruktur und Attestierung getrennt sein.

Diese Entscheidung lassen wir dem Kunden: Er betreibt den Attestation Service selbst, oder er überträgt ihn einer unabhängigen dritten Partei. Letzteres trennt Betrieb und Kontrolle. Sinnvoll ist das überall dort, wo der Nachweis auch gegenüber Dritten tragen soll.

Möglich ist das nur, wenn wir unsere eigenen Bausteine überprüfbar machen. Die Firmware jeder Confidential VM entsteht deshalb öffentlich nachvollziehbar. Der Quellcode ist offengelegt, jeder Build in einem unveränderlichen öffentlichen Protokoll festgehalten. Wer das nachprüfen will, muss uns nicht fragen.

Vertrauen lässt sich nicht überprüfen. Transparenz schon.

Confidential Computing verschiebt den Maßstab für Cloud-Sicherheit

Am Anfang stand die Frage, die sich mit einem Vertrag nicht beantworten lässt: Kann der Cloud-Anbieter auf die verarbeiteten Daten zugreifen? Mit einer Confidential VM lautet die Antwort nein. Sie lässt sich prüfen, ohne den Anbieter zu fragen. Entscheidend ist damit nicht mehr, was er zusichert, sondern was sich unabhängig von ihm überprüfen lässt.

Zertifikate, Auditberichte und Vertragsklauseln bleiben notwendig. Sie beantworten aber immer nur, wie glaubwürdig ein Anbieter ist. An Gewicht gewinnt eine andere Frage: Wo muss ich vertrauen und was kann ich verifizieren?

Souveränität heißt deshalb nicht, dem Anbieter vertrauen zu können. Es geht darum, nicht vertrauen zu müssen.