Ein Protokoll wär‘ toll
PSP Case Study zur DSGVO: Praxisfall 38

DSGVO: Praktischer Fall

Die Huber AG verwendet eine ERP-Software, die sämtliche Veränderungen, die an den dort gespeicherten Daten – ob personenbezogen oder nicht – vorgenommen werden, protokolliert. Im Grunde lautet der Datensatz jeweils: „Datum X wurde in Datum Y geändert durch Z am [Datum, Uhrzeit]“. Für die Huber AG stellt sich die Frage, ob diese Protokolle datenschutzrechtlich vereinfacht gesprochen „zu viel“ oder sogar noch „zu wenig“ sind. Leider lässt sich die Protokollfunktion in der ERP-Software nicht abschalten oder sonst verändern. Auch können in der Software keine automatischen Löschregeln bzw. Löschfristen für derartige Protokolldatensätze festgelegt werden. Allenfalls ließen sich Protokolldatensätze manuell früher oder später (vollständig) löschen. Ein Überschreiben solcher Datensätze mit „Leerdaten“ würde nur seinerseits neue Datensätze über die Veränderung der Protokolldatensätze produzieren.

Protokolldaten werden in der Unternehmenspraxis in erheblichem Umfang generiert. Viele Applikationen erheben ständig Daten darüber, welche Benutzer (bzw. Benutzerkonten) Daten eingeben, verändern, abfragen und löschen. Dabei geht es nicht darum, dass diese Daten – als „Telemetrie-Daten“ – vom Hersteller der Software „abgezogen“ werden, sondern die generierten Daten werden regulär in der Datenbank gespeichert.

Warum sind Protokolldaten gefährlich?

Im Fall 4 wurden Protokolldaten aus der Sicht von Auskunftsansprüchen beleuchtet. Aus derartigen Daten lassen sich allerdings – unabhängig von ihrem primären Zweck, unternehmensinterne Vorgänge nachzuvollziehen – verschiedenste Schlüsse über Beschäftigte ziehen. Daher geht es nicht nur im die „Beauskunftung“, sondern auch um die Frage, ob und in welchem Umfang es solche Daten geben darf bzw. muss. Insbesondere eine Profilbildung kann mit derartigen Daten betrieben werden: Arbeitszeiten, Abwesenheiten, Qualität und Geschwindigkeit von Eingaben etc. können aggregiert und in Beziehung zueinander gesetzt werden. Die Protokollierung von Nutzerdaten ist Gegenstand des Bausteins 43 des Standard-Datenschutzmodells, allerdings nicht so sehr hinsichtlich der „Gefährlichkeit“ bzw. „Ausnutzbarkeit“ solcher Daten (und daher ihrer möglichst sparsamen Erhebung und schnellen Löschung), sondern vor dem Hintergrund der datenschutzrechtlichen Rechenschaftspflicht. Diese Zweckrichtung fassen folgende einleitenden Ausführungen des Bausteins 43 (der die „Orientierungshilfe Protokollierung“ von 2009 ablöst) zusammen:

Die Protokollierung dient der Prüfbarkeit einer Verarbeitung, die in der Vergangenheit stattfand. Zusammen mit der Spezifikation und Dokumentation ist sie eine wesentliche Voraussetzung, um eine Verarbeitung datenschutzrechtlich beurteilen zu können. Prüfbarkeit bedeutet, dass Ist und SollWerte aller relevanten Verarbeitungseigenschaften ermittelt und verglichen werden und somit Prüfergebnisse erzeugt werden können, mit denen fachliche, organisatorische, technische und administrative Aktivitäten und Entscheidungen, die in der Vergangenheit im Rahmen einer Verarbeitung stattfanden, überprüfbar sind. Die Prüfbarkeit ist somit eine Voraussetzung für den Nachweis einer wirksamen Umsetzung der gesetzlichen Datenschutzanforderungen und deren Beurteilung. Eine Protokollierung muss die Frage beantworten können, welche Instanzen (Organisationseinheiten, Systeme oder handelnde Personen) welche Aktivitäten zu bestimmten Zeitpunkten ausgeführt und welche Instanz das Protokoll darüber geführt hat. Protokolle werden in aller Regel automatisiert erstellt („Logging“), können aber auch händisch geführt werden. Um einen lückenlosen Nachweis führen zu können, müssen Protokolldaten valide, reliabel, aktuell und vollständig sein. Zumindest bei hohem Schutzbedarf ist eine gesicherte Revisionsfestigkeit von Protokollen begründet.

