-> Home -> Der LfD -> Tätigkeitsberichte -> 2009
 
  Aufgaben und Befugnisse des Landesbeauftragten
Kontakt
  Pressemitteilungen
Tätigkeitsberichte
Entschließungen der Konferenz der Datenschutzbeauftragten des Bundes und der Länder
 

29. Tätigkeitsbericht 2009 - Inhaltsverzeichnis

 

29. Tätigkeitsbericht 2009 - 7. Teil

7. Teil: Informations- und Kommunikationstechnik (IuK)

1. Der datenschutzrechtliche "GAU"

2. Das Verfahrensverzeichnis nach § 11 LDSG
2.1 Grundlegende Anforderungen
2.2 Datenabgleich von Personaldaten durch Rechnungsprüfungsämter - Mängel auch bei den Verfahrensverzeichnissen

3. Datenschutz bedeutet auch, Verantwortung zu übernehmen

4. EDV in der Praxis: Probleme bei Datei-Zugriffsberechtigungsstrukturen und die Tücken gekaufter Software

5. Orientierungshilfen zu Datenschutzfragen des Anschlusses von Netzen der öffentlichen Verwaltung an das Internet

6. Polizeiliche Datenverarbeitung
6.1 Die polizeiliche Vorgangsbearbeitung ComVor
6.2 Der NATO-Gipfel

7. Kontrolle eines Personalrats

8. Die Neuregelung der informationstechnischen Zusammenarbeit zwischen Bund und Ländern - wo bleibt der Datenschutz?


1. Der datenschutzrechtliche „GAU“

Es wäre schon schlimm genug, wenn man seinen USB-Stick in der Straßenbahn liegen lässt. Wenn eine Kommune aber eine umfangreiche Datensicherung „verliert“, ist das kaum zu übertreffen.

Bereits kurz nach meinem Amtsantritt musste ich die betrübliche Bekanntschaft mit einem „größten anzunehmenden Unfall“ (GAU) im Datenschutz machen: Im April 2009 erreichte uns der Anruf eines Mitarbeiters einer auf Sicherheit in der EDV spezialisierten Unternehmensberatung aus Nordrhein-Westfalen, wonach dort ein Rechner mit der auf den Festplatten gespeicherten Datensicherung einer Stadt aus dem Kraichgau aufgetaucht sei. Seiner Ansicht nach seien das brisante Daten. Da er nächste Woche ohnehin in Stuttgart zu tun habe, wolle er mich aufsuchen und mir eine Kopie der Datensicherung überlassen. Bei der Durchsicht durch meine Mitarbeiter stellte sich heraus, dass die Datensicherung im März 2007 angefertigt worden war. Sie umfasste ca. 180 GByte Daten in über 400 000 Dateien. Die Dateien stammten von einem Datei-Server, den Datenbanken eines sog. Exchange-Servers, aus fachspezifischen Anwendungen und von einem Rechner der städtischen Bibliothek. Der Rechner selbst war offenbar im Zuge einer Verwertung von gebrauchten Computern zu der Beratungsfirma gelangt.

In mehreren Anläufen versuchten meine Mitarbeiter bei der Stadt eine fundierte Stellungnahme einzuholen, wobei sie den Ernst der Lage durch beispielhafte Ausdrucke von Dokumenten - darunter „zur Illustration“ auch private Korrespondenz des Bürgermeisters selbst - untermauerten. Das vorläufige Ergebnis der Recherchen sieht so aus, dass die Stadt seinerzeit die Beschaffung eines neuen Serversystems geplant hatte. Vor dem Kauf wollte sie prüfen, ob der neue Rechner die erforderliche Leistung aufweist. Dazu ließ sie den neuen Rechner, auf dem sie Leistungstests durchführen wollte, testweise bei sich aufstellen. Zu Zwecken der Leistungsbeurteilung wurden auf dem neuen Server personenbezogene Echtdaten - vermutlich des alten Serversystems - gespeichert. Die Leistungstests verliefen nicht wie erhofft, die Stadt ließ den neuen Rechner von einem Unternehmen im Auftrag abbauen und gab ihn an den Hersteller zurück. Dabei unterblieb die Löschung der auf dem neuen Rechner gespeicherten personenbezogenen Daten. Auf diese Weise hatte die Stadt es quasi jedermann, der Zugang zu dem vorübergehend eingesetzten Server hatte, ermöglicht, auf personenbezogene Daten der Bürger der Stadt zuzugreifen. Nur dem umsichtigen Vorgehen der Mitarbeiter des eingangs erwähnten EDV-Beratungsunternehmens ist es zu verdanken, dass sich der Schaden in Grenzen hielt. Solch ein Glück war im Berichtszeitraum nicht allen vergönnt.

Mit ihrer Vorgehensweise hat die Stadt folgende datenschutzrechtliche Verstöße begangen:

  • Sie hat für Tests von Hard- und/oder Software echte personenbezogene Daten genutzt, obwohl § 9 Abs. 1 LDSG klar regelt, dass bei derartigen Systemtests keine oder so wenige personenbezogene Daten wie möglich herangezogen werden dürfen. Da es für Zwecke der Leistungsmessung und -bewertung zuverlässige Verfahren gibt, bei denen keine personenbezogenen Daten verarbeitet werden müssen, war die geschilderte Vorgehensweise nicht erforderlich.
  • Nach § 9 Abs. 3 Nr. 3 LDSG muss derjenige, der personenbezogene Daten verarbeitet, Maßnahmen ergreifen, die geeignet sind, die unbefugte Eingabe in den Speicher sowie die unbefugte Kenntnisnahme, Veränderung oder Löschung gespeicherter Daten zu verhindern. Ein probates Mittel hierfür wäre im vorliegenden Fall natürlich gewesen, die Daten auf dem Rechner vor dessen Rückgabe zu löschen. Für die datenschutzrechtliche Beurteilung ist dabei unerheblich, ob die Stadt oder das seinerzeit beauftragte Unternehmen als Auftragnehmer die Daten hätte löschen müssen.
  • Ob und in welchem Umfang die Stadt ein externes Unternehmen mit der Verarbeitung ihrer Daten beauftragt hatte, blieb zunächst offen. Erforderlich wäre jedenfalls ein präziser schriftlicher Vertrag und eine wirksame Kontrolle durch die Stadt als Auftraggeber gewesen.

Im Ergebnis trägt die Stadt die datenschutzrechtliche Letztverantwortung. Angesichts der Schwere des Verstoßes bedurfte es keiner langen Abwägung. Für öffentliche Stellen, die so leichtsinnig mit den personenbezogenen Daten ihrer Bürger umgehen, sieht das Landesdatenschutzgesetz die (förmliche) Beanstandung nach § 30 vor. Dass der Datenschutzverstoß nicht böswillig erfolgte, ändert daran nichts.

Einen Tag vor Fertigstellung dieses Tätigkeitsberichts erreichte mich die von mir gemäß § 30 Abs. 4 LDSG eingeforderte Stellungnahme der Stadt. Darin räumt sie ein, dass man das System beschaffen wollte, um damit Datensicherungen anzufertigen. Wie von mir befürchtet, hatte die Stadt keinen schriftlichen Vertrag zur Datenverarbeitung im Auftrag gemäß § 7 LDSG mit den beauftragten Unternehmen geschlossen; vielmehr berief sie sich auf eine mündliche Zusicherung, dass das System nach der Rückgabe neu formatiert und konfiguriert werde. Die Stadt selbst habe ein neues Betriebssystem über das alte System installiert. Dabei wurden die Festplatten jedoch nicht neu formatiert, so dass alle nicht zum Betriebssystem gehörenden Dateien vollständig erhalten blieben.

