DSGVO – ja, aber? Ja!

Einige meiner Bekannte betreuen Webseiten von Kunden. Alle berichten von Nervosität bis Panik im Zusammenhang mit der DSGVO. Vor allem kleine Unternehmen schienen mit den Ansprüchen der DSGVO überfordert. Hinzu kamen aber auch externe Berater, deren Motivation für etliche aufwands- und kostenträchtige Ratschläge man wirklich hinterfragen muss. Wie die letzten Artikel in diesem Blog zeigen, bin ich auch selbst als Freelancer von Konsequenzen der DSGVO betroffen. U.a. durch Pauschalverträge, die die DSGVO zum Anlass nehmen, Datenschutz- und Datensicherheitsrisiken auf Externe zu verlagern.

Die DSGVO ist aus solchen Gründen gerade bei Klein- und Kleinst-Unternehmen negativ belastet, weil man insgesamt erhebliche Anstrengungen und Ressourcen in die Umsetzung mancher kleinkariert wirkender und auch strafbewehrter Regeln investieren muss. Es gibt im Lande eine negative Stimmung gegenüber der DSGVO. Auch wir selbst haben geflucht und fluchen. Vergessen wird dabei, dass die DSGVO nur Regeln explizit mit Sanktionen belegt, die bereits vorher galten.

Interessant war in diesem Zusammenhang ein Streitgespräch zwischen einem der Väter der EU GDPR, nämlich Jan Philipp Albrecht, und Sascha Lobo im Podcast des letzteren; s. https://soundcloud.com/user-728223693/albrecht-lobo-und-das-dsgvo. Lobo hebt im Gespräch auf die übertriebene Regulierungssucht der Deutschen ab, die seiner Meinung nach noch Abmahnungen zeitigen würden, und markierte die erheblichen technischen Anstrengungen, die u.a. Blogger, Freelancer etc. belasten oder überfordern würden. Ein interessanter Punkt in der Debatte kam, als Albrecht schließlich auf den eigentlichen Kern der Sache einschwenkte. Ich gebe das verkürzt wie folgt wieder:

Auch Kleinstunternehmer und Privatpersonen müssten sich endlich mal Gedanken dazu machen, an welcher Stelle sie durch welche Tools der unkontrollierten Sammlung und Verwertung von Informationen, die beim Besuch Dritter auf den selbst betriebenen Webseiten/Blogs anfallen, durch Google, Facebook und Co. Vorschub leisten.

Zumindest beim bequemen Betrieb einer eigenen Site unter dem Dach von Facebook muss man diese Feststellung nicht weiter erläutern. Es scheint bereits aufgrund der Gescchäftsausrichtung von Facebook klar, dass der Traffic auf solchen Seiten überwacht wird und direkt dem Profiling sowohl der Site-Betreiber als auch der Besucher der Site durch Facebook dient. Facebook selbst macht daraus in seinen Nutzungsbedingungen ja auch keinen Hehl. Das ganze System Facebook lebt offenkundig vom Profiling seiner Nutzer und der Verknüpfung aller erreichbaren Daten zum Nutzerumfeld. Weniger offenkundig ist das u.U. bei Google Analytics. Hier tritt man ja selbst als Profiteur der Sammlung von Daten zu Nutzern und deren Verhalten auf eigenen Web-Präsenzen auf. Dass man damit gleichzeitig aber auch dem Datensammeln von Google selbst Vorschub leistet, verdrängt man dabei gerne.

Aber es gibt noch andere undurchsichtige Bereiche des heutigen Betriebs von Web-Sites: Überprüft man etwa nicht, wie WordPress-Plugins tatsächlich operieren, so unterstützt der eine oder andere Blogger unbeabsichtigt das Datensammeln durch Plugins, die z.T. unter dem Deckmantel von Sicherheit Daten über Besucher und Kommentatoren irgendwohin ins Ausland befördern.

