Der Bayerische Landesbeauftragte für den Datenschutz; Stand: 12.12.2002

17. Technischer und organisatorischer Bereich

17.1. Grundsatzthemen

17.1.1. Bayerisches Behördennetz

In meinem letzten Tätigkeitsbericht bin ich ausführlich auf die Entwicklung des Bayerischen Behördennetzes (BYBN) und des unter anderem damit verbundenen notwendigen Aufbaues einer Zertifizierungsstruktur zur sicheren Kommunikation eingegangen (vgl. 19. TB, Ziff. 17.1.2).

Im Berichtszeitraum wurde nun von einer Arbeitsgruppe unter Leitung des StMF in Zusammenarbeit mit einer Beratungsfirma der Entwurf einer Neukonzeption für das Bayerische Behördennetz, zukünftig BayKom genannt, erarbeitet. Neben der Berücksichtigung von wirtschaftlichen Aspekten ist eines der definierten Ziele der Neukonzeption auch die Gewährleistung höherer Sicherheitsanforderungen und -auflagen an den Betreiber. An den Beratungen der Arbeitsgruppe wurde teilweise auch meine Geschäftsstelle beteiligt, soweit es sich um datenschutzrelevante Teile des Konzeptes bzw. der daraus resultierenden Leistungsbeschreibung gehandelt hat. Ich habe mich für eine Präzisierung bezüglich einiger datenschutzrelevanter Formulierungen und Anforderungen eingesetzt. Das Bayerische Staatsministerium der Finanzen hat mir mitgeteilt, dass meine Anregungen bei der Überarbeitung der Leistungsbeschreibung berücksichtigt wurden.

Ein Zuschlag nach erfolgter Ausschreibung soll voraussichtlich Anfang 2003 erfolgen.

E-Mail

Auch in diesem Berichtszeitraum konnte der flächendeckende Einsatz einer starken Verschlüsselung unter Verwendung von S/MIME-Clients (z.B. Outlook 98, 2000 oder 2002) nicht umgesetzt werden. Mit ursächlich dafür ist die heterogene Softwareausstattung an den Arbeitsplätzen - von verwendeter Betriebssystemversion über verwendeten Mail-Client bis hin zum notwendigen Verzeichnisdienst.

Allerdings wurden inzwischen alle Behörden-Poststellen mit PGP ausgestattet, eine funktionierende Zertifizierungsstelle für PGP-Keys und ein Key-Server in Betrieb genommen - damit wäre ein sicherer E-Mail-Verkehr zwischen den angeschlossenen Poststellen und zwischen Bürger und Behörden jederzeit möglich - soweit der Bürger auf seinem heimischen PC ebenfalls PGP installiert hat. Leider hat die Firma NAI, der Lizenzinhaber von PGP, inzwischen angekündigt, das Produkt nicht mehr weiter zu entwickeln und den Support dafür eingestellt. Lediglich Fehlerbeseitigung wird noch für die Restlaufzeit der bestehenden Supportverträge Gewähr leistet. Nach derzeitiger Lage verbleibt allerdings das Nutzungsrecht der vom zentralen CERT beschafften und an die Poststellen verteilten PGP-Lizenzen auch nach Ablauf des Supportvertrages bei den derzeitigen Nutzern. Einer Weiterverwendung von PGP bis zur Installation einer endgültigen sicheren E-Mail-Lösung steht also nichts im Wege. Der im Herbst 2002 vollzogene Wechsel des Lizenzinhabers für PGP stellt eine Fortentwicklung des Produktes mit offengelegtem Quellcode und auch die Verfügbarkeit einer Freeware-Version für Privatanwender sicher.

Das vom Bundeswirtschaftsministerium favorisierte und auch geförderte Produkt OpenPGP wäre zwar grundsätzlich als durchaus empfehlenswerte Alternative anzusehen, allerdings ist meines Erachtens die von PGP gewohnte Benutzerfreundlichkeit, die besonders für den ungeübten Benutzer überaus wichtig ist, bei diesem Produkt noch nicht hinreichend gegeben. Außerdem hätte ein Produktwechsel für die Akzeptanz beim Nutzer sicher keine sehr förderliche Wirkung, da in den letzten Jahren im Bayerischen Behördennetz mehrfach verschiedene Produkte getestet wurden (vgl. 19. TB, Ziff. 17.1.2).

IuK-Gesetz

Mit in Kraft treten des IuK-Gesetzes (IuKG) vom 12.12.2001 (LTDrs 14/8267) - zur Ablösung des Gesetzes über die Organisation der elektronischen Datenverarbeitung im Freistaat Bayern (EDVG) vom 12.10.1970 (BayRS 200-3-I) - hat sich auch die Möglichkeit einer Neuorganisation der bisher stark zergliederten Gremien für den Bereich der Sicherheit im ressortübergreifenden Kommunikationsverbund ergeben. Zu diesen Gremien habe ich mich auch im Abschnitt 17.1.2 meines 19. Tätigkeitsberichts geäussert.

Der Koordinierungsausschuss IuK (KoAIuK) hat in seiner Sitzung vom 12. Juni 2002 festgelegt, dass die übergreifende Verantwortung für die IuK-Sicherheit im staatlichen Bereich dem Staatsministerium des Innern obliegt und hierzu die Institution eines "Chief Information Security Officer" (CISO) geschaffen wird. Zu dessen Unterstützung wird voraussichtlich beim Landesamt für Statistik und Datenverarbeitung ein "Computer Emergency und Response Team" (CERT) eingerichtet und ein Sicherheitsteam aus den von den Ressorts bestellten Beauftragten für die IT-Sicherheit gebildet.

Diese Entscheidung könnte die von mir schon lange angemahnte Grundlage für eine kompetente, über Ressortgrenzen hinweg bindende Instanz für die Sicherheit der elektronischen Kommunikation innerhalb der Bayerischen Behörden bilden und so zu einer Steigerung der Sicherheit im Bayerischen Behördennetz beitragen.

Elektronische Signatur von Dokumenten in der öffentlichen Verwaltung

Der Bayerische Ministerrat hat in seiner Sitzung vom 9. Juli 2002 beschlossen, in der Staatsverwaltung flächendeckend bis spätestens zum Jahr 2005 die qualifizierte elektronische Signatur einzuführen, um so eine sichere elektronische Kommunikation zwischen Verwaltung und Bürger zu gewährleisten - so weit diese Art der elektronischen Signatur rechtlich erforderlich ist. In diesem Zusammenhang verweise ich auf den Entwurf eines Gesetzes zur Stärkung der elektronischen Verwaltungstätigkeit, der inzwischen kurz vor der Verabschiedung steht. Mit ihm sollen z.B. Verwaltungsverfahrensgesetz, Meldegesetz dahingehend geändert werden, dass auch die elektronische Kommunikation zwischen Bürger und Verwaltung als rechtswirksam zugelassen und zunehmend ausgebaut wird.

Zur elektronischen Kommunikation innerhalb der Verwaltung hat der Bayerische Ministerrat überdies beschlossen, dass die Behörden des Freistaats Bayern zügig und flächendeckend mit dem Verfahren des Landesamtes für Statistik und Datenverarbeitung für sichere E-Mail ausgestattet werden. Dieses Verfahren nutzt die fortgeschrittene Signatur und ein Verschlüsselungsverfahren.

Zusammenfassung

Meiner immer wieder gestellten Forderung nach einer vertraulichen, authentischen und nicht manipulierbaren Datenübertragung ist noch nicht vollständig Rechnung getragen (es fehlen u.a. flächendeckende sichere E-Mail und Leitungsverschlüsselung - SSL).

Allerdings ist der Verwaltung durch den Ministerratsbeschluss ein eindeutiger Zeitrahmen zur Umsetzung der geforderten Maßnahmen gesetzt worden. Im Zusammenhang mit den erwähnten Neuregelungen des IuK-Gesetzes hoffe ich, dass sich dies als ein entscheidender Schritt zur Erfüllung meiner langjährigen Forderungen erweist.

17.1.2. eGovernment

Unter dem Sammelbegriff "eGovernment" sind drei verschiedene Anwendungsbereiche erkennbar:

• Verwaltung zu Bürger und umgekehrt (Government to Citizen - G2C)
• Verwaltung zu Wirtschaft und umgekehrt (Government to Business - G2B)
• Verwaltung zu Verwaltung und umgekehrt (Government to Government - G2G)

Beispiele für G2C in Bayern finden sich im Bereich der elektronischen Kommunikation im Media@KOMM-Projekt im Raum Nürnberg (vgl. 19. TB, Ziff. 17.3.2) sowie bei der elektronischen Steuererklärung ELSTER (vgl. 18. TB, Ziff. 19.3.12 und 19. TB, Ziff. 11.2) und in den in verschiedensten Behörden eingerichteten Bürgerbüros (vgl. 19. TB, Ziff. 8.5).

Als Beispiele für G2B in Bayern sei hier SOLUM-Star angeführt, auf das ich in den Abschnitten 7.6.9 und 18.2.4 meines 17. Tätigkeitsberichts bereits eingegangen bin, sowie das Projekt "Verdiensterhebung über das Internet" (vgl. 19. TB, Ziff. 17.3.10).

Für den Bereich G2G ist vor allem das Bayerische Behördennetz anzuführen, auf das ich zuletzt in Abschnitt 17.1.2 meines 19. Tätigkeitsberichts sowie hier in Abschnitt 17.1.1 eingegangen bin.

Die Fragen nach Datenschutz und Datensicherheit spielen beim eGovernment eine entscheidende Rolle - auch für dessen Akzeptanz durch Bürger und Wirtschaft. So stellt z.B. die aus operativer Sicht sicherlich wünschenswerte Möglichkeit nach automatisierten Datenabgleichen mit Melderegistern und deren technische Machbarkeit noch keine Rechtsgrundlage für deren Zulässigkeit dar.

Hier sind in letzter Zeit erhebliche Anstrengungen vom Gesetzgeber unternommen worden, bestehende Rechtsnormen um die Aspekte der elektronischen Datenverarbeitung zu ergänzen. Als Beispiele seien hier nur die Novellierungen des Verwaltungsverfahrensgesetzes, des Melderechtsrahmengesetzes und der Abgabenordnung genannt. Solange diese Novellierungsarbeiten und deren ggfs. erforderliche Umsetzung in Landesrecht jedoch nicht abgeschlossen sind, muss die Realisierung und Inbetriebnahme solcher innovativer Vorhaben bis dahin aufgeschoben werden, zumal insbesondere die jeweiligen zu beachtenden technischen und organisatorischen Rahmenbedingungen zum jetzigen Zeitpunkt nicht absehbar sind.

Grundsätzlich ist bei allen Lösungen aus technisch-organisatorischer Sicht zum einen sicherzustellen, dass eine sichere und vertrauliche Kommunikation zwischen den jeweiligen Kommunikationspartnern gewährleistet wird - ungeachtet des verwendeten und zugrundeliegenden Kommunikationsnetzes. Die technischen Mittel hierzu stehen in Form von Kryptografieprodukten auf dem Markt zur Verfügung - es gilt, die geeigneten auszuwählen und auch einzusetzen.

Zum anderen ist von Seiten der öffentlichen Verwaltung auch sicherzustellen, dass mit Anbindung der eigenen Datenverarbeitungsanlagen und Verwaltungsnetzwerke an offene oder öffentliche Netzwerke, d.h. mit der Herbeiführung von deren Erreichbarkeit von außen, für diese Systeme und die darauf verarbeiteten Daten keine zusätzlichen Risiken entstehen.

Die Datenschutzbeauftragten des Bundes und der Länder haben sich bereits in ihrer Entschließung "Vom Bürgerbüro zum Internet - Empfehlungen zum Datenschutz für eine serviceorientierte Verwaltung" anlässlich der 60. Datenschutzkonferenz vom 12./13.Oktober 2000 hierzu geäußert (vgl. 19. TB, Anlage 26). Die in Abschnitt 8.5 meines 19. Tätigkeitsbericht angesprochene Broschüre "Vom Bürgerbüro zum Internet - Empfehlungen zum Datenschutz für eine serviceorientierte Verwaltung" ist unter http://www.datenschutz-bayern.de/technik/grundsatz/so_verw.pdf auf meiner Home-Page abrufbar.

Darüber hinaus sind die Datenschutzbeauftragten des Bundes und der Länder in einer Arbeitsgruppe "eGovernment" unter der Leitung des Landesbeauftragten für den Datenschutz Niedersachsen derzeit damit befasst, eine entsprechende Broschüre mit weiteren praktischen Anregungen zu dem Thema zu erstellen. Mit deren Fertigstellung wird im Frühjahr 2003 zu rechnen sein. Auch diese Broschüre wird zum gegebenen Zeitpunkt über meine Home-Page www.datenschutz-bayern.de zum Abruf bereitgestellt werden.

17.1.3. Prüfkriterien für datenschutzfreundliche Produkte (Common Criteria)

Im Abschnitt 17.1.4 meines 19. Tätigkeitsberichtes, "Prüfkriterien für datenschutzfreundliche Produkte (Common Criteria)", habe ich berichtet, dass der Arbeitskreis "Technische und organisatorische Datenschutzfragen" der Konferenz der Datenschutzbeauftragten des Bundes und der Länder eine Arbeitsgruppe unter meiner Federführung gebildet hat, die zunächst ein Schutzprofil zu den Aspekten Verschlüsselung und Pseudonymisierung erstellen soll, um so bereits im Vorfeld von Produktentwicklungen wesentliche datenschutzrechtliche Anforderungen widergeben zu können.

Im Laufe der Entwicklungsarbeiten wurde deutlich, dass die Verwendungsbreite von Produkten auf Basis des zu entwickelnden Schutzprofils nicht nur den Bereich der Pseudonymisierung, sondern auch die verschlüsselte lokale Datenspeicherung und die sichere Datenübertragung über Netzwerke (z. B. im Gesundheitsbereich, der Statistik, der Forschung) umfassen könnte. Weitere Anwendungsmöglichkeiten derartiger Produkte wurden in den Bereichen Data-Warehouses, E-Commerce sowie bei Tele- und Mediendiensten erkannt und Mitte 2000 lag der erste Entwurf des Schutzprofils in den beschreibenden Teilen vor.

Für die Definition und Spezifikation der tiefergehenden Beschreibungen nach Common Criteria V2.1 - insbesondere für die so genannten "Funktionalen Sicherheitsanforderungen" - wurde im September 2000 das BSI gebeten, die Fertigstellung und Fortentwicklung des Schutzprofils sowie dessen Evaluierung und formale Registrierung zu übernehmen.

Nach einigen verwaltungstechnischen Schwierigkeiten und einer entsprechenden Projektausschreibung beauftragte das BSI sodann im Sommer 2001 das Deutsche Forschungszentrum für Künstliche Intelligenz GmbH (DFKI) mit der entsprechenden Schutzprofilfertigstellung.

Im September 2001 nahm die DFKI GmbH mit einem Kickoff-Workshop die Arbeit an dem nun "Benutzerbestimmbare Informationsflusssicherheit (BISS)" genannten Projekt auf. An diesem nahmen neben dem BSI, den Vertretern des Bundesbeauftragten für den Datenschutz und meiner Dienststelle auch Vertreter mehrerer namhafter Unternehmen der Privatwirtschaft aus den Bereichen der Betriebssysteme, der Anwendungssoftware und der Sicherheitssysteme teil und wurden damit in den Entwicklungsprozess eingebunden.

Die weitere Projektarbeit stellte sich sodann als ausgesprochen komplex und arbeitsintensiv dar. Als Ergebnis sind jedoch nunmehr die folgenden, im Sommer 2002 evaluierten und registrierten Schutzprofile vorzuweisen:

• Benutzerbestimmbare Informationsflusskontrolle (MU) - als Mehrbenutzervariante
• Benutzerbestimmbare Informationsflusskontrolle (SU) - als Einbenutzervariante

Ihre wesentlichen Leistungsmerkmale sind:

• Transparenter Schutz der Informationsflüsse eines IT-Systems anhand definierbarer Regeln
• Bereitstellung von Mechanismen zur Sicherstellung von Vertraulichkeit, Integrität und/oder Authentizität durch elektronische Signatur, Verschlüsselung und elektronische Zertifikate
• Freie Kombinierbarkeit dieser Sicherheitsmechanismen für jeden einzelnen Informationsfluss in Abhängigkeit von seinem jeweiligen Schutzbedarf
• Freie Realisierbarkeit der erforderlichen kryptografischen Funktionen als Hardware, Firmware und/oder Software. Das zum Schutzprofil konforme Produkt muss keine eigene Krypto-Funktionalität aufweisen. Diese kann auch von einem anderen vertrauenswürdigen IT-Produkt (z.B. Smartcard) erbracht werden.
• Einschränkbarkeit der Verarbeitung von Informationen z.B. auf bestimmte Applikationen
• Geringer bis kein Anpassungsbedarf bei den bereits eingesetzten Applikationen
• Realisierbarkeit für unterschiedliche Umgebungen wie z.B. (Mehrbenutzer-) Betriebssysteme, Datenbanksysteme oder E-Mail-Clients und -Server
• Sinnvolle Ergänzung zu etablierten Sicherheitskonzepten wie etwa Zugriffsschutz, Übertragungsschutz, Firewalls und Virtual Private Networks
• Unterscheidbarkeit von Benutzern je nach verwendetem Schutzprofil

Die Schutzprofile können im Internet unter http://www.bsi.bund.de/cc/pplist/pplist.htm (externer Link) sowie http://dic.dfki.de (externer Link) eingesehen werden.

Datenschutzkonformität ist somit zu einem nachprüfbaren Qualitätsmerkmal für IT-Produkte geworden.