Immerhin will die Stadt nun endlich die Konsequenzen aus dem Vorfall ziehen und ein Sicherheitshandbuch erstellen sowie Richtlinien für die Handhabung von mobilen Datenträgern und das sichere Löschen von magnetischen Datenträgern erlassen. Dazu will man sich vom Datenschutzbeauftragten des zuständigen Kommunalen Rechenzentrums beraten lassen bzw. mit diesem eng zusammenarbeiten.

Es ist zu begrüßen, dass die Stadt den leichtfertigen Umgang mit personen-bezogenen Daten abstellen will. Ob eine punktuelle Beratung durch den Datenschutzbeauftragten des Kommunalen Rechenzentrums ausreicht, bleibt abzuwarten. Besser wäre es, wenn die Stadt einen eigenen behördlichen Datenschutzbeauftragten gemäß § 10 LDSG bestellt.

 

2. Das Verfahrensverzeichnis nach § 11 LDSG

2.1 Grundlegende Anforderungen

Nach § 11 LDSG hat jede öffentliche Stelle - oder eine von ihr beauftragte Stelle - ein Verzeichnis der automatisierten Verfahren, mit denen bei ihr personenbezogene Daten verarbeitet werden, zu führen. Daraus müssen die wesentlichen Strukturen des Verfahrens und die Rechtsgrundlage hervorgehen. In der Praxis stoße ich oft auf Unkenntnis oder Gleichgültigkeit hinsichtlich dieser Rechtspflicht.

Bei meiner Beratungs- und Kontrolltätigkeit muss ich leider immer wieder feststellen, dass die nach § 11 LDSG gesetzlich vorgeschriebenen Verfahrensverzeichnisse entweder überhaupt nicht oder nur in mangelhafter Weise vorhanden sind. Oftmals ist zudem unbekannt, was Verfahrensverzeichnisse eigentlich sind und dass sie unter bestimmten Umständen meinem Amt vorgelegt werden müssen. Ich möchte daher einige Erläuterungen und Hinweise zu diesem Thema geben.

  • Was ist der Zweck eines Verfahrensverzeichnisses?
    Schon während der Einführung eines automatisierten Verfahrens - dies geschieht oftmals in Form eines Projektes - muss sich die verantwortliche Stelle Gedanken zum Thema Datenschutz machen. In diesem Zusammenhang ist sowohl die Rechtmäßigkeit der Datenverarbeitung zu prüfen als auch ein Datenschutz- und Sicherheitskonzept zu erstellen, aus dem die zu ergreifenden technischen und organisatorischen Maßnahmen abgeleitet werden können. In einem Verfahrensverzeichnis werden nun alle für eine datenschutzrechtliche Prüfung erforderlichen Informationen zusammengestellt: Die Daten verarbeitende Stelle muss z. B. dokumentieren, welche personenbezogenen Daten sie mit Hilfe welcher automatisierter Verfahren auf welche Weise verarbeitet und welche technischen und organisatorischen Datenschutzmaßnahmen sie dabei getroffen hat. Hierdurch kann sie einen Überblick über ihre Datenverarbeitung behalten. Das Verfahrensverzeichnis, dessen Struktur im Grunde durch den in § 11 Abs. 2 LDSG genannten Katalog vom Gesetzgeber vorgegeben wurde, ist somit unverzichtbar für eine effektive Eigenkontrolle, um zunächst für sich selbst die getroffenen technischen und organisatorischen Maßnahmen zu überprüfen. Zudem ist es eine wichtige Informationsquelle für Fremdkontrollen, etwa datenschutzrechtliche Kontrollen durch meine Dienststelle. Ein Teil der Informationen, die in einem Verfahrensverzeichnis eingetragen sind, dienen zudem dazu, die Öffentlichkeit bei Bedarf über wesentliche Inhalte des automatisierten Verfahrens zu informieren. Diese Pflicht einer öffentlichen Stelle ergibt sich aus § 11 Abs. 4 LDSG.
  • Welchen Inhalt hat ein Verfahrensverzeichnis?
    Über den Inhalt eines Verfahrensverzeichnisses gibt § 11 Abs. 2 LDSG Auskunft. Folgende Informationen sind einzutragen und detailliert zu beschreiben:
    • Name und Anschrift der verantwortlichen Stelle,
    • die Bezeichnung des Verfahrens,
    • die Zweckbestimmung und die Rechtsgrundlage der Verarbeitung,
    • die Art der gespeicherten Daten,
    • der Kreis der Betroffenen,
    • die Empfänger der Daten oder Gruppen von Empfängern sowie die jeweiligen Datenarten, wenn vorgesehen ist, die Daten zu übermitteln, sie innerhalb der öffentlichen Stelle für einen weiteren Zweck zu nutzen oder sie im Auftrag verarbeiten zu lassen,
    • die Fristen für die Prüfung der Sperrung und Löschung der Daten oder für die Sperrung und Löschung,
    • die zugriffsberechtigten Personengruppen oder Personen, die allein zugriffsberechtigt sind,
    • eine allgemeine Beschreibung der eingesetzten Hardware, der Vernetzung und der Software und
    • die technischen und organisatorischen Maßnahmen nach § 9 LDSG.
  • Was ist sonst noch zu beachten?
    Bei der Erstellung eines Verfahrensverzeichnisses ist es wichtig, alle vom Gesetz geforderten Angaben vollständig und detailliert zu machen. So genügt es beispielsweise bei der Angabe der Rechtsgrundlage nicht, „nur“ ein Gesetz zu benennen. Es ist vielmehr der einschlägige Paragraph anzuführen. Da in aller Regel eine Vielzahl von Sicherheitsmaßnahmen nicht vom eingesetzten automatisierten Verfahren, sondern von der zu Grunde liegenden technischen Infrastruktur abhängen (z. B. Sicherheitsmaßnahmen, die im lokalen Computernetzwerk getroffen sind), empfiehlt es sich, die verfahrensunabhängig getroffenen Sicherheitsmaßnahmen in einem Datenschutz- und Datensicherheitskonzept gebündelt zu beschreiben. Im Verfahrensverzeichnis kann dann auf dieses Konzept verwiesen werden. Auf jeden Fall ist es unerlässlich, die realisierten Maßnahmen vollständig und detailliert zu beschreiben. Wichtig ist zudem, dass die jeweilige verantwortliche Stelle, wenn kein behördlicher Datenschutzbeauftragter bestellt wurde, meinem Amt, so schreibt es der Gesetzgeber vor, spätestens mit der ersten Einspeicherung von personenbezogenen Daten die Eintragungen des Verfahrensverzeichnisses vorlegen muss.

Zur Arbeitserleichterung hat mein Amt ein Merkblatt mit verschiedenen praktischen Tipps und Hinweisen zur Erstellung eines Verfahrensverzeichnisses entworfen. Dieses steht zum Download auf der Internet-Seite meiner Dienststelle bereit: www.baden-wuerttemberg.datenschutz.de.

2.2 Datenabgleich von Personaldaten durch Rechnungsprüfungsämter - Mängel auch bei den Verfahrensverzeichnissen

Wie schon im 4. Teil, Nummer 1, berichtet, habe ich mich intensiv mit den bei zwei kommunalen Stellen durchgeführten Verfahren des Datenabgleichs von Personaldaten durch Rechnungsprüfungsämter beschäftigt. Dabei wurden mir auch die Verfahrensverzeichnisse zugeleitet. Die Lektüre dieser Dokumente konnte mich nicht davon überzeugen, dass die Verfahren in datenschutzrechtlich zulässiger Weise abliefen.