Protokolldaten haben daher datenschutzrechtlich zwei Gesichter: Ihre Erstellung und Analyse ist eine technisch-organisatorische Maßnahme zur Absicherung der durch sie protokollierten (überwachten) Daten, und sie stellen ihrerseits personenbezogene Daten dar. Auf den ersten Aspekt ist am Ende dieses Falles noch zurückzukommen. Die (datenschutzrechtliche) Verarbeitung solcher Daten dürfte bei der Protokollierung von Eingaben in Fachapplikationen (im Rahmen von Geschäftsprozessen) „für Zwecke des Beschäftigungsverhältnisses“ im Sinne des § 26 BDSG erfolgen, der eine Ausprägung der datenschutzrechtlichen Legitimationsgrundlage „Vertrag“ (Art. 6 Abs. 1 S. 1 lit. b DGSVO) darstellt (s. Fall 4). Diese Zwecke sind, konkreter formuliert, die betrieblichen Belange des Verantwortlichen, die vom Mitarbeiter gemäß seiner anstellungsvertraglichen Aufgabenstellung umzusetzen sind, einschließlich der Möglichkeit zur Kontrolle der Sachbearbeitung durch den Beschäftigten als solcher (fachliche Qualität, inhaltliche Datenrichtigkeit). Während des laufenden Beschäftigungsverhältnisses obliegt es in erster Linie dem Arbeitgeber, im Rahmen der anstellungsvertraglich vereinbarten Position des Mitarbeiters zu definieren, welche Bewegungsdaten im Einzelnen verarbeitet werden und für welche weiteren Mitarbeiter diese einsehbar sind. In diesem Zusammenhang weist auch das Standard-Datenschutzmodell im Baustein 43 darauf hin, dass Protokolldaten nur zu den Zwecken geprüft werden dürfen, die Anlass für ihre Speicherung waren (Zweckbindung und Berechtigungskonzept):

Weisen Protokolldaten einen Personenbezug auf, dürfen sie nur zu ausgewiesenen Zwecken von speziell dazu Befugten ausgewertet werden. Für die Protokollierung der Tätigkeiten von Mitarbeiter/innen, Administrationstätigkeiten sowie der Aktivitäten von ITSystemen und an Schnittstellen gelten ebenfalls der datenschutzrechtliche Zweckbindungsgrundsatz und die Regelungen des Beschäftigtendatenschutzes. Protokolldaten dürfen daher nur zu den Zwecken geprüft werden, die Anlass für ihre Speicherung waren. Um festzustellen, ob die Zweckbindung eingehalten wird, müssen Protokolldaten unterschiedlicher Ebenen – Protokollierung auf der Ebene der Sachbearbeitung, der Fachprogramme, der ITInfrastruktur, der Administration – miteinander in eine Beziehung gesetzt werden können, um die Rechtskonformität aller Aktivitäten auf den verschiedenen Ebenen, die sich letztlich zumeist aus den gesetzlichen Regelungen der Fachlichkeit herleiten, nachweisen zu können.

Auch für die – wie bei allen personenbezogenen Daten erforderliche – Löschung von Protokolldatenbeständen soll nach dem Baustein 43 des Standard-Datenschutzmodells die aus der „Fachlichkeit“ abgeleitete Löschfrist maßgeblich sein. Was dies im Detail bedeutet, ist unklar, da die zugrundeliegenden (z. B. vom Mitarbeiter geänderten) Daten nicht personenbezogen sein müssen und dann auch keine Löschfristen einschlägig sind.

Viel hilft viel

Die von Baustein 43 hervorgehobene Vorgabe der DSGVO, die Rechtmäßigkeit sämtlicher Verarbeitungen personenbezogener Daten nachweisen zu können (Rechenschaftspflicht, „accountability“), würde nun an sich eine Protokollierung sämtlicher datenschutzbezogener Einzelvorgänge mit sämtlichen Details erfordern: Je mehr, desto besser. Dies kann sich allerdings nur auf den Zugriff auf solche (mit den Protokolldaten überwachten) Daten im ERP-System beziehen, die ihrerseits personenbezogen sind. In diesem Kontext dienen Protokolltätigkeiten einer verwendeten Applikation aus datenschutzrechtlicher Perspektive dem Zweck, einen lückenlosen Nachweis führen zu können, welche Entität (Person, System) welche datenschutzrelevanten Aktivitäten zu welchem Zeitpunkt ausgeführt und welche Entität darüber Protokoll geführt hat. Die Protokollierung von Verarbeitungsvorgängen mit nicht personenbezogenen Daten kann diesem Zweck von vornherein nicht dienen.

