Feedback des Föderalen IT-Architekturboards zum Grobkonzept Transportinfrastruktur (SAK)

Im Rahmen der Vorstellung der aktuellen Konzeption des Programmbereich NOOTS im Föderalen IT-Architekturboard (FIT-AB) am 19.06.2024 wurde vereinbart, Feedback zu den im Termin vorgestellten Themen in Form einer gemeinsamen Einreichung in den gerade laufenden Konsultationsprozess zur Registermodernisierung einzubringen. Das Feedback des Föderalen IT-Architekturboards zum Grobkonzept Transportinfrastruktur (SAK) setzt sich zusammen aus folgenden Rückmeldungen sowie den Rückmeldungen zu den einzelnen Teilfragen des Konsultationsprozesses:

Allgemeine Anmerkungen

Rückmeldung der Hansestadt Hamburg

Das Projekt Gesamtsteuerung der Registermodernisierung des Federführers Hamburg hat an dem Grobkonzept mitgearbeitet.

Fragen können gerne direkt gestellt werden.

Abschnitt 8.3.1.2 Annahme und Rahmenbedingung:

Bitte zwischen Annahmen und Rahmenbedingungen trennen (z. B. 2 Tabellen oder unterschiedlichen Namenskonventionen bei den IDs für Annahmen und den IDs für Rahmenbedingungen) damit für den Leser klar wird, um welche Art von Eintrag es sich handelt. Hintergrund: Rahmenbedingungen und Annahmen müssen in der Architekturentwicklung unterschiedlich behandelt werden.

Abschnitt 8.4.2 Technischer Kontext:

Es werden nur sehr wenige Aussagen im Abschnitt zum tatsächlichen technischen Kontext, in dem die Transportinfrastruktur am Ende betrieben werden muss, getroffen. Diese Informationen tauchen zum Teil in den folgenden Kapiteln auf. Zum Beispiel:

  • Kompatibilität zum EU-OOPS-Transport und Nachrichtenstandards.
  • Betrieb der Data Consumer und Data Provider in unterschiedlichsten RZ unterschiedlichster Ausprägungen
  • Erreichbarkeit der Data Consumer und Data Provider über die unterschiedlichsten Netzwerke
  • Standards und Formate, die für die Kommunikation im NOOTS und mit den Akteuren außerhalb verwendet werden müssen.

Abschnitt 8.5.2 Nicht-funktionale Anforderungen:

Welche nicht-funktionalen Anforderungen wurden für die Transport-Infrastruktur für die Bereiche Verfügbarkeit, Last und Performance identifiziert?

Abschnitt 8.6 Lösungsstrategie:

  1. Designentscheidung „Einfacher NOOTS-Anschluss durch interoperables Anschlussprotokoll“: Das ist eine Anforderung und keine Designentscheidung. Es wäre eine Designentscheidung, wenn hier ein konkretes Anschlussprotokoll genannt wäre oder die Entscheidung getroffen worden wäre, es selbst zu entwickeln, weil es bisher kein geeignetes Anschlussprotokoll gibt.
  2. Designentscheidung „Nahtlose Integration des SAK in bestehende IT-Landschaften“: Das ist eine Anforderung und keine Designentscheidung. Die Designentscheidung ist, dass man SAK-Software als JAR und als Docker Container Image + Helm Chart ausliefert (siehe Abschnitt 8.7.2.5.1 STANDALONE DEPLOYMENT). Bitte hier ergänzen.
  3. Designentscheidung „Nachhaltigkeit in Transport“: Das ist keine Designentscheidung, das ist eine Absichtserklärung, gerne auch ein Architekturprinzip, an dem man sich beim Design orientiert.

Abschnitt 8.7 Bausteinsicht:

Fehlt in dem Abschnitt nicht auch eine Betrachtung der Transportknoten? Diese sind vorher als elementarer Teil der Gesamtlösung identifiziert worden aber werden in keiner Form beschrieben. Müssen neue Transportknoten aufgebaut werden? Müssen bestehende Transportknoten angepasst werden und wenn ja, welche?

