DSGVO: Drum lösche, wer da ewig protokolliert

Lesen Sie hier, was Protokollierung mit Datenschutz zu tun hat und welche Do's and Don'ts es gibt. Wir wissen, dass alle IT-gestützten Systeme Unmengen von Daten permanent aufzeichnen. Typischerweise werden Protokolle genutzt, um Fehler zu analysieren oder auch unerlaubte Aktivitäten aufzudecken.

Was aber haben Protokollierung bzw. Protokolle mit der DSGVO oder dem BDSG oder dem IT-Grundschutz zu tun? Letztlich sehr viel und beim Betreiben von IT-Systemen bilden Sie nicht gerade selten den Stolperstein, der gerne übersehen wird, um datenschutzkonform zu arbeiten.

Betrachten wir die Protokollierung am Beispiel des RDBMS IBM Db2 LUW. Fangen wir dabei mit den "DOs and DON'Ts" an.

Der gesetzliche Auftrag zu protokollieren

Die Datenschutzgrundverordnung (DSGVO) verlangt, dass personenbezogene Daten “nach dem Stand der Technik” (Art. 32) entsprechend abgesichert sein müssen. Hierzu zählen auch Protokolle, da diese nachvollziehbar auflisten, wer, wann, was an einem System unternommen hat. Also sind Protokolle grundsätzlich nicht gesetzeswidrig. Dass ein Protokoll eventuell hierdurch selbst zu einem personenbezogenen Datum wird, darf dabei nicht vergessen werden.

Neben der DSGVO wurde auch im neuen Bundesdatenschutzgesetz (BDSG-neu) ein entsprechender Paragraph ( § 76 Protokollierung ) aufgenommen. Und weiterhin hat man aus dem IT-Grundschutz den Baustein OPS.1.1.5 Protokollierung zu beachten.

De facto sind Unternehmen gesetzlich verpflichtet Protokolle in Ihrer Systemlandschaft zu aktivieren und die Regeln dazu einzuhalten.

Aber ... beachteN Sie die Rechtmäßigkeit der Protokollierung

Für die Nutzung von anonymen Logins oder technischen User wird es sukzessive schwierig, da mit diesen nicht nachvollziehbar ist wer an einem System gearbeitet hat. Dies können die Protokolle selber nicht lösen, aber Verstöße aufzeigen. Denn die Protokollierung von IT-Systemen ist gesetzlich gefordert, um diverse Gefahren aktiv zu erkennen und frühzeitig Handeln zu können um Daten (egal ob personenbezogen oder nicht) zu schützen.

Mit dem §76 Ansatz 4 des BDSG sind sogar Termine für die Löschung von Protokollen festgelegt worden "Die Protokolldaten sind am Ende des auf deren Generierung folgenden Jahres zu löschen". Das ist erstmal eine neue Aufgabe für die Administration, die einen ziemlich ärgern wird, wenn für eine Fehlersuche ein Protokollverlauf vom letzten oder vorletzten Jahresendlauf benötigt wird.

Aber es hilft beim Aufräumen, denn es muss zuerst aufgelistet werden wohin Protokolle, Dumps, etc. überhaupt geschrieben werden, was unter Datenschutz-Gesichtspunkten enthalten ist und ob bzw. wann Dateien wieder überschrieben werden.

Gedanken zu Protokollen

Bei einer Protokollierung muss sich ein Unternehmen darüber Gedanken machen, die Protokolldateien (sofern Sie personenbezogene Daten beinhalten – und das dürfte meistens der Fall sein) entsprechend zu schützen. Auch die Daten sind soweit möglich anzupassen, die in ein Protokoll einfließen. Für die Auswertung von Protokollen und die regelmäßige Überprüfung auf unerlaubte Zugriffe etc. ist die Berechtigung einzuschränken auf einen betreuenden Administratorkreis. Dass Protokolle nicht zur Mitarbeiterüberwachung und Leistungskontrolle eingesetzt werden, versteht sich von selbst.

Grundsätzlich sind somit auch bei Protokollen die Grundsätze des Datenschutzes zu beachten: Datensparsamkeit, Zweckbindung, Schutz vor Manipulation, Anonymisierung und Löschfristen. Nicht vergessen werden darf natürlich die Zugriffsmöglichkeiten für Datenschutzbeauftragte.

Beispiel IBM Db2 LUW

Betrachtet wurden eine seit ein paar Jahren laufende Version 10.5 von Db2 LUW unter Windows mit den dabei angefallenen Protokollen und eine ganz aktuelle Version 11.5.

Fangen wir bei den einfachen Dingen an: In Db2 LUW ein Passwort in Klartext zu finden kommt nicht vor. Maximal werden Anmeldefehler ohne Passwort aufgelistet, z.B. "Password validation for user xxx failed with rc = -2146500507"

Des Weiteren gibt es Verweise auf Security Identifier, aber das ist in einer Windows-Umgebung normal, z.B. die Datei "C:\Users\All Users\IBM\DB2\<xxxxxx>\DB2extsecurity.sid".
Dort findet man bei eingeschalteter "Extended Windows Security" die SID's der Admin- und der User-Group:

# DB2ADMINGROUP:DB2ADMNS
DB2ADMINGRSID:S-1-5-21-7623811015-3361044348-030300820-1043
# DB2USERSGROUP:DB2USERS
DB2USERSGRSID:S-1-5-21-7623811015-3361044348-030300820-1042

Etwas komplizierter wird es bei den Protokollen. Grundsätzlich ist in Db2 LUW wohl eine rollierende Protokollschreibung vorgesehen (siehe DBM-Konfigurationsparameter DIAGSIZE), diese richtet sich aber dann nach dem Volumen und nicht nach dem Verfallsdatum lt. BDSG. Hierzu ist eine individuelle Lösung einzurichten, die davon abhängt, wie das Db2-System konfiguriert ist. Im Folgenden ein paar Konfigurationsparameter, die dabei zu beachten sind.