Im Einzelnen gab es an den Verfahrensverzeichniseinträgen Folgendes zu bemängeln:

  • Eine Stelle meinte es ganz besonders gut und ließ mir gleich drei Verfahrensverzeichniseinträge zukommen, die sich teilweise deutlich unterschieden. Grundsätzlich bin ich nur an einem Verfahrensverzeichniseintrag interessiert, nämlich dem, mit dem die Stelle ihren gesetzlichen Verpflichtungen nachzukommen gedenkt. Warum eine Stelle über mehrere, teilweise unterschiedliche Verfahrensverzeichniseinträge zu einem Verfahren verfügt, erschließt sich mir nicht. Die Vermutung, dass ein Verfahrensverzeichniseintrag eigens für die Stellungnahme erstellt wurde, ließ sich damit jedenfalls nicht entkräften.
  • Bei der Angabe der „Art der gespeicherten Daten“ teilte mir eine Stelle mit, es handle sich um „alle finanzrelevanten Daten der Stadtverwaltung und ihrer Eigenbetriebe“. Ich erwarte in einem Verfahrensverzeichniseintrag keine Beschreibung jedes einzelnen Datenfeldes detailliert bis auf „bits“ und „bytes“. Aber dass die genannte Beschreibung wenig zum Verständnis beiträgt, welche personenbezogenen Daten verarbeitet werden, dürfte nachvollziehbar sein.
  • Beide Stellen nutzten für die Verfahrensverzeichniseinträge ein soweit ersichtlich selbst entworfenes Formular. Dagegen ist zunächst nichts einzuwenden. Fragwürdig ist das Vorgehen dann, wenn beispielsweise eine Rubrik „Rechtsvorschrift“ zwar vorgesehen ist, aber keinen Eintrag enthält. Das schönste Formular nützt bei den Bemühungen, eine datenschutzrechtlich zulässige Verarbeitung durchzuführen, nichts, wenn die gesetzlich vorgeschriebenen Angaben im Verfahrensverzeichniseintrag nicht gemacht werden.
  • In einem Eintrag war die Rede davon, dass das Verfahren an einem sog. Stand-alone-Arbeitsplatz-PC durchgeführt worden sei. In diesem Fall beschränken sich die Maßnahmen der Transportkontrolle auf den Umgang mit Datenträgern, weil definitionsgemäß („stand alone“) der Rechner keinen Zugang zu einem Netzwerk hat. Leider erklärte die Stelle in einem anderen Dokument, dass man für die Nutzung des Programms zum Datenabgleich eine Netzwerklizenz beschafft habe, was die Frage aufwirft, warum eine Netzwerklizenz beschafft worden ist, wenn der (oder die?) Rechner nicht mit einem Netzwerk verbunden war(en).
  • Von ähnlicher „Güte“ waren Angaben zur Vernetzung, wenn in der Nummer 9 eines Verfahrensverzeichniseintrags einerseits durch Ankreuzen im Formular erklärt wird, „es gehe um nicht vernetzte PCs“, und andererseits im gleichen Absatz auch „Netz innerhalb der Stelle (Intranet)“ angekreuzt ist. In der Gewissheit, dass irgendetwas schon passen wird, könnte man hier natürlich auch die gesamte EDV-Infrastruktur der betreffenden Verwaltung aufzählen. Auf diese Weise wird aber der Vorschrift, wonach die bei dem konkreten Verfahren eingesetzte Hard- und Software und deren Vernetzung zu beschreiben ist, nicht Genüge getan.
  • Wenn aber die PCs, mit denen der Abgleich durchgeführt wurde, in die Rechnernetzwerke der Stellen eingebunden waren, wovon ich ausgehe, hätte man bei der Verarbeitung die Erforderlichkeit von Maßnahmen der Transportkontrolle prüfen müssen. Ob man das getan hat, war aus den mir vorgelegten Unterlagen nicht ersichtlich. In beiden Fällen war die Rubrik Transportkontrolle mit „trifft nicht zu“ ausgefüllt worden. Maßnahmen der Transportkontrolle vorzusehen wäre richtig gewesen, solche nicht zu treffen wäre sachlich falsch gewesen, aber die Angabe „trifft nicht zu“ war in jedem Fall völlig verfehlt.
  • Zur allgemeinen Beschreibung der eingesetzten Hardware, der Vernetzung und der Software gehört essentiell, dass im Verfahrensverzeichnis die Betriebssysteme genannt werden, unter denen die Anwendung läuft. Wenn das Betriebssystem von Client und gegebenenfalls Server nicht benannt wird, ist es kaum möglich, sich einen Eindruck von der Ablaufumgebung des Verfahrens zu verschaffen.
  • Ebenso ist die bloße Nennung von Begriffen wie „Passwortvergabe“ oder „Passwortschutz“ so pauschal, dass sie wenig zur Erhellung des Umfangs einer Authentisierung beitragen kann. Wofür war das Passwort? Zur Anmeldung an einer Domäne, zur Anmeldung an dem lokalen PC oder zur Authentisierung gegenüber dem Verfahren? Das Verfahrensverzeichnis soll eigentlich dazu dienen, derartige Fragen zu beantworten.
  • Häufig werden die Daten einer Anwendung in einem anwendungsspezifischen Format gespeichert. Daraus schließen manche Stellen, dass damit bereits ein Zugriffsschutz realisiert wird, da nur mit der jeweiligen Anwendung auf die Daten zugegriffen werden kann. Diese Aussage ist nur teilweise richtig. Dateien, deren Daten in einem anwendungsspezifischen Datenformat geschrieben wurden, können sehr wohl mit anderen Programmen gelesen werden und enthalten häufig personenbezogene Daten. Maßnahmen des Zugriffsschutzes im Rahmen des Dateisystems oder der verschlüsselten Speicherung sind in diesem Fall zur Sicherung der Vertraulichkeit der Daten unerlässlich.

An dieser Stelle will ich mit der Aufzählung enden und nur darauf hinweisen, dass sie hinsichtlich der Mängel nicht erschöpfend ist. Der Verdacht, dass auf meine Anforderung hin in beiden Fällen ein Verfahrensverzeichniseintrag „mit heißer Nadel gestrickt“ wurde, drängte sich bei der Lektüre förmlich auf.

Was ist zu tun: Ein Verfahrensverzeichnis muss den tatsächlichen Gegebenheiten des Verfahrens entsprechen und diese beschreiben, was unstreitig einen gewissen Aufwand und ausreichenden Sachverstand erfordert. Auf den vorangehenden Abschnitt weise ich nochmals hin.

Eine qualitative Verbesserung der Verfahrensverzeichniseinträge ist vor allem dann zu erwarten, wenn sie unter Einbeziehung eines behördlichen Datenschutzbeauftragten, der das Verfahrensverzeichnis der Stelle zu führen hat, erstellt werden. Alle öffentlichen Stellen sollten daher auch aus diesem Grund die Bestellung eines behördlichen Datenschutzbeauftragten ernsthaft ins Auge fassen.

 

3. Datenschutz bedeutet auch, Verantwortung zu übernehmen

Öffentliche Stellen, die personenbezogene Daten für sich selbst verarbeiten oder durch andere im Auftrag verarbeiten lassen, sind für die Einhaltung der datenschutzrechtlichen Vorschriften verantwortlich. Dies ist vielen nicht bewusst.

„Dafür sind wir nicht verantwortlich, der Einsatz dieses automatisierten Verfahrens wurde uns vorgeschrieben.“ Auf solche und ähnliche Äußerungen treffe ich besonders im Umgang mit Schulen, sei es bei Kontrollbesuchen, sei es bei Beratungen oder bei der Bearbeitung von Bürgeranfragen. Die Zuständigkeit wird dann häufig gerne auf vorgesetzte Dienststellen oder auf kommunale Schulträger abzuwälzen versucht; die stereotype Ausrede lautet zumeist: Datenschutzrechtlich verantwortlich ist das Kultusministerium (z.B. weil von dort ein landesweites EDV-Verfahren vorgegeben wurde) oder die Stadt XY als Schulträger (z.B. weil die Stadt die EDV-Ausrüstung der Schule zur Verfügung gestellt hat). Dieses Verhalten macht deutlich, dass elementare datenschutzrechtliche Grundbegriffe vielfach leider nicht bekannt sind oder ignoriert werden. Doch gerade die Frage nach der datenschutzrechtlichen Verantwortlichkeit ist aus meiner Sicht von zentraler Bedeutung. Diese bezieht sich nicht nur auf die gesetzliche Zulässigkeit und die ordnungsgemäße Verarbeitung, sondern auch auf die Realisierung der notwendigen technischen und organisatorischen Maßnahmen zum Schutz der personenbezogenen Daten.

