Schweizer Banken in die Cloud – so geht es (und so nicht)

Kann eine Schweizer Bank mit ihren Kundendaten in die Cloud gehen, auch wenn ein Zugriff auf diese "Client Identifying Data" (CID) aus dem Ausland nicht ausgeschlossen ist? War dies vor einigen Jahren noch undenkbar, lautet die Antwort heute klar ja. Dabei wollen viele Schweizer Banken in die Cloud. Wir selbst begleiten derzeit über ein halbes Dutzend Projekte teils namhafter Institute, und die Frage ist nicht "ob", sondern "wie".

• Viele Vorgaben, aber sie sind lösbar (Checkliste)
• Dokumentierte Risikobeurteilung erforderlich
• Microsoft, AWS: Verträge müssen angepasst werden

Microsoft führt derzeit

Oft beginnt es mit der Ablösung von Skype for Business als "on-premise" Lösung durch Teams. Es folgt M365 mit den diversen Office-Anwendungen, Exchange Online, Sharepoint Online und OneDrive for Business und in einem dritten Schritt folgen bankeigene Anwendungen auf Azure. Dies sind alles Anwendungen von Microsoft, die nach unserer Wahrnehmung im Markt für solche Produkte bei Berufsgeheimnisträgern derzeit dominiert; deren früher Entscheid für Rechenzentren in der Schweiz hat sich zweifellos bezahlt gemacht.

Anwendungen von Schweizer Banken mit CID auf der Basis von AWS, die derzeit ebenfalls ein Rechenzentrum in der Schweiz baut, sehen wir wenige, und noch seltener begegnen wir in diesem Umfeld Lösungen auf der Basis anderer ausländischer Cloud-Anbietern (auf rein schweizerische Lösungen wie etwa von Swisscom gehen wir hier nicht ein). AWS dürfte dann zulegen, wenn Banken damit anfangen, auch bankspezifische Anwendungen in die Cloud zu verlagern und dort nicht "nur" ihren Mailserver oder ihre Dateiablage zu betreiben. Hier sind ihnen die Schweizer Versicherer etwas voraus, da sie nicht wie die Banken einem Berufsgeheimnis unterliegen und daher rascher in die Cloud migrieren konnten. Der Einsatz von M365 ist dort bereits weiter verbreitet.

Wegbereiter entstanden 2019

Der Weg in die Cloud wurde für die Banken 2019 geebnet. Im Frühjahr erschien als Charmeoffensive der Cloud-Leitfaden der Schweizerischen Bankiervereinigung, der gestützt auf zwei Rechtsgutachten zum Ergebnis kam, dass mit entsprechenden Risikoabwägungen und Schutzmassnahmen eine Nutzung der Cloud durchaus möglich ist – auch unter Einbezug ausländischer Dienstleister. Er machte die Cloud in der Schweizer Bankenwelt salonfähig.

Offen blieb die Frage, welche Schutzmassnahmen genügen, damit auch Angebote wie etwa von Microsoft in Anspruch genommen werden können, wenn bei diesen ein Zugriff aus dem Ausland auf CID im Klartext nicht vollständig ausgeschlossen werden kann. Käme es zu einem solchen Zugriff durch eine ausländische Behörde, läge mangels Bankgeheimnisverzicht seitens der Kunden in der Regel eine Verletzung des Bankgeheimnisses vor. Die Lösung brachte im Herbst 2019 eine vom Autor dieses Beitrags für eine Schweizer Grossbank entwickelte Methode zur statistischen Berechnung der Wahrscheinlichkeit eines ausländischen Behördenzugriffs unter Berücksichtigung der konkret getroffenen technischen und organisatorischen Massnahmen.

Mit der Methode konnte das bisher für viele nicht fassbare und nur subjektiv beurteilte Risiko erstmals objektiviert dargestellt werden. Sie wurde in diversen Projekten über längere Zeit verfeinert und schliesslich im August 2020 in Form eines Excel als "Open Source" publiziert. Seither wird sie von Banken, Versicherungen und anderen Berufsgeheimnisträgern sowie ihren Beratern und Anwälten regelmässig zur Einschätzung und Dokumentation des Lawful Access Risikos in Cloud-Projekten eingesetzt. Seit September 2021 bietet auch die International Association of Privacy Professionals (IAPP), der grösste internationale Berufsverband von Datenschutz-Spezialisten, das Excel als eines seiner Tools.