Was habe ich im Zuge der DSGVO selbst gelernt?

Ich habe mich beim Fluchen über so manche Konsequenz der DSGVO selbst gefragt, wo ich dabei eigentlich stehe. Welche der im Lobo-Albrecht-Dialog ausgetauschten Argumente haben für mich ein großes Gewicht? Mir sind dabei mehrere Dinge aufgefallen:

  1. Ich habe angefangen, mich intensiver mit meiner eigenen “Schlamperei” bei der Erstellung von Web-Code auseinander zu setzen. So nutzt mein eigenes Framework Cookies in fragwürdiger, nämlich letztlich unnötiger Weise für einfache
    CMS-basierte Webseiten. Ich hatte bei der Entwicklung die notwendige Nutzung von Cookies für den webbasierten Pflegeprozess und zugehörige Pflegeseiten “der Einfachheit halber” gleich mal pauschal auf die Seitengeneratoren ausgedehnt, ohne die Notwendigkeit an dieser Stelle genauer zu hinterfragen.
  2. Ich habe zum ersten Mal richtig darüber nachgedacht, was eigentlich der Einsatz von Google Analytics bedeutet, wie die zugehörigen Verwertungsklauseln aussehen und welche Verantwortung ich in diesem Prozess für Besucher z.B. dieses Blogs habe. Ja, Google Analytics bietet viel – aber haben wir als Blogger und Webseiten-Betreiber eigentlich das Recht, das Sammeln von Daten durch Google zum Verhalten Dritter (!) ohne Vorwarnung zu veranlassen? Klare Antwort: Nein, das haben wir nicht.
  3. Ich habe mich intensiv mit den Nutzungsbestimmungen von Facebook und Google auseinandergesetzt – und habe leider meine schlimmsten Befürchtungen noch übertroffen gefunden.
  4. Ich habe mal nachgesehen, ob und wie Web-Hosting-Provider (wie etwa 1&1 oder Strato) konkret Log-Daten für gehostete Web-Sites bereitstellen und mich gefragt, in wie weit eine intelligente Auswertung in Kombination mit einer eigenen für den Nutzer verborgenen Datenerhebung über Cookies einen Ansatz von Mini-Profiling zu bestimmten Besuchern ermöglichen würde.
  5. Ich habe mir aufgrund der Strafbewehrung ernsthaft Gedanken darüber gemacht, welches Sicherheitsniveau ich eigentlich im Datenaustausch mit befreundeten Unternehmen leisten und bereitstellen kann. Meine Antworten darauf sind noch unbefriedigend; aber das ist ein aus meiner Sicht wichtiger Prozess, der letztlich den bewussteren und besseren Umgang mit Datensicherheit und Datenschutz auf beiden Seiten fördern wird.

Interessant ist, dass man sich bei einer genaueren Analyse der Anforderungen der DSGVO dem Kern der Frage nähert, wie man heute eigentlich Daten, die einem anvertraut werden, gegenüber dem Zugriff Unbefugter schützen kann. Leute, genau das ist der Kern der DSGVO: Verantwortung für den Schutz von bewusst oder unbewusst anvertrauten Daten Dritter.

Als sicherheitsbewußter Linuxer kommt man dabei schnell auf Grundsätzliches: Was geschieht, wenn ein Einbruch in die eigenen Räumlichkeiten erfolgt? Wie sicher sind dann die dir anvertrauten Daten dann noch? Müsste man hier nicht gerade auf externe Provider mit geschützten Rechenzentren zur Datenhaltung ausweichen?

