Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein

6         Systemdatenschutz

6.1         Wer testet, sündigt nicht

Das ULD erreichen immer wieder Anfragen, wie man datenschutzgerecht aus einer Projektphase in den Produktivbetrieb eines Verfahrens übergehen kann. Dieser Übergang ist entscheidend, da die Arbeiten zur Inbetriebnahme des Verfahrens abgeschlossen sein müssen und das Verfahren getestet und freigegeben werden muss.

Programme und Sicherheitsmaßnahmen sind vor der Aufnahme der Verarbeitung personenbezoge­ner Daten zu testen. Die konkrete Durchführung der Tests ist aus gutem Grund nicht vorgegeben. Die Verfahrensweisen zu Test und Freigabe müssen nämlich auf das jeweilige Verfahren und die aktuelle Einsatzsituation angepasst werden. Häufig wird die Einführung eines Verfahrens zur Verarbeitung personenbezogener Daten in ein­zelne Phasen gegliedert und im Rahmen eines Projekts durchgeführt; Ähnliches gilt für wesentliche Verfahrensänderungen (28. TB, Tz. 6.2 und Tz. 6.3). Beim Übergang in die sogenannte Pilotphase müssen alle wesentlichen Tests und Frei­gaben erfolgt sein. Typischerweise wird in einer Pilotphase in einem beschränkten Umfeld die volle Funktionalität mit Echtdaten für einen begrenzten Zeitraum ausprobiert. Sie ist bereits eine Phase des Produktivbetriebs. Alle Testmaßnahmen und Ergebnisse müssen protokolliert werden. Die Freigabe des Verfahrens für eine Pilotphase hat schriftlich zu erfolgen.

Unabhängig von der jeweiligen Phase, in der sich ein Projekt befindet, ist eine Dokumentation erforderlich, der Folgendes zu entnehmen ist:

• die definierten Ziele,
• die technischen Mittel und Instrumente,
• die Festlegung der einzelnen Projektphasen mit Beginn und Ende,
• die Benennung der verantwortlichen Personen und
• die Entscheidung der verantwortlichen Person über den Beginn einer Projekt­phase, die Dokumentation des Projektverlaufs sowie die Ergebnisse und Schluss­folgerungen.

Der Detaillierungsgrad dieser Dokumentation kann sich nach der Entwicklungs­phase richten, in der sich ein Verfahren zur Verarbeitung personenbezogener Daten befindet.

Bei unseren Beratungen empfehlen wir stets, eine grobe Einteilung in einen „Projektbetrieb“ und in einen „Produktivbetrieb“ durchzuführen. Die Regelungen des Landesdatenschutzgesetzes (LDSG) und der Datenschutzverordnung (DSVO) für die Verarbeitung personenbezogener Daten gelten unabhängig davon, ob diese bereits im Produktivbetrieb oder noch im Projektbetrieb erfolgt. Wird die Inbetriebnahme eines Verfahrens in einzelne Phasen aufgeteilt, kann man die Dokumentation und notwendigen Regelungen genau wie das Verfahren selbst schrittweise entwickeln und fortschreiben. In unseren Beratungsprojekten hat sich eine weitere Unterteilung des Projektbetriebs und des Produktivbetriebs als zweckmäßig erwiesen, die im Folgenden dargestellt wird: nämlich zum einen die Funktionstests sowie Integrations- und Abnahmetests als Teil des Projektbetriebs, zum anderen die Phasen des Piloten und des Regelbetriebs, die beide dem Produktivbereich zuzurechnen sind.

Insbesondere bei komplexeren Verfahren  sollten aufeinander aufbauende Tests und Freigaben durchgeführt werden. Denn immer gilt: Personenbezogene Daten sind vor der Freigabe  eines Systems nicht weniger schutzbedürftig als nach dessen Freigabe. IT-Verantwortliche müssen sich im Klaren darüber sein, dass jede Verarbeitung personenbezogener Daten den gesetzlichen Regelungen unterliegt, unabhängig davon, welchen Namen man ihr gibt.

• Funktionstests

Der Zweck des Funktionstests ist es, die Verwendbarkeit von Programmen und Geräten für die nachfolgenden Projektphasen sicherzustellen. Ein Funktionstest zeichnet sich durch die folgenden Merkmale aus:

• Keine Anwender, nur Tester:

Es gibt außer einer kleinen Gruppe von Testern mit genau umrissenen Aufgaben keine regulären Anwender des Verfahrens.

• Keine Verbindungen zu und kein Datenaustausch mit anderen Verfahren im Produktivbetrieb:

Tests finden in einer isolierten Testumgebung statt.

• Keine Verwendung personenbezogener Daten:

In einem Test dürfen keine realen personenbezogenen Daten verarbeitet und auch nicht aus anderen Produktivsystemen übernommen werden. Gegebenen­falls sind Echtdaten vor ihrer Übernahme in das Testverfahren zu anonymisieren bzw. zu pseudonymisieren.

Werden gemäß diesem Muster in Funktionstests keine personenbezogenen Daten verarbeitet, so sind im Testbetrieb auch keine Datenschutzanforderungen zu erfüllen. Verbindungen mit anderen Produktivsystemen der automatisierten Verar­beitung personenbezogener Daten sind ausgeschlossen. Durch die Funktionstests kann es so auch nicht zu gravierenden Auswirkungen auf andere Verfahren und deren Datenschutz- und Datensicherheitsniveau kommen.

• Integrations- und Abnahmetests

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 quasiproduktiven Umge­bung mit realistischen Lastszenarien abzusichern. Mithilfe von Integrations- und Abnahmetests sollen vor dem Pilotbetrieb oder der 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 limitiert auf detailliert beschriebene Szenarien zu beschränken. Sie sollten wenn möglich nicht personenbezogen durchgeführt werden. Perso­nenbezogene Daten dürfen jedoch im Rahmen zusätzlicher, eng zugeschnittener Tests verwendet werden. Grundlegende Funktionen müssen bereits im Funk­tionstest mit ausreichend anonymisierten Daten überprüft worden sein. Auf die ersten Funktionstests darf nicht wegen der ohnehin geplanten Integrations- und Abnahmetests verzichtet werden.

Zu Testzwecken darf eine Kopie der Originaldatensätze verwendet werden, wenn eine Rechtsvorschrift dies ausdrücklich erlaubt. Fehler können auch im begründeten Ausnahmefall mit Originaldaten aufgeklärt werden, wenn

• eine bereichsspezifische Rechtsvorschrift dies nicht ausdrücklich untersagt,
• eine Anonymisierung der Originaldaten für die vorgesehene Testkonstellation nur mit einem unvertretbar hohem Aufwand verbunden wäre,
• die verantwortliche Stelle dem Vorgehen schriftlich zugestimmt hat,
• bei der Durchführung oder Auswertung des Tests die schutzwürdigen Belange der Betroffenen und die Datensicherheit angemessen berücksichtigt werden,
• nur die für die Fehlerbehebung und Durchführung des Tests erforderlichen Personen die Daten nutzen können und
• Zugang zu diesen Daten nur Personen erhalten, die den jeweils maßgebenden Vertraulichkeitsgrundsätzen und insbesondere datenschutzrechtlichen Vorschrif­ten unterliegen.

Das Kopieren und das Verwenden der Originaldaten muss dokumentiert werden. Nach Beenden des Tests muss die Kopie der Originaldaten gelöscht oder anony­misiert werden. Der oder die behördliche Datenschutzbeauftragte muss vorab informiert werden.

Die Integrations- und Abnahmetests müssen in einer definierten und kontrollier­ten Umgebung stattfinden, um nachvollziehbar und aussagekräftig zu sein. Soll eine Netzanbindung ausprobiert werden, sind die Risiken durch zusätzliche Sicher­heitsmaßnahmen zu beschränken, z. B. durch eine geeignete Auswahl der Daten­sätze.

Werden personenbezogene Daten im Integrations- und Abnahmetest verwendet, bedarf es zumindest einer Kurzfassung eines IT-Konzeptes sowie eines auf die Testbedingungen angepassten Sicherheitskonzeptes. Gegenstand der Integrations- und Abnahmetests ist insbesondere auch die Prüfung und die eventuell notwendige Korrektur der erforderlichen technischen und organisatorischen Sicherheitsmaß­nahmen. Diese Tests dienen als Grundlage für die Erstellung der abschließend gültigen Sicherheitsdokumentation und der Risikoanalyse für den späteren Regel­betrieb. Die Durchführung von Integrations- und Abnahmetests ist Voraussetzung, um das System unter Sicherheitsgesichtspunkten für den Regelbetrieb freigeben zu können.

• Pilotbetrieb

Der Zweck des Pilotbetriebs besteht darin, einen Echtbetrieb in einem zeitlich und sachlich begrenzten Bereich durchzuführen. Es soll überprüft werden, ob das Verfahren den technischen und organisatorischen Anforderungen in der Praxis genügt. Beim Pilotbetrieb wird der führende Datenbestand bearbeitet. Es darf kein Parallelbetrieb stattfinden, bei dem ein eventuell noch vorhandenes altes Verfah­ren das führende System bleibt. In einem Piloten dürfen im 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 Pilotbetriebs ergeben. Soweit im Piloten perso­nenbezogene Daten verarbeitet werden, bedarf es eines vollständigen Sicher­heitskonzeptes und einer hierauf aufbauenden Risikoanalyse. Wird der Pilotbetrieb nur in eingeschränktem Umfang aufgenommen, kann sich auch das Sicherheits­konzept hierauf beschränken. Entspricht der Pilot bereits dem Regelbetrieb der Verarbeitung personenbezogener Daten, so hat sich das Sicherheitskonzept voll­ständig an diesen Anforderungen zu orientieren.

Ein Pilotbetrieb bedarf der Freigabe durch die Dienststellenleitung, wenn personenbezogene Daten verarbeitet werden. Für den Pilotbetrieb kann die Frei­gabe von der Dienststellenleitung auch an eine befugte Person delegiert werden.

