IKT-Architektur für das Land Berlin · Version 1.4 Stand Januar 2019 Seite 6 von 67 Vorwort Das vorliegende Dokument beschreibt die anzustrebende Ziel-Architektur der IKT-Landschaft

IKT-Architektur

für das Land Berlin

Version: 1.4

Stand: Januar 2019

Version 1.4 Stand Januar 2019

Inhaltsverzeichnis

Vorwort .............................................................................................................................. 6

Einführung ............................................................................................................................. 7

1. Ziel-Architektur ...................................................................................................... 8

Grafische Darstellung ...................................................................................................... 8 1.1

Erläuterung des Gesamt-Zusammenhangs..................................................................... 8 1.2

Endgeräte der Verwaltungskunden ................................................................................ 9 1.3

Service.berlin.de ............................................................................................................. 9 1.4

E-Government-Middleware .......................................................................................... 10 1.5

1.5.1 Teilung in vier Schichten ............................................................................................... 11

Ergänzungskanäle ......................................................................................................... 12 1.6

1.6.1 Basisdienst Bürgerterminal ........................................................................................... 12

1.6.2 Basisdienst Dokumenten-Input-Management (DIM) ................................................... 12

1.6.3 Basisdienst Vermittlung und Auskunft (Bürgertelefon 115 u.a.) ................................. 13

1.6.4 Persönliche Vorsprache ................................................................................................ 13

2. IKT – Arbeitsplatz ................................................................................................. 14

BerlinPC ......................................................................................................................... 14 2.1

Telefon .......................................................................................................................... 17 2.2

LAN ................................................................................................................................ 17 2.3

2.3.1 Struktur des LAN ........................................................................................................... 19

Drucker.......................................................................................................................... 20 2.4

3. IKT-Basisdienste für E-Government ....................................................................... 21

Basisdienst Service-Portal ............................................................................................. 21 3.1

Basisdienst Dienstleistungsdatenbank (DLDB) ............................................................. 21 3.2

Basisdienst Service-App ................................................................................................ 22 3.3

Basisdienst Service-Konto ............................................................................................. 22 3.4

Basisdienst Postkorb ..................................................................................................... 22 3.5

Basisdienst eID .............................................................................................................. 22 3.6

Basisdienst PKI .............................................................................................................. 22 3.7

Basisdienst Virtuelle Poststelle ..................................................................................... 23 3.8

Basisdienst DE-Mail ...................................................................................................... 23 3.9

Basisdienst E-Payment .................................................................................................. 23 3.10

Basisdienst Zeit- und Terminmanagement (ZMS) ........................................................ 23 3.11

Basisdienst Digitaler Antrag .......................................................................................... 24 3.12

Basisdienst Digitale Akte ............................................................................................... 24 3.13

3.13.1 Dokumentenmanagement............................................................................................ 24

3.13.2 Langzeitspeicherung ..................................................................................................... 25


3.13.3 Vorgangsbearbeitung ................................................................................................... 25

Basisdienst Drucken ...................................................................................................... 25 3.14

Basisdienst Geodateninfrastruktur (GDI) ..................................................................... 25 3.15

Basisdienst Konvertierungsdienst ................................................................................ 25 3.16

4. IKT-Basisdienste für Infrastruktur ......................................................................... 26

Identity- und Accessmanagement ................................................................................ 26 4.1

Verzeichnisdienste ........................................................................................................ 26 4.2

Mail – Gateway ............................................................................................................. 26 4.3

Domain Name System (DNS) ........................................................................................ 27 4.4

Network Time Protocol (NTP) ....................................................................................... 27 4.5

5. IT-Fachverfahren .................................................................................................. 28

Angebotene Services für IT-Fachverfahren .................................................................. 29 5.1

Architektur- und Designprinzipien für IT-Fachverfahren ............................................. 30 5.2

5.2.1 Architekturprinzipien .................................................................................................... 30

5.2.2 Designprinzipien ........................................................................................................... 31

6. Schnittstellen ....................................................................................................... 32

Nutzung von Schnittstellen ........................................................................................... 32 6.1

Angebot von Schnittstellen ........................................................................................... 32 6.2

Formate und Protokolle von Schnittstellen .................................................................. 33 6.3

Open Data – Anforderungen an IT-Fachverfahren ....................................................... 33 6.4

6.4.1 Bedienung der Schnittstelle des Datenregisters .......................................................... 33

6.4.2 Schnittstelle zur Bereitstellung strukturierter Daten ................................................... 34

6.4.3 Infrastrukturen für dateibasierten Datenaustausch .................................................... 34

7. Infrastruktur ......................................................................................................... 35

Cloud Strategie ............................................................................................................. 35 7.1

7.1.1 Infrastructure as a Service (IaaS) .................................................................................. 35

7.1.2 Platform as a Service (PaaS) ......................................................................................... 35

7.1.3 Software as a Service (SaaS) ......................................................................................... 36

Private und Public Cloud ............................................................................................... 36 7.2

Server-Betriebssysteme ................................................................................................ 37 7.3

Datenbanken und Middleware ..................................................................................... 37 7.4

Netzwerke (LAN,MSN,WAN) ......................................................................................... 37 7.5

7.5.1 BeLa-MSN und Grenznetz ............................................................................................. 38

7.5.2 Rechenzentrum-LAN und Standort LAN ....................................................................... 40

7.5.3 IP-Adressverwaltung ..................................................................................................... 41

WLAN ............................................................................................................................ 41 7.6

Telekommunikation ...................................................................................................... 41 7.7

Lebenszyklen ................................................................................................................. 42 7.8


Betriebsumgebung........................................................................................................ 42 7.9

8. IKT-Sicherheit ....................................................................................................... 44

IKT-Sicherheitsarchitektur ............................................................................................ 44 8.1

Berlin-CERT ................................................................................................................... 45 8.2

Behördliches ISMS ........................................................................................................ 45 8.3

Verfahrensunabhängige (vu) IKT .................................................................................. 46 8.4

Zentrale IKT-Sicherheitskomponenten ......................................................................... 46 8.5

Nutzung Berliner Landesnetz ........................................................................................ 46 8.6

Verfahrensabhängige (va) IKT ....................................................................................... 47 8.7

9. Digitale Barrierefreiheit ........................................................................................ 48

Standards für web- und clientbasierte Software.......................................................... 48 9.1

9.1.1 Anforderungen an den Prüfbericht des externen Gutachtens ..................................... 49

9.1.2 Anforderungen an den Nachbesserungsplan ............................................................... 49

Standards für Sprache................................................................................................... 49 9.2

9.2.1 Leichte Sprache ............................................................................................................. 49

9.2.2 Verständliche Sprache .................................................................................................. 50

Assisitive Technologien ................................................................................................. 50 9.3

10. Anhänge ............................................................................................................... 51

Standardisierungskatalog ............................................................................................. 51 10.1

Netzwerke ..................................................................................................................... 52 10.2

10.2.1 Ergänzungen BeLa-MSN und Grenznetz ....................................................................... 52

10.2.2 Ergänzungen Rechenzentrum-LAN und Standort LAN ................................................. 54

10.2.3 Ergänzungen IP-Adressverwaltung ............................................................................... 57

Begriffsklärung IT – Fachverfahren ............................................................................... 59 10.3

10.3.1 Konkretisierung des Begriffs IT – Fachverfahren .......................................................... 59

10.3.2 Konsequenzen für IT – Fachverfahren .......................................................................... 59

10.3.3 IKT-Architektur und IT-Fachverfahren .......................................................................... 59

10.3.4 Abgrenzung zu IKT–Basisdiensten ................................................................................ 60

10.3.5 Keine IT-Fachverfahren ................................................................................................. 61

Anhänge zu Standards der digitalen Barrierefreiheit ................................................... 62 10.4

10.4.1 Leitfaden für Verständliche Sprache ............................................................................ 62

10.4.2 Ausschlusskriterien für Webseiten / Software ............................................................. 63

10.4.3 Ergänzende Kriterien für clientbasierte Software ........................................................ 64

Verfügbarkeit der Architekturbestandteile .................................................................. 65 10.5


Abbildungsverzeichnis

Abbildung 1: Ziel - Architektur Land Berlin ............................................................................................ 8

Abbildung 2: Strukturbeschreibung E-Government............................................................................. 11

Abbildung 3: IKT-Arbeitsplatz ............................................................................................................... 14

Abbildung 4: standardisierte Schnittstellen für funktionsbezogene Standardsoftware ..................... 15

Abbildung 5: zentrale und dezentrale Bereitstellung des BerlinPC ..................................................... 16

Abbildung 6: Architekturübersicht IKT-Arbeitsplatz ............................................................................ 18

Abbildung 7: Auszug IKT-Basisdienste für E-Government Stand Dez. 2018 ........................................ 21

Abbildung 8: Berliner Landesnetz-Architektur ..................................................................................... 38

Abbildung 10: Architektur des BeLa MSN ............................................................................................ 39

Abbildung 11: Netzstruktur nach DIN EN 50173 .................................................................................. 40

Abbildung 12: Technologie-Übersicht (Auswahl) ................................................................................. 51

Tabellenverzeichnis

Tabelle 1: Politische Ziele und der Lösungsbeitrag durch die IKT - Architektur .................................... 7

Tabelle 2: IP - Adressbereiche des Landes Berlin ................................................................................. 58

Tabelle 3: Wesentliche Änderungen bei IT-Fachverfahren .................................................................. 60

Tabelle 4: Verfügbarkeit der Architekturbestandteile (Auswahl) ........................................................ 65

Tabelle 5: Abkürzungen ........................................................................................................................ 67

Version 1.4 Stand Januar 2019 Seite 6 von 67

Vorwort

Das vorliegende Dokument beschreibt die anzustrebende Ziel-Architektur der IKT-Landschaft

im Land Berlin. Sie hat nicht den Anspruch einer feingranularen Technologie-Planung,

sondern stellt im Sinne eines Übersichtsbildes die wesentlichen Bausteine der Architektur

sowie ihre arbeitsteiligen Zusammenhänge mit Fokus auf den angestrebten strategischen

Nutzen der IKT (Bereitstellung von Online-Diensten, Digitalisierung der internen

Verwaltungsarbeit) dar. Ziel ist die Beantwortung grundlegender Fragen, wie etwa

Wie verhalten sich Endgeräte und IT-Fachverfahren zueinander?

Wie wird die benötigte Infrastruktur von IT-Fachverfahren bereitgestellt?

Wo findet Datenverarbeitung und Datenhaltung von IT-Fachverfahren statt?

Wie präsentieren sich IT-Fachverfahren gegenüber dem Bürger?

Welche Basisdienste sind verpflichtend einzusetzen?

Gemäß § 21 Abs.2 Satz 2 Ziff. 3 EGovG Berlin wird die IKT-Architektur des Landes Berlin von

der IKT-Staatssekretärin bzw. von dem IKT-Staatssekretär festgesetzt und weiterentwickelt,

gleichzeitig ist sie bzw. er für die Einführung und die Überwachung von IKT-Standards

zuständig.

Die Erarbeitung, Festsetzung und Durchsetzung der Architektur regelt der Prozess zum IKT-

Architekturmanagement. Die vorliegende Ziel-Architektur ist ein Ergebnistyp dieses

Prozesses.

Die nachfolgend beschriebene IKT-Architektur gilt in erster Linie für Neu- oder

Ersatzbeschaffungen und größere Weiterentwicklungsprojekte. Altsysteme werden im

Einzelfall auf ihre Migrierbarkeit geprüft.


Einführung

Mit dem E-Government-Gesetz verfolgt der Gesetzgeber im Wesentlichen zwei

Zielrichtungen: Nach außen mehr nutzerfreundliches und sicheres E-Government für

Bürgerinnen, Bürger und Wirtschaft und nach innen mehr gesamtstädtische, einheitliche IKT-

Steuerung für mehr Leistungsfähigkeit, Wirtschaftlichkeit, Sicherheit und eine moderne IKT-

Ausstattung.

Das Gesetz spricht überwiegend von „IKT“, also Informations- und Kommunikationstechnik.

Der Gesetzgeber wollte damit - dies zeigen auch die Wortbeiträge in den parlamentarischen

Beratungen - die integrative Bedeutung der Kommunikationstechnik hervorheben.

Die IKT-Architektur des Landes Berlin ist wesentlich durch Lösungsmuster bestimmt, die als

Antwort auf angestrebte Ziele des eGovG Berlin zurückzuführen sind, die es umzusetzen gilt.

Politisch-strategische Ziele Lösungsbeitrag der IKT-Architektur

One-Stop-Government (einheitlicher

Zugang aus Sicht des Bürgers)

Anbindung von IT-Fachverfahren über das Internet

erfolgt ausschließlich über E-Government-

Middleware; einheitliches Front-End

Zeitnahe Einführung neuer IT-

Fachverfahren

Automatisierte und standardisierte Bereitstellung

von Servern und Laufzeitumgebungen;

vollumfängliche Unterstützung des Application

Lifecycle von der Anforderungsaufnahme über

Softwarearchitektur, Softwareentwicklung und

Inbetriebnahme

IKT-Sicherheit (§23 EGovG Bln) Standardisierte Sicherheitsbausteine für

Infrastrukturen und Plattformen

Stabiler Betrieb (§20 II EGovG Bln) Strikte Standardisierung der

verfahrensunabhängigen (vu) Infrastruktur;

Reduktion von Technologie-Heterogenität

Ausbau Online-Transaktionen Zentrale Bereitstellung und zentraler Betrieb der

E-Government-Middleware

Digitalisierung der internen

Verwaltungsarbeit

Verortung der Digitalen Akte und der digitalen

Antragserfassung in der Gesamtarchitektur

Wirtschaftlicher IKT-Betrieb (§2 Abs. II

EGovG Bln)

Standardisierung, Wiederverwendung von

Diensten, Automatisierung

Mehrkanalzugang (§4 EGovG Bln) Mitplanung von Ergänzungskanälen

Tabelle 1: Politische Ziele und der Lösungsbeitrag durch die IKT-Architektur


1. Ziel-Architektur

Grafische Darstellung 1.1

Abbildung 1: Ziel-Architektur Land Berlin

Erläuterung des Gesamt-Zusammenhangs 1.2

Die Ziel-Architektur geht von der grundlegenden Einsicht aus, dass alle wesentlichen

Technologie-Ebenen der Berliner IKT-Landschaft aufeinander abgestimmt werden müssen

und nur in diesem Gesamtzusammenhang auch weiterentwickelt werden dürfen.

Beispielsweise müssen IT-Fachverfahren kompatibel zu den Mitarbeiter-Endgeräten

gestaltet werden und kompatibel zu einer standardisierten Infrastruktur-Landschaft sein, für


welche etwa bestimmte IKT-Sicherheits-Richtlinien gelten. Zugleich sollen sich IT-

Fachverfahren einheitlich auf dem Stadtportal service.berlin.de präsentieren und mit

anderen E-Government-Diensten (wie etwa dem Service-Konto, E-Payment oder der

Digitalen Akte) interagieren.

Um diese vielfältigen technologischen und logischen Abhängigkeiten in ihrer Komplexität

kontrollieren zu können und in großem Umfang Synergieeffekte zu heben, muss die

Gesamtarchitektur in ihren wesentlichen Teilen so weit wie möglich standardisiert und

Freiheitsgrade in der Architektur-Gestaltung reduziert werden. Nur so kann die Architektur

in ihrer Gesamtheit den eigentlichen Zweck der IKT (digitale Abwicklung von

Geschäftsprozessen in den Verwaltungen durch den Einsatz von IT-Fachverfahren sowie die

Bereitstellung von Online-Diensten für Bürger und Unternehmen) optimal unterstützen. Ziel

ist es also, die gesamte Rahmen-IKT um ein IT-Fachverfahren herum als „Block“

standardisiert und damit zueinander kompatibel bereitzustellen. Freiheitsgrade bestehen im

Wesentlichen nur noch in der Fachlichkeit eines IT-Fachverfahrens.

Das ITDZ Berlin stellt der Berliner Verwaltung diesen hochgradig standardisierten

Technologie-Stack (Netze, Server, Betriebssysteme, Datenbanken, Endgeräte, E-

Government-Middleware, Digitale Akte) für den Betrieb von IT-Fachverfahren und

Anwendungen mit Endnutzer-Bezug (Verwaltungs-Mitarbeiter, Bürger, Unternehmen) zur

