Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein

6         Systemdatenschutz

6.1         IT-Konzept : Grundlage für das Datenschutzmanagement

Jede Daten verarbeitende Stelle muss nachweisen, dass die automatisierte Verarbeitung personenbezogener Daten sicher und kontrolliert erfolgt. Ein Sicherheitskonzept dokumentiert die tatsächlich getroffenen technischen und organisatorischen Sicherheitsmaßnahmen. Ebenso wichtig ist es, in einem informationstechnischen Konzept die technischen und organisatorischen Vorgaben, den Verfahrenszweck und die erzielbaren Ergebnisse zu beschreiben.

In der Kürze liegt die Würze: In nur einem Satz fasst die Datenschutzverordnung (DSVO) die Erfolgskriterien einer Datenverarbeitung personenbezogener Daten zusammen. Die Datenverarbeitung muss vorab geregelt werden. Hierzu sind technische und organisatorische Vorgaben zu entwickeln.

Organisatorische Vorgaben zu entwickeln bedeutet vor allem festzulegen, wer für welche Teilaspekte eines Verfahrens verantwortlich und zuständig ist. Zusätzlich legt die Daten verarbeitende Stelle in einem IT-Konzept fest, wer bei einzelnen Schritten in einem Verfahren zu beteiligen und zu informieren ist. Mit den organisatorischen Vorgaben wird quasi der Grundstein einer datenschutzkonformen Datenverarbeitung gelegt.

Am Beispiel Datensicherung erkennt man den Nutzen organisatorischer Vorgaben: Verantwortlich für die korrekte Sicherung der personenbezogenen Daten auf geeignete Medien ist der IT-Leiter. Zuständig für die Sicherung ist der Administrator des betreffenden Systems. IT-Leiter und Administrator können jedoch nicht abschließend entscheiden, wie die Aufbewahrungsdauer der gesicherten Daten und die Häufigkeit der Datensicherungen zu wählen sind. Für diese Entscheidungen muss der jeweilige Fachbereich beteiligt werden. Der oder die behördliche Datenschutzbeauftragte muss bei der Einführung eines solchen Verfahrens beteiligt und bei einer wesentlichen Änderung zumindest informiert werden. Dieses Beispiel macht bereits klar: Gute organisatorische Vorgaben vermeiden so manche Panne im späteren Betrieb.

Die Entwicklung technischer Vorgaben bedeutet vor allem festzulegen, mit welchen technischen Mitteln – also Rechnern, Netzwerken, Diensten und Programmen – eine Verarbeitung personenbezogener Daten entsprechend dem aktuellen Stand der Technik stattzufinden hat. Das IT-Konzept bietet der Leitung einer Daten verarbeitenden Stelle das Steuerungsinstrument, mit dem ein geordneter, wirtschaftlicher und rechts- bzw. datenschutzkonformer IT-Betrieb erreicht werden kann. Ein IT-Konzept gemäß DSVO regelt damit die Dinge, die häufig mit dem Schlagwort „IT-Controlling“ oder „IT-Steuerung“ erfasst werden. Planen Fachabteilungen den Einsatz neuer Verfahren, so kann mit Bezug zu einem bestehenden IT-Konzept einfach und schnell geprüft werden, ob das geplante Fachverfahren in die IT-Landschaft passt. Fehlinvestitionen und unliebsame Überraschungen in fortgeschrittenen Phasen eines Einführungsprojekts können so effektiv verhindert werden.

Mit einem guten IT-Konzept steuert der IT-Leiter, in enger Abstimmung mit der Leitung des Hauses, die Technikentwicklung seiner Dienststelle. Der Wildwuchs bei der IT-Austattung kann durch die Konzentration auf einzelne Modelllinien im IT-Konzept bekämpft werden. Ein hoher Personalaufwand bei der Unterstützung der Endanwender „in der Fläche“ kann beispielsweise dadurch verhindert werden, dass bereits im IT-Konzept verfahrensübergreifend die Regelungen für eine zentrale Softwareverteilung, ein datenschutzkonformes „Aufschalten“ auf die Endgeräte sowie eine gemeinsame, einheitliche Dokumentation aller verwendeten Geräte geregelt ist.

Das informationstechnische Konzept bildet die Grundlage für ein erfolgreiches Datenschutzmanagement (29. TB, Tz. 6.1). Es dient als „verlängerter Arm“ des Verfahrensverzeichnisses, indem es die Zweckbestimmung der automatisierten Verarbeitung personenbezogener Daten aufgreift. Die erzielbaren Ergebnisse der automatisierten Datenverarbeitung sind zu beschreiben. Es muss darin der Nachweis geführt werden, dass die eingesetzte Informations- und Kommunikationstechnologie den funktionalen, genauer gesagt den fachlichen Anforderungen des Verfahrens genügt. Dies bildet nicht nur die Grundlage für den Nachweis der Wirtschaftlichkeit eines Verfahrens, sondern ermöglicht vor allem einen besseren Einstieg in die Erstellung des Sicherheitskonzepts. Bereits hier können viele Fragen nach Vertraulichkeit, Integrität und Verfügbarkeit der Datenverarbeitung abschließend beantwortet werden. Dieser Nachweis bildet die Arbeitsgrundlage für den Datenschutzbeauftragten. Erst wenn klar ist, was gemacht werden soll, kann entschieden werden, wie es sicher umgesetzt werden soll. Und erst dann kann auch geprüft werden, ob es ausreichend sicher gemacht wurde.

 

6.2         IT-Kooperation der Kreise Nordfriesland und Schleswig-Flensburg

Die Landkreise Schleswig-Flensburg und Nordfriesland werden ihre Informationstechnik modernisieren und in einem IT-Betrieb zusammenfassen. Auf Wunsch der Beteiligten berät und unterstützt das ULD dieses Vorhaben, damit die Daten der Einwohner dieser Landkreise von Beginn an datenschutzkonform und sicher nach dem Stand der Technik verarbeitet werden.