Oder du wirst gehackt – wie sieht es dann aus? Oder: Dein Laptop mit einer SSD wird geklaut – wie sicher sind Daten, die dort in Krypto-Containern aufbewahrst? Oder: Kann man eigentlich die Nutzung von Betriebssystemen im Kontext geheinzuhaltender Daten verantworten, wenn doch der OS-Hersteller selbst in seinen Nutzungsbedingungen unverblümt ankündigt, mit dem System erfasste Daten auf allen elektronischen Nutzungsebenen aus der EU hinaus auf eigene Server zu befördern? Und hat man sich mal mit Penetration-Testing befasst, stellt sich die Frage, ob nicht Browser und Mail-Clients Haupeinfallstore für Schad-SW sind. Wie geht man mit dieser Erkenntnis eigentlich auf Systemen um, auf denen geheimzuhaltene Daten verarbeitet werden?

Und schon verschiebt sich die Perspektive dahin, wo sie im Zeitalter totaler Vernetzung auch hingehört: Wie bewahrt man eine elektronische Schutzsphäre, wenn Eindringlinge an jeder Ecke auf einen Fehler lauern oder du mit der Nutzung von Internet-Diensten den anbietenden Unternehmen direkte Zugangskanäle zu eigenen Daten und Daten Dritter eröffnest?

Leute, wir alle umgeben uns selbst laufend aus Bequemlichkeit freiwillig mit Systemen, die nicht zuletzt dazu dienen, Unternehmen mit Daten von uns, über uns und über unsere Kontaktpersonen zu versorgen. Diese Datenversorgung dient primär kommerziellen Interessen; aber das angehäufte Wissen über uns alle hat auch das Potential zur
Manipulation ganzer Bevölkerungsgruppen, wie wir im Zusammenhang mit Cambridge Analytics lernen durften.

Die Erstellung von Personenprofilen ist heute eine und in vielen Fällen gar die wichtigste Grundlage des Geschäfts von globalen IT-Konzernen. Man muss überhaupt nicht paranoid sein, um festzustellen, dass wir heute kontinuierliche Datenlieferanten sind – ohne einen Funken Kontrolle darüber zu haben, was genau mit den von uns bereitsgestellten Daten geschieht. Sprich: Durch die Nutzung von Android und zugehöriger Dienste etwa liefern wir laufend Daten – aber wir haben über die Verarbeitung keine Kontrolle. Gehen wir auf eine Website liefern wir eine ganze Menge Daten über uns ab – nicht nur unsere IP-Adresse. Sind verschlüsselte Cookies und Javascript im Spiel wissen wir nicht mehr, was über unsere Interaktion mit den Elementen einer Website erfasst und später verarbeitet wird. Speziell über Cookies werden wir jedenfalls potentiell als elektronische Identität identifizierbar. Diejenigen, de argumentieren, dass ein Serviceprovider im Internet nur genau die Daten verarbeiten kann, die wir ihm sowieso schon liefern, übersieht, dass u.a. erst über Cookies ein zusammenhängendes Bild entsteht – auch wenn wir uns nicht in Services einloggen.

IPs kann man mit Tor und VPN-Diensten ggf. verschleiern. Cookies muss man löschen oder automatisch löschen lassen. Für uns selbst können wir solche Entscheidungen treffen und entsprechende Einstellungen vornehmen – wenn wir denn überblicken, was abläuft. Aber wir tragen auch Verantwortung für die, die unsere Seiten besuchen und dabei z.B. in die Fänge von Google Analytics geraten.

Die DSGVO hat – trotz alle Schwächen ihrer Artikel, aus meiner Sicht nicht das Verbot des Umgangs mit personenbezogenen Daten zum Ziel, sondern das Aufstellen von “Warnschildern”, die Nutzer von Websites zumindest darauf hinweisen, wo sie Gefahr laufen, die Kontrolle über die von ihnen automatisch abgelieferten elektronischen Daten zu verlieren.

Der Kern der DSVO ist – bei aller Unvollkommenheit – dass wir uns darüber bewusst werden, dass wir im Umgang mit Diensten und eigenen Webpräsenzen dabei ggf. auch die Daten unserer Besucher weiterschleusen. Es ist ja in diesen Tagen viel von verabscheuenswürdigen Menschenschleusern zu hören. Wir sollten die DSGVO als Mittel begreifen, uns selbst zu fragen, wo und an welchen Stellen wir Daten zu Personen anhäufen und wie wir dazu beitragen, dass wir selbst zu fragwürdigen Datenschleusern im Interesse von Konzernen werden.

