Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein

6         Systemdatenschutz

6.1         Erforderlichkeit und Angemessenheit

Das LDSG fordert, dass bei der Verarbeitung personenbezogener Daten die erforderlichen und angemessenen Sicherheitsmaßnahmen getroffen werden müssen. Das ULD hat in vielen Projekten bei der Risikoanalyse, Beurteilung und Maßnahmenauswahl eine beratende Funktion.

Viele Daten verarbeitende Stellen haben Probleme, die Erforderlichkeit von tech­nischen und organisatorischen Maßnahmen nachvollziehbar herzuleiten und die Angemessenheit der getroffenen Maßnahmen zu beurteilen. Kaum ein Satz des Landesdatenschutzgesetzes (LDSG) formt die Datenverarbeitung so stark wie die Regelung zur Datensicherheit. Darin sind Anforderungen an die Datenverar­beitung gestellt, die sich in den aktuellen Sicherheitsstandards – wie der ISO 27000er-Normenwelt oder der Grundschutz-Vorgehensweise des Bundesamtes für Sicherheit in der Informationstechnik (BSI) – wiederfinden.

Erster Grundsatz ist die Erforderlich­keit. Technische und organisatorische Maßnahmen müssen einem konkret ausgewiesenen Risiko entgegenwirken. Daten verarbeitende Stellen müssen darlegen, warum eine konkrete Sicher­heitsmaßnahme getroffen wurde, und nachweisen, dass eine nachvollziehbare und belastbare Analyse der Risiken stattgefunden hat. Mit der Erforder­lichkeitsprüfung legen IT-Planer dar, dass sie Datenschutz, Datensicherheit und Wirtschaftlichkeit in Einklang gebracht haben: Es werden nur Sicher­heitsmaßnahmen für konkret benennbare Risiken getroffen, und es werden alle konkreten Risiken mit Sicherheitsmaßnahmen bedacht.

In der Praxis kommt diese entscheidende Planungsphase oft zu kurz. Häufig macht die Projektleitung den Fehler, eine Analyse der Risiken und eine Maßnah­menauswahl zu spät im Projekt durchzuführen. In vielen Fällen führt erst die drohende Vorabkontrolle durch behördliche Datenschutzbeauftragte oder durch das ULD dazu, dass die Projektleitung sich um die notwendigen Nachweise gemäß LDSG und Datenschutzverordnung (DSVO) kümmert. Unnötige finan­zielle und personelle Aufwände entstehen so im Projekt. Diese „nacheilenden“ Risikoanalysen führen in der Regel zu deutlichem Nachbesserungsbedarf und so zu unerwünschten Projektverzögerungen oder -verteuerungen. Die Risikoanalyse gehört an den Anfang eines Projekts. Nur hier können frühzeitig die notwen­digen Maßnahmen identifiziert werden.

In den Projekten finden sich häufig zwei unterschiedliche Ansätze zur Risikoanalyse. Der erste Ansatz fordert von allen Projektmitarbei­tern und den Auftraggebern eine Analyse. Häufig wird in einer oder mehreren Sitzungen eine gemein­same Risikosicht erarbeitet: Wel­che Risiken bestehen für die Datenverarbeitung? Welche Risi­ken sind tragbar, gegen welche Risiken muss etwas getan werden? Dieses Vorgehen betont sehr stark den Aspekt der Erforderlichkeit. Nur für identifizierte Risiken werden Maßnahmen getroffen. Dies führt in der Regel zu schlanken und wirtschaftlichen Sicherheitskonzepten. Es kann aber auch dazu führen, dass in der Analyse wesentliche Risiken nicht als solche identifiziert wurden. Die internationalen Standards der ISO 27000er-Reihe orientieren sich beispielsweise an diesem Ansatz.

Der zweite Ansatz zur Risikoanalyse orientiert sich am Vorgehen anderer ver­gleichbarer Organisationen. Arbeitet man in ähnlichen Ausgangssituationen mit ähnlichen Geräten und Programmen, so sind wahrscheinlich die Risiken und die zu treffenden Maßnahmen auch ähnlich. Der aufwendige Prozess der Risiko­analyse vorab kann abgekürzt werden. Man macht einfach das, was alle anderen in derselben Situation auch machen. Diese Vorgehensweise betont die Wirksam­keit. Die Wahrscheinlichkeit, dass bei diesem Ansatz wesentliche Risiken überse­hen werden, ist deutlich geringer. Gleichzeitig steigt jedoch die Wahrscheinlich­keit, dass man aufgrund einer fehlenden spezifischen Analyse auch unangemes­sene Maßnahmen umsetzt und deutliche personelle und finanzielle Mehraufwände in Kauf nimmt. Bei besonders schutzbedürftigen Daten oder in ungewöhnlichen Einsatzszenarien ist eine zusätzliche spezialisierte Risikoanalyse notwendig. Dieses Vorgehen findet man in seinen Grundzügen in der Grundschutz-Vorge­hensweise des BSI wieder.