Die Kreise Nordfriesland und Schleswig-Flensburg haben mithilfe einer Wirtschaftlichkeitsanalyse festgestellt, dass sie ihre Informationstechnik (IT) in einem gemeinsamen IT-Servicebetrieb wirtschaftlicher betreiben können. Daher ist geplant, die IT-Abteilungen der beiden Kreise zusammenzulegen und die Ressourcen Personal, Technik und Fachverfahren gemeinsam über diesen Servicebetrieb zu nutzen.

Der IT-Servicebetrieb wird datenschutzrechtlich als Auftragnehmer die Datenverarbeitung der beiden Landkreise übernehmen sowie Dienstleistungen für die kreisangehörigen Kommunen erbringen. Planung und Umsetzung der datenschutz- und sicherheitsrechtlichen Voraussetzungen unterstützt das ULD beratend. Das Projekt lässt wirtschaftliche, qualitativ hochwertige und innovative Ergebnisse erwarten.

 

6.3         NSI – neue Steuerung

Die Landesregierung hat dauerhaft eine Kommission zur Entwicklung und zum Einsatz neuer Steuerungsinstrumente für Verwaltungen (NSI-Kommission) eingerichtet. Eine wesentliche Aktivität dieser Kommission besteht darin, ein Kennzahlen- und Indikatorensystem zur Kontrolle und Steuerung (Controlling) von Planung und Bewirtschaftung in Abstimmung mit allen Ministerien zu entwickeln.

Das ULD nimmt in beratender Funktion an der NSI-Kommission teil. Die Kommission will hiermit sicherstellen, dass von vornherein die Belange des Datenschutzes in Bezug auf neue Steuerungsinstrumente Beachtung finden. Controller und Datenschützer haben ein gemeinsames Ziel: eine bessere Transparenz in Prozessen und Verfahren in öffentlichen Verwaltungen.

Das Interesse an Transparenz ergibt sich aus verschiedenen Perspektiven: Die Steuerbarkeit von Verwaltungsorganisationen soll generell effektiviert, deren Wirtschaftlichkeit gesteigert und der Nachweis der Rechtmäßigkeit des Verwaltungshandelns gegenüber der bisherigen Situation verbessert werden. Dies alles ist mit Risiken für Bürger, aber vor allem für Mitarbeiterinnen und Mitarbeiter der Verwaltungen verbunden.
Die aktuelle Entwicklung im E-Government – vor allem die EU-Dienstleistungsrichtlinie – führt in Bezug auf die Verarbeitung personenbezogener Daten dazu, dass die bisherigen Lösungen zur Verhinderung der gesetzlich verbotenen Leistungs- und Verhaltenskontrollen bei Verwaltungsmitarbeitern erneut durchdacht und geregelt werden müssen. Diese Kontrollen fanden bislang größtenteils nicht statt, weil diese flächenübergreifend einzurichten zu aufwendig und die erzielten Ergebnisse methodisch oftmals zweifelhaft gewesen wären.

Im Zuge der anstehenden Elektronisierung eines jeden Verwaltungsarbeitsplatzes ändert sich diese Situation. Die Protokollierung von Mitarbeitertätigkeiten wird flächendeckend möglich. Die Protokollierungsfunktionen müssen deshalb mit Nachdruck gesichtet und auf ihre Rechtmäßigkeit hin bewertet werden. Die Auswertung der Protokolle muss dann durch technische und organisatorische Vorgaben unter arbeitsrechtliche und datenschutzkonforme Bedingungen gestellt werden. Hierbei ist die Situation der automatisierten Erfassung von Mitarbeitertätigkeiten aus datenschutzrechtlicher Sicht differenziert zu betrachten: Das Landesdatenschutzgesetz schreibt vor, dass Zugriffe von Personen, die Änderungen an automatisierten Verfahren bewirken, zu protokollieren und zu kontrollieren sind. Dies betrifft vornehmlich die Systemadministratoren. Von quantitativ größerer Bedeutung ist aber eine weitere Regelung, wonach zu protokollieren ist, wann, durch wen und in welcher Weise personenbezogene Daten gespeichert wurden, wenn diese Daten ausschließlich automatisiert gespeichert, verändert und übermittelt wurden. Genau dieser Umbau auf eine ausschließlich automatisierte Verarbeitung personenbezogener Daten einschließlich einer sehr viel genauer als bislang möglichen automatisierten Beobachtung von Mitarbeitertätigkeiten steht in den kommenden Jahren bis 2010 an. Hier fordert das Datenschutzrecht, dass eine Auswertung zwecks Verhaltens- und Leistungskontrolle nicht erfolgt.

Bei den anstehenden Aktivitäten gilt als dritte Anforderung, den Datenschutz für die von den Umstellungen betroffenen Bürger möglichst zu verbessern. Hierfür stehen die Chancen gut, weil in elektronischen Verfahren eine wohldurchdachte automatisierte Protokollierung dazu führen wird, die Rechtmäßigkeit eines Verfahrens bzw. der einzelnen Verfahrensschritte belegen und überprüfen zu können. Allerdings gilt es darauf hinzuwirken, dass sich mit der Umstellung auf digitale Verfahren keine neuen Begehrlichkeiten nach mehr Daten Bahn brechen oder ein bestehend schlechtes Sicherheitsniveau digital fortgesetzt wird, obwohl es sicherheits- und datenschutztechnisch bessere Verfahren gibt. Gemeinsam mit den technisch Verantwortlichen müssen rechtzeitig Fehler identifiziert werden, mit denen bei Einführung neuer Prozesse und Verfahren realistischerweise immer zu rechnen ist.

 

6.4         SOA  (Serviceorientierte Architekturen)

SOA steht für ein Konzept zur Abbildung von Verwaltungsverfahren bzw. Geschäftsprozessen auf IT-Prozesse. Das Besondere an einer SOA ist, dass die IT-Techniken heterogen und die Prozesse organisationsübergreifend eingerichtet sein können.

