Sie sind hier: > Start > Tätigkeitsberichte > 21. TB 2004 > 22. Technischer und organisatorischer Bereich

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

22. Technischer und organisatorischer Bereich

22.1. Grundsatzthemen

22.1.1. Bayerisches Behördennetz (BYBN, BayKOM)

22.1.1.1. Sicherheitsorganisation und –richtlinien

Im Berichtszeitraum lief der Rahmenvertrag mit bol Behörden Online GmbH über den Betrieb des Bayerischen Behördennetzes aus. Nach einer Ausschreibung, in der auch wesentliche Anpassungen im organisatorischen sowie im sicherheitstechnischen Bereich beim Behördennetz vorgenommen wurden, wurde die Firma BT Ignite GmbH & Co. OHG, München, mit der Fortführung des Bayerischen Behördennetzes (BYBN) und der Bereitstellung des zentralen Internetzugangs beauftragt (siehe Kapitel 17.1.1 des 20. Tätigkeitsberichts).

Mit Bekanntmachung vom 15.6.2004 hat die Bayerisches Staatsregierung die "Richtlinie für den koordinierten Einsatz der Informations- und Kommunikationstechnik (IuK) in der bayerischen Staatsverwaltung (IuK-KoordR)" erlassen. Diese regelt die künftige IuK-Strategie innerhalb der bayerischen Staatsverwaltung. Dazu zählen unter anderem das Bayerische Behördennetz und auch Verfahren für Verschlüsselung und Signatur.

Zur Umsetzung dieser Strategie wurde im Staatsministerium des Innern die Zentrale IuK-Leitstelle (ZIL) eingerichtet. Der geschäftsbereichübergreifende, beim Staatsministerium der Finanzen eingerichtete IuK-Fachausschuss steht der ZIL als beratendes Gremium zur Seite. Aufgabe der ZIL ist es, die notwendigen Richtlinien und Standards sowie die zu ergreifenden technisch-organisatorischen Maßnahmen zur Datensicherheit und zum Datenschutz verbindlich festzulegen und für deren Einhaltung und Überwachung zu sorgen. So hat die ZIL die "IT-Sicherheitsleitlinie für die bayerische Staatsverwaltung (IT-Security Policy)" erarbeitet. Darin wird ein gemeinsames Sicherheitsniveau definiert und eine entsprechende Sicherheitsorganisation etabliert.

Als zentrale Instanz dieser Sicherheitsorganisation fungiert der Chief Information Security Officer (CISO), der sich eines beratenden Sicherheitsteams bedient. Das Sicherheitsteam wiederum setzt sich aus den Beauftragten für IT-Sicherheit der Staatskanzlei, der Staatsministerien, des Obersten Rechnungshofs, des Landtagsamts und meiner Dienststelle sowie einem Computer
Emergency Response Team (CERT) zusammen. Bisher wurden von diesen Gremien bereits umfangreiche Sicherheitsrichtlinien (BayITSRL) erarbeitet und der ZIL zur Verabschiedung zugeleitet.

Durch diese Maßnahmen dürfte eine Grundlage für meine schon lange angemahnte Schaffung einer kompetenten und geschäftsbereichübergreifend bindenden Instanz für die Sicherheit der elektronische Kommunikation innerhalb des Bayerischen Behördennetzes geschaffen sein. Diese gilt es in nächster Zeit noch weiter auszufüllen.

22.1.1.2. Elektronische Signatur und Verschlüsselung

Für die sichere elektronische Kommunikation per E-Mail mit den Bürgern bieten inzwischen viele, wenn auch nicht alle staatlichen Behörden auf ihren Webseiten PGP Schlüssel an. Damit können Personen außerhalb des Behördennetzes sicher und vertraulich mit den jeweiligen Poststellen der Behörden E-Mails austauschen.

Wie schon in meinem letzten Tätigkeitsbericht erwähnt, konnte auch in diesem Berichtszeitraum nicht erreicht werden, dass ein nennenswerter Anteil von E-Mails zwischen den Behörden unter der Verwendung von S/MIME digital signiert oder verschlüsselt wird. Es wurden zwar einige tausend Zertifikate vom Statistischen Landesamt für Datenverarbeitung ausgegeben, sodass sich die Voraussetzungen für den Einsatz verbessert haben. Damit ist eine ausreichende Flächendeckung aber immer noch nicht erreicht, was auch an der nach wie vor zu heterogenen Softwarelandschaft liegt. Des Weiteren fehlt es aber anscheinend auch gelegentlich an der Motivation der einzelnen Behörden, E-Mails zu verschlüsseln und zu signieren.

22.1.1.3. Zentralisierung von Rechnerleistung

In Abschnitt 17.1.2 meines 19. Tätigkeitsberichts 2000 vom 14.12.2000 hatte ich ausgeführt, dass ich die heterogene technische und personelle Ausstattung der Teilnehmer am Bayerischen Behördennetz, d.h. die Heterogenität der IuK-Binnenstruktur in der bayerischen Staatsverwaltung, als mit ursächlich für die bestehenden Sicherheitsprobleme halte.

Einige wesentliche Merkmale dieser Struktur sind

• das Bestehen staatlicher Rechenzentren, z.B. beim Landesamt für Statistik und Datenverarbeitung, beim Technischen Finanzamt Nürnberg, beim Landeskriminalamt sowie in einigen Ministerien für deren nachgeordnete Bereiche, die sowohl eigene Aufgaben erledigen als auch z.T. als Dienstleistungsrechenzentren genutzt werden
  
• die unterschiedlich starke IT-Durchdringung der staatlichen Verwaltung,
  
• das z.T. bis auf Dienststellenebene eigenverantwortliche Auswählen, Beschaffen, Betreiben und Fortentwickeln von IuK-Einrichtungen und Software,
  
• daraus resultierend unterschiedlichste IuK-Ausstattungen bzgl. Hard- und Software in den IT-Betriebsstellen sowie
  
• z.T. Mangel an qualifiziertem EDV-Fachpersonal in den jeweiligen IT-Betriebsstellen.

In Anbetracht der Tatsache, dass die Bedeutung der IuK-Technologien für die öffentliche Verwaltung in der Vergangenheit sehr rasch zugenommen hatte und der IuK-Einsatz für die meisten Verwaltungsdienstleistungen zum maßgeblichen Faktor bezüglich Effizienz und Bürgerfreundlichkeit geworden waren, wurde im November 2001 der damalige Koordinierungsausschuss Datenverarbeitung (KoA DV) beauftragt, zu den Rechenzentren der staatlichen Verwaltung und den darauf laufenden Anwendungen eine Bestandsaufnahme durchzuführen sowie erste Überlegungen zu effizienzsteigernden Strukturen und zum Outsourcing von Leistungen der Rechenzentren vorzunehmen. Ziele dieser Bestandsaufnahme waren wie folgt:

• Gewährleistung der Sicherheit in der IuK-Technik und Daten: Zugangsschutz, Backup (räumliche Trennung), Ausfallrechenzentren
  
• Sicherstellung der Verfügbarkeit von Informationen und Diensten: 24 Std-Betrieb/365 Tage (Hochverfügbarkeit)
  
• Steigerung der Leistungsfähigkeit und Wirtschaftlichkeit durch Bündelung von IuK-Dienstleistungen
  
• Konsolidierung der Betriebssysteme unter Beachtung möglichster Herstellerunabhängigkeit
  
• Sicherung der Akzeptanz der benötigten IuK-Dienstleistung
  

Anlässlich einer Sondersitzung des damaligen Koordinierungsausschusses IuK (KoA IuK, Nachfolger des KoA DV) am 10.01.2003 wurde von der Staatskanzlei das mit Hilfe eines externen Unternehmens beabsichtigte Projekt "Untersuchung zur Konsolidierung von Rechen- und IT-Betriebszentren der Staatsverwaltung" vorgestellt. Ziel dieser Untersuchung sollte sein, die Zahl der Rechen- und IT-Betriebszentren vorwiegend aus Wirtschaftlichkeitsgründen drastisch zu reduzieren und die IuK-Ausstattung weitestmöglich zu vereinheitlichen.

Unmittelbar im Nachgang zu dieser Sondersitzung habe ich vorsorglich die Staatskanzlei und die Mitglieder des KoA IuK schriftlich auf folgende Aspekte hingewiesen:

• Die in der Leistungsbeschreibung zum Projektvertrag erhobene Forderung, dass das Soll-Konzept auch den Aspekten des Datenschutzes und der Sicherheit Rechnung tragen müsse, würde ausdrücklich begrüßt.
  
• Das Vorhaben berge aber u.U. erhebliches Gefahrenpotenzial für die Sicherstellung des Datenschutzes im staatlichen Bereich - nicht zuletzt dadurch, dass zentrale Datenbestände erfahrungsgemäß generell Begehrlichkeiten wecken.
  
• Vor dem letztendlichen Ziel der Untersuchung, die Anzahl der derzeit vorhandenen Rechen- und IT-Betriebszentren zu reduzieren, könnten die Datenschutz- und Datensicherheitsaspekte sowohl aus rechtlicher als auch aus technisch-organisatorischer Sicht einen ausgesprochen komplexen Umfang annehmen - je nach Umfang der vorgeschlagenen Konsolidierungsmaßnahme und den davon betroffenen zu verarbeitenden personenbezogenen Daten.
  
• Meinerseits bestünden erhebliche Zweifel, dass diese Thematik in der für die Untersuchung zur Verfügung stehenden knappen Zeit ausreichend beleuchtet und berücksichtigt werden könne. Dabei sei insbesondere zu berücksichtigen, dass bereichsspezifische Vorschriften dem Bayerischen Datenschutzgesetz vorgehen und zum Teil eine Auftragsdatenverarbeitung/ein Outsourcing aus Geheimhaltungspflichten verböten. Es erscheine fraglich, dass alle Dienststellen, die den Fragebogen zum Ausfüllen vorgelegt erhalten, diese Problematik an dieser Stelle und zu diesem Zeitpunkt erkennen und die hier erforderlichen Angaben im Fragebogen vollständig machten.
  
• Wegen der oben dargestellten Komplexität der vorab zu klärenden rechtlichen und technisch-organisatorischen Fragestellungen könne u.U. auch sehr schnell der Zustand erreicht werden, dass die Erreichung der mit der Konsolidierung angestrebten Ziele aufgrund zu ergreifender Sicherheitsmaßnahmen infrage gestellt oder gar verfehlt würden.

Am 29.07.2003 hat der Ministerrat entschieden, dass die bisherigen Rechen- und IT-Betriebszentren der Staatsverwaltung organisatorisch in zwei Rechenzentren (Nord und Süd) zusammengefasst werden. Die Staatskanzlei und die Ministerien können unter Berücksichtigung von Sicherheit und Wirtschaftlichkeit des Betriebs ihre IuK-Anwendungen aber auch von privaten Rechenzentren betreiben lassen. In einem ersten Schritt sollen 150 IT-Betriebszentren sukzessive organisatorisch in eines der beiden Rechenzentren eingegliedert und anschließend die entsprechenden IuK-Einrichtungen nach technischen und wirtschaftlichen Gesichtspunkten physikalisch konsolidiert werden.

An dieser Stelle wiederhole ich meine bei verschiedensten Gelegenheiten geäußerten Bedenken gegen zentrale Datenbestände, weil diese generell Begehrlichkeiten entwickeln, die mit der zunehmenden Automatisierung und Vernetzung der Datenverarbeitung noch wachsen.

Ich weise überdies deutlich darauf hin, dass

• der Grundsatz der informationellen Gewaltenteilung jedenfalls in jedem Einzelfall weiterhin sicherzustellen ist,
  
• Verstöße gegen Datenschutz und Datensicherheit bei zentralen Datenbeständen und IuK-Einrichtungen ungleich schwerer wiegen als bei dezentralen Datenbeständen mit weniger Daten,
  
• es sich bei der Übertragung der Datenverarbeitung an die beiden Rechenzentren um Auftragsdatenverarbeitung i.S.d. Art. 6 BayDSG handeln kann und dessen Bestimmungen dann unbedingt zu beachten und einzuhalten sind, ggf. ist sogar aufgrund spezialgesetzlicher Bestimmungen eine Auftragsdatenverarbeitung nicht zulässig,
  
• die Datentrennung, die Geheimhaltung, die Zugriffsbeschränkungen und die Zweckbindungen für die erhobenen Daten durch diese Zentralisierungen nicht tangiert oder gar unterlaufen werden dürfen und
  
• dem Stand der Technik entsprechende und geeignete Maßnahmen ergriffen werden müssen, um die Authentizität, Integrität und Vertraulichkeit der zwischen den Rechenzentren bzw. IuK-Betriebsstellen und den jeweiligen Behörden übertragenen schutzwürdigen Daten sicherzustellen.

22.1.2. Viren- und Spam-Filterung

Immer mehr Dienststellen beabsichtigen, ein sicheres und leistungsfähiges Intranet für ihre Verwaltungen und andere angeschlossenen öffentlichen Stellen (z.B. Kommunen eines Landkreises) zu errichten. Viele dieser Behördennetze bestehen bereits und sind auch an das Bayerische Behördennetz angeschlossen. Zur Gewährleistung der Datensicherheit innerhalb des eigenen Intranets sollte vom Betreiber dieses Netzes ein entsprechendes Sicherheitskonzept erarbeitet werden, in dem auch die Handhabung virenverdächtiger E-Mails bzw. Spam-Mails geregelt sind.

Bei der Durchsicht derartiger uns vorliegender Sicherheitskonzepte ist uns aufgefallen, dass Unklarheit darüber besteht, ob virenverdächtige E-Mails bzw. Spam-Mails beim Netzbetreiber gelöscht bzw. unterdrückt (geblockt) werden sollen oder ob sie an die Adressaten bei den angeschlossenen Stellen weiterzuleiten sind. Ich darf daher in diesem Zusammenhang auf Folgendes hinweisen:

1. Löschung bzw. Blockung von E-Mails, die gefährlichen oder verdächtigen ausführbaren Code enthalten, bei Gestattung der ausschließlich dienstlichen Nutzung

Es ist richtig, dass aus Gründen der Datensicherheit (dienstliche) E-Mails oder Anlagen von
E-Mails gelöscht bzw. unterdrückt (geblockt) werden sollten, die gefährlichen oder verdächtigen ausführbaren Code enthalten (z.B. E-Mails mit HTML-Seiten als Mail-body oder Dateien mit den Erweiterungen *.exe, *.bat, *.com oder gepackte Dateien wie *.zip, *.arj, *.lha).

Solange diese Löschung oder Blockung von E-Mails auf Rechnern der adressierten bzw. absendenden Behörde erfolgt und eine private E-Mail-Nutzung verboten ist, bestehen auch von Seiten des Datenschutzes keinerlei Bedenken gegen diese Vorgehensweise. Anders sieht es allerdings aus, wenn statt einer Löschung eine Blockung bei einer anderen Stelle (z.B. beim Landratsamt als Netzbetreiber eines Kommunalen Behördennetzes) erfolgt. Denn auch geblockte E-Mails können personenbezogene Daten beinhalten, womit bei einer Blockung dieser E-Mails und einem Abspeichern auf einem Rechner beim Netzbetreiber ein (unberechtigter) Zugriff auf diese Daten seitens seiner Bediensteten möglich wäre.

Somit muss - bei einer rein dienstlichen Nutzung des E-Mail-Verkehrs (Verbot der Privatnutzung bei allen angeschlossenen Stellen) - zumindest vertraglich ein unberechtigtes Öffnen der geblockten E-Mails verboten werden bzw. eine unverzügliche Löschung der betreffenden
E-Mails vereinbart werden. Außerdem sollte bei einer ausgehenden E-Mail der Absender von dem Vorgehen informiert werden.

2. Löschung oder Blockung von E-Mails, die gefährlichen oder verdächtigen ausführbaren Code enthalten, bei Gestattung der privaten Nutzung

Gestattet dagegen eine Dienststelle als Arbeitgeber ihren Bediensteten die private Nutzung des Internets und des E-Mail-Dienstes, ist sie ihnen gegenüber Telekommunikations- bzw. Teledienste-Anbieter und zur Wahrung des Fernmeldegeheimnisses gemäß § 88 TKG verpflichtet (vgl. Nr. 21.1).

Einerseits ist private E-Mail grundsätzlich ohne vorherige Kenntnisnahme des Inhalts an den Adressaten weiterzuleiten, andererseits dürfen - wie bei der dienstlichen Nutzung - aus Gründen der Datensicherheit auch eingegangene private E-Mails oder deren Anhänge unterdrückt werden, wenn sie ein Format aufweisen, das ausführbaren Code enthalten kann. Eine weitere Möglichkeit besteht darin, erkannte Viren automatisch aus den E-Mails zu entfernen und die gesäuberte
E-Mail weiterzuleiten.

Die gewählte Verfahrensweise ist mit dem Personalrat abzustimmen und den Beschäftigten zuvor bekannt zu geben. Die Mitarbeiter sollten zu dieser Vorgehensweise eine schriftliche Einwilligung erteilen.