Weiterer Prüfungspunkt ist die Angemessenheit. Für jede technische und organi­satorische Maßnahme muss die Wirksamkeit überprüft und nachgewiesen werden. In unseren Beratungsprojekten stehen wir gemeinsam mit den Daten verarbeiten­den Stellen immer wieder vor Sachverhalten, zu denen es bei Kontrollen heißt: „Eigentlich soll das aber funktionieren!“

Nur durch regelmäßige und anlassbezogene Kontrollen der Datenverarbeitung durch Datenschutz- und Sicherheitsbeauftragte kann festgestellt werden, ob die gewählten technischen und organisatorischen Maßnahmen wirken. Auch hierbei muss das Ziel einer Sicherheitsmaßnahme im Blick sein. Nur wenn die Sollvor­gabe benannt ist, kann die Zielerreichung geprüft werden. Erfolgreiche Organisa­tionen arbeiten nach dem Prinzip: „Für jede Maßnahme muss es eine messbare Kennzahl geben.“ Dieser an Kennzahlen orientierte Ansatz ist für Sicherheits­maßnahmen nützlich und führt zu einer deutlichen Vereinfachung der Kontrollen. Die Kontrollen werden automatisierbar. Durch die automatisierte Prüfung der Wirksamkeit vor allem von technischen Maßnahmen werden Datenschutz- und Sicherheitsbeauftragte von Routinetätigkeiten entlastet.

6.2         Der allmächtige anonyme Administrator

IT-Systeme bringen in aller Regel im Auslieferungszustand ein administrati­ves Standardbenutzerkonto mit, das mit umfassenden Berechtigungen aus­gestattet ist. Diese Annehmlichkeiten wissen nicht nur ehrliche Administra­toren zu schätzen, sondern auch diverse externe und interne Angreifer.

Mal heißt dieses Benutzerkonto „Administrator“, mal „root“, mal „admin“, mal so wie der Systemhersteller. Es verfügt oft über alle Berechtigungen im System, was für den Administrator das Arbeiten mit diesem Konto nicht nur bei der Erstkonfi­guration sehr angenehm gestaltet. Doch Vorsicht: Schadprogramme nehmen die Allmacht und Anonymität des administrativen Standardbenutzers ebenso gern in Anspruch wie manipulative Benutzer oder Cracker.

Für eine ordnungsgemäße Datenverarbeitung nach aktuellem Stand der Technik ist es zwingend notwendig, dass die administrativen Tätigkeiten nachvollziehbar sind. Das LDSG und die DSVO stellen hierfür konkrete Anforderungen. Bei jeder administrativen Tätigkeit muss stets der Ausführende ermittelt werden können.

Kommt es zu Fehlern, Störungen oder Sicherheitsproblemen in der Datenver­arbeitung, muss verlässlich nachprüfbar sein, wer oder was die Fehler oder Störungen verursacht oder ermöglicht hat. Dementsprechend ist das Arbeiten mit personalisierten Administrations­konten zum Schutz der personenbezo­genen Daten und gleichzeitig auch der Administratoren zwingend erforderlich. Das ULD fordert, dass im Tagesgeschäft mit personalisierten Benutzerkonten ohne administrative Rechte gearbeitet wird. Die administrativen Rechte sollen nur anlassbezogen und gezielt erteilt werden. Wir empfehlen personalisierte und aufgabenbezogene Administrationskonten, deren Rechteprofil restriktiv zusam­mengesetzt ist.

Sprechen gewichtige Gründe gegen die Nutzung personalisierter Administrations­konten, so ist die Verwendung eines anonymen Administrationskontos nur akzep­tabel, wenn andere Maßnahmen die Zuordnung zu einer Person ermöglichen. Als Beispiel können sich Administratoren häufig fallweise administrative Rechte über Befehle wie „sudo“ bei Unix-Systemen oder „Ausführen als …“ bei Windows-Systemen verschaffen. Die Nutzung dieser Funktionen muss nachvoll­ziehbar dokumentiert werden.

Das Anlegen eines lokalen anonymen Administrationskontos muss dadurch gerechtfertigt sein, dass Systeme im Notfall administrierbar sein müssen. Die Gründe und das Vorgehen zur Dokumentation sind in solchen Fällen jeweils schriftlich im Administrations- bzw. Sicherheitskonzept sowie in der Systemakte darzulegen.