Es kommt nun darauf an, dass die Hersteller entsprechende Produkte entwickeln bzw. evtl. bereits existente Produkte entsprechend modifizieren und die Anwender von den Herstellern Produkte fordern, die diesen Schutzprofilen gerecht werden, d.h. entsprechend evaluiert sind.

17.1.4. Biometrische Verfahren

Die heute übliche Methode zur elektronischen Verifikation der Identität einer Person ist die Verwendung einer PIN oder eines Passwortes. Da mit zunehmender Anzahl der elektronischen Authentifizierungsverfahren auch die Anzahl der verschiedenen Passwörter zunimmt, wird es immer schwieriger, diese nicht zu vergessen. Eine Lösung für dieses Problem ist die biometrische Authentifizierung durch elektronische Systeme.

Biometrische Verfahren können zum einen für die Verifikation der Identität einer Person verwendet werden, beispielsweise in Zugangskontrollen, in denen nur die "echte" Person als solche erkannt und zugelassen werden darf. Dabei werden biometrische Merkmale der Person mit vorgelegten (z.B. den auf einem Ausweisdokument gespeicherten digitalisierten biometrischen Merkmalen) Referenzdaten verglichen. Ein anderes Einsatzgebiet ist die Identifizierung einer Person aus einer Menge von (Referenz-)Personen heraus, durch Vergleich der von der Person präsentierten biometrischen Merkmale mit im DV-System (digitalisiert) gespeicherten biometrischen Merkmalen einer Vielzahl von Personen.

Die nach dem 11. September 2001 stattfindende Sicherheitsdiskussion hat ebenfalls die Biometrie als zusätzliches Hilfsmittel bei der Identifikation und Verifikation von Personen ins Rampenlicht gebracht. Es wird seitdem weltweit vermehrt versucht, kritische Bereiche wie z.B. Flughäfen mit biometrischen Systemen zu sichern.

Allgemein versucht man bei biometrischen Systemen, ein ähnliches Verfahren wie bei der Erkennung eines Menschen durch einen anderen Menschen mittels eines rechnergestützten Systems mit Sensoren zu implementieren. Der Rechner nimmt über einen oder mehrere Sensoren bestimmte biometrische Erkennungsmerkmale einer Person auf und vergleicht diese mit bereits gespeicherten Referenzmustern. Passen Sensordaten und Referenzdaten gut genug zusammen, so gilt die Person als authentifiziert bzw. identifiziert. Bei der Verifizierung muss ein Referenzmuster mit den aktuellen Sensordaten verglichen werden, bei der Identifikation müssen die Sensordaten mit allen gespeicherten Mustern verglichen werden.

Biometrische Merkmale haben im Vergleich zu herkömmlichen Sicherheitsmerkmalen den Nachteil, dass sie nicht widerrufbar sind. Ein Passwort kann man ändern und das alte verliert damit seine Gültigkeit. Sind Fingerabdrücke beispielsweise einmal mittels einer Kopie reproduzierbar, so kann niemand die eigenen Fingerabdrücke ändern, um die Fälschungen ungültig zu machen.

Die Tests von biometrischen Erkennungssystemen in letzter Zeit haben gezeigt, dass es noch viele Probleme bei der Zuverlässigkeit der Systeme gibt. Solange die Systeme leicht zu täuschen sind und Fehlerkennungsraten sehr hoch liegen, muss auf alle Fälle sichergestellt sein, dass kein System ausschließlich auf Biometrie beruht. Allen Personen muss es möglich sein, im Falle eines Irrtums diesen zu korrigieren, in dem sie sich mit herkömmlichen Mitteln authentifizieren.

Die Zuverlässigkeit eines biometrischen Systems hängt davon ab, wie hoch die Fehlerrate bei der Erkennung ist. Dabei unterscheidet man die Rate der irrtümlichen Erkennung (False Acceptance) und die der irrtümlichen Ablehnung (False Rejection). Bis zu einer bestimmten Abweichung zwischen Sensordaten und Referenzmuster gilt eine Person als erkannt. Diese maximal zugelassene Abweichung wird als Entscheidungsschwelle bezeichnet.

Ändert man die Entscheidungsschwelle in Richtung einer größeren erlaubten Abweichung, so werden mehr Personen akzeptiert. Die Ablehnungsrate sinkt zwar, aber es werden auch mehr Personen irrtümlich erkannt. Umgekehrtes gilt bei der Verschiebung in die andere Richtung. Die Rate der irrtümlich Abgewiesenen steigt. Je nach Anwendungsgebiet des biometrischen Systems sind die beiden Fehlerraten unterschiedlich kritisch. Ein System, das den Zugang zu einem geschützten Bereich ermöglichen soll, darf keinesfalls unberechtigten Personen Zutritt gewähren. Es ist allerdings weniger schlimm, wenn ein Zugangsberechtigter eventuell nicht zugelassen wird. Wenn andererseits ein System eine gesuchte Person in einer Menschenmenge identifizieren soll, ist es aus operativen Gründen sicher besser, wenn es mehrere "Treffer" anzeigt, unter denen sich die gesuchte Person befindet (false acceptance), als wenn es die eine gesuchte Person nicht bemerkt (false rejection). Beide Fehlerraten beeinflussen sich also und müssen für den jeweiligen Anwendungsfall optimiert werden.

Als biometrische Erkennungsmerkmale können unter anderem folgende verwendet werden:

• Fingerabdruck (Pappilarleistengebilde)
• Augeniris
• Gesicht
• Stimme
• Handgeometrie
• Unterschrift
• Bewegungsmuster

Zur Authentifizierung werden davon in herkömmlichen, nicht elektronischen Verfahren bereits das Bild des Gesichts und die Unterschrift auf Personalausweisen verwendet. Durch das Terrorismusbekämpfungsgesetz ist in § 4 Passgesetz und § 1 Personalausweisgesetz zusätzlich noch die Verwendung von biometrischen Merkmalen von Fingern, Händen oder Gesicht grundsätzlich erlaubt. Technische Einzelheiten insbesondere die Auswahl der biometrischen Merkmale bedürfen jedoch noch einer weiteren gesetzlichen Regelung.

Aus der Sicht des Datenschutzes muss sichergestellt werden, dass die biometrischen Referenzdaten in keiner zentralen Datei gespeichert werden, die auch für andere Aufgaben verwendet werden kann - dieses ist im o.a. Terrorismusgesetz auch so bestimmt.

Sollte es nötig sein, Daten außerhalb der Ausweisdokumente zu speichern, so dürfen keine überschiessenden Daten gespeichert werden, sondern nur die notwendigen Referenzdaten, sodass kein Rückschluss zum Beispiel auf gesundheitliche Eigenschaften getroffen werden kann.

Bei der bisherigen Form der Authentifizierung erfolgte diese grundsätzlich immer mit dem Wissen der Betroffenen. Einige biometrische Systeme können aber, zum Beispiel mit Kamerasensoren gekoppelt, Personen identifizieren, ohne dass diese dazu ihre Einwilligung erteilt haben. Bei einer flächenmäßigen Erfassung könnten damit Bewegungsprofile erstellt werden, zum Beispiel wenn Kameras mit Gesichtserkennungssystemen gekoppelt würden. Da hier sensitive Daten ohne Wissen und Zustimmung der Betroffenen erhoben werden würden, lehne ich ein solches Szenario datenschutzrechtlich ab.

Die Datenschutzbeauftragten des Bundes und der Länder haben bei ihrer 63. Konferenz vom

07./08.03.2002 eine Entschließung zu "Biometrische Merkmale in Personalausweisen und Pässen" gefasst, in der u.a. passive Systeme abgelehnt werden und darauf hingewiesen wird, dass eine zentrale oder dezentrale Speicherung der Merkmale nicht erlaubt ist. Des Weiteren sollten die verwendeten biometrischen Merkmale europaweit abgestimmt werden. Diese Entschließung ist als Anlage 19 beigefügt und auch auf meiner Home-Page unter http://www.datenschutz-bayern.de/dsbk-ent/63Biome.pdf abrufbar.

17.1.5. Auftragsdatenverarbeitung (Outsourcing von DV-Leistungen)

Ich wurde im Berichtszeitraum mehrfach von öffentlichen Stellen, die insbesondere aufgrund eines akuten Mangels an IT-Fachleuten in der öffentlichen Verwaltung den Betreuungsaufwand für ihre IT-Einrichtungen nicht mehr selbst erbringen können oder wollen, darauf angesprochen, unter welchen Voraussetzungen ein Outsourcing von DV-Leistungen möglich wäre. Einige dieser Behörden hatten bereits Kontakt mit externen Dienstleistern aufgenommen, die vermehrt DV-Dienstleistungen der unterschiedlichsten Art anbieten (z. B. Konzeption von DV-Systemen und Netzwerken, Entwicklung, Wartung und Pflege von Software, Wartung von Hardware, Administration einzelner Rechnersysteme beziehungsweise ganzer Netzwerke, Bereitstellung und Betrieb von Rechnersystemen oder von Rechenzentren, Beschaffung, Installation und Betreuung der Bürokommunikation).

Die Auslagerung der gesamten EDV wird anhand von Beispielen zweier Kommunen an anderer Stelle besprochen (siehe 17.3.3 - Outsourcing von Kommunaldaten).

Vor- und Nachteile

Vorteile eines Outsourcings können beispielsweise sein:

• Kosteneinsparung
• zusätzliche Einnahmen aus dem Verkauf der vorhandenen Hard- und Software
• Erhöhung der Planungssicherheit während der Dauer des Vertrages
• Beseitigung historisch gewachsener Probleme durch Neukonzeption
• Unabhängigkeit von Hard- und Softwareaufrüstungen bzw. -wechseln
• Unabhängigkeit von Personalqualifikationsproblemen und Personalengpässen
• hohe Flexibilität
• Konzentration auf die eigentlichen Kernaufgaben der öffentlichen Verwaltung
• Steigerung der Qualität der Datenverarbeitung
• effektiverer Datenschutz durch geschultes Personal und örtlichen Gegebenheiten

Allerdings muss sich genauso jede Behörde jeweils fragen, ob es nicht aus Datenschutzgründen besser wäre oder es notwendig ist, einzelne dieser Aufgaben durch eigene Kräfte zu erledigen. So ist beispielsweise bei medizinischen Daten der Schutz der Patientendaten gegen Beschlagnahme außerhalb der Krankenhäuser in der Regel nicht gewährleistet. Solange hier keine entsprechenden gesetzlichen Regelungen existieren, spreche ich mich gegen eine Auslagerung aus. Außerdem dürfen die Krankenhäuser nicht wesentliche Bereiche ihrer Datenverarbeitung in die Hände Dritter geben, damit sie sich nicht von diesen abhängig machen. Schließlich wäre bei einer solchen Auslagerung das Arztgeheimnis verletzt (ohne wirksame Patientenzustimmung). Gerade wegen der besonderen Sensibilität vieler Patientendaten müssen die Krankenhäuser ein gewisses Grund-Know-How im Umgang mit der Datenverarbeitung aufweisen können.

Ein weiterer Nachteil besteht darin, dass bei einer Auftragsdatenverarbeitung die Kontrolle der Einhaltung des Datenschutzes und der Datensicherheit nur im eingeschränkten Maße möglich ist.

Somit kann in manchen Fällen sehr schnell der Zustand erreicht werden, dass die Erreichung der mit dem Outsourcing angestrebten Ziele (Einsparung von Ressourcen) aufgrund der zu ergreifenden Datenschutz- und Datensicherungsmaßnahmen in Frage gestellt oder gar verfehlt wird. Auch eine Wirtschaftlichkeitsbetrachtung der Outsourcingmaßnahme unter Berücksichtigung des Aufwandes für die erforderlichen Sicherheitsmaßnahmen ist hier dringend geboten.

Zu bedenken ist auch, dass Outsourcing eine mittelfristig kaum widerrufbare Entscheidung ist, da es nach Aufgabe des eignen IT-Know-hows schwierig bis fast unmöglich wird, den Schritt rückgängig zu machen.

Rechtsvorschriften

Die folgenden Ausführungen beziehen sich insbesondere auf Art. 6 BayDSG (Erhebung, Verarbeitung oder Nutzung personenbezogener Daten im Auftrag). Allerdings ist zu berücksichtigen, dass bereichsspezifische Vorschriften dem Bayerischen Datenschutzgesetz vorgehen und zum Teil eine Auftragsdatenverarbeitung aus Geheimhaltungspflichten verbieten. Bereichsspezifische Vorschriften sind beispielsweise:

• Art. 36 des Bayerischen Meldegesetzes (MeldeG)
• Verletzung von Privatgeheimnissen (Berufsgeheimnissen) gemäß § 203 Abs. 1 StGB (z. B. für Ärzte)
• § 30 Abgabenordnung (Steuergeheimnis)
• § 80 SGBX (Erhebung, Verarbeitung oder Nutzung von Sozialdaten im Auftrag)
• Art. 27 Abs. 4 - 6 Bayerisches Krankenhausgesetz (Verarbeitung von Patientendaten im Auftrag)

Verantwortliche Stelle

Wenn eine Behörde personenbezogene Daten durch eine andere Stelle erheben, verarbeiten oder nutzen lässt, so handelt es sich dabei gemäß Art. 6 BayDSG um eine Datenverarbeitung im Auftrag. Datenschutzrechtlich wird der externe Dienstleister in seiner Eigenschaft als Auftragnehmer so behandelt, als sei er eine interne Abteilung des Auftraggebers. Bei der Auftragsdatenverarbeitung wird lediglich eine "Hilfsfunktion" der eigentlichen Aufgabe ausgelagert, nicht jedoch die Aufgabe selbst. Es findet somit keine Datenübermittlung im Sinne der Art. 18 und 19 BayDSG statt. Der Auftragnehmer erhält keine Entscheidungsbefugnis bezüglich der Daten. Deswegen bleibt der Auftraggeber gemäß Art. 6 Abs. 1 BayDSG für die Einhaltung der Vorschriften des Bayerischen Datenschutzgesetzes und anderer Vorschriften über den Datenschutz verantwortlich. Dies betrifft insbesondere die Vorschriften für die Zulässigkeit der Erhebung, Verarbeitung und Nutzung personenbezogener Daten, die Wahrung der Rechte des Betroffenen sowie die Einhaltung der nach Art. 7 BayDSG erforderlichen Datensicherheitsmaßnahmen.

Der Auftragnehmer wird weder "Herr der Daten" noch speichernde Stelle. Er darf die erhaltenen Daten nicht zu eigenständigen Zwecken nutzen und ist dem Auftraggeber gegenüber zur Einhaltung des Datenschutzes und der Datensicherheit verpflichtet.

Auswahlkriterien

Gemäß Art. 6 Abs. 2 Satz 1 BayDSG sind Auftragnehmer unter besonderer Berücksichtigung der Eignung der von ihnen getroffenen technischen und organisatorischen Maßnahmen sorgfältig auszuwählen. Wichtiges Auswahlkonzept ist somit das Datensicherheitskonzept des Auftragnehmers. Die Umsetzung dieses Konzeptes sollte durch den Datenschutzbeauftragten des Auftraggebers vor Ort in Augenschein genommen werden (siehe Art. 6 Abs. 2 Satz 3 BayDSG).

Gemäß Nr. 1 der Vollzugsbekanntmachung zum Bayerischen Datenschutzgesetz gelten das Landesamt für Statistik und Datenverarbeitung und die Anstalt für kommunale Datenverarbeitung (AKDB) als sorgfältig ausgewählte Auftragnehmer im Sinne des Art. 6 Abs. 2 Satz 1 BayDSG. Somit bleibt einem Auftragnehmer eine Prüfung der Eignung der von diesen Stellen getroffenen technischen und organisatorischen Maßnahmen erspart.

Vertragsgestaltung

Der Auftrag ist schriftlich zu erteilen (Art. 6 Abs. 2 Satz 2 BayDSG), wobei detailliert festzulegen sind,

• die Beschreibung des Vertragsgegenstandes,
• die Art und der Umfang der Datenerhebung, -verarbeitung oder -nutzung,
• das Verbot der Benutzung der Daten zu anderen Zwecken bzw. deren unerlaubten Weitergabe,
• Auftrags- und Realisierungszeitraum,
• Vertragsdauer,
• Modalitäten einer vorzeitigen Kündigung,
• Eigentumsrechte an Hard- und Software,
• System- und Benutzerdokumentation,
• Aufbewahrungspflichten,
• Gewährleistungsansprüche,
• Haftung,
• die vom Auftragnehmer einzuhaltenden technischen und organisatorischen Maßnahmen (inklusive deren Fortschreibung) und
• ob und unter welchen Voraussetzungen es zulässig ist, Subunternehmer heranzuziehen.

Dabei ist insbesondere zu regeln:

• Beschreibung der organisatorischen, räumlichen und personellen Maßnahmen zur Gewährleistung der Datensicherheit
• Verpflichtung der Mitarbeiter des Auftragnehmers zur Wahrung des Datengeheimnisses gemäß § 5 BDSG
• Versendungs- und Aufbewahrungsrichtlinien für Datenträger
• Zeitpunkt und Art der Löschung bzw. Vernichtung von Datenträgern
• Kontroll- und Weisungsrecht des Auftraggebers (auch gegenüber etwaigen Subunternehmern).

Auch eventuelle Schadensersatzforderungen sollten im Vertrag aufgenommen werden.

Überprüfung des Einhaltens der Regelungen

Der Auftraggeber muss - wie erwähnt - soweit erforderlich die Einhaltung der getroffenen Regelungen überprüfen (Art. 6 Abs. 2 Satz 3 BayDSG), damit gewährleistet ist, dass die Erhebung, Verarbeitung und Nutzung der personenbezogenen Daten durch den Auftragnehmer nur entsprechend den Weisungen des Auftraggebers erfolgt. Ein Auftraggeber sollte sich nicht mit der
bloßen Erklärung des Auftragnehmers zufrieden geben, dass dieser die Vorschriften der Datenschutzgesetze beachten werde. Zur Ermöglichung der Überprüfung bedarf es der Einräumung eines Betretungsrechtes für die Betriebs- oder Geschäftsräume des Auftragnehmers.

