Feinkonzept FMS/VPS - Bund

Feinkonzept FMS/VPS

FEINKONZEPT FMS/VPS INTEGRATION DER VPS IN FMS

Version 1.2

Verfasser:

Kompetenzzentrum Datensicherheit/Sicherheitskonzepte Godesberger Allee 157 53113 Bonn

Autoren: Armin Wappenschmidt, Thomas Mohnhaupt, secunet Security Networks AG

Status: Final

Erstellung des Dokumentes: 22. September 2004

Stand: 1. Juni 2005

Feinkonzept FMS/VPS

Inhaltsverzeichnis

1 EINLEITUNG ....................................................................................................................5

1.1 Zielsetzung des Dokumentes..................................................................................................... 5

1.2 Abgrenzung und Rahmenbedingungen................................................................................... 5

1.3 Aufbau und Methodik............................................................................................................... 8

2 FUNKTIONALE BESCHREIBUNG DER TECHNISCHEN KOMPONENTEN ...............10

2.1 Fachanwendung FormsForWeb............................................................................................. 10

2.2 Das OSCI-Prinzip.................................................................................................................... 11

2.3 VPS-Komponenten.................................................................................................................. 12 2.3.1 OSCI-Client-Enabler (inclusive OSCI-Bibliothek und SAK)........................................... 14 2.3.2 OSCI-Manager und VPS-Kernsystem............................................................................... 16 2.3.3 OCSP/CRL-Relay ............................................................................................................. 17 2.3.4 OSCI-Backend-Enabler..................................................................................................... 18

3 SYSTEMARCHITEKTURANALYSE FÜR FMS-VPS.....................................................20

3.1 Architekturalternativen für die VPS-FMS Lösung in Bezug auf Datensicherheit............ 20

3.2 Online-Web mit OSCI-Backend-Enabler bei Behörde........................................................ 22 3.2.1 Systemarchitektur.............................................................................................................. 22 3.2.2 Beschreibung der Lösung.................................................................................................. 22

3.3 Offline mit OSCI ..................................................................................................................... 23 3.3.1 Systemarchitektur.............................................................................................................. 23 3.3.2 Beschreibung der Lösung.................................................................................................. 23

4 SOFTWAREARCHITEKTUR..........................................................................................23

4.1 Sequenzdiagramm................................................................................................................... 24

4.2 Prozessorientierte Objekte ..................................................................................................... 25

4.3 Sicherstellung der semantischen Gleichheit von XML- und Bild-Daten............................ 25

4.4 Prozessbeschreibung ............................................................................................................... 27

Version 1.2 Seite 2 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005

Feinkonzept FMS/VPS

4.4.1 Antragsstellung Online-Web mit OSCI bis zum Start des OSCI-Clients.......................... 27 4.4.2 Start, Anwendung des OSCI-Clients und Datenübermittlung zum FMS-Intermediär ...... 29 4.4.3 Antragsannahme Online-Web mit OSCI (Backend-Enabler bei Behörde) ....................... 30

4.5 Detaillierung der Nachrichtenflüsse ...................................................................................... 31

5 SCHNITTSTELLENÜBERSICHT UND –BESCHREIBUNG ..........................................33

5.1 Identifizierung der VPS-spezifischen Schnittstellen ............................................................ 33

5.2 Dialog FFW – JWS.................................................................................................................. 34

5.3 Dialog OSCI-Client – OSCI-Manager................................................................................... 35

5.4 Dialog OSCI-Manager – OCSP/CRL-Relay ......................................................................... 35

5.5 Dialog OSCI-Manager – OSCI-Backend-Enabler ............................................................... 36

5.6 Dialog OSCI-Backend-Enabler – VPS-Kernsystem............................................................. 37

5.7 Dialog Fachspezifischer Adapter des OSCI-Backend-Enablers – FFW-Funktionsmodul zur Integritätsprüfung ........................................................................................................................ 38

5.8 Ausgabe Fachspezifischer Adapter des OSCI-Backend-Enablers – Fachverfahren der Behörde ................................................................................................................................................ 39

6 INTEGRATIONSPLAN ...................................................................................................40

6.1 Unterstützte HW/SW-Einheiten und Kommunikationsprotokolle..................................... 40 6.1.1 Hardware ........................................................................................................................... 40 6.1.2 Betriebssystem und Softwareanforderungen..................................................................... 41 6.1.3 Unterstützte Signaturkarten und Kartenlesegeräte: ........................................................... 43 6.1.4 Java Runtime Environment ............................................................................................... 43 6.1.5 Java Web Start (JWS)........................................................................................................ 43 6.1.6 Browser ............................................................................................................................. 44

6.2 Festlegung der Hard- und Softwareanforderungen............................................................. 44

6.3 Anforderungen an den FMS-spezifischen OSCI-Client....................................................... 45 6.3.1 Funktionale Anforderungen .............................................................................................. 46 6.3.2 Technische Anforderungen ............................................................................................... 47 6.3.3 Sicherheitstechnische Anforderungen ............................................................................... 48 6.3.4 Organisatorische Anforderungen....................................................................................... 48


Feinkonzept FMS/VPS

6.4 Zusätzliche Integrationsaspekte............................................................................................. 49 6.4.1 Behördenspezifische Schutzbedarfsanalyse über eFormulardaten.................................... 49 6.4.2 Lösungsvarianten für eine OSCI-konforme Anbindung der Behörden............................. 49 6.4.3 Lösungsvarianten für Schlüsselmanagement/Zertifikatsmanagement .............................. 50 6.4.4 Eskalationsmechanismen................................................................................................... 50

7 AUSBLICK......................................................................................................................51

7.1 Kryptografische Dienste über DI ........................................................................................... 51

7.2 Mehrfachsignaturen................................................................................................................ 51

7.3 OSCI-Backend-Enabler bei FMS .......................................................................................... 51

ABKÜRZUNGSVERZEICHNIS..............................................................................................53

TABELLENVERZEICHNIS ....................................................................................................54

ABBILDUNGSVERZEICHNIS ...............................................................................................54


Feinkonzept FMS/VPS

1

1.1

1.2

EINLEITUNG

Zielsetzung des Dokumentes Im Rahmen der E-Government-Aktivitäten der Initiative BundOnline soll der Bundesverwal-tung mit dem Formular Management System (FMS) die Basiskomponente „Formular-Server“ zur Verfügung gestellt werden. Die an die Anforderungen von BundOnline angepasste FMS-Basissoftware der Firma Lucom GmbH wird allen Behörden der Bundesverwaltung zur Ver-fügung gestellt werden, deren Online-Dienstleistungen einen formulargebundenen Datenaus-tausch benötigen.

Das FMS soll über Schnittstellen mit den Funktionalitäten der Basiskomponenten und ande-ren Diensten wie der Zahlungsverkehrsplattform, Content Management System (CMS) und insbesondere der Virtuellen Poststelle (VPS) verbunden werden, um damit die Möglichkeit für einen vollständigen und medienbruchfreien formulargebundenen Datenaustausch zwi-schen Bürgern und Verwaltung zu schaffen.

Die Basissoftware des FMS ist das Produkt FormsForWeb der Firma Lucom GmbH. Die Software wird von Siemens Business Services (SBS) geliefert. SBS wird auch den Aufbau der Referenzinstallation unterstützen und den Bundesbehörden für die Einführung der FMS-Software zur Verfügung stehen. Das Zentrum für Informations- und Datentechnik der Bun-desfinanzverwaltung (ZID) in Frankfurt ist mit dem Aufbau der geplanten Referenzinstallatio-nen des FMS beauftragt.

Das Kompetenzzentrum Datensicherheit (CC-DS) begleitet im Rahmen der E-Government-Aktivitäten der Initiative BundOnline die Einführung des Formular Management Systems hin-sichtlich der Datensicherheit und der Integration der Basiskomponente Datensicherheit, der Virtuellen Poststelle (VPS).

Das vorliegende Dokument beschreibt das Zusammenwirken der VPS- und FMS-Komponenten sowie die Aufrufe ihrer Funktionen und Schnittstellen, soweit diese für die In-tegration der VPS in FMS notwendig sind.

Abgrenzung und Rahmenbedingungen Im Workshop vom 19.10.2004 wurden zwischen ZID und CC-DS folgende Abgrenzungen und Rahmenbedingungen als Grundlage dieses Feinkonzepts vereinbart.

Organisatorische und prozessuale Anforderungen

• Es wird nur eine „Posteingangssituation“ (aus Sicht des FMS bzw. der Behörde) be-trachtet.


Feinkonzept FMS/VPS

Funktionale Anforderungen:

• Vor Übernahme von eFormular-Daten zum OSCI-Client sollen diese serverseitig ge-prüft werden (Plausibilitätsprüfung).

Technische Anforderungen:

• Das Produkt FFW unterstützt keine reine Offline-Formular Lösung: Der Offline-Formular Client (Offline-Filler) sendet seine Daten immer an den FMS-Server, plausi-bilisiert diese und dieser startet den OSCI-Client

Eine direkte vertrauliche Übergabe von eFormular-Daten zwischen Offline-Filler und OSCI-Client ist damit nicht möglich.

Das Online- oder Offline-Ausfüllen eines eFormulars unterscheidet sich damit aus Sicht der VPS-Integration nicht.

Eine einheitliche Clientsoftware für FMS/VPS (Offline-Filler und OSCI-Client) muss über eine zentrale Softwareverteilung gewährleistet werden.

Sicherheitstechnische Anforderungen:

• Für den Einsatz der VPS in Antragsverfahren existieren grundsätzlich verschiedene Architekturalternativen. Sofern eine Auswahl bei mehreren Architekturalternativen er-forderlich ist, muss die Auswahl in Abhängigkeit des Schutzbedarfs der Daten der Mandanten erfolgen.

Die Erhebung des Schutzbedarfs betrifft die zu übertragenden und zu verar-beitenden Daten sowohl der eFormulare als auch die Daten, die zur Validie-rung herangezogen werden.

In Ergänzung hierzu wurden in weiteren Workshops mit der Projektgruppe BundOnline fol-gende weiteren Empfehlungen/Beschränkungen festgelegt.

Datenverarbeitung gem. Architekturleitlinien:

• Datenformate

Als Standards für Datenaustauschformate mittels VPS wurden Bildformate (TIFF) und XML festgelegt. Damit die übertragenen Daten im Backend weiter-verarbeitet werden können, muss XML eingesetzt werden.

Für die Referenzinstallation ist geplant, ein Bild (TIFF) des ausgefüllten For-mulars zu signieren.


Feinkonzept FMS/VPS

Abweichungen von den signierten Bildinhalten zu den zugehörigen XML-Daten, die in den Fachanwendungen weiterverarbeitet werden, müssen er-kannt und behandelt werden.

Das zu signierende Bild kann dabei durch einen Viewer im OSCI-Client dar-gestellt werden. Die XML-Daten des Formulars laufen in diesem Fall ebenfalls über den OSCI-Client, so dass Daten im Backend (FFW oder Fachverfahren) weiterverarbeitet werden können.

• Entwicklung eines Migrationspfades von der Architekturvariante „OSCI-Backend-Enabler bei Behörde“ zu einer Variante „OSCI-Backend-Enabler bei FMS“ mit der Möglichkeit eines Angebots für zentrale Dienstleistungen.

Funktionale Anforderungen:

• Plausibilitätsprüfungen im Fachverfahren werden über Webservices realisiert, die ü-ber die eFormulare aufgerufen werden.

• Nach Plausibilisierung der Daten und deren Übergabe, sollen keine temporären Da-ten mehr im FFW-Server gehalten werden.

• Grundsätzlich ist für die Anbindung von Fachverfahren an das FMS jeweils eine Schnittstelle zu programmieren. Dabei kann entweder das FMS die Daten immer in einer festen Form an ein Fachverfahren übermitteln. Dann muss die Anpassung auf der Fachverfahrensseite erfolgen. Oder das Fachverfahren liefert die Form an die das FMS angepasst werden muss. D.h. ein Fachverfahren implementiert eine SOAP-Schnitttstelle (Webservice) nach den strukturellen Vorgaben des FMS.

• Die VPS bietet „vorkonfektionierte“ Standardadapter zur Übergabe der VPS-Daten an das Fachverfahren. Für die VPS-spezifische Übergabe der Daten wird festgehalten, dass es auf Seiten des FFW gleichfalls eine Schnittstelle oder ein Adapter geben muss, das diese Daten zur weiteren Verarbeitung entgegennimmt.

• Grundsätzlich soll ein als Webservice realisiertes Poll-Verfahren zum Einsatz kom-men, um Daten von Fachverfahrensseite aus dem FMS abzurufen.

Sicherheitstechnische Anforderungen:

• Nach der Entwicklung eines Migrationspfades von der Architekturvariante „OSCI-Backend-Enabler bei Behörde“ zur Variante „OSCI-Backend-Enabler bei FMS“ wer-den VPS-Einsatzszenarien mit unterschiedlichen Sicherheitsniveaus zur Verfügung stehen.

• Die mandantenspezifische Frage, wo der OSCI-Backend-Enabler für die jeweilige Behörde zum Einsatz kommt (OSCI-Backend-Enaber direkt bei der Behörde oder


Feinkonzept FMS/VPS

beim FMS), muss dann über eine Schutzbedarfsanalyse für die jeweilige Dienstleis-tung geklärt werden.

• Zur Sicherung der Webservice-Schnittstelle und zur Datenverteilung müssen geeig-nete Lösungen zur Aufrechterhaltung notwendiger Vertraulichkeit, Authentizität und Verfügbarkeit realisiert werden.

• Ein Rechtesystem für Webservices (insbesondere die dazu gehörende Authentisie-rungslösung) ist derzeit noch nicht entwickelt, wird aber nach 2005 von der Firma Lu-com zur Verfügung gestellt werden.

Die Dokumentation dieser Version des Feinkonzepts beschreibt die FMS-VPS Architekturva-riante „OSCI-Backend-Enabler bei Behörde“.

Die Entwicklung eines Migrationspfades von der Architekturvariante „OSCI-Backend-Enabler bei Behörde“ zu einer Variante „OSCI-Backend-Enabler bei FMS“ soll erst in einer zukünfti-gen Version des Feinkonzepts beschrieben werden.

