Experten-Blog

Exzellenter Datenschutz in der Cloud durch klare Trennung von Zuständigkeiten

Public Clouds bieten immer wertvollere Services, aus denen sich mit wenig Aufwand anspruchsvolle Webapplikationen konstruieren lassen. Was aber ist mit dem Datenschutz? Die Sensibilität in der Bevölkerung für dieses Thema ist in den letzten Jahren kontinuierlich gestiegen. Insbesondere Unternehmen mit sensiblen Daten wie Banken, Versicherungen oder öffentliche Auftraggeber müssen den Schutz persönlicher Daten der Anwenderinnen und Anwender sicherstellen.

Wir zeigen einen bewährten Architekturansatz, welcher private und öffentliche Daten trennt und so die hohen Ansprüche an den Datenschutz erfüllt.

Cloud Services fordern den Datenschutz heraus

Services aus Public Clouds wie CDNs, Websuchen, Bild- und Medienverarbeitung, AI, Push-Meldungen oder Infrastrukturdienste für das Betreiben von Applikationen wie Amazon AWS sind mittlerweile unverzichtbarer Bestandteil moderner Weblösungen. In wenigen Fällen ist ein vollständiger On-Premises-Betrieb oder der Betrieb in einer Private Cloud ökonomisch sinnvoll. Dies gilt insbesondere für datensensible Unternehmen und öffentliche Auftraggeber, die sparsam mit den Mitteln haushalten, gleichzeitig aber ein maximales Mass an Datenschutz erreichen müssen. Bei ihnen stellt sich die Frage: Wie lassen sich Services der Public Cloud nutzen und gleichzeitig die Anforderungen des Datenschutzes gewährleisten?

Datenschutz durch planvolle Serviceorientierung

Der Schlüssel liegt in einer klaren Aufteilung von Zuständigkeiten und der Entkopplung der Lösungsbestandteile. Hierzu werden mehrere Best Practices kombiniert. Die Lösung wird als Komposition einzelner Services entworfen. Die Auftrennung der Services erfolgt aus der Business-Perspektive nach dem Prinzip «ein (digitaler) Service pro (Business-) Service». Daraus resultieren klare Zuständigkeiten hinsichtlich der Datenverarbeitung.

Ein Beispiel:

Ein User-Service stellt Identitätsmanagement (IAM) und Profile zur Verfügung und verarbeitet Personendaten. Alle anderen Services müssen die User nicht persönlich kennen, sondern erhalten anonyme Informationen – beispielsweise zur Personalisierung von Inhalten. So muss nur der User-Service On-Premises oder in einer private Cloud betrieben werden, während andere Services aus der Public Cloud stammen dürfen, da diese keine schützenswerten Daten kennen.

Dieses Prinzip ist dann besonders gut umsetzbar, wenn die Komposition der Daten im Client der User – beispielsweise im Webbrowser oder einer App – erfolgt. So ist sichergestellt, dass die persönlichen Daten nur direkt zwischen den Usern und den entsprechenden Services ausgetauscht werden. Voraussetzung für diese Komponierbarkeit ist, dass die Services über Web-Schnittstellen zugänglich sind (Client-Facing) und ein portables, anonymisierbares Authentifikationsverfahren eingesetzt wird, so dass sich die User gegebenenfalls direkt gegenüber den Services ausweisen können, ohne dass diese miteinander kommunizieren. Wir setzen hier in der Regel auf REST-Schnittstellen und JSON Web Token (JWT) als etablierte Standards. Auf diese Weise müssen sich die User nur gegenüber einem Service ausweisen, alle anderen Services vertrauen der vom User-Service bescheinigten Identität, welche keine persönliche Daten beinhalten muss.

Die Serviceorientierung bietet hier aus Datenschutzsicht sogar Vorteile gegenüber traditionellen Applikationen: Die klare Aufteilung von Zuständigkeiten führt zu einer besseren Kontrolle des Datenflusses und erlaubt es, Investitionen gezielt in relevante Services zu tätigen. Gleichzeitig erhalten alle Services nach dem Prinzip der Datensparsamkeit nur genau die Informationen, welche sie benötigen.

Eine Besonderheit stellen Situationen dar, in welchen bereits die Tatsache, dass jemand auf einen Service zugreift, schützenswert ist. Auch hier lassen sich Public-Cloud-Dienste verwenden. Hierzu wird ein Proxy zwischen die User und alle Public Clouds geschaltet. Der Proxy verbirgt unter anderem die IP-Adresse der User vor den Services der Public Cloud.

