Im Rahmen eines Projektes namens „Course And Space Scheduled Allocation Controlling” (CASSAC) soll diese Praxisreflexion Wissen zum Thema Protokollierung vermitteln und darüber hinaus den Grundstein für die Umsetzung einer Logging-Funktion innerhalb des Projektes legen.
Dabei werden im zweiten Kapitel die Ziele und Aufgaben sowie die rechtlichen Aspekte, unter Berücksichtigung von Fachliteratur, analysiert. Außerdem soll aufgezeigt werden, wie eine Protokolldatei aufgebaut ist und wie diese aussehen kann. Die Anforderungen und spezifischen Ziele der Logging-Funktion für das Projekt CASSAC werden im dritten Kapitel genauer überprüft. Das vierte Kapitel zeigt einen Vorschlag zur Umsetzung einer solchen Logging-Funktion für das Projekt sowie deren Optimierungspotenziale. Ein kurzes Fazit sowie ein Ausblick setzen im Kapitel 5 den Schlusspunkt.
Inhaltsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
Abkürzungsverzeichnis
1 Einführung
2 Grundlagen der Protokollierung
2.1 Ziele und Aufgaben der Protokollierung
2.2 Arten von Protokolldaten
2.3 Aufbau der Protokolldaten
2.4 Problematik bei der Protokollierung
3 Analyse der aktuellen Situation im Projekt CASSAC
3.1 Betrachtung des Status Quo
3.2 Anforderungen und Ziele der Logging-Funktion
3.3 Überprüfung der Umsetzbarkeit
4 Realisierung und Optimierung der Logging-Funktion
4.1 Vorschlag zur Realisierung
4.2 Identifikation der Optimierungspotenziale
Fazit und Ausblick
Literaturverzeichnis
Printquellen
Internetquellen
Abbildungsverzeichnis
Abbildung 1: Erstes CASSAC Startfenster
Abbildung 2: Programmablaufplan Logging-Funktion
Abbildung 3: Quelltext Logging-Funktion Teil 1
Abbildung 4: Quelltext Logging-Funktion Teil 2
Abbildung 5: Quelltext Logging-Funktion Teil 3
Abbildung 6: Quelltext Logging-Funktion Teil 4
Abbildung 7: Quelltext Logging-Funktion Teil 5
Abbildung 8: Protokolldatei der Logging-Funktion
Tabellenverzeichnis
Tabelle 1: Beispiel einer CSV Protokolldatei
Tabelle 2: Tabelle einer CSV Protokolldatei
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
1 Einführung
Am Freitagmorgen herrscht in der Firmenzentrale des Unternehmens „OCRON“[1] große Unruhe. Ein neues, von der IT-Abteilung selbst entwickeltes, Dienstleistungsprogramm zur Verwaltung von Kundendaten soll am kommenden Wochenende in Betrieb genommen werden. Doch kurz vor Dienstende bemerken die Mitarbeiter, dass das Programm über keine Protokollierung (engl. Logging) von Benutzerinteraktionen verfügt. Eine Überprüfung - wer, wann, welche Kundendaten eingesehen oder eventuell kopiert hat - kann nicht nachverfolgt werden. Auch Programmabstürze könnten teilweise nicht nachvollziehbar sein. Kurzfristig muss nun entschieden werden, ob und wie eine Logging-Funktion implementiert werden kann.
Dabei kommen einige Fragen auf: Was sind überhaupt die Aufgaben und die übergreifenden Ziele einer solchen Funktion? Wie sieht so eine Protokolldatei überhaupt aus? Welche rechtlichen Faktoren müssen beachtet werden?
Im Rahmen des Projektes „Course And Space Scheduled Allocation Controlling” (CASSAC) soll diese Praxisreflexion Wissen zum Thema Protokollierung vermitteln und darüber hinaus den Grundstein für die Umsetzung einer Logging-Funktion innerhalb des Projektes legen.
Dabei werden im zweiten Kapitel die Ziele und Aufgaben sowie die rechtlichen Aspekte, unter Berücksichtigung von Fachliteratur, analysiert. Außerdem soll aufgezeigt werden, wie eine Protokolldatei aufgebaut ist und wie diese aussehen kann. Die Anforderungen und spezifischen Ziele der Logging-Funktion für das Projekt CASSAC werden im dritten Kapitel genauer überprüft. Das vierte Kapitel zeigt einen Vorschlag zur Umsetzung einer solchen Logging-Funktion für das Projekt sowie deren Optimierungspotenziale. Ein kurzes Fazit sowie ein Ausblick setzen im Kapitel 5 den Schlusspunkt.
2 Grundlagen der Protokollierung
2.1 Ziele und Aufgaben der Protokollierung
Wenn eine Software entwickelt wurde kann nie zu 100% sichergestellt werden, dass diese bereits mit der ersten Veröffentlichung frei von jeglichen Sicherheitslücken sowie Problemen ist. Da ein Fehler in der Software nur behoben werden kann, wenn dieser entdeckt wird, besteht die Notwendigkeit einer Protokollierung, um auf Hinweise für Fehlfunktionen aufmerksam zu machen.[2]
In der Anlage des §9 des Bundesdatenschutzgesetzes (BDSG) lässt sich erkennen, dass eine Pflicht zur Protokollierung ableitbar ist. Dort wird geregelt, wie mit personenbezogenen Daten, welche automatisiert verarbeitet und genutzt werden, umzugehen ist. Mit der Protokollierung soll erreicht werden, dass der Datenschutz und die Datensicherheit dieser sensiblen Daten eingehalten werden. Mit Hilfe der Protokolldaten soll, neben dem Aufdecken von Programmfehlern, die Möglichkeit geschaffen werden, einen Verstoß beim Bearbeiten personenbezogener Daten nachweisbar zu machen. Hierbei muss eindeutig ersichtlich werden, wer, wann, welche Daten verarbeitet oder eingesehen hat. Erfolgte Operationen, beteiligte Anwendungen, Maschinen und Personen sollten mit einem Zeitbezug in der Protokolldatei vorhanden sein. Eine Protokollierung muss immer zweckgebunden, vollständig, datensparsam und aus Kundensicht nach Möglichkeit anonymisiert erfolgen. Zweckgebunden bedeutet, dass sie nur zu den Zwecken genutzt werden, welche Anlass zur Protokollierung waren. Fehlerprotokolle sollten also nicht für automatisierte Verhaltens- oder Leistungskontrollen von Mitarbeitern genutzt werden.[3]
Wenn für ein Programm eine Logging-Funktion vorgesehen ist, sollte vorher ein entsprechendes Konzept ausgearbeitet werden, welches für jede Tätigkeit den exakten Inhalt der Protokolldatei festlegt. Vorher müssen die Tätigkeiten entsprechend eingestuft werden, um zu erkennen, ob sie relevant für die Logging-Funktion sind. Alle als relevant eingestuften Tätigkeiten sollten später zu einem Logeintrag führen. Es muss beachtet werden, dass Protokolldaten, welche über das Netzwerk oder das Internet übertragen werden, geschützt und mit entsprechenden kryptologischen Verfahren verschlüsselt werden müssen.[4]
Außerdem muss sichergestellt sein, dass diese Protokolldaten nur Berechtigten zugänglich sind und sie nachträglich nicht verändert werden können.[5]
Die Zugriffsmöglichkeiten sind daher aus zwei Aspekten zu minimieren. Zum Einen bieten geringe Zugriffsmöglichkeiten bestmöglichen Schutz vor der Dateneinsicht von Unbefugten und zum Anderen wird der Schutz der Administratoren damit erhöht, denn auch diese können dann beweisen, dass sie keinen Zugriff auf die Protokolldaten haben. Zugriffsmöglichkeit sollten demnach nur entsprechend ausgewählte Administratoren sowie der Datenschutzbeauftragte des Unternehmens bekommen.[6]
Im Protokollierungskonzept sollte sich auch über die Aufbewahrungsdauer Gedanken gemacht werden und zwar bevor die ersten Protokolldaten erstellt sind. Ein Maßstab für die Erhaltung der Protokolldaten ist die Erforderlichkeit der Aufgabenerfüllung. Die Protokolldaten einer Logging-Funktion für Programmfehlverhalten nach dem ersten Release eines Programms sollten zum Beispiel nach einigen Tagen ausgewertet und dann gelöscht werden. Wenn es keinen zwingenden Grund für das Vorhalten einer solchen Protokolldatei gibt, besteht die Pflicht zur Löschung. Der Auswertungszyklus kann sich je nach Verfahrensart über eine Frist von wenigen Tagen bis hin zu mehreren Monaten erstrecken.[7]
Um zu bestätigten, das die Protokollierungsmechanismen ordnungsgemäß und sicher arbeiten und die Protokolldaten gültig sind, sollten im Vorfeld Testszenarien definiert werden. Diese Tests sollten eine Überprüfung, ob alle als relevant eingestuften Tätigkeiten korrekt protokolliert werden, ob die Daten sicher übermittelt werden und ob die Daten zugriffsgeschützt sind, umfassen.[8]
Transparenz über die Logging-Funktion sollte auf jeden Fall geschaffen werden. Die Benutzer müssen darüber informiert werden, dass es eine Logging-Funktion gibt und für welchen Zweck sie verwendet wird. Die Konsequenzen bei Verstößen gegen den Datenschutz sollten bewusst gemacht werden.[9]
2.2 Arten von Protokolldaten
Protokolldaten sind die Daten, welche vom Programm automatisch erstellt werden, um Aktionen, wie z.B. Datenänderungen, logbuchartig zu protokollieren.[10][11]
Hinsichtlich der Protokolldaten muss zwischen anfallenden Protokollen für Maschinen, für Administratoren und für Nutzer bzw. Anwender unterschieden werden. Administrative Rechte erfordern eine besondere Kontrolle und immer einen Eintrag ins Protokoll. Maschinen- und Administrator-Protokolle sind der Systemüberwachung zuzuordnen und Nutzerprotokolle hingegen der Verfahrensüberwachung. Neben der Fehlerprotokollierung in Maschinenprotokollen beschäftigen sich alle Protokollarten übergeordnet damit, die Ordnungsmäßigkeit der Datenverarbeitung nachweisen zu können.[12]
Im administrativen Bereich muss die Veränderung von Prozessen, welche automatisiert personenbezogene Daten verarbeiten, lückenlos protokolliert werden. Diese Protokollierung dient maßgeblich dem Eigenschutz des Administrators vor unberechtigten Vorwürfen. Für die Protokollierung im administrativen Bereich reicht eine übergreifende Administrationskennung für Administratoren nicht aus. Jeder Administrator muss zwingend über eine personalisierte Administrationskennung verfügen und darf in der Regel keine Rechte dafür besitzen, die Protokolldaten zu verändern.[13]
In den Nutzerprotokollen werden die als relevant eingestuften Tätigkeiten der Anwender des Programms protokolliert. Diese Protokolle sollen den rechtskonformen Umgang mit den personenbezogenen Daten beweisen. Protokolliert werden in diesem Bereich üblicherweise Tätigkeiten wie die Authentifizierung, Dateneingabe, Datenveränderung, Dateneinsicht, Datenübermittlung und Datenlöschung.[14]
[...]
[1] Fiktiver Unternehmensname, vom Autor erfunden.
[2] Vgl. Baier, D. (2006), http://msdn.microsoft.com/de-de/library/bb979259.aspx
[3] Vgl. Arbeitskreis „Technische und organisatorische Datenschutzfragen“ (2009), S. 2f.
[4] Vgl. Rothmann, P. (2009), S. 331f.
[5] Vgl. Landesbeauftragter für den Datenschutz Niedersachsen (2010), S. 4.
[6] Vgl. Arbeitskreis „Technische und organisatorische Datenschutzfragen“ (2009), S. 7.
[7] Vgl. Arbeitskreis „Technische und organisatorische Datenschutzfragen“ (2009), S. 8.
[8] Vgl. Arbeitskreis „Technische und organisatorische Datenschutzfragen“ (2009), S. 3.
[9] Vgl. Landesbeauftragter für den Datenschutz Niedersachsen (2010), S. 4.
[10] Vgl. Bundesverband Deutscher Zeitungsverleger e.V. (2007), http://www.bdzv.de/information_ multimed+M5b9e1ccfe74.html
[11] Vgl. Winkler, P. (2009), S. 486.
[12] Vgl. Arbeitskreis „Technische und organisatorische Datenschutzfragen“ (2009), S. 3f.
[13] Vgl. Arbeitskreis „Technische und organisatorische Datenschutzfragen“ (2009), S. 4.
[14] Vgl. Arbeitskreis „Technische und organisatorische Datenschutzfragen“ (2009), S. 4f.
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen.