WizardTales erweitert wx-one Cloud: 100 % verifizierbare Confidential-Computing-Sicherheit mit AMD SEV-SNP, ephemerem vTPM und SVSM

Warum Confidential Computing jetzt entscheidend ist

Angriffe verlagern sich zunehmend in die Verarbeitungsebene. Klassische Schutzkonzepte sichern Daten im Ruhezustand und auf dem Transportweg – nicht jedoch die Ausführung. Confidential Computing (CC) schließt diese Lücke: Hardware-gestützte Isolation plus Remote Attestation machen die Vertrauenswürdigkeit einer Umgebung mess- und beweisbar. An die Stelle bloßer Annahmen tritt ein technischer Beweis: „Erst wenn die VM nachweislich sicher ist, erhält sie einen Schlüssel – andernfalls nicht.“

Unser Ansatz: Vertraulichkeit, die sich beweisen lässt

AMD SEV-SNP schützt VM-Speicher durch Seiten-Isolierung und Integritätsschutz. SVSM kapselt Sicherheitsfunktionen, und ein ephemeres vTPM existiert nur für die Lebensdauer der VM. Remote Attestation (RA) prüft vor jeder Schlüsselvergabe, ob die Laufzeitumgebung exakt der vom Kunden definierten Policy entspricht (Image-Hash, Boot-Kette/Firmware-Messwerte, SVSM-Konfiguration, Netzwerkisolation usw.). Erst dann wird der Schlüssel über einen gesicherten Kanal an genau diese attestierte VM übermittelt. Persistente Provider-Secrets? Nein. Schlüssel in Provider-Domäne? Nein.

Mit „Confidential Encryption“ verbindet wx-one CC und RA:

HYOK/BYOK-only: Schlüssel entstehen und verbleiben in der Domäne des Kunden (eigenes HSM/KMS, On-Prem, souveräne KMS, bei uns, oder wo auch immer Sie sich wohlfühlen).

Gating durch RA: Ohne bestandene Attestation keine Schlüssel.

Ephemerie by Design: Nach Shutdown erlischt das vTPM samt Zuständen. Keine Rückstände beim Provider.

Kontext & Vertrauensmodell – wie bereits in unserem Blog beschrieben

Wir haben in der Vergangenheit in unserem Blog „Confidential Computing / CVMs: Was ist das und wie relevant ist es für Kubernetes?“ darauf hingewiesen, dass Confidential Computing das Vertrauensproblem primär vom Cloud-Provider hin zum Hardwarehersteller verschiebt – ein wichtiger, oft übersehener Punkt im Threat Model moderner Infrastrukturen. Hier der Artikel:👉 https://wx1.de/…

Was bedeutet das praktisch?

Der Cloud-Provider verliert die technische Möglichkeit, Workloads einzusehen;

Vertrauen konzentriert sich stärker auf Silizium, Firmware und deren Lieferkette.

Unternehmen aus den USA können im Zweifel immer noch auf ihre Daten zugreifen, aufgrund des Cloud Acts kann nicht davon ausgegangen werden, dass diese Anbieter gezwungen werden, mit Hintertüren an die Daten zu kommen. Da auch die Hardwarehersteller aus den USA stammen, besteht hier also ein Interessenkonflikt. Ein nicht US-Anbieter wie die WX-ONE Cloud ist also sogar noch einmal sicherer, da es weder dem Cloud-Act Folge zu leisten hat, und auf ggf. existierende Hintertüren gar keinen Zugriff bekommen würde.

Wie adressiert WX-ONE diese Verschiebung konstruktiv?

Harter Policy-Anker in der RA: Wir binden Attestation-Policies explizit an Firmware-/Microcode-Stände, Secure-Boot-Kette und SVSM-Profile. Weicht ein Messwert ab → keine Schlüssel (Fail-Secure).

Version-Pinning & Revocation: Nur freigegebene OVMF/PSP/SVSM-Versionen sind zulässig; Revocation-Listen werden strikt erzwungen.

Transparente Evidenz: Attestation-Artefakte lassen sich kundenseitig verifizieren und auditieren – herstellerübergreifend nachvollziehbar.

Mehr-Augen-Prinzip: Optional können unabhängige Attestation-Services einbezogen werden (Separation of Duties).