Rechtliche Anforderungen – eine Checkliste

Will eine Bank (oder auch ein anderes reguliertes Finanzinstitut) eine Cloud-basierte Lösung nutzen, sind nach wie vor eine ganze Reihe von Anforderungen zu erfüllen. Sie ergeben sich einerseits aus dem Datenschutz und dem Bankgeheimnis (oder sonstigem Berufsgeheimnis), aber auch aus den aufsichtsrechtlichen Voraussetzungen wie etwa dem Outsourcing-Rundschreiben der FINMA. Wer mit solchen Projekten nicht gut vertraut ist, für den gestaltet sich die Situation unübersichtlich. Wir haben daher diese Anforderungen in Form einer frei verfügbaren Checkliste für Cloud-Lösungen von Schweizer Banken zusammengestellt. Es gibt sie, wie dieser Blog-Beitrag, in Deutsch und auf Englisch.

In der Praxis fällt uns dabei in Projekten auf, dass insbesondere einige der Vorgaben der FINMA von Cloud-Anbietern, Finanzinstituten und deren Beratern nicht richtig angewendet werden. Aber auch einige Schweizer Prüfgesellschaften prüfen deren Einhaltung immer wieder zuwenig eingehend oder nicht den Vorgaben entsprechend. Das ist insofern kritisch, als sich die FINMA im Bereich der Auslagerungen von Banken auf die Prüfung durch die Audit-Firms verlässt. Nur im Bereich der Versicherungen prüft die FINMA selbst die Voraussetzungen. In einem kürzlichen Fall hat sie eine erteilte Genehmigung sogar widerrufen als ihr bei anderer Gelegenheit ein wesentlicher Mangel am Vertragswerk eines bekannten Cloud-Anbieters bewusst wurde. Auch wenn der Mangel inzwischen behoben ist, dürfte er in etlichen Verträgen noch bestehen. Erkannt hat ihn bisher unseres Wissens interessanterweise sonst niemand.

Die fünf häufigsten Mängel

Drei der nach unserer Erfahrung fünf häufigsten Stolpersteine in Cloud-Projekten beziehen sich auf die Vorgaben der FINMA, insbesondere des Outsourcing-Rundschreibens. Man mag von den einzelnen Vorgaben des Rundschreibens halten was man will, aber das Rundschreiben gibt die derzeit geltende Ansicht der FINMA wieder, welche besonderen Voraussetzungen wesentliche Auslagerungen zu erfüllen haben:

• Durchsetzung der Ansprüche auf Prüfung und Zugriff: Es ist allgemein bekannt, dass nicht nur der Kunde des Cloud-Providers ein Prüfrecht betreffend die ausgelagerte Funktion haben muss, sondern auch die FINMA und die externe Prüfgesellschaft. Wenig bekannt ist, dass die FINMA erwartet, dass dieses Prüfrecht gegenüber dem Provider nicht nur vom Kunden vertraglich durchgesetzt werden kann, sondern auch von der FINMA, der externen Prüfgesellschaft und ferner von allen anderen Finanzinstituten in der Gruppe des Kunden, welche die Cloud-Services mitnutzen. Dies bedeutet, dass ein echter Vertrag zugunsten Dritter bestehen muss. Manche Verträge schliessen einen solchen aber gerade aus (die Provider verlangen, dass Anfragen, Prüfungen und Zugriffe nur über den Kunden möglich sind), oder das anwendbare Recht (wie etwa irisches Recht) erlaubt sie grundsätzlich nicht, selbst wenn sie vereinbart sind.
   
