Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein

 

6    Systemdatenschutz

6.1          Zusammenarbeit für IT-Sicherheit und technischen Datenschutz

IT-Sicherheit und technischer Datenschutz gehören in die Infrastrukturen für Informationstechnik. Um diese zu erreichen, ist eine regelmäßige Koordinierung der unterschiedlichen Akteure im Land notwendig.

Die Informationstechnik (IT) der Landesregierung wird durch die Abteilung „Zentrales IT Management“ (ZIT) der Staatskanzlei unter Leitung des Chief Information Officer (CIO) organisiert. Neben den Ministerien und nachgeordneten Behörden des Landes nutzen weitere Institutionen wie die Landtagsverwaltung und der Landesrechnungshof Teile der technischen Infrastruktur der Landesregierung. Beispiele sind der Standard der Bürokommunikation (genannt „+1“), das Landesnetz oder die Systeme für die eAkte. Auch der kommunale Bereich kann Verfahren oder Systeme des Landes nutzen, etwa den zentralen De-Mail-Zugang.

Diese Tätigkeiten sollen in verschiedenen Gremien mit teils operativem, teils strategischem Charakter koordiniert werden: im Landes-IT-Rat, in der IT-Beauftragten-Konferenz und im Integrierten Sicherheitsmanagement.

Das Spiegelgremium des (Bundes-)IT-Planungsrats, in dem Bund und Länder die bundesweite IT-Planung vorantreiben, ist in Schleswig-Holstein der Landes-IT-Rat. Neben den Vertretern Schleswig-Holsteins im IT-Planungsrat (CIO und Staatskanzlei) sind Landesinstitutionen (u. a. Ressorts, Landtag, Landesrechnungshof) und KOMFIT (Kommunales Forum für Informationstechnik e. V.) als Vertretung der Kommunen beteiligt. Hier war in der Vergangenheit das ULD eingebunden und wird auch derzeit mit Informationen versorgt.

Die IT-Beauftragten-Konferenz (ITBK) ist die regelmäßige Besprechung der Abteilung ZIT mit den IT-Leitungen der Ressorts und einigen nachgeordneten Behörden und finden nach ursprünglich monatlichem Rhythmus mittlerweile je nach Bedarf in mehrmonatigem Abstand statt.

Für das Thema „IT-Sicherheit“ gibt es ein eigenes Gremium, das als Integriertes Sicherheitsmanagementsystem (ISMS) die Tätigkeit des IT-Sicherheitsbeauftragten des Landes (angesiedelt im ZIT) und der IT-Sicherheitsbeauftragten der Ressorts und einiger nachgeordneter Behörden koordiniert. Vertreten ist auch der kommunale Bereich durch das KOMFIT sowie Dataport. Im Gegensatz zu den Treffen der ITBK und des Landes-IT-Rats tritt dieses Gremium in gewohnter Regelmäßigkeit in zweimonatlichen Arbeitstreffen zusammen.

Ein regelmäßiger Tagesordnungspunkt ist der Bericht des CERT Nord („Computer Emergency Response Team“), das im Auftrag der Länder Schleswig-Holstein, Bremen, Hamburg und Sachsen-Anhalt bei Dataport gebildet wurde. Seine Aufgabe ist die Beobachtung und Abwehr von Angriffen auf die IT-Sicherheit. Dazu werden Softwareschwachstellen und Angriffe auf fremde IT-Infrastrukturen analysiert (beispielsweise anhand von Publikationen, aber auch in Zusammenarbeit mit anderen CERTs auf Landes- und Bundesebene sowie dem BSI). Auch die Beobachtung und Abwehr von konkreten Angriffen auf die von Dataport bereitgestellte IT-Infrastruktur gehört zu den Aufgaben des CERT. Hilfreich ist hier die Gesamtschau auf die verschiedenen Bundesländer, denn je nach Konfigurationsvorgaben sind Angriffe in einigen Bundesländern erfolgreich, während sie in anderen Ländern durch eine geeignete Konfiguration unterbunden werden. Hier besteht die Chance, voneinander lernen und erfolgreiche Verteidigungsstrategien kopieren zu können. Daher ist eine weitere Aufgabe des CERT, Warnungen und Gegenmaßnahmen zu publizieren, die zielgerichtet auf Hardware, Software und Konfiguration der öffentlichen Verwaltung zugeschnitten sind. Dies richtet sich zunächst an die Landes-IT, ist aber auch hilfreich für andere öffentliche Bereiche wie Kommunen oder kommunale Dienstleister.

Im Projekt SiKoSH (Sicherheit für Kommunen in Schleswig-Holstein) des KOMFIT werden Hilfsmittel erarbeitet, um IT-Sicherheit im kommunalen Bereich auch mit geringen Ressourcen ausreichend gewährleisten zu können. Ziel ist es, durch die Bereitstellung von anpassbaren Musterdokumenten wie Leitlinien, Rahmenkonzepten, spezifischen Richtlinien und anderen Hilfsmitteln den Aufwand für die Erarbeitung dieser Dokumente zu verkürzen und gleichzeitig praxistaugliche Anforderungen zu formulieren, die dann umzusetzen sind.

