SAGA-Modul Technische Spezifikationen - IT

Transcription

SAGA-Modul Technische
Spezifikationen
Version de.bund 5.0.0
3. November 2011
2
Herausgeber
Die Beauftragte der Bundesregierung für Informationstechnik (BfIT)
Redaktion
Bundesministerium des Innern
Referat IT 2 - IT-Steuerung Bund
Alt-Moabit 101 D
10559 Berlin
[email protected]
Stand
Version de.bund 5.0.0 – final
Vom Rat der IT-Beauftragten der Ressorts am 3. November 2011 beschlossen.
3
4
Inhaltsverzeichnis
1
Einleitung...................................................................................................................................8
1.1
Anwendung des Klassifikationssystems.................................................................................................................8
1.2
Zeichenerklärungen...............................................................................................................................................10
2
IT-Sicherheitskonzeption.........................................................................................................10
2.1
Managementsysteme für Informationssicherheit.................................................................................................10
2.2
IT-Grundschutz-Vorgehensweise..........................................................................................................................11
2.3
Risikoanalyse........................................................................................................................................................11
2.4
Notfallmanagement...............................................................................................................................................12
2.5
Umsetzung der Sicherheitskonzeption.................................................................................................................12
3
Prozessmodelle.........................................................................................................................13
3.1
Technologien zur Prozessmodellierung................................................................................................................13
3.2
Austauschformate für Prozessmodelle.................................................................................................................15
4
Datenmodelle...........................................................................................................................16
4.1
Technologien zur Datenmodellierung...................................................................................................................16
4.2
Austauschformate für Datenmodelle....................................................................................................................17
4.3
Beschreibungssprachen für Metadaten.................................................................................................................18
4.4
Vokabulare für Metadaten.....................................................................................................................................18
5
Applikationsarchitektur............................................................................................................19
5.1
Applikationsarchitektur für große Projekte..........................................................................................................19
5.2
Applikationsarchitektur für kleine und mittlere Projekte.....................................................................................20
5.3
Diensteorientierte Architekturen...........................................................................................................................22
6
Client........................................................................................................................................24
6.1
Informationszugriff mit Computern......................................................................................................................24
6.1.1
Einsatz aktiver Inhalte im Client....................................................................................................................24
6.1.2
Web-Browser..................................................................................................................................................25
6.1.3
Client-Anwendungen.....................................................................................................................................26
6.1.4
E-Mail-Client..................................................................................................................................................27
6.2
Informationszugriff mit mobilen Endgeräten.......................................................................................................27
6.3
Informationszugriff durch externe Systeme.........................................................................................................28
5
6.4
Technologien zur Authentisierung........................................................................................................................28
7
Präsentation..............................................................................................................................30
7.1
Barrierefreie Darstellung......................................................................................................................................30
7.2
Zeichensätze und -kodierungen............................................................................................................................31
7.3
Technologien zur Informationsaufbereitung........................................................................................................32
7.4
Spezifikationen für aktive Inhalte.........................................................................................................................34
7.5
Formulare..............................................................................................................................................................35
7.6
Austauschformate für Daten.................................................................................................................................35
7.7
Austauschformate für Dokumente........................................................................................................................36
7.7.1
Formate für Textdokumente zum Informationsaustausch.............................................................................36
7.7.2
Formate für Textdokumente zur Weiterbearbeitung......................................................................................36
7.7.3
Formate für Tabellen zum Informationsaustausch.........................................................................................38
7.7.4
Formate für Tabellen zur Weiterbearbeitung.................................................................................................39
7.7.5
Formate für Präsentationen zum Informationsaustausch...............................................................................40
7.7.6
Formate für Präsentationen zur Weiterbearbeitung.......................................................................................41
7.7.7
Gesicherter Dokumentenaustausch................................................................................................................42
7.8
Austauschformate für Bilder.................................................................................................................................43
7.9
Animation..............................................................................................................................................................45
7.10
Audio- und Videodaten.........................................................................................................................................45
7.10.1
Austauschformate für Audiodateien..............................................................................................................46
7.10.2
Austauschformate für Audio-Streaming........................................................................................................47
7.10.3
Austauschformate für Videodateien...............................................................................................................48
7.10.4
Austauschformate für Video-Streaming.........................................................................................................48
7.11
3D-Daten...............................................................................................................................................................49
7.12
Austauschformate für Geoinformationen.............................................................................................................50
7.13
Datenkompression.................................................................................................................................................51
7.14
Technologien für die Präsentation auf mobilen Endgeräten................................................................................52
8
Kommunikation.......................................................................................................................53
8.1
8.2
Kommunikation zwischen Applikationen............................................................................................................53
8.1.1
Kommunikation zwischen Applikationen innerhalb der Verwaltung............................................................54
8.1.2
Kommunikation mit verwaltungsexternen Applikationen.............................................................................56
Netzwerkprotokolle...............................................................................................................................................57
6
8.3
E-Mail-Kommunikation........................................................................................................................................58
8.4
IP-Telefonie...........................................................................................................................................................60
8.5
Anwendungsprotokolle.........................................................................................................................................60
8.6
Geodienste.............................................................................................................................................................62
9
Backend....................................................................................................................................65
9.1
Zugriff auf Verzeichnisdienste..............................................................................................................................65
9.2
Zugriff auf Datenbanken und Registrys...............................................................................................................66
9.3
Zugriff auf Bestandssysteme.................................................................................................................................67
10
Verschlüsselung........................................................................................................................68
10.1
Asymmetrische Verschlüsselungsverfahren.........................................................................................................69
10.2
Symmetrische Verschlüsselungsverfahren............................................................................................................69
11
Elektronische Signatur.............................................................................................................70
11.1
Hashen von Daten.................................................................................................................................................70
11.2
Asymmetrische Signaturverfahren.......................................................................................................................71
11.3
Key Management..................................................................................................................................................72
12
Smartcards................................................................................................................................72
12.1
Kontaktbehaftete Smartcards................................................................................................................................72
12.2
Kontaktlose Smartcards........................................................................................................................................73
12.3
Lesegeräte und Schnittstellen für Smartcards......................................................................................................73
13
Langzeitspeicherung................................................................................................................74
A
Literatur....................................................................................................................................76
B
Abkürzungsverzeichnis............................................................................................................77
C
Strukturelle Übersicht klassifizierter Spezifikationen.............................................................80
C.1
IT-Sicherheitskonzeption......................................................................................................................................80
C.2
Prozessmodelle......................................................................................................................................................80
C.3
Datenmodelle........................................................................................................................................................81
C.4
Applikationsarchitektur.........................................................................................................................................81
C.5
Client.....................................................................................................................................................................82
C.6
Präsentation...........................................................................................................................................................82
C.7
Kommunikation....................................................................................................................................................86
C.8
Backend.................................................................................................................................................................87
7
D
C.9
Verschlüsselung.....................................................................................................................................................87
C.10
Elektronische Signatur..........................................................................................................................................88
C.11
Smartcards.............................................................................................................................................................88
C.12
Langzeitspeicherung.............................................................................................................................................89
Alphabetische Übersicht klassifizierter Spezifikationen.........................................................90
1 Einleitung
1
8
Einleitung
SAGA1 ist eine Zusammenstellung von Referenzen auf Spezifikationen und Methoden für SoftwareSysteme der öffentlichen Verwaltung.
SAGA ist modular aufgebaut. Die SAGA-Module können zeitlich und weitgehend inhaltlich unab
hängig voneinander publiziert werden. Jedes SAGA-Modul wird separat versioniert. Die aktuelle
Gesamtversion von SAGA setzt sich aus den neuesten Versionen aller SAGA-Module zusammen.
Alle verfügbaren SAGA-Module sind auf der Website der oder des Beauftragten der Bundesregie
rung für Informationstechnik (BfIT)2 zu finden.
Dieses SAGA-Modul klassifiziert die technischen Spezifikationen, mit denen die Software-Systeme
der Bundesverwaltung realisiert werden MÜSSEN. Es werden die Themengebiete betrachtet, bei denen
der Einsatz einheitlicher Spezifikationen die Erreichung der Ziele von SAGA3 am meisten befördert.
Wenn für Spezifikationen keine Versionsnummern angegeben sind, ist die aus Marktsicht stabilste,
finalisierte Version zu verwenden, welche nicht immer die neueste Version sein muss.
1.1 Anwendung des Klassifikationssystems
Das System zur Klassifikation von Spezifikationen durch SAGA wird im SAGA-Modul „Grundla
gen“4 näher beschrieben. In diesem Modul befinden sich technische Spezifikationen mit den Klassi
fikationen „Verbindlich“, „Empfohlen“, „Beobachtet“ und „Bestandsgeschützt“. Die technischen
Spezifikationen mit den Klassifikationen „Vorgeschlagen“ und „Verworfen“ können auf der Vor
schlagsliste und der Negativliste auf der Website der/des BfIT 5 eingesehen werden.
In den folgenden Ausführungen werden die sechs Klassen hinsichtlich ihrer Anwendung betrachtet.
Vorgeschlagen
Es ist nicht SAGA-konform, vorgeschlagene Spezifikationen einzusetzen, wenn es konkurrierende
Spezifikationen6 gibt, die bestandsgeschützt, beobachtet, empfohlen oder verbindlich sind. Wenn es
keine konkurrierenden Spezifikationen gibt, die höher klassifiziert wurden, befindet sich das The
menfeld noch außerhalb der Festlegungen von SAGA und ist für die Betrachtung der SAGA-Konfor
mität nicht relevant.
Beobachtet
Wenn es neben den beobachteten Spezifikationen keine konkurrierenden empfohlenen oder verbind
lichen Spezifikationen gibt, SOLLTEN beobachtete Spezifikationen in Software-Systemen eingesetzt
1
2
3
4
5
6
SAGA ist ein Eigenname, der ursprünglich als Abkürzung von „Standards und Architekturen für
eGovernment-Anwendungen“ eingeführt wurde.
http://www.cio.bund.de/saga
Siehe (BFIT, 2011B), Kapitel 3 „Ziele“
Siehe (BFIT, 2011B), Kapitel 5 „Klassifikationssystem“
Siehe (BFIT, 2011D)
Zwei Spezifikationen konkurrieren, wenn beide zur Erfüllung der Anforderungen eines Projekts ge
eignet sind.
1.1 Anwendung des Klassifikationssystems
9
werden. Nur in begründeten Ausnahmen KÖNNEN beobachtete Spezifikationen empfohlenen Alterna
tiven vorgezogen werden.
Empfohlen
Konkurrierende Spezifikationen können nebeneinander empfohlen sein, wenn sich ihre Anwen
dungsschwerpunkte deutlich unterscheiden. In solchen Fällen SOLLTE die für die jeweilige Anwen
dung am besten geeignete Spezifikation angewendet werden.
Von den empfohlenen Spezifikationen KANN in begründeten Ausnahmen abgewichen werden. Zu ei
ner empfohlenen Spezifikation gibt es keine verbindliche Alternative, da eine Empfehlung neben ei
ner verbindlich einzusetzenden Spezifikation keinen Sinn hat.
Verbindlich
Konkurrierende Spezifikationen können nebeneinander verbindlich sein, wenn sich die Anwen
dungsschwerpunkte deutlich unterscheiden. In solchen Fällen MUSS die für die jeweilige Anwendung
am besten geeignete Spezifikation verwendet werden.
Spezifikationen dieser Klassifikation sind im eigentlichen Sinne des Wortes verbindlich, MÜSSEN also
bei der Einführung eines neuen Software-Systems jeder Alternative vorgezogen werden. Abweichun
gen gefährden die Ziele von SAGA in hohem Maße und sind deshalb nicht zugelassen.
Bei der funktionalen Änderung oder Erweiterung eines Software-Systems KÖNNEN als „Bestandsge
schützt“ klassifizierte Spezifikationen weiterhin genutzt werden. Es MUSS jedoch geprüft werden, ob
die Migration zur verbindlichen Spezifikation vorteilhaft ist.
Bestandsgeschützt
Bei der funktionalen Änderung oder Erweiterung eines Software-Systems stehen diese Spezifikatio
nen unter Bestandsschutz und KÖNNEN auch weiterhin eingesetzt werden. Es SOLLTE geprüft werden,
ob eine Migration zu den in SAGA als „Beobachtet“ oder „Empfohlen“ klassifizierten Spezifikatio
nen Vorteile gegenüber dem Festhalten an als „Bestandsgeschützt“ klassifizierten Spezifikationen
bringt. Gibt es eine als „Verbindlich“ klassifizierte Alternative, MUSS diese Überprüfung durchgeführt
werden. Für neue Software-Systeme SOLLTEN bestandsgeschützte Spezifikationen NICHT mehr zum
Einsatz kommen.
Verworfen
Verworfene Spezifikationen KÖNNEN dann eingesetzt werden, wenn parallel eine SAGA-konforme
Lösung zur Verfügung gestellt wird.7 Allein DÜRFEN diese Spezifikationen in neuen sowie in beste
henden Software-Systemen NICHT eingesetzt werden. Spätestens bei funktionalen Änderungen oder
Erweiterungen MÜSSEN sie ausgetauscht werden. Dazu MUSS für die Erweiterung des Funktionsum
fanges, gegebenenfalls unter Einsatz von Kapselung, von verworfenen Spezifikationen weg migriert
oder eine SAGA-konforme Alternative geschaffen werden. Es SOLLTE jedoch für das gesamte beste
hende Software-System geprüft werden, ob eine Migration oder Erweiterung vorteilhaft ist.
7
Z. B. dürfen Bilder im BMP-Format zur Verfügung gestellt werden, obwohl diese Spezifikation ver
worfen wurde, wenn gleichzeitig die Bilder auch in einem SAGA-konformen Format wie GIF ange
boten werden.
1.2 Zeichenerklärungen
10
1.2 Zeichenerklärungen
Für die SAGA-konforme Auswahl von Spezifikationen spielt es eine große Rolle, ob die zu erstel
lende Software-Einheit ein Produkt oder eine Individualentwicklung ist.8
Daher werden die klassifizierten Spezifikationen in diesem Modul am rechten Rand mit „I“ oder
„PI“ gekennzeichnet. Ein „I“ bedeutet, dass die Klassifikation nur für Individualentwicklungen und
nicht für Produkte relevant ist. Das Zeichen „PI“ bedeutet, dass die Klassifikation sowohl für Indivi
dualentwicklungen als auch für die Beschaffung von Produkten zu beachten ist.
2
I
PI
IT-Sicherheitskonzeption
Durch eine Reihe vom Bundesamt für Sicherheit in der Informationstechnik (BSI) herausgegebener
Standards werden der Aufbau und die Einhaltung einer umfassenden Sicherheitskonzeption beschrie
ben. Die IT-Sicherheitskonzeption ist erforderlich, um vorgegebene IT-Sicherheitsziele und die vor
gegebene IT-Sicherheitsstrategie zu verfolgen sowie dazu passende Maßnahmen zu planen und um
zusetzen. Beginnend mit einer Beschreibung der Anforderungen an ein sicheres Informationssicher
heits-Managementsystem (ISMS) werden anschließend die Realisierung, die Analyse von Risiken
sowie das Management im Notfall eingehend dargelegt.
In erster Linie richten sich die Spezifikationen dieses Abschnitts an Sicherheitsverantwortliche, -be
auftragte, -experten, -berater und alle Interessierte, die mit dem Management von Informationssi
cherheit betraut sind. Sie bieten weiterhin auch eine Grundlage für IT-Verantwortliche, Führungs
kräfte und Projektmanager, die dafür Sorge tragen, dass die Sicherheitsaspekte in ihrer Institution
bzw. in ihren Projekten ausreichend berücksichtigt werden.
2.1 Managementsysteme für Informationssicher
heit
Als ersten Schritt hin zu einer umfassenden IT-Sicherheitskonzeption ist die Schaffung eines Mana
gementsystems für die Informationssicherheit notwendig. Die Praxis hat gezeigt, dass eine Optimie
rung des Sicherheitsmanagements oftmals die Informationssicherheit effektiver und nachhaltiger
verbessert als Investitionen in Sicherheitstechnik.
Verbindlich: BSI-Standard 100-1: Managementsysteme für Informationssicherheit ≥1.5
Die allgemeinen Anforderungen an Informationssicherheits-Managementsysteme (ISMS) werden im
BSI-Standard 100-19 definiert. Dieser Standard ist kompatibel zu den ISO-Normen 27001 und 27002
und berücksichtigt darüber hinaus die Empfehlungen der anderen ISO-Standards der 2700x-Reihe 10.
Der BSI-Standard 100-1 MUSS mindestens in der Version 1.5 verwendet werden. Bei Fortschreibung
des Standards SOLLTE die aktuellste Version verwendet werden.
8
Siehe SAGA-Modul „Konformität“ (BFIT, 2011C), Abschnitt 2.2 „Definition der SAGA-Konformi
tät“
9 Siehe (BSI, 2011B)
10 http://www.iso.org/
I
2.1 Managementsysteme für Informationssicherheit
11
Bestandsgeschützt: BSI-Standard 100-1: Managementsysteme für Informationssicher
heit 1.0
I
Version 1.0 des BSI-Standards 100-1 wurde mit der Aktualisierung von SAGA 4.0 durch Version 1.5
ersetzt.
2.2 IT-Grundschutz-Vorgehensweise
Nach der im vorherigen Abschnitt adressierten Definition der Anforderungen an ein Informationssi
cherheits-Managementsystem sowie der Beschreibung, mit welchen Methoden Informationssicher
heit initiiert und gesteuert werden kann, wird im Folgenden der Aufbau und das konkrete Vorgehen
bei der Einführung eines Managementsystems für Informationssicherheit behandelt.
Verbindlich: BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise ≥2.0
I
Der BSI-Standard 100-211 stellt eine Methode vor, um ein ISMS in der Praxis aufzubauen und zu be
treiben. Der Aufbau einer Sicherheitsorganisation und deren Einbettung sind dabei wichtige Themen.
Mit dieser Vorgehensweise nach IT-Grundschutz lassen sich IT-Sicherheitskonzepte einfach und effi
zient erstellen und die IT-Sicherheit im laufenden Betrieb aufrechterhalten beziehungsweise verbes
sern. Durch Rückgriff auf bereits bekannte Vorgehensweisen soll der Aufwand für die Umsetzung re
duziert werden. Weiterhin bietet er eine umfassende Basis für die Risikobewertung, die Überprüfung
des vorhandenen Sicherheitsniveaus und die Implementierung der angemessenen Informationssi
cherheit.
Bestandsgeschützt: BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise 1.0
I
ersetzt.
2.3 Risikoanalyse
Verbindlich: BSI-Standard 100-3: Risikoanalyse auf der Basis von IT-Grundschutz ≥2.5
Der BSI-Standard 100-312 beschreibt eine Methode zur Durchführung von Risikoanalysen, die ein
bestehendes IT-Sicherheitskonzept ergänzen. Ausgangspunkt bildet dabei die in der IT-GrundschutzVorgehensweise13 beschriebene ergänzende Sicherheitsanalyse, auf deren Basis entschieden wird, für
welche Zielobjekte eine Risikoanalyse durchgeführt wird, bzw. wo eine Risikoanalyse nicht erfor
derlich ist.
13 Siehe Abschnitt 2.2 „IT-Grundschutz-Vorgehensweise“
I
2.3 Risikoanalyse
12
Bestandsgeschützt: BSI-Standard 100-3: Risikoanalyse auf der Basis von IT-Grund
schutz 2.0
I
ersetzt.
2.4 Notfallmanagement
Die Umsetzung der nach den BSI-Standards 100-1 und 100-2 erstellten IT-Sicherheitskonzeption
und einer durchgeführten erweiterten Risikoanalyse kann nicht verhindern, dass Notfälle eintreten
können, wie z. B. Umweltkatastrophen. Das BSI stellt entsprechende Handlungsmaßnahmen zum
Aufbau eines Notfallmanagements und zum weiteren Vorgehen bereit. Die Rahmenbedingungen
MÜSSEN zunächst geklärt bzw. festgelegt werden, bevor ein Notfallmanagement gemäß dem BSIStandard 100-4 in einer Behörde beziehungsweise in einem Unternehmen eingeführt wird. Grundla
ge der Notfallmanagement-Konzeption bildet die Business Impact Analyse (BIA), um kritische Ge
schäftsprozesse zu ermitteln und Prioritäten für deren Wiederanlauf zu definieren.
Verbindlich: BSI-Standard 100-4: Notfallmanagement ≥1.0
I
Die Methodik zur Etablierung und Aufrechterhaltung eines behörden- bzw. unternehmensweiten in
ternen Notfallmanagements wird im BSI-Standard 100-414 vorgestellt. Dabei soll ein möglichst
schnelles Reagieren im Falle von Notfällen oder Krisen, die zu einer Geschäftsunterbrechung führen
könnten, realisiert werden. Auch Maßnahmen zur Vermeidung von Notfällen sowie zur Minimierung
der Schäden werden beschrieben.
2.5 Umsetzung der Sicherheitskonzeption
Verbindlich: BSI, IT-Grundschutz-Kataloge
I
Die IT-Grundschutz-Kataloge15, bestehend aus Bausteinen, Maßnahmenkatalogen sowie Gefähr
dungskatalogen, dienen der Ermittlung und Beseitigung von sicherheitsrelevanten Schwachstellen in
IT-Systemen und sind somit die Grundlage zur Zertifizierung des IT-Grundschutzes nach ISO 27001.
Bestandsgeschützt: BSI, E-Government-Handbuch
I
Das E-Government-Handbuch wird nicht weiter gepflegt und wurde mit dem SAGA-Modul „Tech
nische Spezifikationen“ 5.0.0 auf die Bestandsschutzliste verschoben.
Bestandsgeschützt: KoopA ADV, Handlungsleitfaden für die Einführung der elektroni
schen Signatur und Verschlüsselung in der Verwaltung 1.1
Der Handlungsleitfaden für die Einführung der elektronischen Signatur und Verschlüsselung in der
Verwaltung 1.1 des KoopA ADV wurde mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0
auf die Bestandsschutzliste verschoben.
15 Siehe (BSI, 2011A)
I
3 Prozessmodelle
3
13
Prozessmodelle
3.1 Technologien zur Prozessmodellierung
Empfohlen: Unified Modeling Language (UML) 2.x
I
UML16 ist eine standardisierte grafische Modellierungssprache zur Spezifikation, Visualisierung und
Dokumentation von Systemen. Sie erlaubt die Modellierung von Software-Architekturen, Ge
schäftsprozessen, Datenstrukturen, Datenbankschemata, Informationsflüssen und Aktivitäten.
Die Object Management Group (OMG)17 entwickelt UML. Seit Mai 2010 liegt die Version 2.318 vor.
UML 2.x SOLLTE zur Vorbereitung und Dokumentation von großen Projekten für objektorientierte
Modellierung angewendet werden. Beispielsweise Use Cases und Aktivitätsdiagramme haben sich
im Einsatz bewährt und erlauben, transparente Spezifikationen zu erstellen und abzustimmen.
Das zugehörige Austauschformat für Prozessmodelle auf UML-2.x-Basis ist XML Medata Inter
change (XMI) in der Version 2.x19.
Empfohlen: Flussdiagramme
I
Flussdiagramme20 sind eine grafische Notation für den Ablauf eines Programms. Flussdiagramme
wurden ursprünglich in Zusammenhang mit dem imperativen Programmierparadigma eingeführt,
lassen sich aber auch mit neueren Paradigmen verwenden.
Flussdiagramme wurden zuerst 1966 als DIN-Norm veröffentlicht. Die letzte Überarbeitung der DIN
66001 erfolgte im Jahr 1983.
Die Strukturierung eines Software-Systems SOLLTE durch Flussdiagramme und die zusätzliche An
wendung von Rollenmodellen erfolgen, die die Flussdiagramme durch Angabe zu den Nutzern des
Systems ergänzen.
Eine Alternative zu Flussdiagrammen stellen die Aktivitätsdiagramme der Unified Modeling Lan
guage (UML) 2.x21 dar.
Empfohlen: Business Process Modeling Notation (BPMN) 1.1 / 1.2
BPMN22 ist eine grafische Notation zur Modellierung von Geschäftsprozessen. Sie eignet sich vor
allem für Projekte, in denen lediglich eine grobe Modellierung und Abstimmung von Prozessen be
nötigt wird, ohne dass diese in eine Software-Entwicklung eingehen. Für eine durchgehende und ein
heitliche Modellierung von Prozessen und Daten in Software-Entwicklungsprojekten ist UML besser
geeignet.
16
17
18
19
http://www.omg.org/spec/UML/
http://www.omg.org/
http://www.omg.org/spec/UML/2.3/
Siehe XML Metadata Interchange (XMI) 2.x im Abschnitt 3.2 „Austauschformate für Prozessmodel
le“ auf Seite 15
20 http://www.beuth.de/langanzeige/DIN-66001/de/1080044.html
21 Siehe Unified Modeling Language (UML) 2.x im gleichen Abschnitt auf Seite 13
22 http://www.omg.org/spec/BPMN/1.2/
I
14
BPMN 1.1 wurde von der OMG im Januar 2008 veröffentlicht23. Das zugehörige Austauschformat
für Prozessmodelle auf BPMN-1.1-Basis ist XML Process Definition Language (XPDL) in der Ver
sion 2.124.
Der Nachfolger BPMN 1.2 wurde von der OMG im Januar 2009 veröffentlicht25.
BPMN 1.1 SOLLTE immer dann eingesetzt werden, wenn die Erweiterungen der Version 1.2 nicht be
nötigt werden und ein Austausch des Modells über XPDL 2.1 erfolgt. In allen anderen Fällen SOLLTE
der Version 1.2 der Vorzug bei der Modellierung von Prozessen gegeben werden.
Empfohlen: Ereignisgesteuerte Prozesskette (EPK)
I
Die EPK26 dient der Abbildung von Abläufen innerhalb von und zwischen Organisationen. Prozess
ketten beschreiben die zeitlich-logischen Abläufe und das Zusammenspiel zwischen Daten, Prozess
schritten, IT-Systemen, Organisationen und Produkten.
EPK wurde von G. Keller, M. Nüttgens und A.-W. Scheer im Januar 1992 in „Semantische Prozeß
modellierung auf der Grundlage ‚Ereignisgesteuerter Prozeßketten (EPK)‘“ eingeführt 27. Seitdem hat
sich EPK zu einem De-facto-Standard zur grafischen Beschreibung von Geschäfts- und Verwal
tungsprozessen entwickelt.
EPK SOLLTE für die Darstellung von Geschäftsprozessen in Verbindung mit der Organisationsent
wicklung eingesetzt werden. Auch einfache technisch-funktionale Prozessmodelle, insbesondere für
die fachliche Grobkonzeption, SOLLTEN durch EPK dargestellt werden.
Der Austausch von EPK-Prozessmodellen kann mittels des Austauschformats EPML 28 erfolgen.
Beobachtet: Business Process Modeling Notation (BPMN) 2.0
I
Siehe Business Process Modeling Notation (BPMN) 1.1 / 1.2 im gleichen Abschnitt.
BPMN 2.0 wurde von der OMG im Januar 2011 veröffentlicht29.
BPMN 2.0 KANN statt BPMN 1.1 / 1.2 als grafische Notation für ausführbare WS-BPEL-Modelle
verwendet werden, da es eine Abbildung auf WS-BPEL beinhaltet, die nicht Teil von BPMN 1.1 /
1.2 ist.
Bestandsgeschützt: Business Process Modeling Notation (BPMN) 1.0
BPMN 1.0 wurde mit der Aktualisierung von SAGA 4.0 durch Version 1.1 ersetzt.
23 http://www.omg.org/bpmn/Documents/BPMN_1-1_Specification.pdf
24 Siehe XML Process Definition Language (XPDL) 2.1 im Abschnitt 3.2 „Austauschformate für Pro
zessmodelle“ auf Seite 15
25 http://www.omg.org/spec/BPMN/1.2/PDF/
26 Nüttgens, M.; Rump, J.F.: Syntax und Semantik Ereignisgesteuerter Prozessketten (EPK), in: Desel,
J.; Weske, M. (Hrsg.): Promise 2002 - Prozessorientierte Methoden und Werkzeuge für die Entwick
lung von Informationssystemen, Proceedings des GI-Workshops und Fachgruppentreffens (Potsdam,
Oktober 2002), LNI Vol. P-21, Bonn 2002, S. 64-77; http://www.wiso.unihamburg.de/fileadmin/wiso_fs_wi/EPK-Community/Promise2002_Nuettgens_Rump.pdf
27 http://www.unisaarland.de/fileadmin/user_upload/Fachrichtungen/fr13_BWL/professuren/PDF/heft89.pdf
28 Siehe EPC Markup Language (EPML) 1.2 im Abschnitt 3.2 „Austauschformate für Prozessmodelle“
auf Seite 15
29 http://www.omg.org/spec/BPMN/2.0/PDF/
I
15
Bestandsgeschützt: Unified Modeling Language (UML) ≤1.5
I
Zum Zeitpunkt der Veröffentlichung von SAGA 2.0 war UML 1.5 die aktuelle Version und als
„Empfohlen“ klassifiziert. Mit SAGA 2.1 erfolgte eine Festlegung auf die aktuellere Version 2.0. Je
doch existieren auch von den vorangegangenen UML-Versionen noch umfangreiche Modelle für be
stehende Software-Systeme. Für diese Modelle besteht kein Migrationsdruck.
3.2 Austauschformate für Prozessmodelle
Empfohlen: XML Metadata Interchange (XMI) 2.x
I
XMI30 ist eine Spezifikation, die die Beschreibung und den Austausch von Daten- und Prozessmo
dellen in XML ermöglicht.
Die OMG gibt XMI heraus. Die Version 2.1.1 ist datiert vom Dezember 2007. Die Version 2.0.1
wurde von der ISO als ISO/IEC 19503:2005 normiert.
XMI SOLLTE für den Austausch für alle Prozessmodelle eingesetzt werden, die auf der Meta-Object
Facility (MOF)-Spezifikation der OMG basieren, also insbesondere für UML-Modelle in der Version
2.x31.
Beobachtet: XML Process Definition Language (XPDL) 2.1
I
XPDL32 ist eine XML-basierte Sprache für den Austausch von Geschäftsprozessen und Arbeitsabläu
fen auf Basis von BPMN33. Dabei ist XPDL explizit darauf ausgelegt, alle Elemente von BPMN zu
unterstützen.
Die von der Workflow Management Coalition (WfMC) im Jahr 2008 veröffentlichte Version 2.1 un
terstützt BPMN 1.1.
XPDL 2.1 KANN für den Austausch von BPMN-1.1-Modellen verwendet werden.
Beobachtet: EPC Markup Language (EPML) 1.2
I
EPML34 ist eine XML-basierte Sprache für den Austausch von Geschäftsprozessen und Arbeitsabläu
fen auf Basis von EPK35.
Die Version 1.2 wurde von J. Mendling und M. Nüttgens im Jahr 2005 veröffentlicht.
EPML 1.2 KANN für den Austausch von EPK-Modellen verwendet werden.
Bestandsgeschützt: XML Metadata Interchange (XMI) 1.x
Mit SAGA 3.0 wurde XMI 2.x zur Notation und zum Austausch von Meta-Object-Facility (MOF)basierten Prozessmodellen (z. B. UML) aufgenommen. Um auch ältere UML-Modelle (siehe UML
30 http://www.omg.org/spec/XMI/Current/
31 Siehe Unified Modeling Language (UML) 2.x im Abschnitt 3.1 „Technologien zur Prozessmodellie
rung“ auf Seite 13
32 http://www.wfmc.org/xpdl.html
33 Siehe Business Process Modeling Notation (BPMN) 1.1 / 1.2 im Abschnitt 3.1 „Technologien zur
Prozessmodellierung“ ab Seite 13
34 http://www.mendling.com/EPML/
35 Siehe Ereignisgesteuerte Prozesskette (EPK) im Abschnitt 3.1 „Technologien zur Prozessmodellie
rung“ auf Seite 14
I
3.2 Austauschformate für Prozessmodelle
16
≤1.5) bestehender Anwendungen mit XMI notieren und austauschen zu können, wurde XMI 1.x auf
die Bestandsschutzliste aufgenommen.
4
Datenmodelle
4.1 Technologien zur Datenmodellierung
Empfohlen: Entity-Relationship-Diagramme (ERD)
I
ERD36 sind die grafische Repräsentationen von Entity-Relationship-Modellen.
Peter Chen hat mit der Publikation seines Paper „The Entity-Relationship Model – Toward a Unified
View of Data“ im März 1976 ERD erstmals veröffentlicht. Seitdem hat sich ERD zu einem QuasiStandard in Lehre und Praxis entwickelt.
ERD ist gegenüber UML weniger ausdrucksstark, weshalb ERD in der Regel leichter verständlich
sind als UML-Diagramme. ERD SOLLTEN daher für die Entwicklung von relationalen DatenbankSchemata eingesetzt werden. Auch einfache funktionale Datenmodelle, insbesondere für die fachli
che Grobkonzeption, SOLLTEN durch ERD dargestellt werden.
Empfohlen: Unified Modeling Language (UML) 2.x
I
Siehe Unified Modeling Language (UML) 2.x im Abschnitt 3.1 „Technologien zur Prozessmodellie
rung“ auf Seite 13.
UML 2.x37 SOLLTE bei der Datenmodellierung für objektorientierte Anwendungen und komplexe Da
tenbankmodelle eingesetzt werden. Es bieten sich beispielsweise Klassendiagramme an, die für an
dere Anwendungen oder durch andere Werkzeuge wiederverwendet oder weiterverarbeitet werden
können. Aus UML-Datenmodellen können direkt Datenstrukturen (XML Schema) sowie komplexe
Datenbanken generiert werden.
Das zugehörige Austauschformat für Datenmodelle auf UML-2.x-Basis ist XML Medata Interchange
(XMI) in der Version 2.x38.
Bestandsgeschützt: Unified Modeling Language (UML) ≤1.5
Siehe Unified Modeling Language (UML) ≤1.5 im Abschnitt 3.1 „Technologien zur Prozessmodel
lierung“ auf Seite 15.
36 http://csc.lsu.edu/news/erd.pdf
37 http://www.omg.org/spec/UML/
38 Siehe XML Metadata Interchange (XMI) 2.x im Abschnitt 4.2 „Austauschformate für Datenmodel
le“ auf Seite 17
I
4.2 Austauschformate für Datenmodelle
17
4.2 Austauschformate für Datenmodelle
Verbindlich: XML Schema Definition Language (XSD) 1.0
PI
XSD39 ist eine Spezifikation, die es erlaubt, Strukturen für XML-Dokumente zu beschreiben und da
mit Datenmodelle auszutauschen. Durch XML-Validatoren können XML-Dateien darauf geprüft
werden, ob sie die durch eine XSD-Datei beschriebene Struktur einhalten.
XSD 1.0 wurde vom World Wide Web Consortium (W3C)40 2004 in einer Second Edition als Re
commendation herausgegeben.
XSD MUSS für den Austausch von XML-Datenmodellen verwendet werden. Nur wenn die Funktio
nalitäten von XSD für die fachlichen Anforderungen des jeweiligen Anwendungsfalls nicht ausrei
chen, SOLLTE RelaxNG eingesetzt werden.
Empfohlen: Regular Language Description for XML New Generation (Relax NG)
PI
RELAX NG41 ist eine Schema-Sprache für XML. Ursprünglich wurde RelaxNG in den Jahren
2001/2002 von der Organization for the Advancement of Structured Information Standards (OA
SIS)42 definiert, dann aber an die ISO übergeben, wo es als ISO/IEC 19757-2:2003 normiert wurde.
Gegenüber XSD (siehe oben) bietet RelaxNG einige zusätzliche Funktionalitäten, wie z. B. nicht
deterministische Inhaltsmodelle, flexiblere Behandlung von Attributen und Elementen sowie eine
Kompaktnotation, die leichter lesbar ist als die XML-Notation.
Aufgrund seiner geringeren Verbreitung SOLLTE RelaxNG nur verwendet werden, um Muster für
Struktur und Inhalt von XML-Dokumenten festzulegen, sofern die Funktionalität von XSD nicht
ausreicht.
Empfohlen: XML Metadata Interchange (XMI) 2.x
PI
le“ auf Seite 15.
Bestandsgeschützt: XML Metadata Interchange (XMI) 1.x
PI
le“ auf Seite 15.
Bestandsgeschützt: Document Type Definition (DTD)
DTD wurde als ISO 8879 normiert und zuletzt 1999 überarbeitet43. Mit dem SAGA-Modul „Techni
sche Spezifikationen“ 5.0.0 wurde DTD auf die Bestandsschutzliste gesetzt. DTD ist trotz der Ent
wicklung von XML Schema und RELAX NG zur Beschreibung von Datenstrukturen immer noch in
Bestandssystemen weit verbreitet.
39
40
41
42
43
http://www.w3.org/standards/techs/xmlschema#w3c_all
http://www.w3.org/
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=52348
http://www.oasis-open.org/
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=30235
PI
4.3 Beschreibungssprachen für Metadaten
18
4.3 Beschreibungssprachen für Metadaten
Als Metadaten werden Daten bezeichnet, die andere Datenobjekte (z. B. Dokumente) näher be
schreiben. Typische Metadaten sind beispielsweise der Autor eines Dokuments, das Erstellungsda
tum oder der Dateiname. Die meisten Dokumentenformate bieten die Möglichkeit, bestimmte Meta
daten zu pflegen. Im Folgenden werden gesonderte Beschreibungssprachen für Metadaten klassifi
ziert.
Empfohlen: Resource Description Framework (RDF)
PI
RDF44 ist eine Sprache zur Beschreibung von Informationen über Ressourcen im World Wide Web.
Insbesondere SOLLTE es für die Darstellung von Metadaten von Webseiten, z. B. Titel, Autor, Ände
rungsdatum, verwendet werden. Zu diesem Zweck besteht die Möglichkeit, RDF direkt in HTMLDateien einzubetten, ansonsten SOLLTE die W3C Recommendation RDF/XML45 zur Serialisierung
verwendet werden.
RDF wurde im Februar 2004 als W3C Recommendation veröffentlicht.
RDF beschreibt, wie Metadaten dargestellt werden sollen. Welche Metadaten angegeben werden
sollten, wird in sogenannten Vokabularen für Metadaten46 spezifiziert.
4.4 Vokabulare für Metadaten
Im vorangegangenen Abschnitt „Beschreibungssprachen für Metadaten“ werden Technologien klas
sifiziert, die es ermöglichen, Metadaten auszudrücken und maschinenlesbar zu veröffentlichen. Die
ser Abschnitt hingegen behandelt Vokabulare für Metadaten. Vokabulare spezifizieren die konkreten
Metadaten, die zu einem Objekt, z. B. einem Dokument, angegeben werden sollten. Vokabulare sind
unabhängig von der Beschreibungssprache, mit der sie im konkreten Fall dargestellt werden.
Empfohlen: Dublin Core Metadata Element Set (DCES)
Das Dublin Core Metadata Element Set (DCES)47 ist ein Vokabular von 15 Elementen und SOLLTE für
die Beschreibung von Metadaten von Dokumenten verwendet werden. DCES wird von der Dublin
Core Metadata Initiative (DCMI) herausgegeben. Damit wird eine einheitliche Semantik für die
wichtigsten Metadaten (z. B. Autor, Erstellungsdatum, etc.) festgelegt.
Das Dublin Core Metadata Element Set wurde als Norm ISO 15836 im Februar 2003, als ANSI/NI
SO-Standard Z39.85-2 im Mai 2007 und von der Internet Engineering Task Force (IETF) als RFC
5013 im August 2007 veröffentlicht.
44
45
46
47
http://www.w3.org/standards/techs/rdf#w3c_all
http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/
Siehe Abschnitt 4.4 „Vokabulare für Metadaten“
http://dublincore.org/documents/dces/
PI
5 Applikationsarchitektur
5
19
Applikationsarchitektur
In diesem Abschnitt werden Programmiersprachen und Technologien zur Realisierung der Applikati
onsarchitektur festgelegt. Dabei wird unterschieden zwischen Software-Systemen in großen Projek
ten und zwischen einfacheren Software-Systemen. Ein eigener Abschnitt ist den Spezifikationen zur
Realisierung diensteorientierter Architekturen (service-oriented architectures – SOA) gewidmet.
5.1 Applikationsarchitektur für große Projekte
Dieser Abschnitt enthält Spezifikationen, die zur Umsetzung der Applikationsarchitektur in großen
Projekten dienen. Als große Projekte werden Software-Entwicklungsprojekte angesehen, die sich
durch komplexe fachliche Anforderungen, hohes Transaktionsvolumen, enge Kopplung mit anderen
Software-Systemen, ressortübergreifende Nutzung, verteilte Architektur, Integration von Einerfür-Alle-Angeboten (EfA-Angeboten)48, umfangreiche Wiederverwendung oder einen nicht abge
schlossenen Nutzerkreis (z. B. antragsberechtigte Bürger) auszeichnen. Im Zweifelsfall obliegt die
Einschätzung der Größe des Projekts dem Projektmanager.
Empfohlen: Java Platform, Enterprise Edition (Java EE) 6
I
Die Java Enterprise Edition (Java EE)49 ist eine Spezifikation, die eine Reihe von Programmier
schnittstellen zur Entwicklung insbesondere von Webanwendungen definiert. In der Gesamtheit bil
det die Java EE eine Architektur, die wesentliche Aspekte geschäftskritischer Funktionen von An
wendungen berücksichtigt und unterstützt. Sie baut auf der Java SE auf und stellt zusätzliche Biblio
theken bereit, die besonders für Webanwendungen und Anwendungen mit komplexer Geschäftslogik
relevant sind, z. B. JAAS (Java Authentication and Authorization Service), JAXP (Java API for
XML Processing), JNDI (Java Naming and Directory Interface).
Im Jahr 2009 wurde Java EE in der Version 6 vom Java Community Process (JCP) veröffentlicht.
Unter Anwendung von Java EE entwickelte Komponenten werden durch sogenannte Application
Server ausgeführt. Neben kommerziellen Application Servern von Oracle, IBM und anderen existie
ren auch Open Source Application Server. Damit stehen Implementierungen für alle gängigen Be
triebssysteme zur Verfügung.
Java EE 6 SOLLTE zur Umsetzung objektorientierter Anwendungen in großen Projekten verwendet
werden.
Java SE 6 SOLLTE als Bestandteil von Java EE 6 auch allein verwendet werden, wenn es der Umset
zung der fachlichen Anforderungen genügt. Neben den Bibliotheken der Java SE (und Java EE)
50
KÖNNEN bei Bedarf weitere Frameworks wie Spring verwendet werden.
Beobachtet: Common Language Infrastructure (CLI)
Der Standard ECMA-33551 „Common Language Infrastructure (CLI)“ (ISO/IEC 23271:2006 und
ISO/IEC TR 23272:2006)52 definiert eine Infrastruktur für verschiedene Systemumgebungen, in der
48
49
50
51
52
Siehe (BFIT, 2011A)
http://jcp.org/en/jsr/detail?id=316
http://www.springsource.org/
http://www.ecma-international.org/publications/standards/Ecma-335.htm
http://www.iso.org/
I
5.1 Applikationsarchitektur für große Projekte
20
Anwendungen, die in verschiedenen Programmiersprachen geschrieben wurden, ausgeführt werden
können. Die Infrastruktur abstrahiert von spezifischen Eigenschaften der Systemumgebungen, so
dass Anwendungen nicht verändert werden müssen, um sie auf verschiedenen Systemen zu betrei
ben.
Die bekannteste Implementation des ECMA-Standards ist das .NET-Framework 53 von Microsoft. Es
läuft nur unter Windows-Betriebssystemen. Die Verfügbarkeit für weitere Betriebssysteme wird vor
allem durch die Implementation des Projektes Mono54 sichergestellt.
Mit der CLI wird nur eine Teilmenge der Funktionalität der Common Language Runtime (CLR)
standardisiert. Die Spezifikation der CLR selbst ist nicht offen gelegt. Die Verbreitung der CLI in der
Praxis entspricht deshalb nicht den Möglichkeiten, die der universale Ansatz bietet und ist im We
sentlichen auf das Windows-Betriebssystem beschränkt.
CLI KANN in großen Projekten verwendet werden, beispielsweise wenn die Umsetzung wesentlich
wirtschaftlicher ist als mittels der empfohlenen Alternativen.
Bestandsgeschützt: Java Platform, Enterprise Edition (Java EE) 5
I
Java EE 5 wurde mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 durch die Version 6 er
setzt.
Bestandsgeschützt: Java 2 Platform, Enterprise Edition (J2EE) 1.4
I
In SAGA 3.0 war diese Version von J2EE als „Obligatorisch“ klassifiziert. Mit SAGA 4.0 erfolgte
eine Festlegung auf den Nachfolger Java Platform, Enterprise Edition (Java EE) 5.
Bestandsgeschützt: Java 2 Platform, Enterprise Edition (J2EE) 1.3
I
Die Version 1.3 von J2EE war in SAGA 1.1 als „Obligatorisch“ klassifiziert. Die nachfolgende Ver
sion 1.4 wurde in SAGA 2.0 als „Obligatorisch“ klassifiziert.
5.2 Applikationsarchitektur für kleine und mitt
lere Projekte
Dieser Abschnitt enthält Spezifikationen, die zur Umsetzung der Applikationsarchitektur in Projek
ten dienen, die nicht in die im Abschnitt 5.1 beschriebene Kategorie der großen Projekte fallen. Im
Zweifelsfall obliegt die Einschätzung der Größe dem Projektmanager.
Empfohlen: Java Platform, Standard Edition (Java SE) 6
Die Java Standard Edition55 (Java SE) ist eine Spezifikation, die eine Reihe von Programmierschnitt
stellen zur Entwicklung von Business-Anwendungen definiert. In der Gesamtheit bildet die Java SE
eine Architektur, die wesentliche Aspekte geschäftskritischer Funktionen von Anwendungen berück
sichtigt und unterstützt.
Im Jahr 2006 wurde Java SE in der Version 6 vom JCP veröffentlicht.
53 http://www.microsoft.com/net/
54 http://www.mono-project.de/
55 http://jcp.org/en/jsr/summary?id=270
I
5.2 Applikationsarchitektur für kleine und mittlere Projekte
21
Java SE 6 SOLLTE zur Umsetzung objektorientierter Applikationen verwendet werden.
Wenn Java SE 6 den fachlichen Anforderungen nicht genügt, SOLLTE Java EE 6 verwendet werden.
Neben den Bibliotheken der Java SE und Java EE KÖNNEN bei Bedarf weitere Frameworks wie
Spring56 verwendet werden.
Empfohlen: PHP: Hypertext Preprocessor (PHP) 5.x
I
PHP57 ist eine in HTML eingebettete Skriptsprache für die Entwicklung von Webanwendungen.
Im Jahr 2010 wurde PHP in der Version 5.3.4 von der PHP Group veröffentlicht.
Wenn ausgeschlossen werden kann, dass für ein Software-System Integrationsbedarf besteht, also für
die Entwicklung von nicht verteilten Stand-Alone-Anwendungen, die nicht mit Einer-für-Alle-Ange
boten (EfA-Angeboten)58, mit Legacy-Systemen oder anderen Software-Systemen kommunizieren,
SOLLTE PHP 5.x verwendet werden. Hierbei ist zu beachten, dass für Versionen kleiner 5.3 keine Wei
terentwicklung stattfindet und eventuell benötigte Funktionen nicht zur Verfügung stehen. Es SOLLTE
stets auf die neueste finalisierte Version gesetzt werden.
Empfohlen: C++
I
C++59 ist eine Sprache zur objektorientierten, generischen und prozeduralen Programmierung.
Im Oktober 2003 wurde C++ als ISO/IEC 14882:2003 von der Open Standard Working Group „The
C++ Standards Committee“60 veröffentlicht. Die ISO-Norm spezifiziert Anforderungen an die Imple
mentierung der Programmiersprache C++ und enthält eine Standardbibliothek. Derzeit findet eine
Überarbeitung der ISO-Norm statt.
C++ SOLLTE insbesondere dann in Projekten eingesetzt werden, wenn eine hohe Performanz gefordert
ist, die durch die relativ maschinennahe Programmierung in C++ erreicht werden kann.
Empfohlen: Python
I
Python61 ist eine in der Regel interpretierte höhere Programmiersprache, die insbesondere auf Pro
grammlesbarkeit ausgelegt ist. Neben der objektorientierten Programmierung unterstützt Python
auch aspektorientierte und funktionale Programmierung. Oft wird Python auch zur Skriptprogram
mierung verwendet.
Python SOLLTE insbesondere dann in Projekten eingesetzt werden, wenn keine hohen Anforderungen
an die Performanz gestellt werden sowie Wartbarkeit und Agilität zentrale Anforderungen an das
Software-System sind.
Beobachtet: Ruby
Ruby62 ist eine interpretierte und objektorientierte höhere Programmiersprache. Neben der Objektori
entierung unterstützt Ruby weitere Programmierparadigmen, unter anderem prozedurale und funk
tionale Programmierung. Ruby wird auch zur Skriptprogrammierung verwendet.
56
57
58
59
60
61
62
http://www.springsource.org/
http://php.net/
Siehe (BFIT, 2011A)
http://www.open-std.org/JTC1/SC22/WG21/
http://docs.python.org/
http://www.ruby-lang.org/de/downloads/
I
5.2 Applikationsarchitektur für kleine und mittlere Projekte
22
Ruby KANN insbesondere dann in Projekten eingesetzt werden, wenn keine hohen Anforderungen an
die Performanz und die Robustheit gestellt werden sowie Wartbarkeit und Agilität zentrale Anforde
rungen an das Software-System sind.
Beobachtet: Common Language Infrastructure (CLI)
I
Siehe Common Language Infrastructure (CLI) im Abschnitt 5.1 „Applikationsarchitektur für große
Projekte“ auf Seite 19.
CLI KANN in kleinen und mittleren Projekten verwendet werden, wenn die Umsetzung wesentlich
wirtschaftlicher ist als mittels der empfohlenen Alternativen.
Bestandsgeschützt: Java 2 Platform, Standard Edition (J2SE) 5.0
I
J2SE 5.0 wurde mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 durch Java SE 6 ersetzt.
I
In SAGA 3.0 war diese Version von J2SE als „Obligatorisch“ klassifiziert. Mit SAGA 4.0 erfolgte
eine Festlegung auf den Nachfolger Java Platform, Standard Edition (Java SE) 5.
I
Die Version 1.3 von J2SE war in SAGA 1.1 als „Obligatorisch“ klassifiziert. Die nachfolgende Ver
sion 1.4 wurde in SAGA 2.0 als „Obligatorisch“ klassifiziert.
Bestandsgeschützt: PHP: Hypertext Preprocessor (PHP) 4.x
I
In SAGA 2.0 wurde PHP 4.x als „Empfohlen“ klassifiziert. Es wurde in SAGA 2.1 durch die nach
folgende Version 5.x ersetzt.
Bestandsgeschützt: Perl
Zwar zeigt die Erfahrung, dass sich mit entsprechend qualifizierten Mitarbeitern auch mit Perl jedes
erdenkliche Problem lösen lässt, die Pflege und Erweiterbarkeit von komplexen mit Perl erstellten
Software-Systemen (durch andere Mitarbeiter als die ursprünglichen Entwickler) lässt aber zu wün
schen übrig – jedenfalls im Vergleich zu anderen Sprachen. Vor allem die Ziele von SAGA Wieder
verwendbarkeit und Skalierbarkeit werden von den in SAGA geführten Technologien besser erreicht
als von Perl.
5.3 Diensteorientierte Architekturen
In diesem Abschnitt sind die Spezifikationen aufgelistet, die bei der Implementation diensteorientier
ter Architekturen relevant sind. Die Spezifikationen, die ausschließlich Interoperabilität in dienste
orientierten Architekturen sicherstellen, befinden sich im Abschnitt 8.1 „Kommunikation zwischen
Applikationen“ auf Seite 53.
I
23
Empfohlen: WS-I Basic Profile 1.1 / 1.2
PI
Das WS-I Basic Profile63 spezifiziert Richtlinien für Kernstandards zum Thema Web Services (z. B.
SOAP 1.1, WSDL 1.1 und UDDI v2.0), die zur Beförderung von Interoperabilität angewendet wer
den SOLLTEN.
Das WS-I Basic Profile 1.1 wurde 2006 von der Web Services Interoperability Organization (WS-I)
veröffentlicht und 2008 von der ISO als ISO/IEC 29361 normiert. Das WS-I Basic Profile 1.264 wur
de 2010 von der WS-I veröffentlicht.
Gegenüber Version 1.1 beinhaltet Version 1.2 zusätzlich asynchrones Messaging, WS Addressing 1.0
und MTOM. Werden diese Technologien benötigt, SOLLTE das WS-I Basic Profile 1.2 angewendet
werden, andernfalls SOLLTE Version 1.1 zum Einsatz kommen.
Weitere WS-I-konforme Profile sind Simple Soap Binding Profile, Basic Security Profile, Reliable
Secure Profile, Kerberos Token Profile, REL Token Profile und SAML Token Profile.65
Empfohlen: Web Services Description Language (WSDL) 1.1
PI
WSDL66 ist eine auf XML basierende Sprache zur Beschreibung von Operationen (Web Services).
Die Beschreibung ermöglicht den automatischen Aufruf der Operationen.
Die formale Veröffentlichung durch das W3C erfolgte als WSDL 1.1 im Mai 2001.
Empfohlen: Web Services Business Process Execution Language (WS-BPEL) 2.0
PI
WS-BPEL67 dient der Orchestrierung von Geschäftsprozessen auf Basis von Web Services. Die Spe
zifikation definiert hierbei eine XML-basierte Sprache, welche diese Prozesse beschreibt und die auf
BPEL-basierten Workflow-Maschinen direkt ausführbar ist.
Im Jahr 2007 wurde WS-BPEL in der Version 2.0 von der OASIS veröffentlicht.
Beobachtet: WS-I Basic Profile 2.0
PI
Siehe WS-I Basic Profile 1.1 auf Seite 23.
Das WS-I Basic Profile 2.068 wurde 2010 von der WS-I veröffentlicht.
Die wesentlichste Neuerung des WS-I Basic Profile 2.0 ist die Referenzierung von SOAP 1.2. Die
Vorgängerversionen 1.1 und 1.2 setzen auf SOAP 1.1. WS-I Basic Profile 2.0 KANN verwendet wer
den, wenn neue Features benötigt werden.
Beobachtet: Web Services Description Language (WSDL) 2.0
Siehe Web Services Description Language (WSDL) 1.1 auf Seite 23.
Die formale Veröffentlichung durch das W3C erfolgte als WSDL 2.069 im Juni 2007.
63
64
65
66
67
68
69
http://ws-i.org/Profiles/BasicProfile-1.1.html
http://ws-i.org/profiles/BasicProfile-1.2-2010-11-09.html
http://ws-i.org/
http://www.w3.org/TR/2001/NOTE-wsdl-20010315
http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html
http://ws-i.org/profiles/BasicProfile-2.0-2010-11-09.html
http://www.w3.org/TR/wsdl20/
PI
24
Als Nachfolger von WSDL 1.1 KANN WSDL 2.0 verwendet werden, wenn die Vorteile durch Erwei
terungen in WSDL 2.0 die Nachteile der Inkompatibilität zu WSDL 1.1 überwiegen.
Beobachtet: Service Component Architecture (SCA) 1.0
SCA70 ist eine Zusammenstellung von Spezifikationen zur Definition eines Modells zur Implemen
tierung von SOA-basierten Anwendungen.
SCA wurde 2007 in der Version 1.0 von der Open SOA Collaboration (OSOA)71 veröffentlicht.
SCA KANN verwendet werden, wenn die Wiederverwendbarkeit von erstellten Komponenten, die Ab
straktion der Service-Implementierung von den Infrastruktur-Rahmenbedingungen oder die Verfüg
barkeit für möglichst viele Programmiersprachen bzw. Implementierungsstandards benötigt wird.
6
Client
Der Client ist eine Software auf einem Endgerät, die einen von anderen Applikationen angebotenen
Dienst in Anspruch nimmt. Die Client-Schicht umfasst somit die klassische Benutzerseite, um mit
der öffentlichen Verwaltung zu interagieren, wobei der Informationszugriff über unterschiedliche
Hardware erfolgen kann. In Deutschland haben bislang vor allem die folgenden Geräte Verbreitung
gefunden, sodass für diese Endgeräte optimale Voraussetzungen für die breite Nutzung von Soft
ware-Systemen der öffentlichen Verwaltung bestehen:
a.
Computer (z. B. PC, Notebook)
b. Mobile Endgeräte (z. B. Mobiltelefone, PDAs (Personal Digital Assistants), Smartphones)
c.
Externe Systeme (z. B. ERP-Systeme von Industrieunternehmen)
Standardisierungsbemühungen insbesondere für digitales, interaktives Fernsehen sind in den letzten
Jahren vorangetrieben worden, aber noch nicht zu einheitlichen Empfehlungen gekommen.
6.1 Informationszugriff mit Computern
Auf Computern72 stehen prinzipiell zwei unterschiedliche Clients zur Verfügung, um auf Informatio
nen 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 internetba
sierte Dienste, E-Mail-Server und – je nach Erlaubnis – auf das Betriebssystem zur Nutzung lokaler
Ressourcen wie lokaler Datenträger.
6.1.1
Einsatz aktiver Inhalte im Client
Aktive Inhalte sind Computer-Programme (z. B. Javascript, Java Applets, ActiveX-Controls, Silver
light-Anwendungen oder auch Flash-Animationen), die in Webseiten oder Dateien (z. B. PDF-Doku
mente, Office-Dokumente) enthalten sind oder beim Betrachten automatisiert nachgeladen werden
und auf dem Client (vom Anzeigeprogramm oder Betriebssystem) ausgeführt werden.
70 http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications
71 http://www.osoa.org/
72 Von einem Computer wird in diesem Zusammenhang dann gesprochen, wenn das Endgerät kein klei
nes Display (Bildschirmdiagonale > 10 Zoll), keine geringe Bandbreite und eine Tastatur besitzt.
I
6.1.1 Einsatz aktiver Inhalte im Client
25
Grundsätzlich MÜSSEN öffentliche Web-Seiten und Software-Systeme so gestaltet sein, dass sie auch
ohne aktive Inhalte nutzbar sind. Diese Forderung deckt sich mit der als „Verbindlich“ klassifizierten
BITV73. Damit wird erreicht, dass Anwender nicht gezwungen werden, wegen Software-Systemen
der öffentlichen Verwaltung ihre lokalen Sicherheitseinstellungen zu lockern.
Bei der Verwendung aktiver Inhalte dürfen nur die in SAGA zugelassenen Client-Spezifikationen
zum Einsatz kommen, siehe auch Abschnitt 7.4 „Spezifikationen für aktive Inhalte“ auf Seite 34.
Active-X-Controls DÜRFEN NICHT eingesetzt werden.
6.1.2
Web-Browser
Um bei der Realisierung von Software-Systemen eine breite Nutzung zu ermöglichen, SOLLTEN als
Frontend Web-Browser verwendet werden, die die Formate der Präsentationsebene verarbeiten und
darstellen können, siehe Kapitel 7 „Präsentation“ ab Seite 30. Hierbei sind folgende browser-basierte
Client-Technologien zugelassen:
1. Die Nutzung von Cookies ist zugelassen, soweit
•
diese nicht persistent sind und
•
Webseiten einer Domain keine Inhalte anderer Domains inkludieren, welche Cookies
setzen.
Hierbei sind die Empfehlungen zum HTTP-Protokoll gemäß Abschnitt 8.5 „An
wendungsprotokolle“ auf Seite 60 zu berücksichtigen.
2.
Die Nutzung von Javascript ist zugelassen. Jedoch MUSS sichergestellt sein, dass die Websei
ten auch dann verwendbar sind, wenn Javascript deaktiviert wurde. Bei der Nutzung von Ja
vascript ist der Abschnitt 6.1.1 „Einsatz aktiver Inhalte im Client“ auf Seite 24 zu berück
sichtigen.
3.
Die Nutzung von Java-Applets ist zugelassen, wenn diese vom Server signiert sind und da
mit als authentisch und integer beim Client erkannt werden können. Die Hersteller von JavaApplets MÜSSEN ihr Produkt vorzugsweise durch ein vom Hersteller unabhängiges SoftwareUnternehmen qualitätssichern lassen oder die Qualität zumindest in Form einer Erklärung
zusichern74.
4.
Nach Möglichkeit SOLLTE auf den Einsatz von Plug-Ins verzichtet werden. Wird dennoch der
Einsatz von Plug-Ins für notwendig befunden, SOLLTEN die Plug-Ins die folgenden Anforde
rungen erfüllen:
•
Soll ein heterogener Anwenderkreis erreicht werden, MUSS das Plug-In in mindestens ei
nem der gängigen Browser auf allen gängigen Betriebssystemen laufen (mindestens: In
ternet Explorer, Mozilla Firefox oder Safari für die Plattformen Windows XP/Windows
Vista/Windows 7, Linux und Mac OS X). Für die Nutzer des Software-Systems SOLLTEN
alle vom Plug-In unterstützten Betriebssysteme und Web-Browser aufgezählt werden
73 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://bundesrecht.juris.de/bitv/)
74 Nähere Informationen zu diesem Thema sind unter http://www.cio.bund.de/saga → „Java-Applets“
zu finden.
6.1.2 Web-Browser
26
und Hinweise zur Installation des Plug-Ins gegeben werden, möglichst mit einem Link
zum Download des Plug-Ins.
•
Wenn nach angemessener Prüfung ermittelt wird, dass das Plug-In deutsche Daten
schutzgesetze (z. B. bei der Übertragung von Informationen über den Anwender) nicht
einhält, DARF es NICHT verwendet werden – unabhängig davon, wo es entwickelt wurde.
Es dürfen nur Daten zum und vom Plug-In übertragen werden, die direkt mit dem Be
trieb des Plug-Ins, mit der Aktualisierung des Plug-Ins oder mit dem Betrieb des Soft
ware-Systems in Verbindung stehen.
•
Wenn nach angemessener Prüfung ermittelt wird, dass das Plug-In ein instabiles Lauf
zeitverhalten oder Schwachstellen bzw. Sicherheitslücken enthält, DARF es NICHT ver
wendet werden. Wenn für ein Plug-In zu einem späteren Zeitpunkt Schwachstellen bzw.
Sicherheitslücken bekannt werden, SOLLTEN die Nutzer des Software-Systems auf diesen
Umstand sowie auf vorhandene Lösungen hingewiesen werden.
•
Plug-Ins, die von der Bundesverwaltung entwickelt wurden, SOLLTEN digital signiert
werden, um Authentizität und Integrität des Plug-Ins für die Nutzer sicherzustellen.
Weitere Informationen und Hinweise zum Einsatz von Plug-Ins können auf der
Website des Bundesamts für Sicherheit in der Informationstechnik (BSI) nachgele
sen werden.75
5.
Für gängige Browser-Typen werden Beispielkonfigurationen erstellt und vom BSI über das
Internet allgemein zur Verfügung gestellt76.
6.
Beim Versand von Formulardaten ist die Vertraulichkeit der Informationen durch Verwen
dung von TLS-verschlüsselten Kanälen (siehe Abschnitt 8.5 „Anwendungsprotokolle“ auf
Seite 60) unter Nutzung zugehöriger Server-Zertifikate sicherzustellen.
7. Bei der Nutzung der zugelassenen Client-Technologien für öffentliche Web-Seiten und Soft
ware-Systeme MUSS die Barrierefreie Informationstechnik Verordnung (BITV)77 unverändert
berücksichtigt werden.
6.1.3
Client-Anwendungen
Empfohlen: Java Platform, Standard Edition (Java SE) 6
Siehe Java Platform, Standard Edition (Java SE) 6 im Abschnitt 5.2 „Applikationsarchitektur für
kleine und mittlere Projekte“ auf Seite 20.
Kommt der Web-Browser als Client nicht in Frage, SOLLTE Java SE 6 zur Umsetzung objektorientier
ter Client-Anwendungen verwendet werden.
Wenn Java SE 6 den fachlichen Anforderungen nicht genügt, SOLLTE Java EE 6 verwendet werden.
Neben den Bibliotheken der Java SE und Java EE KÖNNEN bei Bedarf weitere Frameworks Spring78
verwendet werden.
75 http://www.bsi.bund.de/ → „Themen“ → „Internet-Sicherheit“ → „Gefährdungen“ → „Aktive In
halte“ → „Definitionen und Gefahren“ → „Plug-Ins“
76 http://www.bsi.bund.de/Webbrowser
77 Siehe „Barrierefreie Informationstechnik Verordnung (BITV)“ im Abschnitt 7.1 „Barrierefreie Dar
stellung“ auf Seite 30
78 http://www.springsource.org/
I
6.1.3 Client-Anwendungen
27
Empfohlen: Java Network Launching Protocol (JNLP) 6.x
PI
JNLP79 definiert ein plattformunabhängiges Protokoll und SOLLTE für die Verteilung, Installation, das
Starten und Aktualisieren von Java-Programmen über das Internet verwendet werden. Für das Intra
net KANN eine Abweichung von diesem Vorgehen erfolgen, wenn dort Verteilmechanismen für Soft
ware eingesetzt werden, die für Java- und Nicht-Java-Programme funktionieren.
2010 wurde JNLP in der Version 6.0.18 vom JCP veröffentlicht.
I
J2SE 5.0 wurde mit der Aktualisierung von SAGA 4.0 auf die Bestandsschutzliste gesetzt. Stattdes
sen wurde Java SE 6 in SAGA aufgenommen.
Bestandsgeschützt: Java Network Launching Protocol (JNLP) 1.5
PI
JNLP 1.5 wurde mit der Aktualisierung von SAGA 4.0 durch Version 6.0 ersetzt.
6.1.4
E-Mail-Client
Zum Empfangen, Senden und Bearbeiten von E-Mails sind E-Mail-Clients einzusetzen, die mindes
tens die technische Unterstützung der E-Mail-Spezifikationen aus Abschnitt 8.3 „E-Mail-Kommuni
kation“ auf Seite 58 gewährleisten.
6.2 Informationszugriff mit mobilen Endgeräten
Mobiltelefone, PDAs (Personal Digital Assistants), Smartphones und andere mobile Endgeräte besit
zen in Abgrenzung zum Computer
a.
ein kleines Display (Bildschirmdiagonale kleiner 10 Zoll),
b. eine geringe Bandbreite oder
c.
keine Standardtastatur
und MÜSSEN die von Servern angebotenen Spezifikationen für mobile Endgeräte der Präsentations
schicht unterstützen80. Weiterhin SOLLTEN so umfassend wie möglich die Spezifikationen, die zur Prä
sentation von Inhalten durch Computer im Allgemeinen beschrieben werden, auch durch die mobilen
Endgeräte dargestellt werden81.
Auch für mobile Endgeräte sind die im Abschnitt 6.1 „Informationszugriff mit Computern“ auf Seite
24 beschriebenen Anforderungen einzuhalten.
Beobachtet: Java Plattform, Micro Edition (Java ME) / Mobile Information Device
Profile (MIDP) 2.0
Java ME besteht aus Konfigurationen und Profilen für einen effizienten Einsatz von Java auf mobi
len Endgeräten, wie z. B. die Connected Limited Device Configuration (CLDC)82 und das Mobile In
formation Device Profile (MIDP).
79
80
81
82
Siehe Abschnitt 7.14 „Technologien für die Präsentation auf mobilen Endgeräten“ auf Seite 52
Siehe Kapitel 7 „Präsentation“ auf Seite 30
I
6.2 Informationszugriff mit mobilen Endgeräten
28
MIDP ist ein speziell für Handys angepasstes Profil, das in die CLDC von Java ME eingebettet ist.
Es umfasst u. a. Funktionen für den Zugriff auf das Netzwerk, den Arbeitsspeicher, die Tastatur und
Miniaturbildschirme. Hersteller von Java ME kompatiblen Handys müssen den MIDP-Standard im
plementieren.
Die Version 3.083 von MIDP stammt aus dem Jahr 2009 – weiter verbreitet ist allerdings MIDP 2.0 84,
das zuletzt im Juni 2006 überarbeitet wurde. Die Weiterentwicklung von Java ME wurde inzwischen
eingestellt. Dennoch hat Java ME – auch aufgrund der Weiterentwicklung von MIDP – eine so hohe
Verbreitung, dass es für Anwendungen auf mobilen Endgeräten verwendet werden KANN, wenn der
Web-Browser als Client nicht in Frage kommt.
6.3 Informationszugriff durch externe Systeme
Die Kommunikation und Interaktion zwischen externen und internen Systemen SOLLTE über eine
Teilmenge der Spezifikationen abgewickelt werden, die für die Kommunikation und Interaktion zwi
schen internen Systemen definiert werden.85
6.4 Technologien zur Authentisierung
Um die Schutzziele Vertraulichkeit und Integrität zu gewährleisten, ist die Identitätsfeststellung und
Authentisierung von Kommunikationspartnern für bestimmte Software-Systeme erforderlich.
Empfohlen: WS-Trust 1.3
PI
WS-Trust86 ist eine Erweiterung von WS-Security und SOLLTE zum initialen Austausch von sicher
heitsrelevanten und geheimen Daten genutzt werden. Im Mittelpunkt steht dabei der Security Token
Service (STS), welcher die Aspekte Format, Vertrauensbeziehung und Namensräume beim Umgang
mit Sicherheitstoken behandelt.
Im März 2007 wurde WS-Trust 1.3 von der OASIS veröffentlicht.
Empfohlen: WS-Federation 1.1
WS-Federation87 ist eine Spezifikation aus der WS-*-Familie, welche zur Nutzung von Web Services
über unterschiedliche Sicherheitsdomänen hinweg verwendet werden SOLLTE. Dazu definiert WS-Fe
deration ein XML-basiertes Austauschformat zum sicheren Datenaustausch zwischen unterschiedli
chen Sicherheitsdomänen. Weiterhin wird ein Federation-Modell zum Umgang mit aktiven und pas
siven Requestoren spezifiziert. Als Basis dienen die durch WS-Trust bereit gestellten Sicherheitsto
ken.
Im Mai 2009 wurde WS-Federation 1.1 von der OASIS veröffentlicht.
83 http://jcp.org/en/jsr/detail?id=271
85 siehe dazu Abschnitt 7.6 „Austauschformate für Daten“ auf Seite 35, Kapitel 8 „Kommunikation“
auf Seite 53 und Kapitel 9 „Backend“ auf Seite 65
86 http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.pdf
87 http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-fed/WS-Federation-V1-1B.pdf
PI
29
Empfohlen: Security Assertion Markup Language (SAML) ≥1.0
PI
Mittels SAML88, einer auf XML basierenden Beschreibungssprache, können Web Services auf einfa
che Art und Weise authentifizierungs- und autorisierungsbezogene Informationen austauschen. Web
Single Sign-on und Identity Federation zählen zu den Hauptanwendungsszenarien. SAML hat einen
zu WS-Federation parallelen Ansatz, um Identity Federation umzusetzen, der jedoch nicht mit WSFederation interoperabel ist. WS-Federation, basierend auf WS-Trust, ist wesentlich flexibler bzgl.
der Verwendung von Sicherheitstoken.
SAML wurde erstmalig in der Version 1.0 im November 2002 von der OASIS verabschiedet. Die
Version 2.0 stammt aus dem März 2005.
Empfohlen: Extensible Access Control Markup Language (XACML) 2.0
PI
Mittels XACML89 SOLLEN Autorisierungsinformationen, Darstellungen und Regeln nach einem stan
dardisierten XML-Schema beschrieben werden. Neben einer XML-Sprache zur Zugriffskontrolle
wird auch eine standardisierte verteilte Architektur definiert.
Im Februar 2005 wurde XACML 2.0 von der OASIS veröffentlicht.
Beobachtet: Kerberos 5
PI
Kerberos90 beschreibt einen verteilten Authentifizierungsdienst für offene, unsichere Netzwerke und
bietet einen fälschungssicheren befristeten Identitätsnachweis mittels Token. Ein zentrales Element
dieser Infrastruktur ist der Kerberos-Server, welcher die Rolle der vertrauenswürdigen dritten Partei
übernimmt.
Kerberos 5 wurde am Massachusetts Institute of Technology entwickelt und im Juli 2005 als RFC
4120 veröffentlicht.
Beobachtet: Open-ID 2.0
PI
Open-ID91 ist eine Open-Source-Spezifikation zur dezentralen Authentifizierung von Webseiten so
wie für eine Reihe anderer webbasierter Dienste, durch die es Nutzern möglich ist, sich auf verschie
denen Webseiten mit einer Open-ID-Identität in Form einer URL zu identifizieren, statt auf jeder ein
zelnen Webseite die Benutzerkennung und das Passwort einzugeben.
Open-ID 2.0 wurde im Jahr 2007 von der Open-ID Foundation92 herausgegeben.
Beobachtet: Liberty Identity Web Services Framework (ID-WSF) 2.0
ID-WSF93 ermöglicht auf Basis des Liberty Identity Federation Framework (ID-FF) die Nutzung von
Identitäten durch Web Services. Das Framework beschreibt die technischen Grundlagen zur Erstel
lung von interoperablen, identitätsbasierten Web Services.
Im Oktober 2010 wurde ID-WSF 2.0 von der Kantara Initiative herausgegeben.
88
89
90
91
92
93
http://www.oasis-open.org/standards
http://www.oasis-open.org/standards#xacmlv2.0
http://tools.ietf.org/html/rfc4120
http://openid.net/developers/specs/
http://openid.net/foundation/
http://kantarainitiative.org/confluence/display/idwsf/Home
PI
30
Beobachtet: Liberty Identity Services Interface Specification (ID-SIS) 1.0
PI
ID-SIS94 stellt eine Schnittstelle zu Liberty Basisfunktionen dar, sodass eine Anbindung von erwei
terten Diensten möglich ist. Aufbauend auf dem Liberty Identity Web Services Framework sowie
dem Liberty Identity Federation Framework wird definiert, wie unterschiedliche Identitätsinforma
tionen standardisiert ausgetauscht werden können.
Die Version 1.0 von ID-SIS wurde im Jahr 2006 von der Liberty Alliance spezifiziert. Eine Arbeits
gruppe der Kantara Initiative hat inzwischen die weitere Pflege der Spezifikation übernommen 95.
Bestandsgeschützt: Liberty Identity Federation Framework (ID-FF) 1.2
PI
ID-FF spezifiziert Akteure, Datentypen und Nachrichtenflüsse für ein Single Sign-On über mehrere
Diensteanbieter. ID-FF 1.2 wurde mit SAGA 3.0 in die Vorschlagsliste aufgenommen. Im Jahr 2005
ist ID-FF 1.2 in SAML 2.0 aufgegangen und wurde nicht mehr als eigenständige Spezifikation wei
terentwickelt. Alle in ID-FF 1.2 spezifizierten Funktionalitäten sind in SAML 2.0 umsetzbar, das in
SAGA 4.0 klassifiziert wurde. Aus diesem Grund wurde ID-FF 1.2 mit SAGA 4.0 auf die Bestands
schutzliste verschoben.
Bestandsgeschützt: Identity Web Services Framework (ID-WSF) 1.1
PI
Version 1.1 des ID-WSF wurde mit der Aktualisierung von SAGA 4.0 auf die Bestandsschutzliste
gesetzt. Stattdessen wurde ID-WSF 2.0 in SAGA aufgenommen.
Bestandsgeschützt: BSI, E-Government-Handbuch, Modul „Authentisierung im
E-Government“
PI
Mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 wurde das Modul „Authentisierung im
E-Government“ des E-Government-Handbuchs auf die Bestandsschutzliste verschoben.
7
Präsentation
Die Präsentationsschicht stellt den Clients Informationen zur Verfügung. Je nach Anwendungsfall
müssen unterschiedliche Formate bereitgestellt werden, die in den folgenden Abschnitten aufgelistet
werden. Die Verwendung offener Austauschformate, die über hinreichend viele Funktionen verfügen
und auf unterschiedlichen Plattformen verfügbar sind, wird grundsätzlich gefordert.
Neben den klassifizierten Formaten ist es zulässig, Informationen zusätzlich in Formaten anzubieten,
die von SAGA nicht berücksichtigt werden.
7.1 Barrierefreie Darstellung
Verbindlich: Barrierefreie Informationstechnik Verordnung (BITV)
Die BITV96 konkretisiert als Rechtsverordnung das Behindertengleichstellungsgesetz 97 (BGG) in Be
zug auf die Berücksichtigung von Barrierefreiheit in der Informationstechnik und beschreibt die
94
95
96
97
http://projectliberty.org/resource_center/specifications/liberty_alliance_id_sis_1_0_specifications
http://kantarainitiative.org/confluence/display/WGLSM/Home
http://bundesrecht.juris.de/bitv/
http://bundesrecht.juris.de/bgg/
PI
7.1 Barrierefreie Darstellung
31
technischen Anforderungen an Layout, Design und Benutzerführung, die zu erfüllen sind, wenn eine
Website für alle Benutzer zugänglich gestaltet sein soll. Insbesondere die Gruppe der behinderten
Menschen wird in dieser Verordnung berücksichtigt.
Die BITV MUSS bei der Erstellung öffentlich zugänglicher Web-Seiten und Software-Systeme beach
tet werden98.
7.2 Zeichensätze und -kodierungen
Verbindlich: Unicode ≥2.1
PI
Der Unicode-Standard99 beschreibt einen Zeichensatz, der die meisten der heute gebräuchlichen so
wie viele historische Zeichen aus dutzenden Sprachen abbildet. Er beinhaltet weit über 100.000 ver
schiedene Zeichen.
Die verschiedenen Versionen von Unicode werden vom Unicode Consortium100 veröffentlicht und
von der ISO nahezu deckungsgleich als ISO/IEC 10646101 normiert und durch die IETF als
RFC 3629102 standardisiert.
Seit Unicode Version 2.0 unterscheiden sich die verschiedenen Versionen des Standards hauptsäch
lich durch immer neu hinzugekommene Zeichen. Für die Verwendung durch die Bundesverwaltung
103
MUSS mindestens Version 2.1 (Einführung des €-Zeichens ) eingesetzt werden. Darüber hinaus ist
die anzuwendende Unicode Version abhängig von den darzustellenden Zeichen. So wird beispiels
weise die Batak-Schrift erst in der Version 6.0104 unterstützt.
Da aufgrund der fachlichen Anforderungen niemals alle Unicode-Zeichen in einem Software-System
benötigt werden, SOLLTE das Set der unterstützten Zeichen für jedes Software-System konkret spezi
fiziert werden, damit alle Komponenten alle notwendigen Zeichen verarbeiten können (speichern,
übertragen, anzeigen, drucken, ...).
Verbindlich: UTF-8
Das UCS Transformation Format (UTF)105, auch als Unicode Transformation Format bezeichnet,
dient der Transformation von menschenlesbaren Zeichen in maschinenlesbaren Code (Bytes). Dabei
wird jedem Zeichen ein Zahlenwert zugeordnet, welcher schließlich durch UTF kodiert wird. Die
Festlegung der Zeichen-Zahlenwert-Zuordnung erfolgt durch den zugrunde gelegten Zeichensatz,
z. B. Unicode (Universal Character Set).
Die gebräuchlichsten Versionen von UTF sind UTF-8 und UTF-16. Beide Zeichenkodierungsmetho
den eignen sich für den gesamten Unicode-Standard. Hinsichtlich der Anwendungsgebiete unter
scheiden sich jedoch beide Versionen. UTF-8 ist auf die Verwendung mit europäischen Schriftzei
chen optimiert und ist kompatibel zu ASCII und ISO 8859-1 (ISO Latin-1). In Software-Systemen
der deutschen Verwaltung MUSS deshalb UTF-8 eingesetzt werden. UTF-16 bietet Vorteile gegenüber
98
99
100
101
102
103
104
105
Siehe BITV §1 „Sachlicher Geltungsbereich“, http://bundesrecht.juris.de/bitv/
http://www.unicode.org/versions/Unicode6.0.0/
http://www.unicode.org/standard/standard.html
http://www.iso.org/
http://www.unicode.org/Public/2.1-Update/ReadMe-2.1.1.txt
http://www.unicode.org/versions/Unicode6.0.0/
PI
7.2 Zeichensätze und -kodierungen
32
UTF-8 lediglich bei extensiver Nutzung nicht-europäischer Schriftzeichen (z. B. Thailändisch, Ben
galisch etc.).
Bestandsgeschützt: ISO 8859-1
PI
Bis SAGA 2.1 war ISO 8859-1 als „Empfohlen“ klassifiziert. Die Verwendung des Zeichensatzes
bietet gegenüber UTF-8 keine Vorteile mehr und SOLLTE daher in neuen Projekten NICHT mehr vorge
zogen werden.
Bestandsgeschützt: ISO 8859-15
PI
Bis SAGA 2.1 war ISO 8859-15 als „Empfohlen“ klassifiziert. Die Verwendung des Zeichensatzes
bietet gegenüber UTF-8 keine Vorteile mehr und SOLLTE daher in neuen Projekten NICHT mehr vorge
zogen werden.
Bestandsgeschützt: UTF-16
PI
UTF-16 wurde mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 auf die Bestandsschutz
liste verschoben und allein UTF-8 in SAGA klassifiziert.
7.3 Technologien zur Informationsaufbereitung
Die folgenden Spezifikationen beschreiben Technologien zur Informationsaufbereitung für verschie
dene Kanäle, z. B. E-Mail und Webseiten.
Verbindlich: Multipurpose Internet Mail Extensions (MIME) 1.0
PI
Zur standardisierten Angabe, welches Format eine Datei oder ein Teil davon hat, MUSS das Format
MIME106 verwendet werden. Es erlaubt dem E-Mail-Client oder dem Web-Browser die eindeutige
Identifikation des Dateityps.
MIME wurde 1996 in der Version 1.0 als RFC 2045 von der IETF veröffentlicht.
Empfohlen: Extensible Hypertext Markup Language (XHTML) 1.0
XHTML107 ist eine Beschreibungssprache zur Auszeichnung von Texten, die zum Teil auch semanti
sche Elemente enthält und die zur Darstellung von Inhalten in einem Web-Browser verwendet wer
den SOLLTE. Im Gegensatz zu HTML hat XHTML ihren Ursprung in XML und formuliert somit
strengere Regeln an die Struktur von Websites. Andere XML-Sprachen, wie z. B. SVG, lassen sich
entsprechend in die XML-Struktur einbetten und müssen nicht wie bei HTML referenziert werden.
Weiterhin kann XHTML aufgrund seiner Kompatibilität zu XML von Programmiersprachen und
Stylesheet-Sprachen einheitlich verarbeitet werden. Gemäß BITV sind in Zusammenhang mit
XHTML CSS-Stylesheets zu verwenden, um die Text- und Bildgestaltung sowie die Präsentation
von XHTML-Dokumenten zu beeinflussen.
XHTML 1.0 wurde im Januar 2000 als W3C Recommendation veröffentlicht und im August 2002
überarbeitet.
106 http://tools.ietf.org/html/rfc2045
107 http://www.w3.org/TR/xhtml1/
PI
33
Empfohlen: Hypertext Markup Language (HTML) 4.01
PI
HTML108 ist eine Beschreibungssprache, die zur Darstellung von Inhalten in einem Web-Browser
verwendet werden SOLLTE. Die Beschreibung erfolgt mittels sogenannter Tags, mit denen man die
Struktur eines Dokuments bestimmen, aber auch Textelemente auszeichnen kann. Gemäß BITV sind
in Zusammenhang mit HTML CSS-Stylesheets zu verwenden, um die Text- und Bildgestaltung so
wie die Präsentation von HTML-Dokumenten zu beeinflussen.
HTML wurde 1999 in der Version 4.01 vom W3C veröffentlicht.
Empfohlen: Cascading Style Sheets, Level 2 (CSS2)
PI
Mit Cascading Style Sheets (CSS)109 wird eine Beschreibungssprache mit Vererbungsregeln bezeich
net, mit der Layout und Design von Seiten gestalten werden SOLLTEN. Grafisch umgesetzt werden die
CSS-Regeln durch einen Web-Browser. Die Darstellung im Browser erfolgt in Verbindung mit der
Extensible Hypertext Markup Language (XHTML) und der Hypertext Markup Language (HTML).
CSS2 wurde im Mai 1998 vom W3C herausgegeben und seither kontinuierlich gepflegt.
Empfohlen: Extensible Stylesheet Language (XSL) 1.1
I
XSL110 ist eine Sprache für Stylesheets, d. h. zur Definition von Layout-Informationen von XMLDateien. Die Sprache besteht aus zwei Teilen: Einer Sprache zur Umwandlung von XML-Dokumen
ten (XSLT) und einem XML-Vokabular zur Spezifikation von Format-Informationen (XSL-FO).
XSL wird vom W3C herausgegeben und liegt seit Dezember 2006 in der Version 1.1 vor. XSL 1.1
erweitert XSL 1.0 z. B. um Lesezeichen, Änderungsbalken, erweiterte Indizes und zusätzliche Op
tionen bei einigen Feldern.
XSL 1.1 SOLLTE für die Aufbereitung von Dokumenten verwendet werden, die anschließend in ver
schiedene Ausgabeformate überführt werden.
Empfohlen: Extensible Stylesheet Language Transformations (XSLT) 1.0 / 2.0
XSLT111 ist eine Sprache für die Umformung von XML-Dokumenten. Sie ist neben XSL-FO integra
ler Bestandteil von XSL (siehe oben).
Das W3C hat XSLT 1.0112 im November 1999 als W3C Recommendation verabschiedet. Im Januar
2007 wurde XSLT 2.0113 herausgegeben.
XSLT 1.0 SOLLTE verwendet werden, wenn XML-Dokumente in ein anderes Format oder konform zu
einem anderen XML-Schema überführt werden sollen.
XSLT 2.0 zeichnet sich gegenüber XSLT 1.0 durch einige, teilweise inkompatible Änderungen aus,
die darauf zurückgehen, dass XSLT 2.0 für die Zusammenarbeit mit XPath 2.0 optimiert ist. XSLT
2.0 SOLLTE an Stelle von XSLT 1.0 verwendet werden, falls diese Änderungen benötigt werden und
Kompatibilität zu XSLT 1.0 verzichtbar ist oder über die Mechanismen von XSLT 2.0 sichergestellt
werden kann.
108
109
110
111
112
113
http://www.w3.org/TR/html401/
http://www.w3.org/TR/1998/REC-CSS2-19980512/
http://www.w3.org/TR/2001/REC-xsl-20011015/
http://www.w3.org/standards/techs/xslt
http://www.w3.org/TR/xslt
http://www.w3.org/TR/xslt20
I
34
Empfohlen: XML Query Language (XQuery) 1.0
I
XQuery114 ist eine Abfragesprache für Daten, die im XML-Format vorliegen, z. B. in XML-Daten
banken. XQuery stellt eine Erweiterung von XPath 2.0 dar.
XQuery 1.0115 wurde erstmals im Januar 2007 als W3C Recommendation verabschiedet und zuletzt
im Dezember 2010 in einer Second Edition116 überarbeitet.
Bestandsgeschützt: Hypertext Markup Language (HTML) 3.2
PI
HTML 3.2 war in SAGA 2.0 als „Obligatorisch“ klassifiziert. Sie wurde in SAGA 2.1 von der aktu
elleren Version HTML 4.01 verdrängt.
Bestandsgeschützt: Extensible Stylesheet Language (XSL) 1.0
I
XSL 1.0 wurde mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 durch Version 1.1 ersetzt.
7.4 Spezifikationen für aktive Inhalte
Aktive Inhalte sind Computer-Programme (z. B. Javascript, Java Applets, ActiveX-Controls, Silver
light-Anwendungen oder auch Flash-Animationen), die in Webseiten oder Dateien (z. B. PDF-Doku
mente, Office-Dokumente) enthalten sind oder beim Betrachten automatisiert nachgeladen werden
und auf dem Client (vom Anzeigeprogramm oder Betriebssystem) ausgeführt werden. Bei der Ver
wendung von aktiven Inhalten sind die Restriktionen gemäß Abschnitt 6.1.1 „Einsatz aktiver Inhalte
im Client“ auf Seite 24 zu berücksichtigen.
Empfohlen: ECMAScript Language Specification, 3rd Edition
PI
ECMAScript Language Specification117, oder auch JavaScript, ist eine Skriptsprache, die in einem
Web-Browser ausgeführt wird und dynamische Inhalte auf Webseiten bereitstellt, ohne die Websei
ten neu zu laden.
Die von Ecma International als ECMA-262 standardisierte ECMAScript Language Specification
wurde 1999 in der 3rd Edition veröffentlicht.
ECMA-262 3rd Edition SOLLTE für die Bereitstellung von dynamischen Inhalten in den verbreiteten
Browsern verwendet werden.
Beobachtet: ECMAScript Language Specification, 5th Edition
ECMA-262118 wurde 2009 von Ecma International in der fünften Edition veröffentlicht. Grundlegen
de Neuerung der fünften gegenüber der dritten Edition (siehe oben) sind die verbesserte Unterstüt
zung der Objektorientierung und die Integration der JSON-Notation in den Standard.
ECMA-262 5th Edition KANN für die Bereitstellung von dynamischen Inhalten in der aktuellen Brow
ser-Generation (Firefox 4 und höher sowie Internet Explorer 9 und höher) verwendet werden.
114
115
116
117
118
http://www.w3.org/TR/xquery/
http://www.w3.org/TR/2007/REC-xquery-20070123/
http://www.w3.org/TR/2010/REC-xquery-20101214/
PI
7.5 Formulare
35
7.5 Formulare
Beobachtet: XForms 1.1
PI
XForms119 gibt Webformularen Funktionalitäten, die weit über die Möglichkeiten von HTML hinaus
gehen und aufwändige client-seitige Skriptlösungen überflüssig machen. Zu den von XForms stan
dardisierten Funktionen gehören die Auszeichnung von Pflichtfeldern, die Validierung der Eingaben
und das Ausgeben von Fehlermeldungen.
Im Oktober 2009 wurde XForms 1.1 vom W3C als Recommendation veröffentlicht.
XForms 1.1 KANN für die Bereitstellung von Formularen in Webseiten verwendet werden.
Bestandsgeschützt: XForms 1.0
PI
XForms 1.0 wurde mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 durch Version 1.1 er
setzt.
7.6 Austauschformate für Daten
Standardisierte Austauschformate für Daten sollen den Datenaustausch zwischen Software-Systemen
erleichtern. Die Lesbarkeit der Daten durch Menschen steht dabei nicht im Vordergrund.
Empfohlen: Extensible Markup Language (XML) 1.0
PI
XML120 ist eine aus der Standard Generalized Markup Language (SGML) abgeleitete Sprache, mit
der Daten strukturiert abgebildet werden können.
XML 1.0, Fifth Edition121, wurde im November 2008 vom W3C als Recommendation veröffentlicht.
XML 1.0 SOLLTE für den Austausch von strukturierten Daten verwendet werden. Für viele Anwen
dungsfälle existieren spezialisierte, auf XML basierende Austauschformate (z. B. EML, siehe unten).
Bei hohen Anforderungen an Transaktionszahlen oder Datenvolumina SOLLTEN performantere Aus
tauschformate gewählt werden.
Beobachtet: Election Markup Language (EML) 5.0
EML122 spezifiziert den Datenaustausch zwischen Hardware, Software und Dienstleistern, die mit ir
gendeinem Aspekt eines privaten oder öffentlichen Wahlprozesses befasst sind.
EML 5.0 wurde von der OASIS im Dezember 2007 als Standard herausgegeben. An der Nachfolge
spezifikation EML 6.0 wird derzeit gearbeitet.
EML wird vom Europarat empfohlen und wurde in den letzten Jahren bei einigen Wahlprozessen er
folgreich eingesetzt.
119
120
121
122
http://www.w3.org/TR/2009/REC-xforms-20091020/#concepts-xhtml
http://www.w3.org/standards/techs/xml
http://www.w3.org/TR/2008/REC-xml-20081126/
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=election
PI
7.7 Austauschformate für Dokumente
36
7.7 Austauschformate für Dokumente
7.7.1
Formate für Textdokumente zum Informationsaustausch
Textdokumente, die dem Austausch von Informationen dienen, sollen von der Zielgruppe ausschließ
lich gelesen und nicht verändert werden. Eine weitere Bearbeitung ist deshalb nicht vorgesehen.
Verbindlich: Portable Document Format (PDF) ≥1.4
PI
PDF123 ist ein Format zum Austausch und zur Ansicht elektronischer Dokumente unabhängig von der
Umgebung, in der sie erstellt wurden.
Ursprünglich wurde PDF von Adobe Systems Inc. für die Acrobat-Software entwickelt. Seit Juli
2008 ist PDF in der Version 1.7 durch die ISO als ISO 32000 normiert.
PDF MUSS für Textdokumente verwendet werden, die nur dem Informationsaustausch dienen und
nicht weiterbearbeitet werden sollen, insbesondere für Dokumente mit Anforderungen an das Layout
oder mit eingebetteten grafischen Elementen.
Dabei MUSS PDF mindestens in der Version 1.4 verwendet werden. Erst ab dieser Version besteht die
Möglichkeit zur Erzeugung barrierefreier Dokumente. Als Profil von PDF 1.4 KANN auch PDF/A zum
Einsatz kommen, falls z. B. aktive Inhalte anhand des Dateiformates ausgeschlossen werden sollen.
Höhere Versionen des Standards KÖNNEN verwendet werden, solange zusätzliche Funktionen benötigt
werden und die Verbreitung geeigneter Lesesoftware auf Empfängerseite gesichert ist. Insbesondere
bei mobilen Endgeräten können die Möglichkeiten zur Darstellung eingeschränkt sein.
Empfohlen: Text
PI
Das Text-Format SOLLTE für einfache, unstrukturierte Textdokumente ohne Anforderungen an das
Layout verwendet werden.
Um die Interoperabilität beim Datenaustausch mit Textdateien zu gewährleisten, MÜSSEN die von
SAGA festgelegten Zeichensätze und -kodierungen verwendet werden, siehe Abschnitt 7.2 „Zei
chensätze und -kodierungen“ auf Seite 31. Als Steuerzeichen für das Zeilenende SOLLTEN Carriage
return und Line feed (CR+LF) zum Einsatz kommen.
Bestandsgeschützt: Portable Document Format (PDF) 1.3
In SAGA 2.0 wurde PDF 1.3 als „Obligatorisch“ klassifiziert. Es wurde in SAGA 2.1 durch die
nachfolgende Version 1.4 ersetzt.
7.7.2
Formate für Textdokumente zur Weiterbearbeitung
Textdokumente, die für eine weitere Bearbeitung vorgesehen sind, müssen veränderbar sein. Es wird
zwischen einfachen Textdokumenten und komplexen Textdokumenten mit Layout-Informationen un
terschieden.
123 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=51502
PI
7.7.2 Formate für Textdokumente zur Weiterbearbeitung
37
Empfohlen: Text
PI
Siehe „Text“ im Abschnitt 7.7.1 „Formate für Textdokumente zum Informationsaustausch“ auf Seite
36.
Beobachtet: Open Document Format for Office Applications (OpenDocument) 1.1
PI
Das „Open Document Format for Office Applications (OpenDocument)“ 124, kurz ODF, ist ein XMLbasiertes Format zur Darstellung der Dokumente aus Büroanwendungen (Textverarbeitung, Tabel
lenkalkulation, Präsentationen).
OpenDocument wird durch die OASIS entwickelt. Version 1.1 ist datiert vom Februar 2007. Die
Normierung von OpenDocument 1.1 durch die ISO als Amendment zu ISO 26300 ist in Arbeit.
OpenDocument 1.1 KANN für den Austausch von komplexen, strukturierten oder mit Layoutinforma
tionen versehenen Textdokumenten verwendet werden, die für die Weiterbearbeitung vorgesehen
sind. ODF 1.0 ist aufwärtskompatibel zu ODF 1.1, d. h. Anwendungen, die ODF 1.0 lesen können,
können auch ODF 1.1 Dokumente öffnen. Lediglich die neu in ODF 1.1 hinzugekommenen Features
werden von ODF 1.0-Anwendungen nicht unterstützt, wenn sie in den Dokumenten vorhanden sind.
Beobachtet: Office Open XML (OOXML) / ISO/IEC 29500 Transitional
PI
OOXML125 ist ein ursprünglich von Microsoft entwickeltes, XML-basiertes Format zur Darstellung
der Dokumente aus Büroanwendungen (Textverarbeitung, Tabellenkalkulation, Präsentationen). Es
wurde als ISO/IEC 29500 normiert.
Bei der Transitional-Variante der ISO-Norm wurde besonderer Wert auf Kompatibilität zu den alten
Binärformaten (Microsoft Office File Formats, siehe unten) der Microsoft Office Suite (MS Office
97 bis MS Office 2003) gelegt.
OOXML Transitional KANN für den Austausch von Textdokumenten verwendet werden, die für die
Weiterbearbeitung vorgesehen sind, und für die die Kompatibilität zu alten oder neuen Microsoft-Of
fice-Versionen wichtig ist.
Beobachtet: Office Open XML (OOXML) / ISO/IEC 29500 Strict
Siehe Office Open XML (OOXML) / ISO/IEC 29500 Transitional oben.
Bei der Strict-Variante der ISO-Norm126 wurden insbesondere Teile der Transitional-Variante ausge
schlossen, die Kompatibilität zu älteren Versionen der Microsoft Office Suite beschreiben und die
für Dritte nur schwer zu implementieren sind.
OOXML Strict KANN für den Austausch von komplexen, strukturierten oder mit Layoutinformationen
versehenen Textdokumenten verwendet werden, die für die Weiterbearbeitung vorgesehen sind. Zum
Zeitpunkt der Veröffentlichung dieses SAGA-Moduls gab es jedoch noch keine Implementation.
124 http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1.pdf
125 http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
126 http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
PI
7.7.2 Formate für Textdokumente zur Weiterbearbeitung
38
Beobachtet: DocBook 4.5
PI
DocBook127 ist ein auf SGML und XML basierendes Dokumentenformat zur ausgabeneutralen Er
stellung von Büchern, Artikeln und Dokumentationen. Mittels DocBook können somit die Inhalte
von Textdokumenten erfasst werden, ohne über ihr konkretes Layout Aussagen zu treffen. Insbeson
dere das verteilte Erstellen von Inhalten und die Trennung von Inhalt und Layout werden durch Doc
Book gefördert.
DocBook 4.5 KANN für umfangreiche Dokumente (z. B. Dokumentationen) genutzt werden, wenn die
Dokumente in einem verteilten Prozess entstehen oder in mehreren Ausgabeformaten (z. B. HTML,
XHTML und PDF) zur Verfügung gestellt werden sollen.
Bestandsgeschützt: Open Document Format for Office Applications (OpenDocument)
1.0
PI
Version 1.0 ist datiert vom Mai 2005. Sie wurde von der ISO als ISO 23600:2006 normiert.
OpenDocument 1.0 wurde in den meisten Implementationen durch OpenDocument 1.1 abgelöst und
deshalb mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 durch Version 1.1 ersetzt.
Bestandsgeschützt: Microsoft Office File Formats
PI
Obwohl inzwischen OOXML (siehe oben) das Standarddateiformat für Microsoft Office ist, recht
fertigt die große Relevanz in der Vergangenheit die Aufnahme der Microsoft Office File Formats in
die Bestandsschutzliste.
Das Word 97-2003 Binary File Format (.doc)128 KANN mit bestehenden Software-Systemen für den
Austausch von Textdokumenten verwendet werden, die für die Weiterbearbeitung vorgesehen sind.
Bestandsgeschützt: eXtensible Markup Language (XML) 1.0
PI
In SAGA 2.1 war XML als „Empfohlen“ klassifiziert. Zu dem Zeitpunkt existierte noch kein auf
XML basierendes standardisiertes Format für weiterbearbeitbare Textdokumente, Tabellenkalkulatio
nen und Präsentationen. OpenDocument 1.0, das auf XML basiert, wurde im Mai 2005 veröffentlicht
und in SAGA 3.0 als geeignetes konkretes XML-Format aufgenommen. Durch diese Festlegung
wird eher Interoperabilität erreicht als durch eine allgemeine Einigung auf XML.
7.7.3
Formate für Tabellen zum Informationsaustausch
Tabellen, die dem Austausch von Informationen dienen, sollen von der Zielgruppe ausschließlich ge
lesen und nicht verändert werden. Eine weitere Bearbeitung ist deshalb nicht vorgesehen.
Empfohlen: Portable Document Format (PDF) ≥1.4
Siehe Portable Document Format (PDF) ≥1.4 im Abschnitt 7.7.1 „Formate für Textdokumente zum
Informationsaustausch“ auf Seite 36.
127 http://www.docbook.org/specs/docbook-4.5-spec.html
128 http://msdn.microsoft.com/en-us/library/cc313153%28v=office.12%29.aspx
PI
7.7.3 Formate für Tabellen zum Informationsaustausch
39
Empfohlen: Comma-Separated Values (CSV)
PI
Tabellen mit einfach strukturierten Daten ohne Berechnungen und Anforderungen an das Layout
129
SOLLTEN mittels Comma Separated Values
(Dateiendung .csv) ausgetauscht werden.
Das CSV-Dateiformat wurde im Jahr 2005 durch die IETF im RFC 4180 dokumentiert.
PI
Siehe Hypertext Markup Language (HTML) 4.01 im Abschnitt 7.3 „Technologien zur Informations
aufbereitung“ auf Seite 33.
PI
Siehe Extensible Hypertext Markup Language (XHTML) 1.0 im Abschnitt 7.3 „Technologien zur In
formationsaufbereitung“ auf Seite 32.
PI
Siehe Portable Document Format (PDF) 1.3 im Abschnitt 7.7.1 „Formate für Textdokumente zum
7.7.4
Formate für Tabellen zur Weiterbearbeitung
Tabellen, die für eine weitere Bearbeitung vorgesehen sind, müssen veränderbar sein. Es wird zwi
schen einfach strukturierten Daten und komplexen Dokumenten mit Berechnungen und gegebenen
falls mit Layout-Informationen unterschieden.
Empfohlen: Comma-Separated Values (CSV)
PI
Siehe Comma-Separated Values (CSV) im Abschnitt 7.7.3 „Formate für Tabellen zum Informations
austausch“ auf Seite 39.
PI
Siehe Open Document Format for Office Applications (OpenDocument) 1.1 im Abschnitt 7.7.2
„Formate für Textdokumente zur Weiterbearbeitung“ auf Seite 37.
PI
Siehe Office Open XML (OOXML) / ISO/IEC 29500 Transitional im Abschnitt 7.7.2 „Formate für
Textdokumente zur Weiterbearbeitung“ auf Seite 37.
Siehe Office Open XML (OOXML) / ISO/IEC 29500 Strict im Abschnitt 7.7.2 „Formate für Textdo
kumente zur Weiterbearbeitung“ auf Seite 37.
PI
7.7.4 Formate für Tabellen zur Weiterbearbeitung
40
1.0
PI
PI
Siehe Microsoft Office File Formats im Abschnitt 7.7.2 „Formate für Textdokumente zur Weiterbe
arbeitung“ auf Seite 38.
Das Excel 97-2003 Binary File Format (.xls)130 KANN mit bestehenden Software-Systemen für den
Austausch von Tabellen verwendet werden, die für die Weiterbearbeitung vorgesehen sind.
PI
Siehe eXtensible Markup Language (XML) 1.0 im Abschnitt 7.7.2 „Formate für Textdokumente zur
Weiterbearbeitung“ auf Seite 38.
7.7.5
Formate für Präsentationen zum Informationsaustausch
Präsentationen, die dem Austausch von Informationen dienen, sollen von der Zielgruppe ausschließ
lich gelesen und nicht verändert werden. Eine weitere Bearbeitung ist deshalb nicht vorgesehen.
Empfohlen: Portable Document Format (PDF) ≥1.4
PI
Siehe Portable Document Format (PDF) ≥1.4 im Abschnitt 7.7.1 „Formate für Textdokumente zum
PDF SOLLTE für den Austausch von Präsentationen verwendet werden, die keine Animationen enthal
ten.
PI
Siehe Hypertext Markup Language (HTML) 4.01 im Abschnitt 7.3 „Technologien zur Informations
aufbereitung“ auf Seite 33.
PI
Siehe Extensible Hypertext Markup Language (XHTML) 1.0 im Abschnitt 7.3 „Technologien zur In
formationsaufbereitung“ auf Seite 32.
Beobachtet: Synchronized Multimedia Integration Language (SMIL) 3.0
SMIL131 ist ein vom W3C entwickelter offener Standard einer Auszeichnungssprache für Multime
diaprodukte auf XML-Basis. Er erlaubt es mehrere Elemente wie Audio, Video, Text und Grafik syn
chron zu übertragen und beim Client darzustellen.
SMIL KANN für den Austausch von Präsentationen verwendet werden, wenn besondere Funktionen
von SMIL, wie z. B. eine wiederholte oder bedingte Anzeige von Dokumenten, benötigt werden.
131 http://www.w3.org/TR/2008/REC-SMIL3-20081201/
PI
7.7.5 Formate für Präsentationen zum Informationsaustausch
41
PI
Siehe Portable Document Format (PDF) 1.3 im Abschnitt 7.7.1 „Formate für Textdokumente zum
Bestandsgeschützt: Synchronized Multimedia Integration Language (SMIL) 2.0
PI
SMIL 2.0 wurde mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 auf die Bestandsschutz
liste verschoben und durch Version 3.0 ersetzt.
7.7.6
Formate für Präsentationen zur Weiterbearbeitung
Präsentationen, die für eine weitere Bearbeitung vorgesehen sind, müssen veränderbar sein.
PI
PI
Siehe Office Open XML (OOXML) / ISO/IEC 29500 Transitional im Abschnitt 7.7.2 „Formate für
Textdokumente zur Weiterbearbeitung“ auf Seite 37.
PI
Siehe Office Open XML (OOXML) / ISO/IEC 29500 Strict im Abschnitt 7.7.2 „Formate für Textdo
kumente zur Weiterbearbeitung“ auf Seite 37.
1.0
PI
PI
Siehe Microsoft Office File Formats im Abschnitt 7.7.2 „Formate für Textdokumente zur Weiterbe
arbeitung“ auf Seite 38.
Das PowerPoint 97-2003 Binary File Format (.ppt)132 KANN mit bestehenden Software-Systemen für
den Austausch von Präsentationen verwendet werden, die für die Weiterbearbeitung vorgesehen sind.
Siehe eXtensible Markup Language (XML) 1.0 im Abschnitt 7.7.2 „Formate für Textdokumente zur
Weiterbearbeitung“ auf Seite 38.
PI
7.7.7 Gesicherter Dokumentenaustausch
7.7.7
42
Gesicherter Dokumentenaustausch
Für Kommunikation und Interaktion ist häufig der Austausch sicherer Dokumente erforderlich, d. h.
eine Zusicherung von Vertraulichkeit, Verfügbarkeit und/oder Integrität. Dazu gehören z. B. die Si
cherung von Dokumenten als E-Mail-Anlagen oder als Bestandteile XML-basierter elektronischer
Kommunikation.
Einige der in den vorangegangenen Abschnitten aufgeführten Spezifikationen (z. B. PDF,
OpenDocument, OOXML) stellen bereits integrierte Sicherheitsfunktionen bereit. Soweit diese
Funktionen die Anforderungen erfüllen, SOLLTEN sie zusätzlichen Maßnahmen vorgezogen werden.
Weitere allgemeine Spezifikationen, die im Zusammenhang mit gesichertem Dokumentenaustausch
von Bedeutung sind, finden sich in Kapitel 10 „Verschlüsselung“ auf Seite 68 und in Kapitel 11
„Elektronische Signatur“ auf Seite 70.
Empfohlen: Common PKI Specifications for Interoperable Applications (Common
PKI) 2.0
PI
In der Common PKI Spezifikation133 sind international verbreitete Standards für Public Key Infra
strukturen (PKI), für elektronische Signaturen sowie für die Verschlüsselung zusammengefasst. Ein
besonderer Fokus liegt auf Datenformaten und Kommunikationsprotokollen zur Erreichung von In
teroperabilität.
Empfohlen: XML Advanced Electronic Signatures (XAdES) ≥1.3.2
PI
XAdES134 ist eine Erweiterung der XML Signature Spezifikation im Hinblick auf den Einsatz von
Signaturen im Sinne der EU-Richtlinie 1999/93/EC. In der Grundform entspricht XAdES im We
sentlichen dem Standard XML Signature. XAdES erweitert diesen um Funktionen wie Zeitstempel,
Zeitstempelerneuerung, die Nutzung erweiterter Verifikationsdaten sowie um Funktionen zur Lang
zeitspeicherung.
Empfohlen: XML Encryption
PI
XML Encryption135 definiert die Art und Weise, wie XML-Dokumente ver- bzw. entschlüsselt wer
den. Dies kann mittels eines symmetrischen oder eines asymmetrischen Verfahrens erfolgen. Zusam
men mit XML Signature bildet XML Encryption die Grundlage mehrerer Standards zum XML-ba
sierten Dokumentenaustausch.
Empfohlen: XML Signature
Mit Hilfe des Standards XML Signature136 SOLLTEN Signaturen für beliebige Daten, vorrangig jedoch
für XML-Daten, beschrieben werden, indem ein XML-Schema und ein Verarbeitungsregelwerk für
die Gliederung und Validierung der Signatur bereitgestellt werden. Ein zentrales Merkmal von XML
Signature ist die Möglichkeit, anstelle des gesamten XML-Dokuments nur bestimmte Teile daraus zu
signieren. 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. Für die meisten An
wendungen reichen normale XML-Signaturen aus, jedoch in Verbindung mit qualifizierten elektroni
133
134
135
136
http://www.t7ev.org/themen/entwickler/common-pki-v20-spezifikation.html
http://uri.etsi.org/01903/v1.4.1/
http://www.w3.org/TR/xmlenc-core/
http://www.w3.org/TR/xmldsig-core/
PI
7.7.7 Gesicherter Dokumentenaustausch
43
schen Signaturen im Sinne der deutschen Gesetzgebung bzw. beim Einsatz von Signaturen im Kon
text von Langzeitspeicherung sind XAdES-konforme Signaturen den einfachen XML-Signaturen
vorzuziehen.
Bestandsgeschützt: Common ISIS-MTT Specifications for Interoperable PKI Applica
tions (Common PKI) 1.1, Teil 3
PI
Common PKI 1.1 wurde mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 durch Version
2.0 ersetzt.
Bestandsgeschützt: Industrial Signature Interoperability Specification (ISIS)-MTT 1.0
PI
Zum Zeitpunkt der Veröffentlichung von SAGA 2.0 war ISIS-MTT 1.0 die aktuelle Version und als
„Obligatorisch“ klassifiziert. Mit SAGA 2.1 erfolgte die Ersetzung durch die nachfolgende Version
1.1.
Bestandsgeschützt: MailTrusT (MTT) Version 2
PI
In SAGA 2.0 wurde MailTrusT (MTT) Version 2 als „Obligatorisch“ klassifiziert. Die MTT-Spezifi
kation ging 2001 in der ISIS-MTT-Spezifikation auf und wird seither nicht weiterentwickelt. Des
halb wurde seit SAGA 2.1 allein ISIS-MTT als Standard geführt.
Bestandsgeschützt: XML Advanced Electronic Signatures (XAdES) 1.2
PI
XAdES 1.2 wurde mit der Aktualisierung von SAGA 4.0 auf die Bestandsschutzliste gesetzt. Statt
dessen wurde XAdES 1.3.2 in SAGA aufgenommen.
7.8 Austauschformate für Bilder
Verbindlich: Joint Photographic Experts Group (JPEG)
PI
JPEG137 MUSS für die Speicherung und den Austausch von Fotos und Grafiken mit Farbverläufen, bei
denen die verlustbehaftete Kompression dieses Formates unschädlich ist, verwendet werden. JPEGDateien bieten für derartige Bilder eine hohe Kompressionsrate.
JPEG wurde 1992 von der Joint Photographic Experts Group veröffentlicht und 1994 von der ISO
als ISO/IEC 10918-1 normiert.
Empfohlen: Portable Network Graphics (PNG) 1.2
PNG138 ist ein ein Grafikformat, welches 16 Millionen Farben, verlustfreie Kompression, inkremen
telle Anzeige der Grafik (erst Grobstruktur, bis Datei ganz übertragen ist) und das Erkennen beschä
digter Dateien unterstützt. Transparenz kann mit Hilfe von Alpha-Kanälen erreicht werden.
Im Jahr 2003 wurde PNG in der Version 1.2 vom W3C und der ISO139 veröffentlicht.
PNG 1.2 SOLLTE für den Austausch von Grafiken und Schaubildern verwendet werden.
137 http://www.jpeg.org/jpeg/index.html
138 http://www.w3.org/TR/PNG/
PI
44
Empfohlen: Geo Tagged Image File Format (GeoTIFF) 1.8.2
PI
GeoTIFF140 ist eine Erweiterung von TIFF 6.0. Eine Besonderheit gegenüber TIFF 6.0 ist, dass im
Header eine Georeferenzierung enthalten ist, sodass im Gegensatz zum herkömmlichen TIFF die Ge
oreferenzdatei *.tfw nicht erstellt werden muss.
GeoTIFF wurde im Jahr 2000 in der Version 1.8.2 von Dr. Niles Ritter und Mike Ruth veröffentlicht.
GeoTIFF 1.8.2 SOLLTE für den Austausch von grafischen Geoinformationen verwendet werden, so
fern es erforderlich ist, dass Georeferenzierungen als Metadaten im Header enthalten sind.
Empfohlen: Graphics Interchange Format (GIF) v89a
PI
GIF141 ist ein Grafikformat, das sich vor allem für Bilder mit geringer Farbtiefe (256 Farben) eignet.
Im Jahr 1990 wurde GIF in der Version 89a vom W3C veröffentlicht.
GIF v89a SOLLTE als Austauschformat für nicht-fotografische Bilder, wie Strichzeichnungen, verwen
det werden.
Empfohlen: Tagged Image File Format (TIFF) 6.0
PI
TIFF142 wird zur Speicherung gerasteter Bilder eingesetzt. Um maximale Interoperabilität zu errei
chen, sind ausschließlich Eigenschaften aus der „Baseline TIFF“ 143 einzusetzen.
TIFF SOLLTE insbesondere dann verwendet werden, wenn mehrseitige Grafiken oder Bilder verarbei
tet werden sollen, z. B. gescannte mehrseitige Dokumente.
Beobachtet: Scalable Vector Graphics (SVG) 1.1
PI
SVG144 ist eine Spezifikation für Vektorgrafiken. Damit ist es möglich, Bilder in Webseiten einzubet
ten, die sich ohne Verpixelung auf beliebige Größen skalieren lassen.
Version 1.1 von SVG wurde vom W3C im Januar 2003 als Recommendation veröffentlicht.
SVG KANN insbesondere für Vektorgrafiken benutzt werden. Es wird vom Internet Explorer jedoch
erst mit Version 9 ohne Plug-In unterstützt.
Beobachtet: Joint Photographic Experts Group 2000 (JPEG 2000) / Part 1
JPEG 2000145 ist ein Grafikformat, welches als Nachfolger von JPEG entwickelt wurde und ebenfalls
für die Speicherung und den Austausch von Fotos und Grafiken mit Farbverläufen verwendet wer
den KANN. Neben einer verlustbehafteten Komprimierung beherrscht JPEG 2000 auch eine verlust
freie Komprimierung. Darüber hinaus kann JPEG 2000 zusätzliche Metadaten aufnehmen.
140
141
142
143
http://www.remotesensing.org/geotiff/spec/geotiffhome.html
http://www.w3.org/Graphics/GIF/spec-gif89a.txt
http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf
Unter „Baseline TIFF“ sind Eigenschaften von TIFF-Dateien zusammengefasst, die jedes TIFF-fähi
ge Programm unterstützen sollte. Beispielsweise gehören zu „Baseline TIFF“ ausschließlich die bei
den Komprimierungsverfahren „Huffman“ und „Packbits“, während „LZW“, „JPEG“, „ZIP“ und
„CCITT“ (Baudot-Code) optionale Erweiterungen sind, die nicht in jedem TIFF-fähigen Programm
implementiert sind.
144 http://www.w3.org/TR/2003/REC-SVG11-20030114/
145 http://www.jpeg.org/jpeg2000/
PI
45
JPEG 2000 wurde von der Joint Photographic Experts Group entwickelt und von der ISO als
ISO/IEC 15444-1146 normiert.
Bestandsgeschützt: Enhanced Compressed Wavelet (ECW)
PI
Bis zu SAGA 2.1 war ECW als „Empfohlen“ klassifiziert. Mit SAGA 3.0 wurden Mindestanforde
rungen bezüglich der Offenheit von Standards eingeführt. Eine kostenfreie Lizenz für ECW erlaubte
nur die Kompression von Dateien bis zu einer Größe von 500 MB. Für größere Dateien fielen Li
zenzkosten an. Deshalb wurde ECW auf die Bestandsschutzliste verschoben und in SAGA 3.0 offe
nere Alternativen (GeoTIFF, JPEG 2000 / Part 1) aufgenommen.
7.9 Animation
Empfohlen: Graphics Interchange Format (GIF) v89a
PI
Siehe Graphics Interchange Format (GIF) v89a im Abschnitt 7.8 „Austauschformate für Bilder“ auf
Seite 44.
GIF bietet im Kontext von Animation die Möglichkeit, mehrere GIF-Bilder in eine einzige Datei ein
zubetten. Dadurch können Bewegungsabläufe dargestellt werden, bei denen die Reihenfolge, Anzei
gedauer und Wiederholungen der Einzelbilder vorgegeben werden können. Man spricht dann auch
von animiertem GIF.
Animiertes GIF SOLLTE zur Darstellung einfacher Animationen verwendet werden.
Beobachtet: Scalable Vector Graphics (SVG) 1.1
Siehe Scalable Vector Graphics (SVG) 1.1 im Abschnitt 7.8 „Austauschformate für Bilder“ auf Seite
44.
Um Animationen in Webseiten einzubetten, bedient sich SVG der Spezifikation SMIL Animation.
Im Web-Browser Firefox werden Animationen mittels SVG und SMIL erst ab der Version 4.0 ohne
Plug-Ins unterstützt. Für den Internet Explorer (IE) gibt es noch keine direkte Unterstützung.
SVG KANN für Animationen eingesetzt werden, wenn durch Plug-Ins oder direkte Unterstützung eine
Anzeige in den Clients sichergestellt wird.
7.10 Audio- und Videodaten
Im Bereich der Audio- und Videodaten gibt es viele Namen, die zum Teil synonym für Herausgeber,
Produkte, Containerformate oder Codecs stehen. Da SAGA keine Produkte empfiehlt, werden Emp
fehlungen nur für Containerformate gegeben. Für die Zukunft ist eine detailliertere Betrachtung von
Codecs vorgesehen.
Die in diesem Abschnitt empfohlenen Spezifikationen werden von vielen gängigen Streaming-Ser
vern und Client-Produkten unterstützt. In diesem Bereich ist zurzeit eine hohe Kompatibilität zwi
schen den unterschiedlichen Produkten bezüglich der unterstützten Containerformate und Codecs ge
geben.
PI
7.10.1 Austauschformate für Audiodateien
46
Empfohlen: Ogg Encapsulation Format (Ogg)
PI
Ogg147 ist ein seitenorientiertes Containerformat für Multimediadaten. Es kann sowohl Audio- und
Videodaten als auch Textdaten enthalten. Ogg wurde als unabhängige Alternative zu proprietären
Formaten konzipiert und wird zur Speicherung und zum Streaming multimedialer Inhalte eingesetzt.
Ogg definiert sich dabei vor allem über seine explizite Patent- und Lizenzfreiheit als OpenSource-Alternative zu anderen Containerformaten.
Im Jahr 2003 wurde Ogg als RFC 3533 von der IETF veröffentlicht. Entwickelt wird der Standard
von der Xiph.Org Foundation148.
Bei Audiodateien mit niedrigen Qualitätsanforderungen, zum Beispiel Sprachaufzeichnungen, ist das
Codec Speex149 geeignet. Für Audiodateien mit normalen Qualitätsanforderungen bietet sich Vor
bis150 an, dessen Qualität mit MP3 vergleichbar ist. Für höchste Qualitätsansprüche KANN das verlust
freie Audio-Codec FLAC151 verwendet werden.
Empfohlen: MPEG-4 Part 14 (MP4)
PI
MP4152 ist ein von der Moving Picture Experts Group (MPEG) entwickelter Container für den Aus
tausch von Audio- und Videodateien.
MP4 wurde 2004 von der ISO als Teil 14 der Normenreihe ISO/IEC 14496 normiert.
Beobachtet: RealMedia (RM)
PI
RealMedia153 ist eine von RealNetworks entwickelte Familie von Dateiformaten u. a. auch ein Con
tainer für Audio- und Videoinhalte.
RealMedia KANN zum Austausch von Audiodateien insbesondere dann eingesetzt werden, wenn die
Inhalte bereits in diesem Format vorliegen (z. B. aufgrund eines parallel realisierten Streaming-An
gebots).
Beobachtet: Advanced Systems Format (ASF) 1.2
ASF154 ist ein von Microsoft entwickeltes, proprietäres, insbesondere auf Streaming ausgelegtes
Containerformat.
Im Februar 1998 wurde ASF zunächst unter der Bezeichnung Active Streaming Format von Micro
soft und RealNetworks vorgestellt und liegt seit 2004 in einer wesentlich erweiterten Version vor.
ASF KANN zum Austausch von Audiodateien insbesondere dann eingesetzt werden, wenn die Inhalte
bereits in diesem Format vorliegen (z. B. aufgrund eines parallel realisierten Streaming-Angebots).
147
148
149
150
151
152
153
154
http://www.xiph.org/
http://www.speex.org/
http://www.vorbis.com/
http://flac.sourceforge.net/
https://helixcommunity.org/developers/getting_started/download_source_code
http://www.microsoft.com/windows/windowsmedia/format/asfspec.aspx
PI
47
Bestandsgeschützt: MPEG-1 Layer 3 (MP3)
PI
Bis zu SAGA 2.1 war MP3 als „Obligatorisch“ klassifiziert. Mit SAGA 3.0 wurden Mindestanforde
rungen bezüglich der Offenheit von Standards eingeführt. Da für den Einsatz von MP3 in Software
und Hardware Lizenzkosten anfielen, wurde MP3 auf die Bestandsschutzliste verschoben und in
SAGA 3.0 offenere Alternativen (Ogg) aufgenommen.
7.10.2 Austauschformate für Audio-Streaming
Im Gegensatz zu „normalen“ Audiodateien bietet Audio-Streaming ein Format, das es ermöglicht,
schon während der Übertragung abgespielt zu werden. Dadurch werden Live-Übertragungen mög
lich, wohingegen die herkömmlichen Audiodateien zunächst komplett übertragen und dann abge
spielt werden. Neben den Containerformaten werden für das Streaming zusätzlich Transportproto
kolle benötigt (z. B. HTTP oder RTSP).
Empfohlen: Hypertext Transfer Protocol (HTTP) 1.1
PI
HTTP155 ist ein frei verfügbares, auf der Anwendungsschicht eingesetztes, Protokoll zur Übertragung
von Daten in einem Netzwerk. Es bildet die Basis der Client-Server-Kommunikation im World Wide
Web.
HTTP ist durch diverse Erweiterungen nicht nur auf Hypertext beschränkt, sondern es können belie
bige Daten ausgetauscht werden. Daher SOLLTE es auch für das Streaming von Audiodateien verwen
det werden.
Empfohlen: Real Time Streaming Protocol (RTSP)
PI
RTSP156 ist ein Netzwerkprotokoll zur Steuerung von audiovisuellen Datenströmen.
RTSP wurde 1998 im RFC 2326 von der IETF standardisiert.
PI
Siehe Ogg Encapsulation Format (Ogg) im Abschnitt 7.10.1 „Austauschformate für Audiodateien“
auf Seite 46.
PI
Siehe MPEG-4 Part 14 (MP4) im Abschnitt 7.10.1 „Austauschformate für Audiodateien“ auf Seite
46.
Beobachtet: RealMedia (RM)
Siehe RealMedia (RM) im Abschnitt 7.10.1 „Austauschformate für Audiodateien“ auf Seite 46.
RealMedia KANN insbesondere für Streaming-Angebote zum Einsatz kommen, die auf Basis von
RTSP realisiert werden sollen.
PI
7.10.2 Austauschformate für Audio-Streaming
48
PI
Siehe Advanced Systems Format (ASF) 1.2 im Abschnitt 7.10.1 „Austauschformate für Audiodatei
en“ auf Seite 46.
Da sich ASF durch einen geringen Protokoll-Overhead auszeichnet, KANN es insbesondere für Strea
ming bei beschränkter Bandbreite verwendet werden.
Bestandsgeschützt: Hypertext Transfer Protocol (HTTP) 1.0
PI
HTTP 1.0 war in SAGA 1.1 als „Obligatorisch“ klassifiziert. Es wurde in SAGA 2.0 durch die nach
folgende Version HTTP 1.1 ersetzt.
7.10.3 Austauschformate für Videodateien
PI
Siehe Ogg Encapsulation Format (Ogg) im Abschnitt 7.10.1 „Austauschformate für Audiodateien“
auf Seite 46.
Für Videodateien SOLLTE Ogg in Verbindung mit dem freien Codec „Theora157“ verwendet werden.
PI
46.
PI
Siehe Advanced Systems Format (ASF) 1.2 im Abschnitt 7.10.1 „Austauschformate für Audiodatei
en“ auf Seite 46.
Bestandsgeschützt: QuickTime File Format (QTFF)
PI
QTFF wurde mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 auf die Bestandsschutzliste
verschoben.
Bestandsgeschützt: RealMedia (RM)
Siehe RealMedia (RM) im Abschnitt 7.10.1 „Austauschformate für Audiodateien“ auf Seite 46.
RealMedia wurde für Videodaten mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 auf die
Bestandsschutzliste verschoben, da es lediglich das nicht offene Video-Codec RealVideo unterstützt.
7.10.4 Austauschformate für Video-Streaming
Im Gegensatz zu „normalen“ Videodateien bietet Video-Streaming ein Format, das es ermöglicht,
schon während der Übertragung abgespielt zu werden. Dadurch werden Live-Übertragungen von Vi
deos möglich, wohingegen die herkömmlichen Videodateien zunächst komplett übertragen und dann
abgespielt werden.
157 Siehe http://www.theora.org/
PI
7.10.4 Austauschformate für Video-Streaming
49
PI
Siehe Hypertext Transfer Protocol (HTTP) 1.1 im Abschnitt 7.10.2 „Austauschformate für Au
dio-Streaming“ auf Seite 47.
PI
46.
PI
Siehe Ogg Encapsulation Format (Ogg) im Abschnitt 7.10.3 „Austauschformate für Videodateien“
auf Seite 48.
Empfohlen: Real Time Streaming Protocol (RTSP)
PI
Siehe Real Time Streaming Protocol (RTSP) im Abschnitt 7.10.2 „Austauschformate für Audio-Stre
aming“ aus Seite 47.
PI
Siehe Advanced Systems Format (ASF) 1.2 im Abschnitt 7.10.2 „Austauschformate für Audio-Strea
ming“ auf Seite 47.
PI
Bestandsgeschützt: QuickTime File Format (QTFF)
PI
Siehe QuickTime File Format (QTFF) im Abschnitt 7.10.3 „Austauschformate für Videodateien“ auf
Seite 48.
Bestandsgeschützt: RealMedia (RM)
PI
Siehe RealMedia (RM) im Abschnitt 7.10.3 „Austauschformate für Videodateien“ auf Seite 48.
7.11 3D-Daten
Beobachtet: eXtensible 3D (X3D), Edition 2
X3D158 dient der Definition von dreidimensionalen Daten in interaktiven Echtzeit-Anwendungen
mittels XML. Es definiert ein Dateiformat und eine Laufzeitumgebung, um 3D-Szenen und -Objekte
zu repräsentieren und auszutauschen.
Die Edition 1 von X3D wurde vom Web 3D Consortium entwickelt und im November 2005 als
ISO/IEC 19775:2004 normiert. Im Juli 2008 wurde diese Norm von der ISO als veraltet deklariert
und die Edition 2 als ISO/IEC 19775-1:2008 veröffentlicht.
158 http://www.web3d.org/x3d/specifications/x3d/
PI
7.11 3D-Daten
50
X3D KANN für die Darstellung von 3D-Szenen und Objekten verwendet werden. Gegenüber dem
konkurrierenden Format U3D erzeugt X3D kleinere Dateien und hat daher im Webumfeld seine Vor
teile.
Beobachtet: Universal 3D (U3D) 4th Edition
PI
Die Spezifikation U3D159 definiert Syntax und Semantik des entsprechenden Dateiformats, eines er
weiterbaren Formats für 3D CAD (Computer-Aided Design) Daten. Neben der Visualisierung spezi
fiziert U3D auch eine Architektur, die die Ausführung von Modifikationen zur Laufzeit erlaubt.
U3D wurde erstmals 2004 von der Ecma standardisiert. Die 4. Ausgabe wurde im Juni 2007 heraus
gegeben.
U3D KANN für die Darstellung von 3D-Szenen und Objekten verwendet werden. Gegenüber dem
konkurrierenden Format X3D hat U3D den Vorteil, besser mit CAD-Daten umgehen zu können.
7.12 Austauschformate für Geoinformationen
Die nachfolgend aufgeführten Spezifikationen für den Austausch von Geoinformationen werden in
den Geodiensten aus Abschnitt 8.6 auf Seite 62 angewendet.
Verbindlich: Geography Markup Language (GML) 3.2.x
PI
GML160 ist eine Auszeichnungssprache zum Austausch und zum Speichern von geografischen Infor
mationen im Vektorformat, welche räumliche und nicht-räumliche Eigenschaften berücksichtigt. Ne
ben dem Austausch von Vektordaten, können über diese Spezifikation auch Coverages, zu denen
auch Oberflächen zählen, ausgetauscht werden.
Im Jahr 2007 wurde GML in der Version 3.2.1 vom Open Geospatial Consortium (OGC) 161 veröf
fentlicht. Die ISO hat GML 3.2.1 als ISO 19136:2007 normiert.
GML 3.2.x MUSS, insbesondere im Zusammenhang mit der Nutzung des Web Feature Service (WFS)
2.0 verwendet werden.
Empfohlen: City Geography Markup Language (CityGML) 1.0.0
PI
CityGML162 ist ein Datenmodell, welches auf XML basiert und zur Speicherung und dem Austausch
von 3D-Stadt- und Landschaftsmodellen verwendet werden SOLLTE.
Im Jahr 2008 wurde CityGML in der Version 1.0.0 vom OGC veröffentlicht.
Empfohlen: Geo Tagged Image File Format (GeoTIFF) 1.8.2
Siehe Geo Tagged Image File Format (GeoTIFF) 1.8.2 im Abschnitt 7.8 „Austauschformate für Bil
der“ auf Seite 44.
159
160
161
162
http://www.opengeospatial.org/standards/gml
http://www.opengeospatial.org/
http://www.opengeospatial.org/standards/citygml
PI
7.12 Austauschformate für Geoinformationen
51
Empfohlen: Keyhole Markup Language (KML) 2.2.0
PI
KML163 ist eine XML-basierte Sprache, die dazu verwendet werden SOLLTE, geografische Informatio
nen für die Darstellung in 3D-Betrachtern (z. B. GoogleEarth) bereitzustellen. Neben den eigentli
chen Geoinformationen beinhaltet KML auch schon Informationen zur Visualisierung.
Im Jahr 2008 wurde KML in der Version 2.2.0 vom OGC veröffentlicht.
Bestandsgeschützt: Geography Markup Language (GML) 3.1.1
PI
Bis SAGA 4.0 war GML 3.1.1 in SAGA klassifiziert, da es von WFS 1.1 referenziert wurde. Inzwi
schen wurde WFS 1.1 durch WFS 2.0 abgelöst und damit auch GML 3.1.1 auf die Bestandsschutz
liste verschoben.
Bestandsgeschützt: Geography Markup Language (GML) 3.0
PI
In SAGA 2.1 war die zu diesem Zeitpunkt aktuellste GML-Version 3.0 für den Austausch von Geo
informationen als „Obligatorisch“ klassifiziert. Bei der Aufnahme des neuen Themas „Geodienste“
in SAGA 3.0 wurde festgestellt, dass diese Version im Vergleich zu anderen GML-Versionen keine
große Relevanz im Zusammenspiel mit anderen Geo-Standards hat. Deshalb SOLLTE GML 3.0 in neu
en Anwendungen NICHT eingesetzt werden.
Bestandsgeschützt: Geography Markup Language (GML) 2.1.2
PI
GML 2.1.2 wurde mit der Aktualisierung von SAGA 4.0 durch Version 3.2.1 ersetzt.
Bestandsgeschützt: Geography Markup Language (GML) 2.0
PI
Zum Zeitpunkt der Veröffentlichung von SAGA 2.0 war GML 2.0 die aktuelle Version und als
„Empfohlen“ klassifiziert. Mit SAGA 2.1 erfolgte die Ersetzung durch den Nachfolger GML 3.0.
7.13 Datenkompression
Um den Austausch großer Dateien zu ermöglichen und die Netzbelastung zu minimieren, sollten
Systeme zur Kompression eingesetzt werden.
Empfohlen: ZIP 4.5
ZIP164 ist eine weitverbreitete Spezifikation für die Kompression von Dateien. Zum Komprimieren
stehen verschiedene Algorithmen zur Verfügung.
Das Dateiformat ZIP wurde 1989 von Phil Katz für die Anwendung „PKZIP“ eingeführt und später
als „Public Domain“ freigegeben. ZIP unterstützt verschiedene Kompressionsverfahren. Verwendet
werden SOLLTE das Standardkompressionsverfahren „DEFLATE“, ein frei verfügbarer, patentfreier
Kompressionsalgorithmus.
ZIP SOLLTE für die Datenkompression verwendet werden, insbesondere wenn mehrere Dateien in ei
nem Archiv zusammengefasst werden sollen.
163 http://www.opengeospatial.org/standards/kml
164 http://www.pkware.com/documents/APPNOTE/APPNOTE-4.5.0.txt
PI
7.13 Datenkompression
52
Empfohlen: Gnu ZIP (GZIP) 4.3 / Tape ARchive (TAR)
PI
GZIP165 ist eine besonders in der UNIX-Welt weitverbreitete Spezifikation für die Kompression von
Dateien. Im Gegensatz zu ZIP wird Gnu ZIP nur zum Komprimieren einzelner Dateien verwendet.
Sollen mehrere Dateien komprimiert werden, müssen diese zunächst zu einem Archiv zusammenge
fasst werden. Hierzu SOLLTE die Spezifikation TAR166 dienen.
Das Gnu ZIP Dateiformat wurde von der IETF als RFC 1952 standardisiert. Ebenso wie ZIP verwen
det Gnu ZIP den freien Algorithmus „DEFLATE“ (RFC 1951) für die Kompression.
TAR ist seit langer Zeit Bestandteil von UNIX und wurde im Zuge der Standardisierungsbemühun
gen Teil des „UNIX-Standards“ ISO/IEC 9945.
Die Kombination GZIP/TAR SOLLTE dem ZIP-Format immer dann vorgezogen werden, wenn viele
gleichartige Dateien zu einem Archiv gepackt werden sollen, da von GZIP redundante Informationen
über Dateigrenzen hinweg komprimiert werden und so eine höhere Kompressionsrate erreicht wird.
Bestandsgeschützt: ZIP 2.0
PI
Version 2.0 des ZIP-Formats wurde mit der Aktualisierung von SAGA 4.0 durch Version 4.5 ersetzt.
7.14 Technologien für die Präsentation auf mobi
len Endgeräten
Sofern ein Informationsangebot für Mobiltelefone beziehungsweise Smartphones erstellt werden
soll, ist der Aufbau von SMS-Diensten aufgrund der flächendeckenden Unterstützung von SMS zu
bevorzugen.
Über die folgenden Spezifikationen hinaus SOLLTEN auch die Standards, die zur Präsentation von In
halten durch Computer im Allgemeinen beschrieben wurden, für mobile Endgeräte zum Einsatz
kommen, siehe Abschnitte 7.1 bis 7.13.
Verbindlich: Short Message Services (SMS)
SMS167 ist ein Dienst in GSM168-basierten Mobilfunknetzen, mit dem sich kurze Textnachtrichten mit
Mobiltelefonen austauschen lassen. Eine Textnachricht ist auf 160 Zeichen begrenzt. Durch das Auf
teilen auf mehrere Nachrichten (theoretisch bis zu 255) können auch längere Texte versendet wer
den.
SMS wird durch das 3rd Generation Partnership Project (3GPP) 169 spezifiziert und durch das Euro
pean Telecommunications Standards Institute (ETSI)170 als Standard veröffentlicht.
SMS MUSS verwendet werden, wenn kurze Textnachrichten an Mobiltelefone gesendet werden sol
len.
165
166
167
168
169
170
http://ieeexplore.ieee.org/servlet/opac?punumber=7685
http://pda.etsi.org/pda/queryform.asp
GSM = Global System for Mobile Communications
http://www.3gpp.org/
http://www.etsi.org/
PI
7.14 Technologien für die Präsentation auf mobilen Endgeräten
Beobachtet:
53
Extensible Hypertext Markup Language (XHTML) Basic 1.1
PI
XHTML Basic171 ist eine auf Basis der XHTML-Spezifikation des W3C definierte Untermenge von
Attributen, die für einen mobilen Browser ausreichend sind.
Im Juli 2008 wurde XHTML Basic in der Version 1.1 vom W3C veröffentlicht und zuletzt im No
vember 2010 mit einer Second Edition172 überarbeitet.
XHTML Basic 1.1 KANN für die die Darstellung von Webseiten auf mobilen Endgeräten (z. B. Han
dys, Smartphones) verwendet werden.
Beobachtet: Wireless Application Protocol (WAP) 2.0
PI
WAP173 ist eine Spezifikation zur Entwicklung von Anwendungen, die über drahtlose Kommunikati
onsnetzwerke operieren. Haupteinsatzgebiet sind mobile Internetangebote.
WAP 2.0 wurde durch die Open Mobile Alliance (OMA)174 entwickelt und 2002 als Spezifikation
veröffentlicht. Seither wurde nicht an einer Weiterentwicklung gearbeitet.
Durch steigende Bandbreite und Leistungsfähigkeit mobiler Endgeräte fallen die Vorteile von WAP
immer weniger ins Gewicht. WAP KANN dennoch verwendet werden, um insbesondere die Darstel
lung auf älteren mobilen Endgeräten zu verbessern.
Bestandsgeschützt: Extensible Hypertext Markup Language (XHTML) Basic 1.0
PI
XHTML 1.0 Basic wurde mit der Aktualisierung von SAGA 4.0 auf die Bestandsschutzliste gesetzt.
Stattdessen wurde XHTML Basic 1.1 in SAGA aufgenommen.
Bestandsgeschützt: Wireless Application Protocol (WAP) 1.x
PI
In SAGA 2.0 wurde WAP 1.x als „Unter Beobachtung“ klassifiziert. Es wurde in SAGA 2.1 durch
die nachfolgende Version WAP 2.0 ersetzt.
Bestandsgeschützt: Wireless Markup Language (WML) 1.x
In SAGA 2.0 war WML 1.x als „Unter Beobachtung“ klassifiziert. Sie wurde in SAGA 2.1 durch
WAP 2.0 ersetzt, da WAP 2.0 die Weiterentwicklung WML 2.0 einschließt.
8
Kommunikation
8.1 Kommunikation zwischen Applikationen
In diesem Abschnitt wird nicht zwischen der Kommunikation Client-Server oder Server-Server un
terschieden. Die folgenden Abschnitte unterscheiden aber, ob Applikationen innerhalb der Netze der
öffentlichen Verwaltung untereinander kommunizieren oder ob eine Applikation außerhalb der Ver
waltung mit einer Applikation im Netz der öffentlichen Verwaltung kommuniziert.
171
172
173
174
http://www.w3.org/TR/xhtml-basic/
http://www.w3.org/TR/2010/REC-xhtml-basic-20101123/
http://www.wapforum.org/what/technical.htm
http://www.openmobilealliance.org/
PI
8.1 Kommunikation zwischen Applikationen
54
Kommen Web Services zum Einsatz, SOLLTEN zur Implementation die Spezifikationen des Abschnit
tes 5.3 „Diensteorientierte Architekturen“ auf Seite 22 beachtet werden. Alternativ zu einer dienste
orientierten Architektur kann auch das Architekturkonzept „Representational State Transfer“ (REST)
zur Anwendung kommen. In diesem Fall dient HTTP als Kommunikationsprotokoll.
8.1.1
Kommunikation zwischen Applikationen innerhalb der
Verwaltung
Verbindlich: Web Services Security (WS-Security) 1.1
PI
WS-Security175 ist ein Standard aus dem Kontext der WS-*-Spezifikationen und beschreibt Erweite
rungen von SOAP-Nachrichten (Web Services). Bestehende Techniken, wie z. B. XML Signature,
XML Encryption, PKI oder SAML, werden einbezogen bzw. als Basis zu Hilfe genommen.
WS-Security MUSS zur Sicherung von Nachrichtenintegrität, Vertraulichkeit und zur Authentifizie
rung von SOAP-Nachrichten verwendet werden.
Empfohlen: Simple Object Access Protocol (SOAP) 1.1
PI
SOAP176 ist ein Protokoll zum standardisierten Informationsaustausch in dezentralen, verteilten Um
gebungen. Die Informationen werden in XML repräsentiert.
Im Jahr 2000 wurde SOAP in der Version 1.1 vom W3C veröffentlicht.
SOAP 1.1 SOLLTE für die Kommunikation zwischen dem Erbringer und dem Nutzer eines Dienstes
im Sinne des SOA-Referenzmodells eingesetzt werden.
Empfohlen: Message Transmission Optimization Mechanism (MTOM)
PI
MTOM177 baut auf XOP (XML-binary Optimized Packaging) auf und SOLLTE für die effiziente Über
tragung von SOAP-Envelopes mit Binärdaten verwendet werden.
Im Januar 2005 wurde MTOM vom W3C als Recommendation veröffentlicht.
Empfohlen: Java Message Service (JMS) 1.1
JMS178 ist ein Standard, der es Anwendungskomponenten ermöglicht, Nachrichten basierend auf der
Java Enterprise Edition (Java EE) zu erstellen, zu senden und zu empfangen. Die JMS API ermög
licht eine verteilte Kommunikation, die lose gekoppelt, zuverlässig und asynchron ist.
JMS wurde 2003 in der Version 1.1 als JSR 914 vom JCP veröffentlicht.
JMS 1.1 SOLLTE dann verwendet werden, wenn die miteinander kommunizierenden Komponenten
hinsichtlich ihrer Schnittstellen nicht offen gelegt werden sollen (leichtere Austauschbarkeit) und die
Kommunikation zwischen den Komponenten generell asynchron und fehlertolerant verlaufen soll.
175
176
177
178
http://www.oasis-open.org/specs/index.php#wssv1.1
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
http://www.w3.org/TR/soap12-mtom/
I
8.1.1 Kommunikation zwischen Applikationen innerhalb der Verwaltung
55
PI
Siehe Hypertext Transfer Protocol (HTTP) 1.1 im Abschnitt 8.5 „Anwendungsprotokolle“ auf Seite
60.
HTTP ist das grundlegende Kommunikationsprotokoll des Architekturkonzepts „Representational
State Transfer (REST)“179 für verteilte Anwendungen. REST beschreibt ein Muster, wie Anwendun
gen oder Dienste miteinander kommunizieren sollten. Das World Wide Web mit seinen Standards
HTTP und URL ist die hauptsächliche Ausprägung des REST-Musters – wenn diese Spezifikationen
im Sinne von REST eingesetzt werden.
Im Jahr 2000 wurde REST von Roy Fielding, dem Hauptautor der HTTP-Spezifikation und Vorsit
zenden der Apache Foundation, veröffentlicht.
HTTP und REST SOLLTEN eingesetzt werden, wo eine SOAP-Kommunikation überdimensioniert
wäre. Darüber hinaus SOLLTE HTTP als das hauptsächliche Übertragungsprotokoll für SOAP-Kom
munikation verwendet werden.
Empfohlen: Java Portlet Specification ≥1.0
I
Die Java Portlet Specification180 beschreibt die Interaktion zwischen Portlets und Portalen zum Aus
tausch von Informationen für die Präsentation in den Portalen.
Im Jahr 2003 wurde die Java Portlet Specification in der Version 1.0 vom JCP als JSR 168 veröffent
licht, die Version 2.0 im Jahr 2008 als JSR 286181.
Sofern auf die Weitergabe von Events zwischen Portlets verzichtet werden kann, SOLLTE die Java
Portlet Specification 1.0 aufgrund der einfacheren Handhabung verwendet werden. Andernfalls
SOLLTE die Java Portlet Specification 2.0 verwendet werden.
Wird im Projekt Java nicht verwendet, SOLLTE auf die java-unabhängige Spezifikation Web Services
for Remote Portlets (WSRP) gesetzt werden, siehe unten.
Empfohlen: Web Services for Remote Portlets (WSRP) ≥1.0
I
WSRP182 beschreibt eine Web-Service-Schnittstelle für einen plattform- und programmiersprachen
unabhängigen Austausch von Informationen aus entfernten Quellen. Nur für größere Projekte mit
Datenaggregation bieten Portlets ein gutes Verhältnis zwischen Realisierungsaufwand und Perfor
manz und SOLLTEN dort verwendet werden.
WSRP 1.0 und 2.0 sind jeweils das java-unabhängige Pendant zur Java Portlet Specification 1.0 und
2.0. Sie wurden von der OASIS im April 2003 bzw. April 2008 veröffentlicht.
Beobachtet: Simple Object Access Protocol (SOAP) 1.2
Siehe Simple Object Access Protocol (SOAP) 1.1 im Abschnitt 8.1.1 „Kommunikation zwischen Ap
plikationen innerhalb der Verwaltung“ auf Seite 54.
SOAP wurde im Jahr 2003 in der Version 1.2183 vom W3C veröffentlicht.
179
180
181
182
183
http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf
http://www.jcp.org/en/jsr/detail?id=168
http://www.jcp.org/en/jsr/detail?id=286
http://docs.oasis-open.org/wsrp/v2/wsrp-2.0-spec-os-01.pdf
http://www.w3.org/TR/2007/REC-soap12-part0-20070427/
PI
8.1.1 Kommunikation zwischen Applikationen innerhalb der Verwaltung
56
Bestandsgeschützt: Web Services (WS)-Security 1.0
PI
Die Version 1.0 von WS-Security war in SAGA 2.1 als „Empfohlen“ klassifiziert. In SAGA 3.0 er
setzte WS-Security 1.1 die Version 1.0.
Bestandsgeschützt: SOAP Messages with Attachments (SwA)
PI
SwA wurde mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 auf die Bestandsschutzliste
gesetzt. Die Alternative MTOM wurde als „Empfohlen“ aufgenommen.
Bestandsgeschützt: J2EE Connector Architecture (JCA) 1.5
I
JCA 1.5 wurde mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 für diesen Abschnitt auf
die Bestandsschutzliste verschoben. Lediglich im Abschnitt für den Zugriff auf Bestandssysteme
wurde Version 1.5 durch den Nachfolger JCA 1.6 ersetzt.
Bestandsgeschützt: Common Object Request Broker Architecture (CORBA)
PI
Als Standard für die Interoperabilität von Anwendungen hat sich CORBA nicht durchgesetzt. Es ist
komplex, kostenintensiv und mittlerweile veraltet. Für die Integration bereits bestehender Anwen
dungen hat diese Technologie jedoch noch Relevanz.
Bestandsgeschützt: Java to IDL Language Mapping (JAV2I) 1.0
I
JAV2I 1.0 wurde mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 auf die Bestandsschutz
liste verschoben.
PI
8.1.2
Kommunikation mit verwaltungsexternen Applikationen
PI
Siehe Web Services Security (WS-Security) 1.1 im Abschnitt 8.1.1 „Kommunikation zwischen Ap
PI
Empfohlen: Message Transmission Optimization Mechanism (MTOM)
Siehe Message Transmission Optimization Mechanism (MTOM) im Abschnitt 8.1.1 „Kommunikati
on zwischen Applikationen innerhalb der Verwaltung“ auf Seite 54.
PI
8.1.2 Kommunikation mit verwaltungsexternen Applikationen
57
PI
Siehe Hypertext Transfer Protocol (HTTP) 1.1 im Abschnitt 8.1.1 „Kommunikation zwischen Appli
kationen innerhalb der Verwaltung“ auf Seite 55.
PI
Bestandsgeschützt: Web Services (WS)-Security 1.0
PI
Siehe Web Services (WS)-Security 1.0 im Abschnitt 8.1.1 „Kommunikation zwischen Applikationen
innerhalb der Verwaltung“ auf Seite 56.
Bestandsgeschützt: SOAP Messages with Attachments (SwA)
PI
Siehe SOAP Messages with Attachments (SwA) im Abschnitt 8.1.1 „Kommunikation zwischen Ap
Bestandsgeschützt: Common Object Request Broker Architecture (CORBA)
PI
Siehe Common Object Request Broker Architecture (CORBA) im Abschnitt 8.1.1 „Kommunikation
zwischen Applikationen innerhalb der Verwaltung“ auf Seite 56.
PI
8.2 Netzwerkprotokolle
Verbindlich: Internet Protocol Version 4 (IPv4) / Version 6 (IPv6)
Das Internet Protocol (IP)184 ist ein verbindungsloses Protokoll der Vermittlungsschicht und erlaubt
den Austausch von Daten zwischen zwei Rechnern ohne vorherigen Verbindungsaufbau.
Im Jahr 1981 wurde IP in der Version 4 als RFC 791 von der IETF veröffentlicht. IPv6 wurde im
Jahr 1998 als RFC 2460 von der IETF publiziert.
Eines der wesentlichen Unterscheidungsmerkmale zu IPv4 ist der durch die Verwendung von 128bit-Adressen stark erweiterte Adressraum von IPv6. Auf internationaler Ebene ist der Adressraum
von IPv4 bereits erschöpft. Außerdem wurde u. a. die Netzwerksicherheit (IP Security – IPSec) mit
der Version 6 zum Bestandteil des Protokolls.
IP MUSS zur Übermittlung von Datenpaketen innerhalb eines Netzwerkes unterstützt werden. Die
fachlichen Anforderungen bestimmen, welche Version von IP zum Einsatz kommt. Falls die Wahl
auf IPv4 fällt, SOLLTE geprüft werden, ob zusätzlich auch eine Unterstützung von IPv6 angestrebt
werden sollte, um eine spätere Migration zu erleichtern.
184 IPv4: http://tools.ietf.org/html/rfc791; IPv6: http://tools.ietf.org/html/rfc2460
PI
8.2 Netzwerkprotokolle
58
Verbindlich: Domain Name System (DNS)
PI
DNS185 ist ein Protokoll zur Beantwortung von Anfragen zur Namensauflösung in Netzwerken.
Im Jahr 1987 wurde DNS als RFC 1034 und RFC 1035 von der IETF veröffentlicht.
DNS MUSS für die Namensauflösung in IP-Adressen („forward lookup“) und die umgekehrte Auflö
sung von IP-Adressen in Namen („reverse lookup“) verwendet werden.
8.3 E-Mail-Kommunikation
Verbindlich: Multipurpose Internet Mail Extensions (MIME) 1.0
PI
Siehe Multipurpose Internet Mail Extensions (MIME) 1.0 im Abschnitt 7.3 „Technologien zur In
formationsaufbereitung“ auf Seite 32
Verbindlich: Simple Mail Transfer Protocol (SMTP)
PI
SMTP186 definiert ein textorientiertes Protokoll der TCP/IP-Protokollfamilie, welches zur Übertra
gung von E-Mails an Mail-Server und für die Kommunikation der Mail-Server untereinander ver
wendet werden MUSS. Zum Abruf der E-Mails vom Server durch den Nutzer kommen andere Proto
kolle zum Einsatz.
Im Jahr 2008 wurde SMTP als RFC 5321 von der IETF veröffentlicht.
PKI) 2.0
PI
Siehe Common PKI Specifications for Interoperable Applications (Common PKI) 2.0 im Abschnitt
7.7.7 „Gesicherter Dokumentenaustausch“ auf Seite 42.
Empfohlen: Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
PI
IMAP187 ist ein Anwendungsprotokoll für den Zugriff, die Verwaltung und die Bearbeitung von
E-Mails, die sich im Postfach auf einem Mail-Server befinden.
Im Jahr 2003 wurde IMAP in der Version 4 rev1 als RFC 3501 von der IETF veröffentlicht.
IMAP v4rev1 SOLLTE für die server-seitige Verwaltung von elektronischen Postfächern, bei denen
alle Daten auf dem Server verbleiben, verwendet werden.
Empfohlen: Post Office Protocol, Version 3 (POP3)
POP188 ist ein Anwendungs- und Übertragungsprotokoll für das Abholen von E-Mails von einem
Mail-Server.
Im Jahr 1996 wurde POP in der Version 3 als RFC 1939 von der IETF veröffentlicht.
POP3 SOLLTE für die client-seitige Verwaltung von elektronischen Postfächern, bei denen alle Daten
vom Server auf den Client verschoben werden, verwendet werden.
185
186
187
188
http://tools.ietf.org/html/rfc1034; http://tools.ietf.org/html/rfc1035
PI
8.3 E-Mail-Kommunikation
59
Empfohlen: DomainKeys Identified Mail (DKIM)
PI
DKIM189 definiert ein Verfahren zur Authentifizierung von E-Mails mittels Public-Key-Verschlüsse
lung. Es SOLLTE zur Abwehr von Spam und Phishing eingesetzt werden.
DKIM wurde ursprünglich von Yahoo! entwickelt und zum Patent angemeldet. Yahoo! lizenziert das
Verfahren unter GPL (GNU General Public License) 2.0 und hat es im Jahr 2007 durch die IETF als
RFC 4871 standardisieren lassen.
DKIM erlaubt die Authentifizierung von Quelle und Inhalt einer Nachricht. Die verschlüsselnde Do
main übernimmt dabei die Verantwortung für eine E-Mail-Nachricht und stellt damit die Identität des
Absenders und die Integrität der Nachricht sicher. Dies grenzt DKIM von Verfahren wie Sender ID
und SPF ab, die sich auf die Authentifizierung des Absenders beschränken.
Beobachtet: Sender ID
PI
Das Sender ID Framework (kurz SIDF oder Sender ID)190 ist eine Methode um festzustellen, ob ein
Mail-Server berechtigt ist, eine bestimmte E-Mail zu versenden.
Im April 2006 wurde Sender ID von der IETF als RFC 4406 veröffentlicht.
Sender ID KANN – auch in Ergänzung zu DKIM – verwendet werden, um besser zu beurteilen, ob
eine E-Mail als Spam einzuordnen ist oder nicht.
Beobachtet: Sender Policy Framework (SPF) 1.0
PI
Sender Policy Framework (SPF)191 ist ein Protokoll, das es Domain-Besitzern ermöglicht, die HostComputer zu identifizieren, die E-Mail-Nachrichten für die Domain versenden dürfen.
Im April 2006 wurde SPF von der IETF als RFC 4408 veröffentlicht.
SPF KANN – auch in Ergänzung zu DKIM – zur besseren Abwehr von Spam-Mails verwendet wer
den.
tions (Common PKI) 1.1, Teile 1 bis 6
PI
Common PKI 1.1 wurde mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 durch Version
2.0 ersetzt.
Bestandsgeschützt: Industrial Signature Interoperability Specification (ISIS)-MTT 1.0
PI
Siehe Industrial Signature Interoperability Specification (ISIS)-MTT 1.0 im Abschnitt 7.7.7 „Gesi
cherter Dokumentenaustausch“ auf Seite 43.
Bestandsgeschützt: MailTrusT (MTT) Version 2
Siehe MailTrusT (MTT) Version 2 im Abschnitt 7.7.7 „Gesicherter Dokumentenaustausch“ auf Seite
43.
PI
8.4 IP-Telefonie
60
8.4 IP-Telefonie
Sprache beziehungsweise Telefonie ist ein wichtiger und etablierter Kommunikationskanal für Bür
ger, Unternehmen und Behörden. Auch Behörden betreiben bereits Call-Center und nutzen dafür
teilweise Telefonanlagen mit Voice-over-IP (VoIP). Für diese Kommunikationsart sind im Bereich
der Präsentation die Schnittstellen nach außen anzubieten und im Backend Schnittstellen zu Softwa
re-Systemen bereitzustellen (Computer Telephony Integration – CTI). So können den Kunden auf
Webseiten kontextabhängig VoIP-Verbindungen zu den jeweils spezialisierten Bearbeitern oder CallCenter-Mitarbeitern angeboten und beim Bearbeiter die bis dahin eingegebenen Daten medienbruch
frei angezeigt werden.
Empfohlen: H.323
PI
H.323192 ist ein Standard für die Übertragung von Echtzeitverbindungen (Video, Audio, Daten) in pa
ketorientierten Transportnetzen wie IP-Netzen.
Die von der ITU-T veröffentlichte Spezifikation H.323 SOLLTE für die IP-Telefonie verwendet wer
den.
Empfohlen: Session Initiation Protocol (SIP) 2.0
PI
SIP193 ist eine Spezifikation, die im Anwendungsbereich IP-Telefonie eingesetzt werden SOLLTE. Es
beschreibt die Modalitäten zur Verbindungsaushandlung bzw. -vereinbarung. Die Kommunikations
daten werden über andere, dafür geeignete Protokolle ausgetauscht.
SIP wurde von der IETF in einer Reihe von RFCs beginnend mit RFC 3261 spezifiziert und erwei
tert.
8.5 Anwendungsprotokolle
Empfohlen: File Transfer Protocol (FTP)
PI
FTP194 ist ein Dateiübertragungsstandard, der zu den ältesten Internetdiensten gehört. Das Protokoll
wird benutzt, um Dateien zwischen einem Client und einem Server auszutauschen.
Im Jahr 1985 wurde FTP von der IETF veröffentlicht und SOLLTE nur für Anwendungen mit norma
lem Schutzbedarf eingesetzt werden, da FTP sämtliche Daten unverschlüsselt überträgt. Mit dem
RFC 2228195 wurde die Möglichkeit geschaffen, FTP über verschlüsselte Kanäle zu verwenden
(FTPS). Bei gegebenem Schutzbedarf SOLLTE davon Gebrauch gemacht werden.
HTTP196 SOLLTE zur Übertragung von Daten zwischen Client und Web-Server verwendet werden.
Im Jahr 1999 wurde HTTP in der Version 1.1 von der IETF als RFC 2616 veröffentlicht.
Bei erhöhtem Schutzbedarf SOLLTE die HTTP-Übertragung mittels TLS gesichert werden (HTTPS).
192
193
194
195
196
http://www.itu.int/rec/T-REC-H.323/en
PI
61
Empfohlen: Online Service Computer Interface (OSCI)-Transport 1.2
PI
OSCI-Transport197 unterstützt Transaktionen in Form von Web Services und deren vollständige Ab
wicklung über das Internet. Als Teil des Online Service Computer Interface (OSCI) löst OSCI-Trans
port die Querschnittsaufgaben im Sicherheitsbereich. Als sicheres Übertragungsprotokoll ermöglicht
es verbindliche (auch SigG-konforme) Online-Transaktionen.
Im Jahr 2002 wurde OSCI-Transport in der Version 1.2 durch den KoopA ADV veröffentlicht.
Empfohlen: Secure Shell, Version 2 (SSH-2)
PI
Das Secure Shell (SSH) Protokoll198 SOLLTE in der Version 2 für die Absicherung von Netzwerkdiens
ten über unsichere Netze verwendet werden.
SSH-2 wurde ab 2006 von der IETF in mehreren RFCs (RFC 4250-4256, u. a.)199 spezifiziert.
Empfohlen: Transport Layer Security (TLS) 1.0 / 1.2
PI
TLS200 ist ein kryptografisches Protokoll, das eingesetzt werden SOLLTE, um die Informationssicher
heit hinsichtlich der Eigenschaften Vertraulichkeit und Integrität in IP-basierten Netzwerken (z. B.
dem Internet) sicherzustellen. TLS eignet sich zur Sicherung verschiedener Protokolle, z. B. HTTP.
Die IETF gibt TLS heraus. Version 1.0 ist im RFC 2246201 und Version 1.2 im RFC 5246202 spezifi
ziert.
TLS 1.0 unterstützt lediglich Verschlüsselung auf Basis der veralteten Verfahren IDEA und TripleDES. Für höhere Sicherheitsanforderungen SOLLTE TLS 1.2 verwendet werden. Falls Web-Browser
als Client zur Anwendung kommen, SOLLTE zusätzlich TLS 1.0 unterstützt werden, da der verbreitete
Browser Firefox bisher nur TLS 1.0 implementiert hat. Wenn die Sicherheitsanforderungen für die
Verwendung von TLS 1.0 zu hoch sind, SOLLTE ausschließlich TLS 1.2 eingesetzt werden und die
Anwender MÜSSEN darauf hingewiesen werden, Firefox nicht zu verwenden.
Empfohlen: WWW Distributed Authoring and Versioning (WebDAV)
PI
WebDAV203 ist eine Spezifikation, die als Erweiterung von HTTP das Schreiben und Verändern von
Dateien in Netzwerken ermöglicht.
Im Juni 2007 wurde WebDAV von der IETF als RFC 4918 herausgeben.
Beobachtet: Online Service Computer Interface (OSCI)-Transport 2.0
Siehe Online Service Computer Interface (OSCI)-Transport 1.2 im gleichen Abschnitt.
Im Unterschied zu Version 1.2 übernimmt OSCI-Transport 2.0 mittlerweile verfügbare Protokolle
des Web-Service-Stack. Daher ist OSCI-Transport 2.0 nicht abwärtskompatibel zur Version 1.2.
OSCI-Transport 2.0204 wurde im April 2010 durch den KoopA ADV veröffentlicht.
197
198
199
200
201
202
203
204
http://www.xoev.de/ → „Download“ → „OSCI Transport 1.2“ → „OSCI-Transport 1.2 - Spezifikation“
http://datatracker.ietf.org/wg/secsh/
http://datatracker.ietf.org/wg/secsh/
http://www.xoev.de/ → „Download“ → „OSCI-Transport 2.0“
PI
62
Beobachtet: Service Provisioning Markup Language (SPML) v2
PI
SPML205 ist ein auf XML basierendes Protokoll, das zum systemübergreifenden Austausch von In
formationen zu Benutzern, Ressourcen und Berechtigungen eingesetzt werden KANN.
Im Jahr 2006 wurde SPML v2 von der OASIS herausgegeben.
Beobachtet: Extensible Messaging and Presence Protocol (XMPP)
PI
XMPP206 KANN als Protokoll zur Übermittlung von kurzen Textnachrichten in Echtzeit, sogenanntes
Instant Messaging, verwendet werden.
Im Jahr 2004 wurde XMPP als RFC 3920 - RFC 3923 von der IETF veröffentlicht.
Beobachtet: File Transfer and Access Management (FTAM)
PI
FTAM207 ermöglicht den Transport von Dateien. Dabei erlaubt FTAM u. a. gesicherten Transfer und
Wiederanlaufmechanismen nach Verbindungsunterbrechungen.
Bereits 1988 wurde FTAM als ISO 8571 normiert.
FTAM KANN für die gesicherte Übertragung in Verfahren mit hohem Transfervolumen verwendet
werden.
PI
Bestandsgeschützt: Secure Sockets Layer (SSL) 3.0
PI
Bis zu SAGA 2.1 war SSL zusammen mit dem Nachfolge-Standard TLS als „Obligatorisch“ klassifi
ziert. Für neue Software-Systeme SOLLTE TLS unterstützt werden. SSL 3.0 KANN für bestehende An
wendungen weiter genutzt werden, dagegen DARF SSL 2.0 wegen Sicherheitsmängeln NICHT mehr
zum Einsatz kommen.
Bestandsgeschützt: Service Provisioning Markup Language (SPML) v1.0
SPML v1.0 wurde zusammen mit SPML v2 im Zuge von SAGA 3.0 in die Vorschlagsliste aufge
nommen. SPML v1.0 wurde mit SAGA 4.0 auf die Bestandsschutzliste verschoben.
8.6 Geodienste
Alle Spezifikationen in diesem Abschnitt sind entweder Spezifikationen des Open Geospatial Con
sortium (OGC)208 oder bauen auf diesen auf. Die Klassifikationen wurden mit der Geodateninfra
struktur Deutschland (GDI-DE)209 abgestimmt und orientieren sich am GDI-DE Architekturkonzept
205
206
207
208
209
http://www.oasis-open.org/committees/download.php/17708/pstc-spml-2.0-os.zip
http://tools.ietf.org/html/rfc3920 u. a.
http://www.iso.org/
siehe http://www.opengeospatial.org/
eine Initiative von Bund, Ländern und Kommunen für den Aufbau einer länder- und ressortübergrei
fenden Geodateninfrastruktur Deutschland, siehe http://www.gdi-de.org/
PI
8.6 Geodienste
63
2.0210. Dieses Konzept enthält außerdem weitere Empfehlungen, die über die in SAGA klassifizierten
Spezifikationen hinausgehen und die bei der Umsetzung von Geodiensten beachtet werden SOLLTEN.
Die Festlegung von Formaten für den Austausch von Geoinformationen erfolgt im Abschnitt 7.12
auf Seite 50.
Verbindlich: Catalogue Services Specification 2.0.2 – ISO Metadata Application Profile
1.0
PI
OGC-CSW OpenGIS Catalogue Service Specification 2.0.2 – ISO Metadata Application Profile,
Version 1.0211 ist ein Standard für einen Suchdienst und MUSS für einen webbasierten Zugriff auf Me
tadaten über Geodaten, Geodatendienste und Anwendungen verwendet werden.
Die Version 1.0 wurde 2007 vom OGC veröffentlicht.
Soll ein CSW als INSPIRE Suchdienst eingesetzt werden, MUSS die INSPIRE-Umsetzungsanleitung
„Technical Guidance to implement INSPIRE Discovery Services“ 212 basierend auf dem CSW 2.0.2 –
ISO Metadata Application Profile 1.0 verwendet werden, um eine Konformität zur EU-Richtline IN
SPIRE sicherzustellen.
Verbindlich: Web Map Service (WMS) 1.3.0
PI
WMS213 dient dazu, über eine standardisierte Schnittstelle Kartensichten auf geografische Informa
tionen in Bildformaten anzuzeigen. Der Dienst bietet optional auch die Möglichkeit, Attributinfor
mationen zu einem so genannten Karten-Layer über eine Bildkoordinate (Pixel) abzufragen.
Die Spezifikation wurde im Jahre 2000 in der Version 1.0 vom OGC veröffentlicht und liegt seit
März 2006 in der Version 1.3.0 vor. Die ISO hat WMS als ISO 19128:2005 normiert.
Soll ein Kartendienst für geografische Informationen eingesetzt werden, MUSS WMS 1.3.0 verwendet
werden. Soll ein WMS als INSPIRE Darstellungsdienst eingesetzt werden, MUSS die INSPIRE-Um
setzungsanleitung für Darstellungsdienste „Technical Guidance to implement INSPIRE View Ser
vices“214 basierend auf dem WMS 1.3.0 verwendet werden, um eine Konformität zur EU-Richtline
INSPIRE sicherzustellen.
Verbindlich: Web Coverage Service (WCS) ≥1.1
WCS215 dient dazu, über eine standardisierte Schnittstelle mehrdimensionale gerasterte Geodaten be
reitzustellen und ist wie der WFS grundsätzlich als Download-Dienst anzusehen.
Die Spezifikation WCS wird vom OGC herausgegeben. WCS wurde im Jahre 2007 in der Version
1.1.2 veröffentlicht und liegt seit 2010 in der Version 2.0 vor.
Soll ein WCS als INSPIRE Download-Dienst eingesetzt werden, MUSS die INSPIRE-Umsetzungsan
leitung „Technical Guidance to implement INSPIRE Download Services“ 216 verwendet werden, um
die Konformität zur EU-Richtline INSPIRE sicherzustellen.
210 siehe (GDI-DE 2010)
211 http://www.opengeospatial.org/standards/cat
212 http://inspire.jrc.ec.europa.eu/documents/Network_Services/TechnicalGuidance_DiscoveryServices_
v3.0.pdf
213 http://www.opengeospatial.org/standards/wms
214 http://inspire.jrc.ec.europa.eu/documents/Network_Services/TechnicalGuidance_ViewServices_v3.0.
pdf
215 http://www.opengeospatial.org/standards/wcs
PI
8.6 Geodienste
64
Verbindlich: Web Feature Service (WFS) 2.0
PI
WFS217 definiert eine standardisierte Schnittstelle, die zum Herunterladen und optional zur Manipu
lation von Geodaten im Format GML verwendet werden MUSS.
Die Spezifikation wurde im Jahre 2005 in der Version 1.1 vom OGC veröffentlicht und liegt seit
2010 in der Version 2.0 vor.
Soll ein WFS als INSPIRE Download-Dienst eingesetzt werden, MUSS die INSPIRE-Umsetzungsan
leitung „Technical Guidance to implement INSPIRE Download Services“ 218 basierend auf dem WFS
2.0 verwendet werden, um eine Konformität zur EU-Richtline INSPIRE sicherzustellen.
Empfohlen: Simple Feature Access – Part 2: SQL Option (SFA-2) 1.1.0
PI
SFA-2219 spezifiziert ein SQL-Schema, das für die Speicherung, Abfrage und Manipulation von
raumbezogenen Informationen über das SQL Call Level Interface (SQL/CLI) verwendet werden
SOLLTE.
Im Jahr 1999 wurde SFA-2 in der Version 1.1.0 vom OGC veröffentlicht und 2004 von der ISO als
ISO 19125-2 normiert.
Beobachtet: Simple Feature Access – Part 2: SQL Option (SFA-2) 1.2.1
PI
Siehe Simple Feature Access – Part 2: SQL Option (SFA-2) 1.1.0 im gleichen Abschnitt.
SFA-2 wurde im Jahr 2010 in der Version 1.2.1 vom OGC veröffentlicht.
Beobachtet: Web Map Tile Service (WMTS) 1.0.0
PI
WMTS220 dient dazu, auf bereits vorberechnete gekachelte Kartensichten standardisiert zuzugreifen.
Im April 2010 wurde WMTS in der Version 1.0.0 vom OGC veröffentlicht und dient der Komplettie
rung bestehender Darstellungsdienste zur webbasierten Distribution von digitalen Karten (WMS).
WMTS KANN eingesetzt werden, um hoch performante und skalierbare webbasierte Anwendungen
zur Visualisierung von Geoinformationen zu erstellen.
Bestandsgeschützt: Web Feature Service (WFS) 1.1
PI
WFS 1.1 wurde mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 durch Version 2.0 er
setzt.
Bestandsgeschützt: Web Feature Service (WFS) 1.0
WFS 1.0 wurde mit der Aktualisierung von SAGA 4.0 durch Version 1.1 ersetzt.
216 http://inspire.jrc.ec.europa.eu/documents/Network_Services/INSPIRE%20Draft%20Technical
%20Guidance%20Download%20(Version%202.0).pdf
217 http://www.opengeospatial.org/standards/wfs
218 http://inspire.jrc.ec.europa.eu/documents/Network_Services/INSPIRE%20Draft%20Technical
%20Guidance%20Download%20(Version%202.0).pdf
219 http://www.opengeospatial.org/standards/sfs
220 http://www.opengeospatial.org/standards/wmts
PI
8.6 Geodienste
65
Bestandsgeschützt: Web Coverage Service (WCS) 1.0
PI
WCS 1.0 wurde mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 durch Version ≥1.1 er
setzt.
Bestandsgeschützt: Web Map Service Deutschland (WMS-DE) 1.0
PI
WMS-DE 1.0 wurde mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 auf die Bestands
schutzliste verschoben. Stattdessen wurde WMS 1.3.0 in SAGA aufgenommen.
9
Backend
9.1 Zugriff auf Verzeichnisdienste
Empfohlen: Lightweight Directory Access Protocol, Version 3 (LDAPv3)
PI
LDAP221 ist ein auf hierarchisch geordnete Informationen optimiertes Protokoll des Internets, das auf
X.500 basiert und für den Zugriff auf Verzeichnisdienste verwendet werden SOLLTE.
Im Juni 2006 wurde LDAPv3 von der IETF als RFC 4510 veröffentlicht.
LDAP-Server sind auf sehr kurze Latenzzeiten bei Lesezugriffen optimiert und bieten einfache
Suchfunktionen in verteilten Verzeichnisdiensten.
Beobachtet: Directory Services Markup Language (DSML) v2.0
PI
DSML222 bietet die Möglichkeit, Anfragen und Änderungen an einen Verzeichnisdienst als XMLDokument zu senden. DSML v2.0 Dokumente können vielfältig verwendet werden, z. B. können sie
via HTTP an einen Server zur Weiterverarbeitung geschickt werden.
Im April 2002 wurde DSML v2.0 als OASIS-Standard verabschiedet.
Der Zugriff auf Verzeichnisdienste KANN unter Verwendung dieser Spezifikation erfolgen, falls kein
LDAP-Client zur Verfügung steht oder das LDAP-Protokoll durch eine Firewall blockiert wird.
Beobachtet: Universal Description, Discovery and Integration (UDDI) v2.0
UDDI223 ist die Basis für den Aufbau einer standardisierten, interoperablen Plattform, die das einfa
che, schnelle und dynamische Auffinden von Web Services erlaubt. Es setzt auf Standards des W3C
und der IETF auf, wie z. B. XML, HTTP, DNS und SOAP.
Die Version 2.0 von UDDI wurde 2003 von der OASIS als Standard verabschiedet.
221 http://tools.ietf.org/rfc/index
222 http://www.oasis-open.org/committees/dsml/docs/DSMLv2.doc
223 http://www.oasis-open.org/specs/
PI
9.2 Zugriff auf Datenbanken und Registrys
66
Empfohlen: Java Database Connectivity (JDBC) 4.0
PI
JDBC 4.0224 SOLLTE für eine datenbankunabhängige Verbindung zwischen einem auf Java basieren
den Programm und einer SQL-Datenbank verwendet werden. Kommt aufgrund fachlicher Anforde
rungen eine NoSQL-Datenbank zum Einsatz oder wird kein Java verwendet, SOLLTE der Datenbank
zugriff über eine geeignete herstellerunabhängige Schnittstelle bzw. Spezifikation erfolgen.
Im Jahr 2006 wurde JDBC in der Version 4.0 als JSR 221 vom JCP veröffentlicht.
Beobachtet: Java Content Repository (JCR) 2.0
PI
JCR225 spezifiziert ein abstraktes Modell und eine Java API für die Datenspeicherung und zugehörige
Services von inhaltsorientierten Anwendungen.
Vom JCP wurde JCR 2.0 im September 2009 als JSR 283 verabschiedet und ersetzt die ältere Versi
on 1.0 (JSR 170)226.
JCR KANN nicht nur für traditionelle Content Management Systeme (CMS), sondern für jede Anwen
dung, die mit unstrukturierten digitalen Objekten und strukturierten Informationen umgehen muss,
eingesetzt werden.
Beobachtet: Content Management Interoperability Services (CMIS) 1.0
PI
CMIS227 definiert ein Modell und eine Reihe von Web Services, die von Anwendungen für den Zu
griff auf Content Management Systeme (CMS) oder Repositorys verwendet werden KÖNNEN.
Im Mai 2010 wurde CMIS 1.0 von der OASIS als Standard herausgegeben.
Im Gegensatz zu Java Content Repository (JCR) beschreibt CMIS keine Programmierschnittstellen,
sondern eine weitere Abstraktionsschicht, das auf bestehenden (z. B. auch JCR-konformen) CMS
aufsetzt.
Beobachtet: ebXML Registry Services and Protocols (ebXML RS) 3.0 /
ebXML Registry Information Model (ebXML RIM) 3.0
„ebXML RS“228 beschreibt die Dienste und Protokolle, über die auf eine ebXML 229-konforme Re
gistry zugegriffen werden KANN. Eine ebXML-Registry ist ein System, das beliebige Inhalte und zu
gehörige, standardisierte Metadaten sicher verwaltet. „ebXML RIM“ 230 beschreibt das zugehörige In
formationsmodell. Die Anwendung der Spezifikationen SOLLTE zusammen erfolgen.
2005 wurden „ebXML RS“ und „ebXML RIM“ von der OASIS in der Version 3.0 veröffentlicht.
224
225
226
227
228
229
230
http://jcp.org/aboutJava/communityprocess/final/jsr283/
http://jcp.org/aboutJava/communityprocess/final/jsr170/
http://docs.oasis-open.org/cmis/CMIS/v1.0/os/cmis-spec-v1.0.html
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=regrep
ebXML = Electronic Business using XML
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=regrep
PI
67
Bestandsgeschützt: Java Database Connectivity (JDBC) 3.0
PI
JDBC 3.0 wurde mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 durch Version 4.0 er
setzt.
Bestandsgeschützt: Java Database Connectivity (JDBC) 2.0
PI
Die Version 2.0 von JDBC war in SAGA 1.1 als „Obligatorisch“ klassifiziert. Mit der Aufnahme von
J2xE 1.4 in SAGA 2.0 wurde auch das zugehörige JDBC 3.0 in SAGA 2.0 aufgenommen.
9.3 Zugriff auf Bestandssysteme
In der deutschen Verwaltung werden verschiedene Bestands- oder Legacy-Systeme eingesetzt und
mit einer hohen Wahrscheinlichkeit auch weiterhin betrieben (z. B. ERP, Mainframe-Transaktions
verarbeitung, Datenbanksysteme und andere Legacy-Applikationen). 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 (Massendatenverar
beitung) und
c.
Programm-Programm-Kommunikation auf der Basis proprietärer Protokolle.
Zur Integration von Bestandssystemen existieren zwei grundsätzliche Möglichkeiten:
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 Bestands
systems unterstützt werden sollen, bewertet und verglichen werden.
Die folgenden Abschnitte skizzieren unterschiedliche Lösungskonzepte, die sich bei den drei ge
nannten Betriebsarten bewährt haben.
Die Spezifikation der zu übertragenden Datenelemente SOLLTE mittels der in Kapitel 4 „Datenmodel
le“ auf Seite 16 und im Abschnitt 7.6 „Austauschformate für Daten“ auf Seite 35 benannten Spezifi
kationen erfolgen.
PI
Siehe Web Services Security (WS-Security) 1.1 im Abschnitt 8.1.1 „Kommunikation zwischen Ap
Empfohlen: Java EE Connector Architecture (JCA) 1.6
JCA231 definiert eine Architektur, die eine Einbindung von heterogenen betrieblichen Informations
systemen (Enterprise Information Systems – EIS) in die Java EE Plattform ermöglicht.
I
9.3 Zugriff auf Bestandssysteme
68
Im Dezember 2009 wurde JCA in der Version 1.6 vom Java Community Process (JCP) als JSR 322
veröffentlicht.
JCA 1.6 SOLLTE für den Zugriff auf Bestandssysteme aus einer auf Java EE 6 basierenden Anwen
dung heraus verwendet werden.
Empfohlen: Java Message Service (JMS) 1.1
I
Siehe Java Message Service (JMS) 1.1 im Abschnitt 8.1.1 „Kommunikation zwischen Applikationen
innerhalb der Verwaltung“ auf Seite 54.
PI
PI
Bestandsgeschützt: UN/EDIFACT
PI
UN/EDIFACT war in SAGA 1.1 als „Empfohlen“ klassifiziert und wurde als Beispiel für weit ver
breitete Industriestandards verwendet. Mit SAGA 2.0 wurde es auf die Bestandsschutzliste verscho
ben.
Bestandsgeschützt: J2EE Connector Architecture (JCA) 1.5
I
JCA 1.5 wurde mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 durch die Version 1.6 er
setzt.
Bestandsgeschützt: Java to IDL Language Mapping (JAV2I) 1.0
JAV2I 1.0 wurde mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 auf die Bestandsschutz
liste verschoben.
10 Verschlüsselung
Die Überführung klar lesbarer Daten in einen nicht ohne weiteres lesbaren Geheimtext wird Ver
schlüsselung genannt. Die Umkehrung wird als Entschlüsselung bezeichnet. Als Parameter werden
in beiden Fällen Schlüssel verwendet. Algorithmen zur Verschlüsselung werden grundsätzlich in
symmetrische und asymmetrische Verfahren unterschieden. Während symmetrische Verfahren zur
Ver- bzw. Entschlüsselung den gleichen Schlüssel verwenden, nutzen asymmetrische Verfahren von
einander verschiedene Schlüssel, ein sogenanntes Schlüsselpaar.
Um die Vorteile asymmetrischer und symmetrischer Verfahren in der Praxis zu nutzen, werden oft
Kombinationen beider Verfahren als sogenannte hybride Kryptosysteme verwendet. Dabei erfolgt
die eigentliche Verschlüsselung der Daten mit einem symmetrischen Verfahren, um dessen große Ef
fizienz zu nutzen. Der symmetrische Schlüssel wiederum wird zuvor mit einem asymmetrischen Al
gorithmus verschlüsselt und zwischen Sender und Empfänger ausgetauscht oder durch Schlüsselaus
I
10 Verschlüsselung
69
tauschverfahren vereinbart (z. B. Diffie-Hellman). Somit wird ein optimales Verhältnis zwischen Si
cherheit und Performanz erreicht.
10.1 Asymmetrische Verschlüsselungsverfahren
Asymmetrische Verschlüsselungsverfahren werden auch Public-Key-Verfahren genannt, da sie ein
Schlüsselpaar, bestehend aus einem öffentlichen Schlüssel zum Verschlüsseln sowie einem privaten
Schlüssel zum Entschlüsseln, verwenden.
Asymmetrische Verschlüsselungsverfahren sind in der Regel wesentlich langsamer als symmetrische
Verfahren, umgehen aber das Problem, einen geheimen Schlüssel zwischen Sender und Empfänger
austauschen zu müssen.
Empfohlen: RSA
PI
Das RSA-Verfahren232 wurde 1977 von Rivest, Shamir und Adleman entwickelt und ist das am wei
testen verbreitete asymmetrische Verschlüsselungsverfahren.
Die Parameter für den Einsatz des RSA-Verfahrens, wie z. B. die Schlüssellängen, sind entsprechend
der aktuellen Empfehlungen der Bundesnetzagentur233 auszuwählen.
10.2 Symmetrische Verschlüsselungsverfahren
Bei symmetrischen Verfahren erfolgen sowohl die Verschlüsselung als auch die Entschlüsselung mit
tels des gleichen geheimen Schlüssels. Diese Verfahren sind im Allgemeinen sehr effizient. Der
Nachteil solcher Verfahren liegt in der Notwendigkeit zur sicheren Übertragung des verwendeten
Schlüssels.
Verbindlich: Advanced Encryption Standard (AES)
PI
AES234 ist ein symmetrischer Blockchiffre und der am weitesten verbreitete symmetrische Verschlüs
selungsalgorithmus.
Herausgeber von AES ist das US-amerikanische National Institute of Standards and Technology
(NIST).
AES MUSS für die symmetrische Verschlüsselung verwendet werden.
Bestandsgeschützt: International Data Encryption Algorithm (IDEA)
PI
In SAGA 2.0 wurde IDEA als „Obligatorisch“ klassifiziert. In SAGA 2.1 wurde es von AES ver
drängt.
Bestandsgeschützt: Triple Data Encryption Standard (Triple-DES)
Der in SAGA 2.0 eingeführte symmetrische Kryptoalgorithmus Triple-DES war zuletzt in SAGA 2.1
als „Empfohlen“ klassifiziert worden. Mit SAGA 3.0 wurde Triple-DES auf die Bestandsschutzliste
verschoben.
232 http://people.csail.mit.edu/rivest/Rsapaper.pdf
233 Siehe (BNETZA, 2011)
234 http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
PI
10.2 Symmetrische Verschlüsselungsverfahren
70
Bestandsgeschützt: Chiasmus
PI
Chiasmus ist ein symmetrischer Verschlüsselungsalgorithmus, der in der gleichnamigen Verschlüsse
lungs-Software des BSI eingesetzt wird.
11 Elektronische Signatur
Elektronische Signaturen dienen dazu, die Authentizität der Signaturersteller zu gewährleisten und
die Integrität signierter Daten zu prüfen.
In der deutschen Gesetzgebung werden einfache, fortgeschrittene und qualifizierte elektronische Si
gnaturen sowie qualifizierte elektronische Signaturen mit Anbieterakkreditierung unterschieden. Für
die Gewährleistung der Rechtsverbindlichkeit werden in der Praxis qualifizierte elektronische Signa
turen benötigt.
Im Wesentlichen hängt die Sicherheit von elektronischen Signaturen von der Stärke der zugrunde
liegenden Algorithmen ab. Deren Sicherheit wiederum beruht darauf, dass diese mit der heutigen
Technik nicht in vernünftiger Zeit gebrochen werden können. Daher liegt es nahe, dass eine ständige
Sicherheitsprüfung erforderlich ist.
Weitere Spezifikationen, die im Zusammenhang mit elektronischen Signaturen von Bedeutung sind,
finden sich im Abschnitt 7.7.7 „Gesicherter Dokumentenaustausch“ auf Seite 42 und Kapitel 10
„Verschlüsselung“ auf Seite 68.
Verbindlich: Kryptoalgorithmen nach Bundesnetzagentur für die elektronische Signatur
PI
Bei der Auswahl der Algorithmen und zugehörigen Parameter zur Erzeugung von Signaturschlüs
seln, zum Hashen zu signierender Daten oder zur Erzeugung und Prüfung qualifizierter elektroni
scher Signaturen MUSS der Algorithmenkatalog der Bundesnetzagentur235 in der jeweils aktuellen Ver
sion angewendet werden. Er wird regelmäßig im Bundesanzeiger veröffentlicht.
11.1 Hashen von Daten
Hash-Funktionen dienen dazu, Zeichenfolgen beliebiger Länge auf relativ kurze Zeichenfolgen fes
ter Länge – den Hash-Werten – abzubilden. Eine im kryptografischen Sinne geeignete Hash-Funkti
on zeichnet sich durch Kollisionsresistenz aus, d. h., dass verschiedene Zeichenfolgen stets auf ver
schiedene Hash-Werte abgebildet werden. Dies wird im Kontext elektronischer Signaturen einge
setzt, um nur den kurzen Hash-Wert zu signieren und nicht den vollständigen Datensatz.
Die Algorithmen der ersten Generation (SHA-1) wurden aufgrund nicht garantierter Kollisionsresis
tenz durch eine zweite Generation (SHA-2) ersetzt. Im jährlichen Rhythmus stellt die Bundesnetz
agentur die Sicherheitseignung von Hash-Funktionen im Kontext von elektronischen Signaturen fest.
Verbindlich: Secure Hash Algorithm (SHA-2)
Zu den Algorithmen der SHA-2-Familie, spezifiziert unter FIPS PUB 180-3236, gehören SHA-224,
SHA-256, SHA-384 und SHA-512. Sie unterscheiden sich in der Länge des Hash-Werts. Je nach be
nötigtem Sicherheitsniveau MUSS einer dieser Algorithmen verwendet werden.
236 http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf
PI
11.1 Hashen von Daten
71
Im Zusammenhang mit elektronischen Signaturen ergeben sich zusätzliche Anforderungen an die
Eignung der verwendeten Hash-Funktion: SHA-256, SHA-384 und SHA-512 sind laut Bundesnetz
agentur bis Ende 2017 für die Anwendung bei qualifizierten elektronischen Signaturen geeignet,
SHA-224 hingegen nur bis Ende 2015.237
Bestandsgeschützt: Secure Hash Algorithm (SHA-1)
PI
In SAGA 2.1 wurde SHA-1 unterhalb der Klassifikationen von „SSL/TLS“, „XML Signature“,
„XML Encryption“ und „Kryptoalgorithmen nach RegTP238“ in den Beschreibungen erwähnt. Mit
SAGA 3.0 wurde Hash-Algorithmen ein eigener Abschnitt gewidmet, der sicherere Alternativen
(z. B. SHA-256) enthalten hat. SHA-1 wurde auf die Bestandsschutzliste aufgenommen.
Es darf laut Empfehlung der Bundesnetzagentur239 noch bis Ende 2015 aber ausschließlich zur Prü
fung qualifizierter Zertifikate verwendet werden.
Bestandsgeschützt: RIPEMD-160
PI
RIPEMD-160 darf laut Empfehlung der Bundesnetzagentur240 noch bis Ende 2015 aber ausschließ
lich zur Prüfung von qualifizierten Signaturen verwendet werden.
11.2 Asymmetrische Signaturverfahren
Ein asymmetrisches Signaturverfahren besteht aus einem Signier- und einem Verifizierungsalgorith
mus. Das Signaturverfahren hängt von einem Schlüsselpaar ab, bestehend aus einem privaten
Schlüssel zum Signieren und dem dazugehörigen öffentlichen Schlüssel zum Verifizieren der Signa
tur.
Empfohlen: RSA
PI
Das RSA-Verfahren241 ist ein asymmetrisches Kryptosystem, welches sowohl für die Verschlüsse
lung242 als auch bei der digitalen Signatur zum Einsatz kommen SOLLTE. Die Parameter für den Ein
satz des RSA-Verfahrens, wie z. B. die Schlüssellängen, sind entsprechend der aktuellen Empfehlun
gen der Bundesnetzagentur243 auszuwählen.
Empfohlen: Digital Signature Algorithm (DSA)
DSA244, im amerikanischen Digital Signature Standard (DSS) 1991 spezifiziert, ist ein reines Signa
turverfahren und SOLLTE sowohl zur Erstellung als auch zur Prüfung von Signaturen verwendet wer
den. Aktuell werden bis zum Jahr 2017 eine Schlüssellänge von 2048 Bit sowie bis 2015 eine Para
meterlänge von 224 Bit für DSA empfohlen245.
238 Die Regulierungsbehörde für Telekommunikation und Post (RegTP) heißt seit 2005 Bundesnetz
agentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen (BNetzA).
241 http://people.csail.mit.edu/rivest/Rsapaper.pdf
242 Siehe RSA im Abschnitt 10.1 „Asymmetrische Verschlüsselungsverfahren“ auf Seite 69
244 http://csrc.nist.gov/publications/PubsFIPS.html
PI
11.2 Asymmetrische Signaturverfahren
72
RSA und DSA sind im Kontext von Signaturen bezüglich Nutzen und Sicherheit gleichberechtigt.
Das RSA-Verfahren ist in der Praxis jedoch weiter verbreitet.
11.3 Key Management
Sowohl im Kontext von elektronischen Signaturen als auch bei der Verschlüsselung spielen Schlüs
sel eine zentrale Rolle. Zum Management sowie zum Austausch und zur Prüfung dieser Schlüssel
MÜSSEN jedoch geeignete Strukturen vorhanden sein.
Empfohlen: XML Key Management Specification (XKMS) 2.0
PI
XKMS 2.0246 spezifiziert Protokolle zur Registrierung und Verteilung von öffentlichen Schlüsseln
(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
OCSP247-Infrastrukturen zu. Mit nur einem Protokoll können so parallel verschiedene Verzeichnis
dienste genutzt werden.
12 Smartcards
Als Smartcards bzw. Integrated Circuit Card (ICC) werden Chipkarten mit einem integrierten Schalt
kreis bezeichnet. Im Gegensatz zu Chipkarten, welche nur der Speicherung von Daten dienen, kön
nen Smartcards auch Daten verarbeiten. Sie können als Personal Security Environment dienen, um
vertrauenswürdige Zertifikate und private Schlüssel sicher aufzubewahren und darüber hinaus als si
chere Signaturerstellungseinheit fungieren.
Smartcards werden in kontaktbehaftete und kontaktlose Smartcards unterschieden. Während kon
taktbehaftete Smartcards über sichtbare, äußere Kontaktflächen verfügen, wird die Kommunikation
mit den Lesegeräten bei kontaktlosen Smartcards über Funkkommunikation (Radio Frequency IDen
tification – RFID) hergestellt.
12.1 Kontaktbehaftete Smartcards
Verbindlich: Identification Cards – Integrated circuit cards
Die internationale Norm ISO 7816248 vereinheitlicht die wesentlichen elektrischen und physikali
schen Merkmale von kontaktbehafteten Smartcards. Dazu zählen Größe, Anordnung und Funktion
der Kartenkontakte, Übertragungsprotokolle zwischen Smartcard und Terminal, Nummerierungssys
teme sowie Sicherheitsaspekte.
246 http://www.w3.org/TR/xkms2/
247 OCSP = Online Certificate Status Protocol
PI
12.2 Kontaktlose Smartcards
73
12.2 Kontaktlose Smartcards
Verbindlich: Identification Cards – Contactless integrated circuit cards
PI
Die physikalischen und elektrischen Eigenschaften sowie die von kontaktlosen Smartcards verwen
deten Protokolle werden in der Norm ISO 14443249 spezifiziert. Solche Smartcards kommen bei
Identifikationssystemen, Zugangskontrollen und Bezahlsystemen zum Einsatz.
12.3 Lesegeräte und Schnittstellen für Smartcards
Verbindlich: BSI – Technische Richtlinie „eCard-API-Framework“
(BSI TR-03112) ≥1.1
PI
Das eCard-API-Framework250 umfasst eine Reihe von einfachen und plattformunabhängigen Schnitt
stellen und vereinheitlicht die Kommunikation zwischen den jeweiligen Anwendungen und den ein
gesetzten Smartcards. Es bildet das technische Fundament für die eCard-Strategie der Bundesregie
rung und liegt seit Mai 2011 in Version 1.1.1 vor.
Verbindlich: BSI – Technische Richtlinie für die eCard-Projekte der Bundesregierung
(BSI TR-03116) ≥3.0
PI
Die Technische Richtlinie BSI TR-06116251 stellt eine Vorgabe für die Sicherheitsanforderungen
beim Einsatz kryptografischer Verfahren in den eCard-Projekten der Bundesregierung dar. Teil 1 der
Richtlinie behandelt die elektronische Gesundheitskarte (eGK) und Teil 2 hoheitliche Dokumente,
u. a. den neuen Personalausweis (nPA) und den elektronischen Reisepass.
Empfohlen: Interoperability Specification for ICCs and Personal Computer Systems
(PC/SC) 2.x
PI
Der von der PC/SC Workgroup veröffentlichte Standard252 beschreibt eine Schnittstelle zwischen
Kartenlesegerät und Anwendungen.
Empfohlen: Secure Interoperable ChipCard Terminal (SICCT) 1.20
SICCT253 definiert ein generisches Basiskonzept für interoperable und applikationsunabhängige
Smartcard-Terminals auf Basis von bestehenden Normen (ISO 7816, ISO 14443) und Industriestan
dards (MKT254, PC/SC, EMV255) zu Kartenterminals und Smartcards. Somit entsteht ein interopera
bler und sicherer Kontext für den Betrieb von diversen Smartcard-Arten.
250 https://www.bsi.bund.de → „Publikationen“ → „Technische Richtlinen“ → „eCard-API-Frame
work“
251 https://www.bsi.bund.de/TR → „Publikationen“ → „Technische Richtlinen“ → „BSI TR-03116
eCard-Projekte der Bundesregierung“
252 http://www.pcscworkgroup.com/specifications/overview.php
253 http://www.teletrust.de/uploads/media/SICCT-Spezifikation-120.pdf
254 MKT = Multifunktionale Kartenterminals
255 Spezifikation für Zahlungskarten, EMV = Europay International (heute MasterCard Europe), Mas
terCard, VISA
PI
12.3 Lesegeräte und Schnittstellen für Smartcards
74
PKI) 2.0
PI
Siehe Common PKI Specifications for Interoperable Applications (Common PKI) 2.0 im Abschnitt
7.7.7 „Gesicherter Dokumentenaustausch“ auf Seite 42.
Bestandsgeschützt: BSI – Technische Richtlinie „eCard-API-Framework“ (BSI TR03112) 1.0
PI
Version 1.0 der Technischen Richtlinie des BSI „eCard-API-Framework“ wurde mit dem SAGAModul „Technische Spezifikationen“ 5.0.0 durch Version 1.1 ersetzt.
Bestandsgeschützt: BSI – Technische Richtlinie für die eCard-Projekte der Bundesre
gierung (BSI TR-03116) 1.0
PI
Version 1.0 der Technischen Richtlinie für die eCard-Projekte der Bundesregierung des BSI wurde
mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 durch Version 3.0 ersetzt.
Bestandsgeschützt: Secure Interoperable ChipCard Terminal (SICCT) 1.10
PI
SICCT 1.10 wurde mit der Aktualisierung von SAGA 4.0 durch Version 1.20 ersetzt.
tions (Common PKI) 1.1, Teil 7
PI
Common PKI 1.1, Teil 7 wurde mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 durch
Version 2.0 ersetzt.
13 Langzeitspeicherung
Mit Langzeitspeicherung wird hier die langfristige, rechts- und revisionssichere elektronische Spei
cherung von aufbewahrungspflichtigen elektronischen Dokumenten und Daten sowie der dazugehö
rigen elektronischen Metadaten bezeichnet.
Empfohlen: BSI – Technische Richtlinie „Beweiswerterhaltung kryptographisch si
gnierter Dokumente“ (BSI TR-03125) ≥1.1
PI
Die Technische Richtlinie BSI TR-03125256 definiert Anforderungen zum Beweiswerterhalt bei der
elektronischen Aufbewahrung von kryptografisch signierten elektronischen Dokumenten bis zum
Ende ihrer Aufbewahrungsfrist.
Im Zentrum stehen Begriffe wie Verfügbarkeit, Lesbarkeit, Integrität, Authentizität, Datensicherheit
und Datenschutz von elektronischen Daten.
Empfohlen: PDF/Archive 1 (PDF/A-1)
PDF257 ist ein Format zum Austausch und zur Ansicht elektronischer Dokumente unabhängig von der
Umgebung, in der sie erstellt wurden. PDF/A-1 basiert auf PDF 1.4 und definiert Einschränkungen,
sodass die speziellen Anforderungen der Langzeitspeicherung durch das PDF-Format erfüllt werden.
256 https://www.bsi.bund.de → „Publikationen“ → „Technische Richtlinien“ → „BSI TR-03125 Be
weiswerterhaltung kryptographisch signierter Dokumente“
PI
13 Langzeitspeicherung
75
Seit 2005 ist PDF/A-1 durch die ISO als ISO 19005-1 normiert.
Empfohlen: Joint Photographic Experts Group (JPEG)
PI
JPEG258 SOLLTE für die Langzeitspeicherung von Fotos und Grafiken mit Farbverläufen, bei denen
die verlustbehaftete Kompression dieses Formates unschädlich ist, verwendet werden. JPEG-Dateien
bieten für derartige Bilder eine hohe Kompressionsrate.
1992 wurde JPEG von der Joint Photographic Experts Group veröffentlicht und 1994 von der ISO
als ISO/IEC 10918-1 normiert.
Empfohlen: Tagged Image File Format (TIFF) 6.0
PI
Siehe Tagged Image File Format (TIFF) 6.0 im Abschnitt 7.8 „Austauschformate für Bilder“ auf Sei
te 44.
Empfohlen: Extensible Markup Language (XML) 1.0
PI
Siehe Extensible Markup Language (XML) 1.0 im Abschnitt 7.6 „Austauschformate für Daten“ auf
Seite 35.
XML 1.0 SOLLTE im Bereich der Langzeitspeicherung von Metadaten und stark strukturierten Daten
verwendet werden. Insbesondere bei der Langzeitspeicherung schwach strukturierter Daten SOLLTEN
andere Spezifikationen vorgezogen werden.
Beobachtet: Joint Photographic Experts Group 2000 (JPEG 2000) / Part 1
PI
Siehe Joint Photographic Experts Group 2000 (JPEG 2000) / Part 1 im Abschnitt 7.8 „Austauschfor
mate für Bilder“ auf Seite 44.
Bestandsgeschützt: ArchiSig, Grundsätze für die beweiskräftige und sichere Langzeit
archivierung digital signierter Dokumente
ArchiSig wurde mit dem SAGA-Modul „Technische Spezifikationen“ 5.0.0 auf die Bestandsschutz
liste verschoben.
258 http://www.jpeg.org/jpeg/index.html
I
A Literatur
A
76
Literatur
(BFIT, 2011A)
Die Beauftragte der Bundesregierung für Informationstechnik: IT-Angebot; 2011;
http://www.cio.bund.de/DE/IT-Angebot/it_angebot_node.html;
http://www.cio.bund.de/ → „IT-Angebot“
(BFIT, 2011B)
Die Beauftragte der Bundesregierung für Informationstechnik: SAGA-Modul Grundlagen;
Version de.bund 5.1.0, November 2011;
(BFIT, 2011C)
Die Beauftragte der Bundesregierung für Informationstechnik: SAGA-Modul Konformität;
Version de.bund 5.1.0, November 2011;
(BFIT, 2011D)
Die Beauftragte der Bundesregierung für Informationstechnik: SAGA; 2011;
(BNETZA, 2011)
Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen:
Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der
Signaturverordnung; Juni 2011;
http://www.bundesnetzagentur.de/cln_1932/DE/Sachgebiete/QES/Veroeffentlichungen/Algo
rithmen/algorithmen_node.html;
http://www.bundesnetzagentur.de/ → „Sachgebiete“ → „Qualifizierte elektronische
Signatur“ → „Veröffentlichungen“ → „Algorithmen“
(BSI, 2011A)
Bundesamt für Sicherheit in der Informationstechnik: IT-Grundschutz-Kataloge; 2011;
https://www.bsi.bund.de/DE/Themen/weitereThemen/ITGrundschutzKataloge/itgrundschut
zkataloge_node.html;
http://www.it-grundschutz.de/ → „IT-Grundschutz-Kataloge“
(BSI, 2011B)
Bundesamt für Sicherheit in der Informationstechnik: IT-Grundschutz-Standards; 2011;
https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzStandards/ITG rundsch
utzStandards_node.html;
http://www.it-grundschutz.de/ → „IT-Grundschutz-Standards“
(GDI-DE 2010)
Arbeitskreis Architektur der GDI-DE und Koordinierungsstelle GDI-DE: Architektur der
Geodateninfrastruktur Deutschland Version 2.0; September 2010;
http://www.gdi-de.org/download/AK/A-Konzept_v2_100909.pdf;
http://www.gdi-de.org/arbeitskreise/architektur → „Architektur der GDI-DE, Version 2.0“
B Abkürzungsverzeichnis
B
77
Abkürzungsverzeichnis
ANSI
American National Standards Institute
API
Application Programming Interface
BfIT
Die/Der Beauftragte der Bundesregierung für Informationstechnik
BIA
Business Impact Analyse
BMI
Bundesministerium des Innern
BMP
Windows Bitmap
BNetzA
Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen
BSI
Bundesamt für Sicherheit in der Informationstechnik
CAD
Computer-Aided Design
CLR
Common Language Runtime
CMS
Content Management System
CTI
Computer Telephony Integration
DCMI
Dublin Core Metadata Initiative
DIN
Deutsches Institut für Normung e.V.
ebXML
Electronic Business using XML
Ecma
ein Eigenname (früher: European Computer Manufacturers Association)
EDIFACT
Electronic Data Interchange For Administration, Commerce and Transport
EfA
Einer-für-alle
EIS
Enterprise Information Systems
EPC
Event-driven Process Chain (Ereignisgesteuerte Prozesskette)
ERP
Enterprise Resource Planning (Planung der Unternehmensressourcen)
ETSI
European Telecommunications Standards Institute
FIPS PUB
Federal Information Processing Standards Publication
GDI-DE
Geodateninfrastruktur Deutschland
GIF
Graphics Interchange Format
GIS
Geoinformationssystem
GNU
GNU’s Not Unix
GPL
GNU General Public License
GSM
Global System for Mobile Communications
I
gültig nur für Individualentwicklungen, nicht für Produkte
ICC
Integrated Circuit Card
78
IEC
International Electrotechnical Commission
IETF
Internet Engineering Task Force
INSPIRE
Infrastructure for Spatial Information in the European Community (Richtlinie
2007/2/EG vom 14. März 2007 des Europäischen Parlaments und des Rates vom
14. März 2007 zur Schaffung einer Geodateninfrastruktur in der Europäischen Ge
meinschaft)
ISMS
Informationssicherheits-Managementsystem
ISO
International Organization for Standardization
IT
Informationstechnologie
IT-Rat
Rat der IT-Beauftragten der Bundesressorts
JCP
Java Community Process
JPEG
Joint Photographic Experts Group
JSR
Java Specification Request
KoopA ADV
Kooperationsausschuss Automatisierte Datenverarbeitung Bund / Länder / Kommu
naler Bereich
LZW
Lempel-Ziv-Welch-Algorithmus
MPEG
Moving Picture Experts Group
NISO
National Information Standards Organization
NIST
National Institute of Standards and Technology
OASIS
Organization for the Advancement of Structured Information Standards
OCSP
Online Certificate Status Protocol
OGC
Open Geospatial Consortium
OMA
Open Mobile Alliance
OMG
Object Management Group
OSCI
Online Service Computer Interface
OSOA
Open SOA Collaboration
PDA
Personal Digital Assistent
PI
gültig für Produkte und Individualentwicklungen
PKI
Public-Key-Infrastruktur
RFC
Request for Comments
RFID
Radio Frequency Identification
SAGA
ein Eigenname (ursprünglich: Standards und Architekturen für eGovernment-An
wendungen)
SGML
Standard Generalized Markup Language
SigG
Gesetz über Rahmenbedingungen für elektronische Signaturen (Signaturgesetz)
SOA
Service-oriented architecture (Diensteorientierte Architektur)
SQL
Structured Query Language
TCP
Transmission Control Protocol
TR
Technical Report (Technischer Bericht / Technische Richtlinie)
UCS
Universal Character Set
URL
Uniform Resource Locator
VoIP
Voice over IP (Internettelefonie)
W3C
World Wide Web Consortium
WfMC
Workflow Management Coalition
WS
Web Service
WS-I
Web Services Interoperability Organization
XHTML
eXtensible HyperText Markup Language
XML
eXtensible Markup Language
3GPP
3rd Generation Partnership Project
79
C Strukturelle Übersicht klassifizierter Spezifikationen
C
80
Strukturelle Übersicht
klassifizierter Spezifikationen
C.1 IT-Sicherheitskonzeption
Abschnitt 2.1 Managementsysteme für Informationssicherheit
Verbindlich
Empfohlen
Beobachtet
- BSI-Standard 100-1 ≥1.5
Bestandsgeschützt
- BSI-Standard 100-1 1.0
Abschnitt 2.2 IT-Grundschutz-Vorgehensweise
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
Abschnitt 2.3 Risikoanalyse
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
Abschnitt 2.4 Notfallmanagement
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
Abschnitt 2.5 Umsetzung der Sicherheitskonzeption
Verbindlich
Empfohlen
Beobachtet
- BSI, IT-GrundschutzKataloge
Bestandsgeschützt
- BSI, E-GovernmentHandbuch, Modul
„Authentisierung im
E-Government“
- KoopA ADV,
Handlungsleitfaden 1.1
C.2 Prozessmodelle
Abschnitt 3.1 Technologien zur Prozessmodellierung
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- UML 2.x
- Flussdiagramme
- BPMN 1.1/1.2
- EPK
- BPMN 2.0
- BPMN 1.0
- UML ≤1.5
81
Abschnitt 3.2 Austauschformate für Prozessmodelle
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- XMI 2.x
- XPDL 2.1
- EPML 1.2
- XMI 1.x
C.3 Datenmodelle
Abschnitt 4.1 Technologien zur Datenmodellierung
Verbindlich
Empfohlen
Beobachtet
- ERD
- UML 2.x
Bestandsgeschützt
- UML ≤1.5
Abschnitt 4.2 Austauschformate für Datenmodelle
Verbindlich
Empfohlen
- XSD 1.0
- Relax NG
- XMI 2.x
Beobachtet
Bestandsgeschützt
- XMI 1.x
- DTD
Abschnitt 4.3 Beschreibungssprachen für Metadaten
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
Beobachtet
Bestandsgeschützt
- RDF
Abschnitt 4.4 Vokabulare für Metadaten
Verbindlich
Empfohlen
- DCES
C.4 Applikationsarchitektur
Abschnitt 5.1 Applikationsarchitektur für große Projekte
Verbindlich
Empfohlen
Beobachtet
- Java EE 6
- CLI
Bestandsgeschützt
- Java EE 5
- J2EE 1.4
- J2EE 1.3
Abschnitt 5.2 Applikationsarchitektur für kleine und mittlere Projekte
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- Java SE 6
- PHP 5.x
- C++
- Python
- Ruby
- CLI
- J2SE 5.0
- J2SE 1.4
- J2SE 1.3
- PHP 4.x
- Perl
82
Abschnitt 5.3 Diensteorientierte Architekturen
Verbindlich
Empfohlen
Beobachtet
- WS-I Basic Profile
1.1 / 1.2
- WSDL 1.1
- WS-BPEL 2.0
- WS-I Basic Profile
2.0
- WSDL 2.0
- SCA 1.0
Bestandsgeschützt
C.5 Client
Abschnitt 6.1.3 Client-Anwendungen
Verbindlich
Empfohlen
Beobachtet
- Java SE 6
- JNLP 6.x
Bestandsgeschützt
- J2SE 5.0
- JNLP 1.5
Abschnitt 6.2 Informationszugriff mit mobilen Endgeräten
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- Java ME / MIDP 2.0
Abschnitt 6.4 Technologien zur Authentisierung
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- WS-Trust 1.3
- WS-Federation 1.1
- SAML ≥1.0
- XACML 2.0
- Kerberos 5
- Open-ID 2.0
- Open-ID 2.0
- ID-SIS 1.0
- ID-FF 1.2
- ID-WSF 1.1
- BSI, E-GovernmentHandbuch, Modul
„Authentisierung im
E-Government“
Beobachtet
Bestandsgeschützt
Beobachtet
Bestandsgeschützt
C.6 Präsentation
Abschnitt 7.1 Barrierefreie Darstellung
Verbindlich
Empfohlen
- BITV
Abschnitt 7.2 Zeichensätze und -kodierungen
Verbindlich
- Unicode ≥2.1
- UTF-8
Empfohlen
- ISO 8859-1
- ISO 8859-15
- UTF-16
83
Abschnitt 7.3 Technologien zur Informationsaufbereitung
Verbindlich
Empfohlen
- MIME 1.0
- XHTML 1.0
- HTML 4.01
- CSS2
- XSL 1.1
- XSLT 1.0 / 2.0
- XQuery
Beobachtet
Bestandsgeschützt
- HTML 3.2
- XSL 1.0
Abschnitt 7.4 Spezifikationen für aktive Inhalte
Verbindlich
Empfohlen
Beobachtet
rd
Bestandsgeschützt
- ECMAScript, 5th Ed.
- ECMAScript, 3 Ed.
Abschnitt 7.5 Formulare
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- XForms 1.1
- XForms 1.0
Empfohlen
Beobachtet
Bestandsgeschützt
- XML 1.0
- EML 5.0
Abschnitt 7.6 Austauschformate für Daten
Verbindlich
Abschnitt 7.7.1 Formate für Textdokumente zum Informationsaustausch
Verbindlich
Empfohlen
- PDF ≥1.4
- Text
Beobachtet
Bestandsgeschützt
- PDF 1.3
Abschnitt 7.7.2 Formate für Textdokumente zur Weiterbearbeitung
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- Text
- ODF 1.1
- OOXML Transitional
- OOXML Strict
- DocBook 4.5
- ODF 1.0
- MS Office File
Formats
- XML 1.0
Abschnitt 7.7.3 Formate für Tabellen zum Informationsaustausch
Verbindlich
Empfohlen
- PDF ≥1.4
- CSV
- HTML 4.01
- XHTML 1.0
Beobachtet
Bestandsgeschützt
- PDF 1.3
84
Abschnitt 7.7.4 Formate für Tabellen zur Weiterbearbeitung
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- CSV
- ODF 1.1
- ODF 1.0
- OOXML Transitional - MS Office File
- OOXML Strict
Formats
- XML 1.0
Abschnitt 7.7.5 Formate für Präsentationen zum Informationsaustausch
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- PDF ≥1.4
- HTML 4.01
- XHTML 1.0
- SMIL 3.0
- PDF 1.3
- SMIL 2.0
Abschnitt 7.7.6 Formate für Präsentationen zur Weiterbearbeitung
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- ODF 1.1
- ODF 1.0
- OOXML Transitional - MS Office File
- OOXML Strict
Formats
- XML 1.0
Abschnitt 7.7.7 Gesicherter Dokumentenaustausch
Verbindlich
Empfohlen
Beobachtet
- Common PKI 2.0
- XadES ≥1.3.2
- XML Encryption
- XML Signature
Bestandsgeschützt
- Common PKI 1.1
- ISIS-MTT 1.0
- MTT v2
- XadES 1.2
Abschnitt 7.8 Austauschformate für Bilder
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- JPEG
- PNG 1.2
- GeoTIFF 1.8.2
- GIF v89a
- TIFF 6.0
- SVG 1.1
- JPEG 2000
- ECW
Empfohlen
Beobachtet
Bestandsgeschützt
- GIF v89a
- SVG 1.1
Abschnitt 7.9 Animation
Verbindlich
Abschnitt 7.10.1 Austauschformate für Audiodateien
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- Ogg
- MP4
- RealMedia
- ASF 1.2
- mp3
85
Abschnitt 7.10.2 Austauschformate für Audio-Streaming
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- HTTP 1.1
- RTSP
- Ogg
- MP4
- RealMedia
- ASF 1.2
- HTTP 1.0
Abschnitt 7.10.3 Austauschformate für Videodateien
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- Ogg
- MP4
- ASF 1.2
- QTFF
- RealMedia
Abschnitt 7.10.4 Austauschformate für Video-Streaming
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- HTTP 1.1
- MP4
- Ogg
- RTSP
- ASF 1.2
- HTTP 1.0
- QTFF
- RealMedia
Beobachtet
Bestandsgeschützt
Abschnitt 7.11 3D-Daten
Verbindlich
Empfohlen
- X3D Ed. 2
- U3D, 4th Ed.
Abschnitt 7.12 Austauschformate für Geoinformationen
Verbindlich
Empfohlen
- GML 3.2.x
- CityGML 1.0.0
- GeoTIFF 1.8.2
- KML 2.2.0
Beobachtet
Bestandsgeschützt
- GML 3.1.1
- GML 3.0
- GML 2.1.2
- GML 2.0
Abschnitt 7.13 Datenkompression
Verbindlich
Empfohlen
Beobachtet
- ZIP 4.5
- Gnu ZIP 4.3 / TAR
Bestandsgeschützt
- ZIP 2.0
Abschnitt 7.14 Technologien für die Präsentation auf mobilen Endgeräten
Verbindlich
- SMS
Empfohlen
Beobachtet
Bestandsgeschützt
- XHTML Basic 1.1
- WAP 2.0
- XHTML Basic 1.0
- WAP 1.x
- WML 1.x
86
C.7 Kommunikation
Abschnitt 8.1.1 Kommunikation zwischen Applikationen innerhalb der Verwaltung
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- WS-Security 1.1
- SOAP 1.1
- MTOM
- JMS 1.1
- HTTP 1.1
- Java Portlet
Specification ≥1.0
- WSRP ≥1.0
- SOAP 1.2
- WS-Security 1.0
- SwA
- JCA 1.5
- CORBA
- JAV2I 1.0
- HTTP 1.0
Abschnitt 8.1.2 Kommunikation mit verwaltungsexternen Applikationen
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- WS-Security 1.1
- SOAP 1.1
- MTOM
- HTTP 1.1
- SOAP 1.2
- WS-Security 1.0
- SwA
- CORBA
- HTTP 1.0
Beobachtet
Bestandsgeschützt
Abschnitt 8.2 Netzwerkprotokolle
Verbindlich
Empfohlen
- IPv4/IPv6
- DNS
Abschnitt 8.3 E-Mail-Kommunikation
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- MIME 1.0
- SMTP
- Common PKI 2.0
- IMAP4rev1
- POP3
- DKIM
- Sender ID
- SPF 1.0
- Common PKI 1.1
- ISIS-MTT 1.0
- MTTv2
Beobachtet
Bestandsgeschützt
Empfohlen
Beobachtet
Bestandsgeschützt
- FTP
- HTTP 1.1
- OSCI-Transport 1.2
- SSH-2
- TLS 1.0 / 1.2
- WebDAV
- OSCI-Transport 2.0
- SPMLv2
- XMPP
- FTAM
- HTTP 1.0
- SSL 3.0
- SPML 1.0
Abschnitt 8.4 IP-Telefonie
Verbindlich
Empfohlen
- H.323
- SIP 2.0
Abschnitt 8.5 Anwendungsprotokolle
Verbindlich
87
Abschnitt 8.6 Geodienste
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- Catalogue Services
Specification 2.0.2
- WMS 1.3.0
- WCS ≥1.1
- WFS 2.0
- SFA-2 1.1.0
- SFA-2 1.2.1
- WMTS 1.0.0
- WFS 1.1
- WFS 1.0
- WCS 1.0
- WMS-DE 1.0
Empfohlen
Beobachtet
Bestandsgeschützt
- LDAPv3
- DSML v2.0
- UDDI v2.0
C.8 Backend
Abschnitt 9.1 Zugriff auf Verzeichnisdienste
Verbindlich
Abschnitt 9.2 Zugriff auf Datenbanken und Registrys
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- JDBC 4.0
- JCR 2.0
- CMIS 1.0
- ebXML RS 3.0 /
ebXML RIM 3.0
- JDBC 3.0
- JDBC 2.0
Abschnitt 9.3 Zugriff auf Bestandssysteme
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- WS-Security 1.1
- JCA 1.6
- JMS 1.1
- SOAP 1.1
- SOAP 1.2
- UN/EDIFACT
- JCA 1.5
- JAV2I 1.0
C.9 Verschlüsselung
Abschnitt 10.1 Asymmetrische Verschlüsselungsverfahren
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- RSA
Abschnitt 10.2 Symmetrische Verschlüsselungsverfahren
Verbindlich
- AES
Empfohlen
Beobachtet
Bestandsgeschützt
- IDEA
- Triple-DES
- Chiasmus
88
C.10 Elektronische Signatur
Abschnitt 11 Elektronische Signatur
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
Beobachtet
Bestandsgeschützt
- Algorithmenkatalog
der BNetzA
Abschnitt 11.1 Hashen von Daten
Verbindlich
Empfohlen
- SHA-2
- SHA-1
- RIPEMD-160
Abschnitt 11.2 Asymmetrische Signaturverfahren
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
Beobachtet
Bestandsgeschützt
Beobachtet
Bestandsgeschützt
Beobachtet
Bestandsgeschützt
- RSA
- DSA
Abschnitt 11.3 Key Management
Verbindlich
Empfohlen
- XKMS 2.0
C.11 Smartcards
Abschnitt 12.1 Kontaktbehaftete Smartcards
Verbindlich
Empfohlen
- Identification Cards –
Integrated circuit cards
Abschnitt 12.2 Kontaktlose Smartcards
Verbindlich
Empfohlen
- Identification Cards –
Contactless integrated
circuit cards
Abschnitt 12.3 Lesegeräte und Schnittstellen für Smartcards
Verbindlich
Empfohlen
- BSI TR-03112 ≥1.1
- BSI TR-03116 ≥3.0
- PC/SC 2.x
- SICCT 1.20
- Common PKI 2.0
Beobachtet
Bestandsgeschützt
- BSI TR-03112 1.0
- BSI TR-03116 1.0
- SICCT 1.10
- Common PKI 1.1
89
C.12 Langzeitspeicherung
Abschnitt 13 Langzeitspeicherung
Verbindlich
Empfohlen
Beobachtet
Bestandsgeschützt
- BSI TR-03125 ≥1.1
- PDF/A-1
- JPEG
- TIFF 6.0
- XML 1.0
- JPEG 2000
- ArchiSig
D Alphabetische Übersicht klassifizierter Spezifikationen
D
90
Alphabetische Übersicht
klassifizierter Spezifikationen
Advanced Encryption Standard (AES).................................................................................................69
Advanced Systems Format (ASF) 1.2......................................................................................46, 48, 49
AES .......................................................................................................................................................69
ArchiSig, Grundsätze für die beweiskräftige und sichere Langzeitarchivierung digital signierter Do
kumente.................................................................................................................................................75
ASF 1.2.....................................................................................................................................46, 48, 49
Barrierefreie Informationstechnik Verordnung (BITV).......................................................................30
BITV......................................................................................................................................................30
BPMN 1.0 ............................................................................................................................................14
BPMN 1.1/1.2.......................................................................................................................................13
BPMN 2.0..............................................................................................................................................14
BSI – Technische Richtlinie „Beweiswerterhaltung kryptographisch signierter Dokumente“ (BSI
TR-03125) ≥1.1.....................................................................................................................................74
BSI – Technische Richtlinie „eCard-API-Framework“ (BSI TR-03112) 1.0......................................74
BSI – Technische Richtlinie „eCard-API-Framework“ (BSI TR-03112) ≥1.1....................................73
BSI – Technische Richtlinie für die eCard-Projekte der Bundesregierung (BSI TR-03116) ≥3.0......73
BSI – Technische Richtlinie für die eCard-Projekte der Bundesregierung (BSI TR-03116) 1.0........74
BSI TR-03112 1.0.................................................................................................................................74
BSI TR-03116 >3.0...............................................................................................................................73
BSI TR-30116 1.0.................................................................................................................................74
BSI TR-03125 >1.1...............................................................................................................................74
BSI TR-03112 >1.1...............................................................................................................................73
BSI-Standard 100-1 > 1.5.....................................................................................................................10
BSI-Standard 100-1 1.0.........................................................................................................................11
BSI-Standard 100-1: Managementsysteme für Informationssicherheit ≥1.5.......................................10
BSI-Standard 100-1: Managementsysteme für Informationssicherheit 1.0.........................................11
BSI-Standard 100-2 > 2.0.....................................................................................................................11
BSI-Standard 100-2 1.0.........................................................................................................................11
BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise ≥2.0...............................................................11
BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise 1.0..................................................................11
91
BSI-Standard 100-3 > 2.5 ....................................................................................................................11
BSI Standard 100-3 2.0.........................................................................................................................12
BSI-Standard 100-3: Risikoanalyse auf der Basis von IT-Grundschutz ≥2.5......................................11
BSI-Standard 100-3: Risikoanalyse auf der Basis von IT-Grundschutz 2.0........................................12
BSI-Standard 100-4 > 1.0.....................................................................................................................12
BSI-Standard 100-4: Notfallmanagement ≥1.0....................................................................................12
BSI, E-Government-Handbuch.............................................................................................................12
BSI, E-Government-Handbuch, Modul „Authentisierung im E-Government“...................................30
BSI, IT-Grundschutz-Kataloge.............................................................................................................12
Business Process Modeling Notation (BPMN) 1.0..............................................................................14
3.1Business Process Modeling Notation (BPMN) 1.1 / 1.2.................................................................13
Business Process Modeling Notation (BPMN) 2.0..............................................................................14
5.2C++.......................................................................................................................................................
21
Cascading Style Sheets, Level 2 (CSS2)..............................................................................................33
Catalogue Services Specification 2.0.2 – ISO Metadata Application Profile 1.0................................63
Chiasmus...............................................................................................................................................70
City Geography Markup Language (CityGML) 1.0.0..........................................................................50
CityGML 1.0.0......................................................................................................................................50
Common Language Infrastructure (CLI)........................................................................................19, 22
CMIS 1.0...............................................................................................................................................66
Comma-Separated Values (CSV)..........................................................................................................39
Common ISIS-MTT Specifications for Interoperable PKI Applications (Common PKI) 1.1, Teil 3.....
.......................................................................................................................................................43
Common ISIS-MTT Specifications for Interoperable PKI Applications (Common PKI) 1.1, Teil 7.....
.......................................................................................................................................................74
Common ISIS-MTT Specifications for Interoperable PKI Applications (Common PKI) 1.1, Teile 1
bis 6 .......................................................................................................................................................59
Common Language Infrastructure (CLI)........................................................................................19, 22
Common Object Request Broker Architecture (CORBA).............................................................56, 57
Common PKI 1.1, Teil 3.......................................................................................................................42
Common PKI 1.1, Teil 7.......................................................................................................................74
Common PKI 1.1, Teile 1 bis 6............................................................................................................59
Common PKI 2.0..................................................................................................................................42
92
CORBA...........................................................................................................................................56, 57
CSS2......................................................................................................................................................33
CSV.......................................................................................................................................................39
DCES.....................................................................................................................................................18
Digital Signature Algorithm (DSA)......................................................................................................71
DIN 66001.............................................................................................................................................13
Directory Services Markup Language (DSML) v2.0...........................................................................65
DKIM....................................................................................................................................................59
DNS.......................................................................................................................................................58
DocBook 4.5.........................................................................................................................................38
Document Type Definition (DTD)........................................................................................................17
Domain Name System (DNS)...............................................................................................................58
DomainKeys Identified Mail (DKIM)..................................................................................................59
DSA.......................................................................................................................................................71
DSML v2.0............................................................................................................................................65
DTD.......................................................................................................................................................17
4.4Dublin Core Metadata Element Set (DCES)...................................................................................18
ebXML Registry Information Model (ebXML RIM) 3.0.....................................................................66
ebXML Registry Services and Protocols (ebXML RS) 3.0..................................................................66
ebXML RIM 3.0 ...................................................................................................................................66
ebXML RS 3.0......................................................................................................................................66
ECMA-262............................................................................................................................................34
ECMAScript Language Specification, 3rd Edition..............................................................................34
ECMAScript Language Specification, 5th Edition..............................................................................34
ECW......................................................................................................................................................45
Election Markup Language (EML) 5.0.................................................................................................35
EML 5.0.................................................................................................................................................35
Enhanced Compressed Wavelet (ECW)...............................................................................................45
Entity-Relationship-Diagramme (ERD)...............................................................................................16
EPC Markup Language (EPML) 1.2....................................................................................................15
EPK .......................................................................................................................................................14
EPML 1.2..............................................................................................................................................15
ERD.......................................................................................................................................................16
93
3.1Ereignisgesteuerte Prozesskette (EPK)............................................................................................14
eXtensible 3D (X3D), Edition 2...........................................................................................................49
Extensible Access Control Markup Language (XACML) 2.0 ............................................................29
Extensible Hypertext Markup Language (XHTML) 1.0..........................................................32, 39, 40
Extensible Hypertext Markup Language (XHTML) Basic 1.0............................................................53
Extensible Hypertext Markup Language (XHTML) Basic 1.1............................................................53
Extensible Markup Language (XML) 1.0......................................................................................40, 75
eXtensible Markup Language (XML) 1.0................................................................................40, 40, 41
Extensible Messaging and Presence Protocol (XMPP)........................................................................62
Extensible Stylesheet Language (XSL) 1.0..........................................................................................34
Extensible Stylesheet Language (XSL) 1.1..........................................................................................33
Extensible Stylesheet Language Transformations (XSLT) 1.0 / 2.0....................................................33
File Transfer and Access Management (FTAM)...................................................................................62
File Transfer Protocol (FTP).................................................................................................................60
Flussdiagramme....................................................................................................................................13
FTAM....................................................................................................................................................62
FTP .......................................................................................................................................................60
Geo Tagged Image File Format (GeoTIFF) 1.8.2...........................................................................44, 50
Geography Markup Language (GML) 2.0............................................................................................51
Geography Markup Language (GML) 2.1.2.........................................................................................51
Geography Markup Language (GML) 3.0............................................................................................51
Geography Markup Language (GML) 3.1.1.........................................................................................51
Geography Markup Language (GML) 3.2.x.........................................................................................50
GeoTIFF 1.8.2.................................................................................................................................44, 50
GIF v89a................................................................................................................................................44
GML 2.0................................................................................................................................................51
GML 2.1.2.............................................................................................................................................51
GML 3.0................................................................................................................................................51
GML 3.1.1.............................................................................................................................................51
GML 3.2.x.............................................................................................................................................50
7.13Gnu ZIP (GZIP) 4.3 / Tape ARchive (TAR)..................................................................................52
Graphics Interchange Format (GIF) v89a.......................................................................................44, 45
GZIP......................................................................................................................................................52
94
H.323.....................................................................................................................................................60
HTML 3.2..............................................................................................................................................34
HTML 4.01................................................................................................................................33, 39, 40
HTTP 1.0.......................................................................................................................48, 49, 56, 57, 62
HTTP 1.1.......................................................................................................................47, 49, 55, 57, 60
HTTPS...................................................................................................................................................60
Hypertext Markup Language (HTML) 4.01.............................................................................33, 39, 40
Hypertext Markup Language (HTML) 3.2...........................................................................................34
Hypertext Transfer Protocol (HTTP) 1.1......................................................................47, 49, 55, 57, 60
Hypertext Transfer Protocol (HTTP) 1.0......................................................................48, 49, 56, 57, 62
ID-FF 1.2...............................................................................................................................................30
ID-SIS 1.0..............................................................................................................................................30
ID-WSF 1.1...........................................................................................................................................30
ID-WSF 2.0...........................................................................................................................................29
IDEA.....................................................................................................................................................69
Identification Cards – Contactless integrated circuit cards..................................................................73
12.1Identification Cards – Integrated circuit cards..............................................................................72
Identity Web Services Framework (ID-WSF) 1.1................................................................................30
IMAP4rev1............................................................................................................................................58
Industrial Signature Interoperability Specification (ISIS)-MTT 1.0..............................................43, 59
International Data Encryption Algorithm (IDEA)................................................................................69
Internet Message Access Protocol, Version 4rev1 (IMAP4rev1).........................................................58
Internet Protocol Version 4 (IPv4)........................................................................................................57
Internet Protocol Version 6 (IPv6)........................................................................................................57
Interoperability Specification for ICCs and Personal Computer Systems (PC/SC) 2.x......................73
IPv4 .......................................................................................................................................................57
IPv6 .......................................................................................................................................................57
ISIS-MTT 1.0..................................................................................................................................43, 59
ISO 14443.......................................................................................................................................73, 73
ISO 15836.............................................................................................................................................18
ISO 19005-1..........................................................................................................................................75
ISO 19125-2..........................................................................................................................................64
ISO 19128:2005....................................................................................................................................63
95
ISO 19136:2007....................................................................................................................................50
ISO 23600:2006....................................................................................................................................38
ISO 32000.............................................................................................................................................36
ISO 7816...............................................................................................................................................72
ISO 8571...............................................................................................................................................62
ISO 8859-1............................................................................................................................................31
ISO 8859-15..........................................................................................................................................32
ISO/IEC 10646......................................................................................................................................31
ISO/IEC 10918-1............................................................................................................................43, 75
ISO/IEC 14496......................................................................................................................................46
ISO/IEC 15444-1..................................................................................................................................45
ISO/IEC 19503:2005.............................................................................................................................15
ISO/IEC 19757-2:2003.........................................................................................................................17
ISO/IEC 19775-1:2008.........................................................................................................................49
ISO/IEC 29361......................................................................................................................................23
ISO/IEC 29500 Strict................................................................................................................37, 39, 41
ISO/IEC 29500 Transitional.....................................................................................................37, 39, 41
J2EE 1.3................................................................................................................................................20
J2EE 1.4................................................................................................................................................20
J2EE Connector Architecture (JCA) 1.5.........................................................................................56, 68
J2SE 1.3.................................................................................................................................................23
J2SE 1.4.................................................................................................................................................22
J2SE 5.0...........................................................................................................................................22, 27
JAV2I 1.0.........................................................................................................................................56, 68
Java 2 Platform, Enterprise Edition (J2EE) 1.3....................................................................................20
Java 2 Platform, Enterprise Edition (J2EE) 1.4....................................................................................20
Java 2 Platform, Standard Edition (J2SE) 1.3......................................................................................22
Java 2 Platform, Standard Edition (J2SE) 1.4......................................................................................22
Java 2 Platform, Standard Edition (J2SE) 5.0................................................................................22, 27
Java Content Repository (JCR) 2.0.......................................................................................................66
Java Database Connectivity (JDBC) 2.0...............................................................................................67
96
Java EE 5...............................................................................................................................................20
Java EE 6...............................................................................................................................................19
Java EE Connector Architecture (JCA) 1.6..........................................................................................67
Java ME.................................................................................................................................................27
Java Message Service (JMS) 1.1....................................................................................................54, 68
Java Network Launching Protocol (JNLP) 1.5.....................................................................................27
Java Network Launching Protocol (JNLP) 6.x.....................................................................................27
Java Platform, Enterprise Edition (Java EE) 5.....................................................................................20
Java Platform, Enterprise Edition (Java EE) 6.....................................................................................19
Java Platform, Standard Edition (Java SE) 6..................................................................................20, 26
Java Plattform, Micro Edition (Java ME) / Mobile Information Device Profile (MIDP) 2.0.............27
Java Portlet Specification ≥1.0.............................................................................................................55
Java SE 6.........................................................................................................................................20, 26
8.1.1Java to IDL Language Mapping (JAV2I) 1.0.........................................................................56, 68
JCA 1.5............................................................................................................................................56, 68
JCA 1.6..................................................................................................................................................67
JCA 2.0..................................................................................................................................................66
JDBC 2.0...............................................................................................................................................67
JDBC 3.0...............................................................................................................................................67
JDBC 4.0...............................................................................................................................................66
JMS 1.1...........................................................................................................................................54, 68
JNLP 1.5................................................................................................................................................27
JNLP 6.x................................................................................................................................................27
Joint Photographic Experts Group (JPEG) ....................................................................................43, 75
Joint Photographic Experts Group 2000 (JPEG 2000) / Part 1......................................................44, 75
JPEG................................................................................................................................................43, 75
JPEG 2000.......................................................................................................................................44, 75
JSR 168.................................................................................................................................................54
JSR 170.................................................................................................................................................66
JSR 221.................................................................................................................................................66
JSR 283.................................................................................................................................................66
JSR 286.................................................................................................................................................55
JSR 322.................................................................................................................................................68
97
JSR 914.................................................................................................................................................54
Kerberos 5.............................................................................................................................................29
Keyhole Markup Language (KML) 2.2.0.............................................................................................51
KML 2.2.0.............................................................................................................................................51
KoopA ADV, Handlungsleitfaden für die Einführung der elektronischen Signatur und Verschlüsse
lung in der Verwaltung 1.1....................................................................................................................12
Kryptoalgorithmen nach Bundesnetzagentur für die elektronische Signatur ......................................70
LDAPv3................................................................................................................................................65
Liberty Identity Federation Framework (ID-FF) 1.2............................................................................30
Liberty Identity Services Interface Specification (ID-SIS) 1.0............................................................30
Liberty Identity Web Services Framework (ID-WSF) 2.0...................................................................29
9.1Lightweight Directory Access Protocol, Version 3 (LDAPv3).......................................................65
MailTrusT (MTT) Version 2...........................................................................................................43, 59
Message Transmission Optimization Mechanism (MTOM)..........................................................54, 56
Microsoft Office File Formats.................................................................................................38, 40, 41
MIDP 2.0...............................................................................................................................................27
MIME 1.0..............................................................................................................................................32
Mobile Information Device Profile (MIDP) 2.0...................................................................................27
MP3 .......................................................................................................................................................47
MP4 .....................................................................................................................................46, 47, 48, 49
MPEG-1 Layer 3 (MP3).......................................................................................................................47
MPEG-4 Part 14 (MP4)......................................................................................................46, 47, 48, 49
MTOM............................................................................................................................................54, 56
MTT Version 2................................................................................................................................43, 59
Multipurpose Internet Mail Extensions (MIME) 1.0 ....................................................................32, 58
Office Open XML (OOXML) / ISO/IEC 29500 Strict............................................................37, 39, 41
Office Open XML (OOXML) / ISO/IEC 29500 Transitional..................................................37, 39, 41
OGC-CSW............................................................................................................................................63
Ogg .....................................................................................................................................46, 47, 48, 49
Ogg Encapsulation Format (Ogg).......................................................................................46, 47, 48, 49
8.5Online Service Computer Interface (OSCI)-Transport 1.2.............................................................61
Online Service Computer Interface (OSCI)-Transport 2.0...................................................................61
OOXML Strict .........................................................................................................................37, 39, 41
98
OOXML Transitional................................................................................................................37, 39, 41
Open Document Format for Office Applications (OpenDocument) 1.0..................................38, 40, 41
Open Document Format for Office Applications (OpenDocument) 1.1..................................37, 39, 41
Open-ID 2.0...........................................................................................................................................29
OpenDocument 1.0...................................................................................................................38, 40, 41
OpenDocument 1.1...................................................................................................................37, 39, 41
OSCI-Transport 1.2...............................................................................................................................61
OSCI-Transport 2.0...............................................................................................................................61
PC/SC 2.x..............................................................................................................................................73
PDF >1.4...................................................................................................................................36, 38, 40
PDF 1.3.....................................................................................................................................36, 39, 41
PDF/A-1................................................................................................................................................74
PDF/Archive 1 (PDF/A-1)....................................................................................................................74
Perl .......................................................................................................................................................22
PHP 4.x..................................................................................................................................................22
PHP 5.x..................................................................................................................................................21
PHP: Hypertext Preprocessor (PHP) 4.x..............................................................................................22
PHP: Hypertext Preprocessor (PHP) 5.x..............................................................................................21
PNG 1.2.................................................................................................................................................43
POP3......................................................................................................................................................58
Portable Document Format (PDF) ≥1.4....................................................................................36, 38, 40
Portable Document Format (PDF) 1.3......................................................................................36, 39, 41
Portable Network Graphics (PNG) 1.2.................................................................................................43
Post Office Protocol, Version 3 (POP3)................................................................................................58
Python....................................................................................................................................................21
QTFF...............................................................................................................................................48, 49
QuickTime File Format (QTFF).....................................................................................................48, 49
RDF.......................................................................................................................................................18
Real Time Streaming Protocol (RTSP)...........................................................................................47, 49
RealMedia (RM).................................................................................................................46, 47, 48, 49
Regular Language Description for XML New Generation (Relax NG)..............................................17
Relax NG...............................................................................................................................................17
Resource Description Framework (RDF).............................................................................................18
99
RFC 791................................................................................................................................................57
RFC 1034 und RFC 1035......................................................................................................................58
RFC 1939..............................................................................................................................................58
RFC 2045..............................................................................................................................................32
RFC 2246..............................................................................................................................................61
RFC 2326..............................................................................................................................................47
RFC 2460..............................................................................................................................................57
RFC 2616..............................................................................................................................................60
8.4RFC 3261.........................................................................................................................................60
RFC 3501..............................................................................................................................................58
RFC 3629..............................................................................................................................................31
RFC 3920 - RFC 3923..........................................................................................................................62
RFC 4120..............................................................................................................................................29
RFC 4180..............................................................................................................................................39
RFC 4250-4256.....................................................................................................................................61
RFC 4406 .............................................................................................................................................59
RFC 4408..............................................................................................................................................59
RFC 4510..............................................................................................................................................65
RFC 4871..............................................................................................................................................59
RFC 4918..............................................................................................................................................61
4.4RFC 5013.........................................................................................................................................18
RFC 5246..............................................................................................................................................61
RFC 5321..............................................................................................................................................58
RIPEMD-160........................................................................................................................................71
RM .....................................................................................................................................46, 47, 48, 49
RSA.................................................................................................................................................69, 71
RTSP................................................................................................................................................47, 49
Ruby......................................................................................................................................................21
SAML >1.0............................................................................................................................................29
SCA 1.0.................................................................................................................................................24
Scalable Vector Graphics (SVG) 1.1..............................................................................................44, 45
Secure Hash Algorithm (SHA-1)..........................................................................................................71
Secure Hash Algorithm (SHA-2)..........................................................................................................70
100
Secure Interoperable ChipCard Terminal (SICCT) 1.10......................................................................74
Secure Interoperable ChipCard Terminal (SICCT) 1.20......................................................................73
Secure Shell, Version 2 (SSH-2)...........................................................................................................61
Secure Sockets Layer (SSL) 3.0...........................................................................................................62
Security Assertion Markup Language (SAML) ≥1.0...........................................................................29
Sender ID...............................................................................................................................................59
Sender Policy Framework (SPF) 1.0....................................................................................................59
Service Component Architecture (SCA) 1.0........................................................................................24
Service Provisioning Markup Language (SPML) v1.0........................................................................62
Service Provisioning Markup Language (SPML) v2...........................................................................62
Session Initiation Protocol (SIP) 2.0.....................................................................................................60
SFA-2 1.1.0...........................................................................................................................................64
SFA-2 1.2.0...........................................................................................................................................64
SHA-1....................................................................................................................................................71
SHA-2....................................................................................................................................................70
Short Message Services (SMS).............................................................................................................52
SICCT 1.10............................................................................................................................................74
SICCT 1.20............................................................................................................................................73
Simple Feature Access – Part 2: SQL Option (SFA-2) 1.1.0................................................................64
Simple Feature Access – Part 2: SQL Option (SFA-2) 1.2.1................................................................64
Simple Mail Transfer Protocol (SMTP)................................................................................................58
Simple Object Access Protocol (SOAP) 1.1...................................................................................54, 56
Simple Object Access Protocol (SOAP) 1.2...................................................................................55, 57
SIP 2.0...................................................................................................................................................60
SMIL 2.0 ..............................................................................................................................................41
SMIL 3.0...............................................................................................................................................40
SMS.......................................................................................................................................................52
SMTP....................................................................................................................................................58
SOAP 1.1.........................................................................................................................................54, 56
SOAP 1.2.........................................................................................................................................55, 57
SOAP Messages with Attachments (SwA).....................................................................................56, 57
SPF 1.0..................................................................................................................................................59
SPML v1.0.............................................................................................................................................62
101
SPML v2................................................................................................................................................62
SSH-2....................................................................................................................................................61
SSL 3.0..................................................................................................................................................62
SVG 1.1...........................................................................................................................................44, 45
SwA.................................................................................................................................................56, 57
Synchronized Multimedia Integration Language (SMIL) 2.0..............................................................41
Synchronized Multimedia Integration Language (SMIL) 3.0..............................................................40
Tagged Image File Format (TIFF) 6.0............................................................................................44, 75
TAR .......................................................................................................................................................52
Text .................................................................................................................................................36, 36
TIFF 6.0...........................................................................................................................................44, 75
TLS 1.0 / 1.2..........................................................................................................................................61
Transport Layer Security (TLS) 1.0 / 1.2.............................................................................................61
Triple Data Encryption Standard (Triple-DES)....................................................................................69
Triple-DES............................................................................................................................................69
U3D 4th Edition.....................................................................................................................................50
UDDI v2.0.............................................................................................................................................65
UML < 1.5.......................................................................................................................................15, 16
UML 2.x..........................................................................................................................................13, 16
UN/EDIFACT.......................................................................................................................................68
Unicode >2.1.........................................................................................................................................31
Unified Modeling Language (UML) ≤1.5......................................................................................15, 16
Unified Modeling Language (UML) 2.x........................................................................................13, 16
Universal 3D (U3D) 4th Edition...........................................................................................................50
Universal Description, Discovery and Integration (UDDI) v2.0.........................................................65
UTF-16..................................................................................................................................................32
UTF-8....................................................................................................................................................31
WAP 1.x.................................................................................................................................................53
WAP 2.0.................................................................................................................................................53
WCS >1.1..............................................................................................................................................63
WCS 1.0................................................................................................................................................65
Web Coverage Service (WCS) ≥1.1.....................................................................................................63
Web Coverage Service (WCS) 1.0........................................................................................................65
102
Web Feature Service (WFS) 1.0...........................................................................................................64
Web Map Service (WMS) 1.3.0............................................................................................................63
Web Map Service Deutschland (WMS-DE) 1.0...................................................................................65
Web Map Tile Service (WMTS) 1.0.0..................................................................................................64
Web Services (WS)-Security 1.0....................................................................................................56, 57
Web Services Business Process Execution Language (WS-BPEL) 2.0...............................................23
Web Services Description Language (WSDL) 1.1...............................................................................23
Web Services Description Language (WSDL) 2.0...............................................................................23
Web Services for Remote Portlets (WSRP) ≥1.0.................................................................................55
Web Services Security (WS-Security) 1.1................................................................................54, 56, 67
WebDAV...............................................................................................................................................61
WFS 1.0.................................................................................................................................................64
WFS 1.1.................................................................................................................................................64
WFS 2.0.................................................................................................................................................64
Wireless Application Protocol (WAP) 1.x............................................................................................53
Wireless Application Protocol (WAP) 2.0............................................................................................53
Wireless Markup Language (WML) 1.x...............................................................................................53
WML 1.x...............................................................................................................................................53
WMS 1.3.0............................................................................................................................................63
WMS-DE...............................................................................................................................................65
WMTS 1.0.0..........................................................................................................................................64
WS-BPEL 2.0........................................................................................................................................23
WS-Federation 1.1................................................................................................................................28
WS-I Basic Profile 1.1 / 1.2..................................................................................................................23
WS-I Basic Profile 2.0..........................................................................................................................23
WS-Security 1.0..............................................................................................................................56, 57
WS-Security 1.1........................................................................................................................54, 56, 67
WS-Trust 1.3.........................................................................................................................................28
WDSL 1.1..............................................................................................................................................23
WDSL 2.0..............................................................................................................................................23
WSRP > 1.0...........................................................................................................................................55
103
WWW Distributed Authoring and Versioning (WebDAV)...................................................................61
X3D Ed. 2..............................................................................................................................................49
XACML 2.0...........................................................................................................................................29
XAdES > 1.3.2......................................................................................................................................42
XAdES 1.2............................................................................................................................................43
XForms 1.0............................................................................................................................................35
XForms 1.1............................................................................................................................................35
XHTML 1.0...............................................................................................................................32, 39, 40
XHTML Basic 1.0.................................................................................................................................53
XHTML Basic 1.1.................................................................................................................................53
XKMS 2.0.............................................................................................................................................72
XMI 1.x...........................................................................................................................................15, 17
XMI 2.x...........................................................................................................................................15, 17
XML 1.0..............................................................................................................................15, 35, 38, 75
XML Advanced Electronic Signatures (XAdES) ≥1.3.2......................................................................42
XML Advanced Electronic Signatures (XAdES) 1.2...........................................................................43
XML Encryption ..................................................................................................................................42
XML Key Management Specification (XKMS) 2.0.............................................................................72
XML Metadata Interchange (XMI) 1.x..........................................................................................15, 17
XML Metadata Interchange (XMI) 2.x..........................................................................................15, 17
XML Process Definition Language (XPDL) 2.1..................................................................................15
XML Query Language (XQuery) 1.0...................................................................................................34
XML Schema Definition Language (XSD) 1.0....................................................................................17
XML Signature .....................................................................................................................................42
XMPP....................................................................................................................................................62
XPDL 2.1...............................................................................................................................................15
XQuery 1.0............................................................................................................................................34
XSD 1.0.................................................................................................................................................17
XSL 1.0.................................................................................................................................................34
XSL 1.1.................................................................................................................................................33
XSLT 1.0 / 2.0.......................................................................................................................................33
ZIP 2.0 ..................................................................................................................................................52
ZIP 4.5...................................................................................................................................................51

SAGA-Modul Technische Spezifikationen - IT

Transcription

Similar documents

Bildnachweis

Liebe Leserin, lieber Leser

Schule und was dann? - Ab in Deine Zukunft

Maja Storch Advent Matura - Kaufmännischer Verband Schweiz

social media kompass 2012/2013

Migrationsleitfaden 4.0 - IT-Beauftragter der Bundesregierung

Saphir ISDN-Adapterfamilie

Prof. Jochum - Bezirksregierung Köln