Der Begriff der „verantwortlichen Stelle“ ist im Landesdatenschutzgesetz klar geregelt: Verantwortliche Stelle ist jede Stelle, die personenbezogene Daten für sich selbst verarbeitet oder durch andere im Auftrag verarbeiten lässt (§ 3 Abs. 3 LDSG).

Jede öffentliche Stelle, die personenbezogene Daten verarbeitet, ist gut beraten, wenn sie die Verantwortlichkeitsfrage genau prüft und dabei den Zweck der Datenverarbeitung im Auge behält. Wird sie lediglich als „Datenerfassungsstelle“ für Dritte tätig oder nutzt sie die verarbeiteten Daten zur Erfüllung eigener Aufgaben weiter? Die genaue Prüfung der Verantwortlichkeiten ist auch dann geboten, wenn eine solche Stelle ihre personenbezogenen Daten durch andere im Auftrag verarbeiten lässt, das heißt beispielsweise ein zentrales Rechenzentrum mit der Durchführung beauftragt (sog. Auftragsdatenverarbeitung). Entscheidet sich eine verantwortliche Stelle für eine Auftragsdatenverarbeitung, so bleibt sie dennoch weiterhin für die Einhaltung der Vorschriften des Datenschutzes und damit insbesondere für die notwendigen technischen und organisatorischen Schutzmaßnahmen in der Pflicht. Sie hat in dem Vertrag zur Auftragsdatenverarbeitung entsprechende Verpflichtungen des Auftragnehmers vorzusehen und deren Einhaltung konsequent zu überwachen.

 

4. EDV in der Praxis: Probleme bei Datei-Zugriffsberechtigungsstrukturen und die Tücken gekaufter Software

In einem Gesundheitsamt werden in großem Umfang sensible medizinische Daten von Bürgern verarbeitet. Wenn solche Daten in falsche Hände geraten, können sich daraus erhebliche Nachteile für die Betroffenen ergeben.

Ein Kontrollbesuch in einem Gesundheitsamt zeigte im technisch-organisatorischen Umfeld schwerwiegende Mängel auf, auf die ich hier näher eingehen will:

Ein Gesundheitsamt besteht aus mehreren Abteilungen, denen unterschiedliche Aufgaben zugewiesen sind. Im Rahmen eines Kontrollbesuches stellten meine Mitarbeiter nun fest, dass Dateien mit sensiblen personenbezogenen Daten von Mitarbeitern aus einer anderen Abteilung des Amtes zu lesen waren. Es handelte sich hierbei um Meldungen nach dem Infektionsschutzgesetz, in welchen im Klartext die Betroffenen mit ihren infektiösen Erkrankungen genannt wurden. Diese Daten waren beispielsweise von Mitarbeitern aus der Abteilung „Jugend- und Zahngesundheit“ zu lesen und sogar abzuändern. Nur der Vollständigkeit halber sei gesagt, dass die Betroffenen, um deren Daten es geht, weder Jugendliche noch zahnbehandlungspflichtige Patienten waren. Als der Leiter des Gesundheitsamts während des Kontrollbesuchs darauf angesprochen wurde, konnte keine Erklärung für die Möglichkeit des abteilungsübergreifenden Dateizugriffs gegeben werden. Eine Erforderlichkeit hierfür war nicht zu erkennen, weil die Abteilung „Jugend- und Zahngesundheit“ die fraglichen Daten für die Erfüllung ihrer eigenen Aufgaben nicht benötigte und daher auch nicht verarbeitete. Ich habe deshalb dem Amt gegenüber eine Beanstandung ausgesprochen.

Der Fall hat erneut gezeigt, dass Zugriffsberechtigungen sehr sorgfältig und umsichtig vergeben werden müssen. Weil sich außerdem die Berechtigungen aufgrund des üblichen Personalwechsels häufig ändern, ist auch deren regelmäßige Überprüfung und Aktualisierung unbedingt erforderlich. Die Beschreibung transparenter, allen Beteiligten bekannter Prozesse, die insbesondere die Genehmigung zur Vergabe von Zugriffsrechten einschließt, ist hierbei hilfreich.

Gekaufte Software ist nicht immer dazu geeignet, die datenschutzrechtlichen Anforderungen zu erfüllen. Denn oftmals erfüllt zwar diese Software die fachlich-funktionalen Anforderungen; jedoch sind die datenschutzrechtlich vorgeschriebenen technischen Maßnahmen oft nicht umzusetzen, weil die Software nicht über die entsprechende Funktionalität verfügt. Dies sei an einem Beispiel aus unserer Kontrollpraxis dargestellt:

In Gesundheitsämtern ist häufig das automatisierte Verfahren Octoware anzutreffen. Es handelt sich hierbei um ein Produkt „von der Stange“. Bereits im Jahr 2006 wurde diese Software bei einem Kontrollbesuch in einem anderen Gesundheitsamt beanstandet (vgl. 27. Tätigkeitsbericht für das Jahr 2006, LT-Drucksache 14/650). Die von uns festgestellten Mängel waren damals insbesondere:

  • keine technische Sicherstellung einer Mindestlänge des Passwortes,
  • kein automatischer Verfall der Passwörter nach einer bestimmten Zeit,
  • keine automatische Sperre nach einer gewissen Anzahl von Fehlanmeldungen,
  • keine Passworthistorie, mit der verhindert wird, dass eines der letzten Passwörter erneut genutzt wird.

Zudem erfolgte - wie unsere Prüfung ergab - keine Eingabekontrolle innerhalb der Anwendung. Es wurde zwar erfasst, welcher Mitarbeiter die letzte Änderung an einem Datensatz durchgeführt hatte. Das Landesdatenschutzgesetz fordert von einer Eingabekontrolle jedoch, dass nachträglich überprüft werden kann, welche Daten zu welcher Zeit von wem in dem betreffenden Datenverarbeitungssystem eingegeben worden sind. In der Software Octoware war diese Funktionalität jedoch nicht vorhanden. In der verantwortlichen Stelle war zudem niemandem bekannt, ob eine Eingabekontrolle auf eine andere Weise durchgeführt oder einfach „von Hand“, das heißt durch simples Aufschreiben, realisiert wird. Somit wurde in diesem Amt nicht einmal versucht, die nicht vorhandene Funktionalität der Software durch eine organisatorische Regelung auszugleichen.

All diese festgestellten Mängel waren - wie gesagt - bereits im Jahre 2006 in einem anderen Gesundheitsamt vorhanden. Trotz unserer Aufforderung, die Mängel abstellen zu lassen, wurde offenbar vom Hersteller nichts unternommen.

Bereits vor der Beschaffung von Software „von der Stange“ - also am besten in der Projektphase - ist darauf zu achten, dass durch die zu beschaffende Software auch die datenschutzrechtlichen Anforderungen erfüllt werden. Erst hinterher das Fehlen von Funktionen mit datenschutzrechtlicher Relevanz festzustellen, ist nicht im Sinne des Datenschutzes; dieses Versäumnis ist aber leider in der Praxis immer wieder anzutreffen.

 

