IT-Rat Beschluss Nr. 2017/2
Beschluss IT-Rat vom 19. Januar 2017
Projekt IT-Konsolidierung Bund:
Architekturrichtlinie für die IT des Bundes (Version 2016)
1. Mit dem Maßgabebeschluss des Haushaltsausschusses vom 17.06.2015 (ADrs. 18(8)2134) Abs. II Ziff. 4 ist die Bundesregierung aufgefordert, „sicherzustellen, dass bei der laufenden technischen Weiterentwicklung der IT- Infrastruktur in der Bundesverwaltung und der Neuvergabe von Aufträgen keine Entscheidungen getroffen werden, die einer geplanten späteren Konsolidierung im Wege stehen. Die Gesamtprojektleitung soll dazu, so bald wie möglich, entsprechende Architektur-Richtlinien erarbeiten. Für alle Bereiche, die von der Konsolidierung betroffen sein werden, sind diese Richtlinien verbindlich. Die Ressorts sind bei der Erarbeitung der Richtlinien zu konsultieren. Über Ausnahmen entscheidet der IT-Rat.“
2. Die entsprechend der Aufforderung des Haushaltsausschusses von der Gesamtprojektleitung des Vorhabens „IT-Konsolidierung Bund“ erarbeitete Architekturrichtlinie für die IT des Bundes wurde in Anlehnung an die Rahmenarchitektur IT-Steuerung Bund in folgende Bereiche untergliedert:
• Übergreifende Architekturvorgaben
• Geschäftliche Architekturvorgaben
• Architekturvorgaben für Dienste/Anwendungen
• Architekturvorgaben für Informationen/Daten
• Technische Architekturvorgaben
• Architekturvorgaben zu Informationssicherheit/Datenschutz/Geheimschutz
Beschluss IT-Rat 2017/1 1 19. Januar 2017 Projekt IT-Konsolidierung Bund: Architekturrichtlinie für die IT des Bundes
3. Die Architekturrichtlinie wurde mit den Ressorts erörtert.
4. Die Architekturrichtlinie ist gemäß dem vorgenannten Maßgabebeschlusses des Haushaltsausschusses für alle von der Konsolidierung betroffenen Bereiche verbindlich. Hinsichtlich einer ggf. zeitlich gestaffelten Anwendung sind weitere, in der Regel bilaterale Erörterungen möglich.
5. Die Architekturrichtlinie ist in einem stetigen Prozess fortzuschreiben. Die Gesamtprojektleitung wird eine erste Fortschreibung unter Einbeziehung der Ressorts bis Mitte 2017 vornehmen. Dazu werden insbesondere Workshops mit den Ressorts durchgeführt.
Vor diesem Hintergrund fasst der IT-Rat folgenden
Beschluss Nr. 2017/2:
1. Der IT-Rat nimmt die Architekturrichtlinie für die IT des Bundes zur Kenntnis. Im Sinne des Maßgabebeschlusses des Haushaltsausschusses vom 17.06.2015 (ADrs. 18(8)2134) Abs. II Ziff. 4 ist diese für alle von der Konsolidierung betroffenen Bereiche verbindlich.
2. Die Architekturrichtlinie für die IT des Bundes wird künftig jährlich, jeweils zur Mitte des Jahres durch die Gesamtprojektleitung abgestimmt und fortgeschrieben und der Konferenz der IT-Beauftragten der Ressorts sowie dem IT-Rat zur Zustimmung vorgelegt. Dabei werden spezifische Anforderungen aus dem Ressortforschungsbereich angemessen berücksichtigt.
3. Der Beschluss wird veröffentlicht.
Beschluss IT-Rat 2017/1 2 19. Januar 2017 Architekturrichtlinie für die IT des Bundes
Version 2016
Anlage zu Beschluss Nr.: 2017/2 des IT-Rats vom 19. Januar 2017 Impressum
Herausgeber Der Beauftragte der Bundesregierung für Informationstechnik
Ansprechpartner Bundesministerium des Innern Projektgruppe Gesamtprojektleitung IT-Konsolidierung Bund Postanschrift: Alt-Moabit 140, 10557 Berlin Hausanschrift: Bundesallee 216-218, 10719 Berlin [email protected] www.cio.bund.de
Bildnachweis Titelbild: Toria / Shutterstock.com
Stand Dezember 2016
Nachdruck, auch auszugsweise, ist genehmigungspflichtig.
10/2016
Inhaltsverzeichnis
1 Kurzdarstellung ...... 5
2 Einführung ...... 6
3 Ziele und Rahmenbedingungen ...... 7
3.1 Zielsetzung und Aufbau des Dokumentes ...... 7
3.2 Relevante Projekte, Initiativen und Beschlusslagen ...... 8
3.3 Geltungsbereich/Zielgruppe ...... 11
4 Grundlagen ...... 12
4.1 Begriffsdefinitionen ...... 12
4.2 Strategische Aspekte mit Architekturbezug ...... 15
4.3 Metamodell der Rahmenarchitektur IT-Steuerung Bund und Architekturgrundsätze 21
5 Architekturvorgaben ...... 23
5.1 Vorlage zur Ermittlung der Architekturvorgaben ...... 23
5.2 Übergreifende Architekturvorgaben ...... 30
5.3 Spezifische Architekturvorgaben ...... 44
6 Nutzung von Architekturvorgaben ...... 45
7 Anhänge ...... 48
7.1 Geschäftliche Architekturvorgaben ...... 48
7.2 Architekturvorgaben für Dienste / Anwendungen ...... 53
7.2.1 Übergreifende Architekturvorgaben für Dienste ...... 54
7.2.2 Allgemeine Architekturvorgaben für Dienste ...... 56
7.2.3 Architekturvorgaben für Dienste der Domäne Elektronische Verwaltungsarbeit ...... 58
7.2.4 Architekturvorgaben für Dienste der Domäne Infrastrukturdienste ...... 65
7.2.5 Architekturvorgaben für Dienste der Domäne E-Government ...... 76
7.2.6 Architekturvorgaben für Dienste der Domäne ERP ...... 80
7.3 Architekturvorgaben für Informationen/Daten ...... 82
7.4 Technische Architekturvorgaben ...... 92
7.4.1 IT-Infrastruktur ...... 92
7.4.2 Netzinfrastruktur ...... 101
7.5 Architekturvorgaben zu Informationssicherheit, Datenschutz und Geheimschutz ... 106
7.6 Nutzungsrahmen von Diensten der GIB ...... 120
7.6.1 Dienste der Domäne Elektronische Verwaltungsarbeit ...... 120
7.6.2 Dienste der Domäne Infrastruktur ...... 124
7.6.3 Dienste der Domäne E-Government ...... 127
7.6.4 Dienste der Domäne ERP ...... 131
7.7 Festlegungen zu standardisierten Produkten/Produktfamilien ...... 132
7.7.1 Prozessorarchitekturen ...... 132
7.7.2 Programmiersprachen für serverseitige Anwendungsentwicklung...... 132
7.7.3 Entwicklungsumgebungen für serverseitige Anwendungsentwicklung ...... 132
7.8 Referenzarchitekturen ...... 133
7.8.1 Fachliche Referenzarchitekturen des Bundes ...... 133
7.9 Abbildungsverzeichnis ...... 134
7.10 Abkürzungsverzeichnis ...... 135
Kurzdarstellung 5
1 Kurzdarstellung
Das vorliegende Dokument beinhaltet die Gesamtheit aller verbindlichen Architekturvorgaben, die auf Grundlage des Maßgabebeschlusses des Deutschen Bundestages (ADrs. 18(8)2134) vom 17. Juni 2015 durch die Gesamtprojektleitung des Projektes IT-Konsolidierung Bund erarbeitet und zusammengetragen wurden. Ziel des Maßgabebeschlusses ist es, durch Aufstellen von Architekturvorgaben die Konsolidierung der IT des Bundes zu fördern und gegensätzliche Entwicklungen zu unterbinden.
Vor diesem Hintergrund wurden in einem ersten Schritt strategische Ziele mit unmittelbarem Architekturbezug auf Basis bestehender Beschlusslagen identifiziert. Diese bilden gemeinsam mit dem Metamodell der Rahmenarchitektur der IT-Steuerung Bund den grundlegenden Rahmen für alle hier beschriebenen Architekturvorgaben. Um möglichst umfassende Vorgaben zu erhalten, wurden aus diesem Metamodell verschiedene Architekturbereiche abgeleitet. Neben übergreifenden Architekturvorgaben wurden für jeden der Architekturbereiche von den fachlich zuständigen Bereichen Vorschläge für spezifische Architekturvorgaben ausgearbeitet. Auch vielfältige Vorgaben in den SAGA 5-Richtlinien wurden geprüft und je nach Relevanz mit aufgenommen und gegebenenfalls aktualisiert. Die Vorgaben wurden anschließend durch die Gesamtprojektleitung inhaltlich konsolidiert und in eine einheitliche Form gebracht. Zudem wurden Grundsätze zur Nutzung der Vorgaben aufgestellt und ein Weiterentwicklungsprozess definiert, um auch in Zukunft eine hohe Qualität, Abdeckung und Relevanz der Vorgaben sicherzustellen. Der Geltungsbereich der Richtlinie erstreckt sich, bis auf wenige Ausnahmen (siehe Kapitel 3.3), auf alle Neu- und Weiterentwicklungen der konsolidierungsrelevanten IT des Bundes.
Durch die Gruppierung der Vorgaben in spezifische Teilgebiete ist es jeder Behörde möglich, alle für sie relevanten Architekturvorgaben zu finden und zu befolgen. Hierdurch wird für die künftige Entwicklung der Architektur der IT des Bundes ein konsistentes und insgesamt wirtschaftliches Vorgehen sichergestellt. Neben der primären Unterstützung der IT- Konsolidierung des Bundes wird durch dieses Dokument auch die Umsetzung weiterer Initiativen und Beschlüsse auf Bundes und -europäischer Ebene gefördert.
Eine regelmäßige Fortschreibung dieser Architekturrichtlinie ist für die Zukunft notwendig und vorgesehen, um ein Höchstmaß an Aktualität und einen optimalen Umfang zu erreichen. Auch für die Fortschreibung wird eine enge Einbindung der Ressorts sichergestellt.
6 Einführung
2 Einführung
Das vom Bundeskabinett am 5. Dezember 2007 beschlossene Konzept "IT-Steuerung Bund" hat dem Rat der IT-Beauftragten der Bundesressorts (IT-Rat) u. a. die Aufgabe übertragen, gemeinsame IT-Standards und Architekturen für die Bundesverwaltung zu erarbeiten. Mit dem Aufbau eines solchen aktiven Architekturmanagements schafft die Bundesverwaltung die Voraussetzungen für einen nachhaltigen, effektiven und wirtschaftlichen Einsatz ihrer Informationstechnik.1 Das Architekturmanagement ist für Verwaltungen und Unternehmen ein wesentlicher Schlüssel zur Steigerung der Leistungsfähigkeit ihrer IT-Infrastrukturen. Es gewährt den Blick aus einer übergreifenden Perspektive und ermöglicht eine zielgerichtete Steuerung verschiedener Interessengruppen zu einem einheitlichen Vorgehen. Im Rahmen einer Ist- Aufnahme aller Behörden wurde festgestellt, dass derzeit nur 65% aller Behörden IT-Grundsätze oder Architekturvorgaben etabliert haben. Diese Zahl macht deutlich, dass es einen Bedarf an klaren und einheitlichen Vorgaben gibt.
Mit dem Projekt „IT-Konsolidierung Bund“ wurden drei zentrale Handlungsstränge initiiert, um die IT der unmittelbaren Bundesverwaltung zukunftsfähig zu gestalten und eine moderne und flexible IT-Architektur zu gewährleisten. Diese Handlungsstränge umfassen eine Betriebskonsolidierung von Rechenzentren und Serverräumen, eine Dienstekonsolidierung zur Vermeidung von unnötigen Doppel- und Mehrfachentwicklungen von IT-Systemen sowie die Beschaffungsbündelung in wenigen zentralen IT-Beschaffungsstellen.
Um die Ziele dieses Projektes zu unterstützen ist sicherzustellen, dass bei der dazu parallel laufenden technischen Weiterentwicklung der IT der unmittelbaren Bundesverwaltung keine Entscheidungen getroffen werden, die einer geplanten späteren Konsolidierung im Wege stehen. Aus diesem Grund wurde die Gesamtprojektleitung „IT-Konsolidierung Bund“ beauftragt Architekturvorgaben zu definieren, die vorrangig diesem Zweck dienen sollen. Konzeptionell ist dabei berücksichtigt, dass die Architekturvorgaben langfristig als fester Bestandteil eines übergreifenden Architekturmanagements etabliert werden sollen.
Mit Hilfe von Architekturvorgaben können wichtige Architekturentscheidungen systematisch, nachvollziehbar und transparent getroffen werden. Außerdem unterstützen die Vorgaben eine Ausrichtung der laufenden IT-Projekte an die strategischen Anforderungen und politischen Aufgaben. Die vorliegenden Architekturvorgaben fungieren als Rahmenwerk, das sich über alle vom Metamodell der Rahmenarchitektur IT-Steuerung Bund betroffenen Bereiche erstreckt.
1 http://www.cio.bund.de/Web/DE/Architekturen-und- Standards/Architekturmanagement/architekturmanagement_node.html
Ziele und Rahmenbedingungen 7
3 Ziele und Rahmenbedingungen
Innerhalb dieses Kapitels werden Ziele und Rahmenbedingungen dieser Architekturrichtlinie aufgeführt, zugrundeliegende Beschlüsse erläutert und Geltungsbereich sowie Zielgruppe festgelegt.
3.1 Zielsetzung und Aufbau des Dokumentes
Der Beschluss des Haushaltsausschusses vom 17. Juni 2015, fordert die Bundesregierung auf, „sicherzustellen, dass bei der laufenden technischen Weiterentwicklung der IT-Infrastruktur in der Bundesverwaltung und der Neuvergabe von Aufträgen keine Entscheidungen getroffen werden, die einer geplanten späteren Konsolidierung im Wege stehen. Die Gesamtprojektleitung soll dazu, so bald wie möglich, entsprechende Architekturrichtlinien erarbeiten. Für alle Bereiche, die von der Konsolidierung betroffen sein werden, sind diese Richtlinien verbindlich. Die Ressorts sind bei der Erarbeitung der Richtlinien zu konsultieren. Über Ausnahmen entscheidet der IT-Rat.“2 Ziel dieses Dokumentes ist es, die im Maßgabebeschluss erwähnten Architekturvorgaben in aufbereiteter Form darzustellen und den von der IT-Konsolidierung Bund betroffenen Bereichen zur Verfügung zu stellen. Durch die Verbindlichkeit der Vorgaben wird die Zielerreichung des Projektes IT-Konsolidierung Bund (vgl. Kapitel 3.2) frühzeitig und optimal unterstützt. Außerdem fördert dieses Dokument die Umsetzung des 2007 beschlossenen Konzeptes „IT-Steuerung Bund“ durch das Festlegen und Beschließen von IT-Standards und Architekturvorgaben. Weiterhin berücksichtigt dieses Dokument verschiedene Vorgaben der SAGA 5-Spezifikation, die je nach Relevanz mit integriert und aktualisiert wurden. Vorläufig wird diese Richtlinie parallel zu SAGA 5 existieren. Es wird im Zuge der Fortschreibung geprüft in welcher Form SAGA 5 abgelöst werden kann.
Der Inhalt des Dokumentes ist wie folgt gegliedert:
Kapitel 3 umfasst die Ziele der Architekturvorgaben und der IT-Konsolidierung Bund, zugrundeliegende Beschlüsse und laufende Projekte, sowie den Geltungsbereich und die Zielgruppe der Architekturvorgaben.
In Kapitel 4 werden prinzipielle Grundlagen für das Verständnis der Architekturvorgaben vermittelt. Es umfasst relevante Begriffsdefinitionen, die übergeordneten strategischen Ziele der IT des Bundes und beschreibt das Metamodell der Rahmenarchitektur der IT-Steuerung Bund und dessen Architekturgrundsätze.
2 Beschluss des Haushaltsausschusses zu TOP 23 a) und b) vom 17. Juni 2015
8 Ziele und Rahmenbedingungen
Kapitel 5 beinhaltet in Kombination mit den Anhängen 7.1 - 7.6 die ausgearbeiteten Architekturvorgaben, welche in verschiedene Teilgebiete unter Berücksichtigung des Metamodells der Rahmenarchitektur IT-Steuerung Bund aufgeteilt wurden.
In Kapitel 6 werden Mechanismen zur Nutzung von Architekturvorgaben festgelegt.
3.2 Relevante Projekte, Initiativen und Beschlusslagen
Die Informationstechnik des Bundes ist von zentraler Bedeutung für die Handlungsfähigkeit von Staat und Verwaltung. Die strategische Ausrichtung der IT des Bundes unterliegt verschiedenen bereits verabschiedeten Beschlüssen des Bundes, berücksichtigt Vorgaben auf europäischer Ebene und bereits initiierte strategische Projekte sowie Initiativen. Die Architekturvorgaben unterstützen die architekturrelevanten Ziele der folgenden Projekte und Initiativen.
Bereits initiierte strategische Projekte
„IT-Konsolidierung Bund“: Eine zentrale Initiative zur strategischen Ausrichtung der IT des Bundes stellt das zum 1. Juli 2015 eingerichtete, ressortübergreifende Projekt IT-Konsolidierung des Bundes dar. Im Rahmen des Projektes wird bis 2025 die gesamte IT des Bundes zukunftsfähig aufgestellt. Ziele der IT-Konsolidierung Bund sind die IT-Sicherheit vor dem Hintergrund steigender Komplexität zu gewährleisten, die Hoheit und Kontrollfähigkeit über die eigene IT dauerhaft zu erhalten, auf innovative technologische Trends flexibel reagieren zu können, einen leistungsfähigen, wirtschaftlichen, stabilen, umweltverträglichen und zukunftsfähigen Betrieb sicherzustellen und ein attraktiver Arbeitgeber für IT-Fachpersonal zu bleiben. Die Daten der Bundesverwaltung sollen ferner umfassend geschützt und gegen Missbrauch abgesichert werden.
Um diese Ziele zu erreichen, wurden drei Handlungsstränge identifiziert, die in einem stufenweisen Vorgehen innerhalb der unmittelbaren Bundesverwaltung umgesetzt werden sollen:
• Beschaffungsbündelung des größten Teils der IT-Beschaffungen der unmittelbaren Bundesverwaltung in wenigen zentralen IT-Beschaffungsstellen bis Ende 2018, • Betriebskonsolidierung durch erhebliche Reduktion von Rechenzentren und Serverräumen bis 2022, • Konsolidierung von Diensten bei den zentralen IT-Dienstleistern bis 2025 auf maximal zwei Basis- bzw. Querschnittsdienste je gleicher Funktionalität.
Ziele und Rahmenbedingungen 9
„Digitale Verwaltung 2020“: Die Bundesregierung hat für die übergreifende Steuerung aller E- Government-Aktivitäten der Bundesverwaltung in der 18. Legislaturperiode das Regierungsprogramm „Digitale Verwaltung 2020“ initiiert, welches am 17.September 2014 durch das Bundeskabinett beschlossen wurde. Mit dem Programm ist das Ziel verbunden, „mit Hilfe moderner Informationstechnologien eine digitalisierte, durchgängige, medienbruchfreie und einheitliche öffentliche Leistungserbringung auf der Grundlage kollaborativer Geschäftsprozesse zu etablieren.“3 Die „Digitale Verwaltung 2020“ beinhaltet u. a. Themen wie: die Umsetzung des E-Government-Gesetzes, Bürokratieabbau, Elektronische Rechnung, Open Data, Datenschutz und Informationssicherheit.
„Netzes des Bundes“ (NdB): Ziel von NdB ist es, die gesamte unmittelbare Bundesverwaltung im Bereich der Netze und netznahen Basisdienste unter Nutzung von Konsolidierungs- und Synergiepotenzialen zukunftssicherer aufzustellen. Weiterhin soll eine Infrastruktur mit erhöhtem Sicherheitsniveau bereitgestellt werden, auf welche die drei vom BMI-verantworteten Netze (IVBB, IVBV/BVN sowie DOI) vollständig migriert werden und die als Integrationsplattform für alle Weitverkehrsnetze der Bundesverwaltung dienen kann. Hierdurch werden die gestiegenen Anforderungen und Sicherheitsbedarfe bei der Vernetzung der Bundesbehörden für die Übermittlung von bis maximal VS-NUR FÜR DEN DIENSTGEBRAUCH eingestufte Daten erfüllt. Die notwendigen Parallelanschlüsse der Behörden an Fremdnetze sind dabei zu berücksichtigen.
„IT-Rahmenkonzept des Bundes“: Das IT-Rahmenkonzept umfasst alle IT-Maßnahmen und bestehenden IT-Vorhaben/IT-Verfahren der Gemeinsamen IT des Bundes (ressortübergreifende Basis- und Querschnittsdienste). Bedarfe nach funktionaler Unterstützung, welche ressortübergreifend entstehen, sind frühzeitig bei den verbindlichen Planungen des IT- Rahmenkonzeptes einzubringen. Das jährliche IT-Rahmenkonzept wird jeweils durch den IT-Rat beschlossen. Die Realisierung in IT-Lösungen erfolgt in Zusammenarbeit mit den IT- Dienstleistern des Leistungsverbundes. Die resultierenden IT-Lösungen werden frühzeitig in den Produktkatalog (u. a. Ankündigungen, verfügbare Produkte, Abkündigungen) des Leistungsverbundes eingebracht.
3 Bundesministerium des Innern: Digitale Verwaltung 2020, September 2014, S. 8
10 Ziele und Rahmenbedingungen
Vorhandene Beschlusslagen auf Bundesebene
Neben den bereits initiierten Projekten existieren diverse weitere Beschlusslagen, deren Umsetzung durch diese Architekturrichtlinie gefördert wird. Auf Bundesebene berücksichtigen die Architekturvorgaben Ziele und bereits vorhandene Beschlusslagen, insbesondere. • die „Digitale Agenda 2014-2017“, • das „IT-Rahmenkonzept des Bundes für das Haushaltsjahr 2017“, • die „Rahmenplanung Gemeinsame IT des Bundes“, • das „Konzept zur IT-Steuerung Bund“ , • das Maßnahmenprogramm „Nachhaltigkeitsstrategie für Deutschland“, • das „Aktionsprogramm zum Klimaschutz 2020“, • den „Umsetzungsplan Bund“, • das „Programm zur nachhaltigen Nutzung und zum Schutz der natürlichen Ressourcen“, • die Ziele und Rahmenbedingungen der „Green-IT-Initiative“ des Bundes und • die „allgemeine Verwaltungsvorschrift zur Beschaffung energieeffizienter Produkte und Dienstleistungen“ (AVVEnEff).
Die Implikationen des Beschlusses des Haushaltsauschusses des Deutschen Bundestages vom 28. September 2016 (ADrs. 18(8)3472) in Bezug auf die Rolle der BWI Informationstechnik GmbH (BWI) sind noch nicht abschließend untersucht. Sich aus dem Ergebnis der Untersuchung für die Architekturrichtlinie ergebende Anpassungserfordernisse sind daher im vorliegenden Dokument noch nicht abgebildet. Um die BWI in die Lage zu versetzen, im Sinne des HHA-Beschlusses bereits in 2017 als IT-Dienstleister für zunächst zehn Behörden aufzutreten, ist zusätzlich zu den gemäß Kapitel 6 dargestellten Ausführungen der Beginn einer Fortschreibung der Architekturrichtlinie in 2017 geboten.
Vorgaben auf europäischer Ebene
Auf europäischer Ebene werden beispielsweise mit der „Strategie Europa 2020“ der Europäischen Kommission die Ziele für das Wachstum der Europäischen Union (EU) bis 2020 festlegt. Eine der sieben Säulen dieser Strategie ist die „Europäische Digitale Agenda“. In dieser fordert die Europäische Kommission eine bessere Nutzung der Informations- und Kommunikationstechnologie (IKT), um Innovation, Wirtschaftswachstum und Fortschritt zu stärken. Unter dem Gesichtspunkt von strategischen Architekturentscheidungen soll hierdurch insbesondere die Interoperabilität von IT-Geräten, Anwendungen, Datensammlungen, Diensten und Netzen erhöht werden.
Ziele und Rahmenbedingungen 11
3.3 Geltungsbereich/Zielgruppe
Der Geltungsbereich dieser Architekturrichtlinie erstreckt sich auf alle neuvergebenen Aufträge sowie Neu- und Weiterentwicklungen von konsolidierungsrelevanten IT-Maßnahmen der unmittelbaren Bundesverwaltung. Ausnahmen bilden die Auslands-IT, IT der Nachrichtendienste und IT für den Umgang mit eingestuften Informationen der Geheimhaltungsgrade VS-VERTRAULICH und höher sowie Umgebungen und Verfahren, die gemäß RZ-Konsolidierungsplan von der IT-Konsolidierung Bund ausgenommen sind. Die aufgeführten Vorgaben ebenso wie besondere fachliche Anforderungen und politische Rahmenbedingungen sind gemäß Grobkonzept IT-Konsolidierung Bund zwingend vor der Umsetzung der entsprechenden Maßnahmen zu berücksichtigen.4
Die Architekturvorgaben richten sich an Entscheidungsträger/innen, Projektleitungen und Architekten/innen mit Verantwortung für IT-Infrastruktur-Projekte in der unmittelbaren Bundesverwaltung. Außerdem richtet sich diese Richtlinie an das Service Management und Entscheidungsträger/innen des IT-Betriebs. Die Vorgaben gelten sowohl für die Auftrag gebenden Personen als auch für ihre Auftragnehmer/innen. Ein geeigneter Wissenstransfer an alle relevanten Beschäftigten ist durch die einzelnen Behörden sicherzustellen.
4 Im Geschäftsbereich des BMVg sind sowohl die Vorgaben des Bundes als auch die Vorgaben und Standards der NATO anzuwenden. Näheres regelt u. a. die Technische Architektur der Bundeswehr (TABw, ressortspezifische Variante der SAGA 5)
12 Grundlagen
4 Grundlagen
Dieses Kapitel erläutert grundlegende Begriffe, um eine einheitliche Sprachbasis zu schaffen. Weiterhin werden architekturrelevante strategische Ziele des Bundes aufgezeigt, aus denen grundlegende Architekturvorgaben abgeleitet wurden, um die IT-Strategie optimal zu unterstützen. Außerdem wird das von der IT-Steuerung Bund im BMI entwickelte Metamodell der Rahmenarchitektur erläutert. Aus diesem wurden die architektonisch zu betrachtenden Bereiche der Bundesverwaltung identifiziert, welche ergänzende Vorgaben, die in den Anhängen 7.1 bis 7.5 aufgeführt sind, eingebracht haben.
4.1 Begriffsdefinitionen
Die in diesem Dokument verwendeten Begrifflichkeiten sind im Vorgriff auf ein in der Erstellung befindliches, einheitliches Projekt-Glossar des Bundes zu sehen. Nach Finalisierung wird dieses Glossar als Anlage zum Projekthandbuch zur Verfügung stehen und entsprechend Eingang in diese Architekturrichtlinie finden. Im Folgenden werden zentrale IT-Begriffe, welche im direkten Zusammenhang mit den Architekturvorgaben stehen, kurz aufgeführt.
Architekturvorgabe
Eine Architekturvorgabe definiert die spezifische Ausprägung eines Architekturaspektes, der innerhalb des Geltungsbereichs verbindlich eingehalten werden muss.
Architekturrichtlinie
Die Architekturrichtlinie stellt die Gesamtheit aller Architekturvorgaben dar, die innerhalb des Geltungsbereichs verbindlich eingehalten werden müssen.
Dienst
Ein Dienst ist eine logische Einheit, die einen definierten Umfang an funktionalen Anforderungen erfüllt. Innerhalb der Rahmenarchitektur IT-Steuerung Bund stellt der Dienst eine Beschreibungseinheit zur Strukturierung der IT-Unterstützung für geschäftliche und fachliche Anforderungen dar.
Basisinfrastruktur
Die Basisinfrastruktur umfasst alle technischen Einrichtungen, die Grundvoraussetzung für die Bereitstellung und Nutzung von IT-Lösungen sind (z. B. Netze, Massenspeicher).
Basisdienst
Ein Basisdienst ist ein Dienst, der eine gemeinsame, übergreifende Grundlage für andere, darauf
Grundlagen 13 aufbauende Dienste (u.a. Fach- und Querschnittsdienste) bildet. Der Basisdienst ist i. d. R. keiner einzelnen fachlichen Aufgabe direkt zugeordnet.
Bedarfsträger
Eine Behörde oder beispielsweise ein(e) mit der Erhebung und Konsolidierung beauftragte/s Stelle/Gremium, die/das aufgrund ihrer/seiner Anforderungen IT-Dienstleistungen abruft.
Dienstemodell
Das Dienstemodell stellt in der Rahmenarchitektur IT-Steuerung Bund eine strukturierte Darstellung von Fach-, Querschnitts- und Basisdiensten auf einer funktionalen, logischen Ebene dar.
Fachdienst
Ein Fachdienst ist ein Dienst, der direkt der Erfüllung einer speziellen Fachaufgabe dient.
Geschäftsmodell (GM) / Geschäftliches Modell
Das Geschäftliche Modell stellt in der Rahmenarchitektur IT-Steuerung Bund eine strukturierte Darstellung der geschäftlichen Aufgaben nach Geschäftsfeldern sowie der geschäftlichen Prozesse und deren Teilprozesse, die zur Erfüllung von Aufgaben benötigt werden und die mit IT zu unterstützen sind, dar.
Informationsmodell (IM)
Das Informationsmodell stellt in der Rahmenarchitektur IT-Steuerung Bund eine Beschreibung der semantischen Standardisierung für den übergreifenden Austausch von Daten dar.
Infrastrukturdienst
Ein Infrastrukturdienst ist eine logische Gruppierung von Leistungen innerhalb der Softwarearchitektur, die übergreifend über Schichten bereitgestellt wird, um fachliche Funktionalität von der zu Grunde liegenden Infrastruktur zu entkoppeln.
IT-Architektur
Eine IT-Architektur beschreibt, auf welcher technischen Basis IT-Lösungen zur Umsetzung der Anforderungen bereitgestellt werden. Zur Steuerung von Neu- und Weiterentwicklungen von IT-Lösungen werden zulässige Technologieobjekte im SOLL-Bebauungsplan vorgegeben.
IT-Architekturmanagement
Das IT-Architekturmanagement beschreibt Verfahrensweisen zur engen Verzahnung von
14 Grundlagen
Geschäft, IT-Lösung sowie IT-Infrastrukturen. Sie schafft eine Gesamtsicht auf die wesentlichen fachlichen- und IT-Strukturen und verknüpft sie miteinander.
IT-Lösung
Eine IT-Lösung stellt die informationstechnische Realisierung eines definierten Leistungsumfangs an IT-Unterstützung durch ein (technisches) System dar. In der Rahmenarchitektur stellt eine IT-Lösung ein oder mehrere Dienste technisch bereit. Diese Definition basiert auf dem Begriff „System“ aus DIN EN ISO 19439, (6).
IT-Maßnahme
Eine IT-Maßnahme ist fachlich und technisch abgrenzbar. Sie dient grundsätzlich der Bereitstellung einer IT-Lösung und/oder der Durchführung eines IT-Projektes. Eine IT- Maßnahme kann auch zur Sicherstellung von Infrastrukturleistungen (Infrastrukturmaßnahme) oder zur Beschaffung (Beschaffungsmaßnahme) dienen. Eine IT- Maßnahme kann demnach ein Fachverfahren, ein Querschnitts-, ein Basis- oder ein Infrastrukturdienst sein. Einer IT-Maßnahme können in der Regel mehrere IT-Vorhaben zugeordnet sein.
IT-Vorhaben
Ein IT-Vorhaben dient der übergeordneten Darstellung der Planungsdetails einer oder mehrerer IT-Maßnahmen. Sämtliche Haushaltsmittel, die für eine IT-Maßnahme geplant sind, werden durch entsprechende IT-Vorhaben zugeordnet. Jedes IT-Vorhaben wird mit einem Planungsauftragskennzeichen / vorläufigen Auftragskennzeichen versehen, das bei seiner Beschreibung anzugeben ist.
Querschnittsdienst
Ein Querschnittsdienst ist ein Dienst, der in unterschiedlichen Verwaltungseinheiten stets in ähnlicher oder gleicher Form anfallende Aufgaben unterstützt und auch von Fachdiensten genutzt werden kann.
Grundlagen 15
4.2 Strategische Aspekte mit Architekturbezug
Die strategische Ausrichtung der IT des Bundes stellt eine wesentliche Grundlage für die Erarbeitung der Architekturvorgaben dar, da die zukünftige Architektur diese Ausrichtung bestmöglich unterstützen soll. Die strategischen Ziele der Bundesverwaltung werden in der IT- Strategie der Bundesverwaltung fortgeschrieben. Sofern im Zuge der Fortschreibung der IT- Strategie der Bundesverwaltung Anpassungen hinsichtlich der Architekturvorgaben erforderlich sind, werden diese bei der Aktualisierung der Architekturrichtlinie eingearbeitet.
Dieses Kapitel führt die identifizierten architekturrelevanten Ziele auf und leitet relevante Themenfelder für die Architektur ab. Als primäres Ziel sind die optimale bedarfsgerechte Unterstützung der Fachaufgaben und der politischen sowie strategischen Vorhaben des Bundes und die Einhaltung der Mindeststandards des BSI zu sehen. Die Aufgabenerfüllung in den Behörden darf von der Konsolidierung (u. a. Standardisierung und Zentralisierung) nicht beeinträchtigt werden. Die derzeitige Qualität der IT-Unterstützung muss mindestens auf dem heutigen Niveau erhalten bleiben.
Wirtschaftlichkeit und Kosteneffizienz
Die Entwicklung und der Betrieb der IT des Bundes unterliegen dem Wirtschaftlichkeitsgebot. Darüber hinaus werden Anstrengungen unternommen, den Energie- und Ressourcenverbrauch der IT des Bundes weiter zu senken5. Bei der Erreichung der Ziele und Umsetzung von Maßnahmen sollen Ressourcen wirtschaftlich und effizient eingesetzt werden. Daraus leiten sich unter Beachtung technischer, wirtschaftlicher sowie IT-Sicherheitsaspekte folgende Themenfelder für die Architektur ab:
• Realisierung von Einsparpotenzialen durch Beschaffungsbündelung und Konsolidierung
• Steigerung des Virtualisierungsgrades
• Effizienter Ressourceneinsatz durch Standardisierung • Vollständige Lebenszyklusbetrachtung (bzgl. Wirtschaftlichkeit und Ressourcen) unter Maximierung der Lebensdauer
Diese Felder sind für das Treffen zukünftiger Architekturentscheidungen angemessen zu berücksichtigen.
5 „Digitale Agenda 2014-2017“, S. 17
16 Grundlagen
Effektivität und Qualität der IT des Bundes
Vor dem Hintergrund wachsender Komplexität und wechselnder Rahmenbedingungen gilt es, die Effektivität und Qualität der IT als Unterstützungsprozess für die Erfüllung der Fachaufgaben der unmittelbaren Bundesbehörden weiter zu steigern. Hierfür sind die Wiederverwendbarkeit und Flexibilität der IT-Angebote des Bundes zu stärken und ein leistungsfähiger sowie stabiler Betrieb der IT-Landschaft sicherzustellen.
Aus dieser Zielsetzung leiten sich für die Architektur folgende Schwerpunkte ab:
• Optimale bedarfsgerechte Unterstützung der Fachaufgaben und der politischen sowie strategischen Vorhaben des Bundes • Erhöhen der Modularisierung und Flexibilisieren der IT-Landschaft • Anforderungsgerechte Standardisierung • Absicherung der Zuverlässigkeit und Vorsehen notwendiger Redundanzen
Digitale Verwaltung
Die voranschreitende Digitalisierung der verschiedenen Verwaltungsprozesse ist einer der Kernpunkte für die strategische Ausrichtung der Behörden. Digitalisierung vereinfacht und beschleunigt Prozesse, unterstützt die Kommunikation und Kooperation der Behörden untereinander und verbessert den Zugang zu Verwaltungsdienstleistungen für Bürger/innen und Unternehmen. Zudem unterstützt eine digitale Verwaltung die Kooperation des Bundes und der Länder sowie die Zusammenarbeit im internationalen Kontext.
Geleitet durch die Vorgaben des „E-Government Gesetzes“ und dem damit verbundenen Ziel des Bürokratieabbaus, ergeben sich folgende Themenfelder für die Architektur:
• Bereitstellung eines elektronischen Zugangs zur Verwaltung • Digitalisierung von Verwaltungsprozessen, insbesondere unter Nutzung von Basisdiensten zur Dokumenten- und Vorgangsbearbeitung (Akte, Vorgänge, Kollaboration, Archivierung)
Zukunftsfähigkeit und Offenheit für Innovationen
Die Verwaltung der Zukunft wird u.a. durch Innovationen erreicht und die IT ist dabei einer der Treiber von Innovationen. Sie ermöglicht die Umsetzung neuer Konzepte zur Einbindung der Bürgerinnen und Bürger und ermöglicht neue Arbeitsweisen. Ein effektiver und bedarfsorientierter IT-Betrieb kann jedoch langfristig nur durch den Einsatz zeitgemäßer und umweltverträglicher Technologien sichergestellt werden. Die Zukunftsfähigkeit der Bundesverwaltung soll sichergestellt werden durch:
Grundlagen 17
• Regelmäßige Evaluierung der IT-Systeme und Technologie-Upgrades • Strukturierte Prozesse zur Bewertung und schnellen Umsetzung technischer Innovationen • Förderung von Innovationen durch Zusammenarbeit mit externen Partnern Die Förderung von Innovationen ermöglicht langfristig positive Effekte auf alle Ziele.
Informationssicherheit, Datenschutz und Geheimschutz
Durch die voranschreitende Vernetzung, steigende Komplexität der IT und den Ausbau der digitalen Infrastruktur kommen der Informationssicherheit, dem Datenschutz und dem Geheimschutz immer höhere Stellenwerte zu. Für zukünftige Architekturentscheidungen sind folgende Zielsetzungen von essentieller Bedeutung:
• Gewährleistung der Sicherheit der Daten vor unberechtigter Kenntnisnahme (Vertraulichkeit), unberechtigter Veränderung (Authentizität) sowie vor dem Verlust der Daten (Integrität) und vor Systemausfällen (Verfügbarkeit und Belastbarkeit) • Gewährleistung der Einhaltung des Bundesdatenschutzgesetzes (das 2018 durch die EU- Datenschutzgrundverordnung ersetzt wird) sowie anderer datenschutzrechtlicher Regelungen beim Umgang mit personenbezogenen Daten, u. a. das Recht der Personen zur Selbstbestimmung über die Preisgabe und Verwendung ihrer persönlichen Daten • Gewährleistung der Einhaltung des Sicherheitsüberprüfungsgesetzes und der allgemeinen Verwaltungsvorschriften zur Ausführung des Sicherheitsüberprüfungsgesetzes, insbesondere der allgemeinen Verwaltungsvorschrift des Bundesministeriums des Innern zum materiellen und organisatorischen Schutz von Verschlusssachen (VSA-Anweisung) bei der Handhabung mit Verschlusssachen. • Erleichterung der Bereitstellung von an verschiedenen Schutzbedarfen ausgerichteten IT-Leistungen • Umfassende Umsetzung empfohlener Standards zur Informationssicherheit (u. a. IT- Grundschutz-Kataloge und IT-Grundschutz-Standards des BSI) • Anforderungsgerechte Reduzierung der Komplexität der Anwendungslandschaft auf ein notwendiges Maß • Berücksichtigung von Robustheit und Resilienz in frühen Entwicklungsstadien von Architektur und Design
Attraktivität als Arbeitgeber
Der drastisch wachsende Anteil IT-unterstützter Prozesse in der Verwaltung lässt den Bedarf an qualifiziertem IT-Fachpersonal weiter steigen. Dabei steht die Bundesverwaltung im Wettbewerb
18 Grundlagen mit der Privatwirtschaft und muss sich noch stärker als bisher als zeitgemäßer und attraktiver Arbeitgeber positionieren. Wegen der herausgehobenen Bedeutung des IT-Personals für die Erreichung der Fachziele der Bundesverwaltung wird die „Attraktivität als Arbeitgeber“ als eigenständiges Ziel in der IT-Strategie verankert. Zielsetzung ist die dauerhafte Bindung von vorhandenem IT-Personal und die Gewinnung von neuem Personal als Auszubildende, Studierende und IT-Fachpersonal. Dies soll u. a. durch ein technologisch attraktives Arbeitsumfeld und Verbesserung der Karrieremodelle sowie durch zielgerichtete Weiterbildungen erreicht werden. Eine erhöhte Attraktivität als Arbeitgeber wirkt sich positiv auf die Erreichung weiterer Ziele aus.
Kontrollfähigkeit und Steuerbarkeit
Die bedarfsgerechte und damit erfolgreiche Zusammenarbeit zwischen den IT-Dienstleistern und den Ressorts erfordert effektive Steuerungsmechanismen und ein transparentes IT- Controlling mit zentraler Koordination. Dieses Ziel ist durch eine klare und eindeutige Zuweisung von Aufgaben, Kompetenzen und Verantwortung innerhalb der weiterentwickelten IT-Organisationen umzusetzen. Folgende Prämissen sind durch die zukünftige IT-Architektur zu berücksichtigen:
• Die systematische Zusammenarbeit zwischen Fach- und IT-Seite soll durch die Techniken und Methoden der Rahmenarchitektur IT-Steuerung Bund systematisch gefördert werden. • Die ressortübergreifende IT-Steuerung soll durch effektiven und effizienten IT‐Einsatz das IT-Dienstleistungsangebot für die Verwaltung verbessern. • Die Schaffung geeigneter Planungsinstrumente soll einen effektiven und effizienten IT‐ Einsatz gewährleisten, Innovationen fördern, administrative Handlungsfähigkeit bewahren und die Effizienz der Verwaltung steigern.
Dieser strategische Aspekt wird insbesondere in Kapitel 6 aufgegriffen und dessen Umsetzung spezifiziert.
Kooperationen
Der wachsende Digitalisierungsgrad in der Verwaltung bietet die Chance dem gesteigerten Bedarf an nationaler und internationaler Interoperabilität gerecht zu werden. Voraussetzung für einen effizienten Abgleich und Austausch von Daten zwischen Organen verschiedener Verwaltungsebenen in der NATO, EU, im Bund und den Ländern sind gemeinsame Schnittstellen. Zudem werden die Aktivitäten des Federated Mission Networking (FMN) die Interoperabilität grenzübergreifender Kooperationen maßgeblich verbessern. Diese
Grundlagen 19
Architekturvorgaben müssen die Entwicklung und den Ausbau kompatibler und zukunftsfähiger Schnittstellen ermöglichen und damit den kooperativen und organisationsübergreifenden Informationsaustausch insbesondere in der Digitalen Verwaltung fördern. Zusätzlich müssen weitere Kooperationen mit der Wirtschaft und mit Zweckverbänden gestärkt werden.
Aus dieser Zielsetzung ergibt sich für die Architektur folgender Schwerpunkt:
• Einbetten von zukunftsweisenden Schnittstellen in neue und vorhandene Systeme und Berücksichtigung des Datenaustauschs mit anderen Verwaltungsebenen sowie externen Empfängern (bspw. Wirtschaft und Forschung).
Inklusion und Barrierefreiheit
Die fortschreitende technische Entwicklung birgt Chancen und Risiken für Menschen mit Behinderungen und Menschen mit geringen IT-Kenntnissen. Chancen, weil mit der voranschreitenden Digitalisierung neue Techniken, Arbeitsfelder und Unterstützungsmittel entstehen. Risiken, weil bei der Entwicklung einer neuen Technik der Zugang für Menschen mit Behinderung oft übersehen wird und nicht alle Teilnehmenden die gleichen Nutzungsvoraussetzungen mitbringen. Die "Chancengleichheit im Netz" ist ein Thema von großer politischer und gesellschaftlicher Bedeutung, denn die breite Anwendung neuer Kommunikationstechniken ist eine der zentralen Voraussetzungen für die Wettbewerbsfähigkeit eines Landes und dessen Beschäftigungsentwicklung. Das Ziel umfasst den folgenden architektonischen Aspekt:
• Die digitalen Angebote des Bundes müssen barrierefrei erreichbar sowie für Bürger/innen und Beschäftigte mit Beeinträchtigungen im selben Funktionsumfang verfügbar sein.
Umweltverträglichkeit und Nachhaltigkeit
Die IT-Systeme des Bundes sollen nach umweltverträglichen und nachhaltigen Grundsätzen entwickelt und betrieben werden. Als Maßgabe soll trotz steigender Leistung z. B. der Energieverbrauch der IT-Systeme mindestens konstant gehalten und nach Möglichkeit durch begleitende Maßnahmen zum Einsatz energieschonender Technologien kontinuierlich gesenkt werden. Bereits bei der Beschaffung soll das Nachhaltigkeitsgebot berücksichtigt werden. Mit Blick auf die Architekturrichtlinie folgt daraus:
• Der IT-Betrieb soll umweltverträglich und nachhaltig gestaltet werden. Hierbei sind jegliche Inanspruchnahmen von Ressourcen über den gesamten Lebenszyklus zu betrachten.
20 Grundlagen
• Die IT-Beschaffung soll konsequent umweltverträgliche und nachhaltige Aspekte berücksichtigen.
Grundlagen 21
4.3 Metamodell der Rahmenarchitektur IT-Steuerung Bund und Architekturgrundsätze
Das Metamodell der Rahmenarchitektur IT-Steuerung Bund wurde entwickelt, um gemeinsame Begriffe und Strukturen zur Unterstützung einer effizienten ressortübergreifenden Zusammenarbeit zu schaffen. Die in Kapitel 5 und den Anhängen 7.1 bis 7.5 dargestellten Architekturvorgaben orientieren sich in ihrer strukturellen Gliederung an dem Metamodell der Rahmenarchitektur IT-Steuerung Bund6. Dieses Metamodell stellt einen übergreifenden Begriffs- und Strukturrahmen für die Erstellung von Modellen zum Zweck der Planung und Steuerung der IT der Bundesverwaltung dar. Es schließt auch Definitionen der auf dieser Ebene erforderlichen Objekte und Relationen ein. Die folgende Abbildung stellt eine vereinfachte Form des Metamodells dar, aus der die einzelnen Teilmodelle der Rahmenarchitektur ersichtlich werden. Diese vereinfachte Form wurde gewählt, um die architekturrelevanten Komponenten des Modells aufzuzeigen.
Abbildung 1: Aus dem Metamodell der Rahmenarchitektur IT-Steuerung Bund entwickeltes Modell zur Verdeutlichung der Architekturbereiche
Die Abbildung verdeutlicht, dass aus den bereits in Kapitel 4.2 erläuterten strategischen Zielen übergreifende Architekturvorgaben abgeleitet wurden. Betrachtet man nun unter Berücksichtigung der übergreifenden Architekturvorgaben und der strategischen Ziele die einzelnen Teilbereiche des Metamodells, so lassen sich hieraus diverse spezifische Vorgaben für jeden Bereich ermitteln. Konkret wurden geschäftliche Architekturvorgaben, Architekturvorgaben für Dienste und Anwendungen, Architekturvorgaben für Informationen
6 Abschlussbericht Rahmenarchitektur IT-Steuerung Bund, 15.03.2012 (siehe www.cio.bund.de, Suchbegriff: „Rahmenarchitektur IT-Steuerung Bund“)
22 Grundlagen und Daten, technische Architekturvorgaben und Vorgaben zur Informationssicherheit, Datenschutz und Geheimschutz aufgestellt.
Die folgende Abbildung beschreibt näher, auf welche spezifischen Bereiche sich die Vorgaben innerhalb der einzelnen Modelle beziehen.
Abbildung 2: Zusammenhang zwischen Metamodell der Rahmenarchitektur IT-Steuerung Bund und den Architekturvorgaben
Der Umsetzbarkeit zentraler Vorgaben können durch die Aufgabenerledigung der Behörden Grenzen gesetzt sein. Das ist insbesondere dann der Fall, wenn durch Zusammenarbeit mit Stellen außerhalb der Bundesverwaltung andere Zielsysteme bedient werden müssen. Die fachliche Aufgabenerledigung muss auch unter Berücksichtigung aller Vorgaben möglich bleiben. Den Behörden obliegt es einen Abwägungs- und Priorisierungsprozess in den verschiedenen Zielsystemen umzusetzen und ggf. somit begründete Ausnahmen von dieser Richtlinie zu stellen. Die Architekturgrundsätze sind zu berücksichtigen (Kapitel 6: Nutzung der Architekturvorgaben).
Architekturvorgaben 23
5 Architekturvorgaben
In diesem Kapitel werden, in Kombination mit den Anhängen 7.1 – 7.5, die geltenden Architekturvorgaben aufgeführt, die berücksichtigt werden müssen, um die zukünftige Konsolidierung der IT des Bundes zu fördern und hierzu gegensätzliche Entwicklungen zu vermeiden.
5.1 Vorlage zur Ermittlung der Architekturvorgaben
Um die praktische Arbeit mit den Architekturvorgaben zu erleichtern, wird jede Architekturvorgabe im Folgenden durch einen eindeutigen Bezeichner und einen aussagekräftigen Titel gekennzeichnet. Für eine einheitliche Darstellung und Lesbarkeit der in diesem Dokument beschriebenen Architekturvorgaben, wurde die folgende, aus dem TOGAF Framework7 adaptierte, Formatvorlage genutzt.
Bezeichner: Bezeichnung der Architekturvorgabe
Beschreibt kurz, verständlich, vollständig und widerspruchsfrei die Beschreibung Architekturvorgabe.
Begründung Darstellung der geschäftlichen Vorteile der Architekturvorgabe.
Beschreibung der Beziehungen zu anderen Architekturvorgaben und der Abhängigkeiten Erläuterung, unter welchen Umständen einer konkurrierenden Architekturvorgabe Priorität eingeräumt wird.
Beschreibung der geschäftlichen und technologischen Auswirkungen der Implikationen Architekturvorgabe auf die Behörden und Dienstleister (z. B. in Bezug auf Ressourcen, Kosten und Aktivitäten / Aufgaben).
7 Weiterführende Informationen finden Sie unter http://pubs.opengroup.org/architecture/togaf8- doc/arch/chap29.html
24 Architekturvorgaben
Ergänzt wird das Template um eine weitere Information, die sich am oberen Rand jeder Vorgabe befindet. Es wird ausgeführt, ob die beschriebene Architekturvorgabe auch zwingend verbindlich für Fachanwendungen gilt. Symbolisiert wird dieser Umstand durch folgende Grafik:
Abbildung 3: Symbolik für Fachanwendungen
Die folgende Tabelle beinhaltet eine Übersicht aller Architekturvorgaben, die in Kapitel 5.2 und dem Anhang 7.1 - 7.5 aufgeführt sind. Sie stellt eine Kurzübersicht dar, um das Prüfen von Abhängigkeiten und das Auffinden von Vorgaben zu erleichtern.
Bezeichner Beschreibung Seite
Übergreifende Architekturvorgaben
ÜBAV-01 Einhaltung der Architekturvorgaben 33
Frühzeitige und vollständige Berücksichtigung der rechtlichen 33 ÜBAV-02 Rahmenbedingungen
ÜBAV-03 Verwendung von Standards und einheitlichen Methoden 34
Gewährleistung der Informationssicherheit, des Datenschutzes und 35 ÜBAV-04 des Geheimschutzes
ÜBAV-05 Orientierung an Referenzarchitekturen 36
ÜBAV-06 Sicherstellung von Benutzerfreundlichkeit und Barrierefreiheit 37
ÜBAV-07 Sicherstellung der Herstellerunabhängigkeit 38
ÜBAV-08 Gewährleistung der Interoperabilität von Anwendungen 39
ÜBAV-09 Sicherstellung von loser Kopplung/Modularität 40
Gewährleistung einer umweltfreundlichen Nutzung von 41 ÜBAV-10 Informationstechnik
Architekturvorgaben 25
ÜBAV-11 Reduzierung der Komplexität auf ein notwendiges Maß 42
Geschäftliche Architekturvorgaben
Beachtung des Praxisleitfadens „Projektmanagement für die 48 GSAV-01 öffentliche Verwaltung“
GSAV-02 Etablierung eines Prozessmanagements 48
Nutzung geeigneter Technologien und Sprachen für die grafische 50 GSAV-03 Modellierung von Prozessmodellen
Nutzung geeigneter Austauschformate für den Austausch von 51 GSAV-04 Prozessmodellen
Architekturvorgaben für Dienste / Anwendungen
DAAV-01 Verbindliche Nutzung von Diensten 54
DAAV-02 Lose Kopplung von Diensten 56
Standardisiert dokumentierte Dienst- und 56 DAAV-03 Schnittstellenbeschreibungen
DAAV-04 Separierung von funktionalen und sicherheitsbezogenen Diensten 57
DAAV-05 Sichere Systemgrundkonfiguration 57
DAAV-06 Vermeidungen undokumentierter Funktionen und Schnittstellen 57
DAAV-07 Nutzung des Dienstes E-Akte 58
DAAV-08 Nutzung des Dienstes Social Intranet des Bundes 60
DAAV-09 Nutzung des Dienstes eNorm 61
DAAV-10 Nutzung des Dienstes eGesetzgebung 62
DAAV-11 Nutzung des Dienstes Digitales Zwischenarchiv des Bundes 63
DAAV-12 Nutzung des Dienstes Bundesclient 65
DAAV-13 Anpassung der Anwendungen an den Bundesclient 67
DAAV-14 Entkopplung der Dienste vom Bundesclient 67
DAAV-15 Migration von Clients 69
DAAV-16 Nutzung des Dienstes Bundescloud 70
26 Architekturvorgaben
Nutzung des Dienstes Audiokonferenzanlage der Pressesprecher der 71 DAAV-17 Ministerien
DAAV-18 Nutzung des Dienstes Bund-TV 72
DAAV-19 Nutzung des Dienstes De-Mail-Gateway 72
DAAV-20 Nutzung von IAM-Funktionalität für Dienste 73
Nutzung verpflichtender Schnittstellen und eines einheitlichen 74 DAAV-21 Modells für die Verwaltung von Identitätsinformationen
DAAV-22 Sicherstellung einer vollständigen Zugriffssteuerung 75
DAAV-23 Nutzung des Dienstes Formular-Management-System (FMS) 76
DAAV-24 Nutzung des Dienstes Government Site Builder (GSB) 77
DAAV-25 Nutzung des Dienstes bund.de 78
DAAV-26 Nutzung des Dienstes E-Payment-Bund 79
DAAV-27 Nutzung des Dienstes Verwaltungsportal und Servicekonto Bund 79
DAAV-28 Nutzung des Dienstes Personalverwaltungssystem 80
Architekturvorgaben für Informationen / Daten
Nutzung von Extensible Markup Language (XML) 1.0 für den 82 IDAV-01 Austausch von Daten
IDAV-02 Nutzung von XÖV zertifizierten Standards 83
IDAV-03 Nutzung von Unified Modeling Language (UML) 2.x 83
IDAV-04 Nutzung von Entity-Relationship-Diagrammen (ERD) 84
Nutzung des Resource Description Framework (RDF) 85 IDAV-05 als Beschreibungssprache für Metadaten im World Wide Web
Nutzung des OSCI-Transport Standards zur rechtsverbindlichen 85 IDAV-06 Übertragung im E-Government
IDAV-07 Nutzung des Enterprise-Content-Management-Modells (ECM) 86
Nutzung von Content Management Interoperability Services 86 IDAV-08 (CMIS) zur Anbindung von Content Management Systemen
IDAV-09 Nutzung von PDF ab Version 1.4 als Austauschformat für 87
Architekturvorgaben 27
unveränderbare Dokumente
Nutzung des Open Document Format (ODF) nach ISO 26300 88 IDAV-10 für veränderbare Dokumente
IDAV-11 Nutzung von einheitlichen Austauschformaten für Bilddateien 88
IDAV-12 Nutzung von einheitlichen Austauschformaten für Mediadateien 89
Verwendung des Formates Multipurpose Internet Mail Extensions 90 IDAV-13 (MIME) zur standardisierten Angabe von Dateiformaten im Internet
Einsatz von APIs, Microservices und API Management zur 90 IDAV-14 Datenbereitstellung
Technische Architekturvorgaben - IT-Infrastruktur
TIAV-01 Beschaffung von Servern mit standardisierter Prozessor-Architektur 92
TIAV-02 Nutzung von Windows oder Linux als Server-Betriebssystem 93
TIAV-03 Nutzung von SQL Datenbanken als Datenbanksystem 93
Nutzung von standardisierten Programmiersprachen für die 94 TIAV-04 serverseitige Anwendungsentwicklung
TIAV-05 Ausschließliche Verwendung von JEE-Applikationsservern 95
Nutzung von quelloffenen Bibliotheken und Werkzeugen bei der 96 TIAV-06 Anwendungsentwicklung
TIAV-07 Verfolgung des Bundescloud-First-Ansatzes (höchst möglicher Level) 96
Sicherstellung von energie- und ressourceneffizienten 98 TIAV-08 Rechenzentrums-dienstleistungen
Verpflichtende Verwendung SOAP- oder REST-basierter 98 TIAV-09 Schnittstellen
Angebot zentraler Dienste erfolgt über behördenübergreifende 99 TIAV-10 gemeinsame Infrastruktur mit geeigneten Trennungsmechanismen
Technische Architekturvorgaben - Netzinfrastruktur
TNAV-01 Geeignete Übernahme der NdB-Segmentierung im Nutzer-LAN 101
TNAV-02 Nutzung von zentral bereitgestellten Kommunikationsverbindungen 102
28 Architekturvorgaben
TNAV-03 Nutzung von Internet Protocol Version 6 (IPv6) als Netzwerkprotokoll 103
Sicherstellung der Skalierbarkeit von NdBA-Anschlussbandbreiten 104 TNAV-04 inkl. Transportnetz
Architekturvorgaben zur Informationssicherheit, Datenschutz und Geheimschutz
Einbindung von IT-Verfahren in ein Business Continuity- und 106 ISAV-01 Krisenmanagement
ISAV-02 Nutzung von Identitäts- und Berechtigungsmanagement (IAM) 107
ISAV-03 Sicherstellung des Datenschutzes aller IT-Verfahren 108
ISAV-04 Sicherstellung des Geheimschutzes aller IT-Verfahren 108
Robustheit und Resilienz gegen gezielte Angriffe, Krisen, Notfälle und 109 ISAV-05 technische Störungen
„Security by Design“, „Privacy by Design“ und „Privacy by Default“ im 110 ISAV-06 Lebenszyklus von IT-Verfahren und Produkten
Festlegung von Schutzbedarf und Dienstgüte (Verlässlichkeit) aller IT- 111 ISAV-07 Verfahren und ihrer Ressourcen
ISAV-08 Einhaltung von BSI-Standards, insbesondere IT-Grundschutz 111
ISAV-09 Sicheres Cloud Computing 112
Erstellung und Umsetzung von Sicherheitskonzeptionen für alle IT- 113 ISAV-10 Verfahren
ISAV-11 Einsatz kryptografischer Verfahren 113
ISAV-12 Separierung / Segmentierung / Mandantentrennung 114
ISAV-13 Logging, Monitoring und Detektion von Anomalien 115
ISAV-14 Einrichtung eines Sicherheitsvorfallmanagements 115
Kontrolle der Einhaltung von Sicherheitsvorgaben (Compliance- 116 ISAV-15 Management)
ISAV-16 Durchführung notwendiger Zertifizierungen 117
ISAV-17 Sicherstellung der Schadprogrammabwehr 117
ISAV-18 Bereitstellung von Schnittstellen- und Protokolldaten 118
Architekturvorgaben 29
ISAV-19 Sicherer Remote-Zugriff (inkl. Fernwartung) 118
ISAV-20 Sichere Digitalisierung von analogen Daten 119
30 Architekturvorgaben
5.2 Übergreifende Architekturvorgaben
Neben Architekturvorgaben für die spezifischen Architekturebenen des Metamodells der Rahmenarchitektur IT-Steuerung Bund existieren grundlegende Rahmenbedingungen, die für alle Architekturebenen gelten. Diese werden im folgenden Kapitel mit Hilfe von übergreifenden Architekturvorgaben vorgegeben. Sie sind als grundlegende Basisprinzipien zu verstehen und müssen bei allen IT- Vorhaben (gemäß Kapitel 3.3) berücksichtigt werden. Die Erarbeitung der Architekturvorgaben basiert auf:
• der Herleitung von Vorgaben aus den architekturrelevanten strategischen Zielen der IT des Bundes, • der Herleitung von Vorgaben aus dem Grobkonzept zur IT-Konsolidierung des Bundes und • der Ableitung allgemeiner Vorgaben aus den Zulieferungen der spezifischen Vorgaben.
Der Zusammenhang zwischen den übergreifenden Architekturvorgaben und den spezifischen Architekturvorgaben des Schichtenmodells ist bereits in Kapitel 4.3 (siehe Abbildung 1) aufgezeigt worden.
Die übergreifenden Architekturvorgaben sollen einen grundlegenden (architektonischen) Bereich abgrenzen, innerhalb dessen die einzelnen Projekte Architekturentscheidungen treffen können. Dieser Bereich wird durch die geschäftlichen Vorgaben, die technischen Vorgaben, die Vorgaben für Dienste und Anwendungen, die Vorgaben für Informationen und Daten sowie die IT-Sicherheitsvorgaben weiter konkretisiert.
Die Gesamtheit dieser Vorgaben bildet für die einzelnen IT-Maßnahmen das Rahmenwerk, auf dessen Grundlage Architekturentscheidungen getroffen werden sollen. Ziel ist es, aus den Vorgaben klare Handlungsempfehlungen entnehmen zu können, um spätere Konsolidierungen der IT zu vereinfachen. Mit Einhaltung der Architekturvorgaben werden durch die Projekte die strategischen IT-Ziele im Sinne des Architekturmanagements eingehalten.
Es folgt eine Übersicht aller übergreifenden Architekturvorgaben und den eng mit diesen Vorgaben verknüpften strategischen Aspekten mit Architekturzusammenhang der IT des Bundes (vgl. Kapitel 4.2). Zu diesem Zweck wurde jedes strategische Ziel mit einer Nummer versehen, die anschließend den Vorgaben zugeordnet wurde.
Architekturvorgaben 31
Abbildung 4: Architekturrelevante strategische Ziele der IT des Bundes
Übersicht zu übergreifenden Architekturvorgaben und den verknüpften strategischen Zielen der IT des Bundes
Identifier Übergreifende Architekturvorgabe Verknüpfte Ziele
ÜBAV-01 Einhaltung der Architekturvorgaben Alle
ÜBAV-02 Frühzeitige und vollständige Berücksichtigung der rechtlichen Rahmenbedingungen
ÜBAV-03 Verwendung von Standards und einheitlichen Methoden
ÜBAV-04 Gewährleistung der Informationssicherheit, des Datenschutzes und des Geheimschutzes
ÜBAV-05 Orientierung an Referenzarchitekturen
32 Architekturvorgaben
ÜBAV-06 Sicherstellung von Benutzerfreundlichkeit und Barrierefreiheit
ÜBAV-07 Sicherstellung der Herstellerunabhängigkeit
ÜBAV-08 Gewährleistung der Interoperabilität von Anwendungen
ÜBAV-09 Sicherstellung von loser Kopplung/Modularität
ÜBAV-10 Gewährleistung einer nachhaltigen Nutzung von
Informationstechnik
ÜBAV-11 Reduzierung der Komplexität auf ein notwendiges Maß
Architekturvorgaben 33
ÜBAV-01: Einhaltung der Architekturvorgaben
Die beschlossenen Architekturvorgaben müssen innerhalb der unmittelbaren Bundesverwaltung gemäß Geltungsbereich (vgl. Kapitel 3.3) Beschreibung eingehalten werden. Es sind insbesondere auch die Architekturgrundsätze zu berücksichtigen (vgl. Kapitel 6).
Die hier formulierten Architekturvorgaben können ihre Wirkung nur dann umfassend entfalten, wenn sie allgemein angewendet und Begründung grundsätzlich bei allen wichtigen Entscheidungen zugrunde gelegt werden.
Die Einhaltung der Architekturvorgaben ist eng verzahnt mit den Abhängigkeiten Vorgaben ÜBAV-02 und ÜBAV-11.
Die Architekturvorgaben sind für alle Mitarbeiter/innen einsehbar, verständlich sowie in der Bundesverwaltung kommuniziert.
IT-Vorhaben werden frühzeitig auf Konformität mit den Implikationen Architekturvorgaben geprüft. Eine Abweichung von den Architekturrichtlinien wird durch die Änderung des IT-Vorhabens oder durch die Vorlage einer Sondergenehmigung durch die Zuständigen gemäß Kapitel 6 korrigiert.
ÜBAV-02: Frühzeitige und vollständige Berücksichtigung der rechtlichen Rahmenbedingungen
Die IT-Systeme der Bundesverwaltung müssen allen Rechtsvorschriften genügen. Rechtliche Vorgaben aus dem nationalen und internationalen Beschreibung Umfeld und ähnliche Rahmenbedingungen werden frühzeitig berücksichtigt.
Die Bundesverwaltung ist in ihrer Gesamtheit verpflichtet, jederzeit alle für sie geltenden Gesetze und Verwaltungsvorschriften zu befolgen. Begründung Verstöße führen schnell zu politischen und rechtlichen Konsequenzen, die es unbedingt zu vermeiden gilt.
34 Architekturvorgaben
Alle Architekturvorgaben haben auch in ihrer Fortschreibung die sich ändernden rechtlichen Rahmenbedingungen zu berücksichtigen. Sich Abhängigkeiten hieraus ergebende Inkompatibilitäten sind frühestmöglich zu bereinigen. Insbesondere die Vorgabe ÜBAV-04 spezifiziert einige der rechtlichen Rahmenbedingungen.
Es ist notwendig, dass die mit der Umsetzung der Richtlinien betrauten Mitarbeiter/innen der Bundesverwaltung die für ihren Tätigkeitsbereich relevanten Gesetze, Verwaltungsvorschriften, und Richtlinien und die Implikationen betreffenden umweltpolitischen Ziele kennen und anwenden. Hierfür sind adäquate Aus- und Weiterbildungsmöglichkeiten sowie eine optimale Informationsbereitstellung notwendig.
ÜBAV-03: Verwendung von Standards und einheitlichen Methoden
IT-Standards, standardisierte Konzepte und Methoden auf der Basis definierter Richtlinien (z. B. BSI-Standards) müssen für die Gestaltung der Beschreibung IT geprüft werden. Auch der zugeschnittene Einsatz von Industriestandards und Vorgehensmodelle wie NAF, V-Modell XT, TOGAF, ITIL© und COBIT ist anzustreben.
Standardisierung fördert die Austauschbarkeit von Informationen und Daten (Interoperabilität) sowie von IT-Systemen und IT-Komponenten (Wiederverwendbarkeit). In Bezug auf Methoden und Konzepte erlaubt die Begründung Standardisierung eine bessere Zusammenarbeit und gemeinsame Abstimmung. Außerdem erleichtert sie die Wartung und ermöglicht eine leichtere und bessere Qualifikation von Fachkräften.
Grundsätzlich ist eine Standardlösung in allen Bereichen einer individuellen Lösung vorzuziehen, sofern dieses unter Wirtschaftlichkeits- und Sicherheitsaspekten vertretbar ist. Zu nutzende Standards werden in Abhängigkeiten den spezifischen Vorgaben (Anhang 7.1 - Anhang 7.5) weiter ausgeführt. Die in einem IT-System darüber hinaus verwendeten Standards können von Richtlinien beteiligter Partner und Kunden außerhalb der Bundesverwaltung mit bestimmt sein. Die Architekturgrundsätze sind
Architekturvorgaben 35
daher frühzeitig zu berücksichtigen (vgl. Kapitel 6).
Standardisierungsstrategien müssen ressortübergreifend (weiter-)entwickelt, beschlossen und umgesetzt werden. Funktionsfähige Implikationen Steuerungsstrukturen werden eingesetzt, um dies durchzusetzen. Standards sind verfügbar, werden kommuniziert und insbesondere in der Beschaffung und Systementwicklung verwendet.
ÜBAV-04: Gewährleistung der Informationssicherheit, des Datenschutzes und des Geheimschutzes
Die Sicherheit schutzwürdiger Daten und Informationen ist ein zentrales strategisches Ziel der IT des Bundes und muss zu jedem Zeitpunkt gewährleistet werden. Daten und Informationen sind vor unbefugtem Beschreibung Zugriff und Missbrauch zu schützen. Weiterhin sind die betriebenen IT- Verfahren, die Verschlusssachen (VS) verarbeiten, nach dem jeweils aktuellen Stand der Technik geheimschutzkonform zu gestalten.
Datenverlust, Verletzung der Datenintegrität, Nicht-Verfügbarkeit oder der Fremdzugriff auf schutzwürdige Daten kann ernsthafte Folgen nach sich ziehen. Zu diesen zählen u. a. rechtliche Folgen, Vertrauensverlust gegenüber den Behörden, Autoritätsverlust und Angreifbarkeit des Staates. Weiterhin werden mit der Einhaltung dieser Vorgabe Gesetzesvorgaben, wie das IT-Sicherheitsgesetz und das BSI-Gesetz, das Sicherheitsüberprüfungsgesetz und die zu dessen Ausführung erlassenen allgemeinen Verwaltungsvorschriften, wie die VSA, oder allgemeine Begründung Sicherheitsvorgaben, wie BSI-Mindeststandards, der die IT-Grundschutz- Kataloge des BSI oder der UP Bund, befolgt. Auch das Bundesdatenschutzgesetz und die Verschlusssachenanweisung sind einzuhalten. Durch die Einhaltung der „Leitlinie zur Informationssicherheit der IT-Konsolidierung Bund“ (Arbeitstitel) (s. Anhang 7.5) wird außerdem die Informationssicherheit, also die Vertraulichkeit, Integrität, Verfügbarkeit und Fähigkeit zur Kontrolle der Informationen, wesentlich gesteigert.
36 Architekturvorgaben
Diese Vorgabe steht in direkter Verbindung zu den Architekturvorgaben zur Informationssicherheit, zum Datenschutz und zum Geheimschutz in Abhängigkeiten Anhang 7.5 und der „Leitlinie zur Informationssicherheit der IT- Konsolidierung Bund“ (Arbeitstitel), welche eine weitere Präzisierung dieser Vorgabe vornehmen.
Unter anderem werden die Rechenzentren kontinuierlich geprüft und zahlreiche Sicherheitsmaßnahmen umgesetzt. Um Informationen und Daten außerdem umfassend zu schützen, ist es zwingend notwendig, deren Schutzbedarf (hinsichtlich Vertraulichkeit, Integrität und Verfügbarkeit) zu klassifizieren und zu bestimmen. Dazu benötigt die IT- Konsolidierung Bund einheitliche Schutzbedarfskategorien, um für die entsprechend gebildeten Gruppierungen Schutzkategorien zu entwickeln. Für einen bedarfsgerechten Schutz dieser Informationen sind Implikationen unterschiedliche technische Schutzklassen mit angemessenen Schutzmaßnahmen zu bilden. Diese Kategorien definieren unter anderem Zugriffsrechte, Ablageorte, Backupstrategien, Maßnahmen zu Schutz vor fremden Zugriffen oder Passwortregeln. Umfassende Informationen werden in diesem Kontext durch die „Leitlinie zur Informationssicherheit der IT-Konsolidierung Bund“ (Arbeitstitel) sowie den IT- Grundschutzkatalog des BSI durch den Leitfaden Informationssicherheit und diverse andere Dokumente zur Verfügung gestellt.
ÜBAV-05: Orientierung an Referenzarchitekturen
Referenzarchitekturen werden, soweit möglich und vorhanden, als Beschreibung Vorlage für die Weiterentwicklung der IT-Architektur verwendet.
Die Orientierung an Referenzarchitekturen im Rahmen der Erstellung von Lösungsarchitekturen und Anlehnung an Branchenstandards fördert die Wirtschaftlichkeit der IT durch Wiederverwendung interner oder Begründung externer, praxiserprobter Lösungsarchitekturen. Auf diese Weise wird eine unnötige Neukonstruktion in diesem Gebiet vermieden. Zudem erleichtert sie die Weiterentwicklung der eigenen Architekturen. Zu beachten ist unter anderem die auf dem OeV – „Organisationskonzept elektronische
Architekturvorgaben 37
Verwaltungsarbeit“ basierende Referenzarchitektur „Referenzarchitektur elektronische Verwaltungsarbeit“. Weitere vorhandene Referenzarchitekturen sind im Kapitel 7.8 aufgelistet.
Die Orientierung an Referenzarchitekturen ist eng verzahnt mit der Abhängigkeiten Vorgabe ÜBAV-03.
Die zukünftigen Lösungsarchitekturen basieren auf praxiserprobten Referenzarchitekturen und lassen hierdurch u. a. weniger Spielraum bei Implikationen Architekturentscheidungen zu. Ggf. sind weitere Referenzarchitekturen zu entwickeln und diese kontinuierlich mit Industriestandards abzugleichen.
ÜBAV-06: Sicherstellung von Benutzerfreundlichkeit und Barrierefreiheit
Die Bedienbarkeit von Anwendungen muss für jeden Benutzer einfach, einheitlich und intuitiv sein. Die zugrundeliegenden Bedienkonzepte müssen den Anwendenden bekannt und transparent sein. Weiterhin Beschreibung sollte, sofern möglich, die Barrierefreiheit der Anwendungen sachgerecht sichergestellt sein. Insbesondere ist hierbei der Industriestandard DIN EN ISO 92418 und die Barrierefreie Informationstechnik Verordnung (BITV) für Webangebote zu beachten.
Wenn die zugrundeliegenden Bedienkonzepte einer Anwendung den Benutzern unbekannt sind, wird die Produktivität des Benutzers negativ beeinträchtigt. Benutzerfreundliche Anwendungen erreichen eine höhere Akzeptanz bei den Anwendenden und fördern ein produktiveres Arbeiten, Begründung eine höhere Qualität und verringern Fehlbedienungen durch die Anwendenden. Aufwände und Kosten werden gespart, da die Bedienung ähnlich zu anderen, gängigen Anwendungen erfolgt, der Schulungsaufwand begrenzt und das Risiko einer unsachgemäßen Bedienung der Anwendung gering ist.
Diese Vorgabe hat Auswirkungen auf die Beschaffung von IT-Ausstattung, Abhängigkeiten da die Gewährleistung der Barrierefreiheit sichergestellt sein muss.
8 Teil 171: Leitlinien für die Zugänglichkeit von Software
38 Architekturvorgaben
Es werden Aspekte wie Sprache, Lokation, Barrierefreiheit, körperliche Einschränkungen der Anwendenden (z. B. Sehschwäche, beschränkte Möglichkeit Tastatur und Maus zu nutzen) und Schulungen beim Design
Implikationen der Anwendung berücksichtigt. Standardisierte Design-Aspekte für die grafische Benutzeroberfläche der Anwendungen werden angewandt (einheitliches Look-and-feel) und moderne Technologien berücksichtigt (z. B. Touchscreen).
ÜBAV-07: Sicherstellung der Herstellerunabhängigkeit
Die Nutzung von herstellerunabhängigen Standards wird, soweit möglich und sinnvoll, sichergestellt und vertraglich festgelegt. Solche Standards können beispielsweise allgemeingültige Notationen wie Business Process Model and Notation (BPMN) oder die Verwendung des allgemeinen Sprachumfangs einer Programmiersprache unter Ausschluss proprietärer Beschreibung Erweiterungen (vgl. SQL) sein. Auch die Nutzung des Open Document Formats (ODF) ist ein Beispiel für herstellerunabhängige Standards. Weiterhin sollen die Standards zur Interoperabilität (bspw. SAGA 5) eingehalten und herstellerspezifische Funktionen der Standards nicht verwendet werden.
Die Herstellerabhängigkeit hat negative Auswirkungen auf die Flexibilität sowie die Gestaltungs- und Handlungshoheit der IT-Architektur in den Behörden. Dies beeinträchtigt das Prinzip der Wirtschaftlichkeit und führt potenziell zu höheren IT-Kosten. Auf langfristige Sicht besteht außerdem Begründung das Risiko, dass durch den Hersteller der Support gekündigt wird oder Lizenzbedingungen für den Bund ungünstig gestaltet werden. Weiterhin kann die Herstellerabhängigkeit zu einem „Lock-in-Effekt“ führen, der in eine schlechtere Verhandlungsbasis resultiert und die Innovationsfähigkeit verringert.
Diese Vorgabe steht in direktem Zusammenhang mit ÜBAV-08 und ÜBAV-09. Beide Vorgaben ermöglichen die Anbindung verschiedener Abhängigkeiten Systeme und fördern somit eine Herstellerunabhängigkeit. Es existieren weiterhin diverse Abhängigkeiten zu spezifischen Vorgaben, die diese
Architekturvorgaben 39
Vorgabe weiter präzisieren.
Benötigte Softwaretechnologien sollten nicht an eine Hardware- Technologie/-Plattform gebunden sein. Die Gewährleistung der Herstellerunabhängigkeit kann aufwändigere Implementierungen – und damit Mehrkosten – durch den Verzicht von einzelnen Implikationen herstellerabhängigen Funktionen nach sich ziehen. Darüber hinaus können weitere Risiken durch die Nutzung von Schnittstellen zwischen verschiedenen Frameworks entstehen. Es muss eine hohe Bereitschaft zur Weiterbildung bei dem Personal vorhanden sein.
ÜBAV-08: Gewährleistung der Interoperabilität von Anwendungen
Ein maßgeblicher Faktor bei der Neu- und Weiterentwicklung sowie der Beschaffung von Software ist die Interoperabilität. Sie ermöglicht eine einheitliche Vernetzung von Systemen und erleichtert den Datenaustausch. Interoperabilitätsstandards müssen grundsätzlich angewendet werden, um eine einfache Integration unterschiedlicher Anwendungen und Technologien zu ermöglichen. Hiermit sind insbesondere geeignete Austauschformate (z. B. XML, XÖV-Standards) und Beschreibung wichtige semantische Standards gemeint (vgl. Anhang 7.3). Die rechtliche und organisatorische Interoperabilität wird außerhalb des Architekturmanagements sichergestellt. Für Anwendungen, die europaweit eingesetzt werden können, ist weiterhin das European Interoperability Framework (EIF) zu berücksichtigen. Dieses hat zum Ziel die grenz- und sektorübergreifende Interaktion zwischen europäischen Verwaltungen zu erleichtern und zu fördern. Ähnliches gilt für die Zusammenarbeit mit anderen Kooperationspartnern.
Neben den bekannten Vorteilen der Nutzung von Standards (u. a. Austauschbarkeit, Flexibilität, erhöhte Kompatibilität), ermöglicht die Begründung Nutzung von Interoperabilitätsstandards auch die Zusicherung mehrerer Hersteller hinsichtlich Produktunterstützung und fördert das Zusammenspiel und die Integration zu anderen Anwendungen und
40 Architekturvorgaben
Technologien. Weitere Vorteile, die durch Einhaltung dieser Vorgabe entstehen, sind die Vermeidung von Medienbrüchen und die Ermöglichung von „Best-of-Breed“ Architekturen im Gegensatz zu den Lock-in-Effekt begünstigenden, monolithischen Architekturen. Im Bereich der NATO gilt die Allied Data Publication 34 (ADatP-34), „NATO Interoperability Standards and Profiles (NISP)“, STANAG 5524.
Die Architekturvorgabe ergänzt und erweitert ÜBAV-03. Weiterhin steht sie in direktem Bezug zur Vorgabe ÜBAV-07, da diese Vorgabe ebenfalls Abhängigkeiten die Interoperabilität fördert. Diese Vorgabe wird weiterhin durch folgende spezifischen Vorgaben ergänzt: IDAV-01, IDAV-02 und TIAV-06.
Es werden Interoperabilitäts- und Industriestandards, wie beispielsweise Implikationen die vereinheitlichte erweiterbare Firmware-Schnittstelle (UEFI), befolgt.
ÜBAV-9: Sicherstellung von loser Kopplung/Modularität
Anwendungen und Dienste müssen nach dem Baukastenprinzip modular aufgebaut werden. Jedes Modul soll eigenständig nutzbar sein und entsprechend unabhängig weiterentwickelt, aktualisiert und betrieben Beschreibung werden können. Der funktionale Umfang eines Moduls soll sich hierbei an klar definierten, funktionalen Domänen sowie an etablierten Referenzarchitekturen orientieren.
Das Ergebnis nicht-modular aufgebauter Anwendungen sind nicht anpassungsfähige und inflexible Anwendungen verbunden mit hohen Kosten und Aufwänden. Eine lose Kopplung ermöglicht es, Änderungen an einzelnen Komponenten des Systems einfacher durchzuführen und vereinfacht auch die Wartbarkeit der Komponenten, da diese unabhängig Begründung von anderen Komponenten durchgeführt werden kann (ausgenommen Schnittstellen). Weiterhin gewährleistet die Modularisierung eine Wiederverwendbarkeit und ermöglicht ein strukturiertes Testvorgehen. Außerdem sind modularisierte Anwendungen aufgrund der klaren Abgrenzungen der Teilkomponenten einfacher zu verwalten.
Abhängigkeiten Diese Vorgabe steht in engem Zusammenhang mit den Vorgaben
Architekturvorgaben 41
ÜBAV-07 und ÜBAV-08, da sich die entsprechenden Vorgaben gegenseitig ergänzen. Außerdem wird diese Vorgabe durch DAAV-02 für Dienste weiter spezifiziert.
Implikationen Keine Implikationen.
ÜBAV-10: Gewährleistung einer umweltfreundlichen Nutzung von
Informationstechnik
Es ist über den gesamten Lebenszyklus der Informationstechnik auf einen umweltfreundlichen Einsatz zu achten. Dies beinhaltet insbesondere die Beschaffung, den Betrieb und die Entsorgung von Informationstechnik. Zu berücksichtigen sind beispielsweise die Leitfäden für umweltfreundliche Beschaffung des Umweltbundesamtes in den Ausschreibungen der Bundesverwaltung für Geräte der IKT, insbesondere für PCs, Notebooks, Monitore und Drucker. Weiterhin ist der Leitfaden des Beauftragten der Bundesregierung für Informationstechnik zur Optimierung des Energieverbrauches des IT-Betriebes zu befolgen. Bei Ausschreibungen sind, wo möglich, die Kriterien des Umweltzeichens „Blauer Engel“ zu Beschreibung verwenden; ansonsten sollen die Kriterien oder Standards des Europäischen Umweltzeichens, des Energy Star oder vergleichbarer Label zur Anwendung kommen.
Zusätzlich sind jegliche IT-Lösungen so zu konzipieren, dass der Ressourcenverbrauch über den gesamten Lebenszyklus minimiert wird und gleichzeitig möglichst hohe Nutzungszeiten realisiert werden.
Um Ressourcen zu schonen ist funktionstüchtige IKT darüber hinaus nach dem Nutzungsende in den Behörden dem ReUse-Markt zur Verfügung zu stellen oder fachgerecht zu verwerten.
Mit dieser Maßnahme werden die Regelungen der Allgemeinen Verwaltungsvorschrift zur Beschaffung energieeffizienter Produkte und Dienstleistungen (AVVEnEff) eingehalten. Die Verpflichtungen aus dem Begründung Maßnahmenprogramm Nachhaltigkeitsstrategie für Deutschland (Beschluss März 2015), aus dem Aktionsprogramm zum Klimaschutz 2020, dem Deutschen Ressourceneffizienzprogramm II und der Digitalen Agenda
42 Architekturvorgaben
2014 – 2017 werden hiermit ebenso erfüllt. Grundlage der Vorgabe bilden weiterhin diverse Beschlüsse des IT-Rates. Durch die Umsetzung dieser Kriterien kann der Energieverbrauch reduziert und natürliche Ressourcen geschont werden. Darüber hinaus können mit dieser Maßnahme die Kosten für Energie reduziert werden. Die Berücksichtigung von Umweltkriterien bei der Anschaffung garantiert eine gute Qualität und Haltbarkeit von IT- Geräten.
Diese Vorgabe hat insbesondere Abhängigkeiten zu den Vorgaben Abhängigkeiten TIAV-01 und TIAV-08. Sie schränkt diese Vorgaben weiter ein oder wird durch sie konkretisiert.
Die Anschaffungskosten für IT-Ausrüstung können im Zusammenhang mit Implikationen dieser Richtlinie steigen, da umweltfreundliche Geräte häufig preisintensiver sind.
ÜBAV-11: Reduzierung der Komplexität auf ein notwendiges Maß
Ein wesentlicher Erfolgsfaktor für den Aufbau und langfristigen Betrieb umfangreicher IT-Systeme und Applikationen ist die Reduzierung der Komplexität auf ein notwendiges Maß. Hierbei gilt der Grundsatz, dass die Komplexität so hoch wie nötig und so gering wie möglich zu halten ist. Der Begriff Komplexität ist je nach Anwendungsgebiet selbstständig zu definieren. So kann beispielsweise innerhalb der Anwendungsentwicklung als Maßstab die Anzahl von Codezeilen je Methode herangezogen werden. Beschreibung Aus Gesamtarchitektursicht können die Anzahl und der Umfang von Schnittstellen relevant sein. Insbesondere durch eine einheitliche und ausführliche Dokumentation aller Komponenten werden Redundanzen verhindert und somit die Komplexität verringert. Auch eine klare Funktionstrennung der verschiedenen Anwendungen und Systembestandteile, sowie ein modularer Aufbau von Software sind notwendige Voraussetzungen.
Anwendungen und IT-Systeme mit einer verwaltbaren Komplexität sind Begründung zukunftssicher, erweiterbar und verringern langfristig die Kosten des Betriebes und der Wartung. Außerdem verringern sie das Risiko von
Architekturvorgaben 43
Fehlern.
Es bestehen Abhängigkeit zu ÜBAV-09 und ÜBAV-03. Beide Vorgaben unterstützen die Verringerung der Komplexität auf ein notwendiges Maß Abhängigkeiten oder ermöglichen eine bessere Beherrschbarkeit der vorhandenen Komplexität.
Alle Artefakte der Rahmenarchitektur (inkl. der verschiedenen Sichten) werden dokumentiert und publiziert. Um eine nachvollziehbare Implikationen Darstellung zu gewährleisten müssen geeignete Hilfsmittel (Tools, Standards) definiert und bereitgestellt werden.
44 Architekturvorgaben
5.3 Spezifische Architekturvorgaben
Die Gesamtheit der zugelieferten und konsolidierten spezifischen Architekturvorgaben befindet sich in den Anhängen 7.1 – 7.5. Eine Auslagerung in den Anhang wurde vorgenommen, um die Fortschreibung und Aktualisierung der entsprechenden Vorgaben zu vereinfachen.
Nutzung von Architekturvorgaben 45
6 Nutzung von Architekturvorgaben
In diesem Kapitel werden grundlegende Prämissen zur Nutzung und Mechanismen zur Sicherstellung der Einhaltung von Architekturvorgaben definiert. Zur Erstellung und fortlaufenden Überprüfung der in diesem Dokument dargelegten Architekturvorgaben wird der im Governance Framework COBIT 59 definierte Richtlinien-Lebenszyklus herangezogen. COBIT 5 wird innerhalb des TOGAF Frameworks als Referenzwerk für IT-Governance genutzt, da es einen offenen Standard zur Steuerung der IT darstellt. Der Richtlinien-Lebenszyklus dieser Architekturrichtlinie orientiert sich daher an den in der folgenden Abbildung erkennbaren Phasen:
Abbildung 5: Richtlinien-Lebenszyklus COBIT 5
Jede der im COBIT Framework aufgeführten Phasen beinhaltet klar definierte Vorgehensweisen, die zur Erarbeitung von Prüfungs- und Steuerungsmechanismen berücksichtigt wurden. Aus diesen Mechanismen wurden anschließend die folgenden Grundsätze abgeleitet, die bei der Nutzung und Einhaltung der Architekturrichtlinie für die IT des Bundes zu beachten sind:
1. Die Beachtung der in diesem Dokument aufgeführten Architekturvorgaben ist bei der IT- Leistungserbringung sowie der IT-Beschaffung (gemäß Zielbild zur Beschaffungsbündelung - Teilprojekt 5) der unmittelbaren Bundesverwaltung gemäß Geltungsbereich (vgl. Kapitel 3.3) verbindlich. Die Freigabe der Ausnahmen erfolgt, wie
9 http://www.isaca.org/COBIT/Pages/default.aspx
46 Nutzung von Architekturvorgaben
im Maßgabebeschluss vom 17.6.2015 (ADrs. 18(8)2134, Abs. II Ziff 4) verankert, durch den IT-Rat.
2. Die Behörden sollten einen permanenten Feedbackprozess etablieren, um eine regelmäßige Prüfung und mögliche Anpassung der Vorgaben aus dem operativen Geschäft heraus zu gewährleisten. Sollten bei Prüfung und Einhaltung der Architekturvorgaben Unklarheiten auftreten, so ist der entsprechend zuständige Bereich (siehe 3) zu kontaktieren. Die Überprüfung der geeigneten Einhaltung der Richtlinie ist durch das jeweilige Ressort / die Behörden selbst vorzunehmen.
3. Konkret sind folgende Zuständigkeiten festgelegt:
a) Für die übergreifenden Architekturvorgaben ist bis auf weiteres die Gesamtprojektleitung des Vorhabens „IT-Konsolidierung Bund“ verantwortlich. Die Weiterführung als Daueraufgabe liegt in der Zuständigkeit der Aufbauorganisation des BfIT (derzeit Referat ITI3 im BMI). b) Für die Architekturvorgaben des geschäftlichen Modells ist die Abteilung O im BMI bzw. der von der Abteilung O geleitete ressortübergreifende Ausschuss für Organisationsfragen (AfO) verantwortlich. c) Für die Architekturvorgaben des Dienstemodells ist das Teilprojekt 6 (PG GIB im BMI) des Vorhabens „IT-Konsolidierung Bund“ und für die Weiterführung als Daueraufgabe die noch zu etablierende NMO10 verantwortlich. d) Für die Architekturvorgaben des technischen Modells und des Informationsmodells ist das ITZBund vor dem Hintergrund seiner Vorsitzfunktion und der damit verbundenen koordinierenden Rolle im Anbieterbeirat des IT-Leistungsverbundes federführend verantwortlich. Das ITZBund stimmt sich eng mit dem BWI und den anderen IT-Dienstleistern des Bundes ab. Für netzrelevante Vorgaben ist das Projekt NdB zuständig. e) Für die Architekturvorgaben zur Informationssicherheit ist das BSI in Abstimmung mit dem BMI verantwortlich. Die Aktualisierung der mit der Informationssicherheit eng verbundenen Architekturvorgaben zum Datenschutz und Geheimschutz wird von der Gesamtprojektleitung koordiniert.
10 Die Nachfragemanagementorganisation (NMO) ist ein Bestandteil des Vorschlags zur Weiterentwicklung der IT-Steuerung des Bundes.
Nutzung von Architekturvorgaben 47
Abbildung 6: Darstellung der Zuständigkeiten für die Architekturrichtlinie auf Grundlage des Metamodells der Rahmenarchitektur IT-Steuerung Bund
4. Dieses Dokument ist fortan in einem stetigen Prozess fortzuschreiben, um ein Höchstmaß an Aktualität und einen optimalen Umfang zu erreichen. Sofern ein Grundsatz veraltet ist oder einer Überarbeitung bedarf, werden die unter 3 genannten Verantwortlichkeiten diesen Umstand an die Gesamtprojektleitung melden. Ferner fordert die Gesamtprojektleitung die Verantwortlichen der jeweiligen Bereiche (siehe 3) dazu auf, die Architekturvorgaben in ihrem Verantwortungsbereich einer jährlichen Prüfung auf Aktualität zu unterziehen. Die Fortschreibung und Aktualisierung dieser Architekturrichtlinie ist eine strategische und damit ministerielle Aufgabe. Bis zur Übergabe der Aufgaben im Rahmen des übergreifenden Architekturmanagements an die Regelorganisation liegt die Verantwortung für die Fortschreibung der „Architekturrichtlinie für die IT des Bundes“ bei der Gesamtprojektleitung des Vorhabens „IT-Konsolidierung Bund“. Eine Beteiligung der zentralen IT-Beschaffung wird dabei sichergestellt, um im Rahmen neuer oder angepasster Architekturvorgaben Konformität mit vergaberechtlichen Voraussetzungen sowie laufenden Verfahren zu gewährleisten. Die Fortschreibung ist vorerst in einem jährlichen Turnus geplant. Es ist eine Vorlage der jeweils aktuellen Version der Architekturrichtlinie bei der Konferenz der IT-Beauftragten sowie beim IT-Rat vorgesehen.
48 Anhänge
7 Anhänge
7.1 Geschäftliche Architekturvorgaben
Dieser Anhang beinhaltet Vorgaben mit einem Bezug zu Projekt- und Prozessmanagement von Behörden.
GSAV-01: Beachtung des Praxisleitfadens „Projektmanagement für die öffentliche Verwaltung“
Zur Einführung von IT-Systemen und Durchführung von IT-Maßnahmen ist grundsätzlich die Beachtung des Praxisleitfadens „Projektmanagement für die öffentliche Verwaltung“ vorgeschrieben. Der Leitfaden auf der Website www.bmi.bund.de unter „Praxisleitfaden Projektmanagement für die Öffentliche Verwaltung“ zu finden. Weiterhin ist außerdem bei der Beschreibung Durchführung von Organisationsprojekten das Organisationshandbuch zu berücksichtigen. Weitere Regelungen wie z.B. das V-Modell XT bleiben davon unberührt (vgl. S. 7 Praxisleitfaden.). Der Einsatz neuer Methoden zum agilen Projektmanagement ist als Alternative zu den hier vorgeschlagenen klassischen Methoden möglich.
Die Einführung von IT-Systemen und der entsprechenden Erhebung und Anpassung der Verwaltungsabläufe sollte im Rahmen eines Projektes Begründung erfolgen. Wesentliche Aspekte zum Aufbau und zur Durchführung von Projekten sind im „Praxisleitfaden Projektmanagement für die Öffentliche Verwaltung“ dargestellt.
Abhängigkeiten Keine Abhängigkeiten vorhanden.
Implikationen Keine Implikationen vorhanden.
GSAV-02: Etablierung eines Prozessmanagements
Es wird die Etablierung eines Prozessmanagements in den Behörden unter Beschreibung Berücksichtigung der in der UAG Prozessmanagement erarbeiteten,
Anhänge 49
ressortübergreifenden Grundlagen und der Ergebnisse der Arbeitsgruppen des Netzwerks Prozessmanagement empfohlen. Zudem wird derzeit der DIN Fachbericht 158 „Handlungsleitfaden für ein strategisches und operatives Prozessmanagement in der öffentlichen Verwaltung“ überarbeitet. Sofern für die Etablierung eines Prozessmanagements Beratungsbedarf besteht, können die Beratungsleistungen der Kompetenzzentren Prozessmanagement (CC PM) genutzt werden. Zusätzlich sind die Muster- und Referenzprozesse aus den Bereichen Haushalt und Beschaffung sowie das Referenzmodell des Projektes E- Beschaffung und das Vorgehensmodell des Projektes e-Akte die Grundlage für die Architekturen in diesen Bereichen. Diese sind auf dem BSCW-Server eingestellt.
Nach § 9 Absatz 1 EGovG sollen Behörden des Bundes Verwaltungsabläufe, die erstmals zu wesentlichen Teilen elektronisch unterstützt werden, vor Einführung der informationstechnischen Systeme unter Nutzung gängiger Methoden dokumentieren, analysieren und optimieren. D. h. Prozesse sollen erhoben, dargestellt (als Prozessmodell - IST-Prozess), bewertet und verbessert (SOLL-Prozess) werden.
Zur Unterstützung des Prozessmanagements in den Bundesbehörden enthält das Regierungsprogramm „Digitale Verwaltung 2020“ das Projekt „Ausbau bundeseigener IT- und Prozessberatung“. Im Rahmen dieses Projektes wurde u. a. ein fachliches Netzwerk Prozessmanagement (Netzwerk PM) eingerichtet. Begründung Das Netzwerk PM trifft sich regelmäßig und erarbeitet in zwei Arbeitsgruppen folgende Empfehlungen und Lösungen entsprechend der Projektziele:
- Erstellung eines ressortübergreifenden Glossars zum Prozessmanagement
- Erarbeitung eines Werkzeugkastens
- Erstellung eines Basispapiers Strategisches PM in der öffentlichen Verwaltung (für Einsteiger/innen, Organisatoren/innen und Führungskräfte)
- Katalog/Sammlung mit Best Practice Beispielen
Die Ergebnisse der AGs und damit des Netzwerkes PM sollen bis Ende 2016
50 Anhänge
vorliegen.
Die Vorgaben GSAV-03 und GSAV-04 konkretisieren diese Vorgabe durch Abhängigkeiten die Aufführung geeigneter Technologien und Sprachen.
Nach § 9 Absatz 1 EGovG sollen Behörden des Bundes Verwaltungsabläufe, die erstmals zu wesentlichen Teilen elektronisch unterstützt werden, vor Implikationen Einführung der informationstechnischen Systeme unter Nutzung gängiger Methoden dokumentieren, analysieren und optimieren.
GSAV-03: Nutzung geeigneter Technologien und Sprachen für die grafische Modellierung von Prozessmodellen
Folgende grafische Modellsprachen und Notationen für Prozesse sind aus dem SAGA 5 Standard übernommen und aktualisiert worden:
• UML 2.x
UML ist eine standardisierte grafische Modellierungssprache zur Spezifikation, Visualisierung und Dokumentation von Systemen. Sie erlaubt die Modellierung von Software-Architekturen, Geschäftsprozessen, Datenstrukturen, Datenbankschemata, Informationsflüssen und Aktivitäten. UML 2.x sollte zur Vorbereitung und Dokumentation von großen Projekten für objektorientierte Modellierung angewendet werden. Beschreibung • Flussdiagramme
Flussdiagramme sind eine grafische Notation für den Ablauf eines Programms. Die Strukturierung eines Software-Systems sollte durch Flussdiagramme und die zusätzliche Anwendung von Rollenmodellen erfolgen, die die Flussdiagramme, durch Angabe zu den Nutzern des Systems, ergänzen.
• Business Process Modeling Notation (BPMN) 2.0
BPMN ist eine grafische Notation zur Modellierung und Ausführung von Geschäftsprozessen. Sie eignet sich vor allem für alle Softwareentwicklungsprojekte und organisatorischen Maßnahmen, in
Anhänge 51
denen lediglich eine grobe Modellierung verschiedener Detaillierungsgrade benötigt wird. Die Wahl oder Nutzung geeigneter Modellsprachen und Notationen (BPMN, EPK, DMN, CMMN, UML) sollte in Abhängigkeit des jeweiligen IT-Projektes oder Prozessgegenstandes gewählt werden. Eine Abgrenzung und damit Einschränkung von Methoden ohne vorherige Klassifizierung des Prozessgegenstandes, der IT-Ausrichtung oder des IT-Projekts, auf die sie angewendet werden sollen, ist zu vermeiden.
• Ereignisgesteuerte Prozesskette (EPK)
Die EPK dient der Abbildung von Abläufen innerhalb von und zwischen Organisationen. Prozessketten beschreiben die zeitlich- logischen Abläufe und das Zusammenspiel zwischen Daten, Prozessschritten, IT-Systemen, Organisationen und Produkten. EPK kann für die Darstellung von Geschäftsprozessen in Verbindung mit der Organisationsentwicklung eingesetzt werden. Auch einfache technisch-funktionale Prozessmodelle, insbesondere für die fachliche Grobkonzeption, sollten durch EPK dargestellt werden.
Die korrekte Abbildung von Prozessen ist eine elementare Voraussetzung für die zukünftige IT-Ausrichtung der Bundesverwaltung. Mit vollständig modellierten Prozessen lassen sich Entscheidungen bezüglich der IT- Begründung Ausrichtung schneller und effizienter treffen. Die aufgeführten Vorgaben sind Standards in Lehre und Forschung und sind somit erprobt und verlässlich und werden bereits in einigen Ressorts (u.a. GB BMVg) erfolgreich angewendet.
Abhängigkeiten Diese Vorgabe spezifiziert einen Teilaspekt der Vorgabe GSAV-02.
Den entsprechenden Modellierern müssen geeignete IT-Tools zur Implikationen Verfügung gestellt werden.
GSAV-04: Nutzung geeigneter Austauschformate für den Austausch von Prozessmodellen
Beschreibung Um einen reibungslosen Austausch von Prozessmodellen über
52 Anhänge
verschiedene Nutzer, Tools und Behörden zu ermöglichen, ist es notwendig, Austauschformate zu definieren. Folgende Austauschformate können für Prozessmodelle genutzt werden:
• XML Metadata Interchange (XMI) 2.x (UML Diagramme) • XML Process Definition Language (XPDL) 2.1 (BPMN) • EPML (EPK-Prozessketten)
Durch die Nutzung von einheitlichen, offenen Austauschformaten Begründung können Prozessmodelle ohne Abhängigkeiten zu Herstellern oder Technologien ausgetauscht werden.
Abhängigkeiten Diese Vorgabe erweitert die Vorgabe GSAV-03.
Die genutzten IT-Tools müssen die entsprechenden Austauschformate unterstützen und geeignete Schnittstellen bereitstellen. Das BMI wird als Maßnahmenverantwortlicher ein Evaluierungsprojekt der Implikationen Prozessmanagementtools (inkl. Prozessmodellierungstools) durchführen, da bis 2025 in den zentralen IT-Dienstleistern nur noch maximal zwei Basisdienste bzw. Querschnittsdienste zum Prozessmanagement inkl. Prozessmodellierung bereitgestellt werden sollen.11
11 Vorbehaltlich der Verabschiedung des IT-Rahmenkonzeptes 2018 durch den IT-Rat
Anhänge 53
7.2 Architekturvorgaben für Dienste / Anwendungen
Dieser Anhang beinhaltet Architekturvorgaben, die sich auf die Nutzung von Diensten beziehen. Ein Dienst ist hierbei eine logische Einheit, die einen definierten Umfang an funktionalen Anforderungen erfüllt. Innerhalb der Rahmenarchitektur IT-Steuerung Bund stellt der Dienst eine Beschreibungseinheit zur Strukturierung der IT-Unterstützung für geschäftliche und fachliche Anforderungen dar. Übergreifende Architekturvorgaben besitzen dabei eine Gültigkeit über die Grenzen einer Maßnahme bzw. eines Dienstes hinweg.
In den folgenden vier Architekturdomänen sind die Dienste bezogenen Architekturvorgaben strukturiert:
• Elektronische Verwaltungsarbeit, • Infrastrukturdienste, • E-Government und • ERP.
Diese beziehen sich dabei im Einzelnen auf folgende Kategorien:
• Architekturvorgaben zu funktionalem Umfang (eines Dienstes) • Architekturvorgaben zu Schnittstellen (zwischen Diensten) • Architekturvorgaben zu Standards und Normen (für einen Dienst oder für eine Schnittstelle) • Architekturvorgaben zu Nutzungsvoraussetzungen (eines Dienstes) • Architekturvorgaben zur Qualität (eines Dienstes) • Architekturvorgaben zur Sicherheit (eines Dienstes)
Bei Bedarf können weitere Kategorien gebildet werden.
Die Architekturrichtlinien für die Dienste wurden in einem hier dokumentierten ersten Schritt entlang der Funktionalitäten der Maßnahmenbeschreibungen des IT-Rahmenkonzeptes erstellt. In der Weiterentwicklung werden sich die Architekturrichtlinien für Dienste stärker auf die Abgrenzung innerhalb eines für 2017 anvisierten umfassenden Dienstemodells mit Fokus auf die funktionalen Beschreibungen von Diensten beziehen.
54 Anhänge
7.2.1 Übergreifende Architekturvorgaben für Dienste
DAAV-01: Verbindliche Nutzung von Diensten
Die Dienste der Gemeinsamen IT des Bundes (GIB) sind grundsätzlich verbindlich zu nutzen. Zur Nutzung der Dienste ist im IT Rahmenkonzept des Bundes bereits folgende Regelung enthalten:
„Das IT-Rahmenkonzept des Bundes ist das für alle Ressorts verbindliche Planungsinstrument für ressortübergreifende Vorhaben. In der Ressortplanung können keine Haushaltsmittel für die parallele Entwicklung etatisiert werden, die bereits durch ressortübergreifende IT- Maßnahmen im IT-Rahmenkonzept des Bundes abgedeckt sind. Für die Fortführung alternativer IT-Anwendungen dürfen Mittel nur veranschlagt werden, soweit dies wirtschaftlich ist. Im IT-Rahmenkonzept des Bundes werden also die ressortübergreifend zu nutzende Basis- und Querschnitts- IT sowie zentrale IT-Infrastrukturen festgelegt.“ (siehe IT-Rahmenkonzept des Bundes 2018 Einleitung S.5)
Diese Regelung wird wie folgt weiter konkretisiert:
• Die geplanten und produktiven Dienste der GIB sind durch Beschreibung Maßnahmen des jeweiligen IT-Rahmenkonzeptes repräsentiert. • Die Wirtschaftlichkeit des Einsatzes eines Dienstes der Gemeinsamen IT des Bundes (GIB) für die Bundesverwaltung wird zentral durch TP6 festgestellt.
• Die Nutzungsverpflichtung der Dienste der GIB umfasst die gesamte unmittelbare Bundesverwaltung. • Der Nutzungsrahmen der Dienste der GIB betrifft den jeweiligen Funktionsumfang im definierten Anwendungsbereich des Dienstes der GIB gemäß Anlage 7.6. • Die Verpflichtung zur Nutzung des Dienstes der GIB tritt mit dem Zeitpunkt der Verfügbarkeit (Produktivsetzung) des Dienstes, ersichtlich aus dem (durch den IT-Rat verabschiedeten) Produktkatalog des Verbundes der IT-Dienstleister des Bundes, ein.
Sowohl für produktive als auch für geplante Dienste der GIB im definierten Funktionsumfang gemäß der Dienstekurzbeschreibung dürfen also abweichende Lösungen nicht mehr neu beschafft oder neu entwickelt
Anhänge 55
werden.
Bestehende abweichende Lösungen derselben Funktionalität sind mit dem nächsten grundlegenden Versionswechsel durch die entsprechenden Dienste der GIB abzulösen. Sofern seitens der Maßnahme der GIB keine zentrale Migrationsstrategie abgestimmt wird, sind entsprechende Migrationsstrategien, insbesondere bestehend aus der Machbarkeitsprüfung, der Zielsetzung und der groben zeitlichen, finanziellen sowie organisatorischen Abschätzung der Migration, frühzeitig, spätestens zum Endes des zwölften Monats nach der Produktivsetzung der Dienste der GIB zu erstellen. Für bereits produktive Dienste der GIB sind die Migrationsstrategien bis spätestens Ende 2017 zu erstellen.
Zur Gewährleistung der notwendigen Interoperabilität sind bei der Beschaffung, Entwicklung und Weiterentwicklung von Anwendungen und Diensten, welche die Dienste der GIB nutzen sollen, die entsprechenden Nutzungsvoraussetzungen, Schnittstellen und diese Architekturrichtlinie einzuhalten.
Für eine Harmonisierung und Konsolidierung der IT des Bundes ist die verbindliche Nutzung gemeinsamer Basis- und Querschnittsdienste Begründung unabdingbar. Weiterhin dürfen bei Basis- und Querschnittsdiensten maximal zwei parallele Lösungen entstehen.
Diese Architekturvorgabe hat übergreifende Bedeutung für alle Abhängigkeiten Architekturvorgaben, die den funktionalen Umfang und Anwendungsbereich eines Dienstes der GIB festlegen.
Für alle Funktionen und Anwendungsbereiche, für die Basis- und Querschnittsdienste der GIB bereitgestellt werden, werden die evtl. Implikationen vorhandenen eigenen Lösungen zukünftig abgelöst. Anwendungen und Dienste, die die entsprechenden Funktionen nutzen, werden entsprechend umgestellt.
56 Anhänge
7.2.2 Allgemeine Architekturvorgaben für Dienste
DAAV-02: Lose Kopplung von Diensten
Alle logischen Komponenten müssen über dedizierte Dienste gekapselt werden, die über wohl definierte Schnittstellen nachrichtenbasiert Beschreibung miteinander kommunizieren. Dabei müssen die Dienste austauschbar und nur lose gekoppelt sein, um die Voraussetzung für eine Eigenständigkeit auf Dienstebene zu schaffen.
Die lose Kopplung von Diensten ermöglicht nicht nur die einfache Wiederverwendbarkeit von einzelnen Funktionen, sondern ermöglicht auch die leichtere Integrierbarkeit von Funktionalität der Begründung Zugriffssteuerung. So können in einer entsprechenden Konfiguration beispielsweise sämtliche Nachrichtenflüsse von und zum Dienst gesteuert werden.
Abhängigkeiten bestehen zu allen Architekturvorgaben, Maßnahmen und Abhängigkeiten Vorhaben, welche diese allgemeine Vorgabe einhalten müssen. Weiterhin konkretisiert diese Vorgabe die Architekturvorgabe ÜBAV-09 für Dienste.
Die allgemeinen Vorgaben sind grundsätzlich bei Entwurf, Entwicklung Implikationen und Bereitstellung von Diensten zu berücksichtigen.
DAAV-03: Standardisiert dokumentierte Dienst- und
Schnittstellenbeschreibungen
Die durch einen Dienst angebotenen Schnittstellen müssen detailliert, hinsichtlich ihrer Ein- und Ausgabeparameter sowie ihres Verhaltens, Beschreibung beschrieben werden. Dabei müssen standardisierte bzw. weit verbreitete Beschreibungssprachen verwendet werden.
Soll der Zugang zu Diensten oder der Zugriff auf durch diese angebotenen Operationen anderen Diensten ermöglicht werden, ist es erforderlich, die Begründung genaue Beschreibung der jeweiligen Schnittstelle zu kennen, um mit dieser interoperieren zu können.
Abhängigkeiten bestehen zu allen Architekturvorgaben, Maßnahmen und Abhängigkeiten Vorhaben, welche diese allgemeine Vorgabe einhalten müssen. Weiterhin besteht ein enger Zusammenhang zu ÜBAV-11, da zur
Anhänge 57
Komplexitätsreduzierung eine umfangreiche Dokumentation notwendig ist. Weiterhin ist für die Durchführung der Dokumentation die Vorgabe GSAV-03 zu beachten.
Die allgemeinen Vorgaben sind grundsätzlich bei Entwurf, Entwicklung Implikationen und Bereitstellung von Diensten zu berücksichtigen.
DAAV-04: Separierung von funktionalen und sicherheitsbezogenen Diensten
Funktionale Dienste müssen klar von Diensten zur Gewährleistung der Beschreibung Sicherheit separiert werden.
Die Gewährleistung der Sicherheit wird über entsprechende sicherheitsbezogene Dienste gekapselt, die von den funktionalen Diensten Begründung genutzt werden. Hierdurch wird Redundanz vermieden und die Nachnutzbarkeit der sicherheitsbezogenen Dienste gestärkt.
Abhängigkeiten bestehen zu allen Architekturvorgaben, Maßnahmen und Abhängigkeiten Vorhaben, welche diese allgemeine Vorgabe einhalten müssen.
Die allgemeinen Vorgaben sind grundsätzlich bei Entwurf, Entwicklung Implikationen und Bereitstellung von Diensten zu berücksichtigen.
DAAV-05: Sichere Systemgrundkonfiguration
Alle relevanten Sicherheitseinstellungen müssen bereits in der Beschreibung Grundkonfiguration des Dienstes aktiviert sein (Security-by-Default).
Nur wenn bereits in der Grundkonfiguration eines Dienstes relevante Sicherheitsfestlegungen getroffen werden (z. B. DENY ALL Regeln), kann Begründung sichergestellt werden, dass unautorisierte Zugriffe (z. B. bei Nicht- Verfügbarkeit von Sicherheitsdiensten) verhindert werden.
Abhängigkeiten bestehen zu allen Architekturvorgaben, Maßnahmen und Abhängigkeiten Vorhaben, welche diese allgemeine Vorgabe einhalten müssen. Weiterhin wird diese Vorgabe durch ISAV-08 konkretisiert.
Die allgemeinen Vorgaben sind grundsätzlich bei Entwurf, Entwicklung Implikationen und Bereitstellung von Diensten zu berücksichtigen.
58 Anhänge
DAAV-06: Vermeiden undokumentierter Funktionen und Schnittstellen
Es dürfen keine versteckten und undokumentierten administrativen Beschreibung Funktionen und erweiterte Schnittstellen vorgehalten werden.
Nur wenn sämtliche Schnittstellen und Funktionen bekannt sind, kann ein Begründung effektives Access Management etabliert werden. Das Risiko von Zugriffen am Access Control System vorbei wird somit deutlich minimiert.
Abhängigkeiten bestehen zu allen Architekturvorgaben, Maßnahmen und Abhängigkeiten Vorhaben, welche diese allgemeine Vorgabe einhalten müssen.
Die allgemeinen Vorgaben sind grundsätzlich bei Entwurf, Entwicklung und Bereitstellung von Diensten zu berücksichtigen.
Es sollte strikte Vorgaben bezüglich der Dokumentation von Implikationen Dienstschnittstellen geben, die grundsätzlich durch sämtliche Projekte zu berücksichtigen sind. Vgl. auch DAAV-03: „Standardisiert dokumentierte Dienst- und Schnittstellenbeschreibungen“.
7.2.3 Architekturvorgaben für Dienste der Domäne Elektronische Verwaltungsarbeit
DAAV-07: Nutzung des Dienstes E-Akte
Der Dienst E-Akte ist grundsätzlich gemäß Architekturvorgabe DAAV-01 Beschreibung „Verbindliche Nutzung von Diensten“ zu nutzen. Den Funktionsumfang, Anwendungsbereich und Status des Dienstes E-Akte regelt Anlage 7.6.1.1.
Gemäß EGovG sollen die Behörden des Bundes ihre Akten elektronisch führen. Dieser Dienst stellt die dafür notwendigen Funktionalitäten bereit und ist grundsätzlich von den Behörden für die Aktenführung einzusetzen. Begründung Durch Einführung wird der behördenübergreifende einheitliche Umgang mit der Schriftgutverwaltung gefördert. Die elektronische Aktenführung bildet auch die Basis für die elektronische Verwaltungsarbeit der informellen Zusammenarbeit und Vorgangsbearbeitung (formell).
Der Dienst E-Akte • soll aktenrelevante Inhalte nach der Notwendigkeit der Abhängigkeiten Bearbeitung in der E-Akte und die unmittelbare Übergabe von Inhalten zum Zwecke der Beweiswerterhaltung und/ oder
Anhänge 59
Langzeitspeicherung zum Digitalen Zwischenarchiv des Bundes beinhalten (DAAV-11), • soll eine Schnittstelle zum Dienst Social Intranet des Bundes bereitstellen und aktenrelevante Dokumente dieses Dienstes übernehmen (DAAV-08) und • soll in die Bürokommunikationsumgebung des Bundesclients integriert sein (DAAV-12). Die Bewertung des zu wählenden Grades der Integration/ Entkopplung (DAAV-14) steht noch aus. Die Aufwände zur Integration sind bei der E-Akte zu berücksichtigen.
Weitere sich ergebende Abhängigkeiten zu Diensten, insbesondere zu Workflow/ BPMS, Kollaboration, Scanning und zur Anbindung von Fach- und Querschnittsdiensten (u.a. gemäß Referenzarchitektur), sind noch zu bewerten. Die unterstützten Standards für die Schnittstellen wie z.B. CMIS, WebDAV, XDomea, XAIP, WebServices, SOA werden nach Abschluss der Beschaffung detailliert.
Der Dienst ist über ein sicheres Verwaltungsnetz erreichbar.
Nach der Anlage „Zielvorgaben E-Akte“ vom Beschluss des Staatssekretärs- ausschusses Digitale Verwaltung 2020 vom 03.03.2015 hat jede Behörde bis Ende 2016 ein Konzept der behördenspezifischen Anforderungen für die elektronische Aktenführung zu erstellen. Bis Ende 2017 werden die benannten Anforderungen mit dem Dienst E-Akte abgeglichen.
Bis Ende 2019 müssen die Behörden der Bundesverwaltung die organisatorischen und technischen Voraussetzungen für die Einführung schaffen. Dafür können organisatorische Änderungsbedarfe über den Implikationen Aktionsplan E-Akte des Programmes Digitale Verwaltung 2020 begleitet werden.
Durch Einführung des Dienstes E-Akte müssen zur Nutzung bestehende Altbestände, soweit diese elektronisch benötigt werden, digitalisiert und/oder aus bestehenden Dokumenten-Management-Systemen migriert werden. Die Bundesverwaltung muss nach Bedarfslage die Abläufe und Strukturen der Schriftgutverwaltung und allgemein der elektronischen Verwaltungsarbeit an die Nutzung des Dienstes E-Akte anpassen. Der Dienst E-Akte muss in die bestehende IT-Infrastruktur integriert werden.
60 Anhänge
Zur Nutzung von Diensten über ein sicheres Verwaltungsnetz müssen die Behörden einen sicheren Verwaltungsnetzanschluss mit ausreichender Bandbreite einplanen und umsetzen.
Spätestens bis 2020 müssen sich alle Bundesbehörden in der Umsetzung der elektronischen Aktenführung befinden, sofern Sie eine E-Akte einführen müssen.
DAAV-08: Nutzung des Dienstes Social Intranet des Bundes
Der Dienst Social Intranet ist grundsätzlich gemäß Architekturvorgabe DAAV-01 „Verbindliche Nutzung von Diensten“ zu nutzen. Den Beschreibung Funktionsumfang, Anwendungsbereich und Status des Dienstes Social Intranet regelt Anlage 7.6.1.2.
Die verbindliche Verwendung des Dienstes Social Intranet des Bundes erleichtert die behördenübergreifende informelle Zusammenarbeit. Der Begründung Nutzen der Zusammenarbeitsfunktionen wird durch ein gemeinsames System verstärkt (Netzwerkeffekt).
Der Dienst Social Intranet des Bundes • soll über Standardschnittstellen aktenrelevante Informationen in den Dienst E-Akte überführen (DAAV-07) und • soll im Bundesclient lauffähig sein (DAAV-12).
Weitere, sich ergebende Abhängigkeiten zu Diensten sind noch zu bewerten.
Abhängigkeiten Die Einbindung von Funktionalitäten in andere Dienste und Plattformen (z. B. Portale, eGesetzgebung) ist über Microservices und/oder iFrame- Portlets anvisiert. Eine Detaillierung erfolgt nach verbindlicher Festlegung der Schnittstellen/Integrationsstandards. Ebenfalls erfolgt eine Prüfung der Entkopplung von Diensten (DAAV-14) unter Berücksichtigung von angebotenen Plug-Ins.
Der Dienst ist über ein sicheres Verwaltungsnetz erreichbar.
Für die behördenübergreifende Nutzung sind rechtliche, organisatorische Implikationen und technische Regelungen, insbesondere zu Akzeptanz, Nutzung, Social Media Policy, Einführung und Nutzungsintegration, durch die jeweiligen
Anhänge 61
Behörden zu treffen.
Die informelle Kommunikation über diesen Dienst (Conferencing) ist auf Teilnehmer aus der Bundesverwaltung mit gemäß BSI-Vorgabe abgesicherter Infrastruktur beschränkt. Zur Nutzung von Diensten über ein sicheres Verwaltungsnetz müssen die Behörden einen sicheren Verwaltungsnetzanschluss mit ausreichender Bandbreite einplanen und umsetzen können. Behörden haben organisatorisch den angebotenen Funktionsumfang der genutzten Bestandssysteme mit dem durch den Dienst Social Intranet des Bundes abzugleichen und entsprechende weitere Anforderungen im Kontext der informellen Zusammenarbeit an die Verantwortlichen zur Weiterentwicklung des Dienstes Social Intranet zu übermitteln. Dies gilt insbesondere für die Schnittmengen mit den eingesetzten Diensten der Bürokommunikation und Kollaboration.
DAAV-09: Nutzung des Dienstes eNorm
Der Dienst eNorm ist grundsätzlich gemäß Architekturvorgabe DAAV-01 Beschreibung „Verbindliche Nutzung von Diensten“ zu nutzen. Den Funktionsumfang, Anwendungsbereich und Status des Dienstes eNorm regelt Anlage 7.6.1.3.
Ein medienbruchfreies und instanzenübergreifendes Normsetzungsvorhaben setzt ein einheitliches Dokumentformat unter Verzicht auf fehlerträchtige Konvertierungsprozesse und die Nutzung Begründung desselben Unterstützungstools durch alle am Prozess Beteiligten voraus. Die Weiterentwicklung des Dienstes eNorm fördert die übergreifende einheitliche Nutzung.
Der Dienst eNorm • muss mit eGesetzgebung (DAAV-10) zusammenarbeiten, • muss mit dem Planungs- und Kabinettmanagement-Programm Abhängigkeiten (PKP) zusammenarbeiten und • muss im Bundesclient lauffähig sein (DAAV-12).
Weitere sich ergebende Abhängigkeiten zu Diensten sind noch zu bewerten.
62 Anhänge
Der Dienst eNorm ist derzeit als Add-In zu einer Textverarbeitung konzipiert. Die aktuelle Umsetzung weist eine Abhängigkeit zur Standardsoftware Microsoft Word auf. Diesbezüglich erfolgt noch eine Prüfung der Einhaltung der Architekturvorgabe zur Entkopplung von Diensten (s. DAAV-14).
Die Nutzung des Internetangebotes der Bundesrechtsdatenbank setzt zudem eine Internetanbindung voraus.
Für die Nutzung des weiterentwickelten Dienstes eNorm ist zu validieren inwiefern in den jeweiligen Behörden organisatorische Abläufe und Implikationen Strukturen optimiert werden können. Die Aktivitäten sind eng an eGesetzgebung und PKP zu koppeln.
DAAV-10: Nutzung des Dienstes eGesetzgebung
Der Dienst eGesetzgebung ist grundsätzlich gemäß Architekturvorgabe DAAV-01 zu nutzen. Den Funktionsumfang, Anwendungsbereich und Status des Dienstes eGesetzgebung regelt Anlage 7.6.1.4.
In der Entwicklung des Dienstes eGesetzgebung werden zwingend die Beschreibung Architekturvorgaben beachtet und umgesetzt. Bis zu einer Betriebsphase wird der Dienst auf freiwilliger Basis angeboten. Mit Beschluss über den Regelbetrieb werden die beteiligten Verfassungsorgane im Rahmen des Prozessmodells und der darauf aufbauenden Architekturen über die Nutzungsverpflichtung zu eGesetzgebung entscheiden.
Für die Ausschöpfung der Vorteile einer durchgängig medienbruchfreien Begründung Gesetzgebungsprozesses sollten alle beteiligten Verfassungsorgane den Dienst nutzen.
Die Einführung des Dienstes eGesetzgebung ist noch in Planung und erfolgt stufenweise. Abhängigkeiten können sich zukünftig für relevante fachlich verwandte Systeme ergeben, welche heute bereits Funktionen des
Abhängigkeiten Gesetzgebungsverfahrens abdecken (insbesondere eNorm - DAAV-09, Planungs- und Kabinettmanagement-Programm PKP).
Sich ergebende Abhängigkeiten zu weiteren Diensten sind noch zu bewerten (insbesondere E-Akte - DAAV-07, SIB - DAAV-08).
Anhänge 63
Der Dienst ist über ein sicheres Verwaltungsnetz erreichbar.
Die betroffenen Behörden und Organe sind an der Anforderungsaufnahme für den Dienst eGesetzgebung beteiligt. Ein fachliches Eckpunktepapier wurde bereits erstellt und wird noch abgestimmt. Die Konzeption der Implikationen Architektur der ersten Ausbaustufe wird Anfang 2017 abgeschlossen sein. Sobald die sich daraus ergebenden organisatorischen und technischen Implikationen definiert wurden, werden diese an die betroffenen Akteure kommuniziert.
DAAV-11: Nutzung des Dienstes Digitales Zwischenarchiv des Bundes
Der Dienst Digitales Zwischenarchiv des Bundes ist grundsätzlich gemäß Architekturvorgabe DAAV-01 zu nutzen. Den Funktionsumfang, Beschreibung Anwendungsbereich und Status des Dienstes Digitales Zwischenarchiv des Bundes regelt Anlage 7.6.1.5.
Die einzelnen Behörden des Bundes sollen für die Zwecke der Langzeitspeicherung sowie der Beweiswerterhaltung keine eigenständigen Lösungen mit den dabei einhergehenden organisatorischen, finanziellen und technischen Aufwänden beschaffen und betreiben.
Gemäß BArchG müssen die Behörden des Bundes ihr Schriftgut dem Begründung Bundesarchiv anbieten. Dieses erfolgt derzeit v. a. im Bereich E-Akte und SAP über eine Schnittstelle zwischen den Behördensystemen und dem Digitalen Zwischenarchiv des Bundes (DZAB) bzw. zwischen dem DZAB und dem Digitalen Magazin im Bundesarchiv. Das Bundesarchiv kann frühzeitig die Archivwürdigkeit des Schriftgutes bewerten und Skaleneffekte nutzen.
Der Dienst Digitales Zwischenarchiv des Bundes (DZAB) • wird Inhalte aus der E-Akte übernehmen (DAAV-07), • wird Inhalte aus den De-Mail Diensten übernehmen (DAAV-19) Abhängigkeiten und • muss archivwürdige Inhalte an das Digitale Magazin beim Bundesarchiv überführen.
64 Anhänge
Das DZAB verwendet standardisierte Schnittstellen auf Basis von WebServices und SOAP V1.1. Das DZAB kann derzeit auch über die SAP- Schnittstellen ArchiveLink und BC-ILM angesprochen werden.
Weitere sich ergebende Abhängigkeiten zu Diensten sind noch zu bewerten.
Der Dienst ist über ein sicheres Verwaltungsnetz erreichbar.
Für die Nutzung des Dienstes müssen durch die Behörden organisatorische und technische Maßnahmen zur Selektion der für die Zwischenarchivierung anstehenden Inhalte inklusive deren Metadaten sowie für deren TR-ESOR-konforme12 Datenaufbereitung (XAIP) und Qualitätssicherung erfolgen. In Absprache mit dem Bundesarchiv werden die Datenstrukturen definiert und einzelne Komponenten (Access Service, Konverter, WSDL-Aufruf) bereitgestellt.
Zur Nutzung von Diensten über ein sicheres Verwaltungsnetz müssen die Behörden einen sicheren Verwaltungsnetzanschluss mit ausreichender Bandbreite einplanen und umsetzen.
In Vorbereitung der Nutzung müssen die IT-Sicherheits-, die Datenschutzkonzepte und die geheimschutzrechtlichen Vorgaben validiert Implikationen und ggf. angepasst werden. Ein Zugriff auf das DZAB erfordert eine entsprechende Langzeitspeicher-URL der BA, ein PKI-Zertifikat der BA, um eine sichere Verbindung (s. hierzu Baustein M 5.177) aufbauen zu können sowie Anpassungen in den Firewalls/DMZ der BA, des Bundesarchivs und der beteiligten Behörden. Gleiches gilt auch für die Webanwendung des Access Service (s. hierzu Baustein M 5.66).
Die datenschutzrechtlichen Pflichten des Bundesarchivs und der BA gemäß Art. 28 der EU-DSGVO und § 11 BDSG entbinden die abgebenden Stellen ihrerseits nicht von der Pflicht, den Schutzbedarf ihrer elektronischen Unterlagen selbst zu bestimmen und die datenschutzrechtlichen Vorkehrungen des DZAB selbst zu überprüfen. Gleiches gilt für die geheimschutzrechtlichen Pflichten.
12 Technische Richtlinie 03125 des BSI (Beweiswerterhaltung kryptographisch signierter Dokumente), kurz BSI TR-ESOR - 03125
Anhänge 65
7.2.4 Architekturvorgaben für Dienste der Domäne Infrastrukturdienste
DAAV-12: Nutzung des Dienstes Bundesclient
Der Dienst Bundesclient ist grundsätzlich gemäß Architekturvorgabe DAAV-01 zu nutzen. Den Funktionsumfang, Anwendungsbereich und Status des Dienstes Bundesclient regelt Anlage 7.6.2.1.
Software, die weder über das Portfolio der Standardsoftware noch der optionalen Software in den Bundesclient integriert werden kann, wird auf Basis von Anwendungsvirtualisierung oder gehosteten Applikationen Beschreibung bereitgestellt (sofern die Software dies unterstützt).
Die Erweiterung und Aktualisierung des Bundesclients inklusive Hardware, Betriebssystem und Softwareportfolio erfolgt für alle Nutzer/innen und Behörden nach Prüfung und Qualitätssicherung durch den IT-Dienstleister. Erweiterungsanfragen können durch die Nutzer über neue bzw. bekannte Gremien eingereicht werden, die im Rahmen des IT- Steuerung Bund Konzeptes erarbeitet werden.
Ein zentraler Betrieb der in der Bundesverwaltung eingesetzten Clients Begründung kann nur auf Basis von durchgehender Standardisierung erfolgen. Das gilt sowohl für die Beschaffung als auch für die Administration.
Es besteht eine starke Abhängigkeit zu den Diensten in der Bundescloud (DAAV-13 und DAAV-16), sowie den Möglichkeiten der Anwendungsvirtualisierung, damit Fachverfahren, Basis- und Querschnittsdienste vom Client entkoppelt werden können.
Die Bereitstellung und auch Nutzung des Bundesclients mit all seinen Funktionalitäten erfolgt über ein sicheres Verwaltungsnetz (z.B. NdB).
Es bestehen zudem erhebliche Abhängigkeiten zu Beschaffungsprozessen Abhängigkeiten in der unmittelbaren Bundesverwaltung. Des Weiteren bestehen erhebliche Abhängigkeiten zu der gesamten Betriebsorganisation der IT- Dienstleister. Hard- und Software, ggf. auch Druckumgebung wird ausnahmslos durch den IT-Dienstleister bereitgestellt und administriert. Ein abgesicherter Zugriff durch den Flächenservice des IT-Dienstleisters auf die Nutzerlokationen muss möglich sein.
Es bestehen des Weiteren Abhängigkeiten zu Vorgaben aus dem BSI und
66 Anhänge
von KritiS, die im Rahmen der aktuellen Bewertung und der technischen Entwicklung verschärft werden können, um das VS-NfD Niveau aufrechtzuerhalten. Hier kann ggf. der übliche Update Zyklus in der Software verkürzt werden. Es kann ebenfalls passieren, dass Standardkomponenten oder optionale Komponenten des Bundesclients getauscht oder entfernt werden müssen, weil sie das geforderte Schutzniveau kompromittieren könnten.
Der Bundesclient hat keine eigenen Autorisierungs- und Authentifizierungsdaten. Sie werden ausschließlich über die AD-Struktur zur Verfügung gestellt.
Die Beschaffungsverfahren der Behörden müssen dieser Vorgabe untergeordnet werden, da ansonsten eine Standardisierung nicht erreicht werden kann.
Funktionale und nicht-funktionale Anforderungen werden als wesentliches Qualitäts- und damit auch Sicherheitsmerkmal im Rahmen des Service-Katalogs des Bundesclients verbindlich gemacht. Enthalten sind hierbei auch die entsprechenden Service Level.
Behörden, die den Bundesclient nutzen, müssen für den Betrieb des Bundesclients Elemente Ihrer IT-Infrastrukturen inklusive der dazugehörigen Dienste (z.B. Verzeichnisdienst, ggf. E-Mail-Service) an den Implikationen anbietenden IT-Dienstleister überführen.
Neben der technischen Überführung und Sicherstellung der Nutzbarkeit sind allgemeine und informationstechnische organisatorische Maßnahmen vorzusehen (z.B. Namenskonventionen, Passwort- Richtlinien, Mail-Policies, zentrales und dezentrales Betriebspersonal, Betriebsverantwortung).
Die serverseitige Bereitstellungs- und Managementumgebung des Bundesclients beim anbietenden IT-Dienstleister teilt die verfügbaren und notwendigen Hardwareressourcen zwischen den Nutzern/Behörden; dedizierte Hardware ist nur im Ausnahmefall möglich.
Anhänge 67
Architekturvorgaben zu Voraussetzungen:
DAAV-13: Anpassung der Anwendungen an den Bundesclient
Neue Anwendungen sind für die Nutzung über den Bundesclient zu konzipieren und zu realisieren. Die Beschaffung und Entwicklung von neuen Anwendungen orientiert sich an den Empfehlungen der Beschreibung festgelegten Standards, Verfahren und Methoden für den Bundesclient. Für bestehende Lösungen und laufende Vorhaben, die den Bundesclient noch nicht berücksichtigen, ist die Möglichkeit einer Migrations- oder Ablösestrategie zu prüfen.
Der Nutzen eines zentralen Clients ist davon abhängig, dass die an einem Begründung Arbeitsplatz erforderlichen Fach-, Querschnitts- und Basisdienste und - Anwendungen über diesen Client genutzt werden können.
Diese Architekturvorgabe konkretisiert die übergreifende Architekturvorgabe DAAV-01 und steht in direkter Abhängigkeit zur Architekturvorgabe DAAV-14.
Es besteht eine starke Abhängigkeit zu allen Diensten in der Bundescloud, Abhängigkeiten die in den Bundesclient integriert werden müssen oder aktive Programmteile auf dem Bundesclient benötigen.
Weiterhin besteht eine Abhängigkeit zur Anwendungsvirtualisierung, damit Fachverfahren, Basis- und Querschnittsdienste vom Client entkoppelt werden können.
Behörden haben sicherzustellen, dass neue Anwendungen grundsätzlich auf die Nutzbarkeit über den Bundesclient konzipiert sind. Für Implikationen Bestandsanwendungen sind Migrationsstrategien zu prüfen und festzulegen. Dafür notwendige organisatorische und technische Maßnahmen sind rechtzeitig einzuleiten (siehe DAAV-01).
DAAV-14: Entkopplung der Dienste vom Bundesclient
Fach-, Querschnitts- und Basisdienste sind vom Bundesclient zu entkoppeln. Beschreibung Entkoppelt bedeutet in diesem Zusammenhang, dass Fach-, Querschnitts- und Basisdienste keine zwingenden Abhängigkeiten zu
68 Anhänge
• spezifischen Laufzeitumgebungen (wie z. B. Java Runtime) oder • Software-Komponenten (wie z. B. Outlook, Microsoft Word)
des Bundesclients haben sollen.
Die Bereitstellung von Diensten soll grundsätzlich serverbasiert erfolgen. Der Zugriff und die Nutzung von Fach-, Querschnitts- und Basisdiensten erfolgt über den Webbrowser unter Verwendung von HTML 5 und JavaScript-Technologien.
Eine clientseitige Bereitstellung von Integrationspunkten an standardisierte Schnittstellen kann im Einzelfall für übergreifend genutzte Basisdienste erfolgen. Bei der Bereitstellung von Integrationspunkten ist • die clientseitige Programmlogik möglichst klein zu halten und • der Weiterentwicklungsbedarf bei Änderungen des Bundesclients zu planen und zu budgetieren.
Diese Anforderung gilt für alle Dienste unabhängig von der tatsächlichen oder geplanten Nutzung des Bundesclients, die weiterentwickelt oder neu erstellt werden. Die aktuellen Fach-, Querschnitts- und Basisdienste müssen entsprechend angepasst werden, damit sie unter dieser Vorgabe weiterhin nutzbar sind.
Der Bundesclient kann nur dann eine einheitliche Basis für die unmittelbare Bundesverwaltung darstellen, wenn die Abhängigkeiten zu Fach-, Querschnitts- und Basisdiensten für den Bundesclient reduziert und perspektivisch möglichst ganz abgebaut werden. Gelingt das nicht, wird die Begründung heutige Heterogenität und Komplexität lediglich aus den Behörden an den IT-Dienstleister übertragen. Effektivitäts- und Effizienzgewinne lassen sich so nicht erreichen. Nur wenn der Bundesclient einen hohen Standardisierungsgrad erreicht, sind die Effizienzgewinne zu erzielen.
Insbesondere bestehen Abhängigkeiten zum Übergang der Dienste in die Bundescloud. Für die aktuellen Fach-, Querschnitts- und Basisdienste ist die dargestellte Entkopplung zu prüfen, damit sie unter dieser Vorgabe Abhängigkeiten weiterhin ohne großen Aufwand aufseiten der Dienstleister im Bundesclient nutzbar sind. Die Nutzung offener und standardisierter Webtechnologien ist in Vorgabe TIAV-04 definiert.
Anhänge 69
Eine Vielzahl von Entwicklungs- und Beschaffungsprozessen in den Ressorts und Behörden müssen überarbeitet werden. Entwicklungs- und Beschaffungsvorhaben müssen sich an den Schnittstellen des Bundesclients Implikationen und den verfügbaren Diensten orientieren. Insbesondere müssen die Richtlinien des Bundesclients und der Dienste bei der Entwicklung eingehalten werden.
DAAV-15: Migration von Clients
Sollte eine Migration auf den Bundesclient bis 2020 aus Zeit-, Ressourcen- und Kapazitätsgründen nicht möglich sein und die Behörden zunächst eine Client-Migration in Eigenregie umsetzen, so ist hierbei grundsätzlich der Migrationsleitfaden zu berücksichtigen, der im Projekt Bundesclient erarbeitet wird.
Da der Windows 7 Support zum Januar 2020 endet, müssen bis dahin alle Beschreibung betroffenen Clients auf ein neues Betriebssystem migriert werden. Idealerweise erfolgt hierbei die Migration direkt auf den Bundesclient, der aller Voraussicht nach ab 2018 für eine Nutzung bereitsteht. Der Migrationsleitfaden enthält Vorgaben, damit die Migration in Eigenregie möglichst nah am Bundesclient erfolgt.
Sukzessive sollen alle Clients der unmittelbaren Bundesverwaltung auf den Bundesclient migriert werden.
Bei Einhaltung kann eine kosten- und aufwandsoptimierte Migration auf Begründung den Bundesclient im Nachgang erfolgen.
Die Dringlichkeit und der Bedarf der Migration hängen direkt von den Abhängigkeiten Vereinbarungen und Enddaten des Herstellersupports zu Windows 7 und den definierten Leitfänden zur Migration ab.
Ggf. müssen die Ressorts und Behörden laufende Migrationsplanungen Implikationen stoppen beziehungsweise anpassen.
70 Anhänge
DAAV-16: Nutzung des Dienstes Bundescloud
Der Dienst Bundescloud ist grundsätzlich gemäß Architekturvorgabe DAAV-01 zu nutzen. Den Funktionsumfang, Anwendungsbereich und Status des Dienstes Bundescloud regelt Anlage 7.6.2.2.
Cloud-Dienste, die nicht aus den Rechenzentren des Bundes bereitgestellt werden und/oder Daten außerhalb der Bundesrepublik Deutschland speichern, dürfen von den Behörden nicht genutzt werden. Cloud- Beschreibung Angebote von externen Cloud-Anbietern dürfen zukünftig nicht mehr durch die Behörden in Anspruch genommen werden.
Neue Anwendungen sind zukünftig für die von der Bundescloud bereitgestellte PaaS-Umgebung zu entwickeln. Für diese Entwicklung sind die Empfehlungen der festgelegten Standards, Verfahren und Methoden für die Bundescloud verbindlich.
Durch den Aufbau einer Bundescloud soll der IT-Betrieb konsolidiert und zukunftsfähig aufgestellt werden. Somit entfällt der Betrieb von vielen einzelnen Plattformen in den Behörden.
Die zentral in der Bundescloud bereitgestellte PaaS-Umgebung Begründung standardisiert und beschleunigt zudem die Entwicklung von neuen Anwendungen und unterstützt hierdurch auch maßgeblich die Dienstekonsolidierung.
Mit der zentralen Verwaltung und Bereitstellung der Bundescloud reagiert der Bund außerdem auf die technologische Entwicklung im IT-Sektor.
Die Bundescloud hat als zentrale Instanz umfassende Abhängigkeiten zu allen Diensten. Dafür sind auch umfassend funktionale und nicht- funktionale Anforderungen in Konzepten auszuformulieren. Eine Abhängigkeiten Detaillierung erfolgt gesondert im Rahmen der Maßnahme Bundescloud. Außerdem konkretisiert diese Vorgabe die Richtlinie TIAV-07. Weiterhin werden Sicherheitsaspekte für den Umgang mit Cloud Diensten in ISAV-09 konkretisiert.
Im Rahmen der IT-Konsolidierung werden zukünftig die Fachverfahren Implikationen der Behörden in die Bundescloud überführt. Sollte ein Fachverfahren derzeit nicht in virtuellen Umgebungen lauffähig sein, z. B. aufgrund von
Anhänge 71
spezieller Hardwareabhängigkeit, muss die Behörde das Fachverfahren anpassen oder ablösen, so dass eine Überführung in die Bundescloud möglich ist.
Um die Dienste der Bundescloud nutzen zu können ist ein sicherer Verwaltungsnetzanschluss erforderlich. Behörden ohne sicheren Verwaltungsnetzanschluss können Dienste der Bundescloud nicht nutzen und müssen bei Bedarf zunächst eine sichere Verwaltungsnetzanbindung realisieren.
DAAV-17: Nutzung des Dienstes Audiokonferenzanlage der Pressesprecher der
Ministerien
Der Dienst „Audiokonferenzanlage der Pressesprecher und Ressortpressestellen“ ist grundsätzlich gemäß Architekturvorgabe DAAV- Beschreibung 01 zu nutzen. Den Funktionsumfang, Anwendungsbereich und Status des Dienstes „Audiokonferenzanlage der Pressesprecher und Ressortpressestellen“ regelt Anhang 7.6.2.3.
Es handelt sich um eine bestehende Lösung für einen spezifischen Begründung Anwendungsbereich.
Zum Datentransport wird eine sichere Verwaltungsnetzinfrastruktur genutzt, um die in den Pressestellen der Ressorts befindlichen speziellen Kommunikationsendgeräte mit der Konferenzzentrale zu verbinden. Abhängigkeiten Dieser Dienst hängt von der Verfügbarkeit eines sicheren Verwaltungsnetzes ab, den er als Transportmedium nutzt (Layer-2- Kopplung).
Für die Nutzung müssen die Hausnetze die technischen Voraussetzungen erfüllen (z. B. UDP-, ARP-, RTP- und FastEthernet-fähig) und entsprechend konfiguriert werden. Zudem ist es erforderlich, dass an den Nutzerliegenschaften IT-Personal verfügbar ist, um im Störfall die Implikationen Entstörung zusammen mit dem zuständigen externen Dienstleister durchführen zu können.
Zur Nutzung von Diensten über sichere Verwaltungsnetze müssen die Behörden einen sicheren Verwaltungsnetzanschluss mit ausreichender
72 Anhänge
Bandbreite einplanen und umsetzen.
DAAV-18: Nutzung des Dienstes Bund-TV
Der Dienst Bund-TV ist grundsätzlich gemäß Architekturvorgabe DAAV-01 Beschreibung zu nutzen. Den Funktionsumfang, Anwendungsbereich und Status des Dienstes Bund-TV regelt Anlage 7.6.2.4.
Es handelt es um eine bestehende Lösung für einen spezifischen Begründung Anwendungsbereich.
Dieser Dienst hängt von der Verfügbarkeit eines sicheren Abhängigkeiten Verwaltungsnetzes ab, den er als Transportmedium nutzt.
Für die Nutzung müssen die Hausnetze die technischen Voraussetzungen (z. B. IP-Multicast- und Fast-Ethernet-fähig) erfüllen und entsprechend konfiguriert werden. Insbesondere ist zur Verbreitung von Videostreams in den Hausnetzen der Standard-IP-Multicast einzusetzen.
Zusätzlich ist es erforderlich, dass an den Nutzerliegenschaften IT-Personal verfügbar ist, um die Verteilung der am Nutzerumsetzer ankommenden
Implikationen Signale in das BK-/bzw. Hausnetz sicherzustellen.
In den Mitwirkungspflichten für die Nutzer/innen von Bund-TV sind zudem die Nutzungsvoraussetzungen festgehalten. Diese orientieren sich an den Nutzerpflichten für das genutzte sichere Verwaltungsnetz.
Zur Nutzung von Diensten über ein sicheres Verwaltungsnetz müssen die Behörden einen sicheren Verwaltungsnetzanschluss mit ausreichender Bandbreite einplanen und umsetzen.
DAAV-19: Nutzung des Dienstes De-Mail-Gateway
Der Dienst „De-Mail-Gateway für die Bundesverwaltung“ ist grundsätzlich Beschreibung gemäß Architekturvorgabe DAAV-01 zu nutzen. Den Funktionsumfang, Anwendungsbereich und Status des Dienstes regelt Anlage 7.6.2.5.
Die Umsetzung eines De-Mail-Zugangs ist für alle Behörden des Bundes Begründung durch das E-Government Gesetz verbindlich vorgegeben. Die Nutzung des zentralen De-Mail-Gateway-Dienstes vereinfacht diese Umsetzung ggf. für
Anhänge 73
die einzelnen Behörden.
Der zentrale De-Mail-Gateway-Dienst wird über ein sicheres Verwaltungsnetz bereitgestellt.
Abhängigkeiten Es bestehen Schnittstellen und Beziehungen • zum Digitalen Zwischenarchiv des Bundes (DAAV-11) und • zur E-Akte (DAAV-07).
Für jede Bundesbehörde ist die Einrichtung eines Catch-All-Postfachs und Implikationen ggf. eine Anpassung des Nutzer-E-Mail-Systems erforderlich.
DAAV-20: Nutzung von IAM-Funktionalität für Dienste
Der Dienst „Ressortübergreifendes Identitätsmanagement für die Bundesverwaltung“ ist grundsätzlich gemäß Architekturvorgabe DAAV-01 Beschreibung zu nutzen. Den Funktionsumfang, Anwendungsbereich und Status des Dienstes „Ressortübergreifendes Identitätsmanagement für die Bundesverwaltung“ regelt Anlage 7.6.2.6.
Nur wenn es gelingt, zukünftig alle neuen Dienste an das IAM anzubinden, können die erwarteten positiven Auswirkungen der Lösung (verbesserte Compliance, verbesserte Prozesse, geringere Kosten etc.) vollumfänglich realisiert werden. Für (noch) nicht bestehende Dienste ist es uneingeschränkt möglich, Anforderungen bezüglich ihrer Anbindbarkeit im Rahmen der Konzeptionsphase umfänglich zu berücksichtigen.
Die Integration bestehender Systeme in eine IAM-Lösung gestaltet sich Begründung zum Teil schwierig, da im Rahmen ihrer Beschaffung häufig keine expliziten Anforderungen bezüglich der Bereitstellung (normierter) Schnittstellen zur Anbindung an IAM-Lösung formuliert wurden. Zusätzlich erlaubt es die gewählte Softwarearchitektur häufig nicht oder nur sehr schwer, entsprechende Funktionalitäten mit vertretbarem Aufwand nachzurüsten. Daher wird lediglich gefordert, dass im Rahmen einer Machbarkeitsuntersuchung entschieden werden soll, ob und in welcher Tiefe entsprechende Funktionen genutzt werden müssen.
74 Anhänge
Die Fokussierung auf eine IAM-Lösung erleichtert perspektivisch den Betrieb und kann Anschaffungs- und Integrationsaufwände reduzieren.
Authentifizierung und Autorisierung sind aufeinander aufbauende Schritte im Rahmen der Autorisierung von Zugriffen. Als solche müssen sie jedoch getrennt voneinander gehalten und behandelt werden.
Abhängigkeiten bestehen zu allen zu integrierenden Diensten. Als Basisdienst besitzt das IAM zu sämtlichen anderen Diensten/Projekten eingehende und ausgehende Abhängigkeiten. Die Anbindung an mögliche Quellsysteme wie Personalverwaltungssysteme oder bestehende Verzeichnisdienste ist vor dem Hintergrund der Lieferung qualitativ Abhängigkeiten hochwertiger Identitäts- und Organisationsinformationen von besonderem Interesse. Zielsysteme, d. h. Konsumenten der Identitäts- und Berechtigungsinformationen bzw. –Funktionalität, sind grundsätzlich alle ressortübergreifend genutzten Dienste (z. B. E-Akte, Social Intranet). Dabei ist DAAV-02 zu beachten.
Die IAM-Funktionalität muss perspektivisch ein breites Spektrum verschiedener Anforderungen adressieren können, wenn sie umfänglich durch alle (neuen) Dienste genutzt werden soll. Daher ist es unerlässlich, bereits in einer frühen Phase der Konzeption eines neuen Dienstes, Implikationen getroffene Annahmen zum IAM und realisierte IAM-Funktionalität gegen die tatsächlichen Anforderungen zu prüfen. Es ist nicht auszuschließen und sogar wahrscheinlich, dass auch neue (potenziell nicht berücksichtigte) Anforderungen in Richtung IAM gestellt werden.
Architekturvorgaben zu Voraussetzungen:
DAAV-21: Nutzung verpflichtender Schnittstellen und eines einheitlichen Modells für die Verwaltung von Identitätsinformationen
Die Schnittstelle von anderen Diensten mit eigenen identitätsbeschreibenden Attributen oder Berechtigungsrichtlinien an den Dienst „Ressortübergreifendes Identitätsmanagement für die Beschreibung Bundesverwaltung“ ist grundsätzlich in der gesamten unmittelbaren Bundesverwaltung gemäß Architekturvorgabe DAAV-01 zu berücksichtigen.
Anhänge 75
Sofern neu entwickelte und ressortübergreifend genutzte Dienste der Bundesverwaltung eigene identitätsbeschreibende Attribute (Rollenzuordnungen etc.) oder Berechtigungsrichtlinien (Access Control Policies) vorhalten, müssen diese grundsätzlich über dedizierte Schnittstellen (CRUD- create, read, update, delete) auch durch externe Dienste zugreifbar gemacht werden. Dabei wird DAAV-02 beachtet.
Eine tiefe Integration von IAM-System und Dienst ist nur dann möglich, Begründung wenn alle für die Zugangs- und Zugriffssteuerung des Dienstes benötigten Informationen auch extern abfragbar sind.
Abhängigkeiten bestehen zu allen zu integrierenden Diensten. Bei der Beschaffung von Standardprodukten (wie dies beispielsweise für die E-Akte vorgesehen ist) aber auch der Anbindung bereits bestehender Dienste wird man darauf angewiesen sein, dass die jeweiligen Anbieter bereits
Abhängigkeiten entsprechende Schnittstellen in ihren Lösungen vorsehen oder diese leicht „nachrüsten“ können.
Darüber hinaus ergeben sich aus der Anzahl der Nutzer des anzubindenden Dienstes ggf. weiterführende nichtfunktionale Anforderungen (Performance, Verfügbarkeit usw.).
Die Etablierung zentraler Sicherheitsdienste, welche durch Querschnittsdienste genutzt werden, stellt besondere Anforderungen an Implikationen deren Sicherheit, Performance und Verfügbarkeit. Hier muss sehr genau geprüft werden, welche Anforderungen bei der Konzeption, Umsetzung und dem Betrieb der Lösung berücksichtigt werden müssen.
DAAV-22: Sicherstellung einer vollständigen Zugriffssteuerung
Der Dienst „Ressortübergreifendes Identitätsmanagement für die Bundesverwaltung“ ist zur Zugriffssteuerung auf die zentralen Ressourcen grundsätzlich in der gesamten unmittelbaren Bundesverwaltung gemäß
Beschreibung Architekturvorgabe DAAV-01 zu nutzen.
Jeder Zugriff auf eine Ressource muss durch das Access Management geschützt sein. Es darf auch für Administratoren/innen keine Möglichkeit geben, am Access Management vorbei auf eine Ressource zuzugreifen.
76 Anhänge
Identity und Access Management muss ganzheitlich gesehen werden und bezogen auf Zugang und Zugriff auf eine Ressource einen durchgängigen Begründung Schutz bieten. Dies gilt ebenfalls für privilegierte Identitäten, wie z. B. die Administratoren/innen.
Abhängigkeiten Abhängigkeiten bestehen zu allen zu integrierenden Diensten.
Selbst wenn nicht die Komponenten des IAM zur Zugriffssteuerung genutzt werden, sondern auf die im jeweiligen Dienst integrierte Access Control Funktionalität zurückgegriffen wird, muss die Einhaltung der Anforderung Implikationen sichergestellt werden. Entsprechende Prozesse und Maßnahmen sind bezogen auf die Einführung zu definieren. Beispiel: verpflichtendes Penetration Testing der Anwendung oder Code Review falls sinnvoll.
7.2.5 Architekturvorgaben für Dienste der Domäne E-Government
DAAV-23: Nutzung des Dienstes Formular-Management-System (FMS)
Der Dienst FMS ist grundsätzlich gemäß Architekturvorgabe DAAV-01 zu Beschreibung nutzen. Den Funktionsumfang, Anwendungsbereich und Status des Dienstes FMS regelt Anlage 7.6.3.1.
Die Verwendung eines einheitlichen Formularmanagements erleichtert den Austausch und die Wiederverwendung von Formularen zwischen den Begründung Ressorts. Darüber hinaus kann die Weiterentwicklung des Formularwesens auf diese Weise zentral und somit kostengünstiger erfolgen.
Für den Dienst FMS ist eine Anbindung an den Dienst E-Akte (DAAV-07) Abhängigkeiten geplant, womit die weitere Bearbeitung der erfassten Daten gewährleistet wird. Der Dienst ist über ein sicheres Verwaltungsnetz erreichbar.
Bei Einsatz des FMS für die Bereitstellung von Online-Formularen in Portalen und mobil, muss die nutzende Behörde den FMS in ihrem Inter- und/oder Intranetauftritt integrieren. Implikationen Für eine Nutzung der über die Online-Formulare erfassten Informationen in weiteren Bearbeitungsprozessen (z. B. auf Basis einer E-Akte) muss die nutzende Behörde die Daten in ihre Prozesse integrieren.
Anhänge 77
Zur Nutzung von Diensten über ein sicheres Verwaltungsnetz müssen die Behörden einen sicheren Verwaltungsnetzanschluss mit ausreichender Bandbreite einplanen und umsetzen.
DAAV-24: Nutzung des Dienstes Government Site Builder (GSB)
Der Dienst GSB ist grundsätzlich gemäß Architekturvorgabe DAAV-01 zu Beschreibung nutzen. Den Funktionsumfang, Anwendungsbereich und Status des Dienstes GSB regelt Anlage 7.6.3.2.
Mit dem Kabinettbeschluss zur E-Government-Infrastruktur (März 2005) ist Begründung die Nutzung des GSB für die Einrichtungen der Bundesverwaltung verpflichtend.
Der GSB ist Grundlage von vielen Web-basierten Lösungen der Bundesbehörden unter anderem auch des Portals des Bundes „bund.de“ (DAAV-25) Abhängigkeiten Auch das geplante Verwaltungsportal des Bundes (DAAV-27) wird als ein Mandant des GSB aufgebaut.
Der Dienst ist über ein sicheres Verwaltungsnetz erreichbar.
Werden Änderungen an den zentralen GSB-Komponenten durchgeführt, ist zu prüfen, ob es Anpassungsbedarf an den Komponenten der auf Basis des GSB erstellten Lösungen gibt.
Dabei müssen die folgenden Architekturvorgaben bei Einsatz des GSB eingehalten werden: • Abgesicherter PC-Client Arbeitsplatz nach BSI-Empfehlung • Individuelle Betriebsplattform mit den jeweils durch den GSB Implikationen unterstützten Betriebskomponenten und –systemen (LINUX auf x86-Hardware) • Breitbandiger Anschluss des Rechenzentrums an das sichere Verwaltungsnetz und ggf. Internet
Zur Nutzung von Diensten über ein sicheres Verwaltungsnetz müssen die Behörden einen sicheren Verwaltungsnetzanschluss mit ausreichender Bandbreite einplanen und umsetzen.
78 Anhänge
DAAV-25: Nutzung des Dienstes bund.de
Der Dienst bund.de ist grundsätzlich gemäß Architekturvorgabe DAAV-01 Beschreibung zu nutzen. Den Funktionsumfang, Anwendungsbereich und Status des Dienstes bund.de regelt Anlage 7.6.3.3.
Nach dem Kabinettsbeschluss „Langfristige Sicherung der im Rahmen der eGovernment Initiative BundOnline 2005 getätigten Investitionen“ ist diese Plattform für die im Funktionsumfang adressierten Inhalte zu nutzen. Begründung Durch Anlieferung der Inhalte über die Schnittstelle kann die Übernahme automatisiert oder durch eine Nutzerführung erfolgen. Prüfungen zur Einhaltung von Formaten werden erleichtert.
Die im Funktionsumfang aufgeführten Inhalte von bund.de überdecken sich teilweise mit den geplanten Inhalten des „Verwaltungsportals des Bundes“ (DAAV-27). Wie diese beiden Maßnahmen zueinander positioniert werden ist Gegenstand noch laufender Konzeptionsarbeiten.
Bund.de besteht aus einem Mandanten des Government Site Builder (DAAV-24) und speziell für die Massendatenverarbeitung entwickelten Abhängigkeiten Komponenten (Importer-/Newsletterkomponenten), die alle in der GSB- Hosting-Plattform betrieben und bedarfsgerecht weiterentwickelt werden. Dementsprechend gelten auch die Abhängigkeiten gemäß DAAV-24 für bund.de.
Für die Zulieferung bestehen Abhängigkeiten zu den anliefernden Systemen.
Die zuliefernden Behörden müssen die technischen Voraussetzungen zur Nutzung der Schnittstelle gewährleisten/erfüllen (z. B. XML Schema Konformität, FTP/ HTTP-Server als Ablage, BSI abgesichert, abgesicherter PC-Client Arbeitsplatz nach BSI-Empfehlung). Implikationen Änderungen in den Leistungsangeboten für Ausschreibungen und Stellenangebote können Änderungen der XML-Schemata bedeuten. Zuliefernde Behörden müssen die Änderungen bezüglich ihrer Zulieferungen nachvollziehen.
Anhänge 79
DAAV-26: Nutzung des Dienstes E-Payment-Bund
Der Dienst E-Payment-Bund ist grundsätzlich gemäß Architekturvorgabe Beschreibung DAAV-01 zu nutzen. Den Funktionsumfang, Anwendungsbereich und Status des Dienstes E-Payment-Bund regelt Anlage 7.6.3.4.
Durch den Dienst werden die Aufwände für die Zahlungsabwicklung Begründung gesenkt.
Der Dienst ePayBL (E-Payment Bund-Länder) besitzt Schnittstellen zu den IT-Systemen für das Haushalts-, Kassen- und Rechnungswesen des Bundes, insbesondere zum Zahlungsüberwachungsverfahren, zu den Zahlungsverkehrsdienstleistern und zu den ERP-Systemen der Abhängigkeiten Bewirtschafter. Eine Integration von E-Payment in die Rechnungseingangsbearbeitung von eRechnung ist vorgesehen. Die Architekturvorgaben ÜBAV-07 und ÜBAV-08 sowie DAAV-02 und DAAV- 03 sind zu beachten.
Die Einführung des Dienstes E-Payment-Bund erfordert die organisatorische und technische Begleitung der Zahlungsabwicklungsprozesse und deren Meldungen von und für Quer- sowie Fachdienste der Behörde. Die Quer- und Fachdienste können die Implikationen standardisierte Webservice-Schnittstelle ansprechen.
Bei der Anbindung sind rechtliche Rahmenbedingungen zu Sicherheitsstandards, Datensicherung und Datenschutz, aber auch Bedingungen aus BGB und TMG zu berücksichtigen.
DAAV-27: Nutzung des Dienstes Verwaltungsportal und Servicekonto Bund
Der Dienst „Verwaltungsportal und Servicekonto Bund“ ist gemäß Architekturvorgabe DAAV-01 zu nutzen. Den Funktionsumfang, Beschreibung Anwendungsbereich und Status des Dienstes „Verwaltungsportal und Servicekonto Bund“ regelt Anlage 7.6.3.5.
Für die unmittelbare Bundesverwaltung ist zur Deckung eines etwaigen Begründung Bedarfs an dem beschriebenen funktionalen Umfang ab dem Zeitpunkt der Verfügbarkeit grundsätzlich dieser Dienst zu verwenden.
Abhängigkeiten Die im Funktionsumfang aufgeführten Inhalte des Verwaltungsportals des
80 Anhänge
Bundes überdecken sich teilweise mit den Inhalten des „Portals des Bundes“ bund.de (DAAV-25). Wie diese beiden Maßnahmen zueinander positioniert werden, ist Gegenstand noch laufender Konzeptionsarbeiten und daher noch offen.
Für das geplante Verwaltungsportal des Bundes ist der Einsatz des Government Site Builders (GSB) (siehe DAAV-24) verpflichtend. Dementsprechend gelten auch die Abhängigkeiten des GSB für das Verwaltungsportal des Bundes.
Die Bereitstellung von Informationen zu Verwaltungsdienstleistungen des Bundes und Online-Diensten setzt die Mitarbeit der Bundesbehörden
Implikationen voraus. Das erfordert die Unterstützung der Ressorts auf Leistungsebene.
Für die Nutzung des Servicekontos zur Authentifizierung muss dieses in die Online-Verfahren der Bundesbehörden integriert werden.
7.2.6 Architekturvorgaben für Dienste der Domäne ERP
DAAV-28: Nutzung des Dienstes Personalverwaltungssystem
Der Dienst Personalverwaltungssystem ist grundsätzlich gemäß Architekturvorgabe DAAV-01 zu nutzen. Den Funktionsumfang, Beschreibung Anwendungsbereich und Status des Dienstes Personalverwaltungssystem regelt Anlage 7.6.4.1.
Mit der Einführung eines einheitlichen Systems in der gesamten Bundesverwaltung werden die Prozesse und Datenbestände harmonisiert, sodass die Steuerungsfähigkeit der Bundesverwaltung verbessert wird. deren Effizienz und Flexibilität erhöht wird.
Die Bedeutung der Personalverwaltung wird mit dem demographischen Begründung Wandel sowie dem zu erwartenden Fachkräftemangel steigen, so dass eine einheitliche IT-Unterstützung die ressortübergreifende Zusammenarbeit erleichtert und die Fehleranfälligkeit reduziert.
Der Dienst Personalverwaltungssystem unterstützt die Vereinheitlichung des Personalmanagements durch einheitliche Geschäftsprozesse und reduziert IT-und Papierschnittstellen.
Anhänge 81
Der Dienst Personalverwaltungssystem basiert auf einer weiterentwicklungsfähigen IT-Plattform und trägt entscheidend zur Abhängigkeiten fachübergreifenden Integration unterschiedlichster Bereiche bei. Abhängigkeiten zu weiteren Diensten sind bei Einführung zu bewerten, mit dem Ziel einheitliche Schnittstellen zu schaffen.
Der Dienst Personalverwaltungssystem ist produktiv. Aktuell werden vier verschiedene IT-Lösungen betrieben (PVS+, PVS, PersWiSysBw und EPOS). Im Rahmen der Konsolidierung ist die Reduzierung der Anzahl der IT- Lösungen anvisiert. Der IT-Rat hat am 15. März 2016 Implikationen Konsolidierungsmodelle beschlossen. Die Behörden haben entsprechende technische und organisatorische Planungen in Anlehnung an die Feinkonzeption der Maßnahme im IT-Rahmenkonzept ab 2017 vorzunehmen.
82 Anhänge
7.3 Architekturvorgaben für Informationen/Daten
Dieser Anhang beinhaltet Architekturvorgaben, die sich auf die Nutzung, Interpretation und Modellierung von Daten und Informationen beziehen. Die aufgeführten Standards (standardisierte Übertragungsprotokolle, Schnittstellen und Modellierungsstandards) und Austauschformate vereinheitlichen den internen und externen Austausch und die Darstellung von Daten und Informationen. Durch syntaktische und semantische Vorgaben werden eine hohe Interoperabilität und die vereinfachte Nutzung von Schnittstellen gewährleistet.
IDAV-01: Nutzung von Extensible Markup Language (XML) 1.0 für den Austausch von Daten
Für den Austausch von Daten ist die Extensible Markup Language (XML) zu nutzen. XML ist eine aus der Standard Generalized Markup Language (SGML) abgeleitete Sprache, mit der Daten strukturiert abgebildet werden können. Für viele Anwendungsfälle existieren spezialisierte, auf XML basierende, Austauschformate. Für den Austausch von XML Modellen ist weiterhin die Spezifikation XML Schema Definition (XSD) zu nutzen, die den strukturellen Aufbau von XML Dokumenten beschreibt. Durch XML- Validatoren können XML-Dateien darauf geprüft werden, ob sie die durch Beschreibung eine XSD-Datei beschriebene Struktur einhalten. Nur wenn die Funktionalitäten von XSD für die fachlichen Anforderungen nicht hinreichend sind, kann auf andere Spezifikationen zurückgegriffen werden. Im Übrigen ist für den Austausch von Daten die XML als Datenaustauschformat immer dann auch als Grundlage des Datenaustausches mit Partnern außerhalb der öffentlichen Verwaltung des Bundes und der Länder zu nutzen, wenn nicht die Performanz, das auszutauschende Datenvolumen oder Vereinbarungen über ein anderes Austauschformat die Nutzung binärer Datenaustauschformate erfordern.
Standardisierte Austauschformate für Daten sollen den Datenaustausch zwischen Software-Systemen erleichtern. Die vom World Wide Web Begründung Consortium (W3C) herausgegebene XML-Spezifikation wurde 2008 als Empfehlung veröffentlicht und ist ein sehr weit verbreiteter Standard.
Anhänge 83
Abhängigkeiten XML bildet die Grundlage der in IDAV-02 festgelegten Vorgabe.
Implikationen Keine Implikationen vorhanden.
IDAV-02: Nutzung von XÖV zertifizierten Standards
XML in der öffentlichen Verwaltung (XÖV)-Standards sind nationale Spezifikationen zum Datenaustausch in der öffentlichen Verwaltung bzw. zwischen der öffentlichen Verwaltung und ihren Kunden auf Grundlage von XML. Sie fördern die systematische Entwicklung und Bereitstellung von IT-Standards für den elektronischen Datenaustausch im E- Beschreibung Government. Eingesetzte und zertifizierte XÖV-Standards sind beispielsweise XDomea, XVergabe, XJustiz oder XFinanz. Es ist für alle neu zu nutzenden Schnittstellen zu prüfen, ob bereits ein XÖV zertifizierter Stand existiert. Sollte dies nicht der Fall sein, können neue Standards mit Hilfe des XÖV Verfahrens entwickelt werden.
Durch die Nutzung von XÖV zertifizierte Standards können elektronische Prozesse kostengünstig, schnell und mit hoher Qualität umgesetzt werden. Begründung Weiterhin wird aufgrund einheitlicher Schnittstellen eine hohe Interoperabilität gewährleistet.
Diese Vorgabe steht in direkter Abhängigkeit zu Vorgabe IDAV-01. XML Abhängigkeiten bildet die technische Basis der XÖV-Standards.
Es müssen Kenntnisse über die bereits zertifizierten XÖV-Standards und die zu nutzenden Tools in den Behörden vorhanden sein. Neue Implikationen Anwendungen und Dienste müssen nach Möglichkeit XÖV zertifizierte Standards nutzen.
IDAV-03: Nutzung von Unified Modeling Language (UML) 2.x
Beschreibung Für die Modellierung von objektorientierten Anwendungen und
84 Anhänge
komplexen Datenbankmodellen sollte UML 2.x eingesetzt werden. Es bieten sich beispielsweise Klassendiagramme an, die für andere Anwendungen oder durch andere Werkzeuge wiederverwendet oder weiterverarbeitet werden können. Aus UML-Datenmodellen können im Rahmen der generativen Programmierung/modellgetriebenen Architektur direkt Datenstrukturen (XML Schema), komplexe Datenbanken sowie ausführbarer Quellcode generiert werden.
Eine einheitliche Modellierung verringert den Schulungsaufwand, die Begründung Einarbeitungszeit und fördert die Austauschbarkeit.
Abhängigkeiten Keine Abhängigkeiten vorhanden.
Das zugehörige Austauschformat für Modelle auf UML-2.x-Basis ist XML Metadata Interchange (XMI) in der Version 2.x. Den entsprechenden Implikationen Modellierern/innen müssen geeignete IT-Tools zur Verfügung gestellt werden.
IDAV-04: Nutzung von Entity-Relationship-Diagrammen (ERD)
ERD sind für die grafische Repräsentation von Entity-Relationship- Modellen und einfachen funktionalen Datenmodellen zu nutzen. Sie sind gegenüber UML weniger ausdrucksstark, weshalb ERD in der Regel Beschreibung leichter verständlich sind als UML-Diagramme. ERD sollten daher für die Entwicklung von relationalen Datenbank-Schemata eingesetzt werden. Auch einfache funktionale Datenmodelle, insbesondere für die fachliche Grobkonzeption, sollten durch ERD dargestellt werden.
Eine einheitliche Datenmodellierung verringert den Schulungsaufwand, Begründung die Einarbeitungszeit und fördert die Austauschbarkeit.
Abhängigkeiten Keine Abhängigkeiten vorhanden.
Den entsprechenden Modellierern/innen müssen geeignete IT-Tools zur Implikationen Verfügung gestellt werden.
Anhänge 85
IDAV-05: Nutzung des Ressource Description Framework (RDF) als Beschreibungssprache für Metadaten im World Wide Web
Das RDF ist eine Sprache zur Beschreibung von Informationen über Ressourcen im World Wide Web. Insbesondere sollte es für die Darstellung Beschreibung von Metadaten von Webseiten, z. B. Titel, Autor und Änderungsdatum, verwendet werden.
Das RDF wurde 2004 als W3C-Recommendation veröffentlicht und gilt Begründung somit als Quasi-Standard.
Abhängigkeiten Keine Abhängigkeiten vorhanden.
Implikationen Keine Implikationen vorhanden.
IDAV-06: Nutzung des OSCI-Transport Standards zur rechtsverbindlichen Übertragung im E-Government
Online Service Computer Interface (OSCI)-Transport ist ein Protokollstandard für die sichere, vertrauliche und rechtsverbindliche Übertragung elektronischer Daten im Bereich E-Government. Es werden die klassischen Schutzziele Integrität, Authentizität, Vertraulichkeit und Beschreibung Nachvollziehbarkeit bei der Übermittlung von Nachrichten gewährleistet. Sowohl die Spezifikation OSCI 1.2 als auch OSCI 2.0 sind als Protokollstandards einsetzbar.13 Es ist zu beachten, dass OSCI 1.2 keine synchrone Kommunikation unterstützt und OSCI 2.0 nicht abwärtskompatibel ist.
Das Protokoll bildet die technische Basis von E-Government in Deutschland und wurde vom Bundesministerium des Inneren im Rahmen Begründung von SAGA 5 als Standard für elektronische Transaktionen mit der Bundesverwaltung empfohlen.
13 Weitere Informationen zum OSCI-Transport Standard sind unter folgender URL zu finden: http://www.xoev.de/die_standards/osci_transport-3355
86 Anhänge
Diese Vorgabe steht in engem Zusammenhang mit den Vorgaben TIAV-10 Abhängigkeiten und IDAV-01, da diese die technischen Grundlagen beschreiben.
Für den Empfang von OSCI-Nachrichten stehen den Behörden des Bundes derzeit über die Anwendung Governikus Lösungen auf Basis des Implikationen Communicator Frameworks zur Verfügung. Diese sind zu nutzen, um den Empfang zu ermöglichen. Die derzeitige Nutzung von Governikus ist über die Verträge „VPS des Bundes“ und „Projekt Pflege Governikus“ geregelt.
IDAV-07: Nutzung des Enterprise-Content-Management-Modells (ECM)
Das Enterprise-Content-Management (ECM) der Association for Information and Image Management (AIIM) umfasst die Methoden, Techniken und Werkzeuge zur Erfassung, Verwaltung, Speicherung, Beschreibung Bewahrung und Bereitstellung von Inhalten („Content“) und Dokumenten zur Unterstützung organisatorischer Prozesse. Dieses Modell ist insbesondere bei der Neueinführung von Dokumentenmanagementsystemen zu berücksichtigen.
Das ECM stammt vom Branchenverband AIIM International und stellt einen de-facto-Standard für international agierende Produkthersteller dar, Begründung der die Aspekte rund um das Thema „unstrukturierte Informationen und elektronische Dokumente“ definiert und ordnet.
Die Anbindung von Content-Management-Systemen ist in der Vorgabe Abhängigkeiten IDAV-08 näher beschrieben.
Innerhalb des Beschaffungsprozesses von Implikationen Dokumentenmanagementsystemen ist eine ECM-Kompatibilität zu berücksichtigen.
IDAV-08: Nutzung von Content Management Interoperability Services (CMIS) zur Anbindung von Content Management Systemen
Die Content Management Interoperability Services (CMIS) sind ein offener Beschreibung und herstellerunabhängiger Standard zur Anbindung von Content-
Anhänge 87
Management-Systemen. Ziel des Standards ist es, die Interoperabilität proprietärer Content-Management-Systeme herstellerübergreifend zu ermöglichen. CMIS ist auch im Bereich der öffentlichen Verwaltung weit verbreitet.
Die Nutzung offener, herstellerunabhängiger Standards ermöglicht unter Begründung anderem Kosteneinsparungen und eine erhöhte Flexibilität.
Der Standard beschreibt eine zusätzliche Abstraktionsschicht für Webservices auf Basis von SOAP und REST, diese können dann Abhängigkeiten unabhängig vom verwendeten Repository zur Kommunikation verwendet werden. Somit existiert eine Abhängigkeit zu der Vorgabe TAV-10.
Implikationen Keine Implikationen vorhanden.
IDAV-09: Nutzung von PDF ab Version 1.4 als Austauschformat für unveränderbare Dokumente
PDF (Portable Document Format) ist ein Format zum Austausch und zur Ansicht elektronischer Dokumente unabhängig von der Umgebung, in der sie erstellt wurden.
PDF muss für Textdokumente verwendet werden, die nur dem Beschreibung Informationsaustausch dienen und nicht weiterbearbeitet werden sollen, insbesondere für Dokumente mit Anforderungen an das Layout oder mit eingebetteten grafischen Elementen. Für Dokumente die zur Langzeitarchivierung vorgesehen sind, muss der Standard PDF/A verwendet werden.
PDF sind relativ kompakt, da sie optimal gespeichert und in der Dateigröße für den jeweiligen Anwendungszweck entsprechend reduziert Begründung werden können. Meist kleiner als das Quelldokument können sie problemlos, verlustfrei und originalgetreu versendet werden. Ein weiterer Vorteil ist die Plattformunabhängigkeit.
Abhängigkeiten Keine Abhängigkeiten vorhanden.
Implikationen Ein PDF-Viewer (z. B. Adobe Acrobat Reader) ist zur Ansicht der
88 Anhänge
Dokumente notwendig.
IDAV-10: Nutzung von einheitlichen Austauschformaten für veränderbare Dokumente
Für die Bearbeitung und den Austausch von veränderbaren Dokumenten sind die Formate Open Document Format (ODF) nach ISO 26300 und Office Open XML (OOXML) nach ISO 29500 nutzbar. ODF ist ein Beschreibung international genormter, quelloffener Standard für Dateiformate von Dokumenten. OOXML ist ein von der Firma Microsoft entwickelter Standard, der u.a. die Grundlage des Dateiformates .docx bildet.
Durch den Beschluss des IT-Rates vom 28.11.2008 ist die Nutzung offener Dokumentenformate in der Bundesverwaltung verbindlich zu Begründung berücksichtigen. Die Nutzung von offenen Dokumentenstandards ermöglicht eine verbesserte Interoperabilität, erhöht die Sicherheit und verhindert die Bindung an einen bestimmten Hersteller.
Es existiert eine Abhängigkeit zu ÜBAV-07, da durch die Nutzung von .docx die Herstellerunabhängigkeit nicht mehr gewährleistet ist. In diesem Abhängigkeiten Fall ist jedoch die Verbreitung dieses Formates innerhalb der Bundesverwaltung so groß, dass eine Beschränkung auf das ODF Format die Leistungsfähigkeit der Behörden stark einschränken würde.
Es muss weiterhin gewährleistet sein, dass Dokumente in gängigen Implikationen proprietären Formaten von der Bundesverwaltung empfangen, gelesen und bearbeitet werden können.
IDAV-11: Nutzung von einheitlichen Austauschformaten für Bilddateien
Das Format JPEG muss für die Speicherung und den Austausch von Fotos und Grafiken mit Farbverläufen, bei denen die verlustbehaftete Beschreibung Kompression dieses Formates unschädlich ist, verwendet werden. Sollten sich die technischen und fachlichen Anforderungen mit dem JPEG- Format nicht abbilden lassen, sind die folgenden Formate alternativ zu
Anhänge 89
prüfen und zu nutzen:
• Portable Network Graphics (PNG) • Geo Tagged Image File Format (GeoTIFF) • Graphics Interchange Format (GIF) • Tagged Image File Format (TIFF)
Einheitliche Austauschformate erleichtern die Betrachtung, Bearbeitung Begründung und den Austausch von Bilddateien.
Abhängigkeiten Keine Abhängigkeiten vorhanden.
In den Behörden sind für entsprechende Mitarbeiter geeignete Implikationen Werkzeuge, zur Ansicht und Bearbeitung von Bildern der aufgeführten Formate, zur Verfügung zu stellen.
IDAV-12: Nutzung von einheitlichen Austauschformaten für Mediadateien
Folgende Austauschformate für Mediadateien sind zulässig:
• Ogg Encapsulation Format (Ogg) ist eine unabhängige Alternative zu proprietären Formaten und ermöglicht die Speicherung und das Streaming multimedialer Inhalte Beschreibung • MPEG-4 (MP4) ist ein von der Moving Pictures Experts Group entwickelter Container für den Austausch von Audio- und Videodateien • Mpeg-1 Layer 3 (MP3) ist aus Bestandsgründen weiter erlaubt. Wenn möglich sollte jedoch bevorzugt Ogg genutzt werden.
Einheitliche Austauschformate erleichtern die Betrachtung und Begründung Bearbeitung von Mediadateien.
Abhängigkeiten Keine Abhängigkeiten vorhanden.
Um das Abspielen der Mediadateien zur ermöglichen, sind den Implikationen Mitarbeitern der Behörden geeignete Werkzeuge zur Verfügung zu stellen.
90 Anhänge
IDAV-13: Verwendung des Formates Multipurpose Internet Mail Extensions (MIME) zur standardisierten Angabe von Dateiformaten im Internet
MIME ermöglicht es, zwischen Sender und Empfänger Informationen über den Typ der übermittelten Daten auszutauschen (Content-Type-Feld, Beschreibung Internet Media Type) und gleichzeitig eine für den verwendeten Übertragungsweg sichere Zeichenkodierung (Content-Transfer-Encoding) festzulegen.
MIME wurde in RFC 2045, RFC 2046, RFC 2047, RFC 2048 und RFC 2049 Begründung als Standard definiert.
Abhängigkeiten Keine Abhängigkeiten vorhanden.
Implikationen Keine Implikationen vorhanden.
IDAV-14: Einsatz von APIs, Microservices und API Management zur Datenbereitstellung
Ausgewählte Daten aus der öffentlichen Verwaltung müssen gemäß "Open Government Data" über standardisierte Schnittstellen für die Öffentlichkeit zur Verfügung gestellt werden. Hierfür sind Application Beschreibung Programming Interfaces (API) einzusetzen. Funktionalitäten sind möglichst kleinteilig in Form von Web-APIs zu entwickeln und bereitzustellen (Microservices). Für die GIB ist ein einheitliches API Management bereitzustellen und zu nutzen
Offene vernetzte Daten (Linked Open Data LOD) sind sämtliche Datenbestände, die im Interesse der Allgemeinheit ohne jedwede Einschränkung zur freien Nutzung, zur Weiterverbreitung und zur freien Weiterverwendung frei zugänglich gemacht werden. Begründung Auf Basis von Linked Open Data und offenen Schnittstellen (API) lassen sich Anwendungen und Werkzeuge erstellen, die automatisiert Recherchen und die Berichterstattung unterstützen. Neben öffentlichen Verwaltungen stellen auch große Unternehmen wie Amazon und Telekom bereits Daten per API bereit.
Anhänge 91
Für eine bessere Wartbarkeit und Interoperabilität von Anwendungen sind Microservices zu nutzen. Dieses Entwicklungspattern ermöglicht weitgehend autark entwickelbare Funktionsbausteine und reduziert Abhängigkeiten beim Releasemanagement neuer Funktionalitäten. Ebenso werden Funktionsbausteine dadurch weniger komplex und fehleranfällig sowie einfacher ansteuerbar. Mit einem geeigneten API Management werden die Entwicklung und Versionierung von APIs unterstützt sowie die möglichen Zugriffe Externer auf diese APIs vereinheitlicht und zentral steuerbar.
Abhängigkeiten Keine Abhängigkeiten vorhanden.
Die Konformität mit den Standards der US Bundesverwaltung und demnächst der europäischen Verwaltungen verbessert die standardisierten Möglichkeiten für den Abruf offen vernetzter Daten. Implikationen Auch fordert unter anderem das Regierungsprogramm "Digitale Verwaltung 2020" bei den durch das Programm bereitzustellenden Lösungen die Verwendung von offenen Standards sowie APIs/Schnittstellen zur Erhöhung der Interoperabilität.
92 Anhänge
7.4 Technische Architekturvorgaben
Die technischen Architekturvorgaben beziehen sich auf die technologische Umsetzung der IT-Architektur. Sie beinhalten prinzipielle Vorgaben für die Anwendungsentwicklung, wie beispielsweise die Nutzung von Programmiersprachen. Weiterhin werden durch die Vorgaben Infrastrukturaspekte geregelt.
7.4.1 IT-Infrastruktur
TIAV-01: Beschaffung von Servern mit standardisierter Prozessor-Architektur
Für Server im Backend-Bereich sind grundsätzlich die Prozessor- Architekturen gemäß Anlage 7.7.1 vorzusehen.
Beschreibung Die Kriterien des „Blauen Engels“ für einen energieeffizienten Rechenzentrumsbetrieb sollen bei der Beschaffung von Servern angewendet werden.
Eine standardisierte Prozessorarchitektur ermöglicht die Entwicklung von Software und den Einsatz von Systemkomponenten gegen eine definierte Plattform. Die Kompatibilität und Interdependenzen zu anderen eingesetzten Technologien und Infrastrukturen aus dem Standardkatalog sind notwendig, um die Ziele der IT-Konsolidierung bestmöglich zu Begründung verfolgen. Ein großer Teil der Leistungsanforderungen an bereitzustellende Systemumgebungen kann mit x86-Systemen erfüllt werden. Nur noch in wenigen Ausnahmefällen, wie z.B. im wissenschaftlichen Bereich, wird begründeter Bedarf an anderen Prozessorarchitekturen gesehen. Ziel ist eine weitestgehende Standardisierung auf x86 -Systeme.
Die Festlegung von Standards auf höheren Schichten (Betriebssystem, DB, Abhängigkeiten Applikationsserver usw.) wird durch diese Vorgabe eingeschränkt.
Beschaffte Anwendungen müssen kompatibel mit der Prozessor- Implikationen Architektur sein.
Anhänge 93
TIAV-02: Nutzung von Windows oder Linux als Server-Betriebssystem
Grundsätzlich sind Windows oder Unix-Derivate in der jeweils aktuellen Version als Serverbetriebssysteme zu nutzen. Dabei ist auf einen möglichst Beschreibung langfristigen Support durch den Hersteller oder Distributor zu achten. Weiterhin muss die entsprechende Version durch das BSI freigegeben worden sein.
Einheitliche Server-Betriebssysteme ermöglichen die Kompatibilität und Interdependenzen zu anderen eingesetzten Technologien und Infrastrukturen aus dem Standardkatalog. Sie gewährleisten die Begründung Entwicklung von Software gegen eine definierte Plattform. Weiterhin wird der Betrieb durch die Nutzbarkeit von einheitlichen Installations- und Administrationswerkzeugen erleichtert und eine Reduzierung des Schulungsaufwandes erreicht.
Die Festlegung von Standards auf höheren Schichten (DB, Abhängigkeiten Applikationsserver usw.) wird durch diese Vorgabe eingeschränkt.
Beschaffte Anwendungen müssen mit Windows und/oder Unix-Derivaten Implikationen kompatibel sein.
TIAV-03: Nutzung von SQL Datenbanken als Datenbanksystem
Datenbankmanagementsysteme (DBMS) müssen grundsätzlich den SQL Standard unterstützen. Bei der Entwicklung von Anwendungen muss die Beschreibung Verwendung herstellerspezifischer Erweiterungen vermieden werden. Sind zur Lösung spezieller Problemstellungen andere Technologien (wie NoSQL) unverzichtbar, so ist eine Nutzung dieser möglich.
Die Standardisierung auf SQL ermöglicht funktionale Interdependenzen zu anderen eingesetzten Technologien und Infrastrukturen. Weiterhin erfolgt Begründung eine Vereinfachung der Programmierung durch einheitliche Sprache und Reduzierung des Schulungsaufwandes, sowie bessere Portierbarkeit bei einem Wechsel des DBMS.
94 Anhänge
Neuere Datenbankarchitekturen (z.B. In-Memory-Datenbanktechnik) bieten möglicherweise Vorteile gegenüber Standard SQL. Diese werden Abhängigkeiten jedoch noch im Rahmen von aktuellen und künftigen Entwicklungsprojekten evaluiert.
Implikationen Keine Implikationen vorhanden.
TIAV-04: Nutzung von standardisierten Programmiersprachen für die serverseitige Anwendungsentwicklung
Alle serverseitigen Softwareentwicklungen finden grundsätzlich in den standardisierten Programmiersprachen gemäß Anlage 7.7.2, in der jeweils aktuellen Version, statt. Entwicklungsumgebungen sind grundsätzlich gemäß Anlage 7.7.3 zu nutzen. Schnittstelle zum Nutzer sind offene und standardisierte Webtechnologien, wie HTML, CSS oder ECMAScript, die aus den Anwendungen heraus generiert werden. Die Verwendung von Active X, Flash und anderer herstellerspezifischer Webtechniken ist nicht zulässig. Alle Fachverfahren sollen als Webanwendung angeboten werden. Eine Entwicklung von Anwendungen auf Clientseite findet grundsätzlich nicht Beschreibung statt. Die Nutzung von herstellerspezifischen Erweiterungen oder Modifizierungen, z.B. modifizierten Entwicklungswerkzeugen, ist nicht zulässig. Proprietäre Technik wird weder server- noch clientseitig zur Entwicklung von Anwendungen verwendet. Moderne Programmierprinzipien und -technologien, wie modellgetriebene Softwareentwicklung, sind wenn notwendig zulässig. Der Verbund der IT-Dienstleister stellt bereits einen etablierten anpassbaren Aufbau von verwendbaren Elementen, Entwicklungswerkzeugen, Bibliotheken und Standards zur Verfügung.
Alle Verfahrensentwicklungen werden als Serveranwendungen erstellt. Serverseitige Entwicklungen reduzieren die Komplexität der Entwicklung und des Betriebes eines Verfahrens. Abhängigkeiten zu bestimmten Begründung Clientkonfigurationen und Herstellern werden verringert oder vermieden sowie Wartungen und Aktualisierungen erleichtert. Die Nutzung unterschiedlichster Clients für eine Anwendung wird möglich, da für den
Anhänge 95
Zugriff nur geringe Anforderungen an die Geräte der Nutzer gestellt werden müssen (Webbrowser). Durch die serverseitige Verfahrensbereitstellung bedarf es auf Client-Systemen keiner Software, keiner Laufzeitumgebungen (Runtimes). Dies erhöht die Sicherheit der Geräte, der Nutzer und ihrer Daten enorm. Weiterhin werden die Aufwendungen zur Pflege der Kundensysteme geringer.
Proprietäre Sprachen und Technologien können nicht genutzt werden, Abhängigkeiten auch wenn sie im Einzelfall als attraktive Alternative erscheinen.
Implikationen Keine Implikationen vorhanden.
TIAV-05: Ausschließliche Verwendung von JEE-Applikationsservern
Um den Betrieb der Fachverfahren so einfach, wartbar, migrierbar und zukunftssicher wie möglich zu machen, werden ausschließlich vollständig JEE-kompatible Applikationsserver und Servlet-Container verwendet. Beschreibung Anpassungen und Ergänzungen einzelner Hersteller dürfen grundsätzlich nicht verwendet werden. Abweichungen unterliegen einem Genehmigungsvorbehalt.
Durch die Konzentration auf standardisierte Java-Funktionalitäten und die Vermeidung von Herstellerspezifika aller Art, wird es möglich, Applikationen über unterschiedliche Serverlandschaften zu migrieren, zu konsolidieren und günstiger zu betreiben. Zusätzlich gibt die Begründung Unabhängigkeit von einem Hersteller und seinen Planungen zu einem Produkt (wie z. B. Abkündigungen, Kostensteigerungen bei Lizenzen, mangelnder Wartung, fehlenden Sicherheitspatches o. ä.) gefördert. Weiterhin ist sowohl im JEE-Entwicklungsbetrieb sowie im JEE- Administrationsbetrieb gut ausgebildetes Personal zu finden (extern).
Abhängigkeiten Diese Richtlinie bildet eine Grundlage für die Vorgabe TIAV-04.
Implikationen Keine Implikationen vorhanden.
96 Anhänge
TIAV-06: Nutzung von quelloffenen Bibliotheken und Werkzeugen bei der Anwendungsentwicklung
In der Anwendungsentwicklung sind grundsätzlich quelloffene Bibliotheken, Frameworks und Programme zu verwenden, wo immer dies möglich und sinnvoll ist. Ein definierter Satz an Bibliotheken steht bereit Beschreibung und kann direkt verwendet werden. Abweichungen unterliegen einem Genehmigungsvorbehalt der Softwarearchitektur. Werkzeuge zur modellgetriebenen Architektur/Softwareentwicklung und Quellcodegeneratoren werden unterstützt.
Mit der Verwendung quelloffener Bibliotheken und Entwicklungswerkzeuge wird sichergestellt, dass es jederzeit möglich ist, nicht nur Bestandteile funktionsgleich zu tauschen, sondern auch die Betriebsfähigkeit der Verfahren dauerhaft sicherzustellen.
Begründung Zusätzlich ist es möglich, die Vorteile der Offenheit zu nutzen. Aktualisierungen der Bibliotheken erfolgen schnell und sind gut dokumentiert, sicherheitskritische Fehler werden offen kommuniziert und gefundene Fehler können ggf. selbst behoben werden, so dass die Abhängigkeit von Dritten gering ist.
Abhängigkeiten und Inkompatibilitäten unterschiedlicher Lizenzen sowie Abhängigkeiten Einschränkungen hinsichtlich der Nutzung im militärischen- und Regierungsumfeld müssen beachtet werden.
Implikationen Keine Implikationen vorhanden.
TIAV-07: Verfolgung des Bundescloud-First-Ansatzes (höchst möglicher Level)
Eine wichtige Aufgabe im Rahmen der IT-Konsolidierung ist der Aufbau einer Bundescloud. Dies beinhaltet die Bereitstellung der folgenden
Beschreibung aufeinander aufsetzenden Cloud-Services-Typen:
• Infrastructure-as-a-Service (IaaS) • Platform-as-a-Service (PaaS)
Anhänge 97
• Software-as-a-Service (SaaS)
Für alle zukünftigen Veränderungen bzgl. der IT der Behörden und Einrichtungen muss geprüft werden, ob sich hierfür Angebote der Bundescloud verwenden lassen. Dies betrifft Angebote auf allen Ebenen der Bundescloud, wobei das Angebot IaaS grundsätzlich immer in Betracht zu ziehen ist. Der Dienst Bundescloud ist grundsätzlich gemäß Architekturvorgabe DAAV-01 zu nutzen.
Mit der Umsetzung der Bundescloud wird das Ziel verfolgt, künftig die IT- Lösungen des Bundes mit einer standardisierten Cloud-Technologie zu betreiben. Dabei wird grundsätzlich angestrebt, das komplette Begründung Produktportfolio cloudfähig zu gestalten und nach dem Modell „Software as a Service“ bereitzustellen. Dies ermöglicht eine Standardisierung, verbrauchsgerechte Abrechnung, Automatisierung, Endgeräteunabhängigkeit und Verbesserung der Sicherheit.
Sollten neue Dienste benötigt werden, so ist zu prüfen ob diese gemäß Architekturvorgabe DAAV-01 in der Bundescloud betrieben werden Abhängigkeiten können. Dies betrifft insbesondere die in Anhang 7.2 angegebenen Dienste. Weiterhin sind für den Einsatz von Cloud Diensten die Vorgaben ISAV-09 und TIAV-10 zu beachten.
Durch den Verbund der IT-Dienstleister ist zu definieren, welche Voraussetzungen durch die IT einer Behörde oder Einrichtung zu erfüllen sind, damit zumindest IaaS der Bundescloud genutzt werden kann (siehe Katalog „Dienste der Bundescloud“). Es ist in diesem Zusammenhang die Bereitstellung von IaaS vorrangig durch die IT-Dienstleister zu betreiben. Implikationen Eine verpflichtende Nutzung der Bundescloud besteht erst dann, wenn die Leistungsfähigkeit der Bundescloud durch die IT-Dienstleister sichergestellt ist. Wenn möglich, sollten durch die Behörden und Einrichtungen die für eine Konsolidierung relevanten Anteile ihrer IT auf virtualisierte Umgebungen umgestellt werden, wenn eine Überführung in die Bundescloud mittelfristig beabsichtigt ist.
98 Anhänge
TIAV-08: Sicherstellung von energie- und ressourceneffizienten
Rechenzentrumsdienstleistungen
Die Kriterien des „Blauen Engels“ für einen energieeffizienten Beschreibung Rechenzentrumsbetrieb sollen in den Rechenzentren der Bundesverwaltung angewendet werden.
Die Vorgabe dient der Erfüllung der Verpflichtungen aus dem Maßnahmenprogramm „Nachhaltigkeitsstrategie für Deutschland“ (Beschluss März 2015). Insbesondere die Maßnahmen zum Klimaschutz als Beitrag auf dem Weg zu einer klimaneutralen Bundesverwaltung. Daraus ergibt sich das konkrete Ziel, dass die Kriterien des „Blauen Engels für einen Begründung energieeffizienten Rechenzentrumsbetrieb“ angewendet werden sollen. Darüber hinaus ist diese Maßnahme ein wesentlicher Beitrag für die Umsetzung der Digitalen Agenda 2014-2017. Darin wird erklärt, dass die Anstrengungen verstärkt werden sollen, den Energie- und Ressourcenverbrauch der IKT der Bundesverwaltung weiter zu senken.
Abhängigkeiten Diese Vorgabe konkretisiert die Vorgabe ÜBAV-10.
Durch die Umsetzung dieser Kriterien können der Energieverbrauch reduziert und natürliche Ressourcen geschont werden. Darüber hinaus Implikationen können mit dieser Maßnahme Energie- und Investitionskosten reduziert werden.
TIAV-09: Verpflichtende Verwendung SOAP- oder REST-basierter Schnittstellen
Neu entwickelte und ressortübergreifend genutzte Basis- oder Querschnittsdienste der Bundesverwaltung müssen ihre Funktionalität grundsätzlich über SOAP- oder REST-basierte Schnittstellen bereitstellen. Beschreibung Ausnahmen sind nur zulässig, sofern zwingende funktionale oder nichtfunktionale Anforderungen nach alternativen Lösungen verlangen. Bei der Übertragung von SOAP Nachrichten ist weiterhin Web Services Security (WS-Security) 1.1 als Standard zu nutzen.
Anhänge 99
Die Nutzung von weit verbreiteten Schnittstellenstandards für die Kommunikation mit Diensten erleichtert die Integration der Access Control Begründung Funktionalität, da beispielsweise auf bestehende und leicht integrierbare Interceptor Lösungen (Reverse Proxy, Gateway etc.) zurückgegriffen werden kann.
Abhängigkeiten bestehen zu allen Architekturvorgaben, Maßnahmen und Abhängigkeiten Vorhaben, welche diese allgemeine Vorgabe berücksichtigen.
Diese allgemeine Richtlinie ist grundsätzlich bei Entwurf, Entwicklung und Implikationen Bereitstellung von Diensten zu berücksichtigen.
TIAV-10: Angebot zentraler Dienste erfolgt über behörden-übergreifende gemeinsame Infrastruktur mit geeigneten Trennungsmechanismen
Im Verbund der IT-Dienstleister werden zentrale Applikationen, Fachverfahren, Dienste und (X)aaS-Cloudangebote über nutzerübergreifende und gemeinsame Infrastrukturen bereitgestellt. Gemeinsame IT-Infrastrukturen umfassen hierbei alle informationstechnischen Ressourcen. Hierzu gehören beispielsweise Anwendungssysteme für mehrere Mandanten sowie gemeinsame Datenbank-Managementsysteme und Datenbanken, Speicher- und Managed Storage-Systeme sowie Backup-Systeme in konventionellen und virtualisierten Umgebungen.
Eine geeignete Trennung der Nutzer muss in den IT-Infrastrukturen Beschreibung gewährleistet sein. Abhängig vom konkreten Nutzungsszenario, ist eine Kombination von Trennungsmechanismen auf verschiedenen Ebenen geeignet festzulegen. Hierfür steht eine Reihe von Mechanismen zur Separierung, Segmentierung und Mandantentrennung zur Verfügung, wie beispielsweise ein geeignetes Rechte- und Rollenmanagement, dedizierte virtuelle Server, dedizierte Plattenpartitionen, dedizierte virtuelle LANs für unterschiedliche Nutzer, unterschiedliche Verschlüsselung in den Datenbereichen unterschiedlicher Nutzer oder physische Trennung.
Bei der Auswahl der Trennungsmechanismen sind Aspekte der Wirtschaftlichkeit im Rahmen eines Risikomanagements hinreichend zu
100 Anhänge
berücksichtigen. Das Risikomanagement hat Schutzbedarf und Wirtschaftlichkeit in einem transparenten Prozess gegeneinander abzuwägen und abzustimmen.
Zentral bereitgestellte Applikationen, Fachverfahren, Dienste und (X)aaS- Cloudangebote bedingen eine gemeinsame Infrastruktur für mehrere Nutzer/innen (Aspekte der Shared Infrastructure), ohne den die gewünschten Mehrwerte, den die IT-Konsolidierung erzielen möchte, nicht geschaffen werden. Erst hierüber können u. a. folgende Ziele erreicht werden:
• Funktionale Entflechtung, • Self Service und Messbarkeit, Begründung • Erreichung betrieblicher Skaleneffekte und • effizientere Ressourcennutzung durch Virtualisierung.
Die Notwendigkeit zur Nutzertrennung ergibt sich aus zwei wesentlichen Gründen. Erstens soll sichergestellt werden, dass sich ein Angreifer nicht ungehindert in der IT-Infrastruktur ausbreiten kann. Zweitens soll sichergestellt werden, dass ein Mandant (Nutzer A) nicht unberechtigt Informationen von anderen Mandanten (Nutzer B, C, usw.) einsehen oder auf dessen Ressourcen zugreifen kann.
Die Verkehrsflüsse in NdB müssen eine gemeinsame Nutzung durch alle Nutzer von zentralen Applikationen, Fachverfahren, Diensten und (X)aaS- Cloudangebote, die auf einer gemeinsamen Infrastruktur angeboten werden, ermöglichen. Eine Separierung auf Netzebene ist aber weiterhin erforderlich.
Welche Kombination von Trennungsmechanismen eingesetzt wird, ist u. a.
Abhängigkeiten vom jeweiligen Schutzbedarf der Daten und davon abhängig, ob es sich um Shared oder Private Services (im NdB-Kontext) handelt.
Die Auswahl geeigneter Trennungsmechanismen im Rahmen der IT- Konsolidierung Bund ist Gegenstand intensiver Erörterungen zwischen IT- Dienstleister, TP6 und BSI.
Weiterhin konkretisiert diese Vorgabe die Architekturvorgabe ISAV-12.
Eine Anpassung der Sicherheitsstrategien des Bundes im Bereich der Netz- und Implikationen IT-Konsolidierung ist ggf. notwendig.
Anhänge 101
Behörden, die über die o. g. Infrastruktur eigenentwickelte Dienste/Services/ Fachverfahren anbieten, müssen in Eigenverantwortung ggf. Anpassungen an ihrem „Produkt“ vornehmen, sofern eine sicherheits-konforme Trennung innerhalb der Applikation/Daten erforderlich ist.
7.4.2 Netzinfrastruktur
Die Vorgaben in diesem Kapitel beziehen sich auf Architektur-Aspekte, die einen direkten Bezug zur Nutzung oder Bereitstellung von Netzdiensten haben. Diese Architekturrichtlinie gilt, mit Ausnahme von TNAV-04, nicht für die Architektur der Netze an sich. Diese zu erstellen, ist eine explizite Aufgabe des Architekturboards im Projekt NdB.
TNAV-01: Geeignete Übernahme der NdB-Segmentierung im Nutzer-LAN
Bei NdB sind die für den Nutzer relevanten Netzsegmente: Daten (APCs, …), Sprache (vermittelte IP-Sprache mit Anbindung an das öffentliche Telefonnetz) und IP-Video (Raum-IP-VK-Anlagen), ITVZ (Anbieten von Beschreibung Fachverfahren für andere NdBA1-5-Nutzer) und WebDMZ (Anbieten von Diensten für andere Verwaltungsnetze und Nutzer im Internet). Diese werden beim Übergabepunkt im NdBA-Schrank auf jeweils getrennten Ports übergeben und sind geeignet durch den Nutzer fortzuführen.
NdB segmentiert im Kernbereich Sprach-, Daten-, Video- und Managementverkehr, um negative Auswirkungen z. B. durch Angriffe auf die jeweils anderen Bereiche ausschließen zu können. Durch eine vom Nutzer zu etablierende Fortführung der NdB-Segmentierung im Nutzer- Begründung LAN kann gewährleistet werden, dass eine sichere Kommunikationsfähigkeit auch in besonderen Lagen Ende-zu-Ende sichergestellt ist und eine Schadcodeausbreitung von einer Verkehrsart in eine andere Verkehrsart verhindert wird.
Abhängigkeiten Keine Abhängigkeiten vorhanden.
Die Fortführung der Segmentierung im LAN des Nutzers muss in Abhängigkeit vom gewählten Anschluss (NdBA1-4 oder NdBA5) und unter Implikationen Berücksichtigung der NdB-Sicherheitsanforderungen (siehe NdB- Nutzerpflichten) geeignet fortgeführt werden.
102 Anhänge
TNAV-02: Nutzung von zentral bereitgestellten Kommunikationsverbindungen
Die Nutzer verwenden die von IVBB / NdB zentral bereitgestellten und gesicherten Kommunikationsverbindungen, so dass grundsätzlich keine anderen Netzanschlüsse erforderlich werden sollen. Diese Vorgabe ist primär anzuwenden, wenn mehrere Liegenschaften betroffen sind. In Zugangsnetzbereichen und bei einzelnen Liegenschaften ist eine Prüfung notwendig, die gegebenenfalls eine abweichende Nutzung erlaubt. Folgende zentrale Kommunikationsverbindungen werden durch NdB angeboten:
• Bereitstellung von verschlüsselten LAN-LAN-Kopplungen zu weiteren Liegenschaften des Nutzers (unter Berücksichtigung der Dienstesegmentierung) • Bereitstellung eines zentral abgesicherten Internetanschlusses für den Zugriff auf das Internet • Zugriff auf zentrale Dienste (z. B. E-Mail, De-Mail, PKI, X500) und Fachverfahren im Intranet des Bundes • Zugriff auf dezentrale Fachverfahren im Intranet des Bundes Beschreibung (Bereitstellung über ITVZ) • Zugriff auf Dienste und Fachverfahren in anderen Verwaltungsnetzen (VN, Testa usw.) und NdB-Schutzbedarf- normal-Netz • Bereitstellung von leistungsfähigen Internetzugängen für eigene Internetdienste • Einwahl von BSI zugelassenen mobilen Zugängen • Einwahl von verwaltungsexternem Personal für Fernwartungstätigkeiten in der Behörde (wenn eine zentrale Fernwartungsplattform verfügbar ist) • Zugriff auf weitere Netze, wenn allgemeiner Bedarf besteht
Die entsprechenden Kommunikationsverbindungen und Netzanschlüsse werden an den Anforderungen der IT-Konsolidierung Bund neu ausgerichtet, sodass für die IT-Konsolidierung Bund benötigte Bandbreiten und eine ausreichende Netzqualität (QoS, d. h. Priorisierung von Verkehrsklassen) zur Verfügung stehen.
Anhänge 103
Ohne die Bereitstellung/Nutzung der zentralen Kommunikationsverbindungen wird die Etablierung eines einheitlichen, hohen Sicherheitsniveaus für NdBA1-5, um die Begründung Vertraulichkeit/Integrität/Verfügbarkeit jedes einzelnen Nutzers zu schützen und den sicheren NdB-internen Austausch von Informationen bis zum Geheimhaltungsgrad VS-NUR FÜR DEN DIENSTGEBRAUCH zu ermöglichen, erschwert.
Abhängigkeiten Keine Abhängigkeiten vorhanden.
Erforderliche Zugriffsmöglichkeiten in andere Netze, die zentral durch NdB/IVBB nicht bereitgestellt werden, können durch dezentrale Fremdnetzübergänge realisiert werden, sofern die NdB-Sicherheits- Implikationen anforderungen umgesetzt werden. Unter Berücksichtigung der von NdB angebotenen Kommunikationsverbindungen sollte eine für die jeweilige Behörde geeignete LAN-Architektur entwickelt werden.
TNAV-03: Nutzung von Internet Protocol Version 6 (IPv6) als Netzwerkprotokoll
Das „Internet Protocol“ (IP) ist ein verbindungsloses Protokoll der Vermittlungsschicht und erlaubt den Austausch von Daten zwischen zwei Rechnern ohne vorherigen Verbindungsaufbau. IP muss zur Übermittlung von Datenpaketen innerhalb eines Netzwerkes unterstützt werden. Beschreibung Grundsätzlich ist die Nutzung von IPv6 anzustreben. Aufgrund hoher Sicherheitsanforderungen und heterogener Strukturen ist die Nutzung von IPv4 aus Bestandsschutzgründen möglich. Neu beschaffte Hardware muss kompatibel zu IPv6 ausgelegt sein.
Das Internet Protocol ist ein bereits seit vielen Jahren etablierter internationaler de-facto-Standard für den netzwerkbasierten Datenaustausch. Die Version 6 muss die Protokollversion 4 .ablösen, da Begründung diese langfristig mangels verfügbarem Adressraum keine Zukunftsfähigkeit bietet. Die Unterstützung von IPv6 im Netzwerk (hier vor allem im Backbone) sowie die herstellerseitige Unterstützung von den an das Netzwerk angeschlossenen Endgeräten ist inzwischen ausreichend
104 Anhänge
groß, um weitere Schritte der flächendeckenden Einführung zu planen.
Die Ablösung von IPv4 durch IPv6 bedingt zahlreiche Abhängigkeiten. Folgende Punkte sind u.a. zu klären:
• Unterstützen alle angeschlossenen Netzwerk (Legacy-)Endgeräte Abhängigkeiten IPv6 herstellerseitig, • Wurde eine entsprechende Re-Adressierung vorgenommen, • Wurde die Adressauflösung flächendeckend eingeführt (DNS)
Die Implikationen der flächendeckenden Einführung von IPv6 sind aufgrund der vielfachen Abhängigkeiten sehr groß. Neben dem finanziellen Aufwand sind in einer längeren Übergangsphase auch Implikationen Stabilitätsprobleme in allen Diensten zu erwarten. Dies liegt alleine darin begründet, dass der Erfahrungshintergrund der beteiligten Diensteerbringer im Umfeld IPv6 erst aufgebaut werden muss.
TNAV-04: Sicherstellung der Skalierbarkeit von NdBA-Anschlussbandbreiten inkl. Transportnetz
NdB wird auf Basis der geplanten vom BSI zugelassenen Kryptierer skalierbare Anschlussbandbreiten für Nutzer und Rechenzentren ermöglichen (entweder pro Anschluss oder über Lastverteilung über mehrere Anschlüsse), um mit zukünftig steigender Leistung der Kryptierer auch zukünftig steigende Bandbreitenbedarfe vor dem Hintergrund der Betriebs- und Dienste-Konsolidierung zu kompensieren. Die Anforderung an skalierbare Anschlussbandbreiten beziehen sich sowohl auf Anschlüsse
Beschreibung zur Anbindung von Nutzern und Rechenzentren für Zugriffe auf Dienste und Fachverfahren als auch auf die von den IT-Dienstleistern des Leistungsverbundes benötigten leistungsstarken und skalierbaren Backbone-Verbindungen zwischen den verschiedenen lokalen und regionalen Rechenzentren im VITD.
Das Transportnetz von NdB (derzeit KTN-Bund) wird diesen steigenden Bedarf an NdB-Anschluss- und Übertragungsbandbreiten aufnehmen und ohne Einschränkung übertragen.
Anhänge 105
Die Reduzierung und Zentralisierung der Rechenzentren führt zu einer Konzentration der Datenströme auf wenige Anschlüsse mit entsprechend hohem Bandbreitenbedarf (primär bezogen auf die Rechenzentrums- NdBA).
Begründung Auch bei den reinen Nutzerstandorten ist mit einem Zuwachs des Bandbreitenbedarfs zu rechnen, da zukünftig von der lokalen Bereitstellung auf eine zentralisierte Bereitstellung durch den Verbund der IT- Dienstleister über NdB geschwenkt wird (im Rahmen der Dienste- und Rechenzentrums-Konsolidierung).
Der Erfolg der Konsolidierung und die Bereitstellung zentraler Dienste und Abhängigkeiten deren Nutzbarkeit hängen von einer qualitativ ausreichenden Netzinfrastruktur und skalierbaren Bandbreiten ab.
Die NdBA-Anschluss- und Übertragungsbandbreiten müssen über die im NdBA eingesetzten Kryptierer in der gewünschten Größenordnung nutzbar sein. Um die steigenden Bandbreitenbedarfe auf Portebene auch zukünftig durch effiziente und skalierbare Verschlüsselungshardware BSI-konform zu Implikationen kryptieren, muss die derzeit eingesetzte Hardware entsprechend weiterentwickelt und leistungsfähiger werden (unter Beibehaltung der derzeitigen BSI-Sicherheitsanforderungen). Dies ist als gemeinsames Ziel von NdB und IT-Konsolidierung Bund zu verstehen.
106 Anhänge
7.5 Architekturvorgaben zu Informationssicherheit, Datenschutz und Geheimschutz
Im Zuge des Vorhabens „IT-Konsolidierung Bund“ soll ein übergreifendes Informationssicherheitsmanagement (ISM) konzipiert und etabliert werden, das auf den bestehenden ISM-Systemen der Dienstleistungszentren (insbesondere des ITZBund) und der Kundenbehörden gemäß Umsetzungsplan Bund aufbaut und diese ISM-Systeme miteinander verzahnen soll. Außerdem ist ein übergreifendes Business Continuity und Krisenmanagement sowie ein Sicherheitsvorfallmanagement vorzusehen. Entsprechende Architekturvorgaben diesbezüglich werden zu gegebener Zeit veröffentlicht. Sobald übergreifende Strukturen etabliert sind, sind die behördeninternen Strukturen entsprechend anzupassen. Neben den nachfolgend aufgeführten Architekturvorgaben sind weitere IT-Sicherheitsmaßnahmen – insbesondere organisatorischer und personeller Art – zu berücksichtigen. Diese werden in der geplanten „Leitlinie zur Informationssicherheit der IT- Konsolidierung Bund“ (Arbeitstitel) ausgeführt.
ISAV-01: Einbindung von IT-Verfahren in ein Business Continuity- und Krisenmanagement
Jedes IT-Verfahren muss (bis ein übergreifendes BCM und KM etabliert wurde) anhand seiner Kritikalität in ein geeignetes, behördeninternes Business Continuity Management (BCM) und Krisenmanagement (KM) eingebunden sein.
Voraussetzung ist, dass jeder IT-Verfahrensbetreiber ein geeignetes BCM und KM aufgebaut hat. Dabei sind der BSI-Standard BSI-100-4 (Notfallmanagement) und der daraus abgeleitete Grundschutzbaustein B 1.3 Beschreibung (IT-Notfallmanagement) zu beachten.
Die Konzeption Zivile Verteidigung (KZV, http://www.bmi.bund.de/SharedDocs/Kurzmeldungen/DE/2016/08/vorste llung-konzeption-zivile-verteidigung.html) sieht vor, dass die Staats- und Regierungsfunktionen auch in Krisenfällen funktionsfähig bleiben müssen. Hierzu sind im Bereich der IT-Sicherheit die Mindeststandards des BSI nach § 8 BSIG maßgeblich.
Begründung BCM und KM sind integrale Bestandteile der Sicherheitskonzeption im
Anhänge 107
Sinne des ISM. Nur so lässt sich der Weiterbetrieb der konsolidierten IT auch in besonderen Lagen gewährleisten.
Abhängigkeiten Keine Abhängigkeiten vorhanden.
Implikationen Keine Implikationen vorhanden.
ISAV-02: Nutzung von Identitäts- und Berechtigungsmanagement (IAM)
Für die IT-Verfahren der Bundesverwaltung muss die Authentizität und Autorisation aller Entitäten jederzeit sichergestellt sein. Dazu sind hinreichend starke Verfahren einzusetzen. Die Technischen Richtlinie 03107-1 (Elektronische Identitäten und Vertrauensdienste im E- Beschreibung Government, Teil 1: Vertrauensniveaus und Mechanismen) des BSI ist einzuhalten und der Grundschutzbaustein B 1.18 (Identitäts- und Berechtigungsmanagement) anzuwenden. Die zeitnahe Synchronisation der lokalen IAM der Beteiligten muss sichergestellt werden.
Das Identitäts- und Berechtigungsmanagement (IAM) ist ein integraler Bestandteil der Sicherheitskonzeption im Sinne des ISM. Das IAM hat eine Begründung herausragende Bedeutung, weil eine unberechtigte Kontrolle des IAM Zugriff auf alle Ressourcen der konsolidierten IT geben würde.
ISAV-12 (Separierung / Segmentierung / Mandantentrennung) ist insbesondere beim IAM zu berücksichtigen, in der Regel auf der Ebene der Nutzerbehörde.
Abhängigkeiten Es sind die Ergebnisse des TP6-Projekts "Ressortübergreifendes Identitätsmanagement für die Bundesverwaltung" zu beachten.
Weiterhin wird diese Richtlinie für Dienste in den Richtlinien DAAV-20, DAAV-21 und DAAV-22 weiter spezifiziert.
Den Entitäten können im Rahmen des IAM Rollen und Rechte zugewiesen Implikationen werden.
108 Anhänge
ISAV-03: Sicherstellung des Datenschutzes aller IT-Verfahren
Die in der Bundesverwaltung betriebenen IT-Verfahren, welche Beschreibung personenbezogene Daten verarbeiten, sind nach dem jeweils aktuellen Stand der Technik datenschutzkonform zu gestalten.
Es handelt sich um eine gesetzliche Aufgabe. Der Datenschutz ist durch Umsetzung der Anforderungen des Bundesdatenschutzgesetzes (BDSG), das Begründung 2018 durch die EU-Datenschutzgrundverordnung ersetzt wird, und anderer datenschutzrechtlicher Regelungen zu gewährleisten.
Abhängigkeiten Diese Vorgabe konkretisiert weiterhin die Vorgabe ÜBAV-04.
Vor Inbetriebnahme eines IT-Verfahrens muss ein gültiges Datenschutzkonzept vorliegen und umgesetzt sein.
Der Stand der Technik muss turnusmäßig überprüft und angepasst werden. Implikationen Es sind die Standards, Empfehlungen und Konzepte zu diversen Aspekten des Datenschutzes zu berücksichtigen. Bei einigen IT-Verfahren ist sogar noch während der Planung eine „Vorabkontrolle“ durch den behördlichen Datenschutzbeauftragten gesetzlich vorgeschrieben.
ISAV-04: Sicherstellung des Geheimschutzes aller IT-Verfahren
Die betriebenen IT-Verfahren, die Verschlusssachen (VS) bis zum Geheimhaltungsgrad VS-NUR FÜR DEN DIENSTGEBRAUCH verarbeiten, sind nach dem jeweils aktuellen Stand der Technik geheimschutzkonform zu gestalten.
Für den materiellen Geheimschutz, unter den auch der Aspekt der VS-IT- Beschreibung Sicherheit fällt, sind die Vorgaben des Sicherheitsüberprüfungsgesetzes, der VSA sowie die, Technischen Leitlinien und Empfehlungen des BSI zu berücksichtigen.
Bei der Auswahl geeigneter Schutzmaßnahmen kann Berücksichtigung finden, dass Netze des Bundes bei der Übertragung von Informationen über
Anhänge 109
öffentliche Bereiche mit Ausnahme besonderer Anschlusstypen bereits eine vom BSI für den Geheimhaltungsgrad VS-NUR FÜR DEN DIENSTGEBRAUCH zugelassene Verschlüsselung einsetzt.
In Konkurrenz zu Wirtschaftlichkeitsgrundsätzen ist den Anforderungen des Geheimschutzes eine höhere Priorität einzuräumen.
Es handelt sich um eine gesetzliche Aufgabe. Der Geheimschutz ist durch Begründung die Umsetzung der Anforderungen des Sicherheitsüberprüfungsgesetzes (SÜG) und der Verschlusssachenanweisung (VSA) zu gewährleisten.
Abhängigkeiten Diese Vorgabe konkretisiert die Vorgaben gemäß ÜBAV-04.
Vor Inbetriebnahme eines IT-Verfahrens, das VS verarbeitet, muss eine Freigabe des VS-IT-Verfahrens durch die Leitung der Dienststelle oder ggf. Implikationen durch die federführende Stelle erfolgen. Der Stand der Technik muss turnusmäßig überprüft und angepasst werden. Die diesbezüglichen Regelungen der VSA sind zu beachten.
ISAV-05: Robustheit und Resilienz gegen gezielte Angriffe, Krisen, Notfälle und technische Störungen
Die IT-Verfahren – inklusive aller ihrer Ressourcen und Strukturen – der gesamten Bundesverwaltung sind so robust und resilient zu gestalten, dass technische Störungen, Notfälle, Krisen und gezielte Angriffe nur Beschreibung tolerierbare Auswirkungen haben. Die Vorgabe ist mit einem geeigneten Risikomanagement zu verknüpfen, insbesondere um „tolerierbare Auswirkungen“ identifizieren zu können.
Da es unmöglich ist, alle IT-Verfahren von vornherein so robust zu Begründung gestalten, dass sie den genannten Gefährdungen in jedem Fall widerstehen, kommt insbesondere der Resilienz eine besondere Bedeutung zu.
BSI-Standard 100-3 (Risikoanalyse auf der Basis von IT-Grundschutz) und Abhängigkeiten 100-4 (Notfallmanagement) sind zu beachten.
Der Aufbau eines geeigneten BCM und Krisenmanagements ist eine Implikationen Voraussetzung, um Robustheit und Resilienz auch in besonderen Lagen gewährleisten zu können. Entsprechende Abstimmungen sollen über den
110 Anhänge
Ressortkreis nationales Krisenmanagement (BMI, KM 1) erfolgen.
ISAV-06: „Security by Design“, „Privacy by Design“ und „Privacy by Default“ im Lebenszyklus von IT-Verfahren und Produkten
Sicherheits-, Datenschutz- und Geheimschutzanforderungen und deren Beschreibung Implementierung sind ein Designelement für jeden Teil des Lebenszyklus von IT-Verfahren und Produkten.
„Security by Design“, und „Privacy by Design“ und „Privacy by Default“ sind Begründung zentrale Elemente einer ganzheitlichen Sicherheitskonzeption bzw. Datenschutz- und Geheimschutzkonzeption.
Es sind die einschlägigen Standards, Empfehlungen und Konzepte im Bereich der IT-Sicherheit, des Datenschutzes und des Geheimschutzes einzuhalten.
Bei der Umsetzung von „Security by Design“ sind insbesondere die Grundsätze der sicheren Software-Entwicklung und Programmierung zu beachten (s. Grundschutzbausteine B 5.27 (Software-Entwicklung), B 5.25 (Allgemeine Anwendungen) sowie die allgemeine Literatur zu „Secure Abhängigkeiten Coding“). Beispielsweise sind bei Webanwendungen alle Eingabedaten auf Zulässigkeit zu prüfen und bei der Abnahme des Verfahrens vor Inbetriebnahme zu testen. Siehe auch ISAV-15 (Kontrolle der Einhaltung von Sicherheitsvorgaben).
Es gibt Aspekte, bei denen die Prinzipien „Security by Design“, „Privacy by Design“ und „Privacy by default“ in einem natürlichen Zielkonflikt stehen. Hier ist im Einzelfall zu entscheiden. Diese Vorgabe konkretisiert die Vorgabe ÜBAV-04 hinsichtlich des Daten- und Geheimschutzes.
Informationssicherheit, Datenschutz und Geheimschutz sind kein Zusatz, der am Ende einer Design-, Entwicklungs- oder Realisierungsphase steht, Implikationen sondern ein integraler Bestandteil jeder IT-Lebenszyklusphase von Anfang an.
Anhänge 111
ISAV-07: Festlegung von Schutzbedarf und Dienstgüte (Verlässlichkeit) für IT-Verfahren und ihrer Ressourcen
Für jedes einzelne IT-Verfahren sind der Schutzbedarf und die Dienstgüte festzulegen.
Zudem ist der Schutzbedarf für Systeme festzustellen, auf denen mehrere IT-Verfahren (ggf. unterschiedlicher Nutzer) betrieben werden. Beschreibung Bei der Festlegung des Schutzbedarfs sind Kumulationseffekte zu berücksichtigen.
BSI-Standards 100-1 bis 100-3 leisten Hilfestellung bei der Festlegung des Schutzbedarfs.
Die Festlegung von Schutzbedarf und Dienstgüte ist erforderlich für die zukünftige Steuerung des Leistungsverbunds im Sinne des ISM und für ein Begründung SLA-Management. Über die SLA bilden diese Schutzbedarfs- und Dienstgütefestlegungen die Grundlage eines Verrechnungsmodells.
Abhängigkeiten Keine Abhängigkeiten vorhanden.
Die Festlegung von Schutzbedarf und Dienstgüte hat weitreichende Konsequenzen, beispielsweise hinsichtlich der umzusetzenden Maßnahmen zur Redundanz.
Implikationen Solange es noch keine einheitlichen Schutzbedarfs- und Dienstgütekategorien gibt, müssen die Verfahrensverantwortlichen Schutzbedarf und Dienstgüte ggf. detaillierter bilateral mit den IT- Dienstleistungserbringern aushandeln.
ISAV-08: Einhaltung von BSI-Standards, insbesondere IT-Grundschutz
Die in der Bundesverwaltung betriebenen IT-Verfahren halten die einschlägigen BSI-Standards ein, insbesondere alle Mindeststandards nach Beschreibung § 8 BSIG, die BSI-Standards 100-1 bis 100-4, sowie Technische Richtlinien und Leitlinien.
112 Anhänge
Die Einhaltung von BSI-Standards ist ein integraler Bestandteil der
Begründung Sicherheitskonzeption im Sinne des ISM und des Geheimschutzes (Technische Leitlinien)
Abhängigkeiten Keine Abhängigkeiten vorhanden.
Zu allen genannten Standards, Richt- und Leitlinien bietet das BSI Implikationen entsprechende Beratungen und ggf. auch Zertifizierungsverfahren an.
ISAV-09: Sicheres Cloud Computing
Von allen durch die Bundesverwaltung genutzten Cloud-Diensten ist mindestens die Einhaltung des Anforderungskatalogs C5 des BSI sicherzustellen, vertraglich zu vereinbaren und durch entsprechende Testierungen nachzuweisen. Der Prüfbericht ist regelmäßig vorzulegen.
Nutzer/innen von Cloud-Diensten haben den Baustein 1.17 der IT- Beschreibung Grundschutz-Kataloge anzuwenden.
Es sind die Anforderungen des zukünftigen Mindeststandards Cloud Computing einzuhalten.
Es sind die Kriterien des „Blauen Engels“ für einen energieeffizienten Rechenzentrumsbetrieb einzuhalten.
Begründung Notwendiger Bestandteil des ISM.
Im C5 sind sowohl die Anforderungen als auch die Art des Nachweises durch eine Testierung beschrieben (https://www.bsi.bund.de/C5).
Zudem gelten die Vorgaben des IT-Ratsbeschlusses 05/2015 (Kriterien für Abhängigkeiten die Nutzung von Cloud-Diensten der IT-Wirtschaft).
Darüber hinaus wird voraussichtlich im 1. Quartal 2017 ein Mindeststandard „Sichere Nutzung externer Cloud-Dienste“ veröffentlicht.
Implikationen Keine Implikationen vorhanden.
Anhänge 113
ISAV-10: Erstellung und Umsetzung von Sicherheitskonzeptionen für alle IT- Verfahren
Für alle betriebenen IT-Verfahren muss vor der Inbetriebnahme ein Beschreibung gültiges IT-Sicherheitskonzept gemäß BSI-Standards 100-1 bis 100-3 vorliegen und umgesetzt sein.
Begründung Integraler Bestandteil der Sicherheitskonzeption im Sinne des ISM.
In Konkurrenz zu Wirtschaftlichkeitsgrundsätzen ist den Anforderungen Abhängigkeiten der Sicherheitskonzeption unter Berücksichtigung eines angemessenen Risikomanagements eine höhere Priorität einzuräumen.
Implikationen Keine Implikationen vorhanden.
ISAV-11: Einsatz kryptografischer Verfahren
Für alle betriebenen IT-Verfahren müssen angemessene kryptografische Beschreibung Verfahren nach dem Stand der Technik eingesetzt werden.
Kryptografische Verfahren sind das zentrale Instrument, um die Begründung Grundziele „Vertraulichkeit“ und „Integrität“ der Informationssicherheit sicherzustellen.
Der Stand der Technik bezüglich kryptografischer Verfahren ist in der jeweils aktuellen Fassung der Technischen Richtlinien 02102-X des BSI (Kryptographische Verfahren). Anwendungsbezogene Vorgaben und Empfehlungen finden sich in der Technischen Richtlinie 03116-X des BSI (Kryptographische Vorgaben für Projekte der Bundesregierung). Für den Bereich des BMVg gelten zusätzlich abhängig vom Anwendungsfall NATO- Abhängigkeiten Vorschriften.
Für bestimmte IT-Verfahren ist eine Verschlüsselung auch nach der Anlage zu § 9 BDSG und der VSA vorgeschrieben.
Zu berücksichtigen ist, dass Netze des Bundes entsprechend ISAV-04 (Sicherstellung des Geheimschutzes aller IT-Verfahren) bereits Angebote
114 Anhänge
bei der Übertragung bietet.
Der Stand der Technik muss turnusmäßig überprüft und angepasst Implikationen werden.
ISAV-12: Separierung / Segmentierung / Mandantentrennung
Beim Zusammentreffen von Verfahren unterschiedlicher Behörden in zusammenhängenden – insbesondere virtualisierten – IT-Umgebungen, sind die Grundsätze der Separierung zu beachten. Die Basis für die Konzeption und Maßnahmen bilden die Grundschutz- und Cyber- Sicherheits-Empfehlungen des BSI. Beschreibung Eine sichere Mandantentrennung ist ein Teilaspekt der Separierung und über entsprechende Mechanismen zu gewährleisten. Weitere Teilaspekte, insbesondere zur Separierung von Informationen mit mindestens hohem Schutzbedarf sind grundsätzlich mit höherwertigen Schutzmaßnahmen zu versehen.
Separierung ist das zentrale Instrument, um komplexen Angriffen in Begründung virtualisierten Umgebungen zu begegnen.
Es gelten die einschlägigen Cyber-Sicherheits-Empfehlungen des BSI (https://www.allianz-fuer-cybersicherheit.de/ACS/DE/_/downloads/BSI- CS_113.pdf) als Mindestanforderung, die Anforderungen des Datenschutzes und die des Geheimschutzes.
Zudem ist der Grundschutz-Baustein B 4.1 (Lokale Netze), insbesondere die Abhängigkeiten Maßnahmen M 5.61 (Geeignete physische Segmentierung) und M 5.62 (Geeignete logische Segmentierung), zu beachten. Weitere Empfehlungen ergeben sich aus den Grundschutz-Bausteinen B 5.23 (Cloud Management) und B 3.304 (Virtualisierung). Zusätzliche Hinweise finden sich in den Veröffentlichungen der ISi-Reihe des BSI zum Thema „Sichere Anbindung von lokalen Netzen an das Internet (ISi-LANA)“.
Implikationen Keine Implikationen vorhanden.
Anhänge 115
ISAV-13: Logging, Monitoring und Detektion von Anomalien
Für alle Verfahren ist das Logging aller sicherheitsrelevanten Ereignisse vorzusehen. Die Log-Daten sind in einem zentralen System revisionssicher zu speichern, zu überwachen und auf Anomalien zu überprüfen.
Die Log-Daten sind derart zu speichern, dass IT-SI 03 (Sicherstellung des Datenschutzes aller IT-Verfahren) eingehalten wird. Das Rechte- und Rollenkonzept muss derart gestaltet sein, dass eine einzelne Person keine Beschreibung Manipulation an Log-Quellen vornehmen kann.
Konkrete Vorgaben zum Logging und den vorzusehenden Schnittstellen sind dem zukünftigen Mindeststandard „Detektion von Angriffen“ zu entnehmen.
Außerdem ist der Grundschutz-Baustein B 5.22 (Protokollierung) anzuwenden.
Zielgerichtete Angriffe lassen sich nur durch die detaillierte Analyse von Begründung Log-Daten erkennen.
Abhängigkeiten Keine Abhängigkeiten vorhanden.
Der Bedarfsträger des IT-Verfahrens kann zu Zwecken der Implikationen Sicherheitsdatenanalyse das BSI dazu ermächtigen, diesem Zugriff auf die in Bezug zu diesem Verfahren gespeicherten Log-Daten zu gewähren.
ISAV-14: Einrichtung eines Sicherheitsvorfallmanagements
Jedes IT-Verfahren muss in ein geeignetes (bis auf weiteres behördeninternes) Sicherheitsvorfallmanagement eingebunden sein, um insbesondere den Meldepflichten des § 4 BSIG und der zugehörigen Beschreibung Verwaltungsvorschrift sowie des § 43 VSA nachkommen zu können.
Basierend auf dem Logging, Monitoring und der Detektion sind Sicherheitsvorfälle als solche zu erkennen und geeignet zu behandeln. Ein
116 Anhänge
konsistentes und umfassendes Vorgehen zur Erfassung, Bewertung, Kommunikation und Eskalation von Sicherheitsvorfällen ist zu gewährleisten.
Voraussetzung ist, dass jeder IT-Verfahrensbetreiber ein geeignetes Sicherheitsvorfallmanagement aufgebaut hat.
Insbesondere sind der IT-Grundschutz-Baustein 1.8 (Behandlung von Sicherheitsvorfällen), die Allgemeine Verwaltungsvorschrift über das Meldeverfahren gemäß § 4 Abs. 6 BSIG und die IT-Krisenreaktionspläne des Bundes gemäß IT-Ratsbeschluss vom 31.3.2011 Az IT 5-606000-9/16#34 zu beachten.
Diese Architekturvorgabe ist sowohl für jedes IT-Verfahren einzeln als auch in einem übergreifenden Kontext zu erfüllen.
Ein Sicherheitsvorfallsmanagement ist integraler Bestandteil der Begründung Sicherheitskonzeption im Sinne des ISM.
Abhängigkeiten Keine Abhängigkeiten vorhanden.
Zukünftig ist im Rahmen des übergreifenden ISM eine enge Verzahnung Implikationen aller Stakeholder inklusive NdB bzgl. des Sicherheitsvorfallsmanagements erforderlich.
ISAV-15: Kontrolle der Einhaltung von Sicherheitsvorgaben (Compliance-
Management)
Die Einhaltung der in der gesamten IT-Sicherheitskonzeption (als Teil des Compliance-Managements) festgelegten Anforderungen ist regelmäßig geeignet zu überprüfen – insbesondere durch Revisionen und Audits. Beschreibung Abweichungen müssen zeitnah berichtigt werden.
Der Baustein 1.16 (Anforderungsmanagement) der IT-Grundschutz- Kataloge behandelt das Compliance-Management insgesamt.
Begründung Integraler Bestandteil der Sicherheitskonzeption im Sinne des ISM.
Gegebenenfalls müssen die Anforderungen der Zertifizierungsaktivitäten Abhängigkeiten berücksichtigt werden.
Anhänge 117
Zu der Kontrolle der Einhaltung von Sicherheitsvorgaben gehört auch, dass entsprechende Tests bereits vor der Inbetriebnahme eines IT-Verfahrens Implikationen durchgeführt werden. Insbesondere darf kein Verfahren mit Internet- Konnektivität in Betrieb gehen, welches nicht geeignet vorab durch einen Penetrationstest und/oder Webcheck geprüft wurde.
ISAV-16: Durchführung notwendiger Zertifizierungen
Die IT-Dienstleistungszentren und Rechenzentren, die im Rahmen der IT- Konsolidierung Bund auf Dauer bestehen bleiben, haben unter anderem durch einen geeigneten Prozess der IT-Sicherheitszertifizierung gemäß ISO 27001 auf der Basis von IT-Grundschutz nachzuweisen, dass sie das Beschreibung erforderliche IT-Sicherheitsniveau erreicht haben und dauerhaft halten. Der Nachweis für einen kontinuierlichen Geschäftsbetrieb soll über ein Zertifikat nach ISO 22301 geführt werden. Darüber hinaus sind bei Bedarf (z. B. besonderem Schutzbedarf) spezifische IT-Verfahren geeignet zu zertifizieren.
Vorgabe der Konzeption der IT-Konsolidierung. Vorteil der nachprüfbaren Begründung Sicherheit.
Abhängigkeiten können zu den Anforderungen der Nutzerbehörden Abhängigkeiten bestehen.
Die Erlangung und Fortführung einer Zertifizierung für Rechenzentren und IT-Verfahren bedarf Anpassungen. Für die infrage kommenden Zertifizierungsziele müssen in der Regel eine detaillierte und geschlossene Implikationen Dokumentation und die vollständige Umsetzung der IT- Sicherheitskonzeption vorliegen. Soweit möglich, sind weiterhin nach Common Criteria zertifizierte Produkte bevorzugt einzusetzen.
ISAV-17: Sicherstellung der Schadprogrammabwehr
Für alle IT-Verfahren sind die zentralen Virenschutz- und Schadprogrammabwehrleistungen des Bundes soweit wie möglich zu Beschreibung nutzen. Die Virenschutz- und Schadprogrammabwehrmaßnahmen sind auf dem aktuellen Stand der Technik (Patchlevel) zu halten.
118 Anhänge
Die Sicherstellung der Schadprogrammabwehr ist ein integraler Bestandteil Begründung der Sicherheitskonzeption im Sinne des ISM.
Zu berücksichtigen sind die Mindeststandards und Empfehlungen des BSI Abhängigkeiten sowie die entsprechenden Dienste von NdB.
Bundeslizenzen sind soweit wie möglich zu nutzen. Weiterführende Informationen hierzu werden vom BSI direkt an die in den Implikationen Nutzerbehörden zuständigen Stellen – in der Regel die IT- Sicherheitsbeauftragten – übermittelt.
ISAV-18: Bereitstellung von Schnittstellen- und Protokolldaten
Für alle IT-Verfahren ist sicherzustellen, dass die Schnittstellen- und Protokolldaten über vertrauenswürdige Schnittstellen (z. B. zertifizierte Beschreibung Sicherheitsgateways oder physische Test Access Points, TAP) an die Sensoren des BSI übergeben werden, wobei die Kommunikation mindestens einzelnen Behörden zugeordnet werden können muss.
Die Forderung ergibt sich aus § 5 BSIG. Die Zuordnung der Kommunikation Begründung zu den einzelnen Behörden ist eine notwendige Voraussetzung, um Angriffe auf die zentralen Infrastrukturen analysieren zu können.
Laut § 5 BSIG kann die Anforderung kann erfüllt sein, sofern für die Kommunikation mit dem Verfahren die zentralen Abhängigkeiten Sicherheitsmechanismen des Weitverkehrsnetzes (z.B. IVBB, IVBV, NdB) des Bundes durchlaufen werden.
Bei der Konzeption der Verfahrensarchitektur ist das BSI zu involvieren, um die Anbindung an die Analysesysteme des BSI sicherzustellen.
Implikationen Im Rahmen der Bereitstellung von Schnittstellen- und Protokolldaten muss sichergestellt werden, dass die entsprechenden Daten bei der Übermittlung an Dritte in geeigneter Form pseudonymisiert werden.
ISAV-19: Sicherer Remote-Zugriff (inkl. Fernwartung)
Beschreibung Der Remote-Zugriff (insbesondere im Rahmen eventuell vorgesehener
Anhänge 119
Fernwartung) ist so zu gestalten, dass der Zugriff nur auf die für den vorgesehenen Zweck erforderlichen Daten oder Systeme möglich ist.
Der Remote Zugriff, insbesondere Fernwartungsvorgänge, werden systematisch und umfassend geloggt und überwacht. Siehe auch ISAV-13 (Logging, Monitoring von IT-Umgebungen und Detektion von Anomalien).
Die besondere Betrachtung externen Zugriffs ist integraler Bestandteil jedes Begründung ISM.
Es sind insbesondere der Grundschutzbaustein B 4.4 (VPN), die Abhängigkeiten Grundschutz-Maßnahme M 5.33 (Absicherung von Fernwartung) und das Modul „ISi-Fern“ der ISi-Reihe des BSI zu beachten.
Implikationen Keine Implikationen vorhanden.
ISAV-20: Sichere Digitalisierung von analogen Daten
Bei der Digitalisierung von bisher analogen Verfahren in Geschäftsprozessen sind insbesondere die Bereiche (ersetzendes) Scannen und vertrauenswürdige Langzeitaufbewahrung wegen der besonderen Beschreibung Sicherheitsrelevanz nach dem Stand der Technik durchzuführen. Der Stand der Technik wird in den Technischen Richtlinien des BSI TR-03125 (Beweiswerterhaltung kryptographisch signierter Dokumente (TRESOR)) und TR-03138 (Ersetzendes Scannen (RESISCAN)) dargestellt.
Vorgaben des E-Government-Gesetzes müssen umgesetzt werden. Die Begründung verlässliche Vollständigkeit und der Beweiswert der E-Akte müssen auch bei Vernichtung des Papieroriginals gewährleistet sein.
Abhängigkeiten Diese Vorgabe wird weiter konkretisiert durch die Vorgabe DAAV-11.
Implikationen Keine Implikationen vorhanden.
120 Anhänge
7.6 Nutzungsrahmen von Diensten der GIB
Die Nutzungsverpflichtung auf Basis der Architekturvorgabe DAAV-01 legt den Funktionsumfang und den Anwendungsbereich als Kriterien fest.
Der Funktionsumfang bildet dabei eine logische Bündelung von Funktionalitäten im Sinne der Dienste-Definition. Der Anwendungsbereich legt den nutzerbezogenen prozessualen Kontext fest.
Der Detaillierungsgrad der Beschreibung wird im Zuge der Etablierung der Domänenarchitekturen in den nächsten Iterationen der Architekturrichtlinie weiter angepasst.
Zur Bewertung der zeitlichen Konsequenzen für die Restriktionen zu abweichenden Lösungen und insbesondere der Ablöse-/ Migrationsstrategie wird der Status des Dienstes zum Erstellungszeitpunkt der Architekturvorgabe angegeben.
7.6.1 Dienste der Domäne Elektronische Verwaltungsarbeit
7.6.1.1 Dienstkurzbeschreibung „E-Akte“
Der Funktionsumfang für den Dienst E-Akte beinhaltet • die Verwaltung von Dokumenten, • die elektronischen Aktenbearbeitung als dokumentenbasierte Vorgangsbearbeitung und • die Verwaltung der Instrumente und Regularien der Schriftgutverwaltung, wie Aktenpläne, Geschäftszeichenbildungsregeln und Aufbewahrungsfristen. Der Dienst E-Akte mit seinen verschiedenen Modulen wird vom Baustein E- Funktions- Akte des Organisationskonzepts sowie von Teilen des Bausteins-E- umfang Vorgangsbearbeitung (dokumentenbasierte Prozesse) und der Referenzarchitektur elektronische Verwaltungsarbeit fachlich sowie funktional umrissen. Wesentliche Module des Dienstes E-Akte sind der Dokumenten-Management-Kern und das Records Management. Weiterführende Informationen zu den Modulen sind in der „Referenzarchitektur elektronische Verwaltungsarbeit“ beschrieben.
Anwendungs- Der Anwendungsbereich des Dienstes E-Akte betrifft alle gemäß EGovG bereich betroffenen Behörden des Bundes.
Der Dienst E-Akte als Standardsoftware ist in Beschaffung. Die Pilotierung Status soll in 2018 beginnen. Eine weitere Detaillierung der Vorgaben folgt nach Beschaffung der Standardsoftware.
Anhänge 121
7.6.1.2 Dienstkurzbeschreibung „Social Intranet des Bundes“
Der Funktionsumfang für den Dienst Social Intranet des Bundes (SIB) beinhaltet für die behördenübergreifende Zusammenarbeit • den informellen Dokumentenaustausch für Fachnetzwerke und Funktions- Gremien, umfang • das Wissensmanagement durch Blogs, Wikis sowie Foren und • die informelle Kommunikation zur Durchführung von Telefon- konferenzen und Videoanrufen sowie Desktop-Sharing (Conferencing).
Der Anwendungsbereich des Dokumentenaustausches betrifft die gesamte Anwendungs- Bundesverwaltung. Die Nutzung des Dienstes Social Intranet ist auf bereich Teilnehmer/innen aus der Bundesverwaltung beschränkt.
Der Dienst Social Intranet des Bundes wird unter Nutzung der bestehenden Lösungen und der Dienste der Bundescloud weitergeführt und ausgebaut. Zur Status Abstimmung der Nutzung im Rahmen der Pilotierung ab 2017 steht den jeweiligen Behörden die Konzeptinstanz im BVA (Referat VM II 3) zur Verfügung.
7.6.1.3 Dienstkurzbeschreibung „eNorm“
Der Funktionsumfang des Dienstes eNorm umfasst die textuelle Erstellung und Überarbeitung von Gesetzen und Verordnungen im Kontext von Normsetzungsvorhaben. Sein Funktionsumfang beinhaltet: • Dokumentenvorlagen für die Normsetzung, • Strukturierungswerkzeuge,
Funktions- • Zugriff auf juristische Datenbanken, umfang • dynamische Binnenverweise, • Synopsen, • Prüf- und Korrekturfunktionen und • Export von XML-Daten.
Die Basisfunktionalitäten werden bezüglich Automatismen, Technologie und Nutzerführung weiterentwickelt.
122 Anhänge
Der Anwendungsbereich des Dienstes eNorm betrifft alle Mitarbeiter der Anwendungsb Bundesverwaltung mit Bezug zu Normsetzungsverfahren. eNorm kommt ereich ebenfalls im Deutschen Bundestag verbindlich zum Einsatz.
Der Dienst eNorm ist verfügbar und im Einsatz. Für die Nutzung müssen die jeweiligen Behörden sich mit dem Diensteanbieter abstimmen. Status Eine Maßnahme zur Weiterentwicklung ist Bestandteil des IT- Rahmenkonzeptes Bund.
7.6.1.4 Dienstkurzbeschreibung „eGesetzgebung“
Der Dienst eGesetzgebung repräsentiert eine modularisierte und interoperable Plattform, die einen durchgängigen medienbruchfreien Gesetzgebungsprozess von der Entwurfserstellung bis zur Verkündung einer Rechtsnorm ermöglicht.
Der Funktionsumfang des Dienstes eGesetzgebung ist nach aktuellem Stand gemäß der definierten Geschäftsanwendungsfälle: • Planung und Steuerung (u. a. Zeitplanung, Ablauf Rechtssetzung, Funktionsumf Dokumentation Beschluss, Sachstandsberichte, Veröffentlichung ang Regelungsvorhaben, Informationsbündelung, Freigaben) • Arbeit am Regelungsvorhaben (u. a. Erstellen, Verteilen, Kommentieren, Einarbeitung von Stellungnahmen, Anhörungen, Bürgerbeteiligungen, Berichtungsverfahren) • Wiederkehrende Basisfunktionalitäten (u.a. Text-/ Änderungsvergleich und -nachverfolgung, Prüfung Regelungsvorhaben, Ermittlung Folgeänderungen)
Anwendungs- Der Anwendungsbereich des Dienstes eGesetzgebung betrifft alle Mitarbeiter bereich der Bundesverwaltung mit Bezug zu Normsetzungsverfahren.
Der Dienst eGesetzgebung befindet sich in der Konzeptionsphase. Für 2018 ist Status die Bereitstellung von ersten Funktionen zu erwarten. Ab 2019 ist die Pilotierung und ab 2021 die Nutzung vorgesehen.
Anhänge 123
7.6.1.5 Dienstkurzbeschreibung „Digitales Zwischenarchiv des Bundes“
Der Funktionsumfang des Dienstes Digitales Zwischenarchiv des Bundes (DZAB) umfasst ein auf der Technischen Richtlinie TR 03-125 (Beweiswerterhaltung kryptographisch signierter Dokumente (TRESOR)) des BSI basierenden zentralen Langzeitspeicher für die rechtssichere Aufbewahrung elektronischer Unterlagen und Services. Die Langzeitspeicherung der Daten erfolgt ausschließlich auf dem Territorium der Bundesrepublik Deutschland.
Das DZAB setzt hinsichtlich der Speicherkomponente auf der Langzeitspeicherlösung des IT-Systemhauses der BA in Nürnberg, dem eArchiv- Service, auf und beinhaltet konkret folgende Standardfunktionen: • Lesen, Suchen, Schreiben, Versionieren, Ersetzen und Löschen von elektronischen Unterlagen (z. B. Akten, Vorgänge und Dokumente) auf der Basis von Zwischenarchivobjekten (XAIP-Container) • Verifikation der XAIP-Container gegen ein vorab definiertes XML-
Schema • Abruf des Beweiserhalts von Zwischenarchivobjekten in Form eines
Prüfprotokolls (Evidence Record) • Qualifizierte technische Antworten auf Anfragen an das DZAB Funktions- • Mandantenfähigkeit im Rahmen der datenschutzrechtlichen umfang Anforderungen (einschließlich Rechte- und Rollenkonzept und Zugriffsprotokollierung) • Eine optionale Signaturprüfung bei qualifiziert signierten Objekten vor Eingang in das DZAB • Anbietung und ggf. Übergabe archivreifer Unterlagen an das Bundesarchiv gemäß Bundesarchivgesetz (BArchG)
Der Zugriff auf die Funktionen erfolgt über das Dokumentenmanagement, die Vorgangsbearbeitung oder die webbasierte Zugriffs-, Steuerungs- und Bewertungskomponente (Access Service). Darüber hinaus wird der Access Service vom Bundesarchiv für die archivfachliche Bewertung aller elektronischen Unterlagen im DZAB auf ihre Archivwürdigkeit hin verwendet. Der Access Service soll u. a. folgenden Funktionsumfang bereitstellen: Erzeugung und Transfer von Zwischenarchivobjekten (XAIP), Navigation, Recherche, Anzeige, Ändern, Löschen und Bewertung von XAIP
124 Anhänge
auf Akten-/Aktenplan- und Vorgangsebene, Abruf von Prüfprotokollen sowie Reporting.
Ferner verfügt das DZAB über die Fähigkeit, SAP-Daten aufzunehmen. Die SAP-Daten sind über SAP-Systeme abzugeben und wieder anzuzeigen.
Das Bundesarchiv und die BA garantieren die Einhaltung von Datenschutz und Sicherheitsniveau der Schutzbedarfsklasse 3.
Der Anwendungsbereich des Dienstes Digitales Zwischenarchiv des Bundes Anwendungs- betrifft alle Systeme und Mitarbeiter der Bundesverwaltung mit Bezug zu bereich Klärung von Beweiswerterhaltung, Aufbewahrung und Archivierung.
Der Dienst Digitales Zwischenarchiv des Bundes ist verfügbar. Eine Status Weiterentwicklung ist im Rahmen der Gemeinsamen IT des Bundes gemäß IT Rahmenkonzept geplant.
7.6.2 Dienste der Domäne Infrastruktur
7.6.2.1 Dienstkurzbeschreibung „Bundesclient“
Der Bundesclient ist der zukünftige verbindliche Standard-Client für alle Arbeitsplätze und Mitarbeiter/innen der Bundesverwaltung. Sein Funktionsumfang beinhaltet bei den klassischen PC/Notebook-Plattformen • ein Betriebssystem, • ein festes Portfolio von Standardsoftware und Funktionsumf optional zubuchbare Software. ang • Er erlaubt die Verarbeitung von Daten auf dem Sicherheitsniveau VS-NfD. Die Bereitstellung und Nutzung erfolgt nur im Standard.
Als mögliche Clients sind FatClients, ThinClients, Notebooks, Tablets und Smartphones vorgesehen.
Der Anwendungsbereich des Bundesclients umfasst die gesamte Bundesverwaltung. Er wird für die folgenden Einsatzszenarien vorgehalten: Anwendungs- • IT-gestützte Verwaltungsarbeit im Büro bereich • IT-gestützte Verwaltungsarbeit im Home-Office • Mobiles Arbeiten (Notebook, Smartphone, Tablets) • Entwickler-/ Administratoren Arbeitsplatz
Anhänge 125
Der Dienst Bundesclient befindet sich in Entwicklung. Ein Pilotprojekt ist ab Status Ende 2017 und der Roll-out ab Anfang 2018 vorgesehen.
7.6.2.2 Dienstkurzbeschreibung „Bundescloud“
Der Dienst Bundescloud bietet den Funktionsumfang einer einheitlichen, skalierbaren Plattform für die Basis-, Querschnitts- und Fachverfahren der konsolidierten IT des Bundes. Sie ist eine Private Cloud und wird in den Rechenzentren des Bundes von Dienstleistern betrieben. Die Dienste der Funktionsumf Bundescloud werden in verschiedenen Kritikalitätsstufen angeboten. Diese ang erfüllen jeweils zusammengefasst bestimmte Anforderungen an Sicherheit, Verfügbarkeit und Datenschutz und Geheimschutz orientieren sich am Schutzbedarf der Fachverfahren der nutzenden Bundesbehörden. Die Abrechnung der Bundescloud-Dienste erfolgt nach dem tatsächlichen Nutzen (verbrauchsorientierte Abrechnung).
Anwendungs- Der Anwendungsbereich umfasst alle Basis-, Querschnitts- und Fachverfahren bereich der konsolidierten IT des Bundes.
Der Dienst Bundescloud befindet sich in Entwicklung. Pilot- und erste Status Betriebsphase sind ab Mitte 2017 vorgesehen.
7.6.2.3 Dienstkurzbeschreibung „Audiokonferenzanlage Pressesprecher und Ressortpressestellen“
Der Funktionsumfang des Dienstes Audiokonferenzanlage Pressesprecher und Ressortpressestellen umfasst die Bereitstellung von Audiokonferenzen. Funktions- Es setzt sich aus einer Konferenzzentrale, zwei Hauptstellen und 18 umfang Nebenstellen zusammen. Die zentrale Konferenzzentrale ist im Presse- und Informationsamt der Bundesregierung (BPA) untergebracht.
Der Anwendungsbereich umfasst die Pressesprecher/innen und Anwendungs- Ressortpressestellen, welche an den täglich stattfindenden Pressekonferenzen bereich mit dem BPA teilnehmen.
Dieser Dienst befindet sich im produktiven Einsatz. Eine Neuaufstellung auf Status Basis eines sicheren Verwaltungsnetzes mit Abschluss in 2019 ist vorgesehen.
126 Anhänge
7.6.2.4 Dienstkurzbeschreibung „Bund-TV“
Der Dienst Bund-TV überträgt Sitzungen des Bundestages, des Bundesrates, Funktions- Ausstrahlungen des Bundeskanzleramtes sowie alle Ausstrahlungen des umfang Bundespressekonferenz e.V.
Der Anwendungsbereich umfasst alle Mitarbeiter/innen der Anwendungs- Bundesverwaltung mit Bezug zur Übertragung und dem Empfang von bereich dienstbezogenen TV-Inhalten.
Dieser Dienst befindet sich im produktiven Einsatz. Eine Umstellung vom satellitengestützten Verfahren auf eine IP-basierte Streaming-Lösung unter Status Beachtung der Anforderungen des sicheren Verwaltungsnetzes ab 2017 ist in Entwicklung.
7.6.2.5 Dienstkurzbeschreibung „Dienst De-Mail-Gateway“ für die Bundesverwaltung
Der Dienst De-Mail-Gateway ermöglicht den De-Mail-Empfang und Versand über ein zentrales Gateway zum Transport aller De-Mails des Funktions- Diensteanbieters (DMDA) zu den einzelnen Bundesbehörden. Jede Behörde umfang verfügt mindestens über ein sogenanntes Catch-All-Postfach, das unter einer De-Mail Adresse auf dem Gateway erreichbar ist und in dem alle De-Mails der Behörde gesammelt werden.
Anwendungs- Der Anwendungsbereich umfasst alle Mitarbeiter/innen der bereich Bundesverwaltung mit Bezug zu De-Mail.
Status Dieser Dienst befindet sich im produktiven Einsatz.
7.6.2.6 Dienstkurzbeschreibung „Ressortübergreifendes Identitätsmanagement für die Bundesverwaltung“
Neu entwickelte ressortübergreifend genutzte Dienste der Bundesverwaltung müssen den bereitgestellten Funktionsumfang des ressortübergreifenden Funktions- Identitäts- und Berechtigungsmanagements (IAM) nutzen. umfang Bestehende ressortübergreifend genutzte Dienste der Bundesverwaltung sollen den bereitgestellten Funktionsumfang des IAM nutzen.
Anhänge 127
Die Komponenten und Konzepte des IAM müssen als Grundlage für neue IAM-Lösungen dienen, die auf Ebene einzelner Ressorts oder Behörden umgesetzt werden sollen.
Zudem müssen Authentisierung und Autorisierung durch separate Dienste/Funktionen realisiert werden.
Der Anwendungsbereich des Dienstes Ressortübergreifendes Identitäts- Anwendungs- management für die Bundesverwaltung betrifft alle Mitarbeiter/innen der bereich Bundesverwaltung.
Der Dienst Identitätsmanagement befindet sich derzeit in Entwicklung. Ein Status Pilotprojekt ist ab Ende 2017 geplant, der Roll-out ab Anfang 2019 vorgesehen.
7.6.3 Dienste der Domäne E-Government
7.6.3.1 Dienstkurzbeschreibung „Formular-Management-System“
Das Formular-Management-System (FMS) bietet den elektronischen Zugang zu Verwaltungsformularen. Es dient dem vollständigen und medienbruchfreien Datenaustausch von Bürgerinnen, Bürgern und Unternehmen mit der Verwaltung.
Der Funktionsumfang für den Dienst FMS beinhaltet • Erstellung von benutzerspezifischen Formularen und • Bereitstellung von webbasierten Formularen in Internet und Funktions- Intranet-Portalen. umfang Laufende Weiterentwicklungen von FMS sehen vor, das System dahingehend zu erweitern, dass die Formulare auch in Portalen und auf mobilen Endgeräten nutzbar sind.
Darüber hinaus enthält FMS heute auch eine Workflowkomponente, die für die weitere Bearbeitung der über Formulare eingehenden Anträge sorgt.
Diese Komponente ist nicht Gegenstand dieser Richtlinie.
Der Anwendungsbereich des Dienstes FMS betrifft alle mit der Erstellung und Anwendungs- Bereitstellung von Formularen für Bürger/innen und Unternehmen bereich betrauten Mitarbeitern/Mitarbeiterinnen der Bundesverwaltung.
128 Anhänge
Der Dienst FMS ist verfügbar und im Einsatz. Für die Nutzung müssen die jeweiligen Behörden sich mit dem Diensteanbieter abstimmen. Status Eine Maßnahme zur Weiterentwicklung ist Bestandteil des IT- Rahmenkonzeptes Bund.
7.6.3.2 Dienstkurzbeschreibung „Government Site Builder“
Der Funktionsumfang für den Dienst Government Site Builder (GSB) beinhaltet die Funktionen eines Content Management System (CMS) für die Internet-, Intranet- sowie Extranet-Aktivitäten der Bundesverwaltung. Funktions- Der GSB wurde im Rahmen von BundOnline als Basiskomponente umfang entwickelt. Der GSB ist mandantenfähig, entspricht den Anforderungen an die Barrierefreiheit, ist SAGA 5-konform und bietet ein konfigurierbares Layout, das sich am Internet-Styleguide der Bundesregierung orientiert.
Der Anwendungsbereich des Dienstes GSB betrifft alle mit der Erstellung und Anwendungs- Bereitstellung von Internet-, Intranet- sowie Extranet-Seiten betrauten bereich Mitarbeitern der Bundesverwaltung.
Der Dienst GSB ist verfügbar und im Einsatz. Für die Nutzung müssen die jeweiligen Behörden sich mit dem Diensteanbieter abstimmen. Status Eine Maßnahme zur Weiterentwicklung ist Bestandteil des IT- Rahmenkonzeptes Bund.
7.6.3.3 Dienstkurzbeschreibung „bund.de“
Bund.de wurde als Basiskomponente zur zentralen und einheitlichen Veröffentlichung übergeordneter Belange der Bundesbehörden entwickelt.
Der Funktionsumfang für den Dienst bund.de beinhaltet Funktions- • Zentrale Veröffentlichung der Behördendaten (Behördensteckbrief) umfang von Bundesbehörden • Zentrale Verlinkung zu E-Government-Dienstleistungen der Bundesbehörden • Zentrale Veröffentlichung von Stellenausschreibung
Anhänge 129
• Zentrale Veröffentlichung von Ausschreibungen • Zentrale Veröffentlichung von Veräußerungen (diese Funktion wurde 2013 ausgesetzt)
Das Portal wurde so konzipiert, dass auch darüber hinausgehende übergeordnete Publikationsanforderungen für die Zielgruppe Bürger/innen und Unternehmen in das Portal integriert werden können.
Der Aufbau eines abweichenden Portals für die beschriebenen Inhalte ist nicht zugelassen.
Der Dienst bund.de bietet wegen des hohen Änderungs- und Aktualisierungs- bedarfs an Inhalten für Ausschreibungen und Stellenangebote die zwei Schnittstellen
• Webeditor und • FTP-Upload
an. Über einen speziell entwickelten Webeditor kann die ausschreibende Stelle ihre Ausschreibungen beziehungsweise Stellenangebote auf bund.de einstellen und pflegen und behält so jederzeit die Kontrolle über die veröffentlichten Angebote. Wenn mehr als 250 Ausschreibungen oder Stellenangebote pro Jahr auf dem Portal eingestellt werden sollen, handelt es sich in der Regel um Inhalte eines (z. B. regionalen oder fachspezifischen) Portals. Diese Inhalte können automatisiert über die XML-Schnittstelle mit FTP-Upload in bund.de importiert werden.
Der Anwendungsbereich des Dienstes bund.de betrifft alle mit der übergeordneten zentralen Bereitstellung von Inhalten betrauten Mitarbeiter
Anwendungs- der Bundesverwaltung. bereich Der Anwendungsbereich der Schnittstelle betrifft alle mit der übergeordneten zentralen Bereitstellung von Inhalten betrauten Mitarbeiter der Bundesverwaltung.
Der Dienst bund.de ist verfügbar und im Einsatz. Für die Nutzung müssen die jeweiligen Behörden sich mit dem der Redaktion bund.de (BVA VMI6)
Status abstimmen.
Eine Maßnahme zur Weiterentwicklung ist Bestandteil des IT- Rahmenkonzeptes Bund.
130 Anhänge
7.6.3.4 Dienstkurzbeschreibung „E-Payment-Bund“
Über die Zahlungsverkehrsplattform ePayBL (E-Payment Bund/Länder) können Bundesbehörden, die Leistungen online verfügbar machen, ihren Kunden den Funktionsumfang zur Zahlungsabwicklung/ Inkasso anbieten. Damit wird der Einzug der Geldbeträge für kostenpflichtige Leistungen Funktions- (anfallenden Gebühren, Verpackungs- oder Versandkosten) sichergestellt und umfang über den Erfolg oder Misserfolg der jeweiligen Transaktion informiert.
ePayBL verfügt einerseits über eine direkte Anbindung an das Haushaltssystem des Bundes und andererseits an Zahlungsverkehrsprovider (z. B. Kreditkarteninstitute und Banken).
Anwendungs- Der Anwendungsbereich des Dienstes E-Payment-Bund betrifft alle mit der bereich Zahlungsabwicklung betrauten Mitarbeiter/innen der Bundesverwaltung.
Der Dienst E-Payment-Bund ist verfügbar und im Einsatz. Für die Nutzung müssen die jeweiligen Behörden sich mit dem Diensteanbieter abstimmen.
Status Eine Maßnahme zur Weiterentwicklung ist Bestandteil des IT- Rahmenkonzeptes Bund (z. B. Anbindung von paydirekt und die Integration von eRechnung).
7.6.3.5 Dienstkurzbeschreibung „Verwaltungsportal und Servicekonto Bund“
Das Verwaltungsportal des Bundes stellt einen zentralen Zugang zu den Verwaltungsdienstleistungen des Bundes dar und bietet folgenden Funktionsumfang: • Suche nach allen Verwaltungsdienstleistungen in Deutschland gemäß Leistungskatalog, • Stammtexte zu allen Verwaltungsdienstleistungen und Funktionsumf • Verlinkung zu allen Portalen des Portalverbundes. ang Der Aufbau eines abweichenden Portals für die beschriebenen Inhalte ist nicht zugelassen.
In das Verwaltungsportal des Bundes wird auch eine zentrale Identifizierungs-komponente, das Servicekonto des Bundes, integriert. Das Servicekonto ist ein zentraler Benutzer-Account, in dem Bürgerinnen, Bürger und Unternehmen ihre Daten permanent speichern und zur Identifizierung
Anhänge 131
gegenüber Verwaltungsleistungen nutzen können. In dem Servicekonto können Daten zu dem Benutzer sicher abgelegt und für behördliche Vorgänge genutzt werden (z. B. das automatische Befüllen von Online-Formularen).
Das Servicekonto wird auch eine Postfach-Funktionalität enthalten, über die Behörden Nachrichten an Bürgerinnen, Bürger und Unternehmen versenden können.
Der Anwendungsbereich des Dienstes Verwaltungsportal und Servicekonto Anwendungs- Bund betrifft alle mit Verwaltungsdienstleistungen betrauten bereich Mitarbeiter/innen der Bundesverwaltung.
Status Der Dienst ist in der Konzeptionsphase. Ein Zeitplan ist noch nicht bekannt.
7.6.4 Dienste der Domäne ERP
7.6.4.1 Dienstkurzbeschreibung „Personalverwaltungssystem“
Funktions- Der Funktionsumfang für den Dienst Personalverwaltungssystem beinhaltet umfang die IT-Unterstützung aller Kernprozesse der Personalverwaltung.
Der Anwendungsbereich des Dienstes Personalverwaltungssystem betrifft alle Anwendungs- mit der Verwaltung von Personal betrauten Mitarbeiter/innen der bereich Bundesverwaltung.
Im Projekt PVS Bund wurden Konsolidierungsmöglichkeiten der bestehenden Personalverwaltungssysteme, die derzeit im Einsatz sind, Status ermittelt und werden im Rahmen der Feinkonzeption (Start 2017) weiter verfolgt. Hierzu werden derzeit detaillierte Planungen vorbereitet, diese sind jedoch noch nicht abgestimmt.
132 Anhänge
7.7 Festlegungen zu standardisierten Produkten/Produktfamilien
7.7.1 Prozessorarchitekturen
Für Server im Backend-Bereich sind bevorzugt x86 Prozessoren vorzusehen. In begründeten Ausnahmefällen können daneben weitere Prozessorarchitekturen, insbesondere RISC-Systeme für ausgewählte Anwendungs- und Datenbankserver eingesetzt werden.
7.7.2 Programmiersprachen für serverseitige Anwendungsentwicklung
Als Programmiersprachen für Anwendungsentwicklung können Java, PHP, C++, C# und Python zur Anwendung kommen.
7.7.3 Entwicklungsumgebungen für serverseitige Anwendungsentwicklung
Als Entwicklungsumgebungen sind Visual Studio und Eclipse vorzusehen.
Anhänge 133
7.8 Referenzarchitekturen
Dieses Kapitel beinhaltet eine Übersicht von Referenzarchitekturen, die bei der Umsetzung von IT-Maßnahmen in den entsprechenden Bereichen zu berücksichtigen sind. Die folgende Auflistung wird im Zuge der regelmäßigen Fortschreibungen überprüft und erweitert.
7.8.1 Fachliche Referenzarchitekturen des Bundes
• „Referenzarchitektur elektronische Verwaltungsarbeit“ – Betrachtung von Dokumentenmanagement- und Vorgangsbearbeitungssystemen in der Bundesverwaltung • „Register Factory“ – Standard für den Bau und Betrieb von IT-Systemen zur Führung von elektronischen Registern.
134 Anhänge
7.9 Abbildungsverzeichnis
Abbildung 1: Aus dem Metamodell der Rahmenarchitektur IT-Steuerung Bund entwickeltes Modell zur Verdeutlichung der Architekturbereiche ...... 21
Abbildung 2: Zusammenhang zwischen Metamodell der Rahmenarchitektur IT-Steuerung Bund und den Architekturvorgaben ...... 22
Abbildung 3: Symbolik für Fachanwendungen ...... 24
Abbildung 4: Architekturrelevante strategische Ziele der IT des Bundes ...... 31
Abbildung 5: Richtlinien-Lebenszyklus COBIT 5 ...... 45
Abbildung 6: Darstellung der Zuständigkeiten für die Architekturrichtlinie auf Grundlage des Metamodells der Rahmenarchitektur IT-Steuerung Bund ...... 47
Anhänge 135
7.10 Abkürzungsverzeichnis
Abkürzung Bedeutung
AD Active Directory
API Application Programming Interface
AVVEnEff Allgemeine Verwaltungsvorschrift zur Beschaffung energieeffizienter Produkte und Dienstleistungen
BCM Business Continuity Management
BDSG Bundesdatenschutzgesetz
BfIT Beauftragter für Informationstechnik
BMI Bundesministerium des Innern
BPA Presse- und Informationsamt der Bundesregierung
BSI Bundesamt für Sicherheit in der Informationstechnik
BVA Bundesverwaltungsamt
CMIS Content Management Interoperability Services
CMS Content Management System
DZAB Digitales Zwischenarchiv des Bundes, Digitales Zwischenarchiv des Bundes
ECM Enterprise Content Management
EIF European Interoperability Framework
ERD Entity Relationship Diagram
ERP Enterprise Resource Planning
FMS Formular-Management-System
136 Anhänge
FTP File Transfer Protocol
GIB Gemeinsame IT des Bundes
GPL Gesamtprojektleitung
GSB Government Site Builder
IAM Identitäts- und Berechtigungsmanagement
IKT Informations- und Kommunikationstechnologie
ISM Informationssicherheitsmanagement
KM Krisenmanagement
MIME Multipurpose Internet Mail Extension
MPEG Moving Picture Experts Group
NdB Netze des Bundes
NMO Nachfragemanagementorganisation
ODF Open Document Format
OeV Organisationskonzept elektronische Verwaltungsarbeit
OSCI Online Service Computer Interface
PDF Portable Document Format
PG Projektgruppe
REST Representational State Transfer
RDF Resource Description Framework
SAGA Standards und Architekturen für E-Government-Anwendungen
SIB Social Intranet des Bundes
Anhänge 137
SINA Sichere Inter-Netzwerk Architektur
SOAP Simple Object Access Protocol
SW Software
TAP Test Access Points
UEIF Unified Extensible Firmware Interface
UML Unified Modeling Language
VITD Verbund der IT-Dienstleister
VS-NfD Verschlusssache - Nur für den Dienstgebrauch
WSDL Web Service Description Language
W3C World Wide Web Consortium
XML Extensible Markup Language
XÖV XML in der öffentlichen Verwaltung
138 Anhänge