Insofern stehe ich auf der Seite von Jan Phillip Albrecht – und appelliere gleichzeitig für eine Verbesserung von Umsetzungsverordnungen für KMU. Insbesondere Blogger und Freelancer müssen gegenüber pauschalen Ansprüchen und einseitigen Anforderungen zur Risikominimierung und Risikoübernahme besser geschützt werden. Im Spiel Groß gegen Klein muss klar werden, dass die Großen ihren Teil zur Definition und Absicherung von Schutzniveaus für die Verarbeitung von personenbezogenen Daten nicht im Rahmen von Auftragsweiterverarbeitungs-Verträgen auf die Schultern der Kleinen abschieben dürfen. Zu den Großen rechne ich dabei übrigens auch den Staat.

DSGVO, Datenschutz – und manche verdienen mit – ohne das Richtige zu leisten …

Meine Leser wissen, dass mir Datenschutz ziemlich wichtig ist. Aber manchmal könnte man sich die Haare raufen. Da gibt es endlich eine im Kern vernünftige Vorgabe des Gesetzgebers (nämlich die DSGVO) – und schon wird es von einer bestimmten Art von “Datenschützern” verdreht und missbraucht …

So erlebe ich gerade bei einem Kunden, den wir vor einer Weile auf die DSGVO aufmerksam gemacht haben, eine Art panikartiges Verhalten – nicht durch den Kunden selbst, sondern durch dessen externen “Datenschutzbeauftragten”. Es geht um die Erstellung von HTML-/CSS-Codes für statische Webseiten ohne Cookies – mit einer Ausnahme, nämlich Google Analytics. Das hatten/haben gar nicht wir zu verantworten. Vielmehr hat der Kunde auf einer Seite die Einbindung einer Google-Maps-Lagekarte gemäß der technischen Vorgaben von Google verlangt. Der Kunde hat einen klassischen Web-Hosting-Vertrag bei einem ISO 271001-zertifizierten Provider. Alles bestens. Wir erstellen Webseiten-Codes für statische (!) Seiten nach fachlicher Vorgabe und liefern die dem Kunden auftragsgemäß zu. Aus technischer Sicht ziemlich langweilig.

Nun sollen wir gemäß des besagten externen Datenschutzbeauftragten aber einen ADV-Vertrag (Auftragsdatenverarbeitungs-Vertrag) abschließen, weil “wir und nicht (!) der Provider die Web-Seite pflegen würden und durch die Webseite IP-Daten erfasst würden”.

Da hat wohl jemand was in den falschen Hals bekommen. Leider erweist sich selbiger “Datenschutzbeauftragte” als beratungsresistent.

Ihr wisst schon – ADV-Verträge, das sind die Verträge, bei denen es um die Verarbeitung personenbezogener Daten durch Dienstleister im Auftrag eines Auftraggebers geht. Zielvorstellung von zugehörigen Musterverträgen ist (übrigens ganz im Sinne einer Lieferanten-Einbindung in Datenschutz und Security) die Erfassung der Datenart, der Kreis potentiell betroffener Personen, der Kritikalität der Daten, der Reichweite der Bearbeitungsschritte, etc.. Typischerweise werden zweifache Controller (einer auf AG- und einer auf AN-Seite) eingesetzt, Datenschutzbeauftragte benannt und technische Maßnahmen zum Schutz der Daten vereinbart. Pönalen werden für den Fall angedroht, dass der Auftragnehmer mit dem ihm überantworteten Daten Missbrauch betreiben sollte. Alles gut und richtig so.