• Regelbetrieb

Der Zweck des Regelbetriebs 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 schriftlichen Freigabe durch die Dienst­stellenleitung. Vor dem Beginn des Regelbetriebs sind die eingesetzten Programme und Sicherheitsmaßnahmen zu testen. Solche Tests dürfen z. B. mit Daten von Personen durchgeführt werden, die für das Verfahren verantwortlich oder Mitar­beiter des Projekts sind und diesen Tests zugestimmt haben. Gut dokumentierte Funktionstests sowie Integrations- und Abnahmetests aus den vorherigen Projekt­phasen können den Aufwand für diesen letzten Schritt eines notwendigen Test- und Freigabeverfahrens erheblich reduzieren.

 

6.2         Die neue Datenschutzverordnung

Seit Januar 2009 ist die neue Datenschutzverordnung in Kraft. Was ist geblieben, was wurde verändert?

Wie schon die alte, hat die neue Datenschutzverordnung vor allem ein Ziel: die Transparenz der automatisierten Verarbeitung personenbezogener Daten zu verbessern. Transparenz ist die wichtigste Voraussetzung, um technische und organisatorische Systeme beobachtbar und prüfbar zu machen. Ohne eine Prüf­fähigkeit der Verfahren und Systeme gibt es kein funktionierendes Datenschutz­management: Transparenz ist auch für die Beherrschbarkeit komplexer Systeme essenziell.

Das Einhalten von Datenschutzanforderungen kontrollierbar zu machen ist eine Herausforderung. Für das Prüfen von Zweckbindung und Erforderlichkeit perso­nenbezogener Datenverarbeitung reicht ein formaler Check von Maßnahmen der Datensicherheit nicht aus. Man muss die Wirklichkeit vor Ort verstehen, die mit automatisierten Verfahren abgebildet werden soll. Nur so lässt sich das Maß für eine zweckgemäße und datensparsame Verarbeitung finden. Auf dieser Grundlage können dann effektive und effiziente technische Maßnahmen und organisatorische Regelungen gefunden werden.

Die neue Landesverordnung über die Sicherheit und Ordnungsmäßigkeit automati­sierter Verarbeitung personenbezogener Daten (Datenschutzverordnung – DSVO) verbessert die Transparenz und Überprüfbarkeit der Datenverarbeitung durch präzise Dokumentationsanforderungen. Es wurden vor allem diejenigen Regelun­gen der DSVO überarbeitet und vereinfacht, die in Schulungen und Beratungen für Nachfragen und Diskussionen gesorgt hatten. Die Überarbeitung brachte einen angenehmen Nebeneffekt: Die neue DSVO ist schlanker als die alte, rein formal schon durch deren Verkürzung um drei Paragrafen auf nunmehr sieben. Neben der Bestimmung des Anwendungsbereichs, der Begriffe und den Regeln zum Übergang und Inkrafttreten konzentriert sich der Kern der DSVO auf nur noch drei Para­grafen. Es handelt sich hierbei um die Verfahrensdokumentation, die Dokumen­tation der Sicherheitsmaßnahmen sowie um Test und Freigabe.

Es wurde darauf geachtet, dass die Dokumentationsregelungen mit internatio­nalen Sicherheitsstandards wie BSI-Grundschutz oder der ISO-27000er-Reihe kompatibel sind. Anders formuliert: Wer sich an internationalen Sicherheits­standards orientiert, erfüllt viele Anforderungen der DSVO quasi nebenbei.

Die Bestandteile der Verfahrensdokumentation werden in zehn Punkten aufge­führt. Diese sind als Grobgliederung für das zu erstellende Dokument nutzbar. Zunächst ist der Zweck darzulegen, dann müssen die eingesetzten Geräte und Programme sowie deren Vernetzung beschrieben werden. Die technischen und organisatorischen Vorgaben und deren Umsetzung in einem Berechtigungskonzept sind ebenso zu beschreiben wie die Art und Weise der Protokollierung von Zugriffen und Veränderungen am Verfahren. Finden Datenübermittlungen an andere Stellen oder eine Datenverarbeitung im Auftrag statt, so muss dies nach­vollziehbar sein. Zum Abschluss sind die Maßnahmen darzustellen, wie Ansprü­chen von Betroffenen auf Auskunft entsprochen wird und wie die Berichtigung, Löschung und Sperrung personenbezogener Daten erfolgt. Die Verfahrensdoku­mentation muss für sachkundige Personen in angemessener Zeit nachvollziehbar sein. Sie ist dauernd fortzuschreiben und unterliegt einer Aufbewahrungsfrist von mindestens fünf Jahren.

Nicht neu, aber klarer formuliert ist, dass die Dokumentation mehrerer Verfah­ren oder mehrerer Verfahrensteile zusammengefasst werden kann. Daten verarbei­tende Stellen, die sich für eine gemeinsame Nutzung von IT-Verfahren entschei­den, können hiervon profitieren. Ein Großteil der Verfahrensdokumentation kann einmal zentral erarbeitet und dann bei jeder Stelle in die eigene Dokumentation übernommen werden.

Auf der Grundlage der Verfahrensdokumentation ist die Dokumentation der Sicherheitsmaßnahmen zu erstellen. Nach einer Analyse der vorliegenden Risiken müssen die getroffenen Sicherheitsmaßnahmen dokumentiert werden, die diese Risiken minimieren. Sofern für einzelne Risiken keine angemessenen Maßnahmen getroffen werden können oder sollen, sind diese als Restrisiken zu dokumentieren. Neu in der DSVO sind Bestimmungen zum Umgang mit Verschlüsselung sowie genauere Ausführungen zur Auswertung von Protokolldaten und zu Dokumen­tationspflichten bei einer Datenverarbeitung im Auftrag. Außerdem wurde der in Schleswig-Holstein bereits gängige Begriff des Datenschutzmanagementsystems aufgenommen, unter dem die Tätigkeiten eines Datenschutzbeauftragten zusam­mengefasst sind.

Bezüglich Tests und Freigaben ist eine Bestimmung hinzugekommen, dass beim Testen festgestellte Mängel entsprechend ihrer Bedeutung zu gewichten sind (Tz. 6.1). Eine Freigabe ist nur zulässig, wenn entsprechend der Gewichtung keine wesentlichen Mängel mehr bestehen; geringfügige Mängel müssen in angemessener Zeit beseitigt werden. Testergebnisse anderer Stellen können mit eigenen Ergeb­nissen kombiniert werden. Eine entsprechende Eigenorganisation vorausgesetzt, können mehrere Daten verarbeitende Stellen, die dasselbe Fachverfahren oder dieselbe technische Infrastruktur einsetzen, kooperativ und verteilt testen und so ihren Testaufwand reduzieren.

Die neue DSVO ist schlank und gut mit anderen Vorgehensweisen wie der Metho­dik nach BSI-Grundschutz kombinierbar. Sie unterstützt kooperative Infra­strukturen und Vorgehensweisen im Bereich der Informations- und Kommuni­kationstechnik durch die Möglichkeit, eine modulare Dokumentation aufzubauen.
Die neue DSVO ist im Gesetz- und Verordnungsblatt Schleswig-Holstein (GVOBl. Schl.-H. 2008, S. 841) und unter

https://www.datenschutzzentrum.de/material/recht/dsvo.htm

veröffentlicht.

Das ULD bietet kostenfreie Beratungen und Schulungen zur neuen DSVO an.

 

6.3         Die Europäische Dienstleistungsrichtlinie

Die Richtlinie über Dienstleistungen im Binnenmarkt 2006/123/EG von Ende 2006 soll sicherstellen, dass alle Verfahren und Formalitäten, die mit der Aufnahme oder Ausübung bestimmter Dienstleistungstätigkeiten verbunden sind, europaweit elektronisch über einen „Einheitlichen Ansprechpartner“ abgewickelt werden können.

Über die EU-Dienstleistungsrichtlinie (EU-DLR) sollen sich die Verwaltungen europaweit über regionale Anerkennungsverfahren für Dienstleistungstätigkei­ten austauschen und zudem problematische Antragsteller identifizieren können. In einem Binnenmarktinformationssystem („Internal Market Information System“, IMI) sollen die relevanten Informationen bereitgestellt und ausgetauscht werden (30. TB, Tz. 11.3). Die Richtlinie muss bis Ende 2009 umgesetzt werden. Sie bedeutet für den Datenschutz eine ganze Reihe an Chancen und Risiken.

Der Einheitliche Ansprechpartner (abgekürzt: EAP) soll als Verfahrensvermitt­ler zwischen einem Dienstleistungsanbieter aus dem europäischen Raum und den Behörden agieren, die die entsprechenden Prüfungen in ihrer Region vornehmen und Genehmigungen erteilen. Die Zuständigkeiten der Verwaltungen bleiben durch den EAP unangetastet.

Das Land Schleswig-Holstein hat deutschlandweit die Federführung zur Ausarbei­tung einer Vorlage für die rechtliche Umsetzung der EU-Dienstleistungsrichtlinie in den Bundesländern übernommen. Die sogenannte „Blaupause“, eine 172 Seiten umfassende Vorlage (Stand: September 2008), enthält einige datenschutzrechtliche Ausführungen sowie eine Vielzahl technischer Empfehlungen, die zum Teil auf noch nicht praxiserprobten Technologien aufsetzen.

Das in Schleswig-Holstein für die Umsetzung der EU-DRL zuständige Finanz­ministerium hat frühzeitig alle Beteiligten, die mit einem EAP kooperieren müssen, an einen Tisch geholt und will den EAP als Anstalt des öffentlichen Rechts, die für ganz Schleswig-Holstein zuständig ist, institutionalisieren. Daneben wurde begonnen, ein Prozesskataster aufzubauen, das all die Gesamtprozesse beschreibt, in denen einzelne Verwaltungen an einem Genehmigungsverfahren beteiligt sind. Bislang waren es die Antragsteller, die beim Durchlaufen der einzelnen Verwal­tungsstationen das gesamte Beantragungsverfahren kennenlernen und durchlaufen mussten. Die Anstalt wird gemeinsam vom Land, den Kommunen und den Kam­mern getragen.