Die Vorgaben für die Verwendung eines anonymen Administrationskon­tos sind:

• eine hinreichende Protokollierung und Kontrolle,
• kein direktes Log-in mit dem anonymen Administrationskonto,
• regelmäßiger Wechsel des Passwortes des anonymen Administrationskontos,
• das Verwenden eines komplexen und langen (mehr als 12stelligen) Passwortes sowie
• die restriktive Vergabe der „sudo“- bzw. „Ausführen als …“-Berechtigung.

 

Über eine Protokollierung muss feststellbar sein, wer zu welchem Zeitpunkt das anonyme Administrationskonto genutzt hat und welche Programme bzw. Tätig­keiten ausgeführt wurden. Nur unter dieser Maßgabe ist von einer pseudonymi­sierten Wahrnehmung der administrativen Rechte auszugehen, da die admi­nistrativen Tätigkeiten im Nachgang dem personalisierten Benutzerkonto des Administrators zugeordnet werden können. Grundsätzlich darf nach der Grund­konfiguration eines Systems das direkte Anmelden mit einem anonymen Stan­dardadministrationskonto nicht mehr möglich sein. Dies ist durch das Löschen oder das Deaktivieren der anonymen Standardkonten möglich oder indem diesen Konten die administrativen Berechtigungen entzogen werden.

6.3         AAL − altersgerechte Assistenzsysteme

„Ambient Assisted Living“ soll Menschen im alltäglichen Leben eine situa­tionsabhängige und unaufdringliche Unterstützung ermöglichen, wobei über Sensoren Personendaten automatisiert erfasst und ausgewertet werden, die oft zum besonders geschützten privaten Kernbereich des Menschen zählen.

Die Ausgestaltung des AAL hängt vom Unterstützungsbedarf der jeweiligen Nutzergruppe ab. Bei jüngeren, gesunden Menschen stehen Unterhaltung und Lifestyle-Funktionen zur Steigerung der Lebensqualität im Vordergrund. Bei alten und insbesondere hilfebedürftigen Menschen geht es darum, diesen ein sicheres, selbstständiges Leben im häuslichen Umfeld zu ermöglichen bzw. die Möglich­keit einer häuslichen Pflege zu verlängern.

Das ULD hat auf Initiative des Bundesministeriums für Bildung und Forschung (BMBF) eine Vorstudie zu den „Juristischen Fragen im Bereich altersgerechter Assistenzsysteme“ erstellt, deren Ziel es ist, im Kontext von 18 anwendungs­orientierten Verbundprojekten die Technologie- und Anwendungsentwicklung beim AAL zu unterstützen. Neben dem Entwickeln wünschenswerter Lösungen sollten unerwünschte Wirkungen, etwa im Bereich des Datenschutzes, frühzeitig erkannt und vermieden werden.

In den technisch orientierten Partnerprojekten wurden Techniken für altersgerecht ausgestaltete Serviceleistungen entwickelt. Typische Teile dieser Serviceleistun­gen im Rahmen von AAL-Systemen zum Einsatz in Wohnungen oder Zimmern von Pflegeeinrichtungen sind Bewegungssensoren, Sturzmelder, Füllstandmelder (z. B. Aquastop-Systeme), die Überwachung von Vitaldaten zu Atmung, Puls, Körpertemperatur, Blutdruck, Gewicht, Blutzucker, telemedizinische Dienste, Abschaltsysteme etwa für Herd oder Licht, elektronisches Schließen und Öffnen von Fenstern und Türen, Notrufsysteme in Koppelung mit Dienstleistungen, Telefone oder Videoüberwachung in jedem Raum.

In einem geförderten Projekt wurde eine Plattform entwickelt, über die AAL-gestützte Betreuungsdienstleistungen zusammengestellt und beauftragt werden können. In einem anderen Projekt wurden Sensoren konzipiert, die anhand der Nutzung von Licht, Strom, Gas und Wasser, der Dusche und des Fernsehens schleichende Veränderungen des Gesundheitszustands und Notfälle, z. B. Stürze, erfassen sollen. Ein System erfasst mit u. a. im Bett installierten Sensoren konti­nuierlich den Gesundheitszustand der Betroffenen. Die jeweils erzeugten Daten werden von einem Rechnersystem zusammengefasst und interpretiert. Über das Internet werden aktuelle Lageberichte dann an einen Notruf und an ein Sicher­heitssystem weitergeleitet, das Angehörige, Pflegedienste, Hausärzte und Klini­ken einbezieht. In einem weiteren Projekt werden Techniken zur Überwachung sportlicher Betätigungen von Personen entwickelt. Die wesentliche Funktion all dieser AAL-Systeme besteht darin, ein „Normalitätsprofil“ für eine Person zu entwickeln, um daran gemessen Unregelmäßigkeiten festzustellen und adäquat zu reagieren. In Notfällen sollen Tonwarnungen für den Betroffenen ausgegeben oder eine Nachbarin, ein Verwandter oder ein professioneller Warndienst infor­miert werden. Diese können dann bei der Person anrufen, eine Videoverbindung aufbauen, eine Hilfsperson vor Ort beauftragen nachzuschauen oder einen Kran­kenwagen anfordern.