Ein ähnliches Lösungsmuster ist das sogenannte Backend-For-Frontend-Prinzip (BFF-Prinzip). Hier tritt eine Applikation an die Stelle des Proxies. Sie beantwortet Useranfragen dynamisch und verwendet im Hintergrund die entsprechenden Services. Auf diese Weise interagieren die User nur mit einem Dienst – dem Backend-For-Frontend. Dieser Ansatz ist auch dann sinnvoll, wenn Dienste ihre Schnittstellen nicht direkt gegenüber den Usern öffnen können.

Praxisbeispiel SwissPass Smile

Der oben genannte Ansatz hat sich in der Praxis bereits mehrfach bewährt. Ein Beispiel ist die Plattform SwissPass Smile – das Familien- und Jugendprogramm der Schweizerischen Bundesbahnen SBB. Diese Plattform verfügt mit Contentful über ein modernes API-First Headless CMS, welches ausschliesslich als Cloud-Service zur Verfügung steht. Die im CMS redaktionierten Inhalte sind grundsätzlich für die Öffentlichkeit bestimmt und somit nicht schutzbedürftig. Die User von SwissPass Smile können sich zusätzlich mittels SwissPass Login registrieren und persönliche Daten – beispielsweise ihre Familienkonstellation – hinterlegen. Hierzu werden die Services der Public Cloud mit containerisierten Services im ISO 27001-zertifizierten Schweizer Hosting von Unic ergänzt.

Der Datenfluss persönlicher und öffentlicher Daten ist vollständig getrennt, da die Komposition der Daten erst in der Single-Page Application (SPA) des Users erfolgt. Das CMS kennt die User nicht, sondern erhält lediglich die Usersegmente (beispielsweise Familie oder Jugendliche), um Inhalte personalisiert auszuliefern.

Inhalte, welche individuell an die User angepasst werden, laufen über einen dedizierten Service (in der obigen Grafik als Content-Service bezeichnet) in der Private Cloud. So ist sichergestellt, dass die Daten der User zu keinem Zeitpunkt über die Public Cloud fliessen.

Die Lösung profitiert enorm von der direkten Verwendung der CMS APIs (Content Delivery API) für alle öffentlichen Daten, Assets und Videos: Die Single Page Application kann so ohne Backend-Aufwände direkt auf einem bestehenden, gut dokumentierten Cloud-Service aufbauen, was Entwicklungsaufwand und Komplexität deutlich reduziert.

Fazit

Das Verwenden von Services aus der Public Cloud ist in der Regel gut mit hohen Datenschutzanforderungen vereinbar und kann sogar zu einer Stärkung des Datenschutzes führen. Voraussetzung sind eine klare Aufteilung in Zuständigkeiten und die entsprechende Modellierung der Lösung in Form öffentlicher und nicht öffentlicher Services sowie die Verwendung bewährter Mechanismen zur entkoppelten Authentifikation von Usern.

SBB Viel erleben mit SwissPass Smile

SwissPass Smile ist das Mobilitäts- und Freizeitprogramm des öffentlichen Verkehrs für Familien und Jugendliche. Es bietet exklusive Angebote mit Partnerunternehmen, ÖV-Freizeitinspirationen sowie Unterhaltung unterwegs als Gesamtreisepaket an.

MySwitzerland.com: Eine Architektur wie ein Schweizer Uhrwerk

MySwitzerland.com beeindruckt mit einer unglaublichen Reichhaltigkeit an Informationen zum Reiseland Schweiz. Die vernetzte Content-Hub-Plattform mit zahlreichen Daten-Import und -Export-Schnittstellen zu Umsystemen funktioniert wie ein Schweizer Uhrwerk. Daniel Rey, Expert Application Architect, hat die Konzeption und Realisierung der technischen Architektur verantwortet. Im Interview erzählt er, welche Überlegungen zur Lösung geführt haben und wie die verschiedenen Systeme zusammenspielen.

Contract Driven Development verbindet Frontend und Backend

Konzepte und Ideen zu Headless CMS und den möglichen Anwendungsfällen sind derzeit in aller Munde. Für unser Sitecore-Team begann die Reise in diese Welt mit der Einführung von Sitecore Javascript Services JSS für die neue Multisite-Plattform für den Flughafen Zürich. Tobias Studer hat das Neuland Schritt für Schritt erschlossen und gibt einen Einblick in die Überlegungen und die Herausforderungen, welche die finale Lösung geprägt haben.