In Sinne der datenschutzrechtlichen Rechenschaftspflicht fordert Baustein 43 des Standard-Datenschutzmodells zusätzlich zur Protokollierung der Nutzeraktivitäten einer Fachapplikation auch die Protokollierung von Systemaktivitäten, Administrationstätigkeiten und Schnittstellenaktivitäten. Ziel ist es, anhand der Protokolle die Einhaltung datenschutzrechtlicher Vorgaben oder bei der Aufklärung von Datenschutzverstößen deren Ursache und Ausmaß nachweisen zu können, weshalb Protokolldaten valide, unveränderbar, aktuell und vollständig sein müssen. Gerade die Nutzung administrativer Rechte muss zu einem Eintrag im Protokoll führen, auch zum Schutz des Administrators vor unberechtigten Vorwürfen.

Ähnlich umfangreich wird die Protokollierung des Zugriffs (zumindest) auf sensible Daten auch in einem Fallbeispiel des Europäischen Datenschutzausschusses in seinen Empfehlungen vom November 2019 zum Thema „privacy by design/by default“ beschrieben:

A controller wants to extract personal data from a medical database to a server in the company. The company has assessed the risk for routing the extracts to a server that is accessible to all of the company’s employees as likely to be high for data subjects’ rights and freedoms. There is only one department in the company who needs to process these patient data. The extracts will also have a high value to the company. To regulate access and mitigate possible damage from malware, the company decides to segregate the network, and establish access controls to the server and the directory. In addition, they put up security monitoring and an intrusion detection and prevention system. The controller activates access control on the server and isolates it from routine use. An automated auditing system is put in place to monitor access and changes. Reporting and automated alerts are generated from this when certain events related to usage are configured. This security measure will ensure that all users have access on a need to know basis and with the appropriate access level.

Datenminimierung als Gegengewicht

Derart umfangreiche Protokolldaten führen – um der Rechenschafts- und damit Protokollpflicht willen – ihrerseits zu einer großen Menge personenbezogener Daten. Dabei gerät der Grundsatz der Datenminimierung in den Fokus, der natürlich auch eine „Protokolldatensammelwut“ begrenzt. Zwei Gesichtspunkte können zur Steuerung des Datenaufkommens eine entscheidende Rolle spielen:

  • Zum einen sollte bei der Protokollierung, wenn diese personenbezogene Daten beinhaltet, auf die zugehörigen Inhaltsdaten verzichtet werden, sodass es sich um reine Metadaten handelt. Denn mit der Protokollierung „X in Y geändert durch Z am [Datum, Uhrzeit]“ werden die personenbezogenen Daten X auch noch im Protokolldatensatz (vervielfältigt und) „perpetuiert“: Eine Löschung von X muss daher auch Teile des Protokolldatensatzes löschen. Auch der Zugriff auf die Protokolldaten muss den datenschutzrechtlichen Grundsätzen, etwa einem Berechtigungskonzept, unterliegen. Die Datenschutzbehörden fordern teils auch die Verschlüsselung und Signierung der Protokolldaten nach dem Stand der Technik.
  • Zum anderen können bei der Sachbearbeitung – je nach Risikoeinschätzung – in Bezug auf Daten das Lesen (Dateneinsicht), die Eingabe, die Änderung, das Sperren, das manuelle Löschen, die Übermittlung sowie die Nutzung automatisierter Abrufverfahren relevant sein. Die Frage, bei welcher Risikointensität welche Protokollierungs-Intensität erforderlich ist, wird weder im Standard-Datenschutzmodell noch in anderen Veröffentlichungen der Datenschutzbehörden beantwortet. Gerade eine – sehr datenintensive – Protokollierung von Lesezugriffen wird im Grundsatz nur bei sehr sensiblen Daten notwendig sein.

Zum letztgenannten Punkt (Protokollierung von Lesezugriffen) hatte die „Orientierungshilfe Protokollierung“ der Datenschutzbehörden aus 2009 noch Folgendes bestimmt:

Eine Protokollierung lesender Zugriffe ist ebenso aus Gründen der datenschutzrechtlichen Revisionssicherheit grundsätzlich erforderlich, insbesondere wenn ein Verfahrensschritt für den Nutzer direkt auf die Ermittlung personenbezogener Daten abzielt. Bei einem hinreichend fein differenzierten Zugriffsschutz kann der Umfang der Protokollierung reduziert werden.