Verfügung. Über die Art der Bereitstellung der verfahrensunabhängigen (vu) IKT für die IT-

Fachverfahren entscheidet das ITDZ im Rahmen der IKT-Architekturvorgaben auf der Basis

der Anforderungen des jeweiligen IT-Fachverfahrens unter Berücksichtigung der in

Einführung genannten Ziele. Der Betrieb erfolgt zentral im ITDZ Berlin.

Endgeräte der Verwaltungskunden 1.3

Endgeräte der Verwaltungskunden werden nur insofern in der IKT-Architektur beplant, als

dass als Systemvoraussetzung der browserbasierte Zugang auf das einheitliche

Stadtinformationssystem vorausgesetzt wird.

Service.berlin.de 1.4

Als verbindlich vorgegebener „Kundenzugang“ dient service.berlin.de der Information über

Verwaltungsdienstleistungen, der Beratung, der Antragsstellung sowie der Entgegennahme

von Bescheiden. Als einheitliche Schnittstelle organisiert service.berlin.de den

elektronischen Austausch zwischen der Verwaltung einerseits und Bürgern, Unternehmen,

Organisationen und anderen Verwaltungen andererseits.


Dieser Basisdienst organisiert die mobilfähige Darstellung von Präsentationsinhalten über

das einheitliche Stadtportal service.berlin.de.

E-Government-Middleware 1.5

Die Schnittstelle der Verwaltung gegenüber Bürgern, Unternehmen und Organisationen zur

Abwicklung von Online-Transaktionen wird technisch und organisatorisch einheitlich und für

alle Einrichtungen des Landes Berlin verbindlich nutzbar gestaltet. Alle IT-Fachverfahren

werden, soweit sie einen Online-Zugang vorsehen, über die zentrale E-Government-

Middleware des Landes Berlin an das Internet angeschlossen. Sie müssen sich, sofern sie

eine Schnittstelle zum Internet benötigen, über ein standardisiertes Oberflächen-Design

sowie einen einheitlichen Zugangskanal (service.berlin.de) auf Grundlage einer einzigen

technischen Publikations-Plattform dem Bürger gegenüber präsentieren. Dies bedeutet, dass

IT-Fachverfahren nicht mehr über eigene webbasierte Oberflächen im Internet sichtbar sind.

Hierdurch wird die One-Stop-Strategie des Landes Berlin umgesetzt, Mehrfachinvestitionen

in Basisfunktionalitäten vermieden und die technische Komplexität der Bürgerschnittstelle

kontrollierbar gehalten.

Die E-Government-Middleware wird abnahmepflichtig vom ITDZ Berlin bereitgestellt. Das

ITDZ Berlin betreibt alle E-Government-Komponenten, entwickelt sie in ihrem

Zusammenspiel in enger Abstimmung mit SenInnDS weiter.

Der Telefonkanal und das Druck-Angebot des ITDZ Berlin werden als Ergänzungskanäle des

Online-Kanals betrachtet; diese werden auf die Online-Strategie hin ausgerichtet, die den

logischen Vorrang hat.


Abbildung 2: Strukturbeschreibung E-Government

1.5.1 Teilung in vier Schichten

Die Schicht „Kundenzugang“1 dient der Information über Verwaltungsdienstleistungen, der

Beratung, der Antragsstellung sowie der Entgegennahme von Bescheiden. Als einheitliche

Schnittstelle organisiert sie den elektronischen Austausch zwischen der Verwaltung

einerseits und Bürgern, Unternehmen, Organisationen und anderen Verwaltungen

andererseits.

Die Ergänzungskanäle Telefon, Print und persönliche Vorsprache zählen ebenfalls zur Schicht

„Kundenzugang“.

Die Schicht „E-Government-Middleware“ organisiert das Zusammenspiel zwischen den

Schichten „Kundenzugang“ und „Fachverfahren“. IT-Fachverfahren werden einerseits an das

Service-Konto angebunden. Andererseits werden Antragsstrecken und Rückmeldungswege

über den Dienst „Digitaler Antrag“ definiert, verwaltet und zurückgemeldet. Anträge aus der

1 Für die Gestaltung browserbasierter Benutzerschnittstellen gelten die Vorgaben der Landesredaktion

(siehe: http://support.berlin.de/wiki/images/0/0f/Hinweise_fuer_Onlineanwendungen-

verfahren_Technischer_Styleguide.pdf)

http://support.berlin.de/wiki/images/0/0f/Hinweise_fuer_Onlineanwendungen-verfahren_Technischer_Styleguide.pdf

http://support.berlin.de/wiki/images/0/0f/Hinweise_fuer_Onlineanwendungen-verfahren_Technischer_Styleguide.pdf


Schicht „Kundenzugang“ werden entgegen genommen und an die Schicht „Fachverfahren“

weitergereicht. Zwischenstände zur Bearbeitung, Nachfragen und Outputs in Form von

Bescheiden werden wiederum über die Middleware-Schicht an die Schicht „Kundenzugang“

weitergereicht.

Die Schicht „IT-Fachverfahren“ enthält die fachliche Logik der Datenverarbeitung. Sie nimmt

Anträge aus der Schicht „Middleware“ entgegen und meldet Bearbeitungsstände und

Ausgänge in Form von Bescheiden an diese zurück.

In der Schicht „Digitale Akte“ werden Eingänge (Post, Dokumente) und Ausgänge

(Bescheide) aus der Schicht „IT-Fachverfahren“ verpflichtend abgelegt. Eine Integration in IT-

Fachverfahren kann zur Dokument- und Bescheid-Erstellung sinnvoll sein. Für einfache

Prozesse kann die Digitale Akte auch als Vorgangsbearbeitungssystem (VBS) eingesetzt

werden und somit eigenständige IT gestützte Abläufe ersetzen. Sie wird dann direkt an die

Schicht „E-Government-Middleware“ angeschlossen. Darüber hinaus stellt die Digitale Akte

eine Langzeitspeicherung zur Verfügung.

Ergänzungskanäle 1.6

Ergänzungskanäle dienen der Einspeisung von Anträgen in die E-Government-Infrastruktur

sowie der Rückmeldung an den Antragssteller über nicht-digitale Kanäle. Strategisch werden

sie auf den elektronischen Kanal hin ausgerichtet (Ein- und Ausgänge der anderen Kanäle

sind von Software abhängig; Effizienzvorteile durch Selbstbedienung und geringe

Grenzkosten für Leistungserbringung).

1.6.1 Basisdienst Bürgerterminal

Anträge können an fest installierten PC in öffentlichen Einrichtungen gestellt werden. Dort

wird die Seite service.berlin.de angezeigt.

1.6.2 Basisdienst Dokumenten-Input-Management (DIM)

Der Basisdienst Dokumenten-Input-Management übernimmt digitalisierte Dokumente (z.B.

aus dem Posteingang), wandelt sie in ein lesbares PDF/A-Format, klassifiziert

Dokumententypen bzw. -klassen und erkennt automatisch Metadaten. Diese Daten werden

nach einer Qualitätskontrolle an verschiedene Zielsysteme wie z.B. die Digitale Akte

übergeben bzw. für diese bereitgestellt. Der Vorgang zur Digitalisierung der Dokumente wird

noch geklärt.

Der IKT-Basisdienst für eGovernment – Dokumenten-Input-Management (DIM) soll die

nachfolgenden technischen Funktionalitäten beinhalten:


Daten/Bild empfangen [Eingangskanal]

Texterkennung (OCR)

Dokumente klassifizieren

Metadaten erkennen

Datenübermittlung an ein Zielsystem (z. B. Digitale Akte, IT-Fachverfahren)

Die vorgelagerten (z. B. öffnen, Heftklammern entfernen, entfalten, glätten, Bild scannen)

und die nachgelagerten Aufgaben/Prozesse (Aufbewahrung, Vernichtung) werden

betrachtet und im Portfolio des IKT-Basisdienstes Dokumenten-Input-Management

berücksichtigt.

Weitere Informationen zum Projekt: http://b-

intern.de/themen/digitalisierung/informations-und-

kommunikationstechnik/architektur/basisdienste/artikel.727603.php

1.6.3 Basisdienst Vermittlung und Auskunft (Bürgertelefon 115 u.a.)

Ein funktionierendes digitales Angebot benötigt in einer Gesamtstrategie flankierend auch

gebündelte Kommunikationskanäle. Der Basisdienst Vermittlung und Auskunft

(Bürgertelefon 115 u.a.) dient derzeit primär der telefonischen Information über (Online-)

Verwaltungsleistungen und wurde im Rahmen einer Mehrkanalstrategie durch den Kanal

eMail ergänzt.

Mitgeltende Konzepte: Rahmenfachkonzept für IKT-Basisdienste für Telekommunikation

unter: http://b-intern.de/themen/digitalisierung/informations-und-

kommunikationstechnik/architektur/basisdienste/artikel.621816.php

1.6.4 Persönliche Vorsprache

Bei der Antragsstellung durch persönliche Vorsprache wird der Antrag von der

Sachbearbeitung direkt im IT-Fachverfahren bearbeitet. Zu einem späteren Zeitpunkt könnte

erwogen werden, die Eingabe auch durch den Sachbearbeiter im Bürger-Front-End

vornehmen zu lassen.

http://b-intern.de/themen/digitalisierung/informations-und-kommunikationstechnik/architektur/basisdienste/artikel.727603.php






2. IKT – Arbeitsplatz

Der standardisierte IKT – Arbeitsplatz ist ein wesentlicher Teil der vu IKT.

Abbildung 3: IKT-Arbeitsplatz

Der IKT-Arbeitsplatz besteht aus dem standardisierten BerlinPC inklusive Standardsoftware,

Druckservice, einem adäquaten, standardisierten IP-Telefon einem LAN-Anschluss sowie den

zugehörigen Infrastruktur- und Netzservices und –diensten des ITDZ Berlin.

BerlinPC 2.1

Der BerlinPC ist ein standardisierter IT – Arbeitsplatz-Service für die Berliner Verwaltung.

Grundsätzlich wird hierbei eine zentrale Lösung zur Bereitstellung von virtuellen

Desktopumgebungen eingesetzt. Dieser zentralisierte Lösungsansatz ermöglicht nicht nur

die zentrale Speicherung und Sicherung, sondern auch die Bearbeitung der Daten.

Die Komponenten dieses stark standardisierten Services werden automatisiert aufgesetzt

und betrieben. In der Regel wird dezentral nur die Hardware und Software für die Eingabe

(Tastatur, Maus, …) und Ausgabe (TFT, Drucker, …) zur Verfügung gestellt. Die gesamte

Datenbearbeitung läuft im zentralen Rechenzentrum.


BerlinPC

Citrix Terminalserverüber Citrix Provisioning Service

BerlinPC ClientStandard, Standard Plus, Mobil, Mobil Plus

zentraler BerlinPC Desktop

Software Basis Paket

Darstellung des Fachanwendungsclientdezentral bereitgestellten

Fachanwendungsclient

BerlinPC Software Optionen

Betriebssystem Windows 2016 Server

Software Basis Paket

Betriebssystem Windows 10

Citrix

local ap

paccess

dezentrale Anwendungsvirtualisierung App-V

mit Citrix local app access

zentrale Anwendungs-virtualisierung App-V Citrix Published App

Abbildung 4: standardisierte Schnittstellen für funktionsbezogene Standardsoftware

Der BerlinPC stellt die funktionsübergreifende Standard-Software für alle Nutzenden bereit.

Funktionsbezogene Standard-Software, zu der auch die IT-Fachanwendungen gehören,

werden über standardisierte Schnittstellen zur Verfügung gestellt, wenn diese nicht über ein

Web-Frontend verfügen:

1. Bereitstellung über die Anwendungs-Virtualisierung App-V auf dem zentralen

Desktop-Terminalserver (im App-V Container auch mit anderen Komponenten

kombinierbar, z. B. bestimmte Java Runtime Versionen)

2. Wenn der IT-Fachanwendungs-Client nicht unter App-V lauffähig ist, ist eine

Installation auf für die Anwendung dedizierten Terminalservern möglich

(Virtualisierung unter Citrix, Darstellung über published application)

3. Wenn der IT-Fachanwendungs-Client nicht auf einem Terminalserver betrieben

werden kann oder der lokale Betrieb z. B. durch die Nutzung lokaler Peripherie

notwendig ist, ist die Bereitstellung eines App-V Pakets auf dem dezentralen, lokalen

Client möglich. Die Darstellung erfolgt im zentralen BerlinPC Desktop des jeweiligen

Benutzers.

Die aktuell zur Verfügung stehende funktionsübergreifende Standard-Software (Software

Basis-Paket) und funktionsbezogene Standard Software (BerlinPC Software-Optionen und IT-

Fachanwendungen) wird zukünftig in Katalogen im Anhang zur Architekturliste gepflegt.


Kann eine Software nachweislich nicht über die zuvor genannten drei Standard–

Schnittstellen bereitgestellt werden, muss im Einzelfall eine Option zur gesonderten

Leistungserbringung auf Basis des BerlinPC beantragt werden.

Datacenter des ITDZ

Standardisierte Automatisierungsumgebung

Windows Terminal Server 2016

zentralerBerlinPC Desktop

zentraleServerdienste Dezentraler Standort

BerlinPCClient

(Standard, Standard Plus, Mobil, Mobil Plus)

dezentrale

Serverdienste

Aus dem Internet

BerlinPC Client

(Mobil, Mobil Plus)

AdministrationAus dem Internet

fremde Clients

(Boot Stick,Tablets,

Smartphone)

Abbildung 5: zentrale und dezentrale Bereitstellung des BerlinPC

Die BerlinPC Client–Hardware wird in vier standardisierten Varianten jeweils mit Maus,

Tastatur und Monitor zur Verfügung gestellt:

1. BerlinPC-Client Standard

basiert auf einem PC aus dem APC Rahmenvertrag ohne Anpassungsmöglichkeiten

2. BerlinPC-Client Standard Plus

basiert auf dem BerlinPC-Client Standard mit Anpassungsmöglichkeiten in CPU,

Speicher, Festplatte, DVD sowie anderen möglichen Funktionen

3. BerlinPC-Client Mobil

basiert auf einem Notebook mit Dockingstation ohne weiter Anpassungsmöglichkeit

4. BerlinPC-Client Mobil Plus

basiert auf dem BerlinPC-Client Mobil mit Anpassungsmöglichkeiten in Hardware und

Funktion

Ein Arbeiten mit dem BerlinPC-Client Mobil (Plus) ohne Verbindung zum Berliner Landesnetz

ist mit den lokal installierten Anwendungen des Software–Basispaketes und mit zuvor über

den zentralen BerlinPC–Desktop manuell kopierten Daten möglich. Für den Zugriff auf den

zentralen BerlinPC Desktop ist dann zusätzlich eine Verbindung zum Internet erforderlich.

In allen Client–Varianten werden die Daten auf der Festplatte vor Fremdzugriff durch eine

Verschlüsselung geschützt. Die eigenverantwortliche Installation von Programmen ist

technisch ausgeschlossen.


Die über den vom ITDZ betriebenen Webshop abrufbare Client–Hardware ist für den Einsatz

des BerlinPC vorbereitet.

Das Browsen im Intranet und im Internet erfolgt über zwei verschiedene Browser. Das

Intranet wird mit dem Internet Explorer (oder einem Nachfolger) aufgerufen, das Internet

wird mit dem Browser Mozilla Firefox (in einer abgeschirmten Umgebung) aufgerufen. Beide

Browser können nicht das jeweilige andere Webangebot aufrufen. Intranet und Internet sind

getrennt.

Die mit dem BerlinPC bereitgestellte funktionsübergreifende Standard–Software (ohne

Softwareoptionen und IT-Fachanwendungen) unterliegt einer Lizenzverwaltung, welche den

sachgerechten und effizienten Umgang mit lizenzpflichtiger Software sichert. Alle

Anwendungen und Anwendungsversionen durchlaufen den Integrationsprozess zur

Erstellung von neuen Softwarepaketen. Dieser beinhaltet die technische Bereitstellung für

den Anwendertest in einer definierten Umgebung und eine verbindliche Freigabe.

Die Bereitstellung der Software erfolgt über eine zentrale Softwareverteilung. In Verbindung

mit dem Berechtigungsmanagement wird eine auf den Nutzer bezogene Bereitstellung der

Software sichergestellt.