1.3 Aufbau und Methodik Das Feinkonzept für die Integration der Basiskomponente VPS in das FMS soll die ange-strebten Lösungen zur Erfüllung der funktionalen Anforderungen spezifizieren. Das Feinkon-zept umfasst folgende Abschnitte:

Funktionale Beschreibung der technischen Komponenten

Dieser Abschnitt stellt dar, welche Komponenten der Basiskomponente FMS und der Ba-siskomponente Datensicherheit VPS für die Gesamtlösung FMS Anwendung finden.

Systemarchitekturanalyse für FMS-VPS

Dieser Abschnitt stellt die grundsätzlich möglichen Architekturalternativen einer VPS-Lösung für FMS dar. Dabei wird beschrieben, welche Alternative aufgrund der Schutzbe-darfsanforderung der Formulardaten eingesetzt werden soll.

Softwarearchitektur

Dieser Abschnitt beschreibt die notwendige Softwarearchitektur der VPS für das FMS-System anhand eines Sequenzdiagramms. Dabei werden die Zusammenhänge zwischen Prozessen und den prozessorientierten Objekten (z.B. SW-Komponenten, SW-Module oder Datenbanken) dargestellt.

Schnittstellenübersicht und –beschreibung

Dieser Abschnitt enthält eine zusammenfassende Übersicht über alle Schnittstellen zu der einzusetzenden VPS-Lösung gemäß den Ausführungen im vorher beschriebenen


Feinkonzept FMS/VPS

Sequenzdiagramm. Es enthält für jede in der Übersicht identifizierte Schnittstelle eine Funktionsbeschreibung.

Integrationsplan

Der Integrationsplan enthält konzeptionelle Rahmenbedingungen für den Zusammenbau des Systems aus technischer Sicht. Der Plan identifiziert dabei die Integrationsprodukte und erläutert technische Voraussetzungen, Möglichkeiten und Einschränkungen ebenso wie die Organisation der Integration.


Feinkonzept FMS/VPS

2

2.1

FUNKTIONALE BESCHREIBUNG DER TECHNISCHEN KOMPONENTEN

Dieser Abschnitt stellt dar, welche Komponenten der Basiskomponente FMS und der Basis-komponente Datensicherheit VPS für die Gesamtlösung FMS Anwendung finden.

Fachanwendung FormsForWeb

Abbildung 1: Softwarearchitektur des FFW-Systems

Das FFW besteht im Wesentlichen aus:

• FFW-Designer

o FFW-Applikation zur Erzeugung der behördenspezifischen eFormulare

o Die erstellten Formulare können dann in einem XML-Format gespeichert und an den FFW-Server übertragen werden.

• Formularwebserver zur Datenübernahme von eFormularen von Bürgerseite


Feinkonzept FMS/VPS

o Der Webserver ist die „nach außen“ sichtbare Komponente des FFW. Er ist für die Kommunikation mit den Browsern auf den Client-Rechnern verantwort-lich.

• Applikationssysteme für Formularverwaltung, -plausibilisierung und Anbindung an ex-terne Fachverfahren der Behörden

o Der FormsForWeb-Server ist – wie aus der Abbildung ersichtlich – als Web-applikation im Webserver eingebettet.

o Der Formular-Server ist eine J2EE-Web-Applikation, die auf jedem J2EE kon-formen Application Server lauffähig ist.

o Die Architektur von FormsForWeb entspricht der in SAGA 2.0 geforderten Vier-Schicht-Architektur auf Basis der für Basiskomponenten obligatorischen Java 2 Plattform, Enterprise Edition (J2EE). Umfangreiche Plausibilitäts- und Konsistenzprüfungen können sowohl in der Mittelschicht serverseitig, in der Persistenzschicht als auch in der Client-Schicht (bei aktiviertem JavaScript) stattfinden.

• Datenbanksysteme für eFormulare und Inhaltsdaten

o FormsForWeb verwendet Datenbanken zum Speichern bzw. Zurücklesen von Formulardaten und Anlagen. Das Vorbereiten der Datenbanken zur Aufnahme von Daten aus neu erstellten Formularen (d.h. Anlegen der Tabellen, Indizes etc.) erfolgt automatisch. Alle benötigten SQLScripte werden von FormsFor-Web selbständig erstellt. Neben der Ablage von Formulardaten eignen sich Datenbanken auch zum Füllen von Auswahllisten oder dem automatischen Nachschlagen von Daten (Lookup-Funktion). Alle anzubindenden Datenban-ken werden an zentraler Stelle in FormsForWeb konfiguriert und zur Nutzung innerhalb der Formulare zur Verfügung gestellt.

o Als externe Datenquellen unterstützt FormsForWeb in erster Linie SQL-Datenbanken, LDAP-Verzeichnisse sowie XML-Dateien.

FormsForWeb unterstützt SQL-Datenbanken, für die ein JDBC 2.0 konformer Treiber verfügbar ist. Für FMS soll Oracle 9i unterstützt werden. Die je nach Hersteller unterschiedlichen SQL-Dialekte werden durch spezielle, in Forms-ForWeb bereitgestellte Adapter ausgeglichen.

2.2 Das OSCI-Prinzip OSCI (Online Service Computer Interface) ist ein auf XML basierendes Nachrichtenprotokoll. Es dient dem authentischen und sicheren Transport von geschäftsvorfallspezifischen Daten sowie deren medienbruchfreier Weiterverarbeitung durch die adressierten Fachverfahren.


Feinkonzept FMS/VPS

Dabei entwickelte man das Prinzip des ‚doppelten Umschlags’: Hierbei werden Inhalts- und Transportdaten streng getrennt. Die Inhaltsdaten mit der eigentlichen Nachricht sind nur vom autorisierten Empfänger zu lesen, die Transportdaten enthalten Informationen über die ver-wendeten Zertifikate, dem Typ der Nachricht und andere Angaben, die notwendig sind, um die Daten zuzustellen.

Die Inhaltsdaten befinden sich im ‚inneren’ Umschlag, die Nutzungsdaten im ‚äußeren Um-schlag’. Die Inhaltsdaten werden zwischen Sender und Empfänger verschlüsselt. Der unten in der Abbildung dargestellte „Intermediär“ entpackt oder verpackt jeweils nur den ‚äußeren Umschlag’ mit den Versanddaten. Die Vertraulichkeit der verschlüsselten Inhaltsdaten wird so gewährleistet.

Abbildung 2: OSCI-Prinzip

2.3 VPS-Komponenten Für die FMS-Lösung werden „nur“ VPS-Web-Komponenten eingesetzt. Diese sind:

• OSCI-Client-Enabler, bestehend aus einer konfigurierbaren Anwendungsschicht (sogenannte Szenarien), einer OSCI-Funktionsbibliothek, und einer OSCI-konformen Client-Signaturanwendungskomponente (SAK).

Der OSCI-Client-Enabler hat für den Versand die Aufgabe, Eingabedaten und Anla-gen (Dateien) zu einer Nachricht in das OSCI-Datenformat einzupacken, die erforder-lichen Verschlüsselungen vorzunehmen und Signaturen des Absenders anzubringen. Für die Signaturerzeugung spricht der OSCI-Client-Enabler den Kartenleser des Kunden an. Beim Empfang einer Nachricht entschlüsselt der OSCI-Client-Enabler die Nachricht und prüft die Signatur der Daten.


Feinkonzept FMS/VPS

• OSCI-Manager: Der OSCI-Manager realisiert gemeinsam mit dem VPS-Kernsystem und dem OCSP/CRL-Relay die Rolle des Intermediärs aus der OSCI-Spezifikation zur Bearbeitung und Steuerung von OSCI-Nachrichten (Transportschicht) und Ver-waltung von OSCI-Postfächern (Postfachverwaltung). Zu den Kernaufgaben gehören dabei die Öffnung des äußeren Umschlags einer OSCI-Nachricht (Transportschicht) und die Überprüfung der Transportsignaturen. Der OSCI-Manager benötigt für die Steuerung der OSCI-Nachrichten auf Transportschicht die kryptographische Funktio-nen des VPS-Kernsystems zur Ver-/Entschlüsselung sowie zur Signaturerstellung und –prüfung. Der OSCI-Manager kann dabei OSCI-Postfächer anlegen und verwal-ten, in denen OSCI-Nachrichten zwischengespeichert werden. Die Inhaltsdaten der OSCI-Nachricht bleiben dabei verschlüsselt.

• VPS-Kernsystem: Das VPS-Kernsystem ist für die zentrale kryptographische Bear-beitung von ein- und ausgehenden Daten bzw. Dokumenten (Ver-/Entschlüsseln, Signieren, Initialisierung Signaturprüfung, Zeitstempelanforderung) verantwortlich. Im VPS-Kernsystem ist neben der Erstellung von fortgeschrittenen Signaturen auch die Erstellung von qualifizierten elektronischen Signaturen im Namen der Behörde ange-siedelt. Zudem können über das VPS-Kernsystem Zertifikatsprüfungen veranlasst werden.

• OCSP/CRL-Relay: Das OCSP/CRL-Relay ist die zentrale Komponente im Rahmen der Signaturprüfung zur Online- bzw. Offline-Prüfung von Zertifikaten auf Basis des Protokolls OCSP (Online-Prüfung) oder auf Basis von CRLs (Offline-Prüfung).

• OSCI-Backend-Enabler: Der OSCI-Backend-Enabler ist die serverseitige Kompo-nente zur Entgegennahme von OSCI-Nachrichten sowie Entschlüsselung und Signa-turprüfung (mathematische Korrektheit) auf Nutzdatenebene. Weiterhin können (aus-gehende) Nutzdaten mit einer elektronischen Signatur versehen sowie verschlüsselt werden. Der OSCI-Backend-Enabler stellt einer nutzenden Fachanwendung die Da-ten im Klartext und im ursprünglichen „Rohformat“ zur Verfügung bzw. nimmt sie von der Fachanwendung zwecks anschließend sicherer OSCI-Versendung entgegen.

Der OSCI-Backend-Enabler und der OSCI-Client-Enabler stellen die Endpunkte einer OSCI-Kommunikation dar. Sie können deswegen auch wechselseitig zum Empfang bzw. zum Versand von OSCI-Nachrichten eingesetzt werden. Während der OSCI-Backend-Enabler ein VPS-Kernsystem benötigt, um die kryptographischen Operatio-nen durchzuführen, führt der OSCI-Client-Enalber diese mit „Bordmitteln“ selbst aus (siehe dazu auch Abschnitt 2.3.4).


Feinkonzept FMS/VPS

2.3.1 OSCI-Client-Enabler (inclusive OSCI-Bibliothek und SAK)

Technische Beschreibung

Der OSCI-Client-Enabler ist ein Framework für die Erstellung von konfigurierbaren Client-Anwendungen in der Programmiersprache Java.

Der OSCI-Client-Enabler stellt Anwendungsentwicklern

• eine Programmierschnittstelle mit OSCI-spezifischen Objekten,

• eine Infrastruktur zur freien Konfiguration der Anwendung ohne Änderung der Programmierung sowie

• eine Sammlung von Programm-Vorlagen für die wesentlichen Anwendungs-Szenarien, die als Startpunkt für die eigene Entwicklung verwendet werden können,

zur Verfügung.

Funktionalitäten:

1. Komposition und Dekomposition der OSCI-Nachrichtentypen:

2. Dialoginitialisierung, Zustellungsauftrag, Abholauftrag, Dialogende

3. Kryptografische Funktionen für elektronische Signatur und Chiffrierung

4. Anbindung Kartenlesegeräte und Smartcards

5. Automatische Erkennung der installierten Chipkartenlesertreiber und Signaturkarten

6. Visualisierungskomponente

7. Nachrichtentransport

Der OSCI-Client-Enabler kann mittels Java Web Start (JWS) über einen HTML-Link installiert und aktiviert werden Durch den Einsatz von Java Web Start wird Browser-Unabhängigkeit erreicht; die Anwendung läuft in der gesicherten Umgebung einer Java Virtual Machine (JVM).

Die OSCI-konforme Signaturanwendungskomponente (SAK) unterstützt eine Vielzahl an Signaturkartenlesegeräten über die, mittels Signaturkarte, die Signatur über die geladenen Daten oder Dateien ausgeführt werden kann.


Feinkonzept FMS/VPS

Anwendungsbeschreibung

Der Start des OSCI-Client-Enablers erfolgt typischerweise (aber nicht ausschließlich) über Start eines Links in einer Webseite. Dabei können verschiedene Anwendungen (Szenarien) aufgerufen werden.

Die Szenarien stellen eine funktionale Applikationsschicht dar. Der OSCI-Client-Enabler be-inhaltet exemplarisch einfache Vorlagen von Szenarien, die Softwarearchitekten und Ent-wicklern als Templates für konkrete Implementierungen dienen können. Davon können min-destens die zwei folgenden im FMS-Kontext angewendet werden:

1. Zustellung einer OSCI-Nachricht (hier: Client auf Bürgerseite)

Visualisieren, Signieren und Verschlüsseln der Nachrichteninhalte mit an-schließender Übermittlung an den OSCI-Manager

Es ist grundsätzlich möglich lokal, abgelegte Dateien oder Daten einer Webanwen-dung über den OSCI-Client-Enabler zu signieren, verschlüsseln und mit dessen OSCI-Mechanismen an den OSCI-Manager zu übermitteln.

Der Start des OSCI-Client-Enabler und die Übernahme der zu übermittelnden Daten kann dabei manuell erfolgen oder über eine Online-Anwendung.

Daten, die über eine Online-Anwendung in ein Webformular eingegeben wurden, werden vom Client-Browser an den Webserver der Webanwendung zurückgesendet. Der Webserver erhält die Formulardaten und sendet eine Visualisierung (Webseite) der übernommenen Formulardaten an den Browser-Client zurück. Diese Webseite enthält eine URL (z.B. Hinterlegung des Links hinter einem Button) zum Start des OSCI-Client-Enablers über JWS. Die Daten, die signiert werden sollen, werden vom Webserver dem OSCI-Client-Enabler übergeben und das Datenaustauschverfahren initiiert.

2. Abholung einer OSCI-Nachricht (hier: Client/Backend auf Behördenseite)

Abholen von Zustellungsaufträgen aus dem OSCI-Postfach, Sicherung im loka-len Dateisystem

Der OSCI-Client-Enabler wird gestartet, um OSCI-Nachrichten vom OSCI-Manager aus dem eigenen Postfach abzuholen. Dabei wird die Nachricht empfangen, ent-schlüsselt, signatur-geprüft und einer konfigurierten Dateiablage zugeführt. Die Abla-ge der in der OSCI-Nachricht enthaltenen Metadaten (Transportebene) und Inhaltsda-ten erfolgt getrennt (z.B. Ablage von Inhaltsdaten, Laufzettel, Prüfprotokoll oder Zerti-fikaten).

Der Start des OSCI-Client-Enabler und die Abholung der Daten kann dabei manuell erfolgen oder über eine Online-Anwendung.


Feinkonzept FMS/VPS

Der OSCI-Client-Enabler kann auch als einfache Alternative zum OSCI-Backend-Enabler eingesetzt werden (siehe Abschnitt 2.3.4)

2.3.2 OSCI-Manager und VPS-Kernsystem


Der OSCI-Manager übernimmt die Rolle des sicheren Routers für den OSCI-basierten Da-tenverkehr zwischen zwei Kommunikationsteilnehmern, wie z.B. einem externen Benutzern und der Fachanwendung im serverseitigen Backend-Bereich der Verwaltung. Die Kernfunkti-onalität des OSCI-Managers ist somit die Sicherung der Kommunikation zwischen der Client- und Backend-Anwendung.

Zu den Kernaufgaben gehört die „Öffnung des äußeren Briefumschlags“, die Abbildung der spezifischen OSCI-Sicherheitsmechanismen (Dialogfolge- und Dialogpartnersicherung, Ver-gabe eindeutiger Message-ID’s) und die Überprüfung von Transportsignaturen. Innerhalb des OSCI-Managers werden OSCI-Postfächer angelegt, in denen die Nachrichten (in ver-schlüsselter Form) bei asymmetrischen Kommunikationsszenarien zwischengespeichert werden. Innerhalb des OSCI-Managers werden die Inhaltsdaten der Kommunikation (ent-sprechend des Rollenprofils des OSCI-Intermediärs) nicht entschlüsselt. Für die eigentlichen kryptografischen Funktionen bedient sich der OSCI-Manager den entsprechenden Funktio-nen des VPS-Kernsystems.

Funktionen des OSCI-Managers:

• Kontrolle der Dialog- und Nachrichtenfolgen gem. OSCI-Spezifikation (Challenge-Response-Mechanismen, Vergabe von Message-IDs, Prüfung von Dialog-IDs)

• Prüfung und Erstellung von Transportsignaturen

• Über VPS-Kernsystem: Ver- und Entschlüsselung der Transportschicht der OSCI-Nachrichten

• Über VPS-Kernsystem: Zertifikatsprüfung

• Bereitstellung von Postfächern für alle Teilnehmer der OSCI-Kommunikation, wobei für den OSCI-Manager die Inhaltsdaten nicht sichtbar sind; sie können nur durch den Empfänger entschlüsselt werden. Die Zuordnung der Inhaber zu ihren jeweiligen Postfächern erfolgt über das Verschlüsselungs-Zertifikat des Empfängers.

Funktionen des VPS-Kernsystems:

Das VPS-Kernsystem wird über die einheitliche Schnittstelle, das so genannte Dokument-Interface (DI), angesprochen. Über diese Schnittstelle nutzen Web-Anwendungen sowie Fachverfahren folgende Dienste des Kernsystems:


Feinkonzept FMS/VPS

• Prüfung und Erstellung von Signaturen,

• Ver- / Entschlüsselung,

• Über OCSP/CRL-Relay: Zertifikats-Status ermitteln, Lokalisieren von Zertifikaten so-wie Extrahieren und Bereitstellen von Informationen aus Zertifikaten und Funktionen des VPS-Kernsystems

• Anforderung und Prüfung von externen Zeitstempeln


Der OSCI-Manager nimmt die OSCI-Daten vom OSCI-Client-Enabler oder vom OSCI-Backend-Enabler entgegen, bearbeitet sie und legt sie im jeweiligen OSCI-Postfach ab.

Der OSCI-Manager entschlüsselt die OSCI-Transportschicht und prüft u.a. über das VPS-Kernsystem die Gültigkeit der Zertifikate mit Hilfe des OSCP/CRL-Relays, welches wiederum die Verzeichnisdienste der Trustcenter abfragt. Die Prüfergebnisse werden auf dem OSCI-Laufzettel der Nachricht vermerkt. Die OSCI-Nachrichten werden in einem OSCI-Postfach gespeichert.

Der OSCI-Manager benötigt eine aktive Verbindung zum VPS-Kernsystem, um die kryp-tographische Behandlung empfangener (Entschlüsselung auf Transportebene, Signaturprü-fung) bzw. versendeter Daten (Signaturbildung, Verschlüsselung) zu veranlassen. Das VPS-Kernsystem wiederum baut eine aktive Verbindung zum OSCP/CRL-Relay auf, um Zertifika-te der Kommunikationspartner hinsichtlich deren Status (Vorhandensein, Sperrung) zu prü-fen.

2.3.3 OCSP/CRL-Relay


Das OCSP/CRL-Relay stellt dem VPS-Kernsystem sowie weiteren externen Anwendungen Funktionalitäten im Zusammenhang mit dem Umgang von X.509-Zertifikaten bereit. Das OCSP/CRL-Relay übernimmt neben der Prüfung von Zertifikaten auch die Aufgabe der Bil-dung von gültigen Zertifikatsketten. Das OCSP/CRL-Relay wird als eigenständige Kompo-nente außerhalb des VPS-Kernsystems betrieben und stellt eine HTTP/HTTPS-Schnittstelle bereit.

Das OCSP/CRL-Relay hat als eines der zentralen Bestandteile der VPS folgende Aufgaben:

• Zertifikatsstatus ermitteln:


Feinkonzept FMS/VPS

Das OCSP/CRL-Relay hat die Aufgabe, Informationen über Zertifikate bereitzustellen, nicht aber, diese Informationen abschließend zu interpretieren. Dies bedeutet z.B., dass das Relay nicht wissen muss, für welchen Zweck ein Zertifikat verwendet wer-den soll. Es muss nur Informationen darüber bereitstellen, für welchen Einsatz dieses Zertifikat zugelassen ist.

• Extrahieren und Bereitstellen von Informationen aus Zertifikaten:

Zertifikate können eine Reihe von Informationen über den Zertifikatsinhaber und über das Zertifikat selbst enthalten. Hierzu gehören Daten wie Name, Vorname oder Ge-burtsdatum ebenso wie Nutzungsbeschränkungen des Zertifikats. Das OCSP/CRL-Relay extrahiert diese Informationen aus dem Zertifikat und stellt sie in Form von XML-Daten bereit.


Das OCSP/CRL-Relay prüft die Gültigkeit von Zertifikaten anhand von Sperrlisten oder durch eine Online-Abfrage. Hierzu wird nach außen aktiv eine Verbindung zum entsprechenden Zertifikatsaussteller (Zertifizierungsdiensteanbieter) aufgebaut, um Sperrlisten anzufordern bzw. Online-Gültigkeitsabfragen abzusetzen. Die Kommunikation mit den Zertifizierungs-diensteanbietern kann dabei auf unterschiedlichen Ports stattfinden.

2.3.4 OSCI-Backend-Enabler


Die Grundfunktionalitäten des OSCI-Backend-Enablers verhalten sich spiegelbildlich zur Funktionalität eines OSCI-Client-Enablers. Der OSCI-Backend-Enabler kommuniziert für die kryptografischen Funktionen mit dem VPS-Kernsystem.

Auf Seite des OSCI-Backend-Enablers werden identische Funktionen wie beim OSCI-Client-Enabler benötigt: Komplette (De-)Komposition und (De-)Chiffrierung sowie ggf. die Signatur-bildung und -prüfung von OSCI-Nachrichten – in diesem Fall über das Dokument-Interface und die Funktionen des VPS-Kernsystems.

Der OSCI-Backend-Enabler ist als Serverimplementierung des OSCI-Client-Enablers zu be-trachten – der sich im Unterschied zum Client der kryptografischen Funktionen einer Instanz des VPS-Kernsystems bedienen muss. Er stellt als J2EE-Server die Funktionalität des OSCI-Client-Enablers der Fachanwendung zur Verfügung.

Der OSCI-Backend-Enabler stellt eingangsseitig einem fachspezifischen Adapter die geprüf-te OSCI-Nachricht in einer Reihe von Objekten zur Verfügung:

• Auftragscontainer mit Zertifikaten und Prüfergebnissen


Feinkonzept FMS/VPS

• separates Prüfprotokoll inkl. der Ergebnisse aller Signaturprüfungen

• entschlüsselte OSCI-Content-Container

• ggf. zusätzlich übermittelte Attachments (beliebige Fremdformate)

• den Laufzettel des VPS-Kernsystems.

Das Mapping dieser Container in die jeweiligen Formate und Funktionen der Fachanwen-dung ist Sache des Adapaters (Fachadapter für den Posteingang), der i.d.R. fachspezifisch auszuimplementieren ist. Eine Default-Implementierung des Fachadapters für Posteingänge existiert und stellt Eingangsdaten (Metadaten, wie z.B. Laufzettel, Prüfprotokoll und Zertifika-te und die Inhaltsdaten) nach Entschlüsselung und Prüfung im Dateisystem zur Verfügung.

Für die Speicherung der einzelnen Dateien existiert eine Default-Einstellung, welche konfigu-riert werden kann.

Parallel zu diesem Fachadapter wird ein so genannter Persistence-Connector angeboten. Dieses Interface dient der Archivierung aus- und eingehender Nachrichten. Der Persistence-Connector soll diese dauerhaft im Sinne von Langzeitarchivierung speichern. Der Connector erhält den unveränderten OSCI-Datenstrom unmittelbar nach Transportentschlüsselung (bzw. vor Transportverschlüsselung). Somit werden die gespeicherten Daten des Persisten-ce-Connectors weder durch einen Parser noch durch andere Klassen verändert.

Dieser Connector dient also nicht der Extrahierung der Inhaltsdaten, sondern zum Langzeit-speichern für Nachweiszwecke und bei Bedarf nachträglicher Revalidierung von Signaturen. Die Revalidierung kann jederzeit mit dem VPS-Verifikationsmodul durchgeführt werden.


OSCI-Nachrichten können seitens des OSCI-Managers entweder „synchron“ zugestellt oder seitens des OSCI-Backend-Enablers „asynchron“ abgeholt werden:

• Synchrone Zustellung der OSCI-Nachrichten

Im Falle eines passiven OSCI-Backend-Enablers baut der OSCI-Manager eine aktive Verbindung zu diesem auf, um die Daten sowie die Ergebnisse der Verarbeitung (Laufzettel) an das Backend-System weiterzuleiten.

• Asynchrone Abholung der OSCI-Nachrichten

Im Falle der asynchronen Kommunikation initiiert der (aktive) OSCI-Backend-Enabler eine Verbindung zum OSCI-Manager, um dort zyklisch OSCI-Nachrichten abzu-fragen.

Der OSCI-Backend-Enabler öffnet anschließend mit Hilfe des VPS-Kernsystems den „inne-ren Briefumschlag“ der OSCI-Datensätze (Entschlüsselung), prüft implizit Signaturen (ma-


Feinkonzept FMS/VPS

thematische Prüfung der Signatur) und Vertrauenswürdigkeit des Kommunikationspartners über die OSCI-Mechanismen und bereitet die jetzt im Klartext vorliegenden Nutzdaten zur weiteren Verarbeitung im Hintergrundsystem der empfangenden Behörde auf. Der OSCI-Backend-Enabler kann die Daten dabei entweder als unveränderte OSCI-Nachricht (über Persistence-Connector, Inhaltsdaten sind noch auf Inhaltsdatenebene verschlüsselt) oder als geprüfte Inhalts- und Metadaten entweder einem Dateisystem (auch Netzwerkverzeichnis) oder einer Datenbank zur Verfügung stellen.

3

3.1

SYSTEMARCHITEKTURANALYSE FÜR FMS-VPS Dieser Abschnitt stellt mögliche Architekturalternativen einer VPS-Lösung für FMS dar. Da-bei wird beschrieben, welche Alternative aufgrund der Schutzbedarfsanforderung der Formu-lardaten eingesetzt werden soll.

Architekturalternativen für die VPS-FMS Lösung in Bezug auf Datensicherheit Zum Zeitpunkt der Erstellung dieses Feinkonzepts ist nicht bekannt, zu welchem Zwecke die eFormulare im konkreten Fall bestimmt sind, welchen Sensitivitätsgrad sie besitzen und wel-che Daten tatsächlich von einem Bürger in die jeweiligen eFormulare eingetragen werden. In Bezug auf die Sicherheitsziele Vertraulichkeit, Integrität und Authentizität wurden im IT-Rahmensicherheitskonzept (IT-Rahmen-SiKo) für FMS Schutzbedarfsklassen für die IT-Daten entwickelt. Ausgehend von der Schutzbedarfsklassifizierung der Daten kann bestimmt werden, ob die VPS zum Einsatz kommt und welches konkrete VPS-Betriebsszenario dabei einzuplanen ist.

Im Sinne des Feinkonzepts können daraus folgende „Klassen“ abgeleitet werden:

• FMS-Daten müssen bis zur Übergabe des FMS-Systems vertraulich behandelt werden

o Für den Datenkanal Client-FMS muss mindestens eine Kanalverschlüsselung (z.B. SSL) verwendet werden.

Die hier gestellten Anforderungen können ohne Einsatz der VPS durch die FMS-Basislösung realisiert werden.

• FMS-Daten müssen vertraulich behandelt werden und dürfen nur vom Empfän-ger (Behörde) eingesehen werden

o Die FMS-Daten müssen für den Empfänger verschlüsselt werden und dürfen im FMS-System nicht im Klartext gespeichert oder verarbeitet werden

o Die FMS-Lösung muss eine „mandantengerechte“ Speicherung und Verarbei-tung der Daten gewährleisten, der unberechtigte Zugriff eines Mandanten in einem anderen Mandantenbereich muss sicherheitstechnisch ausgeschlossen werden.


Feinkonzept FMS/VPS

Die hier gestellten Anforderungen müssen durch Einsatz der VPS realisiert wer-den. Hier ist die Architekturvariante „Online-Web mit OSCI-Backend-Enabler bei Behörde“ vorzusehen.

• FMS-Daten unterliegen einer Schriftformerfordernis, es werden keine hohen Si-cherheitsanforderungen an die Vertraulichkeit gestellt

o Die FMS-Daten müssen signiert werden (bei Rechtsverbindlichkeit mit qualifi-zierter elektronischer Signatur)

Die hier gestellten Anforderungen müssen durch Einsatz der VPS realisiert wer-den. Allerdings gilt für Vertraulichkeit kein hoher Schutzbedarf. Hier sind ver-schiedene Architekturalternativen (auch ein zukünftiges Einsatzszenario mit „OSCI-Backend-Enabler bei FMS“) denkbar.

• FMS-Daten unterliegen einer Schriftformerfordernis und müssen bis zum Emp-fänger vertraulich behandelt werden

o Die FMS-Daten müssen signiert werden (bei Rechtsverbindlichkeit mit qualifi-zierter elektronischer Signatur)

o Die FMS-Daten müssen für den Empfänger verschlüsselt werden und dürfen im FMS-System nicht im Klartext gespeichert oder verarbeitet werden

o Die FMS-Lösung muss eine „mandantengerechte“ Speicherung und Verarbei-tung der Daten gewährleisten, der unberechtigte Zugriff eines Mandanten in einem anderen Mandantenbereich muss sicherheitstechnisch ausgeschlossen werden

Die hier gestellten Anforderungen müssen durch Einsatz der VPS realisiert wer-den. Hier ist die Architekturvariante „Online-Web mit OSCI-Backend-Enabler bei Behörde“ vorzusehen.


Feinkonzept FMS/VPS

3.2 Online-Web mit OSCI-Backend-Enabler bei Behörde

3.2.1 Systemarchitektur

Abbildung 3: Online-Web mit OSCI (OSCI-Backend-Enabler bei Behörde)

3.2.2 Beschreibung der Lösung

Nach Online-Bearbeitung des eFormulars und Versand wird das eFormular serverseitig durch FFW (Beschreibung siehe 2.1) plausibilisiert und als geprüftes eFormular dem OSCI-Client übergeben. Die Bearbeitung und der Versand über den OSCI-Client erfolgt wie in 2.3.1 beschrieben. Die serverseitige Bearbeitung durch den FMS-internen OSCI-Manager erfolgt wie unter 2.3.2 beschrieben. Anschließend werden die OSCI-Nachrichten vom OSCI-Backend-Enabler abgeholt. Die Abholung der OSCI-Nachrichten durch den OSCI-Backend-Enabler des Mandanten erfolgt wie unter 2.3.4 beschrieben. Über den im OSCI-Backend-Enabler vorhandenen fachspezifischen Adapter (Beschreibung siehe 2.3.4 ) werden die Da-ten dem Fachverfahren der Behörde zugeführt.

Für diese Lösung gilt, dass jede Behörde eine zusätzliche Komponente (OSCI-Backend-Enabler inkl. VPS-Kern-System und fachspezifischen Adapter) selbst betreiben muss. Ein alternatives Lösungsszenario mit OSCI-Client-Enabler wird im Abschnitt 6.4.2 beschrieben.


Feinkonzept FMS/VPS

3.3 Offline mit OSCI

3.3.1 Systemarchitektur

Abbildung 4: Offline-Bearbeitung mit OSCI (hier: OSCI-Backend Enabler bei Behörde)

3.3.2 Beschreibung der Lösung

Als Offline-Variante der FFW-Lösung wird der Offline-Filler angeboten. Aus Sicht der VPS-Integration besteht bei Einsatz der Offline-Variante im Vergleich zur Online-Variante kein funktionaler Unterschied, da die Plausibilität der übertragenen Daten für beide Varianten serverseitig geprüft werden, bevor die Daten anschließend der VPS übergeben werden. Da-mit sind beide Varianten aus Sicht der VPS-Integration als gleich anzusehen.

4 SOFTWAREARCHITEKTUR Dieser Abschnitt beschreibt die notwendige Softwarearchitektur der VPS für das FMS-System anhand eines Sequenzdiagramms. Dabei werden die Zusammenhänge zwischen Prozessen und den prozessorientierten Objekten dargestellt.


Feinkonzept FMS/VPS

Sequenzdiagramm 4.1

Antra

gsan

nahm

eO

nlin

e-W

eb m

it O

SCI

(Bac

kend

-Ena

bler

bei

Behö

rde)

Sta

rt, A

nwen

dung

des

OSC

I-Clie

nts

und

Dat

enüb

erm

ittlu

ng z

um F

MS

OSC

I-M

anag

er

Browser JWS OSCI-Client FFW FMS OSCI-Manager Behörde Portal (Login-Module)

OSCI-Backend-Enabler(incl. Adapter und VPS-

Kern)Fachverfahren Behörde

am Portal der Behörde anmelden (Aufruf http-URL)()

eFormular anzeigen (leer)()

Portal Behörde anzeigen (http-Webseite)()

eFormular senden (mit VPS)()

Plausibilitätsprüfung starten und durchführen()

OSCI-Nachricht senden()

Zertifikatsprüfung anfordern()

OCSP/CRL-Relay

Prüfergebnis übermitteln (OCSP-Information)()

OSCI-Nachricht entschlüsseln, prüfen()

efor

mul

ar a

usfü

llen(

)

Ergebnis der Plausibilitätsprüfung übersenden()

Ant

rags

stel

lung

Onl

ine-

Web

mit

OS

CI b

is z

um S

tart

des

OS

CI-C

lient

s

Visualisieren, Signieren, Dateianhänge anfügen, Verschlüsseln()

OSCI-Nachricht anfordern

OSCI-Nachricht übersenden()

Nachrichten-Inhalte an das Fachverfahren übergeben

Prüfung der Integrität der Bilddatei und XML-Daten

Erzeugung eines TIFFs, elektronische Signierung des TIFFs

Start OSCI-Client()

Zertifikatsprüfung()

Aufruf eFormular (http-Link)()

eFormular bereitstellen()

Abfrage Software-Update()

Software-Update übersenden()

Start OSCI-Client über JWS (JNLP)()

Aufruf JWS()

Initialprozess zum Start des OSCI-Client über JWS()

Daten speichern()

Abbildung 5: Sequenzdiagramm FMS-VPS


Feinkonzept FMS/VPS

Prozessorientierte Objekte 4.2

4.3

Die im Sequenzdiagramm verwendeten „Objekte“ sind funktionale Komponenten der FMS-Lösung die aus Sicht der VPS-Integration an den relevanten Prozessen beteiligt sind. Dabei wird insbesondere das FMS-Basissystem, das Produkt FormsForWeb (FFW), transparent als „Black-Box“ verstanden. VPS-unspezifische, nicht relevante Prozesse, Schnittstellen und Funktionen können auf diese Weise zur Vereinfachung der Darstellung ausgeblendet wer-den. Diese Prozesse und Funktionen müssen, soweit erforderlich, im Feinkonzept des FMS dokumentiert werden und sind nicht Bestandteil dieses Dokuments zur VPS-Integration.

Folgende Objekte werden im Sequenzdiagramm unterschieden:

Clientbereich des Bürgers:

• Browser (Beschreibung siehe 6.1.6 )

• Java Webstart (Beschreibung siehe 6.1.5 unten )

• OSCI-Client (Beschreibung siehe 2.3.1 oben )

FMS-Bereich:

Als FMS gilt das Gesamtsystem, dies wird hier objektorientiert unterteilt in:

• FFW (FMS-Basissystem FormsForWeb, Beschreibung siehe 2.1)

• OSCI-Manager für FMS, incl. VPS-Kernsystem (Beschreibung siehe 2.3.2 oben )

Externer zentraler Dienstleistungsbereich:

• OCSP/CRL-Relay (Beschreibung siehe 2.3.3 oben )

Behörden- (Mandanten-)bereich:

• Webportal der Behörde

• OSCI-Backend-Enabler für Behörden (Beschreibung siehe 2.3.4 oben )

• Fachverfahren der Behörde

Sicherstellung der semantischen Gleichheit von XML- und Bild-Daten Aus Gründen der „medienbruchfreien“ Abwicklung der elektronischen Formulartransaktionen ist es wünschenswert, behördenseitig XML und Stylesheets (XSL) zu verwenden. Im Zu-sammenhang mit qualifizierten elektronischen Signaturen entsteht dabei aber das Problem, dass ein entsprechender sicherer Viewer (im Sinne der Anforderungen des SigG/SigV) mit vertretbarem Aufwand nicht evaluierbar ist. Die qualifizierte elektronische Signatur von durch FMS erzeugten Dateien XML-Dateien verursacht ohne evaluierten sicheren Viewer für den „Normalnutzer“ ein Restrisiko, das im „klassischen“ Verwaltungshandeln nicht entsteht. Hin-gegen sind Bildformate – hier vor allem TIFF-Dateien – im Sinne der Anforderungen des SigG/SigV sicher darstellbar und daher gut evaluierbar.


Feinkonzept FMS/VPS

Vor dem Hintergrund der Entwicklung des FMS/VPS-Clients wurde daher nachfolgend be-schriebene Lösung erarbeitet, die sowohl den Anforderungen der Behörden an eine nahtlose Verarbeitung der XML-Daten als auch den Sicherheitsanforderungen der Bürger gerecht wird.

Die zur Sicherstellung der Integrität der XML- und Bild-Daten notwendigen Prozessschritte laufen zwischen FFW, OSCI-Client, OSCI-Manager und OSCI-Backend-Enabler wie folgt ab:

1. FFW erzeugt aus den XML-Daten des eFormulars ein TIFF-Bild (Abbildung der elekt-ronisch weiterverarbeitbaren Daten in eine nicht elektronisch weiterverarbeitbare Dar-stellung, die aber qualifiziert elektronisch signiert werden kann).

2. FFW signiert fortgeschrittenen zusammen XML-Daten und TIFF-Bild.

3. Der OSCI-Client lädt alle Daten über JWS.

4. Der OSCI-Client visualisiert das TIFF-Bild und der Bürger signiert es qualifiziert.

5. Der OSCI-Client überträgt die fortgeschrittene Signatur, die qualifizierte Signatur so-wie TIFF-Bild und XML-Daten mittels OSCI an den OSCI-Manager.

6. Der OSCI-Manager prüft über das OCSP/CRL-Relay den Online-Status der Zertifika-te (fortgeschritten und qualifiziert).

7. Der OSCI-Backend-Enabler des Fachverfahrens holt die OSCI-Nachricht vom OSCI-Manager und prüft die Signaturen mathematisch.

8. Im fachspezifischen Adapter des OSCI-Backend-Enablers ist zu überprüfen, ob die fortgeschrittene Signatur von einem autorisierten FFW angebracht wurde.

9. Im fachspezifischen Adapter des OSCI-Backend-Enablers ist die Identität des qualifi-ziert signierten Bildes und des fortgeschritten signierten Bildes zu überprüfen.

Die beschriebenen Schritte stellen sicher, dass die vom FFW an den OSCI-Client des Bür-gers und von diesem an den OSCI-Backend-Enabler der Behörde geschickten TIFF- und XML-Daten nicht manipuliert werden können. Weiterhin wird sichergestellt, dass der Bezug zwischen den elektronisch weiterverarbeitbaren XML-Daten und dem nicht weiterverarbeit-baren TIFF-Bild erhalten bleibt. In diesem Sinne wird eine „semantische Gleichheit“ zwischen den XML-Daten und den TIFF-Bild gewährleistet.

Für die fortgeschrittene Signatur muss der FMS-Betreiber ein entsprechendes elektronisches Zertifikat beantragen und im FFW installieren. Damit der Online-Status Zertifikat durch den OSCI-Manager respektive das OCSP/CRL-Relay geprüft werden kann, bietet sich bspw. ein X.509-Zertifikat der PKI-1-Verwaltung an. Die notwendigen Überprüfungen im fachspezifi-schen Adapter des OSCI-Backend-Enablers sollen als Funktionsmodul zur Verfügung ge-stellt werden, welches dann von der Fachanwendung aufgerufen werden muss. Das Zertifi-kat des FMS-Betreibers ist dort für die Prüfung der Autorisation abzulegen.


Feinkonzept FMS/VPS

Prozessbeschreibung 4.4 Das Sequenzdiagramm stellt den Prozess einer Online-Web Antragstellung und Antragsan-nahme über OSCI-konforme VPS-Mechanismen dar.

Das Sequenzdiagramm stellt folgende Hauptprozesse dar:

• Antragsstellung Online-Web mit OSCI bis zum Start des OSCI-Clients

4.4.1 Antragsstellung Online-Web mit OSCI bis zum Start des OSCI-Clients

• Start, Anwendung des OSCI-Clients und Datenübermittlung zum FMS-Intermediär

• Antragsannahme Online-Web mit OSCI (Backend-Enabler bei Behörde)

Dieser Prozess stellt dar, wie durch einen Bürger ein eFormular online aufgerufen, ausgefüllt und für die nachfolgenden, VPS-spezifischen Prozesse versendet wird.

Startprozess: Am Portal der Behörde anmelden (Aufruf http-URL)

Der Bürger ruft die Startseite des Webportals einer Behörde in seinem Browser über einen Link auf. Bei geschlossenen Benutzergruppen muss der Bürger sich bspw. ü-ber Login/Passwort an der portaleigenen Benutzerverwaltung authentisieren.

Portal Behörde (mit oder ohne Login) anzeigen (http-Webseite)

Dem Bürger wird über den Browser die Startseite des Behördenportals angezeigt.

Der Bürger kann sich über weitere Links andere Seiten des Behördenportals anzei-gen lassen.

Aufruf eFormular (http-Link)

Der Bürger möchte einen Antrag stellen.