Konfigurations-Parameter

Die Detaillierungstiefe der Protokollierung wird durch die "Aufzeichnungsebene bei Fehlerdiagnose (DIAGLEVEL) in der DBM-Konfiguration" (Defaultwert = 3) bestimmt.
Durch die erlaubten Werte ergeben sich folgende Details:

Mit dem Level "Event" wird eine Verbindung eines Users unter anderem mit seiner UserID, der IP-Adresse, Token, Application-ID, Datum/Uhrzeit und verbundene Datenbank protokolliert. Und "Events" werden ausgegeben ab einem DIAGLEVEL = 2. Also liegt mit den Protokollen eindeutig ein personenbezogenes Datum lt. DSGVO vor.

Ein weiterer DBM-Parameter "Aufzeichnungsebene (NOTIFYLEVEL)" bestimmt die Detaillierung von administrativen Benachrichtigungen, die unter Windows in das Ereignis-Log geschrieben werden. Darin ist kein personenbezogener Inhalt enthalten, sondern typischerweise dringend erforderliche Tätigkeiten durch die Administration aufgeführt.

Ablageorte

Nun zu den Positionen, an denen sich überall Protokolle befinden können, die relevant sind. Netterweise ist das in der DBM-Konfiguration definiert (Ausgabe mittels GET DBM CFG).

• Die normalen Protokolldateien werden abhängig vom "Verzeichnispfad für Diagnosedaten (DIAGPATH)" geschrieben.
• Und in der Ausnahmesituation, dass dieser Pfad nicht erreichbar ist, wird "Alternativer Verzeichnispfad für Diagnosedaten (ALT_DIAGPATH)" genutzt.

Neben den Protokollen existieren natürlich die LOG-Dateien von Db2 LUW. Die Definition der Ablage erfolgt jeweils in einer DB-Konfiguration und es sind einige Positionen möglich.

• Die Standard-Definition steht in "Pfad zu Protokolldateien (auch LOGPATH genannt)" bzw. in "Datenbankprotokollpfad ändern (NEWLOGPATH)" bis zum nächsten Db2-Start.
• Dazu gibt es noch den "Pfad für Protokollspiegelung (MIRRORLOGPATH)" zur Duplizierung aller LOG-Dateien
• Und als komplette Sicherung die "Erste bzw. Zweite Protokollarchivierungsmethode (LOGARCHMETH1 bzw. 2)", die Möglichkeiten der Sicherung auf weiteren Platten oder sogar TSM (Tivoli Storage Manager) erlauben mit zusätzlichen Konfigurationsparametern.
• LOG's enthalten alle Informationen inkl. der Personenbezogenen, um im Falles eines Absturzes zum letzten abgesicherten Zustand zu kommen. Dies kann noch durch die Parameter "LOG_DDL_STMTS" und "LOG_APPL_INFO" erweitert werden.

Zusätzlich zu den LOG-Dateien werden durch Db2 LUW unter Windows in dem Verzeichnis zur Db2-Instanz "C:\Users\All Users\IBM\DB2\<xxxxx>\DB2" und dem zum Db2 Administration Server "C:\Users\All Users\IBM\DB2\<xxxxx>\DB2DAS00" mehrere Unterverzeichnisse angelegt mit verschiedenen LOG's. Die Existenz von Verzeichnissen ist auch davon abhängig welche Komponenten, z.B. Text Search oder Pure Scale, installiert wurden.

• Dabei sind die vom Db2 Self-Tuning Memory Manager (\stmmlog) und Sync Point Manager (\spmlog) immer rollierend und damit ziemlich aktuell ohne Anforderung einer jährlichen Bereinigung
• Aufgeräumt werden muss in den Verzeichnissen \dump und \events und evtl. in \db2tss (Text Search) etc.

Abschließend gibt es noch die Ausgaben für Ereignismonitore. Diese können auch personenbezogene Daten enthalten und müssen aufgeräumt werden. Da dies von Fall zu Fall, also abhängig vom Ereignis, eine unterschiedliche Aufzeichnung der Monitore (DFT_MON_Switches) und eine unterschiedliche Art der Ausgabe (WRITE TO TABLE / FILE / PIPE) benötigt, kann hier nur durch klare Vorgaben und Namenskonventionen für Tabellen und Verzeichnisse eine rechtmäßige Protokollierung erfolgen.

Lösungsansätze

Dies alles muss in der Lösung zur gestellten Aufgabe der Löschung von Protokollen / LOG's mit personenbezogenem Inhalt entsprechend DSGVO bzw. BDSG natürlich mitberücksichtigt werden.

Der einfachste Ansatz ist "Immer nur ein Jahr aufheben", also zum Jahreswechsel die Db2-Server und Db2-Administration Server herunterzufahren, alle betroffenen Ereignis-Tabellen oder Dateien, z.B. "db2diag.log" unter einem Namen inkl. Jahreszahl "2019-db2diag.log" an einer Archiv-Position abzulegen, die Originale zu löschen, alles kleiner dem aktuellen Jahr im Archiv zu löschen und die Server wieder hochzufahren. Klingt einfach, ist es aber nicht, man denke nur mal an 7x24-Anforderungen.

Der Ein-Jahres-Ansatz mag für Protokolle und Logs noch funktionieren, ist aber bei den "wirklichen" Daten nicht haltbar. Lesen Sie mehr bei meinem Kollegen Timm Euler im BLOG "DSGVO und Data Warehouse - Unvereinbar?"