Wie setzt man GDPR technisch um?

Wie setzt man GDPR technisch um?

GDPR (oder Datenschutzgrundverordnung DSGVO) ist zurzeit in aller Munde. Dies, weil einerseits in der EU die zweijährige Übergangsfrist im Mai dieses Jahres abläuft und die neuen Regelungen dann auch mit Bussen durchgesetzt werden können. Andererseits ist ein entsprechender Entwurf eines verschärften Gesetzes in der Schweiz in den Räten und könnte auch schon 2018 in Kraft treten. Gefordert werden Privacy by Design und Privacy by Default, und grössere Verantwortung für Datenhalter.

Als Entwickler versucht man natürlich mitzuverfolgen, was neue Gesetze für die eigene Arbeit mit Personendaten bedeutet. Betroffen von der Thematik ist sicher eine Mehrheit von uns, wenn man bedenkt, dass schon jedes Login aus Personendaten besteht. Die Datenschutzthematik an sich ist für Entwickler ja nichts Neues. Es gilt als Binsenwahrheit, dass man Passwörter nie direkt, sondern nur als Hashes abspeichert. Oder dass verschlüsselte Übertragung per HTTPS für E-Commerce Pflicht, und eigentlich im Allgemeinen sinnvoll ist. Privacy by Design und Privacy by Default gehören bei uns implizit zur Berufsethik.

Wer zu GDPR recherchiert, findet eine Fülle von Informationen, Handlungsanweisungen, Beratungsangeboten und Tools gerichtet an Managements. Dabei werden fast ausschliesslich die organisatorischen Aspekte des Datenschutzes beleuchtet: Es geht um Prozesse, Projekte, Stellen und Verantwortlichkeiten und Audits. Standards wie ISO 27001 versprechen bessere Compliance.

Eher wenig Informationen finden sich aber zur Technologie selber. Wer die genannten (durchaus sinnvollen) Management-Hilfen nämlich anwendet, und ein Security- oder Privacy Assessment durchführt, ist immer noch hochgradig von der eingesetzten Technologie abhängig. Es macht beispielsweise einen gewaltigen Unterschied, ob Passwörter mit adaptiven Algorithmen wie bcrypt gehasht werden oder mit Relikten wie md5.

Natürlich macht es wenig Sinn, konkrete technologische Standards in Gesetzten verankern zu wollen. Die Lebenszyklen dieser beiden Welten sind einfach zu unterschiedlich.

Setzt sich ein Unternehmen im Rahmen von Audits oder fortwährenden Prozessen mit der physischen und logischen Datenspeicherung und Datenflüssen auseinander, ist dies erst einmal ein Schritt vorwärts. Im Cloud-Zeitalter sind wir nämlich allesamt, ob wissend oder unwissend, Täter in Bezug auf Datenschutzverletzungen.

Eine implizite, aber wichtige technische Anforderung ergibt sich durch die (auf den ersten Blick eher organisatorische) Meldepflicht bei Personal Data Breaches. Solche müssen innert 72 Stunden bei einer öffentlichen Stelle gemeldet werden. Zusätzlich zu dieser kurzen Frist ist auch die erstaunlich breite Definition von Data Breaches eine Herausforderung: Neben der ungewollten Veröffentlichung von Daten (z.B. der klassische Diebstahl von Kreditkartennummern durch Hacker) gilt alles, was die Integrität von Personendaten kompromittieren kann, als Data Breach.

Der Datenhalter ist also auch dafür verantwortlich, dass Daten sich nicht ungewollt ändern oder verlorengehen, oder dass Unbefugte keinen Zugriff erhalten. Solche Breaches schon nur zu erkennen, kann herausfordernd sein, insbesondere wegen der vielen Abstraktionsschichten, die heute ein Informationssystem hat. Welcher (datenbankorientierte) Entwickler hat denn noch die volle Kontrolle darüber, was mit den einzelnen Bits auf der Festplatte oder im Speicher passiert? Wer hat alle Backdoors der Hersteller im Überblick? Zwangsläufig vertrauen wir auf Standards, Abstraktionen, definierte Schnittstellen und deren Einhaltung. Und damit auch immer auf Hardware und Code von Dritten.

Diese Dritten konnten uns in den letzten Jahren mit Cloud-Diensten vieles abnehmen, was sich auch auf die Entwicklungskosten und Produktqualität ausgewirkt hat. Allerdings muss man sich dann unter Umständen einmal der Frage „Wo leckt die Wolke?“ stellen, als Kehrseite dieser Medaille. Man fragt sich zu Recht, ob er Einsatz von Closed Source Software in diesem Kontext überhaupt noch vertretbar ist.

Trotzdem müssen wir nicht gleich den Teufel an die Wand malen. Es ist sicher auch für uns ein Fortschritt, wenn Unternehmen auch einmal von einer anderen Seite auf die Thematik sensibilisiert werden, die ihnen ein bisschen mehr klarmacht, dass Security ein Thema in ihrem eigenen Interesse ist. In der Praxis wird Security leider immer noch allzu häufig als Anliegen der Entwicklung wahrgenommen und als Luxus abgehandelt.

Die Branche wird mit grosser Wahrscheinlichkeit einen Weg finden, die Problematik der Verantwortlichkeit in komplex geschichteten Systemen pragmatisch zu lösen. Ein denkbares Mittel wären Zertifizierungen von Infrastruktur-Dienstleistern, um die Verantwortung auch fair auf der Wertschöpfungskette zu verteilen.

Bis sich ein solches Gleichgewicht eingestellt hat und auch die rechtliche Situation in der Schweiz klarer wird, empfiehlt es sich für die Entwicklung, auf der vorsichtigen Seite zu bleiben. Folgende einfache Triage könnte helfen:

• Wo Personendaten zentral sind, werden Systeme mit entsprechend hohem Security-Aufwand gebaut, was auch entsprechende Kosten nach sich zieht. Zentral ist ein gutes Monitoring und in diesem Fall möglichst wenig Abhängigkeiten zu Diensten, Infrastruktur und Software von Dritten.
• Wo Personendaten eher eine Nebenrolle spielen, sollte die Verantwortung des Datenhalters an dafür besser gerüstete Dienste abgegeben werden (z.B. Identity Provider). Wenn eine Anwendung weitgehend ohne Personendaten auskommt, können diese auch nicht kompromittiert werden. Dabei helfen Protokolle ohne Zustand (stateless), wie JSON Web Token (JWT)

So oder so gilt es in nächster Zeit, die Augen offen zu halten. Die grobe Richtung ist zwar vorgegeben, die entscheidenden Details werden sich erst noch zeigen.

Wer agil bleibt, und auch seine Architektur agil hält (z.B. mit Microservices), hat in dieser unklaren Situation mehr zu gewinnen als zu verlieren.

Das Wichtigste zum Schluss: Open Source sollte immer erste Wahl sein. Wer nämlich nicht im Detail nachschauen und verstehen kann, was der Code genau mit den Daten anstellt, widerspricht das dem Prinzip Privacy By Default diametral.

Gerne beraten wir Sie oder setzen Ihre Vorgaben diesbezüglich um.