Der Datenschutzbeauftragte sagt immer kurz vor dem Release, dass irgendwas nicht erlaubt ist. Dann wird es richtig teuer, wie bei jedem späten Umbau der Architektur. Doch solche Schmerzen lassen sich leicht vermeiden, wenn einige wenige Prinzipien schon ab dem Beginn des Entwicklungsprozesses berücksichtigt werden.

Beim Datenschutz steht die Softwarebranche gedanklich ungefähr da, wo sie bei der Sicherheit vor zehn Jahren stand. Nach der Featureimplementierung bringt irgendjemand das Thema auf und dann wird hektisch gepatcht. Oder das Thema wird wegignoriert, bis ein Datenleck es wieder in Erinnerung bringt – zu spät. Zwar bieten erste Hochschulen Privacy Engineering als Teil von Masterstudiengängen an. Doch es fehlt ebenso an etablierten Standards, wie an nützlicher Toolunterstützung.

Dabei gibt es gute Gründe, den Datenschutz nicht links liegen zu lassen. Auf der einen Seite stehen Risiken, denn Datenschutz ist Gesetz. Verstöße können teuer werden, denn es drohen Bußgelder und Schadenersatzforderungen. Inzwischen werden solche Risiken bei Finanzierungsrunden oder Unternehmensübernahmen geprüft. Zudem schadet mangelnder Datenschutz der Reputation. Vielleicht wäre die Luca-App ja erfolgreich, wenn sie nicht einige, vollkommen vermeidbare Patzer in diesem Bereich enthielte.

Auf der anderen Seite stehen Chancen bei Kunden, die Wert auf die Privatsphäre legen. Der Messenger Signal – ursprünglich ein Nischenprodukt – hat sich vor allem wegen des Datenschutzes zu einem der Meistgenutzten entwickelt. Und manche Bereiche wie Schulen gewichten Datenschutz bei der Systemauswahl sehr hoch.

Dabei führt das deutsche Wort Datenschutz immer wieder zu Missverständnissen. Es geht nicht um den Schutz der Daten, damit befasst sich die Informationssicherheit. Vielmehr geht es um den Schutz der Personen vor Schäden, die durch die Nutzung ihrer Daten entstehen können. Offensichtlich überlappen sich diese beiden Bereiche stark, doch wer nur DevSec betreibt, macht noch nicht automatisch alles richtig.

Rechte von Menschen

Der Bezug zur Person zeigt schon, dass es nicht um jede Art von Daten geht, sondern nur um die, die sich auf einen konkreten Menschen beziehen. Ganz offensichtlich gehört dazu alles, was diesen Menschen identifiziert, zum Beispiel der Name, ein Bild oder ein Video, auf dem er zu sehen ist. Nicht ganz so offensichtlich ist, dass etwa auch die Anschrift in die Kategorie der Daten fällt, anhand derer man Personen leicht identifizieren kann. Weil es gar nicht wenige Häuser gibt, in denen nur ein Mensch lebt, kann die Anschrift eindeutig auf diesen verweisen. Ähnlich verhält es sich z. B. mit der Geräte-ID eines Smartphones, das ja auch ein sehr persönlicher Gegenstand ist.

Dem stehen anonyme Daten gegenüber, die nicht mit einer Person in Verbindung gebracht werden können. Die gute Nachricht: Anonyme Daten sind außerhalb des Geltungsbereichs des Datenschutzes, es gelten keine der folgenden Regeln. Die schlechte Nachricht ist allerdings, dass Datensätze oft weniger anonym sind, als es auf den ersten Blick erscheint. So ist eine einzelne Geo-Koordinate aus Länge und Breite mit Sicherheit anonym. Doch durch einen GPS-Track, der ein Bewegungsmuster enthält, lässt sich wahrscheinlich auf die Person schließen, etwa weil sie sich besonders häufig zu Hause aufhält. Oder wenn zu einer einzelnen Geo-Koordinate die Information bekannt ist, dass sie aus der Routenplanung eines ambulanten Pflegedienstes stammt: Dann handelt es sich wahrscheinlich um eine Adresse, die wie oben gezeigt identifizierend ist, und zwar von einer pflegebedürftigen Person. Als Faustregel gilt: Je reichhaltiger ein Datensatz ist, desto wahrscheinlicher kann die Anonymität gebrochen werden.

Zwischen den anonymen und den identifizierenden Daten stehen die pseudonymen. Sie enthalten keine direkt identifizierenden Merkmale, lassen sich aber mit einer zusätzlichen Information einer Person zuordnen. Typische Beispiele sind Autokennzeichen oder IP-Adressen, bei denen der Personenbezug aus dem Provider-Log kommt. Solche Situationen gibt es häufig auch innerhalb von Systemen. Wenn im Shopsystem die Kundenaccounts (inklusive Namen) und die Bestellungen in separaten Tabellen liegen, von denen die zweite nur auf die erste verweist, sind die Bestellungen pseudonym, da die Accountdaten zur Personalisierung erforderlich sind.

Normalerweise unterscheiden Datenschützer bei ihrer Bewertung nicht zwischen identifizierenden und pseudonymen Daten. So bewerten Gerichte IP-Adressen derzeit grundsätzlich als schützenswert. Pseudonyme Daten müssen also genauso behandelt und geschützt werden wie direkt personenbezogenen.

Aus technischer Sicht ist Pseudonymität hingegen ein Graubereich, denn die Zuordnung zu einer Person kann unterschiedlich kompliziert sein. Bei den erwähnten zwei Tabellen in einem Shopsystem ist sie trivial. Doch wenn es mehrerer Stufen bedarf und die nötigen Informationen unter der Kontrolle verschiedener Organisationen stehen, kann sie nahezu unmöglich sein. In solchen Fällen kann man manche Datenbanken auch als „faktisch anonym“ betrachten. Doch diese Einschätzung sollte unbedingt vor der Implementierung mit den Datenschützern abgeklärt werden.

Dennoch ist das Konzept der pseudonymen Daten äußerst nützlich. Denn pseudonyme Daten lassen sich oft ganz leicht zu anonymen machen, indem man die Referenzen zu den identifizierenden Daten kappt. Neben dem Löschen der Verweise eignet sich dazu auch eine partielle Kopie der Daten, in die die Referenzinformationen nicht mitdupliziert werden.

Diese Anonymisierung funktioniert jedoch nur, wenn schon beim Systemdesign die identifizierenden Daten sauber isoliert werden und die Referenzen so gestaltet werden, dass ihr Fehlen das System nicht beeinträchtigt.

Mein Datenschatz

Im Datenschutz geht es also um alle nicht eindeutig anonymen Daten. Wie damit umzugehen ist, ...