5. Orientierungshilfen zu Datenschutzfragen des Anschlusses von Netzen der öffentlichen Verwaltung an das Internet

Im Berichtszeitraum wurden die Orientierungshilfen zu Datenschutzfragen des Anschlusses von Netzen der öffentlichen Verwaltung an das Internet von einer Arbeitsgruppe des Arbeitskreises Technik der Konferenz der Datenschutzbeauftragten des Bundes und der Länder überarbeitet. Neben vielen redaktionellen Änderungen wurden folgende inhaltliche Erweiterungen vorgenommen:

  • Das Urteil des Amtsgerichts Berlin Mitte (Urteil von 27.03.2007, 5 C 314/06), wonach das Verfolgen von User-Bewegungen auf Homepages (Webservern) mittels Speicherung der IP-Adressen über den Nutzungsvorgang hinaus unzulässig ist, wurde berücksichtigt.
  • Die Techniken „Sender Policy Framework/DomainKeys Identified Mail“ (SPF/DKIM), die zur Bekämpfung der SPAM-Flut entwickelt wurden, wurden von der Arbeitsgruppe untersucht und aufgrund der datenschutzrechtlichen Unbedenklichkeit in die Orientierungshilfen aufgenommen. Verwaltungsnetze müssen über ein Firewallsystem an das Internet angebunden werden. Häufig werden parallel ein zentraler Spamfilter und ein Virenscanner betrieben. In beiden Systemen fallen bei der Internet-Nutzung personenbezogene Daten in Form von Protokolldaten und Inhaltsdaten an. Es ist daher zu klären, unter welchen Bedingungen auf die Daten zugegriffen werden darf. Unter Zuarbeit des Arbeitskreises Medien wurden die Bedingungen präzisiert, unter denen auf die Inhaltsdaten von E-Mails zugegriffen werden darf. Die Arbeitsgruppe vertritt weiterhin die Auffassung, dass die Protokolldaten nach sieben Tagen zu löschen sind.

Bedingt durch den technischen Wandel wird auch zukünftig eine Anpassung der Orientierungshilfen von Zeit zu Zeit erforderlich sein. Die öffentlichen Stellen sollten die nunmehr vorgenommenen Aktualisierungen in ihrem EDV-Betrieb bei Bedarf umsetzen. Die Orientierungshilfen können auf der Homepage meiner Dienststelle unter www.baden-wuerttemberg.datenschutz.de abgerufen werden.

 

6. Polizeiliche Datenverarbeitung

Polizeiarbeit ist zu einem nicht unerheblichen Teil Beschaffung von Information und deren Auswertung. Dazu bedient sich die Polizei Baden-Württembergs der elektronischen Datenverarbeitung. Daher ist die Kontrolle der polizeilichen Informationssysteme ein immer wiederkehrendes Thema auf meiner Agenda.

Im Berichtszeitraum wurden ein neues Vorgangsbearbeitungssystem der Polizei Baden-Württemberg namens ComVor („Computergestützte Vorgangsbearbeitung“) und die EDV-technische Bewältigung der Großlage NATO-Gipfel kontrolliert. Zusammenfassend lässt sich formulieren: Licht und Schatten.

6.1 Die polizeiliche Vorgangsbearbeitung ComVor

Das alte, großrechnerbasierte System zur Erfassung, Be- und Verarbeitung von polizeilichen Vorgängen in Baden-Württemberg stammt aus den achtziger Jahren des vorigen Jahrhunderts und war noch nicht für die aktuell erforderliche Vorgangsbearbeitung auf Sachbearbeiterebene konzipiert. Ein neues Vorgangsbearbeitungssystem war daher von Nöten und wurde in Kooperation mit zwei weiteren Bundesländern entwickelt. Das Ergebnis ist ein datenbankbasiertes Vorgangsbearbeitungssystem, bestehend aus der Vorgangsbearbeitung CV, einer Vorgangsverwaltungsanwendung namens ComVor Index und dem sog. Elektronischen Tagebuch ETB. Schon im Jahr 2008 wurden mehrere Polizeidirektionen auf das neue Vorgangsbearbeitungssystem ComVor umgestellt. Deshalb lag es nahe, die Pilotdienststelle einer Kontrolle zu unterziehen, die zu folgenden Ergebnissen führte:

  • Verarbeitung personenbezogener Daten
    Die Vorgangsbearbeitung CV dient zur Erfassung polizeilicher Vorgänge in Dokumenten. Sie unterscheidet zwischen den Objektrollen (Beschuldigter, Zeuge, Geschädigter etc.) und ihren Rolleninhalten (Name, Vorname, Geburtsdatum etc.) einerseits und ihrem Auftreten in polizeilichen Vorgängen andererseits, die über Formulare abgebildet werden. Dadurch wird prinzipiell eine effektive Trennung von personenbezogenen Daten und Vorgängen sowie bei Bedarf eine flexible Erweiterbarkeit über Formulare erreicht. Ein personenbezogenes Datum wird in der Vorgangsbearbeitung an genau einer Stelle in einer Datenbank gespeichert. Treten personenbezogene Daten in Formularen auf, werden diese daher lediglich als Verweise auf die Objektdaten in der Datenbank realisiert.
    Die Teilkomponente ComVor Index dient zur Verwaltung von Vorgängen, indem gegebenenfalls eine Suche über die Vorgangsdatenbank durchgeführt wird. Es kann dabei über Objektrollen bzw. den dazugehörigen Daten gesucht werden. Überwiegend dürfte ComVor Index dazu genutzt werden, an Hand der Vorgangsnummer Vorgänge zu suchen bzw. zu finden. Ich bin mir bewusst, dass die Suchfunktion die Gefahr birgt, ComVor als weiteres polizeiliches Auskunftssystem zu nutzen. Deshalb habe ich empfohlen, weitergehende Suchfunktionalitäten an bestimmte Berechtigungsstufen zu binden und diese nur restriktiv zu vergeben.
    Das elektronische Tagebuch ETB ist in erster Linie ein reines Informationsmedium für den polizeilichen Sachbearbeiter, um sich einen Lageüberblick zu verschaffen. Soweit bei der Kontrolle ersichtlich, werden personenbezogene Daten in das ETB eingestellt. Ich habe darauf hingewiesen, dass sich der Umfang der Verarbeitung personenbezogener Daten an anderen Lagebildinformationssystemen orientieren muss. Ich kann nachvollziehen, dass die Gewinnung eines lokal begrenzten Lagebildes für die polizeiliche Arbeit erforderlich ist. Dazu ist die Kenntnis von personenbezogenen Daten meiner Ansicht nach aber nicht notwendig. Insbesondere ist darauf zu achten, dass in einer ersten Stufe keine personenbezogenen Daten angezeigt werden. Ich gehe davon aus, dass im ETB im Gegensatz zu anderen Lagebildinformationssystemen nur polizeilich geprüfte Vorgänge gespeichert werden, woraus sich zumindest eine Erhöhung der Datenqualität ergeben sollte.
  • Berechtigungsverwaltung
    Dem Grundsatz, dass der Nutzer nur Kenntnis derjenigen personenbezogenen Daten haben soll, die er für seine Aufgabenerfüllung braucht, wird in ComVor durch ein umfangreiches Berechtigungskonzept Rechnung getragen. Es erstreckt sich auf alle drei Komponenten. Die Berechtigungen werden an Funktionsrollen und an Organisationseinheiten ausgerichtet. Die Berechtigungsverwaltung ist dezentral organisiert. Die Berechtigungen werden lokal durch Personal in der jeweiligen Organisationseinheit vergeben.
  • Löschung
    Durch die Trennung der Vorgangsbeschreibung in Formular und Objektdaten wird erreicht, dass bei Löschung des Objekts dieses aus allen zum Sachverhalt gehörenden Formularen, in denen es in einer bestimmten Rolle aufgetreten ist, eliminiert wird. Diese Lösung ist datenschutzrechtlich zu begrüßen, weil sie sicherstellt, dass die Speicherdauer von personenbezogenen Daten effektiv kontrolliert werden kann. Damit sollten Dokumente, in denen personenbezogene Daten festgehalten werden und die in den Tiefen eines Dateisystems gespeichert sind und von keiner Löschroutine erfasst werden, eigentlich der Vergangenheit angehören.
    Die bei der polizeilichen Vorgangsbearbeitung zu beachtenden Löschfristen ergeben sich nicht direkt aus gesetzlichen Vorschriften. Auffallend ist, dass die Löschfristen in dem neuen System mit generell fünf Jahren deutlich länger waren als im alten System, in dem Daten je nach Einzelfall zwischen einem und fünf Jahre gespeichert wurden. Ich habe gegenüber der Polizei die Auffassung vertreten, dass hinsichtlich der Speicherdauer nachgearbeitet werden muss.
  • Schnittstellen
    Da die Vorgangsbearbeitung die zentrale Anwendung der Polizei ist, bestehen Schnittstellen zu weiteren Polizeiverfahren, die nicht notwendigerweise von der gleichen datenschutzrechtlich verantwortlichen Stelle betrieben werden. Teilweise befanden sich die Entwicklungen noch im Planungsstadium. Wir haben darauf hingewiesen, dass wir eine effektive Übermittlungskontrolle in ComVor für erforderlich halten, falls Daten an eine andere Stelle, die verantwortliche Stelle im Sinne des Landesdatenschutzgesetzes ist, übermittelt werden sollen.