Aus Datenschutzsicht sind bei der vorgesehenen Ausgestaltung zunächst zwei Fragen relevant: Welche Zuständigkeiten sollen bei dem viele Verwaltungstätig­keiten zentralisierenden EAP per Gesetz zusammengezogen werden? In welchem Ausmaß muss oder darf der EAP Kenntnis nehmen von den Inhalten der Anträge, obwohl er laut Richtlinie keine Zuständigkeit für deren inhaltliche Bearbeitung und die Erteilung oder Verweigerung von Genehmigungen hat?

Fällt ein relevanter Anteil inhaltlich-orientierter Verwaltungstätigkeit auf den EAP, dann muss eine Behörde aufgebaut werden, die hohen Anforderungen genügt in Bezug auf Personal, Verbindlichkeit und Validität der Auskünfte und Tätigkeiten, Fallmanagement und Wissensbasis, Aktenführung und nicht zuletzt Beachtung der (datenschutz-)rechtlichen Vorgaben. Die einzurichtende Informationstechnik muss Sicherheit gewährleisten und zugleich die zentralen bzw. dezentralen Zuständig­keiten berücksichtigen. Schließlich müssen die beteiligten Verwaltungen koope­rieren.

Das ULD hat angesichts der schwierigen Anforderungen ein Alternativmodell für den EAP entwickelt, bei dem Controlling und Operating der Prozesse funktional getrennt werden. Es geht darum, die Kontrolle des Gesamtprozesses zu optimieren und zugleich die fallbezogene Datenverarbeitung und die Kommunikation zwischen dem Dienstleister und der Verwaltung diesen zu überlassen. Die Verantwortung des EAP erstreckt sich dann nicht auf eine eigene umfassende Hochleistungs­informationstechnik mit „Datensafes“ zur Dokumentenablage, sondern nur auf sichere Abwicklungsverfahren für die Direktkommunikation zwischen Antrag­stellern und Genehmigungsbehörden. Der integre und vertrauliche Transport von Daten ließe sich über OSCI 2.0 (Online Services Computer Interface, Tz. 6.4) und die notwendige Authentisierung von Personen und Maschinen über den E-Govern­ment-Standard SAFE (Secure Access to Federated E‑Justice/E-Government, Tz. 6.4) realisieren.

Die Einrichtung eines EAP forciert die Digitalisierung und Automatisierung vieler Verwaltungstätigkeiten. Damit diese Technisierung gelingt, müssen die Verwaltungsverfahren als Prozesse zuvor standardisiert und formal beschrieben sein. Notwendige Bedingung ist also eine Transparenz der Verfahren der Organi­sation sowie der Datenverarbeitung. Etwaige rechtliche Regulierungs-, Zuständig­keits- bzw. Verantwortlichkeitslücken werden damit offenkundig.

Zur Beschreibung der Datenstrukturen im XML-Format kommen sogenannte XÖV-Standards zum Einsatz. Der Transport derartig strukturierter Daten geschieht über den internationalen Standard der sogenannten WebServices. Das bedeutet, dass die organisatorischen Prozesse, die Schnittstellen, Kommunikationskanäle, Formate, Daten und Datenflüsse auch zwischen den Verwaltungen offengelegt und abgestimmt werden müssen. Bei der Realisierung sind die Gebote zur Daten­sparsamkeit und zur Zweckbindung zu beachten. Die WebServices ermöglichen zudem, dass Daten dezentral, sozusagen an den Quellen, erhoben, gehalten und gepflegt werden können, was sich positiv auf die Datenqualität auswirkt. Die Daten können dort, wo sie gebraucht werden, zusammengeführt werden.

Aus Datenschutzsicht bedeutet die Technisierung der Verwaltung, dass auch die Methoden zur Kontrolle der Datenverarbeitung stärker technisiert werden müssen, im Sinne einer automatisierten Qualitätssicherung im Allgemeinen und eines internen und externen Datenschutzmanagements im Besonderen. Noch sind viele Punkte offen, die sich zu Risiken für den Datenschutz entwickeln können:

• Zum jetzigen Zeitpunkt zeigt die Blaupause an vielen Stellen Regelungslücken auf. Als ungeklärter Punkt ist das europaweite Handling von Zertifikaten herauszuheben, was für die Sicherstellung der Integrität und Authentizität von Dokumenten von zentraler Bedeutung ist. Es heißt bisher nur lapidar: „Elektro­nische Dokumente von Behörden aus anderen Mitgliedstaaten sind in der Regel als gültig anzuerkennen.“ Hier ist durch konkretere Vorgaben nachzubessern.
• Bei der Nutzung von WebServices ist nicht in jedem Fall klar festgelegt, welche Instanz unter welchen Bedingungen die Daten tatsächlich verarbeitet. Hier gilt es, rechtliche Anforderungen in technisch ausführbare WebService Privacy Policies umzuformulieren und dann zu implementieren, um den Transport und die Verarbeitung personenbezogener Daten über WebServices unter festgelegte Bedingungen zu stellen und dadurch Verbindlichkeit und Nachweisbarkeit von derartigen Transaktionen sicherzustellen.
• Nicht zuletzt besteht das Risiko, dass eine effiziente Technisierung der Daten­verarbeitung neue Begehrlichkeiten zur Überwachung von Mitarbeitern (Leistungs- und Verhaltenskontrollen), Bürgern und Kunden wecken kann. Dem kann durch eine datenschutzrechtliche Projektbegleitung entgegengewirkt werden.

 

6.4         OSCI-Transport  2.0 und SAFE : es gibt einiges zu tun

Beim Aufbau einer E-Government-Infrastruktur müssen viele einzelne Bau­steine miteinander gekoppelt werden. Um das Rad nicht jedes Mal neu zu erfinden, sind viele Teilbereiche inzwischen standardisiert. Datenschutz muss hierbei noch mehr berücksichtigt werden. Das ULD beteiligt sich gemeinsam mit den Kollegen anderer Bundesländer an den Standardisierungsbemühun­gen im E-Government, insbesondere bei OSCI (Online Services Computer Interface) und SAFE (Secure Access to Federated E-Justice/E-Government).

OSCI-Transport ist eine technische Infrastruktur zur Datenübermittlung und gilt als Schlüsseltechnik für die medienbruchfreie Abwicklung von Geschäftsprozessen über das Internet. OSCI-Transport erfüllt sicherheitstechnische Anforderungen an Vertraulichkeit, Unveränderbarkeit, Sicherstellung des richtigen Absenders und richtigen Empfängers sowie Nichtabstreitbarkeit dessen, dass Daten verschickt bzw. empfangen wurden. OSCI-Transport trennt die für die Weiterleitung benötig­ten Informationen wie Absender und Empfänger strikt von den Inhaltsdaten. Seit Juni 2002 ist es in der Version 1.2 in vielen E-Government-Projekten auf Kommunal-, Landes- und Bundesebene im Einsatz. OSCI-Transport wird insbe­sondere dann verwendet, wenn Daten über eigene Organisations- oder Länder­grenzen hinweg verschickt werden. Es spielt beispielsweise bei der Vernetzung der bundesweit über 5.400 Meldebehörden, die seit 2007 ihre Daten untereinander ausschließlich elektronisch austauschen müssen, eine tragende Rolle.

Viele der von OSCI-Transport erfüllten Sicherheitsanforderungen werden seit einigen Jahren international unter dem Stichwort „sichere WebServices“ umge­setzt. Dies führte dazu, dass der „Kooperationsausschuss Automatisierte Daten­verarbeitung“ (KoopA ADV), der von Bund, Ländern und kommunalen Spitzenverbänden getragen wird und gemeinsame Grundsätze des Einsatzes der Informations- und Kommunikationstechniken (IT) und wichtige IT-Vorhaben in der öffentlichen Verwaltung erarbeitet und abstimmt, die OSCI-Leitstelle zur Entwicklung von OSCI-Transport Version 2.0 beauftragt hat. Ziel ist es, WebService-Mechanismen entsprechend den deutschen Rechtsgrundlagen zu gestalten und gegebenenfalls mit Eigenentwicklungen zu ergänzen. Der Abschluss der Spezifikation von OSCI 2.0 war für Juli 2008 zugesagt, ist aber bislang nicht erfolgt (Stand: Ende Oktober 2008). Ein Grund für die Verspätung sind zusätzliche Anforderungen an eine sichere Infrastruktur im Rahmen der Umsetzung der EU‑Dienstleistungsrichtlinie (Tz. 6.3) und der Bürgerportale.

Aus Datenschutzsicht sind zwei Eigenschaften von OSCI-Transport 2.0 heraus­zuheben: Die Nutzung dieser WebServices setzt keinen zentralen Intermediär­server wie noch OSCI 1.2 voraus, auf dem zentrale Sicherheitsfeatures abgebildet werden müssen. Sicherheitsrelevante Dienste, z. B. Signatur- und Authentisie­rungsprüfungen sowie Protokollierung, können von unterschiedlichen Komponen­ten eines Informationsverbunds erbracht werden. OSCI 2.0 erlaubt in diesem Sinne eine dezentrale Datenverarbeitung bei gleichzeitig effizienter Abrufmöglichkeit auf Basis einer nach dem Stand der Technik sicher betreibbaren Infrastruktur.