Die Flexibilität einer SOA erzwingt eine Standardisierung der Geschäfts- und IT‑Prozesse. Über SOA können sich virtuelle Organisationen ausbilden; dadurch geraten die gesamten organisationsübergreifenden Prozessketten in den Blick. Aus Datenschutzsicht bieten die mit SOA einhergehende Standardisierung und die zweckmäßig zugeschnittenen, grundlegenden IT-Services die Chance, die Prüffähigkeit und Nachweisbarkeit einer ordnungsgemäßen Datenverarbeitung durch verbesserte Transparenz von Datenbeständen, Datenflüssen und der Datenverarbeitung wesentlich zu steigern.

Diese Chance zur Verbesserung der Transparenz des Umgangs mit personenbezogenen Daten in Organisationen entsteht über die notwendige Beteiligung der unterschiedlichen Akteure, die zwangsläufig zu einer offenen und transparenten Kommunikation und Dokumentation über Formate und Adressen führen muss. Kann nach erfolgter Standardisierung auf bislang separierte Datenbestände systemübergreifend und effektiv zugegriffen werden, so steigert dies jedoch das Risiko einer Zweckänderung der Daten. Durch das Zusammenführen und das Auswerten verschiedener Datenbestände lassen sich komfortabel Profile bilden. Allerdings bietet SOA die Chance der Datenkapselung in „Containern“. In solchen Datencontainern können sich, neben den eigentlichen Nutzdaten, auch automatisierbar zugängliche Regeln („Policies“) befinden, wie diese Nutzdaten verarbeitet werden dürfen, sowie die Protokollierungsdaten, die – wiederum automatisiert – darüber Auskunft geben können, welche Verarbeitung tatsächlich erfolgte. Das heißt: Mit SOA kann man bei der Automatisierung des Erzeugens und Umgangs mit Protokolldaten einen effektiven Schritt vorankommen.

Wenn in einer SOA derartige Policies zur Verfügung stehen, kann sich der Absender von Daten vergewissern, dass seine Daten in einer Umgebung mit angemessenem Datenschutzniveau und nur für den vorgesehenen Zweck verarbeitet werden. Der Empfänger von Daten muss vor der eigenen weiteren Verarbeitung prüfen, ob diese Verarbeitung wirklich machbar und zulässig ist. Dieser Ansatz ermöglicht es, den Nutzdaten die erlaubten und vertraglich vereinbarten Datenverarbeitungsvorschriften mitzugeben. Solche Container bieten eine neue, qualitativ gute Möglichkeit, die Flüsse der Daten sowie deren beabsichtigte Verwendung durch Policies und deren erfolgte Verwendung anhand von Protokolldaten automatisiert zu kontrollieren und beweisfest zu belegen.

SOA wird zumeist in einen Zusammenhang mit Web Services gebracht. Web Services sind Standards, mit denen Daten in die Sprache XML definiert, beschrieben, weltweit eindeutig identifiziert und über internetbasierte Protokolle wie beispielsweise HTTPS ausgetauscht werden. Derartige Datenweitergaben über Web Services sind wie alle Datenübermittlungen zwischen unabhängigen Organisationen an enge gesetzliche Rahmen gebunden. Es ist absehbar, dass Organisationen sich darum bemühen werden, innerhalb dieses Rahmens ihre Workflows stärker aufeinander abzustimmen. Das ergibt nicht nur in der auf SOA setzenden Zulieferindustrie von Automobilherstellern ökonomischen Sinn, sondern ebenso zwischen unterschiedlichen Verwaltungen – unter Beibehalt der jeweiligen Organisationshoheit und Zuständigkeit.

Das bedeutet aber auch, dass trotz zunehmender gegenseitiger Abhängigkeit die Organisationen sich darum kümmern müssen, ihrer Verantwortung für die Datenverarbeitung gerecht zu werden. Alle Beteiligten sollten ein Interesse daran haben, dass eventuell auftretende Fehler korrekt zugerechnet werden können. Es entsteht dadurch ein unausweichlicher Bedarf für die Organisationen, die Korrektheit der eigenen Funktionalwahrnehmung gegenüber den anderen Beteiligten in der Prozesskette zweifelsfreier als bislang nachweisen zu können. Dieser Nachweis des rechtmäßigen Umgangs mit Daten, der funktionalen Effektivität und der ökonomischen Effizienz lässt eine Win-win-Situation für alle, auch der mit Kontrollaufgaben befassten Stellen, entstehen.

In Schleswig-Holstein sind auf Landes- als auch auf Kreisebene erste Ansätze von serviceorientierten Architekturen auszumachen. Das ULD ist in mehreren Beratungsprojekten aktiv beteiligt. Richtig gestaltet sind SOAs für den Datenschutz ein Gewinn. Das ULD bietet öffentlichen und privaten Stellen seine rechtliche und sicherheitstechnische Beratung an.

 

6.5         Datenschutz bei der Softwareentwicklung

In der öffentlichen Verwaltung wird inzwischen zumeist Standardsoftware eingesetzt. Wird spezielle Software entwickelt, dann sind schon zu diesem Zeitpunkt Datenschutzanforderungen zu beachten. Besonderer Wert ist auf die Dokumentation des Quellcodes und die spätere Nachvollziehbarkeit der Operationen der Software im laufenden Betrieb zu legen.

Die Datenschutzverordnung für Schleswig-Holstein (DSVO) stellt spezifische Anforderungen an die Dokumentation bei der Softwareentwicklung. Die Dokumentation des Programmcodes soll es ermöglichen, den Programmcode aus Datenschutzsicht zu überprüfen, sodass das Programm nicht intransparent und unkontrollierbar Daten verarbeitet. Zu dieser Dokumentation zählen auch solche „Texte“, die während des Betriebes als Protokollierungsdaten anfallen. Auf diese Selbstauskunft von Programmen muss künftig stärker als bisher geachtet werden, weil zunehmend damit zu rechnen sein wird, dass an derartige Protokolltexte arbeitsrechtliche Folgen geknüpft werden.