Für den vom ITDZ Berlin bereitgestellten BerlinPC gibt es Konzepte für die Infrastruktur,

Informationssicherheit und Betriebsführung. Diese basieren auf den Standards des BSI und

den für das Land Berlin gültigen Richtlinien zur IKT-Sicherheit.

Telefon 2.2

Die Telefonie wird über Voice over IP (VoIP) realisiert und ist im Kapitel 7.7

Telekommunikation beschrieben.

LAN 2.3

Im Rahmen des IKT Arbeitsplatz wird am jeweiligen Standort ein lokales Netzwerk betrieben

und LAN Ports für den BerlinPC Client, Telefonie Endgeräte und Netzwerk Drucker

bereitgestellt.

Diese Netzwerk Infrastruktur wird unter Kapitel 7.5 Netzwerke (LAN, MSN, WAN)

beschrieben.


Die folgende Architekturübersicht stellt die grundsätzlichen Zusammenhänge des IKT-

Arbeitsplatzes dar. Dabei werden die physikalische Infrastruktur, vom Arbeitsplatz mit

seinem örtlichen Gebäude-LAN, über den Standardnetzzugang (SNZ) in das Berliner

Landesnetz (BeLa) bis in das Data-Center des ITDZ Berlin betrachtet.

Abbildung 6: Architekturübersicht IKT-Arbeitsplatz


Zur Standardisierung werden die Verwaltungsstandorte in verschiedene Größenklassen

unterteilt, da je nach Größenklasse (in Abhängigkeit von der Anzahl der IKT-Arbeitsplätze)

ein unterschiedlicher Infrastrukturaufwand und unterschiedliche Bandbreitenanforderungen

zum BeLa-MSN zu berücksichtigen sind.

a) Standorte mit mehr als 250 IKT-Arbeitsplätzen werden als Groß- oder auch Core-

Standorte bezeichnet. Im Fall der Bezirksämter trifft dies zumeist auf Rathäuser der

Bezirke zu.

b) Standorte mit IKT-Arbeitsplätzen zwischen 81 und unter 250 werden als mittelgroß

bezeichnet.

c) Standorte mit ca. 25 – 80 IKT-Arbeitsplätzen werden als mittel bezeichnet.

d) Standorte von 3 bis 24 IKT-Arbeitsplätze werden als klein bezeichnet.

e) Für den Fall, dass 1 bis 3 Arbeitsplätze unterstützt werden sollen, gelten diese als

Kleinststandort und werden anlog zu einem Work@Home Arbeitsplatz vernetzt/-

angebunden.

Zusätzlich müssen Standorte mit besonders hohen Bandbreiten- bzw. besonderen Betriebs-

anforderungen (z.B. zum Schutzbedarf) identifiziert und benannt werden

Höhere Bandbreiten- oder Sicherheitsanforderungen können zu einer höheren Bewertung

der Standortklasse bzw. weiteren Infrastrukturmaßnahmen führen.

2.3.1 Struktur des LAN

Die großen Verwaltungsstandorte bilden jeweils den Kern des LAN (LAN Core). Sie sind an

das BeLa-MSN redundant (d.h. mit zwei Leitungen auf unterschiedlichen Leitungswegen)

angebunden. Die Verwaltungs-Core-Standorte bilden die zentrale Instanz für das LAN und

sind untereinander zusätzlich redundant verbunden.

LANs außenliegender Verwaltungsstandorte (mittelgroß, mittel) werden über LWL

unmittelbar mit jeweils einem der beiden Core-Cluster (Rathaus-Standorte) verbunden, die

Übertragung erfolgt soweit möglich mit 10 Gbit/s und wird über MACSec (IEEE 802.1AE)

abgesichert. In der Regel erfolgt dies aus wirtschaftlichen Gründen ohne Leitungsredundanz,

alternativ - bei besonders hohen Anforderungen - kann eine zweite Verbindung zum

komplementären Core-Cluster erfolgen. Die kleineren Standorte werden aus wirtschaftlichen

Gründen überwiegend über gesicherte Providerleitungen angeschlossen. Hier wird auf

Redundanz verzichtet.

Durch dieses Vorgehen bilden alle Standorte eines Bezirksamts oder einer Senatsverwaltung

eine leistungsfähige, gemeinsame LAN-Infrastruktur, die im Sinne der Mandantenfähigkeit/

Absicherung des Gesamtnetzes in einem gemeinsamen VPN vereint wird.


Drucker 2.4

Im Rahmen des IKT Arbeitsplatz werden die Netzwerk- und Multifunktionsdrucker

standardisiert zur Verfügung gestellt.

In der Zielarchitektur sind keine lokal am Arbeitsplatz angeschlossenen Drucker mehr

vorgesehen. Drucker sollen ausschließlich netzwerkbasierte Drucker/Scanner (Multi-

funktionsgeräte) sein. Betrachtet man die Druckfunktion so wird bei einem virtualisierten

Arbeitsplatzrechner der Druckerdatenstrom immer über die zentralen Netzwerk-

komponenten gesteuert. Das bedeutet, jeder Druck muss über die Standortverbindung zum

Data-Center und zurück übertragen werden. Ähnliches gilt für das Drucken aus dezentralen

IT-Fachverfahren. Da der eigentliche Druckerdatenstrom erhebliche Umfänge annehmen

kann, sollen derartige Geräte ggf. von einem im jeweiligen lokalen Netz betriebenen

Druckserver gesteuert werden, dies hält ein erhebliches Datenübertragungsvolumen

innerhalb des lokalen Netzes und entlastet in dieser Weise das BeLa.

Im BerlinPC werden die Universal Drucker Treiber des jeweiligen Herstellers eingesetzt.

Diese sind sowohl auf Client Betriebssystemen als auch Terminalserver einsetzbar. Alle

Druckertreiber werden im Software Basis Paket des BerlinPC bereitgestellt. Die Druckobjekte

werden im Rahmen des Betriebes des IKT-Arbeitsplatzes administriert.

Bei den Multifunktionsgeräten wird zusätzlich das Kopieren sowie das Scannen über die

Funktion „Scan to Mail“ sichergestellt.

Die Netzwerk- und Multifunktionsdrucker sind über den vom ITDZ betriebenen Webshop

abrufbar.


3. IKT-Basisdienste für E-Government

Nachfolgend werden die IKT-Basisdienste für E-Government benannt. Eine genaue

Ausprägung erfolgt in der Architekturliste.

Abbildung 7: Auszug IKT-Basisdienste für E-Government Stand Dez. 2018

Basisdienst Service-Portal 3.1

Dieser Basisdienst organisiert den zentralen Zugang zu allen E-Government-Angeboten der

Berliner Verwaltung unter der Adresse service.berlin.de als Bestandteil des

Hauptstadtportals berlin.de.

Basisdienst Dienstleistungsdatenbank (DLDB) 3.2

Die Dienstleistungsdatenbank bildet alle Dienstleistungen der Berliner Verwaltungen und die

Standorte, an denen die jeweiligen Dienstleistungen erbracht werden, nach einem

einheitlichen Schema ab.


Basisdienst Service-App 3.3

Eine die ein Smartphone bzw. die Funktionen des mobilen Endgerätes nutzende App, die

Inhalte des Service-Portals mit den Informationen zu den Verwaltungsdienstleistungen des

IKT-Basisdienstes DLDB darstellt und den Zugang zu online abwickelbaren Verwaltungs-

dienstleistungen ermöglicht.

Für die Abwicklung von Verwaltungsdienstleistungen innerhalb der App werden die hierzu

benötigten IKT-Basisdienste für E-Government (z.B. Service-Konto, Digitaler Antrag, E-

Payment) auch in der App bereitgestellt, so dass es nur eine App für alle

Verwaltungsdienstleistungen gibt.

Basisdienst Service-Konto 3.4

Das Service-Konto identifiziert und authentifiziert Bürger und Unternehmen auf

service.berlin.de gegenüber den IT-Fachverfahren. Es ergänzt andere Vertrauensdienste wie

die eID.

Basisdienst Postkorb 3.5

Digitale Entgegennahme von Nachrichten und Anhängen (z.B. Bescheide). Upload/Ablage

von Dokumenten zur mehrmaligen Nutzung in verschiedenen Anträgen. Der Postkorb wird

im Basisdienst Service-Konto realisiert.

Basisdienst eID 3.6

Die eID (elektronische Identität), erlaubt durch die Online-Ausweisfunktion des

Personalausweises bzw. mit dem des elektronischen Aufenthaltstitels eine sichere und

eindeutige Identifizierung auf dem höchsten Vertrauensniveau.

Basisdienst PKI 3.7

Als Schriftformersatz kann die qualifizierte elektronische Signatur angewandt werden. Der

Basisdienst PKI bündelt sämtliche Funktionalitäten, um eine gesetzeskonforme Verarbeitung

als auch eine vertrauliche Übertragung von Dokumenten und Daten zu ermöglichen:

• Signieren (in allen Signaturklassen)

• Verifizieren (auch internationaler Formate/Standards gemäß eIDAS-Verordnung)

• Verschlüsseln

• Entschlüsseln


Basisdienst Virtuelle Poststelle 3.8

Die Virtuelle Poststelle (elektronisches Behördenpostfach – eBPF) ist ein optional nutzbarer

Basisdienst für eine sichere, vertrauliche Kommunikation. Sie dient zur Entgegennahme von

Anträgen oder Dokumenten aus webbasierten Kunden-Frontends.

Basisdienst DE-Mail 3.9

Der Basisdienst DE-Mail ermöglicht eine nachweisbare und vertrauliche elektronische

Kommunikation. Der Austausch von DE-Mail-Nachrichten gilt als schriftformersetzend.

Gemäß des E-Government-Gesetzes Bln § 4 (2) ist jede Behörde verpflichtet, eine DE-Mail-

Adresse im Sinne des DE-Mail-Gesetzes als Eingangskanal zu eröffnen.

Als Eingangskanal kann DE-Mail alternativ zum Posteingang oder zur Antragsstellung nach

Authentifizierung über das Service-Konto genutzt werden.

Als Ausgangskanal kann DE-Mail alternativ zum Basisdienst Postkorb genutzt werden, um

Nachrichten der Verwaltung zu erhalten.

Basisdienst E-Payment 3.10

Der Basisdienst E-Payment stellt für alle Online-Fachverfahren im Land Berlin, die Gebühren

oder Entgelte erheben, eine elektronische Zahlungsfunktion mit verschiedenen

Zahlungsarten bereit und kann über standardisierte Schnittstellen sowohl an IT-

Fachverfahren als auch HKR-Systeme angebunden werden. Dies kann auch im Verbund mit

dem Basisdienst „Digitaler Antrag“ erfolgen.

Die derzeit verfügbaren Zahlungsarten sind Kreditkarten (MasterCard und VISA), giropay

sowie SEPA-Lastschriften. Eine Erweiterung um die Zahlarten paydirekt und PayPal ist

vorgesehen.

Basisdienst Zeit- und Terminmanagement (ZMS) 3.11

Das Zeit- und Terminmanagement dient der Buchung von Terminen für persönliche

Vorsprachen (Terminmanagement) sowie der Publikumssteuerung vor Ort

(Wartemanagement). Er kann in Antragsstrecken sowie IT-Fachverfahren integriert werden,

um die Vorsprache durch die Vorabübermittlung von Informationen vorzubereiten und

damit zu beschleunigen.


Basisdienst Digitaler Antrag 3.12

Diese Komponente verbindet als zentrale E-Government-Middleware die antragstellende

Person auf service.berlin.de mit IT-Fachverfahren der Verwaltung, steuert also die

Antragsstellung.

Zentrale Funktionen der Komponente „Digitaler Antrag“ sind:

Definition von Antragstrecken inkl. Einbindung von Prüfroutinen,

Erstellung und Veröffentlichung von webbasierten Dialogen für die Antragserfassung

Übergabe der Anträge an die IT-Fachverfahren zur Bearbeitung mit dezentraler

Fachlogik

Antrags-Verfolgung

Entgegennahme von Rückmeldungen aus den IT-Fachverfahren

der digitale Antrag ist optional als .pdf durch Antragstellende ausdruckbar

Es erfolgt keine Abbildung fachlicher Logik in diesem Basisdienst. IT-Fachverfahren dürfen

sich ausschließlich über diesen Basisdienst im Internet präsentieren.

Die Erstellung neuer Antragsstrecken erfolgt durch Auftrag der Geschäftsstelle „Digitaler

Antrag“ und wird vom ITDZ Berlin geleistet werden. Das ITDZ Berlin entwickelt

standardisierte Consulting- und Projektdienstleistungen, um IT-Fachverfahren an den

Digitalen Antrag anzubinden und den Antragsprozess zu designen und zu implementieren.

Basisdienst Digitale Akte 3.13

Der Basisdienst Digitale Akte stellt folgende Funktionalitäten zur Verfügung:

Dokumentenmanagement

Vorgangsbearbeitung

Langzeitspeicher

3.13.1 Dokumentenmanagement

Das Dokumentenmanagement bildet die Kernfunktionalitäten im Bereich der

Schriftgutverwaltung ab (Registrierung und Verwaltung von Dokumenten, elektronische

Aktenbearbeitung, die Abbildung aller Instrumente und Regularien der Schriftgutverwaltung,

wie z.B. Aktenpläne, Geschäftszeichenbildungsregeln und Aufbewahrungsfristen sowie

Integration in vorhandene Arbeitsumgebungen der Behörden).

Darüber hinaus ist die für die Einführung der Digitalen Akte unerlässliche Komponente

Digitalisierung / Dokumenteninputmanagement (Basisdienst DIM) zur Überführung von


Papierunterlagen in elektronische Form als funktionaler Bestandteil entsprechend zu

berücksichtigen.

3.13.2 Langzeitspeicherung

Langzeitspeicherung umfasst die langfristige revisionssichere Aufbewahrung von

elektronischen Akten, Vorgängen und Dokumenten vom Abschluss der Bearbeitung bis zum

Ablauf der jeweiligen Aufbewahrungsfristen.

Die Funktionalitäten des Dokumentenmanagements und der Langzeitspeicherung sind auch

den IT-Fachverfahren und weiteren IKT-Basisdiensten über geeignete Schnittstellen bereit zu

stellen

3.13.3 Vorgangsbearbeitung

Die Vorgangsbearbeitung ermöglicht eine elektronische und medienbruchfreie Abwicklung

der - im Rahmen der elektronischen Aktenführung relevanten - Geschäftsprozesse. Der IKT-

Basisdienst Digitale Akte wird allen Nutzenden im Land Berlin eine einheitliche

Vorgangsbearbeitung für zuvor definierte und standardisierte Prozesse z.B. im Sinne von

„elektronischen Umlauf-, Eil- bzw. Vorlagenmappen“ und deren Zeichnungssteuerung

bereitstellen. Darüber hinaus werden Funktionalitäten zur Unterstützung von Ad-hoc-

Workflows im Rahmen von dokumentenbasiertem Arbeiten bereit gestellt.

Es besteht die Pflicht, zur Ablage von Eingängen und Ausgängen im Basisdienst Digitale Akte.

Basisdienst Drucken 3.14

Der Basisdienst Drucken dient dem zum schutzbedarfs- und datenschutzkonformen,

zentralisierten Drucken, Kuvertieren und Versenden von Dokumenten (z.B. Bescheiden),

soweit diese nicht digital zugestellt werden.

Basisdienst Geodateninfrastruktur (GDI) 3.15

Über den Basisdienst GDI werden Geodaten über standardisierte Schnittstellen für Nutzende

zur Verfügung gestellt. Neben dem direkten Zugriff über einen Browser können die Dienste

auch in IT-Fachverfahren eingebunden werden. Die Schnittstellen basieren auf der

Architektur der Geodateninfrastruktur Deutschland in der jeweils aktuellen Version.

Basisdienst Konvertierungsdienst 3.16

Der Konvertierungs- und Validierungsdienst (KVD) des ITDZ Berlin ermöglicht die

Umwandlung von weit über 100 verschiedenen Dokumentenformaten in PDF-Dateien.


4. IKT-Basisdienste für Infrastruktur

Identity- und Accessmanagement 4.1

Aufbauend auf dem für den BerlinPC genutzten Verzeichnisdienst sind Rollen und Nutzende

für alle weiteren Anwendungen und IT-Fachverfahren, die von Beschäftigten der Berliner

Verwaltung genutzt werden und für die eine Authentisierung erforderlich ist, über die