Was ist zu tun?
IT-Sicherheit und technischer Datenschutz, wie dies im Land notwendig ist, erfordern ein Handeln mit vereinten Kräften. Die Zusammenarbeit im ISMS und seine Schlagkraft sind zu verbessern. Eine frühzeitige Information und Einbindung des ULD als beratendes Mitglied ist sinnvoll.

 

6.2          Länderübergreifende Zusammenarbeit der Datenschutzbeauftragten

Die Zusammenarbeit der Datenschutzbeauftragten zu technisch-organisatorischen Fragen erfolgt insbesondere über den Arbeitskreis Technik, der auch allen Facharbeitskreisen und -arbeitsgruppen der Konferenz der unabhängigen Datenschutzbehörden des Bundes und der Länder (DSK) durch die Bewertung technisch-organisatorischer Fragen zuarbeitet. Daneben gibt es regionale und Ad-hoc-Kooperationen sowie eine Vertretung der Datenschutzbeauftragten in externen Gremien, die sich mit Datenschutz und IT-Sicherheit in der Verwaltung und der Wirtschaft befassen.

6.2.1       Arbeitskreis Technik

Im Arbeitskreis Technik (AK Technik) beraten sich Vertreter der Technikabteilungen bzw. Technikreferate der Datenschutzbeauftragten der Länder und des Bundes. Mitglieder sind ebenfalls Vertreter des kirchlichen Datenschutzes sowie der Datenschutzbehörden aus der Schweiz und aus Liechtenstein. Der Arbeitskreis bereitet Kommentare, Orientierungshilfen und Entschließungen zu technischen Themen für die DSK vor. Einen weiteren Schwerpunkt bilden die gegenseitige Information und Koordination von Prüfungen und Bewertungen.

Relevante Themen im Berichtszeitraum waren Cloud-Dienste und ihre Prüfbarkeit aus technisch-organisatorischer Sicht, das Standard-Datenschutzmodell (Tz. 6.3) sowie die Wiedererkennung von Kfz bei streckenbasierten Geschwindigkeitskontrollen („Section Control“) und Verkehrsflussmessungen. Derzeit liegt der Arbeitsschwerpunkt auf der Überarbeitung und Anpassung bestehender Orientierungs- und Arbeitshilfen an die EU-Datenschutz-Grundverordnung.

 

6.2.2       Arbeitsgruppe der Datenschutzbeauftragten der Dataport-Trägerländer

Der Dienstleister Dataport hat insgesamt sechs Trägerländer: Schleswig-Holstein, Hamburg, Bremen, Niedersachsen, Mecklenburg-Vorpommern und Sachsen-Anhalt. Für diese führt Dataport insbesondere Auftragsdatenverarbeitungen durch, wobei das für die Auftraggeber jeweils geltende Recht zu beachten ist. Bei der Auftragsdatenverarbeitung für die Trägerländer oder deren Kommunen muss Dataport für einzelne Verfahren bis zu sechs verschiedene landesspezifische Regelungen beachten und wird durch bis zu sechs Datenschutzaufsichtsbehörden kontrolliert. Daneben verarbeitet Dataport eigenverantwortlich Daten, z. B. Personaldaten. Diese Verarbeitung richtet sich gemäß dem Staatsvertrag nach dem LDSG Schleswig-Holstein; die zuständige Aufsichtsbehörde ist das ULD.

Erklärtes Ziel der Gründung von Dataport war, durch Zusammenarbeit Synergieeffekte zu nutzen. Dies gelingt, wenn Verfahren länderübergreifend oder möglichst einheitlich, z. B. durch Nutzung der gleichen Software, betrieben werden können. Beispiele hierfür sind Verfahren für das Personenstandswesen und der Zentrale Meldedatenbestand, in dem die Meldedaten der Meldebehörden auf Landesebene gebündelt und für Auskunftsverfahren bereitgestellt werden.

Die Grenzen der übergreifenden Zusammenarbeit bilden die jeweiligen landesrechtlichen Regelungen. Daher sind bei länderübergreifenden Verfahren zumindest die Bundesländer als eigene Mandanten zu betreiben. Bei Flächenländern wie Sachsen-Anhalt und Schleswig-Holstein kommen häufig noch kommunale Mandanten hinzu. Auch aufgrund der Behördenorganisation in den Ländern unterscheiden sich Verfahren und Verfahrensweise insbesondere zwischen Stadtstaaten und Flächenländern – ein Umstand, der Anpassung der Verfahren erfordert.

Da bis zu sechs Aufsichtsbehörden zuständig sind, sind Absprachen bei Prüfungen und Beratungen notwendig. Zu diesem Zweck treffen sich die Datenschutzaufsichtsbehörden regelmäßig auf Arbeits- und Leitungsebene und nehmen Informationstermine durch Dataport wahr. 2017 wird erstmals eine gemeinsame Prüfung der Datenschutzaufsichtsbehörden im technischen Bereich erfolgen.

Was ist zu tun?
Dataport und seine Auftraggeber sollten die Datenschutzbeauftragten weiterhin frühzeitig einbinden. Dadurch können bereits in der Planungsphase unterschiedliche landesrechtliche Regelungen erkannt und passende Lösungen erarbeitet werden.

 

6.2.3       Standardisierung von Datentransporten im E-Government (XTA)