Ziel der ganzen Geschichte sind in erster Linie Auftragnehmer, die sich für Auftraggeber mit elektronischen Diensten und deren Wartung/Pflege befassen müssen, bei denen z.B. Kundendaten, Bankdaten, Personaldaten etc. erfasst werden. In diesem Umfeld ist das auch alles völlig berechtigt. Das betrifft potentiell Pfleger von Web-Shops, manchmal aber auch Blogs, Personalabrechnungssysteme, Hosting-Provider, etc..

Worum aber geht es in unserem Fall?
Wir erstellen wie gesagt im Zuge von Einzelaufträgen statischen (!) HTML/CSS-Code für ein paar Webseiten nach Vorgaben des Kunden. (Ausnahme: Das kleine Google Analytics-Script für die Maps-Karte). Die einzigen “personenbezogenen Daten”, mit denen wir dabei direkt zu tun hatten/haben, sind dabei die Daten, die im Handelsregister zur Firma veröffentlicht sind und auf den statischen Seiten wiedergegeben werden. Die Zulieferung der von uns erstellten HTML/CSS-Dateien kann von uns per Mail und zip-Datei erfolgen. Wir müssen die nicht mal auf die gehosteten Server hochladen. Mit dem Hosting-Vertrag unseres Kunden haben wir weiter nichts zu tun.

Nun hat der externe Datenschutzbeauftragte aber brav gelernt, dass der Hosting-Provider Zugriffsdaten bzgl. seiner Web-Server und auch bzgl. die Webseiten des Kunden erfasst – u.a. IP-Adressen der Besucher. Wie jeder Hosting-Betreiber halt, der einen ordentlichen Job macht. Wobei gerade der in diesem Fall relevante Provider erfasste IP-Adressen für seine Kunden nur begrenzt und nur verfälscht bereitstellt. Gelernt hat der “Datenschutzbeauftragte” auch, dass Google Analytics womöglich noch mehr Daten sammelt.

Wir haben den Datenschutzmenschen
deswegen schon beim ersten Kontakt darauf aufmerksam gemacht, dass sein und unser Kunde deshalb (aber nicht nur deshalb; man denke etwa an die Mailaccounts) wohl einen ADV-Vertrag mit dem Webhosting-Provider und auch Google braucht. Und dass es entsprechende Hinweise und Erläuterungen in der zu erstellenden Datenschutzvereinbarung für die Web-Site unseres gemeinsamen Kunden geben muss.

Statt dessen will er aber nun einen ADV-Vertrag mit uns, weil ja wir die “Website pflegen würden”. Das sei vom EuGH so geregelt. Und der gute Datenschutz-Mann bezieht sich dabei ausdrücklich auf die ggf. vom Provider und von Google Analytics erfassten IP-Adressen ….

Man fasst es ja nicht! Wir pflegen erstens gar nichts. Wir liefern beim Kunden HTML- und CSS-Code nach Vorgabe ab. Wir können zweitens auf die Elemente des Hosting-Vertrages, die Webserver und auf Log-Daten des Providers nicht zugreifen. Wir wollen das auch gar nicht. Wir haben auch keine Google Analytics Account für die Website unseres Kunden.

Und nun braucht es trotzdem wegen eines Web-Providers, zu dem wir nicht mal Zugang haben, und wegen von Google Analytics erhobenen IP-Adressen einen ADV-Vertrag mit uns? Wo wir von Google Analytics abraten?

Für diese Art von Wahnsinn und technischem Unverstand kann nicht mal Google etwas …

Ich meine: Hier versuchen Leute mit der Not von Kunden in geradezu halsbrecherischer Weise Geld zu verdienen. Leute, die mich kennen, wissen, dass ein ADV-Vertrag mit mir eine fachlich und technisch ausgefeilte Sache werden würde, die sicher mehr als 15 Seiten Vertragstext erfordern würde. Wieviele Stunden würde der externe “Datenschutzbeauftragte” wohl für den Erstellungsmarathon zu welchem Satz abrechnen? Und welchen Sinn hätte im vorliegenden Fall ein solcher ADV-Vertrag für den Kunden?