Nicht nur die Dokumentation des Programms und dessen Betrieb, bereits die Entwicklung der Software muss revisionssicher erfolgen. Die Zugriffe auf die Quelltexte durch die Programmierer müssen geregelt sein. Während der Entwicklung muss es eine qualitätssichernde Testinstanz geben, welche die Änderungen am Programm tatsächlich nachvollzieht und freigibt. Für die Tests von Programmen empfiehlt das ULD den Einsatz dedizierter Test-Suiten mit prototypischen, generierten Testdaten. Wenn für ein neues Verfahren in der Pilotphase bereits ein aussagekräftiges IT- und Sicherheitskonzept in einer hinreichenden Qualität vorliegen, kann es für einen begrenzten Zeitraum und in begrenztem Umfang auch mit Realdaten getestet werden. Auch hier gilt: Sämtliche Tests sind zu dokumentieren.

Ist eine Software im Einsatz, so muss jederzeit sofort geklärt werden können, welche Version in welcher Konfiguration betrieben wird (Release- bzw. Configuration-Management). Handelt es sich um eine Spezialsoftware, an der auch die Besitzrechte bestehen, so muss es eine zweifelsfreie Verbindung zwischen dem Quelltext und der im Betrieb befindlichen Version geben. Das ULD empfiehlt hierfür den Einsatz von Versionsmanagementsystemen.

Findet die Software dann Anwendung bei Daten verarbeitenden Stellen, so bedeutet eine datenschutzfreundliche Softwareentwicklung die Einrichtung fester Zyklen zur Produktentwicklung und eine Dokumentation der durchgeführten Änderungen. Durch feste Zyklen für neue Programmversionen wird die Planbarkeit für Test- und Freigabeverfahren bei den Daten verarbeitenden Stellen verbessert. Mithilfe einer genauen Dokumentation der durchgeführten Änderungen kann eine Daten verarbeitende Stelle ihre eigenen Tests und die notwendige Freigabe besser auf die neuen oder verbesserten Funktionen zuschneiden.

 

6.6         Sicherheitslücken im FHH-Net : Auswirkungen auf Schleswig-Holstein

Der Hamburgische Datenschutzbeauftragte hat eklatante Sicherheitslücken im Behördennetz der Freien und Hansestadt Hamburg aufgezeigt. Das ULD hat die Auswirkungen auf die Datenverarbeitung schleswig-holsteinischer Behörden geprüft. Ein akuter Datenmissbrauch konnte nicht festgestellt werden, doch sind bei Dataport erhebliche Änderungen in der IT-Infrastruktur nötig.

Unsere hamburgischen Kollegen haben im Rahmen einer Prüfung des von den Behörden in Hamburg genutzten Netzwerkes (kurz: FHH-Net) eine Reihe von gravierenden Schwachstellen festgestellt, die es einem internen Angreifer mit Zugang zum FHH-Net ermöglichten, unbefugt auf personenbezogene Daten von schleswig-holsteinischen Kunden bei Dataport zuzugreifen. Ursache ist zum einen eine mangelhafte Durch- und Umsetzung datenschutzrechtlicher Vorgaben im Bereich der Administration bei Dataport. Zum anderen beruhen die festgestellten Mängel – soweit sie Dataport und Schleswig-Holstein betreffen – auf dem Umstand, dass das interne Datennetz von Dataport auf dem FHH-Net aufsetzt und von diesem sicherheitstechnisch nicht ausreichend separiert ist. Derart „erbt“ das interne Datennetz von Dataport konzeptionelle Schwächen des FHH-Net.

Wir haben die Ergebnisse und Bewertungen des Prüfberichts nachvollzogen und durch eigene Untersuchungen vor Ort ergänzt. Das ULD teilt die Einschätzung unserer Hamburger Kollegen über die offensichtlichen Fehler bei der Administration sowie über die konzeptionellen Schwachstellen des internen Hausnetzes von Dataport.

Ein direkter Zugriff aus dem FHH-Net auf schleswig-holsteinische Fachverfahren und die dort verarbeiteten personenbezogenen Daten ist nicht erfolgt. Ein solcher Zugriff hätte über das Landesnetz Schleswig-Holstein passieren müssen, welches – anders als das FHH-Net – strikt aufgeteilt und damit stärker kontrolliert ist. Die Aufteilung des Landesnetzes Schleswig-Holstein begrenzt die Auswirkungen eines Sicherheitsvorfalles deutlich. Die Kontrollmechanismen stellen hier sicher, dass nur Verbindungen möglich sind, die von den jeweiligen Kommunikationspartnern beantragt und genehmigt wurden. Die an das Landesnetz angeschlossenen Teilnehmer können jederzeit eigenständig die sie betreffenden Einstellungen kontrollieren (29. TB, Tz. 9.1).

Aus dem FHH-Net konnte jedoch auf die Bürokommunikationsumgebung bei Dataport zugegriffen werden. Aufgrund einer zu offenen Berechtigungsvergabe war ein Zugriff auf die Dataport-interne Dateiablage möglich. Dort waren sicherheitskritische Dokumente und personenbezogene Daten in großer Menge einsehbar. Sicherheitsmaßnahmen wie eine Verschlüsselung von Dateiablagen oder eine minimalisierte Vergabe von Rechten für den Zugriff auf diese Ablagen waren nicht getroffen worden.