Insgesamt hat die Kontrolle ergeben, dass die Polizei mit der neuen Vorgangsbearbeitung ein leistungsfähiges System entwickelt hat, das datenschutzrechtliche Anforderungen grundsätzlich umsetzen kann. Jetzt gilt es, letzte Schwächen auszumerzen und bei der Weiterentwicklung den Datenschutz im Auge zu behalten.

6.2 Der NATO-Gipfel

Im Frühjahr 2009 fand in Baden-Baden, Kehl und Straßburg anlässlich des 60. Jahrestages des Bestehens der NATO ein zweitägiger NATO-Gipfel statt. Um die Sicherheit der teilnehmenden Delegationen zu gewährleisten, wurde zumindest aus meiner Sicht ein bis dahin im Land nicht gekannter polizeilicher Aufwand betrieben. Damit einher ging eine intensive EDV-technische Unterstützung, bei der personenbezogene Daten von Bürgern erhoben und verarbeitet wurden, die sich vermutlich nie hätten träumen lassen, dass sie eines Tages in einem Polizeicomputer durchleuchtet würden. Insgesamt waren ca. 650 PCs in Betrieb. Die Anzahl entspricht damit der Ausstattung von ungefähr zwei mittelgroßen Polizeidirektionen. Die Vielzahl der Betroffenen und die Eingriffstiefe in das Recht auf informationelle Selbstbestimmung veranlassten mich, die „Besondere Aufbauorganisation Atlantik“ (BAO Atlantik), die mit der Sicherung des Ereignisses beauftragt war, einer Kontrolle zu unterziehen. Dabei ergaben sich folgende Erkenntnisse:

  • Dateien
    Zu meinem Bedauern ist es der Polizei nicht gelungen, für die BAO Atlantik eine spezielle EDV-Anwendung zur Lagebearbeitung, in der alle die Lage betreffenden personenbezogenen Daten gespeichert worden wären, aufzubauen. Stattdessen mussten meine Mitarbeiter vor Ort feststellen, dass anscheinend Excel-Dateien die bevorzugte Speicher- und Verarbeitungslösung waren. Exemplarisch standen hierfür die Dateien der Einwohner der Sicherheitszonen der verschiedenen Örtlichkeiten, Dateien aller im Stadtgebiet Baden-Baden bzw. den entsprechenden Sicherheitszonen in Kehl und am Flugplatz Lahr registrierten Inhaber waffenrechtlicher Erlaubnisse, eine Datei aller Personen in räumlicher Nähe zu Aufenthaltsräumlichkeiten gefährdeter Staats- und Regierungschefs, Dateien mit Firmen und deren Mitarbeitern in diversen Sicherheitszonen bzw. zutrittsberechtigte Personen zu Sicherheitsbereichen, eine Liste der für Gefangenensammelstellen vorgesehenen Ärzte und die hoffentlich leer gebliebene Liste verletzter und einsatzunabhängig erkrankter und verletzter Beamtinnen und Beamten, die mit einer Anwendung namens Xenios auf einem Stand-alone-PC verwaltet wurden.
    Die Dateien waren auf verschiedenen Servern bei der Polizeidirektion Offenburg, dem Einsatzlagezentrum bzw. dem Regierungspräsidium in Freiburg, der Polizeidirektion Rastatt/Baden-Baden, in einem landesweit verfügbaren Informationssystem (MOSS) oder auf Stand-alone-PCs gespeichert. Wie bei Dateien nicht unüblich, dürften sie daneben auch per polizeilicher E-Mail in diversen Postfächern und in sonstigen Ablagen gelandet sein. Wenn schon die Speicherorte über die Landkarte verstreut liegen, wollte man bei der datenschutzrechtlichen Verantwortlichkeit nicht nachstehen. Auch diese war auf mehrere Stellen verteilt. Die Konsequenzen, die ein derartiges Sammelsurium an Dateien für das Auskunftsrecht gemäß §§ 5 und 21 LDSG hat, sind klar. Der Betroffene weiß nicht nur nicht, wer wo welche personenbezogenen Daten über ihn speichert, sondern angesichts der Vielzahl von Dateien kann er auch nicht wissen, an welche verantwortliche Stelle er sich wenden muss, wenn er seinen Auskunftsanspruch geltend machen will. Auch die Löschung der Daten war für den Betroffenen bei dieser Ausgangslage alles andere als transparent, denn als Löschdatum, sofern man das als Datum bezeichnen mag, wurden „nach dem Nato-Gipfel“, „nach endgültiger Beendigung der Einsatzmaßnahmen“, „spätestens zum 31.12.2009“ und weitere nicht ganz einfach einzugrenzende Zeiträume genannt. Bei den Verfahrensverzeichniseinträgen der auf einer Excel-Datei basierenden „Vorgangsbearbeitung im Unterabschnitt 4.1- Ermittlungen“ und der „Befristeten Speicherung und Auswertung von Bild- und Videodaten sowie Daten von sichergestellten Laptops und Mobiltelefonen“ wurde gar erklärt, Fristen für die Prüfung der Löschung oder Sperrung könnten entfallen.
  • Anwendungen
    Neben den Excel-Dateien wurden noch weitere Verfahren, mit denen personenbezogene Daten gespeichert und verarbeitet werden, namens LaDok (Lagedokumentation), Arbeitsdatei RTF (Dokumentation der Anfragen in polizeilichen Auskunftssystemen), GeSa (Verwaltung und Dokumentation der in Gefangenensammelstellen aufgenommenen Personen) oder EPS-Web (Einsatzprotokollsystem) und das schon erwähnte Verfahren MOSS (Microsoft Office Sharepoint Server) eingesetzt. Eine Organisationseinheit hatte mit LaDok und MOSS sogar zwei Systeme im Einsatz.
    Innerhalb MOSS, das auch als Plattform für die Anwendung Polizei Online dient, auf die alle Polizeibeamte des Landes zugreifen können, wurde der BAO Atlantik ein eigener Speicherbereich zugewiesen. Über die Berechtigungsverwaltung von MOSS wurde geregelt, wer auf die personenbezogenen Daten zugreifen kann. Die Gefahr bei derartig „kombinierten“ Systemen besteht erfahrungsgemäß darin, dass Zugriffsberechtigungen zu weitgehend vergeben werden. Bei einer stichprobenweisen Prüfung stellten meine Mitarbeiter beispielsweise fest, dass nicht mit Vollzugsaufgaben betraute Mitarbeiter des Landeskriminalamts auf die Liste der Waffenbesitzer (Name, Anschrift und Aufzählung der gemeldeten Waffen von Offenburg) zugreifen konnten. In einem anderen Fall hatten alle Benutzer einer Domäne namens LPDFR19 - also der Abteilung 6 des Regierungspräsidiums - lesenden und schreibenden Zugriff auf eine Datei, in der Waffeninhaber im Bereich der Polizeidirektion Rastatt/Baden-Baden gespeichert waren.
    Hinsichtlich des technischen Datenschutzes äußerst fragwürdig war auch die Anwendung ITB/Videoauswertung des Einsatzabschnitts Folgemaßnahmen. Die Beamten brachten nämlich ihre EDV-Ausrüstung von ihrer Heimatdienststelle mit, wobei alle Einstellungen der Heimatdienststelle übernommen wurden. Alle Benutzer mussten mit der einheitlichen Kennung „users“ arbeiten und hatten Zugriff auf alle Daten. Ob dieses Vorgehen in der Heimatdienststelle datenschutzrechtlich zulässig ist, erscheint fraglich. Bei der BAO Atlantik hätte es Maßnahmen der Benutzer- und Zugriffskontrolle bedurft, wie sie nicht dadurch zu erreichen sind, dass alle Benutzer unter derselben Benutzerkennung in einem Netzwerk arbeiten.