Wir hätten ja verstanden, wenn der “Datenschutzbeauftragte” aus grundsätzlichen Erwägungen eine Verschlüsselung des künftigem E-Mail-Verkehrs mit unserem Kunden verlangt hätte. Bieten wir natürlich auf OpenPGP-Basis an. Und ggf. eine Lagerung von Vorgabetexten für kommende Webseiten in irgendwelchen Crypto-Containern, falls es denn dabei den jemals um hochsensible Firmeninformationen gegangen wäre. Was alles nicht der Fall ist. Aber nein – er will einen ADV-Vertrag mit uns wegen eines Providers, der nicht unserer ist, und Google Analytics, die IP-Adressen sammeln.

Übrigens: Zu den für den Kunden wirklich relevanten Dingen – nämlich dessen ADV-Verträge mit dem Provider, mit Google, ggf. Facebook haben wir noch nichts gehört. Und eine textliche Vorgabe für eine Datenschutzerklärung, für die wir dann eine statische Website erstellen müssten, wobei wir auch alle anderen Seiten wegen des zugehörigen Link neu generieren würden, haben wir noch nicht bekommen. Sind ja noch 10 Tage Zeit …

Herr, bitte schmeiß mehr Hirn vom Himmel … bitte gleich … vor dem 25.05.2018!

Ein Einzelfall? Schreibt mir doch per Mail oder über Xing, wenn ihr gerade Ähnliches erlebt.

GnuPGP, email and eFail

Some of our clients use OpenPGP to communicate with us via mail. Now, after the last publications on eFail everybody gets nervous.

In general, some people out there – and hopefully not my clients – should indeed become nervous – if they use problematic email programs and/or handle them stupidly. In addition, there must be a chance of real and capable man-in-the-middle-attackers on the Internet – as e.g. secret or intelligence services – to perform and master the special attack vectors of eFail. (Actually, I do not care about the problems of bad guys out there misusing encryption for evil. I care about my business clients …).

But, my dear clients: It is not the encryption mechanism of PGP or OpenPGP in itself which fails! It is partially the stupid default settings in some email programs (regarding HTML/Javascript-execution). Such settings can and should be be changed. And partially there are flaws regarding the structuring of emails which can be used against encrypted PGP mails.

But all of this can be mitigated by short term measures – and, astonishingly for myself, some basic rules coincide with what I am not getting tired to say to my clients:

  • Forbid HTML/Rich text in your email client programs. It is a source of evil. Never ever open HTML-parts of a mail. Do not click on Links. Forbid automatic loading of remote pictures and alike.
  • Install OpenPGP in your desktop environment and decrypt your messages in a non HTML-capable environment outside your eMail clients.
  • Use Kmail or Evolution with PGP.
  • And of course: Use Linux – where GnuPGP/OpenPGP comes along as basic equipment of most user environments and does not require fiddling with external programs as on (some) Windows systems.

Properly used PGP in its Opensource variants still is a secure way of exchanging emails. And, please, remember:

If your whole desktop or PC/laptop/server-environment is under attack and hacked no encryption will help you when you decrypt/encrypt in such an environment.

So: Do not panic. Be clear about what the real threats are and where they potentially may come from! Follow some simple basic rules. PGP-based encryption is only one brick in a secure exchange of information. Other bricks may be much more and directly vulnerable from the beginning.

Get more information here:
https://thehackernews.com/2018/05/efail-pgp-email-encryption.html
https://efail.de/
https://efail.de/efail-attack-paper.pdf
Bruce Schneier on Details on a New PGP Vulnerability

And by the way: There are other aspects of PGP which deserve some interest with respect to intelligence services and/or economic espionage:
https://motherboard.vice.com/en_us/article/ezpxan/pssst-your-pgp-is-leaking