zentrale Komponente Identity- und Accessmanagement zu verwalten.

Die jeweiligen IT-Fachverfahren bringen keine eigenen Identity- und Accessmanagement

Lösungen mit, sondern müssen ihre Identität in die vom ITDZ Berlin bereitgestellte Lösung

integrieren.

Verzeichnisdienste 4.2

Als zentraler Verzeichnisdienst wird im Land Berlin das „Active Directory“ (AD) mit der Root

Domain ad.verwalt-berlin.de genutzt. In dieser bestehenden Organisationsstruktur (Forest)

wird die Nutzung einer Domain für alle Benutzenden und Gruppen verbindlich angestrebt.

Organisationsgrenzen werden über Organisationsverzeichnisse mit möglicher eigener

Administrationsstruktur abgebildet. Die Verantwortung für das Benutzermanagement kann

über ein Web-Frontend an die jeweilige Organisation delegiert werden. Ausschließlich aus

diesen Benutzerangaben werden weitere zentrale Services wie zum Beispiel das globale

Adressbuch versorgt.

Mail – Gateway 4.3

Das ITDZ Berlin betreibt ein zentrales skalierbares Mail Gateway am Übergang zwischen

Landesnetz und Internet. Für den BerlinPC wird der Exchange Verbund genutzt. In der

Verbindung Mail Gateway, Exchange und Outlook Client gibt es aufeinander abgestimmte

Sicherheitssysteme zum Schutz vor Viren, Spam und anderer Malware.

Die Verschlüsselung der E-Mail Kommunikation erfolgt mit Microsoft Exchange zwischen

Outlook Exchange Server und zwischen Exchange Servern. Die Grundlage für die

Verschlüsselung der E-Mails bildet die Public Key Infrastructure (PKI) des Landes Berlin.


Domain Name System (DNS) 4.4

Alle Komponenten, die über das Berliner Landesnetz kommunizieren, verwenden dafür

private IPv4- und landeseigene IPv6-Adressen. Dieser wird mit dem IP-Adressrahmenkonzept

des Landes Berlin organisiert.

Das DNS der Berliner Verwaltung arbeitet mit einem inneren DNS im BeLa und einem

äußeren DNS in Richtung Internet. Innerhalb des Landes Berlins wird für die Kommunikation

ausschließlich der Namensraum *.verwalt-berlin.de verwendet. Das ITDZ Berlin betreibt die

Nameserver für diese Bereiche. Die Nutzung von DNSNamens- und IP-Adress-Zonen bedarf

der Registrierung beim ITDZ Berlin.

Network Time Protocol (NTP) 4.5

Das ITDZ Berlin stellt für die Zeitsynchronisation verbindlich zu nutzende Systeme bereit. Der

Zugang wird für dezentrale Zeitserver geöffnet, die dann wiederum die Clients in Ihrem

Verantwortungsbereich mit einem Zeitnormal versorgen.


5. IT-Fachverfahren

Das IT-Fachverfahren ist ein verwaltungsspezifisch implementiertes IT-Produkt. Es bildet

Geschäftsprozesse innerhalb einer Verwaltung ganzheitlich oder in wesentlichen Teilen IKT-

gestützt für den Endanwender und Endanwenderinnen ab. Ein IT-Fachverfahren besteht aus

IKT-Komponenten und nutzt IKT-Basisdienste.

Für die IT-Fachverfahren sind die übergreifenden Architektur- und Technologievorgaben

verpflichtend zu beachten und in die Ausschreibungsunterlagen mit aufzunehmen.

Die fachliche Hoheit über die IT-Fachverfahren verbleibt bei den fachlich zuständigen

Behörden.

Die Bereiche Infrastruktur, IKT-Sicherheit, Endgeräte und E-Government-Middleware geben

den technologischen Rahmen für die IT-Fachverfahren verbindlich vor. IT-Fachverfahren

werden hinsichtlich der technologischen Rahmenbedingungen vom Anforderungsträger zum

Anforderungsempfänger.

Die Oberflächen der IT-Fachverfahren (Clients) sind browserbasiert und HTML5-konform zu

gestalten. Ein IT-Fachverfahren darf keine spezifischen Einstellungen oder Erweiterungen der

Standard-Browser voraussetzen.

Falls eine browserbasierte Bereitstellung der Anwendungs-Oberflächen (Clients)

nachweislich nicht möglich sein sollte, muss sichergestellt werden, dass der Fachverfahrens-

Client eine der im Abschnitt zum BerlinPC beschriebenen Schnittstellen unterstützt.

Für IT-Fachverfahren stellt das ITDZ Berlin eine Infrastruktur bereit, in der Testumgebungen

aufgebaut werden, mit denen die Integration mit anderen Diensten und Infrastrukturen

getestet wird, bevor sie in der Produktivumgebung bereitgestellt werden.

IT-Fachverfahren müssen sich gegenüber dem Bürger über die einheitliche E-Government-

Middleware im Service-Portal auf Berlin.de präsentieren (siehe Kapitel 1.5). Die benötigten

Schnittstellen werden von den E-Government-Middleware-Komponenten vorgegeben.

Ergebnisse oder Bescheide aus IT-Fachverfahren sind ausschließlich im Basisdienst Digitale

Akte vorzuhalten.

IT-Fachverfahren sind dazu verpflichtet, die landesweiten Versionswechsel und Patch-Zyklen

von Technologien gemäß Architekturliste einzuplanen und nachzupflegen. Bei wesentlichen

technologischen bzw. fachlichen Änderungen an IT-Fachverfahren sind die Vorgaben der IKT-

Architektur verbindlich einzuhalten (siehe Kapitel 10.3.3).


Insbesondere ist sicher zu stellen, dass IT-Fachverfahren so implementiert bzw. angepasst

werden, dass sie sowohl in einer IPv4 als auch in einer IPv6-Netzwerkumgebung betrieben

werden können.

IT-Fachverfahren und sonstige, für die Ausübung der Verwaltungstätigkeiten notwendige,

Applikationen dürfen nicht auf der Basis von Office – Produkten (z.B. MS Access und MS

Excel) erstellt werden. Mit Applikationen bzw. dem Datenaustausch auf der Basis von MS

Access werden die Sicherheitsziele der Leitlinie zur Informationssicherheit und

Anforderungen nach BSI IT-Grundschutz nicht erfüllt. Bestehende, auf Office-Produkten

basierende, Applikationen sind in eine alternative Technologie zu überführen.

Für IT-Fachverfahren sind Lösungen zu bevorzugen, die mehr als nur eine der in der

Architekturliste als verbindlich gekennzeichnete Datenbanken unterstützen.

Eine Abbildung von Fachlogik in der Datenbank ist ebenso verboten wie eine direkte

Kopplung des Verfahrensclients mit einer Datenbank. Damit verbieten sich 2-Schicht-

Architekturen für IT-Fachverfahren und deren Bestandteile. Dabei ist es unerheblich, ob die

Client-Software auf dem Endgerät (Arbeitsplatz PC) oder auf einem Terminalserver betrieben

wird.

Im Falle von auf den Arbeitsplatz PCs zu installierenden Komponenten von IT-Fachverfahren

sind nur noch automatisierte und im Ausnahmefall teilautomatisierte Installationen erlaubt.

Die einzelnen Komponenten mit ihren aktuellen Versionen sind der IKT-Architekturliste zu

entnehmen.

Für den Betrieb der IT-Fachverfahren gilt eine landeseinheitliche Hostingstrategie. Alle IT-

Fachverfahren werden grundsätzlich auf der zentralen ITDZ-Infrastruktur betrieben.

Für ggf. mögliche Ausnahmen vgl. Kap. 7.1 (Cloud-Strategie).

Das ITDZ Berlin unterstützt die Behörden des Landes Berlin bei der Anforderungsaufnahme,

der Verfahrenseinführung und der Überführung zum technischen Standard.

Angebotene Services für IT-Fachverfahren 5.1

Das ITDZ Berlin bietet Services für:

IT-Fachverfahrensentwicklung und –integration. Diese Services stehen externen und

internen Softwareentwicklenden zur Verfügung, die im Auftrag der Berliner

Verwaltung IT-Fachverfahrenssoftware oder –dienste entwickeln. Diese Services

unterstützen die Entwicklung, den Test und die Abnahme der Fachsoftware und

stellen bereits in der Phase der Softwareentwicklung die Einhaltung der Vorgabe

sicher.


IT-Fachverfahrensbetrieb. Der Betrieb von IT-Fachverfahren wird abnahmepflichtig

angeboten. Der Betrieb basiert auf den in der IKT-Architekturliste aufgeführten

Technologien. Die Einhaltung der vereinbarten Servicelevels wird durch das ITDZ

Berlin gewährleistet.

Datenbankbetrieb. Der Datenbankbetrieb (Administration und Betrieb) erfolgt im

ITDZ Berlin. Je nach Größe und Komplexität der IT-Fachverfahren werden

unterschiedliche Ausprägungen von Datenbanken angeboten.

IT-Fachverfahren, die im ITDZ Berlin betrieben werden, müssen zunächst in einer

Entwicklungsumgebung auf Standardkonformität geprüft und gegebenenfalls in die

Gesamtarchitektur des Landes Berlin technisch integriert werden. Eine detaillierte

Beschreibung der Staging-Umgebung ist dem Kapitel 7.9 zu entnehmen.

Architektur- und Designprinzipien für IT-Fachverfahren 5.2

Die im Folgenden genannten Architektur- und Designprinzipien erleichtern die

Implementierung von IT-Fachverfahren und Diensten auf der Basis standardisierter

Plattformdienste.

5.2.1 Architekturprinzipien

Die Architektur von modernen Applikationen, die für den Betrieb auf Cloud-Infrastrukturen

optimiert sind, basiert auf vier Hauptprinzipien:

Responsivität (Antwortbereit)

Das Prinzip der Responsivität beschreibt die Eigenschaft einer Applikation, unter allen

Umständen eine zeitgerechte Antwort zu liefern, sofern und solange dies überhaupt

möglich ist.

Resilienz (Widerstandsfähig)

Resiliente Applikationen bleiben auch bei Ausfällen von Hard- und Software

antwortbereit.

Elastizität

Elastizität beschreibt die Beibehaltung des Antwortzeitverhaltens unter sich

ändernden Lastbedingungen.

Nachrichtenorientierung

Nachrichtenorientierte Applikationen verwenden asynchrone Nachrichten zur

Übermittlung von Informationen zwischen Komponenten eines Systems


Die Prinzipien orientieren sich an der Definition von „Reaktiven Systemen“2.

5.2.2 Designprinzipien

Zur Umsetzung der oben genannten Architekturprinzipien dienen die folgend genannten

Design – Prinzipien:

Atomizität

Atomizität bedeutet die Zerlegung von Applikationen in einzelne Services, wobei

jeder dieser Services für die Ausführung einer definierten Aufgabe verantwortlich ist.

Zustandslosigkeit

Ein statusloses Objekt hält keine Information und keinen Kontext zwischen zwei

Aufrufen auf diesem Objekt.

Idempotenz

Idempotente Services erhöhen die Verfügbarkeit und Zuverlässigkeit von

Applikationen dadurch, dass sie die Wiederholung einer fehlgeschlagenen Operation

erlauben, unabhängig auf welchem Knoten einer Umgebung sie laufen.

Parallelität

Parallelität bedeutet die Fähigkeit von Services, Aufgaben gleichzeitig auszuführen.

2 http://www.reactivemanifesto.org/de

http://www.reactivemanifesto.org/de


6. Schnittstellen

In diesem Abschnitt werden die Anforderungen an IT-Fachverfahren und Dienste bzgl. von

Schnittstellen zu Basisdiensten, Diensten und anderen IT-Fachverfahren beschrieben. Dabei

wird zwischen der technischen Ausprägung der Schnittstellen (Formate, Protokolle,

Infrastrukturen), der Nutzung und der Bereitstellung von Schnittstellen unterschieden.

Eine Beschreibung der Schnittstellen der E-Government–Middleware sowohl in fachlicher als

auch in technischer Hinsicht wird den Nutzenden der Schnittstellen verfügbar gemacht

werden, sobald dies für die jeweilige Komponente der E-Government–Middleware möglich

ist.

Die IT-Fachverfahren haben die von der E-Government-Middleware bereitgestellten

Schnittstellen zu nutzen. Individuelle Anpassungen der Schnittstellen für einzelne IT-

Fachverfahren sind nicht vorgesehen.

Nutzung von Schnittstellen 6.1

Entsprechend den Prinzipien einer serviceorientierten Architektur ist vor der

Implementierung oder einer wesentlichen Änderung eines IT-Fachverfahrens oder eines

Dienstes zu prüfen, ob die gleiche Funktionalität bereits als Service mit einer nutzbaren

Schnittstelle vorhanden ist. In diesem Falle ist der Servicenutzung gegenüber einer eigenen

Implementierung der Vorzug zu geben, sofern dies insbesondere unter den Aspekten der

Wirtschaftlichkeit und der IKT-Sicherheit sinnvoll ist.

Angebot von Schnittstellen 6.2

Entsprechend den Prinzipien einer serviceorientierten Architektur ist vor der

Implementierung oder einer wesentlicher Änderung eines IT-Fachverfahrens oder eines

Dienstes zu prüfen, ob die zu implementierende Funktionalität als Service für andere IT-

Fachverfahren oder Dienste bereitgestellt werden kann. Dabei sind insbesondere auch für

die mandanten- und verwaltungsübergreifende Nutzung notwendige Aspekte der

Wirtschaftlichkeit und der IKT-Sicherheit zu berücksichtigen. Die Implementierung einer

Funktionalität als Service ist immer zu bevorzugen, auch wenn beispielsweise dieser Service

in einem ersten Schritt nur innerhalb des IT-Fachverfahrens oder der Fachdomäne genutzt

werden kann. Eine Erweiterung zur Nutzung außerhalb des IT-Fachverfahrens oder der

Fachdomäne ist entsprechend zu planen.


Formate und Protokolle von Schnittstellen 6.3

Für den Austausch von Daten zwischen IT-Fachverfahren und Diensten sowie für die Nutzung

und das Angebot von Schnittstellen sind die Datenformate entsprechend des XÖV-

Rahmenwerkes (http://www.xoev.de/) gemäß der jeweils aktuellen Veröffentlichungen zu

verwenden. Protokolle für Schnittstellen sind an den in diesem Dokument beschriebenen

Architektur-und Designprinzipien (vgl. Kapitel 5.2) auszurichten. Darüber hinaus sind

allgemeine Prinzipien zu beachten:

Allgemein anerkannte und auf offenen Standards basierende

Schnittstellentechnologie (z.B. OSCI, JMS, REST, SOAP)

Angemessene Verschlüsselung auf Transport- und Nachrichtenebene

Asynchronität der Nachrichtenübermittlung

Möglichkeit der Inhaltsinspektion auf dem Transportweg, sofern die Vertraulichkeit

der Daten dies zulässt und/oder die Fachlichkeit dies erfordert (z.B. für das Routing)

Möglichkeiten der Protokollierung, Absenderbenachrichtigung und

Transaktionssicherheit sind der Fachlichkeit angemessen zu berücksichtigen

Open Data – Anforderungen an IT-Fachverfahren 6.4

IT-Fachverfahren sollen zum Export von Open Data über Schnittstellen in das Datenregister

und Datenportal verfügen bzw. diese ansprechen können.

Dabei muss zwischen zwei Wegen unterschieden werden:

1) Bedienung der Schnittstelle des Datenregisters zur Veröffentlichung von Metadaten

2) Schnittstelle zur Bereitstellung strukturierter Primärdaten aus dem IT-Fachverfahren

6.4.1 Bedienung der Schnittstelle des Datenregisters

Das Datenregister verfügt über eine Schnittstelle, die es IT-Fachverfahren erlaubt,

Metadaten zu Datensätzen auf dem Berliner Datenportal zu veröffentlichen. Die

Dokumentation der Schnittstelle kann beim Hersteller der Software für den jeweils gültigen

Versionsstand des Datenregisters abgerufen werden:

http://docs.ckan.org/en/latest/api/index.html

Informationen zum Metadatenschema für Veröffentlichung von Datensätzen im Datenportal

sind direkt im Datenregister abrufbar: https://datenregister.berlin.de/schema/

Zusätzlich zu der genannten Schnittstelle unterstützt das Berliner Datenregister auch das

gemeinsame deutsche Metadatenmodell DCAT-AP. Die entsprechende Dokumentation kann

unter http://www.dcat-ap.de/ abgerufen werden.

http://www.xoev.de/

http://docs.ckan.org/en/latest/api/index.html

https://datenregister.berlin.de/schema/

http://www.dcat-ap.de/


6.4.2 Schnittstelle zur Bereitstellung strukturierter Daten

Jedes IT-Fachverfahren, das Daten verarbeitet, die nach dem Berliner E-Government-Gesetz

zur Veröffentlichung vorgesehen sind, muss eine Schnittstelle bereitstellen, über die diese

Daten strukturiert abgerufen werden können. Diese Schnittstelle muss öffentlich erreichbar

und dokumentiert sein, so dass der Zugriff auf die Schnittstelle über das Datenportal

gesichert ist. Die Anforderungen an diese Schnittstelle werden im Rahmen der Fachlichkeit

auf der Basis der noch zu erstellenden Spezifikation abgestimmt.

6.4.3 Infrastrukturen für dateibasierten Datenaustausch

Für den Austausch von dateibasierten Daten ist der Service „KommGate“ zu nutzen.

KommGate ist der zentrale Dateitransferdienst für Behörden im Land Berlin und vermittelt

den Dateiaustausch sowohl zwischen Berliner Behörden untereinander, als auch zwischen

Berliner Behörden und externen Gegenstellen außerhalb des Berliner Landesnetzes.

Dieser Service wird vom ITDZ bereitgestellt und betrieben.


7. Infrastruktur

Cloud Strategie 7.1

Das ITDZ Berlin stellt den Berliner Verwaltungen einen technologisch abgestimmten Stack

aus IaaS/PaaS/SaaS und korrespondierenden Basisdiensten als private Cloud zur Verfügung.

Die gesamte Infrastruktur, auf welche die IT-Fachverfahren technisch aufsetzen, wird somit

standardisiert, automatisiert und virtualisiert durch die Private Cloud des Landes Berlin

(betrieben im ITDZ Berlin) bereit gestellt. Die von einem IT-Fachverfahren benötigte

Systemumgebung wird somit automatisiert und zeitnah bereitgestellt.

Alle Rechenzentren der Berliner Verwaltung werden vom ITDZ Berlin betrieben. Server

stehen grundsätzlich physisch in den Rechenzentren des ITDZ Berlin.

Die Leistungen Dritter werden in die Gesamt-Architektur und Gesamt-IKT-Strategie des

Landes Berlin integriert. Cloud-Leistungen von Drittanbietern werden in den Ressourcen-

Pool des ITDZ Berlin eingebunden, sofern sie sinnvoll eingesetzt werden können. Siehe dazu

auch Kapitel 7.2.

Das ITDZ Berlin ist zentraler System-Integrator des Landes Berlin. Die angebotenen Services

gibt es in drei unterschiedlichen Ausprägungen, die bezüglich strategischer Relevanz und

Vertretbarkeit bewertet werden.

7.1.1 Infrastructure as a Service (IaaS)

IaaS ist die bedarfsgerechte, automatisierte Bereitstellung von logischen IT-

Infrastrukturressourcen in einer virtualisierten Umgebung und umfasst die Bereitstellung

aller erforderlichen Infrastrukturkomponenten wie Server-, Speicher- und Netzkapazitäten

aus einem zentralen Datacenter. PaaS (Platform as a Service) verwendet die über IaaS

bereitgestellten Ressourcen.

7.1.2 Platform as a Service (PaaS)

PaaS umfasst neben erforderlichen IT-Infrastrukturen zusätzlich Laufzeitumgebungen und

Datenbanken für den Anwendungsbetrieb, sowie die Unterstützung von

Anwendungsentwicklung als Teil des Anwendungszyklus.

Eine PaaS-Umgebung erlaubt durch weitreichende Standardisierung eine automatische

Bereitstellung von Laufzeitumgebungen und Datenbanken. Diese Umgebungen können

automatisiert auf Änderungen der Last reagieren und sorgen so für eine wirtschaftlich

betreibbare aber gleichzeitig flexibel anpassbare IT–Infrastruktur.


Für die Bereitstellung der Plattform-Dienste wird im ITDZ die Containertechnologie Docker

verwendet, so dass neu einzuführende IT-Fachverfahren zukünftig in dem entsprechenden

Format für den Betrieb bereitgestellt werden müssen.

7.1.3 Software as a Service (SaaS)

SaaS beinhaltet die automatisierte Bereitstellung von standardisierten Applikationen aus

einem zentralen Datacenter, wobei der jeweilige IT-Dienstleister die dafür notwendige IT-

Infrastruktur, Laufzeitumgebungen und Datenbanken betreibt sowie technische

Unterstützung und Beratung leistet. Außerdem werden weitere operative Dienstleistungen

wie Authentifizierung, Verfügbarkeits-, Identitäts-, und Patchmanagement,

Aktivitätsüberwachung und Softwareupgrades durch den IT-Dienstleister durchgeführt.

SaaS-Angebote bauen auf Iaa- und Paa-Services auf.

Private und Public Cloud 7.2

Die Cloud des ITDZ Berlin ist grundsätzlich als Private Cloud angelegt. Es kann jedoch

gewichtige Gründe geben, die hybride Betriebsmodelle (Einbindung der Leistungen von

Drittanbietern) erforderlich machen. Insbesondere der Betrieb von nicht IKT-

architekturkonformen IT-Fachverfahren (bei Vorliegen einer Ausnahmegenehmigung), der

Betrieb von Verbundverfahren sowie die Beschleunigung von Service-Innovationen sind hier

einschlägig. Die bisherige exklusive Private Cloud-Strategie (ITDZ-Rechenzentren als Silo; alle

IT-Fachverfahren werden im Ziel-Zustand on-premise betrieben) wird daher erweitert und in

kontrollierter Art und Weise auf einen „Private First“-Ansatz hin flexibilisiert:

1) Als primär präferierte Lösung ist stets die Betreibbarkeit / Bereitstellung von

Services und Applikationen auf der ITDZ-Infrastruktur zu prüfen (Private).

2) Als erste Ausweichoption kommt sodann der Betrieb in anderen deutschen

öffentlich-rechtlichen Rechenzentren mit BSI-Zertifizierung sowie Anschluss an

das Netz des Bundes (NdB) infrage (Private-Partner). Hierzu ist eine

Ausnahmegenehmigung der IKT-Steuerung notwendig.

3) Als zweite Ausweichoption kommt ggf. und nach Einzelfallprüfung der Betrieb in

privaten Rechenzentren infrage (Public). Diese Option erfordert eine gültige

Ausnahmegenehmigung der IKT-Steuerung und ist nur zulässig, sofern

ausschließlich Daten mit normalem Schutzbedarf verarbeitet werden.

Im Rahmen von Einzelfallerwägungen sind die Schutzziele IKT-Sicherheit und Datenschutz im

Zweifel höher zu gewichten als Wirtschaftlichkeitserwägungen.


Server-Betriebssysteme 7.3

Im Land Berlin sind zwei Server-Betriebssysteme zugelassen. Hierbei handelt es sich um

Windows-Server und RedHat Enterprise Linux. Andere derzeit noch verwendete Server-

Betriebssysteme sind auslaufend.

Die anderen bisher genutzten Linux-Betriebssysteme werden nicht mehr unterstützt, weil

die Konzentration auf ein Linux Betriebssystem aus Gründen der Wirtschaftlichkeit und

Standardisierung geboten ist.

Datenbanken und Middleware 7.4

Im Land Berlin sind die folgenden Datenbankprodukte zugelassen: MSSQL, MariaDB,

PostgreSQL.

Die aktuelle Lizenz- und Preispolitik der Firma Oracle kollidiert mit der strategischen

Entscheidung für eine Virtualisierungslösung als Kernkomponente innerhalb der Cloud-

Infrastruktur.

Für Neuentwicklungen oder größere Veränderungsvorhaben ist daher der Einsatz

alternativer Datenbanken und Middleware-Plattformen vorgegeben.

Bei derzeit auf Oracle-Technologien basierenden IT-Fachverfahren sind die Verfahrens-

verantwortlichen verpflichtet, den Einsatz von alternativen Technologien zu prüfen.

Netzwerke (LAN,MSN,WAN) 7.5

Die nachfolgende Grafik zeigt einen Überblick über die Architektur des Berliner

Landesnetzes. In den weiteren Abschnitten werden die einzelnen Bestandteile kurz

dargestellt. Eine umfassendere Darstellung der Netzwerke kann dem Anhang entnommen

werden.


Abbildung 8: Berliner Landesnetz-Architektur

Die Verwaltungsstandorte werden über das BeLa-MSN als IP-Transportnetz angeschlossen.

Sprache wird von Daten getrennt in VLANs bzw. VPNs geführt/übertragen. Hierfür werden

gesicherte Übertragungsstrecken genutzt. Weitere detailliertere Informationen können dem

Kapitel 10.2 im Anhang entnommen werden.

7.5.1 BeLa-MSN und Grenznetz

Auf der eigenen LWL-Infrastruktur betreibt das ITDZ Berlin das BeLa-Multiservicenetzwerk

(BeLa-MSN). Es verbindet die Berliner Verwaltung untereinander und mit den

Rechenzentren des ITDZ Berlin.

Ein zentrales Grenznetz des BeLa-MSN stellt die Verbindung mit allen externen Netzwerken

und Zielen her, wie mit dem NdB-Verbindungsnetz und dem Internet. Der Zugang zu

externen Netzwerken ist ausschließlich über das Grenznetz des BeLa-MSN zulässig.

Die technologische Basis für das Bela-MSN bildet der neueste IEEE Standard 802.1Q-2014

„Bridges and Bridged Networks“, insbesondere Shortest Path Bridging (SPB).

Das BeLa-MSN ist hierarchisch aufgebaut und besteht aus drei Netzebenen:

a. Core Layer Hierarchy (CLH)

b. Distribution Layer Hierarchy (DLH)

c. Access Layer Hierarchy (ALH)

Die Services zum Anschluss der Verwaltungsnetze werden auf den ALH-Knoten erbracht.


Es kommt ein Kapselungsverfahren (MAC-in-MAC Overlay) für die skalierbare Virtualisierung

des Netzwerkes zum Einsatz.

Auf allen Verbindungen zwischen CLH, DLH und ALH-Komponenten wird die Verschlüsselung

MACSec IEEE 802.1AE eingesetzt (Link-Layer-Verschlüsselung). Zur Einhaltung der Schutzziele

Vertraulichkeit (C) und Integrität (I) werden Daten der Berliner Verwaltung, die über

öffentliches Straßenland geführt werden, verschlüsselt (MACsec(L2)/IPSec-VPN(L3))

übertragen

Die folgende Abbildung zeigt das grundlegende Architekturmodell:

Abbildung 9: Architektur des BeLa-MSN

Weitere detailliertere Informationen können dem Kapitel 10.2.1 im Anhang entnommen

werden.


7.5.2 Rechenzentrum-LAN und Standort LAN

In den Rechenzentren des ITDZ Berlin werden die IKT-Dienste und Services für das BeLa

bereitgestellt. Es werden getrennte Sicherheitszonen für Daten mit normalem und hohem

Schutzbedarf bereitgestellt. Es wird der BSI Grundschutz angewendet.

Der Betrieb der RZ-LANs erfolgt weitgehend automatisiert.

Standort- bzw. Campus-LANs werden in strukturierte Datenverkabelung erschlossen. Zur

Verdeutlichung der unterschiedlichen Anforderungen bei der strukturierten

Datenverkabelung nach DIN EN 50173-1 unterscheidet man die Bereiche:

Primärbereich

Sekundärbereich

Tertiärbereich

sowie

den Datenverteiler (Wiring Center)

Standort-LANs müssen einem normalen Schutzbedarf genügen.

WIC

TK TK TK TK

TK TK TK TK

TK TK TK TK

SV

Tertiärbereich

Tertiärbereich

Tertiärbereich

Sekundärbereich

Primärbereich

HWIC

WIC

TK TK TK TK

TK TK TK TK

TK TK TK TK

HWIC

WIC

TK TK TK TK

TK TK TK TK

TK TK TK TK

Sekundärbereich

HWIC

Sekundärbereich

TK = KommunikationsanschlußWIC = Wiring-Center

(Etagenverteiler)HWIC = Haupt-Wiring-Center

(Gebäudeverteiler)SV = Standortverteiler

Kommunikationsnetzbetreiber

Abbildung 10: Netzstruktur nach DIN EN 50173


Es werden Technologien eingesetzt, die einen weitgehend automatisierten Betrieb des LAN

ermöglichen. Es wird der BSI Grundschutz angewendet.

Das LAN stellt eine eigene Schutzbedarfszone dar und wird mit einem Sicherheitsgateway an

das BeLa-MSN angeschlossen. Da es keine Kontrolle über die anderen angeschlossenen

Teilnehmenden hat, ist aus Sicht des LAN das BeLa-MSN nicht vertrauenswürdig. An LAN und

WLAN angeschlossene Endgeräte befinden sich in der administrativen Hoheit des IKT-

Verantwortlichen des LAN. Private Endgeräte sind nicht zugelassen; mit einem geeigneten

Sicherheitsmechanismus wird der Zugang zum LAN/WLAN auf erlaubte und registrierte

Endgeräte beschränkt.


werden.

7.5.3 IP-Adressverwaltung

Die IP-Adressverwaltung im Berliner Landesnetz erfolgt nach einem IP-

Adressrahmenkonzept. Halter der IP-Adressbereiche des Landes Berlin ist SenInnDS. Sie

entscheidet als nachgeordnete Local Internet Registry (Sub-LIR) über die grundsätzliche

Verwendung (Strategie) der IP-Netzbereiche und vertritt Berlin in der Kommunikation nach

außen.


werden.

WLAN 7.6

Es ist geplant, die lokalen kabelgebunden Netzwerke mittelfristig strukturiert um die Option

WLAN-Produkt zu erweitern. Auf LAN bzw. eine aktuelle und leistungsfähige Verkabelung

kann jedoch auch in Zukunft nicht verzichtet werden, da eine entsprechende

Kabelinfrastruktur einerseits in Teilen auch für die Erschließung von WLAN Access Points

benötigt wird und anderseits bestimmte Gerätetypen (Drucker, Kartenleser, etc.) auf

absehbare Zeit auf kabelbasiertes LAN angewiesen sind.

Telekommunikation 7.7

Die Telefonie wird über Voice over IP (VoIP) realisiert. So entfällt der Betrieb zweier

unterschiedlicher Netze am Standort. Die VoIP-Dienste für den IKT-Arbeitsplatz sind im

Betriebsvertrag zum IKT-Arbeitsplatz Anlage A beschrieben. Es umfasst die Bereitstellung

und den Betrieb der IP-Endgeräte, Anpassungs- und Veränderungsleistungen und optionale


Zusatzleistungen. Der Betriebsvertrag und die Anlagen werden in Abstimmung mit dem Land

aktualisiert.

Telefoniedienste, die nicht in den IKT-Arbeitsplatz eingebettet sind, werden in einem

separaten Betriebsvertrag Telefonie-Dienstleistungen geregelt.

Falls erforderlich, kann die zentrale hybride Telefon – Plattform (IP-Centrx Hybrid), die

sowohl VoIP als auch die klassischen Endgeräteanschlüsse (TDM – Time Division Multiplex)

beherrscht, eingesetzt werden. Vor der Realisierung auf Basis dieser Plattform muss eine

Ausnahmegenehmigung der IKT-Steuerung vorliegen.

Lebenszyklen 7.8

Es werden grundsätzlich nur zwei Releases von Software, Hardware und Technologien

vorgehalten (Vorgängerversion und aktuellste Version). Einschränkungen können sich

insbesondere aus Sicherheitsgründen ergeben. Der Betrieb von abgekündigter Software wird

nicht über das Ende des Lebenszyklus (EOL) hinaus aufrechterhalten.

Betriebsumgebung 7.9

Das ITDZ betreibt Services in einer standardisierten Automatisierungsumgebung, in der

Ressourcen dynamisch verwaltet werden (Berlin-Cloud). In dieser Umgebung arbeitet das

ITDZ grundsätzlich mit einer Test-, Referenz- und Produktionsumgebung, um den Service

sicher und stabil erbringen zu können. Abweichungen von diesem Grundsatz können durch

