SAGA 2.1 - IT-Beauftragter der Bundesregierung

Transcription

SAGA
Version 2.1
Standards und Architekturen für
E-Government-Anwendungen
www.kbst.bund.de
Koordinierungs‐ und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung
Schriftenreihe der KBSt
Band 82
September 2005
Schriftenreihe der KBSt
Band 82
Nachdruck, auch auszugsweise, ist genehmigungspflichtig
Dieser Band wurde erstellt von der KBSt im Bundesministerium des Innern in Zusammenarbeit mit der ]init[ AG und Fraunhofer ISST.
Redaktion: ]init[ AG, Berlin
Interessenten erhalten die derzeit lieferbaren Veröffentlichungen der KBSt
und weiterführende Informationen zu den Dokumenten beim
Bundesministerium des Innern
Referat IT 2 (KBSt)
11014 Berlin
Tel.: +49 (0) 1888 681 ‐ 2312
Fax.: +49 (0) 1888 681 ‐ 52312
Homepage und Download der digitalen Version: http://www.kbst.bund.de/saga
mailto: IT2@bmi.bund.de SAGA
Standards und Architekturen für E-Government-Anwendungen
Version 2.1
September 2005
Herausgegeben vom
Danksagung
Die Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung (KBSt) und das Autoren-Team danken allen Mitgliedern
des SAGA-Expertenkreises für ihre fachliche Unterstützung bei der Erstellung der
vorliegenden Version von SAGA.
Der Dank gilt weiterhin allen Teilnehmerinnen und Teilnehmern am SAGA-Forum, die
mit ihren engagierten Kommentaren einen maßgeblichen Beitrag zur Fortschreibung
des Dokuments geleistet haben.
Vorbemerkung:
Dieses Dokument stellt in verdichteter Form verbreitete Standards, Verfahren, Methoden und auch Produkte der modernen IT-Entwicklung für E-Government vor. Naturgemäß werden von den Experten auf diesem Gebiet sehr viele Abkürzungen und überwiegend englischsprachige Akronyme verwendet. Ein Teil dieser Namen sind
urheberrechtlich beziehungsweise als Warenzeichen oder Produkt für bestimmte Hersteller oder Normungsorganisationen national und international geschützt.
Zur Erzielung einer einfachen Struktur wurde generell auf solche Urheberrechts- und
Quellenverweise verzichtet. Die Verwendung eines „Namens“ oder einer Abkürzung in diesem Dokument bedeutet nicht, dass sie frei von Urheber- und
Schutzrechten anderer sind.
Ebenso können Herausgeber, Autoren und befragte Experten keine Verantwortung
für die technische Funktionsfähigkeit, Kompatibilität oder Vollständigkeit der diskutierten Standards übernehmen. Die vorliegende Version 2.1 wurde im September 2005
veröffentlicht; Kommentare, Ergänzungen, Berichtigungen werden erbeten vom Bundesministerium des Innern, Referat IT2 (KBSt) und können im Forum unter http://
foren.kbst.bund.de/saga eingestellt werden.
Teilweise sind diskutierte Standards zwingend mit lizenzpflichtigen Produkten verbunden. Unsere Empfehlung ist rein technisch zu verstehen. Ob und in welcher Form
(Einzel-/ Sammellizenz) ein Produkt wirtschaftlich einsetzbar ist, ist im Einzelfall zu
prüfen.
Versionsnummern sind dort aufgeführt, wo sie im diskutierten Zusammenhang relevant sind; die Nichterwähnung impliziert aber keine Konformität. Wenn für Standards
keine Versionsnummern angegeben sind, ist die aus Marktsicht stabilste Version zu
verwenden, welche nicht immer die neueste Version ist.
Die Autoren gestatten die Weiterverwendung des Dokuments – auch in Teilen – unter
Angabe der Quelle.
Inhaltsverzeichnis
0
Status, Änderungshistorie und Ausblick .............................................9
0.1 Änderungen gegenüber Version 2.0 ........................................................9
0.2 Zukünftige Themenbereiche .....................................................................9
1
Einleitung ..............................................................................................11
1.1 Hintergrund .............................................................................................11
1.2 Angesprochener Leserkreis ...................................................................11
1.3 Ziel und Aufbau des Dokuments ...........................................................12
1.4 Abzubildende Dienstleistungen ..............................................................15
1.5 Beziehung zu anderen E-Government-Dokumenten .............................16
1.6 Der Evolutionsprozess ...........................................................................18
2
Verbindlichkeit und Konformität der Anwendungen ........................21
2.1 Geltungsbereich und Verbindlichkeit von SAGA ....................................21
2.2 Klassifizierung und Lebenszyklen von Standards ..................................21
2.3 SAGA-Konformität ..................................................................................24
3
Architekturmodell für E-Government-Anwendungen .......................29
3.1 Überblick ................................................................................................29
3.2 Enterprise Viewpoint ..............................................................................30
3.3 Information Viewpoint .............................................................................31
3.4 Computational Viewpoint ........................................................................32
3.5 Engineering Viewpoint ............................................................................33
3.6 Technology Viewpoint ............................................................................33
4
Enterprise Viewpoint: Grundlagen E-Government ............................35
4.1 Rahmenbedingungen für E-Government in Deutschland .......................35
4.2 Rahmenbedingungen für E-Government-Anwendungen .......................43
5
Information Viewpoint: Schema-Repository ......................................49
6
Computational Viewpoint: Referenz-Software-Architektur ..............51
6.1 Anforderungen und Voraussetzungen ....................................................51
6.2 Architekturentscheidungen .....................................................................55
6.3 Referenzarchitektur für E-Government-Anwendungen ..........................59
6.4 Folgerungen aus der Software-Architektur .............................................63
7
Engineering Viewpoint: Referenzinfrastruktur ..................................65
7.1 Aufbau einer E-Government-Infrastruktur ..............................................65
7.2 Netzwerk, Benutzer und externe Dienste ...............................................70
Seite 7
8
Technology Viewpoint (Teil I): Standards für die IT-Architektur .....71
8.1 Prozessmodellierung ..............................................................................71
8.2 Datenmodellierung .................................................................................71
8.3 Applikationsarchitektur ...........................................................................73
8.4 Client ......................................................................................................76
8.5 Präsentation ...........................................................................................79
8.6 Kommunikation .......................................................................................90
8.7 Anbindung an das Backend ...................................................................95
9
Technology Viewpoint (Teil II): Standards für Datensicherheit .......99
9.1 Ziele und Prinzipien der Datensicherheit ................................................99
9.2 Standards für die Sicherheitskonzeption ..............................................102
9.3 Standards für bestimmte Anwendungsfälle ..........................................103
9.4 Übergreifende Datensicherheitsstandards ...........................................109
Anhang A Basisbausteine der BundOnline-Initiative .......................................113
A.1 Basiskomponente Zahlungsverkehrsplattform („ePayment“) ...............113
A.2 Basiskomponente Datensicherheit („Virtuelle Poststelle“) ...................119
A.3 Basiskomponente Portal ......................................................................127
A.4 Basiskomponente Formularserver .......................................................132
A.5 Basiskomponente Content Management System ................................136
A.6 Infrastrukturkomponente Informationsverbund der Bundesverwaltung 142
A.7 Infrastrukturkomponente Verzeichnisdienst .........................................146
A.8 Infrastrukturkomponente Public Key Infrastruktur der Verwaltung .......149
A.9 „Einer-für-Alle“-Dienstleistungen ..........................................................153
A.10 Kompetenzzentren ...............................................................................169
Anhang B Anwendung von Basiskomponenten ...............................................173
B.1 Modellierung nach RM-ODP ................................................................173
B.2 Computational Viewpoint des Musterbeispiels Antragsverfahren ........175
Anhang C Vorlagen für eine SAGA-Konformitätserklärung .............................179
C.1 Konformitätserklärung ..........................................................................179
C.2 Checkliste für eigenentwickelte Komponenten .....................................180
C.3 Checkliste für Produktkomponenten ....................................................183
Anhang D Literaturverzeichnis ...........................................................................185
Anhang E Übersicht der klassifizierten Standards ...........................................189
Anhang F Abkürzungsverzeichnis .....................................................................193
Seite 8
0 Status, Änderungshistorie und Ausblick
Das vorliegende Dokument in der Version 2.1 ist eine freigegebene Veröffentlichung
von SAGA (Standards und Architekturen für E-Government-Anwendungen) und hat
verbindlichen Charakter.
0.1
Änderungen gegenüber Version 2.0
Dieses Dokument ist eine Aktualisierung von SAGA in der Version 2.0. Im Wesentlichen wurde auf die Weiterentwicklung von Standards reagiert. Standards der White
List wurden übernommen, Klassifizierungen vorhandener Standards verändert und
Standards aus dem Dokument auf die Grey List verschoben. Der einzige neue
Abschnitt thematisiert Web-Formulare (siehe Abschnitt 8.5.1.6 auf Seite 82).
Im Anhang wurden die Beschreibungen der Basisbausteine aktualisiert und mit der
Infrastrukturkomponente Verwaltungs-PKI um einen vorherigen SAGA-Standard
erweitert. Sie wurde in SAGA 2.0 als „PKI-1-Verwaltung“ zusammen mit „MailTrust
(MTT) Version 2“ und „SPHINX“ zweimal im Abschnitt 9.3 klassifiziert. Außerdem
wurden vier neue „Einer-für-alle“-Dienstleistungen aufgenommen (siehe Seite 153).
Das Beispiel einer Online-Dienstleistung mit Basiskomponenten wurde grundlegend
überarbeitet und an aktuelle Leistungsmerkmale der Komponenten angepasst.
Erste Korrekturen und Hinweise aus den Diskussionen von SAGA 2.0 mit Experten
aus Bund, Ländern, Kommunen, der Wirtschaft und im öffentlichen SAGA-Forum sind
bereits in diese Aktualisierung des Dokuments eingeflossen. Die Anregungen größerer Änderungen und Erweiterungen werden in die bereits laufenden Arbeiten an
SAGA 3.0 aufgenommen.
0.2
Zukünftige Themenbereiche
Die nächste Ausgabe von SAGA wird die Version 3.0 sein. Folgende Themengebiete
sollen weiter untersucht und detailliert werden:
a. stärkere Berücksichtigung der Anforderungen von Ländern und Kommunen
b. Sicherstellung von SAGA-Konformität
c. Entwicklung und Standardisierung von Prozess- und Datenmodellen
d. Konkretisierung der Referenz-Software-Architektur
e. Einarbeiten von praktischen Erfahrungen mit der Anwendung von SAGA
Die Veröffentlichung von SAGA 3.0 ist für das erste Halbjahr 2006 vorgesehen.
Ergänzend zum SAGA-Dokument wird die Koordinierungs- und Beratungsstelle der
Bundesregierung für Informationstechnik in der Bundesverwaltung (KBSt) auf ihrer
Web-Site1 weitere Informationen, Links und Hilfsmittel zur Verfügung stellen.
1. siehe http://www.kbst.bund.de/saga
Seite 9
Seite 10
1 Einleitung
1.1
Hintergrund
Mit den Standards und Architekturen für E-Government-Anwendungen (SAGA)
schafft die Bundesregierung eine wichtige Voraussetzung für eine moderne und
dienstleistungsorientierte Verwaltung.
Im September 2000 hat Bundeskanzler Gerhard Schröder die E-Government-Initiative BundOnline 2005 gestartet, mit der sich die Bundesverwaltung verpflichtet, ihre
über 400 internetfähigen Dienstleistungen bis zum Jahr 2005 online bereit zu stellen.
Bürgerinnen und Bürger sowie die Wirtschaft sollen über nutzerfreundliche Internetangebote auf die Services der Verwaltung zugreifen können. Zur Steuerung und
Koordination der E-Government-Initiative wurde im Bundesministerium des Innern
(BMI) die Projektgruppe BundOnline 2005 eingerichtet.
Die Projektgruppe formulierte den Umsetzungsplan und schreibt ihn in jährlichen
Berichten an das Bundeskabinett fort. Neben dem Portfolio der dezentral durch die
zuständigen Behörden zu realisierenden Dienstleistungen definiert der Umsetzungsplan zentrale Basiskomponenten und Anwendungen, die nach dem Prinzip „Einer für
Alle“ entwickelt werden. Künftig sollen alle diese E-Government-Anwendungen nahtlos miteinander kommunizieren können. Dazu muss – auf Grundlage gemeinsamer
Architekturen und Standards – Interoperabilität zwischen den Komponenten von
BundOnline 2005 hergestellt werden.
Die Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung (KBSt) übernahm die Aufgabe diese Standards zu formulieren. Unter Einbindung von Industrieexperten sowie weiteren Fachleuten aus
Bundes-, Länder- und Kommunalverwaltungen wurde zunächst eine Sichtung und
Bewertung existierender Standards durchgeführt. Auf dieser Basis entstand dann die
erste Version der Standards und Architekturen für E-Government-Anwendungen
(SAGA). Das SAGA-Autorenteam schreibt seitdem in Abstimmung mit der Projektgruppe BundOnline 2005 und dem Expertenkreis das SAGA-Dokument kontinuierlich
fort.
1.2
Angesprochener Leserkreis
SAGA richtet sich in erster Linie an Entscheider aus den Bereichen Organisation und
Informationstechnik (E-Government-Teams) in der deutschen Verwaltung. Das Dokument gibt als Leitfaden eine Orientierungshilfe für die Konzeption technischer Architekturen und die technische Grobkonzeption einzelner IT-Anwendungen.
Entwickler von Anwendungen sind aufgefordert, im Detail nach weiteren Lösungen zu
suchen, wenn die vorgestellten Standards zur Umsetzung fachlicher Anforderungen
nicht ausreichen.
Seite 11
Der Bund sieht seine Initiative auch als Beitrag zur Entwicklung von E-Government in
Deutschland. Hier gesammelte Erfahrungen und die im Rahmen von BundOnline
2005 entwickelten Basisbausteine sollen allen Anwendern die Orientierung in der Verwaltung erleichtern und flächendeckende E-Government-Angebote fördern.
1.3
Ziel und Aufbau des Dokuments
1.3.1 Grundprinzipien
Modernes E-Government erfordert Informations- und Kommunikationssysteme, die
(idealerweise) reibungslos zusammenwirken. Durch einfache und klare Standards
und Spezifikationen kann die Interoperabilität von Informations- und Kommunikationssystemen erreicht werden. SAGA identifiziert erforderliche Standards, Formate und
Spezifikationen, legt dafür Konformitätsregeln fest und schreibt diese entsprechend
den technologischen Entwicklungen fort.
E-Government-Anwendungen werden nach folgenden Grundprinzipien entwickelt:
a. E-Government-Anwendungen nutzen als Frontend primär den Browser, es sei
denn, die umzusetzenden Dienstleistungen sind über Browser nicht sinnvoll
abbildbar.
b. Sie verzichten auf aktive Inhalte, um den Benutzer nicht zu zwingen, die Sicherheitseinstellungen des Browsers herabzusetzen und so Beschädigungen durch
unsichere Web-Seiten zu ermöglichen, oder verwenden zumindest nur signierte
und qualitätsgesicherte Anwendungen gemäß Abschnitt 8.5 „Präsentation“ auf
Seite 79.
c. E-Government-Anwendungen legen keine Programmteile und Daten auf den
Computern der Anwender ab, die sich deren Kontrolle entziehen.
1.3.2 Zielsetzung
SAGA verfolgt das Ziel:
a. stetige Informationsflüsse zwischen Bürgern, dem Bund und Partnern des Bundes
zu gewährleisten (Interoperabilität)
b. ähnliche Vorgehensweisen bei der Bereitstellung von Dienstleistungen und bei der
Definition von Datenmodellen zu etablieren; Ländern und Kommunen wird angeboten, Entwicklungsergebnisse der Initiative BundOnline 2005 zu verwenden
(Wiederverwendbarkeit)
c. auf Spezifikationen in Form öffentlich zugänglicher Dokumentationen zurückgreifen zu können (Offenheit)
d. Entwicklungen am Markt und im Bereich der Standardisierung zu berücksichtigen
(Reduktion von Kosten und Risiken)
e. die Anwendbarkeit der Lösungen bei sich ändernden Anforderungen hinsichtlich
Volumen und Transaktionshäufigkeit sicherzustellen (Skalierbarkeit)
Seite 12
1.3.3 Aufgaben
SAGA ist ein umfassender Standardisierungsansatz für die Initiative BundOnline
2005, der sich auf vier Entwicklungsrichtungen (Aufgaben) konzentriert:
a. Festlegung der technischen Normen, Standards und Architekturen,
b. Prozessmodellierung,
c. Datenmodellierung sowie
d. Entwicklung von Basiskomponenten.
Festlegung der technischen Normen, Standards und Architekturen
Die technischen Standards und Architekturen umfassen alle für das E-Government
relevanten Ebenen und Komponenten (siehe Kapitel 3 „Architekturmodell für
E-Government-Anwendungen“ auf Seite 29). Sie sind die Grundlage für die Interoperabilität und Kompatibilität bei der Entwicklung der E-Government-Anwendungen und
der Basiskomponenten der Initiative BundOnline 2005.
Prozessmodellierung
Prozessmodellierung umfasst die methodische Beschreibung der E-Government-Prozesse im Ganzen oder in Teilschritten (siehe Abschnitt 3.2 auf Seite 30), um
a. die verschiedenen Fachanwendungen ähnlich zu gestalten und
b. die Wiederverwendbarkeit von Prozessen und Systemen zu einem hohen Grad zu
gewährleisten.
Datenmodellierung
Datenmodellierung umfasst die methodisch standardisierte Beschreibung der Daten,
die in den E-Government-Prozessen (-Anwendungen) kommuniziert werden, im Ganzen oder in Teilen (siehe Abschnitt 3.3 auf Seite 31), um
a. die Interoperabilität von verschiedenen, auch von zukünftigen Anwendungen
sicherzustellen und
b. die Wiederverwendbarkeit von Prozessen und Systemen zu einem hohen Grad zu
gewährleisten.
Entwicklung von Basiskomponenten
Basiskomponenten werden auf Grundlage von oft verwendeten, übergreifenden Prozessmodellen von BundOnline 2005 ausgewählt, spezifiziert und umgesetzt. Fünf
Basiskomponenten und drei Infrastrukturkomponenten befinden sich in der Umsetzungsphase (siehe Anhang A auf Seite 113).
1.3.4 Umfang
SAGA versteht sich als Standardisierung mit einem ganzheitlichen Ansatz, der alle
erforderlichen Aspekte erläutert, um die genannten Ziele zu erreichen. Nicht aufgeführte Standards oder Architekturen sind
Seite 13
a. nicht spezifisch für E-Government- oder E-Commerce-Anwendungen,
b. auf eine andere Detailebene bezogen als die hier in SAGA aufgeführten
Standards,
c. in genannten Standards inbegriffen oder werden durch genannte Standards
referenziert,
d. zu neu oder zu umstritten, um verlässlich die baldige Etablierung als Standard voraussetzen zu können oder
e. nicht gewünscht, weil sie mit vorgestellten Standards oder Architekturen konkurrieren oder die Interoperabilität einschränken.
Des Weiteren betrachtet SAGA nicht alle Elemente einer technischen Architektur,
sondern nur Bereiche, die wesentlichen Einfluss auf die genannten Ziele haben.
1.3.5 Aufbau
Nach der Einleitung trifft das Kapitel 2 Aussagen zur Verbindlichkeit von SAGA und
zur SAGA-Konformität von E-Government-Anwendungen. Im Kapitel 3 folgt die Darstellung des Architekturmodells für E-Government-Anwendungen. Das Modell wurde
auch für die Beschreibung des deutschen E-Government angewendet. Dementsprechend enthalten die nachfolgenden Kapitel 4 bis 9 Sichten (Viewpoints) auf das
E-Government in seiner Gesamtheit.
Kapitel 4 dokumentiert Ziele des deutschen E-Government, Akteure, Rollen, Rahmenbedingungen, Richtlinien und Interaktionsformen (Enterprise Viewpoint). Im
Kapitel 5 werden die Bemühungen um einheitliche Datenmodelle beschrieben (Information Viewpoint). Das Kapitel 6 enthält eine Referenz-Software-Architektur, aus der
Architekturen für konkrete E-Government-Anwendungen entwickelt werden können
(Computational Viewpoint). Im Kapitel 7 werden die Anforderungen an E-Government-Rechenzentren und die Einbindung von Basisbausteinen in eine bestehende
Infrastruktur dargestellt (Engineering Viewpoint). In den Kapiteln 8 und 9 werden die
SAGA-Standards für die IT-Architektur und zur Erreichung von Datensicherheit festgelegt (Technology Viewpoint).
Eine ausführliche Beschreibung der Basisbausteine der Initiative BundOnline 2005
erfolgt im Anhang A. Von Basiskomponenten und Infrastrukturkomponenten werden
Leistungsumfang, klassifizierte Geschäftsvorfälle (Einsatzszenarien), Roadmap und
Schnittstellen aufgezeigt. Außerdem werden die wichtigsten „Einer-für-Alle“-Dienstleistungen vorgestellt und erläutert, welche Kompetenzzentren die Entwicklung von
E-Government-Anwendungen unterstützen. Im Anhang B befindet sich ein Beispiel
einer Online-Dienstleistung, die mehrere Basiskomponenten verwendet. Eine Vorlage
zur Erstellung einer SAGA-Konformitätserklärung wurde als Anhang C beigefügt. Der
Anhang D enthält ein Literaturverzeichnis und im Anhang E werden die Standards
aus den Kapiteln 8 und 9 alphabetisch aufgelistet. Im Anhang F befindet sich schließlich ein Verzeichnis der in SAGA verwendeten Abkürzungen.
Seite 14
1.4
Abzubildende Dienstleistungen
Das Dokument definiert drei Zielgruppen, an die sich die Dienstleistungen der Bundesverwaltung richten (siehe eine Auswahl in Abbildung 1-1).
a. Government to Citizens (G2C): Dienstleistungen, die der Bund Bürgern direkt
anbietet,
b. Government to Business (G2B): Dienstleistungen, die der Bund Unternehmen
anbietet,
c. Government to Government (G2G): Dienstleistungen des Bundes für die Verwaltung.
G2C
Government to Citizens
G2B
Government to Business
• BA: Vermittlung von Arbeitsplätzen
• BA: Gewährung von Geldleistungen
• BfA: Berechnung und Gewährung von
Renten
• BMA: Bereitstellung von
Informationen
• BA: Durchführung von Beratungen
• BfA: Durchführung von Beratungen
• DWD: Durchführung von
meteorologischen Vorhersagen und
Beratungen
• BfA: Einzug von
Rentenversicherungsbeiträgen
• BEV: Erstattung von Kosten im
Rahmen der Krankenversorgung und
Pflegeversicherung der Beamten
• BZgA: Bereitstellung von Fachinformationen (zur gesundheitlichen
Aufklärung)
• BpB: Bereitstellung von Informationen
und Abwicklung von Bestellungen
• BAFA: Förderung erneuerbarer
Energien
• BA: Vermittlung von Arbeitsplätzen
• BeschA: Durchführung von
Beschaffungen
• BBR: Durchführung von
Beschaffungen im Baubereich
• BZV: Zollbehandlungen Aus- und
Einfuhr
• StBA: Durchführung zentraler
Statistiken
• BMBF: Vergabe von projektbezogenen Förderungen
• BMWi: Abwicklung von
Förderprogrammen
• BaKred : Informationsangebot zu
bankenaufsichtlich relevanten
Themen
• BfF: Vergabe der Umsatzsteueridentifikationsnummer
• EBA: Vergabeverfahren nach VOL/A,
VOB/A, VOF
• RegTP: Vergabe von Rufnummern
• BA: Bereitstellung von Informationen
G2G
Government to Government
• KBA: Führen zentraler Verkehrs- und
Kfz-Register
• BeschA: Beschaffungen
• BfF: zentrale Kassenführung des
Bundes
• BBR: Durchführung von
Beschaffungen im Baubereich
• BMF: Bewirtschaftung der Immobilien
des Bundes
• BAköV: Buchungen in der Fortbildung
• StBA: Durchführung zentraler
Statistiken
• BZR: Führen des Bundeszentralregisters
• BZR: Erteilung von Auskünften aus
dem Gewerbezentralregister
Abbildung 1-1: Ausgewählte Dienstleistungen des Bundes
Ca. 400 Dienstleistungen der verschiedenen Verwaltungen des Bundes wurden identifiziert. Durch die Betrachtung der Dienstleistungen entlang der Wertschöpfungskette
konnten acht Dienstleistungstypen2 abgeleitet werden. 73 Prozent der heute nachgefragten Dienstleistungen lassen sich den folgenden drei Typen zuordnen:
a. Erfassen, Aufbereiten und Bereitstellen von Informationen,
b. Bearbeiten von Anträgen, die an die Verwaltung gerichtet werden,
c. Abwickeln von Förderungen.
2. siehe [BOL], Seite 20
Seite 15
1.5
Beziehung zu anderen E-Government-Dokumenten
Standards und Architekturen für E-Government werden bereits seit einigen Jahren in
Deutschland und in anderen Ländern erprobt3. Die hier gewonnenen Erfahrungen
und der internationale Austausch tragen dazu bei, die Definition und Umsetzung von
SAGA zu erleichtern.
SAGA erscheint innerhalb der KBSt-Schriftenreihe, wie beispielsweise auch das
„V-Modell XT“, der „Migrationsleitfaden“ und „DOMEA“. Die Dokumente dieser Reihe
werden bei Fortschreibungen aufeinander abgestimmt. Das bedeutet konkret, dass
SAGA Aussagen älterer Dokumente „überschreibt“ und neuere Dokumente die Aussagen der letzten SAGA-Version berücksichtigen. Bei der Fortschreibung von SAGA
wird durch einen breiten Abstimmungsprozess vermieden, dass Widersprüche zu
aktuellen Dokumenten auftreten.
E-Government-Handbuch
Zur Förderung der Initiative BundOnline 2005 sowie zur Unterstützung der Landesund Kommunalbehörden entsteht unter Federführung des Bundesamts für Sicherheit
in der Informationstechnik (BSI) das E-Government-Handbuch4. Das Handbuch ist
als Nachschlagewerk und zentrale Informationsbörse zum Thema E-Government
konzipiert.
Das E-Government-Handbuch ist eine modularisierte Materialsammlung mit einem
weiteren Themenspektrum als SAGA. Wo gleiche Themen behandelt werden, ist das
E-Government-Handbuch konkreter. Deshalb werden aus SAGA heraus einige
Module des E-Government-Handbuchs referenziert5. SAGA gibt Richtlinien vor, während das E-Government-Handbuch die Umsetzung dieser Richtlinien erläutert und
praktische Ratschläge gibt.
Mitte Februar 2003 wurde SAGA in das E-Government-Handbuch aufgenommen. Es
ist das verbindlichste Modul des Handbuchs. Alle anderen Module stellen die Konformität zu SAGA sicher.
IT-Grundschutzhandbuch
Im Handbuch zur Erstellung von IT-Sicherheitskonzepten für normalen Sicherheitsbedarf (IT-Grundschutzhandbuch)6 werden Standardsicherheitsmaßnahmen für typische IT-Systeme empfohlen. Das Ziel dieser IT-Grundschutz-Empfehlungen ist es,
durch geeignete Anwendung von organisatorischen, personellen, infrastrukturellen
und technischen Standard-Sicherheitsmaßnahmen ein Sicherheitsniveau für ITSysteme zu erreichen, das für den normalen Schutzbedarf angemessen und ausreichend ist und das als Basis für hochschutzbedürftige IT-Systeme und -Anwendungen
dienen kann.
3. siehe entsprechende Dokumente Großbritanniens [e-GIF], der Vereinigten Staaten von Amerika
[GOSIP], Australiens [APEC] und Europas [IDABC]
4. siehe http://www.e-government-handbuch.de/
5. vgl. z. B. die Abschnitte 9.1.2, 9.2 und 9.4
6. siehe http://www.it-grundschutzhandbuch.de/
Seite 16
Die Anwendung des IT-Grundschutzhandbuchs wird in SAGA durch Festlegung als
obligatorischer Standard gefordert7.
Barrierefreie Informationstechnik-Verordnung – BITV
Die Verordnung zur Schaffung barrierefreier Informationstechnik nach dem § 11
Behindertengleichstellungsgesetz (Barrierefreie Informationstechnik-Verordnung –
BITV)8, die am 24. Juli 2002 in Kraft trat, wird in SAGA referenziert und in Bezug auf
die Realisierung der Präsentations- und Client-Schicht als obligatorischer Standard
festgelegt9.
V-Modell
Das Vorgehensmodell (V-Modell) ist der für den gesamten Bereich der Bundesverwaltung verbindliche Entwicklungsstandard für IT-Systeme der Bundesbehörden
(EStdIT). Das V-Modell muss bei strategischer Planung und Projektmanagement
sowie bei der Implementierung von E-Government-Anwendungen beachtet werden.
Als Leitfaden zum Planen und Durchführen von Entwicklungsprojekten definiert es
unter Berücksichtigung des gesamten Systemlebenszyklus die in einem Projekt zu
erstellenden Ergebnisse. Gleichzeitig beschreibt es die konkreten Vorgehensweisen,
mit denen diese Ergebnisse erarbeitet werden. Darüber hinaus legt das V-Modell die
Verantwortlichkeiten jedes Projektbeteiligten fest. Es dient somit als Vertragsgrundlage, Arbeitsanleitung und Kommunikationsbasis.
Die aktuellste Fassung ist das V-Modell XT10. Im Rahmen von Releases wird es unter
Einbeziehung aller Beteiligten ständig weiterentwickelt.
Migrationsleitfaden
Ziel des Leitfadens11 ist es, sowohl strategisch-wirtschaftliche als auch detailliert
technische Entscheidungshilfen bei einer geplanten oder gerade vollzogenen Migration zu bieten. Im Fokus steht die Ablösung von Microsoft-Produkten sowohl durch
Open-Source-Software (OSS) als auch durch nachfolgende Generationen von Microsoft-Produkten. Es werden behördenspezifische Szenarien erstellt und verschiedene
Migrationsalternativen diskutiert.
Zur Erstellung des Migrationsleitfadens wurde bei den relevanten Berührungspunkten
SAGA in der Version 1.1 berücksichtigt. Die Fortschreibung von SAGA hat keine Auswirkungen auf die gemachten Aussagen.
7. vgl. Kapitel 7 und die Abschnitte 9.1.2 und 9.2
8. siehe http://www.bmi.bund.de/Internet/Content/Themen/Informationsgesellschaft/Einzelseiten/
Verordnung__zur__Schaffung__barrierefreier__Id__90156__de.html
9. vgl. Abschnitte 4.1.5.3 und 8.5.1.1
10. siehe http://www.kbst.bund.de/
Seite 17
DOMEA
DOMEA12 steht für Dokumentenmanagement und elektronische Archivierung im ITgestützten Geschäftsgang. Ziel des Konzepts ist die Einführung der elektronischen
Akte. An die Stelle der Papierakten sollen künftig behördliche Geschäftsprozesse treten, die medienbruchfrei und vollständig elektronisch realisiert werden können. Hierbei gelten die gleichen rechtlichen und funktionalen Anforderungen wie bei Papierdokumenten. Seit der Veröffentlichung des Konzepts 1999 hat sich DOMEA zu einem
Standard in der elektronischen Vorgangsbearbeitung in Bundes-, Landes- und auch
Kommunalbehörden etabliert. Für Produkthersteller stellt DOMEA eine wesentliche
Informationsquelle zur Ermittlung der Anforderungen der öffentlichen Verwaltung dar,
die wiederum in die Weiterentwicklung der Produkte einfließen.
Gegenwärtig wird DOMEA weiterentwickelt. Das modular aufgebaute Konzept enthält
künftig neben dem Organisationskonzept und dem sich hieraus ergebenden Anforderungskatalog Erweiterungsmodule, die spezielle Themen des Organisationskonzepts
vertieft darstellen. Die Entwürfe der Weiterentwicklungen werden auf der Web-Site
der KBSt veröffentlicht und können dort diskutiert werden.
Der Anforderungskatalog des DOMEA-Konzepts setzt die organisatorischen Erfordernisse in funktionale Anforderungen um. Diese orientieren sich einerseits an den
SAGA-Standards und beeinflussen andererseits die Fortschreibung des SAGA-Dokuments. Für Software-Produkte aus dem Bereich der elektronischen Vorgangsbearbeitung beschreibt DOMEA die maßgeblichen Anforderungen. Diese gehen in einigen
Punkten über die Anforderungen von SAGA hinaus, gefährden also nicht die SAGAKonformität.
1.6
Der Evolutionsprozess
Das Bundesministerium des Innern schlägt die Standards und Architekturen vor, die
übergreifend für das E-Government des Bundes gelten sollen. Dieser Vorschlag geht
aus den Hinweisen und Anmerkungen aus den Foren zu SAGA, der Bewertung durch
den Expertenkreis und der abschließenden Formulierung durch die Autoren hervor.
Das Bundesinnenministerium stellt im Weiteren die Abstimmung mit den Bundesressorts sicher.
Die Prozess- und Datenmodellierung erfolgt aus den einzelnen E-Government-Projekten der Behörden heraus. Prozessmodelle von übergreifender Bedeutung werden
durch das für Prozesse und Organisation zuständige Kompetenzzentrum beim Bundesverwaltungsamt (BVA) standardisiert. Die Standardisierung der Datenmodelle
wird in einem zwischen dem Bundesministerium des Innern und dem Finanzsenator
Bremen (OSCI-Leitstelle) abgestimmten Verfahren koordiniert13.
Über die Entwicklung von Basiskomponenten entscheidet das Bundesministerium
des Innern in Abstimmung mit den Bundesressorts.
13. siehe dazu auch Kapitel 5 „Information Viewpoint: Schema-Repository“ auf Seite 49
Seite 18
SAGA wird in regelmäßigen Abständen fortgeschrieben, neuesten Entwicklungen und
Erkenntnissen angepasst und unter der Adresse http://www.kbst.bund.de/saga sowie
im E-Government-Handbuch unter http://www.e-government-handbuch.de/ publiziert.
1.6.1 Öffentliches Diskussionsforum
In einem öffentlich zugänglichen Forum unter http://foren.kbst.bund.de/saga können
sich Internetnutzerinnen und -nutzer registrieren und die Anwendung und Weiterentwicklung von SAGA diskutieren. Die Ergebnisse der Diskussionen werden ausgewertet und bei der nächsten Version des SAGA-Dokuments berücksichtigt.
1.6.2 Expertenkreis
Das Bundesministerium des Innern hat einen Expertenkreis mit Vertretern aus Industrie und Behörden eingerichtet und beruft deren Mitglieder. In regelmäßigen Abständen oder bei begründeten Anlässen wird die Expertenrunde in die Fortschreibung einbezogen.
1.6.3 Aufforderung zu Vorschlägen, Request for Proposals (RFP)
Wenn Problemstellungen auftreten, die durch bekannte Techniken nicht gelöst werden können, werden Aufforderungen zu Vorschlägen (RFP – Request for Proposals)
an den autorisierten Expertenkreis versandt, um Lösungsmöglichkeiten zu eruieren.
Die Vorschläge werden unter http://foren.kbst.bund.de/saga in einem geschlossenen
Expertenforum eingestellt und diskutiert.
Seite 19
Seite 20
2 Verbindlichkeit und Konformität der Anwendungen
2.1
Geltungsbereich und Verbindlichkeit von SAGA
SAGA beschreibt die empfohlenen technischen Rahmenbedingungen für die Entwicklung, Kommunikation und Interaktion von IT-Systemen der Bundesbehörden. Die
Konformität mit SAGA ist grundsätzlich verbindlich für alle Prozesse und Systeme, die
E-Government-Dienstleistungen des Bundes erbringen. Für Systeme, die keine direkten Schnittstellen zum E-Government haben, wird eine Migration empfohlen, wenn
die Kosten-Nutzen-Betrachtung positiv ausfällt. Bei der Beschaffung von StandardSoftware14 sollten vorrangig Produkte oder Produktversionen gewählt werden, die zu
der in SAGA empfohlenen Architektur kompatibel sind, siehe dazu auch
Abschnitt 2.3.1 „Definition der Konformität“ auf Seite 24.
Die Bundesministerien regeln die Verbindlichkeit von SAGA in ihren Geschäftsbereichen.
2.2
Klassifizierung und Lebenszyklen von Standards
2.2.1 Klassifizierung in SAGA
Standards werden in drei Klassen eingeordnet. Konkurrierende Standards, die nicht
aufgeführt sind, sollen nicht oder nur in Ausnahmefällen angewendet werden, siehe
dazu auch Abschnitt 2.2.3 „Erweiterte Klassifizierung von Standards“.
Obligatorisch:
Standards sind obligatorisch, wenn sie sich bewährt haben und die bevorzugte
Lösung darstellen. Diese Standards sind vorrangig zu beachten und anzuwenden.
Konkurrierende Standards können nebeneinander obligatorisch sein, wenn sich die
Anwendungsschwerpunkte deutlich unterscheiden. In solchen Fällen ist der für die
jeweilige Anwendung am besten geeignete Standard anzuwenden.
Wenn obligatorische und empfohlene oder unter Beobachtung stehende Standards
nebeneinander existieren, so sollen die letztgenannten nur in begründeten Ausnahmefällen angewendet werden.
Eine obligatorische Klassifikation bedeutet nicht, dass der Standard in jeder
E-Government-Anwendung einzusetzen ist. Nur wenn aus den Anforderungen der
Anwendung heraus der Einsatz der mit dem Standard verbundenen Technologie oder
Funktionalität erforderlich oder sinnvoll ist, soll der jeweilige obligatorische Standard
befolgt werden.
14. Software, die lediglich installiert und konfiguriert wird
Seite 21
Empfohlen:
Standards werden empfohlen, wenn sie sich bewährt haben, sie aber entweder nicht
zwingend erforderlich sind beziehungsweise nicht die bevorzugte Lösung darstellen
oder eine Einstufung als obligatorisch noch weiterer Abstimmung bedarf. Wenn es
neben empfohlenen Standards keine konkurrierenden obligatorischen Standards gibt,
so darf von den empfohlenen Standards nur in begründeten Ausnahmen abgewichen
werden.
Konkurrierende Standards können nebeneinander empfohlen sein, wenn sich die
Anwendungsschwerpunkte deutlich unterscheiden. In solchen Fällen ist der für die
jeweilige Anwendung am besten geeignete Standard anzuwenden.
Wenn empfohlene und unter Beobachtung stehende Standards nebeneinander existieren, so sollen die letztgenannten nur in begründeten Ausnahmen angewendet
werden.
Unter Beobachtung:
Standards stehen unter Beobachtung, wenn sie der gewünschten Entwicklungsrichtung folgen, sie aber noch nicht ausgereift sind oder sie sich noch nicht ausreichend
am Markt bewährt haben. Wenn es neben unter Beobachtung stehenden Standards
keine konkurrierenden obligatorischen oder empfohlenen Standards gibt, so können
unter Beobachtung stehende Standards eine Orientierungshilfe geben.
2.2.2 Lebenszyklen von Standards
Neben den in SAGA klassifizierten Standards (siehe Abschnitt 2.2.1) werden mit dem
Lebenszyklen-Modell drei Listen mit Standards eingeführt, die einen Überblick über
neue, noch zu beurteilende Standards (White List), veraltete, bereits abgewiesene
Standards (Black List) und über Standards mit Bestandsschutz (Grey List) geben.
Während die Einordnung von Standards in die Klassifikationen „Obligatorisch“, „Empfohlen“ und „Unter Beobachtung“ im SAGA-Dokument festgehalten und fortgeschrieben wird, erfolgt die Darstellung und laufende Pflege der Standards auf den Listen in
der SAGA-Rubrik der KBSt Web-Site unter http://www.kbst.bund.de/saga-standards.
Standards können in ihrem Lebenszyklus verschiedene Stadien durchlaufen, die im
Überblick in Abbildung 2-1 „Lebenszyklen von SAGA-Standards“ auf Seite 23 dargestellt werden.
Die Übergänge eines Standards zwischen den Listen in der SAGA-Rubrik unter http:/
/www.kbst.bund.de/saga-standards und den Klassen im SAGA-Dokument sind wie
folgt definiert:
Seite 22
SAGA-Rubrik
auf der KBSt-Website
SAGA-Dokument
Black List
obligatorisch
abgewiesene,
veraltete Standards
9
5
6
8
empfohlen
Grey List
7
Standards mit
Bestandsschutz
2
4
White List
unter Beobachtung
3
neue, noch nicht
klassifizierte Standards
1
neue Standards
Abbildung 2-1: Lebenszyklen von SAGA-Standards
1
Neue Standards werden vom SAGA-Team, von Experten oder von Teilnehmern des SAGA-Forums zur Klassifizierung eingebracht (siehe dazu auch
Abschnitt 1.6 „Der Evolutionsprozess“ auf Seite 18). Vor einer weiteren Evaluation werden diese Standards zunächst in der White List auf der KBSt-WebSite geführt. Die Übergänge 1 und 3 können auch in einem Schritt durchlaufen
werden.
2
Standards, die nach erfolgter Evaluation keinen Eingang in SAGA erhalten,
werden in der Black List als abgewiesene Standards geführt.
3
Nach einer positiven Prüfung werden Standards in der nächsten SAGA-Version aufgenommen.
4
Kommende Standards mit dem Status „Unter Beobachtung“ werden in der
nächsten SAGA-Version als „Empfohlen“ klassifiziert.
5
Kommende Standards mit dem Status „Empfohlen“ werden in der nächsten
SAGA-Version als „Obligatorisch“ klassifiziert.
6
Gehende Standards mit dem Status „Obligatorisch“ werden in der nächsten
SAGA-Version als „Empfohlen“ klassifiziert. Die Übergänge 6 und 7 können
auch in einem Schritt durchlaufen werden.
7
Gehende Standards mit dem Status „Empfohlen“ werden in der nächsten
SAGA-Version nicht mehr im SAGA-Dokument, sondern in der Grey List
geführt.
8
Veraltete Standards in der Grey List, die keinen weiteren Bestandsschutz
genießen, werden in die Black List überführt.
Seite 23
9
Ausgemusterte Standards mit dem Status „Unter Beobachtung“ werden direkt
in die Black List verschoben.
2.2.3 Erweiterte Klassifizierung von Standards
In der SAGA-Rubrik auf der KBSt-Web-Site unter http://www.kbst.bund.de/saga-standards wurden mit dem Erscheinen von SAGA 2.0 drei Listen zur erweiterten Klassifizierung von Standards eingeführt. Lediglich die Standards auf der Grey List dürfen
den im SAGA-Dokument klassifizierten Standards (obligatorisch, empfohlen, unter
Beobachtung) vorgezogen werden – allerdings nur bei Erweiterungen bestehender
Systeme, bei denen diese Standards bereits im Einsatz sind.
White List
Standards werden in der White List geführt, wenn sie als Vorschläge zur Aufnahme in
SAGA an das SAGA-Team herangetragen wurden und noch nicht weitergehend klassifiziert wurden. Standards in der White List werden durch das SAGA-Team und den
Expertenkreis beurteilt. Dabei kann auch der weitere Verbleib eines Standards in der
White List beschlossen werden, wenn zunächst aktuelle Entwicklungen abgewartet
und eine Entscheidung über die Klassifizierung zu einem späteren Zeitpunkt getroffen
werden soll.
Grey List
Standards werden in die Grey List aufgenommen, wenn sie in der aktuellen SAGAVersion nicht mehr geführt, in einer vorangegangenen SAGA-Version aber mit dem
Status „Empfohlen“ oder „Obligatorisch“ klassifiziert wurden beziehungsweise in der
Vergangenheit am Markt eine große Verbreitung hatten. Bei der Erweiterung bestehender Systeme stehen diese Standards unter Bestandsschutz und können weiterhin
eingesetzt werden.
Black List
Standards werden in der Black List geführt, wenn sie durch das SAGA-Team und den
Expertenkreis erfasst und abgewiesen wurden.
2.3
SAGA-Konformität
2.3.1 Definition der Konformität
Die SAGA-Konformität einer E-Government-Anwendung15 wird anhand der in SAGA
beschriebenen Modelle, Verfahren und Standards beurteilt:
a. Anwendung standardisierter Prozessmodelle
15. E-Government-Anwendung wird als Überbegriff für jegliche IT-Systeme gebraucht, die E-Government-Dienstleistungen des Bundes erbringen. Für die Definition des Begriffs E-Government-Dienstleistung siehe Abschnitt 4.1.2 auf Seite 36.
Seite 24
b. Berücksichtigung standardisierter Datenmodelle
c. Einhaltung der in SAGA beschriebenen technischen Standards und Architekturen
d. Nutzung vorhandener Basiskomponenten
Um eine umfassende Aussage über die SAGA-Konformität einer E-GovernmentAnwendung insbesondere bei der Umsetzung komplexer Fachverfahren zu ermöglichen, sollte eine Anwendung für die Konformitätsaussage zunächst in einzelne Komponenten16 untergliedert werden. Die für die SAGA-Konformität der jeweiligen Komponente relevanten Teilbereiche von SAGA können dann in einem nächsten Schritt
identifiziert und eine sinnvolle Berücksichtigung von SAGA für den jeweiligen konkreten technischen Sachverhalt sichergestellt werden.
Welche Standards für die Erfüllung der SAGA-Konformität relevant sind, hängt von
der Art der Komponente ab und kann sich je nach Funktionsumfang, Schnittstellen
und der Anwendungsarchitektur unterscheiden.
2.3.2 Konformitätserklärung
Als Hilfestellung für Behörden, IT-Dienstleister und Hersteller sind im Anhang C Vorlagen für eine SAGA-Konformitätserklärung17 beigefügt, die im Rahmen von Ausschreibungen als Grundlage für die Feststellung der SAGA-Konformität einer
E-Government-Anwendung verwendet werden sollen. Ein Beispiel einer ausgefüllten
Konformitätserklärung wird im Web unter der Adresse http://www.kbst.bund.de/sagakonformitaet zu finden sein.
Der Auftraggeber identifiziert im Vorfeld einer Ausschreibung die einzelnen Komponenten der Anwendung. Dabei ist zwischen Produktkomponenten18 und eigenentwikkelten Komponenten zu unterscheiden. Die Konformität wird für jede Komponente
anhand der im Anhang C bereitgestellten Checklisten – wie in Abbildung 2-2 auf
Seite 26 dargestellt – erklärt.
In der SAGA-Konformitätserklärung erstellt in der Regel der Auftraggeber die Übersicht der identifizierten Komponenten seiner E-Government-Anwendung und fügt die
entsprechenden Checklisten für eigenentwickelte Komponenten und Produktkomponenten bei. Wenn dem Auftragnehmer größere Freiheiten bei der Realisierung der
E-Government-Anwendung gelassen werden sollen, kann er auch selbst Komponenten identifizieren und diese nach Eigenentwicklungen und Produkten unterteilen.
In den Checklisten können durch den Auftraggeber bereits relevante Konformitätsaspekte für die jeweilige Komponente vorgegeben werden. Falls der Auftraggeber an
dieser Stelle bereits eine Festlegung auf einen bestimmten Standard wünscht, kann
er dies ebenfalls in der Checkliste vorgeben.
16. Komponenten sind nicht-triviale, in sich geschlossene, austauschbare Bausteine einer E-Government-Anwendung, die eine klare Funktion im Kontext der Architektur der Gesamtanwendung haben
und über Schnittstellen verfügen.
17. siehe Seite 179
18. Software, die lediglich installiert und konfiguriert wird
Seite 25
E-Government-Anwendung
Kom ponente 1
(Eigenentwicklung)
Kom ponente 2
(Produkt)
...
Kom ponente n
(...)
Checkliste für
eigenentwickelte
Kom ponenten
(Anhang C.2)
Checkliste für
Produktkom ponenten
(Anhang C.3)
...
Checkliste für
...
Konformitätserklärung (Anhang C.1)
Abbildung 2-2: Aufbau SAGA-Konformitätserklärung und Checklisten
Der Auftragnehmer erhält die Konformitätserklärung mit den vorausgefüllten Checklisten der identifizierten Komponenten und macht Angaben inwieweit er die Vorgaben
erfüllt.
2.3.3 Konformität bei Standards unterschiedlicher Klassifizierung
Die obligatorische Klassifikation einzelner Standards bedeutet nicht, dass diese in
jeder E-Government-Anwendung einzusetzen sind. Den obligatorischen Standards ist
bei der Auswahl der Technologien der Vorzug vor konkurrierenden Standards zu
geben. SAGA-Konformität wird deshalb durch den Einsatz der Teilmenge aller SAGAStandards erreicht, die für die jeweilige E-Government-Anwendung relevant sind.
Wenn obligatorische oder empfohlene SAGA-Standards für bestimmte Einsatzbereiche verwendet werden, können zusätzlich Standards beziehungsweise Formate eingesetzt werden, die SAGA nicht aufführt. Werden beispielsweise Daten für Tabellenkalkulationen19 im CSV-Format angeboten, können dieselben Daten zusätzlich auch
in anderen Formaten, wie Microsoft Excel, zur Verfügung gestellt werden, ohne die
SAGA-Konformität zu verletzen.
2.3.4 Verantwortung für Konformität
Die Verantwortung für die Konformität von E-Government-Anwendungen zu SAGA
liegt bei der für eine E-Government-Anwendung fachlich zuständigen Behörde. Es
obliegt auch den jeweiligen Behörden zu überprüfen, wie Fachanwendungen migriert
werden können.
Die Bundesministerien regeln die Verantwortlichkeit in ihren Geschäftsbereichen.
19. siehe Abschnitt 8.5.1.8 „Dateitypen für Tabellenkalkulationen“ auf Seite 83
Seite 26
Hilfestellungen zur Sicherstellung der SAGA-Konformität sind Teil der zukünftigen
Entwicklung von SAGA20.
2.3.5 Migration zur Konformität
Übergangsphase
SAGA wird kontinuierlich weiterentwickelt und neuen Anforderungen angepasst. Deshalb können einzelne E-Government-Anwendungen vorübergehend nicht zur aktuellen SAGA-Version konform sein.
Für nicht konforme Anwendungen sollen Migrationspläne entwickelt werden, wenn
eine Kosten-Nutzen-Betrachtung positiv ausfällt. Dies wird möglicherweise erst bei
einer wesentlichen Fortschreibung oder Erneuerung der Fall sein.
Maßnahmen zur Erzielung von Konformität
Die Konformität zu SAGA wird durch folgende Maßnahmen gefördert:
a. SAGA wird frühzeitig in Projektplanungen einbezogen.
b. Die SAGA-Konformität wird bei der Genehmigung von Projekten gefordert und
überprüft.
c. Bei Förderung, insbesondere aus Mitteln für die Initiative BundOnline 2005, wird
die Konformität zu SAGA verbindlich gefordert.
d. SAGA-Konformität wird bei der Vergabe von Aufträgen verbindlich gefordert.
2.3.6 Nicht-Konformität
E-Government-Anwendungen, die ganz oder in Teilen nicht konform zu SAGA sind,
unterliegen folgenden Restriktionen:
a. Die Nutzung von Basiskomponenten kann eingeschränkt sein.
b. Die Beratung durch Kompetenzzentren ist eingeschränkt oder nicht möglich.
c. Schnittstellen zu diesem System können ggf. nicht bedient werden.
d. Eine Förderung, insbesondere aus Mitteln für die Initiative BundOnline 2005, ist in
der Regel nicht möglich.
e. Das System kann ggf. nicht in das Dienstleistungsportal www.bund.de integriert
werden.
20. siehe Abschnitt 0.2 „Zukünftige Themenbereiche“ auf Seite 9
Seite 27
Seite 28
3 Architekturmodell für E-Government-Anwendungen
3.1
Überblick
Mit dem Architekturmodell verbindet SAGA folgende Ziele:
a. Zur Erleichterung der Kommunikation soll ein gemeinsames Verständnis aktueller
IT-Architekturen, IT-Technologien und E-Government-Strukturen erreicht werden.
b. Für E-Government verfügbare IT-Technologien sollen mit diesem Modell erfasst,
verglichen, nach Relevanz bewertet und einheitlich strukturiert werden.
c. Bei der Realisierung von E-Government-Projekten soll auf einheitliche Standards
zurückgegriffen werden können.
Um komplexe‚ verteilte E-Government-Anwendungen zu beschreiben, bietet sich das
Referenzmodell für offene, verteilte Datenverarbeitung (RM-ODP21) an. Die Betrachtung der Anwendung wird in verschiedene Sichtweisen (Viewpoints) zerlegt und so
die Komplexität der Gesamtarchitektur reduziert. Die anspruchsvolle Technik wird
dadurch verständlicher und somit beherrschbarer. Die Basis von RM-ODP ist das
objektorientierte Paradigma. Objektorientiertheit fördert klare Strukturen, Wiederverwendbarkeit und Wartbarkeit der geschaffenen Modelle, Komponenten und Systeme.
Das RM-ODP-Modell definiert fünf Sichtweisen auf ein System (siehe Abbildung 3-1):
Enterprise
Viewpoint
Information
Viewpoint
Computational
Viewpoint
Prozessmodelle
und Rollen
E-Government
Daten und
Datenmodellierung
Hardware und
Infrastruktur
Module und
Schnittstellen
Standards und
Techniken
Engineering
Viewpoint
Technology
Viewpoint
Abbildung 3-1: Viewpoints gemäß RM-ODP
21. Reference Model of Open Distributed Processing, siehe [ISO 1996]
Seite 29
a. Der Enterprise Viewpoint spezifiziert Zielsetzung, Anwendungsbereich, Verfahren
und Regeln einer Anwendung.
b. Der Information Viewpoint beschreibt die Ausprägung und Semantik der zu verarbeitenden Daten, also das Datenmodell.
c. Der Computational Viewpoint stellt die Zerlegung einer Anwendung in funktionale
Module und deren Interaktionsschnittstellen dar.
d. Der Engineering Viewpoint stellt die Verteilung der einzelnen Elemente des
Systems auf physikalische Ressourcen sowie deren Verbindungen dar.
e. Der Technology Viewpoint beschreibt die zur Realisierung des Systems verwendeten Technologien.
Mit Hilfe der fünf Sichten können sowohl existierende Systeme beschrieben werden,
als auch neue Systeme und Anwendungen modelliert werden. Der Einsatz von RMODP zur Beschreibung von E-Government-Anwendungen wird von SAGA nahe
gelegt, jedoch nicht gefordert.
Darüber hinaus wird im SAGA-Dokument das RM-ODP-Modell auf das deutsche
E-Government angewendet. So sind Kapitel entstanden, die jeweils einem Viewpoint
zuzuordnen sind, siehe Abschnitt 1.3.5 auf Seite 14. Diese Darstellung der Sichten
auf der Meta-Ebene „deutsches E-Government“ kann als Grundlage zur Entwicklung
von konkreten Modellen für einzelne E-Government-Anwendungen verwendet werden.
3.2
Enterprise Viewpoint
Der Enterprise Viewpoint für E-Government-Anwendungen beinhaltet zwei grundlegende Elemente: die organisatorische Struktur von E-Government allgemein und die
organisatorischen Modelle der Anwendung. Hier wird die Gesamtumgebung für das
System und sein Zweck beschrieben. Außerdem werden die Anforderungen an das
System, zu erfüllende Rahmenbedingungen, ausführbare Aktionen und Richtlinien
aus Sicht der Organisation oder des Unternehmens definiert. Dabei werden die Verfahren, deren Regeln und die an den Verfahren beteiligten Akteure in ihren Rollen
definiert.
Die Effizienz der Informationstechnologie hängt wesentlich von einer ganzheitlichen
Betrachtung ab. Das heißt, dass man nicht die Informationstechnologie in den Vordergrund stellt, sondern zuvorderst die fachliche Anwendung als Prozess betrachtet und
beschreibt.
Dienstleistungen sind in Form von fachlichen Prozessmodellen zu beschreiben. Hierfür sollen von der Anfrage des „Kunden“ (Bürger, Wirtschaft, andere Behörde etc.) bis
zur Leistungserbringung alle Arbeitsschritte Ende-zu-Ende betrachtet werden. Diese
Prozessmodelle sollen in einer ersten Entwicklungsstufe auf einem relativ abstrakten
Niveau verbleiben.
Seite 30
Neue Vorschläge zu Prozessdefinitionen sollen immer auf
a. Wiederverwendbarkeit,
b. Einfachheit und
c. Abbildbarkeit mit bereits vorhanden Prozessdefinitionen
überprüft werden. Hierbei soll das für Prozesse und Organisation zuständige Kompetenzzentrum22 Unterstützung leisten.
Das Kapitel 4 „Enterprise Viewpoint: Grundlagen E-Government“ auf Seite 35
beschreibt modellhaft den Enterprise Viewpoint auf das deutsche E-Government und
kann als eine Grundlage für die Erstellung dieser Sicht auf konkrete E-GovernmentAnwendungen verwendet werden. SAGA stellt im Abschnitt 8.1 „Prozessmodellierung“ auf Seite 71 Beschreibungsmittel zur Definition des Enterprise Viewpoint zur
Verfügung.
3.3
Information Viewpoint
Dieser Viewpoint legt die Struktur und Semantik der Informationen des Systems fest.
Weitere Punkte sind die Definition von Quellen (Sender) und Senken (Empfänger)
von Informationen sowie die Verarbeitung und Transformation von Informationen
durch das System. Weiterhin sind Integritätsregeln und Invarianten zu beschreiben.
Zur Definition der Datenmodelle stellt SAGA im Abschnitt 8.2 die notwendigen Mittel
bereit.
Eine stringente Prozessdefinition erfordert die Verwendung von übergreifenden
Datendefinitionen für wesentliche Datenentitäten (z. B. den Antrag) und für Daten, die
zwischen Prozessen oder Anwendungen ausgetauscht werden.
Datenmodelle sollen immer auf
a. Wiederverwendbarkeit,
b. Einfachheit,
c. Abbildbarkeit mit bereits vorhandenen Datendefinitionen
überprüft werden. Hierbei soll das für Prozesse und Organisation zuständige Kompetenzzentrum23 unterstützen.
Das Kapitel 5 „Information Viewpoint: Schema-Repository“ auf Seite 49 entspricht
dem Information Viewpoint auf das deutsche E-Government und sollte bei der Erstellung eigener Datenmodelle berücksichtigt werden. Im Abschnitt 8.2 „Datenmodellierung“ auf Seite 71 werden die anzuwendenden Technologien klassifiziert.
22. siehe Abschnitt A.10.4 „Kompetenzzentrum Vorgangsbearbeitung, Prozesse und Organisation“ auf
Seite 170
23. siehe Abschnitt A.10.4 „Kompetenzzentrum Vorgangsbearbeitung, Prozesse und Organisation“ auf
Seite 170
Seite 31
3.4
Computational Viewpoint
In dieser Sicht wird ein System in logische, funktionale Komponenten zerlegt, die für
die Verteilung geeignet sind. Das Ergebnis sind Objekte, die Schnittstellen besitzen,
an denen sie Dienste anbieten beziehungsweise nutzen.
Eine E-Government-Anwendung wird dabei prinzipiell in vier Schichten (siehe
Abbildung 3-2) zerlegt:
Sicherheit
Präsentation
Mittelschicht
Integrationskomponenten
Kommunikation
Client
Persistenz / Backend
Abbildung 3-2: Strukturelle Sicht – Schichtenmodell
a. Die Client-Schicht repräsentiert unterschiedliche Zugriffskanäle, die sich aufgrund
unterschiedlicher Benutzer, Endgeräte, Übertragungswege, aber auch unterschiedlicher Anwendungszwecke ergeben, um mit den Fachanwendungen zu
interagieren. Auf folgende Endgeräte wird in SAGA 2.1 Bezug genommen:
i. Web-Zugriff über Web-Browser oder spezielle Browser-Plug-Ins,
ii. Mobilfunktelefone und Personal Digital Assistants (PDAs),
iii. externe Systeme (z. B. ERP-Systeme von Industrieunternehmen).
b. Die Präsentation beschreibt die Informationsaufbereitung für den Client und die
Interaktion des Nutzers mit der Fachanwendung. Die Präsentationskomponente
umfasst alle Standards zur Kommunikation mit den betrachteten Endgeräten der
Client-Schicht.
c. Die Mittelschicht umfasst vor allem Neuentwicklungen für E-Government und bildet meist den Kern E-Government-spezifischer Anwendungen. In der Mittelschicht
werden die spezifischen Geschäftslogiken der Fachanwendungen verknüpft. Die
Darstellung der technischen Komponenten konzentriert sich auf die Abbildung und
Diskussion von Standards für die Mittelschicht und ihrer Schnittstellen, da hier der
höchste Integrationsbedarf im Rahmen von E-Government-Lösungen erwartet
wird. Die Mittelschicht verarbeitet die Daten aus der Persistenzschicht.
d. Die Persistenzschicht stellt die Datenspeicherung sicher. Dies wird meist mittels
Datenbanken gelöst. Das Backend steht als Sammelbegriff für Funktionalitäten
Seite 32
des Betriebssystems, spezifische Datenbanken, aber auch für bestehende, nicht
SAGA-konforme Fachanwendungen, Legacy- oder ERP-Systeme.
Innerhalb dieser Schichten wird eine Fachanwendung in Module aufgeteilt, die über
definierte Schnittstellen interagieren. Die Interaktion geschieht über lokale und entfernte Kommunikation zwischen den Modulen. Die in Anhang A definierten Basiskomponenten stellen funktionale Module zur Realisierung von E-Government-Anwendungen zur Verfügung.
Zwischen sämtlichen Modulen ist eine sichere Interaktion notwendig. Die Schutzziele
sind im Abschnitt 9.1.1 auf Seite 99 beschrieben.
Das Kapitel 6 „Computational Viewpoint: Referenz-Software-Architektur“ auf Seite 51
ist die Beschreibung eines allgemeinen Computational Viewpoint auf E-GovernmentAnwendungen, der als eine Grundlage für die Erstellung dieser Sicht für eine konkrete
Online-Dienstleistung verwendet werden kann. SAGA definiert in den Abschnitten 8.3
bis 8.7 ab Seite 73 Standards und Technologien zur Realisierung des Computational
Viewpoint. Im Kapitel 9 auf Seite 99 werden Standards und Modelle festgelegt, um
Interaktionen sicher zu gestalten.
3.5
Engineering Viewpoint
Der Engineering Viewpoint beschreibt die erforderliche Systemunterstützung, um eine
Verteilung der Objekte aus dem Computational Viewpoint zu erlauben. Dazu gehören
Ausführungseinheiten für die Objekte, wie zum Beispiel Rechner und Kommunikationsinfrastruktur, sowie alle Arten von Software-Plattformen für verteilte Systeme.
Das Kapitel 7 „Engineering Viewpoint: Referenzinfrastruktur“ auf Seite 65 beschreibt
allgemein den Engineering Viewpoint für E-Government-Anwendungen von Bundesbehörden. Daraus kann die entsprechende Sicht auf eine konkrete Online-Dienstleistung abgeleitet werden. Dem Kapitel 9 auf Seite 99 sind eine Reihe von Technologien zu entnehmen, mit denen die Sicherheit von Netzwerken unterstützt werden
sollte.
3.6
Technology Viewpoint
Diese Sicht beschreibt die gewählten konkreten Technologien zur Implementierung
und Realisierung des Systems.
SAGA beschreibt in Kapitel 8 die klassifizierten Standards für die IT-Architektur.
Sicherheitsrelevante und -unterstützende Modelle und Standards werden als Querschnittsthemen separat in Kapitel 9 übergreifend für alle Bereiche der IT-Architektur
spezifiziert.
Seite 33
Seite 34
4 Enterprise Viewpoint: Grundlagen E-Government
Entsprechend der Definition des Enterprise Viewpoint werden im Folgenden als
Gesamtumgebung für die standardisierte Einführung von E-Government-Anwendungen die allgemeinen Rahmenbedingungen für E-Government in Deutschland
beschrieben.
Neben dieser übergreifenden Betrachtung wird die prozessuale Ebene beleuchtet.
Als Rahmenbedingungen für E-Government-Anwendungen werden Prozessmodelle
entwickelt, die die Ableitung von Basisbausteinen ermöglichen.
4.1
Rahmenbedingungen für E-Government in Deutschland
4.1.1 Definition von E-Government
Bei der Verwendung des Begriffs E-Government wird oft nicht deutlich, was darunter
zu verstehen ist und welche Chancen sich daraus ergeben. Viele betrachten es nur
als weiteres Schlagwort des Computerzeitalters, andere sehen darin den nächsten
logischen Schritt der Verwaltungsinformatik oder die elektronische Ausprägung der
bisherigen Bemühungen zur Verwaltungsreform.
Folgt man der Bundesinitiative BundOnline 2005, umfasst Electronic Government alle
Prozesse der Entscheidungsfindung und Leistungserstellung in Politik, Staat und
Verwaltung, soweit diese unter weitestgehender Nutzung von Informations- und Kommunikationstechnologien stattfinden. Dabei sind die Nutzungsmöglichkeiten sehr vielfältig. Sie fangen an bei der Verwaltungsmodernisierung durch elektronische Vorgangsbearbeitung, reichen über die Bereitstellung von Verwaltungsinformationen auf
Behörden-Portalen im Internet bis hin zu den komplexen Transaktionen und interaktiven elektronischen Bürgerdiensten im Netz. Ziel ist es, externen Verwaltungskunden,
wie Bürgerinnen und Bürgern, Wirtschaftsunternehmen sowie anderen Verwaltungen,
sämtliche Behördendienstleistungen elektronisch zugänglich zu machen. E-Government steht also für den öffentlichen Sektor in der sich entwickelnden Informationsgesellschaft24.
E-Democracy-Aspekte werden hier nicht explizit aufgegriffen, da von einem unterschiedlichen Rollenverständnis ausgegangen wird, in denen der Staat den Bürgern
gegenübertritt. Im Bereich von E-Government werden die Bürger und Unternehmen
als Kunden der Verwaltung und des Staates gesehen. Im Bereich von E-Democracy
sind die Bürger der Souverän, der die Grundlagen für die Ausübung von Staatsgewalt
bildet.
24. siehe auch E-Government-Handbuch (http://www.bsi.bund.de/fachthem/egov/6.htm), Kapitel VI 1,
Modul „Das E-Government-Glossar“, Abschnitt 1.1
Seite 35
4.1.2 Abgrenzung des Dienstleistungsbegriffs
Um bestimmte Handlungsformen der öffentlichen Verwaltung als Dienstleistungen im
Sinne von E-Government verstehen zu können, muss im Vorfeld der Dienstleistungsbegriff definiert werden. Unter dem Begriff Dienstleistung wird in der Regel eine
gegen Entgelt in Anspruch genommene Leistung verstanden. Im Rahmen des fortgeschriebenen Umsetzungsplans der Initiative BundOnline 2005 wurde er für den
Bereich des E-Government abgegrenzt.
Wenn der Bürger mit dem Staat in Kontakt tritt, versteht man demnach unter einer
Dienstleistung die vollständige Abwicklung eines Prozesses für einen externen Nutzer. Dies umfasst Vorgänge, Verpflichtungen und Belastungen, wie z. B. die Anerkennung der Kriegsdienstverweigerung, die Beantragung von Arbeitslosenhilfe oder die
Erteilung einer Zolleinfuhrgenehmigung. In den nachfolgenden Ausführungen werden
deshalb unter Dienstleistungen alle Kontakte und Prozesse zwischen einem Bürger
oder der Wirtschaft und der Verwaltung verstanden25.
4.1.3 Leitbilder des E-Government
Durch E-Government ergeben sich neue Möglichkeiten zur Reform der öffentlichen
Verwaltung. Dies betrifft zum einen das Innenverhältnis der Verwaltung und zum
anderen das Außenverhältnis zwischen der Verwaltung, den Bürgern und der Wirtschaft26.
4.1.3.1 Bürgerservice
Bürger treten nicht immer freiwillig mit der Verwaltung in Kontakt. Zum Teil sind Verwaltungsvorgänge für den Bürger mit langen Wegen und Wartezeiten verbunden.
Deshalb kann die Kontaktaufnahme via Internet für große Bevölkerungsgruppen vorteilhaft sein.
Für kommende Generationen werden vernetzte Computersysteme ein Teil der natürlichen Umwelt sein. Dies zeigen auch die enormen Internetnutzerzahlen der heute 14bis 19-jährigen. Mit steigender Internetdurchdringung der Gesellschaft werden auch
die Forderungen nach Online-Dienstleistungen vermehrt gestellt.
Die Möglichkeiten, die sich durch E-Government für eine Neugestaltung der Verwaltungskontakte mit dem Bürger ergeben, sind groß. Durch Internetportale ergibt sich
die Chance, einen zentralen Zugang zur Verwaltung bereitzustellen. Deshalb ist ein
zentrales Leitbild der Initiative BundOnline 2005 die Verbesserung des Bürgerservice.
Auch in Zukunft sollte es jedem Bürger freistehen, welchen Zugang zur Verwaltung er
wählt. Er muss nach wie vor die Möglichkeit haben, zu einer Stelle gehen zu können,
wo fachkundiges Personal anwesend ist. Dementsprechend muss von der Verwaltungsseite ein Mehrkanalzugang bereitgestellt werden, der sich auf die Hauptsäulen
25. siehe auch E-Government-Handbuch (http://www.bsi.bund.de/fachthem/egov/6.htm), Kapitel VI 1,
Modul „Das E-Government-Glossar“, Abschnitt 1.2
26. siehe auch E-Government-Handbuch (http://www.bsi.bund.de/fachthem/egov/6.htm), Kapitel I, Modul
„Chefsache E-Government – Leitfaden für Behördenleiter“
Seite 36
Internet, Call Center und Bürgerbüro stützt. Sowohl das Call Center als auch das Bürgerbüro nutzen im Idealfall das Portalangebot im Internet beziehungsweise die
Anwendungsinfrastruktur, die sich dahinter verbirgt. Die eigentliche Dienstleistungserstellung bleibt dabei unabhängig vom Zugangskanal. E-Government kann somit zu
einer Verbesserung des Bürgerservice beitragen.
4.1.3.2 E-Government als Standortfaktor
Unternehmen haben oftmals eine höhere Kontaktfrequenz mit der Verwaltung als dies
bei Bürgern der Fall ist, z. B. bei Zertifizierungs-, Zulassungs- oder Genehmigungsverfahren sowie dem gesamten Dienstleistungsbereich der Zoll- und Steuerverwaltung.
Teilweise sind dies durch den Staat auferlegte Pflichten, die sowohl für die Verwaltung als auch für die Unternehmen einen enormen bürokratischen Aufwand nach sich
ziehen können. Auch langwierige und komplizierte Genehmigungsverfahren verursachen hohe Kosten und können durch den Einsatz moderner Informations- und Kommunikationstechnologien für die Unternehmen effizienter gestaltet werden. Es liegt im
beidseitigen Interesse, diese Austauschbeziehungen durch E-Government zu erleichtern.
Ein enormes Potenzial bringt auch das öffentliche Beschaffungswesen mit sich, das
bei erleichtertem Zugang zum Ausschreibungsverfahren einen wesentlich höheren
Anreiz für Firmen bieten würde.
Die Qualität der Verwaltungsleistung ist mittlerweile ein nicht zu unterschätzender
Faktor im globalen Konkurrenzkampf um attraktive Firmenstandorte geworden. Bei
einem hohen Maß an Regeln und Pflichten für Unternehmen ist es entscheidend, Barrieren so niedrig wie möglich zu halten. Diese Aufgabe wird durch BundOnline 2005
umfassend wahrgenommen. Massendienstleistungen mit einem enormen bürokratischen Aufwand, beispielsweise im Zollbereich, werden mit großem Nachdruck als
Online-Verfahren umgesetzt.
4.1.4 Organisatorische Voraussetzungen
Zur nachhaltigen Einführung von E-Government sind bestimmte organisatorische
Rahmenbedingungen zu beachten. Im Folgenden werden die wichtigsten beschrieben.
4.1.4.1 Verwaltungsübergreifende Vorgehensweise
Föderalistische Länder werden bei der Implementierung von E-Government mit den
Problemen eines dezentralen Verwaltungsaufbaus konfrontiert. Häufig sind die
dezentralen Verwaltungseinheiten weitgehend autonom von der zentralen staatlichen
Instanz. In Deutschland ist dies besonders ausgeprägt. Während die Gesetzgebungskompetenz zum Großteil vom Bund wahrgenommen wird, liegt die Ausführung der
Gesetze hauptsächlich bei den Ländern und Kommunen.
Seite 37
Die unmittelbare Bundesverwaltung übernimmt lediglich einige gesamtstaatliche Aufgaben. Einen Verwaltungsunterbau besitzen nur die im Grundgesetz (Art. 87-89) festgelegten Bereiche, wie z. B. der Auswärtige Dienst, die Bundeswehr, der Bundesgrenzschutz oder die Bundesfinanzverwaltung.
Daneben gibt es noch weitere gesamtstaatliche Aufgaben, die in der Regel von Sonderverwaltungsbehörden wahrgenommen werden. Diese sind für das ganze Bundesgebiet zuständig und haben keinen Verwaltungsunterbau. Hierzu gehören beispielsweise das Bundeskriminalamt, das Statistische Bundesamt oder auch das Deutsche
Patent- und Markenamt.
Die unmittelbare Bundesverwaltung gliedert sich in
a. Oberste Bundesbehörden, wie z. B. die Bundesministerien, das Bundespräsidialamt und das Bundespresseamt.
b. Bundesoberbehörden, die für ein spezielles Aufgabengebiet zentral für die
gesamte Bundesrepublik zuständig sind (z. B. das Bundeskartellamt),
c. Bundesmittelbehörden mit regionalen Zuständigkeiten (z. B. die verschiedenen
Oberfinanzdirektionen) und
d. Untere Bundesbehörden, die örtlich beschränkt tätig sind (z. B. Hauptzollämter).
Für bestimmte bundesstaatliche Aufgaben für den Vollzug von Gesetzen bedient sich
der Bund ausgegliederter Verwaltungsträger mit eigener Rechtspersönlichkeit. Diese
rechtsfähigen Körperschaften, Anstalten und Stiftungen der mittelbaren Bundesverwaltung sind selbstständig für ihren Sachbereich im gesamten Bundesgebiet zuständig und unterstehen der Aufsicht eines Ministeriums.
Vergleichbare Strukturen finden sich in den einzelnen Bundesländern. Hinzu kommen
die Städte, Kreise und Gemeinden, die als selbstverwaltete Gebietskörperschaften
die dritte Verwaltungsebene bilden. Neben Bundes- und Landesaufgaben nehmen sie
auch eigene Aufgaben wahr.
Insgesamt muss es Kooperation, Vernetzung und Abstimmung innerhalb und zwischen den Verwaltungsebenen geben. Ein erster Schritt war auf Bundesebene die
Realisierung des Informationsverbunds Berlin-Bonn (IVBB), mit dem ein Intranet für
Oberste Bundesbehörden geschaffen wurde. Mit dem Ausbau zum Informationsverbund der Bundesverwaltung (IVBV) werden alle Bundesbehörden in einem sicheren,
geschlossenen Netz vereint, was sowohl technisch als auch organisatorisch eine
große Herausforderung darstellt27.
Auch im Verwaltungsvollzug müssen bei der Einführung von neuen Applikationen
Insellösungen und Alleingänge vermieden werden. Es gilt neue Lösungen zwischen
den Ebenen abzustimmen, um eine möglichst flächendeckende Dienstleistungstiefe
und -breite zu erreichen und die Anwendungen der Verwaltungsebenen kompatibel
zu gestalten.
27. siehe auch E-Government-Handbuch (http://www.bsi.bund.de/fachthem/egov/6.htm), Kapitel V C,
Modul „Netzplattform für E-Government“
Seite 38
Um den gesamtstaatlichen Ansatz verfolgen zu können, wurde auf der Ministerpräsidentenkonferenz am 26. Juni 2003 eine gemeinsame Strategie für integriertes
E-Government DeutschlandOnline28 beschlossen. Bund, Länder und Kommunen vereinbarten in ihrem gemeinsamen Strategiepapier, eine integrierte E-GovernmentLandschaft in Deutschland zu schaffen.
Ebenenübergreifend sollen Verwaltungsdienstleistungen online bereitgestellt, Portale
vernetzt und gemeinsame Infrastrukturen und Standards entwickelt werden. Gleichzeitig soll die E-Government-Koordinierung verbessert und der Transfer von Lösungen beschleunigt werden. Auf diese Weise werden Doppelentwicklungen vermieden,
Kosten gespart und Verwaltungsprozesse integriert, modernisiert und optimiert.
4.1.4.2 Prozessoptimierung
Eine erfolgreiche Einführung und Umsetzung von E-Government setzt im Vorfeld
Restrukturierungsaktivitäten voraus, die auf Prozessebene ansetzen. Bestehende
Regeln sowie die Ablauf- und Aufbauorganisation müssen angepasst und verbessert
werden. Bei der elektronischen Abwicklung von Dienstleistungen stößt man ansonsten auf dieselben grundlegenden Schwierigkeiten, die sich auch bei der herkömmlichen Abwicklung ohne Zuhilfenahme der Informationstechnik zeigen.
Die bestehenden Verwaltungsabläufe sind teilweise historisch gewachsen und über
Jahre hinweg durch viele kleine Änderungen sehr komplex geworden. Folgende Maßnahmen sind daher vor der Umsetzung von Fachanwendungen empfehlenswert:
a. Vereinfachung von Verfahren
b. Deregulierung
c. Verkürzung von Prozessketten
d. Verringerung von Schnittstellen
e. Vermeidung von iterativen Durchläufen
f. Verkürzung von Durchlauf- und Liegezeiten29
Erste Schritte wurden bereits im Rahmen des Modells zum Bürokratieabbau eingeleitet30. Die Initiative zielt darauf ab, Prozesse und gesetzliche Regelungen bei hoch frequentierten, Verwaltungsebenen übergreifenden Dienstleistungen, wie z. B. beim
Passwesen und bei Kraftfahrzeugen, möglichst schnell zu vereinfachen.
4.1.4.3 Qualifizierung von Personal
Die Verwendung und Pflege von Standards bedeutet einen kontinuierlichen Informationsaustausch und Schulungsprozess. Der Erwerb von Umgangskompetenz eines
Mitarbeiters mit einem PC ist eindeutig teurer, aber auch nachhaltiger als der PC
selbst. Es zeigt sich, dass die Mitarbeiter des öffentlichen Dienstes stark motiviert
28. siehe http://www.deutschland-online.de/
29. siehe auch E-Government-Handbuch (http://www.bsi.bund.de/fachthem/egov/6.htm), Kapitel III, Modul „Phase 3 – Analyse“
30. siehe http://www.staat-modern.de/
Seite 39
sind, E-Government zu unterstützen. Dieses wichtige Kapital muss für die Umsetzung
von E-Government genutzt und vermehrt werden.
Im Vordergrund steht die intensive Schulung von Mitarbeitern und die Steigerung der
Attraktivität und Anziehungskraft der Verwaltungen für IT-Experten. Über das BMI
beziehungsweise die Projektgruppe BundOnline 2005 werden entsprechende Aktivitäten organisiert.
4.1.4.4 Einbindung der Nutzer
Der Nutzen von E-Government hängt im Wesentlichen von der Kundenakzeptanz der
angebotenen Dienstleistungen ab. Das Einsparpotenzial von E-Government kann nur
dann voll ausgeschöpft werden, wenn die bereitgestellten Online-Dienstleistungen
von den potenziellen Nutzern angenommen und genutzt werden.
Wünsche von Bürgern, Unternehmen und Behörden müssen kontinuierlich zielgruppenspezifisch abgefragt werden.
Das Dienstleistungsportfolio und der Prozess zur Erbringung der Leistung müssen
sich diesen Anforderungen anpassen.
4.1.5 Rechtliche Rahmenbedingungen
Neben den organisatorischen Rahmenbedingungen sind auch rechtliche Richtlinien
zu beachten. Im Folgenden werden die wichtigsten beschrieben. Eine ausführliche
Darstellung der vorgenommenen Rechtsanpassungen bieten das E-GovernmentHandbuch des Bundes31 und der fortgeschriebene Umsetzungsplan der Initiative
BundOnline 200532.
4.1.5.1 Elektronische Signaturen
Modernes E-Government setzt voraus, dass die Rechtsgrundlagen zeitnah angepasst
werden und so Medienbrüche vermieden werden und effizientes, papierloses Verwaltungshandeln ermöglicht wird.
Rechtliche Anpassungen
Ein wesentlicher Erfolgsfaktor für die Umsetzung von E-Government ist die Rechtsverbindlichkeit von elektronischer Kommunikation. Nötig ist deshalb eine digitale
Lösung für eine rechtsverbindliche Unterschrift: die qualifizierte elektronische Signatur. Die zum Einsatz von elektronischen Signaturen erforderlichen Rechtsanpassungen sind in Deutschland weitgehend abgeschlossen. Es ist neben der Anpassung des
Signaturgesetzes an europäische Vorgaben auch eine Einbindung der elektronischen
Signatur in die jeweiligen Generalklauseln im Verwaltungs- und Privatrecht erfolgt33.
31. siehe E-Government-Handbuch (http://www.bsi.bund.de/fachthem/egov/6.htm), Kapitel II, Modul
„Rechtliche Rahmenbedingungen für E-Government“
32. siehe http://www.wms.bundonline.bund.de/ (im Bereich > „BundOnline“ > „Öffentlichkeitsarbeit“ >
„Umsetzungsplan“)
33. für Informationen zu den rechtlichen Grundlagen der elektronischen Signatur siehe http://
www.bsi.bund.de/esig/basics/
Seite 40
Verbreitung der elektronischen Signatur
Die Verbreitung und Akzeptanz qualifizierter elektronischer Signaturen erfolgt auf
Grund des begrenzten Nutzens bei relativ hohen Kosten bisher nur langsam. Ursachen dafür sind die mangelnde Interoperabilität zwischen verschiedenen Anwendungen und die Einschränkung auf einzelne Staaten. Auch die Kosten für die Ausstattung
(Chipkarte, Software, Kartenleser) und die laufende Nutzung (regelmäßig zu erneuernde Zertifizierung des Signaturschlüssels) sowie der Aufklärungsbedarf über den
Einsatz und Mehrwert elektronischer Signaturen innerhalb der Bevölkerung sind noch
relativ hoch.
Durch den Beschluss des Bundeskabinetts vom 9. März 2005 über die Eckpunkte für
eine gemeinsame eCard-Strategie der Bundesregierung zur Unterstützung der flächendeckenden Einführung von elektronischen Karten ist zukünftig mit einer stärkeren Verbreitung von elektronischen Signaturen zu rechnen. In diesem Beschluss wird
vorgesehen, dass die geplanten Kartenprojekte der Bundesverwaltung – die Elektronische Gesundheitskarte, der Digitale Personalausweis, das JobCard-Verfahren und
die Elektronische Steuererklärung – eng aufeinander abgestimmt werden. Gemeinsames Merkmal der elektronischen Gesundheitskarte und des digitalen Personalausweises ist es, dass diese von vorne herein technisch so vorbereitet sind, dass diese
auf Wunsch der Anwender auch für qualifizierte Signaturen genutzt werden können.
Im dritten Eckpunkt wird festgelegt: „Alle Verwaltungsvorgänge, die eine qualifizierte
Signatur benötigen, akzeptieren grundsätzlich die Signaturkarten, die den im Signaturbündnis getroffenen Standards entsprechen.“
Das Signaturbündnis gründeten im April 2003 Staat und Wirtschaft, um die stärkere
Verbreitung von multifunktionalen Signatur-Chipkarten zu fördern und die oben
genannten Hindernisse zu überwinden. Dem Bündnis liegt der Gedanke zugrunde,
dass vom verstärkten Einsatz elektronischer Signaturen Staat wie Wirtschaft gleichermaßen profitieren. Denn elektronische Signaturen werden sowohl für sichere und
rechtsverbindliche E-Commerce- als auch für E-Government-Anwendungen benötigt.
Das Bündnis setzt dabei auf zwei Strategien. Zum einen haben sich die Bündnispartner bereit erklärt, sich auf gemeinsame Standards zu verständigen. Zum anderen soll
mit Hilfe tragfähiger Geschäftsmodelle die Attraktivität des Bündnisses für alle Mitglieder erhöht werden.
Erste realisierte Anwendungen zeigen, dass Chipkarten für Bürgerinnen und Bürger
dann besonders attraktiv sind, wenn diese damit sowohl private als auch staatliche
Dienstleistungen in Anspruch nehmen können.
4.1.5.2 Datenschutz
E-Government bietet im Bereich der Datenverarbeitung vielfältige Möglichkeiten und
Rationalisierungspotenziale. Im Idealfall werden Daten aus den unterschiedlichsten
Zusammenhängen nur einmal zentral erfasst und können für beliebige Zwecke
dezentral abgerufen und wiederverwendet werden.
Seite 41
Beim Austausch elektronischer Daten in und zwischen den Behörden müssen jedoch
datenschutzrechtliche Anforderungen beachtet und durch geeignete technische und
organisatorische Maßnahmen umgesetzt werden. Vor allem personenbezogene
Daten dürfen nur im gesetzlich formulierten Rahmen erhoben, verarbeitet und weitergegeben werden.
Umfassende Informationen zum Thema datenschutzgerechtes E-Government sind im
E-Government-Handbuch des Bundes in einem eigenen Modul34 dargestellt.
4.1.5.3 Barrierefreiheit
In Deutschland leben über acht Millionen behinderte Menschen, davon 6,6 Millionen
mit einer Schwerbehinderung. Insbesondere Menschen mit Sehstörungen und körperbehinderte Menschen sind bei der Nutzung des Internets auf technische Hilfen
angewiesen, wie zum Beispiel Großbildmonitor oder Lupenfunktion, Braillezeile,
Sprachausgabe oder ähnliches. Damit E-Government-Anwendungen von diesen
Geräten optimal erfasst werden können, muss bei Programmierung, Gestaltung und
redaktioneller Pflege eine Vielzahl von Regeln beachtet werden.
Am 1. Mai 2002 trat das neue Behindertengleichstellungsgesetz (BGG) in Kraft mit
dem Ziel, die Benachteiligung von behinderten Menschen zu beseitigen und zu verhindern sowie die gleichberechtigte Teilhabe von behinderten Menschen am Leben in
der Gesellschaft zu gewährleisten und ihnen eine selbstbestimmte Lebensführung zu
ermöglichen.
Dies gilt auch für die Nutzung des Internets. Die wesentlichen Kriterien und Hinweise
finden sich in der Verordnung zur Schaffung barrierefreier Informationstechnik nach §
11 BGG (Barrierefreie Informationstechnik-Verordnung – BITV), die am 24. Juli 2002
in Kraft trat.
Die BITV wendet als technischen Standard die Web Content Accessibility Guideline
1.0 (WCAG 1) aus dem Jahr 1999 an.
Die Barrierefreie Informationstechnik-Verordnung gilt für Behörden der Bundesverwaltung35 und betrifft:
a. Internetauftritte und -angebote,
b. Intranetauftritte und -angebote, die öffentlich zugänglich sind, und
c. mittels Informationstechnik realisierte grafische Programmoberflächen, die öffentlich zugänglich sind.
34. siehe E-Government-Handbuch (http://www.bsi.bund.de/fachthem/egov/6.htm ), Kapitel II, Modul „Datenschutzgerechtes E-Government“
35. siehe E-Government-Handbuch (http://www.bsi.bund.de/fachthem/egov/6.htm), Kapitel IV, Modul
„Barrierefreies E-Government“
Seite 42
4.2
Rahmenbedingungen für E-Government-Anwendungen
4.2.1 Interaktionen im E-Government
4.2.1.1 Interaktionsstufen
Generell kann man E-Government-Dienstleistungen nach den Interaktionsstufen
Information, Kommunikation und Transaktion unterscheiden36.
Information umfasst vor allem die Bereitstellung von Informationen für Bevölkerung,
Wirtschaft und andere Gesellschaftsteile. Auf dieser Stufe nimmt der Benutzer lediglich die Rolle eines Informationsempfängers ein. Dieser Bereich ist am weitesten entwickelt, nahezu alle öffentlichen Stellen sind im Internet durch umfangreiche WebAngebote präsent.
Viele dieser Informationssysteme werden durch Kommunikationslösungen mit Dialog- und Partizipationsmöglichkeiten ergänzt, um den Austausch von Nachrichten zu
ermöglichen. Diese reichen von Lösungen wie E-Mail oder web-basierten Diskussionsforen bis hin zu komplexen Anwendungen, wie z. B. Videokonferenzsystemen für
Telekooperation. Auch hier ist der Entwicklungsstand in der deutschen Verwaltung als
weit fortgeschritten zu bezeichnen.
Transaktion hat das höchste Interaktionsniveau. Dieser Bereich umfasst die eigentliche Erbringung von Dienstleistungen in der öffentliche Verwaltung. Dazu gehören
z. B. die elektronische Annahme und Bearbeitung von Anträgen oder Aufträgen sowie
die Bereitstellung von Formularen, die direkt am Computer ausgefüllt und sofort an
den zuständigen Empfänger versandt werden können. Auch elektronische Zahlungsoder Ausschreibungssysteme sind hier zuzuordnen.
Bisher sind lediglich vereinzelt Transaktionsdienstleistungen vollständig realisiert. Um
die Authentizität und Vertraulichkeit der zwischen den einzelnen Instanzen übermittelten Daten sicherzustellen, sind PKI-Infrastrukturen ein wichtiges Instrument. Vor
allem der rechtsverbindliche elektronische Austausch von Dokumenten stellt die
öffentliche Verwaltung nach wie vor sowohl vor technische als auch organisatorische
Herausforderungen, die bisher nicht befriedigend gelöst werden konnten. Hinzu
kommt die mangelnde Verbreitung der elektronischen Signatur in allen Gesellschaftsteilen.
Im Bereich der Abwicklung von Transaktionen muss noch Pionierarbeit geleistet werden. Die folgenden Ausführungen befassen sich daher hauptsächlich mit Transaktionsdienstleistungen und den hiermit verbundenen organisatorischen und technischen
Herausforderungen.
4.2.1.2 Interaktionsbeziehungen
Neben der Unterteilung nach Interaktionsstufen kann bei E-Government auch eine
Unterteilung nach den beteiligten Partnern vorgenommen werden37.
36. siehe [Lucke et al. 2000], Seite 3
37. siehe [Lucke et al. 2000], Seite 3
Seite 43
a. Government-to-Citizen (G2C)
Gemeint ist die elektronische Interaktion zwischen Bürger und Verwaltung. Dieser
Bereich umschließt auch Non-Profit- und Non-Government-Organisationen.
b. Government-to-Business (G2B)
Hierunter wird die elektronische Geschäftsbeziehung zwischen Verwaltung und
Wirtschaft verstanden.
c. Government-to-Government (G2G)
Dieser Bereich umfasst die vielfältigen elektronischen Beziehungen zwischen verschiedenen Behörden und Einrichtungen der öffentlichen Verwaltung.
Kommunen
Länder
Behörde
Behörde
Behörde
§
§
G2G
Bund
Behörde
§
G2G
G2G
G2G
Behörde
Behörde
Behörde
§
§
G2G
G2C
G2B
€
Bürger
Unternehmen
Abbildung 4-1: E-Government-Interaktionen im Überblick
Dienstleistungskunden sind somit Bürger, Wirtschaft und andere Verwaltungen. Der
Fokus liegt hier auf den Interaktionsbeziehungen G2C und G2B. Abstimmungsbeziehungen zwischen Behörden (G2G) werden im Rahmen der jeweiligen Transaktionsdienstleistungen zwischen der Verwaltung und den Bürgern beziehungsweise der
Wirtschaft behandelt. Kommunikationsbeziehungen innerhalb einer Behörde
(Government-to-Employee, G2E) werden hier nicht explizit behandelt.
4.2.2 Transaktionen im E-Government
Wie oben bereits beschrieben, handelt es sich bei den Dienstleistungen der öffentlichen Verwaltung nicht nur um Leistungen, sondern auch um Rechte und Pflichten.
Um die Handlungsformen der Verwaltung – und damit die möglichen Transaktionen –
standardisieren zu können, ist eine funktionale Kategorisierung der Verwaltung not-
Seite 44
wendig. Dadurch lassen sich allgemeingültige Typen von transaktionalen Dienstleistungen ableiten.
4.2.2.1 Transaktionale Dienstleistungstypen
Die deutsche Verwaltung lässt sich anhand von Zuständigkeiten und Rechtsformen
funktional in die Bereiche der Leistungs- und Eingriffsverwaltung kategorisieren. Aus
den kategorisierten funktionalen Verwaltungszweigen lassen sich verschiedene
Dienstleistungstypen ableiten und entsprechend in Leistungen und Eingriffe unterteilen.
Bei Leistungen fordern Bürger oder Wirtschaftsunternehmen von der Verwaltung eine
Leistung oder Vergünstigung ab, d. h. sie sind die Initiatoren. Leistungen umfassen:
a. Antragsverfahren für staatliche Geldleistungen
b. Gewährung von Subventionen
c. Förderverfahren
d. Genehmigungsverfahren
Eingriffe liegen vor, wenn die Verwaltung in die Rechtssphäre des Bürgers eingreift
und dessen Freiheit oder Eigentum belastet beziehungsweise ihm Verpflichtungen
auferlegt. In diesem Fall geht die Einleitung von bestimmten Maßnahmen von der
Verwaltung aus. Eingriffe liegen vor bei:
a. Bußgeldverfahren
b. Strafverfolgungsverfahren
c. Gerichtsverfahren
d. Einzug von Steuern
e. Einzug von Zöllen
f. Meldepflichten
Einen weiteren Dienstleistungstyp stellt das öffentliche Beschaffungswesen dar. Hier
tritt der Staat als Kunde von Wirtschaftunternehmen auf. Die Beauftragung von Leistungen oder Gütern ist an bestimmte Verwaltungsverfahren gebunden.
4.2.2.2 Teilschritte, Aktionen und Rollen bei Transaktionsleistungen
Die einzelnen Transaktionstypen lassen sich wiederum in verschiedene Teilschritte
unterteilen. Teilschritte bestehen aus einer oder mehreren Aktionen, an denen unterschiedliche Rollenträger beteiligt sind. Im Folgenden werden für den Bereich der Leistungen exemplarisch Teilschritte, Aktionen und Rollen aufgezeigt. Anhand dieser
Methodik lassen sich für jeden anderen Transaktionstyp vergleichbare Modelle ableiten.
Zur Beantragung einer Leistung muss der Bürger zunächst die Möglichkeit haben,
sich umfassend informieren zu können. Nach der Information erfolgt die Antragstellung. Der Antrag wird an die Behörde übermittelt und gelangt dort zum entsprechenden Sachbearbeiter. Eventuell müssen von anderen Organisationseinheiten oder
Behörden Stellungnahmen angefordert werden. Hier gilt es, wie bereits oben erwähnt,
Seite 45
Information
Antragstellung
Übermittlung
und Empfang
Sachbearbeitung
Stellungnahme
Entscheidung
Einzug von
Verwaltungsgebühren
Leistungs- oder
Mittelvergabe
Verwendungskontrolle
Archivierung
Übermittlung
und Empfang
Anderes Verfahren
(z.B. Rechtsbehelfsverfahren)
Abbildung 4-2: Teilschritte von Transaktionsleistungen
gegebenenfalls Prozesse zu optimieren und zu reformieren. Nach Abschluss der
Sachbearbeitung erfolgt die Entscheidung. Unter Umständen muss diese wieder an
andere Stellen zur Kenntnisnahme übermittelt werden.
Schließlich erfolgt die Übermittlung der Entscheidung an den Antragsteller. Ist die
Entscheidung im Sinne des Antragstellers, erfolgt der Abschluss des Verfahrens und
je nach Verfahren eine Mittelvergabe. Hier wiederum muss eine laufende Verwendungskontrolle möglich sein. Der letzte Teilschritt ist die Archivierung.
Sollte der Antragsteller die Entscheidung nicht akzeptieren, kann er mit Rechtsbehelfen, wie beispielsweise einem Widerspruch oder einer Klage, die Entscheidung in
Frage stellen.
Es lassen sich demnach für den Bereich der Leistungen jene Teilschritte definieren,
die in der Abbildung 4-2 und der Tabelle 4-1 in Beziehung gesetzt und näher erläutert
werden.
Jeder Teilschritt beinhaltet verschiedene Aktionen und Rollen, die von verschiedenen
Akteuren ausgeübt werden. So beinhaltet beispielsweise der Teilschritt Antragstellung als Aktionen die Antragstellung an sich, die Antragsübermittlung sowie die Ent-
Seite 46
gegennahme des Antrags. Die Rolle des Antragstellers wird im Normalfall von einem
Bürger oder einem Wirtschaftsunternehmen wahrgenommen. Die Antragsentgegennahme in der Behörde und die Übermittlung an den jeweiligen Sachbearbeiter übernimmt die Poststelle – im Idealfall eine virtuelle. Sobald der Sachbearbeiter den
Antrag erhält, bestätigt er ebenfalls dessen Entgegennahme.
Äquivalent beinhalten auch die übrigen Teilschritte Aktionen und Rollen, die in der
Tabelle 4-1 genannt werden.
Teilschritte
Aktionen
Rollen
Information
Informationsbereitstellung
Informationsabruf
Interessent
Redaktion
Antragstellung
Antragstellung
Antragsübermittlung
Antragsentgegennahme
Antragsteller
Poststelle
Bearbeiter
Sachbearbeitung
Sachverhaltsprüfung
Informationsanforderung
Informationsabgabe
Bearbeiter
vorgesetzter Bearbeiter
Antragsteller
Poststelle
weitere Bearbeiter
Stellungnahme
Informationsbewertung
Bearbeiter
weitere Bearbeiter
Entscheidung
Bescheiderstellung
Bescheidzustellung
Bearbeiter
Antragsteller
Poststelle
Einzug von VerGebühreneinzug
waltungsgebühren
Zahlungspflichtiger
Kasse
Leistungs- oder
Mittelvergabe
Bezugsberechtigter
Kasse
Auszahlung
Verwendungskon- Sachverhaltsprüfung
trolle
Informationsanforderung
Informationsabgabe
Bearbeiter
Bezugsberechtigter
Poststelle
weitere Bearbeiter
Archivierung
Archivierung
Bearbeiter
Registratur
Anknüpfung an
andere Verfahren
Datenübergabe
Antragsteller
Bearbeiter
weitere Behörden und Bearbeiter
Tabelle 4-1: Teilschritte, Aktionen und Rollen bei Transaktionsleistungen
Seite 47
Nicht jeder Dienstleistungstyp, der im Abschnitt 4.2.2.1 definiert ist, muss alle Teilschritte beinhalten. Je nach Vorgang können Teilschritte während der Bearbeitung
mehrfach auftreten.
4.2.3 Bausteine zur Implementierung von elektronischen Verfahren
Aus der dargestellten Analyse der Dienstleistungstypen mit der damit verbundenen
Identifikation von Teilschritten, Aktionen und Rollen lassen sich funktionale Bausteine
ableiten, die – mit entsprechenden Konfigurationsmöglichkeiten versehen – bei der
informationstechnischen Abbildung unterschiedlicher Verfahren verwendet werden
können. Die potenziellen Einsatzmöglichkeiten dieser Bausteine sind abhängig von
der Qualität der Prozessanalyse und der gewählten Software-Architektur38.
Bei Anwendung des beschriebenen Verfahrens lassen sich exemplarisch die folgenden Typen von Basisbausteinen definieren:
a. Benutzerschnittstelle
Anhand der analysierten Rollen ergibt sich die Notwendigkeit, Basisbausteine zu
entwickeln, die Funktionen für den Zugang zur E-Government-Anwendung ermöglichen. Hierzu gehört eine einheitliche, wiedererkennbare Benutzerschnittstelle
einschließlich Funktionen zur Benutzer- und Rollenverwaltung sowie zur Authentifizierung der Anwender im System.
b. Aktionsbausteine
Die identifizierten Aktionen werden – z. B. nach Häufigkeit des möglichen Einsatzes bei der Abbildung der Geschäftslogik priorisiert – in Anwendungsbausteine
umgesetzt. Hierbei kann zwischen dezentralen und zentralen Bausteinen unterschieden werden.
c. Integrations- und Infrastrukturbausteine
Die Definition von Basisbausteinen führt zur Entwicklung von software- oder netzwerkbasierten Komponenten, die die Kommunikation zwischen den Basisbausteinen vereinheitlichen und realisieren.
Die im Rahmen der Initiative BundOnline 2005 identifizierten Basisbausteine werden
im Anhang A auf Seite 113 näher beschrieben. Die Erstellung von Fachanwendungen
unter Einsatz wiederverwendbarer Software-Komponenten, wie BundOnline-Basisbausteine, wird im Kapitel 6 „Computational Viewpoint: Referenz-Software-Architektur“ auf Seite 51 skizziert.
38. siehe Kapitel 6 „Computational Viewpoint: Referenz-Software-Architektur“ auf Seite 51
Seite 48
5 Information Viewpoint: Schema-Repository
Die in den Kapiteln 8 und 9 folgenden Festlegungen zu Standards für IT-Architektur
und Datensicherheit sind notwendige, aber nicht hinreichende Voraussetzungen zum
Erreichen von Interoperabilität zwischen E-Government-Anwendungen der Bundesverwaltung. Die festgelegten Technologien geben den Daten keine Einheitlichkeit in
Grammatik, Semantik und Layout. Interoperable Anwendungen erfordern jedoch eine
gemeinsame Semantik für die zwischen diesen Systemen ausgetauschten Daten.
Erst durch Verwendung von gemeinsam genutzten Schemata und übereinstimmenden Definitionen von elementaren Datentypen werden hier die entsprechenden Voraussetzungen geschaffen.
Die Akteure im E-Government und ihre Kommunikationsbeziehungen sind vielfältig
und dementsprechend komplex wird der Prozess zur Vereinbarung solcher Schemata. Im Rahmen der Abstimmung und Entwicklung von Anwendungen, die eine oder
mehrere der im Abschnitt 4.2.1.2 auf Seite 43 dargestellten Interaktionsbeziehungen
nutzen, sind bereits erste Schemaübereinkünfte und -definitionen getroffen worden.
Die hier geleisteten Arbeiten wären zumindest teilweise auch in anderen Projekten
nutzbar, allerdings gibt es derzeit noch keine etablierte Kommunikationsplattform, die
dieses Potenzial erschließt.
Der Bremer Senat für Finanzen hat im Auftrag des Kooperationsausschusses ADV
Bund / Länder / Kommunaler Bereich (KoopA ADV) den Aufbau einer Leitstelle übernommen, die alle Projekte koordiniert und begleitet, die im Zusammenhang mit OSCITransport stehen. Ein entsprechendes Repository wird zurzeit aufgebaut.
Die Leitstelle in Bremen ist bei Bedarf auch Ansprechpartner und Kompetenzzentrum
für inhaltliche Schemastandardisierung für Bund-Länder-Kommunen-Projekte, wie
beispielsweise XMeld, den Standard für Daten- und Transaktionsschemata im Meldewesen.
Die Federführung für die Etablierung und Verwaltung der XML-Schemata des Bundes
übernimmt zunächst die KBSt. Das schließt insbesondere die Zuständigkeit für die
Definition der elementaren Schemata der Bundesverwaltung, den so genannten Core
Components ein. In Koordination mit der Bremer Leitstelle ist vor allem auch im Rahmen der Initiative DeutschlandOnline der Aufbau eines übergreifenden Repositories
geplant.
In diesem Repository werden die relevanten XML-Schemata bereitgestellt und um
Metadaten ergänzt:
a. Quelle
i. Autoren
ii. Ansprechpartner
b. Dokumentation
c. Versionsverwaltung
d. Angabe über den Status des Abstimmungsprozesses
Seite 49
e. Angaben über die Qualität, z. B.
i. Geltungsbereich
ii. Verbindlichkeit
Der zentrale XML-Infopoint der Bundesverwaltung entsteht zurzeit auf der Web-Site
der KBSt unter http://www.kbst.bund.de/xml-technologie. Dort kann auch die Entwicklung der gemeinsamen Plattform mit der Bremer Leitstelle beobachtet werden. Der
XML-Infopoint wird über die folgenden Funktionen verfügen:
a. Bereitstellung von Informationen
b. Kommunikationsplattform für den Erfahrungsaustausch von Entwicklern und
Anwendern der XML-Schemata
c. Bekanntgabe und Hinweise auf Methoden und Richtlinien für den Einsatz der
Schemata
d. Katalog der XML-Projekte der Bundesverwaltung mit Informationen über Projektinhalte und Ansprechpartner
e. Sammlung von Core Components
f. Aufbau und Bereitstellung von Verzeichnissen:
i. UDDI-Dienst für die Bundesverwaltung,
ii. Schema-Repository,
iii. Verweise auf weitere Verzeichnisse
g. Drehscheibe zum Austausch mit internationalen Gremien, beispielsweise im Rahmen der Standardisierung von Schemata für europäische Verwaltungsprozesse
Seite 50
6 Computational Viewpoint: Referenz-Software-Architektur
Ziel dieses Kapitels ist es, die im Rahmen von SAGA getroffenen Architekturentscheidungen zu erläutern und das daraus resultierende Architekturmodell für die einzelne
Fachanwendung darzustellen. Zu diesem Zweck werden zunächst allgemeine Voraussetzungen und Anforderungen an eine Software-Architektur für E-GovernmentAnwendungen vorgestellt. In weiteren Abschnitten werden die grundlegenden Architekturentscheidungen erläutert und in Form einer Referenzarchitektur auf eine typische, jedoch idealisierte Fachanwendung angewandt. Diese Referenz-SoftwareArchitektur beschreibt im Sinne des Computational Viewpoints nach RM-ODP39 den
technischen Aufbau von E-Government-Anwendungen. Den Abschluss bilden Folgerungen, die sich aus der Software-Architektur für den Technology Viewpoint ableiten
lassen.
Die Auswahl von Java und J2EE als Basistechnologie erfolgt unter Berücksichtigung
von Kapitel 8 „Technology Viewpoint (Teil I): Standards für die IT-Architektur“, da
diese Technologien obligatorisch40 sind. Die Referenz-Software-Architektur ist aber
auch auf andere Technologien anwendbar.
6.1
Anforderungen und Voraussetzungen
Der Computational Viewpoint in SAGA wurde eingeführt, um fachliche Hilfestellungen
beim Entwurf von E-Government-Anwendungen unter Beachtung der in SAGA deklarierten Ziele41 und der im Rahmen der Betrachtungen des Enterprise Viewpoints in
Kapitel 4 dargestellten Leitbilder und Anforderungen, schwerpunktmäßig der Wiederverwendbarkeit und Interoperabilität, zu geben. Ein zentraler Aspekt ist die Integration
von Fachanwendungen in bestehende und zukünftige E-Government-Architekturen
beziehungsweise -Infrastrukturen, insbesondere unter Berücksichtigung der hergeleiteten Basisbausteine.
6.1.1 Verwaltungsbedingte Voraussetzungen und Rahmenbedingungen
Bei den Designentscheidungen zum Aufbau einer Software-Architektur für E-Government-Anwendungen müssen bestimmte Vorraussetzungen und Rahmenbedingungen
beachtet werden. Die wichtigsten werden hier kurz erläutert.
6.1.1.1 Verwaltungsübergreifende Dienstleistungen
Wie in Kapitel 4 ausführlich beschrieben42, besteht in Deutschland eine sehr heterogene Behördenlandschaft. Diese Heterogenität wird zum einen durch den Föderalismus und den daraus folgenden unterschiedlichen Verwaltungsebenen hervorgerufen.
Daneben bestehen zudem innerhalb der einzelnen Verwaltungsebenen unterschiedli39. siehe Kapitel 3 „Architekturmodell für E-Government-Anwendungen“, Abschnitt 3.4 „Computational
Viewpoint“ auf Seite 32
40. siehe Abschnitt 8.3.1 „Applikationsarchitektur mit Middleware“ auf Seite 73
41. siehe Abschnitt 1.3.2 „Zielsetzung“ auf Seite 12
42. siehe Abschnitt 4.1.4.1 „Verwaltungsübergreifende Vorgehensweise“ auf Seite 37
Seite 51
che Zuständigkeiten, Verantwortlichkeiten und Anforderungen an die einzelnen Verwaltungszweige.
Der dezentrale Verwaltungsaufbau hat zur Folge, dass die einzelnen Verwaltungsbereiche ihre Fachanwendungen häufig unabhängig voneinander realisieren. Ein Kernanliegen des E-Government ist die medienbruchfreie Abwicklung von Online-Dienstleistungen. Insellösungen machen dies nahezu unmöglich beziehungsweise
verursachen bei der Verknüpfung von Anwendungen hohe Aufwände, was besonders
dann zum Tragen kommt, wenn eine Dienstleistung von mehreren Behörden erbracht
wird.
6.1.1.2 Prozessoptimierung
Neben der Vermeidung von Insellösungen und Doppelentwicklungen ist eine Reorganisation von Prozessketten zu empfehlen. Ziel ist es, wie auch in Kapitel 4 erläutert43,
die komplexen Verwaltungsverfahren zu vereinfachen.
Durch eine Vereinfachung der Prozesse in Fachverfahren lassen sich Fachanwendungen wesentlich kostengünstiger realisieren. Auch die Fehleranfälligkeit und die
Aufwände für Wartung beziehungsweise Erweiterungen können deutlich reduziert
werden.
So sollte beispielsweise geprüft werden, an welchen Stellen die qualifizierte digitale
Signatur unbedingt notwendig ist und in welchen Verfahren der Einsatz einer fortgeschrittenen Signatur ausreicht. Entsprechende Anpassungen des Fachrechts sind in
diesem Fall nachzuziehen.
Eine umfassende Hilfestellung zu Prozessoptimierung bietet z. B. auch das
E-Government-Handbuch44.
6.1.1.3 Beachtung des Datenschutzes
Ein weiterer zentraler Punkt bei den Designentscheidungen ist die Sicherung des
Datenschutzes. Zum einen muss bei allen Vorteilen, die sich durch eine zentrale,
nicht redundante Speicherung von Daten ergeben, gewährleistet werden, dass bei
der Datenhaltung und -verarbeitung von personenbezogenen Daten die rechtlichen
Regelungen eingehalten werden.
Daneben muss die Software-Architektur bestimmte Sicherheitssysteme beinhalten,
die beispielsweise Manipulationen von Dateninhalten und Hackerangriffe abwehren
können.
Weitere Informationen zum Thema datenschutzgerechtes E-Government sind im
E-Government-Handbuch niedergeschrieben45.
43. siehe Abschnitt 4.1.4.2 „Prozessoptimierung“ auf Seite 39
44. siehe E-Government-Handbuch (http://www.bsi.bund.de/fachthem/egov/6.htm), Kapitel V D, Modul
„eStrategie, Prozessanalyse und -gestaltung“
45. siehe E-Government-Handbuch (http://www.bsi.bund.de/fachthem/egov/6.htm), Kapitel II, Modul „Datenschutzgerechtes E-Government“
Seite 52
6.1.1.4 Weitere Rahmenbedingungen
Neben den bereits hergeleiteten und dargestellten Voraussetzungen und Rahmenbedingungen gibt es weitere, die Einfluss auf die zu treffenden Architekturentscheidungen beziehungsweise die gewählte Software-Architektur haben. Diese sind in Dokumenten nachzulesen, die im Abschnitt 1.5 „Beziehung zu anderen E-GovernmentDokumenten“ auf Seite 16 aufgeführt sind und in ihrem Geltungsbereich zu SAGA
abgegrenzt wurden.
6.1.2 Interoperabilität und Wiederverwendbarkeit
Wie beschrieben stellt vor allem die medienbruchfreie Realisierung von Transaktionsdienstleistungen organisatorische und finanzielle Anforderungen an die einzelne
Behörde. Oft ist eine behördenübergreifende Zusammenarbeit, in Form der Kopplung
von bestehenden Fachanwendungen, und der Einsatz von kostenintensiven Software-Komponenten notwendig, wie beispielsweise einer Bezahlplattform oder Modulen zur Unterstützung elektronischer Signaturen.
Um diese Herausforderungen bewältigen zu können, ist eine Wiederverwendbarkeit
von Software-Komponenten sowie Interoperabilität zwischen den einzelnen Anwendungen beziehungsweise Komponenten unabdingbar.
Durch den Einsatz von genormten und wiederverwendbaren Prozessen innerhalb
einer einheitlichen Software-Architektur im E-Government können auf lange Sicht
Kosten reduziert werden. Mittels dieser standardisierten Vorgehensweise werden
beim Entwurf und der Implementierung von Software-Projekten einheitliche Schnittstellen geschaffen, durch die Fachanwendungen den Zielen von SAGA gerecht werden können.
Zu diesem Zweck wurden im ersten Schritt in Kapitel 4 Basisbausteine abgeleitet46.
Um diese Basisbausteine bei der Realisierung von Fachanwendungen verwenden zu
können, bedürfen sie der Einbindung in eine Software-Architektur. Die SoftwareArchitektur kann nicht beliebiger Natur sein, sondern muss bestimmte Anforderungen
und Kriterien erfüllen, um die gesteckten Ziele zu erreichen.
6.1.3 Weitere Grundanforderungen an eine Software-Architektur
Neben den konkreten Zielen bei der Entwicklung einer Fachanwendung, wie sie sich
z. B. aus den spezifischen fachlichen Anforderungen ableiten lassen, gibt es auch
eine Reihe von allgemeinen Anforderungen an das zu entwickelnde System. Diese
allgemeinen Ziele beziehungsweise Grundanforderungen an eine Fachanwendung
sind bei den Designentscheidungen im Rahmen der Software-Architektur zu berücksichtigen:
a. Sicherheit
Vertraulichkeit, Authentizität und Nachvollziehbarkeit sowie die Anwendung des
Bundesdatenschutzgesetzes und die Beachtung der relevanten Kapitel des
46. siehe Abschnitt 4.2.3 „Bausteine zur Implementierung von elektronischen Verfahren“ auf Seite 48
Seite 53
E-Government-Handbuchs zum Thema Sicherheit müssen beim Einsatz von
E-Government-Anwendungen gewährleistet sein.
b. Wiederverwendbarkeit
Die Wiederverwendbarkeit einer E-Government-Anwendung oder einer ihrer Komponenten ist eines der zentralen Ziele, die durch Einhaltung beziehungsweise Verwendung von SAGA erreicht werden sollen. Eine redundante Entwicklung von
Anwendungen für ähnliche oder gleiche Dienstleistungen wird somit vermieden
und führt langfristig zu Kosteneinsparungen. Der Einsatz erprobter Module erhöht
außerdem die Qualität des Gesamtsystems.
c. Flexibilität
Anpassungen an geänderte Rahmenbedingungen und Erweiterungen sind mit
geringem Aufwand durchführbar.
E-Government-Anwendungen müssen so konzipiert sein, dass Änderungen oder
Erweiterungen der Anwendung – beispielsweise resultierend aus Gesetzesänderungen, Prozessoptimierungen oder der Verwendung durch weitere Behörden –
effektiv und kostengünstig durchgeführt werden können.
d. Offenheit
Damit die Integration bestehender oder neuer Systeme ohne größere Aufwände
möglich ist, muss das verwendete System über wohldefinierte und dokumentierte
Schnittstellen verfügen.
In vielen Behörden existieren bereits kostenintensive Legacy-Systeme. Die in
SAGA definierten Kommunikationsprotokolle sollten daher gerade im Hinblick auf
Legacy-Systeme eine reibungslose Integration erlauben. Die Offenheit einer
E-Government-Anwendung ist mitentscheidend für den erfolgreichen Einsatz der
Anwendung.
e. Skalierbarkeit
Eine Verteilung der Anwendung oder einzelner Komponenten muss bei einer
E-Government-Anwendung problemlos durchführbar sein. Nur so kann vor allem
bei steigender Nutzung der weitere Betrieb der Anwendung effizient und performant erfolgen. Gerade beim zentralen Betrieb einer E-Government-Anwendung ist
die Anzahl der nutzenden Behörden nicht festgelegt, aus diesem Grund muss eine
spätere kostengünstige Skalierbarkeit bei steigender Behörden- und Anwenderzahl gewährleistet sein.
f. Performanz
Für eine hohe Akzeptanz der nutzenden Bürger oder Unternehmen ist eine kurze
Reaktionszeit der Anwendung von entscheidender Bedeutung. Komplexe Transaktionen benötigten oftmals die Verarbeitung großer Datenmengen. Nur wenn die
Bereitstellung der Daten komfortabel und performant erfolgen kann, wird die
Anwendung erfolgreich genutzt.
g. Verfügbarkeit
Der Zugriff auf E-Government-Anwendungen muss permanent gewährleistet sein.
Durch eine ständig verfügbare Anwendung wird Zuverlässigkeit und Seriosität vermittelt, sodass die Bereitschaft der Bürger und Unternehmen wächst, die Anwen-
Seite 54
dung zu nutzen und die für die Abwicklung der Transaktion benötigten Informationen – in der Regel sensibler Natur – zur Verfügung zu stellen.
h. Fehlertoleranz
Das System muss auch mit unvorhergesehenen beziehungsweise unzulässigen
Systemzuständen umgehen können. Fehler oder unvorhergesehene Ereignisse
dürfen nicht zu einem Absturz oder einem unkontrollierten, für den Nutzer nicht
nachvollziehbaren Verhalten des Systems führen.
Wie die Verfügbarkeit ist die Fehlertoleranz wichtig für die Seriosität der Anwendung. Nur bei fehlerfreiem, transparentem Betrieb wird der Nutzer der Anwendung
das für komplexe Transaktionen notwendige Vertrauen entgegenbringen.
i. Wartbarkeit
Der Betrieb und die Pflege von E-Government-Systemen soll mit möglichst geringem Aufwand möglich sein. Externe Fachleute, die nicht an der Entwicklung des
Systems beteiligt waren, müssen ohne größere Einarbeitung seine effiziente Wartung sicherstellen können.
Die obige Aufzählung spiegelt eine ungefähre Gewichtung der einzelnen Anforderungen unter software-technischen Gesichtspunkten wider. Eine konkrete Gewichtung
der verschiedenen Punkte hängt von Faktoren ab, die im Rahmen des Konzepts der
einzelnen Fachanwendung erarbeitet und bewertet werden müssen. So ist beispielsweise bei Anwendungen, die über sehr hohe Zugriffszahlen verfügen, eher die Verfügbarkeit von Bedeutung, während bei umfangreichen Genehmigungsverfahren eher
die Sicherheit im Vordergrund stehen könnte.
6.2
Architekturentscheidungen
Die hier dargestellte Software-Architektur beinhaltet einige grundlegende Designentscheidungen. Dies sind die unbedingte Verwendung von objektorientierten SoftwareEntwicklungsparadigmen und ein darauf aufsetzendes, komponentenbasiertes Software-Entwicklungsschema.
Komponentenbasierte Software-Entwicklung
Software-Komponenten definieren sich im Kontext dieser Referenz-Software-Architektur genau wie im Abschnitt 2.3.1 ab Seite 24 dargelegt.
Komponentenbasierte Software-Entwicklung erlaubt die Zusammensetzung von Software aus bestehenden Komponenten und deren Wiederverwendung. Die dabei
erhofften positiven Effekte sind:
a. schnellere Anwendungsentwicklung und Anwendungsbereitstellung
b. gesenkte Kosten
c. gesteigerte Qualität
d. reduzierte Komplexität
e. flexible Anwendungssysteme und moderne Systemarchitekturen
Seite 55
Der Einsatz von komponentenbasierter Software-Entwicklung hat nicht nur positive
Folgen. Der Entwicklungsaufwand ist anfangs erhöht, zusätzliche Personalschulungskosten können anfallen und durch Designfehler kann eine ungewünschte Abhängigkeit von Komponenten geschaffen werden, die die Systemarchitektur negativ beeinflusst. Obwohl die Vorteile sich eher mittel- und langfristig auswirken und kurzfristig
die negativen Effekte nicht auszuschließen sind, ist der Bereich E-Government aufgrund der Projektlaufzeiten und dem hohen Grad ähnlicher Anwendungen für den
Einsatz von Software-Komponenten hervorragend geeignet. Zur Entwicklung von
robusten, wiederverwendbaren Komponenten müssen die funktionalen Abgrenzungen der Komponenten klar definiert werden, um maximalen Nutzen durch Reduzierung von Parallelentwicklungen zu erzielen.
Trennung von Präsentations- und Geschäftslogik
Eine Trennung von Präsentations- und Geschäftslogik bietet eine technische Lösung
zur optimalen Unterstützung von mehreren Präsentationskanälen wie verschiedener
Browser-Typen oder mobiler Endgeräte, z. B. Personal Digital Assistants (PDAs).
Neben diesem Aspekt führt die Trennung von Präsentations- und Geschäftslogik zu
einer wesentlich besseren Strukturierung des Codes, wodurch Wartbarkeit, Fehlerbehebung, Flexibilität, Wiederverwendbarkeit und Nachvollziehbarkeit deutlich verbessert und schließlich mittelfristig die Kosten gesenkt werden. Außerdem führt die Trennung zu einer potenziellen Verteilbarkeit der Anwendung auf mehrere Server, wobei
ein Server die Präsentationsschicht und ein zweiter Server die Geschäftslogik
bedient. Damit wird der Betrieb in den Aspekten Sicherheit, Wartbarkeit und Skalierung positiv beeinflusst. Hierbei sollte besonderes Augenmerk auf die Kommunikation
gelegt werden, da eine nicht optimale Verteilung die Performanz negativ beeinflusst.
Trennung von Geschäfts- und Datenlogik
Die Trennung von Geschäfts- und Datenlogik führt zu Applikationen, die unabhängig
vom Datenbanktyp47 sind. Gleichzeitig sind die Funktionalität und die Performanz
nicht unmittelbar von der Datenbank abhängig. Diese Datenbankunabhängigkeit wird
für die Funktionalität durch Abstraktion erreicht und für die Performanz z. B. durch
Caching.
Vier-Schicht-Architektur
Die Umsetzung der genannten Punkte führt zu einer Mehrschichtarchitektur aus vier
Schichten. Der Aufbau einer Fachanwendung in Schichten unter Einbeziehung von
Komponenten benötigt eine klare Zuordnung von Komponenten zu jeweils einer
Schicht. Dies erleichtert die Klassifizierung von Komponenten und impliziert eine formale Abgrenzung ihrer Funktionalität.
47. im Sinne von relationaler Datenbank gegenüber objektorientierter Datenbank
Seite 56
Client
Mobile Device
Web-Browser
Präsentation
HTML / XML
Servlets
Java Server Pages
Mittelschicht
Presentation Application Server
Applikationskomponente
Anwendungsschnittstelle
SOAP
JMS
RMI
Business Application Server
Persistenz /
Backend
DBMS
LegacySystem
ERP-System
Abbildung 6-1: Beispielmodell einer Vier-Schicht-Architektur von
E-Government-Anwendungen
Die einzelnen Schichten der Mehrschichtarchitektur sind die Client-Schicht, die Präsentationsschicht, die Mittelschicht und Persistenzschicht / Backend.
a. In der Client-Schicht findet die Interaktion zwischen Benutzer und ApplikationsSoftware statt. Die von der Präsentationsschicht aufbereiteten Daten sowie das
User Interface werden visualisiert.
b. Die Präsentationsschicht ist für die Darstellung der Anwendungsdaten (z. B. als
Web-Seite) zuständig.
c. Die Mittelschicht, auch Applikationsschicht genannt, beherbergt die wesentlichen
Komponenten zur Implementierung der Anwendungslogik, unabhängig von deren
Präsentation. Hier findet die Programmablaufkontrolle statt. Dementsprechend
werden die Daten aus der Persistenzschicht aufbereitet und an die Präsentationsschicht übergeben. In dieser Schicht finden z. B. die Validierung der Benutzereingaben oder die Autorisierung statt. Ein optionaler Teil dieser Schicht realisiert bei
Bedarf die Integration von zentralen Komponenten, Legacy- oder ERP-Systemen.
Über Anwendungsschnittstellen kann externen Diensten ein Zugriff auf die Applikation unter Umgehung der Präsentationsschicht ermöglicht werden.
Seite 57
d. Die Persistenzschicht ist für die Speicherung von Datenobjekten zuständig. Sie
abstrahiert von der Datenbank. Das Backend steht als Sammelbegriff für Funktionalitäten des Betriebssystems, spezifische Datenbanken, aber auch bestehende
nicht SAGA-konforme Fachanwendungen, Legacy- oder ERP-Systeme.
Auf Abbildung 6-1 auf Seite 57 wird der Aufbau grafisch veranschaulicht. Man erkennt
den Aufbau der Präsentationsschicht, die aus einem Presentation Application Server
für Präsentationsaufbereitung und entsprechenden einzelnen Komponenten, wie
Servlet Engine, besteht. Der Business Application Server in der Mittelschicht bildet
das Rückgrat der Anwendung und ermöglicht über Anwendungsschnittstellen die Nutzung der Fachanwendung durch andere Applikationen als Service.
Für einfache Anwendungen, die weder transaktionsbasiert noch mit besonderen integrativen Funktionalitäten ausgestattet sind, kann auf eine Mittelschicht verzichtet werden. Dieser Fall wird aber im Rahmen der folgenden Betrachtung einer idealisierten,
typischen Fachanwendung nicht weiter ausgeführt.
Java und J2EE
Die Umsetzung der Mehrschichtarchitektur erfolgt bevorzugt mit der Programmiersprache Java, im Sinne des Abschnitt 8.3.1 „Applikationsarchitektur mit Middleware“
des Technology Viewpoints auf Seite 73. Die Entscheidung für den Einsatz von Java
basiert auf der Plattformunabhängigkeit, der optimalen Unterstützung von objektorientierten Software-Techniken, der Stabilität der Ausführungsumgebung und der großen
Anzahl der frei oder auch kommerziell verfügbaren APIs. Als Konklusion kann gesagt
werden, dass die Verwendung von Java eine Mehrschichtarchitektur optimal unterstützt.
Die Orientierung auf eine Mittelschicht und die Verwendung von Java bedeutet sinnvollerweise den Einsatz von J2EE. Damit erhält man ein detailliertes technisches
Paradigma zur Software-Erstellung und die Basis eines Application Frameworks.
Ein Application Framework definiert das Standardverhalten und die Struktur aller
Anwendungen mittels einer aufeinander abgestimmten Gruppe von abstrakten48 und
konkreten49 Klassen. Das Erstellen von neuen Anwendungen wird durch Ableitung
konkreter Klassen von den abstrakten Framework-Klassen und durch Hinzufügen von
eigenständigen, anwendungsspezifischen Klassen realisiert. Hinsichtlich des Einsatzzwecks von Application Frameworks und Komponenten werden ähnliche Ziele verfolgt. Application Frameworks sollen auch zur Wiederverwendbarkeit von Programmbestandteilen führen. Dies wird dabei jedoch auf Klassenebene durch Vererbung
vollzogen. Der Produktivitäts- und Qualitätssteigerung bei der Entwicklung interaktiver
Anwendungssysteme stehen jedoch einige Nachteile gegenüber, wie eine hohe Komplexität und starre Strukturen, die zu unvorhergesehenen Problemen bei der Anwendungsentwicklung führen können. Das attraktive Konzept eines Application Frame-
48. Abstrakte Klassen definieren nur Schnittstellen, die dann durch konkrete Methoden einer Unterklasse
ausgefüllt werden.
49. fertige, vollständig implementierte Klassen mit einer bestimmten Funktionalität
Seite 58
works zur Wiederverwendung von Software-Strukturen wird jedoch durch den
Komponentenansatz flexibilisiert und damit optimal ergänzt.
Schwache Kopplung von verteilten Komponenten
Die Verbindung der Schichten und Komponenten zu einem harmonischen Gesamtsystem innerhalb der Mehrschichtarchitektur erfolgt mittels standardisierter, gleichartiger Schnittstellen. Dies ist notwendig, um Anwendungen aus beliebigen Komponenten zusammenfügen zu können. Weiterhin ist eine schwache Kopplung von verteilten
Komponenten zu bevorzugen.
Komponentenkommunikation über Methodenaufrufe oder Web Services
Bei Komponenten aus der Client- und Präsentationsschicht kommen Netzwerkprotokolle auf HTTP-Basis als Kommunikationsmittel zur Anwendung. Die Komponenten
der Applikationsschicht kommunizieren über entsprechende Methodenaufrufe beziehungsweise über Schnittstellen, die durch ein Komponenten-Framework vorgegeben
sind. Bei der Kommunikation mit verteilten beziehungsweise dem Einsatzzweck entsprechend nur zentral verfügbaren Komponenten wird auch in der Mittelschicht auf
eine Kommunikation über Web Services zurückgegriffen.
Datenschnittstellen auf XML-Basis
Datenschnittstellen zu Fremdsystemen sind grundsätzlich über XML und entsprechende Schemadefinitionen zu realisieren50.
6.3
Referenzarchitektur für E-Government-Anwendungen
Die im vorangegangenen Kapitel aufgeführten Architekturmerkmale werden anhand
einer Referenzarchitektur für eine idealisierte, typische Fachanwendung vertieft und
angewandt. Diese Fachanwendung ist, wie im Abschnitt über die Architekturentscheidungen erläutert, nach dem Vier-Schicht-Modell und komponentenbasiert aufgebaut.
6.3.1 Grundfunktionalitäten der verwendeten Komponenten
Allen Komponenten einer Anwendung ist gemeinsam, dass sie auf allgemeine Dienste einer Infrastruktur, wie Unterstützung von Testmethoden, Logging und Monitoring,
zurückgreifen können. Dies stellen vorgegebene Infrastrukturschnittstellen der Komponenten sicher. Zu Hinweisen auf die Realisierung dieser Grundfunktionalitäten
siehe http://www.kbst.bund.de/saga-tools.
Unterstützung von Testmethoden
Neben den Empfehlungen zur Software-Strukturierung gibt es auch ablauforganisatorisch-orientierte Richtlinien. So wird häufig das wichtige Testen der Applikation vom
eigentlichen Entwicklungsschritt getrennt und bisweilen auch vernachlässigt. Es bietet
50. siehe Kapitel 5 „Information Viewpoint: Schema-Repository“ auf Seite 49
Seite 59
sich an, bereits bei der ohnehin erforderlichen Erstellung des Pflichtenhefts auf Testszenarien einzugehen und diese in den Entwicklungsprozess fest zu integrieren.
Logging
Zur Erleichterung des Betriebs der Applikation wird ein einheitlicher Umgang mit
Systeminformationen empfohlen. Dazu sind standardisierte Log-Komponenten und
-Formate vorzusehen. Die Größe einer Logdatei darf nicht beliebig wachsen, muss
aber auch einen angemessenen Zeitraum abdecken. Daher ist ein Mechanismus für
ein Logdatei-Management erforderlich. Dies kann auf Dateigrößen oder zeitlichen
Aspekten basieren. In der Logdatei sollten im Normalbetrieb nur Fehler aufgezeichnet
werden. Damit auch Daten aufgezeichnet werden, die beispielsweise zu Analysezwecken benötigt werden, muss ein Mechanismus vorhanden sein, der Log-Level und
das Ein- und Ausschalten von Log-Nachrichten bestimmter Level ermöglicht. LogLevel dienen zur Klassifizierung von Ereignissen im Bezug auf deren Relevanz im
Kontext der Applikation oder Komponentenfunktion. Dazu ist es vorteilhaft, sich in der
Designphase der Software-Architektur klar zu machen, in welchen Fällen welche LogLevel zum Einsatz kommen.
Monitoring
Unter Monitoring wird in diesem Kontext ein Überwachen des Systems beziehungsweise einzelner Ressourcen im laufenden Betrieb verstanden, beispielsweise hinsichtlich des Status oder der Performanz. Der Monitoring-Service soll den Systembetreibern ein Instrument an die Hand geben, mit dem sie den aktuellen Systemzustand
feststellen können. Dazu sind die Betriebsbedingungen und Zustände zu definieren
und entsprechende Möglichkeiten auf Applikationsseite vorzusehen, um Auskunft
über den Systemzustand zu geben.
Konfigurationsmanagement
Hierunter wird in diesem Kontext die Konfiguration des Systems beziehungsweise
von Ressourcen des Systems verstanden. Für alle Komponenten sollte möglichst der
gleiche Mechanismus eingesetzt werden, der die Konfiguration von einer zentralen
Stelle aus ermöglicht. Wichtige Systemparameter sollten auch zur Laufzeit des
Systems konfiguriert werden können. Applikationslösungen basieren meist auf statischen, in so genannten Property-Dateien abgelegten Konfigurationen. Die Rekonfiguration, z. B. die Änderung des Log-Levels, erfordert oft einen Neustart der Applikation.
Dies sollte vermieden werden.
Fehlerbehandlung
Kann eine Komponente ihre Funktion nicht wahrnehmen und bricht deshalb mit einem
Fehler ab, muss der Fehler über den gesamten Verarbeitungspfad hinweg nachvollziehbar sein. Das heißt, dass aus der Protokollierung einer Fehlersituation ersichtlich
sein muss, woher sie stammt. In der Regel ist dem normalen Stacktrace einer Anwendung diese Information zu entnehmen. Zudem muss die Protokollierung möglichst
Seite 60
viele zusätzliche Informationen enthalten, damit das Problem schnell eingegrenzt und
behoben werden kann. So hat sich z. B. bewährt, in Web-Anwendungen den vollständigen Request (inklusive URL), der zu diesem Fehler führte, mit anzugeben.
Sicherheit
Komponenten, die Zugang zu kritischen oder sensitiven Daten gewähren oder schreibende Transaktionen auf solchen Daten ausführen, müssen den im Kapitel 9 „Technology Viewpoint (Teil II): Standards für Datensicherheit“ auf Seite 99 genannten
Sicherheitsanforderungen genügen.
6.3.2 Aufbau einer typischen Fachanwendung
Ausgehend von einer vorhandenen Behördeninfrastruktur ergibt sich die Aufgabe,
Fachanwendungen zu erstellen, die sich dort gut eingliedern lassen und gleichzeitig
mit bestehenden Anwendungen kooperieren können. Die Kooperation erstreckt sich
nicht nur auf Kommunikation, sondern vor allem auf eine technologische Gleichartigkeit, wie sie in SAGA angestrebt wird, um Installations-, Wartungs- und Erstellungskosten zu minimieren. Beim Entwurf einer zu erstellenden Fachanwendung wird im
Sinne des Komponentengedankens ausgewählt, welche Komponenten neu entwikkelt werden müssen und wo bestehende verwendet werden können. So sind vorrangig die im Anhang A „Basisbausteine der BundOnline-Initiative“ ab Seite 113 aufgeführten Basiskomponenten auf Einsetzbarkeit zu prüfen.
Die betrachtete Fachanwendung realisiert eine transaktionale E-Government-Dienstleistung und folgt dabei dem im Enterprise Viewpoint im Abschnitt 4.2.1.1 „Interaktionsstufen“ auf Seite 43 gesetzten Schwerpunkt.
Im Regelfall wird es eine Kommunikation zwischen der Client-Schicht, dem hier favorisierten Web-Browser als Thin Client, und der Präsentationsschicht geben. Einzelne
Komponenten der Präsentationsschicht kümmern sich um die Aufbereitung der
Daten, die z. B. in XML vorliegen können, in das vom Web-Browser benötigte HTMLFormat.
Die eigentliche Applikationslogik wird in der Mittelschicht realisiert. Aufgaben einer
Web-Anwendung sind beispielsweise Benutzereinangaben zu validieren und mit entsprechenden Datenbeständen abzugleichen sowie die Daten aufbereitet zur Präsentationsschicht zu übertragen.
In der Mittelschicht erfolgt auch die Kommunikation und logische Integration von
Basiskomponenten, wie ePayment und Datensicherheit, sowie „Einer für Alle“ (EfA)
Dienstleistungen. Externen Anwendungen werden die Dienste der Fachanwendung
über Anwendungsschnittstellen angeboten. Gemäß den im Abschnitt A.1.3 auf
Seite 115 aufgeführten Geschäftsvorfällen realisiert die Basiskomponente ePayment
Bezahlvorgänge. Die Einsatzbedingung der Basiskomponente erfordert, dass sie an
zentraler Stelle beim Bundesamt für Finanzen betrieben wird. Damit erfolgt die Anbindung an die Fachanwendung mittels Web Services auf SOAP-Basis51. Die Basiskom51. siehe „Simple Object Access Protocol (SOAP) v1.1” auf Seite 91
Seite 61
EfA-Dienstleistung
Client
Mobile Device
Präsentation
Web-Browser
Mittelschicht
Basiskomponente
ePayment
Präsentation
Basiskomponente
Datensicherheit
Mittelschicht
Externe
Anwendung
Basiskomponente
CMS
Basiskomponente
Portal
Infrastrukturkomponente
Verzeichnisdienst
Basiskomponente
Formularserver
Verwaltungs-PKI
ERP-System
Fachanwendung
IVBV-Infrastruktur
Legacy-System
ERP-System
Abbildung 6-2: Referenz-Software-Architektur
ponente Datensicherheit wird dezentral betrieben und deckt gemäß den Geschäftsvorfällen die Sicherheitsaspekte des Dokumentenaustausches und der E-MailKommunikation ab.
Neben der Benutzung von SOAP wird zur Kommunikation mit verteilten Komponenten Remote Method Invocation (RMI)52 oder auch ein Message Service53 eingesetzt.
Die Komponenten der Persistenzschicht realisieren den Datenbankzugriff und implementieren Caching-Strategien.
In der Realität wird eine Fachanwendung immer mit Integrationslösungen ausgestattet werden müssen, da sie mit einer bereits bestehenden Datenhaltung kommunizieren muss. Diese Integrationskomponenten, in Abbildung 6-2 „Referenz-SoftwareArchitektur“ gezeigt, siedeln sich direkt an der Mittelschicht an. Hierzu werden die zu
entwickelnden Komponenten Kommunikationsmöglichkeiten zu Systemen wie z. B.
SAP-Lösungen bieten.
Die Umsetzung einer realen Fachanwendung beschäftigt sich hauptsächlich mit der
Realisierung von identifizierten Komponenten und deren Anbindung an die erwähnten
Basisfunktionalitäten. Die Anforderungen an die Software-Qualität der Komponenten
sind bei intendierter Wiederverwendbarkeit hinsichtlich funktionaler Abgrenzung,
Robustheit und Dokumentation hoch. Als abschließenden Schritt gilt es, die Kompo52. siehe „Remote Method Invocation (RMI)” auf Seite 91
53. siehe „Java Message Service (JMS) v1.1, J2EE Connector Architecture v1.5” auf Seite 75
Seite 62
nenten zu einer lauffähigen Applikation zusammenzusetzen. Dabei kann man aber
zum einen auf entsprechende Frameworks und zum anderen auf das von allen Modulen unterstützte Konfigurationsmanagement zurückgreifen.
Für die Konzeption von Antragsverfahren hat die Projektgruppe BundOnline eine
Musterarchitektur veröffentlicht [PGBO 2005c]. Sie zeigt das Zusammenspiel aller
Komponenten einer antragsorientierten Dienstleistung aus verschiedenen Blickwinkeln.
6.4
Folgerungen aus der Software-Architektur
Die in diesem Kapitel dargelegten Voraussetzungen und Architekturentscheidungen
haben vielfältige Auswirkungen auf die folgenden Kapitel zum Engineering und Technology Viewpoint.
Die zugrunde liegenden Architekturentscheidungen finden sich teilweise als obligatorische Standards dokumentiert in den entsprechenden Abschnitten wieder. Hierzu
gehört z. B. die Festlegung auf J2EE im Abschnitt 8.3.1 „Applikationsarchitektur mit
Middleware“ auf Seite 73.
Seite 63
Seite 64
7 Engineering Viewpoint: Referenzinfrastruktur
Die Wahl der richtigen Infrastruktur ist ein zentraler Erfolgsfaktor für die Planung und
den Betrieb von E-Government-Anwendungen: Eine stabile und sichere IT-Infrastruktur ist die Grundvoraussetzung für den hochverfügbaren und zuverlässigen Betrieb
von E-Government-Anwendungen. Aktuelle Anforderungen an Datenschutz, Datensicherheit, Leistungsfähigkeit und Verfügbarkeit von E-Government-Anwendungen setzen hohe Maßstäbe an die Betreiber der Anwendungen und ihre Infrastruktur.
Die Modellierung der Referenzinfrastruktur für E-Government-Anwendungen erfolgt
gemäß dem Engineering Viewpoint nach RM-ODP54 und beschreibt die Kapselung
von Systemeinheiten und ihre Verbindungen. Die beschriebenen Standards und
Technologien der Referenzinfrastruktur sind im eigentlichen Sinn nicht Bestandteil
eines Engineering Viewpoints, wurden aber mit dem Ziel einer möglichst praxisnahen
Darstellung aufgenommen. Die folgenden Ausführungen können nach dem TopDown-Prinzip zu einem Engineering Viewpoint auf eine einzelne Fachanwendung
konkretisiert werden.
Hierbei sind insbesondere die Empfehlungen des Bundesamtes für Sicherheit in der
Informationstechnik (BSI) zur Sicherheit von E-Government-Anwendungen55 und das
IT-Grundschutzhandbuch56 des BSI zu berücksichtigen. Bei der Feststellung eines
geringen Schutzbedarfs für die Fachanwendungen sind geringere Sicherheitsanforderungen an die konkrete Infrastruktur möglich als in der folgenden Referenz berücksichtigt werden.
Nicht jede Behörde benötigt eine eigene, vollständige E-Government-Infrastruktur.
Kleinere Institutionen können die Rechenzentren externer IT-Dienstleister oder übergeordneter Behörden nutzen.
7.1
Aufbau einer E-Government-Infrastruktur
Die Einführung einer Referenzinfrastruktur in SAGA dient dem Ziel, die erforderlichen
infrastrukturellen Voraussetzungen für den Betrieb von E-Government-Anwendungen
und die dafür erforderliche Systemarchitektur zu definieren. Folgende Ziele sollen mit
einer Festlegung von Parametern für eine Referenzinfrastruktur im Sinne einer
Betriebsumgebung erreicht werden:
a. physikalischer Schutz der Systeme
b. höchstmögliche Verfügbarkeit der Systeme
c. Erhöhung der Sicherheit von Systemen und Systemkomponenten durch eine
Klassifizierung nach ihrem Schutzbedarf
d. Einordnung von Systemen und Systemkomponenten in getrennte Sicherheitszonen
54. siehe Kapitel 3 „Architekturmodell für E-Government-Anwendungen“, Abschnitt 3.5 „Engineering
Viewpoint“ auf Seite 33
55. siehe E-Government-Handbuch unter http://www.e-government-handbuch.de/
Seite 65
e. Skalierbarkeit von Systemen und Infrastruktur
f. einfache Pflege, effektive Wartung komplexer E-Government-Anwendungen und
Systemkomponenten durch das Betriebspersonal
Externe
Fach-Externe
anwendung
Fach-anwendung
Benutzer
Zentraler
BasisZentraler
baustein
Basisbaustein
Benutzer
Benutzer / externe Dienste
IVBV
Internet
Extranet,
VPN
Netzwerk
Netzwerkzugang
Zugangskontrolle
Informations- und Dienstzone
Zugangskontrolle
Zugangskontrolle
Logik- und Verarbeitungszone
Zugangskontrolle
Zugangskontrolle
Datensicherung
Management-Zone
Zugangskontrolle
Datenzone
Infrastruktur
Externe
Sicherung
Abbildung 7-1: Engineering Viewpoint einer E-Government-Anwendung
Seite 66
In Abbildung 7-1 wird eine allgemeine Gesamtsicht einer verteilten E-GovernmentAnwendung auf die Bereiche Benutzer, Netzwerk und Infrastruktur dargestellt.
Sowohl der Bereich des Netzwerks als auch der des Benutzers liegen in der Regel
außerhalb der Kontrolle des Betreibers einer E-Government-Anwendung und sind
daher nicht Schwerpunkt dieser Betrachtung. Der Infrastrukturbereich hingegen wird
durch den Betreiber kontrolliert und muss durch seine Architektur und Systemstruktur
den Betriebsanforderungen für E-Government-Anwendungen genügen.
Im Folgenden werden die Anforderungen an ein Rechenzentrum und seine IT-Infrastruktur beschrieben.
7.1.1 Physikalische Infrastruktur
Der Schutz von Systemen gegen äußere Einflüsse, Naturgewalten und unbefugten
Zugang setzt die Einrichtung eines geeigneten Raumes voraus. Rechenzentren, die
den Betrieb von E-Government-Anwendungen planen, sollten daher mindestens über
die folgenden Eigenschaften verfügen:
a. feuerfester, funkentstörter und baulich geschlossener Sicherheitsraum
b. Eintrittskontrolle mit personenbezogener Authentifizierung
c. Löschanlage mit nicht-korrosiven und nicht-toxischen Löschmitteln
d. redundante Energieversorgung mit einer Einrichtung zur unterbrechungsfreien
Stromversorgung
e. redundant ausgelegte Klimaanlage
f. Datensicherung in einem feuerfesten Tresor außerhalb des Rechenzentrums
7.1.2 Zonenkonzept und Kommunikationsbeziehungen
Die Systeme innerhalb des Rechenzentrums werden in verschiedenen Zonen platziert, die anhand der Sicherheitsanforderungen für Dienste und Daten der jeweiligen
Zone definiert werden. Um den grundsätzlichen Schutzbedarf von E-GovernmentAnwendungen durch das Zonenkonzept abdecken zu können, sollen mindestens die
im Folgenden beschriebenen vier Zonen in der Infrastruktur eines Rechenzentrums
implementiert werden. Für den Betrieb komplexer E-Government-Anwendungen können weitere Zonen erforderlich werden. Dabei sollte auf eine strikte physikalische
Trennung der Zonen geachtet werden, das bedeutet:
a. Eine Netzwerkkomponente (Router, Switch, Hub o.ä.) kann immer nur als Übergang von einer in eine zweite Zone genutzt werden, sodass in jeder Netzwerkkomponente nur Daten der beiden direkt angeschlossenen Zonen weitergeleitet werden. Eine Vermischung von Datenströmen im Falle eines Fehlers oder eines
gezielten Angriffs wird somit verhindert.
b. Auf einem Server-System können nur Systeme einer Zone gehostet werden. Verteilte Anwendungen müssen daher auf Server-Systemen in verschiedenen Zonen
betrieben werden.
Seite 67
c. Ein Server-System, dessen E-Government-Anwendungen Kommunikationsbeziehungen in mehrere Zonen benötigen, muss über eine entsprechende Anzahl physikalisch und logisch getrennter Netzwerkverbindungen (z. B. mehrere Netzwerkkarten) verfügen. Ein Übergang von einer Zone in die andere wird somit auf
diesem System ausgeschlossen.
Informations- und Dienstezone
Die Informations- und Dienstezone umfasst den Bereich des Netzes, der zwischen
dem Internet und den übrigen Zonen des Netzes steht. In dieser Zone befinden sich
Server, auf die ein Zugriff aus externen Netzen erforderlich ist oder die ihrerseits
Dienste aus externen Netzen nutzen. Sollen Systeme mit unterschiedlichen Sicherheitseinstufungen betrieben werden, empfiehlt sich die Einrichtung weiterer Informationszonen.
Die Kommunikationsbeziehungen zwischen Systemen in der Informations- und
Dienstezone und Systemen in der Logik- und Verarbeitungszone sollten durch den
Aufbau verschlüsselter Kommunikationskanäle geschützt werden.
Logik- und Verarbeitungszone
In dieser Zone werden Systeme untergebracht, die Daten aus der Datenzone verarbeiten und diese den Anwendern über Systeme in der Informations- und Dienstezone
zur Verfügung stellen. Eine direkte Kommunikation zwischen externen Netzen, wie
dem Internet, und der Logik- und Verarbeitungszone ist nicht erlaubt.
Datenzone
In der Datenzone stehen alle Systeme, auf denen Daten gespeichert und für längere
Zeiträume vorgehalten werden. Zugriffe auf diese Zone sind nur aus der Verarbeitungszone und der Management-Zone erlaubt. Ein direkter Zugriff aus externen Netzen ist unter keinen Umständen erlaubt. Ebenso dürfen aus dieser Zone heraus keine
aktiven Zugriffe auf weitere Zonen erfolgen, eine Ausnahme stellt die ManagementZone dar.
Management-Zone
In der Management-Zone werden alle Systeme untergebracht, die zu administrativen
Zwecken oder der Überwachung von Systemen in den anderen Zonen benötigt werden. Weiterhin können zentrale Dienste zur Benutzerverwaltung oder Authentifizierung in dieser Zone untergebracht werden. Ein Zugriff aus der Management-Zone in
andere Zonen und umgekehrt ist daher erlaubt.
Ein Zugriff aus externen Netzen auf die Management-Zone ist unter keinen Umständen zulässig.
Seite 68
Datensicherung
Die Datensicherung sollte in jeder Zone durch eigenständige Sicherungskomponenten erfolgen. Die Sicherung der Daten der Informationszone sollte dabei wiederum
über geschützte Kommunikationskanäle erfolgen.
7.1.3 Netzwerkzugang und Zugangskontrolle
Zugangskontrollsysteme steuern die Trennung der einzelnen Zonen innerhalb des
Rechenzentrums ebenso wie den Zugang von und zu externen Netzwerken. Dabei
können verschiedene Technologien zum Einsatz kommen.
Der Übergang zwischen der Informations- und Dienstezone und externen Netzen ist
der sicherheitskritischste Punkt und wird daher durch eine Kombination mehrerer
Sicherheitsmechanismen geschützt. Zum einen erfolgt an dieser Stelle eine Trennung
auf Netzwerkprotokollebene in verschiedene Netzwerksegmente und -adressbereiche. Interne Netzwerkadressen werden in TCP/IP-basierten Netzwerken auf Basis
des Network Address Translation (NAT) Protokolls maskiert und somit in externen
Netzwerken nicht publiziert.
Weiterhin wird durch Filtermechanismen sichergestellt, dass der Zugriff aus externen
Netzen nur auf bestimmte Dienste in der Informations- und Dienstezone erlaubt ist.
Die Filterregeln werden üblicherweise auf Firewalls oder Firewall-Routern implementiert, die auf Basis von Paketfiltern die Informationen in den Headern der eingehenden
Datenpakete untersuchen und nicht erlaubte Zugriffe abweisen.
Darüber hinaus können Application Gateways eingesetzt werden, die die Kommunikation vollständig entkoppeln, indem sie Datenströme auf Anwendungsebene validieren und gegebenenfalls eine protokollkonforme Neugenerierung von Requests realisieren.
Die Kommunikationsbeziehungen zwischen den internen Zonen werden ebenfalls
durch Zugriffskontrollsysteme geregelt. Für die Implementierung der Zugriffskontrolle
zu den sensiblen Bereichen der Logik- und Verarbeitungszone sowie der Datenzone
sollten aufgrund der umfassenderen Filtermöglichkeiten Firewalls zum Einsatz kommen, die auf Basis von dynamischen Paketfiltern (Stateful Inspection) arbeiten und in
der Lage sind, nicht nur einzelne Pakete, sondern Kommunikationsströme über mehrere Pakete hinweg zu überwachen. Dynamische Paketfilter bieten die Möglichkeit,
Netzwerkverbindungen nicht nur nach fest eingetragenen Regeln, sondern darüber
hinaus auch auf Basis von vorangegangenen Kommunikationsbeziehungen validieren zu können.
Der Einsatz von VLAN-Technologie bietet sich aufgrund seiner einfachen und flexiblen Administration für die Zugangskontrolle zu den Systemen in der ManagementZone an. Dazu werden alle Systeme, die Zugriff auf einen Dienst in der ManagementZone benötigen, in einem virtuellen Netzsegment (VLAN) zusammengefasst. Um eine
ungewollte Kopplung der einzelnen Zonen über die VLANs der Management-Zone zu
verhindern, werden alle Systeme mit einem zweiten Netzwerk-Interface ausgestattet,
Seite 69
das ausschließlich für administrative Zugänge genutzt werden darf und mit einem
Paketfilter ausgerüstet ist.
Von einem Einsatz der VLAN-Technologie zur Verbindung anderer Zonen als der
Management-Zone ist aus Sicherheitsgründen abzuraten.
7.2
Netzwerk, Benutzer und externe Dienste
Die Netzwerkebene ist das Verbindungsglied zwischen den Systemen in der Rechenzentrumsinfrastruktur und externen Diensten sowie den Benutzern von E-Government-Anwendungen. In dieser Ebene werden sowohl das Internet, TESTA (TransEuropean Services for Telematics between Administrations), der Informationsverbund
der Bundesverwaltung (IVBV), der Informationsverbund Berlin-Bonn (IVBB) als auch
weitere VPN-basierte Netze oder Extranets zusammengefasst. Auch hauseigene
Intranets fallen in den Bereich der Netzwerkebene. In den letzten Jahren haben sich
deutliche Konsolidierungstendenzen im Bereich der Netzwerktechnologien gezeigt.
Dennoch sind nach wie vor eine Vielzahl verschiedener Technologien im Einsatz.
Durch eine Abstraktion auf höheren Protokoll- oder Anwendungsebenen kann jedoch
eine Interoperabilität der Systeme erreicht werden, sodass in SAGA auf konkrete
Technologieempfehlungen für den Bereich der Netzwerkebene verzichtet wird.
Aus Sicht des Engineering Viewpoints auf eine E-Government-Anwendung spielt
jedoch die sichere und performante Anbindung an Internet, TESTA, IVBV, IVBB oder
Extranets eine wichtige Rolle, um einen zuverlässigen Zugang zu Anwendern und
externen Diensten zu gewährleisten. Bei der Konzeption von E-Government-Anwendungen müssen daher auf Basis einer Abschätzung des zu erwartenden Netzwerkverkehrs die erforderlichen Bandbreiten bereitgestellt und die im Abschnitt 7.1.3
beschriebenen Zugangskontrollen implementiert werden.
Die Initiative BundOnline 2005 stellt verschiedene externe Dienste in Form von Basisund Infrastrukturkomponenten sowohl im Internet als auch über den IVBV bereit.
Zusätzliche Informationen über die Infrastrukturkomponente IVBV befinden sich im
Anhang A „Basisbausteine der BundOnline-Initiative“, Abschnitt A.6 auf Seite 142.
Weitere Dienste, wie zum Beispiel die Basiskomponente ePayment, können über
Web-Service-Schnittstellen im Internet aufgerufen werden. Dazu werden von der
Basiskomponente zum einen die erforderlichen server-seitigen Web-Service-Schnittstellen und zum anderen eine Referenzimplementierung zum Aufruf der Web Services durch die jeweilige E-Government-Anwendung zur Verfügung gestellt. In ähnlicher Form erfolgt auch die Kommunikation mit externen Fachanwendungen von
anderen Behörden oder Unternehmen, die ebenfalls über Middleware-Kommunikationsschnittstellen angebunden werden können.
Dezentrale Basisbausteine hingegen, wie die Basiskomponenten Datensicherheit und
Formularserver, werden innerhalb der Rechenzentrumsinfrastruktur der einzelnen
Behörden implementiert. In diesem Fall sollten wiederum die bereits im Abschnitt 7.1
beschriebenen Regeln beachtet werden.
Seite 70
8 Technology Viewpoint (Teil I): Standards für die IT-Architektur
In diesem Kapitel werden den einzelnen Elementen des in Kapitel 3 vorgestellten
Architekturmodells technische Standards zugeordnet und kurz beschrieben. Wenn für
Standards keine Versionsnummern angegeben sind, ist die aus Marktsicht stabilste
Version zu verwenden, welche nicht immer die neueste Version sein muss.
8.1
Prozessmodellierung
Obligatorisch: Rollenmodelle und Flussdiagramme
Rollenmodelle und Flussdiagramme können zur Definition einfacher Prozesse eingesetzt werden. Dabei ist es wichtig, alle mit einem Prozess befassten Rollen und
Systeme zu identifizieren und die Prozessschritte in Form von Flussdiagrammen zu
beschreiben. Flussdiagramme sollen sich im weiteren Sinne nach DIN 66001 „Informationsverarbeitung; Sinnbilder und ihre Anwendung“ richten.
Empfohlen: Unified Modeling Language (UML) v2.0
Zur Vorbereitung und Dokumentation von Großprojekten soll die Unified Modeling
Language (UML)57 für objektorientierte Modellierung angewendet werden. Insbesondere Use Cases haben sich im Einsatz bewährt und erlauben, transparente Spezifikationen zu erstellen und abzustimmen. Die Anwendung von UML ist jedoch aufwändig
und setzt entsprechende Kenntnisse sowie gegebenenfalls den Einsatz spezieller
Werkzeuge voraus. Andererseits können aus entsprechenden Spezifikationen direkt
XML-Datenstrukturen oder Java-Programmteile generiert werden.
8.2
Datenmodellierung
8.2.1 Modellierungswerkzeuge
Obligatorisch: Entity Relationship Diagramme
Funktionale Datenmodelle für eine fachliche Grobkonzeption bedürfen der Darstellung mit Entity Relationship Diagrammen.
Obligatorisch: XML Schema Definition (XSD) v1.0
Die Datenspezifikation soll als XML-Schema erfolgen (siehe folgender Abschnitt
Abschnitt 8.2.2).
57. siehe http://www.uml.org/
Seite 71
Empfohlen: Regular Language Description for XML New Generation (Relax NG)
Die Datenspezifikation kann mit Relax NG erfolgen, die Relax NG-Schemata müssen
aber in XML Schemata transformiert werden (siehe folgender Abschnitt 8.2.2).
Empfohlen: Unified Modeling Language (UML) v2.0
Analog zu Abschnitt 8.1.
8.2.2 Datenbeschreibung
Obligatorisch: Extensible Markup Language (XML) v1.0
XML (Extensible Markup Language)58 soll als der universelle und primäre Standard
für den Datenaustausch aller verwaltungstechnisch relevanten Informationssysteme
dienen.
Neu zu beschaffende Systeme sollen in der Lage sein, über XML Daten auszutauschen. Existierende Systeme müssen nicht zwingend XML-fähig sein.
Wo nötig, kann auch Middleware eingesetzt werden, die eingehende XML-Informationen interpretiert und in die benötigten Datenformate der Alt- beziehungsweise Fremdsysteme transformiert beziehungsweise konvertiert. Dieser Prozess kann in beide
Richtungen erfolgen; über Workflow- und Transaktionsmechanismen kann die Durchbeziehungsweise Ausführung eines Geschäftsprozesses überwacht werden.
Zur strukturierten Beschreibung von Daten sollen XML-Schemata gemäß den Definitionen des World Wide Web Consortium (W3C)59 mit der XML Schema Definition
(XSD) erstellt werden.
Der ISO-Standard (ISO/IEC 19757-2:2003) Relax NG60 kann, ebenso wie XML
Schema Definition (XSD), zur strukturierten Beschreibung von Daten genutzt werden.
Relax NG ist weniger verbreitet als XSD und hat eine geringere Werkzeugunterstützung. Es ist jedoch einfacher, leichter lesbar und dennoch ausdrucksstärker.
Zwar ist für die strukturierte Beschreibung von Daten XSD obligatorisch, die Nutzung
von Relax NG ist dennoch möglich, da Relax-NG-Schemata mit (Open Source) Werkzeugen in XML Schemata transformiert werden können61.
58. siehe http://www.w3.org/XML
59. siehe http://www.w3.org/XML/Schema
60. siehe http://www.relaxng.org/ und http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=37605&ICS1=35&ICS2=240&ICS3=30
61. siehe http://www.thaiopensource.com/relaxng/trang.html
Seite 72
8.2.3 Datentransformation
Empfohlen: Extensible Stylesheet Language Transformation (XSLT) v1.0
Wenn Anwendungen unterschiedliche XML-Schemata verwenden, kann bei einem
Datenaustausch die Konvertierung von einem Format in ein anderes notwendig werden. Diese Formatkonvertierung erfolgt über die vom W3C definierte Sprache XSLT62
als Teil von XSL (Extensible Stylesheet Language).
8.2.4 Zeichensätze
Beim Austausch von Daten gelten für die zu verwendenden Zeichensätze die Standards, die im Abschnitt 8.5 „Präsentation“63 definiert werden. Dabei können individuelle Teile von XML-Schemata weiter im Zeichensatz eingeschränkt werden.
8.3
Applikationsarchitektur
In diesem Abschnitt werden Programmiersprachen und Technologien zur Realisierung der Applikationsarchitektur festgelegt. Im ersten Teil werden die Standards für
die Middleware-Schicht des E-Government-Architekturmodells definiert, wobei vor
allem auf den Aspekt der Applikationsintegration eingegangen wird. Im Anschluss
erfolgt eine Erweiterung der Standards für Applikationen ohne Middleware, d. h. dass
die Middleware-Standards auch für einfachere Applikationen eingesetzt werden können.
Die Vorgaben und Empfehlungen folgen aus den Gestaltungsprinzipen, die im Umsetzungsplan der Initiative BundOnline 2005 festgelegt wurden, namentlich Betriebssystemneutralität, Interoperabilität und Portabilität.
Middleware-Dienste, wie z. B. Replikation, verteiltes Transaktionsmanagement, Personalisierung, Internationalisierung, Messaging etc., werden in der aktuellen Version
in Ansätzen referenziert.
In begründeten Fällen, z. B. bei erheblichen Wirtschaftlichkeitsvorteilen, kann von den
zu bevorzugenden (obligatorischen, empfohlenen) Technologien abgewichen werden.
8.3.1 Applikationsarchitektur mit Middleware
Obligatorisch: Java 2 Platform, Enterprise Edition (J2EE) v1.4
Zur Entwicklung und Integration folgender Anwendungen (Verbundanwendungen) auf
dem Middle-Tier, nämlich
a. Basiskomponenten,
62. siehe http://www.w3.org/TR/xslt
63. siehe Abschnitt 8.5.1.4 „Zeichensätze“ auf Seite 80
Seite 73
b. Anwendungen, die Basiskomponenten oder dazu bereitgestellte Bibliotheken
unmittelbar einbinden, und
c. Anwendungen, die als Ganzes oder in Teilen (Komponenten) für eine Wiederverwendung (Portierung) vorgesehen sind,
wird die Anwendung von Java 2 Platform, Enterprise Edition (J2EE)64 Technologien
vorausgesetzt. J2EE ist eine Spezifikation, die eine Reihe von Programmierschnittstellen und einen Entwicklungsprozess definiert. In der Gesamtheit bildet J2EE eine
Architektur, die wesentliche Aspekte von geschäftskritischen Anwendungen berücksichtigt und unterstützt. J2EE stellt wichtige Funktionsbausteine bereits zur Verfügung, die bei der Entwicklung von Anwendungen genutzt werden können. Dazu gehören seit der Version 1.4 als so genannte Core-Bibliotheken auch StandardProgrammierschnittstellen (APIs) und Technologien, die in SAGA 1.1 noch einzeln
klassifiziert wurden: Java Authentication and Authorization Service (JAAS), Java API
for XML Parsing (JAXP) und Java Naming and Directory Interface (JNDI). Sämtliche
Core-Bibliotheken sind alternativen Technologien vorzuziehen.
Als so genannte optionale Bibliotheken bietet J2EE gegenüber J2SE unter anderem
folgende APIs und Technologien: Java Message Service (JMS) 1.1, J2EE Connector
Architecture 1.5, Java Transaction API (JTA) 1.0, JavaMail API 1.3, Java API for XML
Registries (JAXR) 1.0, Java Management Extensions (JMX) 1.2, Enterprise JavaBeans (EJB) 2.1, Web Services 1.1, Java Server Pages (JSP) 2.0 und Servlet API
2.4. Im Folgenden wird der Einsatz der Kommunikationstechnologien JMS und J2EE
Connector Architecture als obligatorisch klassifiziert. Die Java-Middleware-Technologien EJB und Servlet-API bilden die Basis für Application-Server-Anwendungen.
Durch den Java Community Process65 werden in naher Zukunft immer mehr anwendungsnahe Module die Funktionsvielfalt von J2EE bereichern. Die Definition neuer
Module geschieht über so genannte Java Specification Requests (JSR).
Obligatorisch: Java 2 Platform, Standard Edition (J2SE) v1.4
Soweit für eine Anwendung der Leistungsumfang von J2EE anfänglich oder dauerhaft
nicht im vollen Umfang benötigt wird, sollen alternativ die Technologien von J2EE einzeln eingesetzt werden. Als Grundlage dient dabei die Java 2 Platform, Standard Edition (J2SE)66. Die einzelnen Technologien sollten entsprechend der J2EE Spezifikation 1.4 verwendet werden, um einen kompatiblen Migrationspfad zu J2EE zu bilden.
Obligatorisch: Java Database Connectivity (JDBC) v3.0
Für Zugriffe auf Datenbanken soll JDBC67 genutzt werden.
64.
65.
66.
67.
siehe http://java.sun.com/j2ee/
siehe http://www.jcp.org/
siehe http://java.sun.com/j2se/
siehe http://java.sun.com/products/jdbc/
Seite 74
Obligatorisch: Java Message Service (JMS) v1.1, J2EE Connector Architecture
v1.5
Für die Integration von externen Systemen sollte entweder der Java Message Service
(JMS)68 oder die J2EE Connector Architecture genutzt werden.
Obligatorisch: Java Network Launching Protocol (JNLP) v1.5
Die Auslieferung von Java-Anwendungen über das Internet soll über das Java Network Launching Protocol (JNLP)69 erfolgen. Dafür kann die Referenzimplementierung
„Java Web Start“70 genutzt werden.
Der Einsatz von JNLP ermöglicht die einfache, plattformunabhängige Verteilung von
Java-Applikationen und vermeidet Versionskonflikte der Java-Laufzeitumgebungen
(Java Runtime Environment – JRE).
Unter Beobachtung: Microsoft Windows .NET Framework
Das .NET Framework ist eine Middleware-Technologie, die von Microsoft entwickelt
wurde. Die Systemarchitektur von .NET umfasst eine Laufzeitumgebung für unterschiedliche Programmiersprachen und eine Entwicklungsumgebung. Sie unterstützt
wesentliche Web-Standards (darunter SOAP, WSDL, UDDI, XML).
Kernkomponenten der .NET Middleware sind durch internationale Gremien standardisiert worden. Zurzeit werden Projekte durchgeführt, die die Implementierung von
Kernkomponenten der .NET Middleware auf Nicht-Windows-Betriebsystemen zum
Ziel haben.
Derzeit erfüllt die .NET-Architektur die Anforderungen an die Portabilität noch nicht
betriebssystemunabhängig. Es wird erwartet, dass Microsoft die .NET-Technologie zu
einem offenen Standard weiterentwickelt und dabei auch die Konformität zu den in
SAGA vorgesehenen Standards gewährleistet.
8.3.2 Applikationsarchitektur ohne Middleware
Für einfache E-Government-Anwendungen ohne Middleware steht ergänzend zu den
Standards des vorigen Abschnitts die folgende Technologie zur Auswahl.
Empfohlen: PHP: Hypertext Preprocessor (PHP) v5.x
Für Anwendungen ohne Integrationsbedarf, also nicht verteilte Stand-Alone-Anwendungen, die nicht mit einer der Basiskomponenten, mit Legacy-Systemen oder anderen E-Government-Fachanwendungen kommunizieren, ist der Einsatz von PHP71
68.
69.
70.
71.
siehe http://java.sun.com/products/jms/
siehe http://java.sun.com/products/javawebstart/download-spec.html
siehe http://java.sun.com/products/javawebstart/
siehe http://www.php.net/
Seite 75
(rekursives Akronym für „PHP: Hypertext Preprocessor“) möglich. PHP wird als OpenSource-Projekt von der PHP Group entwickelt und ist eine in HTML eingebettete
Skriptsprache für die Entwicklung von Web-Applikationen.
In der Version 5 erfolgt eine umfassende Unterstützung von Konzepten objekt-orientierter Programmierung. Verfahren zur Datenkapselung, der Referenzierung von
Variablen und Exception Handling (Ausnahmebehandlung) stellen wichtige Fortschritte im Rahmen der Weiterentwicklung dar.
8.4
Client
Der Client ist eine Software auf einem Endgerät, die einen vom Middle-Tier angebotenen Dienst in Anspruch nimmt. Der Client-Tier umfasst somit die klassische Benutzerseite mit allen Möglichkeiten der modernen Technologie, um mit der öffentlichen Verwaltung zu interagieren, wobei der Informationszugriff über unterschiedliche Medien
erfolgen kann. In Deutschland haben bislang vor allem die folgenden Medien Verbreitung gefunden, sodass bei einem Informationsangebot für diese Endgeräte optimale
Voraussetzungen für die breite Nutzung von E-Government-Anwendungen bestehen:
a. Computer (PC, Laptop)
b. Mobiltelefon / Personal Digital Assistant (PDA)
c. externe Systeme (z. B. ERP-Systeme von Industrieunternehmen)
Standardisierungsbemühungen für Spielkonsolen und insbesondere für digitales,
interaktives Fernsehen sind noch nicht zu einheitlichen Empfehlungen gekommen.
Größte Verbreitungschancen werden dem so genannten „Thin Client“ eingeräumt, der
nur geringe Anforderung an Hard- und Software-Ausstattung des Endgerätes stellt
und voraussetzt, dass möglichst viel Funktionalität server-seitig zur Verfügung gestellt
wird.
8.4.1 Web-/ Computerbasierter Informationszugriff
Auf Computern stehen prinzipiell zwei unterschiedliche Clients zur Verfügung, um auf
Informationen zuzugreifen oder Informationen zu erhalten: Web-Browser und spezifische Client-Anwendungen (z. B. Java-Clients – auch Applets). Letztere ermöglichen
u. a. einen direkten Zugriff auf internetbasierte Dienste, E-Mail-Clients und – je nach
Erlaubnis – auf das Betriebssystem. Bei der Verwendung aktiver Inhalte dürfen nur
die in SAGA zugelassenen Client-Technologien zum Einsatz kommen. Der Einsatz
von Active-X-Controls ist grundsätzlich nicht zugelassen. Bei Verwendung aktiver
Inhalte soll – soweit möglich – ein Parallelangebot ohne aktive Inhalte vorgehalten
werden (siehe auch Abschnitt 1.3.1).
8.4.1.1 Web-Browser
Um bei der Realisierung von E-Government-Anwendungen eine breite Nutzung zu
ermöglichen, sollen als Frontend Web-Browser verwendet werden, die die Formate
Seite 76
der Präsentationsebene (siehe Abschnitt 8.5) verarbeiten und darstellen können.
Hierbei sind folgende browser-basierte Client-Technologien zugelassen:
a. Die Nutzung von Cookies ist zugelassen, soweit
i. diese nicht persistent sind und
ii. Web-Seiten einer Domain keine Inhalte anderer Domains inkludieren, welche
Cookies setzen.
Hierbei sind die Empfehlungen zum HTTP-Protokoll gemäß Abschnitt 8.6.3 zu
berücksichtigen.
b. Die Nutzung von Javascript ist zugelassen. Jedoch muss sichergestellt sein, dass
die Web-Seiten auch dann verwendbar sind, wenn Javascript deaktiviert wurde.
Diese Forderung deckt sich mit der als obligatorisch klassifizierten BITV72. Damit
wird erreicht, dass Anwender nicht gezwungen werden, wegen E-GovernmentAnwendungen ihre Sicherheitseinstellungen zu lockern. Bei der Nutzung von
Javascript ist der Abschnitt 8.5.1.5 zu berücksichtigen.
c. Die Nutzung von Java-Applets ist zugelassen, wenn diese vom Server signiert
sind und damit als authentisch und integer beim Client erkannt werden können.
Die Hersteller von Java-Applets müssen ihr Produkt vorzugsweise durch ein vom
Hersteller unabhängiges Software-Unternehmen qualitätssichern lassen oder die
Qualität zumindest in Form einer Selbsterklärung zusichern. Nähere Informationen
zu diesem Thema sind im Web unter der Adresse http://www.kbst.bund.de/sagaapplets zu finden.
d. Es wird eine Positivliste von unterstützten Plug-Ins geführt und im Web unter der
Adresse http://www.kbst.bund.de/saga-plugins veröffentlicht.
e. Für gängige Browser-Typen werden Beispielkonfigurationen erstellt und vom BSI
über das Internet allgemein zur Verfügung gestellt.
f. Beim Versand von Formulardaten ist die Vertraulichkeit der Informationen durch
Verwendung von SSL-verschlüsselten Kanälen unter Nutzung zugehöriger Server-Zertifikate sicherzustellen.
g. Auch bei der Nutzung der zugelassenen Client-Technologien ist die Rechtsverordnung zur Barrierefreiheit unverändert zu berücksichtigen.
8.4.1.2 Client-Anwendungen mit direktem Zugriff auf internetbasierte Dienste
Der Standard-Client für Anwendungen mit direktem Zugriff auf Web-Server ist der
Web-Browser. Wenn die Funktionalität eines Web-Browsers begründeterweise als
unzureichend anzusehen ist, wie zum Beispiel im Fall komplexer Geschäftsvorfälle
mit direktem Dateisystemzugriff oder Nutzung von Legacy-Software, dann können
Client-Anwendungen verwendet werden. Diese Anwendungen werden auf dem Client
installiert und müssen bei Weiterentwicklungen mit den notwendigen Updates versorgt werden. Sie können entweder über CD-ROM oder über eine Download-Möglich72. siehe BITV, Abschnitt 6.3 „Es muss sichergestellt sein, dass mittels Markup-Sprachen geschaffene
Dokumente verwendbar sind, wenn Scripts, Applets oder andere programmierte Objekte deaktiviert
sind.“ (http://www.bmi.bund.de/Internet/Content/Themen/Informationsgesellschaft/Einzelseiten/
Verordnung__zur__Schaffung__barrierefreier__Id__90156__de.html)
Seite 77
keit auf einer Web-Seite als signierte Anwendungen zur Verfügung gestellt werden.
Dabei wird die Verwendung von Java-Anwendungen empfohlen (Vorteil der Plattformunabhängigkeit).
Client-Anwendungen müssen den folgenden Anforderungen genügen:
a. Alle personenbezogenen und sicherheitskritischen Daten sind auf dem lokalen
Datenträger verschlüsselt abgelegt.
b. Eine sichere Datenübertragung zum Server, zum Beispiel gemäß den Spezifikationen von OSCI-Transport, wird unterstützt. Für die sonstige Client-Server-Kommunikation sind ausschließlich die im Abschnitt 8.6.1.2 definierten Protokolle
zugelassen.
c. Die in SAGA dokumentierten Austauschformate für einen Austausch der Nutzerdaten mit anderen Anwendungen sollen unterstützt werden.
d. Es erfolgt eine Qualitätssicherung der Anwendung durch ein vom Hersteller unabhängiges Software-Unternehmen.
e. Die Anwendung wird mit einem Software-Zertifikat ausgeliefert, welches im Rahmen der Installation verifiziert wird.
f. Neben dem Download der Anwendung über das Internet wird auch die Distribution
per CD-ROM angeboten.
g. Die Rechtsverordnung zur Barrierefreiheit ist zu berücksichtigen.
8.4.1.3 E-Mail-Client
Zum Empfangen, Senden und Bearbeiten von E-Mails sind E-Mail-Clients einzusetzen, die mindestens die technische Unterstützung der folgenden beiden E-Mail-Standards gewährleisten:
a. SMTP: zum Empfang und zum Versenden von E-Mails
b. MIME: als E-Mail-Formatbeschreibung
An dieser Stelle sei darauf hingewiesen, dass die Kommunikation dieser Clients nur
im Hinblick auf die Kommunikation mit der Verwaltung standardisiert beziehungsweise auf obiges beschränkt ist. Bei der Verwendung externer, nicht mit dem Bund
gekoppelter Mail-Server unterliegt der Client hinsichtlich der verwendeten Standards
und Protokolle keiner Beschränkung.
In Ausnahmefällen kann es vorkommen, dass elektronische Postfächer angeboten
werden müssen. Es sind die Standards aus dem Abschnitt 8.6.3 zu verwenden.
8.4.2 Informationszugriff via Mobiltelefon / PDA
Um über Mobiltelefone oder PDAs das Angebot der Präsentationsebene nutzen zu
können, sind derzeit Protokolle notwendig, die server-seitig bedient werden (siehe
Abschnitt 8.5.2).
Seite 78
8.4.3 Informationszugriff über externe Systeme
Die Kommunikation und Interaktion zwischen externen und internen Systemen soll
über eine Teilmenge der Standards abgewickelt werden, die für die Kommunikation
und Interaktion zwischen internen Systemen definiert werden. So ist bei der Serverzu-Server-Kommunikation XML über SOAP gleichberechtigt zu RMI zu betrachten73.
8.5
Präsentation
Das Element Präsentation stellt dem Client-Tier Informationen zur Verfügung. Je
nach Anwendungsfall müssen unterschiedliche Formate bereitgestellt werden, die in
den folgenden Abschnitten aufgelistet werden. Dabei wird die Verwendung offener
Austauschformate, die über hinreichend viele Funktionen verfügen und auf unterschiedlichen Plattformen verfügbar sind, grundsätzlich gefordert.
Es ist zulässig, die Informationen zusätzlich – oder nach Vereinbarung zwischen allen
Beteiligten auch alternativ – zu den obligatorischen und empfohlenen Formaten in
Formaten anzubieten, die von SAGA nicht berücksichtigt wurden.
8.5.1 Informationsverarbeitung – Computer / Web
8.5.1.1 Behindertengerechte Darstellung
Obligatorisch: Barrierefreie Informationstechnik Verordnung (BITV)
Um das Informationsmedium Internet auch behinderten Menschen zugänglich zu
machen, wird die Vermeidung von Barrieren für Menschen mit Behinderungen gefordert. Um eine solche barrierefreie Darstellung sicherzustellen, sollen die Anforderungen der „Verordnung zur Schaffung barrierefreier Informationstechnik nach dem
Behindertengleichstellungsgesetz (Barrierefreie Informationstechnik Verordnung –
BITV)“74 zugrunde gelegt werden. Diese Rechtsverordnung setzt §11 des Behindertengleichstellungsgesetzes um und berücksichtigt dabei insbesondere die Web Content Accessibility Guidelines75 des W3C in der Version 1.0. Zum Thema Barrierefreiheit siehe auch Abschnitt 4.1.5.3 auf Seite 42.
8.5.1.2 Austauschformate für Hypertext
Obligatorisch: Hypertext Markup Language (HTML) v4.01
HTML ist die etablierte Sprache, um Hypertexte im World Wide Web zu publizieren.
Neben den Text-, Multimedia- und Hyperlink-Funktionen früherer HTML-Versionen
73. siehe dazu die Abschnitte 8.2 „Datenmodellierung”, 8.3 „Applikationsarchitektur“, 8.6 „Kommunikation“ und 8.7 „Anbindung an das Backend“
74. siehe http://www.bmi.bund.de/Internet/Content/Themen/Informationsgesellschaft/Einzelseiten/
Verordnung__zur__Schaffung__barrierefreier__Id__90156__de.html
75. siehe http://www.w3.org/TR/WCAG10
Seite 79
unterstützt HTML v4.0176 mehr Multimedia-Optionen, Skript-Sprachen und bessere
Formulare und Druckfunktionen. Für die technische Umsetzung des barrierefreien
Zugangs durch Web Content Accessibility Guidelines Version 1.0 ist der Einsatz von
HTML v4.01 erforderlich. Es wurde eine bessere Trennung zwischen Dokumentstruktur und Präsentation eingeführt. Dazu wird die Nutzung von Stylesheets anstelle von
HTML-Präsentationselementen und -attributen forciert. HTML 4 macht auch große
Schritte im Hinblick auf die Internationalisierung von Dokumenten, mit dem Ziel, das
World Wide Web wirklich weltweit zu machen.
Unter Beobachtung: Extensible Hypertext Markup Language (XHTML) v1.0
XHTML v1.077 formuliert HTML v4.01 als XML-Anwendung. Mit der weiteren Entwicklung und Verbreitung neuerer Browser-Generationen soll XHTML v1.0 zum Einsatz
kommen.
8.5.1.3 Style Sheets
Um angebotene Informationen für unterschiedliche Browser-Typen einheitlich darzustellen, können Style Sheets Verwendung finden. Style Sheets sind Formatvorlagen
für beliebige Daten, in denen beschrieben wird, wie Auszeichnungen in SGML-konformen Sprachen darzustellen sind. Je nach Anwendungszweck können einer oder
beide der folgenden durch das W3C etablierten Typen von Style Sheets verwendet
werden:
Empfohlen: Cascading Style Sheets Language Level 2 (CSS2)
Zur Gestaltung von HTML-Seiten soll die Cascading Style Sheets Language Level 2
(CSS2)78 verwendet werden.
Empfohlen: Extensible Stylesheet Language (XSL) v1.0
Zur Transformation und Darstellung von XML-Dokumenten in HTML Dateien soll die
Extensible Stylesheet Language (XSL)79 in der Version 1.0 eingesetzt werden.
8.5.1.4 Zeichensätze
Obligatorisch: ISO 10646-1:2000 / Unicode v3.0 UTF-8
Um ausreichend Zeichen für die verschiedenen, weltweit existierenden Buchstaben,
Ziffern und Symbole zur Verfügung zu haben, soll als Zeichensatz für Dokumente im
HTML-Format ISO 10646-1:2000 / Unicode v3.0 in der UTF-8 Kodierung verwendet
werden80.
76.
77.
78.
79.
siehe http://www.w3.org/TR/html401/
siehe http://www.w3.org/TR/xhtml1/
siehe http://www.w3.org/TR/REC-CSS2/
siehe http://www.w3.org/TR/xsl/
Seite 80
Empfohlen: ISO 10646-1:2000 / Unicode v3.0 UTF-16
Soweit die Dokumente in griechischer Sprache oder in anderen nicht westeuropäischen Sprachen verfasst sind, soll die UTF-16-Kodierung81 verwendet werden.
Empfohlen: ISO 8859-1
Derzeit findet der Zeichensatz ISO 8859-1 noch immer Verbreitung und kann weiterhin verwendet werden. Er beinhaltet ASCII plus westeuropäische Sonderzeichen, wie
die deutschen Umlaute.
Empfohlen: ISO 8859-15
Die Kodierung gemäß ISO 8859-15 ist derzeit noch verbreitet und wird in diesem
Rahmen weiterhin zugelassen. Zusätzlich zum Zeichensatz ISO 8859-1 ist z. B. das
Euro-Zeichen „€“ enthalten.
8.5.1.5 Statische und dynamische, passive und aktive Inhalte
Statische Inhalte sind (HTML-)Dateien, die von einem Web-Server nicht zur Laufzeit
generiert, sondern in der Regel aus dem Dateisystem gelesen und ausgeliefert werden. Dynamische Inhalte sind HTML Dateien, die zur Laufzeit – z. B. mittels Abfragen aus Datenbanken – auf dem Server generiert und dann ausgeliefert werden.
Passive Inhalte sind HTML Dateien, die keinen Programm-Code und keine Computerprogramme enthalten oder zur Laufzeit nachladen. Aktive Inhalte sind Computerprogramme, die in Web-Seiten enthalten sind (z. B. Javascript) oder beim Betrachten
der Seite automatisiert nachgeladen werden (z. B. Java Applets, ActiveX Controls
oder auch Flash-Animationen) und auf dem Client (vom Browser oder Betriebssystem) ausgeführt werden. Bei der Verwendung von aktiven Inhalten sind die Restriktionen gemäß Abschnitt 8.4 zu berücksichtigen.
Obligatorisch: Hypertext Markup Language (HTML)
Für die Bereitstellung von Informationen sollen HTML-Seiten mit Hilfe der in
Abschnitt 8.5.1.2 definierten Austauschformate für Hypertext eingesetzt werden. Die
Unterstützung von aktiven Inhalten und von Plug-Ins darf nur in dem in Abschnitt 8.4
definierten Umfang vorausgesetzt werden.
Obligatorisch: ECMA-262 – ECMAScript Language Specification
Soweit gemäß Abschnitt 8.4.1.1 innerhalb von HTML-Seiten Javascript verwendet
wird, soll dieses der Spezifikation von ECMA-26282 genügen.
80. Diese Spezifikation ist unter http://www.unicode.org/ verfügbar.
81. Diese Spezifikation ist unter http://www.unicode.org/ verfügbar.
82. siehe http://www.ecma-international.org/
Seite 81
Empfohlen: Servlets und Java Server Pages (JSP) oder Extensible Stylesheet Language (XSL) v1.0
Für die server-basierte, dynamische Erzeugung von HTML-Seiten sollen Servlets und
JSP83 oder Servlets und XSL84 eingesetzt werden.
8.5.1.6 Web-Formulare
Unter Beobachtung: XForms v1.0
XForms ist eine Spezifikation85 für Web-Formulare. Die Intention der Spezifikation ist
es, in Zukunft die in HTML oder XHTML formulierten Formulare abzulösen. XForms
bietet einen größeren Funktionsumfang und führt bei client-seitiger Verarbeitung zu
einer Reduzierung der Anzahl der Server-Zugriffe.
Zwar sind Implementierungen und auch einige Plug-Ins verfügbar, standardmäßig
wird XForms jedoch von den Web-Browsern mit der weitesten Verbreitung bisher
noch nicht unterstützt.
8.5.1.7 Dateitypen und Typerkennung für Textdokumente
Je nach Verwendungszweck sind unterschiedliche Dateitypen für Textdokumente zu
verwenden:
Obligatorisch: Text (.txt)
Einfache, veränderbare Textdokumente werden im weit verbreiteten Format (.txt)
ausgetauscht, was eine generelle Lesbarkeit sicherstellen soll. Die anzuwendenden
Zeichensätze werden im Abschnitt 8.5.1.4 festgelegt.
Hypertext-Dokumente sollen im HTML-Format als (.html)-Dateien zum Einsatz kommen (siehe Abschnitt 8.5.1.2).
Obligatorisch: Portable Document Format (PDF) v1.4
Für nicht zur Änderung vorgesehene Textdokumente sowie zur Unterstützung von
Formularen und barrierefreien Textdokumenten soll das plattformunabhängige Portable Document Format von Adobe (.pdf) eingesetzt werden. Die PDF-Version 1.4 wird
von der Acrobat-Software86 ab Version 5 unterstützt. Beim Einsatz sind die Empfeh-
83.
84.
85.
86.
siehe http://java.sun.com/products/jsp/
siehe http://www.w3.org/TR/xsl/
siehe http://www.w3.org/MarkUp/Forms
siehe http://www.adobe.de/products/acrobat/readermain.html
Seite 82
lungen des Moduls „Sicherer Internet-Auftritt“ im E-Government-Handbuch in Bezug
auf aktive Inhalte zu berücksichtigen (siehe Abschnitt 8.5.1.5).
Obligatorisch: Multipurpose Internet Mail Extensions (MIME) v1.0
Zur standardisierten Angabe, welches Format eine Datei oder ein Teil davon hat, ist
das Format Multipurpose Internet Mail Extensions (MIME) zu verwenden. Es erlaubt
dem E-Mail-Client oder dem Web-Browser die eindeutige Identifikation des Dateityps,
siehe dazu RFC 2045 bis RFC 204987.
Empfohlen: Extensible Markup Language (XML) v1.0
Weiterhin kann auch XML88 zur Beschreibung von Dokumenten eingesetzt werden,
welches hierfür mehr gestalterische Möglichkeiten bietet als HTML89.
Unter Beobachtung: Portable Document Format (PDF) v1.5
Die PDF-Version 1.5 ist noch nicht so verbreitet wie 1.4. Zudem sind für einige UnixSysteme (IBM AIX, HP-UX) und ältere Windows- und MacOS-Versionen keine Versionen des Readers für PDF v1.5 verfügbar. Die PDF-Version 1.5 wird von der Acrobat-Software90 ab Version 6 unterstützt. Beim Einsatz sind die Empfehlungen des
Moduls „Sicherer Internet-Auftritt“ im E-Government-Handbuch in Bezug auf aktive
Inhalte zu berücksichtigen (siehe Abschnitt 8.5.1.5).
8.5.1.8 Dateitypen für Tabellenkalkulationen
Für Tabellenkalkulationen sind je nach Anforderung an die Veränderbarkeit des
Dokuments unterschiedliche Formate für den Datenaustausch einzusetzen:
Obligatorisch: Comma Separated Value (CSV)
Abgegrenzte (delimited), kommaseparierte Tabellen sind als (.csv)-Dateien zu speichern und auszutauschen.
Analog zu Abschnitt 8.5.1.7.
87. siehe http://www.ietf.org/rfc/
88. siehe http://www.w3.org/XML/
89. Als XML-Format kann beispielsweise OpenDocument eingesetzt werden, das von OASIS standardisiert wurde, siehe http://www.oasis-open.org/committees/office/.
90. siehe http://www.adobe.de/products/acrobat/readermain.html
Seite 83
Weiterhin kann auch XML91 zur Beschreibung von Tabellenkalkulationen eingesetzt
werden, welches hierfür flexiblere Möglichkeiten bietet als CSV92.
8.5.1.9 Dateitypen für Präsentationen
Präsentationen sollen je nach Anforderung an die Veränderbarkeit des Dokuments in
unterschiedlichen Formaten ausgetauscht werden:
Veränderbare Präsentationen sollen als Hypertext-Dokumente im HTML-Format als
(.html)-Dateien ausgetauscht werden (siehe Abschnitt 8.5.1.2 „Austauschformate für
Hypertext“).
Unter Beobachtung: Synchronized Multimedia Integration Language (SMIL) v2.0
SMIL ist eine auf XML basierende, standardisierte Sprache zum Schreiben von interaktiven Multimediapräsentationen93. „Ein typisches Beispiel für eine solche Anwendung ist ein multimediales Nachrichtencenter, welches Audios und Videos zu einer
Nachricht abspielt, während gleichzeitig Hintergrundinformationen auf HTML-Webseiten dargestellt werden.“94
Es gibt eine Reihe von SMIL-Playern, auch kostenlose. Von den marktüblichen Browsern unterstützt aber bisher nur der Internet Explorer eine Teilmenge von SMIL95.
92. Als XML-Format kann beispielsweise OpenDocument eingesetzt werden, das von OASIS standardisiert wurde, siehe http://www.oasis-open.org/committees/office/.
93. siehe http://www.w3.org/TR/2005/REC-SMIL2-20050107/
94. siehe Pauen, Peter: Zukunftsorientierte Ansätze – SMIL, http://www.informatik.fernuni-hagen.de/import/pi3/peter/smil.htm
95. siehe http://www.w3.org/AudioVideo/#SMIL
Seite 84
8.5.1.10 Austauschformate für Bilder
Obligatorisch: Graphics Interchange Format (GIF)
Aufgrund der weiten Verbreitung ist für den Austausch von Grafiken und Schaubildern
das Format Graphics Interchange Format (.gif) zu wählen, wobei (.gif) Bilddateien mit
einer Farbtiefe von 256 Farben (8 Bit pro Pixel) komprimiert werden.
Obligatorisch: Joint Photographic Experts Group (JPEG)
Für den Austausch von Bildern ist das Format Joint Photographic Experts Group
(.jpg) zu wählen, welches das Ändern des Komprimierungsgrades und die Angabe
der Dichte unterstützt, sodass ein Kompromiss zwischen Dateigröße, Qualität und
Verwendung erleichtert wird. Es werden 16,7 Millionen Farben (24 Bits Farbinformationen) unterstützt.
Empfohlen: Portable Network Graphics (PNG)
Wenn möglich, soll das Grafikformat Portable Network Graphics96 (.png) verwendet
werden. Das Format (.png) kann lizenzfrei angewendet werden, unterstützt 16 Millionen Farben, Transparenz, verlustfreie Kompression, inkrementelle Anzeige der Grafik
(erst Grobstruktur, bis Datei ganz übertragen ist) und das Erkennen beschädigter
Dateien.
(.png) wird anstelle von (.gif) obligatorisch, wenn sich neuere Browser der fünften
Generation vollständig etabliert haben.
Empfohlen: Tagged Image File Format (TIFF)
Für Grafikinformationen, die keinerlei Informationsverlust erlauben, soll das Tagged
Image File Format (.tif) verwendet werden. (.tif) ist ein Dateiformat für Rastergrafiken,
wobei verschiedene Formatierungen es Anwendungen erlauben, Teile der Grafik zu
verarbeiten oder zu ignorieren.
Empfohlen: Enhanced Compressed Wavelet (ECW)
Falls höchstmögliche Kompression benötigt wird, soll das Rastergrafikformat Enhanced Compressed Wavelet (.ecw) zum Einsatz kommen.
8.5.1.11 Geoinformationen
Die Bereitstellung und Verteilung von Geoinformationen über das Internet sowie die
kartografische Darstellung (WebGIS / WebMapping) von Geoinformationen im Internet verbreiten sich zunehmend, z. B. mit dem Aufbau von Geodateninfrastrukturen
(GDI).
96. siehe http://www.w3.org/TR/REC-png
Seite 85
Die Verteilung beziehungsweise der Austausch von Geoinformationen erfolgt im Vektorformat. Die Darstellung von geografischen Informationen in Form thematischer
Karten erfolgt über Rastergrafiken. Für die Standardisierung dieser Vorgänge ist das
Open Geospatial Consortium (OGC)97 verantwortlich. Das OGC ist ein Zusammenschluss von über 230 Institutionen, die im Bereich der raumbezogenen Informationsverarbeitung tätig sind. Es hat sich zum Ziel gesetzt, die Interoperabilität in der geografischen Informationsverarbeitung und die Integration von raumbezogener
Informationstechnologie in Standard-IT-Verfahren voranzutreiben. Die meisten führenden Hersteller von Geoinformationssystemen unterstützen mittlerweile OGC-Standards in ihren Produkten.
Obligatorisch: Geography Markup Language (GML) v3.0
GML (Geography Markup Language)98 ist eine Auszeichnungssprache zum Austausch und zum Speichern von geografischen Informationen im Vektorformat, welche
räumliche und nicht-räumliche Eigenschaften berücksichtigt. Die Spezifikation
erfolgte durch das Open Geospatial Consortium (OGC).
GML beinhaltet keine Aussagen über die Darstellung auf dem Bildschirm oder in einer
Karte. Die Geometrien werden durch Simple Features repräsentiert, welche ebenfalls
durch das OGC definiert wurden.
Empfohlen: Web Map Service (WMS) v1.3
Der Web Map Service (WMS99) ist ein auf SOAP / HTTP basierender, standardisierter Dienst, welcher Schnittstellen für Darstellung von geografischen Informationen in
Form thematischer Karten bereitstellt. Die Spezifikation erfolgte durch das Open
Geospatial Consortium (OGC).
Der WMS kann georeferenzierte, thematische Karten auf Basis von Rasterdaten
(GeoTiff u. a.) und Vektordaten (ESRI-Shapes, GML u. a.) aus verschiedenen Datenquellen erzeugen. Die generierten Karten (Format PNG oder JPEG) können mit
jedem gängigen Web-Browser visualisiert werden. Damit stellt der WMS eine einfache und für Datenanbieter leicht umzusetzende Möglichkeit für den interoperablen
Zugriff (lesend) auf verteilte und heterogene Geodatenbestände dar.
8.5.1.12 Austauschformate für Audio- und Video-Dateien
Obligatorisch: MPEG-1 Layer 3 (MP3)
Für den Austausch von Audio-Sequenzen soll das marktübliche Format (.mp3) verwendet werden, wobei (.mp3) für MPEG-1 Layer 3 (MPEG = Motion Picture Experts
Group) steht. (.mp3) ist ein Verfahren, um Audio-Daten bei höchster Qualität extrem
97. siehe http://www.opengeospatial.org/
98. siehe http://www.opengeospatial.org/specs/
99. siehe http://www.opengeospatial.org/specs/
Seite 86
zu komprimieren100. Mit einem entsprechenden Plug-In ist ein Browser in der Lage,
solche Dateien „abzuspielen“.
Obligatorisch: Quicktime (.qt, .mov)
Für den Austausch von Videosequenzen soll das marktübliche Quicktime-Format101
verwendet werden. Mit einem entsprechenden Plug-In ist ein Browser in der Lage,
solche Dateien „abzuspielen“.
Unter Beobachtung: Windows Media Video (.wmv)
Das Format Windows Media Video (WMV) ist dem Quicktime-Format qualitativ überlegen. Allerdings verfügt das WMV-Format noch nicht über dessen breite Verfügbarkeit von Playern für verschiedene Betriebssysteme. Nur bei homogenen Zielgruppen,
deren verwendete Betriebsysteme bekannt sind und durch Player für das verwendete
WMV-Format unterstützt werden, ist der ausschließliche Einsatz von WMV möglich.
Unter Beobachtung: RealMedia v10 (.rm, .ram)
RealMedia der Firma RealNetworks102 ist das Container-Format für das Audio-Format RealAudio und das Video-Format RealVideo. All diese Formate sind proprietär.
RealVideo ist dem Quicktime-Format qualitativ überlegen. Der kostenlose Player
steht für alle gängige Plattformen außer für Unix einschließlich für Mobile Devices zur
Verfügung. Nur bei homogenen Zielgruppen, deren verwendete Betriebssysteme
bekannt sind, und durch Player für das verwendete RealMedia-Format unterstützt
werden, ist der ausschließliche Einsatz von RealMedia möglich.
8.5.1.13 Austauschformate für Audio- und Video-Streaming
Im Gegensatz zu „normalen“ Audio- und Video-Sequenzen bietet Audio- und VideoStreaming ein Format, das es ermöglicht, schon während der Übertragung
abgespielt zu werden. Dadurch werden Live-Übertragungen von Videos möglich,
wohingegen bei „normalen“ Audio- und Videodateien die Datei zunächst komplett
übertragen und dann gestartet wird. In diesem Bereich ist bisweilen eine etwas
unübersichtliche Vermischung von Anbietern, Produkten, Container- und Inhalts-Formaten anzutreffen. Da SAGA keine Produktempfehlungen treffen will, sollen Empfehlungen nur für das Container-Format getroffen werden.
Wichtig dabei ist, dass die getroffenen Empfehlungen – so weit möglich – mit den
gängigen Streaming-Servern und Client-Produkten kompatibel sind. Aufgrund eines
seit Jahren vorhandenen starken Wettbewerbs in diesem Bereich ist zurzeit eine
hohe Kompatibilität zwischen den unterschiedlichen Produkten bezüglich der unterstützten Formate gegeben.
100. Mehr Informationen zu (.mp3) sind unter http://www.iis.fraunhofer.de/ verfügbar.
101. siehe http://quicktime.apple.com/
102. siehe http://www.realnetworks.com/
Seite 87
Obligatorisch: Hypertext Transfer Protocol (HTTP) v1.1
Um eine hohe Verbreitung an möglichst viele Bürger zu erreichen, soll bei der Wahl
des Server-Produkts darauf geachtet werden, dass der Transport der StreamingDaten auf jeden Fall über HTTP möglich ist.
Obligatorisch: Quicktime (.qt, .mov)
Um eine möglichst hohe Kompatibilität des Streaming-Signals mit gängigen Browsern, Audio- und Video-Clients beziehungsweise Plug-Ins zu erreichen, wird der Einsatz des Quicktime-Formats103 empfohlen, das derzeit von allen gängigen Produkten
unterstützt wird.
Unter Beobachtung: Ogg
Ogg104 ist ein derzeit unter Open Source entwickeltes, herstellerunabhängiges Container-Format für Streaming Audio (Ogg Vorbis) und Video (Ogg Theora, Ogg Tarkin).
Es gibt bereits Ankündigen von führenden Streaming-Server-Herstellern, dieses Format in Kürze zu unterstützen. Es wird erwartet, dass dieses Format in naher Zukunft
eine größere Verbreitung finden wird.
Unter Beobachtung: Windows Media Video (.wmv)
Das Format Windows Media Video (WMV) ist dem Quicktime-Format qualitativ überlegen. Allerdings verfügt das WMV-Format noch nicht über dessen breite Verfügbarkeit von Playern und Streaming-Servern für verschiedene Betriebssysteme. Nur bei
homogenen Zielgruppen, deren verwendete Betriebsysteme bekannt sind und durch
Player für das verwendete WMV-Format unterstützt werden, ist der ausschließliche
Einsatz von WMV möglich.
Unter Beobachtung: RealMedia v10 (.rm, .ram)
RealMedia der Firma RealNetworks105 ist das Container-Format für das Audio-Format RealAudio und das Video-Format RealVideo. All diese Formate sind proprietär.
RealVideo ist dem Quicktime-Format qualitativ überlegen. Der kostenlose Player
steht für alle gängige Plattformen außer für Unix einschließlich für Mobile Devices zur
Verfügung. Nur bei homogenen Zielgruppen, deren verwendete Betriebssysteme
bekannt sind, und durch Player für das verwendete RealMedia-Format unterstützt
werden, ist der ausschließliche Einsatz von RealMedia möglich.
103. siehe http://quicktime.apple.com/
104. siehe http://www.xiph.org/ogg/
105. siehe http://www.realnetworks.com/
Seite 88
Es ist zu beachten, dass die Preise für die RealMedia Server, Helix Server genannt,
im Vergleich zu Windows Media und Quicktime hoch sind. Allerdings unterstützen die
Helix Universal Server auch Windows Media und Quicktime.
8.5.1.14 Animation
Obligatorisch: Animated GIF
Unter Animation ist hier die Bewegung in Grafiken zu verstehen, die auf einer Site
angezeigt wird. Bevorzugt soll Animated GIF als eine Variante des GIF-Grafikformats
zum Einsatz kommen. Mehrere GIF-Einzelbilder werden hierbei in einer Datei gespeichert; die Reihenfolge, Anzeigedauer und Anzahl der Wiederholungen kann vorgegeben werden.
8.5.1.15 Datenkompression
Um den Austausch großer Dateien zu ermöglichen und die Netzbelastung zu minimieren, sollen Systeme zur Kompression eingesetzt werden.
Obligatorisch: ZIP v2.0
Die komprimierten Daten sollen im international verbreiteten Format ZIP Version 2.0
als (.zip) Dateien ausgetauscht werden.
Empfohlen: GZIP v4.3
Ersatzweise ist auch das Format GZIP in der Version 4.3, spezifiziert in RFC 1952106,
als (.gz)-Dateien möglich.
8.5.2 Informationsverarbeitung – Mobiltelefon / PDA
Sofern ein Informationsangebot für Mobiltelefone beziehungsweise PDAs erstellt werden soll, ist der Aufbau von SMS-Diensten aufgrund der breiten Akzeptanz in der
Bevölkerung zu bevorzugen. Die Darstellung von Web-Seiten für den Mobilfunk findet
noch keine große Anwendung in Deutschland.
Obligatorisch: Short Message Services (SMS)
Für die Realisierung von Short Message Services sollen die Spezifikationen des
SMS-Forums107 Anwendung finden. Das SMS-Forum ist ein internationales Forum
aller großen Informationstechnologieunternehmen.
106. siehe http://www.ietf.org/rfc/rfc1952.txt
107. siehe http://www.smsforum.net/
Seite 89
Unter Beobachtung: Wireless Application Protocol (WAP) v2.0
Das Wireless Application Protocol (WAP)108 v2.0 ist eine Spezifikation zur Entwicklung von Anwendungen, die über drahtlose Kommunikationsnetzwerke operieren.
Haupteinsatzgebiet ist der Mobilfunk. WAP umfasst die Wireless Markup Language
(WML) v2.0. Die Darstellungsmöglichkeiten haben sich gegenüber der Vorgängerversion denen im Internet stark angenähert.
Mit üblichen Internet-Browsern sind WML-Seiten nicht lesbar. Somit müssen Angebote, die sowohl für mobiles als auch für das normale Internet angeboten werden sollen, zweifach publiziert werden.
Mittlerweile sind die meisten mobilen Endgeräte mit WAP-2.0-Browsern ausgestattet.
Jedoch geht der Trend bei Handys und insbesondere bei PDAs hin zu Internet-Browsern mit voller Funktionalität.
Unter Beobachtung: Extensible Hypertext Markup Language (XHTML) Basic
XHTML Basic109 ist ein Standard zur Darstellung von auf XML umgesetzten HTMLSeiten für Anwendungen, die nicht die volle Darstellungsvielfalt von HTML unterstützen können (z. B. Mobilfunktelefone oder PDAs). Derzeit werden wiederum Subsets
von HTML Basic für verschiedene Endgeräte definiert.
WML v2.0 basiert wie WML v1.0 auf XML, ist jedoch ein Subset der XHTML Mobile
Profile Spezifikation, welches wiederum ein Subset von XHTML Basic ist.
8.5.3 Informationsverarbeitung – externe Systeme
Siehe dazu die Abschnitte 8.2 „Datenmodellierung“, 8.3 „Applikationsarchitektur“, 8.6
„Kommunikation“ und 8.7 „Anbindung an das Backend“. Von den im Bereich Middleware benannten Standards ist jedoch nur eine Untermenge für die Kommunikation mit
externen Systemen relevant. Im Zentrum der Kommunikation mit externen Systemen
stehen XML und Web-Service-Technologie. Bestehende Schnittstellen, basierend auf
OSI-Technologie, werden schrittweise migriert.
8.6
Kommunikation
Innerhalb des Elements Kommunikation wird zwischen Anwendungs-, Middlewareund Netzwerkprotokollen sowie Verzeichnisdiensten unterschieden.
8.6.1 Middleware-Protokolle
Bei den Middleware-Protokollen wird unterschieden, ob Server-Anwendungen innerhalb der Verwaltung untereinander kommunizieren (siehe Abschnitt 8.6.1.1) oder ob
108. siehe http://www.openmobilealliance.org/tech/affiliates/wap/wapindex.html
109. siehe http://www.w3.org/TR/xhtml-basic/
Seite 90
eine Client-Anwendung außerhalb der Verwaltung mit einem Server der Verwaltung
kommuniziert (siehe Abschnitt 8.6.1.2).
8.6.1.1 Server-Server-Kommunikation innerhalb der Verwaltung
Obligatorisch: Remote Method Invocation (RMI)
Für die Kommunikation zwischen unterschiedlichen Java Virtual Machines ist Java
RMI110 besonders geeignet. Über RMI kann ein Objekt auf einer Java Virtual Machine
(VM) Methoden eines Objektes aufrufen, das in einer anderen Java VM existiert. Java
Remote Method Invocation ist Bestandteil der Java 2 Standard Edition (J2SE) und
damit auch Bestandteil der Enterprise Edition (J2EE).
Obligatorisch: Simple Object Access Protocol (SOAP) v1.1
Für die Kommunikation von Anwendungen oder Anwendungskomponenten, die auf
einer J2EE-Architektur basieren, kann SOAP111 eingesetzt werden, wenn die Anforderungen an den Protokollumfang es zulassen. Bei einer Kommunikation zwischen
Servern, die nicht auf J2EE basieren, ist SOAP besonders geeignet. Mittels SOAP
können strukturierte Daten als XML-Objekte zwischen Anwendungen oder Anwendungskomponenten über ein Internetprotokoll (z. B. über HTTP) ausgetauscht werden.
Obligatorisch: Web Services Description Language (WSDL) v1.1
Zur Servicedefinition soll die Web Services Description Language (WSDL) eingesetzt
werden. WSDL ist eine standardisierte Sprache112, mit der Web Services so
beschrieben werden, dass sie durch andere Applikationen genutzt werden können,
ohne weitere Implementierungsdetails kennen oder die gleiche Programmiersprache
einsetzen zu müssen.
Die Spezifikation der zu übertragenden Datenelemente soll mittels XML Schema113
erfolgen.
Empfohlen: Remote Method Invocation over Internet Inter-ORB Protocol (RMIIIOP)
Java RMI-IIOP114 ist integraler Bestandteil der Java 2 Standard Edition (J2SE) und
damit auch Bestandteil der Enterprise Edition (J2EE). Über RMI-IIOP können verteilte
110.
111.
112.
113.
114.
siehe http://java.sun.com/rmi/
siehe http://www.w3.org/TR/SOAP/
siehe http://www.w3.org/TR/wsdl
siehe http://www.w3.org/XML/Schema
siehe http://java.sun.com/products/rmi-iiop/
Seite 91
Java-Applikationen mit entfernten Anwendungen über CORBA kommunizieren. Eine
RMI-IIOP-Kommunikation kann mit allen Object Request Brokern geführt werden, die
der aktuellen CORBA Spezifikation 2.3.1115 genügen. Die entfernten Anwendungen
sind deshalb nicht auf die Sprache Java beschränkt.
Die Spezifikation der zur übertragenden Datenelemente kann mittels Relax NG erfolgen. Die Relax-NG-Schemata müssen aber in XML Schemata transformiert werden
(siehe Abschnitt 8.2.2).
8.6.1.2 Client-Server-Kommunikation
Für den Zugriff von Client-Applikationen über das Internet auf Server-Applikationen
bei der Verwaltung sollen Web Services verwendet werden.
Indem eine Web-Service-Schicht für eine existierende Server-Applikation zur Verfügung gestellt wird, ermöglicht sie es Client-Systemen, die Funktionen der Applikationen über das Hypertext Transfer Protocol (HTTP) aufzurufen. Ein Web Service ist
eine Software-Komponente, die mit anderen Komponenten über das Standardprotokoll HTTP mittels SOAP kommuniziert. Für den Nachrichteninhalt selbst wird XML
verwendet, das schon im Abschnitt 8.2 „Datenmodellierung“ als universeller und primärer Standard für den Datenaustausch aller verwaltungstechnisch relevanten Informationssysteme beschrieben wurde.
Zur leichteren Zusammenstellung der benötigten Standards definiert die Web Service
Interoperability Organization (WS-I) Profile aus bestehenden Standards. Das anzuwendende Profil ist WS-I-Basic v1.1116 und umfasst u. a. XML Schema v1.0, SOAP
v1.1, WSDL v1.1 und UDDI v2.0.
Obligatorisch: Simple Object Access Protocol (SOAP) v1.1
Mittels SOAP117 können strukturierte Daten als XML-Objekte zwischen Anwendungen über ein Internetprotokoll (z. B. über HTTP) ausgetauscht werden.
Obligatorisch: Web Services Description Language (WSDL) v1.1
Zur Servicedefinition soll die Web Services Description Language (WSDL) eingesetzt
werden. WSDL ist eine standardisierte Sprache118, mit der Web Services so
beschrieben werden, dass sie durch andere Applikationen genutzt werden können,
ohne weitere Implementierungsdetails kennen oder die gleiche Programmiersprache
einsetzen zu müssen.
115.
116.
117.
118.
siehe http://omg.org/cgi-bin/doc?formal/99-10-07
siehe http://www.ws-i.org/Profiles/BasicProfile-1.1.html
siehe http://www.w3.org/TR/SOAP/
siehe http://www.w3.org/TR/wsdl
Seite 92
Die Spezifikation der zu übertragenden Datenelemente soll mittels XML Schema119
erfolgen.
Die Spezifikation der zur übertragenden Datenelemente kann mittels Relax NG erfolgen. Die Relax-NG-Schemata müssen aber in XML Schemata transformiert werden
(siehe Abschnitt 8.2.2).
Unter Beobachtung: Universal Description, Discovery and Integration (UDDI) v2.0
Das Projekt UDDI (Universal Description, Discovery and Integration, aktuelle Version
3.0)120 ist eine XML-basierte Technologieinitiative von Unternehmen aus allen Wirtschaftszweigen mit dem Ziel, Web Services zu publizieren, strukturiert zu verwalten
und dem Nutzer verfügbar zu machen. UDDI setzt dabei auf Standards des W3C und
der Internet Engineering Task Force (IETF) auf, wie z. B. XML, HTTP, DNS und
SOAP.
8.6.2 Netzwerkprotokolle
Obligatorisch: Internet Protocol (IP) v4
Aktuell wird im IT-Umfeld der Bundesverwaltung IP v4 (RFC 0791, RFC 1700) in Verbindung mit TCP (Transmission Control Protocol, RFC 793) und UDP (User Datagram Protocol, RFC 768) verwendet.
Unter Beobachtung: Internet Protocol (IP) v6
IP v6 ist die nächste Version des IP-Protokolls, die bisher noch keine weite Verbreitung gefunden hat. Eine der Änderungen gegenüber der aktuellen Version 4 ist die
Vergrößerung der IP-Adresse auf 128 Bit, um zukünftig auch vielfältige eingebettete
und mobile IP-basierte Systeme adressieren zu können.
IP v6 beinhaltet IPsec (IP-Security Protocol), das im Wesentlichen im Bereich VPN
(Virtual Private Network) Anwendung findet und auch unabhängig von IP v6 eingesetzt werden kann. Informationen zum Thema finden sich u. a. im Internetangebot der
Aktion „Sicherheit im Internet“121 oder beim Bundesamt für Sicherheit in der Informationstechnik122.
119.
120.
121.
122.
siehe http://www.w3.org/XML/Schema
siehe http://www.uddi.org/
siehe http://www.sicherheit-im-internet.de/
siehe http://www.bsi.de/
Seite 93
Bei der Neubeschaffung von Systemkomponenten sollten solche beschafft werden,
die neben IP v4 auch IP v6 unterstützen, um eine zukünftige Migration zu ermöglichen.
Obligatorisch: Domain Name Services (DNS)
Seit Mitte der 1980er Jahre sind Domain Name Services (DNS, RFC 1034, RFC
1035, RFC 1591) Standard im Internet. DNS bezeichnet einen hierarchischen NameServer-Dienst an zentralen Stellen des Internets. Hier wird ein eingegebener ServerName in die zugehörige IP-Adresse umgewandelt.
8.6.3 Anwendungsprotokolle
Die Anbindung von sicherheitsbezogenen Infrastrukturkomponenten (z. B. Verzeichnisdienste für Zertifikate, Sperrlisten usw.) wird in Abschnitt 9.4.2 behandelt.
Obligatorisch: File Transfer Protocol (FTP)
Für die Dateiübertragung gilt das File Transfer Protocol (FTP, RFC 959, RFC 1123,
RFC 2228, RFC 2640) als Standard. FTP ist einer der ältesten Internetdienste. Ziele
von FTP sind es, das Mitbenutzen von Dateien zu ermöglichen, dem Benutzer die
einheitliche Bedienung von verschiedenen Dateisystemtypen bereitzustellen und
Daten effizient und verlässlich zu transportieren. Der Download größerer Dateien
gelingt über FTP meist etwas schneller als über HTTP.
Obligatorisch: Hypertext Transfer Protocol (HTTP) v1.1
Für die Kommunikation zwischen Client und Web-Server soll HTTP v1.1 (RFC 2616)
eingesetzt werden. Web-Server sollen neben der Version 1.1 aber auch HTTP v1.0
(RFC 1945) unterstützen. Beim Einsatz von HTTP Session Management und Cookies
soll der Standard HTTP State Management Mechanism (RFC 2965) befolgt werden.
Obligatorisch: Simple Mail Transfer Protocol (SMTP) / Multipurpose Internet Mail
Extensions (MIME) v1.0
Für den E-Mail-Transport werden E-Mail-Protokolle vorausgesetzt, die den Spezifikationen von SMTP / MIME für den Nachrichten-Austausch entsprechen (RFC 821,
RFC 822, RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049). E-Mail-Anhänge
sollen dabei den Dateiformaten entsprechen, die im Abschnitt 8.5 definiert wurden.
Seite 94
Obligatorisch: Post Office Protocol (POP) 3 / Internet Message Access Protocol
(IMAP)
In Ausnahmefällen kann es vorkommen, dass elektronische Postfächer angeboten
werden müssen. Dazu sollen POP3 oder IMAP als weit verbreitete Standards eingesetzt werden.
8.6.4 Verzeichnisdienste
Obligatorisch: Lightweighted Directory Access Protocol (LDAP) v3
LDAP v3 (RFC 2251) ist ein auf hierarchisch geordnete Informationen optimiertes
Protokoll des Internets, das auf X.500 basiert und für den Zugriff auf Verzeichnisdienste verwendet wird.
Unter Beobachtung: Universal Description, Discovery and Integration (UDDI) v2.0
Das Projekt UDDI123 ist eine XML-basierte Technologie von Unternehmen aus allen
Wirtschaftszweigen mit dem Ziel, Web Services zu publizieren, strukturiert zu verwalten und dem Nutzer verfügbar zu machen. UDDI setzt auf Standards des W3C und
der IETF auf, wie z. B. XML, HTTP, DNS und SOAP.
Unter Beobachtung: Directory Services Markup Language (DSML) v2
DSML124 ist eine Definition in XML, mit der auf Verzeichnisdienste zugegriffen werden kann. Sie ist so entwickelt, dass verschiedene Verzeichnisse zusammen bearbeitet werden können.
8.7
Anbindung an das Backend
In der deutschen Verwaltung werden verschiedene Bestands- oder Legacy-Systeme
eingesetzt und mit einer hohen Wahrscheinlichkeit auch weiterhin betrieben (z. B.
ERP, Mainframe-Transaktionsverarbeitung, Datenbanksysteme und andere LegacyApplikationen). Diese Legacy-Systeme können je nach unterstützter Betriebsart in
drei Klassen gruppiert werden:
a. transaktionsgesicherte Verarbeitung durch Endbenutzer mittels vorhandener Dialogsysteme,
b. asynchrone Verarbeitung von Daten mit Stapelverarbeitungsprozessen (Massendatenverarbeitung) und
c. Programm-Programm-Kommunikation auf der Basis proprietärer Protokolle.
Zur Integration von Bestandssystemen existieren zwei grundsätzliche Möglichkeiten:
123. siehe http://www.uddi.org/
124. siehe http://www.oasis-open.org/
Seite 95
a. direkte Integration über so genannte „Legacy-Schnittstellen“ oder
b. Integration über eine eigene Integrationsschicht, in welcher der eigentliche Zugriff
auf die Bestandssysteme modular gekapselt wird.
Detaillierte Lösungskonzepte müssen in Anbetracht der zu erreichenden Ziele, der
zur Verfügung stehenden Zeit, des vorhandenen Budgets und der Funktionen, die bei
der Integration des Bestandssystems unterstützt werden sollen, bewertet und verglichen werden.
Die folgenden Abschnitte skizzieren unterschiedliche Lösungskonzepte, die sich bei
den drei genannten Betriebsarten bewährt haben.
8.7.1 Dialogsysteme
Solche Bestandssysteme können mit oder ohne Integrationsschicht in E-GovernmentLösungen der deutschen Verwaltung integriert werden:
a. mit Integrationsschicht
Oberflächen für eine Darstellung im Browser werden neu entwickelt. Die Verarbeitung der Bestandsdaten soll dann in einer eigenen Integrationsschicht erfolgen.
b. ohne Integrationsschicht
Die vorhandenen Dialoge werden mittels eines Produkts auf Oberflächen umgesetzt, die in einem Browser ablaufen können.
8.7.2 Stapelverarbeitung
Viele große Kommunikationssysteme verarbeiten ihre Daten in Stapelverarbeitungsprozessen, insbesondere wenn es um die Verarbeitung großer Datenmengen geht.
Die Daten werden entweder auf Datenträgern angeliefert oder per File Transfer übermittelt.
Bei dieser Betriebsart soll in Zukunft auch die Übermittlung der Daten über Dokumente im XML-Format125 unterstützt werden, siehe Abschnitt 8.2 „Datenmodellierung“. Dies eröffnet neue Möglichkeiten und macht die Schnittstellen flexibler.
8.7.3 Programm-Programm-Kommunikation
Im Bereich der Bundesverwaltungen existieren weit verbreitete Schnittstellen, die
angewendet und modernisiert werden sollen.
Für die Umstellung von Verarbeitungsschnittstellen, die noch auf proprietären Protokollen basieren, zu modernen Technologien hat sich der Informationsaustausch über
Seite 96
Dokumente im XML-Format126 etabliert. Mittlerweile bieten viele Hersteller die erforderlichen Schnittstellen zur Konvertierung der Daten in XML-Formate an, sodass sich
der Entwicklungsaufwand reduziert und gegebenenfalls die Entwicklung einer eigenständigen Connector-Funktionalität entfallen kann.
Empfohlen: Java Message Service (JMS) v1.1, J2EE Connector Architecture v1.5
Um eine nahtlose Integration in die J2EE-Plattform zu gewährleisten, wird empfohlen,
die Integration über den Java Message Service oder die J2EE Connector Architecture
zu realisieren.
Empfohlen: Web Services
Für die Übertragung der Daten bieten sich vor allem Web Services127 an.
Unter Beobachtung: Business Process Execution Language for Web Services
(BPEL4WS) v1.1
Zur Beschreibung von Geschäftsprozessen auf Basis von Web Services kann
BPEL4WS128 eingesetzt werden. Das unter der Schirmherrschaft von OASIS stehende BPEL4WS ist eine XML-basierte Beschreibungssprache, die Web Services
und die damit verbundenen Standards (SOAP, WSDL, UDDI) um geschäftliche
Transaktionen erweitert.
Große Infrastrukur- und Anwendungsanbieter wie Oracle, Microsoft, IBM, SAP, BEA
und Siebel unterstützen die Spezifikation und es stehen Werkzeuge, auch Open
Source129, zur Verfügung. Ein offizieller (OASIS-)Standard ist BPEL4WS aber noch
nicht. Die Weiterentwicklung von BPEL4WS findet unter dem Namen Web Services
Business Process Execution Language (WS-BPEL) v2.0 statt.
126.
127.
128.
129.
siehe http://www.w3.org/XML/
siehe http://www.w3.org/TR/ws-arch/
siehe http://www.oasis-open.org/committees/wsbpel/
siehe http://www.bpelsource.com/products/
Seite 97
Seite 98
9 Technology Viewpoint (Teil II): Standards für Datensicherheit
Ein wesentlicher Aspekt für die erfolgreiche Umsetzung und Durchführung von
Dienstleistungen im Rahmen von BundOnline 2005 ist die Gewährleistung der
Datensicherheit. Datensicherheit repräsentiert und fördert die vertrauenswürdige und
sichere Interaktion von Bürgern, Behörden und Wirtschaft.
Das E-Government-Architekturmodell (siehe Kapitel 3) identifiziert Datensicherheit
als eine durchgängige Komponente, die je nach Bedarf beziehungsweise Anforderung in jedem Element und jeder Säule des Modells durch entsprechende Verfahren,
Methoden und Datenformate unterstützt werden kann. Der Einsatz der technischen
Mittel muss so gestaltet werden, dass Vertrauen zwischen den kommunizierenden
Instanzen gebildet wird, der Grundschutz gewährleistet ist und die klassischen
Schutzziele erfüllt werden.
Da die Relevanz von Sicherheitsmaßnahmen in den letzten Jahren durch die zunehmende Nutzung des Internets extrem gestiegen ist, kann man auch einen Anstieg von
Normungsbestrebungen in diesem Bereich verzeichnen. So ist eine Vielzahl von
Sicherheitsstandards, -richtlinien und -empfehlungen entstanden.
Dieses Kapitel stellt die relevanten Sicherheitsstandards und -empfehlungen für
E-Government-Dienstleistungen vor.
9.1
Ziele und Prinzipien der Datensicherheit
Die vorgestellten Standards für Datensicherheit helfen zu ermitteln, ob für eine
Dienstleistung ein Schutzbedarf vorliegt oder nicht. Nur wenn Schutzbedarf ermittelt
wurde, müssen auch Schutzmaßnahmen ergriffen werden.
9.1.1 Schutzziele
Schutzziele definieren die Sicherheitsinteressen der beteiligten Kommunikationspartner in allgemeiner Form:
a. Vertraulichkeit – Schutz vor unbefugter Kenntnisnahme:
Daten werden Individuen, Entitäten oder Prozessen nicht unautorisiert zur Verfügung gestellt oder offenbart.
b. Integrität – Schutz vor Manipulation:
Daten können nicht unautorisiert verändert oder zerstört werden.
c. Authentizität – Schutz vor gefälschter Identität / Herkunft:
Es wird sichergestellt, dass die Identität einer Entität beziehungsweise Ressource
(z. B. Mensch, Prozess, System, Dokument, Information) die ist, die sie zu sein
vorgibt.
d. Verfügbarkeit – Schutz vor Ausfall der IT-Systeme:
Die Eigenschaft einer Entität beziehungsweise Ressource ist zugänglich beziehungsweise nutzbar, wenn es durch eine autorisierte Entität gewünscht wird.
Seite 99
Die Verschlüsselung von Informationen (Kryptografie) ist ein wichtiges Hilfsmittel bei
der Sicherung der Vertraulichkeit, Integrität und Authentizität.
Hohe Verfügbarkeit wird durch Vielfalt, Verteiltheit und Fehlertoleranz erreicht.
9.1.2 Schutzbedarf
Der Schutzbedarf muss für jede IT-Anwendung ermittelt werden. Er orientiert sich an
den möglichen Schäden, die mit einer Beeinträchtigung der betroffenen IT-Anwendung verbunden sind.
Die Ermittlung des Schutzbedarfs wird im IT-Grundschutzhandbuch130 (Abschnitt 2.2
Schutzbedarfsfeststellung) erläutert und im E-Government-Handbuch131 (Modul:
Phasenplan E-Government – Phase 3 „Analyse“132) in Anlehnung an das IT-Grundschutzhandbuch in vier Kategorien unterteilt:
Schutzbedarfsklasse
Ausprägung der Schutzbedarfsklasse
„kein“
Ein besonderer Schutz ist nicht notwendig, da keine Schadensauswirkungen zu erwarten sind.
„niedrig“
Die Schadensauswirkungen sind eng begrenzt.
„mittel“
Die Schadensauswirkungen sind begrenzt und überschaubar.
„hoch“
Die Schadensauswirkungen können beträchtlich sein.
„sehr hoch“
Die Schadensauswirkungen können ein existenziell bedrohliches, katastrophales Ausmaß erreichen.
Tabelle 9-1: Schutzbedarfsklassen
Um Anwendungen sicherheitstechnisch zu bewerten, kann jedem Schutzziel eine
Schutzbedarfskategorie zugeordnet werden. Beispiele für die Schutzbedarfsfeststellung findet man im E-Government-Handbuch (Modul: Phasenplan E-Government –
Phase 3 „Analyse“).
Bei der Schutzbedarfsfeststellung ist insbesondere auch eine mögliche Verarbeitung
von personenbezogenen Daten zu betrachten, um die datenschutzrechtlichen Rahmenbedingungen einzuhalten. SAGA verzichtet auf die Erläuterung von Datenschutzmaßnahmen. Hinweise zum Datenschutz bezüglich Rahmenbedingungen, Herausforderungen und Handlungsempfehlungen findet man im E-Government-Handbuch
(Modul: Datenschutzgerechtes E-Government133).
132. siehe E-Government-Handbuch (http://www.bsi.bund.de/fachthem/egov/6.htm), Kapitel III, Modul
„Phase 3 – Analyse“
133. siehe E-Government-Handbuch (http://www.bsi.bund.de/fachthem/egov/6.htm), Kapitel II, Modul
„Datenschutzgerechtes E-Government“
Seite 100
9.1.3 Strukturmodell für Datensicherheit
Um Sicherheitsstandards einfacher zu verstehen und anwenden zu können, wurde
das E-Government-Architekturmodell aus Kapitel 3 sicherheitsspezifisch in einem
Strukturmodell (siehe Abbildung 9-1) verfeinert.
Interaktionsszenarien
Schutzbedarfsklassen
Schutzziele
Schutzziele – Sicherheitsinteressen der Kommunikationspartner: Vertraulichkeit, Integrität, Authentizität, Verfügbarkeit
Schutzbedarfsklassen – Unterteilung des Schutzbedarfs:
kein, niedrig, mittel, hoch, sehr hoch
Interaktionsszenarien für Dienstleistungen:
Information, Kommunikation, Transaktion
Anwendungssicherheit
Anwendungsspezifische Standards für Fachanwendungen,
z.B. Gesetze, Verordnungen, Empfehlungen für
Datensicherheit und Datenschutz
Sicherheitsdienste
Sicherheitsdienste, die von Anwendungen für die Sicherung
ihrer Daten / Ressourcen genutzt werden können, z.B. sichere
E-Mail, Dokumentensignatur (Signieren / Prüfen)
Übertragungssicherheit
Protokolle, Schnittstellen und Austauschformate, die eine
sichere Übertragung von Informationen ermöglichen bzw.
unterstützen, z.B. SSL/TLS
Sicherheitsmechanismen
Basismechanismen und Datenformate, z.B. Zertifikate,
Sperrlisten, Schlüssel
Sicherheitsinfrastruktur
Infrastrukturkomponenten und Zugriffsprotokolle, die eine
vertrauenswürdige Kommunikation unterstützen, z.B. PKI,
Zeitstempeldienst, Verzeichnisse, LDAP, OCSP
Kryptografische
Verfahren
Verfahren, die kryptografische Mechanismen und
Algorithmen bereitstellen, z.B. Hash-Funktionen,
asymmetrische und symmetrische Verfahren
Sicherheits-Software
und SicherheitsHardware
Spezielle Hardware und Software für Sicherheitszwecke,
z.B. Smartcards und Lesegeräte, sowie Software für deren
Anbindung
Abbildung 9-1: Strukturmodell für Sicherheitsstandards
Seite 101
Das Strukturmodell ist kein Schichtenmodell, sondern veranschaulicht verschiedene
Spezifikationsprozesse zum Erreichen der gewünschten Sicherheitsziele. Es dient
der Verständnisbildung für die Komplexität von IT-Sicherheit.
Ein Datensicherheitsstandard umfasst im Allgemeinen mehr als eine Strukturebene,
daher wird auf eine gezielte Einordnung verzichtet. Jeder Standard kann jedoch aus
Sicht der einzelnen Strukturebenen betrachtet werden.
Das Strukturmodell und die aufgeführten Datensicherheitsstandards entbinden nicht
von der eingehenden Analyse der Fachanwendung hinsichtlich Gesetzeskonformität
und der Einhaltung der Datenschutzbestimmungen durch die entsprechenden Spezialisten sowie von der Überprüfung und Einhaltung des Sicherheitsniveaus in allen
Instanzen und Prozessen der Interaktionskette. Eine anwendungsspezifische Risikoanalyse, die Schutzbedarfsfeststellung sowie ein Sicherheitskonzept sollen erstellt
werden.
Schutzziele, Schutzbedarf und Anwendungsfälle definieren die Zielsetzung von
Sicherheitsmaßnahmen.
9.2
Standards für die Sicherheitskonzeption
Generell sind die Gesetze und Beschlüsse des Bundes als obligatorisch anzusehen.
Diese werden durch Empfehlungen und Anleitungen für die IT-Sicherheit ergänzt.
Für die Ermittlung des Schutzbedarfs sollen die nachfolgend aufgeführten Empfehlungen und Anleitungen des Bundesamts für Sicherheit in der Informationstechnik (BSI)
und des Kooperationsausschusses ADV Bund / Länder / Kommunaler Bereich
(KoopA ADV) verwendet werden. Sofern ein Schutzbedarf für die IT-Anwendung
beziehungsweise -Komponente ermittelt wurde, ist die Beachtung dieser Empfehlungen und Anleitungen obligatorisch.
Obligatorisch: BSI, IT-Grundschutzhandbuch
Die Anwendung des IT-Grundschutzhandbuchs des BSI (Handbuch zur Erstellung
von IT-Sicherheitskonzepten für normalen Sicherheitsbedarf)134 und die Umsetzung
der dort beschriebenen Standardsicherheitsmaßnahmen wird gefordert. Mit Hilfe des
IT-Grundschutzhandbuchs lassen sich IT-Sicherheitskonzepte einfach und arbeitsökonomisch realisieren. Die Struktur des IT-Grundschutzhandbuchs unterstützt eine
komponentenorientierte Arbeitsweise.
Empfohlen: KoopA ADV, Handlungsleitfaden für die Einführung der elektronischen
Signatur und Verschlüsselung in der Verwaltung v1.1
Der Handlungsleitfaden für die Einführung der elektronischen Signatur und Verschlüsselung in der Verwaltung des KoopA ADV 135 soll dem Ziel dienen, die Lösung
135. siehe http://www.koopa.de/projekte/pki.html
Seite 102
kryptografischer Problemstellungen für ausgewählte Projekte in der öffentlichen Verwaltung zu erleichtern und ist in erster Linie als Arbeitshilfe für die Behörden gedacht.
Typische Problemstellungen werden in Form von Szenarien definiert, für die wiederum Lösungsmöglichkeiten aufgezeigt werden.
Empfohlen: BSI, E-Government-Handbuch
Das E-Government-Handbuch136 des BSI wurde zur Unterstützung der Initiative
BundOnline 2005 erstellt. Das Handbuch umfasst organisatorische und technische
Empfehlungen zum IT-Einsatz im E-Government. Insbesondere werden auch sicherheitstechnische Empfehlungen zur Verfügung gestellt.
9.3
Standards für bestimmte Anwendungsfälle
Um eine anwendungsnahe Zuordnung von Sicherheitsstandards zu ermöglichen,
werden häufige Anwendungsfälle aus sicherheitsspezifischer Sicht formuliert (siehe
Tabelle 9-2 auf Seite 103).
Information
Kommunikation
Transaktion /
Integration
Sichere Übertragung von SSL/TLS
Web-Inhalten (Integrität
und Vertraulichkeit)
Web-Server-Authentizität SSL/TLS
Sicherung von E-MailKommunikation
ISIS-MTT v1.1
Gesicherter Dokumentenaustausch
(Authentizität, Integrität
und Vertraulichkeit)
ISIS-MTT v1.1
XML Signature
und XML
Encryption
Transaktionen
OSCI-Transport
v1.2
Web Services
WS-Security v1.0
Tabelle 9-2: Sicherheitsstandards für bestimmte Anwendungsfälle
9.3.1 Sichere Übertragung von Web-Inhalten und Web-Server-Authentizität
Kommuniziert ein Client mit dem Web-Server einer Behörde, so muss sichergestellt
sein, dass es sich tatsächlich um den Server der Behörde handelt (Web-ServerAuthentizität). Der Abruf von Informationen, d. h. die Übermittlung von Web-Inhalten,
Seite 103
die Integrität und / oder Vertraulichkeit erfordern, muss während der Übertragung im
Internet gesichert erfolgen.
Obligatorisch: Secure Sockets Layer (SSL) / Transport Layer Security (TLS)
SSL ist ein kryptografisches Protokoll, das die Integrität, Vertraulichkeit und Authentizität einer Kommunikationsverbindung im World Wide Web sichert. Es wurde zum
Protokoll TLS137 weiterentwickelt.
SSL/TLS setzen auf TCP/IP auf und sichern Kommunikationsprotokolle für Anwendungen, wie z. B. HTTP, FTP, IIOP etc., in transparenter Art und Weise. SSL/TLSgesicherte WWW-Seiten werden mit https:// statt mit http:// angesprochen.
Die Verwendung von HTTP über SSL-gesicherte Verbindungen wird oft als HTTPS
bezeichnet.
SSL/TLS unterstützt ebenfalls eine einseitige Authentisierung des Behörden-Servers
gegenüber dem Client des Kommunikationspartners, damit sich dieser davon überzeugen kann, dass er tatsächlich mit dem Behörden-Server verbunden ist. Auch eine
beidseitige Authentisierung von Client und Server kann durch SSL/TLS unterstützt
werden.
SSL/TLS bietet folgende kryptografische Mechanismen:
a. asymmetrische Authentisierung der Kommunikationspartner (über X.509-Zertifikate),
b. sicherer Austausch von Sitzungsschlüsseln (über RSA-Verschlüsselung oder Diffie-Hellman-Schlüsseleinigung),
c. symmetrische Verschlüsselung der Kommunikationsinhalte,
d. symmetrische Nachrichtenauthentisierung (über MACs) und Schutz gegen Wiedereinspielen von Nachrichten.
Die genaue Funktionsweise von SSL/TLS ist im KoopA ADV Handlungsleitfaden138
Abschnitt 5.2.2 beschrieben. Die Kombination verschiedener Verfahren wird in SSL/
TLS als „Cipher Suite“ bezeichnet. Eine SSL/TLS-Cipher-Suite enthält stets vier kryptografische Algorithmen: ein Signaturverfahren, ein Schlüsselaustauschverfahren, ein
symmetrisches Verschlüsselungsverfahren sowie eine Hash-Funktion.
Folgende Empfehlungen werden im Handlungsleitfaden des KoopA ADV vorgegeben:
a. Die Schlüssellängen für die symmetrischen Verfahren sollten maximal (d. h. derzeit 128 Bit oder 112 Bit Triple-DES) gewählt werden; Einfach-DES und RC2 sollten nicht eingesetzt werden.
b. Als Hash-Funktion soll SHA-1 eingesetzt werden.
c. RSA-Modulus soll mindestens 1024 Bit haben.
137. siehe http://www.ietf.org/rfc/rfc2246.txt
138. siehe http://www.koopa.de/projekte/pki.html
Seite 104
9.3.2 Sicherung von E-Mail-Kommunikation
Für die Interaktionsstufe Kommunikation ist ein möglicher Anwendungsfall der sichere
Austausch von E-Mails. Eine sichere E-Mail-Kommunikation umfasst die Sicherung
von E-Mails während ihrer Übermittlung von einem Sender zu einem Empfänger. Dieser Anwendungsfall betrachtet E-Mails in ihrer Gesamtheit. Die Sicherung von Dokumenten, auch von E-Mail-Anlagen, wird in Abschnitt 9.3.3 „Gesicherter Dokumentenaustausch“ behandelt.
Obligatorisch: Industrial Signature Interoperability Specification (ISIS)-MTT v1.1
Die ISIS-MTT-Spezifikation139 berücksichtigt auf Basis der Grundfunktionen elektronische Signatur, Verschlüsselung und Authentifizierung vielfältige Anwendungsfelder
von Verfahren zur Sicherung des elektronischen Geschäftsverkehrs (z. B. Datei-,
Mail-, Transaktions- und Zeit-Sicherung“).
ISIS-MTT ist eine Delta-Spezifikation, die auf bestehenden, relevanten internationalen Standards (S/MIME, PKIX, PKCS, X.509, ETSI, CEN ETSI) basiert. Schwerpunkt
der Spezifikation sind Aussagen zu Konformitätsanforderungen, die von konformen
PKI-Komponenten und -Anwendungen bei der Generierung beziehungsweise Verarbeitung von bestimmten Datenobjekten, wie beispielsweise Zertifikaten, erfüllt werden
müssen.
Der Umfang der ISIS-MTT-Spezifikation wurde bestimmt durch die Zusammenführung und Vereinheitlichung der MailTrusT- (Version 2, März 1999, TeleTrusT e.V.)
und der ISIS-Spezifikation (Industrial Signature Interoperability Specification: Version
1.2, Dezember 1999, T7 e.V.).
Die ISIS-MTT-Spezifikation besteht im Wesentlichen aus einem Kerndokument, das
ausschließlich auf einer Profilierung (Einschränkung optionaler Merkmale) internationaler Standards beruht und somit internationale Interoperabilität gewährleisten soll.
Die Basis von ISIS-MTT ist eine für alle Hersteller und Anbieter obligatorische Kernspezifikation, die bei Bedarf um optionale Profile ergänzt werden kann. Die bereits
vorliegenden Profile „SigG-Profile“ und „Optional Enhancements to the SigG-Profile“
beschreiben die aktuelle Ausprägung qualifizierter Signaturen in Deutschland.
9.3.3 Gesicherter Dokumentenaustausch
Für die Interaktionsstufe Kommunikation ist der Austausch sicherer Dokumente erforderlich. Dies umfasst z. B. die Sicherung von Dokumenten als E-Mail-Anlagen und die
Sicherung von Dokumenten für beliebige Kommunikationswege.
Bezüglich der Sicherung von E-Mail-Anlagen ist der Standard ISIS-MTT v1.1 relevant.
Für den sicheren Austausch von XML-Dokumenten (z. B. für weiterverarbeitbare Formulare) erlangen die XML-spezifischen Standards XML Signature und XML Encryption zunehmend Relevanz.
139. siehe http://www.isis-mtt.org/
Seite 105
ISIS-MTT v1.1 (siehe Abschnitt 9.3.2 „Sicherung von E-Mail-Kommunikation“) definiert ein interoperables Datenaustauschformat für signierte und verschlüsselte Daten.
Es berücksichtigt auch die Sicherung binärer Daten (insbesondere Part 3: Message
Formats), sodass beliebige Dateien als E-Mail-Anlagen gesichert übertragen werden
können.
Obligatorisch: XML Signature
XML Signature ist ein gemeinsamer Standard von W3C und IETF (W3C, XML-Signature Syntax and Processing, W3C Recommendation und IETF RFC 3275, März
2002)140.
Dieser Standard beschreibt digitale Signaturen für beliebige Daten (in der Regel
jedoch XML), indem ein XML-Schema und ein Verarbeitungsregelwerk (für die Generierung und Validierung der Signatur) bereitgestellt werden. Die Signatur kann dabei
ein oder mehrere Dokumente beziehungsweise Daten unterschiedlicher Art (Bild,
Text etc.) umfassen.
Für die Platzierung der XML Signature gibt es drei Möglichkeiten:
a. Einbettung (enveloped): Die Signatur kann eingebettet sein, d. h. in das signierte
Dokument wird das XML-Fragment, das die Signatur darstellt, eingefügt.
b. Umschlag (enveloping): Die Signatur kann als Umschlag fungieren, d. h. sie wird
auf ein Dokument angewendet, auf das innerhalb der Signatur verwiesen wird.
c. Unabhängigkeit (detached): Die Signatur kann unabhängig vorliegen (detached),
d. h. sie wird separat von der Quelle aufbewahrt, entweder in demselben oder in
einem anderen XML-Dokument.
Ein zentrales Merkmal von XML Signature ist die Möglichkeit, anstelle des gesamten
XML-Dokuments nur bestimmte Teile desselben zu signieren. Es können sowohl
asymmetrische Kryptoalgorithmen als auch symmetrische Verfahren eingesetzt werden, die in Abhängigkeit vom Schutzziel gewählt werden müssen.
Diese Flexibilität ermöglicht beispielsweise, die Integrität bestimmter Elemente eines
XML-Dokuments zu sichern, während andere Teile verändert werden können: z. B.
ein signiertes XML-Formular, das an einen Benutzer geschickt wird. Hier kann der
Benutzer bestimmte Felder ausfüllen, ohne dass die Integrität des Dokuments verletzt
wird. Dies war in herkömmlichen Signaturen nicht möglich, da immer das gesamte
Dokument signiert wurde und somit jede Veränderung / Einfügung eine Integritätsverletzung bedeutet hätte.
Folgende Kryptoalgorithmen werden benannt:
a. Hash-Funktion: SHA-1
b. Kodierung: base64
140. siehe http://www.w3.org/TR/xmldsig-core/
Seite 106
c. MAC: HMAC-SHA-1 (symmetrische Schlüssel); (HMAC RFC 2104)
d. Signatur: DSA-SHA-1 (DSS); empfohlen zusätzlich RSA-SHA-1
Eine Spezialisierung der kryptografischen Präferenzen für bestimmte Kommunikationsszenarien ist noch nicht erfolgt.
Obligatorisch: XML Encryption
Der W3C-Standard XML Encryption (XML Encryption Syntax and Processing, W3C
Recommendation, 10. Dezember 2002)141 stellt ein XML-Schema und ein Verarbeitungsregelwerk (für die Verschlüsselung / Entschlüsselung) bereit, das die Verschlüsselung / Entschlüsselung von ganzen Dokumenten, Dokumentteilen (Dokumentelementen) oder von Elementinhalten unterstützt.
Die Verschlüsselung kann mit einem symmetrischen oder einem asymmetrischen
Schlüssel erfolgen.
Folgende Kryptoalgorithmen werden benannt:
a. Blockverschlüsselung: Triple-DES, AES
b. Schlüsseltransport: RSA (RSAES-PKCS1-v1_5 algorithm, RFC 2437)
c. Schlüsseleinigung: Diffie-Hellman (optional)
d. Hash-Funktion: SHA-1, RIPEMD-160
e. Kodierung: base64
Im Gegensatz zu XML-Signature ist XML-Encryption noch kein RFC, ist aber zusammen mit XML-Signature gesetzte Grundlage mehrerer von der Industrie angenommener Standards für den sicheren XML-basierten Dokumentenaustausch (Web Services
Security, SAML, ebXML-Messaging, FinTS, OSCI-Transport).
9.3.4 Transaktionen
Transaktionen umfassen die komplexen, fachbezogenen Geschäftsvorfälle mit einer
mehrstufigen Wertschöpfungskette zwischen beteiligten Kommunikationspartnern.
Obligatorisch: Online Service Computer Interface (OSCI)-Transport v1.2
Das Online Service Computer Interface (OSCI)142 wurde im Rahmen des Wettbewerbs MEDIA@Komm entworfen. OSCI umfasst eine Menge von Protokollen, die für
die Anforderungen im E-Government geeignet sind und durch die OSCI-Leitstelle
erstellt werden. Zielsetzung ist dabei die Unterstützung von Transaktionen in Form
von Web Services und deren vollständige Abwicklung über das Internet.
OSCI-Transport 1.2 ist der Teil von „OSCI“, der die Querschnittsaufgaben im Sicherheitsbereich löst. Die Existenz einer zentralen Vermittlungsstelle, des so genannten
Intermediär, der Mehrwertdienstleistungen erbringen kann, ohne die Vertraulichkeit
141. siehe http://www.w3.org/TR/xmlenc-core/
142. siehe http://www.osci.de/
Seite 107
auf der Ebene der Geschäftsvorfalldaten zu gefährden, ist für die sichere Umsetzung
von Prozessen des E-Government mittels OSCI charakteristisch. Als sicheres Übertragungsprotokoll ermöglicht es verbindliche (auch SigG-konforme) Online-Transaktionen.
OSCI-Transport unterstützt die asynchrone Kommunikation per Intermediär und die
Ende-zu-Ende-Verschlüsselung für die vertrauliche Übermittlung von Daten. OSCITransport standardisiert sowohl die Nachrichteninhalte als auch die Transport- und
Sicherheitsfunktionen und basiert auf internationalen Standards (u. a. XML Signature,
DES, AES, RSA und X.509), die in geeigneter Weise konkretisiert werden.
Wesentliche Designkriterien für OSCI-Transport in der Version 1.2 waren:
a. Aufsetzen auf offene Standards (SOAP, XML Signature, XML Encryption),
b. Technikunabhängigkeit, d. h. Übertragung mit einem beliebigen technischen Kommunikationsprotokoll ohne spezifische Anforderungen an Plattformen und Programmiersprachen,
c. Skalierbarkeit der Sicherheitsniveaus (fortgeschrittene Signaturen oder qualifizierte beziehungsweise akkreditierte elektronische Signaturen nach Bedarf der
Anwendung).
9.3.5 Web Services
Die zunehmende Wichtigkeit von XML als Datenaustausch- und Spezifikationsformat
auch im Sicherheitsbereich sowie die Einführung von Web Services als integrative
Middleware bewirkt eine aktive Standardisierung von XML-Sicherheitsstandards in
den Gremien des W3C und OASIS. Die Relevanz und der finale Umfang der Entwürfe
sind derzeit noch nicht vollständig abschätzbar.
Empfohlen: Web Services (WS)-Security v1.0
WS-Security143 ist ein OASIS-Standard für sichere Web Services. Er definiert Erweiterungen des SOAP-Protokolls, um Vertraulichkeit, Integrität und Verbindlichkeit der
SOAP-Nachrichten für die Sicherung von Web Services bereitzustellen. Unterschiedliche Sicherheitsmodelle und unterschiedliche kryptografische Verfahren sollen
zugrunde liegen können.
Ebenfalls erlaubt WS-Security unterschiedliche „Sicherheits-Token“, d. h. Datenformate, die bestimmte Identitäten oder Eigenschaften zusichern, z. B. X.509-Zertifikate,
Kerberos Tickets oder verschlüsselte Schlüssel.
143. siehe http://www.oasis-open.org/specs/index.php#wssv1.0 und http://www.oasis-open.org/specs/index.php#wssprofilesv1.0
Seite 108
9.4
Übergreifende Datensicherheitsstandards
Übergreifende Sicherheitsstandards umfassen die Standards, die nicht bestimmten
Anwendungsfällen beziehungsweise Interaktionsstufen zuzuordnen sind, siehe
Tabelle 9-3 auf Seite 109.
Information
Anbindung
Sicherheitsinfrastruktur
Kommunikation
Transaktion /
Integration
ISIS-MTT v1.1
Anbindung Smartcards
ISO/IEC 7816
Key Management
XKMS v2
Kryptoalgorithmen für die
elektronische Signatur
Veröffentlichung durch RegTP (Hash-Funktionen:
RIPEMD-160, SHA-256, SHA-512; Signaturalgorithmen: RSA, DSA, DSA-Varianten)
Symmetrische
Kryptoalgorithmen
AES, Triple-DES
Tabelle 9-3: Übergreifende Sicherheitsstandards
9.4.1 Authentisierung
Um das Schutzziel Authentizität zu gewährleisten, ist die Identitätsfeststellung und
Authentisierung von Kommunikationspartnern für bestimmte E-Government-Anwendungen erforderlich. Verschiedene Mechanismen können für die Authentisierung verwendet werden, z. B. Nutzerkennung / Passwort, PIN / TAN oder Zertifikate. Eine
sicherheitstechnische Betrachtung verschiedener Authentisierungsverfahren erfolgt
im Modul „Authentisierung im E-Government“144 des E-Government-Handbuchs.
9.4.2 Anbindung Sicherheitsinfrastruktur
Die Sicherheitsinfrastruktur umfasst Verzeichnis-, Zertifizierungs- und Zeitstempelkomponenten, welche die Verteilung und Handhabung von Zertifikaten, Sperrlisten
und Zeitstempeln sowohl für E-Mail als auch für Web-Umgebungen unterstützen. Der
Zugang zu diesen Komponenten erfolgt durch operationale Protokolle.
ISIS-MTT (siehe Abbildung 9.3.2 „Sicherung von E-Mail-Kommunikation“) beschreibt
im Teil 4 „Operational Protocols“ Protokolle beziehungsweise Profile für die Anbindung von Sicherheitsinfrastrukturen. Diese umfassen den Zugang zu Verzeichnissen
144. siehe E-Government-Handbuch (http://www.bsi.bund.de/fachthem/egov/6.htm), Kapitel IV B, Modul
„Authentisierung im E-Government“
Seite 109
mittels LDAP v3, Online Certificate Status Protocol (OCSP), FTP und HTTP sowie
das Time Stamp Protocol (TSP).
9.4.3 Anbindung Smartcards
Die Integration von Smartcards, Smartcard-Lesern und deren Treiberarchitekturen
beziehungsweise von kompletten, multifunktionalen „Smartcard / Leser Bundles“ ist
für die Client-Infrastruktur unter anderem für den Einsatz von qualifizierten elektronischen Signaturen erforderlich.
Die Initiative D21145 bearbeitete diese Thematik in der Arbeitsgruppe 5 – Projekt
Smartcards. Die Ergebnisse wurden in einem Projektreport146 zusammengefasst.
Obligatorisch: ISO/IEC 7816
Smartcards (Chipkarten) müssen der Norm ISO/IEC 7816 entsprechen. Komponenten, welche die universelle Krypto-Schnittstelle „Cryptographic Token Interface“
(Cryptoki) unterstützen, müssen Konformität zu ISIS-MTT Teil 7 (Cryptographic
Token Interface) aufweisen.
9.4.4 Key Management
Damit Anwendungen elektronische Signaturen einsetzen können, muss es die Möglichkeit geben, öffentliche elektronische Schlüssel (Public Keys) realen Personen
oder Institutionen zuzuordnen. Um Interoperabilität zwischen verschiedenen Anwendungen zu erreichen, müssen die Formate für diese Daten übereinstimmen sowie einheitliche Mechanismen zum Lesen und Schreiben der Daten eingesetzt werden.
Empfohlen: XML Key Management Specification (XKMS) v2
XKMS147 spezifiziert Protokolle zur Registrierung und Verteilung von Public Keys. Die
Protokolle sind für das Zusammenspiel mit XML Signature und XML Encryption entworfen worden und finden ihr Anwendungsgebiet deshalb bei XML-basierter Kommunikation, wie z. B. bei Web Services. Die Spezifikation besteht aus zwei Teilen: die
XML Key Registration Service Specification (X-KRSS) und die XML Key Information
Service Specification (X-KISS).
Clients können vergleichsweise einfache XKMS-Anfragen zum Auffinden und Validieren von Public Keys einsetzen und Relay-Server greifen zur Beantwortung der Anfragen auf bestehende LDAP- und OCSP-Infrastrukturen zu. Mit nur einem Protokoll
können so parallel verschiedene Verzeichnisdienste genutzt werden.
145. siehe http://www.initiatived21.de/
146. siehe http://www.initiatived21.de/druck/news/publikationen2002/doc/28_1053503411.pdf
147. siehe http://www.w3.org/TR/xkms2/
Seite 110
9.4.5 Kryptoalgorithmen für die elektronische Signatur
Die Sicherheit einer elektronischen Signatur hängt primär von der Stärke der
zugrunde liegenden Kryptoalgorithmen ab. Zum Thema „Elektronische Signatur“
siehe auch Abschnitt 4.1.5.1 auf Seite 40.
Obligatorisch: Kryptoalgorithmen nach RegTP für die elektronische Signatur
Die Regulierungsbehörde für Telekommunikation und Post (RegTP) veröffentlicht im
Bundesanzeiger jährlich die geeigneten Kryptoalgorithmen, die in Erfüllung der Anforderungen nach Signaturgesetz (SigG) und Signaturverordnung (SigV) als mindestens
geeignet für die jeweils kommenden sechs Jahre anzusehen sind148. Das BSI kann
die Eignung weiterer Verfahren feststellen.
Eine elektronische Signatur im Sinne des Gesetzes umfasst die folgenden Kryptoalgorithmen:
a. Ein Algorithmus zum Hashen von Daten (eine Hash-Funktion), der die zu signierenden Daten auf einen Hash-Wert, d. h. eine Bitfolge fester Länge, reduziert.
Signiert werden dann nicht die Daten selbst, sondern stattdessen jeweils ihr HashWert.
b. Ein asymmetrisches Signaturverfahren, das aus einem Signier- und einem Verifizieralgorithmus besteht. Das Signaturverfahren hängt von einem Schlüsselpaar
ab, bestehend aus einem privaten (d. h. geheimen) Schlüssel zum Signieren
(Erzeugen) und dem dazugehörigen öffentlichen Schlüssel zum Verifizieren (Prüfen) der Signatur.
c. Ein Verfahren zur Erzeugung von Schlüsselpaaren für die einzelnen Teilnehmer.
Geeignete Hash-Funktionen
a. RIPEMD-160
RIPEMD-160 ist eine kryptografische Hash-Funktion, die wie SHA-1 Hash-Werte
mit 160 Bit Länge generiert.
b. SHA-256, SHA-512
SHA-256 und SHA-512 (Secure Hash Algorithm) ist eine kryptografische HashFunktionen, die als Weiterentwicklungen von SHA-1 mit längeren Hash-Werten
arbeiten. Entsprechend der Empfehlung des BSI149 sollten neue Produkte zur
Erstellung von Signaturen SHA-1 nicht mehr verwenden.
Geeignete Signaturalgorithmen
a. RSA
RSA wurde von Rivest, Shamir und Adleman entwickelt. Das RSA-Verfahren ist
das wichtigste asymmetrische Verfahren, auch Public Key Verfahren genannt. Die
Sicherheit basiert auf der Schwierigkeit, große natürliche Zahlen zu faktorisieren.
148. siehe http://www.regtp.de/tech_reg_tele/in_06-02-02-00-00_m/03/
149. siehe http://www.bsi.bund.de/esig/basics/techbas/krypto/
Seite 111
Übliche Längen für den Modulus sind 512, 1024 und 2048 Bit, wobei 512 Bit
Schlüssel nicht mehr empfohlen werden.
b. DSA
Der Digital Signature Algorithm (DSA) ist das Signaturverfahren, das im amerikanischen Digital Signature Standard (DSS) 1991 entwickelt und spezifiziert wurde.
DSA ist ein reiner Signaturalgorithmus (im Gegensatz dazu ermöglicht RSA
sowohl die elektronische Signatur als auch den Schlüsselaustausch). Die USRegierung hat DSS patentiert, die Benutzung ist jedoch frei.
c. DSA-Varianten basierend auf elliptischen Kurven (EC-DSA, EC-KDSA, ECGDSA, Nyberg-Rueppel-Signaturen).
Die Eignung beziehungsweise Ausprägung der anzuwendenden Algorithmen kann
durch die geltenden Standards beeinflusst werden, z. B. spezifiziert ISIS-MTT Teil 6
die für ISIS-MTT gültigen kryptografischen Algorithmen.
9.4.6 Symmetrische Kryptoalgorithmen für die Verschlüsselung
Kryptografische Algorithmen für die Verschlüsselung können auf Daten und / oder
Schlüssel angewendet werden, um diese vertraulich zu übermitteln.
Werden symmetrische Verfahren verwendet, so benutzen diese den gleichen geheimen Schlüssel für die Verschlüsselung und Entschlüsselung. Diese Verfahren sind im
Allgemeinen sehr performant.
RegTP schreibt keine Verschlüsselungsalgorithmen vor, jedoch werden hier die in
ISIS-MTT Teil 6 (Cryptographic Algorithms) festgelegten Algorithmen übernommen.
Im Zweifelsfalle besitzen die Spezifikationen im ISIS-MTT-Standard Gültigkeit. Für die
Ausprägung (Mode / Padding) des jeweiligen Algorithmus wird auf ISIS-MTT Teil 6
verwiesen.
Obligatorisch: Advanced Encryption Standard (AES)
AES150 ist ein symmetrischer Blockchiffre, der Datenblöcke von 128 Bit mit Schlüssellängen von 128, 192 oder 256 Bit verschlüsselt.
Empfohlen: Triple Data Encryption Standard (Triple-DES)
Triple-DES151, auch als 3DES bezeichnet, ist eine dreifache DES-Variante, d. h. ein
symmetrischer Verschlüsselungsalgorithmus mit 168 Bit effektiver Schlüssellänge.
Triple-DES benutzt drei DES-Schlüssel mit je 56 Bit. Das Verfahren gilt als sicher, ist
aber nicht besonders performant.
150. siehe http://csrc.nist.gov/
151. siehe http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf
Seite 112
Anhang A Basisbausteine der BundOnline-Initiative
Die Realisierung der im Rahmen von BundOnline 2005 identifizierten über 400 internetfähigen Dienstleistungen wird durch so genannte Basiskomponenten unterstützt.
Die Basiskomponenten bieten zentral technische Funktionalitäten an, die durch unterschiedliche Dienstleistungen und Behörden genutzt werden können. Sie liefern Technologieplattformen, die – einmal entwickelt – teils identisch oder bedarfsgerecht konfiguriert zur breiten Anwendung in der Bundesverwaltung kommen.
Die Basiskomponenten stellen Funktionalitätsblöcke zur Verfügung, die Bestandteil
sehr vieler Dienstleistungen sind und als Dienste oder Module in die E-GovernmentAnwendungen eingebunden werden. Sie werden in mehreren Stufen realisiert. Somit
werden im Laufe der Zeit immer wieder neue Versionen der Basiskomponenten mit
jeweils erweitertem Funktionsumfang zur Verfügung gestellt.
Für die als obligatorisch gekennzeichneten Geschäftsvorfälle sind die Basiskomponenten bei der Realisierung von E-Government-Anwendungen grundsätzlich einzusetzen. Die vorübergehende Nutzung alternativer Realisierungswege für durch die
Basiskomponenten realisierte Funktionalitätsblöcke soll nur in begründeten Ausnahmefällen erfolgen, wenn dadurch nachträgliche Migrationskosten vermieden werden
können. Im Anhang B auf Seite 173 wird an einem Beispiel gezeigt, wie mehrere
Basiskomponenten in die Prozesse einer Fachanwendung integriert werden können.
Neben den Basiskomponenten, die direkt Teilprozesse von E-Government-Anwendungen übernehmen, werden auch Infrastrukturkomponenten im Rahmen der
Initiative BundOnline 2005 zu Verfügung gestellt. Diese unterstützen die Bildung
eines Intranets für die gesamte Bundesverwaltung. Die Leistungen sind unabhängig
von konkreten E-Government-Anwendungen, aber von grundlegender Bedeutung für
eine behördenübergreifende elektronische Kommunikation.
EfA-Dienstleistungen („Einer für Alle“-Dienstleistungen) unterstützen nicht nur Teilprozesse, wie die Basiskomponenten, sondern erbringen selbst vollständige Dienstleistungen. Dabei handelt es sich um Dienstleistungen, die von mehreren Behörden
gleich oder ähnlich erbracht werden.
Als Ergänzung zu den Basiskomponenten wurden so genannte Kompetenzzentren
eingerichtet. Ihre Aufgabe besteht vornehmlich in der Begleitung der Behörden bei
der Einführung der entsprechenden Basiskomponenten und der Anpassung von
Geschäftsprozessen an den Einsatz von E-Government-Anwendungen.
A.1 Basiskomponente Zahlungsverkehrsplattform („ePayment“)
A.1.1 Einleitung
Das Leistungsangebot der Basiskomponente Zahlungsverkehrsplattform (ZVP)
umfasst derzeit im Wesentlichen die Übernahme von Sollstellungen aus den verschiedenen internetbasierten Fachanwendungen, E-Shops und Vorgangsbearbei-
Seite 113
tungssystemen mittels Web Services, deren Validierung und die Weiterleitung zur
Zahlungsüberwachung (ZÜV) bis hin zur anschließenden haushaltsmäßigen Buchung
im System des Haushaltskassenrechnungswesen (HKR). Dabei kann es sich um
Warenpreise oder auch um Gebühren für Dienstleistungen handeln.
Die Basiskomponente ePayment wird zentral zur Verfügung gestellt. Für die einzelnen Fachanwendungen des Bundes entfallen aufwändige Verfahrensprüfungen. Die
Anbindung der Fachverfahren an das ePayment-System erfolgt über eine verschlüsselte Verbindung mittels Aufruf der zur Verfügung stehenden Web Services.
Ansprechpartner
Herr Volker Walgenbach
ePayment@bff.bund.de
Bundesamt für Finanzen
Friedhofstraße 1
53225 Bonn
Tel. +49 228 406-2905
Fax +49 228 406-2241
Verfügbarkeit der Basiskomponente in seit Juli 2003
Version 2.0
Web-Adresse für Informationen zur
Basiskomponente und zu den Inhalten der Versionen
https://epay.bff-online.de/doku/
Login und Passwort erhalten Sie beim
Ansprechpartner oder unter der E-MailAdresse: ePayment@bff.bund.de
A.1.2 Leistungsbeschreibung
Die Zahlungsverkehrsplattform unterstützt folgende Zahlungsverfahren:
a. Lastschrifteinzugsverfahren,
b. Überweisung,
c. Kreditkarte.
Der Ablauf der einzelnen Verfahren wird in den Geschäftsvorfällen im folgenden
Abschnitt näher beleuchtet.
Die Basiskomponente dient ausschließlich zur einnahmeseitigen Abwicklung von
internetbasierten Transaktionen. Ausgaben werden auf den bisher üblichen Verfahrenswegen durchgeführt. Die im ePayment-System eingehenden Annahmeanordnungen werden automatisiert an das Zahlungsüberwachungsverfahren (ZÜV) weitergeleitet. Dort werden sie als Sollstellungen in üblicher Weise dargestellt.
Nach Abschluss eines Haushaltsjahres werden ausgeglichene Kassenzeichen in die
Historie überführt und stehen nicht mehr aktiv zur Verfügung. Im Falle von Zahlpartnerkonten oder einer Fälligkeit am Ende eines Jahres bleibt die Sollstellung auch im
folgenden Haushaltsjahr bestehen. Micropayments, also das Sammeln von Sollstel-
Seite 114
lungen bis zu einer gewissen Höhe, sind nicht vorgesehen, da die Bundeshaushaltsordnung (BHO) einen sofortigen Einzug der Geldbeträge vorschreibt.
Die Geschäftsprozesse, von denen der Zahlungsvorgang nur ein Baustein ist, müssen aus den Fachanwendungen heraus entwickelt werden. Entsprechend dieser Prozesse ist die Zahlungsverkehrsplattform in das Fachverfahren zu integrieren. Die Projektgruppe ePayment betreibt ein Kompetenzzentrum, das Beratungen rund um das
Thema elektronischer Zahlungsverkehr anbietet. Dazu werden unter anderem Erfahrungen von Pilotprojekten gesammelt und zur Verfügung gestellt.
Eine Referenzimplementierung für die Einbindung der Basiskomponente in Fachverfahren wird im Abschnitt A.1.5 „Schnittstellen“ auf Seite 118 beschrieben.
A.1.3 Geschäftsvorfälle
Sämtliche Geschäftsvorfälle haben die Klassifizierung obligatorisch. E-GovernmentAnwendungen nutzen als Frontend primär den Browser, es sei denn, die umzusetzenden Dienstleistungen sind über Browser nicht sinnvoll abbildbar.
Einige der folgenden Geschäftsvorfälle beinhalten eine Adress- und Bonitätsprüfung.
Teilweise setzt die Basiskomponente auf externe Dienstleister, die Online-Prüfungen
anbieten. Bei der Adressprüfung wird die Existenz einer Adresse sichergestellt. Zur
Bonitätsprüfung gehören beispielsweise eine Plausibilitätsprüfung von Kontonummer
und Bankleitzahl, die Analyse noch ausstehender Rechnungen, das Volumen bezahlter Rechnungen und erfolgte Rückbuchungen. Im Ergebnis können einem Kunden
zum Beispiel höhere Rechnungsbeträge oder die Zahlung nach Lieferung gestattet
werden. Die Fachanwendungen können den Einsatz der Prüfschritte individuell konfigurieren.
Überweisung vor Lieferung
Die Vorauszahlung per Überweisung ist ein sicherer Zahlungsweg und deshalb
besonders bei Zahlvorgängen mit hohen Beträgen geeignet.
a. Registrierung des Kunden bei der Fachanwendung mit E-Mail-Adresse oder
einem anderen eindeutigen Merkmal für die Zustellung der Rechnung
b. Kunde füllt Warenkorb und gibt optional eine Lieferadresse an
c. Fachanwendung stellt dem Kunden die Rechnung zu
d. Entweder zyklisch (z. B. einmal täglich) oder sofort überträgt das Fachverfahren
online die notwendigen Daten für die Sollstellung. Einmal täglich überstellt der
ePayment-Server dem ZÜV-System die Daten aller zu erwartenden Überweisungen.
e. Kunde zahlt die Rechnung
f. Zahlungseingang wird dem ePayment-Server vom ZÜV-System gemeldet
g. Fachanwendung fragt zyklisch (z. B. einmal täglich) beim ePayment-Server die
zuletzt erfolgten Zahlungseingänge ab
h. Fachanwendung liefert Waren oder Dienstleistung aus
Seite 115
Überweisung nach Lieferung
Diese im Versandhandel weit verbreitete Zahlungsart ist für den physikalischen Versand von Produkten oder Dienstleistungen besonders geeignet. Der Einsatz bei elektronischen Downloads muss im Einzelfall geprüft werden.
6. Auslieferung von Waren und Rechnung
1. Kunde registriert sich
Internet
Kunde
Bonitätsprüfung
Fachanwendung
5. Kunde füllt Warenkorb
2. Registrierung
des Kunden
9. Kunde zahlt
Rechnung
7. Übertragung
der Sollstellung
4. Bestätigung der
Registrierung
3. Prüfung der
Kundendaten
11. Abfrage der
Zahlungseingänge
Bank
Bank
€
€
ePayment
8. Übertragung
aller Sollstellungen
HKR / ZÜV
10. Meldung des
Zahlungseingangs
Abbildung A-1: Überweisung nach Lieferung mit der Basiskomponente ePayment
a. Registrierung des Kunden bei der Fachanwendung mit Adressdaten zur Identifizierung und E-Mail-Adresse für die Zustellung der Rechnung
b. Prüfung der Kundendaten
c. Kunde füllt seinen Warenkorb
d. Fachanwendung liefert sofort Waren oder Dienstleistung aus und stellt dem Kunden die Rechnung zu
e. Entweder zyklisch (z. B. einmal täglich) oder sofort überträgt das Fachverfahren
online die notwendigen Daten für die Sollstellung. Einmal täglich überstellt der
ePayment-Server dem ZÜV-System die Daten aller zu erwartenden Überweisungen.
f. Kunde zahlt die Rechnung
g. Zahlungseingang wird dem ePayment-Server vom ZÜV-System gemeldet
h. Fachanwendung fragt zyklisch (z. B. einmal täglich) beim ePayment-Server die
Einzeleinzug durch elektronische Lastschrift
Die Lastschrift ist in Deutschland ein sehr beliebtes Zahlungsmittel und die elektronische Lastschrift ist im Internet weit verbreitet. Das Verfahren ist gut geeignet zur
Bezahlung von einmaligen Dienstleistungen beziehungsweise dem Versand von
Seite 116
Waren. Der Zahlbetrag wird zur Fälligkeit eingezogen. Bei sich wiederholenden Zahlungsvorgängen sollte die Zahlungsart „Wiederholte Lastschrift mit Einzugsermächtigung“ gewählt werden.
Da Benutzer falsche Kontodaten angeben können und die Gefahr einer Rücklastschrift besteht, sind Prüfverfahren unabdingbar. Das Verfahren ist wegen der Risiken
für die Fachanwendung nicht für größere Beträge geeignet. Jede Fachanwendung
legt selbst die Obergrenzen für die verschiedenen Bonitätslevel fest.
a. Registrierung des Kunden bei der Fachanwendung mit Adressdaten zur Identifizierung und Kontodaten
b. sofortige Prüfung aller Kundendaten
d. Fachanwendung liefert (sofort oder nach Zahlungseingang) Waren oder Dienstleistung aus und stellt dem Kunden die Rechnung zu
e. ZÜV-System zieht einmal täglich bzw. zur Fälligkeit die Beträge ein
f. Zahlungseingang wird dem ePayment-Server vom ZÜV-System gemeldet
g. Fachanwendung fragt zyklisch (z. B. einmal täglich) beim ePayment-Server die
Wiederholte Lastschrift mit Einzugsermächtigung
Das Verfahren ist besonders geeignet zum Einziehen von Gebühren für wiederkehrende Dienstleistungen. Es ist eine relativ sichere Zahlungsart, da vom Kunden eine
unterschriebene Lastschrifteinzugsermächtigung vorliegt und diese im Falle einer
Rücklastschrift der Bank vorgelegt werden kann. Jede Fachanwendung legt selbst die
Obergrenzen für die verschiedenen Bonitätslevel fest.
Weil das Ermächtigungsverfahren bei der ersten Benutzung durch einen Kunden
mehrere Tage dauert, sollte die Fachanwendung einen Warenkorb über einen längeren Zeitraum speichern können.
a. Registrierung des Kunden bei der Fachanwendung, um später die Einzugsermächtigung dem Kunden zuordnen zu können
b. Kunde füllt seinen Warenkorb
c. liegt der Fachanwendung bereits eine Einzugsermächtigung vor, folgt Punkt f
d. Kunde erteilt per Post einmalig eine Einzugsermächtigung
e. Kunde erhält per Post einmalig seine PIN
f. Kunde benutzt PIN zur Bestätigung des Zahlungsvorgangs für den Warenkorb
g. Fachanwendung liefert (sofort oder nach Zahlungseingang) Waren oder Dienstleistung aus und stellt dem Kunden die Rechnung zu
h. Betrag wird über das Konto des Bundes vom Kundenkonto eingezogen
i. Zahlungseingang wird dem ePayment-Server vom ZÜV-System gemeldet
j. Fachanwendung fragt zyklisch (z. B. einmal täglich) beim ePayment-Server die
Seite 117
Kreditkarte
a. Registrierung des Kunden bei der Fachanwendung; Adressdaten sind für dieses
Zahlverfahren nicht zwingend erforderlich
b. Bei sofortiger Auslieferung der Ware kann eine Adressverifizierung durchgeführt
werden.
d. Fachanwendung fragt die Kreditkartendaten einschließlich des Card Verification
Code (CVC) ab und überstellt diese zwecks Belastung der Kreditkarte an das
ePayment-System.
e. Fachanwendung liefert (sofort oder nach Zahlungseingang) Waren oder Dienstleistung aus und stellt dem Kunden die Rechnung zu
f. ePayment- und ZÜV-System gemeinsam betreiben das Settlement, also den Einzug des Geldes
g. Zahlungseingang wird dem ePayment-Server vom ZÜV-System gemeldet
h. Fachanwendung fragt zyklisch (z. B. einmal täglich) beim ePayment-Server die
A.1.4 Roadmap
Die Version 2.0 der Basiskomponente Zahlungsverkehrsplattform steht produktiv zur
Verfügung. Größere Erweiterungen sind zurzeit nicht geplant. Pflege, Wartung und
Betrieb werden vom zugehörigen Kompetenzzentrum sichergestellt. Momentan läuft
die Anbindung von E-Government-Fachanwendungen an das ePayment-System. In
diesem Rahmen findet eine kontinuierliche Weiterentwicklung der Basiskomponente
zur Berücksichtigung neuer Anforderungen statt.
A.1.5 Schnittstellen
Die Zahlungsverkehrsplattform ist mit Hilfe zentraler Web Services realisiert. Dies
sind bisher im Einzelnen:
a. Kundendatenpflege
b. Banksuche
c. Überweisungsverfahren
d. Lasteinzugsverfahren
e. Kreditkartenverfahren
f. Paypage
g. Report
Die Projektgruppe stellt Referenzimplementierungen u. a. in Java zur Verfügung, mit
der die Basiskomponente in eine lokale Fachanwendung oder E-Shop integriert werden kann. Die Implementierung beinhaltet alle erforderlichen SOAP-Schnittstellen
inklusive der Serialisierer und Deserialisierer. Zur Realisierung wurden ausschließlich
Seite 118
Open-Source-Bibliotheken verwendet. Eine Integration in kommerzielle ShopSysteme, wie Intershop Infinity, sollte möglich sein.
Weiterführende Informationen befinden sich unter der Web-Adresse, die in der Einleitung genannt wurde.
A.2 Basiskomponente Datensicherheit („Virtuelle Poststelle“)
A.2.1 Einleitung
Kernelement der Basiskomponente Datensicherheit ist die Virtuelle Poststelle (VPS),
deren Aufgabe in der Unterstützung der E-Government-Anwendungen bei Abwicklung der sicheren, nachvollziehbaren und vertraulichen Kommunikation zwischen
zwei Kommunikationspartnern im Rahmen des E-Government-Angebotes behördlicher Dienstleistungen liegt. Sie soll u. a. zu einer wesentlichen Entlastung aller Beteiligten von teilweise komplexen und fehleranfälligen kryptografischen Operationen führen, die mit einer durch elektronische Signaturen und Verschlüsselung gesicherten
Kommunikation häufig noch verbunden sind.
Ein weiteres zentrales Element der Virtuellen Poststelle ist die Verifikationskomponente. Sie erlaubt es internen und externen Benutzern, die Signatur von Dokumenten
zu verifizieren. Dazu werden Programmbibliotheken der Virtuellen Poststelle genutzt.
Das Interface zum Benutzer wird auf Basis einer client-server-basierten Anwendung
realisiert.
Ansprechpartner
Herr Dr. Christian Mrugalla
egov@bsi.bund.de
Bundesamt für Sicherheit in der
Informationstechnik
Postfach 200363
53133 Bonn
Tel. +49 1888 9582-232
Fax +49 1888 9582-405
Vorhandensein der Basiskomponente in Version 2.0
Mai 2005
Web-Adresse für Informationen zur Basiskom- http://www.bsi.bund.de/fachthem/
egov/vps.htm
ponente und zu den Inhalten der Versionen
Die Virtuelle Poststelle stellt als zentrales Security-Gateway und KommunikationsServer über standardisierte Schnittstellen Sicherheitsdienste für die gesicherte Kommunikation zwischen Behörden und externen Kommunikationspartnern bereit, wie
anderen Behörden, Bürgern und der Wirtschaft. Hierzu unterstützt die Virtuelle Poststelle die Fachverfahren bei der Gewährleistung der nachfolgenden Sicherheitsziele:
Seite 119
a. Vertraulichkeit – der übertragenen und gespeicherten Informationen,
b. Integrität – der übertragenen und gespeicherten Informationen,
c. Verbindlichkeit – Authentizität und Nachweisbarkeit,
d. Authentifizierung – Unterstützung für web-basierte und andere Anwendungen mit
verschiedenen Authentifizierungsverfahren,
e. Monitoring und Auditing.
Backend-Anwendung
VPS
Wirtschaft
WebDokumente
Internet
Bürger
@
§
Web- / E-Mail-Anwendung
€
E-Mails
Behörde
Security Server
WebGateway
Ver- / Entschlüsseln
DokumentGateway
Bearbeitung
steuern
Signatur prüfen /
erstellen
Zeitstempel prüfen /
erstellen
Authentisierung prüfen
E-MailGateway
Behörde
Zentrale Dienste
z.B. Viren- und Content-Prüfung,
Zeit-Server
Sachbearbeiter
Internet
Zentrales
OCSP / CRL Relay
Externe Dienste
z.B. Trust Center, PKI-1, PIN / TAN,
Zeitstempeldienst
Abbildung A-2: Prinzip der Basiskomponente „Datensicherheit“
Über die angebotenen Schnittstellen werden den E-Government-Dienstleistungen
einheitliche und – soweit dies möglich ist – automatisch nachfolgende Sicherheitsfunktionen zur Verfügung gestellt:
a. Ver- und Entschlüsselung,
b. Signaturprüfung und -erstellung,
c. Zeitstempelprüfung und -erstellung,
d. Sicherheitsprüfungen wie Viren- oder Content-Prüfung von E-Mails und Dokumenten,
e. Authentifizierung auf Basis verschiedener Credentials,
f. Prüfung der Sicherheitsmerkmale eines Dokuments,
g. Administration der Virtuellen Poststelle.
Seite 120
Für einige der genannten Funktionen greift die Virtuelle Poststelle auf zentrale Dienste der Infrastruktur oder auf externe Dienste zurück, siehe Abbildung A-2 „Prinzip der
Basiskomponente „Datensicherheit““ auf Seite 120.
Neben der indirekten E-Mail-Kommunikation mit einer zentralen Adresse in den
Behörden unterstützt die Basiskomponente auch eine strikte Ende-zu-Ende-Sicherheit mit einzelnen Sachbearbeitern. Eingehende und ausgehende E-Mails werden
dann unverändert durchgeleitet und nicht ent- beziehungsweise umgeschlüsselt. Deshalb sind einzelne Leistungsmerkmale der Virtuellen Poststelle flexibel deaktivierbar.
Entsprechend den unterschiedlichen Anforderungen der verschiedenen Fachverfahren einer Bundesbehörde stellt das zentrale Security-Gateway Sicherheitsmechanismen und Algorithmen unterschiedlicher Stärke zur Verfügung. Darüber hinaus sind
die bei Bürgern und in der Wirtschaft verbreiteten Standards und Verfahren angebunden, u. a. ISIS-MTT, SPHINX, PGP (in Versionen, die X.509-Zertifkate unterstützen)
und OSCI.
Die Anbindung externer Trust Center an die Virtuelle Poststelle erfolgt über ein OCSP
/ CRL-Relay. Diese Komponente soll an einer Stelle zentral für alle Bundesbehörden
bereit stehen, sie kann aber auch lokal in der Behörde betrieben werden. Das zentrale Relay hat aus Sicht der einzelnen Behörden den Vorteil, dass nur eine einheitliche Schnittstelle für Zertifikatsprüfungen existiert.
In Erweiterung des ursprünglichen Konzepts bietet die Virtuelle Postelle einen so
genannten OSCI-Enabler an, der in Form einer verteilten Architektur die OSCI-Kommunikation auf allen drei im Protokoll vorgesehen Ebenen (Client – Intermediär –
Backend) unterstützt152.
Vor dem Einsatz der Basiskomponente Datensicherheit ist jede Fachanwendung
dafür verantwortlich, eine Schutzbedarfsklassifikation durchzuführen. Hierbei ist das
Kompetenzzentrum Datensicherheit153 beratend tätig. Beim Kompetenzzentrum
wurde auch eine Einführungsstrategie für die Virtuelle Poststelle entwickelt, die kontinuierlich aktualisiert wird.
Sämtliche Geschäftsvorfälle haben die Klassifizierung empfohlen.
Zu jedem Geschäftsvorfall gehört die Dokumentation der relevanten Aktionen der Virtuellen Poststelle in einem Laufzettel, der als XML-Datei mit übertragen wird. Der
Zugriff auf die Daten in gegebenenfalls außerhalb der Virtuellen Poststelle existierenden Posteingangs- und Postausgangsbüchern bleibt Administratoren mit Sonderrollen (Revision) vorbehalten. Die Erstellung dieser „Bücher“ ist nicht Aufgabe der Virtuellen Poststelle.
152. zur Erläuterung der OSCI-Fachtermini siehe http://www.osci.de/
153. siehe Abschnitt A.10.2 „Kompetenzzentrum Datensicherheit“ auf Seite 169
Seite 121
Behörde empfängt Dokument per E-Mail
a. externer Mail-Benutzer verschickt eine E-Mail an internen Empfänger
b. eingehende E-Mail wird geprüft und weitergeleitet
i. ggf. Entschlüsselung
ii. ggf. Prüfung von Signatur und Zeitstempel der E-Mail
iii. Virenprüfung des Inhalts der E-Mail
iv. ggf. Weiterverschlüsselung
c. ggf. Bedienung einer Schnittstelle zum Eintrag ins Posteingangsbuch
d. Ausgang einer E-Mail an interne Empfänger; ggf. Vertretungsregeln beachten
e. ggf. Zustellbestätigung an den Absender
Behörde empfängt Dokument per Web-Browser oder Anwendung
a. externer Browser-Nutzer oder Anwendung stellt ein Dokument ein
b. Authentifizierung aufgrund der Signatur des Dokuments
c. eingehendes Dokument wird geprüft und weitergeleitet
ii. ggf. Prüfung von Signatur und Zeitstempel des Dokuments
iii. Virenprüfung des Dokuments
iv. ggf. Weiterverschlüsselung
d. ggf. Übergabe zum Eintrag in ein Posteingangsbuch
e. Übergabe des Dokuments an Anwendung
Behörde sendet Dokument per E-Mail
a. interner Mail-Benutzer verschickt eine E-Mail an externen Empfänger
b. ausgehende Mail wird geprüft und weitergeleitet
ii. ggf. Prüfung von Signatur und Zeitstempel der E-Mail
iii. Virenprüfung des Inhalts der E-Mail
iv. Zeitstempel erstellen
v. E-Mail signieren oder ggf. Weiterverschlüsselung
c. ggf. Übergabe zum Eintrag in ein Postausgangsbuch
d. Versand der Mail an den externen Empfänger
e. ggf. Zustellbestätigung an den Absender
Behörde überträgt Dokument per Web-Browser oder Anwendung
a. interne(r) Web-Benutzer oder Anwendung stellt Dokument für externen Empfänger ein
b. ausgehendes Dokument wird geprüft und weitergeleitet
Seite 122
ii. ggf. Prüfung von Signatur und Zeitstempel des Dokuments
iv. Zeitstempel erstellen
v. Dokument signieren oder ggf. Weiterverschlüsselung
c. ggf. Übergabe zum Eintrag in ein Postausgangsbuch
d. Übergabe des Dokuments an Anwendung
Interne Bearbeitung eines Dokuments
a. interne(r) Browser-Nutzer oder Anwendung übergibt ein Dokument zur Bearbeitung
b. eingehendes Dokument wird entsprechend beigefügter Regeln bearbeitet
i. ggf. Entschlüsselung / Verschlüsselung
ii. ggf. Prüfung / Erstellung einer Signatur
iii. ggf. Prüfung / Erstellung eines Zeitstempels
iv. ggf. Virenprüfung des Dokuments
c. Übergabe des Dokuments an interne(n) Browser-Nutzer oder Anwendung
Verifizieren eines signierten und ggf. zeitgestempelten Dokuments
a. interne(r) oder externe(r) Browser-Nutzer bzw. Anwendung übergibt ein Dokument
zur Prüfung
b. Anwendung überträgt Signatur, Hash-Wert, Zertifikat und ggf. Zeitstempel an VPS
c. VPS verifiziert das Dokument
i. mathematische Prüfung der Signatur
ii. ggf. Prüfung des Zeitstempels
iii. Prüfung der Zertifikatskette
iv. Prüfung des Wurzelzertifikats
d. Prüfergebnis wird der Anwendung übergeben (ggf. geschützt)
e. Prüfergebnis wird ggf. dem Nutzer von Browser oder Anwendung angezeigt
Authentifizierung eines internen oder externen Nutzers von Browser bzw. Anwendung
a. Browser-Nutzer übergibt notwendige Daten zur Authentifizierung
b. Anwendung überträgt zu prüfende Credentials an VPS
c. VPS prüft die Credentials auf
i. Korrektheit
ii. Gültigkeit
d. Prüfergebnis wird der Anwendung übergeben (ggf. geschützt)
e. Prüfergebnis wird dem Nutzer von Browser oder Anwendung angezeigt
Seite 123
Behörde empfängt mehrere Dokumente mit einer E-Mail
a. externer Mail-Benutzer verschickt signierte E-Mail an internen Empfänger mit
mehreren jeweils signierten und verschlüsselten Attachments
b. eingehende E-Mail wird entsprechend Geschäftsvorfall 1 von VPS überprüft und
an internen Empfänger übergeben
c. interner Empfänger zerlegt die E-Mail mittels einer Anwendung, die jedes Dokument einzeln der VPS übergibt
d. VPS prüft jedes Dokument
i. Entschlüsselung
ii. Prüfung von Signatur und Zeitstempel des Dokuments
e. VPS übergibt jeweils das Ergebnis der Signaturprüfung und das entschlüsselte
Dokument der Anwendung
A.2.4 Einsatzszenarien
Durch den offenen Architekturansatz kann die Virtuelle Poststelle in unterschiedlichen
Einsatzszenarien genutzt werden:
Szenario 1: Kommunikation per E-Mail (SMTP)
Ist gut geeignet für „formlose“ – also z. B. nicht formulargebundene – Kommunikation
mit einem offenen Kreis von Kommunikationspartnern. Die Absicherung setzt allerdings immer voraus, dass die Kommunikationspartner der Behörde über die dazu
erforderliche Technik verfügen (insbesondere ein zusätzlich zu installierendes Plug-In
für qualifizierte Signaturen in E-Mails).
Szenario 2: Kommunikation über OSCI-Web-Mail
Ist von der Bedienung her ähnlich einfach wie die SMTP-E-Mail, bietet jedoch die
OSCI-spezifischen Verschlüsselungs- und Signaturverfahren bis hinauf zur qualifizierten Signatur. Dieses Szenario stellt nur minimale technische Anforderungen an
Behörde und Kunden, setzt jedoch voraus, dass die Nachrichten „manuell“ versendet
und geöffnet werden. Die auf Kunden- und Behördenseite benötigte Client-Software
lässt sich unentgeltlich aus dem Internet herunterladen.
Szenario 3: OSCI-Kommunikation mit automatisierter Anbindung an Fachverfahren
Auch hier stehen alle OSCI-Mechanismen zur Verfügung. Im Gegensatz zu Szenario
2 können die Nachrichten behördenseitig jedoch automatisiert in Hintergrundsysteme
übernommen werden. Dieses Szenario, das behördenseitig technisch höhere Anforderungen als Szenario 2 stellt, ist ideal geeignet für die Kombination von Formularsystemen o.ä. mit OSCI-Mechanismen. Auch hier können die Kunden die erforderliche
Software unentgeltlich aus dem Internet herunterladen.
Seite 124
Szenario 4: Kommunikation über Client-Server-Fachverfahren ohne OSCI-Nutzung
In diesem Szenario nutzt ein bestehendes oder neues Fachverfahren die Virtuelle
Poststelle als Kryptografie-Server, ohne dass eine Anpassung auf OSCI erfolgen
muss. Dieses Szenario ist vor allem dann eine Option, wenn bereits etablierte Kommunikationsanwendungen ohne große „sichtbare“ Änderungen die Virtuelle Poststelle
nutzen sollen oder die Nutzung von OSCI nicht möglich oder nicht durchsetzbar ist
(z. B. bei internationalen Verfahren).
Szenario 5: Nutzung der Virtuellen Poststelle durch Backend-Systeme
Über die XML-basierte Schnittstelle „Document Interface“ können beliebige Fachverfahren im Hausnetz der Behörde auf die Dienste des VPS-Kernsystems zugreifen.
Die Virtuelle Poststelle fungiert in diesem Szenario als „Krypto-Engine“. Hierdurch
können sich alle internen IT-Systeme mit Bedarf an kryptografischen Funktionalitäten
aus der gleichen „Quelle“ bedienen. Ein „Sicherheitsgefälle“ durch unterschiedliche
Standards und Verfahren wird verhindert.
A.2.5 Roadmap
Anfang
2004
Release 1.0 der VPS ist bei BundOnline-2005-Pilotanwendern im Einsatz
OCSP / CRL-Relay
Verifikations- und Authentifizierungsmodul (eingeschränkter Leistungsumfang)
(rudimentäres) Kernsystem mit Nutzung von Governikus-1.1-Komponenten
JULIA MailOffice („Stand-alone“)
2. Quartal
2004
Release 1.1 bei Bundesbehörden im Einsatz
erweiterte Funktionalität des Kernsystems, Authentisierung auch
ohne OSCI
OSCI-Enabler auf Basis OSCI 1.2
JULIA MailOffice mit Nutzung des OCSP / CRL-Relays
Seit Mai
2005
Release 2.0 ist für alle BundOnline-2005-Dienstleistungen bei Bundesbehörden einsetzbar
Umsetzung der VPS entsprechend des Fachkonzepts
Betrieb des JULIA MailOffice mit dem Kernsystem der VPS oder
„Stand-alone“ möglich
Aktuelle Informationen finden Sie unter der in der Einleitung genannten Web-Adresse.
Seite 125
Neben dem Fachkonzept der Virtuellen Poststelle sind die Schnittstellen in einer
detaillierten Spezifikation154 veröffentlicht. Im genannten Dokument werden ausführlich beschrieben:
a. das Document Interface des Kernsystems der Virtuellen Poststelle, über welches
Mail- und Web-Anwendungen mit dem VPS-Kernsystem kommunizieren. Diese
Schnittstellenspezifikation soll Software-Architekten und Programmierer in die
Lage versetzen, die Dienste des VPS-Kernsystems für die eigenen Anwendungen
zu nutzen. Dazu ist es nötig, aus den eigenen Anwendungen heraus die Schnittstellen des Document Interface korrekt aufzubauen (Eingangsseite DIDocument)
und die Response des VPS-Kernsystems entsprechend zu interpretieren (DIResult).
b. die Schnittstelle des Virenscanner-Stubs. Diese Spezifikation soll es Systemintegratoren und / oder Herstellern von Anti-Viren-Systemen ermöglichen, die Services solcher Produkte dem Kernsystem der Virtuellen Poststelle zugänglich zu
machen.
Hinsichtlich der unterstützten Kommunikationsstandards und -protokolle gilt für die
Virtuelle Poststelle:
a. Für die Kommunikation mit Mail-Anwendungen kommen die Protokolle MIME, S/
MIME gekapselt in XML zum Einsatz. Ausgetauscht werden die Daten über den
Java Message Service (JMS).
b. Mit der Authentisierungskomponente kommuniziert man über ein XML-basiertes Protokoll, das ebenfalls über JMS transportiert wird.
c. Auch bei der Verifikationskomponente kommen ein XML-basiertes Protokoll und
JMS zum Einsatz.
d. Für den Zugriff auf Directory Services (interne Benutzer, externe Benutzer, Trust
Center) wird als Protokoll LDAP eingesetzt. Der Transport erfolgt über Secure
Sockets Layer (SSL).
e. Die Anbindung des OCSP / CRL-Relays an das VPS-Kernsystem erfolgt über das
innerhalb der Initiative Web Services Security entwickelte Protokoll XKMS v2155.
Hierdurch spielt es für den Nutzer des Kernsystems keine Rolle, ob der betreffende Verzeichnisdienst Online-Auskünfte nach OCSP oder lediglich Sperrlisten
herausgibt. Sämtliche – in der Praxis oft sehr komplexe – Details in der Ausprägung der jeweiligen Protokolle werden ebenso wie die IP-Adressen der Verzeichnisdienste in der Administration des Relays verwaltet.
154. siehe http://www.bsi.bund.de/fachthem/egov/vps_2.htm
155. siehe „XML Key Management Specification (XKMS) v2” auf Seite 110
Seite 126
A.3 Basiskomponente Portal
A.3.1 Einleitung
Die Basiskomponente Portal „bund.de – Verwaltung Online“ ist der zentrale Zugang
zu den elektronischen Dienstleistungen und Informationsangeboten der Verwaltung
im Internet. Unter dem Motto „Ein Portal – viele Behörden – alle Inhalte“ sind die
Behörden und Einrichtungen des Bundes verpflichtet, ihre Behördendaten („Behördensteckbrief“) im Portal bund.de einzustellen, ihre E-Government-Dienstleistungen
im Portal zu verlinken und grundsätzlich alle Formulare, geeignete Stellenangebote,
Ausschreibungen und Veräußerungen im Portal bekannt zu machen. Mit mehreren
Bundeseinrichtungen und Ländern bestehen Datenkooperationen. bund.de ist aktiv
im Verbund der E-Government-Portale von Ländern, Kommunen und Bund156 und im
Editorial Board des EU-Partnerportals „Europa für Sie“157 beteiligt.
Über ein verteilt zugreifbares Content Management System können die Informationen
von den Behörden selbstständig und bei Bedarf mit Unterstützung der zentralen Portalredaktion veröffentlicht und aktuell gehalten werden.
Das Portal hält getrennt für die Zielgruppen „Bürgerinnen und Bürger“, „Wirtschaft und
Wissenschaft“ sowie „Verwaltung und Institutionen“ alle Internetangebote und Dienstleistungen, Adressen und weitere Informationen zur Aufbauorganisation der Bundesbehörden vor. Über das Portal sind die E-Government-Angebote von Bund, Ländern,
Kommunen und EU im Internet erreichbar.
Der Informationsumfang und die Nutzerfreundlichkeit des Portals, die Zahl der zentral
zur Verfügung gestellten Dienstleistungen und die Schnittstellen des Portals werden
kontinuierlich erweitert.
Organisatorischer Ansprechpartner
Herr Andreas Polster
pgbo2005@bmi.bund.de
Projektgruppe BundOnline 2005
Bundesallee 216-218
10179 Berlin
Tel. +49 1888 681-4318
Fax +49 1888 681-54318
Ansprechpartner der Portalredaktion
Frau Katja Gajetzki
redaktion-portal@bva.bund.de
Bundesverwaltungsamt
Barbarastr. 1
50735 Köln
Tel. +49 1888 6358 1720
156. http://www.deutschland-online.de/Vorhaben/vorhaben2.htm
157. http://europa.eu.int/youreurope/index_de.html
Seite 127
Technischer Ansprechpartner
Herr Thomas Schubert
thomas.schubert@bva.bund.de
Barbarastr. 1
50735 Köln
Tel. +49 1888 358-1730
Fax +49 1888 358-3899
Verfügbarkeit der Basiskomponente / seit dem 21. März 2001 / 18. Mai. 2005
letzter Relaunch
http://www.bund.de/
http://www.wms.bundonline.bund.de/
Die zugrunde liegende Technik des Portals ist die Basiskomponente CMS158 der
Initiative BundOnline 2005 (Redaktionssystem CAP 4.1 von CoreMedia) und eine
Suchmaschine von FAST. Die Pflege der Datenbestände von bund.de geschieht
durch dezentral arbeitende Lokalredakteure und die zentrale Portalredaktion im Bundesverwaltungsamt. Die redaktionelle Hoheit der darzustellenden Informationen liegt
dabei immer bei der jeweiligen Behörde.
Die Realisierung des Portals ist in mehrere Ausbaustufen gegliedert und befindet sich
derzeit in der dritten von drei geplanten Ausbaustufen:
Ausbaustufe 1
Die erste Ausbaustufe bietet seit der CeBIT im März 2001 die Kernaufgaben „Suchen“
und „Finden“ an. Deshalb präsentiert sich das Portal den Internetnutzern in der vertrauten Gestalt eines Katalogs mit Suchmaschine.
Der Katalog hilft beim Auffinden der Informationsangebote und Dienstleistungen in
Form von kommentierten Links, die nach Themen gegliedert sind. Die verteilt
gepflegte Behörden-Datenbank umfasst die obersten Verfassungsorgane, alle Bundesbehörden und bedeutende institutionelle Zuwendungsempfänger, wie z. B. große
Bibliotheken, Museen und Forschungseinrichtungen. Die Bundesländer sind mit ihren
Verfassungsorganen, der obersten Verwaltungsebene und gegebenenfalls weiteren
Behörden vertreten, die kommunale Ebene mit den Spitzenverbänden und den großen Städten.
Die zentrale Volltextsuche basiert auf einem Suchindex, der alle Behördenangebote
umfasst. Über die Geosuche können sich Benutzer die Standorte von Behörden in
Karten anzeigen lassen. In verschiedenen Rubriken des Portals besteht die Möglichkeit, sich für ein E-Mail-Abonnement registrieren zu lassen. Nach der Einstellung
158.
siehe Abschnitt A.5 „Basiskomponente Content Management System“ auf Seite 136
Seite 128
neuer Informationen über das Portal-Redaktionssystem werden die Meldungen sofort
auch per E-Mail-Versand publiziert.
Benutzer können Anfragen an Bundesbehörden über ein Kontaktformular, per E-Mail,
Fax oder telefonisch stellen. Die Portalredaktion beantwortet die Anfragen oder leitet
sie zur Beantwortung an die zuständigen Behörden weiter.
Ausbaustufe 2
Im Zentrum der zweiten Ausbaustufe stand die Umsetzung der Verordnung zur
Schaffung barrierefreier Informationstechnik (BITV), die zum 24. Juli 2002 in Kraft
getreten ist. Zur CeBIT im März 2003 konnte das Portal der Bundesverwaltung
www.bund.de barrierefrei geschaltet werden.
Zusätzlich zur Überarbeitung des Portals zur Umsetzung der BITV wurde das Angebot der zentralen Dienstleistungen ausgebaut: Im Jahr 2002 wurden u. a. die wichtigsten Formulare der Bundesverwaltung über das neue Online-Formular-Center des
Portals159 zur Verfügung gestellt. Jobbörse, Veräußerungen und Ausschreibungen
erhielten neue Funktionen. Mit der Gemeindesuche konnten alle wichtigen Daten auf
kommunaler Ebene in interaktiver Form bereitgestellt werden.
Ausbaustufe 3
In der Ausbaustufe 3 wurde das Portal im September 2004 auf die Basiskomponente
CMS der Initiative BundOnline 2005 migriert und damit die Grundlage für die konzeptionelle Weiterentwicklung von bund.de geschaffen.
Nach dem erfolgreichen Relaunch im Mai 2005 bietet das Portal eigene Einstiegsseiten für die Zielgruppen Bürgerinnen & Bürger, Wirtschaft & Wissenschaft sowie Verwaltung & Institutionen. Neben dieser neuen Angebotsstruktur ist die Seite durch ein
neues Design, eine verbesserter Navigationsstruktur und neuen Funktionen noch
anwenderfreundlicher und effektiver geworden. Bis zum Ende des Jahres 2005 werden die Portalinhalte im Dialog mit den Nutzern weiter optimiert sowie das Portal um
weitere Angebote und Funktionen erweitert. Alle im Zuge der Initiative BundOnline
2005 umgesetzten öffentlichen elektronischen Dienstleistungen des Bundes sind auf
dem Dienstleistungsportal des Bundes vollständig abgebildet und recherchierbar.
Dem Bund und der öffentlichen Verwaltung steht mit dem Portal bund.de eine
gemeinsame Online-Plattform für die weite Verbreitung ihrer Dienstleistungen, Fachinformationen und Kontaktdaten zur Verfügung. Die folgenden Geschäftsvorfälle können als Anhaltspunkte zur Einsatzentscheidung des Portals und seiner Funktionen
dienen.
159.
siehe Abschnitt A.4 „Basiskomponente Formularserver“ auf Seite 132
Seite 129
Pflege der zentralen Datenbank der Behörden-Stammdaten (Behördenname, Abkürzung, Anschriften, Web- und E-Mail-Adressen, Standorte, Aufgaben, Geschäftsbereich) sowie der Adress- und des Abkürzungsverzeichnisse des Bundes
a. Die zu veröffentlichenden Stamm- und Verzeichnisdaten der Behörden werden
erstellt.
b. Die Einstellung in das Portal erfolgt über das Portal-Redaktionssystem.
Dieser Geschäftsvorfall ist für den Bund obligatorisch. Die doppelte Pflege von
Behördenanschriften im Portal und im IVBB-Verzeichnisdienst ist durch einen Export
der Daten auf XML-Basis und die Bereitstellung zur Aktualisierung des IVBB-Verzeichnisses abgelöst.
Pflege der Online-Dienstleistungen der Behörden
a. Die zu veröffentlichenden Informationen über Dienstleistungen werden erstellt.
Dieser Geschäftsvorfall ist für den Bund obligatorisch.
Pflege der zentralen Informationsdienste (Formulare, Stellenangebote, Ausschreibungen und Veräußerungen)
a. Die zu veröffentlichenden Angebote werden erstellt.
b. Die Einstellung in das Portal erfolgt über das Portal-Redaktionssystem oder durch
einen standardisierten Datenimport von Sammelstellen
Dieser Geschäftsvorfall ist für den Bund obligatorisch.
Pflege des Angebots aktueller Informationen
a. Aktuelle Informationen werden zur Veröffentlichung bereitgestellt oder durch die
Redaktion erstellt.
Dieser Geschäftsvorfall ist für den Bund empfohlen.
Pflege der Informationsangebote BundOnline 2005
a. Informationen über BundOnline und den Fortschritt der Initiative werden erstellt.
Dieser Geschäftsvorfall ist für den Bund empfohlen.
Pflege der Gemeindedaten und der Geoverortung von Adressen
a. Informationen über Städte, Kreise und Gemeinden und Geoverortungen werden
bereitgestellt.
b. Die Einstellung in das Portal erfolgt über eine Routine des Portal-Redaktionssystems.
Da die Zielgruppen dieses Geschäftsvorfalls keine Bundesbehörden sind, entfällt eine
Klassifizierung.
Seite 130
A.3.4 Roadmap
2. Quartal 2005
Relaunch des Portals mit neuem Design, neuer Struktur und
neuer Navigation; Realisierung der Schnittstelle zum Virtuellen
Arbeitsmarkt der Arbeitsagenturen
3. Quartal 2005
Realisierung der Schnittstelle zur eVergabe sowie zu
www.bundesliegenschaften.de
4. Quartal 2005
Konzeptionelle und inhaltliche Erweiterungen der Zielgruppenangebote
Die vorhandenen Schnittstellen basieren auf den Import- und Exportmöglichkeiten der
Basiskomponente CMS (Government Site Builder) oder werden als Projektlösung
implementiert.
Web Services
Die Geoverortung einer gesendeten Adresse steht als Web Service einem eingeschränkten Nutzerkreis bereit. Elektronische Ausschreibungen werden künftig von
einen Web Service der e-Vergabe übernommen.
Datenexport
Im Redaktionssystem sind Steuerungsmöglichkeiten für den Datenexport implementiert, über die ein Portalredakteur Datensätze exportieren kann. Die Exportfunktionalitäten schließen ein:
a. Die Portalredakteure können das Anschriftenverzeichnis als XML- oder CSV-Datei
exportieren.
b. Das gesamte Anschriftenverzeichnis auf bund.de kann als PDF heruntergeladen
(exportiert) werden.
X.500-Export
Behördenanschriften werden dem IVBB-Verzeichnisdienst im CSV-Format zum
Import über dessen X.500-Schnittstelle zur Verfügung gestellt.
Datenimport
Es besteht die Möglichkeit des Datenimports von Behördenstammdaten über ein
XML-Format für Behördeneinträge und Adressen. Des Weiteren besteht ein Import
von freien Stellen des öffentlichen Dienstes bei der Bundesagentur für Arbeit über ein
proprietäres CSV-Format.
Seite 131
Basiskomponente Formularserver
Die Basiskomponente Formularserver umfasst in der ersten Ausbaustufe das Formular-Center im Portal bund.de. Einzelheiten sind im folgenden Abschnitt A.4 zu finden.
A.4 Basiskomponente Formularserver
A.4.1 Einleitung
Die Basiskomponente Formularserver umfasst das Formular-Center im Portal
bund.de und das Formular-Management-System (FMS). Über das Formular-Center
wird der Zugriff auf mehr als 500 Formulare des Bundes ermöglicht. Mit dem Formular-Management-System können auf Basis der den Behörden zur Verfügung gestellten Software FormsForWeb® von Lucom mittels eFormularen Verwaltungsprozesse
medienbruchfrei über das Intra-/Internet bearbeitet werden. Das FMS kann dabei
sowohl zentral für mehrere Behörden als auch dezentral für einzelne Online-Dienstleistungen eingesetzt werden.
Organisatorische Ansprechpartnerin
Frau Barbara Jost
Bundesallee 216-218
10179 Berlin
Tel. +49 1888 681-4124
Fax +49 1888 681-54124
Formular-Center
Herr Thomas Schubert
thomas.schubert@bva.bund.de
Barbarastr. 1
50735 Köln
Tel. +49 1888 358-1730
Fax +49 1888 358-3899
Technischer Ansprechpartner Formular-Management-System
Markus Schulmeyer
markus.schulmeyer@zid-f.bfinv.de
Zentrum für Informations- und Datentechnik
der Bundesfinanzverwaltung (ZID)
Wilhelm-Fay-Straße 11
65936 Frankfurt am Main
Tel: 069 20971 447
Fax: 069 20972 554
Seite 132
Verfügbarkeit Formular-Center
zielgruppenspezifischer Zugang zu den Formularen unter http://www.bund.de/ (online
seit März 2002)
Verfügbarkeit Formular-Management-System
seit 1. Quartal 2005 Nutzung der FMS-BasisSoftware möglich
ab Juli 2005 Referenzimplementierung des
FMS abgeschlossen
Web-Adressen für Informationen zur
Basiskomponente und zu den Ausbaustufen
http://www.formulare-bmf.de/
http://www.wms.bundonline.bund.de/ (> ITund Beratungsangebot > Formularserver)
A.4.2.1 Leistungsbeschreibung Formular-Center
Im Portal bund.de160 wird ein Kataster der eFormulare161 des Bundes für die Zielgruppen Bürgerinnen & Bürger, Wirtschaft & Wissenschaft sowie Verwaltung & Institutionen zur Verfügung gestellt. Internetadresse und Beschreibung der eFormulare
können über das Redaktionssystem des Portals eingestellt werden.
Die eFormulare sind auf der obersten Ebene nach Zielgruppen sortiert. Danach folgt
eine Aufteilung in Rubriken und konkrete Themen. Die einzelnen eFormulare werden
im PDF- oder HTML-Format angeboten. Eine Suchmaschine und der Katalog des
Portals ermöglichen das schnelle Auffinden der eFormulare.
A.4.2.2 Leistungsbeschreibung Formular-Management-System (FMS)
Das Formular-Management-System unterstützt die wesentlichen Schritte der webbasierten Verwendung von internen und externen Formularen bei parallelem Einsatz
von Papiervordrucken. Das umfasst das Erstellen und Publizieren von eFormularen
und Vordrucken durch die Behörde sowie das Ausfüllen, Speichern, Signieren, Verschlüsseln und Versenden von eFormularen durch die Nutzer. Weiterhin wird eine
medienbruchfreie Annahme von eFormularen und die Bereitstellung der Formulardaten für eine Weiterverarbeitung in den Fachverfahren der Behörden ermöglicht. Auf
längere Dauer wird mit dem parallelen Einsatz von Papiervordrucken und eFormularen gerechnet.
160. siehe http://www.bund.de/
161. Im Weiteren wird unter einem Papiervordruck das von einer Behörde oder in deren Auftrag bereitgestellte Formular in Papierform verstanden. Als elektronisches Formular (eFormular) wird die Abbildung
dieses Papiervordrucks beziehungsweise seines Inhalts in digitaler Form – einschließlich der damit verbundenen IT-gestützten Funktionalitäten – definiert.
Seite 133
A.4.3.1 Geschäftsvorfall Formular-Center
Der folgende Geschäftsvorfall beschreibt wesentliche Nutzungsmöglichkeiten des
Formular-Centers. Der Einsatz wird als obligatorisch klassifiziert.
Papiergebundene Einreichung eines eFormulars bei einer Behörde
a. Bereitstellung des eFormulars in Verbindung mit der Online-Dienstleistung der
Behörde und Publikation im Formular-Center
b. Auffinden des eFormulars im Formular-Center und Zugang zur Online-Dienstleistung bei der Behörde
c. Download und Ausfüllen des eFormulars durch den Nutzer
d. Ausdruck des ausgefüllten eFormulars, Unterschrift und Versand per Post
e. papiergebundene oder digitale Weiterverarbeitung des Antrags in der Behörde
A.4.3.2 Geschäftsvorfälle zum Formular-Management-System
Die folgenden Geschäftsvorfälle beschreiben die Nutzungsmöglichkeiten des Formular-Management-Systems im Zusammenwirken mit anderen Basiskomponenten
sowie den jeweiligen E-Government-Anwendungen. Änderungen im Sinne von Erweiterungen und Einschränkungen des Funktionsumfanges sind im Ergebnis der laufenden Weiterentwicklung nach Bedarfslage der Bundesbehörden möglich. Da die Referenzimplementierung des Formular-Management-Systems noch nicht abgeschlossen
ist, werden diese Geschäftsvorfälle noch als unter Beobachtung klassifiziert.
Elektronische Einreichung eines eFormulars bei einer Behörde
a. Erstellung des eFormulars durch die Behörde; die Berücksichtigung von Zusatzfunktionalitäten, wie z. B. Validierung der Daten, ist möglich
b. Bereitstellung des eFormulars in Verbindung mit der Online-Dienstleistung der
Behörde und Publikation im Formular-Center
c. Online- oder alternativ Offline-Ausfüllen des eFormulars; lokale Speicherung des
eFormulars beim Nutzer
d. elektronische Signierung, ggf. Verschlüsselung und elektronischer Versand des
ausgefüllten eFormulars
e. papiergebundene oder digitale Weiterverarbeitung des Antrags in der Behörde
Integrierter Datenaustausch für Dienstleistungen mit eFormularen
a. Erstellung des eFormulars durch die Behörde; die Berücksichtigung von Zusatzfunktionalitäten, wie z. B. Personalisierung oder Validierung der Daten, ist möglich
b. Bereitstellung des eFormulars in Verbindung mit der Online-Dienstleistung der
Behörde und Publikation im Formular-Center; Anpassung des eFormulars an die
spezifischen Anforderungen des Nutzers
Seite 134
c. On-/ Offline-Ausfüllen des eFormulars am Rechner, ggf. Datenabgleich mit den
Fachverfahren der Online-Dienstleistungen
d. elektronische Signierung, ggf. Verschlüsselung und Anbindung an weitere Basiskomponenten (z. B. ePayment) und Versand des ausgefüllten eFormulars; ggf.
Hinzufügen von elektronisch vorliegenden Anlagen (z. B. Nachweise)
e. Entgegennahme des elektronisch signierten und / oder verschlüsselten eFormulars durch die Virtuelle Poststelle (Signaturprüfung, ggf. Entschlüsselung) des
eFormulars und elektronische Übergabe an die zur Online-Diensteistung gehörenden Fachanwendungen
f. Kommunikation mit dem Nutzer (z. B. Eingangsbestätigung, Meldung fehlerhafter
Angaben) sowie Statusabfrage durch den Nutzer
g. mögliche Integration Dritter (z. B. andere Behörden, Banken etc.) zur Antragsbearbeitung
A.4.4 Roadmap
2. Quartal
2004
Zuschlag auf das Produkt FormsForWeb® der Firma Lucom als Basissoftware für das FMS
4. Quartal
2004
Erste Version der FMS-Toolbox-Dokumente zur Unterstützung der
FMS-Einführung in den Behörden steht zur Verfügung
Weitere Unterstützungsleistungen (technische und nichttechnische
Einführungsberatung sowie Implementierungsleistungen) stehen für
die Behörden zum Abruf bereit.
1. Quartal
2005
Referenzinstallation des FMS für die Ausbaustufen I, II und IV abgeschlossen. Die FMS-Basis-Software steht den Behörden zur Nachnutzung zur Verfügung.
2. Quartal
2005
Formular-Design-Schulungen können durch die Behörden beauftragt
werden
Juli 2005
Abschluss der Referenzimplementierung des FMS
Zur Verwaltung der Daten für behördeninterne Benutzerzugänge soll die Nutzung von
Verzeichnisdiensten entsprechend SAGA162 ermöglicht werden.
Des Weiteren können zukünftig Schnittstellen zu folgenden Basiskomponenten relevant werden:
a. Die Erstellung und Bereitstellung von eFormularen für die Basiskomponente Formularserver wird mit der Basiskomponente Content Management System (CMS)
verbunden.
162. siehe Abschnitt A.7 „Infrastrukturkomponente Verzeichnisdienst“ auf Seite 146
Seite 135
b. Über die Basiskomponente Datensicherheit („Virtuelle Poststelle“) soll die
Annahme, die Verifikation der Signaturen sowie gegebenenfalls die Entschlüsselung von eFormularen erfolgen.
c. Formularbasierte Zahlungsvorgänge werden an die Basiskomponente Zahlungsverkehrsplattform („ePayment“) übergeben.
d. Das Formular-Center ist in der Basiskomponente Portal integriert.
Darüber hinaus sollte grundsätzlich die Weiterverarbeitung von eFormularen in Fachverfahren, wie z. B. in elektronischen Vorgangsbearbeitungs- und DokumentenManagement-Systemen, ermöglicht werden.
A.5 Basiskomponente Content Management System
A.5.1 Einleitung
Die Basiskomponente Content Management System verfolgt das Ziel, die Verwaltung
und Pflege von Informationen in Intranet- und Internetumgebungen der Bundesbehörden zu vereinheitlichen und zu erleichtern.
Das unter der Marke „Government Site Builder“ bekannte System ist eine umfassende Lösung, die speziell für den Bedarf der Bundesverwaltung entwickelt wurde.
Sie ist mandantenfähig, ermöglicht die Umsetzung der Anforderungen an das „barrierefreie“ Internet gemäß BITV und bietet ein konfigurierbares Layout, das sich an den
vom Presse- und Informationsamt der Bundesregierung veröffentlichten Gestaltungsrichtlinien („Internet Styleguide der Bundesregierung“) orientiert. Das System enthält
vorkonfigurierte Module, die von den Behörden als Standard übernommen oder an
einen speziellen Bedarf angepasst werden können. Den Produktionsprozess unterstützt die Basiskomponente durch ein Rollen- und Rechtekonzept sowie Workflows
mit entsprechenden Qualitätssicherungsmechanismen. Technologische Plattform ist
das Content-Management-Framework der CoreMedia AG.
Der Bundesverwaltung wird durch die zentrale Entwicklung und die gemeinsame Nutzung der Weiterentwicklungen eine wirtschaftliche Nutzung eines leistungsfähigen
Content Management Systems ermöglicht.
Die Lösung steht dabei sowohl als zentraler Plattformdienst im BVA wie auch als
dezentrale Komponente – in Eigenverantwortung der jeweiligen Behörden – zur Verfügung.
Seite 136
Herr Andreas Polster
Bundesallee 216-218
10179 Berlin
Tel. +49 1888 681-4318
Fax +49 1888 681-54318
Herr Claus Hackethal
claus.hackethal@bva.bund.de
50728 Köln
Tel. +49 1888 358-1549
Fax +49 1888 358-3899
Verfügbarkeit GSB Version 1.0
seit 1. Oktober 2003
Verfügbarkeit GSB Version 2.0
seit 21. Dezember 2004
http://www.government-site-builder.de/
Die Basiskomponente CMS basiert auf der Smart Content Technology (SCT) der
CoreMedia AG163. Es handelt sich um ein leistungsfähiges „Enterprise Content
Management System“ (ECMS), das es u. a. ermöglicht, die Online-Aktivitäten mehrerer Behörden auf einem System zu hosten und zu verwalten (Mandantenfähigkeit).
Der Zugriff auf das CMS erfolgt über Editoren. Zur Verfügung stehen ein auf JavaTechnologie basierender Editor sowie ein browser-basierter Web-Editor.
Die Verwendung der Basiskomponente CMS erlaubt eine Trennung von Gestaltung,
Inhalt und Logik. Inhalte werden separat vom Layout strukturiert erfasst und verwaltet.
Dies erfolgt auf der Grundlage von so genannten Dokumenttypen, anhand derer die
Inhalte klassifiziert und erfasst werden. Die Redakteure können sich nach kurzer
Schulung somit auf ihre Kernaufgabe, die Erstellung von Inhalt, konzentrieren, ohne
dass sie dazu besondere technische Kenntnisse benötigen.
Innerhalb des CMS erfolgt die Strukturierung der Inhalte durch diese Dokumenttypen
und deren Relationen zueinander. Ein Dokumenttyp enthält Attribute (Eigenschaften),
welche die eigentlichen Informationen aufnehmen. Relationen beschreiben die Beziehungen zwischen den Dokumenttypen und legen fest, welche Dokumente unterge-
163. siehe http://www.coremedia.com/
Seite 137
ordnete Dokumente enthalten können sowie welche Attribute sie von ihnen übernehmen (Vererbung).
Die Basiskomponente stellt eine Reihe von Dokumenttypen bereit, die bei Bedarf
angepasst oder ergänzt werden können, z. B. Pressemitteilung, Rede, Bild, Stellenangebot und Interview. Aber auch Grafiken, Video- und Audio-Daten können mit der
Basiskomponente CMS als eigene Dokumenttypen verwaltet werden.
Einheitliche Dokumenttypen tragen auch zu einem leichteren Austausch bei. Die
medienneutrale Ausgabe beziehungsweise Darstellung des so erfassten Inhaltes wird
durch Darstellungs-Templates gewährleistet, die den Internet-Styleguide der Bundesregierung berücksichtigen.
Eine Versionskontrolle innerhalb des CMS unterstützt die Verwaltung von Dokumenten und ermöglicht den Zugriff auf die jeweils aktuellsten oder frühere Versionen eines
Dokuments. Auf Basis der gewählten Version wird bei Bearbeitung eines Dokuments
eine neue Version erzeugt. Die vorherige Version des Inhalts wird entsprechend gesichert. Die Versionskontrolle der Basiskomponente CMS stellt dabei sicher, dass alle
anderen berechtigten Nutzer auf das gerade in Bearbeitung befindliche Dokument nur
noch lesend zugreifen können. Nach der Bearbeitung wird das Dokument mit den vorgenommenen Änderungen an das System zurückgegeben und steht dann wieder
anderen Nutzern zur Verfügung. Das Linkmanagement der Basiskomponente
gewährleistet die Überprüfung und korrekte Auflösung interner Links und unterstützt
dies bei externen Links.
Weitere technische Funktionalitäten sind:
a. Unterstützung von Mehrsprachigkeit und Internationalisierung
b. Bereitstellung von Möglichkeiten für Multi-Site- und -Channel-Publishing
c. Workflows, inklusive Benachrichtigungssystem, um redaktionelle Prozesse abbilden zu können (4- und 6-Augen-Workflow, Stellvertreterregelung, Möglichkeit der
Erweiterung durch mandanten-spezifische Workflows)
d. Berechtigungssystem (Rollen, Rechte)
e. Style-Definition und Erstellung von HTML-Formularen auf der Basis konfigurierbarer Baukastensysteme
f. Newsletter-Versand (z. B. E-Mail-Push-System für Pressemitteilungen)
g. Mit der Basiskomponente wird zudem auch eine vollständig vorbereitete Website
ausgeliefert (Out-of-the-Box-Lösung / „Standard-Lösung“), die von den Nutzern
leicht an einen spezifischen Bedarf angepasst werden kann.
Für die Basiskomponente CMS wurden zwei Geschäftsvorfälle identifiziert. Beschreibung und Klassifizierung der Geschäftsvorfälle dienen der Entscheidung über den
Einsatz der Basiskomponente.
Seite 138
Informations-Web-Site
Bei reinen Informationsdienstleistungen, beispielsweise bei Behörden-Web-Sites
oder thematischen Internetangeboten, gilt es eine Reihe von Inhalten zu verwalten
und zu präsentieren. In der Regel sind die Änderungshäufigkeit und die Anzahl der
Dokumente so hoch, dass die Verwendung eines Content Management Systems
sinnvoll ist.
Der Einsatz der Basiskomponente CMS ist für alle Informationsdienstleistungen obligatorisch.
Behörden-Web-Site mit Zugang zu Fachanwendungen
Fachanwendungen mit Kommunikations- oder Transaktionscharakter sind häufig im
Rahmen von Web-Auftritten zu präsentieren beziehungsweise zu integrieren. Besonders die Bündelung von verschiedenen Fachanwendungen und deren einheitliche
Präsentation erfordern den Einsatz einer CMS-Lösung. In diesem Fall ist das CMS als
Integrationsplattform zu betrachten.
Behörden-Website mit
Zugang zu fünf
Fachanwendungen
Client
Web-Browser
Präsentation
Servlet
API
Mittelschicht
Mittelschicht
Mittelschicht
Basiskomponente CMS
Fachanwendung B
Fachanwendung A
API
RMI
SOAP
Mittelschicht
Mittelschicht
Mittelschicht
Fachanwendung C
Fachanwendung D
Fachanwendung E
Abbildung A-3: CMS-basierte Behörden-Web-Site integriert Fachanwendungen
Die Integration erfolgt durch Kommunikation von CMS (Integrationskomponente) und
Fachanwendung (Anwendungsschnittstelle) auf der Ebene der Mittelschicht, wobei
Inhalte aus der Fachanwendung auf der Basis von XML-Dateien ins CMS importiert
werden können. Weiterhin kann die Präsentationsschicht – unabhängig vom eigentlichen CMS – dazu genutzt werden, Inhalte direkt von der Anwendungsschnittstelle der
Seite 139
Fachanwendung abzurufen und zu visualisieren. Als Kommunikationsprotokolle können SOAP, CORBA, RMI und direkte Interprozesskommunikation zum Einsatz kommen.
Zusätzlich können ergänzende Inhalte, wie Hilfetexte und Hintergrundmaterial, mit
dem Redaktionssystem des CMS eingepflegt werden und in der Präsentationsschicht
mit den Inhalten der Fachanwendung verknüpft werden. Das Web-Frontend der Fachanwendungen wird von der Basiskomponente CMS realisiert.
Die Abbildung A-3 zeigt fünf unterschiedliche Fachanwendungen. Bei drei dieser
Fachanwendungen werden die Inhalte über unterschiedliche Kommunikationskanäle
(z. B. API, SOAP oder RMI) mit dem CMS ausgetauscht. Das Datenaustauschformat
und die Kommunikationsschnittstellen können auf der Grundlage der vom CMS
bereitgestellten Schnittstellen164 aufgebaut werden.
Die beiden anderen Fachanwendungen werden unabhängig vom CMS in der Präsentationsschicht auf unterschiedlichen Wegen (z. B. mittels einer speziellen API oder
eines Servlets) in den Web-Auftritt integriert.
Die Kopplung über API oder Servlet bedeutet den direkten Zugriff auf Programmierschnittstellen innerhalb derselben Laufzeitumgebung. Bei einer Kopplung über SOAP
oder RMI können die Basiskomponente und die Fachanwendungen auch auf unterschiedlichen Rechnern im Netzwerk verteilt werden.
Der Einsatz der Basiskomponente Content Management System für die Integration
von Fachanwendungen in einer Behörden-Web-Site ist obligatorisch.
A.5.4 Einsatzszenarien
Hat man sich für den Einsatz der Basiskomponente CMS entschieden, stehen zwei
Einsatzszenarien zur Auswahl. Zunächst kann die im Bundesverwaltungsamt (BVA)
zur Verfügung stehende Hosting-Umgebung genutzt werden. Dies empfiehlt sich z. B.
dann, wenn die Behörde selbst kein eigenes Rechenzentrum hat, über eine geringe
technische Infrastruktur verfügt oder die Anwendung aus personellen Gründen nicht
selbst betreiben und administrieren möchte. Durch die Nutzung einer gemeinsamen
Lösung kann ein besonders wirtschaftlicher Betrieb erreicht werden, da Infrastrukturen wie Rechenzentrumsumgebung, Netze, Firewall, Server-Park usw. nur einmal
bereitgestellt und gepflegt werden müssen.
Daneben besteht die Möglichkeit, die Basiskomponente als Software abzurufen.
Diese Option kann gewählt werden, wenn die Behörde über ein eigenes Rechenzentrum verfügt und hohe Integrationsanforderungen im Zusammenhang mit Fachanwendungen vorhanden sind.
Auch bei diesem Szenario können das vorhandene Dokumentenmodell der Basiskomponente und die vorkonfigurierten Funktionalitäten vollständig genutzt werden.
Werden angebotene Features nicht benötigt, kann auch nur eine Teilmenge verwendet werden.
164. siehe Abschnitt A.5.6 „Schnittstellen“ auf Seite 141
Seite 140
Zur Auswahl des passenden Einsatzszenarios sind die Anforderungen an die
E-Government-Anwendung zu betrachten und vorhandene Infrastruktur und personelle Ausstattung der Behörde zu berücksichtigen. Grundsätzlich sollte jedoch vor
einer Entscheidung über den zentralen oder dezentralen Einsatz das Kompetenzzentrum CMS konsultiert werden. Die Entscheidung über die gewählte Einsatzart wird der
Wirtschaftlichkeitsbetrachtung des Einzelfalles überlassen.
A.5.5 Roadmap
2005
Softwarepflege und -updates für die aktuellen Versionen 1.2 und
2.0
Entwicklung nach den Anforderungen des Nutzerbeirates CMS
ab 2006
Auslieferung von Folgeversionen
Ein entscheidender Erfolgsfaktor für einen Web-Auftritt besteht in der Aktualität der
präsentierten Inhalte. Diese Informationen liegen jedoch oft auf verschiedenen Systemen vor oder werden von externen Partnern bezogen. Zusätzlich ist es manchmal
erforderlich, einen Teil der Inhalte an mehrere Partner zu liefern. Darüber hinaus soll
in vielen Intra- und Internetlösungen auch der in Altsystemen vorliegende Inhalt verwendet und bei Bedarf im Rahmen des neu gestalteten Web-Auftrittes dargestellt
werden. Hier sind in der Regel weitere Ergänzungen oder eine zusätzliche Attributierung dieser Legacy-Daten notwendig.
Das der Basiskomponente zugrunde liegende Content Management System von
CoreMedia bietet aus diesem Grund Schnittstellen sowohl für den XML-Import als
auch für den XML-Export an. Da jedoch jedes System eine andere XML-Spezifikation
verwendet, können diese Daten nicht ohne weiteres in das Zielsystem importiert werden. Deshalb werden ergänzend spezielle XML-Importer165 angeboten, dazu zählen
u. a.:
a. AP-Import (IPTC 7901),
b. dpa-Import (IPTC 7901),
c. dpa Newsfeed Interface.
Weitergehende Schnittstellen können beispielsweise ereignisgesteuert auf der Basis
von SOAP als Web Services in einer J2EE-konformen Software-Architektur realisiert
werden. Bei zusätzlichem Bedarf an Schnittstellen und XML-Importern können diese
in den Projekten entwickelt und den Bundesbehörden bereitgestellt werden.
165. Die aufgeführten „speziellen“ XML-Importer sind kein Bestandteil der Lizenzvereinbarung des Bundes mit CoreMedia.
Seite 141
A.6 Infrastrukturkomponente Informationsverbund der Bundesverwaltung
A.6.1 Einleitung
Der „Informationsverbund der Bundesverwaltung“ (IVBV) erleichtert die Kommunikation und Informationsbereitstellung innerhalb der Bundesverwaltung, indem er die existierenden und zukünftigen Informationsdienste in ein Intranet des Bundes integriert.
Den Institutionen und Behörden des Bundes wird dazu eine auf dem Internet Protocol
(IP) basierende Kommunikationsplattform bereitgestellt.
Der IVBV ist eine Weiterentwicklung des Informationsverbunds Berlin-Bonn (IVBB),
die Informations- und Kommunikationsdienste in die Fläche trägt, den Nutzbereich auf
die gesamte Bundesverwaltung ausdehnt und den Bedarf der Behörden an Weitverkehrskommunikation berücksichtigt.
Herr Jürgen Blum
blum@kbst.bund.de
10559 Berlin
Tel. +49 1888 681-2700
Fax +49 1888 10 681-2700
Herr Arnd van Dornick
dornick@kbst.bund.de
10559 Berlin
Tel. +49 1888 681-2783
Fax +49 1888 681-2782
Verfügbarkeit der Infrastrukturkomponente
seit April 2004
Web-Adresse für Informationen zur Infrastrukturkomponente
http://www.kbst.bund.de/saga-ivbv
A.6.2 Aufbau
Der IVBV besteht aus den drei Ebenen IVBV-Dienste, IVBV-Netzinfrastruktur und
IVBV-Intranet.
In der Bundesverwaltung führt der IVBV die Anbieter von Informationsdiensten
zusammen. Er stellt den angeschlossenen Nutzern die Informationsdienste des Bundes als IVBV-Dienste zur Verfügung, z. B. aus Quellen wie dem IVBB oder BundOnline 2005.
Die Basis für den IVBV und die gemeinsame technische Integrationsplattform bilden
Dienstleistungen und Produkte, die aus dem „Rahmenvertrag zur Beschaffung von
Datennetzen für die Bundesverwaltung“ abgerufen werden (Rahmenvertrag zum
BVN).
Seite 142
Durch den Verbund bestehender Netze der Bundesverwaltung (einschließlich des
IVBB) mit Hilfe der Dienstleistungen und Produkte des Rahmenvertrages wird das als
Bundesverwaltungsnetz (BVN) bezeichnete Kernnetz als gemeinsame technische
Netzplattform des IVBV gebildet. Die IVBV-Netzinfrastruktur umfasst darüber hinaus
auch die hierdurch verbundenen weiteren Datennetze der Bundesverwaltung, siehe
Abbildung A-4.
Internet
Netzsegmente
(geschlossene
Netze) im BVN
sonstiges
Behördennetz
Netzabschluss
Koppelnetz
NKZ
SINA-Boxen
NKZ
§
Bx
§
Lx
Netzwerkkompetenzzentrum
des Deutschen
Wetterdienstes
Behörde
§
§
§
Ln
Ln
L1
Liegenschaft eines
Behördenverbunds
§
Bn
IVBV-Intranet
§
§
L1
B1
BVN
IVBV-Netzinfrastruktur
Abbildung A-4: IVBV-Netzinfrastruktur und -Intranet
Zusätzlich ermöglichen die durch den Rahmenvertrag definierten Leistungen den
Behörden der Bundesverwaltung, die keinen eigenen Netzzugang besitzen, die Realisierung eigener Weitverkehrsnetze zur Kopplung ihrer Standorte über jeweils
bedarfsgerecht dimensionierbare Netzanschlüsse. Ein weiterer grundlegender
Bestandteil des Rahmenvertrages ist der durch eine Firewall abgesicherte Zugang
zum Internet, den die Behörden individuell zusätzlich zu ihren Netzanschlüssen abrufen können.
Die gemeinsame Nutzung derselben technischen Plattform durch die Behörde und
den IVBV ermöglicht die einfache Realisierung der Anbindung der Behörde an den
IVBV durch Mitnutzung des Netzanschlusses. Der Zugriff über den Netzzugang einer
Seite 143
Behörde oder eines bestehenden Verwaltungsnetzes auf den IVBV wird mit dem Hinzufügen eines Leitungsverschlüsselungsgerätes, der SINA-Box, ermöglicht. Diese
SINA-Box sichert die Vertraulichkeit und Integrität der Informationsübertragung im
IVBV-Intranet.
Das IVBV-Intranet wird so als abgeschlossenes gesichertes IP-Netz über alle an die
IVBV-Netzinfrastruktur angeschlossenen Verwaltungsnetze und Behörden gebildet.
Zur Überwachung des Netzbetriebs und Vertretung der Interessen der Behörden
gegenüber dem Netzbetreiber sowie für das Management der Leitungsverschlüsselungsgeräte und weiterer zentraler Betriebsaufgaben im IVBV wurde ein „Service
Center IVBV“ (SC IVBV) eingerichtet.
Zentral vom SC IVBV zur Verfügung gestellte Dienste sind DNS und ein E-Mail-Relay.
Diese dienen der Unterstützung der Kommunikation zwischen den Teilnehmern des
IVBV sowie von und zu Teilnehmern in den angeschlossenen Netzen, wie dem IVBB.
Ein zentraler Internetzugang wird nicht durch das SC IVBV bereit gestellt. Internetzugänge werden in den vorhandenen Netzen der Bundesverwaltung (z. B. IVBB) oder
individuell durch die Behörden (z. B. aus dem Rahmenvertrag zum BVN) realisiert.
A.6.3 Teilnehmer und Zugangsbedingungen
Teilnehmer des IVBV sind in erster Linie Angehörige der juristischen Person „Bund“
mit Liegenschaften in ganz Deutschland. Der Zugang erfolgt entweder über das BVN
oder über den IVBB. Andere Netze der Bundesverwaltung werden das BVN nutzen,
um darüber ihren Teilnehmern den Zugang zum IVBV zur Verfügung zu stellen.
Betreiber der jeweiligen technischen Anschlussbasis des Teilnehmers bleiben die bisherigen Netzbetreiber der Teilnetze.
Der IVBV bildet technisch ein abgeschlossenes Kommunikationsnetz oberhalb der IPNetze der Bundesverwaltung, über das ausschließlich berechtigte Teilnehmer kommunizieren. Zur Realisierung des IVBV wird ein vom BSI zugelassenes Leitungsverschlüsselungsgerät, eine so genannte SINA-Box, beim anzuschließenden Teilnehmer
(Standort einer Behörde) benötigt. Für IVBB-Teilnehmer, die am IP-Backbone angeschlossen sind, wurde ein zentraler Übergangspunkt in den IVBV geschaffen.
A.6.4 Technische Leistungsbeschreibung
Die Dienstleistungen und Produkte des Rahmenvertrags zum BVN definieren ein für
die Bundesverwaltung gestaltetes, nichtöffentliches, auf der MPLS-Technologie166
basierendes Kommunikationsnetz. Die Technologie MPLS ermöglicht die logische
Trennung von Anschlüssen in Teilnetzen, den Netzsegmenten. Die Behörden (Nutzer) definieren zwischen den Anschlüssen ihrer Standorte ein von anderen Behörden
isoliertes Netzsegment, in dem jeweils eine uneingeschränkte Kommunikation stattfinden kann. Übergänge zwischen den isolierten Netzsegmenten werden separat zwischen Nutzern vereinbart und durch den Dienstleister umgesetzt. Der IVBV definiert
166. MPLS: Multi Protocol Label Switching
Seite 144
ein eigenes Netzsegment mit den am BVN angebundenen Bundesverwaltungsnetzen
und Behörden.
Der Leistungsabruf aus dem Rahmenvertrag erfolgt durch den jeweiligen Bedarfsträger direkt beim Dienstleister.
Die Grundleistungen des SC IVBV und die IVBB-Informationsdienste im IVBV werden
den IVBV-Teilnehmern zentral zur Verfügung gestellt. Darüber hinaus können Individualleistungen des SC IVBV in Form von individuellen Beratungs- und Betriebsleistungen für BVN-Nutzer vereinbart werden, die direkt mit dem SC IVBV abgerechnet
werden.
Technische Parameter des BVN:
a. Anschlüsse an das BVN über Netzendgeräte mit einem Ethernet-Port für den
Zugang zum BVN, sowie optional einem weiteren Ethernet-Port für den transparenten Zugang zum Internet
b. BVN-Anschlussbandbreiten von 128 KBit/s bis 3x155 MBit/s in drei Service-Varianten (u. a. hochverfügbarer Anschluss mit Zweiwegeführung) und mit weiteren
optionalen Parametern (u. a. vier „Quality of Service“-Klassen)
c. transparenter, individueller Internetzugang mit Anschlussbandbreiten von 128
KBit/s bis 1x155 MBit/s in drei Service-Varianten
d. abgesicherter, zentraler Internetzugang als optionaler Dienst am Teilnehmeranschluss
e. Einwahl in das BVN über Wähl- und Mobilfunknetze mit nutzerbezogener Abrechnung und Authentifizierung des mobilen Teilnehmers
Die durch das SC IVBV erbrachten Grundleistungen sind:
a. Überwachung der Leistungserbringung durch den Dienstleister
b. Reporting über die Leistungserbringung an die Nutzer
c. Koordination mit den Betreibern anderer Behörden- und Verwaltungsnetze
d. Management (Personalisierung und Administration) der Verschlüsselungsgeräte
(SINA-Boxen) für den Zugang zum IVBV-Intranet
e. Betrieb zentraler Komponenten des IVBV (DNS, E-Mail-Relay)
f. Vermittlung von E-Mails zwischen IVBB- und IVBV-Teilnehmern über sichere
Infrastrukturen
Informationsdienste, die aus dem IVBB im IVBV zur Verfügung gestellt werden:
a. zentrale Dienste des IVBB, z. B. Verzeichnisdienst und Verwaltungs-PKI
b. Datenbankanwendungen, z. B. EU-Dokumenten-Server, Ausländerzentralregister
(AZR), Juristisches Informationssystem für die öffentliche Verwaltung (JURIS)
c. Web-Angebote im IVBB für die Bundesverwaltung, die in einem Extranet-Bereich
des IVBB für den IVBV bereit gestellt werden
Jeder IVBV-Nutzer kann auch Anbieter von Informationsdiensten im IVBV sein.
Seite 145
Der IVBV ist der Verbund der Anbieter von Informations- und Kommunikationsdiensten der Bundesverwaltung und daher als Intranet ohne Alternative. Zwei Geschäftsvorfälle sind dabei von besonderem Interesse:
Zugriff auf das Informationsangebot des IVBB
Behörden, die nicht zu den Obersten Bundesbehörden gehören und daher nicht
IVBB-Teilnehmer sind, möchten auf das für die Bundesverwaltung bereitgestellte
Dienste- und Informationsangebot des IVBB zugreifen.
Ein Zugriff kann nur erfolgen, wenn die erforderlichen Schutzmaßnahmen, u. a. die
Absicherung der Kommunikation durch ein Leitungsverschlüsselungsgerät, eingehalten werden und der IVBB-Dienst im IVBB-Extranet mit entsprechenden Zugriffsrechten bereitgestellt wurde. Der Zugriff erfolgt daher über den Nutzeranschluss an den
IVBV in das IVBB-Extranet.
Die Auflösung des Namens des Informations-Servers benötigt den zentralen DNS im
IVBV. Voraussetzung auf Nutzerseite ist daher, dass die Konfiguration der Namensauflösung im lokalen Netz des Nutzers entsprechend konfiguriert ist.
Bereitstellen von Informationsdiensten für die Bundesverwaltung in einem sicheren
Umfeld (G2G)
Eine Behörde ist Teil einer Prozesskette eines Projektes der Initiative BundOnline
2005. Sie nutzt ihrerseits zentrale Komponenten, um ihre Prozesse für andere Behörden zugänglich zu machen. Als Anbieter benötigt sie für ihre betrieblichen Belange
ein sicheres Umfeld an Kommunikations- und Informationsdiensten.
Das BVN bietet ihr dazu einen hochverfügbaren Zugang zum IVBV. Der IVBV ermöglicht die sichere Kommunikation mit anderen Partnern innerhalb der Bundesverwaltung.
Die Behörde als IVBV-Teilnehmer stellt ihre Informationen für andere Behörden im
IVBV bereit, indem ein Informations-Server am IVBV-Anschluss zur Verfügung
gestellt und der Name des Informations-Servers im zentralen DNS des IVBV freigeschaltet wird.
A.7 Infrastrukturkomponente Verzeichnisdienst
A.7.1 Einleitung
Die Infrastrukturkomponente Verzeichnisdienst stellt über den Informationsverbund
Berlin-Bonn (IVBB) und den Informationsverbund der Bundesverwaltung (IVBV) ein
Verzeichnis, basierend auf dem Standard X.500, bereit. Den an IVBB und IVBV angeschlossenen Nutzern, in der Regel Behörden, werden mittels des Verzeichnisdienstes
übergreifende Adressinformationen, Telefonnummern, Adressen, E-Mail-Adressen
Seite 146
etc. zur Verfügung gestellt. Damit soll die Kommunikation zwischen den Behörden
erleichtert werden.
Im Verzeichnisdienst in den Intranets von IVBB und IVBV werden Informationen zu
den beteiligten Behörden und deren Mitarbeitern abgelegt. Im IVBV sind nur die von
den Behörden freigegebenen Adressdaten aus dem IVBB-Verzeichnisdienst eingestellt. Die Datensätze aus dem IVBV werden vollständig in den IVBB gespiegelt. Teilnehmer des IVBB und IVBV können mit LDAP-v2/v3-Clients auf den Verzeichnisdienst zugreifen. Für IVBB-Teilnehmer besteht zusätzlich die Möglichkeit, mit WebBrowsern die Daten zu administrieren. Ein Vorteil des Verzeichnisdienstes für die Mitarbeiter der Behörden ist die gewährleistete Aktualität der Daten, ohne dass die Mitarbeiter aufwändige eigene Aktualisierungen durchführen müssen.
Der Verzeichnisdienst steht außerdem auch im Internet zur Verfügung167. Datensätze
des X.500 Directory werden mit reduziertem Inhalt vom Intranet in das Internet
gespiegelt. Welche Adressdaten im Internet verfügbar sind, entscheiden die Behörden. Verfügbar im IVBB sind derzeit 70.875 Einträge und ca. 3.850 Zertifikate.
Organisatorischer Ansprechpartner Frau Sabine Richter
it2@bmi.bund.de
10559 Berlin
Tel. +49 1888 681-2763
Fax +49 1888 10 681-2763
Herr Wilfried Kister
referati12@bsi.bund.de
Bundesamt für Sicherheit in der Informationstechnik
Postfach 200363
53133 Bonn
Tel. +49 1888 9582-366
Fax +49 1888 10 9582-366
in IVBB, IVBV und Internet (http://
x500.bund.de/) vorhanden
Web-Adresse für Informationen zur http://www.kbst.bund.de/saga-x500
Zur Bereitstellung der Daten im Verzeichnisdienst bestehen mehrere Möglichkeiten:
a. Nutzer, die über ein eigenes Verzeichnissystem verfügen, können sich am verteilten X.500 Directory (hier Synomyn für Verzeichnisdienst) beteiligen. Wie und in
167. siehe http://x500.bund.de/
Seite 147
welcher Form die Kopplung der Server erfolgt, muss im Einzelfall entschieden
werden.
b. Wenn beim Nutzer kein eigenes Verzeichnissystem zur Verfügung steht, ist eine
Dateischnittstelle vorgesehen, über die Daten in das zentrale X.500 Directory eingespielt werden können.
Der Verzeichnisdienst wird im Intranet und im Internet von der Firma T-Systems
betrieben. T-Systems administriert die Einbindung dezentraler Directories und ist für
die Einlagerung von Daten über die Dateischnittstelle und Schemaänderungen beziehungsweise -erweiterungen zuständig.
Das Datenmodell im X.500 Directory ist hierarchisch aufgebaut. Der oberste Knoten,
der verwaltet werden kann, ist c=de, o=bund, wobei die Kürzel c=de für country=
Deutschland und o=bund für organization=Bund steht. Nur unterhalb dieses Knotens,
dem „administrative point“, können Daten verwaltet werden.
Die folgende Aufzählung zeigt die unterstützten Objekte im Verzeichnisdienst.
a. Behörden – sind die Obersten Bundesbehörden und weitere Behörden (Ressorts,
Häuser). Sie werden als „organizationalUnit“ im Directory gespeichert.
b. Orte – werden als „locality“ im Directory gespeichert.
c. Personen, aber auch Organisationseinheiten – werden als „inetOrgPerson“ im
Directory gespeichert.
d. Räume – werden als „room“ im Directory gespeichert.
e. Abteilungen (bzw. Referate) – werden als „ivbbDepartment“ im Directory gespeichert.
f. Certification Authorities (CAs) – werden als „applicationProcess“ im Directory
gespeichert.
Der Aufbau des X.500-Schemas orientiert sich zwar im Wesentlichen an den Standards X.509, X.520, X.521 (1997, 2000); X.402 (1988); RFC 1274 (COSINE / Paradise); RFC 2256 (X.500 Schema for LDAP v3); RFC 2798 (inetOrgPerson), aber es
sind etliche Erweiterungen, insbesondere von Attributen, vorgenommen worden, die
unter der oben angegebenen Web-Adresse nachgelesen werden können.
Der Einsatz der Infrastrukturkomponente Verzeichnisdienst ist in allen Geschäftsvorfällen obligatorisch:
Standardanwendung
Der Benutzer einer Behörde sucht die E-Mail-Daten eines Adressaten aus seiner oder
einer anderen Behörde. Die Applikation, z. B. Outlook, greift auf die E-Mail-Daten aus
dem X.500 Directory zurück, um entsprechende Adressvorschläge unterbreiten zu
können.
Seite 148
Voraussetzung ist, dass der Name des Gesuchten im X.500 Directory gespeichert ist
und eine Datenvollständigkeit (zentrale Synchronisation der X.500-Daten) realisiert
ist.
Basiseinsatzfall
Die Behörde stellt ihre Adressdaten für andere Behörden und auch für Benutzer
außerhalb von Behörden bereit. Eine dezentrale Pflege der Daten und zentrale Verteilung werden ermöglicht.
Im Abschnitt A.7.2 „Leistungsbeschreibung“ auf Seite 147 werden die Standards und
Formate genannt, mit denen die Daten im X.500 Directory angelegt, geändert und
ausgelesen werden können.
A.7.5 Roadmap
Der Verzeichnisdienst ist im Informationsverbund Berlin-Bonn (IVBB), im Informationsverbund der Bundesverwaltung (IVBV) und im Internet168 verfügbar.
A.8 Infrastrukturkomponente Public Key Infrastruktur der Verwaltung
A.8.1 Einleitung
Die Public Key Infrastruktur der Verwaltung (im Folgenden als Verwaltungs-PKI
bezeichnet oder als V-PKI abgekürzt) stellt für Bundes- und Landesbehörden, Kommunen sowie öffentliche Institutionen die Basistechnologie für zertifikatsbasierte
Sicherheitsdienstleistungen bereit. Auf dieser Grundlage können ausreichende
Sicherheit (Integrität und Vertraulichkeit der Daten) und eine aussagekräftige Authentizität (Identifikation und Unabstreitbarkeit) in der Kommunikation innerhalb elektronischer Verwaltungs- und Geschäftsprozesse erreicht werden.
Ziel der Verwaltungs-PKI ist es, den elektronischen Geschäftsverkehr zwischen Verwaltung, Wirtschaft und Bürgern mindestens auf dem IT-Grundschutz-Niveau zu
ermöglichen, wie es im Beschluss der Bundesregierung vom 16. Januar 2002
„Sicherheit im elektronischen Rechts- und Geschäftsverkehr mit der Bundesverwaltung“ gefordert wurde.
Ansprechpartner
Referat I 1.1
v-pki@bsi.bund.de
Postfach 200363
53133 Bonn
168. siehe http://x500.bund.de/
Seite 149
seit 2001
Web-Adresse für Informationen zur Verwaltungs-PKI
http://www.bsi.bund.de/fachthem/verwpki/
A.8.2 Aufbau
Die PKI der Verwaltung kann in die drei Komponenten Wurzelzertifizierungsstelle,
Zertifizierungshierarchie und Verzeichnisdienst aufgeteilt werden. Die Architektur ist
in der folgenden Abbildung dargestellt.
Die Wurzelzertifizierungsstelle (Policy Certification Authority – PCA) erstellt als oberste Zertifizierungsstelle der Hierarchie ein selbstsigniertes Wurzelzertifikat und
signiert die Zertifikate der angeschlossenen Zertifizierungsstellen.
Die von der Wurzelzertifizierungsstelle zertifizierten Zertifizierungsstellen (Certification Authority – CA) bilden die zweite Stufe der PKI-Hierarchie. Die Teilnehmer (TN)
wiederum werden durch die ihnen zugeordnete Zertifizierungsstelle eingebunden und
bilden die unterste Stufe der Zertifizierungshierarchie.
European
Bridge CA
Zertifizierungshierarchie
Organisationsübergreifende
Anbindung
Verzeichnisdienst
Wurzelzertifizierungsstelle (PCA V-PKI)
Bereitstellung der
Zertifikate & Sperrlisten
PCA EB-CA
zertifiziert
CA
CA
zertifiziert
(optional)
sub-CA
X.500 des
IVBB
CA
akkreditiert
TN
TN
TN
Abbildung A-5: Aufbau der Verwaltungs-PKI
Teilnehmer sind Personen, Personengruppen, Funktionen oder Dienste (IT-Prozesse), die im Rahmen der PKI-1-Verwaltung Schlüssel und Zertifikate erhalten oder
aus dem Verzeichnisdienst PKI-Informationen von CAs oder Teilnehmern abrufen.
Für natürliche Personen werden Pseudonyme zugelassen.
Seite 150
Die Zertifizierungsstelle kann dabei entweder durch die jeweilige Institution in Eigenverantwortung betrieben werden oder die PKI-Dienstleistungen durch kommerzielle
CA-Dienstleister erbringen lassen.
Darüber hinaus steht es jeder Zertifizierungsstelle frei, weitere nachgeordnete Zertifizierungsstellen (Sub-CA) zu zertifizieren. Um eine praktikable Architektur mit überprüfbaren Sicherheitsleitlinien zu gewährleisten, wird eine maximal fünfstufige PKIHierarchie vorgegeben. Sollten besondere Umstände gegen diese Beschränkung
sprechen, so ist dies bei der Antragstellung zu begründen und die Genehmigung der
PCA der Verwaltung einzuholen.
Die Wurzelzertifizierungsstelle stellt die von ihr ausgestellten Zertifikate und Sperrlisten in den öffentlich zugänglichen Teil des X.500-Verzeichnisses des IVBB (Informationsverbund Berlin-Bonn)169 ein. Die Verfügbarkeit dieses Verzeichnisses erfüllt die
hohen Verfügbarkeitsanforderungen des IVBB. Detailliertere Informationen über Aufbau und Zugriff sind dem Verzeichnisdienstkonzept der PCA der Verwaltung zu entnehmen.
Um die Nutzung der PKI jedoch nicht gegenüber bestehenden Kommunikationsbeziehungen zu anderen Regierungen, Wirtschaftsunternehmen und Bürgern abzugrenzen, bietet die European Bridge CA (EB-CA) unter der Leitung des TeleTrusT
Deutschland e. V. eine organisationsübergreifende Lösung an. Sie verbindet die
PKIen von Wirtschaft und Verwaltung miteinander und ist auf maximale Interoperabilität und Flexibilität ausgerichtet. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) vertritt als Betreiber der Wurzelzertifizierungsstelle der Verwaltungs-PKI
die öffentliche Verwaltung der Bundesrepublik Deutschland innerhalb der EB-CA.
Die vom BSI betriebene Wurzelzertifizierungsstelle erstellt auf Antrag Zertifikate für
alle Zertifizierungsstellen aus dem Bereich der öffentlichen Verwaltung (Bund, Länder, Kommunen).
Da für die PKI die Einschätzung der Vertrauenswürdigkeit der ausgestellten Zertifikate von entscheidender Bedeutung ist, werden die für die Zertifikatsstellen verbindlichen Sicherheitsleitlinien (Policy) in einem Dokument beschrieben. Der Aufbau dieses Dokuments lehnt sich dabei an die Empfehlungen des RFC 2527 an, womit es
inhaltlich sowohl Elemente einer Policy, als auch des mehr technisch-organisatorisch
orientierten Certificate Practice Statements (CPS) vereinigt.
Zertifikate können von Zertifizierungsstellen als personenbezogene Zertifikate oder
als Gruppenzertifikate ausgestellt werden. Gruppenzertifikate können ausgestellt werden für:
a. Personengruppen (z. B. Projektgruppe PKI)
b. Funktionen (z. B. Poststelle; Funktion, die durch einen Mitarbeiter ausgefüllt wird)
169. siehe auch Abschnitt A.7 „Infrastrukturkomponente Verzeichnisdienst“ auf Seite 146
Seite 151
c. Automatisierte IT-Prozesse (z. B. elektron. Stempel, Serverprozesse mit Signatur,
SSL- Server).
Der Anwendungsbereich der Zertifikate der PKI der Verwaltung erstreckt sich im Rahmen dieser Policy auf die Verschlüsselung und Authentisierung sowie die fortgeschrittene elektronische Signatur im Sinne der durch das Signaturgesetz (SigG) vorgenommenen Umsetzung der EG-Richtlinie.
Im Rahmen der Infrastrukturkomponente V-PKI übernimmt die Wurzelzertifizierungsstelle folgende Verpflichtungen:
a. Erzeugung eines kryptografisch geeigneten Schlüsselpaares in einer gesicherten
Umgebung
b. Erzeugung ihres selbstsignierten Zertifikats
c. Integere und authentische Veröffentlichung:
i. ihres Zertifikats einschließlich des dazugehörigen Fingerabdrucks,
ii. der von ihr ausgestellten Zertifikate,
iii. von Sperrlisten der Zertifizierungsstellen,
d. Einhaltung der Policy und
e. Bereitstellung eines Sperrdienstes.
Über diese Leistungen hinaus wird die V-PKI über die European Bridge-CA in die
deutsche Wirtschaft integriert, wobei die Wurzelzertifizierungsstelle den Nutzerkreis
der öffentlichen Verwaltung repräsentiert. Zudem werden in regelmäßigen Abständen
Interoperabilitätstests zu PKI-Produkten durchgeführt und die Ergebnisse mit einer
Empfehlung geeigneter Produkte veröffentlicht.
Die Infrastrukturkomponente wird für alle Geschäftsvorfälle empfohlen:
Verschlüsselte Kommunikation per E-Mail
Ein Benutzer wünscht eine vertrauliche Kommunikation per E-Mail. Dazu kann entweder die gesamte E-Mail verschlüsselt werden oder lediglich eine Datei, die der Mail
als Anhang beigefügt wird. Die Verschlüsselung erfolgt dabei über das so genannte
Public-Key-Verfahren. Über eine Zertifikatsstelle innerhalb der V-PKI erhält der
Benutzer dazu einen privaten und einen öffentlichen Schlüssel. Die verlässliche
Zuordnung des öffentlichen Schlüssels zum Benutzer erfolgt über elektronische Zertifikate. Sowohl das Zertifikat als auch der öffentliche Schlüssel werden dazu im Verzeichnisdienst X.500 des IVBB öffentlich zur Verfügung gestellt.
Signierte Kommunikation per E-Mail
Ein Benutzer möchte die Verbindlichkeit seiner E-Mail, also seine Authentizität sowie
die Integrität der Daten, gewährleisten. Dazu nutzt er wie vorstehend beschrieben
den privaten Schlüssel des Public-Key-Verfahrens und erstellt eine Signatur. Dabei
handelt es sich um einen kurzen fälschungsicheren Wert, der an die ursprünglichen
Seite 152
Daten angehängt und vom Empfänger über den öffentlichen Schlüssel überprüft werden kann.
Verschlüsselte Kommunikation per Web
Eine Behörde möchte ein (interaktives) Angebot ihrer Website über einen gesicherten
Kanal an den Benutzer übertragen. Um eine SSL-Verschlüsselung und somit eine
vertrauliche Übermittlung der Daten zwischen Web-Server und Browser zu erreichen,
wird ein Server-Zertifikat einer Zertifizierungsstelle der V-PKI genutzt.
Die flächendeckende Nutzung der eingesetzten Komponenten innerhalb einer PKI ist
nur durch eine übergreifende Interoperabilität möglich, die den Austausch der PKIInformationen (Teilnehmer-Zertifikate, CA-Zertifikate und Sperrlisten) sicherstellt. Die
hierzu von der Wurzelzertifizierungsstelle verwendeten Standards werden durch die
Sicherheitsleitlinie für die gesamte PKI verbindlich.
Die Verwaltungs-PKI basiert auf der MailTrusT-Spezifikation des TeleTrusT Deutschland e. V. in der Version 2 (MTT v2). Damit wird die Interoperabilität zu international
verbreiteten Standards wie z. B. S/MIME, X.509 und LDAP sichergestellt. Eine
zukünftige Migration zu übergreifenden Standards wie ISIS-MTT wird entsprechend
dem Stand der Entwicklung mitvollzogen.
A.9 „Einer-für-Alle“-Dienstleistungen
A.9.1 Einleitung
Während sich die Fachaufgaben der Ressorts mit ihren nachgeordneten Behörden
auf völlig unterschiedliche Bereiche des öffentlichen Lebens richten – von Finanzen
über Verteidigung und Justiz bis hin zum Verbraucherschutz – laufen die zugrunde
liegenden Prozesse zur Realisierung der unterschiedlichen Dienstleistungen häufig
sehr ähnlich ab.
Wird der Prozess der Leistungserbringung von der eigentlichen Fachaufgabe und den
verarbeiteten Informationen abstrahiert, ergeben sich signifikante Synergiepotenziale
in Bezug auf Kosten und Aufwand, wenn es darum geht, die Prozesse informationstechnisch zu unterstützen und online zu setzen.
So läuft beispielsweise der Prozess der Förderung in jedem Ressort prinzipiell nach
dem gleichen Schema ab – unabhängig vom Gegenstand der Förderung: Einem
Antrag auf Förderung folgt die Prüfung, die Bewilligung, der Mittelabfluss, die Überwachung und die abschließende Bewertung.
Um diese Synergiepotenziale zu nutzen, beschloss das Bundeskabinett im Dezember
2002 die Entwicklung so genannter „Einer-für-Alle“-Dienstleistungen (kurz EfADienstleistungen).
Seite 153
EfA-Dienstleistungen sind Angebote, die – wie das Beispiel der Förderung – von einer
Reihe von Behörden in gleicher oder ähnlicher Weise erbracht werden. Sie decken
somit identische Anforderungen der Behörden an die IT-Unterstützung der betroffenen Geschäftsprozesse ab.
EfA-Dienstleistungen werden von einem Ressort oder einer Behörde entwickelt und
gegebenenfalls auch von dieser zentral betrieben. Software und Systemkonfiguration
sollen mit möglichst geringem Aufwand an sich ändernde Anforderungen der verschiedenen Nutzerinnen und Nutzer angepasst werden können. Deshalb muss bei
der Konzeption und Entwicklung in starkem Maß auf ein generisches und konfigurierbares System- bzw. Software-Design geachtet werden.
Insgesamt wurden in einem ersten Schritt 15 BundOnline-Dienstleistungen als EfADienstleistungen identifiziert. Im Rahmen der regelmäßig stattfindenden Ressortbesprechungen der Initiative wurden mittlerweile neun hinsichtlich ihres Nutzens für die
Ressorts mit besonders hoher Priorität bewertet:
Projektförderinformationssystem
profi
Dienstleistungstyp 6: Förderungen abwickeln
e-Vergabe
Dienstleistungstyp 7: Beschaffungsvorhaben
durchführen
TravelManagementSystem
Dienstleistungstyp 7: Beschaffungsvorhaben
durchführen
Elektronischer Rechtsverkehr
Dienstleistungstyp 5: Allgemeine Antragsverfahren
Vorbereiten politisch-regulativer
Entscheidungen
Dienstleistungstyp 3: Vorbereiten von politischen
Entscheidungen
Personalwerbung und -gewinnung
Dienstleistungstyp 9: Sonstige Dienstleistungen
ArchiSafe
Dienstleistungstyp 9: Sonstige Dienstleistungen
Ressortspezifisches Haushaltsaufstellungsverfahren
Dienstleistungstyp 4: Zusammenarbeit zwischen
Behörden
Online-Beratung
Dienstleistungstyp 2: Beratung durchführen
Damit die nutzenden Ressorts und Behörden ihre Anforderungen an die EfA-Dienstleistungen einbringen können, wird für jede EfA-Dienstleistung ein Nutzerbeirat eingerichtet, der aus Vertreterinnen und Vertretern interessierter Behörden zusammengesetzt ist. Dieser soll dazu beitragen, dass die jeweiligen Anforderungen frühzeitig
zusammengetragen und bei Konzeption und Realisierung berücksichtigt werden.
Seite 154
A.9.2 Projektförderinformationssystem profi und profi Online
Eine wesentliche Aufgabe der Bundesverwaltung ist die Förderung unterschiedlicher
Vorhaben, Maßnahmen und Projekte. Allein das Bundesministerium für Bildung und
Forschung (BMBF) wendete im Jahr 2003 über zwei Milliarden Euro für Projektförderungen auf. Diese Relevanz spiegelt sich auch in der Initiative BundOnline wider.
Circa zehn Prozent der BundOnline-Dienstleistungen betreffen Fördermaßnahmen
der Bundesressorts. Bereits vor dem Start von BundOnline hatte das BMBF profi
(Projektförderinformationssystem) entwickelt und dies – zusammen mit Projektträgern und anderen Ressorts, wie dem Bundesministerium für Wirtschaft und Arbeit –
weiter ausgebaut. Profi unterstützt Förderungen informationstechnisch – von der Ausschreibung über die Antragstellung bis hin zur administrativen Abwicklung. Der Kern
von profi ist eine gemeinsame, einheitliche und zentral gehaltene Datenbank, von der
aus Daten von allen dazu berechtigten Anwendern dezentral abgerufen und bearbeitet werden können.
Fachlicher Ansprechpartner
Herr Dr. Peter Mecking
peter.mecking@bmbf.bund.de
Bundesministerium für Bildung und Forschung
Heinemannstr. 2
53175 Bonn
Tel. +49 1888 57-3815
Fax +49 1888 57-83815
Herr Michael Noack
michael.noack@dlr.de
Deutsches Zentrum für Luft- und Raumfahrt
Linder Höhe
51447 Köln
Tel. +49 2203 601-3613
Fax +49 2203 601-13613
Verfügbarkeit des Kernsystems
seit 2000 in produktivem Einsatz
Verfügbarkeit von profi Online
3. Quartal 2005
Web-Adresse für Informationen
zur EfA-Dienstleistung
http://www.kp.dlr.de/profi/
Die Vorteile der Nutzung von profi bestehen nicht nur in der höheren Qualität und
Aktualität der Daten, sondern auch in einer effizienteren und beschleunigten Durchführung der Verfahren. Zum Beispiel ersetzt profi das herkömmliche Prozedere der
manuellen Kassenanordnungen durch ein maschinelles Verfahren der Sammelanordnung. So profitiert auch die Bundeskasse vom elektronischen Austausch zahlungsrelevanter Daten. Derzeit werden mehr als 19.000 laufende Verfahren von 1.800
Anwendern an 33 Standorten bearbeitet.
Seite 155
Bis 2002 war profi bei vier Bundesministerien im Einsatz. 2003 wurde es im Bundesministerium für Umwelt, Naturschutz und Reaktorsicherheit eingeführt. Ab 2006 wird
profi im Bundesverwaltungsamt und im Bundesamt für Migration und Flüchtlinge eingesetzt. Weitere Interessenten sind derzeit das Bundesministerium für Familie,
Senioren, Frauen und Jugend (BMFSFJ) und das Bundesministerium für Gesundheit
und Soziale Sicherung sowie die Bundeszentrale für politische Bildung.
Profi wird um weitere Bestandteile ergänzt. Um eine sichere Kommunikation mit
externen Nutzern zu gewährleisten, wird für die Komponente „profi Online“ die qualifizierte elektronische Signatur eingeführt. Die angestrebte Lösung ist eine barrierefreie
Web-Applikation, die auf allen gängigen Plattformen (Windows, Linux, Mac-OS) läuft.
Ihr produktiver Start ist für das dritte Quartal 2005 geplant.
Die Erweiterung der Mandantenfähigkeit von profi soll im Dezember 2005 umgesetzt
sein. Zur Ablage und Verwaltung von Dokumenten im Förderbereich wurde ein Sollkonzept zur Anbindung von DOMEA-zertifizierten Vorgangsbearbeitungs- und Dokumentenmanagementsystemen erarbeitet. Die Realisierung dieser Anbindung wird
erstmals in Zusammenarbeit mit dem BMFSFJ realisiert.
A.9.3 e-Vergabe
Der Bund beschafft über seine rund 600 Vergabestellen jährlich für circa 63 Milliarden
Euro Produkte und Dienstleistungen. Bei diesem hohen Volumen sind bei einer elektronischen Abwicklung der Vergabeverfahren erhebliche Einsparungen sowohl bei
den Prozesskosten als auch bei den Preisen für die zu beschaffenden Leistungen zu
erzielen. Neben der öffentlichen Hand kann auch die Privatwirtschaft von einer einheitlichen elektronischen Beschaffungslösung profitieren.
Ansprechpartner
Frau Dr. Sonja Branskat
sonja.branskat@bescha.bund.de
Beschaffungsamt des Bundesministeriums
des Innern
Postfach 30015
53181 Bonn
Tel. +49 228 610-1202
Fax +49 228 610-1610
Verfügbarkeit
seit Mai 2002
Web-Adressen für Informationen
zur EfA-Dienstleistung
http://www.bescha.bund.de/egovernment/
http://www.evergabe-online.de/
Das Beschaffungsamt des Bundesministeriums des Innern hat deshalb im Rahmen
des Projektes „Öffentlicher Eink@uf Online“ eine elektronische Vergabeplattform, die
so genannte „e-Vergabe“, realisiert. Die Entwicklung der Plattform erfolgte unter Einbindung des Bundesministeriums der Verteidigung sowie des Bundesministeriums für
Seite 156
Verkehr, Bau- und Wohnungswesen und wurde durch das Bundesministerium für
Wirtschaft und Arbeit gefördert. Im Mai 2002 wurde über das System die erste durchgehend elektronische Beschaffung abgewickelt.
Die e-Vergabe erlaubt die elektronische Abwicklung von Beschaffungsaufträgen über
das Internet. Die Kommunikation zwischen der Vergabestelle und den potenziellen
Bietern erfolgt rechtsverbindlich sowie medienbruchfrei und erstreckt sich von der
Bekanntmachung des Ausschreibungstextes über den Versand der Verdingungsunterlagen und die elektronische Angebotsabgabe bis zur Zuschlagserteilung. Dokumente werden durch Smartcards mit der qualifizierten elektronischen Signatur versehen und verschlüsselt übertragen.
Abbildung A-6: Einstiegsseite zur EfA-Dienstleistung e-Vergabe
Das System bildet alle relevanten Verdingungsordnungen ab und ist mandantenfähig.
Zurzeit wird es u. a. vom Beschaffungsamt des Bundesministeriums des Innern, vom
Bundesamt für Bauwesen und Raumordnung sowie vom Bundesamt für Wehrtechnik
und Beschaffung sowie 15 weiteren Vergabestellen des Bundes eingesetzt; daneben
nutzen aber auch Landes- bzw. Kommunalbehörden, wie z. B. das Amt für Technik
und Beschaffung der Polizei in Mecklenburg-Vorpommern, die e-Vergabe. Die Plattform, die das Statistische Bundesamt in Wiesbaden für das Beschaffungsamt des
Bundesministeriums des Innern technisch betreibt, ist im Internet unter http://
www.evergabe-online.de/ erreichbar.
Seite 157
Die Bundesverwaltung strebt eine organisatorische Verbesserung des öffentlichen
Auftragswesens auf der Basis neuer Informationstechnologien an. Kern ist ein Sieben-Punkte-Programm mit folgenden für die e-Vergabe relevanten Aussagen:
a. Die e-Vergabe wird allen öffentlichen Stellen zur Nutzung angeboten. Alle Bundesbehörden stellen ihre Vergabeverfahren sukzessive bis Ende 2005 auf die eVergabe um.
b. Es werden durchgängige (elektronische) Prozessketten zwischen den Bedarfsträgern und den Lieferunternehmen mit definierten Schnittstellen entwickelt.
Ein Geschäftsmodell, welches sich derzeit in der Ressortabstimmung befindet, legt
dar, wie sich die Weiterentwicklung des Systems sicherstellen lässt (u. a. Anpassung
an neue gesetzliche Bestimmungen oder technische Neuerungen) und eine möglichst
verursachungsgerechte Kostenverteilung auf die Nutzerinnen und Nutzer realisiert
werden kann.
Die e-Vergabe wird noch im Laufe des Jahres 2005 an die Erfordernisse, die sich aus
der Novellierung des Vergaberechts ergeben, angepasst. Mit Inkrafttreten der neuen
nationalen Vergabeverordnung Anfang 2006 stehen dann auch auf der e-Vergabe die
neuen Möglichkeiten, wie z. B. inverse Auktionen, zur Verfügung.
A.9.4 TravelManagementSystem
Das TravelManagementSystem (TMS) des Bundes stellt alle Leistungen im Rahmen
von Planung, Organisation und Steuerung der Reiseaktivitäten von Bundesbehörden
online zur Verfügung. Es verfolgt damit das Ziel, das Dienstreisewesen der Bundesverwaltung wirtschaftlicher zu gestalten und gleichzeitig die Qualität zu sichern.
Neben der Bündelung der Nachfrage zur Senkung der direkten Reisekosten steht
dabei insbesondere die Optimierung der Prozesse im Vordergrund.
Ansprechpartner
Gregor Willemsen
gregor.willemsen@bva.bund.de
Barbarastr. 1
50735 Köln
Tel. 0221/358-1138
Fax 0221/358-2823
Verfügbarkeit der EfA-Dienstleistung
seit 2003
Das bisher manuell durchgeführte Reiseantrags- und Buchungsverfahren wird durch
eine integrierte vollelektronische Workflow-Lösung ersetzt, mit der Dienstreisegenehmigungs- sowie -abrechnungsanträge online gestellt und bearbeitet werden können.
Bucht der Reisende seine Reisemittel nicht selbst, werden auch die für die Buchung
erforderlichen Daten über den Workflow digital an die zuständige Reisevorbereitungsstelle weitergeleitet. Von dort können sie – ohne weitere Dateneingabe – direkt aus
Seite 158
Abbildung A-7: Online-Antragstellung mit dem TMS
dem System heraus mittels strukturierter Mail an das Reisebüro weitergegeben werden. Gleichzeitig werden die Daten für die Abrechnungsstelle und den elektronischen
Rechnungsabgleich vorgehalten.
Der TMS-Workflow ermöglicht eine umfassende Verschlankung und Optimierung des
Prozesses „Dienstreise“ vom Reiseantrag über die Genehmigung und die Reisemittelbestellung bis zur Reisekostenabrechnung. Die Daten sind für alle vier Vorgänge
stets vollständig im System verfügbar. Post- und Botenwege können – derzeit mit
Ausnahme der Belegübersendung – entfallen. Auch manuelle Eingaben durch die
Abrechnungsstelle entfallen – die bei wiederholter Dateneingabe möglichen Übertragungsfehler werden dadurch vermieden.
Online-Buchungssysteme, wie z. B. die Bahn Internet Booking Engine (BIBE) und das
Online-Buchungstool des Hotel Reservation System (HRS), runden die Möglichkeiten
der Prozessoptimierung ab. Mit ihrer Hilfe können Buchungen von Dienstreisenden
selbst entsprechend den Vorgaben des Travel Managements ausgeführt werden.
Sonderkonditionen, die mit Leistungserbringern verhandelt wurden, sind im System
hinterlegt.
Das TMS des Bundes wird bereits von einer hohen Anzahl von Behörden genutzt.
Seite 159
A.9.5 Elektronischer Rechtsverkehr
Die Dienstleistung „Elektronischer Rechtsverkehr“ umfasst die Übermittlung verfahrensrelevanter Erklärungen samt Anlagen auf elektronischem Wege durch Verfahrensbeteiligte an Gerichte sowie Mitteilungen von diesen an Verfahrensbeteiligte
ebenfalls auf elektronischem Wege170. Die Einführung des Elektronischen Rechtsverkehrs lohnt sich insbesondere im Bereich standardisierter und sich oft wiederholender
Vorgänge.
Ansprechpartner
Dr. Klaus Strößner
post@dpma.de
Deutsches Patent- und Markenamt
Zweibrückenstr. 12
80331 München
Tel. +49 89 2195-3927
Fax +49 89 2195-2058
seit dem 1. Quartal 2004
Der Elektronische Rechtsverkehr hat als Ausgangspunkt das Verfahren der elektronischen Patentanmeldung beim Deutschen Patent- und Markenamt. Die Dienstleistung
weist Parallelen zu elektronischen Antragsverfahren (Dienstleistungstyp 5) auf, denen
ungefähr ein Fünftel aller Dienstleistungen zugeordnet sind. Mit dem Ausbau dieser
Anwendung zu einer EfA-Dienstleistung können eine Vielzahl von Anmelde- und
Antragsverfahren umgesetzt werden, bei denen Anforderungen an Gesetzeskonformität, Datenschutz und -sicherheit sowie Integrierbarkeit in die Fachverfahren des
Dienstleistungsanbieters zu erfüllen sind.
Die elektronische Patentanmeldung ist bereits realisiert und ist für die Öffentlichkeit
nutzbar. Eine Harmonisierung des Verfahrens mit dem des Europäischen Patentamts
ist ebenfalls erfolgreich abgeschlossen. Über den eingerichteten Nutzerbeirat können
weitere Ressorts und Behörden ihre Anforderungen an den Elektronischen Rechtsverkehr einbringen und abstimmen.
A.9.6 Vorbereiten politisch-regulativer Entscheidungen
Gegenstand der EfA-Dienstleistung „Vorbereiten politisch-regulativer Entscheidungen“ sind Regierungsvorlagen. Ziel ist es, den Dokumentenaustausch im Rahmen der
Vorbereitung und Verabschiedung von Gesetzesvorlagen und Verordnungen zwischen den beteiligten Ressorts und dem Bundeskanzleramt sowie dem Bundesrat
und Bundestag medienbruchfrei zu ermöglichen. Die Beteiligten sollen damit sämtliche Abstimmungs- und Entscheidungsprozesse dokumentieren und die Vorlagen zwischen den beteiligten Stellen austauschen können. Gleichzeitig soll das Datenformat
helfen, die Drucklegung zu beschleunigen.
170. Der Verkehr von Dokumenten innerhalb einer Behörde oder eines Gerichtes ist nicht Gegenstand
des elektronischen Rechtsverkehrs und der EfA-Dienstleistung.
Seite 160
Ansprechpartner
Herr Klaus Brandenburg
klaus.brandenburg@bk.bund.de
Bundeskanzleramt
Willy-Brandt-Platz 1
10557 Berlin
Tel. +49-1888-400-2149
Verfügbarkeit der ersten Ausbaustufe
seit Oktober 2004
Verfügbarkeit der zweiten Ausbaustufe 4. Quartal 2005
Arbeitshilfen im Verfahren sollen die Mitarbeiterinnen und Mitarbeiter bei der Erstellung von Entwürfen unterstützen. So kann die Rechtsprüfung unmittelbar in das
System eingebunden werden. Das spart Arbeitszeit und Kosten. Die Druckereien können Bundestagsdrucksachen und verabschiedete Gesetze schneller produzieren und
veröffentlichen.
Teilprojekte der Dienstleistung sind federführend im Bundeskanzleramt sowie in verschiedenen Bundesministerien angesiedelt.
Das Teilprojekt „E-Gesetz“ beim Bundesministerium für Gesundheit und Soziale
Sicherung (BMGS), das die detaillierte Beschreibung und elektronische Abbildung
des Gesetzgebungsprozesses durch Einsatz eines Vorgangsbearbeitungssystems
Bundestag
AA
Bundesrat
Bundeskanzleramt
BPA
BMI
BKM
BMJ
BMZ
BMF
BMBF
Elektronische
Dokumente
BMU
BMWA
BMVEL
BMVBW
BMGS
BMVg
BMFSFJ
Abbildung A-8: Vorgang elektronischer Austausch von Regierungsvorlagen
Seite 161
(VBS) abbilden soll, hat Schnittstellen zu den anderen Teilprojekten „Planung Online“,
„Abstimmung Online“ und zu IT-Lösungen des Bundeskanzleramtes. Ein VBS nach
dem DOMEA-Standard soll dazu eingesetzt werden.
Mit dem Modul „Abstimmung Online“, dem zweiten Teilprojekt des BMGS, wird
zusätzlich eine web-basierte Anwendung zur Pflege kontextbezogener Stellungnahmen auf Grundlage der Basiskomponente CMS (Government Site Builder) entwickelt.
Das Teilprojekt „Elektronische Zuleitung“ des Bundeskanzleramtes ermöglicht das
Austauschen von Regierungsvorlagen in einem sicheren, signierbaren Format über
die Schnittstellen zwischen allen beteiligten Ressorts. Die Umsetzung erfolgt in zwei
Etappen: Die Vorschaltlösung ist seit Oktober 2004 im Einsatz, die Ausbaulösung
wird die verschiedenen im Einsatz befindlichen Fachverfahren zu einer modernen ITLösung zusammenführen.
Das Bundesministerium der Justiz (BMJ) verfolgt das Projekt „Elektronische Veröffentlichung von Verordnungen und Bekanntmachungen im amtlichen Teil des elektronischen Bundesanzeigers“. Der amtliche Teil des elektronischen Bundesanzeigers
(eBAnz) wird seit dem Jahr 2002 für die elektronische Veröffentlichung einzelner amtlicher Bekanntmachungen genutzt. Nun soll auch die elektronische Verkündung von
Rechtsverordnungen ermöglicht werden.
Weitere Projekte sind beim Bundesministerium für Wirtschaft und Arbeit (BMWA) und
beim Bundesministerium für Familie, Senioren, Frauen und Jugend (BMFSFJ) angesiedelt. Das BMWA führt im Rahmen von „Planung Online“ eine Software-Lösung zur
Unterstützung der politischen Planung ein. Beim BMFSFJ wird ein Vorgangsbearbeitungssystem eingeführt, wobei einer der drei Kernprozesse, die in diesem Rahmen
elektronisch abgebildet werden, ebenfalls im Kontext der Vorbereitung politisch-regulativer Entscheidungen steht.
Die erste Ausbaustufe der EfA-Dienstleistung „Vorbereiten von politisch-regulativen
Entscheidungen“ ist seit Oktober 2004 im Einsatz. Die zweite, parallel entwickelte
Ausbaustufe soll im 4. Quartal 2005 zur Verfügung stehen. Die Integration der Basiskomponente Virtuelle Poststelle wird derzeit geprüft.
A.9.7 Personalwerbung und -gewinnung
Das Bundesministerium der Verteidigung (BMVg) stellt mit der EfA-Dienstleistung
„Personalwerbung und -gewinnung“ Inhalte und Funktionalitäten zur Verfügung, die
von anderen Ressorts für ihre eigene Personalbeschaffung verwendet werden können.
Ansprechpartner
Referat IT1
BMVgIT1@bmvg.bund400.de
Bundesministerium der Verteidigung
Fontainengraben 150
53123 Bonn
Seite 162
Verfügbarkeit der ersten Ausbaustufe
seit Juni 2004
Verfügbarkeit der zweiten Ausbaustufe
Dezember 2005
Der Bereich Personalwerbung bietet ein umfassendes und aktuelles Informationsangebot über die Berufsbilder und Karrieremöglichkeiten innerhalb des Ressorts. Die
Bundeswehr stellt sich so als Arbeitgeber mit Laufbahnen, Beschäftigungsmöglichkeiten und Einstellungsmodalitäten vor. Das Informationsangebot wird auf die Situation
der Interessenten ausgerichtet und nach Schul- bzw. Berufsabschluss sowie Fachbereichen gegliedert. Es ist somit ein effektives Marketinginstrument für den modernen
und kundenorientierten Arbeitsplatz in der Bundesverwaltung.
Im Bereich Personalgewinnung findet der Interessent die aktuellen Arbeitsplatzangebote der Behörden im Ressort. Dies können konkrete Stellenausschreibungen oder
Angebote im Rahmen der Nachwuchsgewinnung sein. Wer sich darauf bewerben
möchte, kann dies online tun. Die Funktionalität ist so gestaltet, dass die Daten aus
der Online-Bewerbung in das Backend-System der Behörde übertragen werden.
Bearbeitungszeiten lassen sich hiermit zum Nutzen der Behörde und der Bewerber
reduzieren.
Info über Berufsmöglichkeiten, Stellenangebote
Online-Bewerbung
§
Sie haben...
... Haupt-/ Realschulabschluss
... Eine abgeschlossene
technische Berufsausbildung
@
... Allgemeine Hoch- oder
Fachhochschulreife
Wir stellen ein
... Beamte im gehobenen nicht
technischen Dienst
mehr
... Beamte im gehobenen
technischen Dienst
mehr
Bewerbung für den gehobenen
nicht technischen Dienst
Name:
Vorname:
Geburtstag/ -ort:
Abbildung A-9: EfA-Dienstleistung Personalwerbung und -gewinnung
Ressorts, die die EfA-Dienstleistung einsetzen, können die durch das BMVg eingestellten Informationen an ihre spezifischen Fachaufgaben anpassen und ihr Arbeits-
Seite 163
platzangebot im Rahmen einer einheitlichen Struktur präsentieren. Dies kann die
Grundlage bilden für ein gemeinsames „Karriereportal“ der Bundesverwaltung auf
www.bund.de mit Links zu den Angeboten der Ministerien und Behörden.
Die erste Ausbaustufe der Personalwerbung und -gewinnung, die zur CeBit 2004
online gestellt wurde171, umfasst die Grundstruktur für das zielgruppenorientierte
Informationsangebot (zunächst ausgerichtet auf militärisches Personal) sowie die
Online-Bewerbung. Im Dezember 2005 werden die Informationen und Arbeitsplatzangebote für das zivile Personal im technischen und nichttechnischen Dienst ergänzt.
Auch die Nutzung der Basiskomponente Formularserver ist vorgesehen.
A.9.8 ArchiSafe (Langzeitarchivierung)
Die Physikalisch-Technische Bundesanstalt (PTB) plant ab 2005 die schrittweise
Umsetzung der Dienstleistung „Metrologische Dienstleistungen Online – Antragsverfahren auf Prüfung, Zulassung, Akkreditierung von Geräten, Laboren und Verfahren“.
Für die in diesem Zusammenhang erstellten Dokumente, z. B. Zertifikate, Prüfergebnisse, rechnungsbegründende Unterlagen, amtlichen Bescheide und andere hoheitliche Dokumente, bestehen sehr unterschiedliche Aufbewahrungsfristen. Für einen
durchgängigen, medienbruchfreien elektronischen Geschäftsprozess ist es daher
unabdingbar, für die elektronische Ablage rechtsverbindlicher und rechnungsbegründender Unterlagen eine Archivlösung zu schaffen, welche neben der sicheren Aufbewahrung der Unterlagen auch die Anforderungen gemäß SigG/SigV erfüllt.
Ansprechpartner
Herr Dipl. Wirt.-Inform. Tobias Schäfer
tobias.schaefer@ptb.de
Physikalisch-Technische Bundesanstalt
Bundesallee 100
38116 Braunschweig
Tel. 0531/592-2456
Fax 0531/592-692456
2005
Im Rahmen des Projektes „ArchiSafe“ werden die Grundlagen für eine kostengünstige und skalierbare elektronische Archivlösung definiert und in Form eines Pilotsystems realisiert. Denn der in der Behördenlandschaft immer häufiger vollzogene
Wechsel zu einer elektronischen Dokumenteninfrastruktur mit elektronisch signierten
Dokumenten bleibt unvollständig ohne ein adäquates elektronisches Archiv, das die
langfristige und rechtssichere Aufbewahrung und Verfügbarkeit elektronischer Informationen gewährleistet. Bedingt durch die technologische Weiterentwicklung in der
Computer- und Softwareindustrie sind sowohl die Lebensdauer elektronischer Dokumente als auch die Sicherheit elektronischer Signaturen zeitlich begrenzt. Ohne ein
171. siehe http://www.bundeswehr-karriere.de/
Seite 164
geeignetes Archivierungssystem wäre ein „Wertverlust“ elektronischer Dokumente
die Folge.
Daraus ergeben sich vor allem zwei Konsequenzen für elektronische Dokumenteninfrastrukturen mit signierten Dokumenten:
a. Die elektronische Dokumenteninfrastruktur muss die langfristige Überlieferung
elektronischer Dokumente mindestens unterstützen, d. h. der Zugriff auf elektronische Dokumente muss auch für längere Zeiträume mit einem vertretbaren wirtschaftlichen und zeitlichen Aufwand möglich sein, und
b. die elektronische Dokumenteninfrastruktur muss die Rechtssicherheit, insbesondere die Authentizität und Integrität der elektronischen Dokumente dauerhaft bis
zum Erreichen der geschäftsprozessrelevanten Aufbewahrungszeit sicherstellen,
d. h. sowohl die bildliche und inhaltliche Übereinstimmung mit den originären
Dokumenten gewährleisten als auch eine so genannte „Resignatur“ ermöglichen.
Vorrangiges Ziel des Projektes „ArchiSafe“ in der PTB ist es daher, am Beispiel einer
vorhandenen elektronischen Dokumenteninfrastruktur (Projekte MELODI, e-Vergabe,
Ex-Info Vorgang Online) eine ebenso rechtssichere wie skalierbare elektronische
Archivinfrastruktur zu definieren und beispielhaft zu implementieren.
Als EfA-Dienstleistung plant „ArchiSafe“, bundeseinheitliche Standards für die Langzeitarchivierung von Dokumenten zu erreichen, z. B. ein standardisiertes Datenaustauschformat – Stichwort „XArchiv“. So kann die Möglichkeit für die Nutzung sowohl
zentraler als auch dezentraler Archive bis hin zum Bundesarchiv geschaffen werden.
Das Projekt „ArchiSafe“ wird in drei Stufen entwickelt. In der ersten Stufe werden
zunächst ein Fachkonzept und ein DV-technisches Konzept als Basis für eine detaillierte Leistungsbeschreibung entwickelt. Auf dieser Grundlage soll in der zweiten
Stufe ein erster voll funktionsfähiger Pilot installiert werden, der es erlaubt, Erfahrungen vor allem hinsichtlich der Skalierbarkeit und der Anbindung von Back-OfficeSystemen zu gewinnen. In einer dritten Stufe soll – nach Verallgemeinerung der
Erfahrungen und Erkenntnisse sowie der Verfeinerung der Leistungsbeschreibung –
eine vollständige Realisierung und Einbettung in die elektronische Dokumenteninfrastruktur der PTB erfolgen.
A.9.9 Ressortspezifisches Haushaltsaufstellungsverfahren (HAV)
Die Dienstleistung „Ressortspezifisches Haushaltsaufstellungsverfahren“ des Bundesministeriums für Wirtschaft und Arbeit (BMWA) unterstützt den gesamten Haushaltsaufstellungsprozess und die Vorbereitung der Haushaltsrechnung von der Planung über die Verhandlung bis hin zur Verabschiedung in einem Ressort.
Seite 165
Ansprechpartner
Thomas Grashof
thomas.grashof@bmwa.bund.de
Bundesministerium für Wirtschaft und Arbeit
Scharnhorststr. 34-37
11019 Berlin
Tel. 01888/615-7961
Fax 01888/615-507961
2005
Über eine Web-Eingabe können autorisierte Stellen (Fachreferate, nachgeordnete
Behörden u. a.) ihre Anmeldungen zum Haushalt auf ihre Titel im HAV einstellen und
den Stand der weiteren Bearbeitung verfolgen. Die Steuerung, wer welche Titel in
welcher Version einsehen darf, erfolgt im HAV.
Ergebnisse werden in normierter Form an das Bundesministerium für Finanzen (BMF)
weitergegeben. Die in der HAV-Datenbank aufgenommenen Haushaltsdaten des
BMWA werden außerdem per Schnittstelle an die für die Aufstellung des Gesamthaushaltes relevante Datenbank des BMF geschickt. Es folgt im BMWA ein manueller
Abgleich der aufstellungsrelevanten Daten, die nicht elektronisch übertragen werden
können. Danach wird die formelle Ressortanmeldung gegenüber dem BMF abgeschlossen.
Es können bis zu 900 Versionen der jeweiligen Pläne angelegt werden, sodass jeder
Schritt des Planungs- und Verhandlungsprozesses im BMWA archiviert werden kann.
Alternierende Pläne, z. B. die des Spiegelreferates im BMF und des Haushaltsreferates in einem Ressort sind zusammen in einer Verhandlungsversion darstellbar und
ermöglichen gegebenenfalls eine „Online-Verhandlung“, in der die beiden Parteien
sowohl ihre eigenen Vorstellungen wie die der anderen Partei im Vergleich angezeigt
bekommen. Spezialfunktionen unterstützen das Herausstellen der „Streitpunkte“
sowie die Darstellung von Verhandlungsergebnissen.
Nach dem Entwurf werden die Beratungen ressortintern durch weitere Versionen
unterstützt. Sämtliche Elemente, die dem BMF zur Verfügung gestellt werden müssen, liefert das System auf Knopfdruck. Die Haushaltsdaten können zu jeder Zeit auf
verschiedenen Medien (u. a. PDAs) flexibel zur Verfügung gestellt werden.
Ist das aufzustellende Haushaltsjahr vorbei, wird durch das derzeit noch manuelle
Erfassen der Ist-Werte und der Jahresreste aus dem HKR-Verfahren die Soll-IstBetrachtung mit Abweichungsbegründungen dargestellt und gedruckt oder als PDF
bereitgestellt. Auf Basis der bereitgestellten Ist-Werte kann die Titelentwicklung leicht
nachverfolgt und als Grundlage für die Planung des nächsten Jahres herangezogen
werden. Eine automatisierte Datenübernahme der Ist-Werte aus den Haushaltsbewirtschaftungssystemen ist derzeit in Vorbereitung.
Das Haushaltsaufstellungsverfahren ist bereits in einigen Ressorts bzw. Behörden im
Einsatz, wie z. B. beim Bundesrechnungshof, dem Bundesministerium für Gesundheit
Seite 166
und Soziale Sicherung und dem Bundesministerium der Verteidigung. Weitere Bundesministerien sind am Einsatz interessiert. Derzeit bereitet das BMWA ein HostingAngebot für kleinere Ressorts vor.
Haushaltsaufstellungsverfahren
Plan
Planjahr
Rechnung
Haushaltsplanung
Mittelanforderungen/Voranschläge
Versionierung
Haushaltsverhandlung
Verhandlungsversionen
(Streit-)Begründung/Kommentare
Bewirtschaftung
• Ausgaben
• Einnahmen
• Verpflichtungen
Parlamentarisches
Verfahren
Haushaltsrechnung
Gegenüberstellung Soll & Ist
(außerplanmäßige und
überplanmäßige Ausgaben
und Einnahmen, Jahresreste,
Begründungen)
Haushaltsentwurf
Ergänzungsantrag
Verabschiedung
Haushaltsgesetz
Nachtrag
Rechenschaftsbericht
Rechnungshof
1 Jahr
Abbildung A-10: Komponenten des Haushaltsaufstellungsverfahrens
A.9.10 Online-Beratung
Die Bundeszentrale für gesundheitliche Aufklärung (BZgA) berät zu Schwerpunktthemen der gesundheitlichen Aufklärung wie z. B. Ernährung, Sexualität, Schwangerschaft, Aids, Drogen, Alkohol, Rauchen usw. Mit der Dienstleistung „Online-Beratung“
der BZgA wird das bisherige Online-Informationsangebot durch neue Module zur
Kommunikation mit den Kunden ergänzt bzw. erweitert. Bisher findet diese Kommunikation im Sinne einer Beratung seitens der Behörden überwiegend als personalintensive Telefonberatung oder durch das individuelle Beantworten von E-Mails statt.
Ansprechpartner
Manfred Brandt
Manfred.brandt@bzga.de
Bundeszentrale für gesundheitliche Aufklärung
Ostmerheimerstraße 220
51109 Kön
Tel. 0221/8992-0
Fax 0221/8992-300
Seite 167
2005
Mit der „Online-Beratung“ wird die Möglichkeit geschaffen, Beratung über das Internet
und andere Medien durchzuführen und Schnittstellen zur Telefonberatung zu schaffen, die in einigen Bereichen auch weiterhin unverzichtbar ist. Die neuen Online-Beratungsmodule ermöglichen, abhängig vom Thema, eine mehr oder weniger starke Entlastung der telefonischen und persönlichen Beratung. Viele der bisher telefonisch
beantworteten Anfragen können auch standardisiert unter Nutzung einer Wissensdatenbank beantwortet werden. Hierfür eignen sich spezifische über das Internet nutzbare Beratungsmodule.
Die Dienstleistung „Online-Beratung“ der BZgA beinhaltet folgende verschiedene
Beratungsformen: FAQs, Avatar, Live-Chat, E-Mail Auto-Response-System, E-MailBeratung, Chat-Beratung, Diskussionsforen.
Bei der BZgA soll diese Dienstleistung für verschiedene Beratungsthemen, speziell
aber zuerst für das Thema „Essstörungen“ eingesetzt werden. Weitere Themenbereiche der BZgA, in denen anschließend Funktionalitäten der Online-Beratung eingeführt werden sollen, sind unter anderem die „Raucherberatung“, in der aufgrund aktueller Kampagnen ein sehr starkes Wachstum der Anfragen erwartet wird, und die
„Schwangerenberatung“. Die Auswahl der in der BZgA pro Thema einzusetzenden
Beratungsmodule erfolgt im Rahmen der Konzeptionsphase.
Die BZgA erwartet aus der Realisierung des beschriebenen Beratungsangebotes folgenden Nutzen:
a. Bessere Erfüllung der an die Behörde gestellten Informations- und Beratungserwartungen
b. Erhöhung der Quantität und der Qualität der Beratung
c. Erhöhung der Beratungs- und Informationsverfügbarkeit der Behörde (bisher landen z. B. 60% der Beratungssuchenden Anrufer in der BZgA beim Anrufbeantworter der Telefonberatung)
d. Bessere Möglichkeiten des zielgruppenorientierten Zugangs zum Informationsund Beratungsangebot der Behörde
e. Entlastung der Fachreferate und der qualifizierten Fachberater der Telefonberatung von Informations- und Beratungsleistungen, die wirtschaftlicher durch OnlineAngebote und/oder standardisiert auf Basis einer Wissensdatenbank erbracht
werden können
f. Minimierung der Kosten qualifizierter psychosozialer Beratung durch gegenseitige
Referenzierung der Online-Beratungsangebote mit externen Beratungsstellen
(z. B. Vereinen, Wohlfahrtsverbänden und freien Trägern) und durch Weiterleitung
des Klienten zur Beratung durch diese Stellen (möglichst im lokalen Umfeld des
Klienten) im Anschluss an die Erstberatung
Die erste Version der Online-Beratung mit den wesentlichen Beratungsmodulen wird
voraussichtlich im Herbst 2005 zur Verfügung stehen.
Seite 168
A.10 Kompetenzzentren
Zur Unterstützung der E-Government-Initiative BundOnline 2005 wurden vier Kompetenzzentren eingerichtet. Vorrangige Aufgabe der Kompetenzzentren ist die Bereitstellung von Know-how für die dezentrale Umsetzung der Online-Dienstleistungen.
Dies umfasst insbesondere die Beratung bei der Implementierung der Basiskomponenten und der Online-Dienstleistungen.
A.10.1 Kompetenzzentrum Zahlungsverkehrsplattform
Das Kompetenzzentrum Zahlungsverkehrsplattform stellt für die gesamte Bundesverwaltung Methoden und Konzepte zum Aufbau und für den Betrieb von ePaymentAnwendungen zur Verfügung. Zusätzlich sammelt es technisches Know-how zur
Anbindung von E-Shops und anderen Verfahren an die zentrale Zahlungsverkehrsplattform und bereitet dieses auf. Es führt Präsentationen und Beratungen zum
Thema ePayment des Bundes durch und unterstützt die Behörden technologisch bei
der Integration der Zahlungsverkehrsplattform. Weiterhin wird der Markt bezüglich
weiterer Payment-Verfahren wie z. B. Micropayments oder Mobile Payments beobachtet. Seit dem 31. Juli 2003 steht das Kompetenzzentrum zur Verfügung.
Ansprechpartner
Herr Volker Walgenbach
ePayment@bff.bund.de
Bundesamt für Finanzen
Friedhofstrasse 1
53225 Bonn
Tel. +49 228 406-2905
Fax +49 228 406-2241
A.10.2 Kompetenzzentrum Datensicherheit
Das Kompetenzzentrum Datensicherheit im Bundesamt für Sicherheit in der Informationstechnik (BSI) berät die Behörden in Fragen der Sicherheit von E-GovernmentAnwendungen und beim Einsatz der digitalen Signatur. Für die Übertragung sensibler
Daten über das Internet gilt es, vertrauenswürdige Infrastrukturen zu schaffen, Verwaltungsprozesse neu zu strukturieren und vorhandene Anwendungen der Behörden
mit geeigneten Sicherheitslösungen auszustatten. Hierdurch wird eine reibungslose,
rechtsverbindliche und vertrauliche Online-Kommunikation der externen Umwelt mit
der Bundesverwaltung ermöglicht und eine sichere innerbehördliche Kommunikation
gewährleistet.
Darüber hinaus werden über das Kompetenzzentrum Datensicherheit alle Sicherheitsfragen in Zusammenhang mit der Virtuellen Poststelle behandelt sowie Kommunikations- und Migrationskonzepte zur Einbindung der Virtuellen Poststelle in bestehende Behördeninfrastrukturen erarbeitet.
Seite 169
Ansprechpartner
Referat I 1.1
referati11@bsi.bund.de
Postfach 200363
53133 Bonn
A.10.3 Kompetenzzentrum Content Management System
Das Kompetenzzentrum Content Management System (CMS) berät Behörden der
Bundesverwaltung, die für die Online-Bereitstellung ihrer Dienstleistungen die Basiskomponente CMS nutzen wollen, bei der Implementierung. Zudem wirkt es konzeptionell an der bedarfsgerechten Weiterentwicklung der Basiskomponente CMS mit und
steht als Ansprechpartner für Optimierungsvorschläge und individuelle Bedarfsanpassung zur Verfügung.
Ansprechpartner
Herr Claus Hackethal
claus.hackethal@bva.bund.de
50728 Köln
Tel. +49 1888 358-1549
Fax +49 1888 358-3899
A.10.4 Kompetenzzentrum Vorgangsbearbeitung, Prozesse und Organisation
Zur Realisierung von E-Government-Lösungen ist die vorherige Optimierung der
davon betroffenen Geschäftsprozesse eine zwingende organisatorische Voraussetzung, um tatsächliche Effizienzgewinne nutzen zu können. Eine IT-Lösung soll demnach nicht auf den althergebrachten Ist-Prozessen, sondern auf optimierten Soll-Prozessen basieren.
Das Kompetenzzentrum Vorgangsbearbeitung, Prozesse und Organisation (CC
VBPO), angesiedelt im Bundesverwaltungsamt, unterstützt bei der Durchführung von
Geschäftsprozessoptimierungen und berät produktneutral bei der Einführung von
Vorgangsbearbeitungssystemen.
Ansprechpartner
Herr Stefan Salz
stefan.salz@bva.bund.de
50728 Köln
Tel. +49 1888 358-1547
Fax +49 1888 358- 71 1547
Seite 170
Zielsetzung
Oberstes Ziel des Kompetenzzentrums ist die Unterstützung der Bundesbehörden bei
der eigenverantwortlichen und wirtschaftlichen Umsetzung von BundOnline-2005Dienstleistungen. Den Bundesbehörden soll die fachliche und methodische Unterstützung zur Anpassung der Aufbau- und Ablauforganisation sowie der prozessualen
Verwaltungsabläufe angeboten werden. Ziel ist es hierbei, nachstehende Nutzenaspekte für die Behörden zu generieren:
a. kostenneutrale, kundenorientierte und professionelle Unterstützung der Bundesbehörden
b. standardisiertes Vorgehen für die Bereitstellung von Online-Dienstleistungen
c. Schaffung von nachhaltiger Kompetenz innerhalb der Behörden durch Coaching
von Projektverantwortlichen
d. Entwicklung effizienter Geschäftsprozesse und zielgerechte Informationsbereitstellung
e. aufeinander abgestimmte, technische Lösungen der Vorgangsbearbeitung und
optimierte Geschäftsprozesse
Leistungsumfang
Zur Realisierung der oben genannten Ziele bietet das Kompetenzzentrum den Bundesbehörden folgende Leistungen an:
a. Unterstützung bei der Vorbereitung von Vergaben für die Erstellung von Prozessanalysen und Grobkonzepten zur Einführung von Vorgangsbearbeitungssystemen
b. Unterstützung bei der Analyse und Reorganisation besonders komplexer Prozesse
c. Unterstützung bei der Einführung von Vorgangsbearbeitungssystemen
d. Erstellung von Musterprozessen auf Basis ausgewählter Dienstleistungen und
Basiskomponenten
e. Durchführung von projektspezifischen Informationsveranstaltungen und Workshops
f. Entwicklung einer Toolbox zur Bereitstellung von Methoden und Konzepten zur
Prozessanalyse und -optimierung sowie zur Einführung einer IT-gestützten Vorgangsbearbeitung
g. Sammlung von Praxisbeispielen auf Grundlage ausgewählter Beratungsprojekte
Vorgehen im Rahmen von Beratungsprojekten
Im Rahmen der Beratungsprojekte werden optional die folgenden Phasen durchlaufen:
a. In der Phase der Analyse werden die Behörden bei der Untersuchung von Optimierungspotenzialen unterstützt.
Seite 171
b. In der Konzeptionsphase wird die Formulierung von funktionalen Anforderungen
an die technischen Komponenten auf Basis des Prozessmodells unterstützt.
c. In der Phase der Realisierung wird die Behörde bei der eigenständigen Umsetzung der neuen Prozesse sowie beim Testen unterstützt.
d. Die Inbetriebnahme der Systeme in der Einführungsphase begleitet das CC VBPO
bei Bedarf mit einem Coaching.
Analyse
Konzeption
Realisierung
und Test
Kick-off
Aufnahme
Ist-Prozesse
SollKonzeption
QualitätsSicherung
Pilotierung
Projektplanung
Bewertung
der
Prozesse
AnforderungsSpezifikation
Prozessrealisierung
Rollout
Vorbereitung
Einführung und
Inbetriebnahme
Arbeitsschritte
Vergabe
Vom CC VBPO unterstützte Teilschritte
Abbildung A-11: Phasen von Beratungsprojekten
Seite 172
Anhang B Anwendung von Basiskomponenten
Dieser Anhang soll verdeutlichen, wie Basiskomponenten untereinander zusammenwirken und in die Prozesse einer Behörde integriert werden können. Die Ausführungen basieren auf der Musterarchitektur Allgemeine Antragsverfahren [PGBO 2005c].
Die Musterarchitektur Allgemeine Antragsverfahren beschreibt das Zusammenspiel
von BundOnline-Basiskomponenten und weiterer notwendiger Komponenten aus
dem Blickwinkel einer antragsorientierten Dienstleistung. Somit ist die Musterarchitektur Allgemeine Antragsverfahren vor allem eine Integrationsarchitektur, bei der die
Basiskomponenten als Black Boxes verstanden werden.
Die für die Architektur Antragsverfahren verwendeten Integrationsgrundmuster sowie
die grundlegenden Begrifflichkeiten werden in dem Dokument „Grundlagen der Integration“ beschrieben [PGBO 2005b]. Eine ausführliche Version der Musterarchitektur
Antragsverfahren findet sich unter http://www.wmsbundonline.de/.
Die Musterarchitektur liefert Systemarchitekten und IT-Verantwortlichen, die eine
Dienstleistung mit Antragscharakter planen oder konzipieren wollen, konkrete Hilfestellungen bei ihrem Vorhaben, indem es das Zusammenspiel aller Komponenten
einer Dienstleistung aus verschiedenen Blickwinkeln darstellt. Die Beschreibungen
können als Grundlage einer fachlichen und technischen, dienstleistungsspezifischen
Konzeption und zur Vorbereitung von Ausschreibungen verwendet werden, müssen
allerdings im Rahmen der Feinkonzeption detailliert und für die dienstleistungsspezifischen Belange konkretisiert werden.
B.1 Modellierung nach RM-ODP
Für die folgende Beschreibung werden die Viewpoints des Reference Model of Open
Distributed Processing – RM-ODP [ISO 1996] herangezogen.
B.1.1 Enterprise Viewpoint
Im Enterprise Viewpoint werden die typischen fachlichen Teilprozesse des Antragsverfahrens identifiziert und modelliert. Der Musterprozess Allgemeine Antragsverfahren [PGBO 2005a] beschreibt eine vollständig elektronische und medienbruchfreie
Bearbeitung eines Antrags sowohl durch den Antragsteller als auch durch die
Behörde. Er besteht aus vier Teilprozessen:
a. Antragsstellung (TP1)
b. Antragsannahme (TP2)
c. Antragsbearbeitung/Einleitung von Maßnahmen (TP3)
d. Bescheiderteilung (TP4)
Ein der Antragstellung vorausgehender Prozess der Formularerstellung und -bereitstellung durch die Behörde wird im Musterprozess nicht dargestellt.
Seite 173
B.1.2 Computational Viewpoint
Ausgehend von dem Musterprozess [PGBO 2005a] werden im Computational Viewpoint zunächst die Softwarekomponenten identifiziert, die zur Unterstützung der verschiedenen Teilprozesse notwendig sind. Die identifizierten Komponenten werden in
einer statischen Sicht zueinander in Beziehung gesetzt. Durch die Verwendung von
UML-Sequenzdiagrammen172 werden die dynamischen Abläufe zwischen den Komponenten und damit auch die Beziehung zum Enterprise-Viewpoint dargestellt.
Im Abschnitt Computational Viewpoint des Musterbeispiels Antragsverfahren „Computational Viewpoint des Musterbeispiels Antragsverfahren“ werden eine ReferenzSoftware-Architektur und ein Überblick über die Prozessschritte eines Antragsverfahrens erläutert.
B.1.3 Technology Viewpoint
Für die Modellierung eines Antragsverfahrens müssen frühzeitig die zur Unterstützung der einzelnen Teilprozesse benötigten Technologien identifiziert werden. Dazu
ist erforderlich festzulegen, wie Antragsstellung, Antragsannahme und Bescheiderteilung prinzipiell technologisch erfolgen sollen.
Eine detaillierte Diskussion der möglichen technologischen Varianten erfolgt in
[PGBO 2005c]. Die identifizierten technischen Alternativen zur Realisierung von
Antragsverfahren sind:
a. Web / OSCI
i. Online-Antragsstellung browser-basiert als Web-Formular mit anschließender
Signatur mittels OSCI
ii. Offline-Antragsstellung, bei der das Formular in einem Fat-Client (z. B. eine
Java-basierte Anwendung) ausgefüllt wird
b. Web / ohne OSCI
c. E-Mail
d. Papier
B.1.4 Weitere Viewpoints
Information und Engineering Viewpoint sowie eine Detaillierung des Technology
Viewpoint sind von den konkreten Anforderungen und Rahmenbedingungen der
Online-Dienstleistung abhängig und lassen sich somit nicht mustergültig für ein allgemeines Antragsverfahren beschreiben. Diese sind im Rahmen der Feinkonzeption
einer Dienstleistung zu berücksichtigen.
172. Die „Musterarchitektur BundOnline Allgemeine Antragsverfahren“ [PGBO 2005c] beschreibt Komponentendiagramme und Sequenzdiagramme für die einzelnen Teilprozesse von Antragsverfahren.
Seite 174
B.2 Computational Viewpoint des Musterbeispiels Antragsverfahren
B.2.1 Referenz-Software-Architektur für Antragsverfahren
Abbildung B-1 zeigt in vereinfachter Form die Referenz-Software-Architektur für
Antragsverfahren gemäß [PGBO 2005c] für die Variante „Web / OSCI“, OnlineAntragsstellung. Die Antragsdaten werden browser-basiert eingetragen und anschließend mittels OSCI173 signiert und verschlüsselt. Die Bescheiderteilung erfolgt ebenfalls auf Basis einer OSCI-Nachricht.
W e b s e rv e r -K o m p o n e n te
Abbildung B-1: Referenz-Software-Architektur Antragsverfahren
173. 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, siehe auch „Online Service Computer Interface (OSCI)-Transport v1.2” auf Seite 107.
Seite 175
Die folgenden Basiskomponenten kommen dabei zum Einsatz:
a. Basiskomponente Formularserver174
Die Basiskomponente Formularserver generiert das Antragsformular und unterstützt den Anwender beim Ausfüllen. Sie wird in Abbildung B-1 in Form zweier
Teilkomponenten dargestellt, einer Komponente FMS, die als Web-ServerAnwendung läuft, und einer mit dieser interagierenden Komponente FMS-Outputsystem.
b. Basiskomponente Datensicherheit175
Die Basiskomponente Datensicherheit dient zur sicheren Übertragung persönlicher Daten und zum Signieren des ausgefüllten Formulars. Die Basiskomponente
Datensicherheit besteht aus den Teilkomponenten OSCI-Manager und OSCIBackend zur Bearbeitung von OSCI-Nachrichten und aus dem Kernsystem der
Virtuellen Poststelle (VPS)
Zudem werden bei der Antragsbearbeitung ein Fachverfahren und ein Vorgangsbearbeitungssystem (VBS) eingesetzt. Der Antragsannahme-Manager integriert die Basiskomponenten sowie die Vorgangsbearbeitung und das Fachverfahren zu einer
Online-Dienstleistung „Antragsverfahren“.
B.2.2 Überblick der Prozessschritte eines Antragsverfahrens
Als Schnittstelle zum Enterprise Viewpoint werden im Folgenden die einzelnen Teilaktivitäten eines Antragsverfahrens diskutiert.
Teilprozess 1: Antragsstellung
1. Der Antragsteller fordert über seinen Browser beim Formular-ManagementSystem (FMS) ein Formular an, das im Browser dargestellt wird.
2. Der Antragsteller füllt das Formular online aus und sendet es an das FormularManagement-System zurück.
3. Das Formular-Management-System führt eine Plausibilitätsprüfung durch.
4. Das FMS-Outputsystem bereitet das ausgefüllte und geprüfte Formular auf, das
jetzt aus einer druck- und signierbaren Fassung sowie den strukturierten Formulardaten besteht.
5. Das Formular-Management-System übergibt das Formular an den Browser des
Antragstellers, der sich das Formular ansehen kann. Mittels des JNLP-Protokolls176 wird ein OSCI-Client zur Signatur und Verschlüsselung des Formulars
aktiviert.
6. Der Antragsteller signiert und verschlüsselt das Formular mit dem OSCI-Client.
7. Der OSCI-Client übermittelt das signierte und verschlüsselte Formular als OSCINachricht an die Basiskomponente Datensicherheit.
174. siehe Abschnitt A.4 „Basiskomponente Formularserver“ auf Seite 132
175. siehe Abschnitt A.2 „Basiskomponente Datensicherheit („Virtuelle Poststelle“)“ auf Seite 119
176. siehe „Java Network Launching Protocol (JNLP) v1.5” auf Seite 75
Seite 176
8. Die Basiskomponente Datensicherheit prüft zunächst das Zertifikat der OSCINachricht und legt diese dann im OSCI-Postfach der Empfängerbehörde ab.
Teilprozess 2: Antragsannahme
9. Der Antragsannahme-Manager prüft regelmäßig die betreffenden OSCI-Postfächer der Basiskomponente Datensicherheit. Liegt ein neuer Antrag vor, so wird
dieser geprüft und in das Vorgangsbearbeitungssystem eingestellt.
10. Eine unverbindliche Empfangsbestätigung wird an den Antragsteller versandt.
Teilprozess 3: Antragsbearbeitung und Einleitung von Maßnahmen
Je nach fachlicher Spezifikation kann dieser Teilprozess primär innerhalb eines Fachverfahrens oder innerhalb eines Vorgangsbearbeitungssystems oder wie im Folgenden beschrieben gleichrangig in beiden Systemen ausgeführt werden.
11. Dem Antragsbearbeiter wird vom Vorgangsbearbeitungssystem der Antrag zugeteilt.
12. Der Antragsbearbeiter bearbeitet in seinem Fachverfahren den Antrag, bereitet
die Bescheiderstellung vor und stellt alle benötigten Daten bereit.
Teilprozess 4: Bescheiderteilung
13. Über einen VBS-Client initiiert der Antragsbearbeiter die Bescheiderstellung durch
das Vorgangsbearbeitungssystem.
14. Im Kontext des VBS wird der Inhalt des Bescheides erstellt und nach Fertigstellung an die Basiskomponente Datensicherheit übergeben.
15. Aus dem Bescheid wird eine OSCI-Nachricht erstellt.
16. Der Bescheid wird in Form der erstellten OSCI-Nachricht über die Basiskomponente Datensicherheit an den Antragsteller übermittelt.
Seite 177
Seite 178
Anhang C Vorlagen für eine SAGA-Konformitätserklärung
C.1 Konformitätserklärung
Für die Anwendung _______________________________________
Name der Anwendung, Verweis auf Leistungsbeschreibung
sind folgende Komponenten identifiziert worden, für die der Auftragnehmer die SAGAKonformität nach SAGA 2.1 anhand der beigefügten Checklisten erklärt.
Eigenentwickelte Komponenten
Eigenentwickelte Komponenten einer Anwendung werden vom Auftragnehmer nach
den Anforderungen des Auftraggebers erstellt und sind somit individuell auf den Einsatzzweck und die Systemarchitektur abgestimmte Bausteine der Anwendung.
Folgende eigenentwickelte Komponenten wurden identifiziert:
1. _________________________________________
2. _________________________________________
3. _________________________________________
4. _________________________________________
Produktkomponenten
Produktkomponenten einer E-Government-Anwendung sind fertige Software-Bausteine, die durch den Auftragnehmer lediglich installiert und konfiguriert werden.
Folgende Produktkomponenten wurden identifiziert:
1. _________________________________________
2. _________________________________________
3. _________________________________________
4. _________________________________________
________________________
________________________
Auftraggeber
Auftragnehmer
________________________
________________________
vertreten durch
vertreten durch
________________________
________________________
Ort, Datum, Unterschrift
Ort, Datum, Unterschrift
Seite 179
C.2 Checkliste für eigenentwickelte Komponenten
_______________________________
Name der Komponente, kurze Beschreibung
_______________________________
Name der zugehörigen Anwendung
Zur Erfüllung der SAGA-Konformität der oben genannten Komponente sind folgende
Kriterien und die entsprechenden in SAGA 2.1 beschriebenen Standards auf ihre
Relevanz für die Anwendung hin zu überprüfen:
a. Prozessmodelle
b. Datenmodelle
c. technische Standards und Architekturen
d. Nutzung vorhandener Basiskomponenten
Prozessmodellierung
Die zur Erstellung von Software-Komponenten erforderliche Modellierung von Prozessen wird in Kapitel Kapitel 8 beschrieben.
(Prozessmodellierung siehe Abschnitt 8.1)
Relevanter Konformitätsaspekt
Standard
SAGA-Konformität
gegeben? Ja / Nein
Datenmodellierung
Die zur Erstellung von Software-Komponenten erforderliche Modellierung von Daten
wird in Kapitel 8 beschrieben.
(Datenmodellierung siehe Abschnitt 8.2)
Standard
Seite 180
SAGA-Konformität
gegeben? Ja / Nein
Technische Standards und Architekturen
Die für die Erstellung einer Komponente relevanten technischen Standards und Architekturen ergeben sich aus den in den Kapiteln 8 und 9 beschriebenen Standards für
die IT-Architektur und den Standards für Datensicherheit.
Darüber hinaus werden aber auch in den Kapiteln 5, 6 und 7 Vorgehensweisen und
Konzepte beschrieben, die für die Umsetzung einer Komponente von Bedeutung sein
können. Diese Anforderungen müssen außerhalb der folgenden Tabellen abhängig
vom jeweiligen ausgeschriebenen Projekt durch den Auftraggeber konkretisiert werden.
Applikationsarchitektur (siehe Abschnitt 8.3)
Standard
SAGA-Konformität
gegeben? Ja / Nein
Client (siehe Abschnitt 8.4)
Standard
SAGA-Konformität
gegeben? Ja / Nein
Präsentation (siehe Abschnitt 8.5)
Standard
SAGA-Konformität
gegeben? Ja / Nein
Kommunikation (siehe Abschnitt 8.6)
Standard
SAGA-Konformität
gegeben? Ja / Nein
Seite 181
Anbindung an das Backend (siehe Abschnitt 8.7)
Standard
Datensicherheit (siehe Kapitel 9)
Standard
SAGA-Konformität
gegeben? Ja / Nein
SAGA-Konformität
gegeben? Ja / Nein
Basiskomponenten
Bei der Umsetzung von Komponenten ist zu überprüfen, ob die erforderlichen Funktionen zum Teil oder komplett durch eine der im Anhang A des SAGA-Dokuments
beschriebenen Basis- oder Infrastrukturkomponenten erbracht werden kann.
Nutzung von Basisbausteinen (siehe Anhang A)
Basisbaustein
Relevante Funktionen des
Basisbausteins
Zahlungsverkehrsplattform
Datensicherheit
Portal
Formularserver
CMS
IVBV
Verzeichnisdienst
Verwaltungs-PKI
Seite 182
Nutzung des Basisbausteins
vorgesehen? Ja / Nein
C.3 Checkliste für Produktkomponenten
_______________________________
Name der Komponente, kurze Beschreibung
_______________________________
Name der zugehörigen Anwendung
Zur Erfüllung der SAGA-Konformität der oben genannten Produktkomponente sind
die in SAGA 2.1 beschriebenen technischen Standards auf ihre Relevanz für den Einsatz des Produkts hin zu überprüfen.
Der Schwerpunkt der Prüfung liegt auf der Interoperabilität. Die SAGA-Konformität
eines Produkts erfolgt daher anhand der Benutzerschnittstellen, Datenaustauschformate, Kommunikationsschnittstellen und APIs dieser Lösung.
Technische Standards
Die für Schnittstellen und APIs eines Produkts relevanten technischen Standards
ergeben sich aus den in Kapitel 8 und 9 beschriebenen Standards für die IT-Architektur und den Standards für Datensicherheit.
Client (siehe Abschnitt 8.4)
Standard
Präsentation (siehe Abschnitt 8.5)
Standard
SAGA-Konformität
gegeben? Ja / Nein
SAGA-Konformität
gegeben? Ja / Nein
Seite 183
Kommunikation (siehe Abschnitt 8.6)
Standard
Anbindung an das Backend (siehe Abschnitt 8.7)
Standard
SAGA-Konformität
gegeben? Ja / Nein
SAGA-Konformität
gegeben? Ja / Nein
Datensicherheit (siehe Kapitel 9)
Seite 184
Standard
SAGA-Konformität
gegeben? Ja / Nein
Anhang D Literaturverzeichnis
[APEC]
National Office for the Information Economy / CSIRO: APEC e-Business: What do
Users need?, 2002
http://pandora.nla.gov.au/tep/25067
http://www1.cmis.csiro.au/Reports/APEC_E-commerce.pdf
[BOL]
Bundesministerium des Innern (Hrsg.): Umsetzungsplan für die eGovernmentInitiative BundOnline 2005, Dresden 2004
http://www.wms.bundonline.bund.de/ (im Bereich > BundOnline > Öffentlichkeitsarbeit > Umsetzungsplan)
[e-GIF]
Office of the e-Envoy: e-Government Interoperability Framework Version 6.0,
2004
http://www.govtalk.gov.uk/schemasstandards/egif.asp
http://www.govtalk.gov.uk/documents/e-gif-v6-0_.pdf
Office of the e_Envoy: Technical Standards Catalogue Version 6.1, 2004
http://www.govtalk.gov.uk/documents/TSCv6-1_2004-11-15.pdf
[GOSIP]
National Institute of Standards and Technology (NIST): U. S. Government Open
Systems Interconnection Profile (GOSIP), Version 2.0, 1990
http://www.elka.pw.edu.pl/ftp/pub/doc/gosip_v2.txt
[IDABC]
European Commission: Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens, 2005
http://europa.eu.int/idabc/
[ISO 1996]
ISO/IEC 10746-3: Information technology – Open Distributed Processing – Reference Model: Architecture, Genf 1996
[ITG 2000]
Informationstechnische Gesellschaft (ITG) im VDE: Electronic Government als
Schlüssel der Modernisierung von Staat und Verwaltung. Ein Memorandum des
Fachausschusses für Verwaltungsinformatik der Gesellschaft für Informatik e.V.
(GI) und des Fachbereichs 1 der Informationstechnischen Gesellschaft (ITG) im
Verband der Elektrotechnik, Elektronik und Informationstechnik (VDE), Bonn /
Frankfurt 2000
http://www.mediakomm.net/documents/memorandum.pdf
Seite 185
[Kudraß 1999]
Kudraß, Thomas: Describing Architectures Using RM-ODP, Online-Publikation,
1999
http://www.imn.htwk-leipzig.de/~kudrass/Publikationen/OOPSLA99.pdf
[Lenk et al. 2000]
Lenk, Klaus / Klee-Kruse, Gudrun: Multifunktionale Serviceläden, Berlin 2000
[Lenk 2001]
Lenk, Klaus: Über Electronic Government hinaus Verwaltungspolitik mit neuen
Konturen, Vortrag auf der 4. Fachtagung Verwaltungsinformatik in der Fachhochschule des Bundes für öffentliche Verwaltung am 5. September 2001
[Lucke et al. 2000]
Lucke, Jörn von / Reinermann, Heinrich: Speyerer Definition von Electronic
Government. Ergebnisse des Forschungsprojektes Regieren und Verwalten im
Informationszeitalter, Online-Publikation, 2000
http://foev.dhv-speyer.de/ruvii/Sp-EGov.pdf
[Neuseeland]
E-government Unit, State Services Commission, New Zealand: New Zealand
E-government Programme Home Page, 2005
http://www.e-government.govt.nz/
[PGBO 2005a]
Musterprozess Allgemeine Antragsverfahren, Kompetenzzentrum Vorgangsbearbeitung, Prozesse und Organisation (CC VBPO), BVA, Version 1.0
http://www.wmsbundonline.de/ (im Bereich > Dienstleistungen > Musterarchitekturen)
[PGBO 2005b]
Musterarchitektur, Grundlagen der Integration, Projektgruppe BundOnline, BMI,
Version 1.0
[PGBO 2005c]
Musterarchitektur Allgemeine Antragsverfahren, Projektgruppe BundOnline, BMI,
Version 1.0
[Schedler et al. 2001]
Schedler, Kuno / Proeller, Isabella: NPM, Bern / Stuttgart / Wien 2001
Seite 186
[Schreiber 2000]
Schreiber, Lutz: Verwaltung going digit@l. Ausgewählte Rechtsfragen der OnlineVerwaltung, in: Digitale Signaturen, in: Kommunikation & Recht Beilage 2 zu Heft
10/2000
[Schweiz]
Schweizerische Bundeskanzlei: CC Web BK – Kompetenzzentrum elektronischer
Behördenverkehr, Homepage der Beratungs-, Dienstleistungs- und Betriebsorganisation für den elektronischen Behördenverkehr (E-Government), 2005
http://www.admin.ch/ch/d/egov/index.de.html
Seite 187
Seite 188
Anhang E Übersicht der klassifizierten Standards
Advanced Encryption Standard (AES) ....................................................................112
Animated GIF ............................................................................................................89
Barrierefreie Informationstechnik Verordnung (BITV) ...............................................79
BSI, E-Government-Handbuch ...............................................................................103
BSI, IT-Grundschutzhandbuch ................................................................................102
Business Process Execution Language for Web Services (BPEL4WS) v1.1 ...........97
Cascading Style Sheets Language Level 2 (CSS2) ..................................................80
Comma Separated Value (CSV) ...............................................................................83
Directory Services Markup Language (DSML) v2 .....................................................95
Domain Name Services (DNS) .................................................................................94
ECMA-262 – ECMAScript Language Specification ...................................................81
Enhanced Compressed Wavelet (ECW) ...................................................................85
Entity Relationship Diagramme .................................................................................71
Extensible Hypertext Markup Language (XHTML) Basic ..........................................90
Extensible Hypertext Markup Language (XHTML) v1.0 ............................................80
Extensible Markup Language (XML) v1.0 ............................................... 72, 83, 84, 96
Extensible Stylesheet Language (XSL) v1.0 .......................................................80, 82
Extensible Stylesheet Language Transformation (XSLT) v1.0 .................................73
File Transfer Protocol (FTP) ......................................................................................94
Geography Markup Language (GML) v3.0 ...............................................................86
Graphics Interchange Format (GIF) ..........................................................................85
GZIP v4.3 ..................................................................................................................89
Hypertext Markup Language (HTML) v4.01 ............................................ 79, 81, 82, 84
Hypertext Transfer Protocol (HTTP) v1.1 ............................................................88, 94
Industrial Signature Interoperability Specification (ISIS)-MTT v1.1 ......... 105, 106, 109
Internet Message Access Protocol (IMAP) ...............................................................95
Internet Protocol (IP) v4 ............................................................................................93
Internet Protocol (IP) v6 ............................................................................................93
ISO 10646-1:2000 ...............................................................................................80, 81
ISO 8859-1 ................................................................................................................81
ISO 8859-15 ..............................................................................................................81
ISO/IEC 7816 ..........................................................................................................110
J2EE Connector Architecture v1.5 ......................................................................75, 97
Java 2 Platform, Enterprise Edition (J2EE) v1.4 .......................................................73
Seite 189
Java 2 Platform, Standard Edition (J2SE) v1.4 .........................................................74
Java Database Connectivity (JDBC) v3.0 .................................................................74
Java Message Service (JMS) v1.1 ...................................................................... 75, 97
Java Network Launching Protocol (JNLP) v1.5 .........................................................75
Java Server Pages (JSP) ..........................................................................................82
Joint Photographic Experts Group (JPEG) ...............................................................85
KoopA ADV, Handlungsleitfaden für die Einführung der elektronischen Signatur und
Verschlüsselung in der Verwaltung v1.1 .................................................................102
Kryptoalgorithmen nach RegTP für die elektronische Signatur ..............................111
Lightweighted Directory Access Protocol (LDAP) v3 ................................................95
Microsoft Windows .NET Framework ........................................................................75
MPEG-1 Layer 3 (MP3) .............................................................................................86
Multipurpose Internet Mail Extensions (MIME) v1.0 ............................................ 83, 94
Ogg ...........................................................................................................................88
Online Service Computer Interface (OSCI)-Transport v1.2 ....................................107
PHP: Hypertext Preprocessor (PHP) v5.x .................................................................75
Portable Document Format (PDF) v1.4 ......................................................... 82, 83, 84
Portable Document Format (PDF) v1.5 ............................................................... 83, 84
Portable Network Graphics (PNG) ............................................................................85
Post Office Protocol (POP) 3 ....................................................................................95
Quicktime (.qt, .mov) ........................................................................................... 87, 88
RealMedia v10 (.rm, .ram) .................................................................................. 87, 88
Regular Language Description for XML New Generation (Relax NG) .......... 72, 92, 93
Remote Method Invocation (RMI) .............................................................................91
Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP) ................91
Rollenmodelle und Flussdiagramme .........................................................................71
Secure Sockets Layer (SSL) / Transport Layer Security (TLS) ..............................104
Servlets .....................................................................................................................82
Short Message Services (SMS) ................................................................................89
Simple Mail Transfer Protocol (SMTP) ......................................................................94
Simple Object Access Protocol (SOAP) v1.1 ...................................................... 91, 92
Synchronized Multimedia Integration Language (SMIL) v2.0 ...................................84
Tagged Image File Format (TIFF) .............................................................................85
Text (.txt) ...................................................................................................................82
Triple Data Encryption Standard (Triple-DES) ........................................................112
Unicode v3.0 UTF-16 ................................................................................................81
Seite 190
Unicode v3.0 UTF-8 ..................................................................................................80
Unified Modeling Language (UML) v2.0 ..............................................................71, 72
Universal Description, Discovery and Integration (UDDI) v2.0 ............................93, 95
Web Map Service (WMS) v1.3 ..................................................................................86
Web Services ............................................................................................................97
Web Services (WS)-Security v1.0 ...........................................................................108
Web Services Description Language (WSDL) v1.1 ............................................91, 92
Windows Media Video (.wmv) .............................................................................87, 88
Wireless Application Protocol (WAP) v2.0 ................................................................90
XForms v1.0 ..............................................................................................................82
XML Encryption .......................................................................................................107
XML Key Management Specification (XKMS) v2 ....................................................110
XML Schema Definition (XSD) v1.0 ........................................................ 71, 72, 91, 93
XML Signature ........................................................................................................106
ZIP v2.0 .....................................................................................................................89
Seite 191
Seite 192
Anhang F Abkürzungsverzeichnis
3DES
Triple Data Encryption Standard
AES
Advanced Encryption Standard
APEC
Asia-Pacific Economic Cooperation
API
Application Programming Interface
ASCII
American Standard Code for Information Interchange
B2B
Business to Business
BGG
Behindertengleichstellungsgesetz
BITV
Barrierefreie Informationstechnik-Verordnung
BMI
BOL
Initiative BundOnline 2005
BPEL4WS
Business Process Execution Language for Web Services
BSI
BVA
BVN
Bundesverwaltungsnetz
CA
Certification Authority
CAP
Content Application Platform
CC VBPO
Kompetenzzentrum Vorgangsbearbeitung, Prozesse und Organisation
CEN
Comité Européen de Normalisation
CMS
Content Management System
CORBA
Common Object Request Broker Architecture
CPS
Certificate Practice Statement
CRL
Certificate Revocation List
CSS
Cascading Style Sheets Language
CSV
Comma Separated Value
CVC
Card Verification Code
DES
Data Encryption Standard
DIN
Deutsche Industrie-Norm
DNS
Domain Name Services
DSA
Digital Signature Algorithm
DSML
Directory Services Markup Language
DSS
Digital Signature Standard
Seite 193
EB-CA
European Bridge CA
ECMA
European Computer Manufacturers Association
ECMS
Enterprise Content Management System
ECW
Enhanced Compressed Wavelet
EDI
Electronic Data Interchange
EfA
„Einer für Alle“-Dienstleistungen
e-GIF
E-Government Interoperability Framework
ERP
Enterprise Resource Planning
EStdIT
Entwicklungsstandard für IT-Systeme des Bundes
ETSI
European Telecommunications Standards Institute
FMS
Formular Management System
FTP
File Transfer Protocol
G2B
Government to Business
G2C
Government to Citizen
G2E
Government to Employee
G2G
Government to Government
GDI
Geodateninfrastruktur
GI
Gesellschaft für Informatik e.V.
GIF
Graphics Interchange Format
GML
Geography Markup Language
GOSIP
Government Open Systems Interconnection Profile
HKR
Haushaltskassenrechnungswesen
HMAC
Keyed-Hash Message Authentication Code
HTML
Hypertext Markup Language
HTTP
Hypertext Transfer Protocol
IDABC
Interoperable Delivery of European eGovernment Services to public
Administrations, Businesses and Citizens
IDEA
International Data Encryption Algorithm
IEC
International Electrotechnical Commission
IETF
Internet Engineering Task Force
IIOP
Internet Inter-ORB Protocol
IMAP
Internet Message Access Protocol
IP
Internet Protocol
Seite 194
IT
Informationstechnologie
ITG
Informationstechnische Gesellschaft
ISDN
Integrated Services Digital Network
ISIS
Industrial Signature Interoperability Specification
ISO
International Organization for Standardization
IVBB
Informationsverbund Berlin-Bonn
IVBV
Informationsverbund der Bundesverwaltung
J2EE
Java 2 Platform, Enterprise Edition
J2SE
Java 2 Platform, Standard Edition
JAAS
Java Authentication and Authorization Service
JAXP
Java API for XML Parsing
JAXR
Java API for XML Registries
JCE
Java Cryptography Extension
JDBC
Java Database Connectivity
JDO
Java Data Objects
JMS
Java Message Service
JMX
Java Management Extensions
JNDI
Java Naming and Directory Interface
JNLP
Java Network Launching Protocol
JPEG
Joint Photographic Experts Group
JRE
Java Runtime Environment
JSP
Java Server Pages
JSSE
Java Secure Socket Extension
JSTL
JSP Standard Tag Library
JTA
Java Transaction API
KBSt
Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung im Bundesministerium des Innern
KoopA ADV Kooperationsausschuss ADV (automatische Datenverarbeitung) Bund /
Länder / Kommunaler Bereich
LDAP
Lightweight Directory Access Protocol
MAC
Message Authentication Code
MIME
Multipurpose Internet Mail Extensions
MPEG
Moving Picture Experts Group
Seite 195
MPLS
Multi Protocol Label Switching
MTT
MailTrusT
NAT
Network Address Translation
OASIS
Organization for the Advancement of Structured Information Standards
OCSP
Online Certificate Status Protocol
OGC
Open GIS Consortium
OSCI
Online Services Computer Interface
OSS
Open Source Software
PCA
Policy Certification Authority
PDA
Personal Digital Assistant
PDF
Portable Document Format
PHP
PHP: Hypertext Preprocessor
PKCS
Public Key Cryptography Standards
PKI
Public Key Infrastructure
PKIX
IETF Working Group „Public-Key Infrastructure (X.509)“
PNG
Portable Network Graphics
POP
Post Office Protocol
PTB
Physikalisch-Technische Bundesanstalt
RegTP
Regulierungsbehörde für Telekommunikation und Post
Relax NG
Regular Language Description for XML New Generation
RFC
Request for Comments
RFP
Request for Proposals
RIPEMD
RIPE (RACE Integrity Primitives Evaluation) Message Digest
RMI
Remote Method Invocation
RMI-IIOP
Remote Method Invocation over Internet Inter-ORB Protocol
RM-ODP
Reference Model of Open Distributed Processing
RSA
Rivest, Shamir, Adleman Public Key Encryption
SAGA
Standards und Architekturen für E-Government-Anwendungen
SC
Service Center
SGML
Standard Generalized Markup Language
SHA
Secure Hash Algorithm
SigG
Signaturgesetz
Seite 196
SigV
Signaturverordnung
SINA
Sichere Inter-Netzwerk Architektur
SMIL
Synchronized Multimedia Integration Language
S/MIME
Secure Multipurpose Internet Mail Extensions
SMS
Short Message Service
SMTP
Simple Mail Transfer Protocol
SOAP
Simple Object Access Protocol
SSL
Secure Sockets Layer
Sub-CA
Subordinated Certification Authority
TCP/IP
Transmission Control Protocol / Internet Protocol
TESTA
Trans-European Services for Telematics between Administrations
TIFF
Tagged Image File Format
TLS
Transport Layer Security
TN
Teilnehmer
Triple-DES
Triple Data Encryption Standard
UDDI
Universal Description, Discovery and Integration
UDP
User Datagram Protocol
UML
Unified Modeling Language
URL
Uniform Resource Locator
UTF
Unicode Transformation Format
VBS
Vorgangsbearbeitungssystem
VDE
Verband der Elektrotechnik, Elektronik und Informationstechnik
V-PKI
Public Key Infrastruktur der Verwaltung (Verwaltungs-PKI)
VPN
Virtual Private Network
VPS
Virtuelle Poststelle
W3C
World Wide Web Consortium
WAP
Wireless Application Protocol
WCAG
Web Content Accessibility Guideline
WML
Wireless Markup Language
WMS
Web Map Service
WSDL
Web Services Description Language
WS-I
Web Service Interoperability Organization
Seite 197
WWW
World Wide Web
XHTML
Extensible Hypertext Markup Language
XKMS
XML Key Management Specification
XML
Extensible Markup Language
XSD
Extensible Markup Language Schema Definition
XSL
Extensible Stylesheet Language
XSLT
Extensible Stylesheet Language Transformation
ZÜV
Zahlungsüberwachungsverfahren
Seite 198

SAGA 2.1 - IT-Beauftragter der Bundesregierung

Transcription

Similar documents

splitter 4/2006 - IT-Dienstleistungszentrum Berlin

TANDEM-Magazin - Das Arbeitsschutz

Fehlertolerante Steuerungs- und Regelungssysteme

bekämpfen

Referat VI - Bundesbeauftragter für den Datenschutz

3. Ausgabe: Datensicherheit im Netz

Dr. Michael Grimberg und Matthias Knödler, Hochschule Harz Anett

Installationsanleitung Einsatznachbearbeitung