Generell sind die Beschäftigten darüber zu unterrichten, wenn an sie gerichtete oder von ihnen abgesendete E-Mails ganz oder teilweise unterdrückt werden oder virenverseucht sind.

3. Blocken von Spam-Mails

Das Versenden bzw. Empfangen von unerwünschter Post mittels E-Mail (so genannte Spam-Mails) ist an sich kein Datenschutzproblem. Allerdings stellt es ein Ärgernis dar und belastet die Ressourcen in erheblichem Masse. Solche Sendungen können insbesondere zu Behinderungen der Arbeit führen; im Extremfall ist eventuell überhaupt keine Kommunikation mehr möglich. Zudem können auch erhöhte Kommunikationsgebühren entstehen. Somit besteht natürlich ein dienstliches Interesse daran, auch diese E-Mails zu filtern und zu blocken.

Eine weitere Möglichkeit würde darin bestehen, die Annahme von vermeintlicher Spam-Mail automatisch zu verweigern und an den Absender zurückzusenden. Dies birgt aber die Gefahr, dass der Absender erkennt, dass die gespamte E-Mail-Adresse existiert und er nur sein Spam-Verhalten zur Vermeidung einer erneuten Filterung verbessern muss.

Außerdem muss damit gerechnet werden, dass aufgrund der derzeitigen Schwächen der eingesetzten Filterungssoftware eventuell auch "sinnhafte" E-Mails als Spam-Mails behandelt und somit nicht weitergeleitet werden würden (False-Positive-Filterung). Dies kann auch zu Haftungsproblemen führen.

So lange eine hundertprozentig zuverlässige Spam-Filterung von E-Mails technisch nicht möglich ist, sollten auch augenscheinliche Spam-Mails nur entsprechend gekennzeichnet werden. Bei gestatteter privater E-Mail-Nutzung dürfen diese nicht geblockt, sondern müssen an den Empfänger weitergeleitet werden. Diese Vorgehensweise wird auch im Bayerischen Behördennetz praktiziert.

Der Empfänger kann dann selbst sein weiteres Vorgehen bestimmen. So besteht bei den meisten E-Mail-Clients die Möglichkeit, beispielsweise E-Mails, welche von Absendern stammen, die dem Empfänger als Spammer bekannt sind (Black List), mittels Regel auszusortieren. Eine weitere Möglichkeit besteht darin, vermeintliche Spam-Mails in einem gesonderten Ordner bis zu einem vorher bestimmten Verfallsdatum, bis zu einer bestimmte Menge oder bis zur manuellen Löschung durch den Empfänger abzulegen.

Zusammenfassend möchte ich noch einmal darauf hinweisen, dass jegliche Art von Filterung beim Netzbetreiber vertraglich zu verankern ist. Zusätzlich ist bei einer gestatteten privaten
E-Mail-Nutzung die Einwilligung jedes einzelnen Betroffenen zur gewählten Vorgehensweise erforderlich.

22.1.3. Verzeichnisdienste

Da immer mehr Behörden auf elektronischem Weg miteinander kommunizieren und sich zum Teil zusammen mit anderen Behörden zu eigenen Netzen (kommunale Behördennetze, Bayerisches Behördennetz etc.) zusammenschließen, stellt sich die Frage nach einem behördenübergreifenden Verzeichnisdienst immer mehr. Die klassische Trennung der Netzwelt in zwei Bereiche, Intranet als behördeninternes und Internet als weltweites Netz, trifft hier nicht mehr zu.

Wie sieht es dann aber mit dem Datenschutz aus? Darf man Daten, die man im eigenen Verzeichnisdienst im Intranet veröffentlichen darf, auch im Behördenverzeichnisdienst veröffentlichen, oder dürfen dort nur Daten publiziert werden, die auch für das Internet zulässig wären?

Für nicht personenbezogene Daten, wie Funktionsadressen und Dienststellendaten, bestehen weder für das Internet noch für das Behördenintranet datenschutzrechtliche Einschränkungen; diese dürfen auch in behördenübergreifende Verzeichnisdienste aufgenommen werden.

Für personenbezogene Daten ist darauf zu achten, dass die Sichtbarkeit der Daten außerhalb der eigenen Behörde eingeschränkt werden kann. Grundsätzlich sollen auch in einem Verzeichnisdienst nur die personenbezogenen Daten in dem jeweiligen Anwenderkreis sichtbar sein, die zur ordnungsgemäßen Aufgabenerfüllung dieses Kreises notwendig sind. Der Grundsatz der Erforderlichkeit gilt auch für die Veröffentlichung einzelner Daten bestimmter Mitarbeiter. Im Übrigen verweise ich auf die Ausführungen in Kapitel 12.3 meines 18. Tätigkeitsberichts und Kapitel 13.1.4 meines 20. Tätigkeitsberichts. Somit sollte zum einen ein Datenfeld nur im kleinsten benötigten Anwenderkreis standardmäßig sichtbar sein, zum anderen muss es auch möglich sein, auf Wunsch eines Mitarbeiters normalerweise sichtbare Daten nicht zu veröffentlichen, wenn der Mitarbeiter daran ein berechtigtes Interesse hat.

Damit ergibt sich für die Sichtbarkeit von Informationen ein Schalenmodell, das von innen nach außen einem immer größeren Anwenderkreis Zugriff auf die Daten erlaubt. Für einen bayernweiten Verzeichnisdienst wäre dies beispielsweise:

• Schale 1: staatliche Behörde (Intranet)
• Schale 2: staatliche Verwaltung / unabhängige staatliche Behörden
• Schale 3: bayerische Verwaltung
• Schale 4: Internet

Für jeden Datentyp im Verzeichnisdienst muss festgelegt werden, wie weit die darin beinhalteten Daten die eigene Schale (Intranet) verlassen dürfen.

22.1.4. Gütesiegel für datenschutzfreundliche Produkte

Im Berichtszeitraum haben sich mehrfach Unternehmen mit der Frage an mich gewandt, ob ich ihre Produkte (Software, Hardware) aus Datenschutzgesichtspunkten bewerten und ggf. zertifizieren kann, weil sie diese Produkte im Bereich der öffentlichen Verwaltung zum Einsatz bringen wollen oder bereits zum Einsatz gebracht haben. Eine Produktzertifizierung gehört derzeit nicht zu meinen Aufgaben.

In § 9a Bundesdatenschutzgesetz ist ein Datenschutzaudit normiert. Bislang ist mir aber noch kein Gesetzentwurf bekannt, in dem dieses Datenschutzaudit näher präzisiert wird. So kann von allen meinen Kollegen auf Landes- und Bundesebene derzeit lediglich mein Kollege vom Unabhängigen Landeszentrum für Datenschutz Schleswig-Holstein (ULD) anhand der dortigen Datenschutzauditverordnung Schleswig-Holstein einen solchen Service bieten und ein Datenschutz-Gütesiegel vergeben. Durch das i.d.R. auf zwei Jahre befristete Gütesiegel wird bescheinigt, dass ein Produkt einem förmlichen Prüfungsverfahren hinsichtlich seiner Konformität zu den Vorschriften über den Datenschutz und die Datensicherheit unterzogen wurde und diese gegeben ist. Das Gütesiegel wird vom ULD auf Basis eines Gutachtens verliehen, welches von den beim ULD akkredierten Sachverständigen und sachverständigen Prüfstellen erstellt wird. Ergänzend sollen nach dem Landesdatenschutzgesetz Schleswig-Holstein vorrangig solche Produkte eingesetzt werden, die mit dem Datenschutz-Gütesiegel ausgezeichnet wurden.

Es sollte geprüft werden, ob eine Regelung über die Zertifizierung von Produkten auch in Bayern eingeführt werden sollte. Dies hätte aus meiner Sicht folgende Vorteile:

• Hersteller: Gezielteres Bewerben eines zertifizierten Produktes möglich und gesteigerte Produktqualität erreichbar
  
• Öffentliche Verwaltung: leichtere Auswahl geeigneter Produkte, die mit den Vorschriften des Datenschutzes in Einklang stehen, d.h. zeit- und kostenaufwändige Prüfungen der Produkte und Verhandlungen mit dem Hersteller bzgl. Anpassungen und Änderungen aufgrund von Datenschutzforderungen entfallen
  
• Meine Dienststelle: Effizientere, da erleichterte Kontrolle der Einhaltung der Datenschutzvorschriften bei Verwendung zertifizierter Produkte in der öffentlichen Verwaltung
  
• Der Bürger: Zuverlässige Gewissheit, dass seine Daten in der öffentlichen Verwaltung mit Produkten verarbeitet werden, die von unabhängigen und sachverständigen Gutachtern auf die Einhaltung von Datenschutz und Datensicherheit geprüft wurden, wobei Schwerpunkte auf Datenvermeidung und Datensparsamkeit, Datensicherheit und Revisionsfähigkeit gelegt werden.

Das Staatsministerium des Innern ist der Auffassung, dass wegen der vorhandenen Datenschutzkontrollinstanzen ein zusätzliches Audit nicht notwendig sei. Durch ein Audit würde neben der Selbstkontrolle durch behördliche und betriebliche Datenschutzbeauftragte und der Fremdkontrolle durch die Datenschutzkontrollbehörden nunmehr eine dreifache Kontrolle eingeführt werden. Dies sei auch angesichts der Kosten nicht vertretbar.

Diese Fragen könnten im Rahmen einer Prüfung im einzelnen beantwortet werden.

22.1.5. Pseudonymisierte Protokolle

In Kapitel 17.3.1 meines 20. Tätigkeitsberichts bin ich auf die Protokollauswertung auf Firewallsystemen und Webservern eingegangen. Das Problem, Protokolldateien mit den Anforderungen des Datenschutzes in Einklang bringen, stellt sich aber nicht nur dort - es trifft prinzipiell auf jede Protokollierung zu, die mit und von IuK-Systemen erstellt wird.

Art. 7 Abs. 2 Ziffern 6 und 7 BayDSG fordern implizit eine Protokollierung, um

• überprüfen und feststellen zu können, an welche Stellen personenbezogene Daten durch Einrichtungen zur Datenübertragung übermittelt werden können und
  
• nachträglich überprüfen und feststellen zu können, welche personenbezogenen Daten zu welcher Zeit von wem in Datenverarbeitungssysteme eingegeben worden sind.

Art. 7 Abs. 2 Ziffer 10 BayDSG fordert überdies, die innerbetriebliche Organisation so zu gestalten, dass sie den besonderen Anforderungen des Datenschutzes gerecht wird. Zu diesen Anforderungen gehören auch die Sicherstellung der Verfügbarkeit der Systeme sowie die Möglichkeit, eventuelle Angriffe und Sicherheitsverletzungen erkennen und diesen nachgehen zu können. Auch daraus ergibt sich der Zwang, Protokolldateien anzulegen.

Nun besteht aber das Dilemma, dass einerseits Protokolldaten anzulegen sind, andererseits aber damit personenbezogene Daten gespeichert werden, ohne dass evtl. zunächst erkennbar sicherheitsrelevante Ereignisse vorliegen - weil deren Erkennung ggf. längere Zeit in Anspruch nimmt. Derjenige, dessen Aktivitäten protokolliert werden, hat natürlich ein Interesse und grundsätzlich auch einen Rechtsanspruch darauf, diese seine Aktivitäten anonym durchführen zu können. Der Betreiber eines IuK-Systems hat aber natürlich ein Interesse, evtl. Sicherheitsverletzungen entdecken und diesen dann konkret nachgehen zu können.

Einen aus Datenschutzsicht sehr interessanten und zielführenden Ansatz zur Lösung dieses Dilemmas verfolgt das Konzept Pseudo/CoRe, welches im Rahmen eines Forschungsauftrags an der Universität Dortmund entwickelt wurde. Es ist auf verschiedenen UNIX-Systemen getestet worden und wurde auch anlässlich der CeBIT 2003 der Öffentlichkeit vorgestellt. Pseudo/CoRe basiert darauf, dass bereits bei der Erstellung von Protokolldatensätzen die vorab festzulegenden und zu verfremdenden Bestandteile der Potokolldatensätze durch Pseudonyme unterschiedlichster Art ersetzt werden. Außerdem werden gemeinsam mit dem örtlichen Datenschutzbeauftragten ebenfalls im Vorfeld bestimmte Merkmale (Schwellwerte) definiert, die einen Anfangsverdacht für eine Sicherheitsverletzung darstellen und automatisch aufdeckbar werden sollen. Stellt sich erst im Nachhinein heraus, dass bestimmte weitere Anhaltspunkte für eine Sicherheitsverletzung vorhanden sind, so können diese pseudonymisierten Daten auch nur wieder in Zusammenarbeit mit dem örtlichen Datenschutzbeauftragten aufgedeckt werden. Durch die technische Zweckbindung bei der Pseudonym-Aufdeckung werden bereits bei der Protokollerstellung die Interessen nach Anonymität einerseits und Zurechenbarkeit andererseits in einen fairen Ausgleich gebracht.

Ich habe das Bayerische Landesamt für Statistik und Datenverarbeitung, als Betreiber des zentralen Internetübergangs aus dem Bayerischen Behördennetz, auf Pseudo/CoRe aufmerksam gemacht.

22.1.6. Bestellung eines gemeinsamen Datenschutzbeauftragten für mehrere Städte

Ich hatte mich mit der Absicht dreier Städte zu befassen, für alle drei Städte einen gemeinsamen Datenschutzbeauftragten zu bestellen.

Gemäß Art. 25 Abs. 2 BayDSG haben alle öffentliche Stellen in Bayern, die personenbezogene Daten mit Hilfe von automatisierten Verfahren verarbeiten oder nutzen, einen ihrer Beschäftigten zum behördlichen Datenschutzbeauftragten zu bestellen. Diese Vorschrift zur Bestellung eines behördlichen Datenschutzbeauftragten beruht auf Art. 18 Abs. 2 Spiegelstrich 2 EG-Datenschutzrichtlinie. Nach dieser Regelung entfallen die zwingend vorgeschriebenen Meldepflichten der Behörden gegenüber der Datenschutzkontrollstelle - für bayerische Behörden also gegenüber dem Landesbeauftragten für den Datenschutz - und die Vorabkontrollen durch die Datenschutzkontrollstelle nur dann, wenn von diesen Behörden behördliche Datenschutzbeauftragte ernannt werden. Diesen obliegt insbesondere die unabhängige Überwachung der Anwendung der zur Umsetzung dieser Richtlinie erlassenen einzelstaatlichen Bestimmungen (also dem BayDSG).

Die EG-Datenschutzrichtlinie geht davon aus, dass eine Ausnahme von der Meldepflicht nur dann zulässig ist, wenn vor Ort durch den behördlichen Datenschutzbeauftragten sichergestellt wird, dass ,,die Rechte und Freiheiten der Betroffenen durch die Verarbeitung nicht beeinträchtigt werden". Dies verlangt, dass eine effektive Kontrolle vor Ort möglich sein muss. Eine derartig effektive Kontrolle setzt voraus, dass diese Stelle personalmäßig so ausgestattet ist, dass sie ihren Aufgaben gerecht werden kann. Dabei sind die Anforderungen umso höher, je größer die zu kontrollierenden Stellen sind.

Diese Verpflichtung ist bei der Entscheidung zu Grunde zu legen, ob von der Regelung in Art. 25 Abs. 2 Satz 2 BayDSG, wonach aus Gründen der Verwaltungsvereinfachung mehrere öffentliche Stellen einen gemeinsamen Datenschutzbeauftragten bestellen können, Gebrauch gemacht werden kann.

In der Gesetzesbegründung zu Art. 25 Abs. 2 BayDSG (LT-Drs. 14/3327 vom 04. 04. 2000) wird als Beispiel genannt, dass mehrere Gemeinden miteinander oder auch ein Landratsamt mit Gemeinden einen gemeinsamen behördlichen Datenschutzbeauftragten bestellen. Der Gesetzgeber wollte mit dieser Vorschrift der Arbeits- und Personalsituation bei kleineren Behörden (z.B. kleinere kreisangehörige Gemeinden) und bei Behörden mit wenigen personenbezogenen Daten Rechnung tragen. Die Kommentarliteratur erwähnt als Beispiel den Fall, dass mehrere öffentliche Stellen über eine gemeinsame Verwaltung verfügen, z.B. wenn ein Zweckverband von einer Gemeinde mitverwaltet wird (Wilde, Ehmann, Niese, Knoblauch, Kommentar und Handbuch zum BayDSG, Art. 25 Rn. 20).

Vom Sinn und Zweck der Vorschrift her scheidet demnach eine gemeinsame Bestellung eines einzigen Datenschutzbeauftragten z.B. für mehrere Städte aus. Eine effektive interne Kontrolle lässt sich insbesondere bei größeren Städten nur durch jeweils einen Datenschutzbeauftragten vor Ort erfüllen.

Ein behördlicher Datenschutzbeauftragter hat eine Vielzahl von gesetzlich vorgeschriebenen Aufgaben zu erledigen:

