19. Tätigkeitsbericht (1997)



6.

Sicherheit und Ordnungsmäßigkeit der Datenverarbeitung

6.1

Das Pferd von hinten aufgezäumt


Weil die Beschaffung von Informationstechnik zu früh im Mittelpunkt aller Überlegungen steht, bemerken viele Behörden zu spät, daß Planungsfehler sie um die Früchte ihrer Arbeit bringen und ihnen vermeidbare Rechts- und Sicherheitsprobleme bescheren.

Fragt man die für die Informationstechnik (IT) in einer Behörde zuständigen Mitarbeiter nach den technischen Spezifikationen der von ihnen betreuten Systeme, sprudeln in der Regel die technischen Details nur so heraus. Da geht es um File-, Datenbank-, Mail-, Fax- und Printserver, um 166 Megahertz getaktete Clients, um Backbone-Netze, Lichtwellenleiter, Controller, Multiplexer, Hubs, X.25, ISDN, X.400, X.500, Gigabyte-Platten, Quad-Speed-CD-ROM-Laufwerke usw. usw. Fragt man nach der Zielrichtung des IT-Einsatzes, werden die Antworten etwas weniger wortreich. Da wird von Informations- und Managementsystemen gesprochen, von Bürokommunikation, von struktureller Modernisierung, von Arbeitsverdichtung, von individueller Datenverarbeitung, Workflow-Management und dergleichen. Will man wissen, welche konkreten Veränderungen und Verbesserungen von dem geplanten bzw. realisierten Technikeinsatz zu erwarten sind, welche Arbeitsschritte durch welche automatisierten Abläufe ersetzt werden, welche Zuständigkeiten wohin verlagert werden und vor allem welcher Nutzen für die Mitarbeiter, die Behörde und den betroffenen Bürger eintreten soll, erhält man nicht selten nur Hinweise auf noch nicht abgeschlossene Erfahrungsberichte; gelegentlich wird ergänzend auf nicht quantifizierbare Vorteile, auf Sachzwänge, auf die Notwendigkeit, den technischen Anschluß halten zu müssen, und auf die Zuständigkeit anderer zur Beantwortung dieser Fragen hingewiesen.

Eine Techniklastigkeit und Technikgläubigkeit der Verwaltung bei ihren Bestrebungen, uneffektive Verwaltungsabläufe zu optimieren, ist mithin nicht zu übersehen. Allzu häufig ist das Ziel einer Maßnahme noch gar nicht abschließend definiert, da sind die hard- und softwaretechnischen Komponenten schon geordert. Im weiteren richtet sich nicht die Technik nach den objektiven Erfordernissen, sondern man paßt die Verfahrensweisen so gut es eben geht und soweit rechtlich gerade noch vertretbar den technischen Gegebenheiten an. Nicht die Technik dient, sie wird bedient.

Aus vielen Beispielen hierfür seien nur folgende exemplarisch herausgegriffen:

  • Im Rahmen des Personalverwaltungs- und Personalmanagementsystems, das unter der Federführung des Innenministeriums entwickelt wurde, werden bereits Datenbanken mit Tausenden von Einzelinformationen gefüttert, obwohl man noch gar nicht weiß, wie man bei späteren Auswertungen die Aktualität und Vollständigkeit der Daten gewährleisten kann und wer die Richtigkeit der Selektionsmerkmale testet.

  • Nach wie vor werden Polizeidienststellen parallel zum COMPAS-Projekt mit Einzelplatz-PC ausgerüstet, um einen vermeintlich dringenden Bedarf zu decken. Zu welchen Zwecken die vielen hundert Geräte tatsächlich eingesetzt werden, kann schon längst nicht mehr wirkungsvoll überwacht werden. Die Verpflichtung aus dem Landesverwaltungsgesetz, die Errichtung von Dateien auf das erforderliche Maß zu beschränken, in angemessenen Abständen die Notwendigkeit ihrer Weiterführung zu prüfen und in Errichtungsanordnungen ihre Zweckbestimmung festzulegen, dürfte deshalb kaum erfüllt werden können.

  • Krankenhausinformationssysteme speichern eine Vielzahl von Patientendaten über lange Zeiträume in Datenbanken und stellen sie über Netzwerke an vielen Arbeitsplätzen bereit, obwohl nach Abschluß und Abrechnung einer stationären Behandlung eine Namenskartei mit einem Verweis auf die papierene Behandlungsdokumentation ausreichen würde.

  • In kleinen Organisationseinheiten (z.B. Kommunen) werden komplexe Client-Server-Konfigurationen mit mehreren Betriebssystemen installiert, bevor geklärt und getestet wurde, welcher Administrationsaufwand von wem zu erbringen ist, um die erforderliche Verfügbarkeit der Verfahren langfristig zu gewährleisten.

Die Ursache dafür, daß in diesen Fällen das Pferd von hinten aufgezäumt worden ist, liegt nach unseren Erkenntnissen an zu kurzen und zu wenig intensiven Planungsphasen. Die weit überwiegende Mehrzahl der Entscheidungsträger in der öffentlichen Verwaltung sind zwar ausgebildete Verwaltungsrechtler, aber keine IT-Spezialisten. Die Planung und Realisierung von IT-Systemen stellt sich ihnen daher als ein Problem dar, für das anerkannte und bewährte Grundlagen und Entscheidungsmaßstäbe fehlen. Auch die allgemeinen und bereichsspezifischen Vorschriften zur IT-gestützten Datenverarbeitung (vgl. Landesdatenschutzgesetz, Sozialgesetzbuch X, Landesverwaltungsgesetz) setzen für ihre richtige Auslegung ein Mindestmaß an IT-Kenntnissen voraus. Automatisierte Verfahren bestehen nun einmal nicht nur aus dem PC, sondern aus den vier Elementen "Hardware", "Software", "Daten" und vor allen Dingen der "Orgware". Jedes Element hat vielfältige Beziehungen zu allen anderen. Im Hinblick auf die IT-Planung ist daher jedem von ihnen eine gleichgroße Bedeutung beizumessen. Planungsfehler in einem Bereich haben häufig negative Auswirkungen in allen anderen Bereichen. Dabei geht es nicht nur um so vordergründige Probleme, daß zu geringe technische Kapazitäten den Einsatz bestimmter Softwareprodukte unmöglich machen, Mängel in der Datenorganisation zu inkonsistenten Dateien führen oder unzureichende Tests falsche Ergebnisse nach sich ziehen. Als die eigentliche Achillesferse stellt sich in der Praxis die Orgware dar. Wer das Ziel und die Rahmenbedingungen einer IT-Maßnahme nicht klar definiert, kann nicht erwarten, daß die Ergebnisse optimal sind.