AAL-Systeme dienen, so das Konzept der meisten Projekte, der kostengünstigen Betreuung von hilfebedürftigen Menschen. Häufig sollen die Möglichkeiten einer häuslichen Pflege technisch verlängert werden, was zumeist im Interesse sowohl der meisten Pflegebedürftigen als auch der Kostenträger liegt. AAL-Systeme können die Autonomie körperlich eingeschränkter Menschen länger als bislang aufrechterhalten. Die Menschen sollen wählen können, wo sie sich aufhalten bzw. wohin sie sich begeben wollen. Dies ist ein wesentlicher Aspekt individueller Selbstbestimmung. Durch Nutzung von Technik soll die informationelle, kör­perliche und soziale Autonomie von Menschen länger erhalten bleiben.

Dies erfolgt zu dem Preis, dass sie einer technisierten Kontrolle ihrer körperlichen Verfassung und ihres Verhaltens unterworfen werden. Selbstbestimmung ist aber nur dann wirklich gewährleistet, wenn die Betroffenen mitbestimmen können, wie die Informationsverarbeitung der AAL-Dienstleister stattfindet. Der Konflikt zwischen zunehmender Freiheit und zugleich zunehmender Abhängigkeit durch Technik ist typisch für die arbeitsteilige Informationsgesellschaft. Er kann nur aufgelöst werden, wenn die Organisationen, die ihre Dienstleistungen der Pflege, der medizinischen Versorgung, der Beobachtung oder der Leistungsdokumenta­tion technikunterstützt erbringen, ihre oft komplizierten technischen Systeme selbst beherrschen und sich zugleich einer externen Kontrolle unterwerfen. Die Abhängigkeit von der Technik darf nicht zu einer Abhängigkeit von den die Technik einsetzenden Organisationen führen, die eine hohe Gestaltungsmacht über den Alltag von Menschen innehaben.

Haben Menschen mit der Veralltäglichung von AAL tatsächlich die Wahl, die Techniken selbstbestimmt und würdig zu nutzen? Wird es möglich sein, nach einer Zeit der Nutzung von AAL-Techniken der weiteren Nutzung zu widerspre­chen? Wird am Ende der voll vermessene Mensch stehen, dessen privaten Eigen­schaften und Handlungen erforscht und zu einem Profil des Normalmenschen zusammengestellt sind? Tatsächlich besteht die Tendenz, Abweichungen von diesem Normalprofil zu erfassen. Werden die Betroffenen gegenüber ihren Versicherungen Rechenschaft für ihr Verhalten ablegen müssen? Freiheit und Selbstbestimmung bedeutet, dass man nicht dem standardisierten Normalmaß entsprechen und sich für Abweichungen rechtfertigen muss.

Die Studie zeigt die Grenzen eines Datenschutzes auf, der sich stark auf die frei­willige und informierte Einwilligung der Betroffenen stützt. Die Herausforde­rung liegt darin, den Anforderungen des Datenschutzes nicht über das Erteilen von Unmengen an rein formell bleibender Einwilligungen formal zu genügen, sondern materiell wirksam operativ zu sichern. Einwilligungen, so das Daten­schutzrecht, müssen inhaltlich klar, freiwillig und informiert erfolgen. Doch gerade die von den Entwicklern der AAL-Systeme vorgesehene Klientel verfügt typischerweise über kein Wissen von komplexen informationstechnischen Syste­men. Es ist deshalb eine wichtige Aufgabe beim Aufbau von AAL-Infrastruk­turen, ein betroffenengerechtes Niveau an Transparenz und Wahlmöglichkeit herzustellen.

Ein Teil der Lösung des Problems besteht darin, Datenschutz in die Systeme von Anfang an einzubauen. Die AAL-Systeme müssen so funktionieren, dass sie, dem Paradigma der Privacy-Enhancing Technologies (PET) folgend, den grundrecht­lich garantierten Datenschutz der Menschen unterstützen. Zudem sind die Herstel­ler und Betreiber der Systeme aufgefordert, Transparenz in hochauflösender professioneller Qualität insbesondere für Prüfinstanzen bereitzustellen.