Prüfaktivitäten zu einer Ausdehnung der geplanten Nicht-Verfügbarkeit der Anwendungen

(Wartungsfenster) führen.

In der Entwicklungs-/Testumgebung können Software (Anwendungen) entwickelt,

Hardware und Software (Betriebssysteme und Anwendungen) getestet und Fehlerursachen

ermittelt werden. Die Entwicklungs-/Testumgebung wird von Softwareentwicklern,

Anwendungs- und Systembetreuern u.a. Dienstleistern genutzt. Die Entwicklungs-

/Testumgebung muss nicht zwingend vom ITDZ-Berlin bereitgestellt werden. Die technische

Gestaltung der Entwicklungs-/Testumgebung referenziert immer die im ITDZ-Berlin zu

nutzenden Services (z.B. definierte Versionen von Betriebssystemen, Datenbanken,

Middleware etc.).

In der Referenzumgebung wird jede Software automatisiert installiert. Die infrastrukturellen

und fachlichen Funktionen werden durch den Verfahrensverantwortlichen abgenommen.

Zusätzlich besteht die Möglichkeit, hier Fehler aus dem Produktionssystem nachzustellen.

Eine Referenzumgebung wird von Verfahrensverantwortlichen genutzt, wobei


Softwareentwickler, Anwendungs- und Systembetreuer, das ITDZ Berlin und andere

Dienstleister die Referenzumgebung betreuen.

Die Produktionsumgebung stellt ausschließlich die beauftragten Services zur Unterstützung

der Business Prozesse des Kunden zur Verfügung. Alle Komponenten sind vor

Inbetriebnahme in der Referenzumgebung vom Verfahrensverantwortlichen freizugeben.

Die Übernahme der Komponenten in die Produktionsumgebung erfolgt typischerweise

automatisiert.

Zusätzliche Umgebungen (z.B. Umgebungen für Lasttests) können bei Bedarf bereitgestellt

werden.


8. IKT-Sicherheit

Die Berliner Verwaltung richtet sich an den relevanten Standards des Bundesamtes für

Informationssicherheit (BSI) aus.

IKT-Sicherheitsarchitektur 8.1

Zu den Aufgaben der IKT-Staatssekretärin / des IKT-Staatssekretärs gehört gemäß § 21, Abs.

2 Satz 2 Nr. 4 EGovG Bln die „fortlaufende Weiterentwicklung und Festsetzung der zentralen

IKT-Sicherheitsarchitektur und der Standards für die IKT-Sicherheit in der Berliner

Verwaltung und deren Unterstützung und Überwachung bei der Umsetzung der IKT-

Sicherheits-Standards.“

Die IKT-Sicherheitsarchitektur ist das zentrale Steuerungsinstrument zur Gewährleistung der

IKT-Sicherheit in der Berliner Verwaltung. Sie führt die hier dargestellten Inhalte weiter aus

und umfasst folgende Elemente:

Leitlinie Informationssicherheit (InfoSic LL) gemäß Standards des BSI und Vorgaben

des IT-PLR

Methodische und technisch-organisatorische Richtlinien zu einzelnen Aspekten der

IKT-Sicherheit. Richtlinien konkretisieren die InfoSic LL durch Vorgabe

standardisierter Rahmenbedingungen für wesentliche Aspekte/Bereiche der IKT-

Sicherheit

o Methodische Richtlinien legen verbindliche Rahmenbedingungen für

übergreifende Themen des ISMS-Prozesses (z. B. Notfallmanagement,

Risikoanalyse) fest.

o Technisch-organisatorische Richtlinien legen verbindliche

Rahmenbedingungen für die sichere Nutzung von IKT-Komponenten fest (z. B.

E-Mail-Server-Richtlinie, Richtlinie zum sicheren Browsen, Sicherer

Arbeitsplatz, Richtlinie zum sicheren Anschluss an das Berliner Landesnetz …).

IKT-Basisdienste für IKT-Sicherheit, die gemäß § 24 vom ITDZ den Behörden zur

verbindlichen Nutzung bereitgestellt werden (z. B. Verschlüsselung, Grenznetz)

Standard IKT-Sicherheitsbausteine für die vu IKT.

IKT-Sicherheitsbausteine definieren konkrete IKT-Sicherheitsmaßnahmen für die

einzelnen Komponenten der vu IKT und basieren auf den entsprechenden

Empfehlungen der IT-Grundschutzkataloge.

Übergangsfristen für den modernisierten IT-Grundschutz

Alle bestehenden IT-Sicherheitskonzeptionen und ISMS sind bis zum 30.09.2021 auf

den modernisierten BSI-Grundschutz umzustellen.


Das bedeutet insbesondere:

o Es sind die Anforderungen des jeweils gültigen Grundschutzkompendiums

umzusetzen und im ISMS-Tool entsprechend der Vorgaben zu

dokumentieren.

o Für Vorgehensweise und Methodik sind die gültigen BSI-Standard (derzeit BSI-

Standard 200-1, 200-2 und 200-3) anzuwenden.

Neu zu erstellende IT-Sicherheitskonzeptionen und neue ISMS sind ab dem 01.03.2019

ausschließlich nach dem modernisierten Grundschutz (Grundschutzkompendium) zu

erstellen/aufzubauen.

Bis zum 01.09.2018 sind IT-Sicherheitskonzeptionen noch nach der letzten Auslieferung der

IT-Grundschutz-Kataloge (15. Ergänzungslieferung) zu erstellen und im ISMS-Tool zu

dokumentieren.

IT-Sicherheitskonzeptionen umfassen die Sicherheitskonzepte der IT-Fachverfahren (und

mittelfristig auch die Infrastruktursicherheitsbausteine der vu IT-Infrastruktur).

Die (derzeit in Erarbeitung befindliche) zentrale IKT-Sicherheitsarchitektur wird die bereits

vorhandenen Regelungen zur IKT-Sicherheit (z. B. IT-Sicherheitsgrundsätze) gemäß den

Anforderungen des EGovG Bln fortschreiben. Bis zur Festsetzung der IKT-

Sicherheitsarchitektur sind die derzeit geltenden Regelungen zur IKT-Sicherheit weiter

anzuwenden.

Berlin-CERT 8.2

Das ITDZ Berlin betreibt als zentraler IKT-Dienstleister zur Unterstützung und Beratung der

Behörden der Berliner Verwaltung bei sicherheitsrelevanten Vorfällen in IKT-Systemen ein

Computersicherheits-Ereignis- und Reaktionsteam (Berlin-CERT). Die an das Berliner

Landesnetz angeschlossenen Behörden und Einrichtungen haben dem Berlin-CERT

sicherheitsrelevante Vorfälle unverzüglich zu melden. Zur Abwehr von Gefahren für die

Sicherheit der Informationstechnik werden zentral geeignete Monitoring- und

Analysekomponenten insbesondere zur Erkennung von Sicherheitslücken und zur

Früherkennung von versuchten Angriffen betrieben.

Behördliches ISMS 8.3

Alle Behörden der Berliner Verwaltung sind verpflichtet, ein Informations-Sicherheits-

Management-System (ISMS) gemäß den Standards des BSI aufzubauen und

weiterzuentwickeln (vgl. § 23 EGovG Bln). Dabei sind die Festsetzungen zur IKT-

Sicherheitsarchitektur und zu den Standards zur IKT-Sicherheit zu beachten (s. u.).


In den Behörden obliegt die Gesamtverantwortung für IKT-Sicherheit der Behördenleitung.

Dazu gehören u.a. die Steuerung und Aufrechterhaltung der IKT-Sicherheit, die

Bereitstellung der notwendigen Ressourcen, die Integration der IKT-Sicherheit in alle

Geschäftsprozesse (insbesondere die Festlegung sicherheitskritischer Geschäftsprozesse und

Informationen) sowie die Verabschiedung der behördlichen Leitlinie zur IKT-Sicherheit.

Im ITDZ Berlin wird ein ISMS gemäß den Standards des BSI umgesetzt.

Es wird ein einheitliches ISMS- Werkzeug (ISMS-Tool) eingesetzt.

Verfahrensunabhängige (vu) IKT 8.4

Sofern das ITDZ Berlin nach § 24 Abs. 2 EGovG Bln die vu IKT-Infrastruktur bereitstellt bzw.

betreibt, obliegt diesem die Verantwortung hinsichtlich der IKT-Sicherheit für entsprechende

Komponenten.

Für die vu IKT-Infrastruktur werden auf Basis IT-Grundschutz vom ITDZ zukünftig Standard

IKT-Sicherheitsbausteine erstellt und umgesetzt. Diese sind auch für Behörden verbindlich,

deren vu IKT-Infrastruktur noch nicht vom ITDZ betrieben wird, und von diesen

eigenverantwortlich umzusetzen.

Die Anpassung an höhere Schutzbedarfe erfolgt im Rahmen der IT-Sicherheitskonzeption des

IT-Fachverfahrens in der ergänzenden Risikoanalyse nach BSI-Standards. Ggf. sind danach

zusätzliche Maßnahmen durch den Verfahrensverantwortlichen notwendig.

Zentrale IKT-Sicherheitskomponenten 8.5

Die Übergänge vom Behördennetz in das BeLa und in Fremdnetze sind durch IT-

Sicherheitsgateways orientiert am Stand der Technik abzusichern. Die IT-

Sicherheitsgateways werden vom ITDZ Berlin betrieben. Die Kommunikation zwischen

Netzen mit unterschiedlichem Schutzbedarf ist ebenfalls durch IT-Sicherheitsgateways

abzusichern. Der Zugriff auf externe Datenquellen ist durch mindestens 2 unterschiedliche

Schadsoftwarescanner abzusichern. Dabei ist mindestens ein vom ITDZ zentral betriebener

Schadsoftwarescanner zu verwenden, welcher für die zentrale Erstellung der regelmäßigen

(z.B. wöchentlich, monatlich, …) Berichte verantwortlich ist.

Nutzung Berliner Landesnetz 8.6

Für den Anschluss an das vom ITDZ Berlin betriebene Berliner Landesnetz werden

Anschlussbedingungen für die sichere Nutzung festgelegt. Diese Anschlussbedingungen

gelten verbindlich für alle Einrichtungen, die das Berliner Landesnetz nutzen.


Verfahrensabhängige (va) IKT 8.7

Sicherheitsanforderungen an die verfahrensabhängige IKT werden gemäß § 21, Abs. 2 Satz 2

Nr. 9 EGovG Bln von der IKT-Staatssekretärin in enger Zusammenarbeit mit der jeweils

zuständigen Fachverwaltung definiert. Sie basieren auf der IKT-Sicherheitsarchitektur und

konkretisieren diese für die IT-Verfahren.


9. Digitale Barrierefreiheit

Die Berliner Verwaltung muss sich bei allen IT-unterstützen Aufgaben nach folgenden

rechtlichen Bestimmungen richten:

Verordnung zur Schaffung barrierefreier Informationstechnik nach dem

Behindertengleichstellungsgesetz (Barrierefreie-Informationstechnik-Verordnung

BITV) in der jeweils aktuellen Fassung

EN 301 549: Barrierefreiheitsanforderungen geeignet für die öffentliche Beschaffung

von IKT-Produkten und -Dienstleistungen in Europa

Web Accessibility Guidelines (WCAG) in der jeweils aktuellen Fassung

Diese Richtlinien gelten für alle Nutzeroberflächen (Präsentationsschicht), sowohl für die

Mitarbeitenden und Administrierenden der Berliner Verwaltung, als auch für Bürgerinnen

und Bürger.

Standards für web- und clientbasierte Software 9.1

Obwohl die BITV und die WCAG sich auf webbasierte Software beziehen, lassen sich die

meisten Kriterien auch auf clientbasierte Software anwenden. Um einige Erfolgskriterien

besser zu verstehen, kann der Begriff „Webseite“, „Seite“ oder „Webangebot“ durch den

Begriff „Software“ ersetzt werden. Die Aussage ein „Satz von Webseiten“ kann ersetzt

werden mit „innerhalb der Software“.

Die Standard-Anforderungen für digitale Barrierefreiheit basieren auf der BITV,

WCAG und EN 301549 in der jeweils aktuellen Version. Eine Checkliste der

Ausschlusskriterien für Webseiten sowie Software können der Anlage

„Ausschlusskriterien“ in Kapitel 10.4.2 entnommen werden.

Alle Bedingungen der Priorität 1 bei der BITV oder Konformitätsstufe AA beim WCAG

müssen erfüllt sein. Wenn die Bedingungen nicht beim Abschluss des Vertrages bzw.

der Softwareeinführung erfüllt sind, müssen sie spätestens nach Ablauf eines Jahres

erfüllt sein.

Alle Dokumente, die auf der Webseite bzw. in der Software verwendet werden,

müssen den Berliner Dokumenten Standards zur Barrierefreiheit entsprechen.

Erstellt die Software Dokumente, müssen diese den Berliner Dokumenten Standards

zur Barrierefreiheit entsprechen.

Die Webseite bzw. Software muss durch einen Screenreader vollständig nutzbar sein.

Die web- als auch clientbasierte Software muss nach BITV oder WCAG in der jeweils

aktuellen Version geprüft werden.


Für clientbasierte Software gelten ergänzende Prüfkriterien laut Anhang unter Kapitel 10.4.3.

Folgende Kriterien müssen nicht für clientbasierte Software getestet werden:

Blöcke umgehen (BITV-Nr. 2.4.1)

Seite mit Titel versehen (BITV-Nr. 2.4.2)

verschiedene Methoden (BITV-Nr. 2.4.5)

Sprache von Teilen (BITV-Nr. 3.1.2)

9.1.1 Anforderungen an den Prüfbericht des externen Gutachtens

Der Prüfbericht muss auflisten, ob die geforderten Berliner Ausschlusskriterien 10.4.2

erfüllt werden.

Der Prüfbericht muss eine Zusammenfassung der nicht erfüllten Kriterien beinhalten.

Der Prüfbericht muss Lösungsvorschläge der nicht erfüllten Kriterien beschreiben.

9.1.2 Anforderungen an den Nachbesserungsplan

Es muss ein Maßnahmenplan erstellt werden, in dem beschrieben ist, welche

Verstöße zu welchem Zeitpunkt beseitigt werden. Bedingungen sollen nach ihrer

Gewichtung priorisiert werden.

Es muss ein Konzept erstellt werden, in dem erklärt wird, wie Barrierefreiheit im

Produktionszyklus berücksichtigt und integriert wird.

Standards für Sprache 9.2

Die Anforderungen basieren auf der GGO I und den Anforderungen der BITV in der aktuellen

Version. Sie finden die Standards im Anhang „Leitfaden für verständliche Sprache“ im Kapitel

10.4.110.2.1.

9.2.1 Leichte Sprache

Leichte Sprache richtet sich an Menschen die Schwierigkeiten haben komplexere Texte und

Informationen zu verstehen. Ungefähr 7,5 Millionen Menschen der Bevölkerung brauchen,

aufgrund von verschiedenen Behinderungen, Texte in leichter Sprache. Es gibt klare Regeln,

die angewendet werden müssen, damit der Text als leicht gilt.

Jeder Webauftritt muss auf der Startseite einen Link zu einer Start bzw. Übersichtsseite in

Leichter Sprache haben. Diese Übersichtsseite soll in leichter Sprache erklären welche

Aufgaben die jeweilige Verwaltung hat, welche Dienste sie anbietet und wie diese Dienste in

Anspruch genommen werden können. Diese Seite soll durch ein dezentral zu beauftragendes

Übersetzungsbüros für Leichte Sprache erstellt und zertifiziert werden.


9.2.2 Verständliche Sprache

Verständliche Sprache hat weniger genaue Regeln als leichte Sprache. Verständliche Sprache

versucht Alltagsdeutsch zu benutzen und auf Fachsprache oder Amtsdeutsch zu verzichten.

Es werden auch die Begriffe Klare oder Einfache Sprache benutzt. Die verschiedenen Begriffe

sind nicht klar voneinander abgegrenzt und beinhalten sehr ähnliche Konzepte und Regeln.

Verständliche Sprache richtet sich an alle Menschen die es lieber einfach mögen oder

brauchen. Ungefähr 60 Prozent der Bevölkerung braucht Texte in verständlicher Sprache, um

die Inhalte verstehen zu können.

Die Berliner Verwaltungen sind angehalten ihre digitalen Texte in verständlicher oder

einfacher Sprache zu schreiben.

Assisitive Technologien 9.3