Wenn wir derartige Schwachstellen bei unseren Prüfungen kritisieren, ist daher nicht zu akzeptieren, daß "der Datenschutz" für die manchmal nicht unerheblichen "Korrekturkosten" verantwortlich gemacht wird. In der Regel gelangen die Diskussionen erst dann wieder in die richtige Richtung, wenn wir Antwort auf die Frage verlangen: "Wären die Sicherheitsrisiken und die rechtlichen Probleme nicht vorhanden, wenn es das Datenschutzrecht nicht gäbe?" (vgl. zu dieser Thematik auch 18. TB, Tz. 6.1 bis Tz. 6.3 und Tz. 6.7.3 sowie Tz. 6.2 dieses Berichtes).

Was ist zu tun?
Die für den Einsatz von Informationstechnik in der öffentlichen Verwaltung verantwortlichen Entscheidungsträger müssen der Planung automatisierter Verfahren eine größere Bedeutung beimessen und von der Vorstellung abrücken, daß Technik von sich aus die Lösung aller Probleme bringt.

6.2

Der Beratungsbedarf der Kommunen und anderer kleinerer Organisationseinheiten

IT-Konzepte sind als Grundlage für die Realisierungsphase automatisierter Verfahren unverzichtbar. Behörden, die nicht in der Lage sind, derartige Soll-Regelungen zu erstellen, sind auf externe Berater angewiesen. Immer mehr Behörden wollen deshalb die Dienste des Datenschutzbeauftragten in Anspruch nehmen.

Unter Tz. Textziffer 1.2 des 18. Tätigkeitsberichtes ist dargestellt worden, in welchem Umfang in den nächsten Jahren von den datenverarbeitenden Stellen im Lande in Informationstechnik investiert werden wird. Zu einem wesentlichen Teil werden diese Investitionen von kleineren Organisationseinheiten mit einem Mitarbeiterstamm zwischen 12 und 20 Personen getätigt. Gleichwohl belaufen sich die Kosten für die Neuinstallation bzw. die Umstellung der bestehenden Hard- und Software auf die neuen Gegebenheiten nicht selten auf Größenordnungen von mehr als 500.000 DM. Selbst bei einem solchen Finanzvolumen verzichten die meisten Behörden auf die Erstellung von IT-Konzepten als Grundlage für die Realisierung des Projektes, weil ihnen das Know-how und die personellen Kapazitäten fehlen. Die Einschaltung externer Berater stößt allein schon deshalb auf Schwierigkeiten, weil man sich schwertut, den Beratern die Zielrichtung des gewünschten Konzeptes zu erläutern. Behörden, die derartige IT-Konzepte in Auftrag gegeben haben, ohne ihre Wünsche zu konkretisieren, erhielten für viel Geld voluminöse Abhandlungen über IT-Philosophien, Prozessor-Kapazitäten und Netztopologien, aber keine konkreten und unmittelbar umsetzbaren Vorschläge für die Problemlösungen.

Wenn wir in dieser Situation um Hilfe gebeten werden, können wir natürlich nicht als Unternehmensberater agieren, dies ist weder unser gesetzlicher Auftrag, noch verfügen wir über die personellen Kapazitäten. Wir schlagen den Behörden jedoch vor, von den externen Beratern bzw. von ihren eigenen "IT-Spezialisten" ein IT-Konzept zu verlangen, das wie folgt strukturiert ist:

a) Beschreibung der Möglichkeiten zur Effizienzsteigerung und Qualitätsverbesserung durch einen IT-Einsatz, bezogen auf die konkreten Gegebenheiten in der betreffenden Behörde.

b) Vorschläge zum Software-Einsatz, um die unter a) genannten Ziele zu erreichen.

c) Vorschläge zur technischen Ausgestaltung der einzelnen Arbeitsplätze unter Berücksichtigung der unter a) und b) gemachten Vorschläge.

d) Ggf. Vorschläge zur Vernetzung der Arbeitsplatzrechner mit Server/n unter Berücksichtigung der tatsächlichen baulichen Gegebenheiten und der sich aus a) bis c) ergebenden Konsequenzen.

e) Ggf. Vorschläge zur technischen Ausgestaltung der Server unter Berücksichtigung der sich aus a) bis d) ergebenden Konsequenzen.

f) Darstellung der aufbau- und ablauforganisatorischen sowie der systemtechnischen Konsequenzen unter der Annahme, daß entsprechend a) bis e) verfahren wird; Fortschreibung des bisherigen Aufgabengliederungsplans (Geschäftsverteilungsplans) unter Berücksichtigung der IT-bedingten Funktionen und Schnittstellen (Hard- und Software-Administration, Verantwortungsverteilung zwischen den Fachabteilungen und der IT-Abteilung sowie evtl. externen Dienstleistern).

g) Vorschläge zur Ausgestaltung von IT-Dienstanweisungen, bezogen auf die konkreten personellen und organisatorischen Gegebenheiten und unter Berücksichtigung der sich aus a) bis f) ergebenden Konsequenzen.

h) Vorschläge zur zeitlichen Realisierung der einzelnen sich aus a) bis f) ergebenden Maßnahmen; Darstellung verschiedener Handlungsalternativen und ihrer Konsequenzen.

i) Entwicklung eines Schulungsplans unter Berücksichtigung der tatsächlichen personellen Situation sowie der Vorschläge zu den aufbau- und ablauforganisatorischen Maßnahmen und des Realisierungsplanes.

j) Darstellung der finanziellen Auswirkungen der Vorschläge und Maßnahmen; Entwurf einer Kosten-Nutzen-Relation.

Unabhängig von der Größe des jeweiligen Vorhabens (von der Einführung eines neuen Sozialhilfeverfahrens in einer kleinen Amtsverwaltung bis hin zur völligen Reorganisation einer großen Stadtverwaltung) führen "handwerklich sauber" erarbeitete Vorschläge für die einzelnen Komplexe zu einer aussagefähigen Entscheidungsgrundlage und - wenn es denn so beschlossen wird - zu einer vernünftigen Soll-Regelung.

Hinzu kommt ein weiterer wichtiger Aspekt: Ein so gestaltetes IT-Konzept läßt zweifelsfrei erkennen, was gewollt ist. Darauf aufbauend kann in einem Sicherheitskonzept relativ einfach dargestellt werden, wie verhindert werden soll, daß alles, was nicht gewollt ist, auch nicht möglich ist (vgl. 18. TB, Tz. 6.2). Liegt ein schlüssiges IT-Konzept vor, ist es für uns deshalb auch viel leichter möglich, zu Sicherheitsfragen beratend Stellung zu nehmen.

Der Nutzen einer solchen Beratung spricht sich offenbar zunehmend herum. Unsere hierfür zuständigen Mitarbeiter sind zur Zeit sechs Monate im voraus "ausgebucht".

Was ist zu tun?
Behörden, die in Informationstechniken investieren, sollten von ihren Beratern in sich schlüssige, unmittelbar umsetzbare IT-Konzepte verlangen; dazu müssen sie ihnen aber auch ihre Zielvorstellungen und die rechtlichen Rahmenbedingungen transparent machen.

6.3

Kurswechsel bei der Automationskommission


Selbst sorgfältige Softwaretests schließen Programmfehler nicht aus. Unzureichende und methodisch fragwürdige Prüfungen vor dem Echteinsatz automatisierter Verfahren müssen daher schon fast als grobe Fahrlässigkeit betrachtet werden. Dem will die Automationskommission der kommunalen Landesverbände jetzt Rechnung tragen.

Seit Jahren kritisieren wir die Vorgehensweise beim Test von Programmen und automatisierten Verfahren, die im kommunalen Bereich eingesetzt werden (vgl. 13. TB, Tz. 6.3).Zu häufig kommt es vor, daß Software und technische Lösungen eingesetzt werden, die weder den rechtlichen noch den sicherheitstechnischen Anforderungen entsprechen, weil insbesondere die kleineren Organisationseinheiten sich nicht in der Lage sehen, jedes einzelne Produkt detaillierten Tests zu unterziehen. Sie vertrauen auf entsprechende Prüfungen durch die Automationskommission der kommunalen Landesverbände und deren Gremien. Aber auch deren Organisationsstrukturen und Kapazitäten waren bisher nicht so ausgelegt, daß eine wirkungsvolle Kontrolle der Produkte der am Markt agierenden Softwarehäuser möglich war.

Selbst eine bindende Anweisung des Innenministeriums aus dem Jahre 1990, in dem Bereich des Meldewesens ausschließlich von Melderechtsspezialisten getestete Software einzusetzen, wurde bislang nur sehr eingeschränkt befolgt. Eine Freigabeempfehlung nach entsprechenden Prüfungen durch eine damit beauftragte "Testkommune" wurde für ein Produkt der Datenzentrale erst ausgesprochen, nachdem über 50 Kommunen diese Programme bereits länger als ein Jahr in der Praxis einsetzten. Glücklicherweise wurden bei den verspäteten Tests keine gravierenden Fehler entdeckt.

Vor diesem Hintergrund hat die Automationskommission nunmehr "Empfehlungen zur Neufassung der Aufgabenstellung der Automationskommission und ihrer Gremien" sowie "Empfehlungen zum Test und zur Freigabe von IT-Produkten in Kommunen" erarbeitet und der Arbeitsgemeinschaft der kommunalen Landesverbände zur Beschlußfassung vorgelegt.

Die Kommission folgt damit weitgehend den Vorschlägen, die wir im Rahmen unserer beratenden Mitarbeit gemacht haben:

  • Es sollte grundsätzlich zwischen dem Test von Software und der Freigabe von Verfahren unterschieden werden. In der Datenschutzverordung ist nämlich ausdrücklich festgelegt, daß die Einsatzfreigabe der automatisierten Verfahren durch die datenverarbeitenden Stellen selbst zu erfolgen hat. Für die Durchführung von Testarbeiten können sie sich dagegen der Unterstützung von Dienstleistern bedienen. Dies kann jedoch nur im Wege der Auftragserteilung geschehen, die rechtliche Verantwortung verbleibt bei der Stelle, die das jeweilige Verwaltungsverfahren betreibt.

  • Wird Software von einer Vielzahl von Anwendern in gleicher Weise eingesetzt, erscheint es nicht ökonomisch, daß jeder zusätzliche Anwender sich erneut davon überzeugt, daß die Programme die zu erwartenden (richtigen) Ergebnisse erbringen. Will man sich jedoch auf die Testergebnisse der bisherigen Anwender verlassen, müssen Art und Umfang dieser Tests bekannt und dokumentiert, das Testergebnis schriftlich fixiert und die getesteten Programmversionen exakt bezeichnet sein.

  • Bisher bezogen sich die Überlegungen der Kommunen zu dem Problem "Test mit Wirkung für andere" nur auf Software, die von der Datenzentrale entwickelt worden ist. Im Zeichen einer immer breiteren Angebotspalette auch für den kommunalen Bereich erscheint eine solche Begrenzung weder sinnvoll noch erforderlich. Es sollten daher grundsätzlich alle Anbieter die Möglichkeit haben, ein anerkanntes Testat für ihre Produkte zu erhalten.

  • Die Initiative zur Erlangung eines Testats sollte grundsätzlich von dem jeweiligen Anbieter ausgehen. Er sollte alle mit dem Test in Zusammenhang stehenden Leistungen zu erbringen und die daraus resultierenden Kosten zu tragen haben.

  • Die Auswahl der Tester sollte dem Anbieter obliegen. Grundsätzlich sollten mindestens zwei Stellen mit der Durchführung des Tests beauftragt werden. Es sollte sich um Mitglieder der kommunalen Landesverbände handeln. Die Tester sollten nur Verpflichtungen gegenüber dem Anbieter, nicht aber gegenüber der Automationskommission eingehen. Die Vereinbarungen zwischen dem Anbieter und den Testern sollten allerdings schriftlich fixiert sein.

  • Vor Durchführung der Tests sollte vom Anbieter ein Testkonzept zu enwickeln und mit den Testern und den Gremien der Automationskommission abzustimmen sein. In ihm wären folgende Punkte schriftlich zu fixieren:

    • Gegenstand des Tests (Verfahren, Programme, Versionen),

    • zu beachtende rechtliche Grundlagen,

    • sonstige zu beachtende Vorgaben (z.B. Pflichtenheft, Softwareentwicklungsauftrag, Schnittstellen zu anderen Verfahren, Sicherheitskriterien),

    • Testumgebung (Testsystem, flankierende Software),

    • Testmethoden (Pilotierung, Schattenläufe, Simulation mit Testfällen, Integrationstest),

    • Dokumentation der Testfälle, der zu erzielenden Arbeitsergebnisse und der tatsächlichen Ergebnisse,

    • Form des Testprotokolls (verbale Beschreibung des Ablaufs, Systemprotokolle, Listen),

    • Form des Testats,

    • zu beteiligende Institutionen (z.B. Aufsichtsbehörden, Landesbeauftragter für den Datenschutz, Landesrechnungshof, Personalräte).

  • Das Testkonzept sollte einen kontinuierlichen Test von Software ermöglichen. Für den Fall, daß bei nachfolgenden Tests bisher nicht erkannte Fehler oder Mängel festgestellt werden, wäre zu gewährleisten, daß diese entweder unverzüglich behoben werden oder daß allen beteiligten Institutionen und Anwendern ein modifiziertes Testat zugeht. Die Tester sollten gehalten sein, Zweifelsfragen und Testfälle der Anwender in angemessener Zeit zu überprüfen bzw. abzuarbeiten. Sie sollten sich verpflichten, die von ihnen erstellten bzw. dokumentierten Testunterlagen und Testprotokolle nach Ablauf ihrer Tätigkeit ihren Nachfolgern zu übergeben.

  • Das Testat sollte hinreichend genau beschreiben, welche Produkte auf welche Weise mit welchem Ergebnis wann von wem getestet worden sind. Es sollte auch Auskunft darüber geben, welche Rahmenbedingungen (technische und organisatorische Einsatzvoraussetzungen) der künftige Anwender einzuhalten hat, um das beschriebene Testergebnis zu erzielen. Außerdem wäre sicherzustellen, daß Mängel, die gleichwohl dem positiven Testat nicht entgegengestanden haben, den künftigen Anwendern bekannt werden.

  • Bietet ein Anbieter sein Produkt als "Paketlösung" (d.h. als integraler Teil eines Hardware-, Software- und Organisationskonzeptes) an, so sollte das Testat auch eine Bewertung dieser Komponenten bzw. Lösungen enthalten (Qualität der Handbücher, Wirksamkeit von Sicherheitsmaßnahmen, Fragen der Systemadministration usw.).

  • Das abschließende Votum darüber, ob und in welchem Umfang aufgrund des Testats künftige Anwender auf eigene Tests verzichten können, sollte der Automationskommission bzw. ihren Gremien obliegen. Die Beschlußfassung hierüber sollte protokolliert werden. Die Anbieter wären zu unterrichten. Erst danach wären sie berechtigt, ihre Software als von den kommunalen Landesverbänden testiert zu bezeichnen.

  • Der Anbieter sollte sich verpflichten, jeder Auslieferung an ein Mitglied der kommunalen Landesverbände das betreffende Testat beizufügen.


Eine Entscheidung der Arbeitsgemeinschaft der kommunalen Landesverbände stand zum Zeitpunkt des Redaktionsschlusses dieses Berichtes noch aus.

Was ist zu tun?
Die Gremien der "kommunalen Familie" sollten sich konsequent für effektive aufbau- und ablauforganisatorische Maßnahmen im Zusammenhang mit dem Test von IT-Produkten einsetzen. Zum eigenen Nutzen, insbesondere aber zum Nutzen der betroffenen Bürger, sollten die Empfehlungen der Automationskommission kurzfristig in Kraft gesetzt werden.

6.4

Sicherheitsrisiken durch Standardsoftware


Im Gegensatz zur Individualsoftware, die exakt auf die Bedürfnisse des Benutzers zugeschnitten wird, deckt die Standardsoftware, z.B. für Textverarbeitung, Graphik- oder Präsentationserstellung, Tabellenkalkulation oder Datenbankverwaltung meist ein größeres Spektrum an Funktionen ab, als der Anwender eigentlich braucht. Dies ist einer der Gründe, weshalb beim Einsatz von Standardsoftware oft Sicherheitsrisiken entstehen.

Durch eine entsprechende Systemkonfiguration muß technisch gewährleistet sein, daß der Benutzer eines Computersystems nur Aktionen ausführen kann, zu denen er berechtigt ist. Passend für jeden Benutzer müssen die Berechtigungen für den Zugriff auf Programme und Daten sowie für das Ausführen bestimmter Aktionen eingestellt werden. Bietet das vorhandene Betriebssystem nicht die Möglichkeit, wirksame Zugriffsbeschränkungen zu realisieren, muß zu diesem Zweck zusätzliche Sicherheitssoftware installiert werden.

Anschließend kann man eine auf den Anwender zugeschnittene Benutzungsoberfläche entwerfen, die ebenfalls nur die zugelassenen Aktionen ermöglichen und andere Funktionalität gar nicht anbieten soll. Im Gegensatz zu den Zugriffsrechten, die unmittelbar im Betriebssystem verankert sind, ist eine Benutzungsoberfläche allerdings in der Regel nur "aufgesetzt". Der Einsatz von "multifunktionaler" Standardsoftware führt leider oft zu Schwächen in beiden Bereichen:

  • Bei dem Microsoft-Office-Paket läßt sich z.B. zwar die Funktionsauswahl in dem Menü und über Piktogramme relativ frei konfigurieren. Eine Beschränkung kann jedoch durch den Nutzer jederzeit rückgängig gemacht werden, wenn die entsprechende Datei nicht vor Veränderungen geschützt wird.

  • Mit der nicht deaktivierbaren Makrosprache steht dem Benutzer eine mächtige Programmiersprache zur Verfügung (vgl. 18. TB, Tz. 6.5). Makroviren, die durch Dokumentenaustausch übertragen werden, sind inzwischen verbreitet, selbst im Bereich der Landesverwaltung. Die Ausführung solcher Makroprogramme ist zwar an die Zugriffsrechte des Anwenders gebunden, doch entfalten deren destruktive Aktionen außerordentlich gefährliche Wirkungen, wenn sie von Benutzern mit umfassenderen Zugriffsberechtigungen (Systemadministratoren, Dienststellenleitung oder Schreibdienst) aufgerufen werden.

  • Die Zugriffsrechte können oft nicht so restriktiv vergeben werden, wie es sinnvoll wäre. Meist funktionieren die Produkte nur dann, wenn der Anwender im Programmverzeichnis, im Verzeichnis mit der Systemsoftware und in einem Druckverzeichnis (Spool) weitreichende Berechtigungen hat. Den Benutzern werden im Interesse eines problemlosen Software-Einsatzes häufig technische "Generalvollmachten" ausgestellt.

  • Die meisten Produkte ermöglichen eine Kommunikation oder einen (automatisierbaren) Datenaustausch mit anderen Programmen. Der dadurch erheblich erweiterte Funktionsumfang läßt sich in der Regel nicht ausreichend reduzieren.

  • Häufig steht der Quellcode nicht zur Verfügung. Bei Firmen in Quasimonopolstellung basiert ein wesentlicher Marktvorteil gerade auf der fehlenden Dokumentation bestimmter Bereiche, denn dies garantiert, daß nur die eigene Firma paßgenau Erweiterungen und neue Versionen liefern kann. Bücher über "Undocumented Features" sind keine Seltenheit mehr. Durch diese mangelnde Transparenz können "Hintertüren" und Sicherheitslücken vom Benutzer nicht ausgeschlossen werden.

Was ist zu tun?
Die Systemverantwortlichen sollten beobachten, welche Sicherheitslücken bei der von ihnen eingesetzten Software bekannt werden, und sofort Gegenmaßnahmen ergreifen. Generell können nur ausgefeilte Zugriffsrechte das Schlimmste verhindern.

6.5

Geringe Lernbereitschaft bei Führungskräften?


Führungskräfte scheuen sich offenbar vor einer intensiven Auseinandersetzung mit den Fragen des Datenschutzes und der Datensicherheit. Entsprechende Kurse der DATENSCHUTZAKADEMIE werden jedenfalls nicht ausreichend in Anspruch genommen.

Seit Jahren versuchen wir in unseren Beratungsgesprächen und im Rahmen der Prüfungsmaßnahmen den Behörden im Lande deutlich zu machen, daß der Slogan "Datenschutz und Datensicherheit sind Chefsache!" eben nicht nur ein Programmsatz ist, sondern die zwingende Konsequenz aus den rechtlichen und sicherheitstechnischen Problemstellungen im Zusammenhang mit der automatisierten (und natürlich auch der konventionellen) Verarbeitung personenbezogener Daten. Den Entscheidungsträgern in der öffentlichen Verwaltung die einschlägigen Kenntnisse zu vermitteln war deshalb ein wesentlicher Grund für den Aufbau der DATENSCHUTZAKADEMIE. Von Anfang an wird ein dreitägiger Kursus speziell für Führungskräfte angeboten. Namhafte Referenten halten Vorträge zu folgenden Themen:

  • Risiken der elektronischen Datenverarbeitung für das Persönlichkeitsrecht
  • Grundzüge des Bundes- und des Landesdatenschutzgesetzes
  • Einführung in das bereichsspezifische Datenschutzrecht
  • Technische und organisatorische Maßnahmen zur Datensicherheit
  • Revisionsfähigkeit und Ordnungsmäßigkeit der Datenverarbeitung
  • Datenschutzverordnung des Landes Schleswig-Holstein
  • Koordinierungs- und Normungsbemühungen der IT-Kommission des Landes und der Automationskommission der kommunalen Landesverbände
  • Besonderheiten bei der Auftragsdatenverarbeitung
  • Grundzüge der Datenschutzregelungen für die Wirtschaft
  • Darstellung der Maßnahmen zur Datensicherheit bei der Datenzentrale Schleswig-Holstein
  • Praktische Umsetzung des Datenschutzes in den Behörden

Während alle anderen Veranstaltungen gut ausgebucht, teilweise sogar "überlaufen" sind, läßt die Resonanz auf das Angebot gerade bei Führungskräften sehr zu wünschen übrig.


Natürlich haben wir nach Gründen für die Abstinenz gesucht. Unisono versicherten die von uns befragten Führungskräfte, daß das Thema wichtig und das Angebot attraktiv sei. Auch hätten die Teilnehmer sich durchweg positiv geäußert. Das Problem sei aber die dreitägige Dauer. Über einen so langen Zeitraum könne man sich wegen der hohenArbeitsbelastung nicht aus dem Tagesgeschäft ausklinken. Tragendes Argument hin, vorgeschobene Ausrede her, wir haben reagiert und bieten ab 1997 weiterhin einen nunmehr aber nur zweitägigen Kursus für Entscheidungsträger an. Über die Resonanz werden wir berichten.

Was ist zu tun?
Führungskräften in der öffentlichen Verwaltung sollte die Verantwortung für den IT-Einsatz bei der personenbezogenen Datenverarbeitung erst dann übertragen werden, wenn sie den Nachweis der erforderlichen Sachkunde auf diesem Gebiet erbringen können.

6.6

Ergebnisse von Kontrollen im Bereich der automatisierten Datenverarbeitung

6.6.1

Sicherheit und Ordnungsmäßigkeit der Datenverarbeitung der Kommunen: nicht ohne Beanstandungen


In dem Maße, wie die Anforderungen an die Datenverarbeitung steigen, vergrößern sich die Sicherheitsrisiken. Viele Kommunen sind überfordert, können und wollen sich aber nicht beschränken. Bei unseren Kontrollen sind nach wie vor viele Fehler zu beanstanden.

Die im Jahre 1995 begonnenen Schwerpunktprüfungen in Kommunalverwaltungen mittlerer Größe sind konsequent fortgesetzt worden, weil die Ergebnisse und Reaktionen der geprüften Stellen einen dringenden "Bedarf" anzeigen. Die vorgefundenen "Verhältnisse" sprechen für sich und sind denen aus dem Vorjahr (vgl. 18. TB, Tz. 6.7.3) durchaus vergleichbar. Ein Auszug aus den Prüfungsprotokollen:

  • Vor dem Echteinsatz von Software wurden keine Tests durchgeführt.

  • Softwareänderungen durch den Anbieter wurden von der Verwaltung übernommen, ohne zu fragen, warum eine Änderung der Programme erforderlich wurde.

  • Änderungen an Betriebssystemen, Programmen und Datenbeständen konnten ohne Protokollierung vorgenommen werden.

  • Die Aktivitäten von externen Dienstleistern (Softwarehäuser, Systemlieferanten) wurden nicht überwacht bzw. konnten wegen fehlender Fachkenntnisse gar nicht überwacht werden.

  • Die Speicherung von Textdokumenten mit personenbezogenem Inhalt erfolgte ohne jeden Sinn, bis die "Platte platzte". Der "Rekord" lag bei 2300 Dokumenten aus drei Jahren, wobei es sich bei den meisten um Schriftverkehr aus dem Sozialamt handelte.

  • Mitarbeiter bauten ihre eigenen Datenbestände auf, eine Kontrolle fand nicht statt.

  • Vorgesetzte mit Kontrollverantwortung waren über die tatsächlichen Verfahrensweisen nicht informiert und mangels Know-how auch gar nicht in der Lage, ihrer Kontrollpflicht nachzukommen.

  • Die Fernwartungsaktivitäten externer Dienstleister konnten nicht überprüft werden, weil niemand in den Behörden verstand, "was da abläuft".

  • Einzelplatz-PC wurden eingesetzt, ohne jedwede Maßnahmen zur Datensicherheit zu ergreifen.

  • Es wurde den Normalbenutzern völlig überflüssige Software zur Verfügung gestellt (z.B. alle gängigen Computerspiele, WISO-Tips aus der bekannten Fernsehsendung, Hilfen zur Erstellung von Steuererklärungen, aber auch Tools zur Daten- und Systemmanipulation wie XT-Gold und Norton-Commander).

  • Es war undokumentierte Software verfügbar, die von einem Mitarbeiter erstellt wurde, der längst nicht mehr in der betreffenden Behörde beschäftigt war.

  • Es fehlten schriftliche Anweisungen für Mitarbeiter, die mit der Systemadministration betraut waren.

Zwei bezeichnende Sachverhalte lassen sich nicht in einem Satz darstellen:

  • In einem Sozialamt fiel der Zentralrechner aus. Im Rahmen der Beseitigung der Störung ergab sich folgender Ablauf:

    • Der zuständige Systembetreuer war zu diesem Zeitpunkt in Urlaub. Eine Vertretung, die über die erforderlichen Kenntnisse verfügte, war nicht greifbar.

    • Der für die Datensicherung zuständige Mitarbeiter des Sozialamtes war seit einigen Tagen krank. Sicherungskopien waren in dieser Zeit nicht angefertigt worden.

    • Die Verwaltung beauftragte eine ortsansässige Servicefirma, den Fehler auf dem Zentralrechner zu beseitigen.

    • Die Firma konnte den Fehler "vor Ort" nicht finden und brachte den Zentralrechner mit dem gesamten Datenbestand in ihre Werkstatt. Sie stellte dort einen Festplattendefekt fest.

    • Der Rechner wurde daraufhin auf Anweisung der Verwaltung von der Servicefirma an die Auslieferungsfirma übergeben, um noch bestehende Garantieleistungen in Anspruch zu nehmen.

    • Die Garantiezeit war jedoch erloschen, so daß die Lieferfirma den Rechner mit dem Datenbestand wieder zur Servicefirma zurückbrachte.

    • Diese stellte dem Sozialamt ein Ersatzgerät zur Verfügung und generierte hierauf die Daten der letzten Datensicherung.

    • Das Sozialamt schloß sodann für zwei Tage seine Türen, um den nicht gesicherten Datenbestand von drei Tagen zu rekonstruieren.

    • Nach einigen Tagen wurde der reparierte Rechner von der Servicefirma zurückgeliefert.

    • Die Daten wurden sodann vom Ersatzgerät auf den reparierten Rechner übertragen.

    • Das Ersatzgerät wurde mit dem gesamten Datenbestand der Servicefirma übergeben.

    • Sofern diese Firma die Daten noch nicht gelöscht hat, verfügt sie seitdem über den damals aktuellen Bestand an Sozialhilfedaten, Wohngelddaten und den Schriftverkehr des Sozialamtes, insgesamt einige Tausend Datensätze.

  • In einem anderen Sozialamt fehlten ausreichende und verschließbare Büroschränke, um die Akten sachgerecht zu lagern. Deshalb begann man, die Akten auf dem Fußboden zu stapeln. Als der Platz dort nicht mehr ausreichte, wurden die Fensterbänke belegt. Da die Fenster im Erdgeschoß des Gebäudes aber vom Bürgersteig aus einsehbar waren, dachte man sich eine "hochwirksame" Sicherheitsmaßnahme aus. Die Akten wurden umgedreht, so daß die Namen der Sozialhilfeempfänger von der Straße aus nicht erkennbar waren.

Wie reagierten die geprüften Stellen auf diese Feststellungen? In keinem einzigen Fall wurde den Beanstandungen widersprochen. Im Gegenteil, man bat uns um eine eingehende Beratung, um die Mängel abzustellen. Allerdings ließ das Tempo der Abarbeitung der Probleme in dem Maße nach, wie sich der "Schock" über die vielen Beanstandungen legte. Zitat eines Bürgermeisters: "Es ist erforderlich, daß eine völlig neue Konzeption für die Datenverarbeitung erstellt wird, die sämtliche Bereiche der Verwaltung erfaßt. Die Erstellung dieser Konzeption wird durch den Organisator erfolgen. Da es sich hierbei um eine sehr zeitintensive Aufgabe handelt und der Mitarbeiter lediglich zu 50 Prozent seiner Tätigkeit Aufgaben der Datenverarbeitung wahrnimmt, kann eine fertige Konzeption frühestens ... vorgelegt werden."