Wesentliche Änderungen des Datensicherheitskonzeptes des Auftragnehmers müssen dem Auftraggeber unverzüglich mitgeteilt werden. Dies gilt auch für Störungen, Mängel oder andere Unregelmäßigkeiten im Verarbeitungsablauf.

Weitere Pflichten des Auftragnehmers

Der Auftragnehmer darf die Daten nur im Rahmen der Weisungen des Auftraggebers erheben, verarbeiten oder nutzen (Art. 6 Abs. 3 Satz 2 BayDSG). Die Speicherung von personenbezogenen Daten ist nur während der Durchführung des Auftrages gestattet. Eine Weitergabe von personenbezogenen Daten an Dritte ist nur im Rahmen des Vertrages zulässig. Auch eine Verarbeitung der personenbezogenen Daten für andere Zwecke ist unzulässig.

Ist ein Auftragnehmer der Ansicht, dass eine Weisung des Auftraggebers gegen das Bayerische Datenschutzgesetz oder andere Vorschriften über den Datenschutz verstößt, hat er den Auftraggeber unverzüglich darauf hinzuweisen (Art. 6 Abs. 3 Satz 3 BayDSG).

Abgrenzung zur Funktionsübertragung

Um keine Form der Auftragsdatenverarbeitung im Sinne des Bayerischen Datenschutzgesetzes handelt es sich bei der so genannten Funktionsübertragung. Bei einer Funktionsübertragung wird nicht nur eine genau definierte Dienstleistung, sondern die Erfüllung einer bestimmten Aufgabe (z.B. die Lohn- und Gehaltsabrechnung) oder zumindest wesentlicher Teile einer Aufgabe übertragen.

Bei einer Funktionsübertragung findet im Gegensatz zu einer Auftragsdatenverarbeitung eine Datenübermittlung im rechtlichen Sinne statt. Der Auftragnehmer wird damit zur speichernden Stelle und erhält die Nutzungsrechte an den Daten und ist für deren Zulässigkeit und Richtigkeit verantwortlich. Außerdem ist bei einer Funktionsübertragung der Auftragnehmer für die Gewährleistung des Datenschutzes und der Datensicherheit im Rahmen der übertragenen Aufgabe verantwortlich.

17.1.6. Novelliertes Bayerisches Datenschutzgesetz (BayDSG)

Mit dem Gesetz zur Änderung des Bayerischen Datenschutzgesetzes vom 25.Oktober 2000 sind zahlreiche Bestimmungen des Bayerischen Datenschutzgesetzes (BayDSG) in der überwiegenden Anzahl zum 01.12.2000, teilweise auch zum 01.03.2001, geändert worden. Ursächlich hierfür war überwiegend die Notwendigkeit zur Umsetzung der Vorgaben der EG-Datenschutzrichtlinie 95/46/EG vom 24.10.1995 (Abl. EG Nr. L 281/31). Ich verweise auf meine Darstellung im 19. TB unter Nr. 2.2.2.

Aus technisch-organisatorischer Sicht sind im Rahmen der gemachten Änderungen insbesondere von Bedeutung:

Prüfung und Wartung automatisierter Verfahren und Datenverarbeitungsanlagen

Diese Regelung über die Prüfung und Wartung automatisierter Verfahren und Datenverarbeitungsanlagen wurde mit Art. 6 Abs. 4 BayDSG neu eingeführt.

Datenschutzrechtliche Freigabe

• Delegation zur datenschutzrechtlichen Freigabe selbstentwickelter Verfahren auf die das Verfahren einsetzende öffentliche Stelle (Art. 26 Abs. 1 Satz 1 BayDSG)
  Dadurch ist es möglich, vor Ort entwickelte Verfahren auch unmittelbar dort datenschutzrechtlich freizugeben. Beibehalten wurden die bisherigen Regelungen bzgl. Verfahren, die von der Anstalt für Kommunale Datenverarbeitung oder vom fachlich zuständigen Staatsministerium freigegeben und von der das Verfahren einsetzenden öffentlichen Stelle unverändert übernommen werden.
  
• Delegation der Freigabebefugnis auf den behördlichen Datenschutzbeauftragten (Art. 26 Abs. 3 Satz 2 BayDSG)
  Mit dieser Änderung wird die Befugnis zur datenschutzrechtlichen Freigabe von Verfahren für den Regelfall auf den behördlichen Datenschutzbeauftragten delegiert.
  Hat der behördliche Datenschutzbeauftragte Bedenken, dass das Verfahren den Datenschutzvorschriften nicht genügt, und werden diesen nicht Rechnung getragen, so legt er die Entscheidung über die Freigabe der Person vor, der er nach Art. 25 Abs. 3 Satz 1 BayDSG unterstellt ist. Diese entscheidet dann, ob sie die Freigabe selbst erteilt oder verweigert.
  Ist die Verarbeitung besonders sensibler Daten nach Art. 15 Abs. 7 BayDSG beabsichtigt, so hat der behördliche Datenschutzbeauftragte bei Bedenken vor einer Vorlage an die Person, der er nach Art. 25 Abs. 3 Satz 1 BayDSG unterstellt ist, zunächst meine Stellungnahme einzuholen (Art. 26 Abs. 3 Satz 3 BayDSG).
  
• Erweiterter Umfang der datenschutzrechtlichen Freigabe (Art. 26 Abs. 2 BayDSG)
  Die bisherigen sieben Nrn. wurden inhaltlich unverändert beibehalten. Neu aufgenommen wurden die Nrn. 8 und 9, d.h. Angaben zu Auftragnehmern bei Auftragsdatenverarbeitung gem. Art. 6 Abs. 1 mit 3 BayDSG und Angaben zu den Empfängern von Datenübermittlungen, in deren Länder die EG-Datenschutzrichtlinie nicht gilt.
  Eine erneute datenschutzrechtliche Freigabe von bereits freigegebenen Verfahren ist aufgrund dieser Gesetzesänderungen nicht erforderlich - es sei denn, am betreffenden Verfahren werden wesentliche Änderungen vorgenommen (vgl. Art. 26 Abs. 1 Satz 3 BayDSG); diese neue Freigabe ist dann gemäß den nunmehr geltenden Vorschriften vorzunehmen.
  Ein Muster-Formblatt für die Verfahrensbeschreibung nach der neuen Fassung des Art. 26 Abs. 2 BayDSG steht auf meiner Home-Page unter http://www.datenschutz-bayern.de/inhalte/technik.htm zur Verfügung.

Verfahrensverzeichnis und Anlagenverzeichnis

• Konkretisierte Verpflichtung zur Führung des Verfahrensverzeichnisses durch den behördlichen Datenschutzbeauftragten (Art. 27 Abs. 1 BayDSG)
  Die bisherige Bestimmung, dass öffentliche Stellen ein Verzeichnis der bei ihnen eingesetzten freigegebenen automatisierten Verfahren, mit denen personenbezogene Daten verarbeitet werden, d.h. ein Verfahrensverzeichnis zu führen haben, wurde dahin präzisiert, dass dieses Verfahrensverzeichnis durch den behördlichen Datenschutzbeauftragten zu führen ist.
  In dem Verzeichnis sind nach Art. 27 Abs. 2 BayDSG für jedes Verfahren die Angaben, die auch für die datenschutzrechtliche Freigabe nach Art. 26 Abs. 2 BayDSG erforderlich sind, festzuhalten. Für die Praxis bedeutet dies, dass z.B. die geordnete Sammlung ausgedruckter datenschutzrechtlicher Freigaben das Verfahrensverzeichnis bildet.
  
• Streichen der Verpflichtung, ein Anlagenverzeichnis zu führen (Art. 27 Abs. 1 BayDSG)
  Die bisherige Verpflichtung, neben dem Verfahrensverzeichnis ein Anlagenverzeichnis zu führen, wurde gestrichen und durch die Aufnahme der Verpflichtung, der Verfahrensbeschreibung eine allgemeine Beschreibung der Art der eingesetzten Datenverarbeitungsanlagen und der technischen und organisatorischen Maßnahmen nach Art. 7 und 8 BayDSG beizugeben (Art. 26 Abs. 3 Satz 1 BayDSG) ersetzt.
  
• Neueinführung, dass das Verfahrensverzeichnis von jedem kostenfrei eingesehen werden kann (Art. 27 Abs. 3 Satz 1 BayDSG).
  Dieses Recht zur Einsichtnahme bezieht sich nur auf die nach Art. 26 Abs. 2 BayDSG erforderlichen Angaben der datenschutzrechtlichen Freigabe; die nach Art. 26 Abs. 3 Satz 1 BayDSG der Verfahrensbeschreibung beizugebenden Angaben zu den Datenverarbeitungsanlagen und zu den technischen und organisatorischen Maßnahmen sind davon nicht umfasst. Es empfiehlt sich daher - auch aus Sicherheitsgründen - , die technischen Beschreibungen von dem Verfahrensverzeichnis getrennt zu führen, um so bei einer Einsichtnahme in das Verfahrensverzeichnis nicht unnötigerweise auch die technischen Beschreibungen offen zu legen.
  
• Wegfall der Verpflichtung zur Bestellung behördlicher Datenschutzbeauftragter, der datenschutzrechtlichen Freigabe und der Aufnahme in ein Verfahrensverzeichnis bei denjenigen öffentlichen Stellen, bei denen durch Rechtsverordnung abschließend der Umfang der erhobenen, verarbeiteten oder genutzten Daten festgelegt wird (Art. 28 Abs. 2 BayDSG).

Nicht umgesetzt wurden leider weitere Änderungsvorschläge aus dem technisch-organisatorischen Bereich z.B. zur Einführung von Regelungen über Videoüberwachung und Chipkarten sowie zur "Modernisierung" der "10 Gebote" der technischen und organisatorischen Maßnahmen (vgl. Art. 7 Abs. 2 BayDSG), so dass hier nunmehr Unterschiede zum diesbezüglich novellierten Bundesdatenschutzgesetz bestehen. Diese Änderungsvorschläge bleiben einer zweiten Novellierungsstufe des BayDSG vorbehalten.

17.1.7. Der Internetauftritt

Immer mehr Stellen der öffentlichen Verwaltung erkennen das Internet als ein weiteres Medium zur Informations-Präsentation und zur eigenen Darstellung dem Bürger gegenüber. Die Veröffentlichung von Information und das Bereitstellen von Angeboten z.B. in Form von Formularen u.ä. ist als Teledienst im Sinne des § 2 Abs. 2 Teledienstegesetz (TDG) zu sehen. Somit sind sowohl das Teledienstegesetz als auch das Teledienstedatenschutzgesetz (TDDSG) auf Internetauftritte/Home-Pages anzuwenden.

Diese beiden Gesetze, gefasst als Art. 1 und 2 des Gesetzes zur Regelung der Rahmenbedingungen für Informations- und Kommunikationsdienste (Informations- und Kommunikationsdienstegesetz - IuKDG) vom 22.07.1997 (BGBl I, S. 1870), wurden mit dem Gesetz über rechtliche Rahmenbedingungen für den elektronischen Geschäftsverkehr (Elektronischer Geschäftsverkehr-Gesetz - EGG) vom 14.12.2001 (BGBl I, Nr. 70, S. 3721) novelliert.

Beide Gesetze legen dem Telediensteanbieter, d.h. dem Betreiber der Home-Page, gewisse Informationspflichten auf. So verlangt § 6 TDG die leicht erkennbare, unmittelbar erreichbare und ständig verfügbare Bereitstellung von Informationen zum Telediensteanbieter selbst. Diese geforderten Angaben können verglichen werden mit dem aus der gedruckten Presse bekannten Impressum und werden häufig auch als Anbieterkennzeichnung bezeichnet.