• Datenspeicherung in der Schweiz: Das Outsourcing-Rundschreiben verlangt, dass der Zugriff auf die für die Sanierbarkeit und Abwickelbarkeit des Instituts erforderlichen Informationen jederzeit in der Schweiz möglich sein muss. Viele verstehen dies noch immer dahingehend, dass der Online-Zugriff auf ihre Daten in der Cloud garantiert sein muss, was in den Verträgen mitunter auch versprochen wird. Die FINMA versteht das anders: Diese Daten müssen auf Schweizer Boden gespeichert sein, und zwar mit allem, was für ihre Nutzung erforderlich ist. Ein reiner Online-Zugriff auf ein Rechenzentrum im Ausland genügt nicht. Immerhin kann die Anforderungen durch eine regelmässige Anfertigung und Lagerung von Kopien in der Schweiz erfüllt werden; die "Masterkopie" darf im Ausland sein. Die Überlegung der FINMA: Sie will im Falle einer globalen Krise nicht auf ausländische Behörden angewiesen sein, wenn sie im Notfall einen Zugriff auf die Daten organisieren muss.
   
• Meldung Cyberangriffen: Alle Provider verpflichten sich heute zwar, Verletzungen der Datensicherheit zu melden, da die DSGVO dies verlangt. Sie gehen allerdings auch von den Meldefristen der DSGVO aus, wonach der Kunde innert 72 Stunden melden muss. Die Anforderungen der FINMA ist strenger: Sie verlangt im Rahmen von Art. 29 Abs. 2 FINMAG eine Meldung nicht nur von Verletzungen der Datensicherheit von Personendaten, sondern ganz generell von Cyberangriffen, und sie verlangt einen ersten Bericht innert 24 Stunden. In einer öffentlichen Stellungnahme vom März 2021 hat ein Vertreter der FINMA klargestellt, dass sie von solchen Angriffen innert 24 Stunden ab dem Zeitpunkt des Angriffs erfahren möchten, und nicht innert 24 Stunden ab dem Zeitpunkt, an welchem die Bank davon erfährt. Im Moment kann diese Anforderungen mit Cloud-Providern nicht erfüllt werden, was auch der FINMA bewusst ist.
   
• Ungenügender Schutz von CID: Eine rechtskonforme Auslagerung von CID in die Cloud eines ausländischen Anbieters ist nach unserer Ansicht zwar möglich. Aber sie setzt nebst gewissen technischen Massnahmen auch entsprechende Verträge voraus. Manche der Verträge, die wir gesehen haben, genügen diesen Ansprüchen leider nicht, selbst unter Berücksichtigung ihrer Zusatzvereinbarungen für Finanzinstitute und der Vereinbarung über die Auftragsdatenverarbeitung nach DSGVO. Es wird zum Beispiel übersehen, dass der Begriff des Personendatums enger ist als jener von CID und die für die DSGVO geltenden Regelungen schlicht nicht greifen. Cloud-Anbieter wie Microsoft behalten sich die Bearbeitung von Kundendaten auch für eigene Zwecke vor; in diesen Fällen sind sie keine Auftragsbearbeiter. Die für die Auftragsbearbeitung vereinbarten Regelungen greifen dann nicht mehr; dementsprechend muss die Bearbeitung von CID im Klartext aus der Bearbeitung für solche eigene Zwecke ausgeschlossen oder stark eingeschränkt und geregelt werden. Weitere typische Schwachpunkte ist eine zu geringe Haftung, die zeitliche Beschränkung der Vertraulichkeit, eine unzureichende oder fehlende "defend your data"-Klausel und unzureichende Löschklauseln.
   