Nur der Vollständigkeit halber sei erwähnt, dass nicht wenige der oben genannten Anwendungen die Gelegenheit eröffneten, in Freitextfeldern Daten einzugeben und abzuspeichern. Regelungen, was in die Freitextfelder einzugeben war, waren nicht erkennbar.

In einer Stellungnahme zu meinem Kontrollbericht hat das Innenministerium erklärt, die IT-Konzeption sei darauf ausgerichtet gewesen, auf der Grundlage einer einheitlichen technischen Plattform zu arbeiten. Hierunter versteht das Innenministerium offenbar, dass das Arbeiten auf Servern in mindestens vier sog. Domänen (Landespolizeidirektion Freiburg, Polizeidirektion Offenburg, Polizeidirektion Rastatt/Baden-Baden und Landeskriminalamt Baden-Württemberg) von Benutzern aus fünf Domänen (zusätzlich polizei-bw.net) und die gegenseitige Öffnung der Domänen (durch die Schaltung von sog. Vertrauensstellungen) mit mindestens sieben Anwendungen eine „einheitliche Plattform“ sei. Diese Auffassung teile ich nicht. Weiterhin vertrat das Innenministerium die Auffassung, die Verwendung unterschiedlicher Anwendungssysteme sei nicht zu vermeiden und deshalb zur sachgerechten Bewältigung erforderlich gewesen. Auch das ist nicht nachvollziehbar: LaDok, EPS-Web, Recherchetool-Funkbuch waren Anwendungen, die dazu dienten, polizeiliches Handeln zu dokumentieren. Dass die Dokumentation polizeilichen Handelns so komplex ist, dass es dazu drei unterschiedlicher Anwendungen bedarf, ist nicht nachvollziehbar. Zur Speicherung erklärte das Innenministerium, entsprechend der IT-Konzeption sei weitgehend eine zentrale Speicherung von Daten erfolgt. Diese Behauptung deckt sich nicht mit den Beobachtungen meiner Mitarbeiter, wonach personenbezogene Daten auf diversen Servern und Laufwerken gespeichert wurden. Insgesamt hätte man dem Datenschutz sicher besser dadurch Genüge getan, wenn man eine eigenständige Domäne nur für die BOA Atlantik eingerichtet hätte. Meiner Schlussfolgerung, angesichts der „verteilten Speicherung“ personenbezogener Daten sei deren termingerechte Löschung alles andere als gesichert, wollte sich das Innenministerium nicht anschließen. Immerhin hat es zugestanden, dass man als Prüffrist - nicht Löschfrist - für die Einsatzdokumentation nunmehr den April 2010 vorgemerkt hat.

Insgesamt hat die Datenverarbeitung beim NATO-Gipfel den Eindruck erweckt, als sei die IT-Strategie der BAO Atlantik „EDV by patchwork“ gewesen. Dabei bleibt der Datenschutz erfahrungsgemäß auf der Strecke. Ich hoffe, dass die neue Vorgangsbearbeitung und die sich derzeit in Entwicklung befindlichen neuen polizeilichen Informationssysteme so flexibel sein werden, dass damit zukünftige Großlagen EDV-technisch in geordneten datenschutzrechtlichen Bahnen verlaufen und von mir begleitet werden können.

 

7. Kontrolle eines Personalrats

Auch der Personalrat einer Dienststelle ist Teil der meiner Kontrolle nach § 28 LDSG unterliegenden öffentlichen Stelle und hat wegen der hohen Vertraulichkeit der von ihm verarbeiteten Daten besondere datenschutzrechtliche Sorgfalt walten zu lassen.

Aufgrund der Eingabe eines Beschäftigten einer Stadt hat meine Dienststelle den Personalrat dieser Stadtverwaltung einer Kontrolle unterzogen. Besonders zu erwähnen ist, dass das Ergebnis der Kontrolle ausschließlich dem Personalrat mitgeteilt wurde, weil er seine Aufgaben im Verhältnis zu seiner Dienststelle unabhängig und eigenverantwortlich wahrnimmt. Im Einzelnen wurde von meinen Mitarbeitern Folgendes festgestellt bzw. empfohlen:

  • Einer der Angehörigen des Personalrats nahm seine Aufgaben im Rahmen einer Freistellung im Umfang von fünfzig Prozent wahr. Für das städtische Sozialamt war er ebenfalls im Umfang von fünfzig Prozent tätig. Im EDV-System hatte dieses Personalratsmitglied nun eine Benutzerkennung, unter der er vom Personalratsbüro aus sowohl auf personenbezogene Daten, die der Personalratstätigkeit zuzuordnen waren, als auch auf personenbezogene Daten in seiner städtischen Tätigkeit zugreifen konnte. Diese Vorgehensweise entsprach nicht dem Gebot einer funktionsbezogenen Trennung innerhalb des EDV-Systems. Der Personalrat teilte mit, dass er die Problematik gegenüber der EDV-Abteilung angesprochen habe. Eine Lösung würde kurzfristig angestrebt.
  • Mit dem Rechner erstellten die einzelnen Personalräte hauptsächlich Dokumente, die im Dateisystem des lokalen Rechners oder auf einem Server abgelegt wurden. Auch für den Personalrat gilt bei der Verarbeitung personenbezogener Daten, dass diese zu löschen sind, wenn ihre Kenntnis nicht mehr für die Aufgabenerfüllung erforderlich ist. Hierzu muss gegebenenfalls manuell das Dateisystem nach zu löschenden Dateien durchsucht werden.
  • Zur Gewährleistung der Vertraulichkeit empfiehlt es sich, dass die von einem Personalrat erstellten Dateien verschlüsselt gespeichert werden. In Frage kommt auch, dass jedes Personalratsmitglied die Daten auf einem eigens beschafften USB-Stick verschlüsselt abspeichert und diesen in der Dienststelle verschlossen aufbewahrt.
  • Bei der kursorischen Durchsicht des E-Mail-Postfachs wurden Nachrichten gefunden, deren Anhänge aus Dokumenten bestanden, in denen personenbezogene Daten gespeichert wurden. Auch für E-Mails müssen die Löschfristen eingehalten werden.
  • Bei der Kontrolle fielen meinen Mitarbeitern Mängel der Benutzerkontrolle auf, die insbesondere für die von den einzelnen Personalratsmitgliedern genutzten PCs von besonderer Tragweite sein können:

    • Das Passwort war nur fünf Zeichen lang. Wir haben den Personalrat darauf hingewiesen, dass jedes seiner Mitglieder ein Kennwort mit einer Mindestlänge von acht Zeichen wählen solle, die aus Groß- und Kleinbuchstaben sowie Zahlen bestehen sollten.
    • Bildschirmsperren waren nicht aktiviert. Wir haben empfohlen, dies nachzuholen, damit ein PC bei vorübergehender Abwesenheit des Nutzers nicht von Dritten genutzt werden kann. Der Zeitraum bis zur Aktivierung der Bildschirmsperre sollte zehn Minuten nicht überschreiten.
    • Es fand keine Sperre bei erfolglosen Anmeldeversuchen statt. Wir halten es für erforderlich, dass nach einer von den Administratoren zu bestimmenden Anzahl von erfolglosen Anmeldungen die Benutzerkennung gesperrt wird. Diese Maßnahme ist deshalb angeraten, weil sonst von Unbefugten über das Netzwerk unbemerkt automatisiert Anmeldeversuche durchgeführt werden können, die insbesondere aufgrund eines zu kurzen Passworts mit hoher Wahrscheinlichkeit erfolgreich sind und damit den Schutz durch das Passwort unterlaufen.