So haben die behördlichen Datenschutzbeauftragten gemäß Art. 25 Abs. 4 Satz 1 BayDSG die Aufgabe, in ihrer öffentlichen Stelle auf die Einhaltung des BayDSG und anderer Vorschriften über den Datenschutz hinzuwirken. Sie können dazu die erforderliche Einsicht in Dateien und Akten der öffentlichen Stelle nehmen (Art. 25 Abs. 4 Satz 2 BayDSG). Prüfungsmaßstab ist nicht nur das BayDSG, sondern eine Vielzahl von bereichsspezifischen Normen, wie z.B. SGB X (Sozialgeheimnis), AO (Steuergeheimnis), MeldeG (Meldegeheimnis), BayBG (Personalaktengeheimnis), TKG (Telekommunikationsgeheimnis), TDDSG, BayArchivG, BayEUG, GewO, BSHG, BStatG usw.

Der Datenschutzbeauftragte ist für die gesamte Kommune Ansprechpartner und Auskunftsperson für datenschutzrechtliche Fragen und trägt dazu bei, datenschutzrechtliches Fehlverhalten der Kommune, Haftungsansprüche und ggf. strafrechtlich relevantes (vgl. § 203 Abs. 2 StGB) bzw. ordnungswidriges Verhalten der Beschäftigten zu vermeiden.

Automatisierte Verfahren zur Verarbeitung personenbezogener Daten dürfen nur eingesetzt werden, wenn sie zuvor von dem behördlichen Datenschutzbeauftragten freigegeben worden sind (Art. 26 BayDSG). Das soll sicherstellen, dass in öffentlichen Stellen nur solche automatisierte Verfahren eingesetzt werden, die den Vorschriften des Datenschutzes entsprechen. Die Freigaben sind wegen der notwendigen Abstimmungen (Fachbereiche, EDV-Referat, Personalrat) mit erheblichem Aufwand verbunden. Hinzu kommt die Kontrolle vor Ort, ob die datenschutzrechtliche Freigabe auch eingehalten wird.

Die kommunalen Datenschutzbeauftragten führen ein Verzeichnis aller eingesetzten und datenschutzrechtlich freigegebenen Verfahren ihrer Gemeinde (Art. 27 BayDSG). Dieses Verfahrensverzeichnis kann von jedem kostenfrei eingesehen werden (Art. 27 Abs. 3 Satz 1 BayDSG).

Neben diesen gesetzlich besonders erwähnten Aufgaben sind von den kommunalen Datenschutzbeauftragten weitere Aufgaben auf dem Gebiet des Datenschutzes zu erledigen, z.B. die Beantwortung von Auskunftsersuchen nach Art. 10 BayDSG und von Eingaben von Bürgerinnen und Bürgern, die Beschwerden gegen die Datenverarbeitung der Kommunen erheben (diese können sich auch direkt an die Kommunen wenden).

Diese Aufgaben können wegen der Vielfalt und der Schwierigkeit der Aufgaben von einem einzigen örtlichen Datenschutzbeauftragten für mehrere Städte nicht sach- und zeitgerecht erledigt werden. Diese Schwierigkeiten werden noch potenziert dadurch, dass ein einziger behördlicher Datenschutzbeauftragter noch "fremde" Städte betreuen und kontrollieren müsste, einschließlich der Einsichtnahme in Datenbestände und Akten auch der anderen Städte. Der Sinn des Gesetzes, nämlich durch die Bestellung eines behördlichen Datenschutzbeauftragten eine ortsnahe Beratung und Kontrolle sicherzustellen, würde durch die Anwendung von Art. 25 Abs. 2 Satz 2 BayDSG auf mehrere Städte in sein Gegenteil verkehrt.

Die Bestellung eines einzigen DSB für mehrere Städte halte ich deshalb für unzulässig. Nachdem ich das den drei Städten mitgeteilt hatte, wurde diese Absicht nicht mehr weiter verfolgt.

22.1.7. Datenarten für die Verfahrensbeschreibung nach Art. 26 Abs. 2 BayDSG sowie Errichtungsanordnung nach Art. 47 Abs. 1 PAG und Art. 9 Abs. 1 Satz 1 BayVSG

Nach Art. 26 Abs. 1 Satz 1 BayDSG bedarf der erstmalige Einsatz von automatisierten Verfahren, mit denen personenbezogene Daten verarbeitet werden, der vorherigen datenschutzrechtlichen Freigabe durch den zuständigen behördlichen Datenschutzbeauftragten. Die personenbezogen Daten können sich auf Bürger, aber auch auf Beschäftigte von Behörden beziehen. Art. 26 Abs. 2 BayDSG zählt den Inhalt einer Verfahrensbeschreibung auf, die die Grundlage der Verfahrensfreigabe bildet.

Zum Kern der Verfahrensbeschreibung gehört die Art der gespeicherten Daten (Art. 26 Abs. 2 Nr. 3 BayDSG). Es genügen aussagefähige Oberbegriffe und Sammelbezeichnungen wie Bankverbindungsdaten (= alle Daten, die auf dem Überweisungsträger stehen), Geburtsdaten
(= Datum und Ort der Geburt) oder Adressdaten. Die Beschreibung muss aber erkennen lassen, welche Datenarten gespeichert werden. Bei "Antragsdaten" - z.B. für einen Antrag auf Wohngeld - ist nicht ersichtlich, welche einzelnen Dateninhalte mit dieser Sammelbezeichnung gemeint sind. Im Zweifel sollten die Datenarten daher einzeln aufgeführt werden, wenn dafür keine gängigen und zusammenfassbaren Begriffe gefunden werden können.

Wichtig ist, dass auch für Nichtfachleute nachvollziehbar ist, welche Daten und welcher Dateninhalt gespeichert werden. Es muss ebenso bedacht werden, dass die freigegebenen Verfahrensbeschreibungen für jedermann einsehbar sind (vgl. Art. 27 Abs. 2 BayDSG).

In den Verfahrensbeschreibungen, die für die datenschutzrechtliche Freigabe den behördlichen Datenschutzbeauftragten vorgelegt werden, taucht immer wieder der Begriff Bemerkung auf. Dieser Begriff ist zu unbestimmt und nicht eingrenzbar. Er hat keinen Aussagewert über den vorgesehenen Dateninhalt und ist damit als Grundlage für die datenschutzrechtliche Freigabe ungeeignet.

Der Begriff "Bemerkung" erschwert auch die Arbeit des Sachbearbeiters, der mit dem Programm arbeitet und einerseits nicht weiß, welche Angaben gespeichert werden sollen und andererseits stets im Feld "Bemerkung" nachsehen muss, ob dort möglicherweise für die aktuelle Bearbeitung relevante Daten enthalten sind.

Für die Daten, die unter "Bemerkung" gespeichert werden sollen, sind durchaus Alternativen vorhanden, zum Beispiel:

• Hinweise zur Sachbearbeitung
• Stand des Verfahrens/von Eingaben/Petitionen usw.
• Stand von Rechtsbehelfen (Widerspruch/Klagen)
• Ergebnisse von Vorsprachen, Ferngesprächen oder Besprechungen
• Hinweise zur Bestellung/zur Lieferung/zum Artikel/zur Verteilung usw.
• Schreiben von Antragstellern /Schreiben an Antragsteller (bei Volltextspeicherung)

Der Begriff "Bemerkung" ist deshalb zur Erläuterung der Datenart ungeeignet und es sollten statt dessen aussagefähigere Bezeichnungen verwendet werden.

22.2. Prüfungen, Beratungen und Informationen

22.2.1. Geprüfte Einrichtungen

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

• Bayerische Versorgungskammer
• Bezirksklinikum Ansbach
• Bezirkskrankenhaus Landshut
• Bezirksverwaltung Unterfranken in Würzburg
• Große Kreisstadt Nördlingen
• Klinikum Freising
• Kommunaler Eigenbetrieb in Bad Gögging
• Landratsamt Donau-Ries in Donauwörth und Nördlingen
• Landratsamt Regensburg
• Schiller-Gymnasium Hof
• Stadt Regensburg
• Städtisches Krankenhaus Bad Reichenhall
• Städtisches Krankenhaus Landshut
• Virtuelle Hochschule Hof und Bamberg
• Zentrale Aufnahmeeinrichtung für Asylbewerber in Zirndorf

Die Überprüfungen erstreckten sich neben den klassischen Ansätzen der Daten- und Netzwerksicherheit sowie der organisatorischen Aspekte auch auf den datenschutzgerechten Einsatz neuerer Technologien wie Biometrie zur Zugangskontrolle, den Einsatz von Videotechnik und optische Archivierung. Es zeigte sich wie auch in den Vorjahren, dass der Stand der technisch-organisatorischen Maßnahmen zum Teil recht unterschiedlich ist. Wenngleich alle Stellen dem Datenschutz und der Datensicherheit erfreulicherweise einen hohen Stellenwert einräumen wollen, so mangelt es doch gelegentlich an einem umfassenden und schlüssigen Sicherheitskonzept bzw. dessen konsequenter Umsetzung.

22.2.2. Erkenntnisse aus Prüfungen

Aus den vorgenannten Prüfungen ergaben sich wieder eine Reihe von Erkenntnissen bzgl. der praktischen Probleme in der Umsetzung von technisch-organisatorischen Datenschutz- und Datensicherungsmaßnahmen.

Nach wie vor weit verbreitete Mängel bestehen bzgl.

• der Durchführung und der Revisionsfähigkeit der Benutzerverwaltung,
• der Passwortverwaltung,
• der Einbindung des behördlichen Datenschutzbeauftragten,
• der Protokollierung nach Umfang und Speicherdauer,
• der Auswertung von Log-Dateien,
• der Absicherung von Serverräumen und PC-Schnittstellen und
• des Zugriffsschutzes auf schriftliche Unterlagen.

Darüber hinaus zeigten sich noch weit verbreitete Mängel in den nachfolgend ausführlicher beschriebenen Aspekten.

22.2.2.1. Virenbekämpfungskonzept

Während laut neuesten Statistiken (z.B. FBI-Studie aus dem Jahre 2004) Hackerangriffe zurückgehen, waren Viren und andere Formen der Schadenssoftware (Malware) in den letzten Jahren die häufigste Form von Angriffen. Auch der finanzielle Schaden, der durch Viren entstand, war im Jahre 2003 doppelt so hoch wie bei allen anderen Risiken.

Umso erstaunlicher ist die Tatsache, dass es immer noch Behörden gibt, die kein durchgreifendes Virenbekämpfungskonzept erstellt haben. So werden zwar durchaus vereinzelte Maßnahmen wie Installation von Virenscannern auf den Mail-Servern ergriffen, allein es mangelt häufig an einem detaillierten Konzept, das sowohl Sicherheitsrichtlinien in Bezug auf Viren und Maßnahmen zur Verhinderung von Schäden und zur Minimierung des Risikos eines Virenbefalls gegen alle bekannten Arten der Schadenssoftware beinhaltet sowie dabei auch alle IT-Plattformen berücksichtigt. Es genügt eben nicht, nur an einer Stelle Antivirensoftware einzusetzen, sondern dies muss auf allen Ebenen - also sowohl an der Firewall, am Gateway, beim Mail- und Datenbankserver als auch bei den Endgeräten - geschehen. Dieses Sicherheitskonzept und insbesondere seine Regelungen müssen konsequent umgesetzt, laufend überprüft und auch den Bediensteten bekannt sein.

Da ich bereits in meinen letzten Tätigkeitsberichten (z.B. im Kapitel 17.2.1 im 20. Tätigkeitsbericht und im Kapitel 17.1.5 im 19. Tätigkeitsbericht) immer wieder auf die Virenproblematik und mögliche Gegenmaßnahmen hingewiesen habe, will ich im Folgenden nur noch einmal auf einige der wichtigsten Vorsorgemaßnahmen eingehen, die ein Virenkonzept beinhalten sollte:

Über 90 % der Viren, Trojanischen Pferde, Würmer und Backdoor-Programme gelangen heutzutage durch das Einschleusen und Aktivieren von ausführbaren Dateien, etwa mittels E-Mail-Anlage oder beim Besuch einer verseuchten Home-Page im Internet auf die Festplatte eine Rechners oder ins lokale Netzwerk. Ein Anhang (Attachment) einer E-Mail kann nicht nur einen in einer Script-Sprache geschriebenen Virus sondern auch sonstige ausführbare Programme, eine selbstextrahierende Datei oder einen Makrocode (z.B. zur Ausführung in Word-Dokumenten) mit Schadensfunktion enthalten. Deshalb sollten generell nur angeforderte oder erwartete Dateianhänge an E-Mails geöffnet werden. Im Zweifelsfall hilft eine Nachfrage beim Absender weiter, denn auch eine dem Empfänger bekannte Absenderadresse ist kein Indiz für den Erhalt einer virenfreien Mail, da viele Schädlinge Adressen aus den Adressbüchern eines von ihnen befallen Rechners nutzen, um sich weiterzuverbreiten.

Da beispielsweise Script-Viren in E-Mail-Anhängen bereits bei einem Öffnen des Attachments mit Doppelklick aktiviert werden und den Rechner befallen können, sollten Dateianhänge an
E-Mails, gleich welcher Art (ob DOC-, VBS-, BAT- oder EXE-Files usw.) keinesfalls mit Doppelklick geöffnet werden, da sonst kein noch so guter Virenschutz greifen kann. Stattdessen rate ich dringend dazu, dass jeder Bedienstete dazu verpflichtet wird, Dateianhänge mit der Funktion "Datei/Anlagen speichern" auf eine mittels Virenscanner überwachte Festplatte in einem speziell dafür angelegen Verzeichnis zu speichern. Erst dann darf der Dateianhang von der Festplatte aus mit der entsprechenden Anwendung gestartet werden.

Auch bereits das bloße Lesen einer E-Mail im HTML-Format kann das Ausführen eines Codes auslösen, der für eine blitzschnelle Verbreitung des Virus sorgt und/oder eine Schadensfunktion auslöst. Dies kann bereits dadurch geschehen, dass - wie bei den meisten E-Mail-Clients (z.B. Outlook, Outlook-Express oder Netscape Messenger) standardmäßig üblich - ein sogenanntes Vorschaufenster aktiviert ist. Dieses Vorschaufenster öffnet automatisch die erste markierte
E-Mail. Befindet sich beispielsweise ein HTML-Virus in dieser markierten E-Mail, so wird er sofort ausgeführt. Deshalb sollte eine Deaktivierung dieser Vorschaufenster erfolgen.

Die gleiche Gefahr besteht beim Herunterladen von Dateien aus dem Internet. Auch sie können Viren enthalten. Deshalb sollte niemals direkt von einer Webseite aus gestartet werden (Funktion "Öffnen"). Stattdessen sollte über die Option "Speichern" das Programm auf die Festplatte abgelegt und von dort aus geöffnet oder ausgeführt werden. Dabei kann wiederum die heruntergeladene Datei vor dem Starten von einem Virenscanner überprüft werden.

Dies bedeutet natürlich auch, dass der Virenscanner stets aktiv im Hintergrund laufen muss. Wird er deaktiviert, kann er verdächtige Dateien nicht erkennen.

Eine wichtige Maßnahme besteht darin, das auf dem Rechner installierte Antivirenprogramm durch möglichst tägliche Updates der Virensignaturen (=Datenbank mit Informationen zu den Schädlingen) immer auf dem neuesten Stand zu halten, denn ein nicht aktualisierter Virenscanner ist schlimmer als kein Virenscanner, da dem Anwender eine Sicherheit vorgegaukelt wird, die in Wirklichkeit nicht vorhanden ist.

Selbstverständlich sollte auch sein, dass alle Software auf Viren geprüft wird, bevor sie im Netzwerk installiert wird.

Immer mehr Schadenssoftware (insbesondere Würmer und Trojanische Pferde) nutzen zu ihrer Verbreitung Sicherheitslücken in Browsern und Betriebssystemen aus. Deshalb sollten immer aktuelle Patches, Bugfixes und Programm-Updates der Softwarehersteller eingespielt werden. So bringt etwa die Firma Microsoft einmal monatlich, in der Regel an jedem zweiten Mittwoch eines Monats, Windows-Updates heraus, die sicherheitskritische Fehler beheben.

Viele Softwarehersteller haben in ihren Produkten eine Update-Funktion integriert, die automatisch in definierten Zeiträumen auf den Home-Pages dieser Anbieter nach dem Vorhandensein neuer Programmkomponenten zur Fehlerbereinigung sucht. Dazu nehme ich aber eine kritische Haltung ein (vgl. Nr. 22.3.4).

22.2.2.2. Online-Datenschutz-Prinzipien

Die Veröffentlichung von Informationen auf einer Home-Page und das Bereitstellen von Angeboten, z.B. in Form von Formularen u.ä., ist als ein Teledienst im Sinne des § 2 Abs. 2 Teledienstegesetz (TDG) anzusehen. Somit sind auch bezüglich des Internetauftritts (Home-Page) öffentlicher Stellen sowohl die Vorschriften des TDG als auch die des Teledienstedatenschutzgesetzes (TDDSG) zu beachten.