• Unzureichende Haftung: Die Bestimmungen eines Vertrags sind nicht viel wert, wenn es keine Notwendigkeit gibt, sie einzuhalten, weil ihre Verletzung keine wirklichen Konsequenzen zeitigt. Das bedeutet, dass jeder Vertrag, mit dem eine Schweizer Bank in die Cloud geht, eine ausreichende Haftung vorsehen muss. Dies ist jedoch zuweilen ein Problem. Microsofts Standardverträge unterliegen irischem Recht und was die meisten Leute dabei nicht wissen ist, dass das irische Recht es nicht verbietet, die Haftung für grobe Fahrlässigkeit oder gar Vorsatz auszuschliessen. Microsofts Standardvertrag "MBSA" wurde so abgefasst, dass diese Eigenheit des irischen Rechts zum Tragen kommt und Microsoft selbst bei einer vorsätzlichen Vertragsverletzung, die zu einem Datenverlust führt, höchstwahrscheinlich nicht haften muss. Dem Vertrag fehlt also ein wichtiges Instrument zur Durchsetzung und Microsoft einer der Anreize, sich an den Vertrag zu halten. Ein Kunde kann natürlich andere Massnahmen zu seinem Schutz treffen, aber das Schweizer Bundesgericht hat 2019 in einem Fall zum Berufsgeheimnis von Rechtsanwälten (BGE 145 II 229) klargestellt, dass es nicht einmal zulässig sein soll, die Haftung auf grobe Fahrlässigkeit und Vorsatz zu beschränken. Dieser Fall bezog sich zwar auf das Berufsgeheimnis von Anwälten, aber wir bezweifeln, dass die FINMA, der Eidgenössische Datenschutz- und Öffentlichkeitsbeauftragte (EDÖB) und auch die Gerichte in einem konkreten Fällen eine weniger strenge Auffassung vertreten werden, sollten sie sich erst einmal ob der erwähnte Fussangel irischen Rechts bewusst werden (bis war diese in der Schweiz auch unter Spezialisten kaum bekannt). Daher müssen nebst all den anderen Massnahmen zur Risikominderung (wie z.B. Cloud-Backups bei einem anderen Provider) die Verträge auch in diesem Punkt geändert werden, wenn sie nicht bereits entsprechende Ausnahmen von ihren Haftungsbeschränkungen und -ausschlüssen vorsehen. Selbst wenn Haftungsbeschränkungen Ausnahmen vorsehen, muss darauf geachtet werden, ob nicht etwa Haftungsausschlüsse trotzdem versuchen, die Haftung für den Verlust von Geschäftsinformationen komplett auch für grobe Fahrlässigkeit und Vorsatz auszuschliessen. Eine andere Lösung besteht darin, das anwendbare Recht zum Beispiel auf das Recht einer Civil-Law-Rechtsordnung anstelle eines Common-Law-Rechts zu vereinbaren. Wir haben all diese Ansätze gesehen.

Noch eine Bemerkung zur Datennutzung durch den Provider: Regelungen, welchem dem Provider die Bearbeitung von Personendaten des Kunden für eigene Geschäftszwecke erlauben – Microsoft spricht von "Legitimate Business Operations" (LBOs) – sind in der richtigen Dosis nicht unangemessen. Es ist normal, dass ein Provider Personendaten des Kunden auch in eigener Verantwortung und nicht als Auftragsbearbeiter bearbeitet. Die Durchführung von Abrechnungen zur Nutzung des Service, das Erbringen von Supportleistung aber auch die Administration der Benutzer eines Online-Service sind solche Fälle. Auch das Bedürfnis des Providers, die Nutzung seines Service für nicht personenbezogene Zwecke auszuwerten, ist legitim, wenn es in gewissen Schranken erfolgt. Tatsache ist aber, dass diese Bearbeitungen von vielen Providern in den Verträgen gar nicht erwähnt werden – oft auch, weil sie im Kontext des Datenschutzes gar nicht daran denken. Der Kunde wiederum muss sich überlegen, unter welchen datenschutzrechtlichen Voraussetzungen er eine solche Nutzung zulassen kann (z.B. bei Information der Mitarbeiter).

Wesentliches Outsourcing?