Um Menschen mit verschiedensten Einschränkungen und Behinderungen in der Verwaltung

eine gleichberechtigte Teilhabe zu ermöglichen, legt die IKT-Steuerung über die IKT-

Architekturliste Standards für assistive Technologien fest.


10. Anhänge

Standardisierungskatalog 10.1

Die nachfolgende Grafik stellt die wesentlichen Technologien und fachlichen Bausteine der

Ziel-IKT Architektur dar.

Abbildung 11: Technologie-Übersicht (Auswahl)

Die einzusetzenden Technologien sind mit den zulässigen Versionen in einem separaten

Dokument - der IKT-Architekturliste - aufgeführt.


Netzwerke 10.2

10.2.1 Ergänzungen BeLa-MSN und Grenznetz

Auf der eigenen LWL-Infrastruktur betreibt das ITDZ Berlin das BeLa-Multiservicenetzwerk

(BeLa-MSN).

Das BeLa-MSN ist hierarchisch aufgebaut und besteht aus drei Netzebenen:

a. Core Layer Hierarchy (CLH)

Die 6 CLH-Knoten sind als teilvermaschter Ring (hier dunkelblau) konzipiert und

bieten dadurch eine sehr hohe Ausfallsicherheit. Jeder CLH-Knoten ist immer mit drei

anderen CLH-Knoten verbunden. Hier werden IP-Pakete mit maximaler

Geschwindigkeit und Effizienz zwischen zwei Distributions-Knoten transportiert. Die

Verbindungen im Core-Bereich des BeLa-MSN erfolgen mit mindestens 40 Gbit/s,

vorzugsweise mit 100 Gbit/s, sofern die Entfernungen und die Optiken dies erlauben.

Die Komponenten sind auf Standorte im Stadtgebiet sowie dem Data-Center des ITDZ

Berlin verteilt. Das Design erlaubt das Abschalten einzelner Coreswitches ohne

Betriebsunterbrechung.

b. Distribution Layer Hierarchy (DLH)

Die Distribution-Ebene verbindet den Access-Layer mit dem Core-Layer und

konzentriert dabei zahlreiche Access-Standorte, um sie gemeinsam und redundant

mit dem Core zu verbinden.

Jeder DLH-Standort wird mit zwei gekoppelten Knoten ausgestattet, die jeweils eine

Verbindung zu zwei verschiedenen CLH-Knoten besitzen.

c. Access Layer Hierarchy (ALH)

Ein ALH-Knoten, bestehend aus zwei Switches, bildet die äußere Grenze des MSN.

Der Access-Layer (hier: hellblaues Oval) stellt für das jeweilige LAN den Anschluss an

das BeLa-MSN bereit und verbindet diesen mit dem Distribution-Layer. Hier werden

VPNs gebildet und das Routing sowie QoS-Policies für die angeschlossenen

Nutzernetze realisiert. Die physikalische Verbindung zu den Bedarfsträgern wird in

der Regel mit Gigabit Ethernet (bzw. bei großen Standorten mit 10 Gigabit Ethernet)

bereitgestellt.

Die ALH-Knoten werden redundant an 2 DLH-Knoten (am gleichen Standort oder

alternativ an unterschiedlichen Standorten) mit jeweils 10 Gbit/s angeschlossen.

Bei besonders hohen Anforderungen an die Verfügbarkeit der Leitungen erfolgt die

Anbindung auch zweibeinig an zwei DLH-Switches. Als ALH-Switches werden Layer-3-


Switches eingesetzt. An sie wird die im SNZ enthaltene Firewall angeschlossen.

Zwischen ALH und der Firewall des SNZ wird dynamisches Routing verwendet.

Die Services zum Anschluss der Verwaltungsnetze werden auf den ALH-Knoten erbracht. Die

logische Kopplung für Layer 3 Services stellt ein IP-Transportnetz dar. Das Routing aller

Kundennetze kann statisch oder dynamisch erfolgen.

Das BeLa-MSN ist ein IPv4/IPv6 Dualstack Transportnetz mit normalem Schutzbedarf. Es

verbindet die Berliner Verwaltung untereinander und mit den Rechenzentren des ITDZ

Berlin. Verschiedene, logisch voneinander getrennte, administrative Domänen und

geschlossene Nutzergruppen werden in „Virtuellen Privaten Netzwerken“ (VPN) realisiert.

Der allgemeine Datenverkehr des BeLa wird im VPN „BeLa Intranet“ und die IP-Telefonie im

VPN „BeLa Voice“ transportiert. Verwaltungen können sich auch eigene VPN für

geschlossene Nutzergruppen einrichten lassen.

Der sichere Zugang zu Ressourcen des ITDZ Berlin ist durch VPN-Tunnel zu schützen. Dabei

sind die beiden Techniken IP-SEC VPN und für mobile Geräte SSL VPN der Stand der Technik.

Insbesondere im Umgang mit mobilen Geräten ist die Implementierung von

Endpointprotection zu beachten.

Alle LAN-Verbindungen zwischen den Liegenschaften einer Verwaltung werden aus

Sicherheitsgründen grundsätzlich mit MACSec (IEEE 802.1AE) verschlüsselt.

Die physikalische Verbindung zu den Bedarfsträgern wird in der Regel mit Gigabit Ethernet

(bzw. bei großen Standorten mit 10 Gigabit Ethernet) bereitgestellt.

Ein zentrales Grenznetz des BeLa-MSN stellt die Verbindung mit allen externen Netzwerken

und Zielen her, wie mit dem NdB-Verbindungsnetz und dem Internet. Der Zugang zu

externen Netzwerken ist ausschließlich über das Grenznetz des BeLa-MSN zulässig.

Das Grenznetz fungiert als Paketfilter - Applikationsfilter - Paketfilter Sicherheitsgateway

(PAP) nach BSI Grundschutz. Es arbeitet streng nach dem Prinzip des Whitelistings: jeder

Verkehr wird unterbunden und nur der explizit mit Regeln definierte Verkehr ist zugelassen.

Es arbeitet weiterhin als Proxy, über den alle Verbindungen zwischen den externen Netzen

und dem BeLa terminiert und neu aufgebaut werden. Der zugelassene Verkehr wird auf

Sicherheitsrisiken untersucht.

Es stellt eine DMZ (Demilitarisierte Zone) bereit, in der alle Dienste platziert werden, die aus

dem Internet erreichbar sein sollen.

Das Grenznetz stellt somit Zugangspunkt wie auch erste Verteidigungslinie des Berliner

Landesnetzes gegenüber externen Netzwerken dar (Perimeter-Sicherheit). Es entbindet die

IKT-Verantwortlichen nicht von der Aufgabe, ihre IKT-Systeme entsprechend ihrem

Schutzbedarf zu schützen.


Für das BeLa-MSN und das Grenznetz gilt das Prinzip der Netzneutralität. Hiervon

ausgenommen sind Echtzeitanwendungen, die zur Sicherstellung der vom Land Berlin

erwarteten Qualität priorisiert behandelt werden können, wie etwa Telefonie.

10.2.2 Ergänzungen Rechenzentrum-LAN und Standort LAN

In den Rechenzentren des ITDZ Berlin werden die IKT-Dienste und -Services für das BeLa

bereitgestellt. Dies wird durch „high-performance, low-latency“ LANs mit Rechenzentrums-

Technologien und -Technik ermöglicht. Die RZ-LANs arbeiten in diesem Sinne als IPv4/IPv6-

Dualstack Transportnetz. Das Design der LANs folgt der Grundidee einer flachen Topologie

mit der geringstmöglichen Zahl an Hops zwischen zwei Endpunkten. Es werden getrennte

Sicherheitszonen für Daten mit normalem und hohem Schutzbedarf bereitgestellt. Es wird

der BSI Grundschutz angewendet. Alle Verbindungen und Komponenten in den RZ-LANs sind

mit einer 1 : 1 oder einer 1 : n+1 Redundanz ausgelegt.

Der Betrieb der RZ-LANs erfolgt weitgehend automatisiert.

Standort- bzw. Campus-LANs werden vom ITDZ Berlin betrieben und müssen einem

normalen Schutzbedarf genügen.

Das Design der LANs folgt der Grundidee einer flachen Topologie mit der geringstmöglichen

Zahl an Hops zwischen zwei Endpunkten. Es besteht aus einem redundanten LAN-Backbone,

an den Etagen-Switches (Edge/Access) zweibeinig angebunden werden. Statt Spanning Tree

werden moderne Layer2-Redundanztechnologien eingesetzt. Allgemein werden solche

Technologien eingesetzt, die einen weitgehend automatisierten Betrieb des LAN

ermöglichen. Es wird der BSI Grundschutz angewendet.

Jeder Endgeräte-Port im LAN unterstützt Power over Ethernet (mindestens IEEE802.3af-

2003) und QoS mit DiffServ. Die Portgeschwindigkeit beträgt mindestens 100 Mbit/s

Fullduplex.

Das LAN stellt eine eigene Schutzbedarfszone dar und wird mit einem Sicherheitsgateway an

das BeLa-MSN angeschlossen. Da es keine Kontrolle über die anderen angeschlossenen

Teilnehmer hat, ist aus Sicht des LAN das BeLa-MSN nicht vertrauenswürdig. Zur

vertraulichen Kommunikation mit anderen LANs oder zwischen Endgeräten werden

Verschlüsselungstechnologien unter Beachtung der Technischen Richtlinie BSI TR-02102

„Kryptographische Verfahren“ eingesetzt.

Nach Bedarf werden die LANs durch dem Stand der Technik entsprechende, sichere WLANs

erweitert.

An LAN und WLAN angeschlossene Endgeräte befinden sich in der administrativen Hoheit

des IKT-Verantwortlichen des LAN. Private Endgeräte sind nicht zugelassen.


Mit einem geeigneten Sicherheitsmechanismus wird der Zugang zum LAN/WLAN auf

erlaubte und registrierte Endgeräte beschränkt. Die Endgeräte des ITDZ werden durch eine

Zwei-Faktor Authentisierung geschützt.

Nach Bedarf werden zusätzliche Gäste-WLANs mit eigener physischer Infrastruktur ohne

Verbindung zum LAN betrieben. Zulässig ist auch die logische Trennung auf gemeinsamer

physischer Infrastruktur, wenn diese zur physischen Trennung gleichwertig ist. Gäste-WLANs

verfügen über einen eigenen Internetzugang. Eine direkte Verbindung zum Berliner

Landesnetz besteht nicht. Die Kommunikation zwischen Endgeräten im Gäste-WLAN wird

unterbunden. Zur Nutzung des Gäste-WLAN ist die Anmeldung an einem SelfService-Portal

notwendig.

Der Betrieb aller vom ITDZ Berlin betrieben LANs erfolgt mit einem zentralen

Managementsystem.

Die nachfolgenden Ausführungen geben einen Überblick über die passiven

Netzinfrastrukturen der Standortverkabelung. Details sind im „Planungsleitfaden - Bau und

Betrieb passiver Netzinfrastrukturen“ auf der Seite der IKT-Steuerung zu finden.

Im Primär- und Sekundärbereich werden grundsätzlich Lichtwellenleiter (LWL) eingesetzt.

Ergänzende Kupferverbindungen sind u. U. für Dienste, welche aus regulatorischen und/oder

wirtschaftlichen Gründen nicht im Kommunikationsnetz oder über LWL übertragen werden

können, sinnvoll.

Im Primär- und Sekundärbereich dienen LWL-Kabel zur Verbindung der einzelnen

Datenverteiler.

Dabei sind die Verbindungen zwischen dem Primär- und Sekundärbereich 10 Gigabit

Ethernet-fähig und der Tertiärbereich ist Gigabit Ethernet-fähig.

a) Primärnetz

Der Primärbereich stellt die gebäudeübergreifende Verkabelung zwischen den Gebäuden auf

einem Gelände (Campusbereich) dar. Ist nur ein Gebäude vorhanden, besteht der

Primärbereich nur aus dem Haupt-Wiring-Center (Gebäudeverteiler).

Im Primärbereich werden grundsätzlich Einmoden-LWL-Fasern eingesetzt.

b) Sekundärnetz

Der Sekundärbereich umfasst die Netzverbindungen zwischen dem Haupt-Wiring-Center

(HWIC) (Gebäudeverteiler) und den Wiring-Centern (WIC) (Etagenverteiler). Eingesetzt

werden Kabel mit Einmoden- und mit Mehrmoden-LWL-Fasern.


c) Tertiärnetz

Als Tertiärnetz wird die Verbindung zwischen den Etagenverteilern und den

Kommunikationsanschlüssen bezeichnet.

Das Tertiärnetz ist sternförmig als strukturierte Verkabelung aufzubauen. Dabei erfolgt die

Übertragung im Regelfall elektrisch über paarweise verseilte Kupferkabel (Twisted-Pair) und

im Ausnahmefall, wenn es aus baulichen oder technischen Gründen notwendig ist, optisch

über Glasfaserkabel.

Für die Installations- und Übertragungsstrecke definiert die Norm DIN EN 50173

verschiedene Anwendungsklassen (Link-Klassen für die Anwendung bis 10-Gigabit-Ethernet)

und somit das Leistungsvermögen der Übertragungsstrecke. Höhere Klassen erfüllen

automatisch die Anforderungen der darunterliegenden Klassen.

Die Anwendungsklasse (kurz Klasse) bezieht sich immer auf die Installationsstrecke.

Die Anwendungsklasse EA ist verbindlich für Verwaltungsneubauten, sowie Neu- und

Ergänzungsverkabelungen.

Diese symmetrische Kupferverkabelung ist somit eine Installation aus Einzelkomponenten

wie z. B. Kabel und Anschlussdosen.

Im Berliner Verwaltungsnetz gehen wir derzeit im Rahmen der Zielarchitektur von einer

Klasse EA mit einer Bandbreite bis 500 MHz Datenübertragung mit Standard Anforderungen

für den Einsatz bis 10-Gigabit-Ethernet aus. Sollte erhöhte Anforderungen zugrunde gelegt

werden müssen, so ist die Anwendungsklasse F mit einer Bandbreite bis 600 MHz

Datenübertragung für den Einsatz bis 10-Gigabit-Ethernet vorgesehen. Bei einzelnen

Komponenten erfolgt eine Klassifizierung in Kategorien. Für die einzelnen Komponenten sind

die Kategorien 6A mit einer Bandbreite bis 500 MHz und 7 mit einer Bandbreite bis 600 MHz

vorgesehen.

Enthält sie z. B. nur eine Komponente der Kategorie 6 (250 MHz) und ansonsten

Komponenten der Kategorie 7 (600 MHz) so wird die Übertragungsstrecke trotz der

leistungsstarken Kategorie 7-Komponenten lediglich in die Klasse E (250 MHz) eingestuft.

Die Kategorie 6A bezeichnet die Vorgabe für Infrastruktureinzelkomponenten, verbaut in

Neu- und Ergänzungsverkabelungen des Landes Berlin.

Grundlagen über symmetrische Kupferkabel und über deren Anwendung sind in DIN EN

50290-4-2 enthalten.

Für die Installationsstrecken sind aus Gründen des Investitionsschutzes mindestens Kabel

der Kategorie 7 vorzusehen.


Bei Neu- und Ergänzungsverkabelungen und bei Kupfer im Tertiärnetz sind in jedem Raum

unabhängig von der tatsächlichen Belegung, nach Arbeitsstätten Richtlinie (ASR), pro

potentiell möglichem Arbeitsplatz, vorzusehen:

2 Anschlüsse

ab 100 Mbit/s am Arbeitsplatz

Zusätzlich sind in Flurbereichen alle 20m jeweils 2 Kommunikationsanschlüsse sowie

zwei DV-Stromanschlüsse einzuplanen.

Gegebenenfalls sind Anschlüsse z.B. für energetische Steuerungen,

Videoüberwachung, WLAN Einsatz, sowie Besprechungsräume vorzusehen.

Derzeit wird davon ausgegangen, dass durch den Einsatz des BerlinPC, der nach den

Rahmenbedingungen zur Migration der Verwaltungsarbeitsplätze mindestens eine

Verkabelung der Kategorie 5 erfordert, je Arbeitsplatz nur 2 LAN-Anschlüsse belegt werden.

Im Rahmen der konkreten Migrationsplanung zum ITDZ Berlin kann in Abstimmung zwischen

ITDZ Berlin und der Migrationsbehörde weitere Anschlüsse vorgesehen werden, ohne dass