In der Vorstudie wurde ein Modell entwickelt, mit dem die Datenschutzproble­matik des AAL übersichtlich erfasst werden kann. In einer Matrix mit drei Dimensionen werden Daten, Akteure sowie – in die Form von Schutzzielen des Datenschutzes gebracht – die technischen und organisatorischen Anforderungen an die Verarbeitung der Daten bzw. Systeme durch die Akteure bzw. Prozesse erfasst.

Schon beim Ausfüllen dieser Matrix wird klar, welche gesellschaftliche Gestal­tungsaufgabe vor Datenschützern, aber auch vor den Anbietern und Nutzern von AAL-Systemen liegt. Hersteller und Betreiber von AAL-Anwendungen müssen immer wieder daran erinnert werden, dass die „Unantastbarkeit der Würde des Menschen“ mehr als eine ethische Forderung ist und gesetzlich zwingende prakti­sche Konsequenzen hat.

6.4         Tests und Fehlerbehebung mit Echtdaten

Die steigende Komplexität vernetzter Rechnersysteme führt zu komplexeren Fehlerszenarien. In Einzelfällen können Fehler laut Aussagen der Hersteller nur mit Echtdaten nachvollzogen werden. Der Schutz der personenbezoge­nen Daten muss hierbei sichergestellt bleiben.

Mit der Vielschichtigkeit der einge­setzten Software in Unternehmen und Verwaltungen steigt auch die Komple­xität und Vielzahl der möglichen Feh­lerbilder. Oft sind es nicht mehr die offensichtlichen, sondern individuelle und schwer nachzustellende Fehler, die Anwender und Hersteller beschäf­tigen. Solche Fehler sind besonders schwer zu vermitteln – sowohl nach innen als auch nach außen.

Muss die Nutzung der Software bis auf Weiteres komplett eingestellt werden oder nur für ganz bestimmte Aktionen? War es ein Bedienungsfehler oder ist die Software fehlerhaft? Welche Tätig­keiten sind genau zum Zeitpunkt des Fehlers, davor und danach durchge­führt worden und von wem? Diese Analysen erfordern von der Daten ver­arbeitenden Stelle wie vom Software­hersteller ein hohes Maß an exakter Dokumentation, effizienter Kommu­nikation und Kenntnis der Software. Trotz solcher Bemühungen ist es nicht immer gegeben, dass der Fehler zügig gefunden und behoben werden kann. In der Praxis können äußerst individuelle Sachverhalte auftreten. Hierfür existiert nicht immer ein passender Testdaten­satz beim Hersteller. Der Fehler kann dann kaum mit vertretbarem Aufwand nachgestellt werden. Als Ausweg wird dann häufig die Übermittlung der Echt­daten an den Softwarehersteller geprüft, um die mitunter kostspielige Anreise eines Entwicklers zur Vorortanalyse zu vermeiden. Das ULD bearbeitet viele Anfragen zu diesem Themenbereich. Häufig handelt es sich um größere Projekte wie neue kommunale Kassenverfahren oder das Zusammenführen von Daten nach einer Verwaltungsfusion. Unter welchen Bedingungen ist eine solche Datenüber­mittlung und Datenverarbeitung beim Softwarehersteller zulässig?

Zunächst ist zu prüfen, ob eine Auftragsdatenverarbeitung – etwa im besonders sensiblen Bereich der Gesundheits- und Sozialdaten – überhaupt zulässig ist. Ist diese möglich, so sind explizite vertragliche Regelungen zu treffen, die die Anforderungen zur Auftragsdatenverarbeitung auf Systemen des Software­herstellers oder zur Fernwartung auf organisationseigenen Systemen erfüllen. Das LDSG fordert konkrete schriftliche Vorgaben und Aufträge, insbesondere zu technischen und organisatorischen Sicherheitsmaßnahmen. Gemäß der DSVO muss die Daten verarbeitende Stelle – also der Auftraggeber – die beim Auftrag­nehmer getroffenen technischen und organisatorischen Sicherheitsmaßnahmen dokumentieren.

Wird die Fehleranalyse im Produktivsystem durchgeführt, so sind strikte Rege­lungen zur Fernwartung zu treffen. Das ULD forderte regelmäßig eine Vollpro­tokollierung aller Tätigkeiten der externen Dienstleister, verbunden mit einer regelmäßigen Auswertung unter Beteiligung des oder der behördlichen Daten­schutzbeauftragten.

Wird die Fehleranalyse mit Echtdaten in einer vom Hersteller bereitgestellten Umgebung durchgeführt, so ist auf eine strikte Trennung der verwendeten Systeme zu Systemen anderer Kunden zu achten. Der Hersteller muss ange­messene Sicherheitsmaßnahmen zur Kontrolle des Zugriffs, zur Durchsetzung der Datentrennung und zur Dokumentation der Sicherheitsmaßnahmen umsetzen.