So apodiktisch lässt sich eine solche „grundsätzliche Erforderlichkeit“ dem Standard-Datenschutzmodell nicht (mehr) entnehmen. Wie der Umfang derartiger Protokolldaten durch einen „hinreichend fein differenzierten Zugriffsschutz“ verringert werden kann, blieb ohnehin offen.

Risikoerhöhung – und nochmal von vorn!

Aus Sicht des Standard-Datenschutzmodells (Abschnitt D3.4) stellt die Protokollierung eine potentiell risikoerhöhender technische Maßnahme dar, die ihrerseits neue technische und organisatorische Maßnahmen erforderlich machen kann:

Zu beachten ist, dass neue Risiken durch ergriffene technische und organisatorische Maßnahmen entstehen können. Diese Risiken sind zu bewerten und angemessen zu reduzieren. Als Beispiel kann eine Vollprotokollierung von Mitarbeiter-Handlungen gefordert sein, die zugleich das Risiko birgt, dass durch Auswertungen dieses Protokolls eine unzulässige Leistungs- und Verhaltenskontrolle stattfindet. Wird in diesem Schritt eine Verarbeitung so verändert, dass die getroffenen Maßnahmen zu neuen Risiken, die höher sind als das Ausgangsrisiko, und somit zu einer Erhöhung des Schutzbedarfs führen, muss die Ausgestaltung der Maßnahmen erneut evaluiert werden. Die oben genannten Strategien sind in einem iterativen Prozess so lange anzuwenden, bis die Ausgestaltung der Maßnahmen ein angemessenes Schutzniveau gewährleistet.

Das klingt nach einem nicht unerheblichen Umsetzungsaufwand.

Nur der Vollständigkeit halber ist darauf hinzuweisen, dass auch Protokolldaten Teil eines dokumentierten Löschkonzepts sein müssen. In Bezug auf die Vorgaben zum Löschen selbst (s. Fall 28) ergeben sich keine Besonderheiten. Da meist keine spezifisch auf Protokolldaten anwendbaren Aufbewahrungspflichten bestehen, ist im Regelfall die Erfüllung des Protokollierungszwecks maßgeblich für die Löschpflicht (Art. 17 Abs. 1 lit. a) DSGVO). Die Datenschutzbehörden haben in der Vergangenheit – aus im Einzelnen ungeklärten Gründen – Speicherfristen von einem bis mehreren Jahren für erforderlich gehalten. Längere Speicherfristen können insbesondere dann angezeigt sein, wenn ein Protokoll der Dokumentation eines unternehmensinternen Verfahrens dient (Kontrolldokumentation über die tatsächliche Anwendung des Prozesses) und eine Dokumentationspflicht für eine längere Dauer besteht, etwa bei der Protokollierung von Berechtigungen (Erteilung und Entzug von Zugriffsrechten, Anlegen und Löschen von Benutzerkennungen) oder in Industriebereichen mit spezifischen Aufzeichnungspflichten (Arzneimittelherstellung etc.).

Geht’s denn überhaupt?

Selbst wenn die Huber AG nun im Rahmen ihrer (Risiko-)Analysen und Spezifizierung („Lastenheft“) ihrer ERP-Software verschiedene Anforderungen an die Beschaffenheit, den Umfang und die Löschung von Protokolldaten definiert hat, wird sich in der Praxis herausstellen, dass die konkret eingesetzte Software dies nicht leistet. Für diesen Fall sieht der Baustein 43 vor:

Bei bestehenden Systemen müssen sämtliche Protokolldaten inventarisiert werden inklusive den Nachweis darüber, dass diese Protokollinhalte gesichtet und deren Relevanz für den Datenschutz beurteilt wurde.

Bereits in der Spezifikationsphase muss definiert werden, für welche Fragen und Prüfungen welche Protokolldaten erforderlich sind. Insbesondere wenn marktgängige StandardProgramme eingesetzt werden sollen wird es notwendig sein, noch vor der Inbetriebnahme zu prüfen, welche Protokolldaten standardmäßig erzeugt werden und ggfs. datenschutzrechtlich erforderliche Änderungen beim Hersteller zu verlangen.