Immer wieder für Diskussionen sorgt auch die Frage, ob ein wesentliches Outsourcing vorliegt, denn nur dann gilt das Outsourcing-Rundschreiben. Die meisten Versicherer, deren Projekte wir kennen und die den Schritt bereits gewagt haben, sind davon ausgegangen, dass jedenfalls eine Auslagerung von blossen Office-Services (also etwa M365 inklusive Exchange Online und Sharepoint Online) noch kein wesentliches Outsourcing darstellt, da es die Kernanwendungen nicht tangiert. Die FINMA hat das, soweit wir dies beurteilen können, bisher hingenommen, allerdings wohl eher unbewusst. In der Regel beginnt in diesem Sektor die Wesentlichkeit, wenn Versicherer mit versicherungsspezifischen Anwendungen in die Cloud gehen, was inzwischen erste Institute tun. Es würde uns jedoch nicht überraschen, wenn die FINMA die Schrauben weiter anzieht und künftig auch die Auslagerung von Office-Anwendungen als wesentliches Outsourcing klassifiziert mit dem Argument, dass auch diese Systeme zunehmen geschäftskritisch werden. Es gibt jedenfalls bereits Zeichen für eine Verschärfung der Praxis.

Banken müssen ohnehin damit rechnen, dass für sie ein strengerer Standard gilt, weil in ihrem Falle CID hinzukommt. Schon bisher galt, dass wo die Bearbeitung einer grösseren Menge an CID ausgelagert wird, dies grundsätzlich für die Wesentlichkeit spricht. Lagert also eine Bank den Betrieb ihres Mail-Servers an einen Hyperscaler aus, über den sie regelmässig auch E-Mails an Bankkunden oder mit CID austauscht, was oft gegeben sein wird, so wird oft bereits von einer Wesentlichkeit auszugehen sein. Hier haben wir allerdings auch den Eindruck gewonnen, dass die Prüfgesellschaften in ihrer Annahme eines wesentlichen Outsourcings tendenziell nicht streng sind. Wir empfehlen jedenfalls, für den Vertrag so oder so von einem wesentlichen Outsourcing auszugehen. So werden Notfallübungen zur Vertragsanpassung zu einem späteren Zeitpunkt vermieden, und der Zusatzaufwand ist in der Regel gering.

Microsoft und AWS: Nachbesserungsbedarf

Wie aber sind die Verträge der erfolgreichen Hyperscaler aus der Sicht einer Schweizer Bank zu beurteilen?

Die Verträge von Microsoft genügen beispielsweise selbst mit den Standarderweiterungen für Finanzinstute (M453), das Schweizer Datenschutzrecht (M329) und Schweizer Berufsgeheimnis (M744) für eine Schweizer Bank mit CID nicht. Wir konnten bisher allerdings in allen Fällen mit entsprechenden Vertragsverhandlungen durch kundenspezifische Vertragsanpassungen eine Lösung finden, so dass die betreffenden Schweizer Banken auch die Microsoft-Cloud auch mit CID nutzen können. Allerdings setzt dies wiederum voraus, dass die Banken bestimmte Vertragsformen nutzen (z.B. Enterprise Agreement), da Microsoft bei bestimmten anderen Vertragsformen sehr unflexibel ist. Kunden, die über Reseller wie etwa Branchenprimus SoftwareOne einkaufen, sind von Microsoft heute daher zum Teil unverständlicherweise schlechter bedient. Die nötigen Vertragsanpassungen erhielten sie bisher wegen fehlender Standard-Amendments höchstens über Umwege. Wenn eine Bank (oder ein anderer Kunde mit Berufsgeheimnis) zu klein ist, gibt es derzeit auf vertraglicher Ebene derzeit keine Lösung. Solche Kunden müssen einen Risikoentscheid treffen oder warten bis Microsoft – hoffentlich – ein Standard-Amendment für "Berufsgeheimnisträger" anbietet, das diesen Namen verdient; das bisherige Standard-Amendment M744 ist klar ungenügend, auch wenn gewisse andere Rechtsberater (aus dem Umfeld von Microsoft) etwas anderes behaupten. Mit weiteren Änderungen ist seitens Microsoft auch mit ihrem neuen Data Protection Addendum zu rechnen, welches noch im September eingeführt werden dürfte aufgrund der neuen EU Standardvertragsklauseln (EU SCC); der Kunde wird die EU SCC nicht mehr direkt mit Microsoft Corporation abschliessen, wie dies bisher der Fall war. Hoffentlich nutzt Microsoft die Gelegenheit der Neufassung des DPA um es gleich auch in anderen Punkten zu verbessern und mindestens einige der nach Schweizer Datenschutzrecht ungenügenden Bestimmungen zu korrigieren.

