Der Themenkomplex “Datenverarbeitung in unsicheren Drittstaaten” hat bei Unternehmen zu einer massiven Rechtsunsicherheit gesorgt. Wenn man es 100% genau nimmt, dann dürften Cloud-Dienste von Amazon oder Microsoft überhaupt nicht mehr eingesetzt werden, mit unabsehbaren Auswirkungen auf die heimischen Unternehmen und die Verwaltung. Eine verlässliche Rechtsprechung dazu gibt es aber nicht, und so bleibt es vorerst wohl beim bekannten Lavieren rund um dieses Thema herum.
Dieser Artikel kann zwar keine Antwort auf die Frage liefern, was erlaubt ist und was nicht, aber er kann Ihnen dabei helfen, die besagte Datenverarbeitung in unsicheren Drittstaaten auf einer Website nachzuweisen, was auch nicht immer leicht ist.
Kriterien für Datenübertragung
Wenn ich einen Dienst wie Google Mail verwende, und dieser meine Emails auf einem Server in den USA speichert, handelt es sich ganz offensichtlich um eine Verarbeitung personenbezogener Daten im Ausland.
Der Begriff muss aber weiter gefasst werden, denn bei jedem Kontaktieren eines Servers durch einen Netzwerk-Request wird die eigene IP-Adresse übertragen, die als personenbezogene Information gilt. Ob der Server selbst in den USA steht, spielt wegen des CLOUD-Acts keine Rolle. Im Rahmen eines Website-Checks müssen Sie deshalb die folgenden drei Aspekte untersuchen:
Hosting der Website
Hat eines der Unternehmen, das in irgendeiner Form mit der Hosting-Infrastruktur zu tun hat, seinen Sitz in einem unsicheren Drittstaat? Oder steht der Server, der die Website ausliefert, in einem unsicheren Drittstaat? Wie diese Überprüfung funktioniert, erfahren Sie weiter unten.
Betreiber externer Dienste
Analog zum Hosting der Website stellt sich für alle eingebundenen Dienste die Frage: Wo hat das Unternehmen, das den Dienst betreibt, seinen Hauptsitz? Und zusätzlich: steht der Webserver des Dienstes in einem unsicheren Drittstaat, oder sind Unternehmen, die die Infrastruktur betreiben in einem unsicheren Drittstaat?
Den Hauptsitz des Unternehmens zu ermitteln ist keine technische Aufgabe, dafür reicht ein Blick ins Impressum oder (wenn nicht vorhanden) eine Recherche durch Google & Co. Ein Beispiel für die technische Prüfung lernen Sie weiter unten kennen.
Empfänger von Formulardaten
Wenn über ein Formular Daten abgeschickt werden, dann gehen sie möglicherweise an einen externen Dienst – für diese gelten dann die gleichen Fragen wie oben. Wie diese Prüfung funktioniert beschreiben wir in einem separaten Artikel (der sicher bald erscheint 🙂
Prüfen des Server-Standorts und der Infrastruktur
Bei jedem der drei oben genannten Aspekte kann die Infrastruktur nach der gleichen Methodik überprüft werden. Zur Vorbereitung müssen wir uns vorab die Möglichkeiten vor Augen halten, mit denen aktuelle Web-Anwendungen und die eingebundenen externen Dienste betrieben werden können.
On-Premise-Hosting
Beim “On-Premise”-Hosting handelt es sich um den Website-Betrieb in einem Rechenzentrum. Der Standort – oder zumindest das Land – des Webservers entspricht dabei dem des Rechenzentrums, und meist auch dem des Providers. Dabei ist mit “Webserver” natürlich kein einzelner Rechner gemeint, sondern die gesamte verbundene Infrastruktur (Router, Load-Balancer, Webserver-Cluster etc.).
Meist ist auf den Servern des Providers ein Content-Management-System (wie etwa WordPress) oder ein Shopsystem installiert. Die meisten Unternehmen betreiben ihre Website auf diese Weise, auch decareto.
Platform as a Service
Seit einigen Jahren ist “Platform as a Service” (PaaS), auch als Cloud-Hosting bezeichnet, sowohl bei Website-Betreibern als auch bei Anbietern von externen Diensten sehr populär. Der Grund ist die große Flexibilität und leichte Skalierbarkeit dieses Verfahrens. Die großen Provider wie Amazon AWS, Microsoft Azure oder Google Cloud Platform betreiben weltweit Rechenzentren, und ermöglichen einen performanten und ausfallsicheren Betrieb auch bei sehr großen Besucherzahlen.
Datenschutzrechtlich ist diese Option aber zumindest nicht völlig unproblematisch, da sowohl das Rechenzentrum des Cloud-Anbieters als auch dessen Hauptsitz in einem unsicheren Drittstaat lokalisiert sein können. Da fast alle Anbieter aus den USA stammen ist letzteres sogar sehr wahrscheinlich.
Software as a Service
Anstatt selber eine Software wie WordPress in einem Rechenzentrum zu hosten, können Unternehmen mittlerweile auf Website-Baukästen wie Jimdo oder Cloud-Shopsysteme wie Shopify zurückgreifen. Diese Unternehmen betreiben ihre SaaS-Anwendung meist auf gemieteter Infrastruktur, wie der von Amazon AWS oder Google. Hier sind also der Standort des Webservers, der Hauptsitz des SaaS-Unternehmens und der Hauptsitz des Infrastruktur-Betreibers relevant.
Content-Delivery-Networks
Um eine stark frequentierte Website bzw. einen Dienst ausfallsicherer, schneller und kostengünstiger zu betreiben setzen Unternehmen oft sogenannte “Content Delivery Networks” (CDNs) von Firmen wie Akamai, Cloudflare oder Fastly ein. Diese haben eine große Zahl an Zwischenspeicher-Servern weltweit im Einsatz.
Wenn ein Benutzer auf eine solche Website zugreift, dann baut er keine Verbindung zum eigentlichen Webserver auf, sondern zu einem Server des CDNs. Dieser hat die Daten vorab vom Ursprungs-Server geladen. Dadurch wird die Last auf dem Ursprungs-Server reduziert, und Daten können schneller zu Benutzern im jeweiligen Land ausgeliefert werden.
CDNs können mit allen drei oben beschriebenen Varianten kombiniert werden, viele SaaS-Anbieter schalten ihrer Software ein CDN vor. So verwendet der deutsche Anbieter Jimdo bspw. die Infrastruktur von Amazon AWS und zusätzlich das CDN des amerikanischen Anbieters Fastly.
Sie sind aber auch ein potentielles Datenschutz-Risiko, das zeigte sich, als der Einsatz von Cookiebot in Verruf geriet, weil das (dänische) Produkt den amerikanischen CDN-Dienstleister Akamai einsetzte (siehe unten).
So ermitteln Sie Serverstandort und Provider
Es ist bemerkenswert einfach, Informationen über einen Webserver zu erhalten. Dazu benötigt man lediglich die IP-Adresse des Servers – den Rest erledigen Online-Dienste, die entsprechende Datenbanken zur Verfügung stellen. Diese Dienste werden bspw. für personalisierte Online-Werbung oder Betrugsprävention eingesetzt – der bekannteste Anbieter ist Maxmind, aber es gibt eine große Zahl derartiger Unternehmen.
Um die IP-Adresse des Servers herauszufinden gehen Sie wie folgt vor:
- Öffnen Sie die zu untersuchende Website, und dafür dann den Netzwerk-Reiter der Chrome Entwickler-Tools.
- Klicken Sie mit der rechten Maustaste auf die Spalten und wählen Sie “Remote Address”
- Anschließend zeigt diese Spalte die IP-Adresse des Servers für jeden einzelnen Request an. Hinter dem Doppelpunkt wird die “Port-Nummer” angezeigt, sie ist 443 für verschlüsselte und 80 für unverschlüsselte Verbindungen. Sie ist für die Untersuchung aber nicht relevant und kann ignoriert werden.
- Für unseren Server decareto.de ist die IP-Adresse 83.138.88.57
Online-Datenbanken zur Analyse der IP-Daten
Es gibt eine ganze Reihe von Diensten, die zu einer IP-Adresse weiterführende Informationen bereitstellen. Für gelegentliche Online-Recherchen sind sie meist kostenfrei. Wir verwenden im nächsten Schritt den Dienst “ip-api”, er ist verfügbar unter ip-api.com.
Geben Sie dort im Eingabefeld die IP-Adresse ein und bestätigen Sie mit Klick auf “Search”. Sie sollten dann folgendes sehen:
- Unter city und country sehen Sie den Standort des Servers, in diesem Fall Bremen.
- Unter isp sehen Sie den Namen des Hosting-Providers, “hostNet”. Es handelt sich hier wie oben erwähnt um ein On-Premise-Hosting bei einem deutschen Provider.
- Das Feld org enthält manchmal weiterführende Informationen, in diesem Fall aber nicht.
Lassen Sie uns eine weitere Website untersuchen:
- Die Entwickler-Tools zeigen hierfür die IP 54.171.81.156
- Eingabe bei ip-api.com ergibt folgendes Ergebnis:
- country: Irland
- isp: Amazon.com, Inc.
- org: AWS EC2 (eu-west-1)
Hier handelt es sich offenbar um ein Cloud-Hosting mit Amazon Web Services. Ein Blick in die Request im Netzwerk-Reiter gibt zusätzliche Anhaltspunkte:
- Es tauchen zwei Domains sehr häufig auf: assets.jimstatic.com und u.jimcdn.com. Wenn Sie die erste Domain im Browser aufrufen, sehen Sie nicht viel, aber genug um das dahinterstehende Unternehmen zu raten:
Diese Website verwendet also den deutschen Website-Baukasten Jimdo, welcher wiederum (auch das haben wir oben schon erwähnt) auf der Infrastruktur von Amazon Web Services läuft. Der Serverstandort ist Irland. Amazon ist jedoch ein US-amerikanisches Unternehmen.
Das Cookiebot-Problem
Das Verwaltungsgericht Wiesbaden hatte am 01.12.2021 den Einsatz des Consent-Tools Cookiebot als nicht zulässig eingestuft, weil es Daten in unsichere Drittstaaten überträgt. Das Urteil wurde zwar vom Verwaltungsgerichtshof Hessen wieder kassiert, es hat aber in der Datenschützer-Community für einige Aufregung gesorgt, weil es die Problematik von Hosting-Infrastrukturen im Ausland deutlich macht.
Das Unternehmen Cookiebot sitzt in Dänemark. Was war also problematisch am Einsatz der Software? Und sind möglicherweise auch andere Dienste europäischer Anbieter betroffen? Um das zu klären, öffnen wir die Website www.bkk24.de, die Cookiebot einsetzt, und identifizieren zunächst die Netzwerk-Requests, die zum Dienst Cookiebot gehören.
- Der im Screenshot zu sehende Request https://consent.cookiebot.com/uc.js gehört der Domain nach zu urteilen zu Cookiebot. Eine weitergehende Recherche diesbezüglich ersparen wir uns…
- Der Server consent.cookiebot.com hat die IP-Adresse 2.16.204.144
- Wir überprüfen sie mit ip-api.com und erhalten folgendes Ergebnis:
- city, country: Hamburg / Germany
- isp: Akamai Technologies
Der Webserver gehört also zum US-Amerikanischen Content Delivery Network Akamai. Datenschutzrechtlich problematisch, auch wenn der physikalische Standort des Servers in Deutschland ist.
Es handelt sich hier um ein Hosting wie oben im Abschnitt “Content-Delivery-Networks” beschrieben. Leider schirmt das CDN den Ursprungsserver ab, es ist also nicht möglich, herauszufinden, wo Cookiebot tatsächlich gehostet wird. Es könnten Server in Dänemark sein, aber genauso gut eine Infrastruktur wie Amazon Web Services.
Wen betrifft das noch?
Man könnte nun auf den Gedanken kommen, sich die Hosting-Infrastruktur anderer europäischer Dienste genauer anzuschauen, zum Beispiel die von Usercentrics. Der deutsche Platzhirsch im Bereich Consent-Management hat im Jahr 2021 mit Cookiebot fusioniert, verwendet man dort vielleicht auch Akamai?
Die folgende Website verwendet Usercentrics, und wir erkennen im Netzwerkreiter die entsprechenden Requests des Dienstes:
- Im Screenshot zeigt der Pfeil auf Requests von zwei verschiedenen Domains, die offenbar zu Usercentrics gehören: api.usercentrics.eu und app.usercentrics.eu.
- Wir untersuchen beispielhaft api.usercentrics.com mit der IP-Adresse 35.241.3.184
- Wir überprüfen sie mit ip-api.com und erhalten folgendes Ergebnis:
- city, country: Kansas City / USA
- isp: Google LLC
- org: Google Cloud
Usercentrics betreibt also sein Produkt auf der Infrastruktur der Google Cloud Platform, und der Serverstandort ist in den USA. Analog zu Cookiebot muss man schlussfolgern, dass das datenschutzrechtlich möglicherweise problematisch ist, zumal Usercentrics ja eigentlich beim Einhalten von Datenschutzrichtlinien helfen sollte.
Autor: Eckhard Schneider
