DSGVO: Risiken beim Einsatz von Drittanbieter-Tools
Seite 2: Security und fehlerhafter Code
Selbst wenn die eigene Webanwendung gut abgesichert ist, öffnen extern eingebundene Ressourcen einen zusätzlichen und für Angreifer lohnenden Angriffsvektor. Sie können davon ausgehen, dass bei einer erfolgreichen Infektion des externen Drittanbieterservers tendenziell alle Nutzer der dort bereitgestellten Ressourcen die infizierten Versionen beziehen und ausführen.
Da der Code mit denselben Rechten läuft wie der legitime der Entwickler der besuchten Webanwendung, stehen Angreifern alle Türen offen. Die Folgen sind hinlänglich bekannt und reichen vom "harmlosen" Cryptomining über die böswillige Manipulation der Webanwendung bis hin zum diskreten und unauffälligen Diebstahl monetär interessanter Daten. Das können Kreditkarteninformationen, aber auch Passwörter und andere sensible Daten sein.
Lässt man den bösen Vorsatz außen vor, bleibt noch immer das Risiko, dass der externe Code fehlerhaft ist oder falsche Abhängigkeiten mit ausliefert, die wiederum dazu führen, dass die eigene Webanwendung angreifbar oder schlimmstenfalls nicht mehr nutzbar ist. Der Fall von Google aus dem Jahr 2010, als Chrome einen Bug in der Datumsberechnung im produktiven Build enthielt und dadurch eine große Zahl von Date-Pickern "über Nacht" nicht mehr funktionierten, ohne dass ein Fehler auf Seiten der Entwickler und Webanwendungsbetreiber vorlag, macht dies deutlich. Ähnliche Erfahrungen hat sicher jeder Entwickler schon gemacht, der stundenlang nach Fehlern im eigenen Code sucht, die in der Release-Abnahme noch nicht vorhanden waren, nur um festzustellen, dass sie nicht aus dem eigenen Code stammen, sondern externer Code sie verursacht hat.
Performanceengpässe vermeiden
Ein weiterer, leicht zu übersehender Aspekt lautet "blockierende Abhängigkeit". Während lokal gehostete Ressourcen, Pakete, Skripte et cetera von der eigenen Infrastruktur abhängig sind, schaffen 3rd-Party-Ressourcen eine zusätzliche Abhängigkeit. Die kann sowohl den Entwicklungsprozess als auch den produktiven Betrieb beeinflussen.
(Bild: Romina Borgardt)
Die direkte und offensichtliche Abhängigkeit ist die Verfügbarkeit der benötigten 3rd-Party-Ressourcen. Dabei unterscheidet man zumeist binär: die Ressourcen sind entweder verfügbar oder nicht. Sind notwendige Ressourcen nicht vorhanden oder nicht abrufbar, kann das dazu führen, dass neben einem Funktionsverlust der produktiven Anwendung bei direkter Abhängigkeit auch die Entwicklungs- und Build-Prozesse scheitern und stillstehen.
Des Weiteren können langsam ladende Ressourcen, die im <head> extern synchron eingebunden sind, dazu führen, dass eine Webanwendung mehrere Sekunden zum Laden benötigt – mit der Gefahr, dass Anwender oder potenziell interessierte Kunden vorzeitig abspringen. Denn bei den Wartezeiten gilt die Grenze von zwei Sekunden nach wie vor als Schallmauer, die Kunden dazu bewegt, eine Webanwendung zu verlassen, egal wie vielversprechend sie ist.
Sensible Daten schützen
Als Mitarbeiter einer Krankenkasse und Körperschaft des öffentlichen Rechts steht der Autor dieses Beitrags häufig im Zentrum des Interessenkonflikts. Ist der Bestellverlauf im Amazon-Webshop möglicherweise nur bedingt schützenswert, sind Informationen über den Krankheitsverlauf oder auch nur der Verlauf der auf der Webseite einer Krankenkasse abgerufenen Krankheitsbilder hingegen hochgradig sensibel. Eine Übermittlung der Informationen in Kombination mit persönlichen Identifikationsmerkmalen wie der IP-Adresse an Dritte sollte in keinem Fall erfolgen.
Genau das ist jedoch der Fall, wenn 3rd-Party-Code unkontrolliert auf Webseiten eingebunden wird und damit auch Zugriff auf den gesamten Verlauf sowie die IP-Adresse der Besucher erhält.
Suchen Nutzer zum Beispiel auf der Webseite einer großen deutschen Direkt-Krankenkasse nach dem sensiblen Thema "Syphilis" wird die Information mit einer Reihe externer Anbieter geteilt – und zwar inklusive der IP-Adresse des Suchenden und aller relevanten Metainformationen, die ausreichen, um einen eindeutigen Fingerabdruck des Suchenden auch über die Grenzen von Cookies und Co. hinweg zu erstellen. Die Direkt-Krankenkasse teilt die Informationen, die im Rahmen einer Suche nach kritischen Gesundheitsthemen anfallen, zum Beispiel ohne Opt-in und ohne vorherige warnende Information mit den folgenden Anbietern: Google (Tag Manager), Typekit und Cookiebot.
(Bild: Romina Borgardt)
Für diese 3rd-Party-Anbieter sind Nutzer dadurch transparent. Betreiber der Webanwendung begeben sich in eine Grauzone. In dem konkreten Beispiel sind lediglich einige der Anbieter in der Datenschutzerklärung erwähnt und sicherlich gibt es – nicht öffentlich einsehbare – Verträge, die den Einsatz der gesammelten Daten im Rahmen des "EU-US Privacy Shields" reglementieren. Was die Anbieter jedoch letztlich mit den Daten anfangen, kann kein Betreiber nachvollziehen oder dem Endkunden garantieren. Da selbst der EuGH das Schutzniveau der US-Anbieter nicht nachvollziehen kann und von einem unkontrollierten Datenabfluss an Sicherheitsbehörden ausgehen muss, wurde auch das Privacy-Shield als Grundlage zur Datenübertragung inzwischen "vom EuGH für nichtig erklärt (Schrems gegen Facebook)".
Wie können sich Betreiber einer Webanwendung nun absichern, wenn das Vertrauen in die Versprechen oder vertraglichen Regelungen nichts taugt? Die einfache Lösung ist der vollständige Verzicht auf externe Tools – zumindest auf solche von Anbietern, die außerhalb des europäischen Wirtschaftsraums ansässig sind. Da dieses Vorgehen jedoch häufig zu Unverständnis und Frust bei Marketing-Kollegen und Vorgesetzten im eigenen Unternehmen führen dürfte, muss eine echte technische Alternative her.