Gemäß § 4 Abs. 1 Teledienstedatenschutzgesetz (TDDSG) muss der Diensteanbieter den Nutzer des Teledienstes (z.B. den Besucher der Home-Page) zu Beginn des Nutzungsvorganges über Art, Umfang, Ort und Zwecke der Erhebung, Verarbeitung und Nutzung seiner personenbezogenen Daten unterrichten. Der Diensteanbieter muss darüber informieren, welche Arten von Daten erhoben, verarbeitet und genutzt werden, für welche Zwecke dies erfolgt, wo und wie lange sie gespeichert und eventuell an wen sie weitergegeben werden. Dies geschieht mit Hilfe so genannter Online-Datenschutz-Prinzipien (Privacy Policy).

Die Erhebung personenbezogener Daten im Zusammenhang mit einem Internetauftritt beginnt grundsätzlich dann, wenn der Nutzer ein Web-Angebot aufruft, denn dabei werden die IP-Adresse des vom Nutzer verwendeten Rechners und weitere technische Angaben automatisch an den Anbieter weitergeleitet. Auch eine bei einer Einwahl ins Internet über einen Internet-Provider vergebene temporäre IP-Adresse, die zufällig aus einem Pool an freien IP-Adressen ausgewählt und einmalig für die Zeit der Online-Verbindung einem PC zugeordnet wird, besitzt einen Personenbezug, da der Provider natürlich die Vergabe der IP-Nummern für einen begrenzten Zeitraum zum Beispiel zur Kostenabrechnung speichern muss. Damit ist über den Provider auch wieder der temporäre Besitzer dieser IP-Adresse ermittelbar.

Spätestens zu dem Zeitpunkt, wenn der Nutzer zur Angabe persönlicher Daten aufgefordert wird (z.B. Ausfüllen eines Online-Formulars oder Beginn einer Kommunikation mittels E-Mail) oder wenn Dateien mit direktem oder indirektem Personenbezug von seinem Rechner abgerufen werden, die dort schon gespeichert vorliegen (etwa in so genannten Cookies), muss der Diensteanbieter den Nutzer unterrichten. Die Unterrichtung muss vollständig und verständlich sein. Diese Unterrichtung bzw. der Hinweis auf die Unterrichtung ist so anzubringen, dass ein Nutzer sie üblicherweise zur Kenntnis nimmt, wenn er das entsprechende Angebot aufruft. Verstöße gegen diese gesetzlich geforderten Informationspflichten sind als Ordnungswidrigkeiten zu betrachten, die mit einer Geldbuße bis zu 50.000 Euro geahndet werden können.

Umso verwunderlicher ist es, dass ich im Rahmen meiner Prüfungen feststellen musste, dass kaum eine der geprüften Stellen eine gesetzeskonforme Online-Datenschutzerklärung erstellt hatte. Dabei habe ich bereits sowohl in Kapitel 17.4 meines 19. Tätigkeitsberichts als auch in Kapitel 17.1.7 meines 20. Tätigkeitsberichts auf diese Informationspflichten hingewiesen.

Nähere Hinweise zu den Online-Datenschutz-Prinzipien enthält meine gleichnamige Orientierungshilfe - abrufbar auf meiner Home-Page (www.datenschutz-bayern.de) im Bereich "Technik/Grundsätze".

22.2.2.3. Anbieterkennzeichnung

Neben einer Online-Datenschutzerklärung muss jeder Betreiber einer Home-Page, der Waren oder Dienstleistungen anbietet, seine Home-Page auch mit einer Anbieterkennzeichnung (Impressum) gemäß § 6 Teledienstegesetz (TDG) ausstatten. Gleiches gilt gemäß § 10 Mediendienste-Staatsvertrag (MDStV) für die Anbieter von Seiten redaktionellen Inhalts.

Die Anbieterkennzeichnung soll für den Nutzer ein Mindestmaß an Transparenz und Information über die natürliche oder juristische Person oder Personengruppe, die ihm beispielsweise einen Teledienst anbietet, sicherstellen. Die Informationen zur Anbieterkennzeichnung müssen an gut wahrnehmbarer Stelle und ohne langes Suchen und jederzeit auffindbar sein. Es darf also nicht der Fall sein, dass ein Besucher der Home-Page die Anbieterkennzeichnung erst durch so genanntes "Scrollen" (Vorwärtsblättern) einen Hinweis auf das Impressum findet. Die Anbieterkennzeichnung darf auch nicht in Allgemeinen Geschäftsbedingungen "versteckt" sein. Außerdem muss die Anbieterkennzeichnung z.B. mittels Link von jeder Seite der Home-Page aufrufbar sein. Dieser Link sollte zur Verdeutlichung mit Anbieterkennzeichnung oder Impressum tituliert sein.

Die verantwortliche Person des Diensteanbieters (in der Regel der Bürgermeister oder Dienststellenleiter) trägt die volle Verantwortung für die Inhalte seiner Home-Page. Dies gilt auch für den Fall, dass der Anbieter von Inhalten die technische Abwicklung seines Dienstes einem Dritten überträgt (so genanntes Web-Hosting).

Die Pflicht zur Angabe von Identität und Anschrift dient auch als Anknüpfungspunkt für die Rechtsverfolgung in einem Streitfall. Deshalb muss die Information so vollständig sein, dass sie quasi als ladungsfähige Adresse für einen Rechtsstreit geeignet ist.

Bei öffentlichen Stellen sind auf ihrer Home-Page folgende Angaben leicht erkennbar, unmittelbar erreichbar und ständig verfügbar anzubringen:

• Der Name und die Anschrift der Dienststelle
• Der Vor und Nachname des Verantwortlichen (z.B. der Dienststellenleiter)
• Die vollständige Postanschrift und sonstige Angaben, die eine schnelle elektronische Kontaktaufnahme und unmittelbare Kommunikation mit ihnen ermöglichen, einschließlich der Adresse der elektronischen Post

Bei fehlenden Anbieterkennzeichnungen oder fehlerhaften Angaben zur Anbieteridentität können wiederum Bußgelder in Höhe von bis zu 50.000 Euro verhängt werden.

22.2.2.4. Sonstige Erkenntnisse

Reaktion der IT-Systeme auf Anmeldefehlversuche

Obwohl alle modernen Betriebssysteme über die Möglichkeit verfügen, fehlerhafte Anmeldeversuche abzuweisen und zu sanktionieren, wird davon immer noch bei vielen öffentlichen Stellen nicht Gebrauch gemacht. Ich weise daher erneut darauf hin, dass nach höchstens fünfmaliger fehlerhafter Anmeldung in ununterbrochener Reihenfolge bei allen IT-Systemen der Anmeldedialog abgebrochen und das entsprechende Endgerät "out of service" gesetzt bzw. die betreffende Benutzerkennung auf Dauer gesperrt werden muss, damit etwaige missbräuchliche Zugriffsversuche unterbunden werden. Eine Entsperrung sollte nur durch eine dazu berechtigte Person (z.B. Systemverwalter) möglich sein. Den Ursachen für fehlerhafte Anmeldeversuche ist nachzugehen.

Datenschutzmaßnahmen für mobile Rechner

Mobile Computer stellen aufgrund ihrer Mobilität und geringen Größe ein besonderes Sicherheitsrisiko dar, da für sie eine erhöhte Gefahr bezüglich eines Diebstahls oder eines Verlusts besteht. Auf diesen Geräten können genauso vertrauliche Informationen gespeichert werden, wie bei einem stationären Gerät.

Insbesondere die Speicherung personenbezogener Daten auf einem PDA ist besonders gefährlich, da PDAs standardmäßig keinerlei Maßnahmen zur Gewährleistung des Zugangsschutzes (insbesondere keinen Boot-Schutz) und der Vertraulichkeit bieten. Der einzige Zugangsschutz besteht in der Regel darin, die Eingabe eines höchstens vierstelligen Passworts zu erzwingen. Soweit keine weiteren Maßnahmen ergriffen werden, sind damit natürlich die Anforderungen des Datenschutzes nicht erfüllt.

Daher ist die verschlüsselte Speicherung von personenbezogenen Daten auf Datenträgern in mobilen Rechnern (z.B. Laptops, Notebooks, PDA) sowie die Ergreifung datenschutzgerechter Maßnahmen zur Gewährleistung der Zugangs- und Zugriffssicherheit unbedingt erforderlich, damit die Daten bei einem Verlust oder Diebstahl des Rechners nicht in unbefugte Hände geraten. Dazu ist in der Regel der Einsatz entsprechender Zusatzsoftware erforderlich.

Möglichst kein Versenden von Telefaxen mit personenbezogenem Inhalt

Da Verschlüsselungstechniken bei einem Telefax-Versand - ob konventionell oder auch mittels PC - aufgrund des verwendeten Protokolls derzeit nicht zur Verfügung stehen, sollte zur Gewährleistung der Vertraulichkeit - außer wenn dadurch in einem Notfall eine nicht zumutbare Zeitverzögerung entstehen würde - ein Versand sensibler personenbezogener Daten per Telefax unterbleiben. Zu den zu ergreifenden Sicherheitsmaßnahmen habe ich mich in Kapitel 17.2.2 meines 19. Tätigkeitsberichts bereits geäußert und weise auch auf meine Orientierungshilfe "Datensicherheit beim Telefax-Dienst" hin, die auf meiner Home-Page unter www.datenschutz-bayern.de/technik/orient/telefax.htm zu finden ist.

Sichere Browserkonfiguration

Viele Dienststellen gestatten zwar ihren Mitarbeitern das Surfen im Internet, vergessen aber dabei, entsprechende Sicherheitseinstellungen bei den eingesetzten Web-Browsern zu nutzen. Ich rate dringend dazu, die Sicherheitseinstellungen der Browser zu aktivieren und den Bedürfnissen anzupassen (z.B. beim Internet Explorer unter Extras / Internetoptionen / Sicherheit). Dadurch lässt sich die Sicherheit im Internet beträchtlich steigern. Insbesondere sollten - soweit nicht unbedingt erforderlich - die Ausführung von ActiveX-, Java- und Javascript-Programmen durch Browser-Einstellungen abgeschaltet oder nur nach automatischer Rückfrage gestattet werden. Auch die AutoVervollständigen-Funktion der Browser, wodurch die Eingaben von Benutzerkennungen und Passworten gespeichert werden, sollte nicht genutzt werden. Bei den meisten Browsern kann vordefiniert werden, ob ein Benutzer die Sicherheitseinstellungen ändern darf oder nicht. Soweit möglich, sollte eine Änderungsmöglichkeit durch den Benutzer unterbunden werden.

Mit Hilfe eines Online-Checks können Personal Computer auf sichere Browser-Einstellungen und mögliche Sicherheitslücken hin überprüft werden. Auch ein Port-Scan sollte im Rahmen des Online-Checks durchgeführt werden. Dabei wird festgestellt, welche Internetdienste auf dem PC aktiv sind und welche Ports sie belegen. Werden bei dieser Überprüfung Ports als Offen bezeichnet, bedeutet dies eine potenzielle Hintertür für das Eindringen von Hackern oder Trojanischen Pferden. Deshalb führen auch Hacker, die versuchen wollen, in einen Rechner oder in ein Netzwerk einzudringen, zunächst einen Port-Scan durch, um einen offenen Port zu finden.

Nach Abschluss der Tests sollten Erkenntnisse über den Sicherheitsstatus des PC vorliegen. Zusätzlich geben viele Checks Hinweise auf angemessene Sicherheitseinstellungen sowie Tipps für weiter gehende Informationen über mögliche Gefahren und deren Vermeidung.

Entsprechende Selbsttests können auf verschiedenen Webseiten (z.B. beim Landesbeauftragten für den Datenschutz Niedersachsen: www.lfd.niedersachsen.de (externer Link)) abgerufen werden. Grundsätzlich sollte darauf geachtet werden, dass Eingaben und Ergebnisse immer verschlüsselt übertragen werden. Ich weise aber deutlich darauf hin, dass in den Fällen, in denen eine Firewall den zu testenden Rechner gegen das Internet oder andere Netze schützt, diese Tests natürlich nur auf die Firewall wirken, d.h. diese getestet wird, und der Test dort evtl. als Angriff gewertet wird. Solche Tests sollten also nur von hierzu berechtigten Systemadministratoren und nicht von "Normal-Nutzern" von innerhalb eines lokalen Netzwerkes angestoßen werden.

Da bekanntermaßen gerade der Internet Explorer gerne Angriffsziel ist, sollte der Einsatz alternativer Browser zumindest bedacht werden.

22.2.3. Beratungsleistungen

Auch in diesem Berichtszeitraum ist die Zahl der Nachfragen nach Beratungsleistungen stark angestiegen und nahm im technisch-organisatorischen Bereich einen ganz wesentlichen Teil meiner personellen Kapazitäten in Anspruch. Diesen Anfragen komme ich, soweit personell und zeitlich möglich, gerne nach. Darauf bin ich bereits in meinem letzten Tätigkeitsbericht eingegangen (Kapitel 17.2.2 im 20. Tätigkeitsbericht).

Ich möchte diese Gelegenheit nutzen, mein vielfach geäußertes Angebot nach Vorab-Beratung auch an dieser Stelle zu wiederholen und alle Dienststellen zu ermuntern, bereits im Vorfeld von Neu-Einführungen oder gravierenden Änderungen an ihren IuK-Systemen um Beratungsleistung zunächst des behördlichen Datenschutzbeauftragten nachzufragen. Durch die frühzeitige Einbindung des behördlichen Datenschutzbeauftragten einerseits und sodann meiner Dienststelle andererseits können eventuell aufwändige Nachbesserungen an Systemen und Abläufen vermieden werden - von Verletzungen der Datenschutzvorschriften im Wirkbetrieb ganz abgesehen.

Auf einige der Projekte, die ich beraten habe, bin ich in den Kapiteln "TEMPiS" (vgl. Nr. 5.1) und "Gesundheitsmodernisierungsgesetz und elektronische Gesundheitskarte" (vgl. Nr. 6.1) bereits eingegangen. Auf einige weitere Projekte möchte ich im Folgenden näher eingehen.

22.2.3.1. KVB Safenet

In zunehmendem Maße steigen auch im Bereich der niedergelassenen Ärzte die Anforderungen an die medizinische Dokumentation, was z.B. die Vollständigkeit, Fehlerfreiheit und Qualität der erfassten Daten betrifft. Gleichzeitig nimmt die Verbreitung standardisierter Programme zur Versorgung von Patienten zu, z.B. im Rahmen von Disease Management Programmen, die ebenfalls eine sorgfältige Dokumentation erfordern. Auch der Wunsch nach einer Erhöhung der Effizienz der Datenerfassung und Verarbeitung führt zunehmend in Richtung der medienbruchfreien elektronischen Erhebung von medizinischen Daten. Ein geeigneter Lösungsansatz hierfür ist die Bereitstellung von Web-Portalen, auf denen die behandelnden Ärzte direkt über einen Web-Browser an ihrem Praxis-PC die Patientendaten eingeben können. Voraussetzung ist allerdings, das mindestens ein Praxiscomputer eine Außenanbindung besitzt, mit der der Dokumentationsserver angesprochen werden kann.

Die Kassenärztliche Vereinigung Bayerns (KVB) bietet mit dem KVB Safenet hierzu eine Basisinfrastruktur für die bayerischen Kassenärzte. Aufbauend auf einer gesicherten Vernetzungsinfrastruktur soll eine Online-Dokumentation für verschiedene Programme wie z.B. das Mammographie-Screnning (vgl. Nr. 6.2) möglich sein. Die Anbindung der Ärzte erfolgt über ein VPN, das derzeit auf ISDN und einem gesonderten Netz eines Providers basiert, in Zukunft aber auch via DSL über das Internet laufen soll. Zur Teilnahme müssen die Ärzte ihr Praxissystem mit einem gemäß den Sicherheitsrichtlinien der KVB vorkonfigurierten ISDN-Router ausstatten, der den Zugang zum VPN und auf die von der KVB bereitgestellten Web-Portale möglich macht.

Da bei dieser Art von medizinischer Dokumentation personenbezogene medizinische Daten an Stellen außerhalb der Arztpraxis übermittelt und dort gespeichert werden, spielen Datenschutz sowie technisch-organisatorische Sicherheit im Projekt eine große Rolle. Daher wurde ich beratend von der KVB hinzugezogen. Es ergeben sich aus Datenschutzsicht für derartige Konzepte diverse Anforderungen, die einerseits den Schutz der Praxissysteme und des KVB Safenet-Zugangs des niedergelassenen Arztes, andererseits die Datenübertragung sowie die Speicherung der Daten auf den Servern der KVB betreffen.

• Schutz der Praxissysteme: Praxis-Computer, die an das KVB Safenet angeschlossen werden, dürfen nicht mit einem Internetzugang ohne zusätzliche Schutzmaßnahmen wie z.B. Firewalls ausgestattet sein, da sonst ein Einbruch in das KVB Safenet aus dem Internet möglich wäre. Analoges gilt für alle Praxis-Rechner, auf denen personenbezogene Patientendaten gespeichert werden, da hier ein unerwünschter Zugriff auf die gespeicherten Daten erfolgen könnte. Daher ist für eine Internetnutzung der Einsatz eines gesonderten PCs, der keine Verbindung zu den sonstigen Praxis-PCs hat, erforderlich.
  
