DSGVO: Risiken beim Einsatz von Drittanbieter-Tools

Im Zuge der DSGVO ist der Einsatz externer Werkzeuge nicht einfacher geworden, denn es gibt einige Aspekte zu beachten, auch hinsichtlich Privacy.

In Pocket speichern vorlesen Druckansicht 46 Kommentare lesen
Risiken beim Einsatz von Drittanbieter-Tools

(Bild: BeeBright / Shutterstock.com)

Lesezeit: 17 Min.
Von
  • Jan Thiel
Inhaltsverzeichnis

Spätestens seit dem Einführen der DSGVO im Mai 2018, den wegweisenden Urteilen des EuGH sowie der jüngsten Entscheidung des BGH zur Opt-in-Pflicht für Cookies und Datenübertragungen an die Server von 3rd-Party-Providern, ist es für Entwicklerinnen und Entwickler webbasierter Anwendungen unvermeidbar zu wissen, was mit dem Code und den Daten passiert. Bußgelder und Abmahnungen durch Wettbewerber sind eine Drohkulisse, die inzwischen durchaus realistisch scheint, sobald sich die Datenschutzbehörden sortiert haben und tatsächlich in die aktive Prüfung übergehen.

Nachdem es viele Jahre ratsam und auch gängige Praxis war, externen Code aus stets verfügbaren und performanten Content Delivery Networks (CDNs) direkt von Software-as-a-Service-Anbietern zu laden, ist jetzt aufgrund der rechtlich verschärften Umstände die Zeit zum Umdenken gekommen.

Während die vermeintlichen Vorteile der CDN-Einbindung Anwendern einfach zu vermitteln sind und auch Entwickler lediglich eine Referenz auf JavaScript, CSS oder auch Google-Web-Fonts zu integrieren brauchen, sind die Nachteile und Risiken auf den ersten Blick nur schwer ersichtlich.

Die weitverbreitete und oftmals wenig kritisch hinterfragte Installation beliebiger Pakete aus öffentlichen Quellen, wie npm oder zentralen Maven-Repositories, sind weitere Beispiele für den Tanz auf Messers Schneide, den Entwickler tagtäglich für ihre Arbeitgeber eingehen. Stattdessen sollten sich Webentwickler vorab mit Risiken und passenden Vermeidungsstrategien auseinandersetzen, wenn sie sich auf fremden Code aus Drittanbieterquellen verlassen wollen.

Entwickler vergessen gerne, dass die IP-Adresse als personenbezogenes Datum gilt und damit eine Übermittlung an eine dritte Partei die explizite Zustimmung vorab erfordert. Binden Entwickler Ressourcen nun so ein, dass ein externer Server sie lädt, findet unvermeidbar eine Übertragung der IP-Adresse des Kunden statt.

Je nach Art der geladenen Ressourcen fällt es schwer, Besuchern zu erklären, warum sie für den Einsatz einer Schriftart seine IP-Adresse an Google oder andere Dienstleister außerhalb der EU übermitteln müssen, ohne vorher gefragt zu werden. Zumal der Kunde keinen unmittelbar erkennbaren Vorteil davon hat, dass die Dateien von einem fremden Server kommen. Die Pflicht, die Zustimmung des Kunden einzuholen, liegt wiederum bei Entwicklern und Betreibern der Webanwendung und wird bis heute in vielen Fällen rechtswidrig nicht erfüllt.

Herausforderung Data Privacy

(Bild: Romina Borgardt)

Befindet sich Drittanbietercode jedoch integriert in der eigenen Webanwendung, und damit unabhängig von der Zustimmung der Kunden, hat der Code dieselben Rechte und Möglichkeiten wie der Code, der aus vertrauenswürdigen Quellen der Betreiber stammt. Können Entwickler lokalen Code vor einer Ausspielung vergleichsweise einfach prüfen, ist das mit Code aus externen Quellen komplizierter.

Wie bei jedem Risiko gilt es hinsichtlich einer möglichen Datenschutzverletzung, die konkrete Eintrittswahrscheinlichkeit sowie die etwaigen Folgen zu bewerten und einzuschränken. Kommen 3rd-Party-Provider aus der EU, ist die Wahrscheinlichkeit für die Unterstützung datenschutzkonformer Angebote um ein Vielfaches höher, da Anbieter aus der EU denselben rechtlichen Anforderungen unterworfen sind wie das eigene Unternehmen. Kommen die Anbieter aus Drittstaaten wie den USA, ist insbesondere nach dem (erneuten) Ende des Datenaustauschabkommens "Privacy Shield" umso mehr Vorsicht und Sorgfalt geboten. Im schlimmsten Fall holt man sich unwissentlich eine tickende "Datenschutz-Bombe" ins eigene Haus.