Schnelle Remediation: Fällt eine HW/FW-Version negativ auf, sperrt die Policy die Schlüsselvergabe sofort; betroffene Workloads bleiben verschlüsselt.

So wird das unvermeidbare Restvertrauen in die Hardwarelieferkette auf minimale, überprüfbare Anker reduziert – ohne Rückfall in Provider-Zugriffsmodelle.

Warum wir keine „transparente Verschlüsselung“ für Block-Storage anbieten

„Transparente Verschlüsselung“ (Data-at-Rest auf Provider-Seite) klingt bequem, löst aber nicht das Kernproblem: Wer kontrolliert den Moment der Entschlüsselung während der Verarbeitung? Häufig verbleiben Schlüssel – direkt oder indirekt – in der Provider-Infrastruktur. Das schafft Abhängigkeiten und erfordert Restvertrauen. Wir setzen stattdessen auf Kundenschlüssel in Kundendomäne und Attestation-Gating, damit niemand außer dem Kunden über die Daten verfügen kann – auch nicht wir.

Probleme aus der Praxis

1) DSGVO/Datenschutz – Datenminimierung, Zweckbindung, Nachweisbarkeit

Problem: Verantwortliche müssen „Stand der Technik“ (Art. 32), Datenminimierung, Zweckbindung und Nachweisbarkeit sicherstellen – inkl. Risiko-Reduktion in DPIAs (Art. 35) und Drittland-Transfers.

WX-ONE Lösung:

Kundenseitige Schlüsselkontrolle (HYOK) → Kein Provider-Zugriff, keine Schlüssel-Kopien, minimierte Datenverarbeitung in der Provider-Sphäre.

Remote Attestation Logs → prüffähige Evidenz pro Start/Ereignis; erleichtert Rechenschaftspflichten und Audit-Trails.

Laufzeit-Vertraulichkeit (data at runtime) → senkt Rest-Risiken in DPIAs signifikant, weil Klartext-Fenster hardware-isoliert sind.

Standort & Souveränität: Kombinierbar mit regionalen Deployments und souveränen KMS – ohne Schlüsselabgabe.

2) Geschäftsgeheimnisse/Know-how-Schutz (GeschGehG & Co.)

Problem: Rechtlicher Schutz gilt nur bei angemessenen Geheimhaltungsmaßnahmen. Cloud-Betrieb birgt Insider-, Supply-Chain- und Forensik-Risiken.

WX-ONE Lösung:

Attestierte Ausführung + Ephemer-Keys → keine dauerhaften Secrets in fremder Domäne.

Provider-Insider-Resilienz: Ohne Schlüssel kein Zugriff, auch nicht bei kompromittierten Operator-Konten.

Beweisbarkeit: Attestation-Evidenz unterstützt die Argumentation, dass angemessene Maßnahmen tatsächlich technisch umgesetzt sind.

3) Regulatorik/Branchen-Compliance (Banken, KRITIS, Healthcare, Public)

Problem: Strenge Anforderungen an Mandantentrennung, Nachvollziehbarkeit und Souveränität – oft über reine Zertifikatslagen hinaus.

WX-ONE Lösung:

Messbare Isolation (SEV-SNP/SVSM) auf VM-Ebene statt bloßer Prozesszusagen.

Policy-gebundene RA: Jede VM muss live beweisen, dass sie Ihrer Sicherheitsrichtlinie entspricht – bei jedem Start.

Konkrete Praxisbeispiele – „alles verschlüsselt“ + verifizierbar Data at Rest (Speicher/Ruhezustand)

Backups & Snapshots: Kundenseitig verschlüsselt; Schlüssel verbleiben im eigenen KMS/HSM. Restore nur nach RA-Freigabe in attestierte Ziel-VMs.

Objekt- & Block-Storage: Keine Provider-Schlüssel; Rotation und „crypto-shredding“ vollständig kundenseitig steuerbar.

Protokoll-Daten & Crash-Dumps: Vor Speicherung pseudonymisiert/verschlüsselt; Zugriff nur aus attestierten Analyse-VMs.

Data in Transit (Netz/Übertragung)

mTLS/Key-Pinning zwischen Kunden-KMS, RA-Service und VM; Schlüssel-Kanäle nur an attestierte Identitäten.

Mandantenübergreifende Isolation: Segmentierung + mutual Auth; Kein lateraler Zugriff ohne Attestation-basierte Freigabe.

Data at Runtime (Verarbeitung/Laufzeit)

ML-Training auf sensiblen Datensätzen: Schlüsselbereitstellung nur in attestierte Trainings-VMs; Model-Artefakte können separat verschlüsselt werden.

Payments/Kontenabgleich: Temporäre Entschlüsselung ausschließlich im TEE; Keys ephemer, kein „Warm Cache“ beim Provider.

Gemeinsame Forschung (Health/Industrie): Confidential federation: Parteien verarbeiten gemeinsam Daten, ohne gegenseitige Offenlegung – dank CC + RA.

PLUS: Workload- & Firmware-Verifizierbarkeit via Remote Attestation

Boot-Kette: OVMF/Bootloader/Kern-Hashes werden gemessen; Policy fordert bestimmte Versionen/Signaturen.

Workload-Echtheit: Nur Images/Container mit freigegebenen Digests erhalten Keys.

Drift-Schutz: Weicht ein Messwert ab (z. B. ungepatchte Firmware), wird kein Schlüssel freigegeben → Fail-Secure.

Sicherheitsgewinne auf einen Blick

Zero-Trust-konform: Keine Annahmen – Beweise.

Insider- & Forensik-Resilienz: Ohne Schlüssel kein Zugriff – auch nicht „aus Versehen“.

Audit-fähig: Attestation-Evidenz als harte Nachweise statt bloßer Prozessbeschreibungen.

Shared-Responsibility neu gedacht: Verlagerung kritischer Kontrollen zum Kunden, ohne Betriebsaufwand zu erhöhen.

Roadmap & Partnerschaften

In Kürze folgen Partnerschaften im Confidential-Computing-Ökosystem (Hardware-Roots-of-Trust, Attestation-Services, souveräne KMS-Integrationen, Supply-Chain-Sicherung). Parallel stehen mehrere interne Entwicklungen vor Release: Policy-Engines, automatisierte Attestation-Workflows und Self-Service-Tools für „Confidential-by-Design“ in DevOps-Pipelines.

Branchen-Use-Cases (Auswahl)

Bank/Finanz: Echtzeit-Scoring/Abgleich in attestierten VMs; Schlüssel bleiben im Bank-HSM.

Healthcare: Forschende Kooperationen über Häuser hinweg, ohne Rohdaten offenzulegen.

Public/Sovereign: Datenhoheit, Standorttreue, verifizierbare Mandantentrennung.

Industrie/IP: CAE/ML auf Konstruktionsgeheimnissen – geschützt während der Verarbeitung.

Stimmen aus dem Unternehmen

„Verifizierbarkeit schlägt Vertrauensannahmen. Mit wx-one entscheiden Sie, wann, wo und ob Schlüssel in eine Laufzeitumgebung gelangen – und zwar nur nachdem diese Umgebung bewiesen hat, dass sie Ihrer Policy entspricht“, sagt Tobias Gurtzick, Geschäftsführer der WizardTales GmbH.„Das ist der Unterschied zwischen Marketing-Sicherheit und echter, messbarer Sicherheit.“

Eine Schlüsseltechnologie

Anders als Zertifikate macht Confidential Computing die Umgebung für den Kunden so sicher, als wenn diese im eigenen Gebäude untergebracht wäre. Dies ist ein Paradigmenwechsel und bedeutet, dass selbst bis dato als sehr kritisch angesehene Daten wie tiefste Geschäftsgeheimnisse zuverlässig und sicher ausgelagert werden können.

Deshalb unsere positive, klare Botschaft:

Ein Partner mit echtem, verifizierbarem Confidential Computing – selbst wenn er dies nicht anders nachweisen kann – kann im Zweifel sicherer sein als ein Anbieter ohne verifizierbares CC, der sich zwar mit vielen Zertifikaten schmückt, aber keinen technischen Beweis für die Integrität Ihrer konkret laufenden Workloads liefert. Daher glauben wir, dass Confidential Computing zu einer Schlüsseltechnologie wird, auch wenn noch viel zu tun ist.

Verfügbarkeit

Die erweiterten Confidential-Computing-Funktionen der WX-ONE Cloud sind ab sofort für ausgewählte Kunden/Early-Access verfügbar; die breite Verfügbarkeit folgt sukzessive. Proof-of-Concepts können ohne Schlüsselabgabe an den Provider durchgeführt werden.