In WebServices wird die Datenverarbeitung über sogenannte Policies gesteuert. Hierfür müssen rechtliche Anforderungen zunächst in technische Maßnahmen überführt werden, die dann in das maschinenlesbare Format der WebService Policies übertragen werden. Über Policies lässt sich regeln, welche Sicherheits­standards für eine Datenverarbeitung gefordert sind, also z. B. ob die Datenüber­mittlung verschlüsselt erfolgen muss, ob Nachrichtenbestandteile zu signieren sind, in welcher Qualität dies zu geschehen hat und wie das Protokoll darüber zu führen ist. Diese technische Umsetzung rechtlicher Anforderungen steigert die Trans­parenz der Datenverarbeitung und macht für die Betreiber die Einhaltung der Sicherheitsregeln für Geschäftsvorfälle im E-Government leichter. Sie erlaubt außerdem den von der Datenverarbeitung Betroffenen, den Auftraggebern und den internen und externen Kontrolleuren, die Art der Datenverarbeitung zu kontrollie­ren. Die Beachtung von Zweckbindung, Datenvalidität und Erforderlichkeit wird erleichtert.

Durch Herausnahme der Datenverarbeitung aus einem eigenen Rechenzentrum und das Verteilen auf viele Betreiber mit unterschiedlichen Sicherheitsniveaus steigt zugleich das Risiko, dass gegen Regeln verstoßen wird, dass unberechtigt auf Daten zugegriffen wird und die Daten verfälscht oder zweckentfremdet verarbeitet werden. Um diese Risiken zu begrenzen, muss mit der Einführung dieser Tech­niken die Kontrollierbarkeit der Systeme, der Policies und der Prozesse bewahrt werden. Techniken müssen entwickelt werden, die die Überwachung und Steu­erung der Systeme ermöglichen.

Diese Anforderungen und Eigenschaften gelten sowohl für OSCI 2.0 als auch für SAFE (Secure Access to Federated E-Justice/E-Government). SAFE definiert im Kontext von WebServices und unter Berücksichtigung von OSCI 2.0 ein technisches Rahmenwerk für die sichere Nutzung digitaler Identitäten über admi­nistrative Domänengrenzen (Trust-Domains) hinweg. Mit SAFE kann sich ein Notar über das Internet sicher an einer Stelle als ein solcher authentisieren, um dann im gesamten (unter Umständen europaweiten) Verbund entsprechend seiner zugebilligten oder entzogenen Zugriffsrechte zu agieren.

Die WebService Policies der Sicherheitskonfigurationen von OSCI 2.0 und SAFE bilden nur einen standardisierten Rahmen. Dieser Rahmen muss mit konkret operativ umsetzbaren Anweisungen ausgefüllt werden. Hieran mangelt es in den ambitionierten Projekten. Bisher wurden datenschutzspezifische Aspekte nicht ausreichend betrachtet. Es gibt konkrete Zusagen der Projektgruppen, dass in Nachfolgeprojekten diese Lücke geschlossen wird. Zusammen mit den Daten­schutzkollegen der anderen Länder versuchen wir, bereits in der Standardisie­rungsphase die für einen funktionierenden Datenschutz wichtigen Aspekte zu verankern.

 

6.5         Kontodatenskandal – Datenverarbeitung im ULD

Als das ULD im Sommer mehrere Datenträger mit insgesamt fast acht Millionen Kundendatensätzen erhielt, musste intern eine Vorgehensweise mit diesen hochsensiblen Daten festgelegt werden. Das ULD ist eine Daten verarbeitende Stelle mit einer hohen Verantwortung für die Daten der vom Skandal Betroffenen.

Die Daten auf den CDs lagen vollkommen ungeordnet, aufgeteilt in unzählige Teildateien in unterschiedlichen Formaten vor. Damit Anfragen von Bürgern und Ermittlungsbehörden beantwortet werden konnten, mussten die Daten in einer geeigneten Form aufgearbeitet werden. In welcher Form das geschehen sollte, wurde gemeinsam von der Dienststellenleitung, der behördlichen Datenschutz­beauftragten sowie technischen und juristischen Mitarbeitern des ULD erarbeitet. Es musste geprüft und festgelegt werden,

• auf welcher rechtlichen Grundlage die Daten verarbeitet werden,
• wer Zugriff auf die Daten erhält,
• in welcher Form und wo die Verarbeitung erfolgt und
• in welchem Umfang die Daten protokolliert und in welchen Abständen die Protokolle überprüft werden.

Unter Berücksichtigung dieser Überlegungen konnten folgende Entscheidungen umgesetzt werden:

• Für diese Daten wurde exklusiv ein Server bereitgestellt, auf dem das Daten­banksystem und die Abfrageschnittstelle, mit der auf die Kontodaten zugegriffen werden kann, laufen.
• Die Daten sind auf dem Server durch eine vollständige Festplattenverschlüs­selung gesichert; das entsprechende Passwort wird in einem Safe gelagert.
• Der Server wird in einem vom Dienststellennetz komplett getrennten Netz betrieben ohne Schnittstellen zu externen Netzen.
• Um zu vermeiden, dass ein unbefugter Zugriff auf Datensicherungsmedien (z. B. Back-up-Sicherungsbänder) eintritt, wird der Server nicht gesichert. Bei einem Ausfall wird der Server neu installiert. Sämtliche Schritte, die aus den verteilten und uneinheitlich vorliegenden Datenbeständen einen zentralen Datenbestand erschließen, sind in maschinell durchführbaren Anweisungen festgehalten und können bei Bedarf auf Basis der Ausgangsdaten wiederholt werden.
• Die Anzahl der Beschäftigten mit lesendem Zugriff ist streng begrenzt. Jede Abfrage erfolgt mit einer persönlichen Kennung. Sämtliche administrativen Kennworte sind in einem Safe hinterlegt und werden in regelmäßigen Abständen geändert.
• Sowohl Änderungen an den Datenbeständen und der Konfiguration des Servers als auch alle An- und Abmeldevorgänge und Datenabrufe werden automatisiert protokolliert. Die Protokolle werden durch die Datenschutzbeauftragte regel­mäßig kontrolliert und ausgewertet.
• Die Datenträger mit den originalen Datensätzen werden in einem Safe aufbe­wahrt.

Alle festgelegten Prozesse, die Konfiguration des Servers und der Anwendungs­software, die Berechtigungskonzeption sowie die Protokollierungsmaßnahmen und die Datenschutzkontrollen werden in der Verfahrensakte schriftlich dokumentiert. Nach Abschluss des Ermittlungsverfahrens werden die elektronischen Kontendaten gelöscht, die Datenträger mit den originalen Datensätzen zerstört und die Akte für fünf Jahre gespeichert.

 

6.6         Einsatz privater Geräte

In Behörden besteht zunehmend der Wunsch, personenbezogene Daten auf privat genutzten Geräten zu bearbeiten. Die Daten verarbeitende Stelle hat die technischen und organisatorischen Maßnahmen zur sicheren Verarbei­tung zu ergreifen. Geht das überhaupt beim Einsatz von privaten Geräten?

Die Ausgestaltung der PC-Arbeitsplätze, mit denen auf Daten innerhalb einer Behörde zugegriffen wird, wird in Bezug auf die Hard- und Software, die Konfigu­ration und Nutzung verbindlich in den IT- und Sicherheitsfestlegungen der Daten verarbeitenden Stelle geregelt. Diese Konzeption setzt im Grunde voraus, dass die IT-Ausstattung vom Arbeitgeber zur Verfügung gestellt wird. Datenschutz- und Sicherheitskontrollen nach der organisatorischen Vorgabe der Daten verarbeiten­den Stelle können innerhalb der Diensträume jederzeit gewährleistet werden. Der Einsatz privater Computer zur Verarbeitung dienstlicher Daten ist im LDSG und der DSVO nicht vorgesehen. Eine ordnungsgemäße Ausgestaltung der Hardware, Art und Umfang der zulässigen Nutzung und eine effektive Kontrolle der tech­nischen und organisatorischen Sicherheitsmaßnahmen gemäß der IT- und Sicher­heitskonzeption der Daten verarbeitenden Stelle können nicht wirkungsvoll gewährleistet werden. Im Einzelnen:

• Auf einem privaten Computer kann technisch nicht verhindert werden, dass sich nur befugte Personen am System anmelden können. Eine private Nutzung z. B. von Familienmitgliedern kann nicht ausgeschlossen werden. Es lässt sich auch nicht verhindern, dass unbefugte Personen die Benutzerkennung des Mitarbei­ters verwenden. Daher können die Daten verarbeitende Person, der Zeitpunkt und der Umfang der Verarbeitung nicht eindeutig protokolliert und kontrolliert werden. Es lassen sich hauptsächlich organisatorische Regelungen treffen, was in puncto Sicherheit als schwach zu bewerten ist.
• Auf einem privaten Computer werden in der Regel andere Sicherheits­maßnahmen getroffen als innerhalb der Daten verarbeitenden Stelle. Es lässt sich technisch nicht sicherstellen, dass regelmäßig Service Packs, Sicherheits­patches und Antivirussoftware auf den privaten Computern eingespielt werden. Wieder sind nur – als schwach zu bewertende – organisatorische Regelungen möglich. Die Daten verarbeitende Stelle muss sich bewusst sein, dass bei dem privaten Computer meistens ein deutlich schwächeres Sicherheitsniveau besteht als innerhalb des Behördennetzes.
• Auch bei der Nutzung privater Computer muss sichergestellt werden, dass Administratoren der Daten verarbeitenden Stelle die notwendigen Sicherheits­maßnahmen für das automatisierte Verfahren installieren, konfigurieren und warten können. Das gilt besonders für eine Verschlüsselung, wie sie bei der Verarbeitung außerhalb der Daten verarbeitenden Stelle gesetzlich gefordert ist. Daher müssen die Administratoren einen administrativen Fernzugang und unter Umständen einen physikalischen Zugang zum Gerät haben. Die Änderungen, die die Administratoren auf dem System durchführen, sowie die ordnungs­gemäße Anwendung der automatisierten Verfahren müssen protokolliert und durch eine Kontrollinstanz (z. B. behördlicher Datenschutzbeauftragter oder Prüfungsamt) kontrolliert werden. Das ist bei privaten Geräten in privaten Umgebungen, wenn überhaupt, nur sehr schwer machbar.