Das ULD hat die von Dataport getroffenen Sofortmaßnahmen geprüft und eigene Kontrollen durchgeführt. Im Ergebnis und gemäß dem Dataport-eigenen Sicherheitsmanagement ist es nach dem Stand der Technik unumgänglich, dass das interne Datennetz des Dienstleisters Dataport aus dem FHH-Net herausgelöst wird. Das ULD wird den Prozess der Trennung des Dataport-Netzes aus dem FHH-Net beratend begleiten. Dataport muss zudem seine interne Dateiablage stärker absichern. Für Daten mit hohem Schutzbedarf ist eine Verschlüsselung einzuführen, um diese dem systembedingten Zugriff von Administratoren bei Dataport zu entziehen. Für alle Datenablagen sind die vergebenen Zugriffsrechte zu überarbeiten und auf die zwingend notwendigen Zugriffsmöglichkeiten zu beschränken.

 

6.7         Datenschutz und Datensicherheit  an den Hochschulen

Die Lage des Datenschutzes an den Hochschulen Schleswig-Holsteins ist schlecht. Dies wurde im Jahr 2007 anhand von Prüfungen, einer zunächst schleppend verlaufenden Auditierung und mehreren Beratungsterminen vor Ort erneut sichtbar.

Die Feststellung ist nicht überspitzt formuliert, dass sich die Hochschulen unter dem Label „Freiheit für Forschung und Lehre“ um die Schaffung vom Datenschutz unbeobachtbarer Räume bemühen, und zwar selbst dort, wo ambitioniert Mechanismen des Finanz-Controllings installiert sind (Tz. 6.8.4). Unser Fazit: Hochschulen haben generell ein Steuerungsproblem.

Das ULD wird langsam auch von Hochschulen nicht nur als Aufsichtsbehörde, sondern auch als Beratungsinstitution wahrgenommen. So erkundigte man sich bei Beratungsterminen an Hochschulen vor Ort u. a. nach den Auffassungen des ULD zu Service Oriented Architectures (SOA, Tz. 6.4), Überlegungen zum Risk-Management gemäß der „IT Infrastructure Library“ sowie zu einzelnen Maßnahmen, die im Rahmen von BSI-Grundschutz anzuwenden sind. Wohl standen praxisorientierte Erläuterungen der rechtlichen Anforderungen im Vordergrund. Nach solchen Beratungen erwarten wir, dass gemeinsam gefundene und festgelegte Lösungen dann auch tatsächlich umgesetzt werden und der Dialog mit dem ULD fortgesetzt sowie an Datenschutzschulungen teilgenommen wird.

Häufig begegnen wir in Gesprächen mit Hochschulvertretern einem glaubwürdigen Bekunden von Sensibilität für Datensicherheit und Datenschutz. Die Systemadministratoren an Hochschulen erweisen sich überwiegend als technisch kompetent; sie haben ihre IT-Systeme weitgehend im Griff. Festzustellen ist allerdings, dass kein einziger der auf IT gestützten Kernprozesse bei unseren Überprüfungen hinreichend dokumentiert war. Nur die Dokumente zum Thema „Anweisungen der EDV-Nutzung für Studierende“ waren bei allen Hochschulen in einer passablen Verfassung. Schon bei den Dienstanweisungen für die Sachbearbeiterinnen und Sachbearbeiter hörte es dann auf. Es konnten keine aktuellen Organigramme der Hochschulorganisation, keine gültigen Geschäftsverteilungspläne sowie keine Tätigkeitsbeschreibungen – insbesondere für Systemadministratoren – vorgelegt werden. Als „Verfahrensverzeichnis“ betitelte Dokumente waren durchweg auf einem rudimentären Stand. Es fehlten ferner durchgängig IT- und Verfahrensbeschreibungen sowie Sicherheitskonzepte. Netzwerkpläne, ohne die eine Administration eines Computernetzes undenkbar ist, waren zwar teilweise vorhanden, aber methodisch unzureichend gestaltet und nie aktuell.

Rechnersysteme zum Testen von Software waren teilweise vorhanden, aber es konnten keine Dokumentationen erfolgter Tests und deren Ergebnisse vorgelegt werden. Die Zugriffsrechte der Hochschulleitungen, des Verwaltungspersonals oder des akademischen Lehrapparats auf Dateiserver oder Datenbanken mit personenbezogenen Daten von Studierenden konnten in keinem Fall dokumentiert oder zumindest rasch aus den Systemen selbst erzeugt werden. Auch wurden keine Dokumente zur Freigabe von Programmen vorgelegt, die den Akt der Verantwortungsübernahme durch einen Fachverantwortlichen und die Entlastung des IT‑Verantwortlichen signalisierten. Verträge mit externen Dienstleistern, insbesondere den IT-Dienstleistungen der „Hochschul-Informations-System GmbH“ (HIS), fehlten entweder ganz oder waren unzureichend. Nicht zuletzt herrschten durchgängig weitgehende Unkenntnisse über die geltenden Rechtsvorschriften, insbesondere auf der Ebene der Fakultäten, Institute und Fachbereiche.

Die Datenschutzbeauftragten waren in der Regel mit zu geringen Zeitkontingenten ausgestattet (5 % bis 50 %), verfügten durch die Bank nur über geringe technische Kenntnisse und konnten keine auf Nachhaltigkeit zielende Strategien mit Gestaltungsanspruch vorweisen. Es blieb einzig bei anlassbezogenen Aktivitäten im Modus einer akuten Brandbekämpfung. Sie wussten aber von keinen Sicherheitsvorfällen zu berichten. Entsprechend war ihnen der Gedanke fremd, im Rahmen eines Sicherheitsmanagements bei Sicherheitsvorfällen bestimmter Qualität zwangsläufig beteiligt zu werden.

Es gibt keine einfache Lösung für die oben aufgeführten Mängel und Probleme. Die Bereitstellung von einfach mehr Ressourcen für den Datenschutzbeauftragten wäre wenig zielführend. Mehr Ressourcen gibt es erfahrungsgemäß nur, wenn die oder der Datenschutzbeauftragte etwas sichtbar Funktionales zu bieten hat. Sie oder er sollte zumindest als ein aktiver Wächter der Rechtmäßigkeit im Umgang mit personenbezogenen Daten auftreten. Dafür gilt es, Bündnispartner mit Interessenüberschneidungen zu finden, also mit dem Personalrat bezüglich Mitarbeiterdatenschutz ins Gespräch zu kommen, mit Studierendenvertretern zu sprechen und den Kontakt zum Sicherheitsbeauftragten des Rechenzentrums zu suchen. Mit der IT muss eine Dokumentationsstrategie vereinbart werden. Ein Anfang könnte in einer Dokumentation liegen, welche Datenverarbeitungen in welcher Form und wo zugänglich protokolliert werden und wer unter welchen Umständen diese Daten wie auswerten muss. Dabei ist dann festzulegen, wie mit möglicherweise festgestellten Sicherheitsvorfällen und Datenschutzverstößen umzugehen ist, um Kopflosigkeit und ungeregelte Prozesse zu vermeiden. Dies wäre ein Einstieg in den Aufbau eines Datenschutzmanagementsystems (DSMS).

Im Herbst 2007 wurde aufgrund einer Prüfung des ULD eine erste Initiative seitens einiger Hochschuldatenschutzbeauftragter gestartet, um die Dokumentationssituation in einer gemeinsamen Anstrengung zu verbessern. Datenschutz zu betreiben heißt heute: konstruktive Beteiligung am gesamten Kommunikationsmanagement nach innen und außen, mit entsprechenden Anforderungen an den Datenschutzbeauftragten.

 

6.8         Kontrollen  vor Ort – ausgewählte Ergebnisse

6.8.1      Querschnittsprüfung „Landesnetz“

Im Rahmen einer Querschnittsprüfung des vom ULD auditierten Landesnetzes wurde überprüft, wie die Landesnetznutzer ihren vertraglichen Pflichten nachkommen und welche Praxisprobleme bei der Nutzung, der Dokumentation und der Überprüfung der Landesnetzanschlüsse bestehen.

Im August 2006 wurde das Landesnetz durch das ULD auditiert. Zum Jahresbeginn 2007 waren nahezu alle Verwaltungen in Schleswig-Holstein an das Landesnetz angeschlossen. Darauf folgend wurden vom ULD die Landesnetzanschlüsse (LN-Anschlüsse) von elf Ämtern und Gemeinden überprüft. Im Interesse der Einheitlichkeit und Vergleichbarkeit wurden prüfungsspezifische Checklisten für folgende Bereiche erstellt und eingesetzt: Vertragssituation, Dokumentation der Kommunikationsaufträge und -beziehungen, Freischaltung und Einsatz der Tools LNRC und LNWebView sowie Rolle des Kommunikationskoordinators.

Folgende datenschutzrechtliche Aspekte standen im Vordergrund:

• Beachtung von Rechtsvorschriften zur Datensicherheit und zur Ordnungsmäßigkeit der Datenverarbeitung,
• konzeptionelle Festlegung und Umsetzung von technischen und organisatorischen Datensicherheitsmaßnahmen,
• Vollständigkeit der Verträge bei einer Auftragsdatenverarbeitung.

Weiterhin wurden die ablaufspezifischen Vorgänge bei

• der Beantragung des Landesnetzanschlusses,
• der Beantragung von Kommunikationsbeziehungen und
• der Beantragung der Kommunikationsbeziehungen (Routen) für die Tools LNWebView und LNRC

in Verbindung mit den notwendigen Anträgen, Bestätigungen und Dokumentationen berücksichtigt.

Der Anschluss der Behörden an das Landesnetz konnte im Verlauf der Prüfung in drei unterschiedliche Typen klassifiziert werden, die sich besonders in Bezug auf Verantwortlichkeiten, Auskunftsfähigkeit und Dokumentationsverhalten unterscheiden.

Typ 1:

Die Behörde hat einen eigenen LN-Anschluss, d. h., der Zugangs- und der Übergaberouter sind in den eigenen Räumlichkeiten installiert. Die Behörde hat einen eigenen Kommunikationskoordinator benannt. Er leitet alle Schritte bis zum voll funktionsfähigen Landesnetzanschluss in Verantwortung der eigenen Behörde in die Wege.

Typ 2:

Die Behörde hat einen eigenen LN-Anschluss, d. h., der Zugangs- und der Übergaberouter sind in den eigenen Räumlichkeiten installiert. Der Kommunikationskoordinator ist beim Kreis benannt. Er leitet alle Schritte bis zum funktionsfähigen Landesnetzanschluss in Vertretungsfunktion der Behörde in die Wege.

Typ 3:

Die Behörde hat keinen eigenen LN-Anschluss, sondern ist über das Kreisnetz an das Landesnetz angeschlossen. Der Kommunikationskoordinator ist beim Kreis benannt. Er leitet alle Schritte bis zum funktionsfähigen Landesnetzanschluss in Verantwortung des Kreises in die Wege.

Die Prüfungsergebnisse waren unterschiedlich: Der Landesnetzanschluss Typ 1 ist dadurch gekennzeichnet, dass sowohl die Verträge als auch die Funktion des Kommunikationskoordinators in dem Verantwortungsbereich der entsprechenden Behörde liegen. Zusammenfassend: Die Behörden, die ihre Datenverarbeitung im Allgemeinen datenschutzkonform organisieren und dokumentieren, haben bei der Landesnetzprüfung mit wenigen oder ohne Mängel abgeschnitten. Die Sorgfalt, die bei dem Umgang und der Dokumentation des Landesnetzes angesetzt wurde, kann als Spiegel der allgemeinen Datenverarbeitung innerhalb der Behörde gesehen werden.

Der Landesnetzanschluss Typ 2 zeichnet sich dadurch aus, dass die Verträge in dem Verantwortungsbereich der entsprechenden Behörde liegen und die Funktion des Kommunikationskoordinators beim Kreis in Vertretung der Behörde wahrgenommen wird. Die Prüfung fiel umso besser aus, je besser der Kommunikationskoordinator beim Kreis mit der Behörde kommunizierte. So funktionierte z. B. die Weiterleitung der Vertragsbestandteile bzw. der Kommunikationsberichte oder die Freischaltung von den Routen, die für den Einsatz von den Überwachungstools notwendig sind, nicht immer reibungslos.