Das ULD berät stellvertretend für die Datenschutzaufsichtsbehörden der Länder eine Arbeitsgruppe der Koordinierungsstelle für IT-Standards (KoSIT), die als operativer Arm des IT-Planungsrats arbeitet. Sie erstellt u. a. die Spezifikation eines „fachunabhängigen Standards für Transportverfahren“ (XTA) für die öffentliche Verwaltung.

Aufgabe des Standards XTA

Die Sachbearbeitung in einer öffentlichen Verwaltung erfolgt meist mithilfe von Fachverfahren, z. B. für das Einwohnermeldewesen. Diese Fachverfahren kommunizieren mit anderen Fachverfahren derselben Verwaltung, aber auch mit Fachverfahren anderer Behörden (etwa Einwohnermeldeverfahren bei Umzügen). Dabei kommen verschiedene Transportmechanismen für die Daten zum Einsatz. XTA ist ein Programmbestandteil, der zwischen den Fachverfahren und den verfügbaren Transportmechanismen (z. B. OSCI-Transport, Direkteintrag in Datenbanken, örtliche Clearingstellen usw.) vermittelt und beispielsweise bestimmen kann, welche Transportmechanismen zum Einsatz kommen dürfen.

Die Datenübertragung entspricht in der papierbasierten Welt der Weitergabe von Papieren oder Akten, entweder innerhalb einer Verwaltung oder an andere Verwaltungen. Die Transportmechanismen setzen die verschiedenen Formen der Weitergabe bzw. des Versands (etwa persönliche Übergabe, Einlegen in örtliche Ablagefächer, Postversand, Einschreiben, Kurier für Verschlusssachen usw.) um. Mit dem Standard XTA lassen sich Verfahren beschreiben, mit denen die Modalitäten der Weitergabe der Daten festgelegt werden können, etwa: „Personalakten innerhalb der Verwaltung in geschlossenen Umschlägen oder von Hand zu Hand, an andere Verwaltungen nur per Post und Einschreiben weitergeben.“