Eine Ausnahme beim Einsatz privater Geräte für die Verarbeitung personenbezo­gener dienstlicher Daten ist mit Terminalserverdiensten möglich. Dabei wird zusätzlich zur Authentifizierung am privaten Computer eine weitere Authentifi­zierungs- und Autorisierungsebene zum separaten Aufbau einer Terminalserver­sitzung eingefügt. Hierbei werden nur Bildschirminhalte übertragen, und die Dateien bleiben auf dem Server der Daten verarbeitenden Stelle. Mit einer sorgfältigen Planung und mit detailliert dokumentierten organisatorischen Maß­nahmen können Risiken, die aufgrund mangelnder Kontroll- und Eingriffsmög­lichkeit beim Einsatz privater Geräte entstehen, mit technischen Maßnahmen so verringert werden, dass kein Widerspruch zu einer ordnungsgemäßen Datenverar­beitung besteht. Bei allen Begehrlichkeiten: Aufwand und Schutzbedarf müssen in einem angemessenen Verhältnis bleiben.

Insbesondere bei der Nutzung der Terminalserverdienste sind gewisse Sicherheits­maßnahmen einzuhalten. So muss

• die Nutzung der Terminalserverdienste an eine Zwei-Faktor-Authentifizie­rung gebunden sein, z. B. durch Eingabe einer PIN und die Nutzung eines Tokens,
• eine Dateiübertragung sowohl auf Ebene der Terminaldienste, über die Netz­ebene als auch über die Konfiguration der verwendeten Software ausgeschlos­sen sein,
• jeder privat genutzte Computer mit den in der IT- und Sicherheitskonzeption beschriebenen Sicherheitsmaßnahmen der Daten verarbeitenden Stelle ausgerüstet sein (z. B. Virenschutz, Patches, Updates); die Ausstattung der Computer mit diesen Sicherheitsmaßnahmen muss vor der Nutzung durch einen Automatismus sichergestellt werden,
• durch regelmäßige Prüfungen der verwendeten Computer durch eine Kon­trollinstanz gewährleistet werden, dass die technischen Sicherheitsmaßnahmen eingehalten werden.

Werden alle erforderlichen technischen und organisatorischen Sicherheitsmaß­nahmen umgesetzt und so dokumentiert, dass die Anforderungen der DSVO erfüllt sind, so ist der Einsatz privater Geräte zur Verarbeitung personenbezogener dienstlicher Daten ausnahmsweise möglich, da die eigentliche Datenverarbeitung auf Geräten der Behörde stattfindet und durch angemessene Sicherheitsmaßnah­men das Risiko der Einsichtnahme und Veränderungen von personenbezogenen Daten auf den privaten Geräten ausreichend verringert wurde. Die Verarbeitung von Daten, die einem Berufs- oder Amtsgeheimnis unterliegen, darf aber auch unter diesen Voraussetzungen nicht mit privaten Geräten stattfinden.

 

6.7         IP-Adressen 1: Grundsätzliches

Eigentlich überall, wo zwei oder mehr Rechner miteinander vernetzt sind, werden Protokolldateien erstellt. Das gilt vom kleinen Heimnetz bis hin zum World Wide Web. Diese Protokolldateien erfüllen durchaus ihren Sinn zum Zweck der Sicherheitsanalyse, Revision oder statistischen Auswertung. Aller­dings wird hierbei gern vergessen, dass die zu den genannten Zwecken erhobene IP-Adresse ein personenbezogenes Datum sein kann.

Für Protokolldateien, in denen IP-Adressen oder andere möglicherweise personen­bezogene Daten gespeichert sind, gelten die Anforderungen der Datenschutz­gesetze, insbesondere das Gebot der Datensparsamkeit und die Zweckbindung von den erhobenen Daten. Oftmals lässt sich nach klarer Anforderungsanalyse das Erheben der IP-Adresse umgehen oder ein frühzeitiges Löschen bzw. Anonymi­sieren der Protokolldaten realisieren.

Zumeist ist die Erfassung der IP-Adressen in der Standardkonfiguration des protokollierenden Dienstes verankert, um eine möglichst breit gefächerte Weiter­verarbeitung (z. B. für Zwecke der Forensik oder der Statistik) zu gewährleisten. Die Erzeugung von standardisierten Protokolldateien erleichtert es den Analyse­tools, auf diese Dateien zuzugreifen und sie für eine bessere Lesbarkeit aufzu­bereiten. Häufig übernimmt die IP-Adresse die Funktion eines eindeutigen Identi­fikators, um einen bereits bekannten Computer wiederzuerkennen. Diese Zuord­nungsmöglichkeit kann für einige Anwendungen erforderlich sein, z. B. zum Erkennen eines wiederholten Angriffsversuchs von einem bestimmten Rechner aus.

Häufig wird allerdings zu viel und zu lange protokolliert, frei nach dem Motto „Man kann ja nie wissen!“ Jeder IT-Verantwortliche ist jedoch verpflichtet, sich über einige Grundsätze der datenschutzgerechten Datenerhebung Klarheit zu verschaffen: Welche Daten werden wirklich für meine gestellten Anforderungen benötigt? Wie lange müssen die erhobenen Daten vorgehalten werden? Werden die erhobenen Daten für andere Zwecke weitergegeben oder -verarbeitet? Nach vollständiger Klärung dieser Fragen werden sich einige Datenbestände stark reduzieren lassen. Die Gesetze stellen klar, dass IP-Adressen nur für die Erbrin­gung des Dienstes und für Abrechnungszwecke kurzfristig gespeichert werden dürfen.

Besteht das Erfordernis, die IP-Adresse zu erheben, um eine bestimmte Funktio­nalität der Anwendung gewährleisten zu können, sind die Methoden der Anony­misierung, der Pseudonymisierung und des frühzeitigen Löschens in Betracht zu ziehen. Dient die IP-Adresse als eindeutiger Identifikator, kann diese auch gekürzt oder ersetzt werden. Das Streichen des letzten Oktetts einer IP-Adresse wird bei Protokolldateien mit überschaubarer Anzahl von Einträgen kaum Qualitätseinbußen der anschließenden Anwendung zur Folge haben. Bei sehr großen Protokolldateien kann diese Streichung bewirken, dass unterschiedliche IP‑Adressen anschließend nicht mehr zu differenzieren sind. Hier bietet sich eine Substitution der IP-Adressen an, d. h., die IP-Adressen werden automatisch durch andere Zeichenfolgen ersetzt, wodurch weiterhin die statistische Auswertung von sogenannten Klickstreams ermöglicht wird. Dabei muss sichergestellt sein, dass die neue Zeichenfolge keine Rückschlüsse auf die ursprüngliche IP‑Adresse erlaubt.

In jedem Fall sollten Protokolldateien so früh wie möglich gelöscht oder anony­misiert werden. Müssen z. B. die IP-Adressen zum Zweck von Sicherheitsanalysen kurzzeitig vorgehalten werden, ist ein Löschen oder Anonymisieren der Daten innerhalb von 24 Stunden anzuraten. Spätestens nach fünf Tagen dürfte eine Speicherung für diesen Zweck nicht mehr erforderlich sein. Werden die IP-Adres­sen für statistische Zwecke benötigt, so sollten gleich Tools eingesetzt werden, die diese entsprechend anonymisieren bzw. pseudonymisieren. Meist werden Anwen­dungen für Protokolldateien täglich ausgeführt, sodass ein längeres Vorhalten der Originaldateien nicht erforderlich ist. Sind hingegen die personenbezogenen Daten vollständig anonymisiert, also ist keine Reidentifikation mehr möglich, sollte die Löschung auch dieser Protokolldateien aus Gründen der Übersichtlichkeit regel­mäßig stattfinden.

 

6.8         IP-Adressen 2: Umsetzung in Schleswig-Holstein

Das Internetportal des Landes Schleswig-Holstein stellt dem Nutzer eine Vielzahl an Informationen sämtlicher Ministerien, Kreise, Gemeinden und Städte des Landes sowie eine kleine Anzahl von Services zur Verfügung. Das Speichern der IP-Adressen der Nutzer ist dabei auf ein den Anforderungen entsprechendes Minimum reduziert worden.

Der Internetauftritt der Landesregierung wurde mit einem überarbeiteten Layout versehen und die redaktionelle Bearbeitung der Inhalte auf die Basis eines neuen Content-Management-Systems gestellt. Im Zuge dieses Relaunches ist von der Staatskanzlei der Wunsch geäußert worden, das Webangebot datenschutz­konform aufzuarbeiten und das ULD hierbei einzubeziehen. Zwei Schwerpunkte waren ein korrektes Impressum und eine verständliche und richtige Datenschutz­erklärung. Zwangsläufig stellten sich zudem Fragen zur Rechtmäßigkeit der Verarbeitung, zu den Verantwortlichkeiten sowie zur Sicherung der Zweckbin­dung. Für eine bestmögliche Vermittlung der Inhalte möchte die Regierung ihren Internetauftritt stetig optimieren. Daher werden die Seitenaufrufe der Nutzer protokolliert, um sie mithilfe eines Auswertungstools statistisch aufzubereiten. Damit dies datenschutzgerecht geschieht, ist das ULD um Unterstützung gebeten worden.

Bei der Erstellung der Datenschutzerklärung eines Internetangebotes muss der Betreiber sämtliche Prozesse der Erhebung, Verarbeitung und Löschung von personenbezogenen Daten exakt definieren und einer datenschutzrechtlichen Prüfung unterziehen. Welche Daten werden wann, wo und zu welchem Zweck erhoben? Wo und wie lange werden diese gespeichert? Wer hat Zugriff auf diese Daten? Wann und wie werden diese gelöscht? Sind sämtliche Prozesse daten­schutzkonform? Das Hauptaugenmerk wird im Folgenden auf die protokollierten IP-Adressen gelegt, die häufig zur statistischen Auswertung des Nutzerverhaltens notwendig sind.

Die Staatskanzlei hat bei der Einführung des neuen Content-Management-Systems eine Dokumentation mit sämtlichen Verträgen, Beschreibungen und Konzepten nach Vorgabe der DSVO angelegt. Ein Dokument beschreibt die Anforderungen an die statistische Auswertung der Protokolldateien. Danach ist das Verhalten eines einzelnen Nutzers – über welche Pfade er an bestimmte Informationen gelangt – nicht von Interesse. Die protokollierte IP-Adresse wird somit nur als eindeutiger Identifikator genutzt, um verlässliche Aussagen über die Besucherzahl des Landesportals treffen zu können. Die IP-Adressen dürfen nicht länger als nötig gespeichert werden. Die Staatskanzlei verständigte sich mit dem ULD, die Proto­kolldateien mit den IP-Adressen zu Sicherheitszwecken für maximal vier Tage zu speichern. Danach wurden die IP-Adressen aber nicht vollständig aus dem System eliminiert. Diese fanden sich an anderen Orten im System wieder.

In jeder gut administrierten IT-Umgebung werden in regelmäßigen Abständen Datensicherungen durchgeführt. Das Landesportal einschließlich seiner System­komponenten wird täglich gesichert, was zur Folge hat, dass auch die Protokoll­dateien mit den IP-Adressen gesichert werden. Eine Reproduktion sämtlicher IP‑Adressen der letzten Wochen oder sogar Monate wäre dann mithilfe der Daten­sicherungen möglich gewesen. Eine regelmäßige Löschung der gesicherten Originalprotokolldaten war somit unumgänglich.

Die zweite Falle lauerte im Auswertungstool. Dieses erstellt nach jedem Durchlauf eine aktualisierte History-Datei, die die IP-Adressen der ausgewerteten Proto­kolldateien beinhaltet, um Auskunft erteilen zu können, wann ein Nutzer erneut das Angebot in Anspruch nimmt. Diese Funktion war nicht in der Anforderungsanalyse der Staatskanzlei enthalten, also nur ein „nice to have“. Ein eigens geschriebenes Skript, das nach jeder erfolgten Auswertung gestartet wird, löscht nun die IP‑Adressen aus dieser Datei. Die IP-Adressen zum Zweck der statistischen Auswertung haben somit eine maximale Speicherfrist von 24 Stunden.

 

6.9         Modularisierung der Dokumentation  – sinnvoll nicht nur beim Geoserver

Geodaten sind Basis- und Referenzinformationen für viele Verfahren. Diese sollen über einen Geoserver zentral bereitgestellt werden. IT-Konzept und Sicherheitskonzept zum Geoserver sind stilbildend für die kommenden E‑Government-Verfahren des Landes.

Das federführende Innenministerium hat sich aus dem „Baukasten E-Government-Infrastruktur“ die für den Geoserver benötigten Bausteine herausgenommen und zusammen mit dem Fachverfahren eines Drittanbieters zu einem neuen Paket geschnürt. Das ULD hat beim Erstellen des IT-Konzepts und des Sicherheits­konzepts beraten. Die Herausforderung bestand vor allem darin, die bestehende Dokumentation der einzelnen Bestandteile in einem „Dachdokument“ zusammen­zuführen. Hierbei ergab sich eine modulare Vorgehensweise, die das ULD auch anderen Verfahren der E-Government-Infrastruktur empfiehlt.

Ein IT-Konzept enthält die wesentlichen Ziele und Entscheidungen zur einzuset­zenden Technik. Daraus ergeben sich die nötigen Sicherheitsmaßnahmen, die entsprechend LDSG und DSVO zu dokumentieren sind. Der Geoserver soll auf der vom Finanzministerium zu verantwortenden E-Government-Infrastruktur auf­setzen und mit den IT-Gerätschaften Dataports betrieben werden. Soll für eine solche Informationstechnik über Organisationsgrenzen hinweg eine Doku­mentation erstellt werden, so ist besonders schwierig zu entscheiden, welche Themenbereiche in welchem Abschnitt in welcher Auflösung darzustellen sind.
Ein Vorgehen in drei Schichten bietet sich an:

• Schicht 1 erfasst ausschließlich technische und organisatorische Maßnahmen, die direkt den Fachverfahren zuzuordnen sind.
• In Schicht 2 werden die Infrastrukturbausteine der E-Government-Infrastruktur betrachtet.
• Schicht 3 kümmert sich schließlich um konkrete Maßnahmen auf Ebene der Geräte, wie z. B. Serversysteme oder Netzkomponenten.

Ordnet man die Sachverhalte schichtbezogen den jeweiligen Zuständigkeiten zu, so kommt man zu einem modularen Aufbau der Dokumentation mit speziellen Anforderungen an Datenschutz und Datensicherheit sowie eigenen Kontrollanfor­derungen für jeden Bereich.

Die IT-Dokumentation im Bereich des Fachverfahrens muss zunächst den Zweck des Verfahrens und die zu erfüllenden Rechtsgrundlagen ausweisen. Im entsprechenden Pendant der Sicherheitsdokumentation ist darzulegen, wie dieser Zweck datensparsam umgesetzt und wie die Einhaltung der Anforderungen durch technisch-organisatorische Vorkehrungen durchgesetzt und durch Regula­rien wie Dienstvereinbarungen auf der Fachverfahrensebene kontrolliert wird. Auf dieser Ebene muss die Spezifikation der Nutzerrollen erfolgen. Hier ist auch der Nachweis des rechtskonformen Verwaltungshandelns zu führen. Es ist festzulegen, wie die Kontrolle bezüglich der Einhaltung der Regularien geschieht und welche Prozesse eingerichtet sind, wenn gegen Regeln verstoßen wurde. Aus daten­schutzrechtlicher Sicht muss gezeigt werden, welche Mitarbeiteraktivitäten wie protokolliert werden – unter Vermeidung einer Leistungs- und Verhaltenskon­trolle.

Ein Fachverfahren setzt entweder auf einer übergreifenden IT-Infrastruktur des Landes sowie den konkreten Gerätschaften eines IT-Dienstleisters auf oder wird lokal in Eigenregie betrieben. Wenn ein Fachverfahren an technischen Dienst­leistungen anderer Organisationen anknüpft, muss dies entweder durch eine gesetz­liche Grundlage, etwa eine Verordnung, oder einen Vertrag geregelt sein. In dem Vertrag sind Anforderungen seitens des Auftraggebers und Zusicherungen seitens des dienstleistenden Auftragnehmers bezüglich Funktionalität, Sicherheit und Datenschutz enthalten. Solche Verträge gehören zur Sicherheitsdokumen­tation, damit klargestellt ist, auf welche Aspekte die Kontrollfunktionen zur Überwachung des Auftragnehmers abzielen. Anforderungen und Zusagen müssen gegeneinander abgeglichen werden. Es dürfen keine Lücken entstehen, bei denen für eine Anforderung keine entsprechenden Zusagen vorhanden sind.

Im Bereich der Infrastruktur müssen im IT-Konzept und im Sicherheitskonzept solche Aspekte angeführt werden, die das Anforderungsmanagement (Anforderun­gen/Zusicherungen) und deren Controlling betreffen. Hier wird auch festgelegt und gerechtfertigt, was als Stand der Technik bezüglich der Applikation für das Fachverfahren, der Infrastruktur und der eingesetzten Hardware gilt und welche Schutzziele bezüglich dieser drei Aspekte zu verfolgen sind. Hier müssen die Verfahren beschrieben werden, mit denen die Zugriffe auf Daten geschehen dürfen. Auch ist darzulegen, welche Instanz auf welche Art und Weise welche Personen autorisiert. Zudem werden bestimmte Fachverfahren und deren Anforderungen in die der vorhandenen Infrastruktur eingepasst. Unter Kontrollaspekten muss hier dokumentiert sein, welchem Paradigma das Controlling aller beteiligten Seiten folgt und welche organisatorischen Prozesse im Rahmen des Sicherheits- und Datenschutzmanagements, insbesondere bei Regelverstößen, zu durchlaufen sind.

Im Bereich des IT-Dienstleisters müssen im IT-Konzept die für das Fachverfahren eingesetzten Gerätschaften und deren Konfigurationen entlang dem physikali­schen Netzplan dokumentiert werden. Neben den Anforderungen der DSVO ist eine Orientierung an den BSI-Grundschutzkatalogen und -Maßnahmen empfeh­lenswert. Besonderes Augenmerk ist dabei auf die Dokumentation der Zugriffs­möglichkeiten der Systemadministration und deren Protokollierung zu legen.

Führt man diese Art der modularen Dokumentation ein, so kümmert sich jede beteiligte Organisation nur um ihre originäre Zuständigkeit. Jede Organisa­tion muss lediglich die Schnittstellen festlegen. Dies geschieht über den Mecha­nismus der Anforderungen und Zusagen. Werden diese genau und verständlich formuliert, so kann eine schlanke Dokumentation entstehen, die allen Beteiligten nützt und gleichzeitig die Anforderungen des LDSG und der DSVO erfüllt.

Beim Geoserver wurden all diese Punkte berücksichtigt. Von dieser Verfahrens­weise zur Erstellung der Dokumentation können nun andere E-Government-Pro­jekte profitieren.

 

6.10       ISMS  Dataport

Das im vergangenen Jahr bei Dataport eingerichtete Informationssicherheits­managementsystem (ISMS) konnte erfolgreich fortentwickelt und auf weitere Kundenverfahren und Infrastrukturen angewandt werden.

Schon im vorangegangenen Jahr hatte Dataport begonnen, ein Management­system für Informationssicherheit (ISMS) aufzubauen und auf erste Verfahren (ZIAF) und Infrastrukturen (Landesnetz, KITS.system) anzuwenden. Eine schritt­weise erfolgende Implementierung des ISMS bei Dataport war vorgesehen (30. TB, Tz. 9.1.3). Diese Planungen wurden konkretisiert und umgesetzt, vor allem in der Fortentwicklung der Aufbauorganisation des ISMS und in der Weiter­entwicklung zahlreicher Dokumente wie Leit- und Richtlinien. Diese Aktivitäten haben auch im erheblichen Maße zur erfolgreichen Zertifizierung bei ZIAF (Tz. 9.2.2) beigetragen.

