Datenschutzkonforme Gestaltung von Trouble Ticket Systemen Anke Nöbel 34. Tagung der Arbeitsgemeinschaft Datenschutzbeauftragte Niedersächsischer Ahlhorn 18.02.2010
Trouble Ticket Systeme sind auch nur IT-Verfahren zur automatisierten Verarbeitung personenbezogener Daten 2
Grundgedanken: Zweck von Trouble Ticket Systemen Erfassung von Störungsmeldungen keine Meldung geht verloren Erfassung von Bearbeitungsschritten Vereinfacht Zusammenarbeit mit den Kollegen Mehr Transparenz für den Kunden Ein Hilfsinstrument zur Optimierung der Arbeitsprozesse 3
Zusatznutzen: Zweck von Trouble Ticket Systemen Quantitative Auswertung der Störungen nach Gerät, Kunde (Person/Gruppe), Bearbeiter, Zeitpunkt, Qualitative Auswertung der Störungen nach Lösungsdauer, Eskalationen, Lösungserfolg, Kosten, Arbeits- / Leistungs- / Verhaltenskontrolle sowohl der Bearbeiter als auch der Kunden möglich! 4
Personenbezogene Daten im System Speicherung und Verarbeitung von personenbezogenen Daten Bearbeiter Wer hat wann was getan oder unterlassen? Kunde Wer hat wann was gemeldet oder beauftragt? Verkettung der Personen mit Störungen / Tätigkeiten sowie Zeitstempeln 5
Grundsätze des Datenschutzes Rechtmäßigkeit Einwilligung Zweckbindung Erforderlichkeit und Datensparsamkeit Transparenz und Betroffenenrechte Datensicherheit Kontrolle 6
Bearbeiter: Dienstvereinbarungen, Anordnungen, Erlasse Einwilligung Kunden: Opt-In bewusstes Einwilligen in die Speicherung und Verarbeitung der personenbezogenen Daten zum konkret umschriebenen Zweck (Auf personenbezogene Auswertungen explizit hinweisen!) Opt-Out Widerspruchsmöglichkeit, insbesondere bei automatisiertem Erstellen von Tickets ohne Zutun des Kunden 7
Zweckbindung Trouble Ticket Systeme sammeln viele Daten, mit denen vieles bewertet und optimiert werden kann ABER Nutzung der personenbezogenen Daten ausschließlich zum vorab bestimmten und eingewilligten Zweck!! Personenbezogene Auswertungen können mit Einwilligung und Zweckbindung akzeptabel sein 8
Datensparsamkeit Es sollen nur die notwendigen Daten für die notwendige Dauer gespeichert werden. Für die einzelnen Bestandteile eines Tickets kann insbesondere die notwendige Dauer verschieden sein, wenn das Ticketsystem zur Dokumentation der Geräte- Lebenszyklen genutzt wird (Änderungen, Reparaturen, Ersatz) das Ticketsystem zur statistischen Auswertung objektiver Bestandteile genutzt wird (Anfälligkeit von Gerätetypen, Schwerpunktthemen, Ticketmengen und häufungen) 9
Ticketbearbeiter Transparenz & Betroffenenrechte Klare Regelungen bezüglich Arbeits- / Leistungs- und Verhaltenskontrolle seitens des Arbeitsgebers als auch der Kollegen Konkrete Dienstvereinbarung Wer darf was wann wie warum auswerten? Wer darf was wann wie warum sehen? 10
Transparenz & Betroffenenrechte Kunden Klare Aussagen bezüglich Umfang der gespeicherten Daten, Speicherzweck, Speicherdauer und Widerspruchsmöglichkeiten Bei Kunden mit eigenem Systemzugang Information bei Erteilung Erstzugang und / oder Information verfügbar auf Anmeldeseite Hinweis in automatischer Mailbestätigung des Ticketeingangs 11
Datensicherheit Verfügbarkeit Wer braucht wann welche Informationen? Oder: Ab welchem Zeitpunkt kann auf welche Daten verzichtet werden? Löschkonzept Vertraulichkeit Wer benötigt zu seiner Aufgabenerfüllung welche Leserechte? Oder: Muss jeder alles lesen können, genügen auch themenbezogene Sichten? Granulare Berechtigungen Integrität Wer darf die Ticketdaten bearbeiten / manipulieren? Granulare Berechtigungen Wie stelle ich Manipulationen fest Protokollierung 12
Kontrolle Protokollierung Protokollierung der schreibenden Zugriffe Protokollierung der lesenden Zugriffe ( Volltextsuche!) Protokollierung der Löschungen Regelmäßige Auswertung und Löschung der Protokolle 13
Kontrolle Sicherstellen des Funktionierens der Löschprozesse Tickets gemäß definierter Löschfrist ggf. einzelner Ticketbestandteile gemäß definierter Löschfrist Nutzerdaten gemäß definierter Löschfrist 14
Zwischenstand 15
Zwischenstand Kein Betrieb eines Trouble Ticket Systems ohne: Verfahrensdokumentation Zweckbeschreibung Berechtigungskonzept Protokollierungskonzept Beschriebene Löschprozesse Einwilligung der Kunden der Bearbeiter 16
ABER man kann doch gar nicht aus Trouble Ticket Systemen löschen ohne die Revisionssicherheit und die Datenkonsistenz zu gefährden! 17
Revisionssicherheit Der Begriff Revisionssicherheit bezieht sich auf die revisionssichere Archivierung für elektronische Archivsysteme, die in Deutschland den Anforderungen des Handelsgesetzbuches ( 239, 257 HGB), der Abgabenordnung ( 146, 147 AO), der Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS) und weiteren steuerrechtlichen und handelsrechtlichen Vorgaben entsprechen. (Quelle: wikipedia.de) 18
Die Wahrung der Datenkonsistenz liegt in der Verantwortung des jeweiligen Entwicklers. Datenkonsistenz Das Herauslösen und Ersetzen von einzelnen Daten führt nicht zwangsläufig zu Inkonsistenzen, sie schränken aber ggf. die Vielfalt der Auswertungsmöglichkeiten ein Datenkonsistenz Datenvollständigkeit 19
Beispiel OTRS 20
Beispiel OTRS OpenSource-Lösung - Grundsätzlich kostenlos - Individuell anpassbar - Objektorientierte Programmierung in Perl - Zusätzlich ansprechbar via SOAP - Gut dokumentiert - Verbreiteter Einsatz / aktives Anwenderforum - Professioneller Support (customizing) möglich 21
22
Beispiel OTRS tn = Ticketnummer Gewollt Editierbar (z.b. zum Verknüpfen von Tickets) Customer_user_id Frei editierbar sogar aus der normalen Nutzeroberfläche! 23
Löschen personenbezogener Daten 24
25
26
27
Beispiel OTRS Mittels der Ticketnummer oder der TicketID sind alle Werte der Datenbank direkt bzw. indirekt erreichbar. my %Ticket = $CommonObject{TicketObject}->TicketGet( TicketID => $TicketID ); my @ArticleBox = $CommonObject{TicketObject}->ArticleGet(TicketID => $Ticket{TicketID}); if ( @ArticleBox > 1 ) { } shift @ArticleBox; foreach my $Article ( @ArticleBox ) { # -- deletes articles and attachments - also the basic ticketinfo!!! => ignore the smallest article_id (shift) my $Email = $CommonObject{TicketObject}->ArticleDelete(ArticleID => $Article->{ArticleID}, UserID => '$UserID'); } 28
OTRS im ULD Test-/Pilotbetrieb Bearbeiter werden mit Benutzernamen einmalig manuell angelegt, authentisieren sich gegen das LDAP Kein fester Kundenstamm Kunden werden automatisch bei Maileingang angelegt, haben keinen eigenen Zugang zu OTRS a) Nach Abschluss des Tickets 3 Monate weiter im System für Nachfragen bzw. Wiederaufleben b) Nach 3 Monaten Löschen der Kundendaten, Ticketanhänge und Artikel c) Nach 1 Jahr statistische Auswertung auf Ticketzahlen (veraktet ja/nein) und Schlagwörter, dann endgültiges Löschen Zwischen b) und c) ist eine Verkettung von Ticket und Kunde nur durch den Kunden möglich, indem er sich mit der Ticketnummer an das ULD wendet. 29
OTRS mit LDAP-Anbindung der Kunden Endgültiges Löschen aus der customer_user-tabelle erst bei Ausscheiden aus dem Kundenstamm möglich Bedingung für Anmeldung am System Mögliche Lösung: Verknüpfen des Tickets mit einem anonymen Standardkunden (lokal in OTRS DB zu hinterlegen, ohne Anmelderechte!) Löschen bzw. x-en des Kundennamens aus dem article_body Entfernen von Mailadresse / Telefon aus dem article_body mittels Suchmuster ( Mailsignaturen) 30
Grenzen der Anonymisierung Identifizierbarkeit der Kunden / Bearbeiter durch Umschreibungen im Text Verkettbarkeit von Kunden und IT-Geräten Personenbezogene Daten in weiterhin benötigten Dokumentenanhängen Wägen Sie Aufwand, Nutzen und Risiken ab! Löschen eines Ticketvorganges kann effektiver sein Ausleiten der zur Statistik benötigten Daten in andere Systeme kann effektiver sein 31
Kontaktdaten Vielen Dank für Ihre Aufmerksamkeit! Unabhängiges Landeszentrum für Datenschutz Anke Nöbel Holstenstraße 98 24103 Kiel 0431-988-1395 anoebel@datenschutzzentrum.de 32