§ 4 Abs. 1 TDDSG verlangt, dass der Telediensteanbieter den Nutzer zu Beginn des Nutzungsvorgangs über Art, Umfang und Zweck der Erhebung, Verarbeitung und Nutzung personenbezogener Daten usw. zu unterrichten hat. Zum Inhalt dieser Vorabunterrichtung verweise ich auf Abschnitt 17.4 meines 19. Tätigkeitsberichtes und auf die in meiner Home-Page bereitgestellte Orientierungshilfe "Online-Datenschutz-Prinzipien (ODSP)" (http://www.datenschutz-bayern.de/technik/orient/priv_pol.htm).

Hinsichtlich der Realisierungsmöglichkeiten für diese Unterrichtungspflichten verweise ich auf die o.g. Orientierungshilfe sowie auf die Orientierungshilfe "Tele- und Mediendienste" meines Hamburger Kollegen (http://fhh.hamburg.de/stadt/Aktuell/weitere-einrichtungen/datenschutzbeauftragter/informationsmaterial/internet-telekommunikation/orientierungshilfe-tele-und-mediendienste-pdf,property=source.pdf (externer Link)).

Besonders aufmerksam machen möchte ich insbesondere auf § 4 Abs. 4 Ziffer 3 TDDSG, wodurch der Telediensteanbieter zwingend verpflichtet wird, kryptografische Mechanismen zur Wahrung der Vertraulichkeit, d.h. Verschlüsselungssysteme, anzubieten.

Im Berichtszeitraum habe ich die Internetauftritte verschiedenster Stellen der öffentlichen Verwaltung in Bayern besucht und auf die Aspekte des neu gefassten Teledienstegesetzes und Teledienstedatenschutzgesetzes hin überprüft. Dabei musste ich zum Teil erhebliche Defizite in der Umsetzung der Forderungen dieser beiden Gesetze feststellen. Ich weise darauf hin, dass Verstöße gegen diese gesetzlich geforderten Informationspflichten mit der Novellierung der Gesetze auch als Ordnungswidrigkeit zu betrachten sind, die mit einer Geldbuße bis zu € 50.000.-- geahndet werden können.

Es wird daher allen Anbietern von Internetauftritten dringend empfohlen, Ihre eigenen Internetauftritte hinsichtlich der Konformität zu den Forderungen des Teledienstegesetzes und des Teledienstedatenschutzgesetzes zu überprüfen und ggf. zu überarbeiten.

17.1.8. Anforderungen an Antivirenprogramme

Der Schutz von IT-Netzen gegen einen Virenbefall wird immer schwieriger. Immer neue Wege der Datenübertragung schaffen immer wieder neue Gefahren. Jahr für Jahr steigt die Anzahl neuer Viren und neuer Virenarten. Waren es früher "nur" Datei- und Systemviren, gegen die sich ein Anwender schützen musste, so entstanden nach und nach weitere Arten von Schadenssoftware (Malware), wie z. B. Hybride Viren, Trojanische Pferde, Würmer, Makroviren, Script-Viren, Hostile Applets und Hoax-Viren. Auf diese Virenarten und die Möglichkeiten ihrer Bekämpfung bin ich in meinen früheren Tätigkeitsberichten (z. B. Nr. 18.1.7 - Makroviren im 17. TB, Nr. 19.3.8 Hoax-Viren und Hostile Applets im 18. TB oder Nr. 17.1.5 - Viren im Internet im 19. TB) bereits eingegangen.

War es früher ausreichend, Arbeitsplatzrechner ohne Disketten- und ohne CD-ROM-Laufwerk auszustatten, um den Import von Viren abzuwehren, steigt das Risiko eines Virenbefalls durch die Einrichtung von Intranets - insbesondere bei einem Anschluss an das Internet. So können Viren durch den E-Mail-Verkehr, beim Websurfen oder durch das Herunterladen von Dateien eingeschleust werden.

Die zuverlässigste Methode, um einen Computervirenbefall frühzeitig erkennen und beseitigen zu können, stellen Virenentdeckungsprogramme (so genannte Scanner) dar, mit denen Arbeitsspeicher und Datenträger regelmäßig auf Virenverseuchung untersucht werden können. Allerdings bietet auch diese Software keinen hundertprozentigen Schutz gegenüber einer Vireninfektion, da sie grundsätzlich nur die Viren suchen und bekämpfen kann, die ihr bereits bekannt sind. Das bedeutet, dass ein neuer Virus zunächst einmal einen Rechner befallen haben muss, damit er erkannt, in einer speziellen Datenbank beim Antivirensoftwarehersteller erfasst, isoliert und bekämpft werden kann. Also werden auch gute Virenscanner immer der Entwicklung zeitlich hinterherhinken. Sie bieten nach allgemeinen Schätzungen im Moment ihres Erscheinens bzw. Updates lediglich eine Sicherheit, bis zu 85 Prozent aller Viren erkennen zu können. Umso mehr sollte jede öffentliche Stelle darauf achten, dass nur Scanner von Anbietern erworben werden, die einen regelmäßigen (möglichst täglichen) Update-Service gewährleisten.

Virenscanner sollten nicht nur das Eindringen von Viren soweit wie möglich verhindern oder zumindest erschweren, sondern auch die Ausbreitung bereits eingedrungener Viren unterbinden. Dazu suchen sie nach bereits bekannten Hex-Pattern, durch die sich ein Virus erkennen lässt. Das können bestimmte Befehlsfolgen oder Texte im Virenprogramm sein. Einige Antivirenprogramme überprüfen zusätzlich den Anfang und das Ende aller ausführbaren Dateien auf virentypisches Verhalten (heuristisches Verfahren). Diese Methode kann allerdings auch zu Fehlalarmen führen. Außerdem sind heuristische Scanner nicht in der Lage, Viren zu entfernen.

An dieser Stelle soll auch nicht verschwiegen werden, dass eine Beseitigung von Viren in einem ausführbaren Programm unter Umständen dazu führen kann, dass dieses Programm nach der Säuberung nicht mehr ablauffähig ist, da ein wichtiger Teil des Programmes bei der Desinfektion mitbeseitigt wurde. In einem solchen Falle ist es häufig besser, gleich das ganze Programm zu entfernen und durch die Originalfassung zu ersetzen.

Gute Antivirenprogramme sollten über folgende Bestandteile verfügen:

• Virensuchprogramm (Scanner) incl. heuristischem Suchen
• (Mit Hilfe von Virensuchprogrammen können Software und Datenträger schon vor dem Einsatz überprüft werden. Man kann damit eine Infektion mit bekannten Viren weitestgehend vermeiden. Mit vielen Scannern können durch die Betriebsart "heuristisches Suchen" neue, bisher noch nicht bekannte Viren aufgespürt werden.)
• Prüfsummenverfahren (Integrity Checker)
• (Prüfsummenverfahren dienen der Überwachung der Unversehrtheit eines Programms. Sie errechnen für jede ausführbare Datei eine Prüfsumme aus einer Reihe von dateispezifischen Informationen (z. B. Erstellungsdatum, Dateigröße, Datum und Zeit der letzten Aktualisierung, Adresse der Datei auf dem Speichermedium) und speichern diese in einer eigenen Datenbank. Bei jedem Aufruf einer ausführbaren Datei werden deren Prüfsumme mit der in der Datenbank hinterlegten Prüfsumme verglichen. Programmänderungen, die eine Veränderung der Prüfsumme zur Folge haben, werden damit sofort erkannt.)
• Speicherresidente Wächterprogramme (Behavior Blocker)
  (Diese Programme überwachen alle Programmaktivitäten (einschließlich der Ausführung von Makros) und melden ein verdächtiges "Benehmen" - z. B. Schreibzugriffsversuche auf Systembereiche.).

Bei der Auswahl eines Antivirenprogramms sollte u. a. folgende Anforderungen an die Funktionalität, die Handhabung und die Sicherheit gestellt werden:

• Erkennen aller verbreiteten (in the wild = in freier Wildbahn) Viren
• einstellbarer Prüfablauf (On Demand = Starten von zeitgesteuerten Suchvorgängen (Scheduled-Scan) bzw. auf Benutzeranforderung und On Access = permanente Überwachung aller Dateizugriffe)
• umfangreiche Möglichkeiten der Virenbehandlung von infizierten Dateien (Löschen, Säubern, Umbenennen, Isolieren)
• Benutzer- bzw. Administratorbenachrichtigung bei Verdacht eines Virenbefalles
• Netzwerkunterstützung
• zentrale Administration
• aussagekräftige Protokollierung
• Ablaufsicherheit
• geringe Performance-Belastung
• Notfallhilfe (Erstellung einer Boot-Diskette etc.)
• Untersuchung von komprimierten Dateien
• Online-Dokumentation
• regelmäßiger Online-Update-Service
• automatischer Update der Clients per Log-in-Skript.

Bei einem Internet-Anschluss müssen spezielle Virenscanner zum Einsatz gelangen, die auch Script Viren und Hostile Applets aufspüren können und bei einem Befund den Zugriff dieser Programme auf den Rechner unterbinden sowie das Applet löschen. Unsichere Seiten, von denen die feindlichen Programme kamen, dürfen kein zweites Mal angesteuert werden können.

Mit Hilfe von Filtertechniken (Content-Filtering) sollte es möglich sein, E-Mails mit speziellen Dateianhängen (z. B. vbs = Visual Basic Script) zu blockieren.

Werden Dateien verschlüsselt übertragen, müssen diese nach dem Entschlüsseln erneut gescannt werden. Der Einsatz von aktuellen Virenscannern sowohl beim zentralen Datenbankserver als auch beim E-Mail-Server und bei der Firewall (Gateway-Rechner) ist daher unverzichtbar. Auch ein laufendes Scannen der Arbeitsplatzrechner wird angeraten, insbesondere wenn diese PC mit Disketten- und/oder CD-ROM-Laufwerken ausgestattet sind.

Bereits am 01.08.1991 gab das Bundesamt für Sicherheit in der Informationstechnik (BSI) erstmals "Forderungen an Viren-Suchprogramme" heraus. Im Rahmen einer Arbeitsgruppe zwischen den für ITSEC zuständigen Behörden von Großbritannien und Deutschland entstand eine untereinander abgestimmte Fassung einer "Funktionalitätsklasse für Viren-Suchprogramme". Diese Informationen können der BSI-Broschüre "Informationen zu Computer-Viren" entnommen werden (im Internet abrufbar unter: www.bsi.de/av/virbro/anhang/anhang_c.htm (externer Link)).

17.1.9. Fernwartung und Einsatz von Remote Management (Control) Programmen (Fernbedienung)

Fernwartung

In der modernen Verwaltung wird heute eine Vielzahl von speziellen Rechnern und Verfahren eingesetzt, deren alleinige Wartung durch das eigene Personal wegen der dafür benötigten Spezialkenntnisse vielfach nicht mehr möglich ist, so dass bei Störungen sowie bei in der Hard- oder Software auftretenden Fehlern aufgrund der Abhängigkeit von einer funktionierenden IT-Verarbeitung oft der Hersteller eingeschaltet werden muss. Das geschieht zum Teil vor Ort, meist jedoch im Rahmen des Teleservice, also in Form einer Ferndiagnose und -wartung (unter Umständen auch durch den eigenen Systemverwalter von zu Hause aus - siehe unter Remote Management Programme). Die Vorteile einer Fernwartung sind insbesondere die schnellere Hilfe, geringere Kosten (auch wenn sicherlich der Aufbau einer Fernwartungszentrale ebenfalls mit Kosten verbunden ist) und die Verfügbarkeit von Spezialisten. Es besteht bei einer Fernwartung aber immer die Gefahr, dass sensible Informationen bewusst oder unbewusst an Unberechtigte offenbart werden.

Bei einer reinen Hardwarewartung wird in der Regel nur auf bestimmte Statusinformationen in eigens dafür eingerichteten Diagnosedateien zugegriffen, die keine personenbezogenen Daten enthalten. Bei vielen DV-Systemen kann aber die Fehlerdiagnose und -behebung mit einer Offenbarung geschützter personenbezogener Daten verbunden sein. Deshalb ist eine Fernwartung datenschutzrechtlich besonders problematisch. Bei einer Wartung vor Ort sind die Kontroll- und Eingriffsmöglichkeiten des eigenen Personals im Regelfall größer. Es ist dann eher erkennbar und prüfbar, welche konkreten Personen in Erscheinung treten und ein unberechtigtes "Entfernen", Verändern, Lesen oder Übertragen von Daten ist durch die Kontrolle erschwert.

Bei Einsatz einer Fernwartung ist daher insbesondere auf die Einhaltung folgender Regeln zu achten:

• Der Auftraggeber definiert Art und Umfang der Fernwartung sowie die Abgrenzung der Kompetenzen und Pflichten zwischen Wartungs- und Kundenpersonal im Wartungsvertrag. Für Zuwiderhandlungen sind empfindliche Vertragsstrafen vorzusehen.
• Das Wartungspersonal muss auf das Datengeheimnis verpflichtet sein.
• Eine Weitergabe der im Rahmen der Fernwartung anfallenden Daten ist zu untersagen.
• Für die Durchführung der Fernwartung muss eine eigenen Benutzerkennung eingerichtet werden. Das dazugehörige Passwort ist nach jedem Wartungsvorgang zu ändern.
• Bei der Fernwartung ist die Verbindung oder die Freischaltung (nach einem Authentifikationsprozess) stets vom Auftraggeber aus aufzubauen (Call-Back-Verfahren) oder frei zu geben, damit sichergestellt ist, dass keine unbefugten Einwählversuche stattfinden können. Nach Abschluss der Wartungsarbeiten ist diese Verbindung wieder zu deaktivieren.
• Vom Auftraggeber sind der Wartung/Fernwartung nur solche Zugriffsmöglichkeiten zu eröffnen, die für die Fehlerbehebung unbedingt erforderlich sind. Insbesondere gilt dies für Systemverwalterprivilegien und den Zugriff auf personenbezogene Daten. Es ist ferner darauf zu achten, dass im Rahmen der Wartung bzw. Fernwartung keine Funktionen frei geschaltet werden, die eine Übertragung oder Auswertung von Anwenderdatenbeständen zulassen. Eine Übertragung personenbezogener Daten zur Fernwartungsstelle muss auf den Einzelfall beschränkt sein und nur mit Einverständnis des Auftraggebers erfolgen können. Ein zweckwidriger Zugriff auf andere Rechner im Netz ist zu unterbinden.
• Soweit möglich müssen alle Aktivitäten im Rahmen der Fernwartung vom Auftraggeber online mitverfolgt werden. Im Zweifelsfalle muss dieser Mitarbeiter auch die Aktivitäten jederzeit abbrechen können.
• Außerdem sind alle Aktivitäten der Fernwartung (inklusive etwaiger versuchter Fernzugriffe) aufzuzeichnen und die entsprechenden Protokolle auszuwerten. Bei besonders kritischen Aktionen ist der gesamte Dialog zu protokollieren, damit später erkennbar wird, auf welche Daten zugegriffen wurde.
• Zur Sicherung der Vertraulichkeit der übertragenen Daten auf dem Übertragungswege kann es erforderlich sein, dass die Daten mit einem starken Algorithmus (mindestens 128 Bit bei symmetrischer Verschlüsselung und mindestens 1024 Bit bei asymmetrischer Verschlüsselung) verschlüsselt werden. Es ist in diesem Falle jedoch darauf zu achten, dass die Protokollierung vor Ort unverschlüsselt erfolgt und nicht auf dem Rechner des Fernwarters. Nur so ist eine effektive Kontrolle durch den Auftraggeber gewährleistet.

Zu Fragen im Zusammenhang mit einer Fernwartung in speziellen Bereichen verweise ich auf die auf meiner Homepage im Internet im Bereich Technik/Rechnersysteme unter www.datenschutz-bayern abrufbare Orientierungshilfe zur "Wartung und Fernwartung im Mainframe-Bereich" und auf meine Ausführungen zur "Wartung medizin-technischer Anlagen" im 19. Tätigkeitsbericht von 2000 unter Nr. 17.3.3.

Einsatz von Remote Management (Control) Programmen

Remote Management Programme (z. B. pcAnywhere oder WinTel) - auch als Remote Control Programme oder Remote Support Programme bezeichnet - ermöglichen einem Systemadministrator, von seinem Arbeitsplatz aus Zugriff auf andere im Netzwerk angeschlossene Computer zu nehmen. Dies dient hauptsächlich einer Fehlersuche und -beseitigung. Hat ein Benutzer Probleme bei der Arbeit an seinem PC und teilt dies dem Administrator mit, so kann sich dieser mit Hilfe der Fernsteuerungssoftware je nach Einstellung des Programmes entweder alles, was auf dem Bildschirm des Benutzers angezeigt wird, auch auf seinem eigenen anzeigen lassen oder zumindest auf bestimmte Programme und Daten auf dem fremden Rechner zugreifen. Zudem kann der Administrator steuernd in den Dialog eingreifen und - an Stelle des Benutzers - Eingaben tätigen, aus der Ferne Installationsarbeiten am PC des Benutzers durchführen oder sich als Administrator anmelden.

Weitere Einsatzmöglichkeiten für diese Software bestehen darin, Wartungsarbeiten an einem Server in der Dienststelle von zu Hause vorzunehmen oder auch von der Dienststelle aus bei einem Telearbeiter zu Hause Software-Updates aufzuspielen. Notwendige Wartungsarbeiten lassen sich dadurch schneller und kostengünstiger vornehmen.

Auch der Versand von Nachrichten oder das Überspielen von Daten ist auf diese Weise möglich.

Der Zugriff auf den zu bearbeitenden Rechner kann entweder über das eigene Netzwerk, über einen ISDN-Adapter, ein Modem oder mittels Browser über das Internet erfolgen.

Diese Art von Fernbedienung beinhaltet natürlich auch die Gefahr des Missbrauches. So kann sie zur Überwachung von Mitarbeitern verwenden werden, indem beispielsweise alle Tastatureingaben des Überwachten aufgezeichnet und zur Auswertung an einen anderen PC übersandt werden. Außerdem besteht die Möglichkeit, unbemerkt Dateien herunterzuladen oder aufzuspielen bzw. unberechtigt auf gespeicherte Daten zuzugreifen. Dateien oder ganze Verzeichnisse könnten kopiert, verändert, gelöscht oder umbenannt werden. Denkbar ist es auch, Passwörter auszulesen oder Veränderungen an Systemprogrammen vorzunehmen.

Ist der Einsatz einer Fernsteuerungssoftware bei einer Behörde aus dienstlichen Gründen erforderlich, so sollten zumindest folgende technisch-organisatorischen Maßnahmen getroffen werden:

• Mit dem Personalrat sollte eine Dienstvereinbarung abgeschlossen werden, in der parallel zu einer zu erlassenden Dienstanweisung die Zugriffsmöglichkeiten, Zugriffsgründe, die Zugriffsarten und die dabei zu ergreifenden Sicherheitsmaßnahmen eindeutig geregelt sind. Der zeitlich uneingeschränkte Zugriff auf andere Rechner ist zu untersagen. Diese Dienstanweisung muss jedem Mitarbeiter zur Kenntnis gebracht werden, der entweder die Fernzugriffe durchführt oder auf dessen PC zugegriffen werden soll.
• Die Möglichkeiten des eingesetzten Remote Management Programmes sind auf diese festgelegten Regelungen zu beschränken. So könnte beispielsweise der Zugriff auf bestimmte Rechner (z. B. in der Personalabteilung) ganz verboten oder bestimmte Verzeichnisse oder Dateien vom Zugriff ausgenommen sein. Generell ist der Zugriff auf personenbezogene Daten auf das unbedingt Notwendige zu reduzieren.
• Wann immer möglich, sollte der Bedienstete bei jedem Zugriffsversuch die Möglichkeit haben, zu entscheiden, ob er den Zugriff auf seinen PC zulässt oder nicht.
• Falls dies im Einzelfall nicht möglich ist, muss dem Betroffenen zumindest der Remote-Zugriff angezeigt werden.
• Soweit möglich hat sich der Zugreifende mittels Passwort beim Zugriffsobjekt zu legitimieren.
• Bei einem Fernzugriff von oder nach außerhalb des Netzwerkes muss gewährleistet sein, dass personenbezogene Daten nur verschlüsselt übertragen werden.
• Sollte der Verdacht bestehen, dass der Zugriff auf Daten erfolgt, die offenkundig nicht für den Wartungsfall erforderlich sind, sollte der PC-Nutzer die Möglichkeit haben, die Verbindung abzubrechen.
• Die lückenlose Protokollierung aller Zugriffsversuche muss gewährleistet sein, so dass erkennbar ist, wer mit Hilfe der Fernwirkungssoftware wann auf welche Art und Weise auf welche Daten zugegriffen hat. Diese Protokolldaten sind regelmäßig von einem nicht der Systemadministration angehörigen Mitarbeiter (z. B. behördlicher Datenschutzbeauftragter, Personalrat) auszuwerten.

17.1.10. Platform for Privacy Preferences (P3P)

Am 16.04.2002 wurde vom World Wide Web Consortium (W3C) die Platform for Privacy Preferences (P3P) Version 1.0 (http://www.w3.org/2002/04/p3p-pressrelease (externer Link)) als Empfehlung verabschiedet. Bei P3P Version 1.0 handelt es sich um ein einfaches, standardisiertes und automatisiertes Protokoll zur formalen und maschinenlesbaren Beschreibung von Datenschutzerklärungen (siehe auch Abschnitt 17.1.7 "Der Internet-Auftritt"). Die Diskussion um notwendige oder sinnvolle Erweiterungen sind bereits im Gange.

Grundsätze

Aufgrund der Verwendung von XML zur Formulierung einer Datenschutzerklärung kann diese zum einen automatisch in der jeweiligen Sprache des Besuchers dargestellt werden. Zum anderen kann der Besucher von seinem Browser automatisch prüfen lassen, ob eine Webseite seinen spezifischen, in seinem Browser voreingestellten Anforderungen an den Datenschutz genügt.

P3P erlaubt somit Nutzern des Internet eine bessere Kontrolle über die Nutzung ihrer personenbezogenen Daten durch die von ihnen besuchte Web-Site. Die formalisierte und dv-technisch validierbare P3P Datenschutzerklärung steht ergänzend neben den verbalen Informationen, die Telediensteanbieter aufgrund der Forderungen des Teledienste- und des Teledienstedatenschutzgesetzes den Nutzern bereit zu stellen haben. Auf meiner Homepage stelle ich seit dem 23.04.2002 meine Datenschutzerklärung auch im P3P-Format zur Verfügung.

Ob die tatsächliche Datenverarbeitung beim Telediensteanbieter allerdings mit der Ankündigung in der Datenschutzerklärung übereinstimmt, lässt sich auch mit der Validierung einer P3P Datenschutzerklärung nicht überprüfen.

Praktische Anwendung

Der Internetnutzer benötigt lediglich eine Browser-Software, die in der Lage ist, P3P Datenschutzerklärungen zu lesen und zu verarbeiten. Andere spezielle Software ist nicht erforderlich. Zum Zeitpunkt des Redaktionsschlusses unterstützte nur der Microsoft Internet Explorer (ab Version 6.0) einen Teil der P3P Empfehlung. Für andere Browser ist dies für die nahe Zukunft angekündigt.

Stehen einzelne Definitionen der P3P Datenschutzerklärung im Widerspruch zu den vom Nutzer in seinem Browser gewählten Einstellungen, z.B. bzgl. Akzeptanz von Cookies, so erscheint in der Fußzeile des Browsers ein Warnhinweis.

Im Microsoft Internet Explorer 6 gelangt man unter dem Menü "Anzeigen - Datenschutzbericht" nach dem Anzeigen von "allen Websites", der Selektion einer Seite und durch Drücken von "Zusammenfassung" schließlich zu einer lesbaren Darstellung der P3P Datenschutzerklärung - interpretiert durch den Microsoft Internet Explorer.

Wenn der Internetnutzer eine vorgefundene P3P Datenschutzerklärung überdies vom World Wide Web Consortium nach den formalen P3P Kriterien (bzgl. Syntax, Links, usw.) automatisch validiert haben möchte, so ist dies unter dem Link http://www.w3.org/P3P/validator.html (externer Link) durchführbar.

Folgerung

Mit der praktischen Verfügbarkeit von P3P ist ein wesentlicher Schritt in Richtung mehr Transparenz und Datenschutzschutzfreundlichkeit für den Internetnutzer getan. Es kommt jetzt darauf, dass die Browserhersteller die P3P-Funktionalität zügig in Ihre Produkte einbauen, der Standard P3P fortentwickelt wird, die Internetnutzer diese neue Möglichkeit zur Validierung von Datenschutzerklärungen nutzen und auch die Internet- und Informationsanbieter ihre Datenschutzerklärungen zusätzlich zur Textversion ebenfalls in P3P-Format bereitstellen.

17.2. Prüfungen, Beratungen und Informationen

17.2.1. Erkenntnisse aus Prüfungen

Im Berichtszeitraum habe ich bei folgenden Dienststellen die Einhaltung der gebotenen technischen und organisatorischen Datensicherheitsmaßnahmen überprüft:

• Alten- und Pflegeheim "Römerschanz" des Bayerisches Rotes Kreuzes
• AOK-Direktion Kempten
• Bezirkskrankenhaus Taufkirchen
• Brentano-Volksschule in Aschaffenburg
• Gemeinde Altdorf
• Gemeinde Memmelsdorf
• Gemeinde Putzbrunn
• Kreiskrankenhaus Haßfurt
• Stadt Schweinfurt
• Stadt Kitzingen

Ergebnisse der Kontrolltätigkeit

Die Kontrollen ergaben, dass der Stand der technisch-organisatorischen Datensicherheitsmaßnahmen recht unterschiedlich ist. Erfreulich ist, dass bei vielen Stellen der Datenschutz und die Datensicherheit einen hohen Stellenwert besitzen, so dass nur geringfügige Lücken im Sicherheitssystem festzustellen waren. Andererseits wurden bei manchen Stellen in Teilbereichen erhebliche Defizite aufgedeckt.

Verschlüsselung bei der Datenfernverarbeitung

Obwohl ich bereits in den letzten Tätigkeitsberichten immer wieder daraufhingewiesen habe, dass personenbezogene Daten, die über das öffentliche Leitungsnetz übertragen werden, verschlüsselt werden müssen, da sonst die Vertraulichkeit der Informationen nicht gewährleistet ist und die Daten für missbräuchliche Zwecke aufgezeichnet und genutzt werden könnten, gibt es immer noch öffentliche Stellen, die zum Teil auch sensible Daten unverschlüsselt über das Internet übertragen. Im Übrigen ist auch im Rahmen der Fernwartung immer dann eine Datenverschlüsselung erforderlich, wenn auf Echtdaten zugegriffen werden muss.

Virenbekämpfungskonzept

Der Einsatz von aktuellen Virenscannern sowohl beim zentralen Datenbankserver als auch beim E-Mail-Server und - soweit vorhanden - bei der Firewall ist unverzichtbar. Auch ein laufendes Scannen der Arbeitsplatzrechner wird dringend angeraten, insbesondere wenn diese PC mit Disketten- und/oder CD-ROM-Laufwerken ausgestattet sind oder verschlüsselte Dateien erhalten. Diese Dateien müssen nach dem Entschlüsseln - wie auch jeder unverschlüsselte Anhang einer E-Mail - auf der Festplatte abgespeichert und gescannt werden und dürfen erst anschließend geöffnet werden.

Bei der Verwendung von Virensuchprogrammen verschiedener Anbieter ist zu beachten, dass diese unabhängig voneinander verwendet werden. Bei gleichzeitigem Gebrauch verschiedener, nicht aufeinander abgestimmter Produkte kann es zu falschen Virenalarmen kommen. Aufgrund des Anschlusses an öffentliche Netze müssen spezielle Virenscanner zum Einsatz gelangen, die auch Hostile Applets aufspüren können.

Die allermeisten Dienststellen setzen zwar - zumindest wenn sie über einen Internetzugang verfügen - entsprechende Software zur Bekämpfung von Viren ein, vergessen aber dabei, eine Schutzfunktion zu aktivieren, die einen Virenbefall durch verseuchte E-Mail-Anhänge verhindern kann. Viele moderne Virenscanner verfügen über die Möglichkeit, ein so genanntes "Dateiblocking" durchzuführen. Dabei werden Dateianhänge in E-Mails nicht nur auf Viren überprüft, sondern auch bestimmte, einstellbare Dateitypen (z. B. die stets verdächtigen vbs- und exe-Dateien) in so genannten "Quarantäneordner" abgelegt und zunächst nicht an den eigentlichen Empfänger der E-Mail weitergeleitet. Der vorgesehene Empfänger erhält statt des geblockten Dateianhangs einen entsprechenden Hinweis. Möchte der Adressat nun die geblockte Datei, muss er sich an den Systemverwalter (oder eine damit beauftragte Person) wenden. Dieser hat nun die Möglichkeit, entweder diese benannte Datei per E-Mail weiterzuleiten oder direkt in ein benanntes Dateiverzeichnis einzuspeichern. Nähere Informationen zu diesem Thema können u.a. unserer Orientierungshilfe "Sicherheitsmaßnahmen im Landkreis-Behördennetz" auf unserer Homepage www.datenschutz-bayern.de im Bereich Technik/Orientierungshilfen/Vernetzung entnommen werden.

Online-Datenschutzprinzipien und Pflicht zur Anbieterkennung

Häufig wird übersehen, dass gemäß § 4 Abs. 1 Teledienstedatenschutzgesetz (TDDSG) jeder Nutzer einer Homepage vor der Erhebung personenbezogener Daten über Art, Umfang, Ort und Zwecke der Erhebung, Verarbeitung und Nutzung seiner personenbezogenen Daten unterrichtet werden muss. Dies geschieht mit Hilfe so genannter Online-Datenschutzprinzipien (Privacy Policy). Nähere Hinweise dazu enthalten unsere gleichnamige Orientierungshilfe - abrufbar auf unserer Homepage (www.datenschutz-bayern.de) im Bereich "Technik/Grundsätze" und das Kapitel "Der Internet-Auftritt" in diesem Tätigkeitsbericht.

Im Übrigen besteht eine Pflicht zur Anbieterkennzeichnung gemäß § 6 Mediendienste-Staatsvertrag (MDStV) und § 6 Teledienstegesetz (TDG).

Absicherung von Serverräumen

Aufgrund der Abhängigkeit vieler öffentlicher Stellen von der ständigen Verfügbarkeit der Rechnersysteme muss Vorsorge gegen einen eventuellen Ausfall der DV getroffen werden. Dazu gehört insbesondere auch die Absicherung der Serverräume. Deshalb müssen neben der Wahl eines geeigneten Raumes Sicherheitsmaßnahmen für diesen ergriffen werden. Insbesondere sind Maßnahmen zur Zugangskontrolle (Festlegung der Zugangsberechtigungen, Außen- und Innenhautsicherung, revisionsfähige Schlüssel- und Chipkartenregelung usw.) und zur Bekämpfung von physischen Schäden (z. B. Schutz vor Feuer und Wassereinbrüchen) zu ergreifen. Näheres dazu enthält das Kapitel 17.3.8 in meinem 19. Tätigkeitsbericht.

Auswertung der Logdateien

Alle Sicherheitsverletzungen (einschließlich eventueller Eindringversuche in das Netzwerk einer öffentlichen Stelle) an den DV-Anlagen bzw. im Netzwerk sind durch Auswertung entsprechender Logdateien in einem täglichen Sicherheitsbericht aufzuzeigen und zu überprüfen, damit Sicherheitsverletzungen und vor allem Versuchen von unzulässigen Aktionen rechtzeitig nachgegangen werden kann. Die Auswertungen sind zu dokumentieren.

17.2.2. Anstieg der Beratungsleistungen

Auch in diesem Berichtszeitraum ist wiederum die Zahl der Dienststellen stark gestiegen, die sich im Vorfeld von Um- oder Neubautätigkeiten, hinsichtlich der Öffnung des lokalen Netzes zum Internet und vor der Einführung neuer DV-Verfahren mit der Bitte um Beratung bezüglich der erforderlichen Datenschutz- und Datensicherheitsmaßnahmen an meine Geschäftsstelle gewandt haben. Auch Softwareersteller, die ihre Produkte bereits in öffentlichen Bereich einsetzen bzw. einsetzen wollen, und Sicherheitsberatungsfirmen, die Netzwerke bzw. Notfallkonzepte für Behörden planen sollen, bitten vermehrt um Anregungen bzw. legen mir ihre Konzepte zur Beurteilung vor.

Viele Kommunen möchten ihren Bürgern mit Hilfe einer serviceorientierten Verwaltung längere Wartezeiten in den Fachämtern ersparen und eine bessere Beratung bieten. Aus diesem Grunde entstehen immer mehr so genannte "Bürgerbüros" als zentrale Anlaufstelle für die Gemeindemitglieder bzw. mit Hilfe der elektronisch gestützten Verwaltung (eGovernment) soll den Bürgern die Möglichkeit gegeben werden, ihre Behördengänge auf elektronischem Wege zu erledigen. Ein Schwerpunkt meiner Beratungstätigkeit im kommunalen Bereich lag daher darin, den Gemeinden die damit verbundenen Gefahren für den Datenschutz und die Datensicherheit aufzuzeigen und entsprechende Sicherheitsmaßnahmen vorzuschlagen.

Soweit es mir aus personellen und zeitlichen Gründen möglich ist, komme ich Beratungswünschen gerne nach, da es mir zum Einen zeigt, dass bei den Hilfe suchenden Stellen ein Datenschutzbewusstsein vorhanden ist und mir zum Anderen die Möglichkeit gegeben wird, auf
eventuelle Fehler im Datenschutz- und Datensicherheitskonzept hinzuweisen. Eine wesentliche Voraussetzung für meine Beratungsleistung ist allerdings, dass ein solches Datenschutz- und Datensicherheitskonzept bereits erstellt, dem örtlich zuständigen Datenschutzbeauftragten vorgelegt und von diesem auch beurteilt wurde und erst dann mir vorgelegt wird. Die erstmalige Erarbeitung eines Datenschutz- und Datensicherheitskonzeptes kann von meiner Dienststelle aus den oben erwähnten personellen und zeitlichen Gründen beim besten Willen nicht geleistet werden.

17.3. Technische Einzelprobleme

17.3.1. Protokollauswertung auf Servern und Firewall-Systemen

Jeder Internetdienstanbieter kann über automatisch generierte Protokolle auf seinen Servern eine große Anzahl an Daten über das Verhalten seiner Nutzer gewinnen. Da das Internet für einen immer größeren Bevölkerungsanteil an immer mehr Orten zur Verfügung steht, werden auch diese Daten wertvoller und vollständiger erfassbar.

Deshalb ist besonders darauf zu achten, dass alle Protokollierungen von personenbezogenen Daten mit den entsprechenden Datenschutzvorschriften übereinstimmen.

Aus technischer Sicht werden Protokolle bei der Internetnutzung hauptsächlich zum Erkennen von Fehlern und Angriffen und zur Optimierung von Netzdiensten verwendet. Auch für die eventuelle Abrechnung der Dienstnutzung sind Protokolldaten unumgänglich.

Nach § 3 Abs. 1 und § 6 Abs. 1 Teledienstedatenschutzgesetz (TDDSG) ist es dem Diensteanbieter in Deutschland nur erlaubt, personenbezogene Daten über die Inanspruchnahme von Telediensten zu erheben, verarbeiten und nutzen, soweit dies erforderlich ist, um dem Nutzer die Inanspruchnahme von Telediensten zu ermöglichen (Nutzungsdaten) oder um die Nutzung von Telediensten abzurechnen (Abrechnungsdaten).

Protokollauswertung auf Firewallsystemen

Da beim Einsatz einer Paket-Firewall der gesamte Internetverkehr zwischen internem und externem Netz durch die Firewall fließt und dort auf Zulässigkeit geprüft wird, können hier besonders viele Daten in Logdateien gespeichert werden. Für jedes einzelne Datenpaket kann hier mitprotokolliert werden:

• Absende IP Adresse und Absende Port
• Empfänger IP Adresse und Empfänger Port
• Erlaubnis, Zurückweisung oder Unterdrückung der Verbindung
• Protokolldetails

Nicht protokolliert wird in der Regel der Inhalt der einzelnen Pakete.

Da zumindest eine IP Adresse innerhalb des eigenen Netzes liegt, kann diese auch einem internen Nutzer zugewiesen und somit personenbezogen sein. Aber auch die IP Adressen von außerhalb können, zumindest in Kombination mit Informationen aus anderen Datenbanken, eventuell einzeln bestimmbaren Personen zugeordnet werden.

Eine Protokollierung auf einer Firewall wird vorgenommen, um die Sicherheit des eigenen Netzes zu überwachen und auf Einbruchsversuche reagieren zu können. Aus Sicherheitsgründen ist deshalb eine Protokollierung nach dem allgemeinen Datenschutzgesetzen durchaus möglich. Zur Erkennung von Langzeitangriffen halte ich einen Zeitraum von maximal drei Monaten für die Aufbewahrung und Verwendung der Logdateien für akzeptierbar. Hierbei ist jedoch eine strikte Zweckbindung zu beachten.

Sollen die Logdateien auf einer Firewall auch für statistische Zwecke verwendet werden, so müssen dafür die vollständigen IP Adressen mindestens durch Wegkürzen der letzten drei Stellen anonymisiert werden. Danach handelt es sich um keine personenbezogenen Daten mehr und damit unterliegen sie auch keinen datenschutzrechtlichen Restriktionen mehr.

Zu prüfen ist auch, ob es nicht reicht, für die Gewährleistung der Sicherheit ein bestimmten, nicht zulässigen Teil des Verkehrs zu protokollieren (Datensparsamkeit).

Neben einer Paket-Firewall werden in der Regel auch auf der Anwendungsebene Programme eingesetzt, die die Kommunikation zwischen internem und externem Netz ermöglichen. Dies kann zum Beispiel ein Mail-Server oder Proxy-Server sein. Auf diesen Servern kann nicht nur der Aufbau einer Verbindung zwischen zwei IP Adressen protokolliert werden, sondern beispielsweise auch, wer mit wem E-Mails ausgetauscht hat und welche IP Adresse welche WWW-URLs besucht hat.

Da diese Daten normalerweise nicht für Abrechnungszwecke verwendet werden, dürfen sie nur zu Betriebszwecken gespeichert und verwendet werden. Da die zuverlässige Übermittlung von E-Mails einerseits auch das Suchen von länger zurückliegenden Fehlern nötig machen kann und andererseits der Mailserver auch Angriffen von Außen ausgesetzt ist, betrachte ich hier eine strikt zweckgebundene Speicherung von bis zu drei Monaten für zulässig. Für einen Proxy fallen keine sicherheitsrelevanten Protokolldaten an, deshalb müssen die Daten so schnell wie möglich, spätestens jedoch nach einem Tag gelöscht oder anonymisiert werden - falls sich die Protokollierung nicht gänzlich unterbinden lässt, was immer zu bevorzugen ist.

Protokollauswertung auf Webservern

Neben den Diensteanbietern haben auch die Inhaltsanbieter im Internet ein großes Interesse an Daten über die Nutzung ihres Angebots und das Surf-Verhalten der Dienstenutzer. Ein Webserver, der die einzelnen Webseiten an die Nutzer ausliefert, protokolliert in der Standardkonfiguration die abgerufene URL, die anfordernde IP Adresse, den Browser und das Betriebssystem des Nutzers sowie eventuell an den Server übergebene Argumente wie etwa die Daten, die in einem Formular eingegeben wurden.

Grundsätzlich ist auch hier ist die IP Adresse, unabhängig davon, ob sie dynamisch vergeben oder statisch ist, als personenbezogen zu betrachten. Sowohl dynamische also auch statische IP Adressen können vom jeweiligen Netzblock Eigentümer in der Regel einer Person oder zumindest einem Telefon- oder DSL-anschluss zugeordnet werden. Sollen Auswertungen über den Nutzungsgrad des Internetauftritts gefertigt werden, so ist die Speicherung der vollständigen IP Adresse hierzu nicht erforderlich, das heißt sie ist nicht zulässig. Da die meisten Web-Server nur eine vollständige Protokollierung der IP Adressen oder überhaupt keine Protokollierung zulassen, ist es jedoch akzeptierbar, wenn die Datensätze, etwa durch Wegkürzen der drei letzten Stellen, täglich anonymisiert werden.

17.3.2. Einsatz von Videotechnik

In früheren Tätigkeitsberichten habe ich mich bereits zu Fragen

• der Videoüberwachung kommunaler Wertstoffhöfe und Containerstandorte (vgl. 18. TB, Ziff. 18.1),
• der Bildaufnahmen bei Versammlungen durch die Polizei (vgl. 19. TB, Ziff. 5.6.3),
• der Videoüberwachung öffentlicher Straßen und Plätze durch die Polizei (vgl. 19. TB, Ziff. 5.6.4) und
• der Videoüberwachung öffentlicher Plätze durch Kommunen (vgl. 19. TB, Ziff. 8.8) geäußert.

Die Datenschutzbeauftragten des Bundes und der Länder haben sich im Rahmen ihrer 59. Sitzung vom 14./15.03.2000 in der Entschließung "Risiken und Grenzen der Videoüberwachung" mit dem Themenkomplex befasst und Grundsätze hierzu aufgestellt.

Und auch in diesem Berichtszeitraum wurde ich mehrfach zum Einsatz optisch-elektronischer Überwachungseinrichtungen um Beratung gebeten, so z.B.

• von einer Gemeinde zur Videoüberwachung ihres Friedhofes nach z.T. erheblichen Sachbeschädigungen und sonstigen nachhaltigen Störungen der Totenruhe,
• von einer meiner Kontrollkompetenz unterliegenden Einrichtung im Rahmen der Außensicherung ihrer Liegenschaften (insbesondere außerhalb der Dienstzeiten),
• von mehreren Schulen zur Überwachung ihres Eingangsbereichs zum Schutz vor Zutritt durch Unbefugte und
• von einer Universität zur Überwachung Ihrer CIP-Räume nach Diebstahlsvorfällen und zur Fertigung von Mitschnitten von Vorlesungen für weitere Informations- und Schulungszwecke.

Nun besteht die Schwierigkeit, dass in den o.g. Fällen einerseits keine bereichsspezifischen Regelungen - vergleichbar dem Einsatz von Videotechnik im Polizeibereich - bestehen und auch das Bayerische Datenschutzgesetz im Gegensatz zum Bundesdatenschutzgesetz (vgl. § 6 b BDSG) keine spezielle Rechtsnorm enthält. Da es sich bei Videoüberwachung aber um eine Datenerhebung handelt, bleibt als Prüfungsmaßstab mangels einer speziellen Norm nur Art. 16 BayDSG.

Aus Gründen der Prävention, der Gefahrenabwehr und zum Schutz des öffentlichen Eigentums halte ich Videoüberwachungen in den o.g. Fällen für akzeptabel, sofern nachfolgende Voraussetzungen erfüllt sind:

• Die Videoüberwachung dient der Verhinderung oder Verfolgung von Eigentumsstörungen und/oder sonstiger strafrechtlich relevanter Ereignisse und findet im Rahmen der Ausübung des Hausrechts statt.
• Ist keiner der vorstehenden Zwecke gegeben - wie teilweise im obigen vierten Fall (Vorlesungsmitschnitte) - so kommt nur eine rechtswirksame Einwilligung der Betroffenen in Betracht. Zu deren praktischer Erreichbarkeit habe ich aber gerade im Bereich einer Vielzahl von möglichen Betroffenen - z.B. Hörer von Vorlesungen - meine Zweifel.
• Die Videoüberwachung ist räumlich eng auf diejenigen Bereiche zu begrenzen, bei denen aufgrund der Erfahrungen der Vergangenheit auch künftig mit vergleichbaren Vorkommnissen (z.B. Diebstahl, Sachbeschädigung) gerechnet werden muss.
• Der Zeitraum für eine Videoüberwachung ist auf das unabdingbare Maß zu beschränken, d.h. sie erfolgt nur zu den Zeiten, in denen nach den bisherigen Erfahrungen mit einem Schadensfall gerechnet werden muss, also z.B. im o.g. Fall des Friedhofs nur nachts zu den Zeiten, in denen das Betreten des Friedhofs nicht erlaubt ist.
• Gemäß Art. 16 Abs. 2 Satz 1 BayDSG sind personenbezogene Daten primär beim Betroffenen mit dessen Kenntnis zu erheben. Auf die Videoüberwachung ist deshalb durch entsprechende Hinweisschilder deutlich hinzuweisen, auf denen der Erhebungszweck anzugeben ist (vgl. Art. 16 Abs. 3 Satz 1 BayDSG).
• Die Aufzeichnungen unterliegen einer strikten Zweckbindung und dürfen nur zur Täterfeststellung und/oder zur Beweissicherung ausgewertet werden. Sie sind zu löschen (möglichst automatisch), sobald sie hierzu nicht mehr erforderlich sind. Die maximale Speicherdauer für Aufzeichnungen ist möglichst kurz zu fassen, also z.B. auf 36 Stunden im o.g. Fall des gemeindlichen Friedhofs oder auf drei Schultage im Falle der o.g. Schulen.
• Sind die Kameraeinrichtungen schwenkbar und evtl. überdies zoombar ausgelegt, so ist darauf zu achten, dass keine schutzwürdigen Belange eigener Bediensteter betroffen werden (z.B. zoomendes Schwenken mit Blick in Diensträume hinein). Dies kann je nach verwendetem System z.B. durch technische Beschränkung der Nutzbarkeit von Zoom- und Schwenkfunktion auf Zeiträume außerhalb der Dienstzeiten und/oder durch softwaretechnisches Sperren bestimmter möglicher Beobachtungsbereiche (Ausblenden) erreicht werden.
• Es sind geeignete Sicherungsmaßnahmen vor einem unberechtigten Zugang und Zugriff zu den Aufzeichnungsgeräten und zu den Aufzeichnungen zu ergreifen.
• Es sind entsprechende schriftliche Regelungen und Festlegungen zu treffen.

Das Bayerische Staatsministerium für Unterricht und Kultus hat auch als Reaktion auf meine Beratung mehrerer Schulen in einem Informationsschreiben alle Schularten über die o.g. Grundsätze zur Videoüberwachung schriftlich unterrichtet. Ich begrüße diese Maßnahme.

17.3.3. Outsourcing von Kommunaldaten

Im vergangenen Jahr sind einige Kommunen an mich herangetreten, mit der Bitte um Auskunft, ob eine Gemeinde berechtigt sei, personenbezogene Daten in ein privat betriebenes Rechenzentrum auszulagern. Ebenfalls Unklarheit herrschte darüber, in wieweit einzelne DV-Leistungen (z. B. Systemverwaltung) ausgelagert werden können.

Outsourcing der Datenbankserver mit dem gesamten Datenbestand

Art. 6 des Bayerischen Datenschutzgesetzes (BayDSG) enthält Regelungen, die bei der Erhebung, Verarbeitung oder Nutzung personenbezogener Daten im Auftrag zu beachten sind. Im Umkehrschluss kann daraus entnommen werden, dass sich eine öffentliche Stelle bei der Erhebung, Verarbeitung oder Nutzung personenbezogener Daten grundsätzlich einer anderen Stelle bedienen darf, wobei vom Gesetzgeber keine Einschränkung zu Lasten lediglich öffentlicher Auftragnehmer getroffen wurde. Voraussetzung ist jedoch, dass keine Funktionsübertragung stattfindet, das heißt die Aufgabe selbst, zu deren Wahrnehmung die Erhebung, Verarbeitung oder Nutzung dient, muss beim Auftraggeber verbleiben (Wilde/Ehmann/Niese/ Knoblauch, Bayerisches Datenschutzgesetz Art. 6, Rdnr. 10). Die Erhebung, Verarbeitung oder Nutzung von Daten, mit der die andere Stelle beauftragt wird, darf somit im Ergebnis lediglich in einer Hilfstätigkeit bestehen.

Bei der Auftragsdatenverarbeitung bleibt wie unter Nr. 17.1.5. - Auftragsdatenverarbeitung (Outsourcing) - dargelegt, der Auftraggeber für die Einhaltung der Vorschriften des Bayerischen Datenschutzgesetzes und anderer Vorschriften über den Datenschutz verantwortlich. Die im zweiten Abschnitt des Bayerischen Datenschutzgesetzes genannten Rechte, zum Beispiel das Auskunftsrecht des Betroffenen, sind ihm gegenüber geltend zu machen (Art. 6 Abs. 1 BayDSG). Nach Art. 6 Abs. 2 BayDSG ist der Auftragnehmer unter besonderer Berücksichtigung der Eignung der von ihm getroffenen technischen und organisatorischen Maßnahmen sorgfältig auszuwählen. Der Auftrag ist schriftlich zu erteilen, wobei Datenerhebung, -verarbeitung oder -nutzung, die technischen und organisatorischen Maßnahmen und etwaige Unterauftragsverhältnisse festzulegen sind.

Ich halte die Vorhaltung personenbezogener Daten von Kommunen in einer Datenbank eines privaten Rechenzentrumsbetreibers im Rahmen der Auftragsdatenverarbeitung unter Beachtung der oben dargestellten Grundsätze und unter Beachtung der nachstehenden Ausnahmen generell für zulässig, wenn auch nicht unbedingt für wünschenswert, da sich die Gefahr erhöht, dass Unberechtigte auf die den Gemeinden größtenteils gezwungenermaßen und nicht freiwillig anvertrauten Daten der Bürger Zugriff nehmen können.

Ich weise jedoch darauf hin, dass für bestimmte Daten spezielle gesetzliche Bestimmungen eine Datenverarbeitung im Auftrag ausschließen. So können nach Art. 36 Abs. 1 Satz 1 des Bayerischen Meldegesetzes Meldebehörden lediglich andere Gemeinden oder die Anstalt für kommunale Datenverarbeitung in Bayern mit der Erfüllung der Aufgaben nach dem Bayerischen Meldegesetz und den aufgrund dieses Gesetzes erlassenen Rechtsvorschriften mit Hilfe automatisierter Verfahren beauftragt werden. Diese Regelung schließt zwar die Möglichkeit nicht aus, sich zur Erfüllung einzelner Datenverarbeitungsaufgaben, wie zum Beispiel der Erfassung von Daten, privater Institutionen zu bedienen, soweit dabei die Voraussetzungen des Bayerischen Meldegesetzes und des Bayerischen Datenschutzgesetzes beachtet werden, die Beauftragung privater Auftragnehmer mit der Erfüllung aller mit der automatisierten Führung des Melderegisters zusammenhängenden Aufgaben ist danach jedoch nicht möglich. Gleiches gilt gemäß Art. 80 Abs. 5 Nr. 2 SGB X für die Sozialdatenverarbeitung im Auftrag. Auch hier darf der Auftrag nicht die gesamte Speicherung des Datenbestandes umfassen.

Soweit die Speicherung der im vorherigen Absatz erwähnten Datenbestände von der Auftragsdatenverarbeitung ausgenommen werden würde, müsste darauf geachtet werden, dass eine Kenntnisnahme und ein Zugriff auf andere sensible Datenbestände durch den Auftragnehmer (insbesondere im Rahmen der durch den Auftragnehmer übernommen Systemadministratortätigkeiten) im Hinblick auf die schutzwürdigen Belange der Betroffenen durch Verschlüsselung auszuschließen ist. Dies gilt z. B. für folgende Datenbestände:

• aus dem Steueramt ( § 30 AO - Steuergeheimnis),
• aus dem Personalbereich (Art. 100 ff. BayBG -Vertraulichkeit der Personalakte),
• für Datenbestände, die der ärztlichen Schweigepflicht unterliegen (§ 203 StGB - Patientengeheimnis),
• für Personenstandsdaten (§ 61 PStG - eingeschränktes Einsichtsrecht),
• aber auch für Daten in Vollstreckungsangelegenheiten und sonstigen Verwaltungsverfahren, die nach Art. 30 BayVwVfG geheim zu halten sind.

Die einzige Möglichkeit, die ich derzeit für eine komplette Auslagerung der Kommunaldaten sehe, besteht darin, einen Raum beim Outsourcingpartner anzumieten und dort die Server der Kommune aufzustellen. Die Verfügungsgewalt über diesen Raum muss ausschließlich beim Mieter liegen. Außerdem muss der Vermieter ausdrücklich auf das ihm sonst nach dem BGB zustehende Vermieterpfandrecht verzichten. Zur Gewährleistung der Zugangssicherheit zum angemieteten Serverraum müsse Maßnahmen zur Innen- und Außensicherung wie Installation einer Einbruchmeldeanlage an Fenster und Türen, Ausstattung der Türe des Serverraums mit mechanischem Türschließer, Zylinderschloss und Türknauf ergriffen werden. Für die Gewährleistung der Vertraulichkeit, Integrität, Verfügbarkeit und Authentizität für die gespeicherten und zu übermittelnden Daten müssen zusätzliche Maßnahmen (z. B. Verschlüsselung - siehe Zentrale Datenbank verschiedener Gemeinden und Auslagerung der Systemadministration) ergriffen werden.

Zentrale Datenbank für mehrere Gemeinden

Bei der Vorhaltung personenbezogener Daten verschiedener Gemeinden in einer zentralen Datenbank ist zusätzlich zu den oben genannten Maßnahmen darauf zu achten, dass die Datenbestände zumindest logisch getrennt voneinander gespeichert werden. Die Anlegung einer einzigen Datei für alle Gemeinden ist unzulässig, soweit eine solche nicht ausdrücklich vom Gesetz vorgesehen ist. Sie ist aus datenschutzrechtlicher Sicht auch insoweit abzulehnen, als ein Missbrauch einer solchen Datei regelmäßig schwerwiegender ist als der der Datei einer einzelnen Gemeinde, da sie einen wesentlich umfassenderen Datenbestand aufweist. Aus allgemeinen datenschutzrechtlichen Überlegungen heraus ist es zudem wünschenswert, zentrale Datensammlungen möglichst zu verhindern bzw. soweit sie sich nicht vermeiden lassen, ihre Zahl möglichst gering zu halten, da sie eine erhöhte Gefahr in sich bergen, unzulässigerweise oder gegebenenfalls auch nach Schaffung einer entsprechenden Rechtsgrundlage für andere Zwecke als den, zu dem sie angelegt wurden, genutzt zu werden.

Der Zugriff auf die Daten ist darüber hinaus insoweit zu beschränken, als jede Kommune nur ihre eigenen Daten abrufen kann, da die Zuständigkeit nicht über das jeweilige Hoheitsgebiet hinaus reicht. Sollten im Einzelfall Daten einer anderen Gemeinde zur Erfüllung einer bestimmten Aufgabe notwendig sein, können diese unter Berücksichtigung der einschlägigen datenschutzrechtlichen Vorschriften übermittelt werden.

Außerdem weise ich darauf hin, dass durch ausreichende technische und organisatorische Maßnahmen sicherzustellen ist, dass die Vorschriften des Bayerischen Datenschutzgesetzes und anderer Gesetze über den Datenschutz eingehalten werden. Dazu gehört zum Beispiel, dass geeignete Vorkehrungen getroffen werden, um einen Zugriff unbefugter Dritter auf die gespeicherten Daten zu verhindern. Außerdem ist zur Wahrung der Vertraulichkeit und Integrität der Daten eine Verschlüsselung der Daten auf dem Übertragungsweg, der bedingt ist durch die räumliche Trennung des Rechners von der Gemeindeverwaltung, zwingend erforderlich. Als hinreichend sichere Algorithmen gelten derzeit beispielsweise Triple-DES mit 112 oder IDEA mit 128 Bit Schlüssellänge. Für asymmetrische Verfahren wie RSA wird empfohlen, eine Schlüssellänge von wenigstens 1024 Bit zu verwenden. Zur Durchführung der Verschlüsselung bietet sich die Einrichtung eines virtuellen privaten Netzes (VPN) an. Ein VPN ist ein privates Netzwerk, welches von der öffentlichen Telekommunikationsstruktur Gebrauch macht, gleichzeitig die Privatsphäre durch den Einsatz von so genannten Tunnelling- und Sicherheitsprotokollen schützt und in der Regel über das Internet realisiert wird. Virtuell bedeutet dabei, dass der Anwender glaubt, seine Daten laufen über exklusive (private) Verbindungen. In Wirklichkeit wird die vorhandene Netzstruktur jedoch - aus Kostengründen - von verschiedenen Anwendern gemeinsam genutzt.

Neben den allgemein bekannten Sicherheitsmaßnahmen (z. B. rigorose Einschränkung der Zugriffs- und Nutzungsrechte auf das unbedingt Notwendige, Ergreifung von Maßnahmen zur Virenbekämpfung, Auswertung von Sicherheitsverletzungen in den maschinell geführten Protokollen und effektiver Passwortschutz - siehe Orientierungshilfe zur "Passwortvergabe, -wahl und -verwaltung", abrufbar auf meiner Homepage www.datenschutz-bayern.de im Bereich Technik/Orientierungshilfen/Allgemeines) müssen zur Absicherung der Gemeindedaten zusätzliche Maßnahmen ergriffen werden. So müssen beispielsweise alle Server durch Maßnahmen der Zugangskontrolle physisch geschützt werden. Die Datenzugriffe auf Server und insbesondere die Nutzung administrativer Berechtigungen müssen intensiv mit Hilfe der Protokollierung überwacht werden. Sonstige Hinweise zur Protokollierung enthält die Orientierungshilfen "Datenschutzrechtliche Protokollierung beim Betrieb informationstechnischer Systeme (IT-Systeme)" auf der Homepage des Bayerischen Landesbeauftragten für den Datenschutz.

Natürlich ist es im Rahmen der Auftragskontrolle auch erforderlich, dass sich die Gemeinde davon überzeugt, dass der Auftragnehmer die Datensicherheit durch Ergreifung der oben angeführten Datensicherheitsmaßnahmen gewährleistet.

Auslagerung lediglich der Systemadministration

Eine ledigliche Übernahme der Systemadministration der Server und die Überwachung des lokalen Netzwerkes einer Kommune mittels Fernwartung durch eine Privatfirma ist insbesondere dann nicht als Teilaspekt der Speicherung und sonstigen Verarbeitung von personenbezogenen Daten anzusehen, wenn den Systemadministratoren im Normalbetrieb keinerlei Zugriff auf die gespeicherten personenbezogenen Daten gestattet ist. Aufgabe der Systemadministration ist die Herstellung und Aufrechterhaltung des ordnungsgemäßen Betriebs der DV-Anlagen, nicht aber die fachspezifische Verarbeitung personenbezogener Daten. So könnte beispielsweise die Datenbankadministration durch eigenes Personal des Kunden erfolgen. Damit ist auch für Meldedaten und Sozialdaten der Begriff der Datenverarbeitung im Auftrag (Art. 6 BayDSG) nicht erfüllt. Die Privatfirma wird nicht Auftragnehmer im Sinne des Bayerischen Datenschutzgesetzes. Zur ausreichenden Wahrung der Belange des Betroffenen sieht Art. 6 Abs. 4 BayDSG i. d. F. des Änderungsgesetzes vom 25.10.2000 (GVBl. S. 752) wegen der ähnlich gelagerten Interessenlage jedoch die entsprechende Geltung der Absätze 1 bis 3 dieser Vorschrift vor. Damit ist gemäß Art. 6 Abs. 2 BayDSG insbesondere der Auftrag schriftlich zu erteilen, wobei u.a. die technischen und organisatorischen Maßnahmen festzulegen sind. Unbedingt erforderlich sind insbesondere Maßnahmen zur:

• Zugangskontrolle (z. B. Identifikation und Authentisierung, sicherer Verbindungsaufbau mittels Call Back-Verfahren über eine Firewall, dedizierte Vergabe von Zugriffsrechten und Wartungsprivilegien, Protokollierung aller Zugriffe, Ergreifung von Maßnahmen beim Zugriff auf Kundendaten)
• Wahrung der Vertraulichkeit (z. B. Einsatz von Datenverschlüsselungskomponenten bei der Datenspeicherung und der Datenübertragung, Errichtung von "Virtuellen Privaten Netzen")
• Kundenkontrollmaßnahmen (z. B. Kontrolle der Wartungsaktivitäten online oder mittels ausgewerteter Wartungsprotokolle, ggf. Unterbrechungsmöglichkeit der Fernwartung)
• Organisatorische Maßnahmen (z. B. Einhaltung der Verschwiegenheitsvorschriften, schriftliche Festlegung der Wartungsaktivitäten, Kontrolle der Protokolle)

Da im Gegensatz zu einer reinen Hard- bzw. Softwarefernwartung hier die Systemadministrierung durch den Dritten erfolgt, ist neben einer Datenverschlüsselung insbesondere Wert auf eine umfassende Protokollierung aller Systemaktivitäten und Fernwartungszugriffe zu legen. Aus den Protokollen muss sich die Frage beantworten lassen: "Wer hat wann mit welchen Mitteln was veranlasst bzw. worauf zugegriffen?" Außerdem müssen sich Systemzustände ableiten lassen: "Wer hatte von wann bis wann welche Zugriffsrechte?" Folgende Aktivitäten sind zur Überwachung der Systemadministrations- und Fernwartungsaktivitäten vollständig zu protokollieren:

• Systemgenerierung und Modifikation von Systemparametern
• Einrichten von Benutzern
• Verwaltung von Befugnistabellen
• Änderungen an der Dateiorganisation
• Durchführung von Backup-, Restore- und sonstigen Datensicherungsmaßnahmen
• Aufruf von Administrations-Tools
• Versuche unbefugten Einloggens sowie die Überschreitung von Befugnissen
• Datenübertragungen
• Benutzung von automatisierten Abrufverfahren
• Eingabe, Veränderung und Löschung von Daten durch den Auftragnehmer
• Aufruf von besonders "sensiblen" Programmen

Die Zwangsläufigkeit und damit die Vollständigkeit der Protokolle muss gewährleistet werden. Das Gleiche gilt für die Manipulationssicherheit der Einträge in den Protokolldateien. Die Protokolle müssen durch den Auftraggeber ausgewertet werden. Dazu sind sie so zu gestalten, dass eine effektive Überprüfung möglich ist.

Im Übrigen möchte ich darauf hinweisen, dass bei einer Auslagerung von Systemadministrationstätigkeiten an eine Privatfirma die Aufrechterhaltung eines ordnungsgemäßen Betriebes der Datenverarbeitungsanlagen, z.B. im Falle eines Streiks beim Auftragnehmer, nicht immer gewährleistet ist.

17.3.4. OK.FIS

Im Berichtszeitraum sind mehrere Städte an mich mit der Bitte herangetreten, zu prüfen, ob das Finanzinformationssystem OK.FIS der AKDB datenschutzrechtlich unbedenklich sei. Hauptkritikpunkt war, dass alle Anordnungsdienststellen einer Stadt Zugriff auf alle Finanzadressen (FAD) dieser Kommune hatten. So konnten alle Mitarbeiter neben der Wohnanschrift auch alle anderen Daten - wie Bankverbindungen oder Immobilienobjekte - sowohl von Bürgern als auch von Bediensteten einsehen.

Ich habe deshalb mit Vertretern der AKDB ein Gespräch bezüglich der Datenschutz- und Datensicherheitsmaßnahmen im OK.FIS-Verfahren geführt. Dabei hat sich herausgestellt, dass der Zugriff auf die Adressdatenbank in der sich im Einsatz befindlichen Version des Verfahrens nicht detailliert geregelt war. Entweder besaß ein Mitarbeiter den Zugriff auf die Adressdatenbank mit allen darin befindlichen Daten oder er besaß keinerlei Zugriffsrechte. Eine Begrenzung des Zugriffs auf lediglich die Daten seines Sachbereichs oder einzelne Adressen bzw. Adressangaben war bei der eingesetzten Verfahrensversion nicht möglich. Damit konnte jeder Nutzer der Adressdatenbank auf alle Finanzdaten, Bankverbindungen und i.d.R. auf die zugeordneten Objekte zugreifen.

Außerdem bestand die Gefahr der Eintragung einer nicht gewünschten Bankverbindung. Hatte der Betroffene gegenüber der sachbearbeitenden Stelle eine Bankverbindung bekannt gegeben, so wurde diese vom Sachbearbeiter eingetragen. War der sachbearbeitenden Stelle die Bankverbindung nicht bekannt oder unterblieb der Eintrag des gewünschten Kontos, so wurde - soweit sie der Kasse bekannt war - von dieser die Bankverbindung (oder eine der bekannten Bankverbindungen) beim Zahlungsverkehr eingetragen. Dies konnte dann dazu führen, dass Zahlungen auf ein anderes als das gewünschte Konto erfolgte. War auch der Kasse kein Konto bekannt, wurde der Betroffene angeschrieben. Dieses daraufhin mitgeteilte Konto wurde - soweit vom Betroffenen nicht anders gewünscht - für alle Zahlungen genutzt.

Weiterhin bestand bei der zum Zeitpunkt des Gespräches eingesetzten Version des Verfahrens keine Möglichkeit, (nicht mehr benötigte) Finanzadressen oder einer Adresse zugewiesene Objekte zu löschen oder zu sperren. Damit konnten sich beispielsweise auch die Daten bereits verstorbener Bürger noch im Datenpool befinden.

Alles dies war nicht datenschutzgerecht.

Den Vertretern der AKDB unterbreitete ich im Rahmen des erwähnten Gespräches folgende Forderungen:

• Anpassung einer neuen Programmversion an die Rechtslage (kein gemeinsamer Zugriff auf die Adressdatenbank und die zugewiesenen Objekte). Jede Adresse darf nur dem berechtigten Personenkreis zugänglich sein.
• Die Vergabe der Benutzerberechtigungen und Zugriffsrechte für das Verfahren muss revisionsfähig erfolgen.
• Es muss aus Revisionsgründen jederzeit nachvollziehbar sein, wer welches Datenfeld ausgefüllt bzw. geändert hat (Protokollierung).
• Nach einer durchgeführten Jahresabrechnung und Archivierung des Altbestandes sollte die Möglichkeit bestehen, alle Finanzadressen ohne aktuelle Objekte zu löschen. Auf diese Möglichkeit der automatischen Löschung muss der Kunde der AKDB (z. B. Gemeinde) hingewiesen werden. Die Entscheidung über die Löschung verbleibt dann bei diesem Kunden.
• Alle einer Finanzadresse zugewiesenen Objekte müssen vom jeweils zuständigen Sachbearbeiter gelöscht werden können.
• Sind verschiedene Objekte einer sachbearbeitenden Stelle zugeordnet, muss die Möglichkeit geschaffen werden, den Zugriff einzelner Mitarbeiter dieser Stelle auf einzelne dieser Objekte zu beschränken (z. B. Abgrenzung Personalabteilung/Beihilfesachbearbeitung).

Mit Ausnahme der Revisionsfähigkeit der Benutzerverwaltung und der Protokollierung der Datenzugriffe wurden inzwischen alle meine Forderungen durch die AKDB erfüllt, so dass nach derzeitigem Kenntnisstand keine datenschutzrechtlichen Bedenken gegen die neue Version des OK.FIS-Verfahrens bestehen. Ich gehe allerdings davon aus, dass die entsprechenden Protokollierungskomponenten schnellstmöglich in das Verfahren integriert werden.

17.3.5. Zugriff auf das amtliche Liegenschaftsbuch

Im Berichtszeitraum wurde von der Bayerischen Vermessungsverwaltung das Auswertesystem ALB-Online entwickelt, welches zur Erteilung amtlicher Auskünfte sowie für die Datenauswertung anderer Behörden (insbesondere der Kommunen) genutzt werden kann und einen Zugriff auf die Daten des ALB (Automatisiertes Liegenschaftsbuch) einschließlich der Digitalen Flurkarte ermöglicht. Zu der Einrichtung eines automatisierten Abrufverfahrens nach Art. 8 BayDSG durch die Bayerische Vermessensverwaltung hatte ich bereits im Jahre 1998 in einer Korrespondenz mit der Bayerischen Staatskanzlei und dem Bayerischen Landkreistag die Auffassung vertreten, dass bei der Einrichtung eines solchen Verfahrens die schutzwürdigen Interessen der Betroffenen berücksichtigt sein müssen und der Zugriff auf die Daten zur Wahrnehmung einer konkreten Aufgabe erforderlich sein muss. Eine Weitergabe sämtlicher Daten des Liegenschaftsbuches für unbestimmte, vorher nicht absehbare Zwecke, habe ich als eine "Datenverarbeitung auf Vorrat" abgelehnt.

Im Rahmen eines Pilotversuches wurde dem Landratsamt Starnberg für projektbezogene Einzelfälle der Online-Abruf (z. B. für Abfragen bei Altlastenverdachtsfällen, für Abfragen bei der Überprüfung von Anlagen nach der Verordnung zum Umgang mit wassergefährdenden Stoffen (VAwS) und für Abfragen bei der Einleitung von Pflegemaßnahmen) von personenbezogenen Daten aus dem ALB gestattet. Meine Geschäftsstelle wirkte dabei von Beginn an bezüglich der Fragen zum Datenschutz und zur Datensicherheit beratend mit. Sowohl die Bayerische Vermessungsverwaltung als auch das Pilot-Landratsamt waren für meine Anregungen und Forderungen aufgeschlossen.

Von Anfang an wurde darauf geachtet, dass lediglich ein begrenzter Personenkreis des Landratsamtes ALB-Anfragen starten kann. Diese Personen müssen mit Angabe des Namens, Vornamens, der Dienstbezeichnung und der E-Mail-Adresse der BFD München zur Einrichtung der Zugriffsrechte mitgeteilt werden.

Zur Identifizierung und Authentifizierung muss sich ein Anwender mittels Eingabe einer Benutzerkennung und eines Passwortes legitimieren. Dabei ist jeder Benutzer bei seiner Erstanmeldung gezwungen, das ihm mitgeteilte Transportpasswort in ein nur ihm bekanntes persönliches Kennwort zu ändern. Unsere Forderungen bezüglich der Passwortvergabe, -wahl und -verwaltung (siehe die gleichnamige Orientierungshilfe auf unserer Homepage www.datenschutz-bayern.de im Bereich Technik/Orientierungshilfen/Allgemeines) werden beachtet.

Die Datenanfrage erfolgt über eine gesicherte SSL-Verbindung (128 Bit-Verschlüsselung). Dabei muss bei jeder Abfrage ein Grund angegeben werden. Die zugelassenen Gründe sind in einem Katalog definiert. Das Abfrageergebnis wird sodann als verschlüsselter Dateianhang (asymmetrische Verschlüsselung mittels PGP - Schlüssellänge: 1024 Bit) vom Server des Bayerischen Vermessungsamtes per E-Mail an die jeweilige persönliche Mailbox des autorisierten Benutzers gesandt, wobei vom Server als Mailadresse diejenige ausgewählt wird, die bei der Vermessungsverwaltung als zu der betreffenden Benutzerkennung gehörend gespeichert ist. Durch dieses Sicherheitsmerkmal können unbefugte Zugriffsversuche entdeckt und unberechtigte Datenzugriffe verhindert werden. Die Daten können dann in anderen DV-Programmen weiterverarbeitet werden.

Die BFD München führt ein automatisiertes Zugriffsprotokoll, in dem Datum, Uhrzeit, Name des Abrufenden, Grund der Abfrage und die E-Mail-Adresse des Benutzers erfasst werden. Eine Auswertung dieser Protokolle erfolgt stichprobenartig zur Kontrolle der Rechtmäßigkeit der Abfrage und bei vermuteten Sicherheitsverletzungen. Die Protokolldaten werden ein halbes Jahr aufbewahrt und anschließend gelöscht.

Die Bayerische Vermessungsverwaltung beabsichtigt, dieses Verfahren auf weitere Landratsämter und Gemeinden auszuweiten.

17.3.6. Security@School

Im Rahmen der Prüfungs- und Kontrolltätigkeit besuchte ich auch eine Schule, die an dem Programm "Security@School" der Deutschen Telekom AG teilnimmt. Um den Anschluss der Netzwerke einer Schule sicherer zu machen, wird die Schule über eine von der Deutschen Telekom AG gelieferte Firewall mit Proxy-Diensten entweder über T-DSL/T-Online oder ISDN/T-Online an das Internet angeschlossen.

Die Firewall besitzt drei Netzwerkkarten und eine ISDN Karte, sodass über eine Netzwerkkarte oder die ISDN Karte der Zugang zum Internet und über die beiden verbleibenden Netzwerkkarten je das Schüler- und das Lehrer-/Verwaltungsnetzwerk angeschlossen werden können. Als Betriebssystem kommt ein vorkonfiguriertes GNU/Linux zum Einsatz.

Die Firewall setzt interne Netzwerkadressen auf eine offizielle Internet-Netzwerkadresse um (NAT, Native Adress Translation) und blockiert alle Zugriffe aus dem Internet auf interne Rechner. Es ist mit dieser Lösung somit nicht möglich, eigene Serverdienste (Web-Server) innerhalb der Schule zu betreiben. Es kann aber der Web-Server von T-Online verwendet werden, um einen Internetauftritt der Schule zu realisieren.

Zwischen den beiden internen Netzwerken ist ebenfalls keine Verbindung möglich, sodass das Lehrer-/Verwaltungsnetzwerk vom Schülernetzwerk und damit von möglichen, von dort ausgehenden Angriffsversuchen abgeschottet ist.

Das Lehrer-/Verwaltungsnetzwerk kann über NAT transparent auf alle Internetdienste zugreifen. Um die Geschwindigkeit zu steigern, steht zusätzlich noch ein WWW Proxy zur Verfügung, der für das Lehrer-/Verwaltungsnetzwerk keine Inhaltsfilterung vornimmt.

Für das Schülernetzwerk werden nur spezielle Internetdienste (http, https und ftp) über den auf der Firewall laufenden Proxy "squid" zugelassen. Ein Routing der Schüler-Netzwerkadressen ins Internet erfolgt nicht (kein NAT). Da alle Seitenaufrufe aus dem Schülernetzwerk über den Proxy gehen müssen, kann dieser zur Filterung von Internetinhalten verwendet werden. Es gibt eine von der Telekom betreute Liste an gesperrten Seiten, die auf Anfrage der Schule ergänzt werden kann. Die Schule kann aber auch eine eigene Sperrliste generieren und pflegen. Die Sperrung von Seiten soll dazu dienen, Schülern keinen Zugriff auf jugendgefährdende Inhalte des Internets zu gewähren. Dies kann aber natürlich kein perfekter Schutz sein - es bleibt somit bei der Verantwortung der Lehrer, die Internetnutzung der Schüler sinnvoll zu begleiten.

Die Struktur und Realisierung dieser Lösung schätze ich als grundsätzlich gut ein, es kann aber nur ein Teil eines Sicherheitskonzeptes einer Schule für den Internetanschluss sein.

Auf alle Fälle müssen sowohl alle Rechnersysteme im Lehrer-/Verwaltungsnetzwerk als auch im Schülernetzwerk mit immer aktualisierter Virenschutzsoftware ausgestattet sein. Die Firewall kann nicht verhindern, dass virenverseuchte Daten und Programme aus dem Internet oder über Datenträger in das Netz gelangen. Diese Virenschutzsoftware darf auch nicht einfach von Anwendern deaktivierbar sein.

Auch wenn die Firewall gegen Angriffe aus dem Internet schützen kann, so müssen auf Rechnern, auf denen schutzwürdige Daten gespeichert sind, zusätzliche Sicherheitsmassnahmen getroffen werden. Am besten ist es sicherlich, wenn solche Rechner keinen Zugang zum Internet erhalten. Falls derartige Rechner als Bestandteil des Lehrer-/Verwaltungsnetzwerkes doch über die Firewall an das Internet angeschlossen werden, so werden sie zwar gegen Angriffe aus dem Internet und aus dem Schülernetzwerk geschützt, im Falle einer Fernwartung der Firewall, die auch unbemerkt durchgeführt werden kann, sind diese Rechner jedoch ungeschützt. Deshalb muss hier besonders darauf geachtet werden, dass insbesondere auf diesen Rechnern aktuelle Sicherheitsupdates installiert sind, ein ausreichender Passwortschutz eingehalten wird und keine Freigaben für Zugriffe über das Netzwerk etc. eingerichtet sind. Sinnvollerweise sollte zusätzlich eine Verschlüsselung auf Datei-, Verzeichnis- oder Laufwerksebene durchgeführt werden.

Aus datenschutzrechtlicher Sicht bedenklich ist der verwendete Proxy. Dieser filtert alle Seitenaufrufe und kann somit genaue Auskunft über das Surfverhalten der Schüler geben. Die mitgelieferte Software zur Auswertung der Proxy-Logdateien "Calamaris" erstellt eine Übersicht über die Verwendung des Proxy. Hieraus sind jedoch keine Rückschlüsse auf einzelne Rechner oder Personen möglich. Trotzdem wäre dies vermutlich bei einer detaillierteren Auswertung der Logdateien, auf die auch der Fernwartungsdienst zugreifen kann, problemlos möglich. Deshalb sollte der Proxy so konfiguriert sein, dass nicht die vollständige IP Adresse des Absenders in den Logdateien mitprotokolliert wird (etwa durch das Setzen des Parameters "client_netmask" auf "255.255.255.0" in der Konfigurationsdatei des Proxys squid, wodurch das letztes Segment der IP Adresse des Absenders immer durch "0" ersetzt und somit anonymisiert wird). Ich habe dies der Schule so empfohlen; deren Stellungnahme steht noch aus.

Zusätzlich zu einer Firewall für die Internetanbindung empfiehlt es sich auch, auf den Rechnern des Schülernetzwerkes Software einzusetzen, die die Funktionalität der Rechner einschränkt. So sollten Schüler keine Software installieren oder ändern dürfen und nur die Software starten dürfen, die für Unterrichtszwecke nötig ist. Die von meinen Mitarbeitern besuchte Schule setzte dafür die Softwareprodukte "INIS Classic" und "HDGuard" ein. Damit lässt sich für bestimmte Klassen eine bestimmte Softwareauswahl festlegen, die der Lehrer freigeben kann. Ebenso werden dadurch die Rechner nach Gebrauch wieder in den Originalzustand versetzt, sodass keine persönlichen Daten auf den Rechnern verbleiben (Cookies etc.). Außerdem wird dadurch zusätzlich zur Antivirensoftware ein weiterer Schutz gegen Schadenssoftware installiert.

17.3.7. WLAN

Mittels eines WLANs (wireless local area network - lokales Rechnernetz über Funk) lassen sich Rechner ohne die Verwendung von Netzwerkkabeln vernetzen. Die WLAN Technologie eignet sich zur Erweiterung fest verdrahteter LANs und ermöglicht größere Mobilität. Dies hat zum Beispiel Vorteile in denkmalgeschützten Gebäuden, in denen die Verlegung von Kabeln nur schwierig möglich ist, oder wenn die Teilnehmer des Rechnernetzes nicht immer an festen Arbeitsplätzen arbeiten (zum Beispiel Ärzte mit Laptops in Kliniken).

Standards

Ein minimales WLAN besteht aus zwei Rechnern mit WLAN-Karten, die im Ad-hoc-Modus betrieben werden. Diese beiden Rechner können ohne weitere Infrastruktur ein Netzwerk bilden und beispielsweise Dateien austauschen. Wird ein spezieller Empfänger und Sender benutzt, um mit den Endgeräten mit WLAN-Karten zu kommunizieren, spricht man vom Infrastruktur-Modus, der mit einer GSM-Zelle beim Mobilfunk verglichen werden kann.

Standardisiert ist die Übertragung mittels eines WLANs durch die IEEE 802.11 Working Group for Wireless Local Area Networks, die in den Standards IEEE 802.11 (bis 2Mbit/s), dem zurzeit am häufigst verwendeten IEEE 802.11b (bis 11Mbit/s) und IEEE 802.11a/g (bis 54Mbit/s) die technischen Voraussetzungen definiert hat. In diesen Standards werden die OSI-Schichten 1 (Physical Layer) und 2 (MAC-Layer) für WLANs spezifiziert. Die Funk-Übertragung findet im frei verfügbaren 2,4 GHz Band (Industrial Scientific Medical (ISM-) Band), das beispielsweise auch Bluetooth oder schnurlose DECT Telefone benutzen, oder im 5GHz Band statt.

Die maximale Sendeleistung einer Station ist in Europa auf 100mW beschränkt, womit sich innerhalb eines Hauses bis zu 150 Meter, außerhalb bis zu 500 Meter (bei eventuell nicht voller Übertragungsgeschwindigkeit) überbrücken lassen.

Geregelt wurde der Betrieb eines WLANs mit der Verfügung 122 im Amtsblatt 14/1997 (Vfg 122/1997) des damaligen Bundesministeriums für Post und Telekommunikation (BMPT) für den Betrieb von drahtlosen Datenfunkanlagen ab dem 21. Mai 1997. Mit dem Amtsblatt 22/1999 der Regulierungsbehörde für Telekommunikation und Post (RegTP) wurden mittels der Verfügung 154/1999 die bislang vorläufige Allgemeinzuteilung von Frequenzen nach Verfügung 122 in einigen Details präzisiert.

Innerhalb der eigenen Grundstücksgrenzen ist eine Nutzung ohne eine Anmeldung erlaubt. Bei dem Betrieb einer Richtfunkstrecke über die Grundstücksgrenzen hinaus muss diese bei der RegTP schriftlich angemeldet werden. Wird das WLAN einer nicht geschlossenen Benutzergruppe geöffnet, so ist dies eine lizenzpflichtige Nutzung, die eine Lizenz der Klasse 3 nach § 6 TKG erfordert und es werden dadurch entsprechende Gebühren laut Telekommunikationslizenzgebührenverordnung (TKLGebV) fällig.

Sicherheit

Soll ein WLAN zur Übertragung von schutzwürdigen Daten benutzt werden, so muss das WLAN, wie alle anderen Komponenten eines Rechnernetzes auch, in ein EDV Sicherheitskonzept eingegliedert werden. Problematisch bei WLANs ist, dass der physikalische Zugang zum Übertragungsmedium in der Regel unbemerkt, eventuell sogar ohne Betreten des Grundstücks des Betreibers, möglich ist. Somit kann nicht schon das Abschließen oder Deaktivieren von Netzwerksteckdosen als Zugangserschwernis dienen.

Damit ein Client mit einem so genannten Access Point (Empfangsstation, die den Zugang zum Netz ermöglicht) kommunizieren kann, muss auf beiden die gleiche Server Set ID (SSID) als Netzwerkname eingetragen sein. Die meisten heute verfügbaren Produkte werden mit Standardnamen ausgeliefert - diese sind bei Inbetriebnahme auf alle Fälle zu ändern. Einige Produkte erlauben es auch, als Netzwerkname "any" anzugeben. Häufig ist dies sogar die Standardeinstellung. Das Geheimhalten des Netznamens ist nicht ausreichend, um einen Zugangsschutz gegenüber Unberechtigten zu gewährleisten, vor allem, da die SSID auch bei eingeschalteter Verschlüsselung im Klartext übertragen wird und somit leicht abgehört werden kann.

Des Weiteren kann der Zugang nur für bestimmte MAC Adressen erlaubt werden. Allerdings gibt es Möglichkeiten, die MAC Adresse einer WLAN Karte zu verändern, sodass eine Fälschung und damit ebenfalls ein unerlaubter Zugriff machbar ist.

Um ein Funknetz aufzufinden, gibt es inzwischen einfach zu bedienende Software. Da das so genannte "Wardriving" (Auffinden von WLANs durch Umherfahren mit Auto und Laptop) und "Warchalking" (Markieren von Empfangsbereichen von offenen oder geschlossenen WLANs mittels Kreidezeichen auf Wänden und Strassen) sich steigender Beliebtheit erfreut, kann nicht davon ausgegangen werden, dass ein ungesichertes WLAN lange unentdeckt bleibt.

Um die Sicherheit zu erhöhen, gibt es spezielle WLAN Verschlüsselungsverfahren, die zum einen den Zugang zu einem Access Point sperren können und zum anderen die Verbindung abhörsicherer machen können. Das hierfür meistens verwendete WEP (Wired Eqivalent Privacy) Protokoll erschwert den Zugriff. In der Vergangenheit wurden aber bereits einige Lücken und Schwächen bekannt und ausgenutzt. Die Verschlüsselung kann mit 40 Bit oder 128 Bit erfolgen. Es gibt Bestrebungen, den WEP Standard zum Beispiel mittels RC4 Fast Packet Keyring (IEEE 802.11i) sicherer zu machen, es bleibt aber abzuwarten, wie schnell sich ein sichereres WEP Protokoll durchsetzen wird.

Aufgrund der oben genannten Sicherheitsrisiken auf der Netzwerk-Transportebene müssen für ein Funknetz neben

• geheimen Netzwerknamen,
• restriktiver MAC Authentifizierung und
• WEP Verschlüsselung

zusätzliche Sicherheitsmassnahmen getroffen werden. Dabei handelt es sich um folgende:

• Trennung des WLAN Segments mittels einer Firewall vom internen, schützenswerten Netz
• Unterbindung einer direkten Zugriffsmöglichkeit auf die internen Netzwerkkomponenten aus dem WLAN-Segment heraus
• Verschlüsselung der im WLAN genutzten Dienste (etwa Verwendung von https statt http) oder Schutz des gesamten Netzwerkverkehrs mittels eines VPN (Virtual Private Network)
• Ggf. Einsatz von Verschlüsselung auf Anwendungsebene

Somit gelten für die Datenübermittlung von mobilen Rechner aus ähnliche Sicherheitsanforderungen, wie bei Rechnern, die über das Internet auf das interne Netz zugreifen können sollen.

Des Weiteren müssen auch die mobilen Rechner selbst möglichst gut gegen Angriffe geschützt werden, denn sie befinden sich keineswegs hinter einer sicheren Firewall, sondern zusammen mit einem potenziellen Angreifer außerhalb der Firewall. Auch das Abhandenkommen (Diebstahl) eines WLAN Clients (Laptop) birgt die Gefahr, dass nicht nur die auf dem Laptop gespeicherten Daten in unberechtigte Hände gelangen, sondern unter Umständen ein Unbefugter mittels der registrierten WLAN Karte und richtiger SSID auf das interne Netz zugreifen kann. Deshalb sind die Nutzer darauf zu sensibilisieren, besonders auf diese Geräte zu achten und einen Verlust der WLAN Karte sofort zu melden. Die Geräte selbst sind mit wirksamen Zugriffssicherungsmechanismen auszustatten.

Leider liefern die meisten Hersteller ihre Produkte mit den minimalsten Sicherheitseinstellungen als Standard aus, sodass zwar sehr einfach eine erste Inbetriebnahme eines WLAN Segments erfolgen kann, dieses danach aber offen für vielerlei Angriffe ist. Es liegt am Betreiber, alle bekannten Sicherheitslücken durch geeignete Maßnahmen zu schließen und den Schaden durch eventuell neue Angriffsmethoden möglichst gering zu halten.

17.3.8. Persönlichkeitsschutz im Sozialamt

Gemäß § 35 Abs. 1 Satz 1 Sozialgesetzbuch (SGB) I haben Hilfe Suchende Anspruch darauf, dass die sie betreffenden Sozialdaten (§ 67 Abs. 1 SGB X) von den Leistungsträgern nicht unbefugt erhoben, verarbeitet oder genutzt werden (Sozialgeheimnis). Der Sozialleistungsträger ist damit verpflichtet, u. a. durch technische und organisatorische Maßnahmen (vgl. § 78 a SGB X) zu gewährleisten, dass Sozialdaten der Antragsteller bzw. Leistungsbezieher niemandem unberechtigterweise zur Kenntnis gelangen können.

Diese Verpflichtung folgt aus dem Grundrecht auf informationelle Selbstbestimmung. Neben diesem Grundrecht des Antragstellers steht allerdings ein ebenfalls grundgesetzlich garantiertes Recht auf körperliche Unversehrtheit der Bediensteten der jeweiligen Sozialbehörde. Insbesondere wenn der Antragsteller seine Belange nicht zu seiner Zufriedenheit berücksichtigt oder gewürdigt findet, kann es in Sozialbehörden auch zu verbalen oder gar körperlichen Attacken gegen die dortigen Bediensteten kommen. Manche Sozialämter sehen in dem Offenstehenlassen von Zwischen- und Verbindungstüren den bestmöglichen Schutz vor solchen Angriffen, da es die Möglichkeit bietet, der oder dem Angegriffenen zu Hilfe zu kommen. Im 15. Tätigkeitsbericht wurde diese Maßnahme als Lösungsmöglichkeit angesehen.

Neuerliche Beschwerden über das Offenlassen der Türen haben mich veranlasst, diese Frage erneut zu überprüfen. Ich habe zunächst versucht die widerstreitenden Interessen dadurch einer Lösung zuzuführen, dass ich die betreffenden Sozialämter aufgefordert habe, grundsätzlich den Antragsteller zu Beginn des Gespräches zu fragen, ob er mit dem Offenstehen der Türe einverstanden ist. Bei geöffneten Türen müsse darauf geachtet werden, dass die Besprechung zwischen einem Antragsteller und dem Sozialamtsbediensteten in einer Lautstärke geführt wird, dass die Inhalte der Besprechung im Nebenzimmer nicht zu verstehen sind.

Das Offenhalten der Verbindungstüren müsse die Ausnahme für Bedrohungen oder sonstige Agressionen bleiben, wobei bei der Entscheidung über die Verfahrensweise auf die vom Bediensteten subjektiv empfundene Bedrohungssituation abgestellt werden könne, da mögliche Angriffshandlungen unter Umständen nicht vorausgesehen werden könnten.

Vorstehender Lösungsversuch ist allerdings nicht das Optimum, insbesondere wenn man berücksichtigt, dass bei Antragstellern, von denen Agressionen nicht zu befürchten sind, eigentlich auch kein Anlass besteht, nach dem Einverständnis für das Offenhalten der Türen zu fragen und im umgekehrten Fall es auf sein Einverständnis nicht ankommen kann, wenn in dem Offenstehenlassen der Türe die gebotene Sicherheitsmaßnahme gesehen werden kann.

Bessere Lösungen sind deshalb zu prüfen. Dabei ist zu berücksichtigen, dass eine Gefährdung bzw. Beeinträchtigung des Rechts auf informationelle Selbstbestimmung unverhältnismäßig ist, wenn es zumutbare Alternativen gibt, den Schutz der Bediensteten anderweitig ebenso effektiv zu gewährleisten. Eine solche Alternative zum Offenstehenlassen der Türe sehe ich in einer Alarmeinrichtung, vergleichbar einem Alarmknopf bei Banken, die bei Betätigung in den Nachbarzimmern ein akustisches Signal auslöst und so eine schnelle Hilfeleistung im Bedarfsfall ermöglicht. Auch diese Maßnahme wurde im 15. Tätigkeitsbericht als Lösungsmöglichkeit angesehen. Ich habe deshalb die betreffende Kommune dringend gebeten, den Einbau einer Alarmanlage zu prüfen, oder mir zwingende Hinderungsgründe darzulegen.

Mit wurde entgegen gehalten, dass das Offenstehenlassen der Türen für das Sicherheitsgefühl der meist jungen Bediensteten des Sozialamts erforderlich sei. Ich nehme diesen Einwand ernst. Ich habe allerdings große Zweifel, ob offene Türen tatsächlich in einer Weise zu einer solchen Erhöhung des Sicherheitszustandes beitragen würden, die die Gefahr des Bruchs des Sozialgeheimnisses rechtfertigen würde. Ich bin gleichwohl der Auffassung, dass Sozialdatenschutz primär durch Einbau einer Alarmanlage gewährleistet werden muss. Das Sicherheitsgefühl der Bediensteten kann durch praktische Erprobung der Alarmanlage gefördert werden. In diesem Sinn bin ich nochmals an die betreffende Kommune herangetreten.

17.4. Orientierungshilfen

Im Berichtszeitraum hat meine Geschäftsstelle folgende Orientierungshilfen überarbeitet:

• "Grundsätze für "Benutzerrichtlinien für den Umgang mit Internet"" (http://www.datenschutz-bayern.de/technik/orient/ibenrili.pdf)
• "Einrichtung eines Benutzerservices" (http://www.datenschutz-bayern.de/technik/orient/benutzerservice.html)
• "Aufgaben eines behördlichen Datenschutzbeauftragten" (http://www.datenschutz-bayern.de/technik/orient/behDSB.html) und
• "Verfahrensverzeichnis" auch mit dem neuen Titel "Verfahrensbeschreibung" http://www.datenschutz-bayern.de/download/verfbes.pdf versehen.

Diese Orientierungshilfen können unter den o.a. URL direkt von meiner Home-Page und auch unter der Rubrik "Technik" abgerufen werden.

Aufgrund Gesetzesänderung ist das Führen eines Anlagenverzeichnisses nicht mehr erforderlich (vgl. Abschnitt 17.1.6, "Novelliertes Bayerisches Datenschutzgesetz"), sodass die Mustervorlage "Anlagenverzeichnis" entbehrlich und daher entfernt wurde.

Auf die Orientierungshilfe "Tele- und Mediendienste" mit Stand 01. Juli 2002 meines Hamburger Kollegen "http://fhh.hamburg.de/stadt/Aktuell/weitere-einrichtungen/datenschutzbeauftragter/informationsmaterial/internet-telekommunikation/orientierungshilfe-tele-und-mediendienste-pdf,property=source.pdf" (externer Link) darf ich hier zusätzlich verweisen.