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
Version 1.4 Stand Januar 2019
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
Version 1.4 Stand Januar 2019
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
Version 1.4 Stand Januar 2019
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.
Version 1.4 Stand Januar 2019 Seite 7 von 67
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
Version 1.4 Stand Januar 2019 Seite 8 von 67
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
Version 1.4 Stand Januar 2019 Seite 9 von 67
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.
Version 1.4 Stand Januar 2019 Seite 10 von 67
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.
Version 1.4 Stand Januar 2019 Seite 11 von 67
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)
Version 1.4 Stand Januar 2019 Seite 12 von 67
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:
Version 1.4 Stand Januar 2019 Seite 13 von 67
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.
Version 1.4 Stand Januar 2019 Seite 14 von 67
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.
Version 1.4 Stand Januar 2019 Seite 15 von 67
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.
Version 1.4 Stand Januar 2019 Seite 16 von 67
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.
Version 1.4 Stand Januar 2019 Seite 17 von 67
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.
Version 1.4 Stand Januar 2019 Seite 18 von 67
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
Version 1.4 Stand Januar 2019 Seite 19 von 67
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.
Version 1.4 Stand Januar 2019 Seite 20 von 67
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.
Version 1.4 Stand Januar 2019 Seite 21 von 67
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.
Version 1.4 Stand Januar 2019 Seite 22 von 67
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
Version 1.4 Stand Januar 2019 Seite 23 von 67
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.
Version 1.4 Stand Januar 2019 Seite 24 von 67
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
Version 1.4 Stand Januar 2019 Seite 25 von 67
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.
Version 1.4 Stand Januar 2019 Seite 26 von 67
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.
Version 1.4 Stand Januar 2019 Seite 27 von 67
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.
Version 1.4 Stand Januar 2019 Seite 28 von 67
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).
Version 1.4 Stand Januar 2019 Seite 29 von 67
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.
Version 1.4 Stand Januar 2019 Seite 30 von 67
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
Version 1.4 Stand Januar 2019 Seite 31 von 67
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
Version 1.4 Stand Januar 2019 Seite 32 von 67
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.
Version 1.4 Stand Januar 2019 Seite 33 von 67
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.
Version 1.4 Stand Januar 2019 Seite 34 von 67
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.
Version 1.4 Stand Januar 2019 Seite 35 von 67
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.
Version 1.4 Stand Januar 2019 Seite 36 von 67
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.
Version 1.4 Stand Januar 2019 Seite 37 von 67
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.
Version 1.4 Stand Januar 2019 Seite 38 von 67
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.
Version 1.4 Stand Januar 2019 Seite 39 von 67
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.
Version 1.4 Stand Januar 2019 Seite 40 von 67
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
Version 1.4 Stand Januar 2019 Seite 41 von 67
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.
Weitere detailliertere Informationen können dem Kapitel 10.2.2 im Anhang entnommen
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.
Weitere detailliertere Informationen können dem Kapitel 10.2.3 im Anhang entnommen
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
Version 1.4 Stand Januar 2019 Seite 42 von 67
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
Version 1.4 Stand Januar 2019 Seite 43 von 67
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.
Version 1.4 Stand Januar 2019 Seite 44 von 67
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.
Version 1.4 Stand Januar 2019 Seite 45 von 67
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.).
Version 1.4 Stand Januar 2019 Seite 46 von 67
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.
Version 1.4 Stand Januar 2019 Seite 47 von 67
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.
Version 1.4 Stand Januar 2019 Seite 48 von 67
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.
Version 1.4 Stand Januar 2019 Seite 49 von 67
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.
Version 1.4 Stand Januar 2019 Seite 50 von 67
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.
Version 1.4 Stand Januar 2019 Seite 51 von 67
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.
Version 1.4 Stand Januar 2019 Seite 52 von 67
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-
Version 1.4 Stand Januar 2019 Seite 53 von 67
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.
Version 1.4 Stand Januar 2019 Seite 54 von 67
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.
Version 1.4 Stand Januar 2019 Seite 55 von 67
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.
Version 1.4 Stand Januar 2019 Seite 56 von 67
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.
Version 1.4 Stand Januar 2019 Seite 57 von 67
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.
Version 1.4 Stand Januar 2019 Seite 58 von 67
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
Version 1.4 Stand Januar 2019 Seite 59 von 67
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.
Version 1.4 Stand Januar 2019 Seite 60 von 67
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-
Version 1.4 Stand Januar 2019 Seite 61 von 67
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
Version 1.4 Stand Januar 2019 Seite 62 von 67
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.
Version 1.4 Stand Januar 2019 Seite 63 von 67
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
Version 1.4 Stand Januar 2019 Seite 64 von 67
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
Version 1.4 Stand Januar 2019 Seite 65 von 67
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)
Version 1.4 Stand Januar 2019 Seite 66 von 67
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
Version 1.4 Stand Januar 2019 Seite 67 von 67
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
Top Related