Die Angemessenheit und Wirksamkeit dieser vertraglich vereinbarten Maßnah­men sind durch Kontrollen vorab, während und nach jeder Datenverarbeitung durch die verantwortliche Stelle zu überprüfen. Ist eine Software so anfällig und komplex, dass Fehler nur mit möglichst realistischen und großen Datenvolumen rekonstruiert werden können, empfiehlt sich dringend das Erstellen und Pflegen eines anonymisierten Testdatenbestandes auf Basis der Echtdaten beim Auftrag­nehmer.

6.5         Data Warehouses  in der öffentlichen Verwaltung

Die Grundsätze der Zweckbindung und der Datensparsamkeit verbieten den Einsatz von Data Warehouses in der öffentlichen Verwaltung in aller Regel. In Ausnahmefällen sind sie jedoch datenschutzkonform möglich, wenn die Prozesse zur Datenauswertung unter dauerhafter Kontrolle des behördlichen Datenschutzbeauftragten stehen.

In Data Warehouses werden Daten unterschiedlicher Quellsysteme zusammen­geführt. Kopien der Daten werden üblicherweise in einem separaten Datenbank­system vorgehalten und dort ausgewertet. Data Warehouses dienen dann als Aus­gangsbasis für das Data Mining, also für das „Schürfen“ von Informationen. Ziel ist es, bisher unerkannte Zusammenhänge in großen Datenmengen zu finden.

In der öffentlichen Verwaltung stoßen Data Warehouses mit personenbezogenen Daten an die engen Grenzen der Zweckbindung. Personenbezogene Daten, die zu einem bestimmten Zweck erhoben wurden, dürfen nicht der wahlfreien Aus­wertung zu anderen Zwecken zur Verfügung stehen.

Sollen personenbezogene Daten in einem Data Warehouse verarbeitet werden, so ist jede Auswertung vorab auf die Einhaltung der Zweckbindung zu prüfen. Eine wahlfreie Auswertung ist mit den Vorgaben des LDSG nicht vereinbar. Jede Auswertung muss vorher durch den oder die behördliche Datenschutzbeauftragte kontrolliert und durch die Leitung der Daten verarbeitenden Stelle freigegeben werden. Die Kontrollen und Freigaben sind zu dokumentieren.

Dies stellt hohe Anforderungen sowohl an die behördlichen Datenschutzbeauf­tragten als auch an die Dienststellenleitung. Bei der Einführung eines Data Ware­house ist deshalb bereits zu Beginn des Projektes auf eine intensive Vorbereitung, Unterrichtung und Schulung der behördlichen Datenschutzbeauftragten und der Leitung zu achten. Der Betrieb eines Data Warehouse ohne einen behördli­chen Datenschutzbeauftragten mit spezieller Weiterbildung ist nicht datenschutz­konform.

Das ULD empfiehlt, zusätzlich die Rolle eines Data Warehouse Controllers einzuführen, der die notwendigen Kontroll- und Freigabeprozesse koordiniert und revisionssicher dokumentiert. Jede Anforderung einer Auswertung muss durch den Data Warehouse Controller in einen konkreten Auftrag überführt werden. Der Auftrag zur Auswertung muss geprüft und freigegeben werden. Liegen die Ergeb­nisse der Auswertung vor, so sind diese wiederum zumindest auf die Vereinbar­keit mit den datenschutzrechtlichen Vorgaben zu prüfen, bevor sie an die anfor­dernde Organisationseinheit weitergegeben werden. Nur durch enge Einbeziehung der behördlichen Datenschutzbeauftragten und stetige Befassung der Leitung der Daten verarbeitenden Stelle kann das Risiko des permanenten Rechtsverstoßes angemessen behandelt werden.

Noch stehen Data Warehouses in der öffentlichen Verwaltung in Schleswig-Holstein am Anfang ihrer Entwicklung. Das ULD erhält aber zunehmend Anfra­gen. In einem erfolgreichen Beratungsprojekt mit der Landespolizei (Tz. 4.2.2) wurden gemeinsam erste Grundsätze für den Einsatz eines Data Warehouse fest­gelegt.

6.6         Ergebnisse aus Überprüfungen und Kontrollen  vor Ort

6.6.1      Kooperative Regionalleitstelle Nord in Harrislee

Das ULD prüfte in Zusammenarbeit mit dem Innenministerium die Koope­rative Regionalleitstelle in Harrislee und stellte teilweise erhebliche Mängel fest. Deren Behebung wird vom Innenministerium begleitet.