Die hier unterstellte „Nachfragemacht“ gegenüber dem Software-Hersteller – also das, was sich der DSGVO-Gesetzgeber als Folge der „privacy by design“-Verpflichtung der Verantwortlichen erhofft hat – bleibt in der Praxis aber selbst bei kleineren Anbietern häufig eine Illusion. Eine datenschutzrechtliche Neuorientierung einer „gewachsenen“ Software erfordert meist Veränderungen des grundlegenden Programm-Designs, d. h. der Daten(bank)struktur, und geht nicht mit „attraktiven neuen Funktionen“ einher, mit denen jede neue Programmversion idealerweise am Markt auftrumpfen sollte.

Was macht man mit all den Daten?

Unabhängig davon sieht Baustein 43 für die Verarbeitung der so gewonnenen „rohen“ Protokolldaten eine – im besten Fall skriptgesteuerte und in jedem Fall dokumentierte – Filterung, Normalisierung, Aggregation, Kategorisierung und Priorisierung vor. Das Ergebnis soll insbesondere zur Generierung relevanter Aussagen über Auffälligkeiten (im datenschutzrechtlichen Sinne) führen, die dann auch zum Auslösen von (Abhilfe-)Aktionen führen können.

Dass dies keine graue Theorie ist, zeigt ein Bußgeldbescheid der polnischen Datenschutzaufsicht in einer Größenordnung von 600.000 Euro vom September 2019, der zwar keine Protokollierung interner Vorgänge (wie im Ausgangsfall der ERP-Software der Huber AG) betrifft, aber dennoch die Notwendigkeit der Anfertigung und (laufende) Analyse von Protokolldaten – hier: des externen Netzwerkverkehrs – aufzeigt. Für einen Identitätsmissbrauch geeignete Daten von 2,2 Millionen Betroffenen gerieten durch unzureichende Vorsichtsmaßnahmen in falsche Hände. Man kann dies allgemein als unzureichende technische und organisatorische Maßnahmen bezeichnen oder konkreter im Sinne von „ineffective monitoring of potential risks“:

There was a lack of appropriate response procedures to deal with the emergence of unusual network traffic.

Auch weitere öffentlich gewordene Fälle von unsicher konfigurierten IT-Systemen, sodass Daten von außen „abgezogen“ werden können, und die Untersicherheit, ob, von woher und wie oft das Einfallstor tatsächlich genutzt wurde, verdeutlichen neben der Notwendigkeit der entsprechenden Schutzmaßnahmen auch die Notwendigkeit der Sicherung von Beweismitteln. Dies betrifft beispielsweise das Daten-Leak bei der Autovermietung Buchbinder (drei Millionen Kundendaten mit insgesamt zehn Terabyte), bei dem der SMB-Port von Back-up-Servern „offen stand“, sowie bei Microsoft mit 250 Millionen Einträgen aus der Kundendatenbank, bei denen ebenfalls eine falsche Konfigurierung von Servern vorlag. Im Bereich der organisatorischen Maßnahmen lässt sich etwa der Bußgeldbescheid des Bundesdatenschutzbeauftragten gegen die 1&1 Telecom GmbH nennen, der darauf beruhte, dass (vermeintliche) Kunden durch Nennung ihres Namens und ihres Geburtsdatums umfangreiche personenbezogene Daten telefonisch abfragen konnten. Auch hier könnte das Ausmaß – über den einen dokumentierten Einzelfall, der zum Bußgeld führte – nicht mehr nachvollzogen werden, selbst wenn die Anfragen protokolliert wurden, da anhand der protokollierten Daten die Berechtigung des Anrufers nicht geprüft werden kann. Man hätte also zu Protokollierungszwecken mehr Daten erheben müssen – vermutlich ziemlich genau die (zusätzlichen) Daten, die der Bußgeldbescheid auch zur Authentifizierung des Anrufers forderte.

Auffälliger Netzwerkverkehr, über den massenhaft personenbezogene Daten „abgezogen“ werden, auffällige Veränderungen von Bankdaten von Geschäftspartnern in einem ERP-System: Die richtigen Protokolldaten weisen den Weg zum Datenschutzverstoß. Der Sinn entsprechender Überlegungen sollte jedem Unternehmen klar sein. Aber welchen (signifikanten) Aufwand die Huber AG nun konkret erbringen muss, um eine Vielzahl von Szenarien nachvollziehbar zu evaluieren und – unter anderem – durch entsprechende und gut dokumentierte Protokollmechanismen „aufdeckbar“ zu machen, bleibt offen.

Diese News könnten Sie auch interessieren
Alle News
Mehr laden
Diese Vorträge & Veröffentlichungen könnten Sie interessieren
Alle Vorträge & Veröffentlichungen
Mehr laden