Ausnahmegenehmigungen der IKT-Steuerung einzuholen sind.

Wenn LWL im Tertiärbereich eingesetzt werden soll, ist in den meisten Fällen die Variante

„Fiber to the Office“ die wirtschaftlichere Lösung. Das LWL-Kabel wird direkt über LC-

Verbinder an einen Installationsswitch im Geräteeinbaukanal angeschlossen.

Bei Bestandbauten wird im ersten Schritt auf den tatsächlichen Ausbau im Primär-,

Sekundär- und Tertiärnetz zurückgegriffen. Die Ertüchtigung des Netzes wird anhand von

Messergebnissen im jeweiligen Netzsegment geplant. Eine mögliche Kaskadierung am

Arbeitsplatz kann z.B. über das Telefon erfolgen.

d) Verteiler (Wiring Center)

Die Standort- bzw. Haupt-Wiring-Center (Gebäudeverteiler) sind in separaten Räumen

unterzubringen. Dies gilt nur für Standorte der Standortklassen: mittel, mittelgroß und Core.

Der Standortverteiler sollte im zentralen Serverraum untergebracht werden.

Eine räumliche Zusammenlegung mit der Niederspannungshauptverteilung ist nicht zulässig.

10.2.3 Ergänzungen IP-Adressverwaltung

Die IP-Adressverwaltung im Berliner Landesnetz erfolgt getrennt für IPv4 und IPv6 nach

einem IP-Adressrahmenkonzept. Halter der IP-Adressbereiche des Landes Berlin ist

SenInnDS. Sie entscheidet als nachgeordnete Local Internet Registry (Sub-LIR) über die

grundsätzliche Verwendung (Strategie) der IP-Netzbereiche und vertritt Berlin in der

Kommunikation nach außen.


Das ITDZ Berlin agiert als operative Sub-LIR, erstellt die IP-Adressrahmenkonzepte und

verwaltet nach deren Vorgaben den IP-Adressraum bis zur Ebene der Standorte und

Verwaltungen.

Innerhalb der Standorte werden die IP-Adressen vom jeweiligen IKT-Verantwortlichen (dem

Endnutzer) eigenverantwortlich verwaltet. Bei Bedarf delegiert er die Verwaltung einzelner

IP-Netze an deren Nutzer (Halter/Verfahrensbetreiber des IP-Netzes).

Der IKT-Verantwortliche für ein IP-Netz ist dem IKT-Verantwortlichen der jeweils

übergeordneten IP-Hierarchieebene über die Verwendung seiner IP-Adressen

auskunftspflichtig.

IP-Adressbereiche des Landes Berlin:

Verwendung IPv4 IPv6

BeLa 10.0.0.0/9

2a02:1022∷/32

Internet 141.15.0.0/16

Tabelle 2: IP-Adressbereiche des Landes Berlin


Begriffsklärung IT – Fachverfahren 10.3

10.3.1 Konkretisierung des Begriffs IT – Fachverfahren

Nachfolgend sind Kriterien dargestellt, die den Begriff des IT-Facherfahrens (beschränkt auf

in der Verantwortung der öffentlichen Verwaltung im Land Berlin liegende) konkretisieren.

Das IT-Fachverfahren ist ein verwaltungsspezifisch implementiertes IT-Produkt.

Ein IT- Fachverfahren ist eine Anwendungssoftware, die Prozesse innerhalb einer

Verwaltung ganzheitlich oder in wesentlichen Teilen IKT-gestützt abbildet.

Ein IT-Fachverfahren besteht aus und/oder nutzt IKT-Komponenten bzw. IKT-

Basisdienste.

10.3.2 Konsequenzen für IT – Fachverfahren

Nachfolgend wird dargestellt, welche Konsequenzen und Folgerungen sich daraus ergeben,

dass eine Anwendungssoftware als IT-Fachverfahren eingestuft ist.

Jedes IT-Fachverfahren muss einen Verfahrensverantwortlichen haben, d.h. eine Or-

ganisationseinheit, die für den gesamten Lebenszyklus der Software verantwortlich

ist.

Jedes IT-Fachverfahren erfordert einen laufenden Aufwand, der sich über alle Phasen

des Lebenszyklus (Planung, Einführung, Anpassung, Betrieb, Außerbetriebnahme)

erstreckt.

Jedes IT-Fachverfahren ist in der IT-Bestands- und Planungsübersicht (IT-BePla)

aufzuführen.

Für Planung, Beschaffung, Einführung und Betrieb eines IT-Fachverfahrens sind

fachliche, technische und organisatorische Konzepte zwingende Voraussetzung.

IT-Fachverfahren bedienen sich der standardisierten IT-Infrastruktur und

standardisierter IKT-Basisdienste.

Es muss den Anforderungen der Barrierefreiheit entsprechen.

10.3.3 IKT-Architektur und IT-Fachverfahren

Auf Basis des EGovG Bln besteht für alle neuen und bei wesentlichen Veränderungen von IT-

Fachverfahren die Pflicht zur Selbstprüfung der IKT-Strategie-Konformität und bei

Abweichung zur Anpassung.


In der folgenden Tabelle wird dargestellt, wann wesentliche Änderungen vorliegen:

Wesentliche Änderungen Angleichung

an IKT-

Architektur

nötig

Keine

Angleichung

an IKT-

Architektur

nötig

Erstmalige oder Neu-Beschaffung oder Entwicklung eines IT-

Fachverfahrens

X

Ergänzung einer Funktionalität, für die ein IKT-Basisdienst zur

Verfügung steht

X

Ausweitung der Funktionen eines bestehenden IT-

Fachverfahrens um neue Fachaufgaben

X

Ausweitung der Nutzung eines bestehenden IT-

Fachverfahrens auf weitere Behörden

X

Aktualisierung eines bestehenden IT-Fachverfahrens aus

fachlichen Gründen (z. B. Rechtsanpassung, digitale

Barrierefreiheit)

bei gleichbleibender Prozesslandschaft und in bestehender

technischer Umgebung

X

Anpassung eines IKT-Architekturkonformen IT-

Fachverfahrens an Fortschreibungen der IKT-Architektur zur

Erhaltung der Konformität

X

Anpassung von IT-Fachverfahren an die Fortschreibung der

IKT-Architektur

- Status in der Architekturliste „verboten“

X

Bei größeren Technologie-Umstellungen, z.B.

Datenbanksysteme, Betriebssysteme

X

Tabelle 3: Wesentliche Änderungen bei IT-Fachverfahren

10.3.4 Abgrenzung zu IKT–Basisdiensten

IKT-Basisdienste setzen sich aus IKT-Komponenten, teilweise in Verbindung mit

Dienstleistungen, zusammen. Sie sind von der Verwaltung intern, damit auch von IT-


Fachverfahren, als auch vom Bürger unabhängig von fachlichen Anforderungen zur Erfüllung

von Querschnittsfunktionen zu nutzen.

Alle IKT-Basisdienste - unabhängig der Unterscheidung zwischen IKT-Basisdiensten für E-

Government und IKT-Basisdiensten für Infrastruktur - sind zentral finanziert.

Die folgenden Beispiele sollen im Zweifelsfall bei der Beurteilung helfen, ob eine

Anwendungssoftware als IT-Fachverfahren einzustufen ist oder nicht.

10.3.5 Keine IT-Fachverfahren

Für unterschiedliche IT-Fachverfahren wiederverwendbare IT-Produkte

Nur-Lese-Nachschlagewerke

Betriebssysteme

Datenbanksysteme

Mail-Programme


Anhänge zu Standards der digitalen Barrierefreiheit 10.4

10.4.1 Leitfaden für Verständliche Sprache

Es gibt einen Leitfaden und eine Checkliste die der Berliner Verwaltung bei der Erstellung

von digitalen Texten helfen soll.

1. Klare Struktur: Benutzen Sie Überschriften, Zwischenüberschriften und bei

Aufzählungen Listen. Lassen Sie genügend Zwischenräume zwischen Paragraphen.

2. Kein Amtsdeutsch: Benutzen Sie Alltagswörter statt Amtsdeutsch. Beispiele:

„informieren“ statt „in Kenntnis setzen“

„abgelehnt“ statt „abschlägig beschieden“

„Kopie“ statt „Abschrift“

3. Verständliche Begriffe: Vermeiden Sie Fachausdrücke oder erklären Sie den

Ausdruck. Benutzen sie einfache und bekannte Wörter.

4. Keine Fremdwörter: Versuchen Sie deutsche Wörter zu verwenden.

5. Spracheinstellung: Kennzeichen Sie bitte Wörter oder Passagen, die Sie in einer

anderen Sprache schreiben.

6. Keine Abkürzungen: Vermeiden Sie Abkürzungen. Wenn das nicht möglich ist,

erklären Sie die Abkürzung bei der Einführung.

7. Klare und eindeutige Links: Linktexte sollen aussagekräftig und eindeutig sein. Sie

sollen unabhängig von dem Rest des Textes verstanden werden. Benutzen Sie nur

URLs als Link Text, wenn die Menschen sich die URL merken sollen.

8. Kein Passiv: Benutzen Sie die aktive Form.

9. Keine Verneinungen: Versuchen sie die Sachlage positiv zu beschreiben statt negativ.

Verwenden Sie keine doppelten Verneinungen.

10. Keine Substantivierungen: Benutzen Sie lieber die Verbform, statt das Verb zu

substantivieren.

11. Kurze Sätze: Ein Satz sollte nicht mehr als 15 Wörter haben.

12. Ein Gedanke pro Satz: Versuchen Sie nur einen Gedanken pro Satz zu schreiben.

13. Kurze Worte: Versuchen Sie kurze Worte zu benutzen.

14. Wenig Floskeln und Füllwörter: Versuchen Sie den Text auf das Wesentliche zu

reduzieren und unwesentliche Wörter wegzulassen.

15. Gesetze ans Ende: Stellen Sie, wenn möglich, die Rechtsquellen an das Ende eines

Satzes oder Absatzes.


10.4.2 Ausschlusskriterien für Webseiten / Software

Datum:

Webseiten (URL)/Software (Name, Version):

BITV-

Nummer

Checkpoint Ergebnis

Erfüllt:

Ja/Nein/N.A.

Bemerkung

1.1.1 Nicht-Text-Inhalte

1.2.1 Aufgezeichnete Audio- und

Video-Dateien

1.2.2 Erweiterte Untertitel

(Captions)

1.2.3 Audio-Deskription oder

Volltext-Alternative

1.3.1 Zuordnung und Logik

1.3.2 Sinnvolle Reihenfolge

1.4.1 Ohne Farben nutzbar

1.4.3 Kontraste von Texten

ausreichend

2.1.1 Tastaturbedienbarkeit

2.1.2 Keine Tastaturfalle

3.2.1 Keine unerwartete

Kontextänderung bei Fokus

3.2.2 Keine unerwartete


BITV-

Nummer

Checkpoint Ergebnis

Erfüllt:

Ja/Nein/N.A.

Bemerkung

Kontextänderung bei Eingabe.

3.3.2 Beschriftungen von

Formularelementen

4.1.2 Name, Rolle, Wert

10.4.3 Ergänzende Kriterien für clientbasierte Software

BITV-

Nummer

Checkpoint Ergebnis

Erfüllt:

Ja/Nein/N.A.

Bemerkung

1.4.2 Audio-Kontrolle

2.1.2 Keine Tastaturfalle

2.3.1 Dreimaliges Aufblitzen –

Unterschreiten der

Schwellenwerte

2.4.1 Umgehen von Elementgruppen

2.4.3 Fokus-Reihenfolge

2.4.4 Zweck eines Links (im Kontext)

3.1.1 Sprache

3.2.3 Einheitliche Navigation

3.2.4 Einheitliche Bezeichnung

3.3.4 Fehlervermeidung


Verfügbarkeit der Architekturbestandteile 10.5

Die nachfolgende Tabelle gibt einen Überblick über den Status und die geplante

Verfügbarkeit einzelner Bestandteile der Zielarchitektur.

Komponentenname Status Verfügbar ab

BerlinPC Verfügbar Rollout erfolgt gemäß

Migrationsreihenfolge

Bürgerterminal Derzeit keine Planung

DE-Mail Verfügbar

Digitaler Antrag In Entwicklung H1 / 2019

Dokumenten-Input-Management (DIM) In Entwicklung 2020

DNS Verfügbar

Druck (OMS) Verfügbar

Digitale Akte In Entwicklung 2022/23

eID / ePA Verfügbar

Elektronische Signatur Verfügbar

E-Payment Verfügbar

GDI Verfügbar

IaaS Verfügbar

Identity- und Accessmanagement In Planung H1 / 2019

Mail-Gateway Verfügbar

NTP Verfügbar

PaaS Verfügbar

In Entwicklung

Open Source Services

Microsoft Services

voraussichtlich 2019

Service-App Verfügbar

Service-Konto / Postkorb Verfügbar

Service-Portal Verfügbar

Vermittlung und Auskunft

(Bürgertelefon115 u.a.)

Verfügbar

Verzeichnisdienste Verfügbar

Virtuelle Poststelle (VPS) Verfügbar

Zeit- und Terminmanagement (ZMS) Verfügbar

Tabelle 4: Verfügbarkeit der Architekturbestandteile (Auswahl)


11. Abkürzungsverzeichnis

Abkürzung Bedeutung

BeLa Berliner Landesnetz

DaaS Desktop as a Service

Zentrale Bereitstellung eines virtualisierten Desktops über ein Netzwerk

DLDB Dienstleistungsdatenbank

DIM Dokumenten-Input-Management

DMS Dokumentenmanagement-System

DNS Domain Name Service

Dienst zur Namensauflösung in Netzwerken

eBPF Elektronisches Behördenpostfach

eID Elektronische Identität

EOL End of Lifecycle

Ende des Lebenszyklus

ePA Elektronischer Personalausweis

GDI Geodateninfrastruktur

GIS Geografisches Informationssystem

Grenznetz Stellt die Verbindung des BeLa mit allen externen Netzwerken und Zielen

her (z.B. mit den Netzen des Bundes NdB)

IaaS Infrastructure as a Service

Bereitstellung von über Netzwerke zugreifbare virtuellen Infrastruktur-

Komponenten

JMS Java Message Service

Java Programmierschnittstelle für nachrichtenorientierte Middleware

LAN Local Area Network

Lokales (örtliches) Netzwerk

MSN Multi Services Network

Netzwerk, das verschiedene Kommunikationsarten (z.B. Sprach- und

Datenkommunikation) gleichzeitig unterstützt

NdB Netze des Bundes

NTP Network Time Protocol

Standard-Protokoll zur Synchronisation von Uhren in Netzwerken

OMS Output-Management-System

System zur Erstellung, Steuerung und Verteilung von physischen (und ggf.

auch elektronischen) Dokumenten


Abkürzung Bedeutung

OSCI Online Service Computer Interface

Sammlung von Netzwerkprotokollen für die deutsche Verwaltung

PaaS Platform as a Service

Bereitstellung von kompletten Laufzeitumgebungen, die über Netzwerke

zugreifbar sind

PBX Private Branch Exchange

Telefonanlage

PKI Public-Key Infrastruktur

System zur Verwaltung von digitalen Zertifikaten

PSTN Public Switched Telephone Network

öffentliches Telefonnetz

REST Representational State Transfer

Programmierparadigma für verteilte Systeme und andererseits auch

Schnittstelle.

RZ Rechenzentrum

SOAP Simple Object Access Protocol

SOAP ist ein Protokoll zum Austausch XML-Information-Set-basierter

Nachrichten über ein Rechnernetz

TDM Time Division Multiplex

Zeitmultiplex-Verfahren-Daten verschiedener Sender werden auf einem

Kanal übertragen, wobei jedem Sender dedizierte Zeitabschnitte

zugewiesen werden

VBS Vorgangsbearbeitungssystem

VoIP Voice over IP

Sprachtelefon über das Internet Protokoll

VPN Virtuelles privates Netzwerk

VPS Virtuelle Poststelle

WAN Wide Area Network

Rechnernetz, welches sich über einen großen geografischen Bereich

erstreckt.

Tabelle 5: Abkürzungen

Documents

IKT-Architektur für das Land Berlin · Version 1.4 Stand Januar 2019 Seite 6 von 67 Vorwort Das vorliegende Dokument beschreibt die anzustrebende Ziel-Architektur der IKT-Landschaft