Auch die Standardvereinbarung von AWS inklusive dem Zusatz für Finanzinstitute genügte nach unserer Erfahrung den Anforderungen und insbesondere des Outsourcing-Rundschreibens bisher nicht. Hier wird AWS für Schweizer Banken deutlich nachbessern müssen.

Genau zu prüfen sind auch die in diesem Zusammenhang von den Hyperscalern häufig beworbenen Bestätigungen und Berichten von Prüfgesellschaften: Sie können den Eindruck erwecken, beim Einsatz einer Lösung eines Hyperscalers seien die Voraussetzungen der FINMA oder des Outsourcing-Rundschreibens erfüllt, aber bei genauerem Hinsehen zeigt sich: Die Prüfung betrifft nicht die Verträge, sondern nur die Ausgestaltung des Services selbst (also ob dieser z.B. dem Kunden die Möglichkeit gibt, Backups herzustellen oder verschlüsselte Verbindungen zur Cloud aufzubauen) und die interne Organisation des Hyperscalers (also ob sie vorsieht, dass dem Kunden z.B. Audit-Berichte zugänglich gemacht werden). Das genügt natürlich nicht.

Verträge entwickeln sich weiter

Dies zeigt ein Grundproblem für die Schweizer Banken, für regulierte Finanzinstitute generell und auch für andere Berufsgeheimnisträger im Umgang mit internationalen Cloud-Providern: Letztere bieten zwar ein oft hohes Niveau an Datensicherheit, eine hohe Dienstleistungsgüte und es darf angenommen werden, dass sie sich im Tagesgeschäft grundsätzlich auch so wie erforderlich verhalten. Aber ihre Verträge reflektieren dies noch viel zu häufig nicht. Im Gegenteil sind die Verträge nicht selten unübersichtlich, inkonsistent sowie mehrdeutig, zu offen oder schlicht schlecht formuliert.

Dies macht entsprechende Nachbesserungen nötig, die wiederum sehr zeitraubend und mühselig zu erreichen sind, weil die Provider ihren vertraglichen Standard mit Händen und Füssen zu verteidigen versuchen und dazu oftmals einfach behaupten, die Forderungen der Kunden (oder sogar des Regulators) seien nicht berechtigt. Das ist schade, doch dürfte sich dieses Problem im Laufe der Zeit lösen. Die Verträge von grossen Cloud-Providern wie Microsoft sind unter dem ständigen Druck zahlreicher Kunden und Aufsichtsbehörden in den letzten Jahren immer besser geworden. Auch für Schweizer Banken wird der Zeitpunkt kommen, an welchem wir für unsere Klienten nicht mehr kundenspezifische Anpassungen der Verträge durchsetzen müssen, sondern auf die passenden Standard-Amendments der Verträge zurückgreifen können.

Braucht es "Bring-your-own-key"?

Unsere Checkliste der Anforderungen kann einer Bank auch bei der Erstellung der Risikobeurteilung helfen, welche die FINMA von den beaufsichtigten Instituten in dokumentierter Form erwartet. Denn: Der Gang in die Cloud ist wie jedes andere IT-Projekt mit Risiken befrachtet, die die Leitung einer Bank nicht nur kennen, sondern auch übernehmen muss, bevor dem Vorhaben grünes Licht erteilt werden darf. Unsere Erfahrung in zahlreichen Cloud-Projekten zeigt immerhin, dass eine solche Risikobeurteilung nur selten in hohen Risiken resultiert und das Management in vielen Fällen den Gang in die Cloud sogar aktiv vorantreibt, weil sie mittel- und vor allem langfristig keine Alternative sehen. Interessanterweise werden sie dabei inzwischen von den Spezialisten für Datensicherheit unterstützt: Waren manche vor einigen Jahren noch skeptisch, ist heute eine Mehrheit nach unserer Erfahrung überzeugt davon, dass ihre Daten in den Händen der grossen Hyperscaler besser geschützt sind als in ihren eigenen Rechenzentren. Das ist eine bemerkenswerte Entwicklung.