• Verbindungsaufbau zum KVB Safenet und Zugang zum Web-Portal: Es muss über personenbezogene Kennungen und Passworte / Chipkarten o.ä. sichergestellt werden, dass nur teilnehmende Ärzte auf das KVB Safenet und das Web-Portal zugreifen können. Insbesondere darf der Arzt die entsprechenden Zugangsinformationen nicht weitergeben. Regeln zur Gestaltung sicherer Passworte finden sich z.B. auf meiner Home-Page unter www.datenschutz-bayern.de/technik/orient/pwreg.htm. Zudem muss mittels der Benutzerkennungen dafür gesorgt werden, dass jeder Arzt nur auf die von ihm erhobenen Daten zugreifen kann.
  
• Einschränkung der Verbindungsmöglichkeiten: In den teilnehmenden Arztpraxen (ISDN-Router) und auf Seiten der KVB sollte durch eine entsprechende Konfiguration der Netzzugänge und eine Überprüfung von Verbindungsaufbauwünschen sichergestellt werden, dass sowohl ein- als auch ausgehende Verbindungen nur von und zu festgelegten Stellen möglich ist. Damit wird z.B. verhindert, dass aus der Arztpraxis unerwünschterweise eine andere Stelle für einen Datenexport angewählt wird oder dass Nichtbeteiligte eine Verbindung zum Web-Portal der KVB aufbauen können.
  
• ISDN Sicherheitsmechanismen: Bei einer Datenübermittlung über ISDN sollten die von ISDN angebotenen Sicherheitsmechanismen wie geschlossene Benutzergruppe, Rufnummernidentifizierung / Teilnehmerauthentifizierung und Callback-Mechanismen zum Einsatz kommen, um einen Verbindungsaufbau von und zu unerwünschten Partnern zu verhindern.
  
• Verschlüsselte Datenübertragung: Zum Schutz vor unbefugter Kenntnisnahme sollte eine verschlüsselte Datenübertragung erfolgen. Zwingend erforderlich ist dies, wenn medizinische Daten über das Internet übermittelt werden, wie es z.B. bei der geplanten Anbindung über DSL der Fall ist.
  
• Fernwartung: Grundsätzlich muss sichergestellt werden, dass im Falle einer Bereitstellung von Endgeräten durch Dritte oder im Rahmen von Wartungsverträgen keine unbefugte Kenntnisnahme der Daten durch den die Wartung Durchführenden stattfindet. Dies betrifft z.B. den ISDN-Router in der Arztpraxis. Es muss durch eine entsprechende Konfiguration und organisatorische Maßnahmen (Verpflichtung der Mitarbeiter, Trennung der Aufgaben etc.) dafür gesorgt werden, dass die Wartungsfirma über den Router keinen Zugriff auf das Praxissystem erhält.
  
• Schutz des Web-Portals und der Datenbank: Wie die Systeme in der Arztpraxis müssen auch die Server des Web-Portals sowie die Datenbank zur Speicherung der Erfassungsbögen über eine Firewall vor unbefugtem Zugriff durch Hacker oder Schadenssoftware geschützt werden.
  
• Interne Anbindung von Web-Portal und Datenbank: Es sollte darauf geachtet werden, dass auch innerhalb der KVB bzw. des Web-Portal-Providers der Zugriff auf den Web-Server und die Datenbank nur für Berechtigte möglich ist. Dies kann z.B. dadurch erreicht
  
  werden, dass eine physikalische Trennung von den sonstigen Systemen vorgenommen wird oder durch die Zwischenschaltung von Firewalls.
  
• Datenbankzugriff: Für den Zugriff berechtigter Personen auf die Daten der Datenbank müssen personenbezogene Kennungen und sichere Authentifizierungsmaßnahmen genutzt werden. Nur so kann verhindert werden, dass z.B. Mitarbeiter der KVB, die nichts mit dem in der Datenbank erfassten Behandlungsprogramm zu tun haben, Kenntnis von den gespeicherten Daten erlangen. Die berechtigten Personen sind für das jeweils auf dem KVB Safenet eingesetzte Programm, z.B. Mammographie-Screening, DMP Diabetes, gesondert zu definieren und in ein Berechtigungskonzept für die Datenbanknutzung umzusetzen.
  
• Administratorenrechte: Häufig besteht die Gefahr, dass Systemadministratoren im Rahmen ihrer Tätigkeit Kenntnis von den gespeicherten Daten erhalten. Dem kann zum einen durch eine verschlüsselte Datenspeicherung begegnet werden. Zum anderen ist es sinnvoll, verschiedene Administratorrollen mit unterschiedlichen Rechten und Aufgaben zu definieren, damit nicht eine Person Zugriff auf alle Informationen und Systeme hat.
  
• Protokollierung: An diversen Stellen sollte eine Protokollierung der Vorgänge erfolgen, um die Revisionsfähigkeit und Überprüfbarkeit von Zugriffen und Aktionen zu gewährleisten. Dies betrifft z.B. die Fernwartung auf dem ISDN-Router oder unbefugte Zugriffsversuche und Änderungen an der Dokumentation auf dem Webportal. Auch die Protokollierung von Administratorzugriffen kann sinnvoll sein.
  
• Nutzung der Daten: Es muss festgelegt werden, zu welchem Zweck und durch wen eine Weiterverarbeitung der in der Datenbank gespeicherten Daten erfolgen darf. Anschließend müssen angemessene technische und organisatorische Maßnahmen getroffen werden, die eine unbefugte Nutzung verhindern. Auch für eine eventuelle weitere Datenübertragung, z.B. zu den Krankenkassen, sind Schutzmaßnahmen nötig.

22.2.3.2. Verschlüsselte Datenarchivierung bei externen Providern

Die zunehmende Digitalisierung spielt in vielen Bereichen, so auch im Gesundheitswesen eine immer stärkere Rolle. Mit ihr steigt die Zahl der über längere Zeiträume zu archivierenden elektronischen Dokumente. Im Krankenhaus können beispielsweise Aufbewahrungszeiten von bis zu 30 Jahren für Röntgenbilder verpflichtend sein. Es ist einsichtig, dass hier eine große Menge von Daten mit hohem Aufwand und Sachverstand gelagert, gepflegt und zugänglich gehalten werden muss, der die Kapazitäten des Krankenhauses in erheblichem Maße bindet. Deshalb streben vermehrt Krankenhäuser die Nutzung externer Provider für die Archivierung der Daten an. Da es sich zumeist um personenbezogene medizinische Daten handelt, für die nach dem Bayerischen Krankenhausgesetz besondere Schutzvorschriften gelten, sind derartige Vorhaben technisch wie juristisch besonders sorgfältig zu bewerten.

Basis der folgenden Darstellung ist eine im Berichtszeitraum vorgenommene Bewertung einer Gesamtlösung zur längerfristigen externen Archivierung von Röntgendaten. Bei dieser Lösung sollen nicht mehr benötigte Bilder nach 4 Jahren in verschlüsselter Form zu einem externen Provider ausgelagert und lokal gelöscht werden. Bei Bedarf soll ein Reimport der Daten möglich werden. Hierzu werden die bildgebenden Systeme an einen speziellen Server, der sich in den Räumen des Krankenhauses befindet, angeschlossen. Auf diesem Server werden zunächst die Daten abgelegt und genutzt. Für die Archivierung besitzt dieser Server eine Anbindung an das externe Rechenzentrum, wo für jeden Kunden eine eigene Datenbank vorhanden ist. Zum Schutz vor Datenverlust werden die Daten zudem auf Bändern gespeichert und an verschiedenen Orten gelagert. Sollen Daten aus dem Kliniksystem archiviert werden, werden sie vom Server verschlüsselt, wobei der geheime Schlüssel passwortgeschützt auf einem speziellen USB-Stick
(eToken) gespeichert ist, und anschließend zum Provider übertragen. Um auch bei einem Verlust des USB-Sticks noch auf die Daten zugreifen zu können, erhält der Kunde zusätzlich eine Sicherungskopie, die sicher verwahrt werden muss.

In rechtlicher Hinsicht habe ich auf Folgendes aufmerksam gemacht:

Bei den Vorhaben sind in erster Linie die Vorgaben des Bayerischen Krankenhausgesetzes zu beachten.

1. Bei den Röntgenbildern handelt es sich um Patientendaten. Im Archiv werden Bilddaten (z.B. Röntgenbilder, Durchleuchtungen, Sonographien, nuklearmedizinische Bilder) und Befunde des Arztes mit dem Namen zwar verschlüsselt abgelegt und der Personenbezug ist nur mit Zusatzwissen (Kenntnis des Schlüssels) herstellbar. Jedoch ist das Klinikum in Besitz des Schlüssels, sodass es sich für das Klinikum um personenbezogene Daten handelt.
2. Das Gesetz differenziert zwischen Patientendaten, die zur verwaltungsmäßigen Abwicklung erforderlich sind und solchen, die dies nicht sind. Bei Letzteren, nämlich den hier vorliegenden medizinischen Daten, ist das Datenschutzniveau angehoben, da die Auftragsdatenverarbeitung nach Art. 27 Abs. 5 Satz 6 Bayerisches Krankenhausgesetz (BayKrG) nur in einem anderen Krankenhaus erfolgen darf. Dies wäre in dem mir vorliegenden Fall nicht gegeben gewesen. Es stellte sich daher die Frage, ob der Gesetzeswortlaut so ausgelegt werden kann, dass auch die externe Archivierung durch Private darunter gefasst werden kann. Deshalb war nach Sinn und Zweck der Regelung des Art. 27 Abs. 5 Satz 6 BayKrG zu fragen. Hier sind zwei Aspekte zu unterscheiden. Zum einen sollte durch die Norm der Beschlagnahmeschutz gewährleistet sein, zum anderen sollte der Kreis der Personen, die mit Patientendaten in Berührung kommen, möglichst eng und qualifiziert sein.
1. Für Daten, die nicht zur verwaltungsmäßigen Abwicklung erforderlich sind ("medizinische Daten"), sollte der Beschlagnahmeschutz des § 97 Abs. 2 StPO a.F. gewährleistet werden. Denn früher mussten sich die Datenträger im Gewahrsam des Krankenhauses befinden, um "beschlagnahmefest" zu sein. Diese gesetzgeberische Intention des BayKrG ist mittlerweile durch eine Gesetzesnovellierung des § 97 Abs. 2 StPO erfüllt. Durch Art. 30 Nr. 2 des Gesetzes zur Modernisierung der gesetzlichen Krankenversicherung (GKV-Modernisierungsgesetz-GMG, BGBl 2003 Teil I, Seite 2190 ff., 2256) hat § 97 Abs. 2 Satz 2 der Strafprozessordnung (StPO) mit Wirkung ab dem 01.01.2004 (Art. 37 Abs. 1 GMG) folgende Fassung erhalten:
   
   "Der Beschlagnahme unterliegen auch nicht Gegenstände, auf die sich das Zeugnisverweigerungsrecht der Ärzte, Zahnärzte, Psychologischen Psychotherapeuten, Kinder- und Jugendlichenpsychotherapeuten, Apotheker und Hebammen erstreckt, wenn sie im Gewahrsam einer Krankenanstalt oder eines Dienstleisters, der für die Genannten personenbezogene Daten erhebt, verarbeitet oder nutzt, sind, sowie Gegenstände, auf die sich das Zeugnisverweigerungsrecht der in § 53 Abs. 1 Satz 1 Nr. 3 a und 3 b genannten Personen erstreckt, wenn sie im Gewahrsam der in dieser Vorschrift bezeichneten Beratungsstelle sind."
   
   
   
   Mit der Neuregelung wird damit der Schutz dieser Daten über den Gewahrsam eines Krankenhauses hinaus erweitert auf den Gewahrsam eines Datenverarbeiters im Auftrag der Genannten.
   
2. Damit gefährdet ein fehlender Beschlagnahmeschutz das Recht auf informationelle Selbstbestimmung nicht mehr. Die gesetzgeberische Regelung kann nur noch den Sinn haben, dass der Kreis der Personen, die mit medizinischen Daten in Berührung kommen, möglichst eng und qualifiziert sein soll. Unbefugte sollen von medizinischen Daten keine Kenntnis erhalten. Dies hielt der Gesetzgeber in Krankenhäusern wohl eher für gewährleistet als außerhalb.
   
   Dieser gesetzgeberische Zweck ist jedoch unter bestimmten Voraussetzungen auch dann erfüllt, wenn die Daten verschlüsselt bei einem Auftragnehmer gespeichert werden. Durch bestimmte technische Maßnahmen können die Gefährdungen für das Recht auf informationelle Selbstbestimmung minimiert werden. Dabei kann zwar nicht generell jegliche Gefährdung ausgeschlossen und von garantierter Sicherheit in jedem Fall gesprochen werden. Entscheidend ist insofern, dass bei den technischen und organisatorischen Maßnahmen ein Standard erreicht wird, der die praktische Sicherheit des Verfahrens gewährleistet. Hierzu sind sowohl vom Systemanbieter als auch vom Klinikum gewisse technisch-organisatorische Aspekte der Realisierung zu untersuchen und Anforderungen zu erfüllen.
   
   Dies beinhaltet mehrere Aspekte, die in unterschiedliche Verantwortlichkeiten fallen. Die im Folgenden aufgeführten Punkte 1. und 2. müssen vom Systemanbieter sichergestellt werden, für die Punkte 3. und 4. sind Anbieter und Krankenhaus gemeinsam verantwortlich und 5. liegt vor allem in der Zuständigkeit des Krankenhauses.
   
1. Theoretische Sicherheit des Verschlüsselungsverfahrens
2. Praktische Nichtangreifbarkeit des Verschlüsselungsverfahrens
3. Unterbindung unbefugter Entschlüsselungsversuche mit Zusatzwissen
4. Sichere Installation und Initialisierung des Systems
5. Gewährleistung einer gesicherten Einsatzumgebung
   
   

Zu 1. Theoretische Sicherheit des Verschlüsselungsverfahrens:
Es muss sichergestellt werden, dass nur Verschlüsselungsverfahren zum Einsatz kommen, die veröffentlicht sind und daher von anerkannten Experten kyptanalytisch untersucht wurden. Nur so kann sichergestellt werden, dass das eingesetzte Verfahren ein nach dem derzeitigen Wissensstand starkes Verschlüsselungsverfahren ist, das keine Einbruchsmöglichkeiten bietet. Auch die Angaben zur momentan geeigneten Mindestschlüssellänge sind zu befolgen. Es ist sicherzustellen, dass schwache Schlüssel, soweit vorhanden, nicht verwendet werden.

Zu 2. Praktische Nichtangreifbarkeit des Verschlüsselungsverfahrens:
Häufig beruht eine praktische Angreifbarkeit von theoretisch sicheren Verfahren auf Fehlern bei der Implementierung. Hierzu gehört z.B. ein schlecht programmierter Zufallszahlengenerator, der zur Schlüsselerzeugung benötigt wird. Ein solcher Zufallszahlengenerator ist unter Umständen vorhersagbar oder erzeugt nur einen Teil der theoretisch möglichen Schlüssel. Damit kann der Schlüsselraum deutlich eingeschränkt werden, sodass z.B. bei symmetrischen Verfahren, für die heute im allgemeinen 128 Bit als ausreichende Schlüssellänge angesehen werden, die Zahl der auszuprobierenden Kombinationen so weit gesenkt werden kann, dass ein Brute Force Angriff realistisch erscheint.

Zu 3. Unterbindung unbefugter Entschlüsselungsversuche mit Zusatzwissen:
Häufig stützen sich kryptanalytische Methoden auf Zusatzinformationen, die dem Angreifer neben dem verschlüsselten Text zur Verfügung stehen. Solche Informationen können gerade einem internern Angreifer zugänglich sein, wie z.B. den Administratoren des Rechenzentrums. Es muss daher durch geeignete organisatorische Maßnahmen ausgeschlossen werden, dass ein interner Angreifer einerseits zu viele Informationen, andererseits Zugang zu den verschlüsselten Daten erhalten kann, um unbefugte Entschlüsselungsversuche zu unternehmen:

Durch Rollentrennung ist auszuschließen, dass ein Mitarbeiter sowohl Entwickler als auch Anwender (z.B. Wartungstechniker) des Verfahrens oder Administrator ist. Damit soll verhindert werden, dass einerseits der Entwickler Zugriff auf Echtdaten erhält und andererseits der Anwender Zugriff auf den Quellcode und der Administrator Zugang zur Verschlüsselungssoftware hat. Auch der Zugriff auf die verschlüsselten Daten sowie Kenntnisse zur Erzeugung des Schlüssels und Zugang zur Software, die den Schlüssel generiert, dürfen nur einem möglichst kleinen Kreis zugänglich sein.