Abschnitt 8.7.1.1 Abstraktes Architekturmodell:

  1. Die zentralen Dienste werden im luftleeren Raum dargestellt und es gibt tatsächlich (gestrichelte) Verbindungen zwischen den Anschlussknoten von Data Consumer und Data Provider zu den Anschlussknoten der zentralen Dienste. Bitte auch hier die Netzübergänge nicht weg abstrahieren, sondern ebenso adäquat mit in das Modell aufnehmen. Dann sollte es auch keine Transportprotokolle mehr zwischen Anschlussknoten geben, wie aktuell im Text angegeben.

Abschnitt 8.7.2 Baustein NOOTS Sichere Anschlussknoten (SAK):

Im Unterabschnitt "Nachnutzung SAK" wird die Nutzung von SAK für die Kommunikation zwischen allen NOOTS-Teilnehmern in Frage gestellt („falls geeignet“). In den vorherigen Abschnitten wird aber zumindest die Kommunikation zwischen Data Consumer und Vermittlungsstelle und Data Consumer und IP und IP und Data Provider bereits ein SAK fest vorgesehen. Auch in den folgenden Abschnitten wird davon ausgegangen, dass alle zentralen Dienste über einen eigenen SAK verfügen. Bitte konsistent bleiben.

Abschnitt 8.7.2.2 Software-Architektur:

Bitte die Quelle angeben für die Prinzipien der Fünfzehn-Faktoren-App.

Abschnitt 8.7.4.5 Autorisierung der API-Zugriffe:

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. Damit muss der Data Provider eine Authentifizierung auf Basis des Zugriffstoken hinbekommen. Wie viele Data Provider können das heute bereits? Ggf. Verweis auf den entsprechenden Absatz im Konzept für den Data Provider, in dem beschrieben wird, was zur Ertüchtigung notwendig ist.

Abschnitt 8.8.2.2 Schritt 2:Consumer-API::getNachweisangebot:

Muss es nicht auch bei der RDN-Schnittstelle "findEvidenceService" den Fehler geben, dass kein Provider für einen Nachweistypen registriert ist?

Abschnitt 8.8.2.4 Schritt 4: Consumer-API::getNachweis:

Wie kann ein Data Consumer eine über das NOOTS-Gesamtsystem eindeutige RequestID erzeugen? Ggf. Verweis auf den entsprechenden Abschnitt im Konzept für Data Consumer, in dem beschrieben wird, was zur Ertüchtigung notwendig ist.

Rückmeldung Sachsen-Anhalt

  • In Kapitel 7.1.2 sowie im Anhang werden alternative Transportarchitekturen vorgestellt. Die Gründe gegen die verworfenen Alternativen sollten noch detaillierter beschrieben werden. Falls Alternativen aktuell nicht allen Anforderungen erfüllen, sollte auch betrachtet werden wie diese Alternativen anzupassen wären, um die Anforderungen in Zukunft zu erfüllen. Eine geringfügige Erweiterung kann unter Umständen deutlich aufwandsärmer zu realisieren sein, als die Neuentwicklung einer Transportinfrastruktur.

    Die Komplexität der föderalen IT-Architektur steigt insgesamt erheblich, insbesondere für die beteiligten Systeme wie Online-Dienste und Fachverfahren. Im Gesamtprozess kommen für verschiedene Teilschritte (z.B. Registerabruf, Payment, Antragszustellung, Bescheid an Antragsteller) unterschiedliche Standards zum Einsatz. Es wird daher empfohlen, die föderale Gesamtarchitektur für die OZG-Umsetzung, Registermodernisierung, M2M-Kommunikation sowie Nachrichten- und Kommunikationslösungen ganzheitlich zu betrachten und zu harmonisieren.

Rückmeldung des Föderalen IT-Architekturmanagements der FITKO

Das vorliegende Konzept löst zentrale, komplexe Fragestellungen der Registermodernisierung nicht und benennt diese teilweise auch nicht als Herausforderungen. Insgesamt zeigt sich im Konzept eine unzureichende Umsetzung des Security-by-Design-Prinzips und die Nicht-Beachtung zentraler Kernelemente des Zero-Trust-Prinzips. Notwendige Ansätze zur Mitigation von Bedrohungen auf Grundlage eines Threat Modelings werden nicht dargestellt. Eine umfassende Evaluation der Konzepte aus IT-Sicherheits-Gesichtspunkten wird dringend empfohlen.

Im Übrigen wird auf die Rückmeldung des Föderalen IT-Architekturborads in den einzelnen Teilfragen verwiesen.

Edited by Föderales IT-Architekturmanagement (FITKO)