JobCard: Argumente
Aus Transparenz
Zurück zu: ->JobCard: Grundlegende Einführung ->Job-Card
Das Job-Card-/Elena-Verfahren berührt so unterschiedliche Aspekte wie Effizienzsteigerungen und Kostenersparnisse im Verwaltungshandeln, die gesamtwirtschaftliche Entwicklung und das Recht oder informationelle Selbstbestimmung. In all diesen Bereichen lassen sich Argumente sowohl für als auch gegen das Verfahren anführen.
Inhaltsverzeichnis |
Monetäre Effekte und mehr Gerechtigkeit im Verwaltungshandeln
Von Beginn an bestand das Ziel der Einführung des JobCard- bzw. Elena-Verfahrens darin, Kosteneinsparungen im Verwaltungshandeln zu erreichen. Durch die Ablösung der etablierten papiergebundenen Verfahren und der sich daraus ergebenden Medienbrüche sollten sowohl auf öffentlicher Seite wie auch für die Arbeitgeber Personalkosten gesenkt und damit die Effizienz gesteigert werden. Auch wenn für Einführung und Verwendung des JobCard-/Elena-Verfahren Kosten entstehen (Anschaffung oder Umstellung von Hardware und Software, Betrieb der Infrastruktur, etc.), werden in den Medien regelmäßig mögliche Einsparungen von 300 bis 500 Mio Euro genannt (vgl. bspw. Welt Online 2007, Grebe 2005). Allein für die Unternehmen nennt der derzeitige Gesetzentwurf unter Punkt "F. - Bürokratiekosten" mögliche Einsparungen von "mehr als 250 Mio. € pro Jahr", die sich vor allen Dingen aus der wegfallenden Pflicht zur anlassbezogenen Erstellung papierner Einkommensnachweise ergäben.
Im Gestzentwurf werden zudem mögliche Effizinzsteigerungen in der Rentenversicherung erwähnt ("mindestens 10 Mio. €", Punkt F.c.). Inwiefern sich die Einführung des JobCard-/Elena-Verfahrens auf die Rentenversicherung auswirken soll, bleibt dabei jedoch unklar. Aller Wahrscheinlichkeit nach sind hiermit sekundäre Effekte gemeint, die sich auf eine allgemeine Etablierung der elektronischen Signatur und damit auf die Möglichkeit beziehen, verbindliche Renteninformationen zukünftig in elektronischer Form an die Bürger zu übermitteln (Punkt III.2 des derzeitigen Entwurfes).
Das genannte Einsparpotential wird jedoch bspw. vom Deutschen Landkreistag (2007) in Frage gestellt. Dieser weist u.a. darauf hin, dass neben dem mittels JobCard-/Elena-Verfahren erfassten Einkommen bei der Bearbeitung von Sozialleistungsanträgen auch weitere "Einkommen wie Zinseinnahmen oder Einnahmen aus Vermietung und Verpachtung" (Deutscher Landkreistag 2007, S. 3) berücksichtigt werden müssen. Dies würde dazu führen, dass zwar das Einkommen aus abhängiger Beschäftigung in elektronischer Form und damit medienbruchfrei in die Vorgangsbearbeitung einfließen würde, dass aber gleichzeitig weitere Einkommensnachweise vom jeweiligen Antragsteller eingefordert und in der gewohnten Form in die Bearbeitung einfließen müssten. Damit würde jedoch die elektronische Elena-Abfrage zusätzlich zum bisherigen Vorgehen erfolgen. Die Einsparungen durch Wegfallen einer manuellen Erfassung würden damit obsolet womit möglicherweise sogar "der Bearbeitungsaufwand insgesamt steigt" (ibd.).
Ein weiteres Ziel des JobCard-/Elena-Verfahrens ist es, mehr Gerechtigkeit im Verwaltungshandeln zu erreichen. So nennt der Gesetzentwurf das Beispiel der Rückzahlung von gewährter Prozesskostenhilfe (vgl. derzeitiger Entwurf, Punkt "I.3. Ungleichbehandlungen leistungsberechtigter Bürger" der Begründung). Im derzeitigen Verfahren finde die Überprüfung der Fähigkeit zur Rückzahkung aufgrund des aufwändigen Verfahrens faktisch nicht statt. Von der Einführung des JobCard-/Elena-Verfahrens verspricht man sich hier eine Vereinfachung und damit mehr Rückzahlungen durch hierzu später fähige Beteiligte.
Ähnlich gestalte es sich für andere Verfahren, in denen Leistungsempfänger zwar verpflichtet sind, Änderungen am Einkommen mitzuteilen, dieser Pflicht aber oftmals nicht nachkämen. Durch eine verlässliche Überprüfung auch späterer Einkommensverhältnisse mittels des JobCard-/Elena-Verfahrens sei die Durchsetzung von Rückzahlungsverpflichtungen oder bspw. Leistungsminderungen nicht mehr an das korrekte Verhalten der Beteiligten gebunden, wodurch sich eine höhere Verwaltungsgerechtigkeit insbesondere gegenüber denjenigen Betroffenen ergebe, die sich pflichtgemäß verhalten. Weiterhin würden sich auch in diesem Bereich positive monetäre Effekte ergeben, da weniger Leistungen unberechtigt ausgezahlt würden und zudem mehr Rückzahlungsverpflichtungen durchgesetzt werden könnten. Mehr Gerechtigkeit entsteht allerdings auch dort, wo heute kaum geprüft werden kann - bei der Bescheinigung (des Arbeitgebers) selbst, ob diese in sich korrekt ist, wenn sie stimmig erscheint. So sind nach Angaben der Bundesagentur für Arbeit etwa 50% aller Bescheinigungen zu Erlangung von Arbeitslosengeld 1 unvollständig und/oder falsch (Angabe der BA aus 2006). Auch hier darf sich künftig der Antragsteller darauf verlassen, dass geprüfte Programme korrekte Bescheinigungsinhalte übermitteln.
Gesamtwirtschaftliche Entwicklung
Neben den oben genannten Gründen sind mit der Einführung des JobCard-/Elena-Verfahrens auch weitere, gesamtwirtschaftliche Hoffnungen verbunden. Obwohl mit dem Signaturgesetz (SigG) bereits im Jahr 2001 die rechtliche Grundlage für einen rechtsverbindlichen elektronischen Geschäftsverkehr geschaffen wurde, konnten sich signaturbasierte Verfahren bisher nicht auf breiter Ebene durchsetzen. Die Gründe hierfür sind einleuchtend: So lange nur eine kleine Anzahl von Bürgern bzw. potentiellen Kunden über eine gesetzeskonforme Signaturkarte verfügt, bestehen für ein Unternehmen keine wirtschaftlichen Anreize, Dienste auf Basis der elektronischen Signatur anzubieten. Die zu geringe Masse möglicher Kunden würde die vergleichsweise hohen Entwicklungskosten für solche Dienste nicht rechtfertigen. Die Situation für den potentiellen Nutzer einer Signaturkarte stellt sich ähnlich dar: Solange keine oder nur wenige attraktive Dienste auf Basis der elektronischen Signatur verfügbar sind, existieren für ihn keine Anreize zur Anschaffung einer Signaturkarte.
In der Ökonomie sind derartige Konstellationen als indirekte Netzeffekte bekannt, die insbesondere bei Gütern aus der Informationstechnologie häufig auftreten: Der Wert eines Gutes (bspw. einer Signaturkarte) ist maßgeblich abhängig von der breiten Verfügbarkeit möglichst vieler Komplementärgüter (bspw. signaturbasierte Dienste). Da die gleiche Abhängigkeit aber auch in die entgegengesetzte Richtung besteht (der Wert des Dienstes ist abhängig von der breiten Verfügbarkeit der Karten), setzen sich beide Güter u.U. am Markt nicht durch.
Begegnen lässt sich diesem Effekt durch das bewusst forcierte Erreichen der "kritischen Masse", also einer breiten Verfügbarkeit, für eines der beiden Güter. Ist dieses erreicht, so steigt automatisch auch der Wert des jeweiligen Komplementärproduktes, welches sich im Folgenden ebenfalls am Markt etabliert (Für weitere Ausführungen zu diesem und ähnlichen Effekten, siehe insbesondere Shapiro/Varian, 1999).
Genau hierauf zielten die Hoffnungen auf zusätzliche positive gesamtwirtschaftliche Effekte des JobCard-/Elena-Verfahrens ab. Die kritische Masse von im Umlauf befindlichen Signaturkarten würde erreicht und die Bürger zudem an deren Verwendung gewöhnt. Mit einer derartigen Verbreitung von Signaturkarten würde sich auch für die freie Wirtschaft die Zahl der potentiellen Kunden erhöhen und damit die notwendigen Anreize zur Schaffung signaturbasierter Dienstleistungen entstehen. Das derzeit nahezu brach liegende Signaturgesetz würde "endlich" zur Anwendung kommen und die Bürger zudem in den Genuss einer deutlich erhöhten Sicherheit bspw. beim Online-Shopping oder beim Internetbanking kommen. Dementsprechend sprachen Hornung und Roßnagel im Jahr 2004 auch von der JobCard als möglicher "'Killer-Applikation' für die elektronische Signatur". Der Vollständigkeit halber sei zudem erwähnt, dass die österreichische Verwaltung bei der oben erwähnten Bürgerkarte einen alternativen Weg gewählt hat: Hier wurde die Bereitstellung einer kritischen Masse verfügbarer Dienstleistungen öffentlich forciert, um den Bürgern möglichst hohe Anreize zur Anschaffung einer Signaturkarte zu geben. Grundsätzlich sind aber beide Vorgehensweisen vergleichbar.
Die Überlegungen, dass mit einer möglichen Einführung des JobCard-/Elena-Verfahrens auch die Verbreitung und Nutzung signaturbasierter Verfahren und Dienstleistungen deutlich ansteigen würde, sind in jedem Fall nachvollziehbar und berechtigt. Gleichwohl würden sich möglicherweise die unten beschriebenen Konflikte ergeben.
Datenschutz
In der Diskussion um die Einführung des JobCard-/Elena-Verfahrens spielen auch Datenschutzaspekte eine maßgebliche Rolle.
Positiv könnte sich die Einführung in Bezug auf das Verhältnis zwischen Arbeitgeber und Arbeitnehmer auswirken. So muss ein Arbeitnehmer sich die benötigten Einkommensnachweise derzeit anlassbezogen von seinem Arbeitgeber ausstellen lassen. Der Arbeitgeber erlangt hierdurch Kenntnis davon, dass der Arbeitnehmer in einen Vorgang verwickelt ist, der einen Einkommensnachweis erforderlich macht. Da dem Arbeitgeber zudem mitgeteilt werden muss, auf Basis welcher Rechtsvorschrift er zur Ausstellung eines Einkommensnachweises verpflichtet ist, kann er zudem Kenntnis davon erlangen, um was für ein Verfahren es sich handelt. Er könnte somit bspw. über existierende Unterhaltsstreitigkeiten oder die Arbeitslosigkeit des Ehegatten informiert werden.
Durch Einführung des JobCard-/Elena-Verfahrens wäre dies nicht mehr der Fall. Der Arbeitgeber würde das Einkommen des Arbeitnehmers regelmäßig an die ZSS übermitteln, wäre in den Vorgang der Einkommensabfrage nicht weiter involviert und könnte somit von o.g. Vorgängen keine Kenntnis mehr erlangen. In Bezug auf das Verhältnis zwischen Arbeitnehmer und Arbeitgeber hätte das Jobcard-/Elena-Verfahren damit in der Tat einen verbesserten Schutz der Privatsphäre des Arbeitnehmers zur Folge. Der vorliegende Gesetzentwurf stellt dies auch deutlich heraus (vgl. Abschnitt "A. Problem und Ziel" des aktuellen Entwurfs: "Ebenso soll der Datenschutz für den Beschäftigten verbessert werden, indem der Arbeitgeber nicht mehr in das konkrete jeweilige Verwaltungs- oder Gerichtsverfahren einbezogen wird." sowie Punkt I.4. der Begründung: "Der Beschäftigte ist zur Durchführung eines Leistungsverfahrens häufig gezwungen, seinen Arbeitgeber um die Ausstellung einer erforderlichen Bescheinigung zu ersuchen. Die Bescheinigungsvordrucke müssen die Rechtsgrundlage angegeben, aufgrund derer der Arbeitgeber zur Ausstellung verpflichtet ist. [...] Diese Vorgaben zwingen den abhängig Beschäftigten, die sensible Tatsache der Antragstellung dem Arbeitgeber zu offenbaren [...].").
Anders verhält es sich jedoch für das Verhältnis zwischen Bürger und Staat, in dem zumindest die deutsche Datenschutzgesetzgebung ihren eigentlichen Ursprung hat. Die grundlegende Annahme ist hier, dass die Bürger vor einer übermäßigen Verarbeitung personenbezogener Daten durch staatliche Stellen geschützt werden müssen, da ansonsten essentielle Freiheitsrechte eingeschränkt würden. Dem Bürger wird also das Recht eingeräumt, "seinem Staat" zu misstrauen, anstatt sich auf dessen "Wohlverhalten" zu verlassen.
Grundsätzlich gilt daher, dass der Staat personenbezogene Daten nicht verarbeiten darf, es sei denn, die Verarbeitung wird durch ein Gesetz explizit erlaubt ("Verbot mit Erlaubnisvorbehalt") und es sind weitere zwingende Voraussetzungen erfüllt (Verhältnismäßigkeit, Normenklarheit, etc.). In der Praxis sind noch eine Vielzahl weiterer Bedingungen zu beachten, auf die hier jedoch nicht genauer eingegangen werden soll. Der geneigte Leser sei hierzu auf die einschlägige juristische Fachliteratur verwiesen.
Auf den vorgenannten Grundsatz (sowie auf dessen juristische Repräsentation, bspw. durch das BDSG) bezieht sich auch die Diskussion des Datenschutzes im vorliegenden Entwurf zum JobCard-/Elena-Verfahren. So setzt sich der vorliegende Entwurf in seiner Begründung bspw. mit der Frage auseinander, ob die Datenspeicherung in der ZSS eine "Unzulässige Datenvorratsspeicherung" darstellt (Punkt IV. der Begründung). Der Entwurf kommt hier zu dem Schluss, dass die Datenbevorratung nicht unzulässig sei, da eine hinreichend hohe Wahrscheinlichkeit bestehe, dass die gespeicherten Daten zu einem späteren Zeitpunkt zweckgemäß verwendet würden. Die Situation sei vergleichbar mit der etablierten Vorratsdatenspeicherung im Renten- und Sozialversicherungssystem. Das Allgemeininteresse an einer leistungsfähigen und effizienten Verwaltung überwiege gegenüber einem möglichen Individualinteresse an der Nichtspeicherung. Gegenteilig argumentieren hingegen Hornung und Roßnagel (2004, S. 7): "Allein von der Notwendigkeit der Datenverarbeitung für die Leistungserbringung her betrachtet, stellt sich das geplante System in weiten Teilen als eine nicht erforderliche – und deshalb grundsätzlich unzulässige – Vorratsdatenspeicherung dar."
Konzentration bisher dezentral vorgehaltener Daten
Das Risiko einer übermäßigen Datenverarbeitung besteht im Fall des JobCard-/Elena-Verfahrens insbesondere, weil bisher lediglich dezentral vorgehaltene Daten nunmehr an einer zentralen Stelle (der ZSS) zusammengeführt werden sollen (vgl. hierzu auch die Begründung des derzeitigen Entwurfs, Punkt "IV. Schutz der informationellen Selbstbestimmung": "Die bisher dezentral auf die jeweiligen Arbeitgeber verteilten Daten werden in eine zentrale und neutrale Stelle 'ausgelagert'."). Der aus Sicht des Datenschutzes signifikante qualitative Unterschied ergibt sich zum Einen aus der Zusammenführung selbst, da zentral vorgehaltenen Daten sich deutlich einfacher und effizienter verarbeiten lassen als dezentral gespeicherte, und zum Anderen aus der Tatsache, dass der gesamte Datenbestand der Verfügungsgewalt einer einzigen Instanz untersteht. In der derzeitigen Praxis wird schon durch die "Systemarchitektur" der dezentrale Datenhaltung eine übermäßige oder möglicherweise sogar unkontrollierte Verarbeitung verunmöglicht oder zumindest deutlich erschwert. Dies wäre bei einer zentralen, einer einzigen Instanz unterstehenden Datenhaltung nicht mehr der Fall. Vielmehr ergibt sich das Risiko von "Zweckentfremdungen seitens der zugriffsberechtigten Stellen." (Hornung und Roßnagel 2004, S. 8).
Ein gesetzliches Verbot einer derartigen Zweckentfremdung ist dabei durchaus differenziert zu betrachten. Zum Einen ergeben sich möglicherweise Nichtbeachtungen existierender Vorschriften, wie sie bereits aus der KFZ-Halterabfrage durch "befreundete Polizisten" bekannt sind, und zum Anderen lassen sich rechtliche Einschränkungen jederzeit an die jeweiligen Bedürfnisse der politischen Entscheidungsträger anpassen, wie es derzeit bspw. bei der Verwendung von Mautdaten zu Fahndungszwecken diskutiert wird. Es gilt auch hier der dem Prinzip der Datensparsamkeit zugrundeliegende Grundsatz, dass einmal vorhandene und prinzipiell verwendbare Daten in vielen Fällen Begehrlichkeiten wecken.
Nummerierungsaspekte
Ein weiterer Aspekt, auf den auch die Entwurfsbegründung eingeht, ist die Unzulässigkeit der bereichsübergreifenden Verwendung einheitlicher Ordnungsmerkmale (vgl. hierzu insbesondere das Volkszählungsurteil sowie die Stellungnahme des Rechtsausschusses des Bundestages zum Thema PKZ aus dem Jahr 1976). Diese Unzulässigkeit hat ihren Ursprung in einer ablehnenden Haltung gegenüber der Einführung eines bundeseinheitlichen, zu unterschiedlichsten Zwecken nutzbaren Personenkennzeichens (PKZ). Im Gegensatz zu solchen einheitlichen Personenkennzeichen werden in Deutschland üblicherweise bereichsspezifische Ordnungsmerkmale verwendet. Hierzu zählen bspw. die Rentenversicherungsnummer, die Sozialversicherungsnummer oder auch die Steuernummer.
All diese Ordnungsmerkmale sind bereichsspezifisch und dürfen nicht für andere, "bereichsfremde" Zwecke verwendet werden. Folgerichtig stellt der vorliegende Entwurf fest, dass "insbesondere die Rentenversicherungsnummer als Ordnungskriterium für die in der Zentralen Speicherstelle betriebene Datenbank" ausscheidet (Punkt IV.2. der Begründung) (Anzumerken ist an dieser Stelle, dass in den ursprünglichen Papieren (Hartz et al 2002b, S. 131) eine solche einheitliche und bereichsübergreifende Identifikationsnummer noch empfohlen wurde: "In diesem Zusammenhang ist die Einführung einer einheitlichen Versicherungsnummer aller Sozialversicherungsträger sinnvoll."). Gleichwohl wird aber die Rentenversicherungsnummer in der Registratur Fachverfahren mit der in der ZSS als Ordnungsmerkmal verwendeten Zertifikatsidentifikationsnummer "verknüpft" (vgl. hierzu die Ausführungen zur technischen Umsetzung). In jedem Fall stellt hierzu die Registratur Fachverfahren die Funktionalität zur Verfügung, Rentenversicherungsnummern auf Zertifikatsidentifikationsnummern abzubilden. Diese Funktionalität ist zwingend erforderlich, da der Arbeitgeber bei der Datenübermittlung die Rentenversicherungsnummer des Arbeitnehmers als Ordnungskennzeichen verwenden soll.
Da im Gesetzentwurf von einer "Verknüpfung" zwischen Rentenversicherungsnummer und Zertifikatsidentifikationsnummer die Rede ist und nicht etwa bspw. von einer "Abbildung mittels einer Einwegfunktion" ist davon auszugehen, dass eine entgegen gerichtete Abbildung (das Schließen von einer Zertifikatsidentifikationsnummer auf die entsprechende Rentenversicherungsnummer) zumindest grundsätzlich ebenfalls möglich ist. Damit enstünde jedoch etwas, was sich am ehesten als "System wechselseitig aufeinander abbildbarer bereichsspezifischer Ordnungsmerkmale" bezeichnen ließe. Wie solche bereichsspezifischen aber aufeinander abbildbaren Ordnungsmerkmale im Vergleich zu einem einheitlichen, bereichsübergreifenden Ordnungsmerkmal zu bewerten sind, ist eine der zentralen bisher noch ungelösten Fragen in Bezug auf das JobCard-/Elena-Verfahren.
Neben der möglichen Verknüpfung bereichsspezifischer Ordnungsmerkmale ist jedoch noch ein weiterer Nummerierungsaspekt zu identifizieren: Im Rahmen des JobCard-/Elena-Verfahrens wird die Identitätsnummer des verwendeten Zertifikats als Ordnungsmerkmal für die Speicherung in der ZSS verwendet. Gleichzeitig werden aber mit dem Vorhaben auch Hoffnungen verbunden, die Verwendung von Signaturkarten auch in anderen Bereichen zu etablieren (s.o.). Käme nun aber ein Zertifikat sowohl im Rahmen des JobCard-/Elena-Verfahrens als auch bei weiteren Einsatzzwecken zum Einsatz, so würde unter Umständen auch die Zertifikatsidentitätsnummer in unterschiedlichen Bereichen als Ordnungsmerkmal eingesetzt. Hieraus ergäbe sich dann möglicherweise die implizite bereichsübergreifende Verwendung eines bestimmten Ordnungsmerkmals "von selbst" und nicht, wie ansonsten angenommen, durch eine explizite gesetzliche oder vergleichbare Vorgabe. Hierauf zielt auch die Anmerkung von Hornung und Roßnagel (2004, S. 9) ab, dass es "[m]it der zunehmenden Verbreitung von Signaturverfahren [...] dazu kommen [könne], dass [die Zertifikatsidentitätsnummern] in einer Vielzahl von Lebensbereichen als Ordnungskriterium verwendet würden." Inwiefern dieses Risiko besteht und welche Schlüsse daraus zu ziehen sind, wird zukünftig ebenfalls zu diskutieren sein.
Technische Aspekte
Neben den oben genannten Punkten spielen natürlich auch technische Aspekte eine Rolle für die Bewertung des JobCard-/Elena-Verfahrens unter Datenschutzgesichtspunkten. Selbst wenn man die grundsätzliche Zulässigkeit bejahen und mögliche Probleme auf Grund von Nummerierungsaspekten verneinen würde, müssten bei der Realisierung angemessene "technische und organisatorische Maßnahmen" (Vgl. bspw. §9 BDSG nebst zugehöriger Anlage) getroffen werden. Aus informatischer Sicht sind hier natürlich die technischen Aspekte von besonderem Interesse.
Zur genaueren Betrachtung dieser technischen Aspekte ist es lohnenswert, den Weg nachzuvollziehen, den die Einkommensdaten innerhalb des geplanten Systems nehmen würden:
Vom Arbeitgeber zu der ZSS
Die im JobCard-/Elena-System zu verarbeitenden Daten entstehen beim Arbeitgeber. Dieser soll verpflichtet werden, zu jedem beschäftigten Arbeitnehmer monatlich einen Datensatz an die ZSS übermitteln, der aus dem erfassten Einkommen, dem betreffenden Beschäftigungszeitraum, Namen und Anschrift des Arbeitnehmer, sowie weiteren Angaben besteht. Zudem enthält der Datensatz die Rentenversicherungsnummer des Arbeitnehmers als Ordnungsmerkmal (Zu den übermittelten Daten siehe §1 des vorliegenden Entwurfes). Zur leichteren Veranschaulichung kann man sich diesen Datensatz als Datentupel der Form [RV-Nr, Einkommen, Zeitraum, Name, Anschrift, ...] oder noch weiter vereinfacht als [RV-Nummer, <Nutzdaten>] vorstellen.
Die elektronische Übermittlung an die ZSS soll in verschlüsselter Form erfolgen (vgl. §16, Abs. 1 des vorliegenden Entwurfes). Ohne detaillierter auf die genaue Ausgestaltung einzugehen, lässt sich dies vereinfacht als verschlüsselte VPN-Verbindung vorstellen. Über die Datenverbindung vom Arbeitgeber zur ZSS würde damit ein Datensatz der Form encrypted([RV-Nummer, <Nutzdaten>]) übertragen. Dieser Datensatz würde dann in der ZSS wieder entschlüsselt (vgl. §5, Abs. 1 des vorliegenden Entwurfes: "Die Zentrale Speicherstelle entschlüsselt die vom Arbeitgeber verschlüsselt übermittelten Daten."). Zu diesem Zeitpunkt läge dann in der ZSS ein Datensatz der Form decrypted(encrypted([RV-Nummer, <Nutzdaten>])) bzw. wiederum [RV-Nummer, <Nutzdaten>] vor. Inwiefern die verwendete Verschlüsselung dabei als hinreichend stark erachtet werden kann, soll hier nicht weiter betrachtet werden. Sie wird als stark genug angenommen, womit die Daten während der Übertragung ausreichend geschützt werden.
In der ZSS
Die ZSS würde daraufhin unter Zuhilfenahme der Registratur Fachverfahren aus der Rentenversicherungsnummer die zugehörige (bzw. mit der RV-Nummer "verknüpfte") Zertifikatsidentitätsnummer (ZertID) bestimmen. Die Registratur Fachverfahren muss dazu eine Funktionalität bereitstellen, die vereinfacht als ZertID(RV-Nummer) darstellbar ist. Damit würde sich ein in der ZSS vorliegender Datensatz der Form [ZertID(RV-Nummer), <Nutzdaten>] bzw. [ZertID, <Nutzdaten>] ergeben. Die in diesem Datensatz enthaltenen Nutzdaten würden dann unter dem Ordnungsmerkmal ZertID in der Datenbank abgelegt.
Zu beachten ist hier, dass die in der Datenbank abgelegten Nutzdaten unter Umständen als effektiv unverschlüsselt angesehen werden müssen. Der Gesetzentwurf selbst erwähnt zwar eine Speicherung der Daten in verschlüsselter Form, bleibt zur genauen Vorgehensweise bei Ver- und späterer Entschlüsselung der Daten vergleichsweise unklar. (Vgl. §5, Abs. 2: "Die Zentrale Speicherstelle speichert die [...] Daten in verschlüsselter Form." sowie §6, Abs. 1: Die [...] Daten werden nach dem Stand der Technik verschlüsselt. Dabei ist eine angemessene Abrufgeschwindigkeit sicherzustellen. Ähnlich unspezifisch bleibt auch die Einzelbegründung zu §4: "Die Datensätze werden dann verschlüsselt gespeichert. Im Bedarfsfall - also bei einer jederzeit möglichen Anfrage durch die abrufende Stelle - übermittelt die Zentrale Speicherstelle die Daten.") Bei jeder Verschlüsselung stellt sich aber die Frage, welche Beteiligten zur Entschlüsselung in der Lage sind. Da der vorliegende Entwurf an den hierfür entscheidenden Stellen zur weiteren Spezifikation auf eine noch zu erlassende Rechtsverordnung verweist, kann diese Frage nicht mit absoluter Gewissheit beantwortet werden.
Im Gesamteindruck legt der vorliegende Gesetzentwurf jedoch nahe, dass die Datenbank insgesamt verschlüsselt werden soll, dass aber die jeweilige Entschlüsselung bei einem Abrufvorgang ebenfalls innerhalb der ZSS vorgenommen werden soll. So erwähnt die Einzelbegründung zu §5, Abs. 3, dass "[b]ei jeder Abfrage [...] nur der für dieses Verfahren vorgesehene Ausschnitt aus dem insgesamt vorhandenen (Gesamt-)Datensatz übermittelt" werden soll. Hierzu muss die ZSS entweder in der Lage sein, einzelne Daten selektiv aus einer als ganzes verschlüsselten Datenbank abzurufen oder aber die Daten eines Datensatzes müssen einzeln verschlüsselt sein und dann ohne weitere Analysemöglichkeit an die abrufende Stelle übermittelt werden. Für letztere Alternative finden sich jedoch keine Hinweise im vorliegenden Entwurf. Eine Verschlüsselung der Datenbank als ganzes legt auch Punkt II.2. der Begründung nahe: "Selbst bei einem gelungenen Einbruch in die Datenbank [...] kann der Einbrecher ohne die Zuordnung von Zertifikatsidentitätsnummer zur Person nichts mit den verschlüsselten Daten anfangen. Die Zuordnung muss er dann auf andere Weise ermitteln." Diese Ausführungen lassen vermuten, dass ein "erfolgreicher" Einbrecher bei bekannter Zuordnung von ZertID und einer Person (was bei breiter Nutzung des Zertifikats - s.o. - keine besondere Hürde darstellen sollte) sehr wohl etwas mit den "verschlüsselten Daten anfangen" könnte.
Die derzeit wahrscheinlichste Vorgehensweise ergibt sich aus den Ausführungen von Ernestus (2004): "Ferner wird für jeden Datensatz ein Sessionkey generiert. Damit wird der Datensatz verschlüsselt und im zentralen Datenbanksystem abgespeichert. Zu jedem Datensatz wird auch der mit einem Masterkey verschlüsselten Sessionkey gespeichert [...]" In diesem Fall würden zwar verschlüsselte Gesamtdatensätze in der Datenbank abgelegt, die ZSS müsste aber weiterhin in der Lage sein, die Datensätze zur Übermittlung an die abfragende Stelle wieder zu entschlüsseln.
Unabhängig davon, welche der obigen Alternativen tatsächlich zur Anwendung kommt, müssten die "verschlüsselten" Daten also als "prinzipiell entschlüsselbar" angenommen werden. Ernestus (2004) weist allerdings auch auf die "Chance [zur] Trennung des Betriebes der Datenbank und der Stelle die alleinige Kenntnis des Masterkeys hat" hin. Auch hier würde sich jedoch die Frage stellen, wie die verschlüsselt abgelegten Daten wieder entschlüsselt werden sollen und eine getrennte Hinterlegung eines Masterkeys auch in Zukunft sicher gestellt bliebe. Es zeigt sich, dass das genaue Vorgehen der verschlüsselten Speicherung noch nicht hinreichend genau geklärt ist.
Angesichts der genannten Unklarheiten wird im Folgenden davon ausgegangen, dass die Daten zwar in verschlüsselter Form abgelegt werden sollen, dass sie aber prinzipiell jederzeit durch die ZSS wieder entschlüsselt werden könnten. Für die oben begonnenen Überlegungen würde dies bedeuten, dass die Datenspeicherung und der anschließende selektive Abruf sich in stark vereinfachter Form als encryptedDatabase.insert(ZertID, <Nutzdaten>) und <TeilNutzdaten> = encryptedDatabase.read(ZertID) darstellen ließen. Wie oben erwähnt übermittelt die ZSS bei einem Abruf durch eine abrufende Stelle lediglich die für den jeweiligen Vorgang notwendigen Teilnutzdaten. Ob dafür zuerst der gesamte Datensatz aus der Datenbank gelesen und dann die Teilnutzdaten extrahiert werden oder ob lediglich die relevanten Teilnutzdaten aus der Datenbank gelesen werden ist für die Betrachtung jedoch weitestgehend unerheblich.
Von der ZSS zur abrufenden Stelle
Die Übermittlung an die abrufende Stelle soll wiederum in verschlüsselter Form geschehen. Auch hier würde damit ein als encrypted([ZertID, <TeilNutzdaten>]) darstellbarer verschlüsselter Datensatz übertragen, der bei der abrufenden Stelle zu decrypted(encrypted([ZertID, <TeilNutzdaten>])) bzw. [ZertID, <TeilNutzdaten>] entschlüsselt und daraufhin weiterverarbeitet werden kann.
Weitere Maßnahmen
Zusätzlich zu den genannten Datenübertragungen sieht der vorliegende Entwurf die Umsetzung von Zugriffsrechten vor. So soll durch technische Maßnahmen verhindert werden, dass Abfragen ohne Zustimmung des Betroffenen durchgeführt werden. Lediglich für die Umsetzung dieser Zugriffsrechte kommt die Signaturkarte von Antragsteller und Mitarbeiter der abrufenden Stelle zum Einsatz. Mittels dieser wird die Identität der beteiligten Personen eindeutig bestätigt und das entsprechende Zugriffsrecht umgesetzt. Der beteiligte Antragsteller soll zudem auch vorab die Erlaubnis für zukünftige Zugriffe erteilen können, um nicht für jede Abfrage persönlich erscheinen zu müssen. Von der möglichen Funktionalität der Karten, Nutzdaten zu verschlüsseln, wird jedoch im vorgesehenen Verfahren kein Gebrauch gemacht.
Zusammenfassung
Wie aus obigen Ausführungen deutlich wird, sind mit Ausnahme der Regelungen für die Zugriffsrechte alle technischen Maßnahmen auf die Abwehr von externen Angriffen ausgerichtet. Die Verschlüsselung zwischen Arbeitgeber und ZSS schützt die Daten vor möglichen Angriffen auf dem Übertragungsweg, die Verschlüsselung der Datenbank schützt bspw. bei Diebstahl oder unsachgemäßer Entsorgung von Speichermedien und die verschlüsselte Übertragung von der ZSS zur "abfragenden Stelle" stellt wiederum einen Schutz gegen externe Angriffe auf den Übertragungsweg dar. Die Tatsache, dass die vorhandenen technischen Schutzmaßnahmen insbesondere auf diesen Schutz nach außen abzielen, wird wiederum auch aus der Begründung des vorliegenden Entwurfes deutlich. In Punkt II.2. heißt es hierzu: "[Die ZSS ist] nach dem Stand der Technik durch modernste Sicherheitsvorkehrungen geschützt, die einen Einbruch von außen extrem schwierig und unwahrscheinlich machen".
Demgegenüber erscheint der technische Schutz gegen Innentäter, also sich nicht wohlverhaltende Beschäftigte bspw. der ZSS, deutlich unterrepräsentiert. Zudem bleibt ungeklärt, wie verhindert werden soll, dass die einmal vorhandene Infrastruktur im Nachhinein auch um Zugriffsrechte für weitere als die bisher vorgesehenen Zwecke erweitert wird. Als bildhaftes Beispiel sei auf die derzeitige Diskussion um die Verwendung von Mautdaten zu Fahndungszwecken verwiesen.(Zur selben Thematik siehe auch BfDI (2007): "Die Problematik kann durch eine gesetzgeberische Begrenzung des Verwendungszwecks allein nicht ausgeräumt werden, da diese jederzeit erweitert werden kann.") Als zu diskutierende Frage ergibt sich damit, inwiefern in dieser Hinsicht Misstrauen "dem Staat" gegenüber angebracht ist, und welche Auswirkungen dies für die Systemgestaltung hat.
Literatur
BfDI (2007): "Job-Card-Verfahren" Der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit [1]
Deutscher Bundestag (1976): Stellungnahme des Rechtsausschusses des deutschen Bundestages zum Thema PKZ (online abgelegt an der TU Berlin) [2]
Deutscher Landkreistag (2007): "Stellungnahme zum Entwurf eines Gesetzes zur Einführung des Verfahrens zum Elektronischen Einkommensnachweises (ELENA)" [3]
Ernestus, Walter (2004): "JobCard – der Durchbruch für die elektronische Signatur?" In: DuD 7/2004
Grebe, Gregor (2005): "JobCard: Speicherung von Arbeitnehmerdaten – Rechtliche und Datenschutzbetrachtungen" [4]
Hartz, P. et al (2002b): "Moderne Dienstleistungen am Arbeitsmarkt - Langversion"
Hornung/Roßnagel (2004): "Die JobCard – 'Killer-Applikation' für die elektronische Signatur?" [5]
Shapiro, Carl und Hal Varian (1999): "Information Rules - A Strategic Guide to the Network Economy" Mcgraw-Hill Professional, ISBN: 087584863X
Welt Online (2007): "Die sparsamste Unterschrift" [6], Welt Online vom 1. März 2007.