Der Landesnetzanschluss Typ 3 ist dadurch gekennzeichnet, dass sowohl die Verträge als auch die Funktion des Kommunikationskoordinators nicht in dem Verantwortungsbereich der entsprechenden Behörde, sondern in der des entsprechenden Kreises liegen. Die Prüfungsergebnisse waren nur bei den Behörden positiv, die vom Kreis entsprechend informiert waren bzw. selbst die Initiative ergriffen haben. Einige Behörden waren gar nicht über die Funktionalitäten des Landesnetzes und/oder des Kreisnetzes informiert. Beim Landesnetzanschluss Typ 3 konnte keine vollständige Prüfung durchgeführt werden, da weder die Vertragslage noch der Einsatz der Überwachungstools beim Kreis beurteilt werden konnten. Der Kommunikationskoordinator beim Kreis übernimmt die Aufgabe, die Landesnetzparameter für die angeschlossenen Behörden zu verwalten und zu überprüfen sowie die Behörden über Änderungen beim Landesnetzanschluss oder über Änderungen in der Routerkonfiguration zu informieren. Auch die Erfüllung dieser Aufgaben wurde nicht überprüft.

Die allgemeinen und speziellen Problemstellungen und Unsicherheiten, die sich in Bezug auf den Landesnetzanschluss bei allen elf Prüfungen ergeben haben, lassen sich folgendermaßen zusammenfassen:

• Das Tool LNRC wurde von einigen Administratoren installiert. Die erzeugten LNRC-Routerausdrucke konnten allerdings von keinem Administrator interpretiert werden. Hier muss auf externe Hilfe zurückgegriffen werden.
• Die Rolle des Kommunikationskoordinators ist vor allem bei den Behörden mit dem Landesnetzanschluss Typ 2 und 3 häufig nicht klar. Aus diesem Grund sind während der Prüfung Missverständnisse bei der Kommunikation zwischen Behörde, Kreis und Dataport sowie bei der Frage nach den Verantwortlichkeiten aufgetreten.
• Die Anfragen der Kommunikationskoordinatoren der Kreise beim ULD und die Erfahrungsberichte aus den Ämtern und Gemeinden lassen darauf schließen, dass der Aufgabenumfang eines Kreiskommunikationskoordinators nicht eindeutig definiert ist.
• Häufig wurden innerhalb einer Behörde die relevanten Informationen, die sich aus dem Nutzervertrag und der Generaldokumentation für den Administrator und den Kommunikationskoordinator ergeben (Installation und Freischaltung des Tools LNRC, Benutzung und Freischaltung von LNWebView usw.), nicht weitergegeben.

Daraus ergeben sich folgende Anforderungen: Die Aufgabenbereiche eines Kommunikationskoordinators müssen je nach Einsatzbereich (Landesnetzanschluss Typ 1 bis 3) detailliert definiert werden. In diesem Zusammenhang sollten bei den Gemeinden und Ämtern die Kommunikation mit dem Systemadministrator und Dataport sowie die Dokumentationspflichten beachtet werden. Bei den Kreiskommunikationskoordinatoren hingegen müssen zusätzlich die Aufgaben bei der Verwaltung und Überprüfung der Landesnetzparameter sowie die angemessene Information der angeschlossenen Behörden berücksichtigt werden.

Das ULD hat für die Behörden in Schleswig-Holstein eine Arbeitsanleitung erstellt, die die Aufgaben von Kommunikationskoordinatoren und Administratoren in den Kommunen und Kreisen sowie von angeschlossenen Behörden bei Kreislandesnetzanschlüssen strukturiert. Gewählt wurde eine je nach Einsatzbereich differenzierte Darstellung sowohl als Checkliste als auch als Prozesskette.

Eine Hilfestellung kann die vom ULD bereitgestellte Arbeitsanleitung darstellen, die beim ULD angefordert oder im Internet heruntergeladen werden kann unter

https://www.datenschutzzentrum.de/landesnetz/

 

6.8.2      Vorbildliches Bad Bramstedt

Die meisten Beanstandungen bei unseren routinemäßigen Prüfungen betreffen eine fehlende oder unvollständige Dokumentation. Umso erfreulicher war es, dass die Stadtverwaltung Bad Bramstedt eine (fast) perfekte Dokumentation vorlegen konnte.

Wir hatten die Stadtverwaltung Bad Bramstedt auf dem falschen Fuß erwischt; sie befand sich gerade mitten in einer Telefonanlagen- und Serverumstellung. Die Stadt konnte dennoch das Prüfungsergebnis als Erfolg verbuchen. Ein Großteil dieses Erfolgs ist auf die sorgfältige und vom Systemadministrator vorgelegte (fast) lückenlose Dokumentation zurückzuführen:

• Sicherheitskonzept mit Risikoanalyse,
• Verfahrensverzeichnis mit Verweisen zu Verfahrensakten, Test und Freigabe,
• kombiniertes Geräte- und Patchverzeichnis,
• Netzwerkplan,
• Dokumentation der eingesetzten Benutzerkonten und -gruppen,
• Verträge aller externen Dienstleistungen und
• Dienstanweisungen für die Mitarbeiter.

Insgesamt wirkte die gesamte Dokumentation gut durchdacht und strukturiert. Es fehlen nur noch Kleinigkeiten, um eine perfekte Dokumentation zu haben:

• Die Bestandteile, die den IT-Einsatz in der Stadtverwaltung beschreiben, sind aus dem Sicherheitskonzept herauszuziehen und in einem IT-Konzept zusammenzufassen.
• Die Berechtigungen, die die unterschiedlichen Benutzer und Systemadministratoren im System haben, sind in einem Administrations- und Berechtigungskonzept festzuhalten.