Bleibt noch eine Frage, die uns in der Beratung immer wieder begegnet: Muss eine Schweizer Bank unbedingt "Bring-your-own-key" (BYOK) einsetzen? Bei Microsoft ist damit die Service-Option des "customer managed key" gemeint, was den Sachverhalt wesentlich besser umschreibt: Der Schlüssel wird zwar im Hard- oder Software-Schlüsseltresor bei Microsoft gespeichert, aber das Key Management obliegt dem Kunden – und er darf den "privaten Schlüssel" zu seinen Daten auch selbst auf seinen eigenen Systemen generieren und in den Schlüsseltresor importieren. Wer das Schlüssel-Management selbst betreibt, hat vor allem die Möglichkeit, den Schlüssel zu revozieren (bzw. die Revozierung auszulösen – ausgeführt wird sie von der Hard- oder Software bei bzw. von Microsoft). Mit der Revozierung werden sämtliche gespeicherten Daten unbrauchbar. Das gilt allerdings auch für die Bank. BYOK verschafft dem Kunden also gewissermassen den "roten Knopf zur Selbstzerstörung" seiner Daten. Das kann beim Weggang aus der Cloud nützlich sein, aber auch bei einem drohenden Zugriff von ausländischen Behörden. Ob letzterer damit wirklich verhindert werden kann, ist freilich zu bezweifeln, sollte es tatsächlich wider Erwarten dazu kommen.

Rechtlich nicht erforderlich, faktisch schon

Wir glauben, dass die BYOK-Option aus rechtlicher Sicht nicht erforderlich ist – im Übrigen auch nicht nach den Vorgaben des Cloud-Leitfadens der Schweizerischen Bankiervereinigung. Dieser lässt die Speicherung des Schlüssels beim Provider zu, verlangt aber, dass der Zugriff auf den Schlüssel unter der Kontrolle des Instituts steht. Ohne hier in die Details zu gehen sind wir jedenfalls im klassischen Setup von Microsoft der Ansicht, dass dies über das Zusammenspiel zwischen der beim Kunden geführten Masterkopie des Active Directory und dem Azure Active Directory, welches festlegt, welcher Benutzer oder welche Ressource auf den Schlüssel zugreifen kann, hinreichend sichergestellt ist. Denn: Wenn Microsoft nicht vertraut wird, dass sie sich an die Zugriffsteuerung durch das Azure Active Directory hält, dann ist auch nicht einzusehen, warum ihr vertraut werden kann, dass der von ihr bereitgestellte (und programmierte) Schlüsseltresor nicht manipuliert ist, ohne Intervention von ihr betrieben wird und über keine Hintertür verfügt. Ohne ein Grundvertrauen darin, dass der Provider sich an die Verträge hält und seine eigenen Systeme nicht zum Schaden seiner Kunden manipuliert, ist ein Outsourcing schon im Ansatz nicht möglich. 

Die Risikobeurteilung erfordert unseres Erachtens letztlich eine Betrachtung des Gesamtpakets, bestehend aus technischen Massnahmen (wie z.B. Active Directory bei Microsoft), organisatorische Massnahmen (wie z.B. Verträge und Audits) und rechtlichen Schranken (wie z.B. der Tatsache, dass auch unter dem US CLOUD Act nicht alles erlaubt ist). Wir gehen trotzdem davon aus, dass die meisten Schweizer Banken die BYOK-Option einsetzen werden, sie als zusätzliche Sicherheitsmassnahme mindestens subjektiv als erforderlich erachtet wird und so zum Branchenstandard wird. Auch in dieser Frage ist anzuerkennen, dass der Antwort alle möglichen Faktoren zugrunde liegen können.

Autor: David Rosenthal

Kategorien: Banken- und Finanzmarktrecht, Data & Privacy, Blog