Daneben waren weiterhin Beanstandungen im Zusammenhang mit der von der Datenzentrale vertriebenen MOSAIK-Software, insbesondere bezüglich des Finanzinformationssystems, auszusprechen. Die im 18. Tätigkeitsbericht (vgl. Tz. 6.7.3) dargestellten Rechts- und Sicherheitsprobleme bestehen nach wie vor fort. Zur Erinnerung: Es ging um

  • unzureichende Zugriffsbeschränkungen,
  • mangelnde Abschottung der Administrationsebene,
  • fehlende Tests und Freigabeempfehlungen,
  • unzureichende Überwachung von Fernwartungen,
  • fehlende Sicherheitskonzepte.

Die Absicht der Datenzentrale, diese Lücken im Verlaufe des Jahres 1996 zu schließen, wurde bis Redaktionsschluß offenbar nicht in die Tat umgesetzt. Auf Anfrage teilte sie mit, man habe zunächst ein Konzept erarbeitet, das vorsah, die Vergabe der Zugriffsrechte auf Haushaltsstellen auszudehnen. Bei der Realisierung habe sich ergeben, daß die notwendige Definition von gesonderten Gruppenrechten bei den jeweiligen Kundenverwaltungen einen auch aus deren Sicht unverhältnismäßig hohen Administrationsaufwand zur Folge gehabt hätte. Deshalb mußte ein anderer Weg beschritten werden. Außerdem sei die Selektionslogik für die Anzeige der Haushaltsstellen anzupassen und auch der Bereich der Haushaltsüberwachung in den Zugriffsschutz einzubeziehen gewesen. Dies habe einen beträchtlichen Aufwand verursacht, da die Änderungen und Erweiterungen nachträglich in das bereits im Prinzip fertige Verfahren integriert werden mußten. Man habe daher nicht die gesamte neue Funktionalität zur Verfügung stellen können. Dies werde in 1997 nachgeholt.


Da wir nicht nur die Zugriffsbeschränkungen in der Teilanwendung "Finanzinformationssystem" als problematisch erachten, und bei Prüfungen nur schwer zu erkennen ist, welche der von der Datenzentrale angebotenen Funktionen vom Kunden nicht genutzt werden, haben wir den Beteiligten eine Art "Musterprüfung MOSAIK" angeboten. Wir hoffen, daß die Datenzentrale und einer ihrer Kunden die Hardware-, Software- und Organisationskonzepte des MOSAIK einmal in der optimalen Weise umsetzen, um feststellen zu können, ob auch dann noch datenschutzrechtliche Defizite bestehen.

Was ist zu tun?
Die Kommunalaufsicht, die kommunalen Landesverbände, die Datenzentrale und die anderen IT-Dienstleister sollten sich an einen Tisch setzen und Musterlösungen für den kommunalen Bereich erarbeiten.

6.6.2

Zum Stellenwert des Patientengeheimnisses in einem Krankenhaus

Der Inhalt medizinischer Unterlagen unterliegt einem besonderen Berufsgeheimnis. Da muß man erwarten, daß gerade ein Krankenhaus in öffentlicher Trägerschaft auch besondere Sicherungsmaßnahmen ergreift. Eine datenschutzrechtliche Überprüfung zeigte vielfältige Mängel auf.

Wann immer man ein Beispiel für den "traditionellen" Datenschutz sucht, wird das Arztgeheimnis, genauer das Patientengeheimnis, angeführt. Geradezu selbstverständlich ist die Annahme, daß persönliche Dinge, die man einem Arzt anvertraut, anderen Personen oder Stellen nicht zur Kenntnis gelangen. Jede öffentlich bekanntwerdende Gefährdung dieses "Rechtsgutes von höchstem emotionalen Rang" führt zu heftigen Reaktionen. Aus diesem Grunde richten auch wir seit geraumer Zeit unser besonderes Augenmerk auf die Datenverarbeitung durch die Ärzte und die Verwaltungsstellen der Krankenhäuser in öffentlicher Trägerschaft (niedergelassene Ärzte und Privatkliniken unterliegen nicht unserer Kontrolle). Nach Prüfungen in Universitätskliniken und ersten Prüfungen in Kreiskrankenhäusern (vgl. 16. TB, Tz. 6.6.4 und 18. TB, Tz. 6.7.2) haben wir das "Programm" auf der Ebene der kommunalen Krankenhäuser fortgesetzt.

Das Kreiskrankenhaus in Elmshorn, eines von vier Krankenhäusern eines Eigenbetriebes des Kreises Pinneberg, steht kurz davor, eine psychiatrische Abteilung zu eröffnen. Da traf es sich gut, die automatisierte Datenverarbeitung einem "Sicherheitscheck" zu unterziehen, bevor dort die Computer auch in einem der sensibelsten Bereiche der Krankenversorgung eingesetzt werden.

Zu unserer Überraschung mußten wir feststellen, daß trotz der Größe des Eigenbetriebes (die Kapazität liegt bei ca. 900 Betten) keine verbindlichen Regelungen zur Gestaltung des Einsatzes von Informationstechnik erlassen worden sind. Mithin war eine systematische Analyse und Bewertung der "Soll-Regelungen" sowie ein "Soll-Ist-Vergleich" nicht möglich. Die tatsächlich vorgefundenen Verfahrensweisen mußten daher als "von den Verantwortlichen so gewollt" interpretiert werden. Da auch kein Sicherheitskonzept vorgelegt werden konnte, wurde zur Ermittlung eines Maßstabes zur Beurteilung der Maßnahmen in bezug auf die automatisierten Verfahren die Prüfung auf die papierene Behandlungsdokumentation ausgedehnt. Dieser Versuch erwies sich als ein "Volltreffer", weil eine Vielzahl von Unzulänglichkeiten zutage traten. Die Behandlung der Akten war aus folgenden Gründen ganz und gar nicht vorbildlich:

  • Die Verantwortung für das Archiv lag beim Verwaltungsdirektor, genutzt wurde es jedoch fast ausschließlich vom ärztlichen Bereich. Die Herausgabe von Akten wurde zwar registriert. Kamen sie allerdings nicht zurück, waren die Archivmitarbeiter machtlos. Zum Zeitpunkt der Prüfung war eine große Anzahl von Akten trotz mehrmaliger Mahnung auch mehrere Monate nach der Ausgabe noch nicht wieder an das Archiv zurückgegeben worden. Es konnte mithin nicht ausgeschlossen werden, daß sie "verschwunden" sind.

  • Die Archivmitarbeiter waren auch während der Dienstzeit nicht ständig im Archiv anwesend.

  • Bei Abwesenheit blieb die Eingangstür unverschlossen, da der Zugang zu einem Fax-Gerät, zu dem auf dem Flur gelagerten Kopierpapier und den Röntgenunterlagen, die von den Mitarbeitern des ärztlichen Bereichs selbst dem Archiv entnommen und zugeführt wurden, gewährleistet sein mußte.

  • Unser Prüfer hat sich über einen längeren Zeitraum unkontrolliert in einem Archivraum aufhalten können, während mehrere Personen das Archiv betraten und wieder verließen, zeitweilig hat er sich völlig allein im Archiv aufgehalten.

  • Auch wenn das Archivpersonal anwesend war, konnte es das "Kommen und Gehen" wegen der Verteilung der Akten auf mehrere Räume nicht überwachen. Die gezielte unbefugte Entnahme von Akten, eine Auswertung außerhalb des Archivs und eine Rückführung nach mehreren Tagen wäre nicht aufgefallen.

  • Teilweise wurden Akten auf dem Weg in den ärztlichen Bereich in sogenannten Postfächern zwischengelagert. Diese Fächer waren allgemein zugänglich.

