.png){kind=logo}
Digitale Souveränität erfordert technische Kontrolle über die Daten
Der Standort des Rechenzentrums sagt nicht darüber aus, wer auf Ihre Daten zugreifen kann. Entscheidend in fremden Infrastrukturen sind Schlüsselkontrolle, Zugriffsbeschränkung und die Möglichkeit des Providers-Wechsels. Confidential Computing von enclaive bietet Ihnen genau das, in der Cloud Ihrer Wahl.
ENCLAIVE STELLT DIE CONFIDENTIAL-COMPUTING-SCHICHT DER GOVTECH-PLATTFORM BEREIT. ENTWICKELT UND BETRIEBEN IN DEUTSCHLAND.
Ein europäischer Datenstandort ist ein wichtiger Baustein digitaler Souveränität. Für echte Datenkontrolle sind jedoch Risiken bezüglich Rechtsraum, Betreiberzugriff und Anbieterabhängigkeiten zu berücksichtigen.
Welches Recht gilt?
Ein Standort in der EU beantwortet nicht automatisch, welchem Recht ein Anbieter unterliegt oder ob er zur Herausgabe sensibler Klartextdaten verpflichtet werden kann.
Wer kann auf Klartextdaten zugreifen?
Rollenmodelle und Verträge schränken den Zugriff von Provider-Personal organisatorisch ein. In klassischen Cloud-Architekturen bleiben privilegierte Administratoren und Infrastrukturkomponenten jedoch Teil des Vertrauensmodells. Regulatorische Vorgaben verlangen deshalb zunehmend auch technische Schranken.
Wie einfach lässt sich der Anbieter wechseln?
Wer Workloads und Schlüsselverwaltung eng an einen einzelnen Provider bindet, schafft neue Abhängigkeiten – mit negativen Auswirkungen auf die eigene Souveränität, selbst wenn Rechtsraum und Betreiberzugriff kein Risiko darstellen.
enclaive adressiert diese zentralen Souveränitätsrisiken auf zwei Ebenen: Confidential Computing schützt Daten auch während der Verarbeitung, schränkt den Klartextzugriff durch Infrastrukturbetreiber technisch ein und ermöglicht eine policy-basierte Schlüsselfreigabe an verifizierte Workloads. Die Multi-Cloud-Fähigkeit von enclaive reduziert zusätzlich die Abhängigkeit von einzelnen Infrastrukturprovidern und schafft eine belastbare Grundlage für den Anbieterwechsel.
Bring / Hold Your Own Key über ein virtuelles HSM unter ihrer Kontrolle — unabhängig vom KMS eines Cloud-Providers. Die Freigabe kann an definierte Attestation-Policies gebunden werden, während Schlüsselverwaltung und Plattformadministration getrennt bleiben.
Sensible Daten bleiben auch während der Verarbeitung geschützt. Privilegierte Infrastrukturrechte allein ermöglichen keinen Klartextzugriff auf geschützte Workloads. Das reduziert auch das Risiko durch kompromittierte oder unter Druck gesetzte Administratoren.
enclaive lässt sich über Hyperscaler, europäische Cloud-Provider und On-Premises-Infrastrukturen hinweg einsetzen. Workloads und Schutzarchitektur bleiben dabei weniger eng an einen einzelnen Provider – und auch nicht an enclaive – gebunden.
Attestation und kryptografische Nachweise machen zentrale Eigenschaften der laufenden Umgebung überprüfbar. Zugriffs- und Kontrollmechanismen lassen sich damit technisch belegen statt ausschließlich vertraglich zusichern.
Souveränitätsanforderungen sollten die Wahl der Infrastruktur nicht unnötig einschränken. enclaive setzt Schutz und Kontrolle auf Workload-Ebene um – über Hyperscaler, europäische Cloud-Provider und On-Premises hinweg. So bleibt die Architektur konsistent und der Wechsel zwischen Betriebsmodellen möglich.
Nutzen Sie die Skalierung und Services von AWS, Azure oder Google Cloud, während Schlüssel unter Ihrer Kontrolle bleiben und der reguläre Klartextzugriff durch den Provider praktisch ausgeschlossen wird. So lassen sich bestehende Cloud-Strategien um eine zusätzliche Souveränitätsebene ergänzen.
Betreiben Sie Workloads bei IONOS, STACKIT oder anderen europäischen Providern mit derselben Confidential-Computing-Basis. So verbinden Sie die Vorteile des europäischen Rechtsraums und Datenstandorts mit technischer Zugriffskontrolle.
Besonders sensible Workloads können auf eigener Infrastruktur bleiben, während andere in der Cloud betrieben oder dorthin verlagert werden. enclaive verbindet die Betriebsmodelle über eine gemeinsame Plattform mit einheitlichem Key Management und technischen Nachweisen.
Für Ausschreibungen gemacht
Beschaffungsabteilungen in regulierten Branchen haben konkrete Kriterien, die erfüllt sein müssen. enclaive adressiert dabei die Fragen, die bei souveränitätskritischen Ausschreibungen regelmäßig aufkommen.
Wer kontrolliert die Schlüssel? Sie. BYOK und HYOK ermöglichen Key Management unter Ihrer Kontrolle – unabhängig vom KMS des Cloud-Providers. Schlüsselverwaltung und Plattformbetrieb lassen sich organisatorisch und technisch voneinander trennen.
Kann der Infrastrukturbetreiber auf Klartextdaten zugreifen? Nein. Die Hardware-basierte Isolierung schützt Daten auch während der Verarbeitung. Privilegierte Infrastrukturrechte allein ermöglichen keinen Klartextzugriff.
Wie sieht die Exit-Strategie aus? Die Multi-Cloud-Architektur von enclaive ermöglicht einen planbaren Anbieterwechsel – mit kundenseitigem Key Management und Betrieb in eigenen Cloud-Accounts.
Welche Nachweise gibt es? Attestation sowie technische Nachweise zu Schlüssel- und Zugriffskontrollen machen zentrale Eigenschaften überprüfbar und unterstützen Vergabe und Audit.
Wo sitzt der Anbieter? Die enclaive GmbH ist ein deutsches Unternehmen unter deutscher und europäischer Rechtsprechung.
What sovereignty owners ask
Ist eine EU-Region eines Hyperscalers nicht bereits souverän?
Eine EU-Region adressiert zunächst den Datenstandort. Digitale Souveränität umfasst darüber hinaus die Kontrolle über Schlüssel und Zugriffsrechte, die Frage nach den möglichen Konsequenzen des jeweiligen Rechtraums, dem der Provider unterliegt, sowie die Möglichkeit, den Provider wieder zu wechseln.
Schützt Confidential Computing auch vor ausländischen Zugriffsgesetzen wie dem US CLOUD Act?
Confidential Computing hebt gesetzliche Zugriffsrechte nicht auf. Kundenseitiges Key Management und der Schutz von Data in Use gewährleisten jedoch, dass ein Infrastrukturprovider nur verschlüsselte Informationen sehen und gegegebenfalls weitergeben kann. Die konkrete Bewertung bleibt Sache Ihrer Rechtsabteilung.
Müssen wir unsere Hyperscaler-Umgebungen verlassen, um souveräner zu werden?
Nein. enclaive setzt Schutz und Kontrolle auf Workload-Ebene um und kann sowohl auf Hyperscalern als auch bei europäischen Providern oder On-Premises eingesetzt und nachträglich integriert werden. So bleibt die Wahl der Infrastruktur flexibel.
Wie unterscheidet sich das von Sovereign-Cloud-Angeboten der Hyperscaler?
Sovereign-Cloud-Angebote adressieren je nach Anbieter unter anderem Datenstandort, Betriebsmodelle und organisatorische Kontrolle. enclaive ergänzt eine providerübergreifende technische Schutzschicht gegenüber privilegierten Zugriffen auf Workload-Ebene. Key Management und Schutzmechanismen bleiben auch bei einem Infrastrukturwechsel erhalten.
Welche Nachweise können wir Auditoren und Prüfern vorlegen?
Attestation-Nachweise sowie Dokumentation zu Key Management, Funktionstrennung und Zugriffskontrollen machen zentrale Eigenschaften der Architektur überprüfbar. Ergänzende Mappings ordnen diese Controls relevanten regulatorischen und branchenspezifischen Anforderungen zu.
Wie lassen sich bestehende Workloads migrieren?
Viele bestehende Workloads lassen sich typischerweise ohne Änderungen am Anwendungscode in Confidential VMs, Kubernetes-Umgebungen oder Confidential Databases überführen. Der Einstieg kann schrittweise erfolgen – etwa zunächst über das Key Management und anschließend mit den besonders schützenswerten Workloads.
Souveränität ist kein einzelnes Produkt. Sie entsteht im Zusammenspiel dieser Bausteine.
BYOK und HYOK in einem von Ihnen kontrollierten virtuellen HSM – unabhängig vom KMS des jeweiligen Cloud-Providers.
Workloads bleiben auch während der Verarbeitung in hardwarebasierten Trusted Execution Environments geschützt.
Portable Confidential Pods mit einer einheitlichen Basis – unabhängig davon, wo Ihre Kubernetes-Workloads laufen.
Cloud(s) und On-Premises zentral steuern – mit den technischen Nachweisen, die Audit und Aufsicht benötigen.
Souveränität braucht eine technische Grundlage
Kommen Sie mit Ihren individuellen Anforderungen zu uns: Wir zeigen, was Ihre Architektur bereits abdeckt, wo Lücken bleiben und wie sich Ihre regulatorischen Vorgaben technisch erfüllen lassen.
