Die Speicherung von Finanzdienstleistungsdaten in der Cloud erfordert mehr als nur Zugriffskontrollen. Erfahren Sie, wie fortschrittliche Verschlüsselung und externes Schlüsselmanagement Finanzdaten schützen und DORA, NIS2, DSGVO und PCI DSS erfüllen – ohne den Betrieb zu verlangsamen.
Finanzinstitute haben den Punkt überschritten, an dem es bei der Cloud-Einführung kein Zurück mehr gibt. Die Frage ist nicht mehr, ob Finanzdaten in der Cloud gespeichert werden sollen, sondern ob Ihre Verschlüsselungsstrategie solide genug ist, um sie zu schützen, wenn etwas schief geht, und nicht erst, wenn etwas schief geht.
Die Zahlen sprechen für sich: Die durchschnittlichen Kosten einer Datenschutzverletzung im Finanzsektor belaufen sich derzeit auf 5,85 Millionen US-Dollar pro Vorfall, und 60 % der Finanzorganisationen geben an, dass sie Schwierigkeiten haben, Daten in Multi-Cloud-Umgebungen konsistent zu schützen. Gleichzeitig haben die Regulierungsbehörden die Messlatte deutlich hoher gelegt. DORA ist seit Januar 2025 in vollem Umfang in Kraft. Die obligatorischen Kontrollen gemäss PCI DSS 4.0.1 traten im März 2025 in Kraft. Die Durchsetzung von NIS2 beschleunigt sich bis 2026 in allen EU-Mitgliedstaaten.
In diesem Artikel geht es darum, welche regulatorischen Anforderungen heute tatsächlich an die Speicherung von Finanzdaten gestellt werden, wo Standard-Cloud-Verschlüsselung nicht ausreicht und wie eine wirklich sichere Schlüsselverwaltungsarchitektur in der Praxis aussieht.
Finanzinstitute verarbeiten einige der sensibelsten Daten, die es gibt – Karteninhaberdaten, Transaktionshistorien, KYC-Dokumentation, Kreditdateien und die damit verbundene interne Kommunikation. Diese Daten sind zunehmend über mehrere Umgebungen verteilt: öffentliche Clouds von mehreren Anbietern, SaaS-Plattformen, lokale Systeme und Hybridarchitekturen, deren Inventarisierung wirklich schwierig sein kann.
Die Multi-Cloud-Realität schafft ein spezifisches Problem. Wenn Finanzdaten gleichzeitig in AWS, Azure und einer SaaS-Plattform eines Drittanbieters gespeichert sind, bringt jede Umgebung ihre eigenen nativen Verschlüsselungsstandards, ihr eigenes Schlüsselverwaltungssystem und ihren eigenen Prüfpfad mit. Um einen konsistenten, überprüfbaren Schutz für alle zu gewährleisten, ist eine Kontrollebene erforderlich, die über jedem einzelnen Cloud-Anbieter liegt – und nicht drei separate Richtlinien, die lose durch die Tabellenkalkulation einer anderen Person koordiniert werden.
Dies ist auch kein hypothetisches Risiko. Verstösse im Finanzsektor sind immer wieder auf die gleiche grundlegende Schwachstelle zurückzuführen: Die Daten waren technisch verschlüsselt, die Schlüssel wurden jedoch von derselben Partei verwaltet, die kompromittiert wurde, oder sie waren auf eine Weise zugänglich, die Angreifern einen Durchbruch verschaffte. Verschlüsselung ohne sinnvolle Schlüsselkontrolle ist eigentlich nur der Anschein von Sicherheit.
Das regulatorische Bild für die Speicherung von Finanzdaten hat sich in den letzten 18 Monaten erheblich verändert. Es lohnt sich, jedes wichtige Framework im Einzelnen durchzugehen, da die Anforderungen an Verschlüsselung und Schlüsselverwaltung strenger sind, als vielen Teams bewusst ist.
DORA trat am 17. Januar 2025 in vollem Umfang in Kraft – und im Gegensatz zu einer EU-Richtlinie gilt es in allen 27 Mitgliedsstaaten identisch, ohne Raum für nationale Abweichungen. Es umfasst Banken, Versicherungen, Wertpapierfirmen, Zahlungsdienstleister und die sie bedienenden IKT-Drittanbieter.
Die wichtigsten Anforderungen für die Speicherung von Finanzdaten betreffen das IKT-Risikomanagement und die Aufsicht durch Dritte. Finanzunternehmen müssen ein dokumentiertes Risikomanagement-Framework mit Rechenschaftspflicht auf Vorstandsebene implementieren, und die Verschlüsselung sensibler Daten im Ruhezustand und bei der Übertragung ist eine erwartete Grundkontrolle. Genauer gesagt muss sich das Framework damit befassen, wie kryptografisches Schlüsselmaterial geschützt wird – nicht nur, dass Daten verschlüsselt werden, sondern auch, dass die Schlüssel selbst unter der sinnvollen Kontrolle der Entität stehen.
Bei der Cloud-basierten Speicherung werden die Bestimmungen Dritter besonders relevant. Wenn Sie die Schlüsselverwaltung an einen Cloud-Anbieter delegieren, verlangt DORA von Ihnen, dass Sie nachweisen, dass Sie die Kontrollen dieses Anbieters fortlaufend überwachen. Die Aufsichtsbehörden prüfen, ob der Cloud-Anbieter einseitigen Zugriff auf Ihre Schlüssel hat – das heisst, ob er Ihre Daten ohne Ihr Zutun entschlüsseln könnte. Wenn sie das können, ist Ihre Compliance-Haltung an dieser Front schwach. Die Strafen bei Nichteinhaltung belaufen sich auf bis zu 2 % des gesamten weltweiten Jahresumsatzes von Finanzunternehmen.
NIS2 klassifiziert Organisationen des Finanzsektors sowohl als wesentliche als auch als wichtige Einheiten. Artikel 21 fordert ausdrücklich die Verschlüsselung als Risikomanagementmassnahme mit Kontrollen, die im Verhältnis zum Risiko stehen. Die Durchsetzung läuft bis 2026 – deutsche Unternehmen müssen im April 2026 eine BSI-Registrierungsfrist einhalten, und andere Mitgliedstaaten arbeiten an ihren eigenen Zeitplänen.
Im Juni 2025 veröffentlichte ENISA fast 200 Seiten technischer Leitlinien für die NIS2-Implementierung und machte zuvor informelle Erwartungen deutlich: spezifische Standards für die Verschlüsselung bei der Übertragung und im Ruhezustand, Schlüsselverwaltungspraktiken und Methoden zur Anbieteraufsicht. Wenn Ihr Sicherheitsteam dieses Dokument noch nicht überprüft hat, lohnt es sich, dies zu tun.
Artikel 32 der DSGVO verlangt seit jeher geeignete technische und organisatorische Massnahmen zum Schutz personenbezogener Daten, und Verschlüsselung ist das kanonische Beispiel. Was Schrems II hinzufügte – durch die Aufhebung des EU-US-Datenschutzschilds – ist eine eher operative Anforderung: Organisationen, die Finanzdaten von EU-Bürgern in einer US-amerikanischen Cloud-Infrastruktur speichern, müssen nachweisen können, dass der Cloud-Anbieter ohne Wissen der betroffenen Person und ohne die Möglichkeit, diesen Zugriff zu widerrufen, nicht auf die Daten zugreifen kann (oder von ihnen durch US-Behörden gezwungen werden kann).
Für jedes Finanzinstitut mit EU-Kundendaten auf AWS, Azure oder GCP stellt dies ein direktes Argument für Verschlüsselungsschlüssel dar, die niemals die Infrastruktur des Cloud-Anbieters berühren.
PCI DSS 4.0.1 ist nun ab März 2025 vollständig in Kraft. Die Anforderungen 3 und 4 regeln gespeicherte Karteninhaberdaten bzw. Daten während der Übertragung. Die Schlüsselverwaltungsbestimmungen von Anforderung 3.7 legen fest, dass kryptografische Schlüssel vor Offenlegung und Missbrauch geschützt werden müssen, mit dokumentierten Verwahrern und geteilten Kenntnissen oder Verfahren mit doppelter Kontrolle für Schlüsselverschlüsselungsschlüssel. Dabei handelt es sich zwar nicht um neue Konzepte, aber sie sind mittlerweile verbindlich, es gibt keine verbleibende Nachfrist und es gibt keinen Spielraum für den Ermessensspielraum des Prüfers.
Für Institute mit Schweizer Niederlassung verlangt das Rundschreiben der FINMA zu operationellen Risiken eine nachweisbare Schlüsselverwaltungshoheit für die in Cloud-Umgebungen gespeicherten Daten. Die Schweizer Regulierungsbehörden haben bei der Kontrolle von Cloud-Daten stets eine konservative Haltung eingenommen und erwarten eher Beweise als Behauptungen dafür.
AWS, Azure und Google Cloud verschlüsseln ruhende Daten standardmässig. Dabei handelt es sich um einen entscheidenden Faktor – es handelt sich nicht um ein Unterscheidungsmerkmal, und bei regulierten Finanzdaten entsteht ein spezifisches Compliance-Problem, das die meisten Unternehmen erst dann entdecken, wenn ein Prüfer die richtige Frage stellt.
Bei der standardmässigen Cloud-Verschlüsselung verwaltet der Cloud-Anbieter die Schlüssel. Ihre Infrastruktur generiert sie, speichert sie und nutzt sie in Ihrem Namen. Dies bedeutet einige Dinge, die für die Compliance wichtig sind. Aufgrund einer rechtmässigen Regierungsanordnung kann ein in den USA ansässiger Cloud-Anbieter gezwungen werden, Ihr Schlüsselmaterial herauszugeben – und darf Ihnen möglicherweise nicht mitteilen, dass dies geschehen ist. Ein Verstoss gegen die Schlüsselverwaltungsinfrastruktur des Cloud-Anbieters ist praktisch gesehen ein Verstoss gegen Ihre verschlüsselten Daten. Und Sie haben keine unabhängige Möglichkeit, zu überprüfen, ob Ihre Verschlüsselung nicht stillschweigend umgangen wurde.
Vom Kunden verwaltete Schlüssel (Customer-Managed Keys, CMK) stellen eine Verbesserung dar – sie geben Ihnen die Kontrolle über Schlüsselrichtlinien, Rotationspläne und Zugriffsbedingungen. Das Schlüsselmaterial selbst befindet sich jedoch immer noch in der Infrastruktur des Cloud-Anbieters. Sie vertrauen einem Dritten die Wurzel Ihrer kryptografischen Vertrauenskette an und sind gemäss DORA verpflichtet, die ständige Aufsicht über diesen Dritten nachzuweisen.
Für die meisten Datenkategorien ist dieser Kompromiss akzeptabel. Bei sensiblen Finanzdaten – Karteninhaberdaten, persönliche Finanzinformationen, Transaktionshistorien – erwarten die EU-Regulierungsbehörden zunehmend mehr. Die Richtung der regulatorischen Massnahmen geht in Richtung Verschlüsselungsschlüsselmaterial, das das Finanzinstitut tatsächlich kontrolliert, und nicht in Bezug auf Schlüsselrichtlinien, die auf Schlüssel angewendet werden, die ein Cloud-Anbieter in Ihrem Namen verwahrt.
Die Kluft zwischen verschlüsselt und tatsächlich sicher beruht auf einer Frage: Wer besitzt die Schlüssel?
Betrachten Sie eine typische Cloud-Architektur für Finanzdienstleistungen. Kundenfinanzdaten in AWS S3, verschlüsselt mit vom Kunden verwalteten KMS-Schlüsseln. Transaktionsdaten in Azure SQL, verschlüsselt über Azure Key Vault. Die Kartenverarbeitung wird von einem externen Zahlungsabwickler abgewickelt. Mitarbeiter greifen über SaaS-Anwendungen mit vom Anbieter verwalteter Verschlüsselung auf alle oben genannten Funktionen zu.
In diesem Bild verfügen jeweils drei verschiedene Cloud-Anbieter über Schlüsselmaterial für unterschiedliche Bereiche Ihrer Finanzdaten. Ihre Möglichkeit, den Zugriff zentral zu widerrufen – im Falle eines Verstosses, einer behördlichen Anordnung oder einer Entscheidung, einen Anbieter zu verlassen – ist fragmentiert. Ihr Audit-Trail ist auf drei separate Anbieterkonsolen aufgeteilt. Und Ihre Compliance-Position hängt davon ab, dass jeder Anbieter unabhängig die von Ihnen vorausgesetzten Sicherheitskontrollen aufrechterhält.
Das ist die Lücke bei der Schlüsselverwaltung: Verschlüsselung ist überall vorhanden, aber die Schlüsselkontrolle ist verstreut, unvollständig und effektiv an Anbieter delegiert, die Sie nicht unbedingt im Hinblick auf diese Konsequenz ausgewählt haben.
Die direkte Antwort auf die Schlüsselverwaltungslücke ist eine externe Schlüsselverwaltungsarchitektur: Ihr kryptografisches Schlüsselmaterial befindet sich vollständig ausserhalb der Infrastruktur eines Cloud-Anbieters, in einem System, das Ihr Unternehmen besitzt und kontrolliert. Cloud-Anbieter führen weiterhin Verschlüsselungsvorgänge durch – Sie ersetzen sie nicht –, können jedoch ohne einen autorisierten Anruf bei Ihrem externen Schlüsselmanager nicht auf das Schlüsselmaterial zugreifen.
Diese Architektur erfüllt die sich überschneidenden Anforderungen von DORA, NIS2 und Schrems II durch eine einzige Designentscheidung. Die Schlüsselsouveränität ist gewährleistet, da sich die Schlüssel in Ihrer Infrastruktur befinden. Der Widerruf des Zugriffs erfolgt real und sofort – schalten Sie Ihren externen Schlüsselmanager offline und alle Cloud-Verschlüsselungsvorgänge, die diese Schlüssel verwenden, werden gestoppt. Ein zentralisierter Prüfpfad wird möglich, da jedes wichtige Nutzungsereignis bei jedem Cloud-Anbieter durch ein einziges System fliesst. Und die Anforderungen von DORA an das Risiko Dritter lassen sich wesentlich einfacher erfüllen, wenn Sie der Hauptverwahrer sind und nicht der Anbieter, den Sie beaufsichtigen müssen.
Die technische Integration nutzt Protokolle, die die grossen Cloud-Anbieter bereits unterstützen: AWS KMS External Key Store (XKS), Azure Key Vault Managed HSM mit HYOK und GCP Cloud KMS mit EKMS. Jedes ermöglicht dem jeweiligen Cloud-Anbieter die Durchführung kryptografischer Vorgänge unter Verwendung von Schlüsselmaterial, das niemals Ihre Obhut verlässt.
Die herkömmliche HSM-basierte externe Schlüsselverwaltung löst das Verwahrungsproblem des Cloud-Anbieters, bringt jedoch ein anderes mit sich: Der vollständige Schlüssel existiert als einzelnes Geheimnis an einem einzigen Ort. Eine physische Gefährdung dieses Standorts, eine Insider-Bedrohung mit ausreichendem Zugang oder eine rechtmässige Zwangsverfügung, die auf dieses bestimmte System abzielt, sind allesamt glaubwürdige Angriffsvektoren, gegen die sich ein einzelnes HSM nicht wehren kann.
Multi-Party Computation eliminiert diesen Single Point of Failure auf der kryptografischen Ebene. Bei der MPC-basierten Schlüsselverwaltung existiert nirgendwo ein vollständiger Schlüssel – weder in einem einzelnen Gerät, nicht in einer einzelnen Gerichtsbarkeit, nicht in den Händen eines einzelnen Administrators. Kryptografische Operationen werden gemeinsam über verteilte Schlüsselanteile ausgeführt, von denen jeder für sich genommen mathematisch nutzlos ist. Für den Erfolg einer wichtigen Operation muss eine Mindestzahl autorisierter Parteien teilnehmen.
In der Praxis bedeutet dies, dass für den unbefugten Schlüsselzugriff die gleichzeitige Kompromittierung mehrerer unabhängiger Systeme erforderlich ist. Ein Insider-Bedrohungsszenario erfordert eine Absprache zwischen Parteien, die sich möglicherweise nicht kennen. Eine auf einen Standort gerichtete staatliche Zwangsverfügung führt zu einem unvollständigen Schlüsselanteil, der nichts ermöglicht. Für Finanzdienstleistungen bietet das MPC-basierte Schlüsselmanagement den stärksten verfügbaren Schutz sowohl gegen technische Angriffe als auch gegen regulatorische Zwänge – und es ist die Architektur, die anspruchsvolle Interpretationen der IKT-Risikoanforderungen von DORA am glaubwürdigsten erfüllt.
Die Finanzdienstleistungsverschlüsselung von DuoKey basiert auf MPC. Es ist kein Add-on; Es ist die grundlegende Architektur. Das Ergebnis ist eine externe Schlüsselverwaltung ohne das verbleibende Single-Point-of-Exposure-Risiko, das herkömmliche HSM-Lösungen mit sich bringen.
Einige Dinge stellen die eigentlichen Grunderwartungen für die regulierte Finanzdatenspeicherung im Jahr 2026 dar, unabhängig davon, welchen spezifischen Schlüsselverwaltungsansatz Sie verfolgen.
Beginnen Sie mit der Datenklassifizierung. Nicht alle Finanzdaten weisen die gleiche regulatorische Sensibilität auf. Für Karteninhaberdaten gemäss PCI DSS, persönliche Finanzdaten gemäss DSGVO und betriebliche Telemetrie gelten deutlich unterschiedliche Schutzanforderungen. Die Klassifizierung fordert die Auswahl geeigneter Kontrollen und erleichtert die Vorlage von Compliance-Nachweisen, wenn Prüfer dies verlangen.
Verschlüsseln Sie alles während der Übertragung und im Ruhezustand, ohne Ausnahmen für den Datenverkehr, den Sie als intern betrachten. Sowohl PCI DSS 4.0.1 als auch DORA betrachten dies als nicht verhandelbar. TLS 1.2 mindestens für Daten während der Übertragung, AES-256 für Daten im Ruhezustand. Organisationen unter NIS2 sollten die technischen Leitlinien der ENISA vom Juni 2025 lesen – einige zuvor informelle Normen sind jetzt explizit.
Konsolidieren Sie die Schlüsselverwaltung über mehrere Cloud-Anbieter hinweg, anstatt separate Schlüsselhierarchien pro Umgebung zu verwalten. Eine fragmentierte Schlüsselverwaltung führt zu Prüfungskomplexität, Compliance-Risiken und betrieblicher Fragilität. Ein zentralisierter externer Schlüsselmanager, der mit allen grossen Cloud-Anbietern integriert ist, bietet Ihnen den einzigen, konsistenten Prüfpfad, den die Aufsichtsbehörden tatsächlich sehen möchten.
Planen Sie kryptografische Agilität. DORA, NIS2 und die Post-Quantum-Roadmap der EU NIS Cooperation Group (die die Umstellung von Hochrisiko-Finanzsystemen auf PQC bis 2030 vorsieht) gehen alle davon aus, dass sich kryptografische Standards weiterentwickeln werden. Gestalten Sie Ihre Schlüsselverwaltungsinfrastruktur jetzt so, dass sie algorithmusunabhängig ist, bevor quantenbezogener Regulierungsdruck in Kraft tritt.
Testen Sie die Widerstandsfähigkeit Ihrer kryptografischen Infrastruktur, nicht nur Ihrer Anwendungen. Die Anforderungen von DORA an Resilienztests erstrecken sich auch auf wichtige Managementsysteme. Es werden jährliche Penetrationstests und regelmässige Failover-Übungen erwartet, und die Aufsichtsbehörden werden Beweise einholen.
Schlüsselverwahrung ordnungsgemäss dokumentieren. Die PCI DSS-Anforderung 3.7 erfordert formelle Depotbankaufzeichnungen und definierte Verfahren für die Schlüsselgenerierung, -verteilung, -speicherung, -entsorgung und -vernichtung. Diese Dokumentation gehört zu den ersten Dingen, die Prüfer verlangen, und Organisationen, die sie unter Prüfungsdruck improvisieren, machen keinen guten Eindruck.
DuoKey löst das Problem der Finanzdatenspeicherung auf der Ebene, die am wichtigsten ist: die kryptografische Schlüsselkontrolle, die Ihr Unternehmen tatsächlich besitzt.
Die Plattform bietet Verschlüsselung für sensible Finanzdaten in Cloud-Umgebungen – strukturierte Daten in Cloud-Datenbanken, unstrukturierte Daten im Objektspeicher, von Cloud-nativen Anwendungen verarbeitete Daten – mit Schlüsseln, die niemals die vom Kunden kontrollierte Infrastruktur verlassen. Da DuoKey MPC anstelle eines herkömmlichen HSM verwendet, gibt es kein einzelnes Gerät, das kompromittiert werden könnte, keinen einzelnen Administrator mit vollständigem Schlüsselzugriff und keinen einzelnen Standort, der Ziel einer Zwangsverfügung sein könnte.
DuoKey lässt sich über XKS, Azure Key Vault und GCP EKMS in AWS KMS integrieren, sodass Finanzinstitute eine zentrale Schlüsselkontrolle in heterogenen Cloud-Umgebungen aufrechterhalten können, ohne die vorhandene Infrastruktur zu ersetzen oder Anwendungen zu ändern. Verschlüsselungs- und Entschlüsselungsvorgänge erfolgen innerhalb der vorhandenen API-Oberfläche des Cloud-Anbieters. Die Schlüsselverwaltungsschicht ist für Workloads transparent.
Die Compliance-Vorteile sind architektonischer Natur und nicht nur dokumentiert. Die wichtigsten Souveränitäts- und Aufsichtsanforderungen von DORA durch Dritte werden durch das Design selbst berücksichtigt. Die Schrems-II-Zugriffssperrfunktion ist integriert. PCI-DSS-Split-Knowledge-Anforderungen werden durch das Key-Share-Modell von MPC erfüllt. Und der zentralisierte Prüfpfad über alle Cloud-Umgebungen hinweg vereinfacht die von Aufsichtsbehörden und Prüfern geforderte Beweissammlung.
| Verordnung | Was es für die Datenspeicherung benötigt | Wie die externe Schlüsselverwaltung das Problem behebt |
|---|---|---|
| DORA | Schlüsselmaterial unter der Kontrolle des Finanzunternehmens; Aufsicht durch Dritte; Resilienztests | Schlüsselverwahrung extern; Cloud-Anbieter hat keinen Zugriff; MPC reduziert das Single-Point-of-Failure-Risiko |
| NIS2 | Verschlüsselung als Risikomanagementmassnahme; Modernste technische Steuerungen | AES-256-Verschlüsselung mit externer Schlüsselverwahrung; im Einklang mit den Leitlinien der ENISA vom Juni 2025 |
| DSGVO / Schrems II | Möglichkeit zum Widerruf des Zugriffs; Cloud-Anbieter hat keinen Zugriff auf personenbezogene Daten | Sofortiger Kill-Switch über externen Schlüsselmanager; Kein wichtiges Material zur Cloud-Anbieter-Infrastruktur |
| PCI DSS 4.0.1 | Geteiltes Wissen / doppelte Kontrolle für Schlüsselverschlüsselungsschlüssel; dokumentierte Verwahrung | MPC-Schlüsselfreigaben unterstützen die Aufteilung von Wissen durch Design; vollständige Audit-Protokollierung |
| FINMA | Souveränität der Cloud-Daten; operationelles Risikomanagement | Zentralisierte externe Schlüsselkontrolle mit Schweizer Datenresidenzoptionen |
Dabei handelt es sich um eine Reihe von Kontrollen, die Finanzdaten – Karteninhaberdaten, Transaktionsdaten und persönliche Finanzinformationen – schützen, wenn sie in Cloud-Umgebungen gespeichert werden. Die wichtigste Ebene ist die Verschlüsselung in Kombination mit echter Schlüsselkontrolle: Sie stellt sicher, dass auf verschlüsselte Daten nicht zugegriffen werden kann, selbst wenn der zugrunde liegende Speicher kompromittiert ist oder der Cloud-Anbieter einer rechtlichen Anordnung unterliegt.
Für die sensibelsten Finanzdatenkategorien gilt im Allgemeinen Nein. Wenn ein Cloud-Anbieter Ihre Schlüssel verwaltet, delegieren Sie die Schlüsselverwahrung an einen Dritten, den Sie gemäss DORA beaufsichtigen müssen. Die externe Schlüsselverwaltung ist die Architektur, die DORAs Ziel einer sinnvollen Schlüsselkontrolle am glaubwürdigsten erfüllt.
Bring Your Own Key (BYOK) bedeutet, dass Sie den Schlüssel generieren und ihn in die Schlüsselverwaltungsinfrastruktur des Cloud-Anbieters importieren, wo dieser ihn verwahrt. Hold Your Own Key (HYOK) bedeutet, dass der Schlüssel niemals Ihre Infrastruktur verlässt – der Cloud-Anbieter ruft Ihren externen Schlüsselmanager an, wann immer er eine kryptografische Operation durchführen muss.
Es fügt einen Roundtrip für kryptografische Vorgänge hinzu, aber in der Praxis sind die Auswirkungen auf finanzielle Arbeitslasten oft minimal. Da Cloud-Dienste Datenverschlüsselungsschlüssel zwischenspeichern, müssen nicht für jeden einzelnen Datensatzzugriff externe Schlüsselmanager aufgerufen werden.
Ein HSM speichert den vollständigen Schlüssel in einem einzigen manipulationssicheren Gerät. MPC verteilt wichtige Freigaben auf mehrere unabhängige Systeme, sodass keine einzelne Freigabe Operationen alleine ausführen kann. Für Finanzinstitute bedeutet dies eine wesentliche Verbesserung sowohl der Sicherheitslage als auch der regulatorischen Vertretbarkeit.
Nicht mit Namen. Aber DORA, NIS2 und Schrems II wecken Compliance-Erwartungen, die durch externes Schlüsselmanagement wirkungsvoll und glaubwürdig erfüllt werden können – insbesondere im Hinblick auf die Schlüsselsouveränität, die Einschränkung des Zugriffs von Cloud-Anbietern und die Möglichkeit, den Zugriff sofort zu widerrufen.
Finanzdaten in der Cloud sind sicher, wenn zwei Bedingungen tatsächlich erfüllt sind: starke Verschlüsselung und Schlüsselmaterial unter der tatsächlichen Kontrolle des Finanzinstituts – nicht an einen Cloud-Anbieter delegiert. Im Jahr 2026, wenn DORA und PCI DSS 4.0.1 in vollem Umfang in Kraft treten und die Durchsetzung von NIS2 beschleunigt wird, ist die Erfüllung dieser Bedingungen die regulatorische Erwartung und kein Wettbewerbsvorteil.
Institutionen, die sich damit befassen, bauen nun eine Compliance-Architektur auf, die der Prüfung standhält. Diejenigen, die aufschieben, neigen dazu, herauszufinden, was die Nachrüstung von Verschlüsselungskontrollen unter Prüfungsdruck tatsächlich kostet – was deutlich mehr ist, als die Architektur von Anfang an richtig zu machen.
Geschrieben von
DuoKey Team
Ähnliche Ressourcen
Sagen Sie uns, wo Kontrolle heute schwierig ist. Wir helfen Ihnen, den nächsten praktischen Schritt zu finden.