Die Schutzfunktion von Verschlüsselungsverfahren ist zeitlich begrenzt. Dies kann sowohl die Schlüssellänge, als auch das gesamte Verfahren betreffen, wenn sich mit dem technischen Fortschritt die verfügbare Rechenleistung erhöht oder neue Erkenntnisse im Bereich der Kryptanalyse bekannt werden. Um die Sicherheit der Daten über 30 Jahre hinweg zu erhalten, wird ein Verfahren benötigt, das die archivierten Daten bei Bedarf verschlüsselungstechnisch auf den neuesten Stand bringt. Für die Krankenhausmitarbeiter muss während dieser Umschlüsselung durch den Anbieter überprüfbar sein, dass kein unbefugter Zugriff auf die unverschlüsselten Daten erfolgt. Im Rechenzentrum muss gleichzeitig sichergestellt werden, dass die alten Datenbestände auch wirklich gelöscht werden.

Zu 4. Sichere Installation und Initialisierung des Systems:
Im Rahmen der Systeminstallation im Krankenhaus muss einerseits sichergestellt werden, dass die Techniker des Anbieters keine Kenntnisse von den personenbezogenen medizinischen Daten erlangen. Andererseits darf ein Techniker keinen Zugriff auf den Verschlüsselungsschlüssel, den er erzeugt, erhalten. Zusätzlich sollte er möglichst wenig Kenntnisse über das Verfahren zur Erzeugung des Schlüssels haben. Darüber hinaus muss bei Wartungs- und Fernwartungsarbeiten gewährleistet sein, dass der Techniker auch hier keine Einsicht in die Daten auf dem Server im Krankenhaus oder den Schlüssel erhält.

Zu 5. Gewährleistung einer gesicherten Einsatzumgebung:
Die Sicherheit des Gesamtsystems ist nicht ausschließlich abhängig von der Verschlüsselung der ausgelagerten Bilddaten. Das Krankenhaus muss zudem für eine geschützte Einsatzumgebung sorgen:

Der Verschlüsselungsschlüssel wird im Rahmen der Systeminstallation auf einem passwortgeschützten USB-Stick gespeichert. Das Krankenhaus muss darauf achten, dass die Regeln für sichere Passworte zur Anwendung kommen und das Passwort nicht an Unbefugte weitergegeben wird. Zusätzlich muss der USB-Stick vor einer unerlaubten Entfernung geschützt werden. Auch die Sicherungskopie des Schlüssels muss sicher verwahrt werden.

Des Weiteren muss vom Krankenhaus verhindert werden, dass unberechtigte Personen von innerhalb und außerhalb des Krankenhauses Zugriff auf unverschlüsselte Daten des Radiologiesystems oder den Schlüssel erhalten. Dies betrifft sowohl den Anmeldevorgang am System, als auch den physischen wie den Remote Zugriff auf den Server, die z.B. durch starke Authentifizierungsmaßnahmen und räumliche Absicherung verhindert werden müssen.

Zusätzlich muss die Datenübertragung über die externe Anbindung des Radiologiesystems an das Rechenzentrum abgesichert werden. So kann z.B. mittels VPN, Zugangskontrollen und Firewalls zum einen dafür gesorgt werden, dass kein unbefugter externer Verbindungsaufbau zum Rechenzentrum sowie ins Krankenhaus möglich ist. Zum anderen wird der Transport über verschlüsselte Verbindungen möglich.

Unter diesen Voraussetzungen verstößt meiner Ansicht nach die externe Archivierung von Röntgenbilddaten nicht gegen das Bayerische Krankenhausgesetz.

Die dargelegten Wertungen haben auch Auswirkungen auf standes- und strafrechtliche Vorschriften, die das Arztgeheimnis betreffen. Wenn geeignete technische und organisatorische Maßnahmen getroffen werden, kann aus meiner Sicht die Möglichkeit der unbefugten Kenntnisnahme durch einen Dritten praktisch ausgeschlossen werden. Damit würde kein unbefugtes Offenbaren vorliegen, das standes- oder strafrechtlich sanktioniert wäre.

22.2.3.3. JobCard-Verfahren

Angestoßen durch eine Initiative der Bundesregierung, wird derzeit unter der Führung der ITSG (Informationstechnische Servicestelle der Gesetzlichen Krankenversicherung) GmbH an Realisierungsmöglichkeiten für das JobCard-Verfahren gearbeitet. Ziel dieses Verfahrens ist es, durch ausschließlich elektronische Datenübermittlung zwischen Arbeitgebern und Leistungserbringern den Aufwand für die Erstellung von arbeitsbezogenen Bescheinigungen deutlich zu reduzieren. Dazu soll zukünftig ein standardisierter Datensatz mit Einkommens- und Beschäftigungsdaten als Basis für die unterschiedlichen Bescheinigungen (z.B. Arbeitsbescheinigung, Verdienstbescheinigungen zur Berechnung von Wohngeld, Kindergeld etc.) regelmäßig vom Arbeitgeber an eine zentrale Speicherstelle (ZSS) übermittelt und dort bei Bedarf durch die Mitarbeiter der
Agentur für Arbeit abgerufen werden. Den Zugriff für den Mitarbeiter der Agentur gewährt der betroffene Arbeitnehmer über eine signaturgesetzkonforme Chipkarte, die für das JobCard-Verfahren angemeldet wurde. Durch das JobCard-Verfahren soll eine Entlastung der Arbeitgeber und der Abbau von Bürokratie erreicht werden.

Zur Überprüfung der technischen Machbarkeit wurde in einem ersten Projekt JobCard I, das im April 2004 abgeschlossen wurde, der Abruf der Arbeitsbescheinigung nach § 312 SGB III getestet. Bis 30.06.2005 läuft ein Modellversuch ebenfalls mit virtuellen Personen und mit weiteren 17 Bescheinigungen, deren entsprechende Eignung im Rahmen des Modellversuchs geprüft werden soll. Anschließend soll, nach einer Ausschreibung, die bundesweite Realisierung des Verfahrens beginnen. Geplant ist, das Verfahren zum 01.01.2007 für alle Arbeitnehmer verpflichtend einzuführen.

Da das JobCard-Verfahren komplexe datenschutzrechtliche sowie technisch-organisatorische Fragen aufwirft, wurde auf meine Initiative eine Arbeitsgruppe der Konferenz der Datenschutzbeauftragten des Bundes und der Länder zu diesem Thema ins Leben gerufen, die im Mai 2004 das erste Mal zusammentrat und deren Moderator ich bin.

Ich hielt eine intensive Diskussion des JobCard-Verfahrens unter anderem vor dem Hintergrund des Volkszählungsurteils des Bundesverfassungsgerichts für notwendig. Denn aus diesem Urteil kann auch abgeleitet werden, dass es dem Staat untersagt ist, zentrale Datenbestände aufzubauen, für jeden Bürger ein Personenkennzeichen zu vergeben und es Behörden dann zu ermöglichen, beliebige Daten aus diesem zentralen Datenbestand abzurufen. Insbesondere die Schaffung zentraler Datenbestände ist aus Datenschutzsicht immer mit Vorsicht zu betrachten, da diese Begehrlichkeiten wecken und Missbrauchsmöglichkeiten eröffnen. Dabei sollte man sich nicht zu sehr auf rechtliche Sicherungen verlassen, sondern möglichst schon mit technischen Mitteln Gefährdungen für das Recht auf informationelle Selbstbestimmung ausschließen. Bereits von daher bedurfte die Entwicklung des JobCard-Verfahrens einer kritischen Begleitung durch den Datenschutz.

Das JobCard-Verfahren wirft jedoch noch weitere Probleme auf. So ist es ein allgemeiner datenschutzrechtlicher Grundsatz, dass Daten nur erhoben werden dürfen, wenn es für die Aufgabenerfüllung einer Behörde auch erforderlich ist. Dieser Punkt ist im vorgeschlagenen Verfahren problematisch. Denn das JobCard-Verfahren soll für alle Arbeitnehmer verpflichtend eingeführt werden. Somit werden für alle Arbeitnehmer monatlich, unabhängig vom Bedarfsfall, Einkommensdaten an eine zentrale Stelle übertragen. Im Zeitpunkt der Datenerhebung ist noch überhaupt nicht klar, ob eine Behörde überhaupt jemals diese Daten benötigen wird. So ist es zweifelhaft, ob man im Hinblick auf eine zukünftige Kindergeldgewährung bereits Einkommensdaten erheben darf, wenn jemand überhaupt keine Kinder hat. Hier wird das Problem der "Datenspeicherung auf Vorrat" berührt.

Weiter ist bei der Datenverarbeitung und -nutzung der Grundsatz der Zweckbindung zu beachten. Auch diesbezüglich war das JobCard-Verfahren kritisch zu untersuchen. Schließlich gebietet es die Rechtssicherheit, die Verantwortlichkeiten und den Status der beteiligten Stellen bereits im vorhinein exakt zu definieren. Dies ist unter anderem deshalb erforderlich, damit der Bürger weiß, an welche Stelle er sich im Zweifelsfall wenden kann.

All diese Fragen müssen zunächst mit den Entwicklern des Konzepts kritisch erörtert werden. In einem weiteren Schritt sind dann die wohl erforderlichen Gesetzgebungsarbeiten mit datenschutzrechtlichem Sachverstand zu begleiten.

Geplanter Realisierungsansatz

Die von der ITSG vorgestellte technische Realisierung des JobCard-Verfahrens sieht einen standardisierten Datensatz vor, der Informationen zu Beschäftigungszeiten, Entgeltzahlungen sowie Angaben zur Auflösung von Beschäftigungsverhältnissen enthält. Er wird vom Arbeitgeber regelmäßig in verschlüsselter Form über eine gesicherte Internet-Verbindung an die ZSS übertragen. Dort wird der Datensatz vor der Speicherung temporär entschlüsselt, um Plausibilitätskontrollen durchzuführen und anschließend mit einem Masterkey-Verfahren verschlüsselt und in der Datenbank der ZSS abgelegt. Die Datensätze werden dort so lange aufbewahrt, wie sie für die Bearbeitung durch die Arbeitsagentur benötigt werden, mindestens jedoch sieben Jahre. Besteht auf Seiten des Arbeitnehmers Bedarf an einer arbeitsbezogenen Bescheinigung, z.B. im Falle der Arbeitslosigkeit, wendet er sich an die Agentur für Arbeit. Mit Hilfe seiner JobCard signiert er eine (elektronische) Vollmacht, die dem Mitarbeiter der Arbeitsagentur den Zugriff auf die Daten des Arbeitnehmers erlaubt. Der Mitarbeiter muss sich für den Zugriff über eine Chipkarte authentifizieren. Die Daten des Betroffenen werden bei der ZSS angefragt, dort mit dem Masterkey entschlüsselt, mit dem Schlüssel der Arbeitsagentur neu verschlüsselt und über eine gesicherte Verbindung übertragen. Die Arbeitsagentur kann die Daten für den Zeitraum der Antragsbearbeitung nutzen. Zudem kann der Betroffene zustimmen, dass Daten, die in einem bestimmten Zeitraum nach Antragstellung eintreffen, ebenfalls entschlüsselt und abgerufen werden dürfen, um ein wiederholtes Erscheinen unnötig zu machen.

Zur technischen Absicherung der Datenübertragung und -speicherung werden verschiedene Maßnahmen ergriffen. Sowohl die Arbeitgeber als auch die Arbeitsagentur kommunizieren mit der ZSS über verschlüsselte SSL-Verbindungen. Zusätzlich werden auch die einzelnen Datensätze verschlüsselt. Die Internetanbindung der ZSS ist über Firewalls abgesichert. Dahinter liegen jeweils ein äußeres und inneres Sicherheitssystem, die die Kommunikationspartner verifizieren, die Vollmacht für den Datenzugriff überprüfen, die Daten umschlüsseln und Plausibilitätschecks durchführen. Erst danach erfolgt der Zugriff auf die Datenbank.

Problematik, alternative Ansätze

Eine Kernproblematik bei obigem Realisierungsvorschlag besteht aus technisch-organisatorischer Datenschutzsicht darin, dass die ZSS die technische Möglichkeit hat, sämtliche Daten zu entschlüsseln, da sie im Besitz der verschlüsselten Daten und des Masterkeys ist. Sie kann somit technisch betrachtet alle gespeicherten Daten der Arbeitnehmer ungehindert einsehen ohne selbst die Stelle zu sein, die die Daten für ihre Aufgabenerfüllung benötigt. Daher werden derzeit zwischen der Arbeitsgruppe und der ITSG GmbH verschiedene andere Lösungsansätze diskutiert.

Ein Ansatz ist die Ende-zu-Ende-Verschlüsselung der Daten jeweils mit dem Schlüssel des Betroffenen. Grob skizziert werden in diesem Fall die Datensätze des Arbeitgebers jeweils mit dem öffentlichen Schlüssel des betroffenen Arbeitnehmers (Verschlüsselungsschlüssel auf der Signaturkarte) verschlüsselt und an die ZSS übermittelt. Dadurch ist nur der Eigentümer der
JobCard in der Lage, eine Entschlüsselung vorzunehmen. Identifikationsmerkmal zur Speicherung des verschlüsselten Datensatzes und zum Zugriff ist die UniqueID der Chipkarte des Arbeitnehmers. Eine Nutzung der Daten durch den Sachbearbeiter des betroffenen Amtes ist nach diesem Konzept nur nach Entschlüsselung der Daten mit dem privaten Schüssel des Arbeitnehmers möglich, wodurch dieser die alleinige Kontrolle über seine Daten hat. Anschließend können die Daten auf dem Client des Mitarbeiters im Klartext im Rahmen des Bearbeitungsvorgangs gespeichert werden. Die Umsetzbarkeit eines derartigen Verfahrens soll nach den Vorstellungen der Arbeitsgruppe durch ein Gutachten überprüft werden.

Bisherige Ergebnisse der Arbeitsgruppe

Die Arbeitsgruppe, insbesondere die Vertreter der Landesbeauftragten für den Datenschutz, favorisieren die Ende-zu-Ende-Verschlüsselung gegenüber dem Verfahren der ITSG, aber auch gegenüber den anderen Alternativvorschlägen, die das Problem der technischen Entschlüsselbarkeit des gesamten Datenbestandes häufig nur verlagern, nicht aber beheben. Da jedoch deutlich wurde, dass im laufenden Pilotprojekt JobCard II keine grundsätzlichen konzeptionellen Änderungen mehr möglich sind, wurde in einer Sitzung der Arbeitsgruppe am 09.09.2004 folgendes Vorgehen beschlossen, um im endgültigen Verfahren Verbesserungen des Verfahrens im Hinblick auf den Datenschutz zu erlangen:

• Die Landesdatenschutzbeauftragten sind der Auffassung, dass eine Speicherung personenbezogener Daten des Betroffenen nur zugelassen werden sollte, wenn dieser die technische Verfügungsbefugnis hat (z.B. Ende-zu-Ende-Verschlüsselung mit Schlüssel des Betroffenen).
  
• Diese sind der Meinung, dass mit einer Ende-zu-Ende-Verschlüsselung der Arbeitnehmerdaten eine Alternative zum bisherigen Ansatz zur Diskussion steht, mit der eine datenschutzgemäße Realisierung des JobCard-Verfahrens möglich erscheint.
  
• Da deutlich wurde, dass im Hinblick auf den fortgeschrittenen Stand der Pilotprojekte eine Implementierung in das Pilotprojekt JobCard II nicht mehr realisiert werden kann, schlagen die Datenschutzbeauftragten vor, parallel zur Abwicklung des Projekts JobCard II eine Untersuchung über die Integrierbarkeit der Ende zu Ende Verschlüsselung in das JobCard-Verfahren in Auftrag zu geben, deren Ergebnisse in der endgültigen Ausschreibung des JobCard-Verfahrens berücksichtigt werden sollen.
  

Die Datenschutzkonferenz hat am 29.10.2004 den Vorschlag der Arbeitsgruppe aufgegriffen und zustimmend zur Kenntnis genommen. Sie hat den Arbeitskreis Technik der Datenschutzbeauftragten des Bundes und der Länder beauftragt, die näheren Rahmenbedingungen für den Gutachtenauftrag zu definieren. Gleichzeitig hat sie den Bundesbeauftragten gebeten, das BMWA auf dieser Grundlage um Vergabe eines Gutachtens an einen neutralen Gutachter zur Realisierbarkeit der Ende-zu-Ende-Verschlüsselung zu bitten.

22.2.3.4. Telematikplattform für medizinische Forschungsnetze (TMF), Kompetenznetze

Im Berichtszeitraum war ich auch mit der Bewertung der technisch-organisatorischen Datenschutzkonzepte verschiedener medizinischer Kompetenznetze befasst. Die Kompetenznetze dienen dem Aufbau von Vernetzungsstrukturen zur Durchführung bundesweiter klinischer Studien bezüglich einzelner chronischer und schwerer Erkrankungen über längere Zeiträume hinweg an großen Patientengruppen. Eine Übersicht hierzu bietet www.kompetenznetze-medizin.de/ (externer Link). Derartige Kompetenznetze werfen meist ähnliche datenschutzrechtliche und technische Schwierigkeiten bei der Realisierung auf:

• Wissenschaftliche Langzeitbeobachtung chronisch kranker Patienten
  
• Nutzung von Patientendaten im Forschungs- und Behandlungszusammenhang
  
• Dokumentation durch mehrere behandelnde Stellen

Um diesen Anforderungen zu begegnen, wurde von der Telematikplattform für medizinische Forschungsnetze (TMF) e.V. (www.tmf-net.de (externer Link)) ein generisches Datenschutzkonzept entwickelt. Die TMF e.V., in deren Beirat ich Mitglied bin, ist ein Zusammenschluss medizinischer Forschungsverbünde zur Förderung vernetzter Strukturen, mit dem Ziel, geeignete IT-Infrastrukturen zu schaffen.

Das generische Datenschutzkonzept wurde von der TMF in enger Abstimmung mit dem Arbeitskreis Wissenschaft der Datenschutzbeauftragten des Bundes und der Länder entwickelt, um die bundesweite Verwendbarkeit zu gewährleisten. Es wurde im März 2003 vom AK Wissenschaft angenommen und steht seitdem als Basis für die Realisierung der einzelnen Kompetenznetze zur Verfügung.

Neben den Regeln zur Erfassung und Speicherung medizinischer Patientendaten berücksichtigt das Konzept auch die organisatorische und logistische Einbeziehung von Laborproben und Biomaterialien. Insbesondere enthält es Vorgehensweisen zur Qualitätssicherung bei der Datenerfassung und die Bedingungen zur nachträglichen Reidentifikation von Patienten, um sie über wichtige wissenschaftliche Erkenntnisse informieren zu können. Um den verschiedenen Arten von Studien gerecht zu werden, wurden zwei Lösungsvarianten erarbeitet: klinisch fokussierte Forschungsnetze und wissenschaftlich fokussierte Forschungsnetze.

Klinisch fokussierte Forschungsnetze

In diesem Fall werden die Daten direkt aus dem klinischen Behandlungsprozess heraus erhoben, da die Forschungsergebnisse dem Behandler direkt zur Verfügung stehen sollen. Gleichzeitig dürfen für wissenschaftliche Auswertungen jedoch keine identifizierenden Daten der Patienten genutzt werden. Daher wurde eine getrennte Datenhaltung eingeführt: Die identifizierenden Daten (Name, Adresse etc.) werden zusammen mit einer daraus generierten, eindeutigen PID (Patientenidentifikator) in einer Patientenliste abgespeichert. Die Behandlungsdaten werden nur mit dieser PID, ohne die identifizierenden Daten, in der Behandlungsdatenbank abgelegt. Der behandelnde Arzt kann bei Bedarf temporär Daten der beiden Bestände online zusammenführen (nach entsprechender Berechtigungsprüfung), für den wissenschaftlichen Zugriff erfolgt ein Export von Daten ohne PID, sodass kein Online-Zugriff auf die Behandlungsdaten besteht.

Wissenschaftlich fokussierte Forschungsnetze

In diesem Fall erfolgt die Erfassung der Daten getrennt vom Behandlungsprozess. Die Schwierigkeit besteht dabei darin, die Qualität der erfassten Daten sowie eine Fortschreibung der Daten bei chronischen Erkrankungen sicherzustellen, ohne dem Wissenschaftler Zugang zu identifizierenden Patientendaten zu ermöglichen. Die identifizierenden Daten werden daher wiederum mit einer PID versehen und in einer separaten Patientenliste gespeichert. Den medizinischen Daten wird ebenfalls die PID zugeordnet und sie werden im ersten Schritt an die Qualitätskontrolle weitergegeben, die eine Nacherfassung veranlassen kann. Danach werden die Daten mit einem von der TMF definierten Verfahren pseudonymisiert, d.h. die PID wird mittels kryptografischer Transformation durch ein Pseudonym (PSN) ersetzt, und in der Forschungsdatenbank abgelegt, auf die die Wissenschaftler online zugreifen können. Die Rückführung des PSN ist für die Wissenschaftlicher technisch nicht möglich, hierzu muss ein definiertes Verfahren mit mehreren Beteiligten angestoßen werden.

Technische Sicherheitsmaßnahmen

Beide Teilkonzepte enthalten gewisse obligatorische Basissicherheitsmechanismen. Dies beinhaltet die Verschlüsselung sämtlicher Datenübertragungen via SSL, also sowohl bei der Erfassung der Daten, die meist über ein Web-Formular erfolgt, als auch beim Transport der Daten zwischen verschiedenen Datenbanken. Da die Übermittlung teilweise über das Internet erfolgt, müssen die beteiligten Geräte gegen Angriffe und Schadenssoftware geschützt werden (Firewall, Virenscanner etc.). Die Absicherung der beteiligten Rechenzentren wird als gegeben angenommen. Eine weitere Maßnahme ist die verschlüsselte Datenspeicherung der identifizierenden Daten in der Patientenliste einerseits und der medizinischen Daten in den Forschungs-/Behandlungsdatenbanken andererseits.

Auch Basisrichtlinien zur Vergabe von Zugriffsberechtigungen wurden definiert. So haben z.B. im klinisch fokussierten Ansatz nur die behandelnden Ärzte Online-Zugriff auf die Daten ihrer Patienten. Als Basis der Zugriffsrechte auf der Behandlungsdatenbank wird die Zuordnung Arzt - Patient in der Patientenliste abgespeichert. Über ein Rollenkonzept können einzelnen Personen mit verschiedenen Aufgaben jeweils angemessene Rechte zugeteilt werden. Löschbefugnisse für die Patientendaten sind für Ärzte grundsätzlich ausgeschlossen. Um eine Kenntnisnahme der Gesamtdaten bzw. ihre Zusammenführbarkeit durch einen Administrator zu verhindern, werden Patientenliste und Behandlungsdatenbank getrennt administriert und häufig an verschiedenen Stellen gespeichert. Zudem dürfen die Administratoren nicht an der Behandlung oder wissenschaftlichen Verwertung beteiligt sein. Zur Gewährleistung der Revisionssicherheit werden alle datenschutzrelevanten Vorgänge protokolliert.

In wissenschaftlich fokussierten Forschungsnetzen spielt die Sicherheit des Schlüssels zur Pseudonymgenerierung eine große Rolle, da ansonsten die PID ermittelt werden kann. Deshalb wird der Schlüssel auf passwortgeschützten SmartCards gespeichert, die sicher verwahrt werden müssen. Für die Pseudonymisierung, und somit für die Aufnahme der Daten in die Forschungsdatenbank, authentifizieren sich die Beteiligten wechselseitig über SSL und es werden nur Daten von zugelassenen Sendern entgegen genommen. Die medizinischen Daten selbst liegen während der Pseudonymisierung nur verschlüsselt vor, da sie von der Qualitätssicherung ver- und erst in der Forschungsdatenbank wieder entschlüsselt werden. Die hierzu benötigten Schlüssel sind ebenfalls auf einer SmartCard gespeichert.

Beispiele für Kompetenznetze

Trotz der generischen Datenschutzkonzepte unterscheiden sich die verschiedenen Kompetenznetze im Detail voneinander, sodass jeweils eine genauere Ausgestaltung des gewählten Basiskonzepts nötig ist. In deren Bewertung sind auch jeweils die Landesbeauftragten für Datenschutz eingebunden. Die aktuellsten Beispiele sind die Kompetenznetze Herzinsuffizienz und HIV/ AIDS.

Das Kompetenznetz Herzinsuffizienz, das federführend vom Berliner Beauftragten für Datenschutz und Informationsfreiheit betreut wird, umfasst eine größere Anzahl von Teilprojekten zu diesem Krankheitsbild. Das Datenschutzkonzept orientiert sich an dem für wissenschaftlich orientierte Forschungsnetze. Dabei wurde allerdings für die benötigte verteilte Datenhaltung die Systemstruktur (normalerweise bestehend aus Patientenliste und Forschungsdatenbank) deutlich erweitert und enthält darüber hinaus Studien- und Projektdatenbanken. Zudem musste dem Umstand Rechnung getragen werden, dass ein Patient Teilnehmer mehrerer Studien sein kann, ohne eine Verschlechterung des Datenschutzes zu bewirken. Beides macht die Festlegung weiterer angemessener technischer Sicherheitsmaßnahmen erforderlich.

Auch das Kompetenznetz HIV/AIDS (Federführung Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen) orientiert sich am Datenschutzkonzept für wissenschaftlich fokussierte Forschungsnetze. Änderungsbedarf zum generischen Konzept bestand hier bezüglich des Monitorings und der Replikation der Forschungsdatenbank. Der Monitor überprüft stichprobenartig Fälle aus der Datenbank mit den Originaldaten vor Ort, wodurch er Einblick in patientenbezogene medizinische Daten erhält, der geregelt werden muss. Insbesondere durch die Replikation der Datenbanken zu Zwecken der Qualitätssicherung wird die technische Infrastruktur über das Basiskonzept hinaus erweitert, sodass hier entsprechende Sicherheitsmechanismen definiert werden müssen.

22.2.3.5. Portal-Technologie

Im Berichtszeitraum wurde ich mit dem Projekt "GeoPortal" aus der High Tech-Offensive (HTO) der Bayerischen Staatsregierung befasst. Im Mittelpunkt von GeoPortal steht die Überprüfung der Realisierbarkeit eines Einstiegsknotens im Internet, über den mehrere bei unterschiedlichen speichernden Stellen vorgehaltene Datenbanken miteinander verknüpft werden können. Einem autorisierten Benutzer sollen die Ergebnisdaten für seine Abfrage ungeachtet des physikalischen Speicherortes "in einem Zuge" präsentiert werden; der Benutzer braucht keinerlei Kenntnis über die Verfügbarkeit oder tatsächlichen Speicherorte der angefragten Daten zu haben - er bedient sich lediglich eines "Web-Services".

Für das Projekt wurden

• staatliche Daten (die Digitale Flurkarte (DFK) eines staatlichen Vermessungsamtes, digitale Orthofotos, die Digitale Topographische Karte 1:25.000 und Georeferenzierte Adressen des Bayerischen Landesvermessungsamtes sowie Daten des Raumordnungskatasters (ROK) des Ministeriums für Landesentwicklung und Umweltfragen), die sich innerhalb des Bayerischen Behördennetzes befinden,
  
• gemeindliche Daten (Automatisiertes Liegenschaftsbuch (ALB)), die sich innerhalb des gemeindlichen Intranets befinden, und
  
• externe Daten (z.B. Bebauungspläne), die sich im Internet verteilt befinden, durch die Technische Universität München simuliert und

für autorisierte Mitarbeiter einer Pilotgemeinde virtuell miteinander kombiniert.

Die technische Machbarkeit konnte im Pilotprojekt gezeigt werden. Die Einbindung weiterer Datenbestände ist denkbar. Durch diese virtuelle Zusammenführung und Aggregierung der über mehrere Netzwerke verteilten Daten könnten für die öffentliche Verwaltung und auch für den Bürger z.B. im gesamten Bereich der Baugenehmigungsverfahren erheblicher Aktualitäts- und Komfortgewinn sowie erhebliches Einsparpotenzial realisiert werden.

Ganz entscheidend für die Zulässigkeit derartiger Systeme sind aber die Einhaltung gesetzlicher Normen betreffend

• die Zweckbindung der jeweiligen Datenbestände,
  
• die Zulässigkeit eines (automatisierten) Datenabrufs,
  
• die durchgängige Sicherstellung von Authentizität, Integrität und Vertraulichkeit der Daten sowie
  
• eine zuverlässige Benutzerverwaltung mit Zugriffskontrolle und jeweiliger Netzabsicherung.

Wichtiges Werkzeug in diesem Zusammenhang ist wieder einmal die Kryptographie in Form von elektronischer Signatur, Zertifikaten und Nutzdatenverschlüsselung. Auch ohne funktionierende Public Key Infrastruktur (PKI) wird etwas Derartiges für eine Praxisanwendung nicht zu realisieren sein. Ich konnte hier meine Anregungen einbringen.

Wenngleich auch noch einige Detailfragen in diesem Projekt offen blieben, so erscheint es doch wegweisend für evtl. weitere Vorhaben auch aus anderen Bereichen. Es hat jedenfalls deutlich gezeigt, dass gerade bei derart komplexen Systemen eine frühzeitige Einbindung meiner Dienststelle unabdingbar ist und nur so Fehlentwicklungen oder gar unzulässige Entwicklungen vermieden werden können.

22.3. Technische Einzelprobleme

22.3.1. USB Memory Sticks

USB steht für "Universal Serial Bus" und wurde 1995 als Industrie-Standard entwickelt, um periphere Geräte an Computer anzuschließen und alte Schnittstellen, wie parallele, serielle oder PS/2 zu ersetzen. In der aktuellen Version 2.0 unterstützt USB Übertragungsraten von bis zu 480 Mbit/s und es können bis zu 127 unterschiedliche Geräte an einen Bus angeschlossen werden.

Nahezu jeder heute aktuelle PC wird mit einer USB Schnittstelle ausgeliefert. Die neuesten Modelle verwenden deswegen zum Teil keine der alten Schnittstellen mehr, sodass Tastatur, Maus und Drucker nur noch über USB angeschlossen werden können. Ein Arbeiten ohne USB ist an solchen Workstations somit nicht mehr möglich.

Sobald ein PC eine USB-Schnittstelle hat, kann an diese die oben genannte große Anzahl an Geräten angeschlossen werden. Auch wenn alle USB-Steckplätze am Gehäuse z.B. durch Maus und Tastatur bereits belegt sind, lässt sich problemlos ein USB-Hub dazwischen stecken, der dann zusätzliche freie Schnittstellen bietet.

Betrachtet man die Geräteklassen, die für USB erhältlich sind, so ist dies die gesamte Palette an Hardware, angefangen von Druckern, Kameras, Kartenleser und Massenspeicher (USB Memory Sticks) bis hin zu Modems, Netzwerk- und WLAN-Karten.

Bisher reichte es aus, bei einem PC die Disketten und CD-ROM Laufwerke zu sperren, um unberechtigten Datenaustausch über Speichermedien zu unterbinden. Mit USB Memory Sticks stehen sehr kleine (Schlüsselanhänger) und sehr große (über ein Gbyte Speicher) Speichermedien bereit, die sogar im laufenden Betrieb angesteckt und wieder entfernt werden können.

Hieraus ergeben sich folgende Risiken:

• Aktuelle BIOS Versionen unterstützen das Booten von USB Medien. Somit lassen sich die Schutzmechanismen des auf den PC installierten Betriebssystems leicht umgehen, wenn von einem Betriebssystem über USB gebootet wird, das unter der Kontrolle des Angreifers steht.
  
• Durch im laufenden Betrieb angesteckte USB Memory Sticks kann Schadsoftware eventuell unkontrolliert eingeführt werden, denn nicht alle Virenscanner prüfen auch USB Geräte automatisch.
  
• Durch die hohe Speicherkapazität und die hohe Geschwindigkeit ist es sehr einfach, eine große Menge eventuell sensibler oder personenbezogener Daten unberechtigt und unkontrollierbar außer Hause zu bringen.
  
• Auch das Anschließen von Netzwerkkarten, Bluetooth-Adaptern, Modems und WLAN-Karten über USB bietet einen einfachen Weg, vorhandene Firewalls und andere Restriktionen zu umgehen und unkontrollierte Verbindungen aufzubauen.
  
• Aufwändige Installationsprozeduren für Hard- und Software entfallen, da moderne Betriebssysteme die neu angeschlossenen Geräte sofort einbinden. Dadurch sinkt die Hemmschwelle, nicht freigegebene, mitunter sogar auch private Technik zu nutzen.
  
• Die bisher eingerichteten Nutzungsbeschränkungen für CD- und Floppy-Laufwerke sind deshalb nicht mehr ausreichend wirksam. Es müssen folglich Mechanismen gefunden werden, mit denen der Zugriff auf den USB auf genau die zugelassenen Geräte beschränkt werden kann.

Ein Überblick über die Möglichkeiten zur sicheren USB Konfiguration unter Windows und Linux findet sich in der Orientierungshilfe "Datensicherheit bei USB-Geräten", die von meiner Home-Page unter www.datenschutz-bayern.de/technik/orient/usb.html abgerufen werden kann.

22.3.2. RFID-Technologie

RFID steht für Radio Frequency Identification und ist eine Technologie, die durch Funkwellen eine kontaktlose automatische Identifikation von Gegenständen ermöglicht, die mit einem RFID-Etikett versehen sind.

Die Bauformen der RFID-Etiketten können verschiedenen Einsatzzwecken angepasst werden. Aufgrund ihrer geringen Größe können sie beispielsweise in Verpackungen, Chipkarten und vielen anderen Produkten und Alltagsgegenständen integriert werden. Hauptanwendungsgebiete sind zurzeit die Bereiche Industrieautomation, Zutrittssysteme, Tieridentifikation, Warenmanagement und elektronische Wegfahrsperren.

