In das Projekt HessenVoice wurde ich schon frühzeitig eingebunden. Ziel ist es, für die hessische Landesverwaltung datenschutzgerecht eine zukunftssichere, zentrale Telekommunikationsstruktur mit der Technik „Voice over IP“ aufzubauen. Diese erlaubt es, das Hessische Verwaltungsnetz (HessenNetz) neben der Datenkommunikation auch für die Sprachübertragung zu nutzen. Erste Teilprojekte wurden in den fünf Standorten erfolgreich realisiert. Bei einem zukünftig angedachten flächendeckenden Einsatz müssen aber weiterhin Datenschutzaspekte berücksichtigt werden, die eine Verschlüsselung erfordern können.
7.1.1
Sachstand
Bereits in meinem 34. Tätigkeitsbericht habe ich mich mit der Thematik der Sprachübertragung in Internetprotokoll basierten Netzen (Voice over IP, VoIP) beschäftigt.
Zum damaligen Zeitpunkt im Jahr 2005 wurde in der Landesverwaltung als Basis für die Einführung von VoIP eine Bestandsdatenerfassung zu den vorhandenen Telekommunikationsanlagen durchgeführt. Die Ergebnisse dieser Erhebung sind die Planungsgrundlagen für das heutige Projekt. Es ist langfristig vorgesehen, sukzessive die althergebrachten Telekommunikations-Anlagen abzulösen. Mit dem Projekt HessenVoice wird das Ziel verfolgt, den Dienststellen der Landesverwaltung über eine zentrale Telekommunikationsinfrastruktur Telefoniedienste bereitzustellen, diese zu standardisieren und zentral durch die HZD zu betreiben. HessenVoice nutzt hierfür die Technik Voice over IP (VoIP). Diese Technologie erlaubt es, das nach außen aufwendig abgeschottete, sichere Hessische Verwaltungsnetz neben der Datenkommunikation unter Wahrung der gebotenen Trennung auch für die Sprachübermittlung zu nutzen.
Nach ersten Pilotprojekten in den Finanzämtern Kassel, Nidda und Frankfurt werden zwei große Teilprojekte bis Ende 2009 realisiert.
7.1.1.1
Justiz- und Verwaltungszentrum
Im November 2009 wird in Wiesbaden von sechs Justiz-Dienststellen das neu erstellte Gebäude Justiz- und Verwaltungszentrum (JuVZ) bezogen. Die in diesem Gebäude vom Land Hessen für den Anteil Justizzentrum bereitgestellte Lösung basiert auf den im Projekt HessenVoice angebotenen Voice-Services.
Mit der VoIP-Technologie wurden im JuVZ die 840 Telefone über LAN angeschlossen und Kommunikationslösungen zur Verfügung gestellt, die über zentral für die Hessische Verwaltung implementierte Komponenten gewährleistet werden. Die betroffenen Dienststellen Arbeitsgericht, Verwaltungsgericht, Landgericht, Amtsgericht, Staatsanwaltschaften und Sozialgericht bleiben in der Verwaltung und Vor-Ort-Betreuung autark, jedoch werden Leistungen wie Amtszugang, Anschluss an das HessenNetz und Vermittlungsplatzfunktion gemeinsam genutzt. Beim JuVZ Wiesbaden kommt die neue Rufnummer 0611-32-61xxxx zum Einsatz. Die Rufnummer 32-xxxxxx ist als künftige Rufnummer aller Dienststellen der Hessischen Landesverwaltung in Wiesbaden vorgesehen.
7.1.1.2
Oberfinanzdirektion Frankfurt
Im Dezember 2009 zieht die Oberfinanzdirektion (OFD) Frankfurt am Main mit Sitz in der Adickesallee in den Gebäudekomplex OFD Main Triangel um. Dort bezieht die OFD das Forum und Etagen im Hochhaus des Gebäudekomplexes. 500 Anschlüsse werden hier in gleicher Weise wie im Justiz- und Verwaltungszentrum mit VoIP-Technologie realisiert.
7.1.2
Datenschutzrechtliche Bewertung
7.1.2.1
Allgemeines
Der HDSB wurde schon frühzeitig – im Jahr 2008 – in das Projekt HessenVoice einbezogen, um datenschutzrechtliche Belange sowohl in rechtlicher wie in technischer Sicht von Anfang an zu berücksichtigen. Dabei wurden im Berichtszeitraum im Wesentlichen Details der Vorabkontrolle zur Vorbereitung des Verfahrens nach § 34 Abs. 5 HDSG diskutiert.
Die gegenwärtige datenschutzrechtliche Bewertung stützt sich auf die vorgelegte Vorabkontrolle (Version 04.02 vom 18. November 2009), den Entwurf eines Verfahrensverzeichnisses (Stand 27. August 2009), den Entwurf des Revisionskonzeptes sowie die Ergebnisse der Gespräche mit Herrn Staatssekretär Westerfeld und den Mitarbeitern der Abteilung VII des HMDIS.
7.1.2.2
Vorabkontrolle und Verfahrensverzeichnis
Die Vorabkontrolle ist umfassend und beinhaltet folgende Punkte:
Neben vielen Detailfragen wie zur Netzstruktur, der Administration, der Verkehrslenkung oder einer unter Umständen notwendigen Speicherung von Verkehrsdaten zu Abrechnungszwecken wurde insbesondere geprüft, ob eine Verschlüsselung der Signalisierungs- bzw. der Sprachdaten bei den ersten Teilprojekten zwingend notwendig ist.
Für die zunächst selbständigen Projekte mit ihren begrenzten Netzstrukturen kann unter strengen Voraussetzungen auf eine Verschlüsselung verzichtet werden. Inwieweit es jedoch bei der Komplexität der zu erwartenden Gesamtstruktur gelingen kann, für HessenVoice unter Verzicht auf die Verschlüsselungsoptionen einen dauerhaft sicheren Betrieb zu gewährleisten, muss zukünftig geprüft werden. Um eine ausreichende Sicherheit jetzt zu erreichen, muss
7.1.2.3
Notwendige Konzepte
Der grundsätzliche Aufbau und die Zielsetzung des Revisionskonzeptes wurden mit mir abgestimmt. Der Entwurf stellt derzeit alle Möglichkeiten des Zugriffs und der Aktivitäten im Betrieb dar. Alle für die Revision relevanten Parameter sind wie die Revisionsprozesse insgesamt noch festzulegen. Den im vorangegangen Absatz genannten Kernforderungen für einen sicheren Betrieb ist bei der Ausgestaltung des Betriebs- bzw. Administrationskonzeptes in geeigneter Weise Rechnung zu tragen. Bis zum Start des Echtbetriebes der nächsten Teilprojekte müssen die relevanten Teile der Konzepte fertiggestellt sein.
7.1.2.4
Gespräche
In den Gesprächen wurden die Ergebnisse der Pilotprojekte erläutert und bewertet.
Der wesentliche offene Punkt bleibt, ob die Verschlüsselung der Gesprächs- und Signalisierungsdaten ggf. auch selektiv eingesetzt werden muss, um dem Schutzbedarf der Daten hinreichend Rechnung zu tragen. Ich halte die Option weiterhin für erforderlich. Sofern sie als Stand der Technik zur Verfügung steht und mit verhältnismäßigem Aufwand realisiert werden kann, ist sie einzusetzen. Dies entspricht auch der Entschließung der 70. Konferenz der Datenschutzbeauftragten des Bundes und der Länder vom 27. und 28. Oktober 2005 in Lübeck: „Telefonieren mit Internettechnologie (Voice over IP – VoIP)“; s. 34. Tätigkeitsbericht, Ziff. 10.9.
Bei der Einführung von HessenVoice wird vorerst im „Justizzentrum Wiesbaden“ und in der „OFD“ auf eine Verschlüsselung der entsprechenden Datenströme verzichtet. Bei allen anstehenden Beschaffungen bzw. Ausschreibungen von neuen Systemen muss aber darauf geachtet werden, dass der Einsatz der Verschlüsselungsoption zu einem späteren Zeitpunkt problemlos möglich ist.
7.1.3
Ausblick
Wenn die Realisierung in der beschriebenen Form erfolgt, und auch die Beteiligung des HDSB und damit die Berücksichtigung von Datenschutzgesichtspunkten weiterhin sichergestellt wird, kann das Projekt unter datenschutzrechtlichen Aspekten befürwortet werden.
Zurück zur Übersicht
Zurück zum Inhaltsverzeichnis des 38. Tätigkeitsbericht
USB-Sticks sind als Speichermedien weit verbreitet, um Daten zu transportieren. Sie werden zunehmend auch benutzt, um Programme und ganze Systemumgebungen mit sich zu führen und auf fremden Computern eine eigene, bekannte Arbeitsumgebung einstellen zu können. Diese Möglichkeit bietet eine Reihe sinnvoller Einsatzzwecke, die aber mit Anforderungen an die technische Ausgestaltung verbunden sind.
7.2.1
Der USB-Stick als PC-Ersatz
In der hessischen Landesverwaltung aber auch in Kommunen ergibt sich immer wieder der Wunsch oder die Notwendigkeit von Telearbeitsplätzen. Wünschenswert ist es, dass dazu Dienstgeräte zur Verfügung gestellt werden. Da oft zu wenig Geld zur Verfügung steht, wird über Lösungen nachgedacht, die kostengünstiger sind. In vielen Fällen wären private Rechner vorhanden, aber deren Nutzung weist aus Datenschutz- und Datensicherheitsgründen große Risiken auf. Als neuer Ansatz wird über bootfähige USB-Sticks oder Boot-CDs nachgedacht, die mit vertretbaren Kosten einen Privat-PC für die Dauer der Arbeit zu einer Art dienstlichen Rechner machen. Diesen Gedankengang möchte ich an mehreren Beispielen erläutern.
7.2.1.1
Die Idee
Damit außerhalb der Dienststelle dienstliche Daten problemlos verarbeitet werden können, müssen einige Rahmenbedingungen erfüllt werden.
Wenn ein privater PC genutzt wird, sind die Anforderungen nur schwer oder gar nicht umzusetzen. Hinsichtlich der Forderung, dass der Rechner dem Bediensteten während der Verarbeitung allein zur Verfügung steht, gibt es keinen Unterschied zu einem Dienstrechner. Im Regelfall kann aber unterstellt werden, dass später auch andere Personen damit arbeiten. Diese könnten auf gespeicherte Daten zugreifen. Man muss davon ausgehen, dass viele andere Programme installiert sind; diese könnten beabsichtigt oder ungewollt beispielsweise Schadprogramme wie Viren oder Trojaner sein. Damit akzeptable Bedingungen vorhanden sind, müsste der Mitarbeiter den eigenen PC so administrieren, dass Unbefugte weitgehend weder direkt noch indirekt auf die Daten zugreifen können. Dieser Zustand ist schon bei einer professionellen Administration schwer herstellbar. Umso seltener trifft es bei privaten PCs zu.
Der Gedanke ist nun, den Rechner durch Programme von einem Speichermedium zu starten („booten“), die der Arbeitgeber zur Verfügung stellt. Es sollen zwar der Hauptspeicher, die Tastatur, der Bildschirm und die Maus genutzt werden, aber auf der Festplatte vorhandene Programme wie das Betriebssystem sollen außen vor bleiben und der Plattenspeicher soll ebenfalls möglichst nicht angesprochen werden. Damit könnte ein privater PC für die Dauer der Arbeit bezüglich der Programme und Daten zu einem rein dienstlichen Rechner werden.
Während bei älteren Rechnern neben der Festplatte als Bootmedium Disketten oder CDs ausgewählt werden können, kann es bei neueren Rechnern auch ein USB-Stick sein. Wegen ihrer geringen Speicherkapazität sind Disketten aber praktisch nicht mehr in Gebrauch. CDs und DVDs sind als Bootmedium geeignet. Jedoch gibt es Probleme, wenn nachträglich Daten geändert oder gespeichert werden sollen. Hier hat ein USB-Stick Vorteile.
7.2.1.2
Der Telearbeitsplatz
Eine hessische Kommune hat für Telearbeitsplätze eine Grundstruktur auf Basis eines Terminalservers in Kombination mit einem bootfähigen USB-Stick gewählt. Dabei werden vom Telearbeitsplatz Tastatureingaben und die Mausbewegung an den Server übertragen, während zum Telearbeitsplatz Bildschirminhalte gesendet werden. Es findet keine Übertragung von Dateien statt. Nachdem sich der Mitarbeiter am Terminalserver angemeldet hat, kann er mit seinen Fachanwendungen wie im Büro arbeiten.
Für die Telearbeit bei dieser Kommune sollen lokal keine Dateien gespeichert werden, so dass die Funktion „Dateien auf den PC herunterladen“ auf dem Terminalserver ausgeschaltet ist.
Es bleiben noch folgende Anforderungen umzusetzen:
Nachdem der VPN-Tunnel aufgebaut ist, meldet sich der Mitarbeiter mit seiner Benutzerkennung und einem Passwort am Terminalserver an. Anschließend kann er wie gewohnt arbeiten. Durch diese Anmeldung und die vorgeschaltete Prüfung der Zertifikate ist der Benutzer sicher identifiziert.
Da die Softwareumgebung vom USB-Stick gebootet wird, können auf dem PC bereits vorhandene Schadprogramme weder das Zertifikat kopieren noch Passwörter mitschneiden. Da auch keine Dateien auf dem PC verbleiben, sind die Sicherheitsrisiken so weit reduziert, dass auch ein Privat-PC für die Telearbeit genutzt werden kann.
7.2.1.3
Erstellen sonderpädagogischer Gutachten am Privat-PC
Rund 60.000 Lehrer dürfen nach der neuen Rechtsverordnung (s.a. Kapitel 4.5.1) in Hessen personenbezogene Daten auf ihren privaten Rechnern verarbeiten. Die Verantwortung für die Verarbeitung der Daten verbleibt aber bei der Schule. Der Datensatz ist in Anlage 6 abschließend beschrieben (Der vollständige Datensatz ist unter den Materialien meiner neu erschienenen Broschüre „Datenschutz in Schulen“ abgedruckt; sie ist im Internet unter http://www.datenschutz.hessen.de/downloads/173 abrufbar). Hierbei handelt es sich zum einen um Daten mit normalem Schutzbedarf (Anlage 6, Ziff. 1 bis 13) wie z.B. Name, Geburtsname, Vorname etc.; zum anderen um Daten mit hohem Schutzbedarf (Anlage 6, Ziff. 14) wie medizinische und psychologische Informationen, die in den sog. sonderpädagogischen Gutachten benötigt werden.
Im häuslichen Umfeld des Lehrers sind je nach Schutzbedarf unterschiedliche Verfahrensweisen erforderlich.
Für die Verarbeitung der Schüler- und Elterndaten mit normalem Schutzbedarf habe ich mich mit dem HKM auf folgende Vorgehensweise verständigt:
Die Lehrer speichern die Daten auf einen normalen USB-Stick, der einen verschlüsselten Container beinhaltet. Auf der Homepage der staatlichen Schulämter wird eine Software zum Verschlüsseln mit Installationshilfe angeboten. Einzelheiten zu den Rahmendingungen sind auf meiner Homepage unter der Rubrik Fachthemen Schule im Artikel „Verarbeitung von Lehrer- und Schülerdaten auf den privaten Datenverarbeitungseinrichtungen der Lehrer“ beschrieben.
Für die sonderpädagogischen Gutachten reicht diese Vorgehensweise wegen der Sensitivität der Daten und der hohen Fallzahlen nicht aus. Denn Hessen ist in der Betreuung und Förderung von Schülern nach Aussage des HKM deutschlandweit führend. So wurden allein im letzten Jahr rund 20.000 Schüler betreut, die Zahl ist steigend.
Die Erstellung eines solchen Gutachtens erstreckt sich über einen längeren Zeitraum. Hier dürfen Informationen zur Anamnese des Schülers in seiner Familie, zur Vorgeschichte, zum Lernverhalten, zur sprachlichen und körperlichen Entwicklung, zum emotionalen und sozialen Verhalten und Weiteres verarbeitet werden. Leider stehen dienstliche Geräte aus Kostengründen in dem erforderlichen Umfang für die Lehrer nicht zur Verfügung. Um den Lehrern aber dennoch ein datenschutzrechtlich zulässiges Arbeiten zu Hause mit moderner Technik zu ermöglichen und gleichzeitig dem hohen Schutzbedarf der gespeicherten Informationen Rechnung zu tragen, habe ich mich mit der Thematik eines bootfähigen USB-Sticks beschäftigt.
Eine Lösung könnte idealerweise wie folgt aussehen:
Der USB-Stick ist mit einem bootfähigen Betriebssystem und einem verschlüsselten Container zur Speicherung der Gutachten während der Bearbeitung ausgestattet.
Der Zugriff auf den entschlüsselten Container ist nur nach dem Bootvorgang und einer Anmeldung an dem jetzt zur Verfügung stehenden System möglich. Das Gutachten kann nur vom zuständigen Lehrer auf diesem Wege angelegt und bearbeitet werden.
Nach der Fertigstellung, die über einen längeren Zeitraum erfolgen kann, ist das Gutachten nur in der Schule an einem dafür vorgesehenen Arbeitsplatz auszudrucken und danach zu löschen. Aus diesem Grund muss der USB-Stick über einen weiteren, direkt (ohne vom Stick zu booten) zugänglichen Speicherbereich verfügen. Das Gutachten, dass während der Bearbeitung entschlüsselt im Container liegt, muss nun jeweils schulspezifisch mit einem weiteren Schlüssel, dem öffentlichen Schlüssel der Schule verschlüsselt werden und in den allgemein zugänglichen Bereich, den Transferbereich, kopiert werden. Für den Transport von zu Hause in die Schule befindet sich nun das Gutachten verschlüsselt in dem Transferbereich. Da der private Schlüssel der Schule nicht bekannt ist, kann niemand drittes, auch der Lehrer nicht, die Datei entschlüsseln. Im Schulsekretariat wird die verschlüsselte Datei aus dem allgemein zugänglichen Bereich des USB-Sticks auf den dafür vorgesehenen Verwaltungsrechner übertragen und mit dem passenden privaten Schlüssel der Schule entschlüsselt. Danach ist das Gutachten nur noch auszudrucken und alle Informationen sind, wie in der Rechtsverordnung beschrieben, sowohl auf dem Stick als auch auf dem Rechner zu löschen.
7.2.1.4
Feuerwehr
Wie unter Ziff. 5.7.1 beschrieben, wird für Feuerwehren, die „Florix-Hessen“ nutzen, derzeit eine USB-Lösung mit einem portablen Browser angeboten. Diesen Ansatz betrachte ich als eine Übergangslösung. Sinnvollerweise sollten Dienst-PC beschafft werden. Kurz- und mittelfristig stehen hierfür aber wohl keine Mittel zur Verfügung, so dass ich auch in diesem Fall in einem entsprechend konfigurierten bootfähigen USB-Stick eine mögliche Alternative sehe.
7.2.2
Der USB-Stick als Speichermedium
In diesem Jahr hat mich die Landesärztekammer Hessen um eine Stellungnahme zu einem Produkt gebeten, das in einem Ärztenetz in Nordhessen eingesetzt werden sollte. Als Datenträger für medizinische Daten dient in diesem Fall ein USB-Stick, auf dem sich neben den verschlüsselt gespeicherten Daten auch Programme zur Verwaltung dieser Daten befinden. Der reguläre Zugriff auf die Daten wurde durch die auf dem USB-Stick vorhandenen Programme gesteuert, die für Notfälle den Zugriff auf einen Teil der Daten ermöglichen.
In der Stellungnahme habe ich zahlreiche rechtliche und technische Aspekte thematisiert. Sie differenziert u.a. zwischen dem Einsatz eines USB-Sticks auf Reisen und für den vorübergehenden Transport von Befunden. Die dauerhafte Speicherung einer Krankenakte auf einem USB-Stick war nicht Gegenstand meiner Stellungnahme.
Meine Stellungnahme habe ich gegenüber der Landesärztekammer abgegeben. Dort können ggf. Details erfragt werden.
Zurück zur Übersicht
Zurück zum Inhaltsverzeichnis des 38. Tätigkeitsbericht
Damit PKI-Funktionen sicher genutzt werden können, muss ihre jeweilige Verwendung in allen Anwendungen sachgerecht, transparent und eindeutig sein. Die PKI-Funktionen dürfen nicht inhaltlich vertauscht werden und es muss eine strikte Trennung der Funktionen gegeben sein. Der Hessische Datenschutzbeauftragte hatte sich in die Überarbeitung des Standards „COMMON-PKI“ zur Version 2 eingeschaltet, um entsprechende Verbesserungen zu erreichen.
Es ist für eine sichere und transparente Nutzung unverzichtbar, sowohl die jeweils richtige, also die inhaltlich-logisch zutreffende der drei Funktionen Authentisierung, Signatur und Verschlüsselung zu verwenden als auch diese Funktionen sauber auseinanderzuhalten. Ersteres geschieht auf der Anwendungsebene, Letzteres erfordert eine entsprechende technische Unterstützung. Allgemein verbindliche Regelungen werden mit Hilfe von Normen und Standards getroffen, spezielle für konkrete Verfahren oder Anwendungen in Sicherheitsleitlinien, sogenannten Policies.
7.3.1
Regelungen in Normen und Standards
Im Bereich Public-Key-Infrastrukturen relevante Standards sind der US-amerikanische RFC 5280, die deutsche COMMON-PKI, die in Englisch geschrieben ist und eine europäische bzw. internationale Geltung und Akzeptanz anstrebt, sowie der Telekommunikations-Standard X.509 der internationalen Fernmeldeunion ITU.
Auf dieser „unteren“, technischen Ebene finden wir für Authentisierung und elektronische Signatur eine identische technische Vorgehensweise, nämlich das Bilden eines Hashwertes und dessen anschließende Verschlüsselung mit dem privaten Authentisierungs- bzw. Signatur-Schlüssel. Das E-Government-Glossar des BSI E-Government-Handbuchs definiert:
|
Digitale Signatur
Sicherungsmechanismus für elektronische Daten, bei dem aus der Information mittels eines geheimen Schlüssels (und kryptografischer Verfahren) ein Wert erzeugt wird, der mithilfe eines zugehörigen öffentlichen Schlüssels verifiziert werden kann. |
Die digitale Signatur auf der technischen Ebene wird für verschiedene Funktionen auf der Anwendungsebene genutzt und erhält hierfür im Key Usage Feld des Schlüssel-Zertifikates unterschiedliche Einträge:
7.3.2
Beispiel Common-PKI Version 2
Unter den Aspekten des Daten- und des Verbraucherschutzes hat sich meine Mitarbeiterin an der Erarbeitung der COMMON-PKI Version 2 beteiligt, um hier eine strikte Funktionstrennung zu erreichen und irreführende Bezeichnungen zu ändern:
7.3.2.1
Bezeichnungen
7.3.2.1.1
Content Commitment statt Non Repudiation
Bei der elektronischen Signatur geht es – im Gegensatz zur Signatur von Zertifikaten oder Sperrlisten – immer um Dokumente:
Dem Vorschlag, dieses Feld in der Common PKI entsprechend umzubenennen, wurde gefolgt, zumal X.509 V3 diese Umbenennung schon vorgenommen hatte.
7.3.2.1.2
Authentication statt Digital Signature
Die Funktion „Authentisierung und Integritätsprüfung“ heißt in allen drei Standards „digitalSignature“. Diese Bezeichnung ist unter zwei Aspekten missverständlich:
Die in diesem Zusammenhang aufgestellte Behauptung, es handle sich um einen rein technischen Standard, alles andere müsse man jeweils auf der Anwendungsebene regeln, kann nicht befriedigen: Es handelt sich zwar um einen technischen Standard, dieser legt aber auch die Begriffe auf der Anwendungsebene fest. Gerade deshalb ist es notwendig, dass die Begriffe für Experten und für Bürgerinnen und Bürger klar, eindeutig und unmissverständlich sind.
7.3.2.2
Funktionstrennung
Auf die Ausführungen des Datenschutzes zur Funktionstrennung hin wurden viele, teilsweise recht ausführliche Kommentierungen in den Standard eingefügt, die die Gefahren und sogar rechtliche Konsequenzen konkret benennen. So wird darauf hingewiesen, dass den Nutzenden die Zustimmung zum Inhalt (content commitment) zugerechnet wird, wenn sowohl „contentCommitment“ als auch „digitalSignature“ im KeyUsage Feld des Zertifikats gesetzt sind. Die Nutzenden sind also gut beraten, wenn sie eine Mischung der Funktionen für ihre eigenen Schlüssel sowohl im beruflichen als auch im privaten Umfeld strikt ablehnen, damit sie sich nicht in einem Verfahren authentifizieren, bei dem der Hashwert mit dem eines später vorgelegten, ihnen unbekannten Dokumentes übereinstimmt. Die Nutzenden werden nachträglich kaum beweisen können, dass sie nicht ein Dokument signiert (bzw. technisch: seinen Hashwert verschlüsselt), sondern sich lediglich authentisiert haben. Da das Zertifikat aber sowohl Signatur als auch Authentisierung zulässt, wird ihnen im Zweifelsfall der Inhalt des Dokuments zugerechnet. Das bedeutet, dass sie die gleichen Rechtsfolgen tragen müssen, die sich ergeben würden, wenn sie das ausgedruckte Dokument unterschrieben hätten.
Die neuen Kommentierungen bleiben alle auf der Stufe der Empfehlungen (RECOMMENDED, SHOULD) stehen. Da diese Empfehlungen nicht von allen Herstellern umgesetzt werden, ist so aber eine Lösung dieses Problems nicht erreichbar.
Es muss stattdessen absehbar zu einer Verpflichtung (MANDATORY, MUST bzw. FORBIDDEN, MUST NOT) kommen. Dabei ist ein zweistufiges Vorgehen möglich:
7.3.3
Regelungen in Policies
Selbstverständlich kann man entsprechende Festlegungen auch in Policies treffen. Dies bleibt aber insofern immer eine Notlösung, als man damit keine übergreifende, also über die jeweils einzelne Anwendung hinausgehende Verbindlichkeit und Interoperabilität erreichen kann. Auch dann nicht, wenn für alle Anwendungen Policies zur Verfügung stünden. Vielmehr müssten Betroffene bei allen ihren Kommunikationsbeziehungen in die Zertifikate ihrer Partner schauen und die zugehörigen Policies aufmerksam lesen. Selbst dann wären die Verfahren immer noch weder sicher noch transparent und erst recht nicht benutzerfreundlich. Und auch mit umfangreichem Fachwissen und entsprechendem Aufwand wird ein Nutzender nicht zuverlässig feststellen können, ob eine strikte Funktionstrennung gegeben ist. Denn es gibt inzwischen Chipkarten, bei denen zu einem Schlüsselpaar jeweils bis zu drei verschiedene Zertifikate gespeichert werden können; also beispielsweise eines zur Authentisierung, eines für die elektronische Signatur und eines zur Verschlüsselung. Damit wäre das evtl. im Kontext mitgelieferte bzw. das geprüfte Zertifikat bezüglich der Funktion zwar eindeutig, eine Funktionstrennung aber dennoch nicht gegeben und ein Missbrauch zu Lasten selbst von IT-Spezialisten weiterhin möglich. Hier ist grundsätzlich zu fragen bzw. festzulegen, wie die PKI-Software mit diesen neuen Gegebenheiten umgeht und umgehen soll.
Transparenz und Sicherheit auf der Anwendungsebene können für die Betroffenen mit automatisiert prüfbaren Policies für Web-Anwendungen wenigstens teilweise erreicht werden. Dies ist eine Forderung der Datenschutzbeauftragten, beispielsweise im Rahmen der Entwicklung des Transport-Protokolls OSCI Transport 2, das im Bereich der öffentlichen Verwaltung eingesetzt werden soll. Damit könnten zukünftig sowohl Nutzende in ihrem Browser als auch Verfahren wie z.B. Web-Anwendungen festlegen, was sie von ihrem Kommunikationspartner bzw. (Web)Service verlangen. Abweichungen könnten dann angezeigt und die Verarbeitung nur mit Zustimmung der Nutzenden fortgesetzt werden.
7.3.4
Positive Ansätze
Die Forderung des Datenschutzes nach strikter Funktionstrennung wurde für OSCI-Transport 2 bereits in die „Funktionale[n] Anforderungen und Entwurfsziele“ aufgenommen. Initiiert wurde dies von meiner Mitarbeiterin in einer gemeinsamen Arbeitsgruppe des Arbeitskreises Technik der Konferenz der Datenschutzbeauftragten des Bundes und der Länder mit den Entwicklern von OSCI Transport.
7.3.5
Weiterer Handlungsbedarf
Wichtig ist eine klare Regelung auf der Ebene der Normen und Standards. Die Verwendung eindeutiger, unmissverständlicher Begriffe und die saubere Trennung der Funktionen sind für die Transparenz und Sicherheit der Verfahren und die Nutzbarkeit der Authentisierungs- und der Signaturfunktion unabdingbare Voraussetzung.
Diese Anforderungen sollten auch bei den im Aktionsplan (s. Ziff. 7.4) genannten Maßnahmen vorrangig umgesetzt werden. Dies gilt insbesondere für den geplanten europäischen Signaturstandard.
Zurück zur Übersicht
Zurück zum Inhaltsverzeichnis des 38. Tätigkeitsbericht
Der „Aktionsplan für elektronische Signaturen und die elektronische Identifizierung zur Förderung grenzübergreifender öffentlicher Dienste im Binnenmarkt“ führt neben der qualifizierten elektronischen Signatur als weiteren Begriff die „auf einem qualifizierten Zertifikat beruhende fortgeschrittene elektronische Signatur“ neu ein. Diese soll offenbar EU-weit als Alternative zur qualifizierten Signatur verwendet werden. Da dieses Vorgehen problematisch ist, wird ein Vorschlag für eine sinnvolle Alternative aufgezeigt.
7.4.1
Ein neuer Signaturbegriff: AES-QC
In dem Aktionsplan für elektronische Signaturen und die elektronische Identifizierung zur Förderung grenzübergreifender öffentlicher Dienste im Binnenmarkt werden zwei Signaturbegriffe definiert und betrachtet:
7.4.2
Rechtlicher Unterschied
Nach deutschem Recht (§ 126a BGB, § 3a Abs. 2 VwVfG) kann nur die qualifizierte elektronische Signatur die manuelle Unterschrift und deren Rechtsverbindlichkeit ersetzen. Für den Bereich der EU ist in Artikel 5 Abs. 1 EU-SRL eine entsprechende Regelung getroffen und weiter festgelegt, dass die QES als Beweismittel in Gerichtsverfahren zugelassen sind.
Die AES-QC kann also, da sie nicht mit einer sicheren Signaturerstellungseinheit erstellt wird, weder nach deutschen noch nach europäischem Recht die Schriftform ersetzen.
Artikel 6 EU-SRL regelt die Haftung eines Zertifizierungsdiensteanbieters (ZDA), „der ein Zertifikat als qualifiziertes Zertifikat öffentlich ausstellt oder für ein derartiges Zertifikat öffentlich einsteht“ dafür,
Diese Haftungsregelung gilt gleichermaßen für AES-QC und QES. Streitigkeiten werden aber selten die korrekte Ausstellung oder die Registrierung eines Widerrufs des Zertifikats betreffen. In der Mehrzahl der Fälle wird die oder der Signierende nach der Ausstellung des Zertifikats bestreiten, das konkrete Dokument signiert zu haben. Dies geschieht unabhängig davon, ob die Signaturumgebung oder der Umgang der Signierenden mit ihren Signaturmitteln den Sicherheits-Anforderungen entspricht oder nicht.
In all diesen Fällen hilft die Haftungsregelung dem Empfangenden nicht. Er wird im Rechtsstreit kaum Gegenbeweise zu Aussagen des oder der Signierenden führen können. Einzig wenn das Dokument mit einer qualifizierten elektronischen Signatur nach deutschem Recht versehen ist, hilft den Empfangenden im Rechtsstreit die Beweislastumkehr. Der Absendende muss dann nachweisen, dass er das Dokument nicht signiert hat: Das wird ihm kaum gelingen.
7.4.3
Prüfbarkeit verschiedener Signatur-Qualitäten
Technisch ist außerdem festzustellen, dass es kein Verfahren gibt, mit dem geprüft und festgestellt werden kann, ob eine elektronische Signatur nur „einfach“ ist oder ob sie die vier zusätzlichen Anforderungen an eine fortgeschrittene elektronische Signatur erfüllt. Nach Art. 2 Nr. 2 EU-SRL und § 2 Nr. 2 SigG ist eine elektronische Signatur nur fortgeschritten, wenn sie
Die Verwendung einer sicheren Signaturerstellungseinheit kann außerdem von der Stelle, die das Zertifikat herausgibt, problemlos bestätigt werden. Hierfür gibt es technisch mindestens zwei verschiedene Möglichkeiten:
Solche Signaturen können u.a. von der Verwaltungs-PKI des Bundes und den darunterliegenden Zertifizierungsinstanzen (CAs, Certification Authorities), auch der teilnehmenden Bundesländer, ausgegeben werden. Die Hessen-PKI nutzt diese Möglichkeit bereits. Diese Signaturen entsprechen der höchsten Qualitätsstufe (Stufe 3) der in Entwicklung befindlichen neuen Policy der Verwaltungs-PKI des Bundesamtes für Sicherheit in der Informationstechnik (BSI) und dies wäre damit für Zertifikate, die ab 2010 nach dieser Policy herausgegeben werden sollen, auch automatisiert nachprüfbar.
*= wenn Herausgeber Schlüssel-Speicherung auf SSCD bestätigt
Abbildung 1: Funktionsumfang und Prüfbarkeit der verschiedenen fortgeschrittenen Signaturarten
7.4.4
Prüfung von Signaturen an Dokumenten
Deutschland prüft qualifiziert signierte Dokumente gemäß § 2 Nr. 3a) SigG auf den Zeitpunkt der Erstellung und weicht damit – von der EU genehmigt – von der Empfehlung in Anhang IV der EU-SRL ab, um eine wichtige Analogie zur manuellen Unterschrift auf die elektronische Signatur zu übertragen: dass nämlich die Unterschrift ab dem Zeitpunkt der Unterzeichnung unbefristet gilt.
Sinnvoll ist dies für alle Dokumentsignaturen, unabhängig von ihrer Qualität, also gleichgültig ob sie qualifiziert, fortgeschritten oder einfach sind. Das ist derzeit bei der Prüfung fortgeschrittener und einfacher Signaturen auch in Deutschland nicht der Fall: Hier wird auf den Zeitpunkt der Prüfung geprüft, was spätestens beim Ablauf des Signaturzertifikates, wegen des Schalenmodells (s. 36. Tätigkeitsbericht, Ziff. 8.1.1.2) bei Ungültigkeit eines der ausstellenden Zertifikate evtl. auch schon früher, zum Prüfergebnis „ungültig“ führt.
Für die Verwaltungs-PKI des Bundes, unter der auch die Hessen-PKI als eigene CA betrieben wird, ist eine entsprechende Änderung – Prüfung der Gültigkeit von Signaturen auf den Zeitpunkt der Erstellung – für die nächste Fassung der Policy, die 2010 in Kraft treten soll, vorgesehen. Hersteller von Komponenten zur Signaturprüfung sind gut beraten, ihre Verfahren so bald wie möglich auf diese Anforderung anzupassen. Sie ist keineswegs neu. In § 15 Abs. 2 Nr. 2 b der Signaturverordnung (SigV) ist die Formulierung schon immer enthalten:
|
§ 15 Absatz 2 Nr. 2 b SigV:
Signaturanwendungskomponenten ... müssen gewährleisten, dass |
7.4.5
Nationale Interessen koordinieren und einbringen
In Deutschland fehlt bisher eine offene nationale Diskussion zwischen allen Betroffenen und Interessierten. Auch eine Koordination und Vertretung der deutschen Interessen im Rahmen des Aktionsplanes erscheint dringend erforderlich. Dieser Plan wird auch Konsequenzen für die Ausgestaltung des Einheitlichen Ansprechpartners im Rahmen der EU-Dienstleistungsrichtlinie haben.
Für den geplanten europäischen Signaturstandard ist eine engagierte, qualifizierte und koordinierte Mitarbeit von deutscher Seite dringend erforderlich. Insbesondere vor dem Hintergrund, dass inzwischen auch andere europäische Staaten die Intention der abweichenden deutschen Regelungen nachvollziehen können und gutheißen.
Die Aktivitäten sollten den Inhalt der Ziffern 7.4.2 und 7.4.3 ebenso umfassen wie das zur Verwendung eindeutiger, unmissverständlicher Begriffe und der sauberen Trennung der Funktionen auf der Ebene von Normen und Standards unter Ziff. 7.3 Gesagte.
Der Hessische Datenschutzbeauftragte ist im Rahmen seiner Möglichkeiten gerne zur Unterstützung und Mitarbeit bereit. Die Koordination sollte von einer geeigneten Stelle des Bundes wie z.B. dem Beauftragten der Bundesregierung für Informationstechnik oder dem Bundeswirtschaftsministerium übernommen werden und alle entsprechenden betroffenen und interessierten Stellen beim Bund und in den Bundesländern einbeziehen.
Zurück zur Übersicht
Zurück zum Inhaltsverzeichnis des 38. Tätigkeitsbericht
In Rahmen meiner Prüfung und Beratung werden mir immer wieder Zertifizierungen auf der Basis von Normen und Standards vorgelegt. Um Missverständnisse bei der Beurteilung der Aussage eines Zertifikates zu vermeiden ist es wichtig, Gegenstand und Ziel der Zertifizierung zu berücksichtigen. Es ist ein großer Unterschied, ob das Management der IT-Sicherheit einer Institution oder eines abgegrenzten Teiles einer Institution zertifiziert wird, oder die in einer konkreten Hard- oder Software implementierten Sicherheitsmaßnahmen.
7.5.1
Zertifizierung des Managements der IT-Sicherheit
7.5.1.1
Gegenstand einer ISO 27001-Zertifizierung auf der Basis von IT-Grundschutz
Gegenstand einer ISO 27001-Zertifizierung ist das Management der IT-Sicherheit.
Die internationale Norm ISO 27001 spezifiziert die Anforderungen für Herstellung, Einführung, Betrieb, Überwachung, Wartung und Verbesserung eines dokumentierten Informationssicherheits-Managementsystems unter Berücksichtigung der Risiken innerhalb der gesamten Organisation. Die Norm wurde auch als DIN-Norm veröffentlicht. Sie spezifiziert Anforderungen für die Implementierung von geeigneten Sicherheitsmechanismen, welche an die Gegebenheiten der einzelnen Organisationen adaptiert werden sollen. Die ISO 27001 wurde entworfen, um die Auswahl geeigneter Sicherheitsmechanismen zum Schutze sämtlicher Unternehmenswerte (Assets) in der Wertschöpfungskette sicherzustellen.
Der Zusatz „auf der Basis von IT-Grundschutz“ bedeutet, dass die erforderlichen Standard-Sicherheitsmaßnahmen, die gegen die verschiedenen Gefährdungen getroffen werden, aus den umfangreichen Grundschutzkatalogen des BSI zusammengestellt und umgesetzt werden.
7.5.1.2
Zertifizierungsverfahren und Bedeutung
Voraussetzung für die Vergabe dieses Zertifikates ist eine Überprüfung durch einen vom BSI zertifizierten ISO 27001-Grundschutz-Auditor. Zu dessen Aufgaben gehören eine Sichtung der von der Institution erstellten Referenzdokumente, die Durchführung einer Vor-Ort-Prüfung und die Erstellung eines Audit-Reports. Die Zertifizierungsstelle BSI stellt aufgrund des Audit-Reports fest, ob die notwendigen Sicherheitsmaßnahmen umgesetzt sind, erteilt im positiven Falle ein Zertifikat und veröffentlicht es.
In den Grundschutzkatalogen gibt es fünf verschiedene Schichten: die Bausteingruppen „Übergeordnete Aspekte“, „Infrastruktur“, „IT-Systeme“, „Netze“ und „Anwendungen“. Für die Prüfung wird aus jeder dieser fünf Schichten jeweils ein Baustein nach dem Zufallsprinzip ausgewählt. Darüber hinaus wählt der Auditor gezielt einige Bausteine aus und nimmt ggf. Stichproben aus der Ergänzenden Risikoanalyse.
Unter dem Begriff „Anwendung“ werden beim IT-Grundschutz, und folglich auch bei der ISO 27001-Zertifizierung auf der Basis von IT-Grundschutz, nicht – wie sonst üblich – einzelne konkrete Anwendungsprogramme oder Verfahren verstanden und betrachtet, sondern die Schicht „Anwendungen“ enthält Bausteine, die bestimmte Dienste oder Funktionen bereitstellen, wie z.B. Webserver, Datenbanken, Mobile Datenträger, Allgemeiner Verzeichnisdienst, Telearbeit oder Datenträgeraustausch. Für jede dieser „Anwendungen“, wie im Übrigen auch für alle Bausteine der anderen Schichten, sind in den Grundschutzkatalogen die typischen Gefährdungslagen dargestellt und Maßnahmeempfehlungen gegeben, die für die Zertifizierung umgesetzt sein müssen.
Die Bedeutung des Verfahrens ergibt sich daraus, dass bei ISO 27001 die Geschäftsprozesse dominieren und nicht die IT-Sicherheit. Das Ergebnis der Zertifizierung ist die Bestätigung, dass das Management der Informationssicherheit den Anforderungen genügt im Sinne des sog. PDCA-Verfahrens, einem ständigen Kreislauf von Plan-Do-Check-Act (Plane – Setze um – Prüfe – Reagiere auf Abweichungen). Deshalb wird die Zertifizierung jährlich mit den inzwischen erfolgten Änderungen aktualisiert und nach Ablauf von drei Jahren wieder komplett neu durchgeführt.
Voraussetzung für eine solche Zertifizierung ist u.a., dass aktuelle Dokumentationen, Konzepte und Sicherheitsrichtlinien vorliegen, dass Änderungen regelmäßig eingearbeitet werden, dass Rollenkonzepte, Aufgabenverteilungen, Vertretungsregelungen und Notfallpläne umgesetzt sind und regelmäßig Schulungen der Mitarbeiter stattfinden. Besonders wichtig ist eine klare persönliche Verantwortung für die verbleibenden Restrisiken.
7.5.2
Zertifizierung der IT-Sicherheitseigenschaften von Software oder Systemen
7.5.2.1
Common Criteria und Schutzprofile
Die Common Criteria (CC, Gemeinsame Kriterien) sind eine mehrteilige Norm, die als Grundlage für die Prüfung und Bewertung der Sicherheitseigenschaften von Produkten und Systemen der Informationstechnik (IT) dient. Die aktuelle Version CC 3.1 ist bei der Internationalen Standardisierungsorganisation (ISO) zur Standardisierung eingereicht und löst die für Zertifizierungen nicht mehr aktuelle Version CC 2.3 ab, die als ISO/IEC 15408:2005 zum internationalen Standard wurde.
Die CC schaffen Vergleichbarkeit bezüglich der Ergebnisse unabhängiger Prüfungen und Bewertungen der Sicherheit des sog. Evaluationsgegenstandes (EVG). Sie dienen als Richtschnur für die Entwicklung von Produkten oder Systemen mit IT-Sicherheitsfunktionen sowie bei der Beschaffung von handelsüblichen Produkten oder Systemen mit solchen Funktionen.
Die CC eignen sich ferner zur Spezifikation von Sicherheitsvorgaben. Für grundsätzliche Anforderungen, die an die Sicherheit bestimmter Arten von Produkten gestellt werden und die in Ausschreibungen gefordert und von Herstellern umgesetzt werden sollen, können auch sog. Schutzprofile (PP, Protection Profiles) auf der Basis der CC erstellt werden.
|
Ein PP definiert eine implementierungsunabhängige Menge von IT-Sicherheitsanforderungen an eine Kategorie von EVG [Evaluationsgegenständen]. Solche EVG sollen weit verbreitete Bedürfnisse von Anwendern nach IT-Sicherheit befriedigen. Anwender können daher durch Erstellung eines PP oder Verweis auf ein solches ihre IT-Sicherheitsbedürfnisse ausdrücken, ohne Bezug auf einen konkreten EVG zu nehmen. (Common Criteria Teil I, Anhang B) |
7.5.2.2
Gegenstand der Zertifizierung nach den CC
Die CC gelten für in Hardware, Firmware oder Software implementierte Sicherheitsmaßnahmen.
Die CC befassen sich mit dem Schutz von Informationen vor nicht autorisierter Preisgabe, Modifizierung oder Zugangsverlust. Sie können aber auch auf andere Aspekte von IT-Sicherheit angewendet werden, die nicht unter diese Schutzkategorien der Vertraulichkeit, Integrität oder Verfügbarkeit fallen. Die CC gelten aber nicht für die Bewertung inhaltlicher Qualitäten von kryptografischen Algorithmen. Wenn diese erforderlich ist, muss das Evaluationsschema eine solche Bewertung explizit vorsehen.
7.5.2.3
Zertifizierungsverfahren und Bedeutung
In Deutschland ist das BSI für die Zertifizierung nach den CC zuständig. Von ihm zugelassene Evaluatoren verwenden die in den CC enthaltenen Kriterien, um die Übereinstimmung eines EVG mit den Sicherheitsanforderungen zu beurteilen. Das BSI überprüft das von dem Evaluator erstellte Gutachten und zertifiziert ggf. den EVG.
Die Bedeutung der CC reicht weit über Deutschland hinaus: Es gibt derzeit weltweit 13 Länder, die mit einer eigenen Zertifizierungsstelle Produkte nach den CC zertifizieren, und zwölf weitere, die solche Zertifikate nutzen. Ferner gibt es ein Abkommen, mit dem diese 25 Länder ihre Zertifizierungen nach den CC gegenseitig anerkennen. Eine Zertifizierung nach den CC durch eines der Länder gilt damit auch in den anderen, ohne dass das Verfahren dort jeweils neu durchlaufen wird.
7.5.3
Beispiel ELSTER
Für die Abgabe von Steuer-Voranmeldungen und -Erklärungen wird am ELSTER-Online-Portal nach wie vor ein Authentisierungsverfahren anstelle einer qualifizierten elektronischen Signatur als Äquivalent zur eigenhändigen Unterschrift im manuellen Verfahren genutzt. Da das konkret eingesetzte Verfahren in einigen Punkten die Mechanismenstärke „maximal niedrig“ hat, handelt es sich auch nicht um ein „starkes“ Authentisierungsverfahren. Denn die Stärke eines Mechanismus richtet sich nach derjenigen der schwächsten Komponente (Minimum-Prinzip). Dies ist unmittelbar einleuchtend, weil Angreifer natürlich immer an den Schwachstellen angreifen.
Darüber hinaus authentisiert das Verfahren nicht die Steuerpflichtigen, die die Steuerklärung oder -voranmeldung abgeben müssen, sondern lediglich die Person, die die Erklärung mit ELSTER abschickt. Das kann eine beliebige andere Person sein.
Neuerdings argumentiert die Steuerverwaltung, dass „die ELSTER-Anwendungen (inkl. RA-Dienst), Systeme, Räume und Sicherheitsmanagementprozesse für ihre Clearingstellen nach ISO 27001 auf der Basis der Grundschutzkataloge zertifiziert“ seien und „erklärtermaßen auch dem hohen bis sehr hohen Schutzbedarf“ genügten.
Dies ist in mehrfacher Hinsicht irreführend:
Zunächst einmal bedeutet eine ISO 27001-Zertifizierung nicht, dass das Verfahren ELSTER als solches oder einzelne seiner Komponenten geprüft und zertifiziert wurden, sondern, wie unter Ziff. 7.5.1.1 dargelegt wurde, dass das IT-Sicherheitsmanagement mit seinen fünf Schichten, die als Bausteine auch Systeme und Räume umfassen, geprüft wurde.
Eine ISO 27001-Zertifizierung auf der Basis von IT-Grundschutz besagt, dass das IT-Sicherheitsmanagement-Verfahren eingerichtet ist und dass der IT-Grundschutz – soweit das vom Auditor stichprobenartig geprüft wurde – umgesetzt ist. Selbst wenn darüber hinausgehende, zusätzlich erforderliche Risikoanalysen und deren Umsetzung in die Prüfung mit einbezogen wurden, wird weder attestiert, dass das IT-Sicherheitsmanagement noch dass die ELSTER-Anwendungssoftware oder Teile von ihr „erklärtermaßen auch dem hohen bis sehr hohen Schutzbedarf“ genügen. Der Auditor hat bezüglich des Schutzbedarfs lediglich geprüft, ob die von ELSTER vorgelegte Definition der Schutzbedarfskategorien plausibel ist.
Eine Aussage darüber, ob oder dass die ELSTER-Anwendungssoftware oder Teile von ihr dem hohen bis sehr hohen Schutzbedarf genügen, kann ausschließlich mit einer Zertifizierung nach den CC getroffen werden. Auch die unterschiedlichen Meinungen zur Qualität des Verfahrens ließen sich mit einer Zertifizierung des Verfahrens und seiner Sicherheitseigenschaften nach den CC zuverlässig und eindeutig klären. Dabei würden die getroffenen Maßnahmen mit den Sicherheitsanforderungen verglichen, und insbesondere festgestellt, ob sie überhaupt zielführend sind.
Da die CC keine Bewertung der Qualität der kryptografischen Algorithmen und Parameter vornehmen, bietet sich als Alternative der Algorithmenkatalog gemäß der Signaturverordnung an. Dieser Katalog wird vom BSI jährlich nach Beratung mit Experten fortgeschrieben. Die Anforderungen an die Algorithmen und Parameter entsprechen bei ELSTER nicht dem Algorithmenkatalog. Für die Steuerkontoabfrage ist das unter Datenschutzaspekten nicht akzeptabel. Für die anderen ELSTER-Anwendungen sind klare Übergangsfristen wünschenswert.
Für ein Webportal im Internet, das allen Bürgern zur Verfügung steht, ist eine Zertifizierung von ELSTER nach CC als vertrauensbildende Maßnahme sinnvoll und wünschenswert. Spätestens dann, wenn die Bürger zur Nutzung des Verfahrens verpflichtet werden sollen, ist sie meiner Meinung nach als Nachweis der Sicherheit des Verfahrens erforderlich.
Zurück zur Übersicht
Zurück zum Inhaltsverzeichnis des 38. Tätigkeitsbericht
Mit aktuellen Orientierungshilfen gibt der Arbeitskreis „Technische und organisatorische Datenschutzfragen“ der Konferenz der Datenschutzbeauftragten des Bundes und der Länder (AK-Technik) immer wieder Handreichungen zu technischen Fragestellungen heraus. In diesem Jahr wurden drei Themen aufgegriffen.
Der AK-Technik bereitet aktuelle datenschutzrelevante technische Fragestellungen in Orientierungshilfen auf. Mit den Orientierungshilfen leistet er einen Beitrag zum datenschutzgerechten Einsatz von IT-Technik. Dieses Jahr wurde die Orientierungshilfe „Protokollierung“ neugefasst und die Orientierungshilfen „Datenschutz und Datensicherheit in Projekten: Projekt- und Produktivbetrieb“ sowie „Biometrische Authentisierung – Möglichkeiten und Grenzen“ erstmalig veröffentlicht.
Die Orientierungshilfe „Protokollierung“ aus dem Jahr 1995 wurde durch eine Neufassung ersetzt. Die generellen Gesichtspunkte aus der alten Orientierungshilfe sind noch gültig, aber der Bezug zur heute verfügbaren Technik war nicht mehr ohne Weiteres herstellbar. Es war auch nicht beschrieben, wie die Anforderungen bei der heute verfügbaren Technik umgesetzt werden können. Vor diesem Hintergrund wurde die Orientierungshilfe komplett überarbeitet. Sie geht nun auf den Zweck und die Anforderungen an eine Protokollierung ein, stellt Arten von Protokolldaten dar, behandelt die Qualität der Protokolldaten und erläutert Aspekte bei der Implementierung. Der Text ist in diesem Tätigkeitsbericht im Anhang unter Ziff. 10.1 zu finden.
Die neue Orientierungshilfe „Datenschutz und Datensicherheit in Projekten: Projekt- und Produktivbetrieb“ geht besonders auf die Frage ein, ob und wann Echtdaten zu Testzwecken genutzt werden dürfen. Sie beschreibt die verschiedenen Ausprägungen eines Tests im Projektbetrieb und legt die Unterschiede zwischen Pilot- und Regelbetrieb dar. Die Orientierungshilfe finden Sie ebenfalls im Anhang unter Ziff. 10.2.
Die Anmeldung an einen Rechner, die sog. Authentisierung, geschieht meist noch dergestalt, dass ein Benutzer seine Kennung und sein Passwort eingibt. Da die Kennung und das Passwort auch durch andere Personen eingegeben werden können, wird oft als wesentlich bessere Technik die biometrische Authentisierung betrachtet. Hierbei wird der Benutzer an einem biometrischen Merkmal erkannt. In der Orientierungshilfe „Biometrische Authentisierung – Möglichkeiten und Grenzen“ werden Grundlagen der Biometrie beschrieben, aber eben auch die Möglichkeiten und die – heutigen – Grenzen dieser Technik. Sie finden die Orientierungshilfe unter Ziff. 10.3.
Zurück zur Übersicht
Zurück zum Inhaltsverzeichnis des 38. Tätigkeitsbericht