Zurück zum Inhaltsverzeichnis des 38. Tätigkeitsbericht
Inhalt
Sowohl die Datenschutzgesetze der Länder als auch das Bundesdatenschutzgesetz enthalten Regelungen, aus denen sich die Pflicht zur Protokollierung ergibt oder zumindest ableiten lässt. In einigen Landesdatenschutzgesetzen findet man das Regelungsziel Revisionsfähigkeit, das insbesondere durch die Maßnahme der Protokollierung umgesetzt werden kann. Das Bundesdatenschutzgesetz (BDSG) und andere Landesdatenschutzgesetze normieren Kontrollziele wie Eingabekontrolle oder Verantwortlichkeitskontrolle, aus denen sich ebenfalls die Pflicht zur Protokollierung ableiten lässt. Im BDSG zeigt sich am Beispiel der Anlage zu § 9, dass praktisch keine der dort konkret aufgeführten technisch-organisatorischen Maßnahmen ohne das Vorsehen einer Nachweismöglichkeit, die typischerweise in Form eines Protokolls geschieht, umsetzbar ist. Für eine Reihe von Verwaltungsverfahren gelten zudem bereichsspezifische, vom Datenschutzrecht des Bundes bzw. des betreffenden Landes abweichende, oft wesentlich konkretere Protokollierungsvorschriften (Beispiele: Meldegesetze, Polizeigesetze, Verfassungsschutzgesetze usw.).
Obwohl die Datenschutzgesetze von Bund und Ländern Regelungen enthalten, aus denen sich die Pflicht zur Protokollierung ableiten lässt, gibt es nur wenige Vorgaben für die konkrete Ausgestaltung der Protokollierung. Dennoch haben sich auf Basis der Anforderungen erprobte Vorgehensweisen entwickelt, die in diesem Text als grundlegende Empfehlungen dargestellt werden.
2 Grundsätze
Die Zweckbindung von Protokolldaten ist in den Datenschutzgesetzen von Bund und Ländern explizit geregelt (z. B. § 31 BDSG oder § 13 Abs. 5 HDSG sowie § 34 Abs. 6 HDSG). Die Protokollierung dient allein dem Zweck der Aufrechterhaltung von Datenschutz und Datensicherheit und darf grundsätzlich nicht für eine automatisierte Verhaltens- und Leistungskontrolle der Beschäftigten genutzt werden.
Alle Protokolldaten unterliegen also einer strikten Zweckbindung. Diese strikte Zweckbindung ist die Konsequenz aus dem Umstand, dass Protokollierungsdaten einen umfassenden Einblick in die Tätigkeiten der Administratoren, Nutzer bzw. Anwender ermöglichen, sie aber auch für die genannten Kontrollzwecke erforderlich sind.
Für die Gestaltung der Protokollierungsverfahren gilt der Grundsatz der Erforderlichkeit. Art, Umfang und Dauer der Protokollierung sind demnach auf das zur Erfüllung des Protokollierungszwecks erforderlichen Maß zu beschränken.
Für die technische Ausgestaltung und Auswahl der Verfahren der Protokollierung ist das Gebot der Datensparsamkeit und Datenvermeidung zu befolgen. Hierbei sind insbesondere die Möglichkeiten zur Pseudonymisierung oder Anonymisierung zu berücksichtigen. Im Falle der Pseudonymisierung ist das Verfahren darzustellen, mit dem die Zuordnung zwischen Person und Pseudonym geregelt ist.
3 Zweck und Anforderungen an eine Protokollierung
Der Zweck der Protokollierung besteht darin, ein Verfahren zur Verarbeitung personenbezogener Daten so transparent zu machen, dass die Ordnungsmäßigkeit bzw. ein Verstoß gegen die Ordnungsmäßigkeit einer Verarbeitung personenbezogener Daten nachweisbar ist. Die Protokolldaten müssen darüber Auskunft geben können, wer wann welche personenbezogene Daten in welcher Weise verarbeitet hat.
Entsprechend den allgemeinen Anforderungen an Datensicherheit und Datenschutz - oder allgemeiner: an Beweissicherheit und Revisionsfestigkeit – und der gleichzeitig auszuschließenden automatisierten Leistungs- und Verhaltenskontrolle der an der Datenverarbeitung beteiligten Personen, müssen Protokolldaten mit Personenbezug zweckgebunden, vollständig und datensparsam eingerichtet sein. Sie müssen die tatsächlich erfolgten Operationen, die beteiligten Anwendungen, Maschinen und Personen mit Zeitbezug korrekt dokumentieren. Dabei besteht regelhaft ein Zielwiderspruch zwischen der Vollständigkeit und der Datensparsamkeit. Dieser Konflikt lässt sich nur vor dem Hintergrund der verfahrensspezifischen Bedingungen so weit auflösen, um so einen bestmöglichen Ausgleich der Ziele zu erreichen. Protokolldaten dürfen nicht nachträglich verändert werden können und nur Berechtigten zugänglich sein.
Die ordnungsgemäße Funktion des Protokollierungsverfahrens und die Gültigkeit von Protokolldaten muss durch geeignete Tests sichergestellt werden. Diese sollten ein gezieltes Durchführen von zu protokollierenden Ereignissen und eine darauf folgende Überprüfung, ob diese Ereignisse sich in den Protokolldaten wiederfinden lassen, umfassen. Solche Tests sind immer dann notwendig, wenn die protokollierenden Systeme oder Systemteile verändert werden. Dies gilt insbesondere, wenn die Änderung am System einer datenschutzrechtlichen Freigabe bedarf.
Anforderungen an Vertraulichkeit, Integrität und Authentizität von Protokolldaten sollten mit kryptologischen Verfahren zur Verschlüsselung und Signierung nach dem Stand der Technik sichergestellt werden.
4 Arten von Protokolldaten
Bei der Protokollierung ist zwischen den Aktivitäten der Maschinen, der Administratoren sowie der Nutzer und Anwender zu unterscheiden. Administratoren können einen besonderen Einfluss auf die Strukturen eines IT-Systems ausüben, weshalb sie bei der Nutzung administrativer Rechte einer besonderen Kontrolle unterliegen. Die Nutzung administrativer Rechte muss zu einem Eintrag im Protokoll führen.
Unter Nutzung administrativer Rechte sind üblicherweise Maßnahmen zur Installation, Modifikation und Konfiguration von Hard- und Software zu verstehen.
Während die Protokollierung der Maschinen und der administrativen Tätigkeiten den Charakter einer Systemüberwachung hat, dient die Protokollierung der Benutzeraktivitäten im Wesentlichen der Verfahrensüberwachung.
Beide Protokollierungsformen dienen dazu, die Ordnungsmäßigkeit der Datenverarbeitung nachzuweisen bzw. auf Anforderung nachweisen zu können.
4.1 Protokollierung administrativer Tätigkeiten
Es müssen die Ereignisse und Tätigkeiten protokolliert werden, die die Funktionsweise der informationstechnischen Geräte sowie der Programme, der Dateien, die Speicherorganisation und die Nutzungsrechte einer automatisierten Verarbeitung personenbezogener Daten verändern.
Dabei ist auch zu beachten, dass die Protokollierung auch explizit zum Schutz der Administratoren vor unberechtigten Vorwürfen hinsichtlich eines möglichen Missbrauchs dienen kann. Ohne eine entsprechende Protokollierung administrativer Tätigkeiten könnten solche Vorwürfe gegen Administratoren nicht nachhaltig entkräftet werden.
Administrationstätigkeiten, wie bspw. die Verwaltung einer Datenbank, müssen unter einer personalisierten Administrationskennung durchgeführt werden, während die restliche nichtadministrative Arbeit mit normalen Benutzerrechten unter der allgemeinen Nutzerprotokollierung erfolgt.
Es muss verhindert werden, dass
4.2 Protokollierung der Nutzung von IuK-Systemen
Bei der Benutzung von Verfahren zur automatisierten Verarbeitung personenbezogener Daten müssen die Tätigkeiten protokolliert werden, die zum Nachweis einer korrekten, rechtskonformen Verarbeitung notwendig sind.
Die Inhalte der Protokolldaten orientieren sich hierbei an der konkret durchgeführten Datenverarbeitung und am Schutzbedarf der verarbeiteten Daten. Näheres zur inhaltlichen Ausgestaltung findet sich im folgenden Abschnitt.
Üblicherweise müssen die Tätigkeiten der
5. Qualität der Protokolldaten
Entsprechend dem Zweck der Protokollierung müssen die in Protokolldaten aufgeführten Aktionen so aggregiert werden können bzw. sein, dass sie der kontrollierenden Instanz helfen, einen Sachverhalt zu rekonstruieren und zu bewerten.
5.1 Inhalt
Protokolldaten müssen Auskunft geben über
Die Darstellung der Tätigkeit bzw. des Ereignisses muss eindeutig Auskunft geben, welche Tätigkeit durchgeführt wurde bzw. welche Ereignisse und Operationen auf dem System stattfanden.
Auslöser eines zu protokollierenden Ereignisses ist in der Regel eine Person. Diese muss eindeutig bestimmbar sein. Grundsätzlich sollte die Person deshalb über einen direkt zuordenbaren Bezeichner - beispielsweise durch eine personenbezogene Zugangskennung - benannt werden. Als weitere Auslöser agieren darüber hinaus aber auch Server, Dienste bzw. Services, die automatisiert Protokolldaten erzeugen.
Bei einem Zugriff, bei dem Daten geändert wurden, muss die geänderte Teilmenge klar eingegrenzt benannt werden. Bei datenbankgestützten Systemen erfolgt dies üblicherweise durch Angabe eines oder mehrerer eindeutiger und nichtleerer Feldinhalte - im Allgemeinen Primärschlüssel. Bei einem ändernden Zugriff sollten die Daten vor und nach der Änderung protokolliert werden. Bei datenbankgestützten Systemen geschieht dies üblicherweise durch Benennung der geänderten Datenbankfelder und die Angabe der Feldinhalte vor und nach der Änderung.
Bei einem Zugriff, bei dem Daten nur gelesen wurden, müssen die Daten benannt werden, in die Einsicht genommen wurde. Die Darstellung erfolgt bei datenbankgestützten Systemen üblicherweise durch Angabe des Primärschlüssels und den Bezeichnern der übermittelten Datenfelder.
Der Zweck der Tätigkeit führt viele einzelne Operationen zu einem Vorgang zusammen. So kann beispielsweise das Anlegen eines neuen Benutzers eine Vielzahl von schreibenden und lesenden Zugriffen auf einem System auslösen. Diese einzelnen Operationen müssen dann aggregiert zu Aktionen oder Tätigkeiten zusammengeführt werden können.
5.2 Format
Die Protokolldaten müssen in einem durch gängige Analysewerkzeuge auswertbaren Format vorliegen.
Die Erfahrung hat gezeigt, dass Protokolldaten, die im CSV-Format vorliegen, zusammen mit den frei verfügbaren Tools awk oder grep die operativen Anforderungen an eine maschinell unterstützte Kontrollierbarkeit von Protokolldaten erfüllen. Das CSV-Format fasst üblicherweise einen Protokolleintrag in einer Zeile zusammen. Die Zeile wird in die abgrenzbaren Teilbereiche - beispielsweise Datum, Benutzerkennung, Tätigkeit - durch ein Trennzeichen aufgeteilt. Üblicherweise wird als Trennzeichen das Komma oder Semikolon verwendet. Sollten die Trennzeichen auch innerhalb eines abgrenzbaren Teilbereichs vorkommen, so sollten diese Teilbereiche durch Hochkomma eingeschlossen werden.
6 Technische und organisatorische Aspekte
Bei der Einführung von IuK-Technologie muss der gesamte Lebenszyklus eines Verfahrens betrachtet werden. Dieselbe Anforderung muss deshalb auch an die in diesem Verfahren anfallenden Protokolldaten gestellt werden.
6.1 Erzeugen
Für jedes Verfahren muss in einem Konzept festgelegt werden, welche Tätigkeiten im jeweiligen Verfahren zur Verarbeitung personenbezogener Daten nachzuweisen sind.
Die Notwendigkeit ergibt sich aus
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.
Aufgrund einer Bestandsaufnahme der geltenden Anforderungen muss das Verfahren daraufhin betrachtet werden, welche Tätigkeiten durch Protokolle dokumentiert werden müssen. Für jede Tätigkeit muss der Inhalt der Protokolldaten festgelegt werden. Diese Festlegungen sollten in die Dokumentation des Verfahrens aufgenommen werden.
Die Protokolldaten müssen vollumfängliche Auskunft geben. Jede als relevant eingestufte Tätigkeit muss deshalb zu einem Protokolleintrag führen.
IuK-Systeme, die einen direkten Zugriff auf personenbezogene Daten haben, müssen eine Protokollierung durchführen. Üblicherweise wird der Zugriff auf personenbezogene Daten über ein oder mehrere zentrale Systeme gesteuert. In diesem Fall kann die Protokollierung auf diese Systeme beschränkt werden.
Änderungen an der Konfiguration der Protokollierung müssen einen Eintrag im Protokoll erzeugen.
6.2 Übertragen
Werden Protokolldaten mit Personenbezug und/oder erhöhtem Schutzbedarf über Netze übertragen (z. B. bei zentraler Protokollspeicherung oder entfernter Auswertung), sind zur Wahrung der Vertraulichkeit, Integrität und Authentizität geeignete und für den Schutzbedarf angemessene kryptografische Verfahren nach dem Stand der Technik zu nutzen.
Voraussetzung für eine revisionssichere und datenschutzgerechte Protokollierung ist die vollständige Übertragung der Protokolldaten. Deshalb ist das verbindungsorientierte Transportprotokoll (TCP) dem verbindungslosen Transportprotokoll (UDP) vorzuziehen.
6.3 Speichern
Die Art und der Umfang der Speicherung der Protokolldaten muss festgelegt werden. Wenn eine Tätigkeit protokolliert wird, dann bedeutet dies aber auch, dass genau in diesem Moment der Erzeugung des Protokolldatums auch eine Kontrolle dieser Daten bzw. der Tätigkeiten geschehen kann. Es muss aus Gründen der Datensparsamkeit geprüft werden, ob ein derartiges, sofortiges Überprüfen von Tätigkeiten ohne Speicherung der Daten hinreicht und keine weitere, später erfolgende Kontrollmöglichkeit vorgesehen werden muss.
Die Zugriffsmöglichkeiten auf Protokolldaten sind zu minimieren, insbesondere für die Systemadministratoren, deren Tätigkeiten anhand dieser Protokolldaten kontrollierbar sein müssen. Um dieser speziellen Anforderung, sowie generell den Anforderungen an Datensicherheit und Datenschutz, gerecht werden zu können, sollten Protokolldaten nicht auf den Produktionsmaschinen, sondern auf eigens vorgehaltenen Protokollservern gespeichert werden. Der Zugriff auf diese dedizierten Protokollserver ist entsprechend zu regeln. Ebenso müssen die üblichen Mechanismen zur Datensicherung, wie das Prüfen des Wiederherstellens von Backups, des Lesen- und Verarbeitenkönnens (Hardware, Formate, Zertifikatehandling) auf den Protokollservern umgesetzt sein.
Die Sammlung von Protokolldaten zu einem festgelegten Zweck ist klar zu bezeichnen.
Hat das Sicherheitskonzept (Risikoanalyse) ergeben, dass von einem erhöhten Schutzbedarf der Protokolldaten auszugehen ist, sollten diese mit kryptografischen Verfahren auf dem Protokollserver ausreichend gesichert werden.
6.4 Auswerten
Als Grundlage für eine datenschutzkonforme Auswertung muss die Art und der Umfang der Auswertung unter Beachtung der engen Zweckbindung der Protokolldaten vorab festgelegt werden („Protokollierungskonzept“). Dieses Konzept ist Teil der zu erstellenden Risikoanalyse bzw. des Sicherheitskonzepts, die im Zuge der Vorabkontrolle zu fertigen sind.
Da Protokolldaten geeignet sind, das Verhalten oder die Leistung der Beschäftigten zu überwachen, sollten Mitbestimmungsrechte der Personalvertretungen berücksichtigt werden (vgl. § 87 Abs. 1 Nr. 6 BetrVG oder § 74 Abs. 1 Nr. 17 HPVG). Die Art der Auswertung der Protokolldaten und die an der Auswertung Beteiligten sollten daher in einer Dienstvereinbarung geregelt werden.
Die Auswertung personenbezogener Protokolldaten muss also immer im Vier-Augen-Prinzip, unter Beachtung der personalrechtlichen Beteiligungspflichten und unter Einbeziehung der organisationseigenen Datenschutz- und IT-Sicherheitsbeauftragten, erfolgen.
Bereits bei der Planung der Protokollinhalte sind typische Szenarien zur Auswertung betrachtet worden. Für diese Szenarien müssen geeignete Mechanismen zur Auswertung vorgehalten werden. Für die häufigsten Auswertungen sollte bereits im Verfahren selbst eine Möglichkeit zur Auswertung geschaffen werden.
Für speziellere Auswertungen muss dann unter Nutzung einheitlicher Protokollformate (vgl. Abschnitt „Inhalte“) eine auf den jeweiligen Zweck zugeschnittene Auswertung durchgeführt werden.
Für die Auswertung von Protokolldaten müssen vorab typische Szenarien geplant werden, in denen Protokolldaten entweder anlassbezogen oder regelmäßig ausgewertet werden. Die Szenarien sollten die zu erwartenden Auskunftsersuchen interner und externer Stellen berücksichtigen.
Werden Protokolldaten einer organisationsexternen Instanz zur Auswertung übergeben, so ist, durch geeignete technische und organisatorische Maßnahmen, eine Weitergabe-, Verwendungs- und Löschkontrolle für diese Daten zu etablieren.
Die Vorgehensweise zur Auswertung der Protokolldaten ist zu dokumentieren und die Durchführung ihrerseits zu protokollieren.
6.5 Löschen
Für jedes Protokolldatum ist bereits vor dem Erzeugen die Aufbewahrungsdauer festzulegen. Für die Aufbewahrung der Protokolle gelten die allgemeinen Löschungsregeln der Datenschutzgesetze. Ein Maßstab ist mithin die „Erforderlichkeit der Aufgabenerfüllung”. Gibt es keinen zwingenden Grund für das weitere Vorhalten von Protokolldateien, besteht eine Pflicht zur Löschung.
Somit wird die Länge der Aufbewahrungsdauer maßgeblich durch den geplanten Auswertungszyklus bestimmt. Je nach Verfahrensart können Fristen von nur wenigen Tagen bis hin zu mehreren Monaten zweckmäßig und akzeptabel sein.
Wird diese Dauer überschritten, muss das Datum gelöscht werden.
Mit Blick auf einige Landesdatenschutzgesetze, in denen die Speicherdauer für Protokolldaten selbst bei der Verarbeitung ausschließlich automatisiert gespeicherte Daten auf ein Jahr begrenzt wird (z. B. § 6 Abs. 4 LDSG S-H oder § 22 Abs. 4 DSG M-V), sollte die Speicherdauer grundsätzlich auf höchstens ein Jahr begrenzt werden, soweit nicht spezialgesetzliche Regelungen oder verfahrensspezifische Bedingungen andere Löschfristen zwingend erfordern.
Der Umgang mit Protokolldaten, insbesondere aber das Verfahren zum Löschen der Protokolldaten muss beschrieben sein. Es müssen dabei auch die Protokolldaten in die Löschung einbezogen werden, die auf Datensicherungsmedien oder bei einem Auftragsdatenverarbeiter gespeichert sind.
Bei der Protokollierung von Löschvorgängen für Protokolldaten dürfen keine personenbezogenen Daten in den Inhalten des Lösch-Protokolls enthalten sein. Stattdessen sind gegebenenfalls Hinweise auf Aktenzeichen oder Dateinamen aufzunehmen. Ferner müssen Angaben darüber, welche Person oder welche Systemkomponente die Löschung dieser Protokolldaten zu welchem Zeitpunkt vorgenommen hat, enthalten sein (Beispiel: „Gelöscht Protokolldaten_Fachverfahren_AA200_bis_ZZ620_von 200106_bis_200606, Admin_A, 20090302_1510_35“).
Soweit ein Protokoll der Verfahrensdokumentation dient, kann die erforderliche Speicherdauer identisch sein zur Dauer der Dokumentationspflicht und mehrere Jahre betragen. Dies gilt beispielsweise für die Dokumentation, wer wann welche Zugriffsrechte besaß und umfasst das Anlegen und Löschen von Benutzerkennungen und die Vergabe von Zugriffsrechten. Ein anderes Beispiel, bei dem eine langjährige Speicherung erforderlich sein kann, betrifft lesende Zugriffe die eine Datenübermittlung darstellen; dies wäre der Fall, wenn die Daten verarbeitende Stelle einer anderen Daten verarbeitenden Stelle ein Leserecht einräumt, ohne dass eine Auftragsdatenverarbeitung vorliegt. In diesen und anderen Fällen könnten aus den Protokollen Berichte erstellt werden, um das Verfahren zu dokumentieren. Auf die Speicherung der Protokolle kann anschließend verzichtet werden, falls die Berichte gegen nachträgliche Änderungen geschützt sind und festgestellt werden kann, ob sie vollständig sind.
7 Weiterführende Literatur
Inhalt
Personenbezogene Daten sind vor der Freigabe eines Systems nicht weniger schutzbedürftig als nach dessen Freigabe. Die Regelungen der Landesdatenschutzgesetze und des Bundesdatenschutzgesetzes gelten für die Verarbeitung personenbezogener Daten ungeachtet der Frage, ob die Datenverarbeitung bereits im Produktivbetrieb oder noch in einer Projektphase erfolgt.
Unabhängig von der jeweiligen Phase, in der sich ein Projekt befindet, ist eine Dokumentation erforderlich, der
Der Detaillierungsgrad dieser Dokumentation kann sich nach der Entwicklungsphase richten, in der sich ein Verfahren zur Verarbeitung personenbezogener Daten befindet.
Zu unterscheiden ist der Projektbetrieb von dem Produktivbetrieb.
2 Projektbetrieb
2.1 Funktionstest
Der Zweck des Funktionstests ist es, die grundsätzliche Verwendbarkeit von Programmen und Geräten für die nachfolgenden Projektphasen sicherzustellen.
Ein Test zeichnet sich durch die folgenden Merkmale aus:
2.2 Integrations- und Abnahmetest
Der Zweck der Integrations- und Abnahmetests besteht darin, das Konzept und die Implementierung vor dem Auftreten von (z. B. im Funktionstest nicht erkannten) Designschwächen oder Implementierungsfehlern in einer quasi-produktiven Umgebung mit realistischen Lastszenarien abzusichern. Mit Hilfe von Integrations- und Abnahmetests sollen vor einem Pilotbetrieb (siehe Abschnitt 3.1) oder einer Freigabe des Regelbetriebs eventuell vorhandene oder vermutete Risiken ausgeschlossen werden, die unter den Bedingungen des Funktionstests nicht abgeschätzt werden konnten. Derartige Tests sind zeitlich streng limitiert auf detailliert beschriebene Szenarien zu beschränken.
Die Integrations- und Abnahmetests sollten nach Möglichkeit nicht mit personenbezogenen Daten durchgeführt werden.
Personenbezogene Daten dürfen nur im Rahmen zusätzlicher, minimierter Tests verwendet werden. Grundlegende Funktionen müssen bereits im Funktionstest mit ausreichend anonymisierten Daten überprüft werden. Auf derartige erste Funktionstests darf nicht wegen der ohnehin geplanten Integrations- und Abnahmetests verzichtet werden.
Zu Testzwecken darf eine Kopie der erforderlichen Originaldatensätze verwendet werden, wenn eine andere Rechtsvorschrift dies ausdrücklich erlaubt oder falls sich im Ausnahmefall trotz Nachbildung im Funktionstest ein Fehler aus dem Produktionsbetrieb nicht ermitteln, sondern nur mit Originaldaten aufklären lässt. Unter diesen Voraussetzungen können personenbezogene Daten zu Testzwecken verwendet werden wenn,
Der/die behördliche Datenschutzbeauftragte bzw. – soweit ein solcher nicht bestellt wurde – der/die Landesdatenschutzbeauftragte sowie die betroffenen Daten verarbeitenden Stellen – soweit nicht mit der Fachlichen Leitstelle identisch – sind vorab zu informieren.
Die Integrations- und Abnahmetests müssen in einer definierten und kontrollierten Umgebung stattfinden.
Gegenstand der Integrations- und Abnahmetests ist insbesondere auch der Test und die eventuell notwendige Korrektur der erforderlichen technischen und organisatorischen Sicherheitsmaßnahmen. Sie dienen als Grundlage für die Erstellung des Sicherheitskonzepts und der Risikoanalyse für den späteren Regelbetrieb. Die Durchführung von Integrations- und Abnahmetests ist Voraussetzung, um das System unter Sicherheitsgesichtspunkten für den Regelbetrieb freigeben zu können.
Werden personenbezogene Daten im Integrations- und Abnahmetest verwendet, dann bedarf es hierzu zumindest einer Kurzfassung eines IT-Konzeptes sowie eines auf die Testbedingungen angepassten Sicherheitskonzeptes.
3 Produktivbetrieb
3.1 Pilotbetrieb
Der Zweck des Pilotbetriebs besteht darin, einen Echtbetrieb in einem nach zeitlich und sachlich begrenzten Bereich durchzuführen, um die definierten Anforderungen technischer und organisatorischer Art erfahrungsgestützt auf ihre Praxistauglichkeit prüfen und gegebenenfalls verändern zu können.
Innerhalb des Pilotbetriebs wird in der Regel der führende Datenbestand bearbeitet. Ist beispielsweise eine stichtagsbezogene Umstellung von Alt- auf Neuverfahren erforderlich, kann ein Parallelbetrieb zwischen Alt- und Neuverfahren vorübergehend erforderlich sein. Es sollte aber kein Parallelbetrieb stattfinden, bei dem ein eventuell noch vorhandenes Alt-Verfahren das führende System bleibt. In einem Piloten dürfen in einem zeitlich definierten Rahmen personenbezogene Daten verarbeitet werden.
Voraussetzung für einen Pilotbetrieb ist ein IT-Konzept, aus dem sich der Zweck des Verfahrens sowie das Ziel des Pilotbetriebes ergeben.
Soweit im Piloten personenbezogene Daten verarbeitet werden, bedarf es eines vollständigen Sicherheitskonzepts und einer auf dem Sicherheitskonzept aufbauenden Risikoanalyse. Wird der Pilotbetrieb nur in einem einschränkten Umfang aufgenommen, kann sich auch das Sicherheitskonzept auf diesen begrenzten Funktionsumfang beschränken. Entspricht der Pilot bereits dem Regelbetrieb der Verarbeitung personenbezogener Daten, so hat sich das Sicherheitskonzept vollständig an diesen Anforderungen zu orientieren.
Sollen im Piloten die Wirksamkeit der in dem Sicherheitskonzept beschriebenen technischen und organisatorischen Maßnahmen unter Realbedingungen überprüft werden, so muss das Sicherheitskonzept Aussagen über die Minimierung der gegebenenfalls für personenbezogene Daten auftretenden Risiken treffen.
Ein Pilotbetrieb bedarf grundsätzlich der Freigabe durch die Leitung, wenn personenbezogene Daten verarbeitet werden. Für den Pilotbetrieb kann die Freigabe auch an eine „befugte Person“ delegiert werden.
3.2 Regelbetrieb
Der Zweck des Regelbetriebes besteht darin, ein automatisiertes Verfahren gemäß den definierten Anforderungen und vereinbarten Zielen zu betreiben. Die geltenden Regeln zur ordnungsgemäßen Verarbeitung personenbezogener Daten sind zu beachten.
Der Regelbetrieb erfolgt mit der Freigabe durch die Leitung. Die Freigabe hat schriftlich zu erfolgen.
Vor dem Beginn des Regelbetriebs sind die eingesetzten Programme und Sicherheitsmaßnahmen zu testen. Solche Tests dürfen beispielsweise mit personenbezogenen Daten von Personen durchgeführt werden, die für das Verfahren verantwortlich oder Mitarbeiter des Projekts sind und diesen Tests zugestimmt haben. Gut dokumentierte Funktionstests, Integrations- und Abnahmetests aus den vorherigen Projektphasen können den Aufwand für die notwendigen Tests vor der Freigabe des Verfahrens erheblich reduzieren.
Die Authentisierung von Personen mit bestimmten körperlichen Merkmalen wie z.B. Fingerabdrücken, Gesichtsgeometrie oder Irismuster wird gelegentlich als Alternative zu den Authentisierungsverfahren durch Besitz und/oder Wissen angesehen. In diesem Papier geht es nicht um die spezifischen Datenschutzfragen beim Einsatz biometrischer Verfahren, sondern um die Möglichkeiten und Grenzen dieser Verfahren bei der Authentisierung.
Die biometrische Authentisierung setzt zunächst die Erfassung eines biometrischen Merkmals einer Person mittels optischer, thermischer, chemosensorischer, akustischer oder drucksensitiver Verfahren für spätere Vergleichszwecke voraus. Aus den erfassten Rohdaten wird mittels geeigneter Algorithmen ein sog. Template (Muster) berechnet und zentral oder dezentral für spätere Vergleiche (z.B. auf einer Chipkarte) abgespeichert. Dabei ist sicherzustellen, dass eine Rekonstruktion des biometrischen Merkmals durch Rückrechnung aus dem Template ausgeschlossen ist.
Beim eigentlichen Authentisierungsvorgang wird mit den gleichen Erfassungssystemen das biometrische Merkmal erfasst und ebenfalls mit den gleichen geeigneten Algorithmen aus dem aktuellen Merkmal die sog. biometrische Signatur berechnet. Die biometrische Signatur wird dann mit dem hinterlegten Template computergestützt verglichen. Das Ergebnis dieses Vergleichs führt dann zur automatisierten Entscheidung, ob die Authentisierung zum Erfolg führt oder nicht.
Die wichtigsten Erkennungsarten bei der Überprüfung sind die biometrische Verifikation (1:1-Vergleich) und die biometrische Identifikation (1:n-Vergleich). Bei der Verifikation wird die Identität durch den Vergleich der biometrischen Signatur mit genau einem Template geprüft, das dezentral, zum Beispiel auf einem bei der zu verifizierenden Person befindlichen Chip gespeichert werden kann. Bei der Identifikation wird die biometrische Signatur mit einer Vielzahl von Templates verglichen, die zentral in einer Datenbank gespeichert sind.
Aus datenschutzrechtlicher Sicht ist wegen der Datensparsamkeit und -vermeidung der biometrischen Verifikation eindeutig der Vorzug vor der biometrischen Identifikation zu geben. Dies gilt insbesondere bei einer dezentralen Speicherung der Referenzdaten.
Die Treffsicherheit biometrischer Verfahren folgt im Gegensatz zu den kausalen Verfahren der Authentisierung durch Besitz und/oder Wissen Gesetzen der Wahrscheinlichkeit. Es ist stets davon auszugehen, dass die biometrische Signatur und das Template nie ganz gleich sein werden. Der Vergleich zwischen Signatur und Template kann daher nur einen Grad von Ähnlichkeit ermitteln.
Je nach den Anforderungen an die Treffsicherheit des biometrischen Erkennungssystems muss ein Schwellenwert für die Ähnlichkeit festgelegt werden, über dem die Berechtigung vergeben (Acceptance) und unter dem sie verweigert (Rejection) wird. Je höher (oder geringer) der Schwellenwert gewählt wird, desto geringer (oder höher) ist die Wahrscheinlichkeit, dass eine Berechtigung unzutreffend erteilt wird. Andererseits steigt (sinkt) mit dem Schwellenwert die Wahrscheinlichkeit, dass jemand unberechtigt abgewiesen wird.
Die Wahrscheinlichkeit, dass jemand unrichtigerweise zurückgewiesen wird, wird als „False Rejection Rate“ (FRR) bezeichnet; die Wahrscheinlichkeit, dass jemand unberechtigterweise eine Berechtigung erteilt bekommt, wird als „False Acceptance Rate“ (FAR) bezeichnet. Unter Kalibrierung versteht man die für eine konkrete Anwendung sinnvolle Vergabe von FRR bzw. FAR. Wenn eine der beiden Größen festgelegt bzw. beschränkt wird, ergibt sich die Festlegung bzw. Beschränkung für die andere wegen der wechselseitigen Abhängigkeit aus dem jeweiligen konkreten biometrischen Verfahren.
Die „Equal Error Rate“ ist der Wert, für den FRR = FAR gilt. Sie kann ein sinnvoller Kompromiss hinsichtlich der Sicherheitskalibrierung sein. Es gibt jedoch Anwendungsszenarien, bei denen die FAR im Vergleich zur FRR sehr niedrig sein muss, z.B. beim Zutritt/Zugang zum Hochsicherheitsbereich eines Kernkraftwerkes. Und es gibt Anwendungen, bei denen die FRR beispielsweise aus Performancegründen sehr niedrig sein muss und man eine höhere FAR gerne in Kauf nimmt. Das wäre bei der Zugangskontrolle für Besucher eines großen Fußballspiels der Fall, wenn wenige unberechtigt eingelassene Besucher akzeptiert werden.
Von den vielen übrigen „Rates“, die etwas über das biometrische System aussagen, sei noch die „Failure to Enroll Rate“ (FTE) erwähnt, die die Wahrscheinlichkeit benennt, dass von einer Person aus medizinischen Gründen kein brauchbares Template zu späteren Vergleichszwecken gewonnen werden kann. Dies gilt vor allem für Fingerabdrücke, bei denen FTEs von ca. 2 % der Gesamtbevölkerung ermittelt worden sind.
FRR und FAR sind abhängig von der Qualität des biometrischen Systems hinsichtlich der Genauigkeit der Erfassung, der Qualität der Template- und Signatur-Berechnung und der Genauigkeit des Vergleichs, von der Kalibrierung des biometrischen Systems, also der Wahl der Schwellenwerte und der Kooperation der Betroffenen.
Bei allzu kleiner FAR wird die FRR zu groß, d.h. z.B., bei einem Zutrittskontrollsystem bleiben zu viele Berechtigte vor der Tür. Dagegen führt eine allzu kleine FRR zu einer großen FAR, d.h. zu viele Unberechtigte können die Tür durchschreiten.
Es gibt eine Fülle von Beispielen, die belegen, dass ein korrekter Ablauf des Authentisierungsverfahrens nicht sicherstellt, dass auch die richtige Person das System nutzt.
So können die Authentisierungsmittel beispielsweise
Die tatsächliche Bindung des biometrischen Merkmals an die Person ist als echter Vorteil gegenüber personenbezogenen Merkmalen wie Besitz und Wissen zu werten, bei denen die Anwesenheit der Person nur angenommen werden kann.
Deshalb sind für biometrische Authentisierungsverfahren – unabhängig vom verwendeten biometrischen Verfahren – besondere Vorkehrungen zu treffen:
Die biometrischen Daten sind nicht geheim und sie können nach Bekanntwerden oder Missbrauch nicht verändert oder gesperrt werden. Deshalb ist Folgendes wichtig: