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
Version 1.2 Seite 3 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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
Version 1.2 Seite 4 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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.
Version 1.2 Seite 5 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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.
Version 1.2 Seite 6 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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
Version 1.2 Seite 7 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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
Version 1.2 Seite 8 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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.
Version 1.2 Seite 9 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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
Version 1.2 Seite 10 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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.
Version 1.2 Seite 11 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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.
Version 1.2 Seite 12 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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).
Version 1.2 Seite 13 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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.
Version 1.2 Seite 14 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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.
Version 1.2 Seite 15 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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
Technische Beschreibung
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:
Version 1.2 Seite 16 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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
Anwendungsbeschreibung
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
Technische Beschreibung
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:
Version 1.2 Seite 17 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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.
Anwendungsbeschreibung
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
Technische Beschreibung
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
Version 1.2 Seite 18 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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.
Anwendungsbeschreibung
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-
Version 1.2 Seite 19 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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.
Version 1.2 Seite 20 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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.
Version 1.2 Seite 21 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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.
Version 1.2 Seite 22 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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.
Version 1.2 Seite 23 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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
Version 1.2 Seite 24 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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.
Version 1.2 Seite 25 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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.
Version 1.2 Seite 26 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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).
Version 1.2 Seite 27 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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
Version 1.2 Seite 28 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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
Version 1.2 Seite 29 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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
Version 1.2 Seite 30 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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
Version 1.2 Seite 31 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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
Version 1.2 Seite 32 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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
Version 1.2 Seite 33 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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
Version 1.2 Seite 34 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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
Verzweigungsmöglichkeiten: Keine
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
Version 1.2 Seite 35 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
Feinkonzept FMS/VPS
Beschreibung: Siehe 2.3.2 und 2.3.3
Verwendung: Zertifikatsprüfung
Betroffene Systeme: OSCI-Manager
Art der Schnittstelle: Synchron
Richtung der Schnittstelle: Lesend und Schreibend
Häufigkeit der Aktivierung: Pro eingehender OSCI-Nachricht
Datenvolumen/Aktivierung: Bisher keine Beschränkung
Komplexitätsgrad Standard
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
Version 1.2 Seite 36 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
Feinkonzept FMS/VPS
Synchron: bei jeder Zustellung von OSCI-Nachrichten
Datenvolumen/Aktivierung: Bisher keine Beschränkung
Komplexitätsgrad Standard
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
Art der Schnittstelle: Synchron
Richtung der Schnittstelle: Lesend
Häufigkeit der Aktivierung: Pro eingehender OSCI-Nachricht
Datenvolumen/Aktivierung: Bisher keine Beschränkung
Komplexitätsgrad Standard
Anzeige oder Protokollierung: Serverseitige Systemprotokollierung und Log4J
Version 1.2 Seite 37 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
Feinkonzept FMS/VPS
Verzweigungsmöglichkeiten: Keine
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
Art der Schnittstelle: Synchron
Richtung der Schnittstelle: Lesend und Schreibend
Häufigkeit der Aktivierung: Pro eingehender OSCI-Nachricht
Datenvolumen/Aktivierung: Bisher keine Beschränkung
Komplexitätsgrad Standard
Anzeige oder Protokollierung: Serverseitige Systemprotokollierung und Log4J
Verzweigungsmöglichkeiten: Keine
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
Version 1.2 Seite 38 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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
Anzeige oder Protokollierung: Serverseitige Systemprotokollierung und Log4J
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
Version 1.2 Seite 39 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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,
Version 1.2 Seite 40 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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
Version 1.2 Seite 41 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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 3.2.5 inkl. Tomcat 5.0.26
JBoss MQ MySQL 4.1
4 Red Hat Linux 9.0 SUN 1.4.2_04
JBoss 3.2.5 inkl. Tomcat 5.0.26
JBoss MQ MySQL 4.1
5 Linux SUSE 9.x SUN 1.4.2_04
JBoss 3.2.5 inkl. Tomcat 5.0.26
JBoss MQ Oracle 10g Rel.1 (10.1.0.3)
6 Windows 2003 Server
SUN 1.4.2_04
JBoss 3.2.5 inkl. Tomcat 5.0.26
JBoss MQ Oracle 10g Rel.1 (10.1.0.3)
7 Solaris 9.x SUN 1.4.2_04
JBoss 3.2.5 inkl. Tomcat 5.0.26
JBoss MQ Oracle 10g Rel.1 (10.1.0.3)
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
Version 1.2 Seite 42 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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.
Version 1.2 Seite 43 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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
Primergy FSC RX 300 Dual Prozessor 2 HE
Version 1.2 Seite 44 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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
Primergy FSC RX 300 Dual Prozessor 2 HE
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.
Version 1.2 Seite 45 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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.
Version 1.2 Seite 46 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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.
Version 1.2 Seite 47 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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.
Version 1.2 Seite 48 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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.
Version 1.2 Seite 49 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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:
Version 1.2 Seite 50 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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.
Version 1.2 Seite 51 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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.
Version 1.2 Seite 52 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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
Version 1.2 Seite 53 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
Feinkonzept FMS/VPS
Version 1.2 Seite 54 Kompetenzzentrum Datensicherheit Datei: 05-06-01 CCDS Feinkonzept FMS-VPS_v1.2 Stand: 1. Juni 2005
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