Die Arbeit eines Personalrats bedingt den Umgang mit personenbezogenen Daten, deren Vertraulichkeit besonders hoch einzuordnen ist. Dies erfordert eine spezielle Konfiguration der Personalrats-PCs. Personalräte müssen regelmäßig prüfen, ob die Kenntnis aller von ihnen verarbeiteten personenbezogenen Daten zur Aufgabenerfüllung weiterhin erforderlich ist, und die Daten gegebenenfalls und nicht zuletzt im Interesse der Betroffenen löschen.

 

8. Die Neuregelung der informationstechnischen Zusammenarbeit zwischen Bund und Ländern - wo bleibt der Datenschutz?

Die Föderalismuskommission II hat auch die informationstechnische Zusammenarbeit zwischen Bund und Ländern auf eine neue verfassungsrechtliche Grundlage gestellt. Zur Umsetzung wurde ein IT-Staatsvertrag erarbeitet, der einen IT-Planungsrat mit weitreichenden Befugnissen vorsieht. Weder im Staatsvertrag noch im entsprechenden Ausführungsgesetz des Landes ist von Datenschutz die Rede.

Die Beschlüsse der Kommission von Bundestag und Bundesrat zur Modernisierung der Bund-Länder-Finanzbeziehungen (Föderalismuskommission II) haben u. a. zu einer Änderung des Grundgesetzes in Bezug auf die informationstechnische Zusammenarbeit geführt; danach können Bund und Länder aufgrund von Vereinbarungen die für die Kommunikation zwischen ihren informationstechnischen Systemen notwendigen Standards und Sicherheitsanforderungen (gegebenenfalls auch mit qualifizierter Mehrheit) festlegen (Artikel 91 c Abs. 2 des Grundgesetzes - GG -). Zur weiteren Umsetzung wurde ein „Vertrag über die Errichtung des IT-Planungsrats und über die Grundlagen der Zusammenarbeit beim Einsatz der Informationstechnologie in den Verwaltungen von Bund und Ländern - Vertrag über die Ausführung von Artikel 91c GG“ erarbeitet (vgl. LT-Drucksache 14/4908), der am 1. April 2010 in Kraft treten soll. Der darin vorgesehene IT-Planungsrat wird dann zum zentralen Gremium der IT-Steuerung von Bund und Ländern, das deren Zusammenarbeit in Fragen der Informationstechnik koordinieren, fachunabhängige und fachübergreifende IT-Interoperabilitäts- und IT-Sicherheitsstandards beschließen und eGovernment-Projekte steuern soll. Dabei kann der IT-Planungsrat Beschlüsse, z.B. zu IT-Standards, auch mit Mehrheitsentscheidung fassen. Der Ratifizierungsprozess läuft. Bund und Länder haben außerdem jeweils eigene Ausführungsgesetze auf den Weg gebracht.

Im September 2009 unterrichtete das Innenministerium die Ministerien und mich über den Entwurf des Ausführungsgesetzes, verwies darauf, dass der Ministerrat dem Staatsvertrag bereits am 22. Juli 2009 zugestimmt habe, und kündigte die Verabschiedung des Gesetzes durch den Landtag bis Ende des Jahres an. Leider musste ich nach der Lektüre des Ausführungsgesetzes, aber auch des Staatsvertrages selbst, feststellen, dass darin zwar Ausführungen zur Festlegung von „IT-Interoperabilitäts- und IT-Sicherheitsstandards“, aber nicht zur datenschutzrechtlichen Verträglichkeit von Standards enthalten sind. Weiter fiel auf, dass vorrangig auf „bestehende Marktstandards“ abgestellt werden soll (§ 3 Abs. 1 Satz 2 des Staatsvertrags). Vor einer Beschlussfassung über derartige „verbindliche Standards“ soll auf Antrag des Bundes oder dreier Länder grundsätzlich der Bedarf sowie die IT-fachliche Qualität und Widerspruchsfreiheit des vorgesehenen Standards durch eine vom IT-Planungsrat bestimmte, unabhängige Einrichtung geprüft werden (§ 3 Abs. 3 Satz 1).

Die Ausblendung des Datenschutzes in der Standardsetzung durch den IT-Planungsrat bedeutet aus meiner Sicht insbesondere im Hinblick auf das Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität informationstechnischer Systeme (vgl. Urteil des Bundesverfassungsgerichts vom 27. Februar 2008, siehe hierzu 1. Teil, Nr. 1) ein erhebliches, in Anbetracht der aktuellen Rechtsprechung des Bundesverfassungsgerichts eigentlich unverständliches Defizit. Ich schlug daher dem Innenministerium unter dem Vorbehalt, dass noch Änderungen am Staatsvertragsentwurf zu erreichen sind, vor, den Datenschutz als Standardisierungsmaßstab explizit aufzunehmen sowie vorzusehen, dass datenschutzrelevante neue IT-Standards auch auf Antrag des Bundesbeauftragten für den Datenschutz durch die besagte unabhängige Einrichtung zu überprüfen sind. Nicht unerwartet antwortete mir das Innenministerium kurz darauf, dass der Staatsvertrag bereits im Rahmen der Föderalismuskommission ausverhandelt worden sei; Änderungen seien nicht mehr möglich. Unter den Vertragspartnern bestehe jedoch Einigkeit, dass auch Datenschutzstandards einzuhalten sind. Das mag aufgrund des geltenden Rechts so sein. Dennoch meine ich, dass im Staatsvertrag eine Chance vertan wurde, den Datenschutz auch „offiziell“ zum Maßstab für die Standardisierungsarbeit des IT-Planungsrats zu machen und außerdem dafür zu sorgen, dass datenschutzoptimierte IT-Standards durch entsprechende Festlegungen marktfähig werden können. Ähnlich haben dies auch die Datenschutzbeauftragten von Bund und Ländern gesehen (vgl. Entschließung vom 8./9. Oktober 2009, Anhang 26). Dass es auch verfassungsrechtliche Zweifel an dem Konstrukt des IT-Planungsrats gibt, sei nur am Rande erwähnt. Immerhin wird auf dieses Bund-Länder-Gremium eine relativ unbestimmte, generelle Steuerungskompetenz übertragen, die nicht nur zu Lasten überstimmter Länder gehen, sondern im Einzelfall durchaus auch grundrechtssensible Bereiche erfassen kann.

 

nach oben