Auch wenn die Stadtverwaltung Bad Bramstedt nicht ohne Beanstandungen aus dieser Prüfung herausgegangen ist, so hat sie bei uns doch den positiven Eindruck hinterlassen, dass sie sich mit der Problematik Datenschutz beschäftigt hat, die einzelnen Bereiche in Bezug auf organisatorische oder technische Sicherheitsmaßnahmen sorgfältig durchdacht und dokumentiert sowie die Maßnahmen für die Mitarbeiter in Form von Dienstanweisungen aufbereitet hat.

Eine datenschutzkonforme Dokumentation nach LDSG und DSVO ist eine Grundlage für die ordnungsgemäße Datenverarbeitung von öffentlichen Stellen. Aus diesem Grund nimmt sie einen hohen Stellenwert bei Prüfungen ein und sollte mindestens einen ebenso großen Wert bei den Verwaltungen selbst haben. Das ULD bietet allen öffentlichen Stellen ein umfassendes Beratungsangebot, angefangen bei Kursen der DATENSCHUTZAKADEMIE (Praxisforum, Tz. 13) bis hin zu Einzelberatungen.

 

6.8.3      Stadtverwaltung Tönning

Die Prüfung der allgemeinen Datenverarbeitung und des Internetanschlusses ergab, dass sich die Stadtverwaltung Tönning auf dem richtigen Weg befindet; sie hat den Nutzen einer guten Dokumentation und einer sicheren Datenverarbeitung erkannt und arbeitet an der Defizitbehebung.

Die Bestellung einer behördlichen Datenschutzbeauftragten kann zu einer deutlichen Erhöhung des Datenschutzes in der Verwaltung führen. Dies war dem büroleitenden Beamten wohl erst nach der Prüfungsankündigung bewusst. Zwei Wochen vor dem Prüfungstermin wurde eine Mitarbeiterin schriftlich bestellt. Es stellte sich sehr schnell positiv heraus, dass der Verwaltungschef diese Position nicht als „Feigenblatt“ sieht, sondern als deutliches Signal, die personenbezogenen Daten der Bürger vor unbefugter Kenntnisnahme Dritter zu schützen und als zentraler Ansprechpartner in Datenschutzfragen für die Führungsebene und die Mitarbeiter tätig zu sein.

Folgende Mängel wurden vorgefunden:

• Die Verfahrensdokumentation gemäß DSVO war unvollständig, Tests und Freigaben fehlten vollständig.
• Die Zugriffsberechtigungen waren nur systemseitig nachvollziehbar, ein Berechtigungskonzept fehlte.
• Eine revisionsfähige Protokollierung der administrativen Tätigkeiten fand nicht statt.
• Das Sicherheitskonzept war nur ansatzweise vorhanden. Die Risikoanalyse fehlte vollständig.
• Es existierten keine schriftlichen organisatorischen Regelungen bezüglich des Umgangs mit der IT.

 

6.8.4      Universität Flensburg

Das ULD hatte Anlass, die allgemeine Datenverarbeitung der Universität Flensburg zu prüfen. Wir waren darauf aufmerksam gemacht worden, dass sensible personenbezogene Daten auf einem der gesamten Hochschulverwaltung zugänglichen Laufwerk gespeichert waren.

Die Prüfung führte zur Beanstandung der Dokumentationslage. Nicht ein einziges Verfahren war auch nur in seiner Funktionalität ausreichend beschrieben. Das IT-Konzept befand sich in den Anfängen, das Sicherheitskonzept fehlte.

Wir stellten Mängel in der technischen Konfiguration universitätsweit eingesetzter PCs und Server sowie des Netzwerks fest. So zeigte sich, dass alte Mailbestände abrufbar waren, die als längst gelöscht galten. Das Management der IT geschieht nicht nach einer einheitlichen Methode. Durch den Rückgriff auf inzwischen übliche IT-Paradigmen wie etwa ITIL, COBIT oder BSI-Grundschutz könnte die Universität Flensburg eine Vielzahl der fehlenden Konzepte und Dokumente in einem geordneten Prozess erstellen und den Betrieb der Informations- und Kommunikationstechnologie durch technische und organisatorische Maßnahmen absichern.

Die Universität Flensburg verfügt über kein funktionierendes Datenschutzmanagementsystem (DSMS, 29. TB, Tz. 6.1), das sämtliche datenschutz- und datensicherheitsrelevanten Prozesse im Blick behält. Es gibt bisher weder eine Strategie, geschweige denn eine gelebte Praxis, die an der Hochschule eingesetzten Verfahren anlassbezogen und regelmäßig auf ihre Ordnungsmäßigkeit hin zu kontrollieren. Gleichwohl funktioniert der alltägliche operative Betrieb; die Systemadministration verfügte über erwartbare Kompetenzen beim Betreiben der Server. Die Verarbeitung der Daten der Studierenden durch die Verwaltung war rechtlich betrachtet im Grundsatz in Ordnung. Allerdings stellte sich die Frage, ob die für Schleswig-Holstein geltenden gesetzlichen Regelungen der Studierendenverordnung vom Dienstleister Hochschul-Informations-System (HIS), dessen Leistungen zur StudentInnenverwaltung beansprucht werden, vollständig umgesetzt werden. Dies wurde im Rahmen der Prüfung nicht näher geklärt. Die Universität sagte die Prüfung zu.

Die Leitung der Universität signalisierte Einsicht, dass der Datenschutz bislang vernachlässigt wurde. Die Folgen sind weitgehende Intransparenz der Verfahren und Zweifel an der Nachweisbarkeit eines ordnungsgemäßen Verwaltungsbetriebs an der Hochschule. Ärgerlich ist, dass sich die Papierlage selbst bei Produkten, die beim HIS „von der Stange“ genutzt werden, als nicht ausreichend erwies.

Zurück zum vorherigen Kapitel

Zum Inhaltsverzeichnis

Zum nächsten Kapitel