Warum bringen RFID-Etiketten Gefahren für den Datenschutz?

Ein RFID-Etikett an sich ist aus Datenschutzsicht nicht gefährlich. Solange es nicht in die Nähe eines Lesegerätes kommt, ist es vollkommen inaktiv. Besitzt ein Produkt ein RFID-Etikett und passiert es ein Lesegerät, so werden die Daten, die auf dem Etikett gespeichert sind, ausgelesen. Die Datenmenge auf einem RFID-Etikett kann von einem Bit bis hin zu mehreren Kilobytes gehen. Es gibt des Weiteren auch RFID-Etiketten, die einen kompletten Rechner beinhalten, sodass Lese-, Schreib- und Rechenoperationen bis hin zu kryptografischen Verfahren möglich sind. Diese intelligenten RFID-Etiketten sind zurzeit zwar noch sehr teuer, aber werden wie alle Neuerungen in der IT vermutlich sehr bald sehr billig werden.

Ein RFID-Etikett ist grundsätzlich anders zu würdigen als z.B. die bisher übliche einfache Produktgruppennummer in Form eines Barcodes. Ein Barcode wird etwa an einer Supermarktkasse mit Hilfe eines Barcode Scanners ausgelesen. Bei einem Barcode ist die Datenerhebung (also das Einlesen durch die Kassiererin) offen und für den Kunden erkennbar. Auch bei einem RFID System wird der Kunde davon ausgehen, dass an der Kasse ein Lesegerät steht. Da das Auslesen aber nicht mittels eines räumlich sehr begrenzten und exakt positionierten Gerätes funktioniert, sondern mit Funkwellen, kann der Kunde nicht feststellen, wo genau RFID-Etiketten ausgelesen werden. Schon das Regal kann, wenn es entsprechend ausgestattet ist, feststellen, welche Produkte entnommen werden. Natürlich ist dies aufwändig und wird nicht im ersten Schritt passieren. Zuerst werden die RFID-Etiketten zur Transportkontrolle und zur Lagerverwaltung usw. verwendet werden. Aber wenn dann alle Produkte damit ausgestattet sind und sich die Systeme in "einfachen" Umgebungen bewährt haben, wird man sie immer mehr einsetzen.

RFID-Etiketten sind ohne Berührung auslesbar. Betritt der Kunde ein Geschäft und führt bereits Waren mit RFID-Etiketten aus anderen Geschäften mit sich, so lassen sich auch deren RFID Informationen auslesen. Das heißt, jedes Geschäft kann in den Inhalt der Einkaufstaschen seiner Kunden sehen und diesen theoretisch auch automatisch speichern. Die Haltbarkeit von RFID-Etiketten ist zeitlich nicht begrenzt, selbst nach Jahren dürften sie lesbar sein, da sie keine eigene Energieversorgung etwa in Form von Batterien benötigen.

Noch deutlicher wird die potenzielle Gefahr für den Datenschutz, wenn man einmal nicht vom normalen Haushaltseinkauf ausgeht, sondern beispielsweise an gekaufte Medikamente denkt. An jedem Punkt im Umkreis von bis zu 20 Metern kann, wenn es mit RFID-Etiketten versehen ist, jedes Medikament in der Tasche eines Bürgers unbemerkt von jedem Lesegerät gelesen werden.

Werden, wie von der Europäischen Zentralbank im Moment für die größeren Geldscheine geplant, irgendwann einmal auch alle Geldscheine mit RFID-Etiketten versehen sein, so kann jeder auch feststellen, wie viel Geld dieser Bürger bei sich führt, inklusive der Nummern aller Geldscheine.

Solange nur Produkte mit RFID-Etiketten ausgestattet werden, kann man argumentieren, dass ein direkter Personenbezug schwierig bzw. in der Regel nicht vorhanden ist. Das Lesegerät erkennt nur, dass Medikament X an ihm vorbeigetragen wurde, nicht aber, wer dieses Medikament besitzt. Betrachtet man aber die Bestrebungen, auch Kreditkarten und Ausweispapiere mit RFID- Etiketten auszustatten, so ist ein Personenbezug nicht nur machbar, sondern oft nicht mehr zu verhindern. Eventuell protokolliert ein Lesegerät alle Daten der RFID-Etiketten, die an ihm vorbeikommen. Die Ausweisnummer, den Namen und die Anschrift aus dem RFID-Etikett des Personalausweises, alle Bankverbindungsdaten und Kreditkartennummern sowie alle Produkte und alles Bargeld, das eine Person bei sich führt. Und das eventuell völlig unbemerkt vom Eigentümer dieser Informationen und ohne dass er es einfach verhindern kann.

Nicht betrachtet in den bisherigen Beispielen sind mit einer Vielzahl von Lesegeräten verknüpfte, zentrale Datenbanken, die alle erfassten Daten sammeln, sodass damit für Personen sehr genaue Bewegungs- und Verhaltensprofile gespeichert werden könnten, deren Qualität weit über die potenziellen Bewegungsprofile etwa durch ein Mobiltelefon (das nur vom Netzbetreiber alleine protokolliert und im Vergleich zum RFID-Etikett vom Besitzer ausgeschaltet werden kann) hinausgehen.

Deshalb heben die Internationale Konferenz der Datenschutzbeauftragten und die Konferenz der Datenschutzbeauftragten des Bundes und der Länder in ihren Entschließungen die Notwendigkeit hervor, Datenschutzprinzipien zu berücksichtigen, wenn RFID-Etiketten verknüpft mit personenbezogenen Daten eingeführt werden sollen (s. Anlage 17). Alle Grundsätze des Datenschutzrechts müssen beim Design, der Einführung und der Verwendung von RFID Systemen berücksichtigt werden. Insbesondere

• soll jeder vor der Einführung von RFID-Etiketten, die mit personenbezogenen Daten verknüpfbar sind oder die zur Bildung von Konsumprofilen führen, zunächst Alternativen
  
  
  in Betracht ziehen, die das gleiche Ziel ohne die Erhebung von personenbezogenen Informationen oder die Bildung von Kundenprofilen erreichen;
  
• wenn personenbezogene Daten unverzichtbar sind, müssen diese offen und transparent erhoben werden;
  
• dürfen personenbezogene Daten nur für den speziellen Zweck verwendet werden, für den sie ursprünglich erhoben wurden und sie dürfen nur solange aufbewahrt werden, wie es zur Erreichung dieses Zwecks erforderlich ist und
  
• so weit RFID-Etiketten im Besitz von Personen sind, sollen diese die Möglichkeit zur Löschung der gespeicherten Daten oder zur Deaktivierung oder Zerstörung der Etiketten haben.

22.3.3. Trusted Computing

Der Begriff "Trusted Computing" soll hier als allgemeiner Oberbegriff verwendet werden für die Initiative von mehr als 130 Firmen, darunter die Firmen Microsoft, Intel, IBM, HP, AMD, Sony Corporation und Sun Microsystems, den PC-Einsatz vertrauenswürdiger zu machen. Trusted Computing (TC) war die erste Bezeichnung hierfür. In den Diskussionen taucht weiterhin die "Trusted Computer Platform Alliance" (TCPA) auf, die dann zur "Trusted Computing Group" (TCG) umbenannt wurde - einer Firma, die unter anderen von den oben genannten Unternehmen gegründet wurde. Die geplante Softwareumsetzung von TC in Windows Betriebssystemen wurde als "Palladium" bzw. mit neuem Namen "Next Generation Secure Computing Base" (NGSCB) für die geplante nächste Version ("Longhorn") angekündigt.

Trusted Computing Modul

In einem mit TC geschützten PC gibt es ein "Trusted Computing Modul" (TCM), dessen Funktionen das Vertrauen in die Sicherheit des PC stärken sollen. Unter anderem existieren Funktionen zur Verwaltung kryptografischer Schlüssel, zum sicheren Booten eines PC, zur Authentisierung, zur Protokollierung, zur Initialisierung und für weitere Managementaufgaben. Das TCM stellt dabei eine ausschließlich passive Komponente dar, die das Betriebssystem des PC unterstützt. Für die Nutzung dieser Funktionen sind ein spezielles BIOS und ein angepasstes Betriebssystem nötig. In einigen bereits verfügbaren Hardwarekonfigurationen wird das TCM in Form eines "Fritz-Chips" als eigener Chip auf dem Motherboard installiert, der unter anderem die privaten Schlüssel des Anwenders analog einer Signaturchipkarte vor der ungewollten Veröffentlichung schützen können soll. Bis jetzt nutzt kein zur Zeit verfügbares Betriebssystem den Fritz-Chip.

Funktionen

Mit Hilfe des TCM und einer entsprechenden Softwarekomponente ("Security Support Component" - SSC) im Betriebssystem sollen im Wesentlichen folgende Funktionen ermöglicht werden:

• Daten können so verschlüsselt werden, dass sie nur mit der aktuellen (sicheren) Systemkonfiguration gelesen werden können, d.h. z.B. nach einer Installation einer neuen (nicht zertifizierten) Betriebssystemkomponente kann auf die Daten nicht mehr zugegriffen werden.
  
• Es gibt einen durch die Hardware geschützten Speicherbereich, in dem z.B. kryptografische Schlüssel sicher gespeichert werden können. Auf diese kann dann nur mit zertifizierter Soft- und Hardware zugegriffen werden.
  
• Das System kann sich anderen Systemen als "vertrauenswürdig" beweisen. Beispielsweise kann ein Anzeigeprogramm für Filme damit dem digitalen Filmverleiher online sicherstellen, dass keine Zusatzkomponenten zur Umgehung des Copyrights auf den ausgeliehenen Film zugreifen können.
  
• Ein spezieller Zufallsgenerator zur Erzeugung sicherer kryptografischer Schlüssel ist vorhanden.
  
• Das TCM stellt eine manipulationssichere Echtzeituhr zur Verfügung, sodass sich Zeitstempel sicher prüfen lassen.

Externe Sicherheitsinstanzen

Mit Hilfe von TC lassen sich Transaktionen implementieren und etablieren, die Sicherheitsrichtlinien auch außerhalb des eigenen Einflussbereichs wirksam durchsetzen. Es ist denkbar, dass der Verfasser (Rechteinhaber) eines Dokuments festlegt, auf welchen fremden PCs dieses Dokument verarbeitet werden kann. Das heißt aber, dass das Lesen dieses Dokuments dann davon abhängt, ob die (aus der Sicht des Lesenden externe) Sicherheitsinstanz des Verfassers aktuell erreichbar ist, da der Verfasser auch die Möglichkeit hat, die früher einmal gewährten Rechte zu widerrufen. Auch Software kann so geschützt sein, dass sich eine Softwarekomponente nur dann starten lässt, wenn der PC im TC Modus läuft und der Softwarehersteller das Starten der Software auf diesem PC erlaubt und nicht zwischenzeitlich widerrufen hat.

TC und Datenschutz

Jede dieser Funktionen kann einen PC sicherer machen und damit aktiv zur Verbesserung des Datenschutzes und der Datensicherheit beitragen. Die Datenschutzbeauftragten des Bundes und der Länder begrüßen in der Entschließung "TCPA darf nicht zur Aushebelung des Datenschutzes missbraucht werden" der 65. Datenschutzkonferenz alle Aktivitäten, die der Verbesserung des Datenschutzes dienen und insbesondere zu einer manipulations- und missbrauchssicheren sowie transparenten IT-Infrastruktur führen (siehe Anlage 2).

Die Datenschutzbeauftragten halten es jedoch für unvertretbar, falls

• Anwenderinnen und Anwender nicht die alleinige Kontrolle über die Funktionen des eigenen Computers behalten,
  
• die Verfügbarkeit von TC-konformen Arbeitsplätzen und der darauf verarbeiteten Daten dadurch gefährdet wäre, dass zentrale, extern betriebene Sicherheitsinstanzen nicht verfügbar wären,
  
• andere Institutionen oder Personen sich vertrauliche Informationen von zentralen Servern beschaffen würden, ohne dass der Anwender dies bemerkt,
  
• die Nutzung von Servern oder PC davon abhängig gemacht würde, dass ein Zugang zum Internet geöffnet wird,
  
• der Zugang zum Internet (z.B. E-Mail) durch TC-Restriktionen behindert würde,
  
• der Umgang mit Dokumenten ausschließlich gemäß den Vorgaben einer externen Kontrollinstanz zulässig sein würde und somit eine sehr weit gehende Zensur ermöglicht wird,
  
• auf diese Weise der Zugriff auf Dokumente von Konkurrenzprodukten verhindert und somit auch die Verbreitung datenschutzfreundlicher Open-Source-Software eingeschränkt werden kann und
  
• Programmergänzungen (Updates) ohne vorherige Einwilligung im Einzelfall aufgespielt werden könnten.

Die Datenschutzbeauftragten des Bundes und der Länder fordern deshalb Hersteller von Informations- und Kommunikationstechnik auf, Hard- und Software so zu entwickeln und herzustellen, dass

• Anwenderinnen und Anwender die ausschließliche und vollständige Kontrolle über die von ihnen genutzte Informationstechnik haben, insbesondere dadurch, dass Zugriffe und Änderungen nur nach vorheriger Information und Einwilligung im Einzelfall erfolgen,
  
• alle zur Verfügung stehenden Sicherheitsfunktionen für Anwenderinnen und Anwender transparent sind und
  
• die Nutzung von Hard- und Software und der Zugriff auf Dokumente auch weiterhin möglich ist, ohne dass Dritte davon Kenntnis erhalten und Nutzungsprofile angelegt werden können.

Auf diese Weise können auch künftig die in den Datenschutzgesetzen des Bundes und der Länder geforderte Vertraulichkeit und Verfügbarkeit der zu verarbeitenden personenbezogenen Daten sichergestellt und die Transparenz bei der Verarbeitung dieser Daten Gewähr leistet werden.

22.3.4. Automatischer Software-Update (Windows XP)

Für alle zurzeit auf dem Markt befindlichen Betriebssysteme werden von den Herstellern oder Distributoren bei Bedarf Aktualisierungen angeboten, die beispielsweise Sicherheitsprobleme beheben oder neue Funktionalitäten anbieten. Aus der Sicht der Datensicherheit ist die zeitnahe Behebung von Sicherheitsproblemen unabdingbar.

Für derartige Aktualisierungen ("Updates") gibt es grundsätzlich drei Varianten:

• Die Updates werden vom Hersteller zur Verfügung gestellt und der Administrator muss sich darüber informieren, welche Updates für ihn relevant sind.
  
• Das Betriebssystem benachrichtigt den Anwender/Administrator über neue Updates und fragt, ob diese installiert werden sollen.
  
• Das Betriebssystem sucht automatisch nach Updates und installiert diese ohne Zustimmung des Anwenders oder Administrators (automatisches Software-Update).

Änderungen an automatisierten Verfahren zur Verarbeitung personenbezogener Daten oder an den zugrunde liegenden Betriebssystemen stellen jedoch Wartungstätigkeiten im datenschutzrechtlichen Sinn dar. Deshalb muss sichergestellt sein, dass nur den dazu ausdrücklich ermächtigten Personen die Installation derartiger Updates möglich sein darf. Insbesondere fehlt vielfach die Möglichkeit, dem Update-Vorgang ausdrücklich zuzustimmen. Die Daten verarbeitenden Stellen dürfen daher derartige automatische Software-Updates nicht nutzen, um Softwarekomponenten ohne separate Tests und formelle Freigabe auf Produktionssysteme einzuspielen.

Immer mehr Behörden setzten Windows XP ein oder planen darauf umzusteigen, weil zum Beispiel die bisher eingesetzte Version Windows NT4 nicht mehr vom Hersteller weitergepflegt wird. Windows XP bietet aber als Neuerung ein automatisches Software-Update an. Es ist hier anzuraten, das automatische Update abzuschalten (unter Systemeigenschaften / Automatische Updates) und nur nach vorherigen erfolgreichen Tests die Aktualisierungen einzuspielen. Bei einer größeren Anzahl von Rechnern empfiehlt es sich, alle Updates zentral zu verwalten (etwa über den von Microsoft erhältlichen Windows Update Services WUS) und auch hier Updates nur dann freizugeben, nachdem sie erfolgreich getestet worden sind.

22.4. Orientierungshilfen

Im Berichtszeitraum hat meine Geschäftsstelle alle Orientierungshilfen überarbeitet und auf einen aktuellen Stand gebracht. Neu erstellt wurden die Orientierungshilfen "Einsatz von Funktastaturen" und "Datensicherheit bei USB-Geräten". Vom Arbeitskreis Technik der Konferenz der Datenschutzbeauftragten des Bundes und der Länder wurden die Orientierungshilfe "Sicheres Löschen magnetischer Datenträger" und von einer Arbeitsgruppe der Konferenz der Datenschutzbeauftragten des Bundes und der Länder die Handreichung "Die virtuelle Poststelle im datenschutzgerechten Einsatz" erstellt.

Alle Dokumente können von meiner Home-Page unter www.datenschutz-bayern.de abgerufen werden.

• Novellierung des Bayerischen Polizeiaufgabengesetzes