8. Grobkonzept Transportinfrastruktur

Redaktioneller Hinweis

Dokument der aktuellen Iteration.

8.1 Abstract

Mit der Registermodernisierung entsteht zum ersten Mal ein die gesamte Verwaltung überspannender Informationsverbund. Für den sicheren Nachrichtenaustausch in diesem Verbund wird eine Transportinfrastruktur benötigt, welche nachvollziehbare und Ende-zu-Ende sichere Kommunikation über bestehende Verwaltungsnetze (Netze des Bundes (NdB), Landesnetze, Kommunalnetze) hinweg ermöglicht. Die in Deutschland bestehende OSCI Infrastruktur hat sich nur in Teilen der Verwaltung durchgesetzt. Europäische Infrastrukturen wie eDelivery AS4 oder X-Road erfüllen die Anforderungen nicht oder sind nichtkompatibel zur bestehenden Infrastruktur, bspw. den Verwaltungsnetzen oder dem DVDV. Das NOOTS verfolgt daher eine Entkopplungsstrategie: Anstatt sich auf eine Transportinfrastruktur festzulegen, wird der Transport über Sichere Anschlussknoten (SAK) entkoppelt.

Abb. 1: Entkopplung vom Transport durch Sichere Anschlussknoten (SAK)

Die von den Security Servern aus X-Road inspirierten Sichere Anschlussknoten sollen den Anschluss an die Transportinfrastruktur für dieTeilnehmer einfach und sicher gestalten, bspw. indem sie die Verschlüsselung und die Verwaltung der Zertifikate übernehmen. Gleichzeitig entkoppeln sie die Teilnehmer vom Rest der Transportinfrastruktur im Sinne einer Fassade. So können mehrere Transportinfrastrukturen zeitgleich unterstützt werden. Zudem wird eine sanfte Migration auf zukünftige Transportinfrastrukturen, bspw. auf Grundlage eines europaweiten Transportstandards, unterstützt.

8.2 Einführung und Ziele

8.2.1 Überblick

Die Teilnehmer des NOOTS kommen aus unterschiedlicher Fachlichkeit und Verwaltungsebenen. Beispielsweise werden für einen Kindergeldantrag (Arbeit & Soziales, Bund) unter anderem Geburtsurkunden der Kinder (Personenstand, Kommunen) benötigt. Dabei sind Teilnehmer aus dem Bund in den Netzen des Bundes (NdB) angesiedelt, Teilnehmer aus den Ländern in Landesnetzen oder Kommunalnetzen des jeweiligen Landes. Diese Netze sind zum Teil direkt, zum Teil über das Internet und zum Teil über das Verbindungsnetz (NdB-VN) miteinander gekoppelt. Die Kopplung erlaubt allerdings keine freie Kommunikation über Netzgrenzen hinweg.

Abb. 2: Ausgangslage schematischer Aufbau der Verwaltungsnetze und Anschlüsse Data Provider und Data Consumer

Die Abbildung zeigt den schematischen Aufbau der Netze. Die schraffierten Blöcke stellen dabei Zugangspunkte zu oder Übergangspunkte zwischen Weitbereichsnetzen dar. Jeder Übergangspunkt beinhaltet typischerweise eine Firewall, die den zulässigen Datenverkehr überwacht, und eine Adressumsetzung, die die IPv4 Adressbereiche der Netze für Netzübergreifende Verbindungen aufeinander abbildet. Um eine Kommunikation zwischen Teilnehmern verschiedener Netze zu ermöglichen, müssen sowohl Firewall als auch Adressabbildungen geeignet konfiguriert werden, ggfs. konsistent über mehrere Übergangspunkte hinweg. Das dazu erforderliche Verfahren ist wenig transparent, fehlerträchtig und mit einer Wartezeit von Wochen bis Monaten verbunden. Für kleine Informationsverbünde ist dieser Weg gangbar, in der Registermodernisierung ist jedoch mit einer sehr großen Anzahl von Einzelverbindungen zu rechnen (obere Abschätzung 1.000.000). Daher wird eine Transportinfrastruktur benötigt, die eine Verwaltungsnetze übergreifende Kommunikation ohne Einzelfreischaltung für jede Verbindung ermöglicht.

Ein ähnliches Problem ergibt sich beim technischen Zugang der Data Consumer und Data Provider zu den Weitbereichsnetzen. Diese werden in der Regel in abgeschotteten Netzsegmenten betrieben, die aus den Verwaltungsnetzen nicht erreichbar sind. Auch hier werden einzelne Verbindungen über die Infrastruktur freigeschaltet, über die bspw. auch heute schon auf Register zugegriffen werden kann. Für eine viel stärker vernetzte, digitalisierte Verwaltung wird eine Transportinfrastruktur benötigt, die eine große Anzahl von Verbindungen ermöglich, ohne dass jede einzelne Verbindung von oder zu einem Nahbereichsnetz freigeschaltet werden muss.

8.2.2 Ziele der Komponente

In diesem Dokument wird die Transportinfrastruktur des NOOTS vorgestellt. Diese soll eine einfache und sichere Kommunikation zwischen den Teilnehmern über die Netze von Bund und Ländern ermöglichen. Ein besonderer Fokus liegt auf der Unterstützung von NOOTS-Anwendungsfällen mit interaktiven Nachweisabrufen, die im Dialog mit einer natürlichen Person innerhalb kurzer Zeit ausgeführt werden müssen, wie es auch vom Europäischen Once-Only Technical System (EU-OOTS) gefordert wird. Darüber hinaus soll die Transportinfrastruktur Qualitätsmerkmale bieten, die die Netze allein nicht gewährleisten können. Dabei sind in Zusammenarbeit mit den anderen NOOTS-Komponenten und Teilnehmern die Gewährleistungsziele gemäß Standard-Datenschutzmodell (SQ-13) wie Verfügbarkeit, Vertraulichkeit, Integrität, Transparenz, Nichtverkettung und Intervenierbarkeit relevant.

Abb. 3: Zusammenhang Transportinfrastruktur und Netze

Die folgenden Ausführungen zur Transportinfrastruktur in diesem Dokument sind wie folgt strukturiert:

• Im Kapitel "Randbedingungen" werden die technischen, rechtlichen und organisatorischen Rahmenbedingungen betrachtet, wie beispielsweise Annahmen und Abgrenzungen.
• Das Kapitel "Kontextabgrenzung" beschreibt das fachliche und technische Umfeld der Transportinfrastruktur, einschließlich der Interaktion mit NOOTS-Komponenten und NOOTS-Teilnehmern über Schnittstellen.
• Im Kapitel "Anforderungen" werden wesentliche funktionale und nicht-funktionale Anforderungen für die NOOTS-Transportinfrastruktur mit Erläuterungen aufgelistet.
• Im Kapitel "Lösungsstrategie" werden die wichtigsten Designentscheidungen für die NOOTS-Transportinfrastruktur zusammengefasst.
• Das Kapitel "Bausteinsicht" leitet ein allgemeines Architekturmodell basierend auf einer Analyse bestehender Transportinfrastrukturen in Deutschland und im europäischen Ausland ab. Verschiedene Ansätze werden verglichen und gegenübergestellt, woraus die Bausteine "NOOTS-Sichere Anschlussknoten", "NOOTS-Anschlussprotokoll" und "NOOTS-Transportprotokoll" entwickelt und im Detail vorgestellt werden.
• Die "Laufzeitsicht" beschreibt den Ablauf eines vom Data Consumer initiierten Nachweisabrufs für den HLA-Anwendungsfall "1a: Interaktiver Nachweisabruf zu einer natürlichen Person über das NOOTS" (AD-NOOTS-03) im Detail.
• Im Kapitel "Ausblick und Weiterführende Aspekte" wird ein Ausblick auf Themen gegeben, die in zukünftigen Releases dieses Dokuments behandelt werden sollen.
• Im Anhang "A - Bestehende Transportinfrastrukturen" werden bestehende Transportinfrastrukturen in Deutschland und im europäischen Ausland betrachtet.
• Der Anhang „B - Nachrichtenverfolgung mit OpenTelemetry“ führt in den Open-Source-Standard OpenTelemetry für die verteilte Nachrichtenverfolgung ein, ein Projekt der (Cloud Native Computing Foundation (CNCF).

8.2.3 Begriffsdefinitionen

In diesem Kapitel werden Begriffe und ihre Bedeutungen aufgelistet, die im Rahmen dieses Konzeptes von Bedeutung sind und verwendet werden. Für allgemeine Begriffe der Registermodernisierung wird auf das zentrale Glossar Gesamtsteuerung Registermodernisierung (SQ-14) verwiesen.

Tab. 1: Begriffsdefinitionen

Abbildung A

8.3 Randbedingungen

8.3.1 Technische / Organisatorische / Rechtliche Randbedingungen

8.3.1.1 Verwaltungsnetze und Verbindungsnetz

Bund und Länder betreiben jeweils eigene Netze, über die ihre Verwaltungseinheiten sicher untereinander kommunizieren können. Darüber hinaus ermöglicht das Verbindungsnetz (NdB-VN) den Datenaustausch von öffentlichen Stellen über den so gestalteten Verbund der Verwaltungsnetze von Bund, Ländern und Kommunen. Stellen öffentlichen Rechts, wie beispielsweise Behörden, sowie beliehene Dritte und beauftragte Dienstleister von Bund, Ländern und Kommunen können sich direkt an das Verbindungsnetz anschließen oder bestehende Anschlusspunkte ihrer Verwaltungsnetze nutzen. Die Netzinfrastruktur dient zum einen dem Schutz vor Cyberangriffen aus dem Internet, zum anderen gewährleistet sie die Souveränität der Behörden-IT.

Das Verbindungsnetz bietet initial das Vertrauensniveau "normal" gemäß TR-3107-1, abgesichert durch die vom IT-Planungsrat beschlossenen Anschlussbedingungen und die Technischen Richtlinien des BSI. Es lassen sich zudem weitere geschlossene Netze mit höherem Vertrauensniveau durch Ergänzung der Anschlussbedingungen abbilden. Eine durchgängige Verschlüsselung ist im Verbindungsnetz zwischen den Teilnehmern gegeben. Auch IT-Systeme, die in den Verwaltungsnetzen betrieben werden, und deren Kommunikationsstrecken müssen abgesichert werden, bspw. mittels Sicheren Anschlussknoten und durchgängiger Verschlüsselung.

Verwaltungsnetze sind sehr heterogen ausgebaut, zum Teil sind Kommunen mit Bandbreiten von nur 1 MBit angebunden. Die Zugänge der Kommunen zum Internet sind in den Ländern aufgrund teilweise zentraler Vorgaben sehr unterschiedlich ausgestattet. Die Kosten des Verbindungsnetzes sind nach Leistung und Bandbreiten gestaffelt und werden jeweils vom IT-Planungsrat beschlossen. Da das Verbindungsnetz auf dem Backbone und den Standardprodukten eines großen deutsche Carriers basiert, sind Leistung und Bandbreiten mit dem Angebot der Internet-Carrier vergleichbar. Im Verbindungsnetz wird durchgängig IPv6 bereitgestellt, sowohl bei der durchgängigen Verschlüsselung wie auch bei den Basisdiensten. FIT-Connect und die meisten OSCI-Verbindungen nutzen das Internet. Damit wird bewusst auf Schutzfunktionen und Souveränität verzichtet.

IT-Netzstrategie 2030

Abb. 4: Zielbild des IVÖV gemäß Netzstrategie 2030 (SQ-15)

Im Rahmen der 2019 durch den IT-Rat beschlossenen "Netzstrategie 2030 für die öffentliche Verwaltung" sollen die bestehenden Verwaltungsnetze zu einem neuen Informationsverbund der öffentlichen Verwaltung (IVÖV) konsolidiert und weiterentwickelt werden. Die konzeptionellen Arbeiten am IVÖV befinden sich in einer frühen Phase. Derzeit ist noch wenig über die konkret geplanten Merkmale bekannt.

Wie im Verbindungsnetz wird auch der IVÖV IPv6 vollumfänglich unterstützen. Ergänzt um eine übergreifende Governance, die voraussichtlich auch mit technischen Mitteln wie Software Defined Networks (SDN) durchgesetzt wird, könnte dadurch eine Netzinfrastruktur entstehen, welche die Vorteile der Verwaltungsnetze (Informationssicherheit, Souveränität) mit den praktischen Vorteilen eines transparent durchgängigen Transportmediums verbindet.In einem solchen Szenario könnte eine verteilte Transportinfrastruktur überflüssig werden. Die Integration in den IVÖV könnte mithilfe der Sicheren Anschlussknoten erfolgen.

Da der IVÖV zur Ausbaustufe 2025 nicht zur Verfügung stehen wird, wird die Transportinfrastruktur vorerst auf die aktuell verfügbaren Netze ausgelegt. Dabei soll sie einer Migration auf den neuen Informationsverbund jedoch nicht im Wege stehen, sobald die Voraussetzungen durch die verantwortlichen Stellen geschaffen sind.

8.3.1.2 Annahme und Rahmenbedingung

Tab. 2: Annahme und Rahmenbedingung

8.3.2 Abgrenzungen

8.3.2.1 EU-OOTS Transportinfrastruktur

Die NOOTS-Transportinfrastruktur ermöglicht den rechtskonformen Abruf von elektronischen Nachweisen aus den Registern der deutschen Verwaltung. Über eine Anbindung an die EU-OOTS Transportinfrastruktur (EU-02)wird zudem der Austausch von Nachweisen mit dem EU-Ausland ermöglicht. Innerhalb Deutschlands erfolgt der Austausch von Nachweisen ausschließlich über das NOOTS. Beim Austausch von EU-Nachweisen ist das EU-OOTS für den Transport der Nachweise zwischen den EU-Mitgliedstaaten zuständig, während das NOOTS für den Transport der Nachweise innerhalb von Deutschland verantwortlich ist.

8.3.2.2 Fachdatenstandard für Nachweise

Die Transportinfrastruktur ist für den sicheren technischen Transport von Nachweisen unabhängig von deren Semantik, Struktur und Syntax verantwortlich. Im "Fachdatenkonzept" des PB Register wird beschrieben, wie der automatisierte Nachweisaustausch von Daten zwischen Data Consumer und Data Provider in verschiedenen Reifegraden über das NOOTS fachlich gewährleistet werden kann. Die hierfür benötigten Bedingungen, wie beispielsweise ein semantischer Fachdatenstandard, werden entsprechend definiert. Somit bildet das Fachdatenkonzept die fachliche Grundlage für den automatisierten Datenaustausch.

8.4 Kontextabgrenzung

8.4.1 Fachlicher Kontext

Abb. 5: Fachlicher Kontext Transportinfrastruktur

In der folgenden Tabelle werden die Anwendungsfälle für Abrufe von elektronischen Nachweisen zwischen Data Consumer und Data Provider aufgelistet, die durch die NOOTS-Transportinfrastruktur gemäß dem Architekturzielbild 2028 der High-Level-Architektur (AD-NOOTS-03) unterstützt werden. In dieser Konzeptversion sind die Anwendungsfälle für den Abruf von Registerdaten für den Registerzensus sowie für die Wissenschaft noch nicht berücksichtigt.

Tab. 3: HLA-Anwendungsfälle

Die Data Consumer und Data Provider werden verpflichtend über das Anschlussprotokoll des Sicheren Anschlussknotens (SAK) an die Transportinfrastruktur angebunden. Die Intermediäre Plattform (AD-NOOTS-06) fungiert als Vermittler zwischen der NOOTS- und der EU-OOTS-Transportinfrastruktur, indem sie Nachweisabfragen aus dem EU-Ausland in nationale Abfragen umwandelt und umgekehrt. Die Vermittlungsstelle (AD-NOOTS-08) ist eine dritte öffentliche Stelle, die gemäß § 7 Abs. 2 IDNrG (RGR-01) bei Datenübermittlungen unter Verwendung einer IDNr zwischen öffentlichen Stellen verschiedener Verwaltungsbereiche eine abstrakte Berechtigungsprüfung durchführt. Sie überprüft und protokolliert, ob ein Data Consumer einen Nachweistyp von einem Data Provider zu einem angegebenen Kommunikationszweck abrufen darf. Wenn die erforderliche Abrufberechtigung fehlt, erfolgt keine Übermittlung von Nachweisdaten. Die Prüfung der abstrakten Berechtigung (PAB) wird durch die Sicheren Anschlussknoten der Transportinfrastruktur gewährleistet und ist fest in den SAK für die Data Consumer und Data Provider integriert.

8.4.2 Technischer Kontext

Die Transportinfrastruktur ist über die Sicheren Anschlussknoten für den sicheren und effizienten technischen Transport elektronischer Nachweise zwischen Data Consumer und Data Provider gemäß der XNachweis-Spezifikation (XS-01) verantwortlich. XNachweis ist ein Standard für die fachunabhängige Anforderung und Übermittlung von Nachweisen zu natürlichen Personen und Unternehmen. Dabei muss die Transportinfrastruktur eng mit einer Reihe weiterer NOOTS-Komponenten zusammenarbeiten, um eine reibungslose Datenübertragung zu gewährleisten und gleichzeitig die Einhaltung gesetzlicher und sicherheitsrelevanter Anforderungen sicherzustellen.

Abb. 6: Technischer Kontext Transportinfrastruktur

Neben der NOOTS-Komponente Vermittlungsstelle muss der Sichere Anschlussknoten (SAK) für einen Data Consumer die Schnittstellen der folgenden NOOTS-Komponenten aufrufen, bevor ein Nachweisabruf des Data Consumer beim Data Provider erfolgen kann. Eine detaillierte Ablaufbeschreibung der Nachweislieferung und der Interaktion der NOOTS-Komponenten ist im Kapitel zur Laufzeitsicht zu finden.

• IAM für Behörden (AD-NOOTS-05): stellt dem Data Consumer nach erfolgreicher Authentifizierung ein Zugriffstoken für den Zugriff auf andere Komponenten des NOOTS-Ökosystems aus.
• IDM für Personen (AD-NOOTS-10): ermöglicht dem Data Consumer den Abruf der Identifikationsnummer (IDNr) einer natürlichen Person anhand von deren Basisdaten (XS-03).
• IDM für Unternehmen (AD-NOOTS-11): ermöglicht dem Data Consumer den Abruf der bundeseinheitlichen Wirtschaftsnummer (beWiNr) eines Unternehmens anhand von dessen Unternehmensbasisdaten (XS-06).
• Registerdatennavigation (AD-NOOTS-07): ermöglicht dem Data Consumer die Ermittlung des für den gewünschten Nachweis zuständigen Data Providers (Nachweisangebot) und dem SAK des Data Consumers den Abruf der technischen Verbindungsparameter des Data Providers.

8.5 Anforderungen

8.5.1 Funktionale Anforderungen

Die nachfolgenden funktionalen Anforderungen definieren die erforderlichen Funktionalitäten oder Verhaltensweisen der Transportinfrastruktur und beschreiben, welche Aufgaben sie ausführen oder welche Fähigkeiten sie besitzen soll.

Tab. 4: Funktionale Anforderungen Transportinfrastruktur

8.5.2 Nicht-funktionale Anforderungen

Nicht-funktionale übergreifende Anforderungen an das NOOTS gelten auch für die Transportinfrastruktur und werden nachfolgend aufgelistet.

Tab. 5: Nicht-funktionale Anforderungen NOOTS

8.6 Lösungsstrategie

Die folgende Liste enthält die Top-7 Designentscheidungen für die NOOTS-Transportinfrastruktur:

• Verpflichtender SAK für Einhaltung gesetzlicher Vorgaben, inklusive Vermittlungsstelle:
  Die Transportinfrastruktur ist verpflichtet sicherzustellen, dass gesetzliche und sicherheitsrelevante Anforderungen eingehalten werden. Dazu gehört unter anderem die Verpflichtung, bei jedem Nachweisabruf mit einer IDNr die abstrakte Berechtigungsprüfung der Vermittlungsstellen gemäß § 7 Abs. 2 IDNrG (RGR-01) durchzuführen. Der verbindliche Einsatz des SAK mit integrierter Prüfung des Vorliegens der abstrakten Berechtigung bei jedem Nachweisabruf mit IDNr ermöglichtdie Erfüllung dieser gesetzlichen Anforderung.
• Stärkung der Resilienz durch SAKs in der dezentralen Verantwortung der NOOTS-Teilnehmer:
  Der SAK wird als zentrale Software-Komponente bereitgestellt, jedoch dezentral von den NOOTS-Teilnehmern betrieben. Der Datenaustausch erfolgt ausschließlich zwischen den dezentralen SAKs der NOOTS-Teilnehmer. Nach der Herstellung einer sicheren Verbindung zwischen den SAKs der Data Consumers und Data Providers hängt der kontinuierliche Datenaustausch ausschließlich von der Verfügbarkeit der dezentralen SAKs, den NOOTS-Teilnehmern und dem Netzwerk zwischen ihnen ab. Ein Ausfall eines dezentralen SAKs bei einem Data Consumer beeinträchtigt ausschließlich die daran angeschlossenen Data Consumers. Ein Ausfall eines dezentralen SAKs bei einem Data Provider betrifft lediglich die anfragenden SAKs. Die Gesamtverfügbarkeit der übrigen SAKs bleibt davon unbeeinflusst. Eine Kompromittierung einer einzelnen dezentralen SAK-Instanz führt nicht unmittelbar zur Kompromittierung anderer SAKs.
• Einfacher NOOTS-Anschluss durch interoperables Anschlussprotokoll:
  In einer heterogenen föderalen IT-Anwendungslandschaft müssen zahlreiche NOOTS-Teilnehmer an NOOTS angeschlossen werden. Daher ist es erforderlich, dass die Anbindung über ein einfaches, stabiles und interoperables Anschlussprotokoll des SAK erfolgt. Auf diese Weise sollen Änderungen in der Transportinfrastruktur möglichst geringe Auswirkungen auf die Anbindung der zahlreichen NOOTS-Teilnehmer haben.
• Nahtlose Integration des SAK in bestehende IT-Landschaften:
  Heutzutage betreiben zukünftige NOOTS-Teilnehmer ihre Onlinedienste, Fachverfahren und Register sowohl in traditionellen Betriebsumgebungen als auch in (DVC-konformen) Cloud-Umgebungen. Der SAK muss sowohl auf herkömmlichen Serverplattformen als auch als Container in DVC-konformen Cloud-Umgebungen einsatzfähig sein.
• Vereinfachter NOOTS-Anschluss zur Komplexitätsreduktion:
  Durch die Auslagerung zentraler Transportfunktionen wie Berechtigungsprüfungen und Zertifikatsverwaltung in den SAK werden die NOOTS-Teilnehmer beim NOOTS-Anschluss erheblich entlastet.
• Unterstützung des Request-Response-Nachrichtenaustauschmusters:
  Die nationalen Onlinedienste und Verwaltungsleistungen der EU-Mitgliedstaaten (Evidence Requester) ermöglichen den Nutzern einen interaktiven Abruf von Nachweisen aus nationalen Registern mit sofortiger Vorschau (Preview) der Nachweisdaten. Die NOOTS-Transportinfrastruktur unterstützt dieses interaktive Nutzerverhalten durch Transport- und Anschlussprotokolle, die das synchrone Request-Response-Nachrichtenaustauschmuster implementieren. Diese Designentscheidung entspricht der Definition des Request-Reply-Integrationsmusters im Kapitel 7.2 "Integration and Service Interaction Patterns" der "Once-Only Technical System High Level Architecture" (EU-02) des EU-OOTS.
• Nachhaltigkeit in Transport:
  Die Transportinfrastruktur wird von Beginn an unter Berücksichtigung des Ressourcenverbrauchs entwickelt, zum Beispiel durch die Implementierung einer leichtgewichtigen SAK-Lösung oder den Einsatz effizienter Nachrichtenaustauschmuster. Dadurch entstehen kosteneffiziente und klimafreundliche Lösungen.

8.7 Bausteinsicht

8.7.1 Baustein Übersicht

Im Rahmen des Entwurfs der NOOTS Transportinfrastruktur wurden verschiedene bestehende Transportinfrastrukturen untersucht. Dabei hat sich gezeigt, dass diese sehr unterschiedliche Ziele verfolgen und einen sehr unterschiedlichen Aufbau aufweisen. Daher wird in der Baustein Übersicht zunächst ein abstraktes Architekturmodell abgeleitet. Dieses dient vor allem dazu, eine einheitliche Begriffsbildung für die wesentlichen Elemente einzuführen. Im Anhang A - Bestehende Transportinfrastrukturen werden die existierenden Transportinfrastrukturen unter Verwendung dieser Begriffe beschrieben.

Basierend auf dem abstrakten Architekturmodell und den zugehörigen Begriffen werden in den folgenden Kapiteln ausgewählte Bausteine im Kontext des NOOTS ausführlich erläutert, darunter die Bausteine NOOTS Sicherer Anschlussknoten (SAK), NOOTS-Anschlussprotokoll und NOOTS-Transportprotokoll.

8.7.1.1 Abstraktes Architekturmodell

Abb. 7: Abstraktes Architekturmodell der Transportinfrastruktur des NOOTS

Das Modell geht davon aus, dass Data Consumer und Data Provider in unterschiedlichen Netzen angesiedelt sind. In der Darstellung werden aus Gründen der Anschaulichkeit jeweils drei Data Consumer und drei Data Provider je Netz dargestellt. Tatsächlich sind deutlich mehr Teilnehmer je Netz zu erwarten - allein die Melderegister machen im Mittel mehrere Hundert je Bundesland aus. Zudem gibt es auch mehr als nur zwei Netze. Für eine einzelne Nachrichtenübermittlung spielen jedoch nur zwei Netze eine Rolle: Das des Data Consumer und das des Data Providers.

Data Consumer und Data Provider sind über Anschlussknoten an die Transportinfrastruktur angeschlossen. Die Anschlussknoten auf der Seite des Data Consumer übermitteln Nachweisabrufe an einen Transportknoten in ihrem Netz. Diese Transportknoten sind an zentraler Stelle im jeweiligen Netz angesiedelt und von allen Teilnehmern innerhalb des Netzes erreichbar. Sie leiten die Nachrichten dann zum Transportknoten auf der Seite des Data Providers weiter. Dabei nutzen sie ein Medium für den Netzübergang, das entweder eine direkte Kopplung zwischen den Netzen oder ein drittes Netz, das die erstgenannten miteinander verbindet, sein kann. Der Transportknoten des Data Providers kann alle Anschlussknoten der Data Provider in seinem Netz erreichen und übermittelt die Nachricht an den geeigneten Anschlussknoten. Dort kann der Data Provider die Nachricht abholen, oder der Anschlussknoten leitet den Nachweisabruf aktiv an den Data Provider weiter.

Die Anschlussknoten sind unmittelbar im Verantwortungsbereich des Data Consumer bzw. Data Provider angesiedelt, in der Regel in derselben Betriebsumgebung oder gar auf derselben Maschine. Sie können daher als Teil des Data Consumer oder Data Provider betrachtet werden und Teile von deren Aufgaben in deren Auftrag übernehmen, insbesondere die Ende-zu-Ende-Verschlüsselung. Die Kommunikation zwischen Data Consumer oder Data Provider und deren Anschlussknoten erfolgt über ein Anschlussprotokoll, das auf Einfachheit ausgelegt ist und Details der Transportinfrastruktur so weit wie möglich vor diesen verbirgt.

Transportprotokolle werden zwischen Anschlussknoten, zwischen Anschlussknoten und Transportknoten sowie zwischen jeweils zwei Transportknoten eingesetzt. Diese sind in der Regel deutlich flexibler, aber auch komplexer als die Anschlussprotokolle, da sie beispielsweise neben den Fachdaten auch Informationen zur Ansteuerung der Transportknoten übermitteln müssen.

Die wesentlichen Bausteine des Modells sind:

Tab. 6: Bausteine der Transportinfrastruktur

8.7.1.2 Topologien

Das abstrakte Architekturmodell sieht vor, dass sich vier Knoten (Anschlussknoten DC, Transportknoten DC, Transportknoten DP und Anschlussknoten DP) auf der Strecke zwischen Data Consumer und Data Provider befinden. In den untersuchten Transportinfrastrukturen im Anhang wird diese Topologie jedoch nicht verwendet. Stattdessen nutzen sie nur die Teile, die für ihre spezifischen Anforderungen erforderlich sind. Im Folgenden werden verschiedene Topologien betrachtet und miteinander verglichen.

8.7.1.2.1 Nur Anschlussknoten, keine Transportknoten (siehe auch X-Road)

Transportknoten haben im abstrakten Architekturmodell vor allem die Aufgabe, Nachrichten über die Netzstrukturen zu routen. Verzichtet man auf Transportknoten, muss das darunterliegende Transportmedium das Routing der Nachrichten allein bewältigen. Dafür benötigt man ein nicht segmentiertes, alle Behörden überspannendes Netz wie das Internet. So hat bspw. X-Road von vornherein den Ansatz verfolgt, den physischen Nachrichtentransport über das Internet zu realisieren. Es verfügt daher nicht über Transportknoten und wäre nicht in der Lage, Nachrichten durch die deutschen Verwaltungsnetze zu routen.

Transportknoten verursachen hohe Betriebsaufwände, da in jedem beteiligten Netzsegment mindestens ein Transportknoten mit hoher Verfügbarkeit betrieben werden muss. Sie sind jedoch für ein Routing über segmentierte Netze unverzichtbar, wie am Beispiel des EU-OOTS zu sehen ist: Für jeden Mitgliedsstaat (MS) wird ein eigener AS4 Access Point vorgesehen, der den Datenverkehr aus dem MS und in den MS kanalisiert und durch die Verbindung zu den AS4 Access Points der anderen MS den grenzüberschreitenden Datenverkehr ermöglicht.

Bei Verzicht auf Transportknoten muss nur noch sehr wenig Infrastruktur für den Transport betrieben werden. Da die Anschlussknoten in der Regel durch die Teilnehmer selbst betrieben werden, sind nur die zentralen Dienste durch eine dritte Stelle zu betreiben. Der Aufbau der über die Netze verteilten Transportknoten entfällt.

8.7.1.2.2 Nur Transportknoten, keine Anschlussknoten (siehe auch AS4 eDelivery)

Anschlussknoten vereinfachen den Zugang zur Transportinfrastruktur. Verzichtet man auf sie, bedeutet das zunächst nur, dass jeder Teilnehmer die Anschlussbedingungen des Transports selbst vollumfänglich erfüllen muss. Das ist komplex und fehlerträchtig. Insbesondere der Umgang mit Verschlüsselung und Zertifikaten birgt Risiken, wenn dies von sehr vielen Teilnehmern selbst realisiert werden muss. Aus diesem Grund wurde die OSCI Infrastruktur, die ursprünglich ebenfalls ohne Anschlussknoten aufgebaut wurde, um Anschlussknoten auf Basis der XTA Spezifikation erweitert.

Eine Alternative zu den Anschlussknoten sind Client-Bibliotheken, wie sie beispielsweise für OSCI schon lange im Einsatz sind. Diese Bibliotheken bieten vordefinierte Funktionen und Methoden, die den Zugang zur Transportinfrastruktur erleichtern, erfordern jedoch eine direkte Integration in den Programmcode des Nutzers. Bei der Verwendung einer Client-Bibliothek ist man auf die Aktualisierungen und Wartung dieser Bibliothek durch den Anbieter angewiesen und stark von der Implementierungstechnologie abhängig, da sie sprachspezifisch sind. Ein Beispiel hierfür ist die OSCI-Bibliothek, die nur in Java und .NET verfügbar ist. In modernen Architekturen wird vermehrt auf eigenständig lauffähige modulare Services gesetzt, was auch im Falle der Anschlussknoten der Fall ist. Diese modularen Services kapseln die Funktionen und Methoden für den Zugang zur Transportinfrastruktur und sind über eine interoperable APIs ansprechbar.

Auch das EU-OOTS sieht auf den ersten Blick nur Transportknoten vor, das ist allerdings nicht ganz zutreffend: Die Anschlüsse der Teilnehmer schreibt das EU-OOTS nicht vor, da es diese in der Zuständigkeit der Mitgliedsstaaten sieht. Vorgeschrieben werden nur die AS4-Strecken für den grenzüberschreitenden Datenverkehr. Inländischer Datenverkehr und die Anbindung der Teilnehmer bleibt den nationalen Transportmechanismen überlassen. Dort sind Anschlussknoten also durchaus zu erwarten.

Bei der Kosten-/Nutzenbewertung von Anschlussknoten ist zu beachten, dass zwar sehr viele Anschlussknoten betrieben werden müssen, diese jedoch typischerweise von den Betreibern der Data Consumer bzw. Data Provider mit betrieben werden - ein in modernen serviceorientierten Architekturen gängiger Ansatz. Der Verzicht auf Anschlussknoten bringt hingegen nur scheinbar eine Vereinfachung. Zwar entfallen sehr viele Knoten, deren Aufgaben verschwinden damit jedoch nicht - sie werden zu den Teilnehmern verschoben undmüssen dort immer wieder neu umgesetzt werden. Dadurch bleiben Synergien ungenutzt und das Risiko fehlerhafter Implementierungen steigt mit jedem Teilnehmer.

8.7.1.2.3 Zentraler Transportknoten (siehe auch FIT-Connect)

Ein einzelner Transportknoten, über den alle Verbindungen laufen, kann bereits fast alle Anforderungen an den Transport erfüllen. Mittels Protokollierung oder Notifikation kann er Nachvollziehbarkeit und Nichtabstreitbarkeit gewährleisten, empfangene Nachrichten zwischenspeichern und durch Initiativumkehr das n*m Verbindungen Problem (siehe auch NOOTS-413) lösen. Nicht lösen kann es jedoch das Routing über segmentierte Netze: Der Zentralknoten benötigt weiterhin Verbindungen zu allen Teilnehmern über Netzsegmentgrenzen hinweg. Das ist insbesondere problematisch, wenn mehrere Netzsegmente überbrückt werden müssen. Durch den Verzichtet auf Anschlussknoten sind die Teilnehmer zudem mit der Komplexität der Ende-zu-Ende Verschlüsselung und der Zertifikatsverwaltung konfrontiert.

Dieser Ansatz kommt bei FIT-Connect zum Einsatz. Allerdings nutzt FIT-Connect das Internet, sodass die Problematik segmentierter Verwaltungsnetze nur dann eine Rolle spielt, wenn Teilnehmer nicht über das Internet erreichbar sind.

8.7.1.2.4 Weder Anschlussknoten noch Transportknoten (direkte Punkt-zu-Punkt Kommunikation)

Wird auf beide Arten von Knoten verzichtet, entfällt die Transportinfrastruktur vollständig. Sie kann demnach auch keinerlei Anforderungen erfüllen. Dieser Ansatz wird hier betrachtet, weil diese direkte Nutzung des Internets aus privaten oder privatwirtschaftlichen Nutzungsszenarien gut bekannt ist. Dabei werden Dienste im Internet öffentlich zur Verfügung gestellt. Eine Zustellung über segmentierte Netze ist damit allerdings nicht möglich, ebenso wenig eine Erreichbarkeit nicht-öffentlicher Dienste. Das können die Data Provider zwar durch gängige DMZ und Reverse-Proxy Lösungen selbst implementieren. Dadurch entstehen jedoch sehr viele individuelle Lösungen,in denen Sicherheit nur noch schwer gewährleistet werden kann. Auch die Nachvollziehbarkeit kann in diesen Szenarien nur durch die Dienstenutzer oder Diensteanbieter selbst realisiert werden. Für das NOOTS wird dieser Ansatz nicht weiterverfolgt.

8.7.1.2.5 Mischformen (OSCI/XTA)

In der deutschen Verwaltung kommen historisch bedingt unterschiedliche Topologien zum Einsatz:

Tab. 7: Mischformen (OSCI/XTA)

Theoretisch mögliche weitere Topologien, wie die Kaskadierung mehrerer OSCI Intermediäre, werden technisch nicht unterstützt.

Das 4-Corner-Modell ist ein abstraktes Delegationsmodell in dem zwei Teilnehmer (Corner 1 und 4) miteinander interagieren, indem sie sich Dritter (Corner 2 und 3) bedienen, um Teile dieser Interaktion für sie abzuwickeln. Das Modell wird häufig für Finanztransaktionen verwendet. Die Corner 2 und 3 werden dann von Finanzdienstleistern übernommen. In der Registermodernisierung wird das Modell zur Beschreibung der Nachrichtenkommunikation über dritte Stellen genutzt (§ 7 Abs. 2 IDNrG). Allerdings ist unklar, welche Aufgaben die Corner 2 und 3 konkret übernehmen sollen. Davon hängt jedoch ab, wo diese Corner in der Architektur verortet sind. Drei der im Rahmen der Konzeption betrachteten Transportinfrastrukturen implementieren nach eigener Aussage das 4-Corner-Modell, sehen aber völlig unterschiedliche Aufgaben bei den Cornern 2 und 3 vor. Dieses Dokument nutzt daher die konkreten Begriffe des abstrakten Architekturmodells anstelle der Corner. Dabei können sowohl die Anschlussknoten als auch die Transportknoten als Corner 2 und 3 interpretiert werden.

8.7.1.3 4-Corner-Modell und V-Modell

Abb. 8: Überblick über das 4-Corner-Modell

Die folgende Abbildung schlägt ein V-Modell des Nachrichtentransports als Erweiterung des 4-Corner-Modells vor. Dabei werden unterschiedliche Arten der Delegation unterschieden und in Ebenen dargestellt. Je nachdem welche Aufgabe delegiert werden soll, ist eine andere Ebene dafür geeignet. So können Infrastrukturkomponenten der Ebene 1, wie die Anschlussknoten, die Ende-zu-Ende Verschlüsselung für die Teilnehmer übernehmen, jedoch keine Steuerung des Nachrichtenroutings. Für Infrastrukturkomponenten der Ebene 2, wie die Transportknoten, gilt genau das Gegenteil. Komponenten der Ebene 3, wie die Vermittlungsstellen, arbeiten nicht im Auftragsverhältnis der Teilnehmer und eignen sich daher als einzige für unabhängige Überwachungsaufgaben. Das macht deutlich, warum eine Delegation an nur eine weitere Ebene, wie sie im 4-Corner-Modell vorgesehen ist, in der Praxis oft nichtausreicht.

Abb. 9: Ein V-Modell des Nachrichtentransports

8.7.1.4 Nachrichtenaustauschmuster

Im Kapitel "Nachrichtenaustauschmuster" der High-Level-Architektur (AD-NOOTS-03) werden die unterstützten NOOTS-Nachrichtenaustauschmuster aus der Perspektive von Data Consumer und Data Provider über das Anschlussprotokoll der Anschlussknoten erläutert. Dabei wird ausschließlich das synchrone Request-Response-Muster für die Abbildung synchroner und asynchroner Nachweisabrufe über NOOTS verwendet. Aufgrund der direkten Unterstützung dieses Musters durch das Transportprotokoll zwischen den Anschlussknoten kann eine durchgängige synchrone Kommunikation zwischen Data Consumer und Data Provider gewährleistet werden, was auch die Fehlerbehandlung vereinfacht. Es sei darauf hingewiesen, dass das Kommunikationsmodell aktiver Empfänger des Anschlussprotokolls für Data Provider in diesem Kontext Besonderheiten aufweist, die im Kapitel "Aktiver Empfänger (Initiativumkehr)" erläutert werden.

Abb. 10: Synchrones Request-Response Muster für Anschluss-und Transportprotokoll

Wenn das Transportprotokoll das Request-Response-Muster nicht unterstützt, kann dieses durch den Austausch zweier separater Nachrichten zwischen dem Data Consumer und dem Data Provider nachgebildet werden. Der Data Consumer oder dessen Anschlussknoten muss die Korrelation dieser Nachrichten anhand vereinbarter Merkmale herstellen und die Verarbeitung der Antwortnachrichten explizit steuern. Dabei besteht grundsätzlich das Risiko, dass Angriffe auf den Data Consumer erfolgen können, indem Antworten auf nicht gestellte Anfragen gesendet werden. Um solche Angriffe zu verhindern, sind entsprechende Gegenmaßnahmen erforderlich. Daher ist dieser Ansatz gangbar, aber nachteilhaft. Insbesondere eDelivery AS4 unterstützt nur unkorrelierte Nachrichten. Ergänzend sei erwähnt, dass das häufig verwendete Publish-Subscribe-Muster, welches zur Verteilung von Informationen (Publish) an eine Gruppe von Interessenten (Subscribern) dient, im NOOTS-Kontext keine Rolle spielt und daher hier nicht weiter behandelt wird.

8.7.2 Baustein NOOTS Sichere Anschlussknoten (SAK)

Ein Sicherer Anschlussknoten (SAK) ist eine NOOTS-Komponente, die den Anschlussknoten aus dem Abstrakten Architekturmodell umsetzt. Der Hauptzweck des Sicheren Anschlussknotens besteht darin, Nachweisanfragen zwischen den NOOTS-Teilnehmern, Data Consumer und Data Provider, zu vermitteln. Die Motivation und der Nutzen eines Sicheren Anschlussknotens ergeben sich aus den Designentscheidungen im Kapitel „Lösungsstrategie“.

Nachnutzung des SAK

Die hier vorgestellte Transportinfrastruktur ist primär für den Austausch von Nachweisen zwischen den Sicheren Anschlussknoten der Data Consumer und Data Provider konzipiert. Nach ihrer Implementierung kann sie jedoch, sofern geeignet, auch für andere Kommunikationsbeziehungen im NOOTS und im Rahmen der Registermodernisierung verwendet werden, um von einem einfachen und sicheren Transportmechanismus zu profitieren. Daher kann die Transportinfrastruktur neben dem Nachweisabruf auch die folgenden Kommunikationsbeziehungen unterstützen:

Tab. 8: Kommunikationsbeziehungen für SAK Nachnutzung

Im Gegensatz zum Nachweisabruf zwischen Data Consumer und Data Provider erfolgt bei den genannten Kommunikationsbeziehungen keine abstrakte Berechtigungsprüfung gemäß IDNrG. Das NOOTS-Transportprotokoll gewährleistet für die Kommunikation zwischen den SAKs die gegenseitige Authentifizierung der Kommunikationspartner mittels mutual TLS und Zertifikaten. Abhängig von der Kommunikationsbeziehung erfolgt zusätzlich die Autorisierung des Zugriffs auf eine NOOTS-Komponente über Zugriffstoken des IAM für Behörden. Die Anwendungsfälle für den Abruf von Registerdaten für den Registerzensus sowie für wissenschaftliche Zwecke sind in der aktuellen Auflistung noch nicht berücksichtigt.

8.7.2.1 Systemkontext SAK beim Nachweisabruf

Der SAK ist eine dezentrale Komponente des NOOTS gemäß Ebene 1 des V-Modells, die den Transport zwischen den NOOTS-Teilnehmern Data Consumer und Data Provider sowie zu allen NOOTS-Komponenten kapselt. Sowohl der Data Consumer als auch der Data Provider kommunizieren ausschließlich mit dem SAK, was bedeutet, dass der Einsatz des SAKs für die NOOTS-Teilnehmer verpflichtend ist. Das Anschlussprotokoll, das als API realisiert ist, bedient alle erforderlichen Interaktionen zwischen Data Consumer und Data Provider, ohne fest an einen bestimmten Transportstandard gebunden zu sein. In dieser Hinsicht fungiert der SAK als stabile Fassade vor dem NOOTS, die die Kommunikation mit anderen Teilnehmersystemen oder den NOOTS-Komponenten delegiert und somit die Komplexität der technischen Anbindung an das NOOTS maximal reduziert. Die SAKs haben Zugriff auf die übermittelten Daten und unterstützen den Teilnehmer bei der Sicherstellung von Vertraulichkeit, Integrität und Authentizität beim Transport der Daten. Aufgrund ihrer Nähe zum Teilnehmer eignen sie sich als Endpunkt einer Ende-zu-Ende-Verschlüsselung zwischen den Teilnehmern.

Abb. 11: Systemkontext SAK beim Nachweisabruf

Im Folgenden werden die Kommunikationsbeziehungen für einen Nachweisabruf zwischen den NOOTS-Teilnehmern und den NOOTS-Komponenten tabellarisch aufgeführt. Der Datenfluss wird im Detail im Kapitel "Laufzeitsicht" dargestellt.

Tab. 9: Systemkontext SAK beim Nachweisabruf

8.7.2.2 Software-Architektur

Die Softwarearchitektur des SAK orientiert sich an den Prinzipien der Fünfzehn-Faktoren-App für Microservices, Container-Ansätze und Cloud-native Services und berücksichtigt dabei eine Reihe von Rahmenbedingungen:

• Technologie-Stack: leichtgewichtig, modern, bewährt und zukunftsfähig,
• Betrieb: auf weit verbreiteten klassischen Server-Plattformen (Linux und Windows auf x86) sowie in einer DVC-konformen Cloud,
• Skalierbarkeit: für unterschiedliche Lastanforderungen, sowohl vertikal als Single-Instance als auch horizontal in Cluster-Umgebungen,
• Flexible Integration: mit verschiedenen zentralen Infrastrukturen für Überwachung (Protokollierung, Monitoring und verteilte Nachrichtenverfolgung),
• Verwaltung: mehrerer NOOTS-Teilnehmer innerhalb eines SAK,
• Optionale datenbankbasierte Persistenz: Einfache Betriebsfähigkeit des SAK auch in unsicheren Netzwerkbereichen, ohne Abhängigkeiten von Datenbankdiensten.

Die Software-Architektur des SAK setzt sich aus verschiedenen funktionalen Services zusammen, wie sie in der folgenden Abbildung veranschaulicht werden. Im Rahmen der technischen Konzeption wird festgelegt, ob und in welchem Umfang die funktionalen Services durch einen einzigen SAK oder durch mehrere SAKs mit einem Funktionsumfang, der auf den jeweiligen Einsatzzweck abgestimmt ist, abgebildet werden.

Abb. 12: Übersicht der funktionalen SAK-Services

Im Folgenden wird der Zweck der funktionalenSAK-Services kurz erläutert.

8.7.2.2.0.1 Sicherer Transport

Dieser Service implementiert den API-Endpunkt für das verwendete Transportprotokoll, über das Nachrichten und Daten zwischen den SAKs unter Berücksichtigung der Schutzziele Vertraulichkeit, Integrität und Authentizität ausgetauscht werden. Die SAKs bilden die jeweiligen Endpunkte der Ende-zu-Ende-Verschlüsselung. Folgende APIs werden für den Sicheren Transport bereitgestellt:

• TransportClient-API: Aufruf von Operationen der SAKs der NOOTS-Komponenten
• TransportServer-API: Bereitstellung von Operationen der SAKs der NOOTS-Komponenten.

→ Weiterführende Informationen finden sich im Kapitel Baustein Transportprotokoll.

8.7.2.2.0.2 Sicherer Anschluss

Der Sichere Anschluss Service implementiert das synchrone Anschlussprotokoll für den Datenaustausch von Nachweisen und anderen Nachrichten und stellt folgende APIs für die Anbindung an das NOOTS bereit:

• Consumer-API für den Data Consumer,
• Provider-API (passiverEmpfänger)für den Data Provider und alternativ
• Provider-API (aktiver Empfänger)für den Data Provider.

→ Weiterführende Informationen finden sich im Kapitel Baustein Anschlussprotokoll.

8.7.2.2.0.3 Zugriffsberechtigung

Um die Rechtmäßigkeit der Übermittlung zu gewährleisten, ist abhängig von der Kommunikationsbeziehung der Zugriff auf NOOTS-Komponenten nur mit einem gültigen Zugriffstoken aus dem Identity and Access Management (IAM) für Behörden möglich. Der SAK führt anhand des Zugriffstokens die folgenden Prüfungen zur Sicherstellung der Gültigkeit durch:

1. Vorhanden: Zugriffstoken liegt als "Bearer Token" im HTTP-Header vor.
2. Signatur: Signatur des Zugriffstokens wird mit dem öffentlichen Schlüssel von IAM für Behörden überprüft, um die Unversehrtheit und Herkunft des Tokens sicherzustellen. Dazu muss das Zertifikat von IAM für Behörden vorhanden sein.
3. Inhalte: Ablaufzeit darf nicht überschritten sein.
4. Berechtigungen: Berechtigung zum Zugriff auf die NOOTS-Komponente ist vorhanden.

Je nach Ergebnis der Token-Prüfung stellt die integrierte Zugriffsberechtigungsprüfung im SAK sicher, dass:

• beim Senden einer Anfrage: wenn für die Ausführung einer API-Operation im SAK ein gültiges Zugriffstoken erforderlich ist und kein gültiges Zugriffstoken vorliegt, wird keine Anfrage an eine NOOTS-Komponente oder Teilnehmer gesendet, einschließlich einer Nachweisanfrage an den SAK des Data Providers.
• beim Empfangen einer Anfrage: wenn für denEmpfang einer Anfrage ein gültiges Zugriffstoken erforderlich ist und kein gültiges Zugriffstoken vorliegt, wird die Anfrage abgelehnt.

→ Weitere Details zu den Zugriffstoken sind im AD-NOOTS Konzept IAM für Behörden (AD-NOOTS-05) zu finden, während der Datenfluss zwischen den SAKs und den NOOTS-Komponenten im Kapitel Laufzeitsicht behandelt wird.

8.7.2.2.0.4 Abstrakte Berechtigung

Um die abstrakte Rechtmäßigkeit der Übermittlung bei Nutzung einer Identifikationsnummer im Nachweisabruf gemäß § 7 (2) und § 12 (4) IDNrG sicherzustellen, ist im SAK die Prüfung der abstrakten Berechtigung auf Basis eines Abruftokens für die NOOTS-Teilnehmer, Data Consumer und Data Provider integriert:

• SAK des Data Consumers:
  Der SAK fordert für die abstrakte Berechtigung gemäß IDNrG ein Abruftoken von der NOOTS-Komponente „Vermittlungsstelle“ an. Bei erfolgreicher Ausstellung wird das Abruftoken in die XNachweis-Anfrage integriert, und die erweiterte XNachweis-Anfrage wird an den SAK des Data Providers gesendet. Sollte das Abruftoken nicht ausgestellt werden können, bricht der SAK den Nachweisabruf mit einer Fehlermeldung ab.
  Anmerkung: Der SAK des Data Consumers fordert auch bei Nachweisabrufen ohne Identifikationsnummer ein Abruftoken von der NOOTS-Komponente „Vermittlungsstelle“ an.
  
• SAK des Data Providers:
  Der SAK überprüft bei jeder eingehenden Nachweisanfrage, unabhängig davon, ob eine Identifikationsnummer im Nachweisabruf enthalten ist, die Gültigkeit des Abruftokens sowie die Übereinstimmung seiner Daten mit dem Inhalt der Nachweisanfrage. Bei erfolgreicher Überprüfung leitet der SAK die Nachweisanfrage an den Data Provider weiter; andernfalls wird sie abgelehnt.
• SAK der Intermediären Plattform (IP)
  Der SAK in der Rolle als Data Consumer behandelt Nachweisabrufe von Data Providers analog zu Nachweisabrufen ohne Identifikationsnummer des SAK des Data Consumers. Bei der IP in der Rolle als Data Provider verläuft der Abruf von EU-Nachweisen identisch zum SAK des Data Providers.

Im SAK des Data Consumers und Data Providers werden folgende Prüfungen anhand des Abruftokens durchgeführt:

1. Vorhanden: Abruftoken ist in der XNachweis-Anfrage vorhanden.
2. Signatur: Signatur wird mit dem öffentlichen Schlüssel der Vermittlungsstelle überprüft, um die Unversehrtheit und Herkunft des Tokens sicherzustellen. Dazu muss das Zertifikat der Vermittlungsstelle vorhanden sein.
3. Inhalte: Ablaufzeit darf nicht überschritten sein, und es muss ein Datenabgleich aller Inhalte des Abruftokens mit den Inhalten der XNachweis-Anfrage durchgeführt werden (siehe auch Konzept Vermittlungsstelle (AD-NOOTS-08): Kapitel "Abruftoken")
4. Hash-Wert: Hash-Wert für die XNachweis-Anfrage wird berechnet und mit dem Hashwert aus dem Abruftoken verglichen. Falls der Vergleich negativ ausfällt, ist das Token ungültig.

→ Zusätzliche Details zur abstrakten Berechtigungsprüfung sind im AD-NOOTS Konzept Vermittlungsstelle (AD-NOOTS-08) verfügbar.

8.7.2.2.0.5 Validierung

Der SAK überprüft die Konformität der XNachweis-Anfrage und der Antwort mit den unterstützten Versionen der XNachweis-Spezifikation sowie das Vorhandensein aller erforderlichen Informationen. Darüber hinaus werden Datenkonsistenzprüfungen zwischen den gesicherten Daten im Zugriffstoken aus dem IAM für Behörden und dem Abruftoken aus der Vermittlungsstelle durchgeführt.

→ Weiterführende Informationen finden sich in derXNachweis-Spezifikation (XS-01).

8.7.2.2.0.6 Management

Im SAK müssen die Konfigurationsdaten eines oder mehrerer Mandanten verwaltet werden. Mandanten sind hierbei die NOOTS-Komponenten oder NOOTS-Teilnehmer (Data Consumer und Data Provider). Die Konfigurationsdaten eines Mandanten umfassen Daten für das Anschlussprotokoll und das Transportprotokoll, die Verwaltung von Zertifikaten sowie Konfigurationen für die Protokollierung, das Monitoring und die verteilte Nachrichtenverfolgung.

8.7.2.2.0.7 Routing

Der SAK fungiert als Vermittler für den Transport zwischen den NOOTS-Teilnehmern Data Consumer und Data Provider sowie allen anderen NOOTS-Komponenten. Das bedeutet, dass alle direkten Aufrufe zu NOOTS-Komponenten vom SAK initiiert werden.

Tab. 10: Weiterleitung in den SAKs

Die SAKs der anderen NOOTS-Komponenten leiten die entsprechenden Anfragen direkt an die jeweilige NOOTS-Komponente weiter.

Derzeit bestehen keine Anforderungen an eine weiterführende Routing-Logik. Zum Beispiel kann für einen Mandanten im SAK im Kommunikationsmodell passiver Empfänger die Endpunkt-URL für die Provider-API des Anschlussprotokolls konfiguriert werden, an die die Nachweisanfrage zugestellt wird. Ein Routing an verschiedene Endpunkt-URLs basierend auf Daten aus der Nachweisanfrage ist derzeit nicht vorgesehen.

→ Zusätzliche Informationen zum Anschlussprotokoll sind im Kapitel Baustein Anschlussprotokoll zu finden, während der Datenfluss zwischen den SAKs und den NOOTS-Komponenten im Kapitel Kapitel Laufzeitsicht behandelt wird.

8.7.2.2.0.8 Transformation

Angesichts der hohen Anzahl von NOOTS-Teilnehmern ist es entscheidend, dass das Anschlussprotokoll nicht nur interoperabel, sondern auch robust gegenüber Veränderungen ist. Es soll möglichst unempfindlich gegenüber Änderungen in der Transportinfrastruktur oder bei NOOTS-Komponenten sein. Der SAK wandelt die Daten aus dem Anschlussprotokoll in API-Aufrufe der Ziel-NOOTS-Komponenten um und ergänzt sie gegebenenfalls vor dem Aufruf einer NOOTS-Komponente mit eigenen Konfigurationsdaten oder ermittelten Informationen wie beispielsweise dem Abruftoken.

8.7.2.2.0.9 Teil-Orchestrierung

Die Hauptaufgabe des SAK besteht nicht in der Orchestrierung der verschiedenen Interaktionen mit den NOOTS-Komponenten während eines Nachweisabrufs durch den Data Consumer. In diesem Punkt unterscheidet sich der SAK von Adapterimplementierungen, die die Koordination einzelner Interaktionsschritte übernehmen. Der SAK verfügt lediglich über integrierte obligatorische Funktionen zur Gewährleistung der Rechtmäßigkeit der Übermittlung und zur Kapselung des Transportprotokolls. Diese umfassen:

• die Überprüfung der abstrakten Berechtigung (siehe SAK-Service Abstrakte Berechtigung) und
• die Ermittlung der technischen Verbindungsparameter des NOOTS-Dienstes, wie etwa des Data Providers, anhand einer ServiceID. Die NOOTS-Teilnehmer benötigen lediglich die ServiceID des NOOTS-Dienstes. Der SAK setzt diese ServiceID in konkrete Verbindungsparameter des Transportprotokolls um. Dieser Mechanismus ermöglicht Änderungen an den Verbindungsparametern ohne Auswirkungen auf die NOOTS-Teilnehmer und verhindert eine fehlerhafte oder missbräuchliche Nutzung der Verbindungsparameter durch die NOOTS-Teilnehmer, wodurch die Kapselung des Transportprotokolls unterstützt wird.

→ Weiterführende Informationen finden sich im Kapitel Laufzeitsicht im Kapitel "8.2.4 Schritt 4: Consumer-API::getNachweis".

8.7.2.2.0.10 Monitoring

Der Monitoring-Service bietet Funktionen zur Überwachung und Verfügbarkeitsprüfung des Systemzustands des SAK. Die automatische Verfügbarkeitsprüfung kann über folgende "Health-Checks" erfolgen:

• "Liveness Probe": überprüft, ob der SAK betriebsbereit ist,
• "Readiness Probe": stellt fest, ob der SAK bereit ist, Anfragen anzunehmen.

Der Systemzustand des SAK kann über den Endpunkt der Metrik-API abgerufen werden und lässt sich mit gängigen zentralen Monitoring-Infrastrukturen wie Prometheus/ Grafana visualisieren. Über die Metrik-API ist ebenfalls die installierte SAK-Version abrufbar.

8.7.2.2.0.11 Verteilte Nachrichtenverfolgung

In der verteilten föderalen IT-Landschaft des NOOTS werden Nachweis- und Serviceanfragen nicht nur von einer NOOTS-Komponente beantwortet, sondern von verschiedenen verteilten NOOTS-Komponenten bearbeitet. Häufig sind auch Third-Party-Komponenten Bestandteil der Verarbeitungskette. Um das Verhalten der Anfragen über Komponentengrenzen hinweg nachverfolgen zu können, ist eine verteilte Nachrichtenverfolgung auf Anwendungsebene auf Basis eines anerkannten offenen Standards erforderlich.

→ siehe auch "Anhang B - Nachrichtenverfolgung mit OpenTelemetry"

8.7.2.2.0.12 Protokollierung

Die effiziente Lokalisierung und Analyse von Fehlersituationen im verteilten föderalen NOOTS-Ökosystem und mit seiner Integration in das EU-OOTS der EU-Mitgliedstaaten stellen eine bedeutende Herausforderung dar. Hierbei kommt dem SAK als Vermittler sämtlicher Kommunikationsbeziehungen im NOOTS eine Schlüsselrolle zu. Daher ist es notwendig, dass der SAK nicht nur technische Anfragen protokolliert, sondern auch ein Audit-Protokoll für die Erfassung von fachlichen Daten und Änderungen am Systemstatus oder der Konfiguration führt. Die Protokollinformationen müssen dabei effizient anhand von Suchparametern von berechtigten Personen analysiert werden können.

Die Speicherung der Protokollinformationen kann differenziert und flexibel über eine Konfiguration im SAK gesteuert werden, zum Beispiel durch die Auswahl von Datei, Datenbank oder Konsole für Container-Umgebungen. Optional besteht die Möglichkeit, Datenbanken für die Speicherung von Informationen des Audit-Protokolls einzubinden. In der Praxis haben sich zentrale Loganalyse-Plattformen wie Loki/ Grafana oder Elasticsearch, Fluentd und Kibana (EFK) bewährt, um Protokollinformationen zu analysieren.

Technisches Protokoll

Der SAK protokolliert bei jeder eingehenden Anfrage Informationen zur Anfrage, zur Antwort oder zur Fehlerursache. Darüber hinaus werden auch Metainformationen wie der Schweregrad, Zeitpunkt der Anfrage und die Dauer der Bearbeitung der Anfrage protokolliert. Das technische Protokoll enthält keine personenbezogenen oder personenbeziehbaren Daten gemäß DSGVO.

Audit-Protokoll

Das Audit-Protokoll protokolliert fachlich- und sicherheitsrelevante Ereignisse, wie beispielsweise Token-Anforderungen, abgelehnte Token-Ausstellungen oder Nachweisabrufe mit ungültigem Token. Dabei werden keinerlei personenbezogene Daten im Audit-Protokoll gespeichert. Die Einträge des Audit-Protokolls müssen für einen Zeitraum von zwei Jahren aufbewahrt und anschließend gelöscht werden.

8.7.2.3 Übersicht der SAK-APIs

In der folgenden Tabelle werden alle APIs des SAK aufgelistet. Die Nutzung der Consumer-API und Provider-API wird im Kapitel „Laufzeitsicht“ am Beispiel im Detail beschrieben.

Tab. 11: Übersicht der SAK-APIs

Legende API-Typ:

• Öffentlich: Die API ist öffentlich zugänglich für die NOOTS-Teilnehmer und kann von diesen verwendet werden.
• Intern: Interne APIs dienen ausschließlich der Kommunikation zwischen NOOTS-Komponenten wie den SAKs und sind daher für NOOTS-Teilnehmer nicht zugänglich.
• Admin: Die API ist ausschließlich für die Administration und Überwachung des SAK vorgesehen.

8.7.2.4 Überblick Zertifikate für den SAK

Elektronische Zertifikate im SAK erfüllen mehrere Funktionen, darunter die Ende-zu-Ende-Verschlüsselung und die Authentifizierung des SAK als Kommunikationspartner. Die Anforderungen an diese Zertifikate richten sich nach den folgenden BSI-Richtlinien:

• TR-02103: X.509 Zertifikate und Zertifizierungspfadvalidierung
  • Kapitel "4 TLS Server Zertifikate"
  • Kapitel "5 TLS Client Zertifikate"
• TR-03107-1: Elektronische Identitäten und Vertrauensdienste im E-Government
  • Kapitel "10.6 TLS-Verbindung und -Zertifikate"

Die folgende Tabelle führt die verpflichtenden und optionalen Zertifikate auf.

Tab. 12: Relevante Zertifikate für SAK und NOOTS-Teilnehmer

8.7.2.5 Deployment-Sicht

NOOTS stellt die Software für den Sicheren Anschlussknoten bereit, der dezentral und in der Nähe des NOOTS-Teilnehmers oder der NOOTS-Komponente betrieben werden muss. Zur Überwachung des Systemzustandes der SAK-Instanzen kann die Health-Check-API der SAK-Monitoring-Komponente verwendet werden. Der SAK kann in verschiedenen Deployment-Szenarien eingesetzt werden.

8.7.2.5.1 Standalone Deployment

In Szenarien, in denen die Verfügbarkeit keine kritische Rolle spielt, wie beispielsweise in Entwicklungs- und Testumgebungen, kann eine einzelne SAK-Instanz eingesetzt werden. Diese wird entweder als ausführbare Java-Archive (JAR) Anwendung fürklassische Server-Plattformen oder alternativ als Container (Docker-Image) für eine DVC-konformen Containerumgebung bereitgestellt.

Klassische Server-Plattformen

Das Deployment der SAK-Anwendung erfolgt auf weit verbreiteten Server-Plattformen auf Basis von Linux und Windows mit einer vorinstallierten Java-Runtime. Die SAK-Anwendung kann entweder direkt als ausführbares Java-Archive (JAR) oder alternativ eingebettet in einem Applikationsserver (Tomcat) betrieben werden.

DVC-konforme Containerumgebung

Das Deployment der SAK-Anwendung in einer DVC-konformen Containerumgebung erfolgt mithilfe des bereitgestellten Containers (Docker-Image) und eines Helm-Charts.

8.7.2.5.2 Redundantes Deployment

Die Verfügbarkeit des SAK kann durch den Einsatz von Redundanz erhöht werden. Mithilfe einer Lastverteilungskomponente (Loadbalancer) auf TCP-Ebene können mehrere SAK-Instanzen parallel betrieben werden. Zur Sicherstellung der Ende-zu-Ende-Verschlüsselung auf OSI-Schicht 5: Sitzungsschichtdarf die TLS-Verbindung nicht an der Lastverteilungskomponente terminiert werden. Häufig verfügen Lastverteilungskomponenten über einen "Rate Limiting"-Mechanismus, um die Anzahl gleichzeitiger Anfragen zu begrenzen. Mithilfe dieser Funktion kann die Komponente die Anzahl der Anfragen entsprechend den festgelegten Limits überwachen und steuern, wodurch Überlastungen vermieden werden.

Klassische Server-Plattformen

Für die SAK-Anwendung wird keine Lastverteilungskomponente durch NOOTS bereitgestellt. Es können jedoch beliebige Lastverteilungskomponenten wie beispielsweise HAProxy, NGINX oder Hardware-Loadbalancer eingesetzt werden, die eine Lastverteilung auf OSI-Schicht 5: Sitzungsschicht unterstützen.

DVC-konforme Containerumgebung

In einer DVC-konformen Containerumgebung (Kubernetes) fungieren die sogenannten "IngressController" als Gateway zwischen der Außenwelt und dem SAK-Service. Jeglicher eingehende Datenverkehr wird über den "IngressController" geleitet und an die SAK-Instanzen im Kubernetes-Cluster weitergeleitet. Die SAK-Instanzen im Kubernetes-Cluster können von der Außenwelt nicht direkt aufgerufen werden.

8.7.3 Baustein NOOTS-Transportprotokoll

Da der Datenaustausch der NOOTS-Teilnehmer obligatorisch über deren dezentrale SAKs erfolgt, ist das verwendete Transportprotokoll für die Teilnehmer vollständig transparent. Ein späterer Wechsel des Transportprotokolls ist somit ohne Änderungen an den Implementierungen der Teilnehmer möglich. Für Transportprotokollstandards bei interaktiver Nutzung gelten insbesondere die folgenden Anforderungen:

1. Der Transportstandard muss ein synchrones Request-Response-Nachrichtenaustauschmuster (Message-Exchange-Pattern, MEP) unterstützen, d.h. der Nachweis in der Antwort des Data Providers wird über den HTTP-Response-Kanal transportiert. Zur Erzielung niedriger Antwortzeiten, hoher Zuverlässigkeit und geringer Betriebskomplexität soll auf Nachrichtenaustauschmuster, die auf asynchronem Messaging basieren ("Two Way / push & push"), verzichtet werden.
2. Der Transportstandard muss Mechanismen bereitstellen, auf die sich die Implementierung des SAK zur Gewährleistung der Authentizität, Vertraulichkeit und Integrität stützen kann. Eine Ende-zu-Ende-Verschlüsselung mit den SAK-Instanzen als den jeweiligen Endpunkten muss möglich sein.

Abb. 13: Entkopplung des Transportprotokolls mittels adaptierter, externer Protokollschnittstellen im SAK

Für die interaktive Nutzung hat sich der Einsatz des HTTP-Protokolls zur technischen Umsetzung eines synchronen Request-Response-Nachrichtenaustauschmusters bewährt. Beispiele hierfür sind X-Road, das in mehreren nordischen Ländern für den sicheren Datenaustausch in der öffentlichen Verwaltung genutzt wird, und das NextGenPSD2 API Framework der Berlin Group, eine paneuropäische Initiative zur Schaffung von Interoperabilitätsstandards und zur Harmonisierung im Zahlungsverkehr.

8.7.3.1 NOOTS-Transportprotokoll: synchrones HTTP Request-Response mit mTLS

Die SAKs kommunizieren über das HTTP-Protokoll, das auf der Anwendungsschicht (Schicht 7) des OSI-Schichtenmodells liegt und durch Transport Layer Security (TLS) abgesichert wird. TLS ist ein kryptografisches Protokoll, das auf der Sitzungsschicht (Schicht 5) des OSI-Schichtenmodells operiert und die Sicherheit der Netzwerkkommunikation gewährleistet. Im Folgenden werden die wesentlichen Aspekte der Umsetzung von Authentizität, Vertraulichkeit und Integrität durch mTLS, eine Erweiterung des TLS-Protokolls, unter Berücksichtigung der Richtlinien des Bundesamts für Sicherheit in der Informationstechnik (BSI) für TLS betrachtet. Die notwendigen Zertifikate sind im Kapitel "7.2.4 Überblick Zertifikate für den SAK" aufgeführt.

• Authentizität:
  Mit dem Einsatz von mTLS müssen sowohl der SAK des Data Providers als auch der SAK des Data Consumers ein gültiges und vertrauenswürdiges Zertifikat vorweisen. Die gegenseitige Authentifizierung erfolgt durch den Austausch von Zertifikaten. Dabei sendet der SAK des Data Providers sein Zertifikat an den SAK des Data Consumers, um seine Identität zu bestätigen, und umgekehrt sendet der SAK des Data Consumers sein Zertifikat an den SAK des Data Providers, um ebenfalls seine Identität zu bestätigen. Beide Kommunikationspartner überprüfen die Gültigkeit der erhaltenen Zertifikate, um sicherzustellen, dass sie von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurden und weder abgelaufen noch widerrufen sind. Zusätzlich müssen beide Kommunikationspartner über kryptografische Funktionen den Besitz des zum Zertifikat zugehörigen privaten Schlüssels nachweisen.
• Vertraulichkeit:
  Nach erfolgreicher Authentifizierung wird eine sichere, verschlüsselte Verbindung zwischen den SAKs aufgebaut, um einen sicheren Datenaustausch zu ermöglichen. Die SAKs fungieren dabei als die Endpunkte für die Ende-zu-Ende-Verschlüsselung, die sämtliche HTTP-Daten (Header und Body) abdeckt.
• Integrität:
  TLS gewährleistet auch mithilfe von Hashfunktionen, dass die Daten während der Übertragung nicht von Dritten gefälscht oder manipuliert wurden.
• BSI-Richtlinien für TLS:
  Der Sicherheitsgrad hängt von der gewählten TLS-Version und der Cipher-Suite ab, die Verschlüsselungs-, Authentifizierungs- und Integritätsalgorithmen umfasst. Dabei sind die BSI-Richtlinien maßgebend, zu denen gehören:
  • Mindeststandard des BSI zur Verwendung von Transport Layer Security (SQ-16)
  • BSI TR-02102-2 "Kryptographische Verfahren: Verwendung von Transport Layer Security (TLS)" Version: 2024-1 (SQ-17) und
  • BSI TR-03116-4 Kryptographische Vorgaben für Projekte der Bundesregierung Teil 4 Stand 2023 (SQ-10).

mTLS wird oft im Zero-Trust-Kontext angewendet, um die Authentifizierung von Systemen während der HTTP-Kommunikation zu ermöglichen und APIs zu schützen. Die Verwendung von mTLS trägt dazu bei, den Schutz vor verschiedenen Arten von Angriffen zu verbessern, darunter:

• On-Path-Angriffe: Angreifer versuchen sich zwischen den SAKs zu platzieren und fangen die Kommunikation zwischen den beiden ab oder verändern sie. Angreifer ohne privaten Schlüssel und Zertifikat des Data Consumer können sich aber beim SAK des Data Providers nicht authentifizieren, sodass dieser Angriff fast unmöglich ist.
• Spoofing: Angreifer versuchen den SAK des Data Consumer zu imitieren, wobei Angriffe fast unmöglich sind, wenn sich die SAKs mit TLS-Zertifikaten authentifizieren müssen.
• Credential Stuffing: Angreifer versuchen mit einem "abgefangenen" Zugriffstoken und Abruftoken sich als rechtmäßiger Data Consumer bei einer API-Anfrage auszugeben. Ohne ein rechtmäßig ausgestelltes TLS-Zertifikat und den zugehörigen privaten Schlüssel sind Angriffe erfolglos.

8.7.3.2 Metadaten

Die Metadaten im Transportprotokoll werden im HTTP-Header übertragen.

Tab.13: Metadaten Transportprotokoll (Auszug)

8.7.3.3 Integrität auf OSI-Schicht 8: Transport über Anwendungsebene

Das Transportprotokoll gewährleistet die Unversehrtheit der Daten während der Übermittlung in der NOOTS-Transportinfrastruktur mittels mTLS auf der Sitzungsschicht (Schicht 5) des OSI-Schichtenmodells. Zum Gesamtverständnis der Maßnahmen zur Sicherstellung der Integrität werden hier auch die zusätzlichen Integritätsprüfungen der OSI-Schicht 8, "Transport über Anwendungsebene," aufgeführt:

• Die Integrität der XNachweis-Anfrage wird durch den berechneten Hashwert im gesiegelten Abruftoken der Vermittlungsstellen und dessen Verifizierung im SAK sichergestellt (siehe auch Kapitel "Sichere Anschlussknoten: Abstrakte Berechtigung").
• Der Data Provider kann die Integrität der Nachweisdaten durch Siegelung sicherstellen. Die Transportinfrastruktur muss gewährleisten, dass die Daten zur Siegelung der Nachweisdaten an den Data Consumer übertragen und dabei nicht verändert werden können.

8.7.4 Baustein NOOTS-Anschlussprotokoll

Die NOOTS-Teilnehmer und NOOTS-Komponenten verwenden das Anschlussprotokoll, um mit dem Sicheren Anschlussknoten zu kommunizieren. Es handelt sich um ein synchrones, zustandsloses und interoperables Protokoll im RPC-Stil, das entweder von den NOOTS-Teilnehmern oder den SAKs initiiert werden kann. Das Protokoll basiert auf Representational State Transfer (REST) über HTTP(S) und verwendet zusätzliche HTTP-Header-Attribute zur Übertragung von Metainformationen. Das Anschlussprotokoll unterstützt die folgenden API-Typen:

• Consumer-API für Data Consumer: API zum Abrufen von Nachweisen,
• Provider-API für Data Provider: API für die Bereitstellung von Nachweisen aus nationalen Registern,
• Provider-API für NOOTS-Komponenten, einschließlich der Intermediären Plattform: API zur Bereitstellung zentraler Dienste im Rahmen der SAK-Nachnutzung (Details werden hier nicht behandelt).

Im Kapitel "Laufzeitsicht" wird ein detaillierter Ablauf für den Nachweisabruf im HLA-Anwendungsfall "1a: Interaktiver Nachweisabruf zu einer natürlichen Person über das NOOTS" (AD-NOOTS-03) beschrieben, wobei die Consumer-API für Data Consumer und die Provider-API für Data Provider verwendet werden.

8.7.4.1 Consumer-API für Data Consumer

Die primäre Funktion der Consumer-API besteht darin, Data Consumer dazu zu befähigen, Nachweise vom Data Provider oder von einem EU-Mitgliedstaat über die Intermediäre Plattform abzurufen. Beim Zugriff von Onlinediensten als Data Consumer auf die Consumer-API müssen folgende Festlegungen aus dem "Anschlusskonzept Data Consumer (DC)" (AD-NOOTS-01) und dem Grobkonzept "IAM für Behörden" (AD-NOOTS-05) berücksichtigt werden:

1. Jeder Onlinedienst, auch innerhalb einer Onlinedienst-Plattform, wird als eine IT-Komponente betrachtet und besitzt demnach eine eindeutige "Komponenten-ID". Somit fungiert jeder Onlinedienst als Data Consumer.

2. Mehrere Data Consumer können unter Verwendung desselben Zertifikats für die Fach- und betriebsverantwortlichen Stellen in IAM für Behörden registriert werden.

Der SAK stellt folgende Operationen der Consumer-API zur Verfügung, die vom Data Consumer aufgerufen werden können:

Tab. 14: Übersicht Consumer-API und deren Relevanz für Anwendungsfälle 1, 2 und 4 der HLA

Legende

• ¹⁾ Sofern eine Rechtsgrundlage für den Nachweisabruf mit diesem Identifikator gemäß IDNrG oder UBRegG vorhanden ist.

8.7.4.2 Provider-API für Data Provider

Die Provider-API ermöglicht es einem Data Provider, auf Anfrage Nachweise bereitzustellen. Sie bietet dabei zwei alternative Kommunikationsmodelle für die Kommunikation mit dem SAK: den passiven und den aktiven Empfänger. Die Wahl des geeigneten Kommunikationsmodells richtet sich nach den Anforderungen des Data Providers an Durchsatz und netzseitige Sicherheitsmechanismen.

8.7.4.2.1 Passiver Empfänger

In diesem Kommunikationsmodell definiert der SAK eine API als Service Provider Interface (SPI), die vom Data Provider implementiert werden muss. Der SAK des Data Providers leitet die Nachweisanfrage an das SPI des passiven Data Providers weiter. Ist der Data Provider nicht verfügbar, erzeugt der SAK sofort eine Fehlermeldung und sendet diese an den Data Consumer. Dieses Kommunikationsmodell ist einfach umzusetzen und eignet sich für sichere Betriebsumgebungen, beispielsweise mit kontrollierten Zonenübergängen durch Anwendungs-Level-Gateways oder "P-A-P"-Umgebungen (Paketfilter - Application Layer Gateway - Paketfilter) gemäß "BSI NET.1.1: Netzarchitektur und -design" (SQ-20).

Tab. 15: Übersicht Service Provider Interface für passive Empfänger und deren Relevanz für Anwendungsfälle 1, 2 und 3 der HLA

8.7.4.2.2 Aktiver Empfänger (Initiativumkehr)

Der SAK bietet als Sicherheitsmerkmal die Umkehr der Kommunikationsrichtung, um restriktive Netzarchitekturen bei Data Providern zu ermöglichen. Dieser Mechanismus erlaubt es, Verbindungen ausschließlich von der sicheren in eine weniger sichere Zone zu initiieren.

Abb. 14: Initiativumkehr der Kommunikation durch Long-Polling-Technik

Beim Kommunikationsmodell „aktiver Empfänger“ stellt der SAK die Operationen der Provider-API zur Verfügung. Der Ablauf dieses Modells ("Long-Polling-Technik") gestaltet sich wie folgt:

1. Data Provider sendet Anfrage „warteAufAbruf“: Data Provider initiiert mit der Operation „warteAufAbruf“ und einem Timeout als Parameter eine Anfrage beim SAK, um auf neue Nachweis-Anfragen zu warten. Bei einem redundanten Deployment sollten mehrere zeitgleiche Anfragen initiiert werden.

2. SAK wartet: SAK hält die Anfrage offen und wartet, bis eine neue Nachweis-Anfrage vom SAK des Data Consumers eingeht oder ein Timeout auftritt. Bei einem Timeout wird die Anfrage geschlossen, und der Data Provider startet sofort eine neue Anfrage gemäß Schritt 1.

3. Nachweis-Anfrage ist verfügbar: Sobald eine neue Nachweis-Anfrage beim SAK eingeht, antwortet der SAK auf die offene Anfrage aus „warteAufAbruf“ mit den Daten der Nachweis-Anfrage.

4. Data Provider empfängt Nachweis-Anfrage und sendet Antwort: Data Provider empfängt die Nachweis-Anfrage, verarbeitet diese und sendet die Nachweis-Antwort oder eine Fehlermeldung mittels der Operation „sendNachweis“ an den SAK. Anschließend initiiert der Data Provider sofort eine neue Anfrage mit der Operation „warteAufAbruf“, um auf weitere Nachweis-Anfragen zu warten.

5. Zyklus wiederholt sich: Zyklus von „warteAufAbruf“ und „sendNachweis“ wiederholt sich kontinuierlich.

Die „Long-Polling-Technik“ ermöglicht deutlich geringere Latenzen und höhere Durchsätze als traditionelles Polling und erfordert keine dauerhafte Verbindung wie WebSockets. Sie wird im Vergleich zu WebSockets gut von Firewalls und Proxys unterstützt, da sie auf normale HTTP(S)-Anfragen basiert.Die Implementierung dieser Technik bringt einige Implikationen mit sich: Zum einen unterscheidet sich das Programmiermodell für Data Provider von dem üblichen Thread-Pool-gestützten WebController-Modell, da die Provider-Implementierung die Threads aktiv verwalten muss. Beispiel- oder Referenzimplementierungen können hierbei hilfreich sein. Zum anderen erfordert ein redundantes Deployment in horizontal skalierende Clusterumgebungen Mechanismen zur Lastverteilung. Diese Mechanismen dürfen jedoch nicht die angestrebte Leichtgewichtigkeit des SAKs beeinträchtigen.

Der SAK stellt folgende Operationen zur Verfügung, die vom Data Provider aufgerufen werden können:

Tab. 16: Übersicht Provider-API für aktive Empfänger und deren Relevanz für Anwendungsfälle 1, 2 und 3 der HLA

8.7.4.3 Versionierung

Das Anschlussprotokoll muss bei Änderungen die gleichzeitige Nutzung verschiedener API-Versionen ermöglichen und folgt dabei den Regeln des Semantic Versioning. Eine API-Version setzt sich aus den drei Bestandteilen <Hauptversion.Minorversion.Patchversion> zusammen, z.B. 1.1.0:

• Hauptversion: Erhöhung bei nicht abwärtskompatiblen Änderungen
• Minorversion: Erhöhung bei neuen, abwärtskompatiblen Funktionen
• Patchversion: Erhöhung bei abwärtskompatiblen Fehlerkorrekturen

Die Hauptversion des Anschlussprotokolls ist ein fester Bestandteil der REST-Endpunkt-URL. Bei Anwendung des Entwurfsmusters "Tolerant-Reader-Patterns" in den API-Implementierungen der NOOTS-Teilnehmer können neue abwärtskompatible API-Versionen mit zusätzlichen Funktionen eingeführt werden, ohne die bestehenden API-Implementierungen zu beeinträchtigen.

8.7.4.4 Sicherheit

Die REST-Endpunkte sowohl der SAKs als auch der NOOTS-Teilnehmer müssen ausschließlich über HTTP in Verbindung mit TLS (HTTPS) erreichbar sein. HTTPS gewährleistet die Vertraulichkeit und Integrität der transportierten Daten durch Verschlüsselung und Hashwert-Bildung.

8.7.4.5 Autorisierung der API-Zugriffe

Es wird dringend empfohlen, die Verbindung über das Anschlussprotokoll zwischen dem SAK des NOOTS-Teilnehmers und dem NOOTS-Teilnehmer (Data Consumer oder Data Provider) mittels gegenseitig authentifizierter Zertifikate zu autorisieren, auch bekannt als mutual TLS (mTLS). Die Verwendung von JWT-Tokens als Authentifizierungsmethode wird in der Consumer-API basierend auf dem Zugriffstoken aus IAM für Behörden unterstützt. In der Provider-API im Kommunikationsmodell "passiver Empfänger" wird das Zugriffstoken aus IAM für Behörden unverändert an den Data Provider weitergeleitet. Bei dem Kommunikationsmodell "aktiver Empfänger" kann alternativ zu mTLS auch HTTP Basic verwendet werden.

8.7.4.6 Metadaten

Die Metadaten im Anschlussprotokoll werden im HTTP-Header übertragen.

Tab.17: Metadaten Anschlussprotokoll (Auszug)

8.7.5 Baustein Data Provider

Register sind in der Regel über öffentliche Schnittstellen nicht erreichbar und werden normalerweise in abgeschotteten Netzsegmenten betrieben. Der Zugriff ist nur für ausgewählte Kommunikationspartner möglich, wenn eine fachrechtliche Regelung dies vorsieht. Eine Exposition der Register im Internet erfordert umfassende zusätzliche Schutzmaßnahmen wie beispielsweise "P-A-P" (Paketfilter - Application Layer Gateway - Paketfilter)-Umgebungen gemäß "BSI NET.1.1: Netzarchitektur und -design" (SQ-20).

Initiativumkehr

Darüber hinaus kann der Ansatz der Initiativumkehr (Kommunikationsmodell "aktiver Empfänger" der Provider-API) eingesetzt werden. Dabei exponieren die Register ihre Schnittstellen nicht im Netz, sondern holen aktiv Nachrichten von der Transportinfrastruktur ab. Dadurch sind sie deutlich weniger anfällig für Angriffe. Allerdings ist die technische Umsetzung des Abholens und Beantwortens von Nachrichten komplexer, insbesondere bei hohen Nachrichtenlasten.

→ Weiterführende Informationen zum Anschluss eines Data Provider an das NOOTS sind im Anschlusskonzept für Data Provider (AD-NOOTS-02) zu finden.

8.8 Laufzeitsicht

Im folgenden Sequenzdiagramm und der dazugehörigen Beschreibung wird der vom Data Consumer initiierte Ablauf eines Nachweisabrufs für den HLA-Anwendungsfall "1a: Interaktiver Nachweisabruf zu einer natürlichen Person über das NOOTS" mit einer IDNr gemäß Identifikationsnummerngesetz (RGR-01) im Detail dargestellt. Dabei steht die Kommunikation zwischen dem Sicheren Anschlussknoten (SAK) und den weiteren NOOTS-Komponenten im Vordergrund. In der grafischen Abbildung wird der Anschluss an das NOOTS des Data Providers ausschließlich über das Kommunikationsmodell des "aktiven Empfängers" der Provider-API dargestellt. In der Beschreibung hingegen werden beide Kommunikationsmodelle, sowohl "aktiver Empfänger" als auch "passiver Empfänger", erläutert.

8.8.1 Nachweislieferung für den HLA-Anwendungsfall 1a mit IDNr

Abb. 15: Ablauf einer Nachweislieferung für den HLA Anwendungsfall 1a

8.8.2 Beschreibung Nachweislieferung für den HLA-Anwendungsfall 1a mit IDNr

Der Data Consumer kann über die Consumer-API seines SAK einen Nachweisabruf durchführen. Dazu muss er die folgenden Schritte in der angegebenen Reihenfolge durchlaufen:

1. Anfordern des Zugriffstokens aus IAM für Behörden: getZugriffsToken
2. Ermittlung des Nachweisangebotes aus der Registerdatennavigation: getNachweisangebot
3. Ermittlung der IDNr anhand der Basisdaten aus IDM für Personen, sofern das Nachweisangebot die Verwendung der IDNr für den Nachweisabruf zulässt: getIdNr
4. Abruf des Nachweises vom Data Provider: getNachweis

Im Folgenden werden die einzelnen Operationen der Consumer-API in der obigen Reihenfolge beschrieben und die damit verbundenen Aktivitäten des SAK detailliert erläutert. In der Spalte „Ein-/Ausgabeparameter und Fehlerzustände“ sind die erforderlichen fachlichen Eingabe- und Ausgabedaten für die jeweiligen Operationen sowie mögliche fachliche Fehlerzustände aufgeführt.

Für die Anbindung der Teilnehmer (Data Consumer und Data Provider) an den SAK über die Consumer-API bzw. Provider-API des Anschlussprotokolls gelten allgemein folgende Grundsätze, die in der nachfolgenden tabellarischen Beschreibung nicht wiederholt aufgeführt werden:

• Sichere Kommunikationsverbindung: Die Verbindung zwischen Teilnehmer und SAK ist TLS-verschlüsselt.
• Authentifizierung der NOOTS-Teilnehmer: Die Authentifizierung der NOOTS-Teilnehmer erfolgt entweder mittels „mTLS“ (empfohlen) oder alternativ über „HTTP Basic Authentication“ gemäß RFC 7617. Bei fehlgeschlagener Authentifizierung wird die Verarbeitung abgebrochen. Bei der Consumer-API muss bei Verwendung von „HTTP Basic Authentication“ nur die Operation „getZugriffsToken“ abgesichert werden, da die anderen Operationen bereits durch das Zugriffstoken aus dem IAM für Behörden abgesichert sind.

Folgende Abkürzungen werden für die NOOTS-Teilnehmer und Komponenten verwendet:

• DC: Data Consumer,
• DP: Data Provider,
• SAK-DC: SAK des Data Consumer,
• SAK-IAM: SAK des IAM für Behörden,
• SAK-RDN: SAK der Registerdatennavigation,
• SAK-IDM-P: SAK des IDM für Personen,
• SAK-VS: SAK der Vermittlungsstelle.

8.8.2.1 Schritt 1: Consumer-API::getZugriffsToken

Ein Data Consumer benötigt zur Kommunikation mit NOOTS-Komponenten ein gültiges Zugriffstoken. Dieses Zugriffstoken wird von der NOOTS-Komponente IAM für Behörden ausgestellt und verfügt über eine maximale Lebensdauer von 60 Sekunden.Sobald das Zugriffstoken abgelaufen ist, muss der Data Consumer ein neues Zugriffstoken anfordern.

Tab. 18: Abruf des Zugriffstokens

8.8.2.2 Schritt 2:Consumer-API::getNachweisangebot

Der zuständige Data Provider für den Nachweisabruf wird durch die Registerdatennavigation ermittelt. Für zentrale Register genügt der Nachweistyp zur Bestimmung des Data Providers. Bei dezentralen Registern sind weitere Zuständigkeitsparameter wie z. B. PLZ oder ARS erforderlich.

Tab. 19: Abruf des Nachweisangebotes

8.8.2.3 Schritt 3:Consumer-API::getIdNr

Die Identifikationsnummer (IDNr) wird anhand der Basisdaten aus der Nutzer-Authentifizierung in der IDM für Personen (Bestandteil des Systems Identitätsdatenabruf) ermittelt. Der Aufruf dieser Operation der Consumer-API ist nur erforderlich, wenn aus dem Ergebnis der vorherigen Operation "getNachweisangebot" abgeleitet werden kann, dass die IDNr im lokalen Datenbestand des Data Providers gespeichert ist.

Tab. 20: Abruf der IDNr

8.8.2.4 Schritt 4: Consumer-API::getNachweis

Diese Consumer-API liefert die Nachweisdaten auf Basis einer Nachweis-Anfrage und umfasst die folgenden Orchestrierungsaktivitäten:

1. Abstrakte Berechtigungsprüfung durch die Vermittlungsstelle (VS) ausführen,
2. Verbindungsparameter für den Data Provider aus der RDN ermitteln und
3. Nachweisabruf beim Data Provider ausführen.

Tab. 21: Abruf eines Nachweises

8.9 Ausblick und Weiterführende Aspekte

Die konzeptionelle Gestaltung der Transportinfrastruktur ist fortlaufend und wird in die nächsten Iterationen dieser Architekturdokumentation einfließen. Dabei werden die im Folgenden beschriebenen weiterführenden Aspekte berücksichtigt.

Tab. 22: Weiterführende Aspekte

8.10 Änderungsdokumentation

8.11 Anhang A - Bestehende Transportinfrastrukturen

In diesem Anhang werden die Transportinfrastrukturen vorgestellt, aus denen das Abstrakte Architekturmodell abgeleitet wurde. Dabei werden die im Architekturmodell geprägten Begriffe genutzt, um die die Infrastrukturen leichter vergleichbar zu machen.

8.11.0.1 OSCI und XTA

Abb. 16: Überblick Nachrichtenübermittlung mit OSCI und XTA (XS-07)

Die OSCI Infrastruktur hat seit der Entwicklung im Jahr 2001 in Teilen der deutschen Verwaltung, insbesondere der Innenverwaltung und der Justiz, große Verbreitung gefunden. Aufgrund der intensiven Nutzung im Meldewesen ist sie in praktisch allen Kommunen vorhanden. Sie basiert auf dezentralen OSCI Intermediären, welche Nachrichten von deren Autor entgegennehmen. Diese können vom Leser beim Intermediär abgeholt werden oder durch den Intermediär aktiv an den Leser zugestellt werden. Für die Adressierung der Leser und den Austausch von Verbindungsparametern, insbesondere Zertifikaten, wird ein zentraler Verzeichnisdienst benötigt. In der Innenverwaltung übernimmt das DVDV diese Rolle.

Seit 2012 befindet sich eine Erweiterung der Infrastruktur auf Basis des XTA Standards im Aufbau. Dabei handelt es sich im Kern um Anschlussknoten, die einen einfachen und einheitlichen Zugang zur Transportinfrastruktur ermöglichen sollen, ohne dass die Teilnehmer das recht komplexe OSCI Protokoll sprechen müssen. In einigen Bundesländern kommen XTA Implementierungen auch in der Rolle von Transportknoten vor. Sie werden dann nicht mehr bei den Autoren oder Lesern betrieben, sondern zentral in Landesrechenzentren. Aufgrund der geänderten Rolle können sie die Aufgabe des Anschlussknotens nur noch bedingt übernehmen, insbesondere sind sie ungeeignet als Enden der Ende-zu-Ende Verschlüsselung.

Für das NOOTS ist die OSCI/XTA Infrastruktur nur bedingt geeignet. Die OSCI Intermediäre sind zunächst auf jeder Verbindungsstrecke nur einmal vorhanden, in der Regel im Transportmedium des Lesers. Damit ermöglichen sie ein Routing durch das Transportmedium des Lesers, können jedoch kein Routing über das Transportmedium des Autors unterstützen. Für diesen Zweck wurde OSCI ursprünglich auch nicht entwickelt. Der Schwerpunkt lag auf asynchronen Kommunikationsszenarien mit temporär nicht verfügbaren Empfängern. Hier spielen Anforderungen wie Zustellgarantien und Nichtabstreitbarkeit eine große Rolle, die wiederum im NOOTS derzeit nicht relevant sind. In den allermeisten Fällen erfolgt die Kommunikation vom Autor zum OSCI Intermediär daher über das Internet.

Request-Response Nachrichtenaustauschmuster

Das Nachrichtenaustauschmuster „Request-Response, passiver Empfänger“ in OSCI verwendet Mechanismen aus den asynchronen Kommunikationsszenarien. Die Kommunikation zwischen dem Autor und Leser erfolgt immer über einen OSCI-Intermediär und wird durch verschiedene Auftragsnachrichten umgesetzt: MessageId-Anforderungsauftrag, Dialoginitialisierungsauftrag, Abwicklungsauftrag, Bearbeitungsauftrag und Dialogendeauftrag. Die eingehenden Auftragsnachrichten werden vom OSCI-Intermediär ggf. entschlüsselt und validiert. Neue Auftragsnachrichten werden ggf. signiert, verschlüsselt und an den Empfänger weitergeleitet.

Abb. 17: Request-Response Nachrichtenaustauschmuster (Quelle: OSCI-Transport 1.2 mit integrierten Korrigenda (Fassung: 24. Februar 2021))

Ergänzt man dieses Bild um eine XTA Implementierung, die zentral im Transportmedium des Autors angesiedelt ist, kann diese im Zusammenspiel mit dem OSCI Intermediär durchaus Nachrichten durch die Transportmedien von Autor und Leser zustellen. Dies ist jedoch nur gegeben, wenn zentrale XTA Implementierungen genutzt werden. Häufig werden XTA Implementierungen dezentral, nah bei Autor oder Leser betrieben. Sie können dann die Aufgaben der Anschlussknoten, nicht jedoch der Transportknoten übernehmen. Damit kann die OSCI/XTA Infrastruktur die Anforderungen des NOOTS zwar erfüllen, jedoch nicht alle gleichzeitig.

Im Jahr 2022 wurde in NRW ein Praxistest OSCI durchgeführt, aus dem Handlungsempfehlungen abgeleitet wurden (siehe IT-PLR-B-13). In dem "Whitepaper Ende-zu-Ende-Verschlüsselung im Zusammenspiel OSCI - XTA" (SQ-26) wurden festgestellt, dass die Verschlüsselung und Entschlüsselung von Daten bei OSCI und XTA unterschiedlich ausgeprägt ist. Im Jahr 2023 hat eine Studie zur Skalierbarkeit und Leistungsfähigkeit von OSCI und XTA (siehe IT-PLR-B-10) aufgezeigt, dass die bestehende OSCI/XTA Infrastruktur zahlreiche Schwächen aufweist. So gibt es derzeit keine einzige XTA-Implementierung, die den XTA Standard vollumfänglich unterstützt. Die Implementierungen verschiedener Hersteller sind nicht interoperabel und die Unterstützung einzelner zu übertragender Fachstandards - im NOOTS sind das XNachweis, XBasisdaten und XDatenschutzcockpit - erfordert Anpassungen an diesen. Auch die vom IDNrG geforderte Anbindung der Vermittlungsstellen ist derzeit weder in OSCI-Intermediären noch in XTA-Implementierungen vorhanden. Darüber hinaus wurde ein Teil der XTA Infrastruktur nicht dezentral, sondern jeweils zentral in den Ländern aufgebaut. Diese Infrastrukturelemente übernehmen hier eher die Rolle von Transportknoten. Sie sind daher auch perspektivisch nur bedingt geeignet, die Rolle von Anschlussknoten zu übernehmen.

In Teilen der Verwaltung, die bisher nicht auf OSCI setzen, gibt es erhebliche Widerstände gegen OSCI/XTA. Der OSCI Transportstandard gilt als technologisch veraltet und schwer zugänglich, die verfügbaren Infrastrukturbausteine als schwer zu betreiben und inperformant.

Es bleibt festzuhalten, dass OSCI/XTA zwar eine recht gut etablierte Transportinfrastruktur darstellt, die allerdings für einen anderen Zweck als synchrone Kommunikation entwickelt wurde und für die Anforderungen des NOOTS nur bedingt geeignet ist. Die OSCI Intermediäre könnten nachgenutzt werden, wo sie bereits vorhanden sind. Sie können die Anforderungen des NOOTS jedoch nicht alleine erfüllen, sondern müssen um weitere Elemente ergänzt werden. Die Nachnutzung der XTA Infrastruktur würde eine Ertüchtigung der Infrastruktur in der Fläche erfordern. Ihr starke Heterogenität macht einen Nachnutzung im NOOTS schwierig. Voraussichtlich wäre selbst bei entsprechender Ertüchtigung nur ein Teil der Infrastruktur dafür geeignet.

8.11.0.2 eDelivery AS4

Abb. 18: Nachrichtenübermittlung mittels eDelivery AS4 (EU-EDM-03)

Ähnlich wie in der deutschen Verwaltung, verfügen auch viele Mitgliedsstaaten der EU über eigene Verwaltungsnetze und Transportinfrastrukturen, die zunächst abgeschottet voneinander sind und bisher durch Einzelmaßnahmen gekoppelt wurden. Mit der Einführung einer europaweiten Transportinfrastruktur auf Basis des auf ebMS basierenden AS4 Protokolls soll die Brücke zwischen den nationalen Transportinfrastrukturen geschlagen und ein grenzüberschreitender Nachrichtenverkehr ermöglicht werden.

Die AS4 Infrastruktur basiert auf AS4 Access Points, welche die Rolle von Transportknoten innerhalb der Mitgliedsstaaten einnehmen. Anders als bei OSCI kommen dabei auf jeder Verbindungsstrecke zwei AS4 Access Points zum Einsatz: Einer im Land des Absenders einer Nachricht und einer im Land des Empfängers. Dadurch können die AS4 Access Point vollständige Kontrolle über die Route grenzüberschreitender Nachrichten ausüben. Die Kommunikation zwischen den Transportknoten erfolgt dabei über das Internet. Zentrale Dienste wie das DVDV werden in der ersten Ausbaustufe des EU-OOTS noch nicht angeboten. In späteren Ausbaustufen soll jedoch ein Dienst auf Basis des OASIS Service Metadata Publishing Profils (SMP), einem Standard für die Veröffentlichung von Dienstmetadaten, zum Einsatz kommen.

Die AS4-Infrastruktur sieht keine expliziten Anschlussknoten vor. Dies liegt daran, dass die Zuständigkeit für die Anschlüsse in der Verantwortung der Mitgliedsstaaten liegt und die EU in diesem Zusammenhang keine Vorgaben macht. Die AS4 Infrastruktur ist also gar nicht als einheitliche Transportinfrastruktur bis hin zu den Teilnehmern aus den Mitgliedsstaaten gedacht. Vielmehr koppelt sie bestehende Transportinfrastrukturen und überlässt die Anschlüsse an die lokalen Transportinfrastrukturen den Mitgliedsstaaten.

Abb. 19: Grenzüberschreitender Datenverkehr über eDelivery AS4 Access Points

Technologisch basiert AS4 auf ebMS 3.0 und SOAP und damit auf ähnlich veralteten Technologien wie OSCI. Ähnlich wie OSCI ist auch AS4 auf asynchrone Nachrichtenkommunikation ausgelegt. Es bietet Zustellgarantien und Mechanismen zur Sicherung der Nichtabstreitbarkeit, die für interaktive Nachweisabrufe nicht benötigt werden. Die Korrelation der Nachrichten für synchrone Kommunikationsmuster ist Aufgabe der Kommunikationspartner. Eine Ende-zu-Ende Verschlüsselung über die Access Points hinweg wird mangels einer europaweiten PKI nicht unterstützt.

Für den Aufbau einer eDelivery AS4 Infrastruktur in Deutschland spricht aktuell wenig. Der verteilte Ansatz ist dem Ansatz von OSCI recht ähnlich, müsste jedoch von Grund auf neu aufgebaut werden. Zudem werden benötigte Funktionalitäten wie die Ende-zu-Ende Verschlüsselung derzeit nicht unterstützt. Perspektivisch könnte eine weitergehende Standardisierung von AS4 CEF eDelivery in Europa aber die Chance bergen, eine neue Transportinfrastruktur in Deutschland aufzubauen, die die Komplexität und Heterogenität der OSCI/XTA Infrastruktur vermeidet.

8.11.0.3 X-Road

Abb. 20: Architekturübersicht X-Road (SQ-22)

X-Road ist eine seit 2001 in Estland entwickelte Transportinfrastruktur, die mittlerweile in über 20 Ländern weltweit im Einsatz ist. Im Gegensatz zu den vorgenannten Infrastrukturen hat sie nie das Ziel verfolgt, getrennte Netze oder Transportinfrastrukturen zu verbinden. Daher bringt sie auch keine Transportknoten mit. Der Schwerpunkt liegt vielmehr auf einer effizienten und sicheren Punkt-zu-Punkt Kommunikation über das Internet. Das Nachrichtenrouting erfolgt alleine durch das Internet (OSI-Schicht 3: Vermittlung). Der Anschluss erfolgt über verpflichtende Anschlussknoten, die in X-Road "Security Server" genannt werden. Diese haben die Aufgabe, den Anschluss für die Teilnehmer möglichst einfach und sicher zu gestalten. Ergänzt werden sie durch so genannte "Central Services", welche insbesondere zentrale Service Discovery ähnlich der DVDV anbieten.

X-Road ist für die Verwendung im NOOTS nicht geeignet, da es das Problem der segmentierten Verwaltungsnetze nicht löst und auch zukünftig nicht in der Lage ist, Nachrichten über die deutschen Verwaltungsnetze zuzustellen. Wesentliche Anforderungen an den Anschlussknoten, wie die Prüfung des Vorliegens der abstrakten Berechtigung bei jedem Nachweisabruf mit IDNr zur Erfüllung der gesetzlichen Anforderungen, sind nicht erfüllt. Zudem ist X-Road nicht kompatibel mit den anderen NOOTS-Komponenten. Stattdessen müsste mit den Central Services ein konkurrierendes Diensteverzeichnis eingeführt werden.

Auf der anderen Seite beweist X-Road, dass es mit geeigneter Transportinfrastruktur möglich ist, auch über das Internet sicher zu kommunizieren. Zudem wurde es technologisch stetig weiterentwickelt und ist mit seiner REST-API (ergänzend zur älteren SOAP API) auf dem aktuellen Stand der Technik.

8.11.0.4 FIT-Connect

Abb. 21: Kommunikation mit FIT-Connect (SQ-23)

Im Unterschied zu den vorgenannten Transportinfrastrukturen ist FIT-Connect keine fachunabhängige Transportinfrastruktur, sondern konkret auf die Einreichung vom Onlineanträgen im OZG Kontext ausgelegt. Es basiert auf einem zentralen Dienst, der Anträge entgegennimmt und von dem die antragbearbeitenden Stellen diese abholen können. Darüber hinaus bringt FIT-Connect auch einen Routingdienst ähnlich der Registerdatennavigation mit, über den die für einen Antrag zuständige Stelle ermittelt werden kann.

Der zentrale Dienst ist nicht in der Lage, Nachrichten über verschiedene Verwaltungsnetze zu übertragen. Stattdessen erfolgt der Transport ausschließlich über das Internet. Antragbearbeitende Stellen können sich direkt an den zentralen Dienst anbinden,um Anträge abzuholen, oder über eine eigene Transportinfrastruktur, bspw. lokale Transportmechanismen der Länder. Über diese Konstellation können dann auch Anträge über Netzgrenzen zugestellt werden. Allerdings muss dabei für jeden Netzübergang eine individuelle Lösung gefunden werden.

Aufgrund der fachlichen Auslegung auf die Antragseinreichung sind bisher auch die API fachlich ausgeprägt. Das ermöglicht es den anzuschließenden Stellen, sich allein auf die Fachlichkeit der Antragseinreichung zu konzentrieren, ohne sich mit einer Transportschnittstellen beschäftigen zu müssen. Für das NOOTS ist FIT-Connect derzeit nicht geeignet, da es eine die Netze übergreifende Zustellung nicht unterstützt. Zudem stellt der zentralisierte Ansatz perspektivisch einen Flaschenhals dar, der die Skalierbarkeit der Infrastruktur auf Dauer einschränkt und einen "Single Point of Failure" darstellt.

8.12 Anhang B - Nachrichtenverfolgung mit OpenTelemetry

OpenTelemetry ist ein Open-Source-Standard für die verteilte Nachrichtenverfolgung der Cloud Native Computing Foundation (CNCF) und der Nachfolger der beiden sich überschneidenden Open-Source-Projekte für verteilte Nachrichtenverfolgung, OpenTracing und OpenCensus. Es bietet anbieterunabhängige APIs, Software Development Kits und weitere Tools zum Erfassen von Daten für die verteilte Nachrichtenverfolgung sowie für weitere Performancemesspunkte. Anhand einer "trace-id" lässt sich das Verhalten von Nachweis- und Serviceanfragen über Komponentengrenzen hinweg nachverfolgen und Einblicke in deren Performance und Zustand gewinnen. Durch die "trace-id" können Protokollinformationen und Performancemesspunkte korreliert und ausgewertet werden. Die "trace-id" wird im Datenfluss bei Nachweis- und Serviceanfragen mitgegeben, wodurch eine komponentenübergreifende Auswertung ermöglicht wird.
Bei einer Umsetzung mit OpenTelemetry kann der SAK folgende Funktionen für die verteilte Nachrichtenverfolgung anbieten:

• "trace-id" wird in der Protokollierung der SAKs verwendet (weitere Details zur Protokollierung im nächsten Abschnitt).
• Weitergabe des Tracing-Kontexts gemäß W3C Trace Context (SQ-19) zwischen NOOTS-Komponenten und NOOTS-Teilnehmern. Falls durch NOOTS-Teilnehmer kein Tracing-Kontext gesetzt wird, wird dieser durch den SAK erzeugt.
• Optional: Export der Tracing-Informationen in eine zentrale Plattform (z.B.Jaeger) zur Nachrichtenverfolgung.

→ Weiterführende Informationen finden sich in OpenTelemetry und W3C Trace Context (SQ-19).