Es ist eher ungewöhnlich, dass eine Daten verarbeitende Stelle um eine daten­schutzrechtliche und sicherheitstechnische Prüfung bittet. Das Innenministerium ist diesen ungewöhnlichen Weg gegangen, um eine zusätzliche Kontrolle der sicherheitstechnischen Absicherung und der Datenschutzaspekte in der Leitstelle durchzuführen. Die Kooperative Regionalleitstelle (KLRS) Nord ist eine gemein­same Einrichtung der Landespolizei und der Kreise Nordfriesland und Schles­wig-Flensburg sowie der Stadt Flensburg. Darin wurden die polizeilichen und nicht polizeilichen Leitstellen zusammengefasst. Polizeiliche und nicht polizeili­che Aufgaben werden bei gemeinsamer Nutzung der baulichen und technischen Einrichtungen organisatorisch getrennt wahrgenommen. Beide Bereiche werden jeweils eigenständig von einem Leiter geführt.

Die in der Prüfung erkannten Mängel wurden bereits während der Prüfungen vor Ort bewertet, mögliche Maßnahmen zur Mängelbehebung wurden besprochen und in einigen Fällen wurde die Behebung sofort gestartet. Andere Mängel mussten mit den Herstellern der Leitstellensysteme, der Betriebsmannschaft vor Ort und im Landespolizeiamt im Nachgang bewertet und in einen Plan zur Mängelbehe­bung aufgenommen werden. Die Prüfung zeigte, dass eine unabhängige Kontrolle bei Großprojekten wie der Kooperativen Leitstelle ein wichtiger Baustein der Qualitätssicherung sein kann. Die Kontrollergebnisse von Harrislee werden in die vereinbarten Prüfungen der übrigen Kooperativen Leitstellen in Schleswig-Holstein einfließen.

6.6.2      Prüfung  beim Wasser- und Bodenverband Ostholstein

Eine Software, die das „private Surfen im Internet“ verhindern soll, bietet gleichzeitig die Möglichkeit, automatisch zu protokollieren, welche Program­me wie lang auf den PCs von Mitarbeitern laufen.

Findet eine automatisierte verdeckte Überwachung der Mitarbeiter-PCs statt? In einer Petenteneingabe wurde eine auf den Arbeitsplatz-PCs beim Wasser- und Bodenverband Ostholstein installierte Software beschrieben, die auch eine Proto­kollierung der Tätigkeiten auf dem PC des jeweiligen Mitarbeiters aufzeichnet. Die Verwaltungsleitung hatte einen externen Dienstleister mit einer Lösung beauftragt, die das „private Surfen im Internet“ der Mitarbeiter unterbindet. Der Dienstleister installierte eine Software, die weit mehr als das Sperren von Inter­netseiten ermöglichte. So konnte eine automatische Protokollierung aller Aktivi­täten auf dem Arbeitsplatzrechner aktiviert werden. Bedingt durch Probleme mit einem Buchhaltungsprogramm wurde die Software wieder deinstalliert. Eine Durchsicht der Arbeitsplatz-PCs bestätigte dies. Um sich nicht dem Verdacht der unzulässigen automatisierten Leistungs- und Verhaltenskontrolle auszusetzen, will der Verband eine organisatorische Regelung schaffen, die die private Nutzung des Internets verbietet. Von der vorübergehenden Kontrolle erfasst wurden

• die installierte Programmliste,
• die Programmverzeichnisse im Windows Explorer,
• die Systemsteuerung und
• die Windows Registry.

6.6.3      Prüfung  im Amt Horst-Herzhorn

Eine gute Wahl!

Im Rahmen der Verwaltungsstrukturreform fusionierten Anfang 2008 die Ämter Herzhorn sowie Horst und erhielten den Namen „Amt Horst-Herzhorn“. Trotz der personellen und organisatorischen Problemstellungen wurde der Datenschutz nicht außer Acht gelassen. Die Leitungsebene zeigte mit der Besetzung der Administratorenstelle Weitblick und bewies, dass es sich lohnt, die Aufgaben der IT eine engagierte Mitarbeiterin durchführen zu lassen.

Unsere Überprüfung zeigte den hohen Stellenwert des Datenschutzes in dieser Verwaltung. Die in dem Datenschutzkonzept dokumentierten Sicherheitsmaß­nahmen werden wirksam umgesetzt. Dank effektivem IT-Management und über­durchschnittlich guter Systemdokumentation wird auch bei Krankheit oder Urlaub der Administratorin die Verwaltung der IT-Umgebung durch andere explizit berechtigte Personen gewährleistet. Die durch das LDSG und DSVO geforderte Dokumentation hebt die Verwaltung deutlich vom Durchschnitt der im Land vor­gefundenen Gegebenheiten ab. Es wurden keine Mängel festgestellt – ein seltener, erfreulicher Befund!