Nach und nach wird das ISMS auf weitere Verfahren und Infrastrukturen bei Dataport ausgerollt. In diesem Umfeld sind die folgenden Audits bei Dataport und im Zuge von Fachverfahren von Kunden geplant:

• der Verfahrensbetrieb über Terminaldienste (ABS) – in dieser Infrastruktur werden auch die MLUR-Verfahren K3 und BalVI betrieben,
• das Druck- und Kuvertierzentrum (DuK),
• das ebenfalls von der Finanzverwaltung des Landes Schleswig-Holstein genutzte Data Center Steuern (DCS) mit seinen Standorten Rostock und Schwerin.

Für das DCS und das DuK hat die Auditierung schon begonnen – die Phase der Erhebung wurde bereits erfolgreich abgeschlossen. Auch für K3, BalVI und das DCS ist ein Abschluss der Auditierung im Jahr 2009 geplant.

 

6.11       Zielarchitektur Basis-Infrastruktur bei Dataport

Dataport erfindet sich neu: Eine neue Zielarchitektur soll einen wirtschaft­lichen, sicheren und datenschutzfreundlichen Betrieb von Fachverfahren ermöglichen. Die neue Zielarchitektur existiert jedoch bisher größtenteils nur in den Köpfen der Planer.

Die vier strategischen Partner von Dataport, die Firmen Cisco, EMC, Fujitsu Siemens Computers und Microsoft, haben für Dataport ein Konzept für die Neuausrichtung der technischen Basisinfrastruktur entwickelt. Die Arbeitsergeb­nisse des Projekts mit dem Namen Zielarchitektur Basis-Infrastruktur (ZaBI) sollen es Dataport ermöglichen, eine transparente, einheitliche und skalierbare Architek­tur für die im Kundenauftrag betriebenen Komponenten zum Transportieren, Verarbeiten und Speichern von Daten aufzubauen. Das ULD berät Dataport mit dem Ziel einer datenschutzfreundlich gestalteten Infrastruktur. Dies bedeutet insbe­sondere, dass

• eine lückenlose Protokollierung administrativer Tätigkeiten erfolgt,
• die Konfiguration aller an einem Fachverfahren beteiligten Systeme und Kom­ponenten nachvollziehbar ist,
• die betrieblichen Prozesse vorab festgelegt, bei der Ausführung dokumentiert und regelmäßig überprüft werden,
• die in den jeweiligen Modulen von ZaBI geplanten Sicherheitsmaßnahmen angemessen und wirksam sind und
• das Datenschutz- und Sicherheitsmanagement sowohl bei Dataport, aber vor allem bei den Kunden unterstützt wird.

Die bisherigen Arbeitsergebnisse des Projekts ZaBI sind vielversprechend und stellen einen Qualitätsgewinn durch Vereinheitlichung der Technikplanung im Vergleich zur bisherigen Architektur in Aussicht. Dataport hat es bisher jedoch nicht geschafft, die neue Architektur umzusetzen. In vielen Bereichen fehlen noch Detailkonzepte, die auch den Kunden als Grundlage für eigene Sicherheitskon­zepte dienen können.

http://www.rechenzentrum2010.de/

 

6.12       Internetnutzung: Privat oder rein dienstlich?

E-Mail-Kommunikation und Internetnutzung sind ein fester Bestandteil des modernen Behördenalltags. Doch der gesetzliche Rahmen zur Nutzung dieser Dienste verursacht in vielen Behörden Unsicherheit. Darf eine Behörde die private Internet- und E-Mail-Nutzung erlauben? Und wenn ja, unter welchen Bedingungen?

Der Einsatz von E-Mail-Kommunikation und Web­nutzung in öffentlichen Stellen setzt eine funk­tionierende IT- und Sicherheitsdokumentation nach LDSG und DSVO voraus mit der Beschreibung der nötigen IT-Komponenten, deren Konfiguration, Datensicherheitsmaßnahmen und Kontrollflüssen. Auch bei Internetdiensten muss die Entscheidung über den Umfang der Nutzung durch Mitarbeiter von der Dienststellenleitung getroffen und dokumen­tiert werden. Das Fehlen einer geeigneten Regelung kann rechtliche Konsequenzen nach sich ziehen. Wird z. B. eine private Nutzung der Internetdienste fortwährend stillschweigend geduldet, so ist dieser Zustand als Erlaubnis durch „betriebliche Übung“ anzusehen.

Das Maß der erlaubten Nutzung von Internetdiensten hat Auswirkungen auf die Verpflichtungen der Daten verarbeitenden Stelle nach dem Telemediengesetz (TMG) und dem Telekommunikationsgesetz (TKG). Die nachfolgende Grafik stellt die beiden Gesetze in Auszügen grob gegenüber:

Die Nutzung der Internetdienste in einer Daten verarbeitenden Stelle kann in drei Szenarien unterteilt werden:

• geregelte rein dienstliche Nutzung,
• ungeregelte private und dienstliche Nutzung,
• geregelte private und dienstliche Nutzung.

Die folgenden Übersichten zeigen für jedes Szenario den rechtlichen Status der Daten verarbeitenden Stelle und die geltenden datenschutzrechtlichen Normen.

Wird die E-Mail-Kommunikation und Internetnutzung nur zu rein dienstlichen Zwecken erlaubt, nimmt die Daten verarbeitende Stelle den Status eines Dienste­anbieters nach dem TMG ein. Die datenschutzrechtlichen Sondervorschriften zum Schutz der Nutzer finden aber keine Anwendung. Die Stelle darf daher die Benutzeraktivitäten im Rahmen von technisch-organisatorischen Datenschutzkon­trollen prüfen.

Ist bei Internetdiensten die Nutzung ungeregelt und die Mitarbeiter nutzen diese zu privaten und dienstlichen Zwecken, so bekommt die Stelle den Status eines Diensteanbieters nach dem TMG und nach dem TKG. Das bedeutet, dass die Daten verarbeitende Stelle an das Fernmeldegeheimnis gebunden ist; eine Auswertung von Protokolldaten ist unzulässig.

Wird die private Nutzung der Internetdienste eingeschränkt erlaubt, so hat die Daten verarbeitende Stelle – ebenfalls – den Status eines Diensteanbieters nach dem TMG und nach dem TKG, und die Daten verarbeitende Stelle ist an das Fernmeldegeheimnis gebunden. Durch Einwilligung des betroffenen Beschäftigten sowie durch Betriebsvereinbarung im nicht öffentlichen Bereich bzw. Dienstver­einbarung im öffentlichen Bereich können aber Eingriffe in das Fernmeldegeheim­nis zulässig sein.

Bei der Erarbeitung einer Dienst- bzw. Betriebsanweisung ist Folgendes zu beachten:

• Erlaubt eine Daten verarbeitende Stelle die private Nutzung, wozu sie nicht verpflichtet ist, so kann sie die Erlaubnis an einschränkende Voraussetzungen knüpfen. Die Kontrollmechanismen müssen datenschutzkonform sein.
• Eine Internetnutzung, die den Interessen der Daten verarbeitenden Stelle entgegensteht oder gegen strafrechtliche bzw. urheberrechtliche Vorschriften verstößt, sollte untersagt werden.
• Eingehende private E-Mails sind wie private (Papier-)Post zu behandeln. Fälschlich als Dienstpost behandelte E-Mails sind den betroffenen Mitarbeitern unverzüglich zur alleinigen Kenntnis zu geben.
• Die Inanspruchnahme kostenpflichtiger Angebote sowie die Verfolgung kom­merzieller Zwecke im Rahmen der privaten Nutzung sollte untersagt werden.
• Für die private Nutzung des Internetzugangs kann ein separates Benutzerkonto zur Verfügung gestellt werden. Durch Protokollierung und Auswertung der Nutzungszeiträume des privaten Benutzerkontos kann festgestellt werden, ob zeitliche Vorgaben eingehalten werden.
• Die Protokollierung zu Zwecken der Datenschutzkontrolle, der Abrechnung, der Datensicherheit oder zur Vorbeugung strafrechtlich relevanten Verhaltens ist zulässig. Für darüber hinausgehende Kontrollen sind eine Betriebs- bzw. Dienstvereinbarung oder die Einwilligung des Betroffenen nötig.

Beispiel: Die Richtlinie zur Nutzung von Internet und E-Mail nach dem Mit­bestimmungsgesetz des Landes (MBG) regelt die dienstliche und private Nutzung der dienstlich zur Verfügung gestellten Services Internetzugang und E-Mail und gilt für die Beschäftigten der unmittelbaren Landesverwaltung, deren PCs an das Landesnetz angeschlossen sind (Amtsbl. Schl.-H. 2005, S. 27 ff.). Diese Richtlinie kann für den Bereich der Kommunalverwaltung als Vorbild dienen.

Um datenschutzkonforme Protokollierungs- und Kontrollmaßnahmen durchzu­führen, ist ein gestuftes Vorgehen zu empfehlen (Tz. 6.13).

 

6.13       Überwachung  der Internetnutzung von Mitarbeitern

Was ist zu tun, wenn die Überwachung von Mitarbeiterinnen und Mitarbei­tern notwendig wird? Grundsätzlich gilt, dass eine beabsichtigte Überwa­chung von Mitarbeitern zur Aufdeckung von Missbräuchen ausschließlich in einem für alle Mitarbeiter transparenten, geregelt-kontrollierten Verfahren geschehen darf. Erst auf einer rechtlich geregelten Grundlage stellt sich dann die Frage, wie das Zusammenspiel von Regelungen und Technik auszuge­stalten ist.

Heutige Firmen betreiben typischerweise an ihrer Schnittstelle zum Internet einen Proxy. Mit dessen Hilfe können die Inhalte des Datenverkehrs ins und aus dem Internet automatisiert geprüft werden, um beispielsweise

