[{"data":1,"prerenderedAt":729},["ShallowReactive",2],{"home-/de":3,"whitepapers-de":176},{"id":4,"title":5,"body":6,"brand":12,"compliance":13,"description":5,"docs":17,"extension":29,"faq":30,"footer":53,"hero":59,"locale":67,"meta":68,"navigation":69,"path":70,"pocPage":71,"seo":72,"services":73,"servicesDetail":96,"stem":146,"switchPage":71,"trustPage":71,"trustTeaser":147,"useCases":152,"__hash__":175},"content/de/index.md","",{"type":7,"value":8,"toc":9},"minimark",[],{"title":5,"searchDepth":10,"depth":10,"links":11},2,[],"Alcazarix",{"eyebrow":14,"title":15,"body":16},"Compliance","Für rechtliche Kontrolle entwickelt – nicht nur für Verschlüsselung","Alcazarix ermöglicht echtes externes Schlüsseleigentum, indem Erzeugung, Speicherung und Governance von Verschlüsselungsschlüsseln von der Hyperscaler-Infrastruktur getrennt werden – sodass kein einzelnes Unternehmen und keine einzelne Jurisdiktion sowohl Ihre Daten als auch die zugehörigen Schlüssel kontrolliert. Diese architektonische Trennung hilft Unternehmen, Anforderungen aus Schrems II, DSGVO-Datensouveränität und grenzüberschreitenden Zugriffen zu erfüllen, ohne auf cloud-native Dienste zu verzichten.",{"eyebrow":18,"title":19,"body":20,"links":21},"Dokumentation","Alles, was Ihr Team für den Start benötigt","Strukturierte Anleitungen, Referenzdokumentationen und Migrationsleitfäden unterstützen Ihre Entwickler vom ersten Schlüssel bis zum vollständigen Rollout.",[22,25,27],{"label":23,"href":24},"API-Referenz","#",{"label":26,"href":24},"SDK-Anleitungen",{"label":28,"href":24},"Migrationsleitfäden","md",{"eyebrow":31,"title":32,"subtitle":33,"items":34},"FAQ","Fragen, die uns Sicherheitsteams stellen","Die Fragen aus jedem Architektur-Review – klar beantwortet.",[35,38,41,44,47,50],{"question":36,"answer":37},"Kann Alcazarix meine Daten lesen?","Nein. Alcazarix verwahrt Verschlüsselungsschlüssel und führt Schlüsseloperationen aus, Ihre Daten durchlaufen unsere Infrastruktur jedoch nie. Ihr Cloud-Anbieter hält Ihre verschlüsselten Daten, aber niemals Ihre Schlüssel. Keine Partei allein kann etwas entschlüsseln.",{"question":39,"answer":40},"Ist Alcazarix FIPS-140-zertifiziert?","Nein – und das ist eine bewusste Entscheidung, kein Versäumnis. Unsere HSM-gestützte Plattform konzentriert sich auf die Kontrollen, die bei externem Schlüsselmanagement wirklich entscheiden – Schlüsseleigentum, Zugriffssteuerung, Prüfbarkeit und Resilienz – ohne die Kosten und Starrheit einer FIPS-Zertifizierung. Wenn Ihr Beschaffungsprozess zwingend FIPS-zertifizierte Schlüsselverwahrung verlangt, sind wir möglicherweise nicht die richtige Wahl – und das sagen wir Ihnen frühzeitig.",{"question":42,"answer":43},"Wie verhält sich Ihre Struktur zu Gesetzen wie dem US CLOUD Act?","Wir beschreiben unsere Unternehmens- und Betriebsstruktur präzise und faktisch – welche Rechtsträger existieren, wem sie gehören und was jeder kontrolliert – auf unserer Seite zu Vertrauen & Verwahrung. Unser Custody-Dossier stellen wir Ihrer Rechtsabteilung unter NDA zur Verfügung. Wir treffen keine kategorischen rechtlichen Aussagen in Ihrem Namen; wir liefern Ihrem Legal-Team die Fakten für eine eigene Bewertung.",{"question":45,"answer":46},"Was passiert mit meinen Schlüsseln, wenn Alcazarix den Betrieb einstellt?","Die Schlüsselverwahrung läuft auf redundanter, HSM-gestützter Infrastruktur, die von getrennten Rechtsträgern in getrennten Jurisdiktionen betrieben wird, und Sie können Schlüssel jederzeit rotieren oder widerrufen. Dokumentierte Kontinuitäts- und Exit-Verfahren sind Teil unseres Onboardings – fragen Sie während Ihrer Evaluierung nach der Kontinuitätsdokumentation.",{"question":48,"answer":49},"Wir nutzen heute Thales DPoD oder Fortanix DSM. Wie aufwendig ist der Wechsel?","Mehrere unserer Kunden haben genau diesen Wechsel vollzogen. Wir bieten Architektur-Review, einen Migrationsplan für das Re-Wrapping oder die Rotation von Schlüsseln auf Alcazarix-Verwahrung sowie einen kostenlosen 30-Tage-Proof-of-Concept, damit Sie die Integration vor einer Entscheidung validieren können.",{"question":51,"answer":52},"Was kostet das?","Die Preise sind nutzungsbasiert und transparent – keine Appliance-Zählung, keine Kapazitätsstufen, keine Suite-Bündelung. Kontaktieren Sie den Vertrieb für ein Angebot oder starten Sie mit dem kostenlosen 30-Tage-Proof-of-Concept.",{"copyright":54,"email":55,"address":56},"© 2026 Alcazarix, Inc","hello@alcazarix.com",[57,58],"Alcazarix B.V.","Coolsingel 65, Floor 5, 3012 AC Rotterdam, Netherlands",{"eyebrow":60,"title":61,"subtitle":62,"ctaPrimary":63,"ctaSecondary":64,"metaPrimary":65,"metaSecondary":66},"Unabhängige Schlüsselverwahrung","Unabhängige Schlüsselverwahrung für die Cloud.","Alcazarix verwahrt die Verschlüsselungsschlüssel, die Ihre Daten schützen, außerhalb der Reichweite Ihres Cloud-Anbieters. HSM-gestützte, rechtlich getrennte Schlüsselverwahrung, nativ integriert mit AWS KMS, Azure Key Vault und Google Cloud KMS.","Vertrieb kontaktieren","Mit einem Architekten sprechen","Unabhängig von jedem Cloud-Anbieter","AWS · Azure · Google Cloud","de",{},true,"/de",null,{"description":5},{"eyebrow":74,"title":75,"subtitle":76,"items":77},"Warum Alcazarix","Ihre Cloud sollte nicht Ihre Daten und Ihre Schlüssel halten","Alcazarix ist ein unabhängiger Key Broker. Wir verwahren und verwalten Verschlüsselungsschlüssel – ohne Cloud-Geschäft, ohne Appliance-Geschäft, ohne ausufernde Security-Suite. Nur Verwahrung, die Sie überprüfen können.",[78,81,84,87,90,93],{"title":79,"body":80},"Unabhängig per Architektur","Ihr Cloud-Anbieter speichert verschlüsselte Daten, aber niemals Ihre Schlüssel. Alcazarix verwahrt Ihre Schlüssel, aber niemals Ihre Daten. Keine Partei allein kann irgendetwas lesen.",{"title":82,"body":83},"Nativ für AWS, Azure und Google Cloud","Direkte Integration mit AWS KMS External Key Store (XKS), Azure Key Vault Managed HSM BYOK und Google Cloud KMS EKM. Keine Anwendungsänderungen und keine Schlüsselhandhabung in Ihrem Code.",{"title":85,"body":86},"Rechtliche Trennung, schriftlich belegt","Die Schlüsselverwahrung wird von getrennten Rechtsträgern betrieben – von Alcazarix, Inc. aus Rechenzentren in Kanada für Nordamerika und von der eigenständigen Alcazarix Europe B.V. aus Rechenzentren in Deutschland für Europa. Unsere Seite zu Vertrauen & Verwahrung zeigt genau, wer was besitzt und kontrolliert.",{"title":88,"body":89},"Eine fokussierte Alternative zu etablierten Anbietern","Teams wechseln von Thales DPoD und Fortanix DSM zu Alcazarix – wegen transparenter, nutzungsbasierter Preise und eines Produkts, das eine Sache richtig macht, ohne sehr hohe Preise für ein Funktionspaket zu zahlen, das sie nicht benötigen.",{"title":91,"body":92},"Für regulierte Teams entwickelt","Healthcare- und Clinical-Trial-Plattformen, Finanzdienstleister unter DORA und jedes SaaS-Unternehmen mit EU-Kunden. Erfüllen Sie die Erwartungen von Regulierern und Unternehmenskunden, ohne die Entwicklung auszubremsen.",{"title":94,"body":95},"Kontrollen auf Enterprise-Niveau","An SOC 2 Type II und ISO 27001 ausgerichtete Sicherheitskontrollen, HSM-gestützte Schlüsselerzeugung, detaillierte Audit-Trails, rollenbasierte Zugriffskontrolle und SLA-gestützte Verfügbarkeit.",{"eyebrow":97,"title":98,"intro":99,"items":100},"Leistungen","Verwaltete Schlüsselverwahrung mit Schlüsseln in Ihrem Eigentum","Alcazarix bietet unabhängige Schlüsselverwahrung als Managed Service und ermöglicht Kunden, das vollständige Eigentum und die Kontrolle über die in Cloud-Umgebungen verwendeten Verschlüsselungsschlüssel zu behalten.",[101,109,116,124,132,140],{"title":102,"description":103,"features":104},"Kundenseitig kontrollierte Schlüsselverwaltung","Alcazarix betreibt einen hochverfügbaren, HSM-gestützten Schlüsselverwaltungsdienst, der sich direkt in die KMS-Plattformen der Cloud-Anbieter integriert und Ihre Schlüssel vollständig unter Ihrer Kontrolle hält.",[105,106,107,108],"HSM-generierte und -geschützte Hauptschlüssel","Sichere Schlüsselspeicherung und Verwaltung des Schlüssellebenszyklus","Aktivierung, Rotation, Sperrung und Widerruf von Schlüsseln","Kundendefinierte Zugriffs- und Governance-Kontrollen",{"title":110,"description":111,"features":112},"Cloud-KMS-Integrationen","Native BYOK-Unterstützung für führende Cloud-Anbieter mit rechtlich isolierten Schlüsseloperationen.",[113,114,115],"Kompatibilität mit AWS KMS External Key Store (XKS)","Azure Key Vault Managed HSM BYOK","Integration mit Google Cloud KMS EKM",{"title":117,"description":118,"features":119},"Governance & Prüfbarkeit","Alcazarix bietet die für regulierte Umgebungen erforderliche Transparenz und Kontrolle.",[120,121,122,123],"Detaillierte Protokolle der Schlüsselnutzung","Prüfung administrativer Aktionen","Rollenbasierte Zugriffskontrolle","Exportierbare Audit-Daten für Compliance-Prüfungen",{"title":125,"description":126,"features":127},"Hochverfügbarkeit & Resilienz","Unser Service ist auf die Verfügbarkeitsanforderungen cloud-nativer Workloads ausgelegt.",[128,129,130,131],"Redundante HSM-gestützte Infrastruktur","Optionen zur geografischen Trennung","Fehlertolerante Architektur für den Schlüsselzugriff","SLA-gestützte Verfügbarkeit",{"title":133,"description":134,"features":135},"Einführung & Unterstützung","Wir arbeiten direkt mit den Sicherheits- und Plattformteams unserer Kunden zusammen, um eine reibungslose Bereitstellung sicherzustellen.",[136,137,138,139],"Architekturprüfung und Integrationsberatung","Unterstützung bei der BYOK-Konfiguration","Migrationsunterstützung von Thales DPoD und Fortanix DSM","Direkter Zugang zu technischen Experten",{"title":141,"description":142,"features":143},"Schlüsselverwahrung","Schlüsselverwaltungsinfrastruktur und dedizierte API für Schlüsseloperationen im Eigentum getrennter Rechtsträger.",[144,145],"Schlüsselverwahrung für Nordamerika in Alcazarix-Rechenzentren in Kanada unter der Kontrolle von Alcazarix, Inc.","Schlüsselverwahrung für Europa in Alcazarix-Rechenzentren in Deutschland unter der Kontrolle der eigenständigen Alcazarix Europe B.V.","de/index",{"eyebrow":148,"title":149,"body":150,"cta":151},"Vertrauen & Verwahrung","Wer verwahrt Ihre Schlüssel wirklich?","Verwahrung ist bei Alcazarix eine Eigentumsarchitektur, kein Versprechen – getrennte Rechtsträger, getrennte Jurisdiktionen und Kontrollgrenzen, die Sie Ihrer Rechtsabteilung vorlegen können.","So funktioniert die Verwahrung",{"eyebrow":153,"title":154,"subtitle":155,"items":156},"Anwendungsfälle","Ein Verwahrer, viele Gründe für eigene Schlüssel","Wo auch immer Ihre Daten in AWS, Azure oder Google Cloud liegen – unabhängige Schlüsselverwahrung macht aus Verschlüsselung echte Kontrolle statt einer Checkbox.",[157,160,163,166,169,172],{"title":158,"body":159},"Bieten Sie Ihren Kunden Schlüsseleigentum an","Ihre Unternehmenskunden verlangen CMEK oder BYOK, bevor sie unterschreiben. Liefern Sie es über Alcazarix, statt selbst eine Schlüsselverwaltung aufzubauen – Ihre Kunden besitzen ihre Schlüssel, Ihr Team liefert weiter Produkt.",{"title":161,"body":162},"Europäische Datensouveränität","Machen Sie EU-Personendaten auf US-Clouds verteidigungsfähig. Schlüssel, die in Deutschland von einem eigenständigen europäischen Rechtsträger verwahrt werden, geben Ihrer Schrems-II- und DSGVO-Argumentation einen konkreten technischen und rechtlichen Anker.",{"title":164,"body":165},"Cloud-Exit & Konzentrationsrisiko","Aufsichtsbehörden erwarten zunehmend glaubwürdige Cloud-Exit-Pläne. Extern verwahrte Schlüssel sind eine Kontrolle, auf die Sie im Audit verweisen können – und stilles Verhandlungsgewicht bei jeder Vertragsverlängerung.",{"title":167,"body":168},"Incident Response & Crypto-Shredding","Widerrufen Sie Schlüsselzugriffe in Minuten und machen Sie Cloud-Daten bei einem Sicherheitsvorfall oder Anbieterstreit unlesbar. Löschen Sie Daten endgültig durch kryptografische Vernichtung, die DSGVO-Löschpflichten unterstützt.",{"title":170,"body":171},"KI, ohne Ihre Daten aufzugeben","Trainingsdaten, Vektordatenbanken und Inferenz-Logs bleiben Ihre Daten. Halten Sie sie unter Schlüsseln verschlüsselt, die Ihre KI- und Cloud-Anbieter niemals besitzen.",{"title":173,"body":174},"Eine Schlüsselautorität über alle Clouds","Ersetzen Sie drei unterschiedliche native KMS-Konfigurationen durch einen Verwahrer, ein Richtlinienmodell und einen Audit-Trail über AWS, Azure und Google Cloud hinweg.","EyOg0I5jSF38CHC5vQmUcHFiblw7NPAsNXvLldV3vK0",[177,350,541],{"id":178,"title":179,"body":180,"category":339,"description":340,"extension":29,"locale":67,"meta":341,"navigation":69,"path":342,"pdf":343,"preview":344,"rank":345,"seo":346,"slug":347,"stem":348,"__hash__":349},"whitepapers/de/whitepapers/schrems-ii-byok.md","Schrems II und BYOK: Ein Leitfaden zur Sicherheitsarchitektur für Plattformen für klinische Prüfungen",{"type":7,"value":181,"toc":329},[182,187,191,194,198,201,204,207,210,214,217,220,223,226,230,233,236,239,242,245,248,251,255,258,261,264,267,270,274,277,280,283,286,289,292,295,299,302,305,308,311,315,318,321],[183,184,186],"h2",{"id":185},"zusammenfassung","Zusammenfassung",[188,189,190],"p",{},"Das Schrems-II-Urteil hat die Bedingungen für die Übermittlung europäischer personenbezogener Daten in die USA dauerhaft verändert. Für Plattformen für klinische Prüfungen sind die Auswirkungen besonders gravierend, da Patientendaten zu den sensibelsten personenbezogenen Daten überhaupt gehören. Standardvertragsklauseln (SCC) bleiben ein gültiger Übermittlungsmechanismus, jedoch nur in Verbindung mit einer Übertragungswirkungsanalyse (Transfer Impact Assessment, TIA), die ein tatsächlich gleichwertiges Datenschutzniveau nachweist. Bei Daten, die auf US-Hyperscalern gehostet werden, ist dieser Nachweis ohne technische Kontrollen, die jeglichen Zugriff des Cloud-Anbieters verhindern, zunehmend schwer zu erbringen.",[188,192,193],{},"Bring Your Own Key (BYOK) ist heute die praktikabelste ergänzende technische Maßnahme für Plattformen für klinische Prüfungen. Bei korrekter Implementierung mit HSM-gestützten Schlüsseln außerhalb der Vertrauensgrenze des Hyperscalers stellt BYOK sicher, dass selbst eine rechtmäßige Zugriffsanordnung einer US-Behörde an den Cloud-Anbieter keine verwertbaren Daten liefert. Dieses Whitepaper erläutert die Schrems-II-Risikolage für Plattformen für klinische Prüfungen, die technischen Anforderungen an ein belastbares BYOK-Konzept und die praktische Ausgestaltung einer konformen Architektur.",[183,195,197],{"id":196},"_1-das-schrems-ii-urteil-und-seine-tatsächlichen-anforderungen","1. Das Schrems-II-Urteil und seine tatsächlichen Anforderungen",[188,199,200],{},"Im Juli 2020 erklärte der Gerichtshof der Europäischen Union (EuGH) im Verfahren Data Protection Commissioner gegen Facebook Ireland Limited und Maximillian Schrems (C-311/18) den EU-US Privacy Shield für ungültig. Das Gericht stellte fest, dass das US-Überwachungsrecht, insbesondere Section 702 des FISA und Executive Order 12333, US-Nachrichtendiensten Zugriff auf von US-Unternehmen verarbeitete personenbezogene Daten in einer Weise gewährt, die mit den Rechten betroffener Personen in der EU auf gerichtlichen Rechtsschutz unvereinbar ist.",[188,202,203],{},"Die Standardvertragsklauseln wurden nicht für ungültig erklärt. Das Gericht stellte jedoch ausdrücklich klar: SCC sind nur dann ein gültiger Übermittlungsmechanismus, wenn der Datenimporteur die darin enthaltenen vertraglichen Schutzmaßnahmen tatsächlich erfüllen kann. Stehen dem die Gesetze des Ziellandes entgegen – wie das US-Überwachungsrecht bei Daten von US-Cloud-Anbietern –, reichen SCC allein nicht aus.",[188,205,206],{},"Der Europäische Datenschutzausschuss (EDSA) veröffentlichte im November 2020 die Empfehlungen 01/2020. Diese formalisierten die Anforderung einer TIA und führten ergänzende Maßnahmen auf, mit denen sich eine auf SCC gestützte Übermittlung rechtfertigen lässt. Entscheidend ist, dass der EDSA technische Maßnahmen benannte – insbesondere eine Verschlüsselung, bei der allein der Datenexporteur die Schlüssel kontrolliert –, durch die Daten für den Importeur „unzugänglich“ und damit selbst unter US-Überwachungsrecht wirksam geschützt werden können.",[188,208,209],{},"In der Praxis bedeutet dies: Plattformen, die Patientendaten aus dem EWR auf US-Hyperscalern verarbeiten, müssen nachweisen können, dass der Cloud-Anbieter selbst auf behördliche Anordnung nicht auf die Daten im Klartext zugreifen kann. Mit korrekt implementiertem BYOK lässt sich dieser Nachweis erbringen.",[183,211,213],{"id":212},"_2-warum-daten-klinischer-prüfungen-besonders-risikobehaftet-sind","2. Warum Daten klinischer Prüfungen besonders risikobehaftet sind",[188,215,216],{},"Nicht alle personenbezogenen Daten weisen dasselbe Schrems-II-Risikoprofil auf. Daten klinischer Prüfungen liegen aus zwei sich verstärkenden Gründen am oberen Ende des Risikospektrums.",[188,218,219],{},"Erstens handelt es sich bei Daten klinischer Prüfungen um besondere Kategorien personenbezogener Daten nach Artikel 9 DSGVO. Gesundheitsdaten, genetische und biometrische Daten unterliegen strengeren Verarbeitungsvoraussetzungen und höheren möglichen Bußgeldern. Ein Schrems-II-Verstoß mit Daten klinischer Prüfungen ist kein gewöhnlicher DSGVO-Vorfall: Dem Plattformbetreiber drohen nach Artikel 83 Absatz 5 Geldbußen von bis zu 20 Millionen Euro oder 4 % des weltweiten Jahresumsatzes.",[188,221,222],{},"Zweitens sind Daten klinischer Prüfungen operativ unersetzlich. Anders als eine kompromittierte Kundendatenbank lassen sie sich nicht einfach neu erzeugen; sie bilden die primäre Dokumentation einer Prüfung. Regulierungsbehörden, EMA, FDA und zuständige nationale Behörden stellen jahrzehntelange Archivierungs- und Zugriffsanforderungen. Jede Architekturentscheidung, welche die Datenintegrität oder -verfügbarkeit beeinträchtigt, hat regulatorische und klinische Folgen.",[188,224,225],{},"Die Kombination aus hoher regulatorischer Sensibilität, langen Aufbewahrungsfristen und grenzüberschreitenden Datenströmen – bei den meisten eClinical-SaaS-Anbietern werden EU-Patientendaten standardmäßig auf US-Plattformen verarbeitet – führt dazu, dass Plattformen für klinische Prüfungen stärker unter Schrems-II-Beobachtung stehen als nahezu jede andere SaaS-Kategorie.",[183,227,229],{"id":228},"_3-die-lücke-zwischen-scc-und-tia-und-wie-byok-sie-schließt","3. Die Lücke zwischen SCC und TIA – und wie BYOK sie schließt",[188,231,232],{},"Stützen Plattformen für klinische Prüfungen EU-US-Übermittlungen auf SCC, müssen sie in einer TIA realistisch bewerten, ob der US-Empfänger die zugesagten Schutzmaßnahmen erfüllen kann. Bei Daten auf großen US-Hyperscalern (AWS, Azure, Google Cloud) fällt die Antwort problematisch aus: Das US-Überwachungsrecht kann den Cloud-Anbieter zur Herausgabe zwingen, und technisch ist er dazu in der Lage, weil er bei einer standardmäßigen Cloud-KMS-Konfiguration die Verschlüsselungsschlüssel hält.",[188,234,235],{},"Diese Lücke schließt BYOK. Werden Verschlüsselungsschlüssel außerhalb der Kontrolle des Hyperscalers in einem von einem europäischen Rechtsträger betriebenen HSM verwahrt und die Zugriffe vom EU-Kunden gesteuert, kann der Hyperscaler selbst auf Anordnung keine verwertbaren Daten herausgeben. Er kann lediglich Chiffretext liefern. Der Schutz ist damit technisch wirksam und nicht nur vertraglich zugesichert.",[188,237,238],{},"Damit BYOK als wirksame ergänzende Maßnahme für Schrems II dient, müssen drei Bedingungen erfüllt sein:",[188,240,241],{},"Die Schlüsselgenerierung muss außerhalb des Hyperscalers erfolgen. In AWS KMS oder Azure Key Vault generierte Schlüssel liegen definitionsgemäß innerhalb seiner Vertrauensgrenze. Belastbares BYOK erfordert die Generierung in einem HSM, das der Hyperscaler weder betreibt noch erreichen kann.",[188,243,244],{},"Schlüsselspeicherung und Governance müssen rechtlich isoliert sein. Der Rechtsträger, der HSM und Schlüssellebenszyklus kontrolliert, muss europäischem Recht unterliegen und darf keine US-Muttergesellschaft haben, die nach US-Recht verpflichtet werden könnte. Dies ist eine rechtliche ebenso wie eine technische Anforderung.",[188,246,247],{},"Schlüsselzugriffe müssen protokolliert und kundenseitig kontrolliert werden. Damit eine TIA den verhinderten Zugriff des Cloud-Anbieters dokumentieren kann, muss ein Audit-Trail belegen, dass jede Schlüsselnutzung vom Kunden und nicht vom Cloud-Anbieter autorisiert wurde. Auch der Entzug des Zugriffs – also Schlüsselzugriffe zu sperren oder zu beenden und Daten unzugänglich zu machen – muss tatsächlich in der Kontrolle des Kunden liegen.",[188,249,250],{},"Eine standardmäßige, Hyperscaler-native Schlüsselverwaltung erfüllt diese Anforderungen nicht. Hierfür ist eine externe Schlüsselverwaltungsinfrastruktur erforderlich.",[183,252,254],{"id":253},"_4-architektur-der-cloud-kms-integration","4. Architektur der Cloud-KMS-Integration",[188,256,257],{},"Die großen Hyperscaler haben aufgrund dieses Marktbedarfs jeweils Integrationspunkte für extern verwaltete Schlüssel geschaffen:",[188,259,260],{},"AWS KMS External Key Store (XKS) ermöglicht AWS, Verschlüsselungsschlüssel eines externen Key Managers für KMS-Operationen zu verwenden. Der externe Key Manager führt die kryptografischen Operationen aus, ohne Schlüsselmaterial an AWS zu exportieren. AWS KMS sendet Wrap-/Unwrap-Anfragen an den externen Key Manager, der sie verarbeitet und das Ergebnis zurückgibt. Der Schlüssel verlässt das HSM nie.",[188,262,263],{},"Azure Key Vault Managed HSM BYOK ermöglicht Kunden, im eigenen HSM generiertes Schlüsselmaterial über ein Schlüsselaustauschprotokoll geschützt in Azure Key Vault Managed HSM zu importieren. Für strengste Schrems-II-Anwendungsfälle verbleibt das Schlüsselmaterial vorzugsweise in einem kundenseitig kontrollierten HSM; statt eines Imports in Azure-kontrollierte Infrastruktur werden externe Schlüsselmechanismen von Azure genutzt.",[188,265,266],{},"Google Cloud KMS External Key Manager (EKM) bindet einen externen Schlüsselverwaltungsdienst über eine REST API an. GCP sendet Schlüsselzugriffsanfragen an das externe KMS, das sie anhand kundendefinierter Richtlinien genehmigt oder ablehnt und die kryptografische Operation lokal ausführt.",[188,268,269],{},"Das Integrationsmodell ist stets dasselbe: Der Hyperscaler fordert kryptografische Operationen beim externen Key Manager an, statt sie mit selbst kontrollierten Schlüsseln auszuführen. Der Cloud-Anbieter erhält niemals Zugriff auf Schlüsselmaterial im Klartext.",[183,271,273],{"id":272},"_5-merkmale-einer-konformen-architektur","5. Merkmale einer konformen Architektur",[188,275,276],{},"Eine Schrems-II-belastbare Architektur für eine Plattform, die EWR-Patientendaten auf US-Hyperscalern verarbeitet, weist folgende Merkmale auf:",[188,278,279],{},"Ruhende Patientendaten werden mit Schlüsseln verschlüsselt, die ein für den Cloud-Anbieter unzugängliches externes KMS verwaltet. Das externe KMS wird von einem europäischen Rechtsträger auf europäischer Infrastruktur und unter europäischer Gerichtsbarkeit betrieben.",[188,281,282],{},"Schlüsseloperationen – Generierung, Rotation, Sperrung und Widerruf – werden vom Sicherheitsteam der Plattform ausgeführt oder auf Grundlage eines den Anforderungen von Artikel 28 DSGVO entsprechenden Auftragsverarbeitungsvertrags an einen Managed Service Provider delegiert.",[188,284,285],{},"Jeder Schlüsselzugriff wird so detailliert protokolliert, dass sich rekonstruieren lässt, wer wann mit welchem Schlüssel auf welche Daten zugegriffen hat. Die Protokolle sind exportierbar und für behördliche Prüfungen verfügbar.",[188,287,288],{},"Der Zugriffsentzug wird operativ getestet und dokumentiert. Die Plattform kann nachweisen, dass die Sperrung eines Schlüssels die zugehörigen Daten innerhalb eines definierten SLA unzugänglich macht und diese Fähigkeit praktisch getestet wurde.",[188,290,291],{},"Die TIA verweist auf die technische Architektur, insbesondere die rechtliche Trennung der Schlüsselverwaltung von der Cloud-Verarbeitung, als zentrale Grundlage für die Bewertung der Übermittlung als vertretbar.",[188,293,294],{},"Diese Architektur ersetzt weder SCC noch TIA. Sie macht die TIA belastbar.",[183,296,298],{"id":297},"_6-wie-alcazarix-schrems-ii-konformes-byok-unterstützt","6. Wie Alcazarix Schrems-II-konformes BYOK unterstützt",[188,300,301],{},"Alcazarix bietet Managed BYOK als speziell für Schrems II entwickelten Service. Unsere Schlüsselverwaltungsinfrastruktur wird für nordamerikanische Workloads von Alcazarix Canada und für EU-Workloads von Alcazarix Germany in europäischen Rechenzentren betrieben – durch getrennte Rechtsträger mit klaren rechtlichen Grenzen.",[188,303,304],{},"Wir integrieren nativ mit AWS KMS XKS, Azure Key Vault Managed HSM BYOK und Google Cloud KMS EKM. So können Plattformen für klinische Prüfungen BYOK ohne Änderungen an der Anwendungsebene mit ihrem bestehenden Cloud KMS einsetzen. Schlüssel werden in HSMs unter Kontrolle von Alcazarix generiert und mit kundendefinierten Zugriffs- und Governance-Richtlinien, vollständiger Verwaltung des Schlüssellebenszyklus und exportierbaren Audit-Protokollen verwaltet.",[188,306,307],{},"Für eClinical-SaaS-Anbieter unterstützen wir mandantenfähige Architekturen, in denen jeder Sponsor einer klinischen Prüfung eigene Schlüssel halten kann. Dadurch bleiben die Datensätze verschiedener Sponsoren auf Ebene der Schlüsselverwaltung isoliert – im Einklang mit der Erwartung der ICH E6(R3) GCP an die Datenkontrolle durch den Sponsor.",[188,309,310],{},"Alcazarix ist bewusst nicht FIPS-zertifiziert. Wir konzentrieren uns auf die für Schrems II entscheidenden Kontrollen: Schlüsseleigentum, rechtliche Isolierung, Zugriffs-Governance und Prüfbarkeit. So bleiben die Kosten deutlich unter denen etablierter HSM-Anbieter wie Thales oder Utimaco, ohne die technischen Schutzmaßnahmen zu beeinträchtigen, die eine TIA belastbar machen.",[183,312,314],{"id":313},"_7-fazit","7. Fazit",[188,316,317],{},"Schrems II ist keine Compliance-Checkbox, sondern ein dauerhafter Wandel bei der Architektur von EU-US-Datenübermittlungen. Für Plattformen für klinische Prüfungen mit höchst sensiblen Daten und erheblichen regulatorischen Risiken erfordert der Weg über SCC und TIA echte ergänzende technische Maßnahmen. BYOK mit HSM-gestützter externer Schlüsselverwaltung unter europäischer rechtlicher Kontrolle ist der direkteste Weg, diese wirksam umzusetzen.",[188,319,320],{},"Für Sicherheitsarchitekten lautet die entscheidende Frage bei der Bewertung der Schrems-II-Position ihrer Plattform nicht, ob SCC bestehen – das ist meist der Fall. Entscheidend ist, ob ihre TIA der Prüfung durch eine europäische Datenschutzbehörde standhalten würde. Liegen Ihre Verschlüsselungsschlüssel in einem vom Cloud-Anbieter verwalteten AWS KMS oder Azure Key Vault, lautet die ehrliche Antwort wahrscheinlich nein.",[188,322,323,324,328],{},"Weitere Informationen darüber, wie Alcazarix Schrems-II-konformes BYOK für Plattformen für klinische Prüfungen unterstützt, erhalten Sie unter ",[325,326,55],"a",{"href":327},"mailto:hello@alcazarix.com"," oder auf alcazarix.com.",{"title":5,"searchDepth":10,"depth":10,"links":330},[331,332,333,334,335,336,337,338],{"id":185,"depth":10,"text":186},{"id":196,"depth":10,"text":197},{"id":212,"depth":10,"text":213},{"id":228,"depth":10,"text":229},{"id":253,"depth":10,"text":254},{"id":272,"depth":10,"text":273},{"id":297,"depth":10,"text":298},{"id":313,"depth":10,"text":314},"DSGVO & Datensouveränität","Wie Plattformen für klinische Prüfungen Schrems-II-Übertragungswirkungsanalysen mit HSM-gestütztem BYOK und rechtlich isolierter Schlüsselverwaltung erfüllen können.",{},"/de/whitepapers/schrems-ii-byok","/whitepapers/Alcazarix_Whitepaper_Schrems_II_BYOK_Clinical_Trials.pdf","/whitepapers/preview_Schrems_II_BYOK_Clinical_Trials.png",10,{"title":179,"description":340},"schrems-ii-byok","de/whitepapers/schrems-ii-byok","i4JsVSQsJgiUNg6sp_3YVme5xI8gNBjNZg8LZ29D2lY",{"id":351,"title":352,"body":353,"category":530,"description":531,"extension":29,"locale":67,"meta":532,"navigation":69,"path":533,"pdf":534,"preview":535,"rank":536,"seo":537,"slug":538,"stem":539,"__hash__":540},"whitepapers/de/whitepapers/eu-ctr.md","EU-Verordnung über klinische Prüfungen und Datensouveränität: Was eClinical-SaaS-Unternehmen jetzt aufbauen müssen",{"type":7,"value":354,"toc":520},[355,357,360,363,366,370,373,376,379,382,385,388,391,395,398,401,404,407,410,414,417,420,423,426,429,432,435,439,442,445,448,451,454,457,461,464,467,470,473,476,479,482,486,489,492,495,498,501,504,506,509,512,515],[183,356,186],{"id":185},[188,358,359],{},"Die EU-Verordnung über klinische Prüfungen (CTR, Verordnung 536/2014) ist inzwischen vollständig anwendbar. Seit Januar 2025 müssen alle klinischen Prüfungen in der Europäischen Union über das Clinical Trials Information System (CTIS) eingereicht und verwaltet werden. Dieses zentrale EMA-Portal ersetzt 27 getrennte nationale Verfahren. Für eClinical-SaaS-Anbieter – darunter EDC-Systeme, Plattformen für elektronische Trial Master Files (eTMF), CTMS sowie IRT/RTSM-Lösungen – ist CTR-Compliance verpflichtend und umfasst eine von vielen Anbietern unterschätzte Dimension der Datenarchitektur.",[188,361,362],{},"Die CTR schreibt keine Verschlüsselungsstandards vor. Sie gilt jedoch im Rahmen der DSGVO, die dem Risiko angemessene technische Maßnahmen verlangt. Die in der Verordnung verankerten Erwartungen an Datensouveränität – einschließlich des Zugriffs zuständiger nationaler Behörden auf Anforderung – wirken sich unmittelbar darauf aus, wie Patientendaten gespeichert, verschlüsselt und kontrolliert werden. Zusammen mit dem ungelösten Konflikt zwischen den Übermittlungsvorgaben der DSGVO und dem US CLOUD Act entsteht für eClinical-SaaS-Unternehmen auf US-Hyperscalern ein strukturelles Problem: Ihre Architektur kann mit den durch die CTR begründeten Datenzugriffspflichten rechtlich unvereinbar sein.",[188,364,365],{},"Kundenseitig kontrollierte Verschlüsselung – konkret BYOK mit HSM-gestützter, rechtlich isolierter Schlüsselverwaltung – ist die architektonische Antwort auf diesen Konflikt. Dieses Whitepaper erläutert die Gründe und die Konsequenzen für Ihre Plattform.",[183,367,369],{"id":368},"_1-die-ctr-in-kraft-was-sich-2025-geändert-hat","1. Die CTR in Kraft: Was sich 2025 geändert hat",[188,371,372],{},"Die Verordnung (EU) Nr. 536/2014 ersetzte die Richtlinie 2001/20/EG. Zuvor mussten Sponsoren in jedem EU-Mitgliedstaat, in dem eine Prüfung stattfinden sollte, getrennte Genehmigungen der zuständigen Behörde und Ethikkommission einholen. Die CTR führte über CTIS ein einheitliches Antragsverfahren mit koordinierter Bewertung durch die Mitgliedstaaten und festgelegten Genehmigungsfristen ein.",[188,374,375],{},"Die Verordnung trat im Januar 2022 mit einer dreijährigen Übergangsfrist in Kraft. Seit Januar 2025 müssen alle neuen Prüfungen das CTIS-Verfahren nutzen; nach der alten Richtlinie genehmigte Prüfungen wurden migriert oder abgeschlossen.",[188,377,378],{},"Für eClinical-SaaS-Unternehmen ergeben sich aus der vollständigen Anwendbarkeit der CTR insbesondere folgende praktische Auswirkungen:",[188,380,381],{},"Über CTIS eingereichte Daten sind für alle relevanten zuständigen nationalen Behörden (NCA) und die EMA zugänglich. Dadurch entsteht ein föderiertes Datenzugriffsmodell, das sich grundlegend von den bilateralen Beziehungen zwischen Sponsor und Behörde unter der Richtlinie unterscheidet.",[188,383,384],{},"Prüfungsdaten müssen nach Abschluss der Prüfung mindestens 25 Jahre archiviert werden (Artikel 58). Diese Aufbewahrungspflicht gilt für das vollständige Dossier des Prüfpräparats, nicht nur für veröffentlichte Ergebnisse. eClinical-Plattformen, die als führende Systeme für Prüfungsdaten dienen, übernehmen diese Archivierungspflicht in ihrer Leistungskette.",[188,386,387],{},"Aufgrund der Transparenz- und Veröffentlichungspflichten nach Artikel 37 und 38 CTR müssen Prüfungsergebnisse einschließlich zusammenfassender Daten auf Patientenebene innerhalb festgelegter Fristen an CTIS übermittelt werden. Die Daten müssen in zugänglichen, maschinenlesbaren Formaten vorliegen.",[188,389,390],{},"Keine dieser Anforderungen ist rein technischer Natur. Jede hat jedoch Folgen für die Datenarchitektur: Wer darf unter welchen Bedingungen auf welche Daten zugreifen, und wie wird dies protokolliert?",[183,392,394],{"id":393},"_2-das-problem-der-datensouveränität-bei-us-basierten-cloud-plattformen","2. Das Problem der Datensouveränität bei US-basierten Cloud-Plattformen",[188,396,397],{},"Die meisten eClinical-SaaS-Unternehmen, darunter viele europäische Gründungen, betreiben ihre Infrastruktur auf AWS, Azure oder Google Cloud, häufig in Regionen außerhalb der EU. Aus DSGVO-Sicht ist dies nicht grundsätzlich problematisch, sofern geeignete Übermittlungsmechanismen (SCC, TIA) bestehen. An der Schnittstelle von CTR und DSGVO entsteht jedoch ein besonderer Souveränitätskonflikt, den die Wahl einer Cloud-Region allein nicht löst.",[188,399,400],{},"Der US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) ermöglicht US-Strafverfolgungsbehörden, Cloud-Anbieter mit Hauptsitz in den USA zur Herausgabe weltweit gespeicherter Daten zu verpflichten, auch aus EU-Regionen. Damit können US-Behörden nach US-Recht potenziell auf in EU-Regionen von AWS, Azure oder Google Cloud gehostete Daten klinischer Prüfungen zugreifen – unabhängig vom Schutz der DSGVO.",[188,402,403],{},"Der Europäische Datenschutzausschuss hat klargestellt, dass eine Speicherung in EU-Regionen diesen Konflikt nicht löst, wenn der Cloud-Anbieter US-Recht unterliegt. Schrems II bestätigte, dass für die Bewertung des Übermittlungsrisikos der Rechtsrahmen des Datenimporteurs und nicht nur der physische Speicherort entscheidend ist.",[188,405,406],{},"Für eClinical-SaaS-Anbieter entsteht daraus ein konkretes Risiko: Sponsoren, die nach DSGVO Verantwortliche für Patientendaten sind, verlangen zunehmend vertragliche Zusicherungen, dass Nicht-EU-Stellen nicht aufgrund außereuropäischen Rechts auf ihre Daten zugreifen können. Kann Ihre Plattform dies nicht architektonisch gewährleisten, verlieren Sie Aufträge großer EU-Pharmaunternehmen an entsprechend aufgestellte Wettbewerber.",[188,408,409],{},"Die architektonische Lösung besteht nicht darin, Hyperscaler zu verlassen; das wäre operativ unpraktikabel und wirtschaftlich nicht wettbewerbsfähig. Stattdessen muss der Hyperscaler aus der Kette der Verschlüsselungsschlüssel entfernt werden.",[183,411,413],{"id":412},"_3-kontrolle-über-verschlüsselungsschlüssel-als-souveränitätsmechanismus","3. Kontrolle über Verschlüsselungsschlüssel als Souveränitätsmechanismus",[188,415,416],{},"In einer standardmäßigen Cloud-KMS-Konfiguration verwaltet der Cloud-Anbieter die Verschlüsselungsschlüssel. Ruhende Daten in S3, Azure Blob Storage oder Google Cloud Storage sind verschlüsselt, die Schlüssel werden jedoch vom Cloud-Anbieter gehalten und verwaltet. Eine CLOUD-Act-Anordnung an den Anbieter kann daher Daten im Klartext ergeben.",[188,418,419],{},"Bei BYOK mit extern verwalteten Schlüsseln hält der Cloud-Anbieter nur Chiffretext. Die Verschlüsselungsschlüssel befinden sich in einem HSM außerhalb seiner Infrastruktur, betrieben von einem nicht dem US-Recht unterliegenden Rechtsträger. Eine CLOUD-Act-Anordnung liefert somit Chiffretext, der ohne den dem Cloud-Anbieter nicht vorliegenden Schlüssel nicht entschlüsselt werden kann.",[188,421,422],{},"Diese Architekturänderung entfaltet rechtliche Wirkung, weil sie den Cloud-Anbieter aus der Datenzugriffskette entfernt. Für die DSGVO bedeutet dies: Selbst wenn der Anbieter Daten herausgeben muss, handelt es sich um unverständlichen Chiffretext statt nutzbarer personenbezogener Daten. Die Datensouveränität ist technisch gewährleistet und nicht nur vertraglich zugesichert.",[188,424,425],{},"Für eClinical-SaaS-Anbieter erfüllt BYOK mit extern verwalteten Schlüsseln gleichzeitig die Anforderungen dreier Gruppen:",[188,427,428],{},"Sponsoren als Verantwortliche erhalten eine nachweisbare technische Garantie, dass weder der Cloud-Anbieter noch über ihn handelnde US-Strafverfolgungsbehörden auf Patientendaten zugreifen können. Damit erfüllen sie ihre eigenen Datenschutzpflichten gegenüber betroffenen Personen.",[188,430,431],{},"Zuständige nationale Behörden erhalten eine Architektur, die Daten klinischer Prüfungen unter rechtlicher Kontrolle der EU hält und den in der CTR verankerten Erwartungen an Datensouveränität entspricht.",[188,433,434],{},"Der eClinical-Anbieter kann die von Einkaufsteams großer Pharmaunternehmen zunehmend vor Vertragsabschluss gestellte Frage „Wo liegen meine Daten und wer kann darauf zugreifen?“ belastbar beantworten.",[183,436,438],{"id":437},"_4-bedeutung-für-anbieter-von-edc-etmf-ctms-und-irt","4. Bedeutung für Anbieter von EDC, eTMF, CTMS und IRT",[188,440,441],{},"Je nach Sensibilität und regulatorischer Bedeutung der gespeicherten Daten wirkt sich die CTR-Frage der Datensouveränität auf die Kategorien von eClinical-Plattformen unterschiedlich aus.",[188,443,444],{},"Electronic-Data-Capture-Systeme (EDC) speichern klinische Primärdaten auf Patientenebene, die nach Artikel 9 DSGVO zu den besonderen Kategorien personenbezogener Daten gehören. Dies ist die höchste Sensibilitätsstufe. EDC-Anbieter unterliegen den strengsten Souveränitätspflichten und der intensivsten regulatorischen Prüfung. Für Anbieter in regulierten EU-Märkten ist BYOK praktisch unverzichtbar.",[188,446,447],{},"Electronic-Trial-Master-File-Systeme (eTMF) enthalten die wesentlichen Dokumente der regulatorischen Prüfungsakte. Nach Artikel 58 CTR ist diese Akte 25 Jahre zu archivieren. Der lange Aufbewahrungszeitraum und die regulatorische Bedeutung der Dokumente machen Datensouveränität bei eTMF insbesondere für die Langzeitarchivierung architektonisch relevant.",[188,449,450],{},"Clinical Trial Management Systems (CTMS) enthalten Betriebs- und Prüfstellendaten, die seltener patientenidentifizierende Informationen, aber häufig wirtschaftlich sensible Protokoll- und Prüfstelleninformationen umfassen. Datensouveränität ist hier sowohl wirtschaftlich als auch regulatorisch relevant.",[188,452,453],{},"IRT/RTSM-Systeme (Interactive Response Technology / Randomization and Trial Supply Management) speichern Randomisierungscodes und Behandlungszuweisungen, die für die Integrität der Prüfung entscheidend sind. Unbefugter Zugriff auf entblindete Randomisierungsdaten kann die wissenschaftliche Validität gefährden. Die Schlüsselverwaltung für IRT-Systeme betrifft daher neben dem Datenschutz auch die wissenschaftliche Integrität.",[188,455,456],{},"Die praktische Anforderung ist stets gleich: Der eClinical-Anbieter muss einem Sponsor wahrheitsgemäß zusichern können, dass der Cloud-Anbieter keinen Zugriff auf Klartextdaten hat und das Sicherheitsteam des Kunden den Schlüsselzugriff kontrollieren und bei Bedarf entziehen kann.",[183,458,460],{"id":459},"_5-byok-für-eclinical-plattformen-implementieren-architekturüberlegungen","5. BYOK für eClinical-Plattformen implementieren: Architekturüberlegungen",[188,462,463],{},"Die BYOK-Implementierung für eine eClinical-SaaS-Plattform erfordert Entscheidungen auf mehreren Ebenen des Technologie-Stacks.",[188,465,466],{},"Schlüsselumfang. Zunächst ist festzulegen, welche Daten durch kundenseitig kontrollierte Schlüssel geschützt werden. Bei EDC-Systemen sollten dies alle Patientendaten sein, mindestens sämtliche besonderen Kategorien nach Artikel 9 DSGVO. Bei eTMF und CTMS bestimmen die vertraglichen Anforderungen des Sponsors und die Datenklassifizierungsrichtlinie der Plattform den Umfang.",[188,468,469],{},"Schlüssel-Mandantenmodell. Die meisten eClinical-Plattformen bedienen mehrere Sponsoren auf gemeinsamer Infrastruktur. Die Schlüsselarchitektur sollte Schlüssel je Sponsor isolieren: Die Daten jedes Sponsors werden mit Schlüsseln verschlüsselt, die ausschließlich dessen Sicherheitsteam kontrolliert. Mandantenfähigkeit ist damit auch auf der Verschlüsselungs- und nicht nur auf der Anwendungsebene erforderlich.",[188,471,472],{},"Cloud-KMS-Integration. Native BYOK-Integrationen mit AWS KMS External Key Store (XKS), Azure Key Vault Managed HSM BYOK und Google Cloud KMS External Key Manager ermöglichen kundenseitig kontrollierte Schlüssel für alle cloud-nativen Verschlüsselungsoperationen, darunter Speicher, Datenbanken und Message Queuing, ohne Änderungen an der Anwendungsebene. Das Cloud KMS führt die Operationen mit dem externen Schlüssel aus, der das externe HSM niemals verlässt.",[188,474,475],{},"Schlüssel-Governance und Lebenszyklus. Kundenseitig kontrollierte Schlüssel benötigen zugängliche Governance-Funktionen für Rotation, Sperrung und Widerruf. Der externe Schlüsselverwaltungsdienst muss diese Funktionen dem Sicherheitsteam des Sponsors praktisch nutzbar bereitstellen – über eine API, eine Verwaltungskonsole oder einen delegierten Managed Service.",[188,477,478],{},"Audit-Protokollierung. Jeder Schlüsselzugriff muss mit Identität des Anfragenden (Cloud-Dienst), verwendetem Schlüssel, betroffenem Datenobjekt (soweit identifizierbar) und Zeitstempel protokolliert werden. Die Protokolle müssen für behördliche Prüfungen exportierbar sein. Nach den Audit-Trail-Anforderungen der CTR und den Datenintegritätsstandards der GCP (ICH E6(R3)) ist diese Protokollierung verpflichtend.",[188,480,481],{},"Langfristige Schlüsselverfügbarkeit. Die 25-jährige Archivierungspflicht der CTR stellt die Schlüsselverwaltung vor eine oft übersehene Herausforderung: Schlüssel für archivierte Daten müssen über den gesamten Zeitraum verfügbar bleiben oder die Daten sicher mit neuen Schlüsseln erneut verschlüsselt werden. Jede BYOK-Architektur für eClinical-Plattformen muss daher eine langfristige Schlüsselverwahrung vorsehen.",[183,483,485],{"id":484},"_6-wie-alcazarix-die-datensouveränität-im-eclinical-bereich-unterstützt","6. Wie Alcazarix die Datensouveränität im eClinical-Bereich unterstützt",[188,487,488],{},"Alcazarix bietet Managed BYOK als Service mit den für eClinical-CTR-Compliance erforderlichen architektonischen und rechtlichen Eigenschaften.",[188,490,491],{},"Unsere Schlüsselverwaltungsinfrastruktur läuft in zwei rechtlich isolierten Umgebungen: Alcazarix Canada für nordamerikanische und Alcazarix Germany für EU-Bereitstellungen. Sie werden jeweils von den getrennten Rechtsträgern Alcazarix, Inc. und Alcazarix Europe B.V. betrieben. Unter von Alcazarix Europe B.V. verwalteten Schlüsseln verschlüsselte EU-Prüfungsdaten unterliegen somit ausschließlich europäischem Recht; es gibt keine US-Muttergesellschaft, die nach US-Überwachungs- oder Strafverfolgungsrecht verpflichtet werden könnte.",[188,493,494],{},"Wir unterstützen nativ die Schlüsselisolierung je Sponsor. eClinical-SaaS-Anbieter können so eine mandantenfähige Schlüsselverwaltung implementieren, in der jeder Sponsor seinen eigenen Schlüssel-Namespace kontrolliert. Dies entspricht der GCP-Erwartung, dass Sponsoren die Kontrolle über ihre Prüfungsdaten behalten.",[188,496,497],{},"Unsere Integrationen mit AWS KMS XKS, Azure Key Vault Managed HSM BYOK und Google Cloud KMS EKM decken die Cloud-Plattformen ab, auf denen die meisten eClinical-SaaS-Lösungen betrieben werden, ohne Änderungen an der Anwendungsebene. Schlüsseloperationen erfolgen in der Alcazarix-Infrastruktur; Schlüssel verlassen unsere HSMs niemals im Klartext.",[188,499,500],{},"Für die Langzeitarchivierung bieten wir Schlüsselverwahrungsvereinbarungen zur 25-jährigen Aufbewahrungspflicht, einschließlich dokumentierter Verfahren für Neuverschlüsselung und langfristige Übertragung der Schlüsselverwahrung.",[188,502,503],{},"Alcazarix ist eine gezielt entwickelte Alternative zu etablierten HSM-Anbietern. Wir verlangen weder On-Premises-HSM-Hardware noch den Aufwand einer FIPS-Zertifizierung oder gerätebasierte Preismodelle, durch die Thales und Utimaco für SaaS-Bereitstellungsmodelle unwirtschaftlich werden.",[183,505,314],{"id":313},[188,507,508],{},"Mit der vollständigen Anwendbarkeit der EU CTR im Jahr 2025 wurde Datensouveränität für eClinical-SaaS-Anbieter von einem Zukunftsthema zur aktuellen Pflicht. Die Kombination aus DSGVO-Übermittlungsvorgaben, dem Zugriff des US CLOUD Act auf Cloud-Speicher in EU-Regionen und dem föderierten Zugriffsmodell der CTR schafft ein strukturelles Problem, das Verträge allein nicht lösen können. Es erfordert eine architektonische Antwort.",[188,510,511],{},"Kundenseitig kontrollierte Verschlüsselung – BYOK mit HSM-gestützter, rechtlich isolierter externer Schlüsselverwaltung – ist diese Antwort. Sie entfernt den Cloud-Anbieter aus der Datenzugriffskette, schafft eine nachweisbare technische Garantie europäischer rechtlicher Kontrolle und ermöglicht eClinical-SaaS-Anbietern, die Datensouveränitätsfragen großer EU-Pharmakunden vor Vertragsabschluss überzeugend zu beantworten.",[188,513,514],{},"Diese Architektur sollte nicht erst aufgebaut werden, wenn ein Sponsor sie in einem Beschaffungsfragebogen verlangt. Der richtige Zeitpunkt ist jetzt, solange CTR-Compliance-Programme noch finalisiert werden und die Architektur von Anfang an integriert statt nachträglich ergänzt werden kann.",[188,516,517,518,328],{},"Weitere Informationen darüber, wie Alcazarix die Datensouveränität im eClinical-Bereich unterstützt, erhalten Sie unter ",[325,519,55],{"href":327},{"title":5,"searchDepth":10,"depth":10,"links":521},[522,523,524,525,526,527,528,529],{"id":185,"depth":10,"text":186},{"id":368,"depth":10,"text":369},{"id":393,"depth":10,"text":394},{"id":412,"depth":10,"text":413},{"id":437,"depth":10,"text":438},{"id":459,"depth":10,"text":460},{"id":484,"depth":10,"text":485},{"id":313,"depth":10,"text":314},"EU-Verordnung über klinische Prüfungen","Wie eClinical-SaaS-Anbieter den durch CTR, CLOUD Act und DSGVO entstehenden Konflikt um Datensouveränität mit kundenseitig kontrollierter Schlüsselverwaltung lösen können.",{},"/de/whitepapers/eu-ctr","/whitepapers/Alcazarix_Whitepaper_EU_CTR_Data_Sovereignty_eClinical_SaaS.pdf","/whitepapers/preview_EU_CTR_Data_Sovereignty_eClinical_SaaS.png",20,{"title":352,"description":531},"eu-ctr","de/whitepapers/eu-ctr","PJJQ1GcHj9RHGw4A8pF9Cdox3eN_SEZSIHm22v949LM",{"id":542,"title":543,"body":544,"category":718,"description":719,"extension":29,"locale":67,"meta":720,"navigation":69,"path":721,"pdf":722,"preview":723,"rank":724,"seo":725,"slug":726,"stem":727,"__hash__":728},"whitepapers/de/whitepapers/dora.md","DORA und Governance von Verschlüsselungsschlüsseln: Ein Praxisleitfaden für europäische Fintech-Sicherheitsteams",{"type":7,"value":545,"toc":708},[546,548,551,554,557,561,564,567,570,573,576,579,582,585,589,592,595,598,601,604,607,611,614,617,620,623,626,630,633,636,639,642,645,648,651,655,658,661,664,667,671,674,677,680,683,686,689,692,694,697,700,703],[183,547,186],{"id":185},[188,549,550],{},"Der Digital Operational Resilience Act (DORA, Verordnung (EU) 2022/2554) ist seit dem 17. Januar 2025 für Finanzunternehmen in der EU und ihre IKT-Drittdienstleister verbindlich. DORA ist die bedeutendste IKT-Regulierung des EU-Finanzsektors seit einer Generation. Die Verordnung bündelt und verschärft die zuvor in sektorspezifischen Rahmenwerken (Leitlinien von EBA, EIOPA und ESMA) enthaltenen Anforderungen an das IKT-Risikomanagement in einem einheitlichen, unmittelbar in allen EU-Mitgliedstaaten geltenden Rechtsakt.",[188,552,553],{},"Die Governance von Verschlüsselungsschlüsseln liegt an der Schnittstelle zweier der fünf DORA-Kernbereiche: IKT-Risikomanagement und IKT-Drittparteienrisikomanagement. Wer die Schlüssel eines Finanzunternehmens kontrolliert, wie sie generiert und rotiert werden, was bei einem Widerruf geschieht und welche Dritten an der Zugriffskette beteiligt sind, entscheidet unmittelbar darüber, ob die DORA-Anforderungen an Datenschutz, operative Resilienz und Kontrolle von Drittparteienrisiken erfüllt werden.",[188,555,556],{},"Dieses Whitepaper erläutert die Folgen von DORA für die Schlüssel-Governance europäischer Fintech-Unternehmen, die Merkmale einer konformen Schlüsselverwaltungsarchitektur und warum Managed BYOK für cloud-native Finanzdienstleister zum praktikabelsten Weg zur Compliance wird.",[183,558,560],{"id":559},"_1-dora-geltungsbereich-struktur-und-tatsächliche-anforderungen","1. DORA: Geltungsbereich, Struktur und tatsächliche Anforderungen",[188,562,563],{},"DORA gilt für zahlreiche Finanzunternehmen, darunter Kredit-, Zahlungs- und E-Geld-Institute, Wertpapierfirmen, Anbieter von Kryptowerte-Dienstleistungen, Versicherungsunternehmen und viele weitere regulierte Kategorien. Die Verordnung gilt zudem unmittelbar für IKT-Drittdienstleister einschließlich Cloud-Anbietern, die nach dem DORA-Aufsichtsrahmen als „kritisch“ eingestuft werden.",[188,565,566],{},"Für Fintech-Unternehmen verteilen sich die operativ wichtigsten DORA-Anforderungen auf fünf Bereiche:",[188,568,569],{},"IKT-Risikomanagementrahmen (Kapitel II). Finanzunternehmen müssen einen umfassenden, dokumentierten Rahmen unterhalten, der Identifikation, Schutz, Erkennung, Reaktion und Wiederherstellung in ihren IKT-Systemen abdeckt. Artikel 9 verlangt ausdrücklich „angemessene Mechanismen und Strategien“ zum Schutz von Verfügbarkeit, Authentizität, Integrität und Vertraulichkeit übertragener und ruhender Daten. Verschlüsselung wird ausdrücklich als erforderlicher Schutzmechanismus genannt.",[188,571,572],{},"Management und Meldung von IKT-Vorfällen (Kapitel III). Finanzunternehmen müssen schwerwiegende IKT-Vorfälle klassifizieren und innerhalb strenger Fristen an zuständige Behörden melden (Erstmeldung binnen 4 Stunden, Zwischenbericht binnen 72 Stunden, Abschlussbericht binnen eines Monats). Da Auswirkungen auf die Datenvertraulichkeit zu den Klassifizierungskriterien gehören, kann ein Versagen der Verschlüsselung meldepflichtig sein.",[188,574,575],{},"Tests der digitalen operationalen Resilienz (Kapitel IV). Finanzunternehmen müssen Resilienztests durchführen, bei bedeutenden Unternehmen einschließlich bedrohungsorientierter Penetrationstests (TLPT). Kryptografische Kontrollen und Schlüsselverwaltung sind dabei typische Angriffsflächen.",[188,577,578],{},"IKT-Drittparteienrisikomanagement (Kapitel V). Finanzunternehmen müssen ein Informationsregister über alle IKT-Drittdienstleister führen, diese nach Kritikalität einstufen und sicherstellen, dass Verträge die DORA-Mindestanforderungen erfüllen. Cloud-KMS-Anbieter und externe Schlüsselverwaltungsdienste fallen darunter.",[188,580,581],{},"Informationsaustausch (Kapitel VI). Finanzunternehmen sollen Erkenntnisse über Cyberbedrohungen austauschen. Eine Kompromittierung von Schlüsseln wäre für diesen Austausch wesentlich.",[188,583,584],{},"Für die Governance von Verschlüsselungsschlüsseln bilden Artikel 9 und 10 des IKT-Risikomanagementrahmens die zentralen Grundlagen, ergänzt durch die von den Europäischen Aufsichtsbehörden veröffentlichten regulatorischen technischen Standards (RTS) zum IKT-Risikomanagement.",[183,586,588],{"id":587},"_2-was-dora-tatsächlich-für-die-verwaltung-von-verschlüsselungsschlüsseln-verlangt","2. Was DORA tatsächlich für die Verwaltung von Verschlüsselungsschlüsseln verlangt",[188,590,591],{},"Der DORA-Verordnungstext und die ergänzenden RTS enthalten in mehreren für die Schlüsselverwaltung unmittelbar relevanten Bereichen konkrete Vorgaben zu kryptografischen Kontrollen.",[188,593,594],{},"Datenschutz durch Verschlüsselung. Artikel 9 Absatz 2 DORA verlangt Datenschutzrichtlinien mit Verschlüsselung nach dem „Stand der Technik“. Dies ist keine formale Checkbox: Aufsichtsbehörden bewerten, ob die Umsetzung dem Risikoprofil der Daten tatsächlich angemessen ist. Für Fintech-Unternehmen mit Zahlungs-, Konto- und Identitätsdaten bedeutet dies Verschlüsselung ruhender und übertragener Daten mit angemessen geschützten Schlüsseln.",[188,596,597],{},"Schlüsselverwaltung als Risikokontrolle. Die von DORA für Banken abgelösten und verschärften EBA-Leitlinien zum IKT- und Sicherheitsrisikomanagement enthielten ausdrückliche Vorgaben für Generierung, Speicherung, Verteilung, Rotation und Vernichtung kryptografischer Schlüssel. Die DORA-RTS führen diese Anforderungen verbindlich fort. Finanzunternehmen müssen für jede Phase des Schlüssellebenszyklus dokumentierte Richtlinien und Betriebsverfahren nachweisen können.",[188,599,600],{},"Resilienz und Wiederherstellung. DORA verlangt Wiederherstellungsfähigkeiten einschließlich „Backup-Verfahren sowie Wiederherstellungs- und Wiederaufnahmeverfahren und -methoden“. Bei verschlüsselten ruhenden Daten gilt: Gehen Schlüssel verloren, sind die Daten nicht wiederherstellbar. Resiliente Schlüsselverwaltung durch HSM-Redundanz, Schlüssel-Backups und geografische Trennung ist daher nicht nur eine Sicherheitskontrolle, sondern eine Business-Continuity-Anforderung.",[188,602,603],{},"Schlüsselzugriff Dritter als Konzentrationsrisiko. Kapitel V verlangt die Bewertung übermäßiger Abhängigkeit von einzelnen IKT-Drittdienstleistern. Verwaltet der Cloud-Anbieter zugleich die Verschlüsselungsschlüssel, entsteht ein Single Point of Failure und ein Konzentrationsrisiko auf der kritischsten Ebene der Datenschutzarchitektur. Bei Ausfall des Anbieters oder Vertragsbeendigung werden Datenzugriff und Entschlüsselungsfähigkeit gleichzeitig beeinträchtigt.",[188,605,606],{},"Audit-Trail und Verantwortlichkeit. DORA verlangt dokumentierte und prüfbare IKT-Risikomanagementaktivitäten. Für die Schlüsselverwaltung bedeutet dies vollständige und ausreichend lange aufbewahrte Protokolle von Schlüsselzugriffen, administrativen Aktionen (Rotation, Sperrung, Widerruf) und Statusänderungen.",[183,608,610],{"id":609},"_3-das-konzentrationsproblem-von-cloud-kms-für-fintech","3. Das Konzentrationsproblem von Cloud KMS für Fintech",[188,612,613],{},"Die häufigste Verschlüsselungsarchitektur von Fintech-Unternehmen in der Public Cloud nutzt die native Schlüsselverwaltung des Anbieters: AWS KMS, Azure Key Vault oder Google Cloud KMS. Diese Dienste sind ausgereift, gut in cloud-native Speicher- und Rechendienste integriert und operativ komfortabel. Sie schaffen jedoch auf zwei Ebenen ein DORA-Compliance-Problem.",[188,615,616],{},"Konzentrationsrisiko bei Dritten. Nutzt ein Fintech AWS KMS, ist AWS zugleich Anbieter von Rechenleistung, Speicher und Schlüsselverwaltung. Nach dem DORA-Rahmen entsteht damit eine Abhängigkeit von einem einzigen Anbieter für Datenspeicherung und -entschlüsselung, zwei der kritischsten IKT-Ebenen. Ein AWS-weiter Vorfall oder eine Dienstbeendigung beeinträchtigt gleichzeitig Datenverfügbarkeit und Entschlüsselung.",[188,618,619],{},"Kontroll- und Governance-Lücken. DORA verlangt, dass Finanzunternehmen ihr IKT-Risikomanagement kontrollieren. Verwaltet der Cloud-Anbieter die Schlüssel, kontrolliert er wesentliche Teile der Schlüssel-Governance wie Zugriffsrichtlinien, Rotationspläne und Audit-Protokolle. Durch den Betrieb des KMS kann er auf Schlüssel zugreifen; das Finanzunternehmen hängt für seine eigene Datenschutz-Compliance von dessen Sicherheitsniveau ab.",[188,621,622],{},"Aufsichtsrechtliche Zugangs- und Prüfungsrechte. Nach Artikel 65 DORA dürfen zuständige Behörden IKT-Drittdienstleister prüfen. Dennoch muss das Finanzunternehmen selbst seine Schlüsselkontrollen nachweisen. Ist die Schlüsselverwaltung in einen proprietären Cloud-Dienst eingebettet, kann die erforderliche Transparenz über die operativen Kontrollen fehlen.",[188,624,625],{},"Alle drei Probleme haben dieselbe Lösung: Die Schlüsselverwaltung wird der Kontrolle des Cloud-Anbieters entzogen und in einen getrennten, unabhängig gesteuerten Dienst verlagert, über den das Finanzunternehmen oder sein spezialisierter Managed-Key-Management-Anbieter die operative Kontrolle behält.",[183,627,629],{"id":628},"_4-aufbau-einer-dora-konformen-schlüsselverwaltungsarchitektur","4. Aufbau einer DORA-konformen Schlüsselverwaltungsarchitektur",[188,631,632],{},"Eine DORA-konforme Schlüsselverwaltungsarchitektur für ein europäisches Fintech in der Public Cloud weist folgende Merkmale auf:",[188,634,635],{},"Die Schlüsselverwaltung ist strukturell von Cloud-Rechenleistung und -Speicher getrennt. Schlüssel für Daten in AWS, Azure oder Google Cloud werden von einem organisatorisch und technisch unabhängigen Dienst verwaltet. Dies reduziert das Konzentrationsrisiko und entfernt den Cloud-Anbieter aus der Schlüssel-Governance-Kette.",[188,637,638],{},"Schlüssel werden in HSMs generiert, die der Cloud-Anbieter nicht kontrolliert. HSM-gestützte Generierung bietet kryptografische Sicherheit, die rein softwarebasierte Verwaltung nicht erreicht. Der DORA-Standard „Stand der Technik“ spricht bei hochsensiblen Finanzdaten für HSM-geschütztes Schlüsselmaterial.",[188,640,641],{},"Der Schlüssellebenszyklus wird richtlinienbasiert und prüfbar verwaltet. Rotation, Sperrung und Widerruf folgen dokumentierten Richtlinien; jede Aktion wird protokolliert. Das Protokoll gehört dem Finanzunternehmen, nicht dem Cloud-Anbieter, und steht für behördliche Prüfungen bereit.",[188,643,644],{},"Geografische Trennung schafft Resilienz. HSM-Infrastruktur sollte geografisch verteilt sein, damit ein Standortausfall nicht primäre und redundante Schlüsselzugriffspfade zugleich betrifft. Für EU-Finanzunternehmen erfüllt eine Trennung innerhalb der EU sowohl Resilienzanforderungen als auch Anforderungen an Datensouveränität.",[188,646,647],{},"Die Schlüsselverwahrung ist eindeutig zugeordnet. Der Vertrag mit dem Schlüsselverwaltungsanbieter muss die DORA-Mindestinhalte einschließlich Ausstiegsregelungen, Prüfungsrechten und SLA erfüllen. Das Finanzunternehmen muss die Beziehung beenden und Schlüssel migrieren oder auf archivierte Daten zugreifen können, ohne an den Anbieter gebunden zu sein.",[188,649,650],{},"Cloud-KMS-Integration erhält cloud-native Abläufe. Native Integrationen mit AWS KMS XKS, Azure Key Vault Managed HSM BYOK und Google Cloud KMS EKM ermöglichen externe Schlüssel für Datenbank-, Speicher- und Secrets-Verschlüsselung ohne Anwendungsänderungen. Das Cloud KMS führt kryptografische Operationen mit dem externen Schlüssel aus, der das externe HSM niemals verlässt.",[183,652,654],{"id":653},"_5-schlüsselwiderruf-als-kontrolle-der-operationalen-resilienz","5. Schlüsselwiderruf als Kontrolle der operationalen Resilienz",[188,656,657],{},"Eine seltener diskutierte Folge von DORA ist der regulatorische Wert der Fähigkeit zum Schlüsselwiderruf. Finanzunternehmen müssen bei Sicherheitsvorfällen Eindämmungsmaßnahmen ergreifen können, um Ausbreitung und Auswirkungen eines IKT-Sicherheitsvorfalls zu begrenzen.",[188,659,660],{},"Bei Datenschutzverletzungen mit verschlüsselten Daten ist der Schlüsselwiderruf die wirksamste Eindämmungskontrolle. Erhält ein Angreifer Zugriff auf Cloud-Speicher, nicht aber auf den externen Schlüsselverwaltungsdienst, bleiben die Daten unbrauchbarer Chiffretext. Wird ein Angriff erkannt und ein Zugriff auf den externen Dienst vermutet, kann eine Schlüsselsperrung die Daten vorübergehend unzugänglich machen, ohne die Cloud-Umgebung abzuschalten.",[188,662,663],{},"Dies unterscheidet sich grundlegend von cloud-nativen KMS: Dort sind Widerruf und Sperrung zwar möglich, erfordern aber die Mitwirkung des Cloud-Anbieters. Bei externer Schlüsselverwaltung liegt die Sperrung vollständig in der Kontrolle des Finanzunternehmens, benötigt keine Mitwirkung des Anbieters und kann von diesem nicht umgangen werden.",[188,665,666],{},"Für DORA-Vorfallsmeldungen unterscheidet sich ein Vorfall mit extern verwalteten Schlüsseln, bei dem das Finanzunternehmen den Zugriff widerrufen und eine Klartextoffenlegung verhindern konnte, wesentlich von einem Vorfall mit Schlüsseln des Cloud-Anbieters, bei dem Angreifer auf verschlüsselte Daten derselben Stelle zugriffen, die auch die Schlüssel hielt.",[183,668,670],{"id":669},"_6-wie-alcazarix-dora-compliance-unterstützt","6. Wie Alcazarix DORA-Compliance unterstützt",[188,672,673],{},"Alcazarix bietet Managed BYOK als Service, dessen Architektur die für die Schlüssel-Governance von Fintechs wichtigsten DORA-Anforderungen erfüllt.",[188,675,676],{},"Strukturelle Trennung von Cloud-Anbietern. Alcazarix betreibt vollständig von AWS, Azure und Google Cloud unabhängige HSM-Infrastruktur in eigenen Rechenzentren: in Kanada für nordamerikanische, in Deutschland für EU- und in Hongkong für APAC-Workloads. Von Alcazarix verwaltete Schlüssel verbleiben in Alcazarix-HSMs; der Cloud-Anbieter erhält niemals Zugriff auf Schlüsselmaterial. Dies adressiert unmittelbar das DORA-Konzentrationsrisiko.",[188,678,679],{},"DORA-konforme Vertragsstruktur. Die Kundenverträge von Alcazarix erfüllen die Anforderungen aus Kapitel V an IKT-Drittparteienverträge, einschließlich SLA-Zusagen, Prüfungsrechten, Ausstiegsregelungen und Transparenz über Unterauftragsverarbeiter. Finanzunternehmen können unseren Service mit der erforderlichen Dokumentation in ihr Informationsregister aufnehmen.",[188,681,682],{},"Vollständige Schlüssel-Audit-Protokolle. Alcazarix protokolliert jede Schlüsselzugriffsanfrage von AWS KMS XKS, Azure Key Vault BYOK oder Google Cloud KMS EKM mit anfragendem Dienst, Schlüsselkennung und Zeitstempel. Kunden können Protokolle per API exportieren und zur Echtzeitüberwachung in SIEM-Plattformen einspeisen. So werden die DORA-Audit-Trail-Anforderungen ohne eigene Protokollierungsinfrastruktur erfüllt.",[188,684,685],{},"Schlüsselwiderruf als zentrale Funktion. Alcazarix unterstützt Sperrung und Widerruf als unabhängig ausführbare Operationen, die das Sicherheitsteam des Finanzunternehmens ohne Beteiligung des Cloud-Anbieters direkt auslösen kann. Dies unterstützt die DORA-Anforderungen zur Vorfallseindämmung.",[188,687,688],{},"Resiliente, geografisch getrennte Infrastruktur. Alcazarix betreibt redundante HSM-Infrastruktur mit Optionen zur geografischen Trennung innerhalb der EU und unterstützt damit die DORA-Anforderungen an Business Continuity und Wiederherstellung kritischer IKT-Systeme.",[188,690,691],{},"Transparente Preise ohne Geräteaufwand. Die Preise von Alcazarix sind bewusst auf SaaS- und Fintech-Skalierung ausgelegt: nutzungsbasiert und ohne geräteabhängige Kosten und Wartungsaufwand etablierter HSM-Anbieter wie Thales, Utimaco oder Fortanix. Damit wird DORA-konforme Schlüsselverwaltung für Fintech-Unternehmen jeder Entwicklungsphase wirtschaftlich tragfähig.",[183,693,314],{"id":313},[188,695,696],{},"DORA hat die Anforderungen an das IKT-Risikomanagement im EU-Finanzsektor erhöht. Bei der Governance von Verschlüsselungsschlüsseln zeigen bestehende Fintech-Architekturen häufig ihre größten Schwächen. Die Datenschutzvorgaben, der Rahmen für Konzentrationsrisiken und die Drittparteienpflichten von DORA sprechen regulatorisch klar für eine Trennung der Schlüsselverwaltung von der Infrastruktur des Cloud-Anbieters.",[188,698,699],{},"Fintech-Sicherheitsarchitekten sollten prüfen, ob ihre aktuelle Schlüsselarchitektur einer aufsichtsrechtlichen Prüfung anhand dreier Fragen standhält: Können Sie nachweisen, dass Ihr Cloud-Anbieter nicht einseitig auf Ihre Daten zugreifen kann? Können Sie belegen, dass für Speicherung und Schlüsselverwaltung keine übermäßige Abhängigkeit von einem einzigen IKT-Anbieter besteht? Können Sie eine getestete, dokumentierte und vom Cloud-Anbieter unabhängige Fähigkeit zum Schlüsselwiderruf nachweisen?",[188,701,702],{},"Lautet eine dieser Antworten nein, ist Managed BYOK mit extern gehaltenen, HSM-gestützten Schlüsseln die erforderliche Architekturänderung.",[188,704,705,706,328],{},"Weitere Informationen darüber, wie Alcazarix europäische Fintechs bei DORA-konformer Governance von Verschlüsselungsschlüsseln unterstützt, erhalten Sie unter ",[325,707,55],{"href":327},{"title":5,"searchDepth":10,"depth":10,"links":709},[710,711,712,713,714,715,716,717],{"id":185,"depth":10,"text":186},{"id":559,"depth":10,"text":560},{"id":587,"depth":10,"text":588},{"id":609,"depth":10,"text":610},{"id":628,"depth":10,"text":629},{"id":653,"depth":10,"text":654},{"id":669,"depth":10,"text":670},{"id":313,"depth":10,"text":314},"Digital Operational Resilience Act","Welche Anforderungen DORA an die Governance von Verschlüsselungsschlüsseln stellt, warum cloud-native KMS Konzentrationsrisiken schaffen und wie Managed BYOK die IKT-Risikomanagementpflichten von DORA erfüllt.",{},"/de/whitepapers/dora","/whitepapers/Alcazarix_Whitepaper_DORA_Encryption_Key_Governance_Fintech.pdf","/whitepapers/preview_DORA_Encryption_Key_Governance_Fintech.png",30,{"title":543,"description":719},"dora","de/whitepapers/dora","PeBTw54UCGY-KIBZLAx68luuwesm7GMmZdlBPKI7bV4",1787677010782]