6.6.4      Prüfung  bei der KLG Heider Umland

Die datenschutzrechtliche Überprüfung der Kirchspielslandgemeinde Heider Umland führte zu einer äußerst hohen Anzahl von Beanstandungen.

Bei einer routinemäßigen Überprüfung des Amtes Kirchspielslandgemeinde Heider Umland fanden wir eine Vielfalt datenschutzrechtlicher Mängel vor. Folgende Punkte führten zur Beanstandung:

• Es wurde keine Stellvertretung für den Administrator ausgebildet.
• Der Administrator protokolliert seine administrativen Tätigkeiten nicht.
• Es erfolgt keine Kontrolle der Tätigkeiten des Administrators durch die Ver­waltungsleitung.
• Es existieren keine vertraglichen Regelungen mit dem externen Dienstleister.
• Es wurde keine Verfahrensdokumentation erstellt.
• Ebenso fehlen die Dokumentationen der Sicherheitsmaßnahmen, der Tests und der Freigaben.
• Es wurden keine Arbeitsanweisungen (IT-Dienstanweisungen) für die Admi­nistration erstellt.
• Auf den zentralen Druckern, die auch für Unbefugte jederzeit erreichbar sind, wurden keine zusätzlichen Sicherheitsmaßnahmen getroffen.
• Auf den Notebooks war keine Verschlüsselungssoftware installiert.
• Die Aktenvernichtungscontainer waren nicht verschlossen und für Unbefugte leicht erreichbar.
• Die Archivräume wurden unverschlossen vorgefunden.

6.6.5      Nachprüfung  bei der Stadtverwaltung Ratzeburg

Das ULD schließt Prüfungen erst ab, wenn alle erkannten Mängel nachvoll­ziehbar behoben wurden. Die Mängelbehebung wurde in der Stadtverwal­tung Ratzeburg durch eine Nachkontrolle begleitet.

In der Stadtverwaltung Ratzeburg erfolgte im November 2008 eine stichproben­artige Überprüfung der technischen und organisatorischen Sicherheitsmaßnah­men. Ihr Ziel war es, zusammen mit den Mitarbeitern in der automatisierten Datenverarbeitung eventuelle Schwachstellen zu erkennen. Die Erörterung der festgestellten Sachverhalte mit den Mitarbeitern und Verantwortlichen sollte dazu führen, dass sie die Notwendigkeit organisatorischer und technischer Sicherheits­maßnahmen erkennen und diese zukünftig in die Organisation und Administration der automatisierten Datenverarbeitung einfließen lassen.

Die Stadtverwaltung erkannte im April 2009 unsere Beanstandungen sowie die Vorschläge zur Behebung der Mängel an. Verschiedene Maßnahmen seien schon umgesetzt. Die umfassende Darstellung aller Handlungen wurde für Mitte Mai angekündigt. Erst Ende Juli erhielten wir einen Bericht über die „Durchfüh­rung von Maßnahmen zur Beseitigung von Mängeln/Beanstandungen“, in dem erläutert wurde, dass der Dokumentationspflicht gemäß LDSG und DSVO nach­gekommen wurde, die notwendigen Regelungen jedoch aufgrund von personellen und organisatorischen Umstrukturierungsmaßnahmen noch nicht in Kraft gesetzt werden konnten. Dies sei für Ende September 2009 vorgesehen.

Die Nachprüfung sollte nun zeigen, ob die Mängelbehebung erfolgreich war. Wir stellten fest, dass immer noch nicht alle dokumentierten Regeln in Kraft gesetzt waren. Sie waren zwar mit Stand April 2009 aktualisiert, von der Verwaltungsleitung aber noch nicht unterschrieben. Der Bürgermeister gab dafür personelle und organisatorische Gründe an. Die endgültige Fertigstellung war für Ende 2010 vorgesehen. Das ULD wird die Umsetzung zeitnah abschließend prüfen. Wir hatten ferner festgestellt, dass eine Stellvertretung für den Admi­nistrator nicht mehr vorhanden war. Die Verwaltungsleitung berichtete uns von Überlegungen, administrative Aufgaben den Fachbereichen zu übertragen. Dies wurde bis zum Zeitpunkt der Prüfung jedoch nicht durchgeführt. Somit obliegt einer Person die Administration der hochkomplexen IT der Stadtverwaltung. Ein unzumutbarer Zustand, den das ULD mit Nachdruck beanstandete. Wir boten weiterhin unsere Beratung an.

Zurück zum vorherigen Kapitel

Zum Inhaltsverzeichnis

Zum nächsten Kapitel