Hierfür wird dem Bürger im Behördenportal ein Link auf ein eFormular der Behörde angezeigt. Dieses eFormular wird vom FFW verwaltet. Das eFormular wird über den Browser des Bürgers über einen Link aufgerufen.

eFormular bereitstellen

Das eFormular wird von FFW bereitgestellt und eventuell mit Einträgen vorgefüllt.

eFormular anzeigen (leer)

Das eFormular wird an Browser des Bürgers übertragen. Die Anzeige des eFormu-lars erfolgt ohne weitere Prüfung der Authentisierungsdaten (so genannter Anony-mous-Account).


Feinkonzept FMS/VPS

Nach Beschluss des ZID werden geschlossene Benutzergruppen nicht weiter betrachtet. Bei geschlossenen Benutzergruppen müsste über ein spezielles Login-Modul des FFW die Au-thentisierung bei dem Behördenportal überprüft werden.

eFormular ausfüllen

Das leere eFormular wird im Browser des Bürgers angezeigt.

Das eFormular kann ggf. auch vorausgefüllt sein, z.B. mit Adressdaten. Gem. Aussage von Lucom kann dies entweder über ein lokal verwaltetes XML-Formular vom Bürger selbst konfi-guriert werden oder die Daten können über das Login-Modul aus der Benutzerverwaltung des Behördenportals angefordert werden.

Der Bürger füllt die Eingabefelder des eFormulars aus.

eFormular senden (mit VPS)

Das ausgefüllte eFormular wird an FFW übermittelt. Es wird weiterhin die Information mit übertragen, dass dieses eFormular mit der VPS bearbeitet werden soll.

Plausibilitätsprüfung starten und durchführen

Nach serverseitiger Übernahme wird das eFormulars der Plausibilitätsprüfung zuge-führt.

Wie und in welchem Umfang die Plausibilisierung serverseitig erfolgt ist offen und Be-standteil der Realisierung der Ausbaustufe IV.

Die hier dargestellte Plausibilitätsprüfung der Daten erfolgt in der Annahme, dass eine Verbin-dung zur Behörde notwendig ist um z.B. Vergleichsdaten für eine solche Prüfung anzufordern.

Ergebnis der Plausibilitätsprüfung übersenden

Das Ergebnis der Plausibilitätsprüfung wird an FFW gesendet.

Erzeugung eines TIFFs, elektronische Signierung des TIFFs

FFW erzeugt aus den XML-Daten des eFormulars ein TIFF-Bild und signiert beide zusammen fortgeschrittenen (vgl. Schritte 1 und 2 in Abschnitt 4.3).

Endprozess: Initialprozess zum Start des OSCI-Client über JWS

FFW veranlasst anhand der Konfiguration des eFormulars einen Initialprozess zum Start des OSCI-Clients über JWS.

Diese Konfiguration kann hinsichtlich der Adressierung des Empfängers für die verschiedenen Einsatzszenarien des OSCI-Backend-Enablers unterschiedlich gestaltet sein. Nähere Informa-tionen hierzu werden im Abschnitt 6.4.3 beschrieben


Feinkonzept FMS/VPS

4.4.2 Start, Anwendung des OSCI-Clients und Datenübermittlung zum FMS-Intermediär

Dieser Prozess stellt dar, wie der OSCI-Client installiert und angewendet wird, wie eFormula-re über OSCI-konforme Mechanismen in Form von OSCI-Nachrichten sicher, integer und authentisch an das FMS übertragen werden und wie eine OSCI-Nachricht im FMS OSCI-Manager kryptografisch geprüft wird, um sie als geprüfte OSCI-Nachricht für die Abholung bereitzustellen.

Startprozess: Initialprozess zum Start des OSCI-Client über JWS

FFW veranlasst anhand der Konfiguration des eForumlars einen Initialprozess zum Start des OSCI-Clients über JWS.

Start OSCI-Client über JWS

An den Browser des Bürgers wird eine JNLP-Ressourcendatei mit den spezifischen Konfigurationsparametern für den OSCI-Client übermittelt.

Aufruf JWS

Der Browser startet JWS und übergibt diesem die JNLP-Ressourcendatei.

Abfrage Software-Update

JWS prüft, ob bzw. welche aktuelle Installation des OSCI-Clients vorhanden ist. Sollte eine Aktualisierung notwendig sein werden diese von FMS angefordert und installiert.

Über diesen gleichen Mechanismus werden nicht nur die Software und die Konfigura-tionsdateien geladen, sondern auch die formularabhängigen Daten (TIFF-Bild und XML-Daten, vgl. Schritt 3 in Abschnitt 4.3).

Software-Update übersenden

Die aktuellen Dateien werden an den PC übertragen und installiert.

Start OSCI-Client

Nach Installation oder Update wird der OSCI-Client automatisch gestartet.

Visualisieren, Signieren, Dateianhänge anfügen, Verschlüsseln

Nach Start des OSCI-Clients wird das TIFF-Bild über die Visualisierungskomponente angezeigt. Dabei wird über die Oberfläche des OSCI-Clients eine Bedienungsfunktion zur Verfügung gestellt, die das visualisierte Bild signiert. Lokale Dateien können als Attachments hinzugefügt werden. Alle Daten werden in einer OSCI-Nachricht ver-packt, verschlüsselt und OSCI-konform versendet (vgl. Schritt 4 in Abschnitt 4.3).

eFormular als OSCI-Nachricht senden


Feinkonzept FMS/VPS

Die OSCI-Nachricht (signiertes und verschlüsseltes TIFF-Bild sowie XML-Daten) wird an den FMS OSCI-Manager gesendet (vgl. Schritt 5 in Abschnitt 4.3).

Zertifikatsprüfung anfordern

Das Zertifikat der OSCI-Nachricht wird zur Zertifikatsprüfung über das VPS-Kernsystem an das OCSP/CRL-Relay übergeben.

Zertifikatsprüfung

Am OCSP-Relay werden die Zertifikate gegen bekannte Verzeichnisdiensteauskünfte eingebundener Trustcenter geprüft (vgl. Schritt 6 in Abschnitt 4.3).

Endprozess: Prüfergebnis übermitteln (OCSP-Information)

Das Prüfergebnis wird an den FMS OSCI-Manager zurückgegeben und für den de-signierten Empfänger bereitgestellt.

4.4.3 Antragsannahme Online-Web mit OSCI (Backend-Enabler bei Behörde)

Dieser Prozess stellt dar, wie eine vom FMS OSCI-Manager bereitgestellte OSCI-Nachricht von einem in der Behörde betriebenen OSCI-Backend-Enabler abgeholt, entschlüsselt und signatur-geprüft wird, die TIFF- und XML-Daten integritäts-geprüft werden und wie anschlie-ßend die Metadaten der OSCI-Nachricht und die Inhaltsdaten (TIFF- und XML-Daten) dem Fachverfahren der Behörde übergeben werden.

Startprozess: OSCI-Nachricht anfordern

Der OSCI-Backend-Enabler der Behörde verbindet sich mit dem FMS OSCI-Manager und fordert die für ihn verfügbaren OSCI-Nachrichten an (vgl. Schritt 7 in Abschnitt 4.3).

OSCI-Nachricht übersenden

Verfügbare OSCI-Nachrichten werden an den Backend-Enabler übermittelt.

OSCI-Nachricht entschlüsseln, prüfen

Der OSCI-Backend-Enabler öffnet die Transportsicherung und führt mit Hilfe des VPS-Kernsystems folgende kryptografische Operationen durch:

- Entschlüsselung

- mathematische Signaturprüfung der Signatur über die Inhaltsdaten

Anschließend werden die Daten einem fachverfahrensspezifischen Adapter überge-ben.

Prüfung der Integrität der Bilddatei und XML-Daten


Feinkonzept FMS/VPS

Im fachverfahrensspezifischen Adapter wird zum einen geprüft, ob die fortgeschritte-ne Signatur von einem autorisierten FFW angebracht wurde, und zum anderen wird die Integrität zwischen den elektronisch weiterverarbeitbaren XML-Daten und dem nicht weiterverarbeitbaren TIFF-Bild validiert (vgl. Schritte 8 und 9 in Abschnitt 4.3).

Nachrichten-Inhalte ans Fachverfahren übergeben

Der Adapter übergibt die Metadaten (alle Daten der OSCI-Transportebene, z.B. Zerti-fikate, Prüfprotokoll, Laufzettel) sowie das qualifiziert signierte TIFF-Bild und die fort-geschritten signierten XML-Daten dem Fachverfahren der Behörde.

Endprozess: Daten speichern

Die vom Adapter übergebenen Daten werden im Fachverfahren der Behörde gespei-chert.

4.5 Detaillierung der Nachrichtenflüsse Die o.a. Prozessbeschreibungen spezifizieren die Prozesse in Form von „Good Case“-Beschreibungen, d.h. es wird angenommen, dass alle Funktionen fehlerfrei ausgeführt wer-den.

Dabei wurden begleitende Detailbeschreibungen zur Darstellung der Nachrichtenflüsse, wie z.B. Bestätigungen, Protokollierungen, Fehlermeldungen nicht näher betrachtet.

Zur Unterstützung der Funktionstüchtigkeit des Gesamtsystems müssen daher zusätzliche Anforderungen festgelegt werden, die die Nachrichtenflüsse bei „Good Case“- und „Bad Ca-se“-Szenarien unterstützen.

Dieser Abschnitt beschreibt die im VPS-Prozess auftretenden Nachrichtenflüsse und Infor-mationstypen.

Prozessschritt/ -übergang

Art des Szenarios

Art der Information/ Beschreibung

Ausführende Komponente

FMS Online-Antragsverfahren bis zum Start des OSCI-Clients

Good Case Plausibilisierte eFormulardaten, Erzeu-gen einer TIFF-Bilddatei aus dem XML-Daten des eForumulars, Anbringen des Integritätsschutzes an die Bilddatei und XML-Daten, OSCI-Client wird gestartet, Daten werden über VPS Visualisie-rungskomponente angezeigt.

eFormular sen-den (mit VPS)

Bad Case Entweder HTTP Error Message (Feh-lermeldungen im Browser) oder FMS-spezifische Fehlermeldung/Abbruch

FFW


Feinkonzept FMS/VPS

des Vorgangs, Vorgang muss vom Benutzer wiederholt werden.

Start, Anwendung des OSCI-Clients und Datenübermittlung zum FMS Intermediär

Good Case Anzeige des TIFF-Bildes, Abfrage der Signatur-PIN, TIFF-Bild wird signiert, ggf. werden Dateianhänge angebracht, die gesamte OSCI-Nachricht wird ver-schlüsselt.

Visualisieren, Signieren, Datei-anhänge anbrin-gen, Verschlüs-seln

Bad Case Fehlermeldung des OSCI-Clients wird angezeigt, Vorgang muss vom Benut-zer wiederholt werden.

OSCI-Client

Good Case Empfangsquittung wird übermittelt. eFormular als OSCI-Nachricht senden

Bad Case Fehlermeldung wird übermittelt, Vor-gang muss vom OSCI-Client wiederholt werden. Danach Eskalation an den Benutzer und eventueller Abbruch.

OSCI-Manager

Good Case Prüfergebnis wird übermittelt. Zertifikatsprüfung anfordern Bad Case Fehlermeldung wird übermittelt. Vor-

gang muss wiederholt werden.

OCSP/CRL-Relay

Online-Web mit OSCI (Backend-Enabler bei Behörde)

Good Case OSCI-Nachricht incl. Laufzettel, TIFF-Datei, XML-Daten und Metadaten wer-den übermittelt

Da asynchron, OSCI-Backend-Enabler

OSCI-Nachricht anfordern

Bad Case Fehlermeldung, TIFF-Datei, XML-Daten und Metadaten werden nicht übermit-telt. Vorgang muss vom OSCI-Backend-Enabler wiederholt werden.

OSCI-Manager oder OSCI-Backend-Enabler (Bei Nichterreich-barkeit des OSCI-Managers)

Good Case TIFF-Datei, XML-Daten und Metadaten, werden an fachspezifischen Adapter übergeben.

OSCI-Nachricht entschlüsseln, prüfen

Bad Case Fehlermeldung; keine Entschlüsselung oder keine Signaturprüfung, OSCI-Nachricht verbleibt im Bereich des OSCI-Backend-Enablers.

OSCI-Backend-Enabler muss Fehler-meldung erzeugen und das Fachver-fahren in geeigneter Weise informieren.

OSCI-Backend-Enabler


Feinkonzept FMS/VPS

Good Case Prüfergebnis erfolgreich, TIFF-Datei, XML-Daten und Metadaten, werden zur fachspezifischen Verarbeitung überge-ben.

Prüfung der In-tegrität der Bild-datei und XML-Daten

Bad Case Fehlermeldung; Prüfergebnis schlägt fehl, OSCI-Backend-Enabler muss Fehlermeldung erzeugen und das Fachverfahren in geeigneter Weise informieren.

Fachadapter des OSCI-Backend-Enablers

Good Case TIFF-Bild, XML-Daten und Metadaten werden an Fachverfahren übergeben.

Nachrichten-Inhalte ans Fach-verfahren über-geben

Bad Case Fehlermeldung; OSCI-Nachricht ver-bleibt im Bereich des OSCI-Backend-Enablers. Das Fachverfahren muss in geeigneter Weise informiert werden.

Fachadapter des OSCI-Backend-Enablers

5

5.1

SCHNITTSTELLENÜBERSICHT UND –BESCHREIBUNG Dieser Abschnitt enthält eine zusammenfassende Übersicht über alle Schnittstellen zu der einzusetzenden VPS-Lösung gemäß den Ausführungen im Sequenzdiagramm. Es enthält für jede in der Übersicht identifizierte Schnittstelle eine Funktionsbeschreibung.

Identifizierung der VPS-spezifischen Schnittstellen

Sequenzschritt Involvierte Schnittstellenelemente Schnittstellenart

Erzeugung Bilddatei aus eFormu-lar und Sicherstellung der Integri-tät, Abfrage Software-Update und Software-Update übersenden

FFW – JWS Dialog

eFormular als OSCI-Nachricht senden

OSCI-Client – OSCI-Manager Daten

Zertifikatsprüfung anfordern und Prüfergebnis übermitteln (OCSP-Information)

OSCI-Manager – OCSP/CRL-Relay Dialog

Backend bei Behörde

OSCI-Nachricht anfor-dern/übersenden

OSCI-Backend-Enabler – OSCI-Manager

Dialog

OSCI-Nachricht entschlüsseln OSCI-Backend-Enabler – VPS- Dialog


Feinkonzept FMS/VPS

und prüfen Kernsystem

Prüfung der Integrität der Bildda-tei und XML-Daten

Fachspezifischer Adapter des OSCI-Backend-Enablers – FFW-Funktions-modul zur Integritätsprüfung

Dialog

eFormular und Metadaten über-geben

Fachspezifischer Adapter des OSCI-Backend-Enablers – Fachverfahren der Behörde

Ausgabe

Tabelle 1: Identifizierung der VPS-spezifischen Schnittstellen

5.2 Dialog FFW – JWS

Name Dialog FFW – JWS

Beschreibung: FFW erzeugt eine TIFF-Bilddatei aus den XML-Daten des eFormu-lars und signiert beide zusammen fortgeschritten, um die Integrität sicherzustellen. FFW stellt eine formularabhängige Konfiguration (u.a. Verschlüsselungszertifikat für die empfangende Behörde, Ad-resse des verwendeten OSCI-Managers) für den OSCI-Client zu-sammen. Der Browser startet JWS und übergibt diesem die JNLP-Ressourcendatei. JWS prüft, ob bzw. welche aktuelle Dateien des OSCI-Clients vorhanden ist. Sollte eine Aktualisierung notwendig sein werden diese von FMS angefordert und installiert. Die aktuellen Dateien werden an den PC übertragen und installiert.

Verwendung: Start eines OSCI-Clients zur elektronischen Signatur der Formular-Daten

Betroffene Systeme: PC des Bürgers – FFW-Server

Art der Schnittstelle: Synchron

Richtung der Schnittstelle: Lesend von JWS, schreibend von FFW

Häufigkeit der Aktivierung: Einmal pro zu signierendes eFormular

Datenvolumen/Aktivierung: Bisher keine Beschränkungen

Komplexitätsgrad: Standard

Anzeige oder Protokollierung: Systemprotokollierung von Client oder Server, serverseitig zusätzlich Log4J und Netzwerkprotokollierungen über die Firewall

Verzweigungsmöglichkeiten: Keine

Aktionen: Erstellen der Bilddatei aus den XML-Daten des eFormulars, beide werden zusammen fortgeschritten signiert

Übergabe der Ressourcendatei


Feinkonzept FMS/VPS

Prüfung der aktuellen Konfiguration des OSCI-Clients

Download der aktuellen Software

Installation der aktuellen Software und der aktuellen Konfiguration

Start des OSCI-Clients

Tabelle 2: Dialog FFW – JWS

5.3 Dialog OSCI-Client – OSCI-Manager

Name Dialog OSCI-Client – OSCI-Manager

Beschreibung: Siehe 2.3.1 und 2.3.2

Verwendung: Zustellung von OSCI-Nachrichten

Betroffene Systeme: OSCI-Client – OSCI-Manager

Art der Schnittstelle: Asynchron

Richtung der Schnittstelle: Schreibend von OSCI-Client, lesend von OSCI-Manager

Häufigkeit der Aktivierung: Einmal pro qualifiziert signiertem eFormular

Datenvolumen/Aktivierung: Bisher keine Beschränkung

Komplexitätsgrad Standard

Anzeige oder Protokollierung: OSCI-Client = Prüfprotokoll

OSCI-Manager = Log4J


Aktionen: Prüfung der Transport-ID über VPS-Kernsystem

Entschlüsselung/Verschlüsselung auf Transportebene über VPS-Kernsystem

Verwaltung der OSCI-Nachrichten in Bezug auf mandantenspezifi-sche Empfänger in Datenbank

Tabelle 3: Dialog OSCI-Client – OSCI-Manager

5.4 Dialog OSCI-Manager – OCSP/CRL-Relay

Name Dialog OSCI-Manager – OCSP/CRL-Relay


Feinkonzept FMS/VPS

Beschreibung: Siehe 2.3.2 und 2.3.3

Verwendung: Zertifikatsprüfung

Betroffene Systeme: OSCI-Manager


Richtung der Schnittstelle: Lesend und Schreibend

Häufigkeit der Aktivierung: Pro eingehender OSCI-Nachricht



Anzeige oder Protokollierung: Serverseitige Systemprotokollierung und Log4J, Netzwerkprotokol-lierung über die Firewall

Verzweigungsmöglichkeiten: Einholen von Statusinformationen zu einem Zertifikat oder einem Zeitstempel

Aktionen: Übergabe der Prüfobjekte an VPS-Kernsystem

Übergabe der Prüfobjekte an OCSP/CRL-Relay

Annahme der Prüfergebnisse an VPS-Kernsystem

Übergabe der Prüfergebnisse an OSCI-Manager

Tabelle 4: Dialog OSCI-Manager – OCSP/CRL-Relay

5.5 Dialog OSCI-Manager – OSCI-Backend-Enabler

Name Dialog OSCI-Manager – OSCI-Backend-Enabler

Beschreibung: Siehe 2.3.2 und 2.3.4.

Verwendung: Abholung oder Zustellung von OSCI-Nachrichten an die Behörden

Betroffene Systeme: OSCI-Manager – OSCI Backend Enabler

Art der Schnittstelle: Synchron oder Asynchron

Richtung der Schnittstelle: Synchron: vom OSCI-Manager schreibend, vom OSCI Backend Enabler lesend

Asynchron: vom OSCI-Manager lesend, vom OSCI Backend Enabler schreibend

Häufigkeit der Aktivierung: Asynchron: abhängig vom eingestellten Zeitintervall


Feinkonzept FMS/VPS

Synchron: bei jeder Zustellung von OSCI-Nachrichten



Anzeige oder Protokollierung: Serverseitige Systemprotokollierung und Log4J, Netzwerkprotokol-lierung über die Firewall

Verzweigungsmöglichkeiten: Derzeit keine

Aktionen: Empfang der OSCI-Nachrichten (synchroner Zustellungsauftrag oder asynchrone Abholung)

Übergabe oder Empfang von oder zum VPS-Kernsystem

Dekomposition der OSCI-Nachrichten

Übergabe an Adapter

Tabelle 5: Dialog OSCI-Manager – OSCI-Backend-Enabler

5.6 Dialog OSCI-Backend-Enabler – VPS-Kernsystem

Name Dialog OSCI-Backend-Enabler – VPS-Kernsystem

Beschreibung: Siehe 2.3.4

Verwendung: Entschlüsselung und mathematische Signaturprüfung eingehender OSCI-Nachrichten

Betroffene Systeme: OSCI-Backend-Enabler

VPS-Kernsystem

Kartenlesegerät

Optional: Chipkarte oder HSM-Modul mit Kryptoschlüssel


Richtung der Schnittstelle: Lesend




Anzeige oder Protokollierung: Serverseitige Systemprotokollierung und Log4J


Feinkonzept FMS/VPS


Aktionen: Prüfung und Entschlüsselung der OSCI-Nachricht auf Transportebe-ne

Entschlüsselung der Inhaltsdaten

Signaturprüfung

Ggf. Virenprüfung

Tabelle 6: Dialog OSCI-Backend-Enabler – VPS-Kernsystem

5.7 Dialog Fachspezifischer Adapter des OSCI-Backend-Enablers – FFW-Funktions-modul zur Integritätsprüfung

Name Dialog OSCI-Backend-Enabler – VPS-Kernsystem

Beschreibung: Siehe 4.3

Verwendung: Prüfung der Integrität der Bilddatei und XML-Daten

Betroffene Systeme: OSCI-Backend-Enabler – FFW


Richtung der Schnittstelle: Lesend und Schreibend






Aktionen: Überprüfung, ob die fortgeschrittene Signatur von einem autorisier-ten FFW angebracht wurde.

Überprüfung der Identität des qualifiziert signierten Bildes und des fortgeschrittenen signierten Bildes.

Tabelle 7: Dialog Fachspezifischer Adapter des OSCI-Backend-Enablers – FFW-Funktionsmodul zur

Integritätsprüfung


Feinkonzept FMS/VPS

5.8 Ausgabe Fachspezifischer Adapter des OSCI-Backend-Enablers – Fachverfahren der Behörde

Name Ausgabe Fachspezifischer Adapter des OSCI-Backend-Enablers – Fachverfahren der Behörde

Beschreibung: Der hier benannte Fachspezifische Adapter übernimmt die Aufgaben des in Abschnitt 2.3.4 beschriebenen Adapters mit folgenden be-sonderen Ausprägungen:

Der Adapter soll Daten der OSCI-Nachricht (Inhaltsdaten und Meta-daten) dem Fachverfahren der Behörde strukturiert zur Verfügung stellen.

Es ist davon auszugehen, dass für die Datenübernahme auch ein fachspezifischer Adapter seitens des Fachverfahrens der Behörde bereitgestellt wird.

Verwendung: Übergabe von Inhalts- und Metadaten an das Fachverfahren

Betroffene Systeme: OSCI-Backend Enabler – FFW

Art der Schnittstelle: Synchron oder Asynchron

Richtung der Schnittstelle: Schreibend vom OSCI-Backend Enabler

Häufigkeit der Aktivierung: Bei jedem Empfang von OSCI-Nachrichten

Datenvolumen/Aktivierung: Abhängig von der Größe der Nachricht und der Menge der einge-henden Nachrichten/Aktivierung des OSCI-Backend Enablers

Komplexitätsgrad Komplex

Eingabe: Serverseitige Systemprotokollierung und Log4J, Datenbankprotokol-lierung


Verzweigungsmöglichkeiten: Es ist zusätzlich möglich, die Funktion des Persistenzadapters zu verwenden (siehe Beschreibung 2.3.4)

Die Datenübergabe an das Fachverfahren kann über alternativer Verteilungsmechanismen gestaltet werden (z.B. Übergabe an Da-tenspeicher oder Webservice Schnittstelle).

Aktionen: Authentisierung am Fachverfahren

Strukturierte Übergabe der Inhalts- und Metadaten

Ggf. parallele Übergabe der persistenten OSCI-Daten an Fachver-fahren


Feinkonzept FMS/VPS

Speichern der Daten

Tabelle 8: Ausgabe Fachspezifischer Adapter des OSCI-Backend-Enablers – Fachverfahren der Be-

hörde

6

6.1

INTEGRATIONSPLAN Der Integrationsplan enthält konzeptionelle Rahmenbedingungen für den Zusammenbau des Systems aus technischer Sicht. Der Plan identifiziert dabei die Integrationsprodukte und er-läutert technische Voraussetzungen, Möglichkeiten und Einschränkungen ebenso wie die Organisation der Integration.

Unterstützte HW/SW-Einheiten und Kommunikationsprotokolle Im Folgenden werden die für die VPS notwendigen Hardware- und Softwareanforderungen der VPS beschrieben, die zusätzlich zum Betrieb des FFW notwendig sind.

6.1.1 Hardware

Die Systemplattform für den OSCI-Manager mit seiner Postfachkomponente besteht aus mindestens zwei Rechnern, auf denen neben dem OSCI-Manager mit Postfachkomponente, das VPS-Kernsystem und eine Datenbank betrieben werden.

Die Hardware-Anforderungen an die Rechner orientieren sich an der zu erwartenden maxi-malen Last und an dem zu erwartenden Volumen von Daten, die zwischengespeichert wer-den sollen.

Die Last ergibt sich aus der Anzahl von Nutzern, die gleichzeitig auf das System zugreifen. Bei höherer Last werden mehr CPU-, Speicher- und Netzwerk-Kapazitäten benötigt. Das Datenvolumen ergibt sich im Wesentlichen aus der Anzahl der teilnehmenden Klienten, der durchschnittlichen Dokumentengröße und der Dauer, für die die eFormulare maximal im Postfach aufbewahrt werden sollen.

Da die zu erwartende Last und das Volumen noch nicht konkret bestimmbar ist, können so-mit für die Hardware-Anforderungen keine konkreten Aussagen getroffen werden.

In einer ersten Ausbaustufe kann jedoch von folgenden Kenndaten ausgegangen werden, die die Rechner erfüllen sollten:

• CPU: Doppelprozessor mit min. 1 GHz

• (Intel Pentium oder vergleichbares RISC-System),

• RAM: mindestens 512 MB,


Feinkonzept FMS/VPS

• mindestens 120 GB Festplatten-Kapazität.

Zusätzlich zu den Rechnersystemen wird für den OSCI-Manager eine leistungsfähige Anbin-dung an das Internet benötigt. Die Anforderungen an das Netzwerk resultieren aus dem zu erwartenden Transfer-Volumen.

Dabei wird vorausgesetzt, dass die neuen IT-Systeme in eine bereits vorhandene Sicher-heitsinfrastruktur „eingebettet“ werden, wie sie beispielsweise in einem Rechenzentrum exis-tiert.

6.1.2 Betriebssystem und Softwareanforderungen

Im Wesentlichen kommen Java-Komponenten - Enterprise JavaBeans (EJB’s), Servlets, Java Server Pages - zum Einsatz, die im VPS-Release 1.1 und 2.0 eine zu folgenden Java-Spezifikationen kompatible Ablaufumgebung benötigen:

- Java 2 Standard Edition1 (J2SE) 1.4.2

- Java 2 Enterprise Edition2 (J2EE) 1.3

- Enterprise Java Beans (EJB)3 2.0

- Java Messaging Services4 (JMS) 1.1

- Java Managemnet Extensions5 (JMX) JMX 1.2

Die VPS-Implementierung selbst setzt auf JMX auf; der eingesetzte Application Server muss JMX uneingeschränkt unterstützen.

Für das Speichern und Verwalten von Konfigurations- und Nutzerdaten sowie Persistenzme-chanismen (JMS, Dokumente, OSCI-Postfächer) wird eines der aufgeführten Datenbankma-nagementsysteme eingesetzt.

Darüber hinaus wird für das Vorhalten konsistenter Logging- und Monitoring-Informationen ein Syslog-Server benötigt; die eingesetzten Betriebssysteme müssen dieses Feature unter-stützen. Die Generierung von Log-Meldungen basiert auf Jakarta Commons Logging in der Version 1.0.46. Unterstützt werden von dieser Zwischenschicht aktuell u.a. die Implementie-rungen des JDK1.4 und des verbreiteten Log4J7-Frameworks. Diese beiden Frameworks

1 http://java.sun.com/docs/books/jls/second_edition/html/j.title.doc.html 2 http://java.sun.com/j2ee/1.3/download.html#platformspec 3 http://java.sun.com/products/ejb/docs.html 4 http://java.sun.com/products/jms/docs.html 5 http://java.sun.com/products/JavaManagement/reference/docs/index.html 6 http://jakarta.apache.org/commons/logging 7 http://logging.apache.org/log4j/docs/documentation.html


Feinkonzept FMS/VPS

werden von Commons Logging automatisch erkannt. Syslog-Server können hier über pas-sende Appender angebunden werden.

Die Releases der Basisprodukte sind die minimal benötigten; Nachfolgereleases werden zeitnah unterstützt werden. Dazu erfolgt eine explizite Freigabemitteilung.

Nr. Betriebssystem JDK Application Server JMS DBMS 1 SUSE LINUX 8.x SUN

1.4.2_03 JBoss 3.2.5 inkl. Tomcat 5.0.26

JBoss MQ MySQL 4.1

2 SUSE LINUX 9.x SUN 1.4.2_04

JBoss 3.2.5 inkl. Tomcat 5.0.26

JBoss MQ MySQL 4.1

3 Windows 2003 Server

SUN 1.4.2_04


JBoss MQ MySQL 4.1

4 Red Hat Linux 9.0 SUN 1.4.2_04


JBoss MQ MySQL 4.1

5 Linux SUSE 9.x SUN 1.4.2_04


JBoss MQ Oracle 10g Rel.1 (10.1.0.3)

6 Windows 2003 Server

SUN 1.4.2_04



7 Solaris 9.x SUN 1.4.2_04



Das System wird ab Quartal 2/2005 auf die folgend aufgeführten Plattformen portiert; nach erfolgter Abnahme erfolgt eine explizite Freigabemitteilung 8 Solaris 9.x SUN

1.4.2_04 Oracle Application Server Containers for J2EE 10g (10.1.3) ; « OC4J »

Oracle Applica-tion Server JMS (OracleAS JMS).

Oracle 10g Rel.1 (10.1.0.3)

9 Solaris 9.x IBM 32-bit JDK 1.4.1 for Solaris

IBM WebSphere8 Applica-tion Server 6.0

IBM Web-Sphere MQ 5.3

IBM DB2 Universal Database 8.1

10 Red Hat Linux 9.0 IBM SDK 1.4.1 SR1

IBM WebSphere Applica-tion Server 6.0

IBM Web-Sphere MQ 5.3

IBM DB2 Universal Database 8.1

8 Der IBM WebSphere Application Server ist auch für andere Betriebssysteme verfügbar, siehe: http://www-306.ibm.com/software/webservers/appserv/was/requirements


Feinkonzept FMS/VPS

Nr. Betriebssystem JDK Application Server JMS DBMS 11 SUSE LINUX 9.x SUN

1.4.2_04 JBoss 3.2.6 inkl. Tomcat 5.0.26

JBoss MQ IBM DB2 Universal Database 8.1

Tabelle 9: Unterstützte Kombinationen von Ablaufumgebungen

Das SUN-JDK in den Versionen 1.4.2_05 und 1.4.2_06 wird von den VPS-Serverkomponen-ten ebenfalls unterstützt.

6.1.3 Unterstützte Signaturkarten und Kartenlesegeräte:

Da die Entwicklung des OSCI-Client-Enablers auf Basis des Governikus der Firma bos reali-siert wird, werden alle Signaturkarten unterstützt, die heute schon im Governikus implemen-tiert sind und dem Signaturniveau „qualifizierte Signatur“ gemäß Anforderungen SigG ent-sprechen.

Diese sind bei bos unter http://www.bos-bremen.de/produkte/karten_u_zertifikate.php ge-listet.

Gleiches gilt für die Unterstützung der Kartenlesegeräte, deren aktuelle Liste unter http://www.bos-bremen.de/produkte/leser.php ersichtlich ist.

6.1.4 Java Runtime Environment

Zur Ausführung der Java Web Start Anwendungen ist das Vorhandensein einer Java Runti-me Environment (JRE) ab Version 1.4.2_03 unbedingt erforderlich. Sollte die JRE auf dem gewünschten Rechner dennoch nicht existieren, besteht die Möglichkeit, das Softwarepaket kostenlos aus dem Internet auf den Rechner des Benutzers herunter zu laden. Der Hersteller SUN Microsystems Inc. bietet unter der Internet-Adresse http://java.sun.com/products/ archive/j2se/1.4.2_03/index.html einen kostenlosen Download an.

6.1.5 Java Web Start (JWS)

Durch die Verwendung von Java Web Start (JWS) wird die Client-Anwendung (Java-Anwendung) auf dem lokalen Rechner des Benutzers gestartet.

JWS hat den Vorteil, dass unabhängig von Betriebssystem und Internetbrowser die Java-Anwendung über einen Hyperlink gestartet werden kann. JWS ist ein von SUN Microsystems Inc. kostenlos bereitgestelltes Produkt. JWS basiert auf dem Java Network Launch Protokoll (JNLP); ein Webserver beantwortet einen JNLP-Link mit der Auslieferung der „JNLP-Datei“ (MIME-Type „application/x-java-jnlp-file jnlp“) an den Browser. Der MIME-Type JNLP veran-lasst den Browser, beim Empfang einer JNLP-Response eine externe Java Virtual Machine (JVM) mit den im JNLP-File aufgeführten Ressourcen und Parametern zu starten.


http://www.bos-bremen.de/produkte/karten_u_zertifikate.php

http://www.bos-bremen.de/produkte/leser.php

http://java.sun.com/products/archive/j2se/1.4.2_03/index.html

http://java.sun.com/products/archive/j2se/1.4.2_03/index.html

Feinkonzept FMS/VPS

Beim Start einer JWS-Anwendung wird überprüft, ob sich durch einen vorangegangenen Programmstart bereits benötigte Ressourcen auf dem PC befinden. Über den JWS-Server wird ermittelt, ob dort aktuellere Versionen des jeweiligen Moduls hinterlegt sind. JWS sorgt für den Download nur der fehlenden oder aktuelleren Ressourcen, vorhandene aktuelle Mo-dule werden dagegen nicht erneut geladen. Dies verringert für die Nutzer Ladezeiten und erleichtert die Distribution der JWS-Anwendungen.

6.1.6 Browser

Die eigentliche Java Web Start-Anwendung funktioniert grundsätzlich unabhängig von einem Browser. Da der Aufruf des OSCI-Client-Enablers über eine Online-Anwendung als Verknüp-fung (URL) integriert ist, benötigen die Nutzer einen gängigen Internet-Browser.

Aufgrund der C++ Programmierung des Offline-Fillers können bei Nutzung des Offline-Fillers nur Browser unter Windows Betriebssystemen zum Einsatz kommen.

In der "Windows-Welt“ sind dies z.Z. Microsoft Internet Explorer ab Version 5.5, Netscape ab Version 7.0 sowie Firefox.

Bei Nutzung der Online-Variante können bei Verwendung des Betriebssystems Linux auch Netscape oder Firefox verwendet werden.

6.2 Festlegung der Hard- und Softwareanforderungen Folgende Hardware- und Softwarekomponenten sollen für die Referenzimplementierung des FMS genutzt werden:

Komponente Produkt

Applikationsserver für OSCI-Manager inkl. VPS-Kernsystem

Primergy FSC RX 300 Dual Prozessor 2 HE

OSCI-Datenbank-Server



http://vilpublic.fujitsu-siemens.com/vil/pc/vil/primergy/model_line_200/server_2003/dbl_prim-rx300_d.pdf


Feinkonzept FMS/VPS

Komponente Produkt

Webserver für Start Portal und SW-Deployments für Clients Vorhandener Webserver des FMS oder CMS

OSCI-Backend-Enabler inkl. VPS-Kernsystem mit fachspezifischen und mandantenfähigen Adapter


Zugelassenes Kartenlesegerät Produktauswahl noch offen

Zugelassene Signaturkarte Produktauswahl noch offen

Datenbank DB-Software (ORACLE Enterprise Edition - Oracle 9.i Server Rel.2 - 9.2.0)

Firewall Firewallsoftware (SuSe, F1)

Betriebssystem OS Suse Linux ES-8, Pflege Support für 5Jahre pro Maschine bis 8 CPU)

JDK SUN 1.4.2_03

Application Server JBoss 3.2.2 inkl. Tomcat 4.1.27

JMS JBoss MQ

OSCI-Manager VPS 2.0 Software, Standardausführung

VPS-Kernsystem VPS 2.0 Software, Standardausführung

OSCI-Client-Enabler VPS 2.0 Software, Standardausführung

OSCI-Backend-Enabler SDK (API) VPS 2.0 Software

Tabelle 10: Hard- und Software-Komponenten für die Referenzimplementierung

6.3 Anforderungen an den FMS-spezifischen OSCI-Client Die nachfolgenden Anforderungen an den FMS-spezifischen OSCI-Client werden funktionell, technisch, sicherheitstechnisch und organisatorisch unterschieden.



Feinkonzept FMS/VPS

6.3.1 Funktionale Anforderungen

In diesem Abschnitt werden die funktionalen Mindestanforderungen an einen OSCI-Client für FMS beschrieben. Alle Anforderungen können unter Verwendung des OSCI-Client-Enablers erfüllt werden. Dabei wird vorausgesetzt, dass für die Bedienung der geforderten Funktionen eine entsprechende Benutzeroberfläche mit Interaktionsbereichen zur Verfügung steht (vgl. z.B. Govello, EGVP, o.ä.). Die Anforderungen an eine solche Bedien- und Benutzungsober-fläche sind nicht Bestandteil der hier dargestellten Anforderungen.

6.3.1.1 Visualisierungskomponente Der OSCI-Client muss über eine Visualisierungskomponente verfügen, mit der das zu signie-rende Dokument vor der Signatur dargestellt und vom Benutzer damit auf Richtigkeit über-prüft werden kann. Hierzu ist die Visualisierungskomponente des Client-Enablers zu ver-wenden. Diese unterstützt folgende für das Szenario „Signatur eines Web-Formulars“ not-wendigen Funktionen:

• Anzeigen von OSCI-Nachrichten

• Anzeigen von XML-Daten und Aufbereitung durch eine XSLT-Transformation

• Anzeigen von einigen Binärdaten wie z.B. die in Java integrierten Bildformate (Anzei-ge anderer Dokumentenformate über Standardviewer)

• Anstoßen der Signatur von Inhaltsdaten

• Speichern von OSCI-Nachrichten

• Drucken von OSCI-Nachrichten

6.3.1.2 Signaturkomponente Die Signaturkomponente dient dazu, das zuvor visualisierte Dokument digital zu signieren. Die erforderliche Funktionalität wird durch den Client-Enabler erbracht. Dies betrifft auch die unterstützten Signaturniveaus und Signaturkarten.

Der Benutzer muss die Möglichkeit haben, sowohl (qualifiziert) signierte als auch unsignierte Dokumente zu versenden. Sofern eine qualifizierte Signatur aus rechtlichen Gründen erfor-derlich ist (Schriftform), ist eine Fehlermeldung zu generieren, wenn ein unsigniertes Fomu-lar übersendet werden soll. Der OSCI-Client muss abhängig von der Konfiguration in der Lage sein, Container- und/oder Dokumentsignaturen anzubringen bzw. zusätzliche lokale Attachments in die Nachricht aufzunehmen und auf Wunsch auch mitzusignieren.


Feinkonzept FMS/VPS

6.3.1.3 Sendeprotokoll und Übermittlungsbeleg Der OSCI-Client muss ein Sendeprotokoll erstellen und zusammen mit einer Kopie des vom Benutzer signierten Dokuments auf dem System des Benutzers ablegen. Des Weiteren muss der OSCI-Client einen vom OSCI-Manager eventuell erstellten Übermittlungsbeleg ebenfalls auf dem System des Benutzers ablegen. Diese Daten müssen dem Benutzer in geeigneter Form aufbereitet dargestellt werden.

6.3.2 Technische Anforderungen

In diesem Kapitel werden technische Anforderungen an den OSCI-Client, an den Download und die Installation beschrieben. Bei dem Client handelt es sich um ein Java-Programm, welches über das Protokoll JNLP geladen und aktualisiert wird.

6.3.2.1 Konfigurierbarkeit Es muss möglich sein, dass der OSCI-Client gleichzeitig in verschiedenen Konfigurationen auf dem System des Benutzers installiert werden kann, damit der Benutzer z.B. mit ver-schiedenen Behörden kommunizieren kann. Z.B. muss in Abhängigkeit des vom Benutzer aufgerufenen eFormular die richtige Auswahl des Empfängers und Empfängerzertifikats ge-währleistet werden. Es ist auch davon auszugehen, dass Behörden verschiedene Konfigura-tionen des OSCI-Clients anbieten werden. Eine solche Konfiguration besteht aus eigenen Konfigurationsdateien und Verweisen auf die gemeinsamen Komponenten.

6.3.2.2 Modularisierbarkeit Da der OSCI-Client in verschiedenen Konfigurationen benötigt werden wird, ist es erforder-lich, dass gemeinsam benötigte Komponenten auch nur einmal geladen werden und nicht bei jeder verschiedenen Konfiguration das komplette Programm neu vom Server geladen werden muss. Dies ist insbesondere wichtig, da die von jedem Client benötigten Kernkom-ponenten eine Größe von mehreren Megabyte besitzen.

Dies kann bei JNLP durch den Einsatz von Extension Resources erreicht werden, da in die-sem Fall die bei nur einem JNLP-File notwendige Beschränkung auf einen Host und glei-chem Ersteller der Signaturen von JAR-Files entfällt.

6.3.2.3 Parallelisierbarkeit Es sollte möglich sein, verschiedene Konfigurationen des OSCI-Clients gleichzeitig laufen zu lassen. Dies ergibt sich insbesondere daraus, dass der Benutzer voneinander unabhängige Web-Seiten von verschiedenen Institutionen gleichzeitig aufrufen könnte.


Feinkonzept FMS/VPS

6.3.3 Sicherheitstechnische Anforderungen

6.3.3.1 Authentizität der Programme Da es sich um ein Programm handelt, welches in hohem Maße mit sensiblen Informationen umzugehen hat, muss sich der Benutzer auf die Authentizität der geladenen Programme verlassen können. Daher müssen die Programme signiert ausgeliefert werden. Dies ist zu-dem notwendig, um nach dem Sicherheitsmodell von Java und JNLP unbeschränkten Zugriff auf den Rechner des OSCI-Clients zu erlangen.

6.3.3.2 Authentizität und Vertraulichkeit der dynamischen Daten Beim Aufruf des OSCI-Clients werden dynamische Daten wie z.B. Konfigurationsdaten für den OSCI-Client benötigt. Ebenso können auch Formulardaten oder andere vertrauliche Da-ten mittels JAR-Dateien über JNLP an den OSCI-Client übertragen werden. Ist Vertraulich-keit notwendig, so ist eine Übertragung der JAR-Dateien per https einzurichten. Wird ledig-lich Authentizität benötigt, kann zwischen einer Übertragung mittels https oder einer Signatur der JAR-Dateien gewählt werden. Eine Übertragung der JAR-Dateien mittels https ist mit der Version 1.4.2 oder höher des JRE möglich.

6.3.3.3 Authentizität der Kommunikationspartner Die Authentizität der Kommunikationspartner muss gewährleistet werden. Insbesondere muss sich der Benutzer vergewissern können, dass die Kommunikation tatsächlich mit dem gewünschten Kommunikationspartner stattfindet. Hierzu dienen Zertifikate.

Die Daten des Kommunikationspartners für den OSCI-Client (Intermediär, Empfänger, etc) sind Bestandteil der dynamischen Daten. Diese müssen also authentisch sein und daher entweder in signierten JAR-Dateien enthalten sein oder per https übertragen werden.

Die Authentizität des Benutzers gegenüber der Fachanwendung wird durch seine Signatur gewährleistet.

6.3.4 Organisatorische Anforderungen

Damit die gleichen Module des Programms bei der Nutzung verschiedener OSCI-Clients nicht mehrfach geladen werden müssen, ist eine zentrale Download-Verwaltung notwendig. Um einen zentralen Download zu ermöglichen, ist eine Unterteilung der Module in statische, semi-statische und dynamische Module notwendig:

• Statische Module sind Bestandteil des allgemeinen OSCI-Clients und haben keine Abhängigkeiten von der jeweils vorliegenden individuellen Konfiguration. Hierzu zäh-len insbesondere die Java-Klassen. Die zugehörigen JAR-Dateien werden vom Pro-grammhersteller signiert.


Feinkonzept FMS/VPS

• Semi-statische Module sind z.B. Konfigurationsdateien und eigene Java-Klassen, die zur Anpassung des Clients an die Bedürfnisse eines Anbieters verwendet werden. Die zugehörigen JAR-Dateien müssen nur signiert werden, wenn sie Java-Klassen enthalten oder nicht per https übertragen werden.

• Dynamische Module werden bei Anfragen des Benutzers an den Webserver individu-ell generiert und können z.B. auf Formulardaten verweisen, die vorher durch den Be-nutzer eingegeben wurden. Beinhalten diese Module vertrauliche Daten, so müssen diese per https übertragen werden. Authentizität kann durch Signatur der JAR-Dateien oder durch Übertragung per https sichergestellt werden.

Die statischen Module werden von einem zentralen Download-Server zur Verfügung gestellt. Sie werden mittels des Verfahrens der JNLP-Extensions angeboten. Sämtliche anderen Mo-dule werden jeweils individuell vom Anbieter der Anwendung oder in deren Auftrag zur Ver-fügung gestellt. Durch die JNLP-Spezifikation und die Implementierung von SUN ist sicher-gestellt, dass auch verschiedene Versionen von Modulen gleichzeitig auf dem Rechner des Benutzers zur Verfügung stehen können.

6.4 Zusätzliche Integrationsaspekte

6.4.1 Behördenspezifische Schutzbedarfsanalyse über eFormulardaten

Eine wesentliche Voraussetzung zur Entscheidungsfindung, ob ein eFormular mit oder ohne VPS übermittelt werden soll bzw. wo der OSCI-Backend-Enabler betrieben werden muss, hängt grundsätzlich von der Zuordnung der eFormular-Daten zur jeweiligen Schutzklasse ab (siehe Kapitel 3.1). Um diese Klassifizierung durchzuführen, muss eine Behörde eine Behör-denspezifische Schutzbedarfsanalyse über die Daten des eFormulars durchführen.

6.4.2 Lösungsvarianten für eine OSCI-konforme Anbindung der Behörden

Die Standardvariante der OSCI-konformen G2C-Kommunikation geht davon aus, dass Be-hörden, infolge hoher Transaktionsaufkommen im Backend, leistungsfähige Serversysteme zur Bearbeitung von elektronischen Posteingängen einsetzen. Infolgedessen werden bishe-rige VPS-Szenarien so beschrieben, dass ausschließlich der Einsatz von OSCI-Backend-Enablern bei Behörden beschrieben wird. Es wird (abseits der Intermediärfunktionalität) eine klassische Client2Server-Situation dargestellt.

Dabei ist allerdings nicht auszuschließen, dass insbesondere kleinere Behörden die keine eigene aufwendige VPS-Lösung installieren möchten, darauf angewiesen sind, über OSCI ihre elektronischen Posteingänge zu erhalten. Um dies zu ermöglichen kann eine Behörde auf den OSCI-Backend-Enabler verzichten, wenn sie – wie der Bürger auch – einen OSCI-Client (OSCI-Client-Enabler) einsetzt. Damit verändert sich (abseits der Intermediärfunktio-nalität) die klassische Client2Server- in eine Client2Client-Situation.


Feinkonzept FMS/VPS

Abseits der empfohlenen Lösung des Einsatzes eines OSCI-Backend-Enablers bietet sich deshalb alternativ auch der Einsatz eines OSCI-Client-Enablers für Behörden an, sofern eine Behörde die Anbindung nur für ein und nicht mehrere Fachverfahren benötigt.

Dabei kann ein OSCI-Client entweder in einer Client-Umgebung oder auf einem Server in-stalliert werden.

Bei einem solchen Einsatz eines OSCI-Client-Enablers existieren zwei denkbare Ausbaustu-fen:

• Ein OSCI-Client-Enabler mit graphischer Benutzeroberfläche wird wie beim Bürger durch einen Behördenmitarbeiter bedient, Daten werden vom OSCI-Manager über manuellen Aufruf angefordert und über entsprechende Vorkonfiguration des OSCI-Clients in einem Netzwerkverzeichnis abgelegt (z.B. EGVP).

• Der OSCI-Client wird programmtechnisch (z.B. über zeitgesteuerten Aufruf) zur Ab-holung gestartet und übergibt die Daten über einen fachspezifisches Adapter dem Fachverfahren der Behörde.

6.4.3 Lösungsvarianten für Schlüsselmanagement/Zertifikatsmanagement

Die OSCI-Lösung „OSCI-Backend-Enabler bei Behörde“ sieht vor, dass Bürger die Empfän-gerbehörde im OSCI-Client durch Auswahl des Verschlüsselungszertifikats selbst bestimmen kann. Dies ist eine Muss-Bedingung, falls der Backend-Enabler bei der Behörde selbst be-trieben wird, da die Verteilung über die Zuordnung der behördenspezifischen Verschlüsse-lungszertifikate erfolgt. In diesem Fall muss aber bei der Integration die Behörde sicherge-stellt werden, dass ihr Verschlüsselungszertifikat an das FMS übergeben wird. FMS kann das zusätzliche Verschlüsselungszertifikat in die Konfiguration des OSCI-Clients hinterlegen und als Update über JWS zur Verfügung stellen. Der Entschlüsselungsschlüssel würde durch die Behörde selbst verwaltet werden.

6.4.4 Eskalationsmechanismen

Nach erfolgreicher Übergabe an den OSCI-Manager und Zertifikatsprüfung der OSCI-Nachricht erhält ein Bürger die Bestätigung der erfolgreichen Übermittlung einer OSCI-Nachricht in Form des OSCI-Prüfprotokolls. Ab diesem Zeitpunkt muss davon ausgegangen werden, dass der Bürger sich vom OSCI-Client abmeldet bzw. die Internetverbindung unter-bricht.

Zu diesem Zeitpunkt ist die OSCI-Nachricht noch nicht bei der Behörde ankommen, sondern nur beim OSCI-Manager des FMS. Im Falle eines anschließenden Fehlers müssen seitens der Behörde oder vom FMS zusätzliche Eskalationsprozesse eingeplant bzw. realisiert wer-den.

Auftretende Fehler könnten sein:


Feinkonzept FMS/VPS

• Fehlschlagen der mathematischen Signaturprüfung

• Datenkonvertierungsfehler

• Entschlüsselungsprobleme

• Versehentliche Löschung oder Veränderung von Daten

Sollte durch einen solchen auftretenden Fehler eine Weiterverarbeitung oder Speicherung nicht möglich sein, muss der Bürger darüber informiert werden, dass das eFormular noch-mals versendet werden muss.

Zusätzliche Meldewege an den Bürger können sein:

• Telefonbenachrichtigung,

• E-Mail, sowie

• Postweg.

7

7.1

7.2

7.3

AUSBLICK

Kryptografische Dienste über DI Die direkte Unterstützung der Fachverfahren über das Document Interface (DI) des VPS-Kernsystem ist möglich, soll aber in der aktuellen Planung der Ausbaustufen nicht Bestand-teil des Feinkonzepts sein.

Mehrfachsignaturen Mehrfachsignaturen sollen derzeit nicht von FMS genutzt werden.

OSCI-Backend-Enabler bei FMS Die Entwicklung eines Migrationspfades von der Architekturvariante „OSCI-Backend-Enabler bei Behörde“ zu einer Variante „OSCI-Backend-Enabler bei FMS“ soll erst in einer zukünfti-gen Version des Feinkonzepts beschrieben werden.

Ziel einer solchen Lösung könnte es sein, mehrere Mandanten (Behörde) oder mehrere Fachverfahren eines Mandanten mit der kryptografischen Dienstleistung der VPS zu unter-stützen, ohne dass die Behörden bzw. die einzelnen Fachverfahren selbst VPS-Komponenten betreiben müssten.

In einem solchen Fall könnten die OSCI-Nachrichten von einem OSCI-Backend-Enabler des zentralen FMS-Systems abgeholt und über geeignete Verteilungsmechanismen (z.B. Web-service Schnittstellen) für die jeweiligen Fachverfahren bereitgestellt werden.


Feinkonzept FMS/VPS

Beim Betrieb einer zentralen Lösung sind aber auf jeden Fall die erweiterten sicherheitstech-nischen Anforderungen zu berücksichtigen, die sich aufgrund der Auslagerung von Dienst-leistungen auf einen externen Dienstleister ergeben.


Feinkonzept FMS/VPS

ABKÜRZUNGSVERZEICHNIS

BK DS Basiskomponente Datensicherheit, entspricht der VPS

CC-DS Kompetenzzentrum Datensicherheit

CMS Content Management System

CRL Certificate Revocation List

DI Document Interface

EGVP Elektronisches Gerichts- und Verwaltungspostfach

FFW FormsForWeb

FMS Formular Management System

G2C government to citizen – E-Government-Anwendung Verwaltung zu Bürger

HTTP / HTTPS (Secure) Hypertext Transfer Protocol

J2EE Java 2 Platform, Enterprise Edition

JRA Java Runtime Environment

JVM Java Virtual Machine

JWS Java Web Start

OCSP Online Certificate Status Protocol

OSCI Online Service Computer Interface

SAK Signaturanwendungskomponente

SBS Siemens Business Services

SDK Software Development Kit

SOAP Simple Object Access Protocol

VPS Virtuelle Poststelle des Bundes

XKMS XML Key Management Specification

XML eXtensible Markup Language

XSL eXtensible Stylesheet Language


Feinkonzept FMS/VPS


ZID Zentrum für Informations- und Datentechnik der Bun-desfinanzverwaltung

TABELLENVERZEICHNIS Tabelle 1: Identifizierung der VPS-spezifischen Schnittstellen ..............................................34 Tabelle 2: Dialog FFW – JWS................................................................................................35 Tabelle 3: Dialog OSCI-Client – OSCI-Manager ....................................................................35 Tabelle 4: Dialog OSCI-Manager – OCSP/CRL-Relay ..........................................................36 Tabelle 5: Dialog OSCI-Manager – OSCI-Backend-Enabler..................................................37 Tabelle 6: Dialog OSCI-Backend-Enabler – VPS-Kernsystem ..............................................38 Tabelle 7: Dialog Fachspezifischer Adapter des OSCI-Backend-Enablers – FFW-

Funktionsmodul zur Integritätsprüfung............................................................................38 Tabelle 8: Ausgabe Fachspezifischer Adapter des OSCI-Backend-Enablers – Fachverfahren

der Behörde ....................................................................................................................40 Tabelle 9: Unterstützte Kombinationen von Ablaufumgebungen ...........................................43 Tabelle 10: Hard- und Software-Komponenten für die Referenzimplementierung.................45

ABBILDUNGSVERZEICHNIS Abbildung 1: Softwarearchitektur des FFW-Systems.............................................................10 Abbildung 2: OSCI-Prinzip .....................................................................................................12 Abbildung 3: Online-Web mit OSCI (OSCI-Backend-Enabler bei Behörde) ..........................22 Abbildung 4: Offline-Bearbeitung mit OSCI (hier: OSCI-Backend Enabler bei Behörde).......23 Abbildung 5: Sequenzdiagramm FMS-VPS ...........................................................................24

Documents

Feinkonzept FMS/VPS - Bund