Diesem zweifelsfrei zu niedrigen Sicherheitsniveau vergleichbar waren auch die Sicherungsmaßnahmen bezüglich der automatisierten Verfahren. Es wurden von uns daher u.a. folgende Sachverhalte beanstandet:

  • Für jeden stationär aufgenommenen Patienten wurde parallel zur papierenen Dokumentation in einer Datenbank ein Stammsatz angelegt, der u.a. folgende Merkmale enthielt: Name, Vorname, Anschrift, Familienstand, Konfession, Staatsangehörigkeit, Beruf, Diagnosen, Befunde, Abrechnungsdaten, Angehörige, Arbeitgeber. Die Datensätze wurden auch nach Abschluß der Behandlung und Abrechnung der Kosten nicht gelöscht. Zu welchen Zwecken die Daten auf Dauer gespeichert wurden, konnte im Rahmen der Prüfung nicht abschließend geklärt werden.

  • Allen Mitarbeitern der Systemadministration (also auch den Mitarbeitern des externen Softwarehauses) war jederzeit ein undokumentierter Zugriff auf alle Stammdatensätze möglich. Das galt z.B. auch für die Daten der Patienten der Belegärzte und der Personen, die zum Zwecke der ärztlichen Begutachtung stationär aufgenommen wurden.

  • Systematische Tests mit speziellen Testdaten zur Überprüfung der fachlichen Richtigkeit der Verfahren wurden nicht durchgeführt. Die Echtdaten wurden auch zu Testzwecken genutzt. Da allein in den letzten neun Monaten vor der Prüfung 34 Änderungen an der Software vorgenommen wurden, muß von einem permanenten Test mit Echtdaten ausgegangen werden.

  • Die Zuständigkeiten für die Freigabe der Hard- und Software zum Echteinsatz waren nicht eindeutig geregelt. De facto wurden die Entscheidungen von den Systemadministratoren getroffen. Sie agierten insoweit in einem "revisionsfreien" Raum.

  • Die vorhandenen Dokumentationsunterlagen waren nicht geeignet, die Verfahrensspezifikationen für einen sachverständigen Dritten nachvollziehbar zu machen.

  • Die Zugriffsbefugnisse auf die Patientenstammdaten waren nicht restriktiv genug gestaltet. So wurden z.B. dem Pförtnerdienst die Identitätsdaten, die Staatsangehörigkeit, die Konfession, der Familienstand und der Arbeitgeber aller Patienten, die in den letzten drei Jahren behandelt worden sind, angezeigt. Tatsächlich benötigte der Pförtnerdienst nur die Merkmale: Name, Vorname und Station der zum jeweiligen Zeitpunkt stationär aufgenommenen Patienten.

  • Die Benutzung von 20 unvernetzten Arbeitsplatzrechnern unterlag keinen sicherheitstechnischen Restriktionen. Teilweise war ein Paßwortschutz realisiert, der allerdings dazu führte, daß selbst Vorgesetzte nicht die Möglichkeit hatten, sich einen Überblick über die gespeicherten Daten zu verschaffen. In diesem Bereich wurden überwiegend Personaldaten verarbeitet.

Wir haben eine Reihe von Beanstandungen ausgesprochen und dem Kreis als dem Träger des Krankenhauses sowie der Geschäftsführung des Eigenbetriebes und der Krankenhausleitung in einem Zehn-Punkte-Katalog Vorschläge zur Verbesserung des Datenschutzes gemacht.

In einer ersten Stellungnahme hat die Geschäftsführung des Krankenhauses angekündigt, das Archiv künftig in die Verantwortung des ärztlichen Direktors zu übergeben. Über die Löschungsfristen für die Patientenstammsätze in dem Klinikinformationssystem konnte noch kein Einvernehmen erzielt werden. Hierüber sowie über die weiteren Beanstandungen, denen im Grundsatz nicht widersprochen wurde, sind wir zwischenzeitlich in die Beratungsphase eingetreten, in der wir das Krankenhaus bei der praktischen Umsetzung unterstützen.

6.6.3

Disziplinarverfahren auf PC vergessen

Bei der Kontrolle der EDV-Anwendungen in einer Krankenkasse fanden wir im wesentlichen vernetzte PC mit eigenen Festplatten. Auf einem dieser Geräte wurden bei einer Stichprobenkontrolle mehrere Texte gefunden, die nicht aus dieser Abteilung stammen konnten. Unter anderem handelte es sich um eine Sitzungsvorlage, die disziplinarische Ermittlungen gegen einen Mitarbeiter zum Gegenstand hatten. Es ging dabei um den Vorwurf der sexuellen Belästigung am Arbeitsplatz. Weiter fanden sich ein Schreiben in einer Widerspruchsangelegenheit sowie Aufstellungen über Wochenüberstunden anderer Mitarbeiter.

Uns wurde hierzu erklärt, das Gerät sei vor seinem Einsatz bereits in anderen Abteilungen verwandt worden. Offenbar seien die Texte bei der Übergabe versehentlich nicht gelöscht worden. Nach unserer Beanstandung wurde dies unverzüglich nachgeholt.


Zurück zum vorherigen Kapitel Zum Inhaltsverzeichnis Zum nächsten Kapitel