Der Hintergrund zur Notwendigkeit dieser Standardisierung der elektronischen Kommunikation in der öffentlichen Verwaltung sowie der Begleitung der XTA-Entwicklung durch Datenschutzexperten wurde bereits im letzten Tätigkeitsbericht (35. TB, Tz. 6.2.4) dargestellt. Im Januar 2017 wurde nun die Spezifikation von XTA (Version 3) veröffentlicht, dazu die „Service Profile Schemata (V1.1)“ und die „XTA-WS-Schemata (V2.1.1)“ (http://www.xoev.de/
downloads-2316#XTA). Dataport ist als einer der führenden Entwickler und Nutznießer von XTA beteiligt.

Die Standardisierung der Datenübertragung (genauer: des „Nachrichtentransports“) durch XTA geschieht auf zwei Ebenen: auf der normativen und auf der technisch-operativen Ebene:

Auf normativer Ebene wird den Auftraggebern – das ist aktuell der IT-Planungsrat, der deutschlandweit die Kommunikation zwischen den Behörden beim Bund und bei den Ländern und Gemeinden plant und abstimmt – das Modul „Service Profile“ bereitgestellt. Mit diesem Werkzeug können Anforderungen an Funktionalität, Datenschutz und IT-Sicherheit sowohl für den Transport als auch die dabei beteiligten Instanzen definiert und damit einheitlich konfigurierbar gemacht werden. Dies erfordert, dass der Gesetzgeber die rechtlichen Anforderungen an die Kommunikation und Sicherheit so formuliert, dass deren Rechtskonformität prüfbar und die technische Umsetzung eindeutig spezifizierbar und betriebswirtschaftlich kalkulierbar wird.

Auf technischer Ebene wird durch das Modul des „XTA-Webservice“ (XTA-WS) der Transport von Daten standardisiert. Die Spezifikation von Webservices vereinheitlicht die Schnittstellen zwischen Fachverfahren und Transportverfahren. Für die rechtskonforme Steuerung der dabei zu wählenden Adressierungen, Schutzfunktionen und Überwachungen sorgt XTA anhand der zuvor genannten Service Profile.

Die Spezifikation und Entwicklung des XTA-Standards wurde anhand der sieben Gewährleistungsziele des Standard-Datenschutzmodells (Tz. 6.3) modelliert. Seit 2014 hat diese Spezifikation eine zusätzliche Konkretion, insbesondere im Bereich der Dokumentation und Protokollierung, erfahren.

Mithilfe von Protokollierungen auf verschiedenen Ebenen kann beispielsweise der Nachweis erbracht werden, dass ein Nachrichtentransport erfolgreich war (z. B. Zustellungsquittung) und dass er in einer geforderten Art und Weise (z. B. unter Nutzung eines vorgegebenen Transportmechanismus unter Nutzung verbindlicher Verschlüsselungs- und Quittierungsfunktionen) erfolgt ist. Auf diese Weise lässt sich überprüfen, ob die Anforderungen eines Service Profiles umgesetzt wurden.

Offen ist noch, ob und inwieweit die Anforderungen an die übrige Infrastruktur eines Rechenzentrums (etwa Speichersysteme, Netzanbindungen, Administrationsverfahren) so standardisiert werden können, dass man von einem „XTA-konformen Rechenzentrum“ sprechen kann, dessen Nutzung per XTA gefordert oder sogar erzwungen werden könnte. Dieser Aspekt dürfte mit zunehmender Nutzung der Service Profile und Standardisierung von Datenübermittlungen von Fachverfahren einen immer größeren Nutzerkreis (Verwaltungsbereiche) betreffen. Potenziell sind damit auch zunehmend mehr private und öffentliche Rechenzentren betroffen, die sich als „XTA-konform“ ausweisen können sollten. Noch nicht hinreichend spezifiziert sind außerdem Testverfahren, um XTA-Konformität von Services und Servicebetreibern feststellen zu können.

Was ist zu tun?
Die Spezifikation sollte insbesondere im Hinblick auf Aspekte des Konformitätsnachweises weiterentwickelt werden. Die datenschutzrechtlichen Anforderungen an Funktionalität und Schutzmaßnahmen sollten gezielter formuliert und automatisiert durchgesetzt werden.

 

6.3          Das Standard-Datenschutzmodell (SDM)

Die 92. Konferenz der unabhängigen Datenschutzbehörden des Bundes und der Länder (DSK) hat im November 2016 die Version 1.0 des Standard-Datenschutzmodells zustimmend zur Kenntnis genommen. Die DSK empfiehlt, die Nutzung des Modells bei Beratungs- und Prüfungstätigkeiten zu evaluieren und damit die Praxistauglichkeit zu erproben. Seit Januar 2017 liegt ein erster Entwurf der Englisch-Übersetzung des Standard-Datenschutzmodells vor, der in die europäischen Datenschutzgremien eingespeist werden wird.

Das Dokument zum Standard-Datenschutzmodell beschreibt die Methodik, um rechtliche Anforderungen und technische und organisatorische Eigenschaften in ein systematisches Verhältnis setzen zu können. Das Standard-Datenschutzmodell berücksichtigt auch die Anforderungen der DSGVO im Bereich der technisch-organisatorischen Maßnahmen. Die im März 2013 gegründete Unterarbeitsgruppe zum SDM hatte im Jahr 2015 damit begonnen, neben der Methodik einen Katalog mit Schutzmaßnahmen zu entwickeln. Als methodisches Vorbild dienen die Grundschutzmethode und die Grundschutz-Kataloge des Bundesamts für Sicherheit in der Informationstechnik (BSI). Allerdings betont das Standard-Datenschutzmodell im Unterschied zum IT-Grundschutz, der vornehmlich die Perspektive der datenverarbeitenden Stellen in den Vordergrund stellt, die Sicht der betroffenen Personen und ihre Rechte. Dies wirkt sich auch auf den „Baustein 1.5 – Datenschutz“ in den IT‑Grundschutz-Katalogen des BSI aus, in den nunmehr das Standard-Datenschutzmodell knapp eingeführt werden soll. In diesem Text wird deutlich, dass Datenschutz einerseits ohne Maßnahmen der Informationssicherheit nicht umsetzbar ist und andererseits die Maßnahmen der Informationssicherheit wiederum datenschutzgerecht zu gestalten sind.

Zusätzlich werden übergreifende Datenschutzmaßnahmen wie die Datenschutz-Folgenabschätzung und Datenschutz-Zuständigkeiten (Datenschutzbeauftragter) ebenso wie Maßnahmenbündel zu komplexen Themenstellungen (wie beispielsweise Schuldatenverarbeitung, Videoüberwachung oder Krankenhausinformationssysteme) als Orientierungshilfen veröffentlicht.

Die Trennung von IT-Sicherheit und operativem Datenschutz verlangt von vielen Expertinnen und Experten auch im Bereich des Datenschutzes ein Umdenken, weil sie über viele Jahre hinweg personenbezogene Daten nur als eine technisch besonders schützenswerte Form von Daten begriffen haben. Es wurde mit dem BSI vereinbart, wechselseitig in den IT-Grundschutz-Katalogen und in den SDM-Dokumenten stärker aufeinander zu verweisen.

Die Schulungs- und Beratungstätigkeiten im Jahr 2016 zum SDM haben gerade im Privatbereich stark zugenommen. Im Rahmen der Beteiligung des ULD am Projekt „Forum Privatheit“ (Tz. 8.1) wurde ein Ablaufprozess für eine Datenschutz-Folgenabschätzung entwickelt, der in seinem materiellen Kernbereich stark auf die Methodik und die Maßnahmen nach dem SDM abstellt.

https://www.datenschutzzentrum.de/sdm/

 

6.4         Datenschutz-Folgenabschätzung – ein neues Instrument aus der Grundverordnung

In Artikel 35 DSGVO wird von Organisationen eine Abschätzung der Datenschutzfolgen verlangt, um auf dieser Basis eine bessere Beherrschbarkeit der Risiken und einen verantwortungsvollen Umgang mit personenbezogenen Daten zu erreichen. Diese Abschätzung ersetzt die Vorabkontrolle aus § 4d Abs. 5, 6 BDSG bzw. § 9 LDSG-SH.

Eine Datenschutz-Folgenabschätzung (DSFA) (englische Bezeichnung: „Data Protection Impact Assessment“ (DPIA)) ist laut Artikel 35 DSGVO bei Verfahren mit einem vermutlich hohen Risiko für die Rechte und Freiheiten natürlicher Personen erforderlich. Bei der Prüfung solcher Risiken müssen die potenziellen Schäden – diese können nach Erwägungsgrund 75 physischer, materieller oder immaterieller Art sein – und die Eintrittswahrscheinlichkeit berücksichtigt werden.

Artikel 35 DSGVO nennt einige Faktoren, bei denen von einem hohen Risiko ausgegangen werden muss und demnach eine DSFA durchzuführen ist: Einsatz neuer Technologien, automatisierte Einzelentscheidungen einschließlich Profiling, umfangreiche Verarbeitung besonderer Arten personenbezogener Daten oder systematische umfangreiche Überwachung des öffentlichen Raums. Zusätzlich werden die Aufsichtsbehörden eine Liste von Verarbeitungstätigkeiten, für die in jedem Fall eine DSFA durchzuführen ist, erstellen.

Die Bestandteile einer DSFA sind ebenfalls im Artikel 35 DSGVO festgelegt: Gefordert ist u. a. eine Beschreibung des Verfahrens, der Zwecke, der berechtigten Interessen sowie eine Bewertung der Notwendigkeit und Verhältnismäßigkeit der Verarbeitung sowie der Risiken für Betroffene. Ebenso gefordert ist eine Beschreibung der geplanten Schutzmaßnahmen mit Nachweis über deren Wirksamkeit. Die DSFA ist durch die Verantwortlichen durchzuführen; Datenschutzbeauftragte sind beratend tätig.

Das ULD hat im Rahmen des Projekts „Forum Privatheit“ (Tz. 8.1) zusammen mit weiteren Projektpartnern ein generisches Prozessmodell zur vollständigen Durchführung einer DSFA erarbeitet. Dieses Prozessmodell funktioniert nicht nur für eine DSFA von Verarbeitungsvorgängen nach Artikel 35 DSGVO, sondern ermöglicht auch den Einsatz für wissenschaftliche Untersuchungen von abstrakteren Gegebenheiten, z. B. zur vergleichenden Analyse von staatlichen Überwachungslösungen.

Der Ablauf der DSFA umfasst fünf Phasen: (1) Vorbereitungsphase, (2) Bewertungsphase, (3) Maßnahmenphase, (4) Berichtsphase sowie (5) die Einbindung des Verfahrens in das Datenschutzmanagementsystem einer Organisation. Ein White Paper zur Darstellung des Ablaufmodells findet sich auf der Webseite:

https://www.forum-privatheit.de/forum-privatheit-de/publikationen-und-downloads/veroeffentlichungen-des-forums.php

Bei der Erarbeitung des Prozessmodells haben sich zwei wichtige Aspekte herausgestellt:

• Bei einer systematischen Durchführung einer DSFA empfiehlt es sich, für die Prüfung der rechtlich angemessenen Funktionalitäten und Schutzmaßnahmen in den Phasen 2 und 3 auf die Methodik und die Maßnahmen des Standard-Datenschutzmodells (Tz. 6.3) zurückzugreifen. Bei der Abschätzung des Risikos bietet es sich an, für die Gewährleistungsziele, die im Artikel 5 der DSGVO als Grundsätze enthalten und im SDM ausgeführt sind, zu untersuchen, ob sie vom geplanten Verfahren im erforderlichen Maße umgesetzt werden.
• Artikel 35 DSGVO verlangt mehr als nur eine Abschätzung, welche Risiken durch die beabsichtigte Nutzung des Verfahrens entstehen. Er fordert auch, Schutzmaßnahmen festzulegen und ihre Wirksamkeit nachzuweisen.

Das ULD rät dazu, vor der Einführung eines Verfahrens im Rahmen einer schlanken „Vorab-DSFA“ zu prüfen, ob vermutlich hohe Risiken für Betroffene bestehen und somit die Notwendigkeit einer DSFA gemäß Artikel 35 DGSVO gegeben ist. Zeigt sich, dass nicht mit einem hohen Risiko zu rechnen ist, kann dies die Grundlage für die Rechtfertigung der Entscheidung bilden, dass keine vollständige DSFA durchzuführen ist. Dies ist zu dokumentieren. Bestehen hohe Risiken, so ist eine vollständige DSFA durchzuführen.

Was ist zu tun?
Jede verantwortliche Stelle sollte jetzt ihre Verfahren daraufhin überprüfen, ob eine Datenschutz-Folgenabschätzung durchzuführen ist, und die notwendigen Maßnahmen ergreifen, um die Pflichten nach der Datenschutz-Grundverordnung rechtzeitig umzusetzen.

6.5          Ausgewählte Ergebnisse aus Vorabkontrollen und Prüfungen

6.5.1       Verfahrensdokumentation bei zentralen Verfahren am Beispiel von „KoPers kommunal“

Die Datenschutzverordnung (DSVO) regelt in Verbindung mit dem Landesdatenschutzgesetz Schleswig-Holstein (LDSG) die Anforderung an die Dokumentation von automatisierten Verfahren. Für viele verantwortliche Stellen ist es nicht leicht, diese Anforderungen an Verfahren in ihrem Verantwortungsbereich in Bezug auf Struktur, Transparenz und Vollständigkeit zu erfüllen.

Die Vorlagen und Handreichungen des ULD zum Themenbereich Dokumentation können in diesem Zusammenhang eine Hilfestellung leisten:

https://www.datenschutzzentrum.de/dsvo/

Bei zentralen Verfahren gibt es jedoch nicht nur eine verantwortliche Stelle, die die Dokumentationspflichten übernimmt, sondern die Aufgabe der Dokumentation verteilt sich auf verschiedene Verantwortungsbereiche. Das sind die zentrale Stelle selbst, die beteiligten Stellen sowie gegebenenfalls externe Dienstleister.

Ein solches zentrales Verfahren ist „KoPers kommunal“, ein Personalmanagementsystem im kommunalen Bereich, das seit mehreren Jahren weiterentwickelt wird. In gemeinsamen Sitzungen mit der Versorgungsausgleichskasse der Kommunalverbände in Schleswig-Holstein (VAK), Dataport und den behördlichen Datenschutzbeauftragten einiger beteiligter Stellen konnte die Grundlage für eine Handreichung des ULD erarbeitet werden, die die Dokumentationspflichten aller am Verfahren beteiligten Stellen beschreibt. Die Handreichung basiert auf den oben beschriebenen Dokumentationsvorlagen und kann auf der Webseite des ULD heruntergeladen werden:

https://www.datenschutzzentrum.de/uploads/dsvo/verfahrensakte/Dokumentation_zentrale_beteiligte_Stelle.pdf

Was ist zu tun?
Bei jedem zentralen Verfahren muss anhand der gesetzlichen Grundlagen festgelegt werden, welche Dokumentationspflichten für die zentrale Stelle, für die beteiligten Stellen und gegebenenfalls für externe Dienstleister bestehen.

6.5.2       Verfahrensdokumentation bei zentralen Verfahren am Beispiel von „KoPers kommunal

Das Ministerium für Soziales, Gesundheit, Wissenschaft und Gleichstellung (MSGWG) hat sich 2015 entschlossen, das Verfahren „BafSys“ für die Bearbeitung von BAföG-Anträgen einzuführen. Das ULD wurde im Rahmen einer Vorabkontrolle eingebunden.

Während die BAföG-Ämter in den Kreisen, kreisfreien Städten und Studentenwerken das Verfahren anwenden und somit für die Inhalte des Verfahrens sowie für die Umsetzung der Datenschutzanforderungen vor Ort verantwortlich sind, agiert das MSGWG als zentrale Stelle: Es beauftragt und kontrolliert den Dienstleister Dataport in den zentralen operativen Aspekten des Verfahrens.

Die Rechtsgrundlagen der Datenverarbeitung finden sich vornehmlich im Bundesausbildungsförderungsgesetz (BAföG). Die Rolle des MSGWG als zentrale Stelle ist seit dem 01.05.2016 per Verordnung geregelt (Landesverordnung VOzS BaföG). Es liegen Verträge zwischen dem MSGWG und den Kommunen sowie dem MSGWG und Dataport vor. Die Rechtsgrundlagen bezüglich des Übermittelns von BAföG-Daten an andere im Grundsatz gesetzlich berechtigten Bedarfsträger (Bundesverwaltungsamt (BVA), Bundeszentralamt für Steuern (BZSt), KfW-Bank für Vergabe von Studienkrediten) sind jedoch vielfach nicht hinreichend klar dokumentiert.

Die technisch-organisatorischen Maßnahmen wurden aufseiten des ULD unter Zuhilfenahme des Standard-Datenschutzmodells (Tz. 6.3) geprüft. Als Ausgangspunkt für die Gestaltung der Funktionen und Schutzmaßnahmen wurde zunächst der Schutzbedarf des Verfahrens herangezogen und anschließend die zu treffenden Maßnahmen anhand von Gewährleistungszielen (vgl. § 5 LDSG) bestimmt. Geprüft wurden die vom MSGWG vorgelegten Dokumente der zentralen Verfahrensbestandteile von BafSys.

BAföG-Daten sind Sozialdaten und haben damit einen hohen Schutzbedarf, dem alle IT-Komponenten des Verfahrens genügen müssen. Das bedeutet, dass die Funktionen und Maßnahmen des Datenschutzes wirksam umgesetzt und anhand von Protokolldaten und einer vollständigen und aktuellen Dokumentation kontrollierbar sein müssen.

Der zentrale Verfahrensbestandteil von BafSys wird im Sicherheitsbereich „hoch“ des Rechenzentrums von Dataport betrieben. Die Clients für die Fachkräfte in den BAföG-Ämtern sind über das Landesnetz angebunden, die Kommunikation zwischen den Citrix-Clients und den zentralen Servern bei Dataport geschieht laut Auskunft von Dataport verschlüsselt.

Die Trennung der Verfahren pro BAföG-Amt ist als Mandantentrennung innerhalb einer gemeinsamen Datenbank ausgeführt. Diese Trennung ist schwach; Daten können versehentlich (z. B. bei Programmierfehlern) oder vorsätzlich zusammengeführt werden. Auch Fehler bei der Nutzerverwaltung können relativ leicht dazu führen, dass Zugriffe auf falsche Datenbestände eingerichtet werden. Das MSGWG wurde auf die schwache Trennungsqualität hingewiesen. Die vorliegende Trennung ist zumindest in der Hinsicht hinreichend, dass die Ämter im Normalbetrieb unabhängig voneinander agieren können.

Eine schwache Durchsetzung der Trennungsanforderung bedarf zumindest der Kompensation durch eine besonders gesicherte Prüfbarkeit der Aktivitäten der Systeme, der Sachbearbeitung sowie der Administration. Die Prüfbarkeit des Verfahrensbetriebs muss bereits bei der Spezifikation berücksichtigt werden. Die Datengrundlage bilden Protokolldaten. Hier ist bei BafSys Vieles bislang nicht ausgereift: Weder die Protokollierung auf der Ebene der Sachbearbeitung noch die der Administration der Fachapplikation noch die Tätigkeiten der Systeme auf der Infrastrukturebene und der Schnittstellen sowie deren Administration sind hinreichend konzipiert bzw. aufeinander abgestimmt. Beim Auftragsdatenverarbeiter Dataport fallen zahlreiche Protokolldaten an – nur ist der Verfahrensbezug dieser Protokolle durch das MSGWG nicht sichergestellt. Dies ist jedoch kein BafSys-spezifisches Problem, sondern ein generelles Problem der Arbeitsteilung beim Verfahrensbetrieb in einem Rechenzentrum.

Die Nutzerverwaltung erfolgt im Auftrag durch Dataport und wird auch bei Dataport protokolliert. Die Aktivitäten des Auftragsdatenverarbeiters durch den Verantwortlichen können mit der vorliegenden Protokollierungslösung nicht zweifelsfrei überwacht werden, weil der zu überwachende Auftragnehmer die Instrumente zu seiner Überwachung in der eigenen Hoheit betreibt. Zudem sind bislang keine Prozesse vorgesehen, wenn sich aus Prüfungen Klärungsbedarf ergibt.

Die Dokumentation ließ nicht erkennen, ob und wie Übermittlungen aus dem BafSys-Datenbestand freigegeben werden. In diesem Zusammenhang spielt der Aspekt der Pseudonymisierung und Anonymisierung von Daten eine besondere Rolle, wenn diese zu Zwecken statistischer Auswertungen wie vorgesehen an das Statistische Bundesamt zu übermitteln sind. Diese sind sorgsam zu spezifizierende Prozesse, die bisher jedoch dem ULD gegenüber nicht dargestellt wurden. Aus diesem Grund konnte deren Qualität noch nicht geprüft und daraufhin rechtlich beurteilt werden, ob diese dem hohen Schutzbedarf entsprechen.

Was ist zu tun?
Es muss mit größerem Nachdruck als bislang dafür gesorgt werden, dass die Aktivitäten auf der Ebene der Sachbearbeitung sowie den verschiedenen Ebenen der IT-Systeme und der IT-Administrationen zweifelsfrei anhand der Dokumentation und der Protokolldaten überprüfbar sind.

6.5.3      eBeihilfe – automatisierte Bearbeitung von Beihilfeanträgen

Im Rahmen der Gewährung von Beihilfen für die Beschäftigten des Landes werden derzeit beim Dienstleistungszentrum Personal (DLZP) Beihilfeunterlagen, Anträge und Anlagen (z. B. Rechnungskopien) bearbeitet. In der Vergangenheit wurden diese nach der Bearbeitung und Bescheiderstellung eingescannt und elektronisch archiviert. Die Papieroriginale wurden vernichtet (35. TB, Tz. 4.1.7).

Zur Schaffung von Synergien wurde vor 2011 das Projekt „eBeihilfe“ gestartet, das die Bearbeitung von Beihilfeanträgen automatisieren soll. Das ULD war im Rahmen einer Vorabkontrolle beteiligt. In einer ersten Stufe („Stufe 1a“) wurde die Digitalisierung der eingereichten Unterlagen der Bearbeitung vorgelagert, sodass diese elektronisch der Sachbearbeitung vorgelegt werden. Die Berechnung und Bescheiderstellung erfolgt weiterhin mit der Fachanwendung PERMIS-B. Eine Herausforderung dabei ist neben der Bearbeitung von Fehlern beim Scannen (Unleserlichkeiten) die Klassifizierung der Unterlagen: Anträge, Rechnungen, Rezepte und weitere Belege werden unterschieden, um diese strukturiert bearbeiten zu können. U. a. werden Rezepte automatisiert ausgewertet, damit das Land Arzneimittelrabatte wahrnehmen kann. Die eingereichten Unterlagen und ebenso ihre elektronischen Pendants unterliegen verschiedenen Aufbewahrungsfristen, die sich aus § 91 Abs. 2 Landesbeamtengesetz ergeben: So sind Unterlagen, aus denen sich Rückschlüsse auf die Krankheit ergeben (üblicherweise Rechnungen mit Diagnosen), drei Monate, Rezepte zwölf Monate und übrige Unterlagen fünf Jahre aufzubewahren. Bei Fehlzuordnungen kann manuell die Klassifikation verändert werden.

Papierunterlagen werden drei Monate nach dem Einscannen vernichtet. Für die Löschung der elektronischen Daten liegen mittlerweile Löschkonzepte vor. Dies betrifft zum einen die Beihilfedaten, die in der datenbankbasierten Anwendung PERMIS-B gespeichert sind. Zum anderen sind die elektronischen Dokumente zu löschen. Das Löschen erfolgt automatisiert in Abhängigkeit der vorgegebenen Fristen. Dies wird durch das Verfahren PERMIS-B gesteuert, das das elektronische Archiv ansteuert und die Löschung auslöst. Zu beachten ist dabei, dass im Streitfall (beispielsweise bei Widerspruchs- oder Gerichtsverfahren) die automatische Löschung fall- und dokumentenbasiert aufgeschoben werden muss. Das DLZP entschied sich gegen eine elektronische Signatur der Scandateien, die im Hinblick auf die unterschiedlichen Aufbewahrungsfristen jeweils pro Dokument bzw. Dokumentenklasse erfolgen muss. Beweggrund war neben dem manuellen Prüf- und Signieraufwand auch die Schwierigkeit, im Augenblick des Scans eine zweifelsfreie Klassifikation und damit eine Unterteilung der eingereichten Dokumente vorzunehmen. Einen Entlastungsbeweis über einen streitigen Umfang der eingereichten Dokumente („Wurde Anlage 7 tatsächlich eingereicht“?) kann das DLZP mit einer Signatur nicht führen, denn diese gewährleistet lediglich die Integrität gespeicherter Dokumente und schützt nicht vor Verlust oder Löschung einzelner Dateien.

Was ist zu tun?
Auch in weiteren Projektphasen – nach der Vorabkontrolle – ist eine Beteiligung des ULD sinnvoll, denn Beihilfedaten sind sensibel und gesetzlich besonders geschützt.

6.5.4       Personalbefragungen zum betrieblichen Gesundheitsmanagement

Eingebunden war das ULD in verschiedene Projekte der Staatskanzlei und anderer Behörden, die anhand von Befragungen der Beschäftigten Erkenntnisse für das betriebliche Gesundheitsmanagement gewinnen wollten. Typische Fragestellungen umfassen die Belastungssituation, Zufriedenheit am Arbeitsplatz und gegebenenfalls Hinweise auf Auslöser von Krankheiten, aber auch soziografische Daten wie Alter, Tätigkeitsumfang (Vollzeit/
Teilzeit) und Beschäftigtenstatus (angestellt/
beamtet). Aufgrund der Sensibilität der Fragen wurde eine anonyme Befragung durch einen darauf spezialisierten Auftragnehmer geplant.

Hierbei sollten sowohl ressortübergreifende Erkenntnisse als auch Erkenntnisse auf Ressort- und Abteilungsebene gewonnen werden. Die Ressorts hatten daher die Möglichkeit, spezifische Fragestellungen innerhalb des Ressorts zu entwickeln und Auswertungen auf Ressort- und Abteilungsebene zu beauftragen. Dies hat zur Folge, dass Antworten zumindest den Abteilungen zugeordnet werden können und somit die Anonymitätsgruppe (d. h. die Gruppe, innerhalb der ein Antwortender anonym ist) höchstens so groß wie die zugehörige Abteilung ist.

Die Herausforderung bestand darin, bei der Durchführung und Auswertung der Befragung die Anonymität der Beschäftigten zu wahren. Würde die Auswertung durch den Auftraggeber direkt erfolgen, könnte dieser mit dem Zusatzwissen der soziografischen Daten die Antworten einzelnen Befragten zuordnen. Daher wurden Dienstleister beauftragt, die einerseits die Befragung und die Auswertung vornahmen, andererseits gerade nicht über das Zusatzwissen verfügten, um Antworten einzelnen Befragten zuordnen zu können. Vertraglich wurde festgelegt, dass die vollständigen Antworten beim Auftragnehmer verbleiben und dass beauftragte Einzelauswertungen so vorgenommen werden, dass bei der untersuchten Gruppe eine Mindestzahl von Mitgliedern (z. B. zehn Personen) das relevante Merkmal umfassen muss. Ist diese Bedingung nicht erfüllt, so darf keine Einzelauswertung erfolgen; stattdessen wird aggregiert ausgewertet. Hat beispielsweise eine Behörde eine Abteilung mit 18 Personen, bestehend aus elf Frauen und sieben Männern, so kann keine geschlechtsspezifische Auswertung durchgeführt werden. Eine Zusammenfassung der Auswertung mit einer zweiten Abteilung, bestehend aus vier Frauen und vier Männern, ist hingegen möglich, da stets mehr als zehn Personen dasselbe Geschlecht haben.

Eine weitere Fragestellung betraf die praktische Frage, ob eine Online-Befragung möglich ist oder ob eine papierbasierte Befragung erfolgen muss: Bei einer Online-Befragung besteht zumindest theoretisch die Möglichkeit, über die Rückverfolgung von IP-Adressen den Antwortenden zu ermitteln oder einzugrenzen. Dies wurde jedoch vertraglich und konfigurativ ausgeschlossen. Problematisiert wurde auch die Möglichkeit von (unerwünschten) Mehrfachbeantwortungen. Zwar ließe sich technisch relativ einfach sicherstellen, dass jede bzw. jeder Befragte einen Online-Fragebogen nur einmal ausfüllen kann, doch müssten dazu individuelle Kennzeichen (etwa Befragungsnummern) vergeben und den Befragten individuell, aber unter Wahrung der Anonymität zugestellt werden. Man entschied sich, an die Kooperationsbereitschaft zu appellieren und auf eine Authentisierung zu verzichten.

Was ist zu tun?
Personalbefragungen können sensible Informationen beinhalten, sodass Datenschutzmaßnahmen wie verlässliche Anonymisierung und geeignete Verträge mit Dienstleistern besonders wichtig sind.

 

Zurück zum vorherigen Kapitel

Zum Inhaltsverzeichnis

Zum nächsten Kapitel