• die Filterungen von Inhalten mit Schadfunktion vorzunehmen,
• um eine Authentisierung und Autorisierung von Mitarbeitern durchzuführen,
• um die Internetnutzung zu protokollieren oder
• um an dieser zentralen Stelle bestimmte Regelungen, beispielsweise bezüglich der Anbindung mobiler Geräte, durchzusetzen.

Was an einem Proxy in welchem Ausmaß und welcher Form (z. B. als Rohdaten, pseudonymisiert, anonymisiert) zu welchem Zweck protokolliert und von welcher Abteilung dann kontrolliert wird, muss in einer Betriebsvereinbarung aufgeführt und festgelegt werden. Problematisch wird es insbesondere dann, wenn die private Nutzung des Internets erlaubt wird bzw. keine Dienstvereinbarung vorliegt, in der die private Nutzung der technischen Infrastruktur grundsätzlich ausgeschlossen ist. Dann liegt die Situation der „betrieblichen Übung“ vor, wonach die private Nutzung durch Mitarbeiter geduldet wird (Tz. 6.12). Im Falle der privaten Nutzung hat der Arbeitgeber das Telekommunikationsgeheimnis zu achten, darf insbesondere also nicht in den Mailverkehr der Mitarbeiter hineinsehen.
Wie kann ein transparentes und zielführendes Kontrollverfahren aussehen? Zunächst sind Zweck und die akzeptablen Anlässe einer Kontrolle als Bestandteile der Dokumentation schriftlich festzulegen, dann die Verfahrensabläufe, wie Kon­trollen durchzuführen sind, zu beschreiben sowie eine Betriebsvereinbarung zu schließen, die die Mitarbeiter darüber in Kenntnis setzt. Eine Betriebsvereinbarung muss zumindest die folgenden Aspekte ansprechen:

• Festlegen des Umfangs der erlaubten Nutzung,
• Festlegen des Zwecks und möglicher Anlässe sowie des Umfangs von Kontrol­len und Protokollierungen,
• Festlegung der Aufbewahrungsfristen von Protokolldaten,
• Festlegung der Ausgestaltung personenbezogener Auswertungen,
• Festlegung der Regelungen zu Sperrungen von Kommunikationspartnern oder Webseiten,
• Festlegung der Berechtigungen des Zugriffs auf Hard- und Software sowie
• Festlegen des Verfahrens, unter welchen Umständen Administratoren auf per­sonenbezogene Datenbestände zugreifen dürfen.

All dies sollte in eine generelle IT- und Sicherheitsdokumentation, die auch Konfigurations- und Berechtigungseinstellungen zu enthalten hat, eingepasst sein.
Ein Kontrollverfahren zur Aufdeckung von Missbräuchen oder Regelverstößen sollte zumindest über die folgenden vier Eskalationsstufen verfügen:

Stufe 1:    In der Firmenöffentlichkeit kommunizieren, dass Fälle von Miss­bräuchen oder Regelverstößen vorgekommen sind.
Weitergehende Sanktionen entsprechend den Ausführungen in der Betriebsverein­barung (dies entspricht den nachfolgenden Stufen) ankündigen, sofern weiterhin Missbräuche und Regelverstöße festgestellt werden.

Stufe 2:    Anonyme oder pseudonyme Protokollierung  zentral am Proxy

• Beteiligung des Datenschutzbeauftragten und der Personalvertretung,
• Analyse der Protokolldaten,
• Kommunikation der Ergebnisse in der Firmenöffentlichkeit, z. B. in Form einer Top-Ten-Liste,
• Hinweis, dass bei fortgesetztem Missbrauch personenbezogene Kontrollen oder Protokollierungen durchgeführt werden,
• mögliche technische Unterstützung, z. B. können im Fall einer Internetnutzung mit unerwünschten Webseiten deren Adressen in eine „Blacklist“ eingetragen werden, sodass die entsprechenden Server nicht erreichbar sind.

Die Auswertung der Daten kann dazu führen, dass sich als Quelle eines Miss­brauchs eine Abteilung identifizieren lässt. Auch darüber kann ein letzter Versuch gestartet werden, einen Appell an die Firmenöffentlichkeit zu richten, die uner­wünschten Handlungen zu unterlassen.

Stufe 3:    Personenbezogene Protokollierung  auf einem Proxy
Hierbei muss man die folgenden Regelungen vorsehen:

• Datenschutzbeauftragten beteiligen,
• personenbezogene Protokollierung in der Firmenöffentlichkeit ankündigen,
• den genauen Zweck, den Umfang der Daten und den Zeitraum der Protokol­lierung und deren Auswertung vorab in einem Konzept festlegen; der Umfang der von der Protokollierung erfassten Personen muss dabei auf den Kreis der Verdächtigen begrenzt werden, es darf nicht das gesamte Personal überwacht werden,
• Auswertung der Protokolldaten nur unter Beteiligung der Personalvertretung und des Datenschutzbeauftragten,
• vollständige Dokumentation der Auswertung,
• Löschung der personenbezogenen Daten nach Auswertung,
• Kommunikation der Ergebnisse,
• Abwägung des weiteren Vorgehens unter allen Beteiligten entsprechend der Ergebnisse:
• Einstellen der Kontrollen, keine weitere Überwachung,
• Rückkehr zu Stufe 2, weil man nach wie vor mit Verstößen rechnen muss,
• nochmaliges Verschärfen der Kontrolle, indem die Protokollierung auf dem Arbeitsrechner der Verdächtigen stattfindet (siehe Stufe 4).

Stufe 4:    Personenbezogene Protokollierung  auf dem Arbeitsrechner ohne Ankündigung
Hierfür gelten dieselben Anforderungen wie für die Stufe 3 mit Ausnahme der Ankündigung. Diese Protokollierung darf ebenfalls nur dann geschehen, wenn die Mitarbeiter in der Betriebsvereinbarung darüber aufgeklärt wurden, dass diese letzte Eskalationsstufe unter bestimmten Bedingungen zum Einsatz kommen kann. In dieser äußersten Eskalationsstufe sollte man erwägen, bereits eine Strafanzeige zu stellen und eine Strafverfolgungsbehörde hinzuzuziehen, um bei der Beweis­sicherung keine Fehler zu machen.

 

6.14       Kontrollen  vor Ort

6.14.1    Prüfungen bei Stadtverwaltungen: Lob für Heiligenhafen

Das ULD kontrolliert die Einhaltung der Vorgaben des LDSG und der DSVO direkt vor Ort. Der Schwerpunkt der datenschutzrechtlichen Prüfungen der technischen und organisatorischen Sicherungsmaßnahmen lag wieder bei den Stadtverwaltungen des Landes.

Bei unseren Prüfungen stellen wir immer wieder fest, dass die Verwaltungen, die ihren „Laden im Griff“ haben, auch in Fragen des Datenschutzes und der Daten­sicherheit kaum Anlass zur Kritik geben. Erweisen sich Defizite in der inner­behördlichen Steuerung, sind Zuständigkeiten nicht klar geregelt, und liegt schon das allgemeine Verwaltungshandeln im Argen, so steht es zumeist auch schlecht um Datenschutz und Datensicherheit.

Positiv tat sich die Stadtverwaltung Heiligenhafen hervor. Die geforderten Dokumentationen waren vorbildlich erstellt und auf dem neuesten Stand. Lediglich die durchgeführten Tests waren nicht nachvollziehbar. Der Administrator wusste nicht, wie dies datenschutzkonform zu bewerkstelligen ist. Nach Bereitstellung von Mustern versicherte uns der IT-Verantwortliche, die Dokumentation schnellstmög­lich nachzuholen.

Die im Sicherheitskonzept dokumentierten Regeln waren technisch umgesetzt, u. a. durch die flächendeckende Installation von Programmen zur Absicherung exter­ner Schnittstellen. Dies ist wichtig, denn personenbezogene Daten könnten leicht und unbemerkt auf Wechseldatenträgern die Organisationseinheit verlassen. Zudem könnte selbst ein durch eine Firewall und andere Sicherheitsmaßnahmen von außen gut geschütztes Netz von innen durch Computerviren verseucht werden. Über eine umfangreiche Schnittstellenkontrolle konnte die Administration steuern, welche Benutzer oder Gruppen auf USB- und FireWire-Ports, WiFi- und Bluetooth-Adapter, CD-ROMs, Disketten und andere entnehmbare Geräte Zugriff haben. Das sehr gute Prüfungsergebnis zeigte, dass das Thema Datenschutz in der Stadt­verwaltung Heiligenhafen ernst genommen wird – ein dickes Lob!

 

6.14.2    Amtshilfe bei einer Prüfung

Das ULD berät auch andere Prüforganisationen: Das Rechnungsprüfungs­amt des Kreises Pinneberg wurde durch das ULD bei der Bewertung techni­scher und organisatorischer Sachverhalte unterstützt.

Das ULD wurde vom Rechnungsprüfungsamt gebeten, die Umsetzung angemesse­ner Sicherheitsmaßnahmen und die Qualität der Dokumentation des IT-Einsatzes zu prüfen. Die geprüfte Verwaltung hat einen Großteil der Datenverarbeitung an Dataport ausgelagert. Sie nutzt dafür Teile der Produktlinie ABS.

Das ULD stellte sowohl bei der Stadtverwaltung als auch beim Dienstleister Dataport datenschutzrechtliche Mängel fest, die daraufhin durch das Rechnungs­prüfungsamt beanstandet wurden. Die Behebung dieser Mängel wird gemeinsam mit dem Rechnungsprüfungsamt überwacht. Unabhängig von der Prüfung arbeiten wir zusammen mit Dataport daran, die Produktlinie ABS zu verbessern: ABS‑Kunden müssen besser darin unterstützt werden, die datenschutzrechtlichen Anforderungen an eine ordnungsgemäße Datenverarbeitung zu erfüllen.

 

Zurück zum vorherigen Kapitel

Zum Inhaltsverzeichnis

Zum nächsten Kapitel