Hold Your Own Key: Ihre Daten in AWS und Azure, Ihre Schlüssel in Europa

Hold Your Own Key: Die Cloud fragt, Sie entscheiden

AWS und Microsoft bieten beide einen dokumentierten Weg, den Schlüssel außerhalb ihrer eigenen Infrastruktur zu halten.

Mit AWS KMS External Key Store (XKS) legen Sie KMS-Schlüssel an, deren Schlüsselmaterial in einem externen Schlüsselmanager liegt. Azure Key Vault Managed HSM External Key Management (EKM) leistet dasselbe für die Azure-Dienste, die kundenverwaltete Schlüssel unterstützen.

Das Prinzip ist einfach. Ihre Daten bleiben, wo sie sind: in S3, EBS, Azure Storage oder Azure SQL. Aber jedes Mal, wenn die Cloud einen Datenschlüssel ver- oder entschlüsseln (AWS) bzw. ein- oder auspacken (Azure) muss, muss sie Ihren Schlüsselmanager aufrufen und fragen. Der Schlüssel selbst gelangt nie zum Cloud-Anbieter.

Damit haben Sie, was die Standardverschlüsselung nicht bietet: einen Schalter außerhalb der Cloud. Sperren Sie den Zugriff, kann die Cloud ihre Datenschlüssel nicht mehr öffnen, und Ihre Daten in dieser Cloud werden unlesbar. Nicht gelöscht, nicht verschoben, sondern verschlossen, bis Sie es anders entscheiden.

Was QuantumAPI beisteuert

QuantumAPI implementiert die öffentlichen Proxy-Spezifikationen von AWS XKS und Azure EKM. Sie erstellen in QuantumAPI einen externen Schlüssel, verbinden Ihren AWS-Schlüsselspeicher oder Ihr Managed HSM damit, und von da an fragt AWS oder Azure bei QuantumAPI nach, sobald dieser Schlüssel gebraucht wird. Das bekommen Sie auf unserer Seite:

• Ein Schlüssel in der EU. Das Schlüsselmaterial wird von QuantumAPI, einem europäischen Unternehmen, auf EU-Infrastruktur erzeugt und verwahrt. AWS und Microsoft erhalten es nie.
• Schlüssel aus Quantenzufall. Externe Schlüssel werden aus Quantenentropie eines QRNG-Dienstes erzeugt (derzeit der ANU QRNG der Australian National University). Ist die Quantenquelle nicht verfügbar, springt ein kryptografischer Standardgenerator (CSPRNG) ein. In beiden Fällen wird die tatsächlich verwendete Quelle bei jedem Schlüssel festgehalten, ein Fallback wird also nie verschwiegen.
• Post-Quanten-Schutz im Ruhezustand. Ihr Schlüssel wird verschlüsselt unter einer Schlüsselkette gespeichert, die mit ML-KEM-768 (FIPS 203) geschützt ist, dem Post-Quanten-Standard des NIST.
• Jeder Aufruf protokolliert. Jede Operation erscheint in Ihrem Schlüsselaktivitätsprotokoll: wer angefragt hat (der IAM-Principal bei AWS, der Managed-HSM-Pool bei Azure), über welchen Dienst, mit welchem Ergebnis und welcher Latenz.
• Ein Notschalter. Deaktivieren Sie einen Schlüssel oder trennen Sie einen Schlüsselspeicher im Portal, und QuantumAPI lehnt die Anfragen dieser Cloud ab sofort ab.
• Nutzungsbasierte Preise. Jede erfolgreiche Schlüsseloperation der Cloud zählt als ein API-Aufruf Ihres Tarifs. Externe Schlüssel und Schlüsselspeicher sind kostenlos und unbegrenzt, wie jeder andere Schlüssel in QuantumAPI.

Bei AWS gibt es einen Bonus. KMS nutzt doppelte Verschlüsselung: zuerst innerhalb von AWS, dann mit Ihrem externen Schlüssel. Weder AWS noch QuantumAPI kann Ihre Daten allein entschlüsseln. Das Azure-Protokoll funktioniert anders (QuantumAPI packt den Datenschlüssel direkt ein), deshalb treffen wir diese Aussage für Azure nicht.

Was es nicht leistet (und das sagen wir lieber selbst zuerst)

Post-Quanten-Sicherheit ist unsere ganze Marke. Es wäre also verlockend, von „Post-Quanten-AWS“ zu sprechen. Das ist es nicht, und so werden wir es auch nicht verkaufen.

Die Cloud-Protokolle sind klassisch. Der Verkehr zwischen AWS oder Azure und unserem Proxy nutzt, was die Anbieter vorgeben: TLS, AES-256 und bei Azure RSA-basierte Client-Zertifikate. Keines davon handelt heute ML-KEM aus. AES-256 selbst hält Quantencomputern gut stand; der klassische Schlüsselaustausch in TLS nicht, und den steuert der Client des Cloud-Anbieters, nicht wir. Ihr S3-Bucket oder Ihr Azure-Storage-Konto wird durch diese Funktion nicht quantensicher. Post-quantensicher ist, wie wir Ihren Schlüssel speichern.

Es ist kein HSM. Version 1 ist ein softwarebasierter Schlüsselmanager ohne FIPS-140-3-Zertifizierung. Wenn Ihre Richtlinien ein zertifiziertes HSM verlangen, ist dies noch nicht das richtige Produkt für Sie.

Der Notschalter stoppt neue Anfragen, keine zwischengespeicherten Schlüssel. Manche Cloud-Dienste halten Datenschlüssel eine Zeit lang im Speicher (S3 Bucket Keys, eingebundene Datenträger, Azure Storage). Diese funktionieren weiter, bis der Dienst erneut fragt. Der Widerruf erreicht alles innerhalb dieser Cache-Dauer, nicht in derselben Sekunde.

Es ist eine Preview. Erreicht die Cloud QuantumAPI nicht, kann sie Ihren Schlüssel nicht nutzen, und die davon abhängigen Daten sind nicht verfügbar. Genau darum geht es bei HYOK, und deshalb bitten wir Sie, mit Test- oder unkritischen Workloads zu beginnen. Wir sind kein zertifizierter Partner von AWS oder Microsoft, und Google Cloud wird nicht unterstützt.

So funktioniert es

Aus Sicht der Cloud ist QuantumAPI einfach ein externer Schlüsselmanager. Eine typische Anfrage läuft so ab:

1. Eine Anwendung liest eine Datei aus S3, oder eine Azure-SQL-Datenbank startet. Der Cloud-Dienst braucht seinen Datenschlüssel.
2. AWS KMS oder Azure Managed HSM schickt eine signierte Anfrage an den QuantumAPI-Proxy: „Entschlüssele das mit Schlüssel X“ (AWS) oder „Packe das mit Schlüssel X aus“ (Azure).
3. QuantumAPI prüft, wer anfragt (die AWS-Signatur oder das Azure-Client-Zertifikat), ob der Schlüssel zu dieser Verbindung gehört und ob weder Schlüssel noch Verbindung abgeschaltet sind.
4. Passt alles, führt QuantumAPI die AES-256-Operation mit Ihrem Schlüssel aus und liefert das Ergebnis. Der Aufruf landet in Ihrem Schlüsselaktivitätsprotokoll und zählt als ein API-Aufruf.
5. Haben Sie den Notschalter betätigt, lehnt QuantumAPI ab, und die Cloud kann den Datenschlüssel nicht öffnen.

Für wen es gedacht ist und wie Sie es testen

Externe Schlüsselspeicher richten sich an regulierte europäische Unternehmen, die auf AWS oder Azure arbeiten und nachweisen müssen, wer den Zugriff auf ihre Daten kontrolliert. Denken Sie an DORA und die Vorgaben zum IKT-Drittparteienrisiko für Finanzunternehmen, an NIS2 für wesentliche und wichtige Einrichtungen oder an die DSGVO-Debatte über internationale Datenübermittlungen seit Schrems II. HYOK macht Sie nicht allein compliant, gibt Ihnen aber eine konkrete, prüfbare Antwort auf die Frage: „Kann unser Cloud-Anbieter unsere Daten ohne uns lesen?“

Ein fiktives Beispiel: Ein europäischer Versicherer speichert Policen in S3 in Frankfurt. Sein Risikoteam will die Schlüssel aus der Hand des Anbieters nehmen und jeden Zugriff nachvollziehen können. Mit einem externen Schlüsselspeicher nutzt der Bucket einen KMS-Schlüssel, der bei QuantumAPI liegt. Jede Entschlüsselung erscheint mit der IAM-Rolle und dem anfragenden Dienst, und muss der Versicherer den Zugriff je kappen, stoppt eine einzige Aktion in QuantumAPI neue Entschlüsselungen.

Volle Kontrolle? Dann betreiben Sie es in Ihrem eigenen Rechenzentrum. Wenn der eigentliche Grund für HYOK ist, dass niemand sonst Ihre Schlüssel kontrolliert, ist nicht unser SaaS die stärkste Lösung, sondern QuantumAPI on-premises in Ihrem eigenen Rechenzentrum. Schlüsselmanager, Datenbank, Zufallserzeugung (Quantenquelle oder Fallback), Audit-Protokoll und Notschalter liegen dann unter Ihrer Kontrolle, und kein Dritter, auch wir nicht, ist dazwischen. Die Unterstützung externer Schlüsselspeicher kommt in die On-Premises-Edition; heute ist sie dort noch nicht enthalten. Die SaaS-Preview ist der schnellste Weg, die Idee schon jetzt auszuprobieren. On-Premises folgt demselben nutzungsbasierten Modell: abgerechnet nach API-Aufrufen und Speicher, nie pro Nutzer und nie pro Schlüssel.

Der Preis dafür, offen gesagt: Wer es selbst betreibt, verantwortet auch die Verfügbarkeit. Fällt Ihr Proxy aus, kann die Cloud Ihre Daten nicht entschlüsseln. Das gilt in beide Richtungen, und es ist der Preis der vollen Kontrolle.

Was wir gemessen haben. Am 24. Oktober 2026 haben wir den Azure-Pfad durchgängig mit einem echten Azure Key Vault Managed HSM in North Europe getestet. Azures ekm-connection check hat QuantumAPI erkannt, Wrap- und Unwrap-Durchläufe funktionierten, nach „Trennen“ in QuantumAPI schlug der nächste Unwrap von Azure sofort mit „disconnected in QuantumAPI“ fehl (das Managed HSM speichert Unwraps nicht zwischen), und nach dem erneuten Verbinden war der Zugriff wieder da. Innerhalb von QuantumAPI dauerte jeder Wrap oder Unwrap etwa 2 bis 14 ms bei bereits zwischengespeichertem Schlüssel und etwa 100 ms beim ersten Aufruf, der den Schlüssel lädt. Das ist nur die Verarbeitungszeit auf unserer Seite: Der Netzwerkweg zur Cloud kommt hinzu, und die Summe muss im 250-ms-Budget der Cloud bleiben. Deshalb muss der Dienst nahe an den Cloud-Regionen laufen, die er bedient. Der AWS-XKS-Proxy ist implementiert, aber noch nicht live gegen AWS getestet; diese Ergebnisse veröffentlichen wir, sobald wir sie haben.

Externe Schlüsselspeicher sind als Preview in QuantumAPI 0.25.0 verfügbar. Die Schritt-für-Schritt-Einrichtung für AWS und Azure finden Sie auf docs.quantumapi.eu. Wenn Sie ein Pilotprojekt starten oder Ihr Szenario besprechen möchten, melden Sie sich: Wir hören Ihre Anforderungen lieber jetzt, solange die Funktion noch Form annimmt.