5. Grobkonzept Intermediäre Plattform (IP)

Redaktioneller Hinweis

Dokument aus der vorangegangen Iteration - nicht Teil der aktuellen Iteration.

Das Dokument stellt einen fortgeschrittenen Arbeitsstand dar, der wichtige Ergänzungen und Verbesserungen enthält. Die Finalisierung ist für das kommende Release geplant.

5.1 Abstract

Das Grobkonzept Intermediäre Plattform beschreibt die NOOTS-Komponente Intermediäre Plattform auf konzeptioneller Ebene. Intermediäre Plattformen vermitteln zwischen dem NOOTS und dem EU-OOTS, indem sie Nachweisabfragen aus dem EU-Ausland in nationale Abfragen umwandeln und umgekehrt. Damit stellen die Intermediären Plattformen eine bedeutende Komponente für die Umsetzung der Verpflichtung zum Anschluss an das EU-OOTS gem. SDG-VO dar. Durch den Einsatz Intermediärer Plattformen (IP) werden Funktionen für grenzüberschreitenden Nachrichtenaustausch gebündelt, die sonst durch die Data Consumer und Data Provider selbst erbracht werden müssten.

5.2 Überblick

Um der Verpflichtung der SDG-Verordnung (EU-03) zum Nachweisaustausch mit dem EU-Ausland nachzukommen, hat der IT-Planungsrat mit dem Beschluss 2022/34 vom 10.11.2022 (IT-PLR-E-06) festgelegt, von der in der SDG-Verordnung eingeräumte Möglichkeit sogenannter Intermediäre Plattformen Gebrauch zu machen.

Intermediäre Plattformen dienen als Mittlerinnen zwischen dem NOOTS und dem EU-OOTS, indem sie Nachweisabfragen aus dem EU-Ausland in nationale Abfragen umwandeln und in das NOOTS weiterleiten, und umgekehrt. Dank der Delegation der EU-spezifischen Anforderungen und Aufgaben an Intermediäre Plattformen müssen deutsche Data Provider und deutsche Data Consumer diese nicht jeder einzeln umsetzen, sodass Umsetzungsaufwand eingespart und dadurch eine zügigere Umsetzung des SDG-Anschlusses erreicht wird. Die Nutzung von Intermediären Plattformen für SDG-anschlussverpflichtete Behörden ist dabei verpflichtend; der direkte Anschluss der nationalen Behörden an das EU-OOTS ist ausgeschlossen.

Aufgrund ihrer unterschiedlichen Aufgaben wird zwischen zwei Typen von Intermediären Plattformen unterschieden, der Intermediären Plattform für Data Provider (Anwendungsfall 3 der HLA) und der Intermediären Plattform für Data Consumer (Anwendungsfall 4 der HLA). Ob in der Umsetzung beide Typen in derselben technischen Komponente gebündelt oder getrennt werden, ist, genau wie die Anzahl und der Zuschnitt der Intermediären Plattform, von der vorliegenden fachlichen Konzeption unabhängig und aus organisatorischer bzw. rechtlicher Perspektive zu entscheiden.

Intermediäre Plattformen müssen beim Nachweisaustausch die für das EU-OOTS festgelegten Transportmechanismen verwenden. Für diese Aufgabe wird in Deutschland ein bzw. mehrere sogenannte eDelivery Access Points eingesetzt. Diese sind in einem eigenen Konzept näher beschrieben und das Zusammenspiel in der High-Level-Architecture im Exkurs zur nationalen Anbindung an das EU-OOTS.

5.3 Rahmenbedingungen und Anforderungen des EU-OOTS

Der europäische Gesetzgeber fordert in der SDG-VO die Errichtung eines technischen Systems für den grenzüberschreitenden Austausch von Nachweisen (EU-OOTS), an das die zuständigen Behörden der Mitgliedstaaten nach Artikel 14 der SDG-Verordnung angeschlossen werden müssen. Die Anforderungen an das EU-OOTS werden durch die zugehörige Durchführungsverordnung (EU) 2022/1463 (EU-01) zu Artikel 14 der SDG-VO vom 05.08.2022 (im Folgenden kurz DVO) und die begleitenden Technical Design Documents (TDD, EU-02) weiter konkretisiert. Sie lassen den Mitgliedstaaten erhebliche Umsetzungsspielräume, auf Grundlage derer die nationale Anbindung an das EU-OOTS konzipiert wurde.

Obgleich das NOOTS in Anlehnung an das EU-OOTS konzipiert wurde, war eine vollständige Konvergenz beider Systeme in Hinblick auf Prozesse und Technologien nicht möglich. Diese Differenzen sind von den Intermediären Plattformen sowie von der Transportkomponente Access Point auszugleichen, die den Übergang zwischen den beiden Systemen (EU-OOTS und NOOTS) managen. Für den Anschluss an das EU-OOTS zählen folgende Rahmenbedingungen und Anforderungen:

• Anfragen werden ausschließlich aus Online-Verfahrensportalen (in der SDG-Verordnung eng. als "Online Procedure Portal" bezeichnet) ausgelöst, für deren Nutzung ein Nachweis zu erbringen ist.
• Betrachtet werden ausschließlich synchrone Nachweisabrufe, die unmittelbar und vollautomatisiert beantwortet werden können.
• Die grenzüberschreitende Kommunikation nutzt das Exchange Data Model (EDM, EU-EDM-01) als generischen Once-Only-Datenabrufstandard.
• Auf Transportebene nutzt die grenzüberschreitende Kommunikation den Standard AS4 (EU-EDM-02).
• Das EU-OOTS verlässt sich darauf, dass nur zulässige und vertrauenswürdige Teilnehmer an die jeweiligen Access Points angebunden werden und hierüber einen Nachweisabruf vornehmen können. Eine auf den einzelnen Abruf bezogene Berechtigungsprüfung der Behörde findet nicht statt.
• Da unterschiedliche Mitgliedstaaten den gleichen Sachverhalt (eng. "Requirement") durch unterschiedliche Nachweistypen dokumentieren, muss zunächst ermittelt werden, welcher Nachweistyp aus dem konkreten EU-Mitgliedstaat abgerufen werden soll. Dabei muss die Antwort nicht eindeutig sein und die Auswahl der tatsächlich gewünschten Nachweistypen kann eine Nutzerentscheidung erfordern.
• Für die Ermittlung des notwendigen Nachweistyps und des zuständigen Evidence Providers stellt die Europäische Kommission die zentralen Verzeichnisdienste Evidence Broker und Data Service Directory zur Verfügung (im Folgenden auch eng. "Common Services" bezeichnet) .
• Die abgerufenen Nachweise müssen den Nutzenden in der Regel zur Entscheidung angezeigt werden, ob sie diese für das Verfahren nutzen möchten. Dieser Vorgang wird als "Preview" bezeichnet. Ausnahmen von der Preview-Verpflichtung können nach Artikel 14 Abs. 5 SDG-Verordnung im europäischen oder nationalen Recht definiert werden.

Hinweis zu den Rollenbegriffen in EU-OOTS und NOOTS: Im EU-OOTS werden im Wesentlichen zwei Rollen definiert, der Evidence Requester und der Evidence Provider. Diese Rollen werden in Deutschland durch die Intermediäre Plattform ausgefüllt. Da diese als Brücke ins NOOTS dient, nimmt sie gegenüber dem NOOTS die nationalen Rollen Data Consumer und Data Provider ein, siehe Abschnitt "Rollen beim Nachweisabruf über das EU-OOTS" der HLA. Konkret heißt das: Ein europäischer Evidence Requester wendet sich mit einer Nachweisanfrage an eine Intermediäre Plattform, da diese für Deutschland den entsprechenden Data Service anbietet und somit gegenüber dem EU-Ausland als Evidence Provider auftritt. Um den Nachweis aus dem NOOTS abzufragen, nutzt die Intermediäre Plattform die dort definierten Prozesse und Technologien und nimmt in diesem Zuge national die Rolle des Data Consumers ein.⁽¹⁾ Für den Anwendungsfall 4 gilt dies spiegelbildlich.

⁽¹⁾ Welche Rechtsstellung der Intermediären Plattform hierfür notwendig ist, wird aktuell noch im Programmbereich Recht und Datenschutz geklärt.

5.4 Fachliches Konzept

5.4.1 Fachliche Anforderungen

5.4.2 Facharchitektur

Um die oben genannten fachlichen Anforderungen zu erfüllen, muss die Intermediäre Plattform mindestens den in Abbildung 31 dargestellten und in Tabelle 54 erläuterten Funktionsumfang umfassen. Der gezeigte Komponentenaufbau ist dabei nicht als normativ zu verstehen. Auch eine andere interne Strukturierung einer Intermediären Plattform ist zulässig, solange die gleiche Funktionalität erreicht wird.

5.4.2.1 Gesamt-Architektur für grenzüberschreitende Nachweisabrufe mit Intermediärer Plattform

Abb. 1: Gesamt-Architektur für grenzüberschreitende Nachweisabrufe mit Intermediärer Plattform

5.5 Beschreibung der Funktionen im Einzelnen

5.5.1 Anforderungen an Intermediären Plattformen für Data Provider

Die Kernaufgabe der Intermediären Plattform besteht darin, Nachweisanfragen (Nachricht QueryRequest) aus dem EU-Ausland zu beantworten. Zulässige Antwortnachrichten des Evidence Providers sind dabei laut EU-TDD (Zusatz "EDM"- ergänzt zur besseren Unterscheidung zu XNachweis-Nachrichten):

In ihrer Rolle als nationaler Data Consumer sendet und empfängt die Intermediäre Plattform folgende Nachrichten, die in der \"Spezifikation XNachweis" (XS-01) näher beschrieben werden:

5.5.2 Ablauf eines Nachweisabrufs aus dem EU-OOTS

Die fachlichen Schritte des Nachweisabrufs sind in der [High-Level-Architecture [AD-NOOTS-03]] beschrieben. Ergänzend dazu zeigt das folgende Sequenzdiagramm einen möglichen Nachrichtenfluss zwischen den beteiligten Akteuren unter Verwendung der zuvor vorgestellten Nachrichten. Schritte im Ausland sind nur dargestellt, wenn sie eine direkte Schnittstelle zu einem der NOOTS-Akteure haben.

Hinweis: Gestrichelte Pfeile stehen für die Verwendung von HTTP als Protokoll, während die durchgezogenen für XNachweis bzw. EDM-Nachrichten bedeuten.

Abb. 2: Ablauf Nachweisanfrage durch ausländischem Evidence Requester von nationalem Data Provider

5.5.3 Erläuterung zur Funktionalität der Preview

Das EU-OOTS sieht als Regelfall vor, dass die Nutzenden den Nachweis vor der grenzüberschreitenden Übermittlung einsehen und die Verwendung des Nachweises freigeben müssen (Preview, siehe Artikel 14 Abs. 3 lit. f SDG-VO). Prinzipiell sind für die Implementierung der Preview auf der Intermediären Plattform zwei Szenarien denkbar:

1. Der Data Provider liefert ein menschenlesbares Format des Nachweises, i.d.R. ein PDF. Dieses kann die Intermediäre Plattform unverändert als Preview anzeigen. Dieses Vorgehen ist im Zielbild 2023 zu erwarten, wird aber möglicherweise sukzessive um Szenario 2 ergänzt, wenn weitere Register angeschlossen werden.
2. Der Data Provider liefert ein strukturiertes Datenformat. Dieses muss die Intermediäre Plattform mithilfe eines Diensts gemäß Formatvorlagen menschenlesbar aufbereitet werden.

Die Perspektive, dass ein EU-weit harmonisiertes Datenformat vom Data Provider geliefert und entsprechend durch die Intermediäre Plattform menschenlesbar aufbereitet werden müsste, liegt nicht innerhalb des zeitlichen Rahmens des Zielbilds 2028.

Ausnahmen von der Preview: Es kann Datenabrufe geben, in denen die Notwendigkeit der Preview durch europäisches oder nationales Recht ausgeschlossen wurde (siehe Artikel 14 Abs. 5 SDG-VO); dies wird vom Evidence Requester in der initialen Anfragenachricht gekennzeichnet. In diesem Fall kann die Intermediäre Plattform grundsätzlich bereits die erste Anfrage unmittelbar mit der Übermittlung des betreffenden Nachweises beantworten. Wenn die Intermediäre Plattform aber Zusatzangaben der Nutzenden benötigt, um das richtige Register für den Datenabruf zu ermitteln, kann auch in diesen Fällen eine Weiterleitung der Nutzenden auf die Nutzeroberfläche ("Preview-Space") der Intermediären Plattform angefordert werden (Artikel 14 Abs. 2 i.V.m. Artikel 11 Abs. 3 DVO). Die Nutzenden können diese Weiterleitung ablehnen; es ist jedoch zulässig, dass der Nachweisabruf in diesen Fällen auch fehlschlagen kann.

5.5.4 Aufgaben der Intermediären Plattform in Abgrenzung zu denen der Data Provider oder registerführenden Stellen

• Obwohl die Intermediäre Plattform Nachweise nach den Regeln des EU-OOTS ausliefert (Data Service im Sinne des EU-OOTS), hält sie die Nachweisdaten nicht selbst vor, sondern fordert sie anlassbezogen über das NOOTS von der Stelle an, die im NOOTS für die Bereitstellung dieser Nachweise zuständig ist. Damit verbleiben die Aufgaben der originären Datenhaltung und -pflege bei den eigentlichen registerführenden Stellen. Diese verantworten die fachliche Richtigkeit der Daten.
• Die Aufgabe der Datenpräsentation wird bei SDG-Abrufen in Form der Preview von der Intermediären Plattform übernommen. Obgleich sie nicht für die fachliche Richtigkeit der Nachweisdaten verantwortlich ist, muss sie sicherstellen, dass die vom Register gelieferten Daten korrekt angezeigt werden und bei etwaigen Umwandlungsprozessen keine inhaltlichen Änderungen geschehen.
• Der Data Provider im NOOTS ist verantwortlich für die Bereitstellung der Daten. Dies wird in der Regel von der registerführenden Stelle selbst übernommen, kann jedoch -- anders als Datenhaltung- und pflege -- an zentrale Strukturen, wie Abrufportale oder Spiegelregister delegiert werden, sofern die rechtlichen Voraussetzungen dafür existieren.

5.5.5 Registrierung der Data Services der Intermediären Plattform im Data Service Directory

Bei verteilten Registerlandschaften wie in Deutschland können häufig mehrere Data Provider die gleichen Typen von Nachweisen ausstellen, und es muss im Einzelfall ermittelt werden, welcher Data Provider für die konkrete Anfrage zuständig ist. Dies kann sich z.B. bei einer regionalen Gliederung aus dem Wohnort der betroffenen Person ableiten, aber auch komplexeren Zuständigkeitslogiken folgen (siehe zu einer ausführlicheren Erläuterung dieser Herausforderung im innerstaatlichen Kontext auch das Grobkonzept Registerdatennavigation, AD-NOOTS-07).

Damit diese Komplexität nicht im Data Service Directory (EU-DSD-01) der EU aufwändig zu pflegen ist und Antragstellende nicht aus einer Vielzahl von möglichen Providern auswählen müssen, wurde für Deutschland entschieden, dass im DSD allein die Data Services der Intermediären Plattform(en) hinterlegt werden. Die konkrete Zuständigkeitsermittlung mittels Registernavigation, ggf. unter Verwendung von zusätzlichen Angaben der Nutzenden, findet national auf der Intermediären Plattform selbst statt.

Solange keine andere Regelung zur Pflege getroffen wird, hat der Betreiber einer Intermediären Plattform dafür Sorge zu tragen, dass die Daten zu den von ihr bereitgestellten Data Services im DSD jederzeit aktuell sind.

5.6 Anforderungen an Intermediäre Plattformen für Data Consumer

Die Kernaufgabe der Intermediären Plattform für Data Consumer besteht darin, Nachweisanfragen aus dem Inland zu beantworten. Dazu tauscht sie folgende Nachrichten mit dem Data Consumer aus, die in der XNachweis-Spezifikation ([XS-01]) im Detail definiert werden (Zusatz "XNachweis"- ergänzt zur besseren Unterscheidung zu EDM-Nachrichten). Zu beachten ist, dass die Nachrichten EvidenceOrder und GetEvidences mit ihren jeweiligen Responses in der XNachweis-Spezifikation XNachweis-Version 0.1 zwar erwähnt, aber noch nicht ausspezifiziert sind. Bei den Namen handelt es sich um Arbeitstitel.

Die Intermediäre Plattform muss im nächsten Schritt die erhaltenen Nachweisanfragen um Informationen aus den Common Services anreichern. Für die Kommunikation mit den Common Services der EU verwendet sie die in den TDD (EU-02) definierten Nachrichten, die heißen:

• Evidence Broker: Get List of Requirements (EU-EB-02)
• Evidence Broker: Get Evidence Types (EU-EB-03)
• Data Service Directory: Find Data Services of Evidence Providers (EU-DSD-02)

Anschließend tauscht sie in ihrer Rolle als Evidence Requester die im EDM definierten Nachrichten mit den Evidence Provider im EU-Ausland aus.

5.6.1 Ablauf eines Nachweisabrufs aus dem NOOTS

Die fachlichen Schritte des Nachweisabrufs sind in der [High-Level-Architecture [AD-NOOTS-03]] beschrieben. In dem Prozess sind grundsätzlich zwei unterschiedliche, aufeinander folgende Phasen zu unterscheiden:

• Phase 1 - Vorbereitung des Nachweisabrufs: Zunächst sind eine Reihe von Schritten notwendig, um den richtigen [Data Service] und weitere Parameter für den Abruf unter Nutzung der entsprechenden Verzeichnisdienste zu ermitteln. In diesem Teilprozess kann an verschiedenen Stellen eine Interaktion mit den Nutzenden notwendig sein. Diesen Teilprozess teilen sich die beiden Akteure Data Consumer und Intermediäre Plattform. Die aktuelle Konzeption lässt flexibel verschiedene Varianten zu, welche der benötigten Angaben vom Data Consumer und welche von der Intermediären Plattform erfasst werden. Wichtig ist, dass im Ergebnis alle erforderlichen Daten für Phase 2 vorliegen.
• Phase 2 - Durchführung des Nachweisabrufs: Anschließend erfolgt der eigentliche Nachweisabruf über das EU-OOTS.

Die beiden folgenden Sequenzdiagramme zeigen einen möglichen Nachrichtenfluss zwischen den beteiligten Akteuren unter Verwendung der zuvor vorgestellten Nachrichten. Schritte im Ausland sind nur dargestellt, wenn sie eine direkte Schnittstelle zu einem der NOOTS-Akteure haben. Ablauf Nachweisabfrage durch nationalen Data Consumer von ausländischem Evidence Provider[figure.32] zeigt den Gesamtablauf, während Ablauf Nachweisabfrage durch nationalen Data Consumer von ausländischem Evidence Provider - Fokus Nutzerdialoge[figure.33] die anfallenden Nutzerdialoge zur Ermittlung der benötigten Nachweistypen und Data Services ausdetailliert.

Hinweis: Gestrichelte Pfeile stehen für die Verwendung von HTTP als Protokoll, während die durchgezogenen für XNachweis bzw. EDM-Nachrichten bedeuten.

Abb. 3: Ablauf Nachweisabfrage durch nationalen Data Consumer von ausländischem Evidence Provider

Abb. 4: Ablauf Nachweisabfrage durch nationalen Data Consumer von ausländischem Evidence Provider - Fokus Nutzerdialoge

5.6.2 Kommunikation zwischen Data Consumer und Intermediärer Plattform

Die Phase "Vorbereitung der Nachweisabfrage" wird durch den Einsatz einer Intermediären Plattform auf die beiden Akteure Data Consumer und die Intermediäre Plattform aufgeteilt. Um die Kommunikation zwischen Data Consumer und Intermediärer Plattform abzubilden, ist deshalb eine Erweiterung des ursprünglich im EDM vorgesehenen Nachrichtenmodells notwendig. Hierzu sieht das untenstehende Diagramm zwei neue Nachrichten mit dem Arbeitstiteln EvidenceOrder und GetEvidences mit jeweiliger Response vor.

Da nicht abzusehen ist, welche Informationen der Data Consumer in der Praxis über den gewünschten Nachweistyp und dessen Herkunftsland vorhält, erlaubt die aktuelle Konzeption in dieser Hinsicht Flexibilität: Sollte der Data Consumer über die Pflichtangabe des eigenen Verfahrens (procedure-id) hinaus bereits weitere Informationen haben, kann er diese in der initialen EvidenceOrder der Intermediären Plattform mitgeben. Dazu zählen

• Nachzuweisende(r) Sachverhalt(e) (requirement-id)
• Herkunftsland des Nachweises (zugeordnet zum nachzuweisenden Sachverhalt, falls mehrere)

Deren Aufgabe besteht darin, den QueryRequest durch ergänzende Abfragen der Common Services und Nutzereingaben zu vervollständigen.

5.6.3 Nutzer-Authentisierung

Nachweisabrufe über das EU-OOTS setzen zwingend eine Nutzer-Authentisierung unter Nutzung eines eIDAS-notifizierten Identifizierungsmittel voraus (Artikel 11 Abs. 1 DVO).

Für die Authentisierung der inländischen Antragstellenden ist prinzipiell der Data Consumer zuständig. Da die Intermediäre Plattform jedoch nicht zweifelsfrei davon ausgehen kann, dass diese ordnungsgemäß durchgeführt wurde, authentisiert sie die Antragstellenden auf der eigenen Nutzeroberfläche gemäß einem \"Zero Trust Ansatz\" erneut.

Sollte sich im Laufe der Feinkonzeption ein Weg finden, mit dem der Data Consumer die Authentisierung des Nutzers nachweisen kann, kann die erneute Authentisierung auf der Intermediären Plattform im Interesse der Nutzerfreundlichkeit entfallen.

5.7 Nicht-funktionale Anforderungen

Nicht-funktionalen Anforderungen müssen im Rahmen der Feinkonzeption einzelner Intermediärer Plattformen definiert und mit entsprechenden Schutzbedarfsfeststellungen unterlegt werden. Dennoch folgen Hinweise auf einige besonders zu berücksichtigende Aspekte.

5.7.1 Datenschutz

Die Intermediäre Plattform ist eine Infrastrukturkomponente, die Registerabrufe unterstützt. Sie benötigt dafür Zugriff auf personenbezogene Informationen zur Person, die um den Registerabruf ersucht, und auf die in der Registerantwort enthaltenen personenbezogenen Informationen. Die Kritikalität dieser Angaben ist auch mit Blick auf die konkret angeschlossenen Register und die von ihnen übermittelten Arten von Informationen zu bewerten. In jedem Fall handelt es sich bei Intermediären Plattformen jedoch um eine sensible Infrastruktur, die gegen einen Missbrauch dieser Daten abgesichert werden muss. Hierzu gehört auch, dass durch geeignete Maßnahmen ausgeschlossen werden muss, dass Daten aus verschiedenen Registerabrufen über die gleiche Intermediäre Plattform zusammengeführt und so für eine unzulässige Profilbildung missbraucht werden. Eine Überlegung zur Verringerung dieses Risikos ist die Einrichtung mindestens einer Intermediären Plattform pro Verwaltungsbereich, sodass zumindest Daten über Verwaltungsbereiche hinweg nicht zusammengeführt werden.

5.7.2 IT-Sicherheit

Auch aus der Perspektive der IT-Sicherheit sind hohe Anforderungen an Intermediäre Plattformen zu stellen.

Das EU-OOTS bietet für Intermediärer Plattformen und/oder Evidence Provider keine Möglichkeit, die Berechtigung einer Registerabfrage aus dem Ausland im Rahmen einer abstrakten Berechtigungsprüfung im Einzelfall vor der Datenübermittlung zu plausibilisieren. Die entsprechende Verantwortung wird von der Durchführungsverordnung bei den anfragenden Behörden verortet, die die Rechtmäßigkeit ihrer Anfragen sicherstellen müssen, und bei den jeweiligen Mitgliedstaaten, die sicherstellen müssen, dass nur zuständige Behörden Zugriff auf das EU-OOTS erhalten. Im Mitgliedstaat des Evidence Provider muss die Anfrage dann grundsätzlich als zulässig betrachtet werden. Diese aus deutscher Sicht mit Blick auf IT-Sicherheit kritische Vorgabe lässt sich nicht auf der Ebene einer Intermediären Plattform revidieren. Bei der Umsetzung einer Intermediären Plattform muss jedoch darauf geachtet werden, die potenziellen Folgen dieses Designs so gering wie möglich zu halten.

Nach aktuellem Kenntnisstand bedingt dies mindestens zwei Aspekte, die bei der weiteren Ausgestaltung Intermediärer Plattformen zu beachten sind. Zunächst müssen alle Anfragen aus dem EU-OOTS über einen Access Point als legitim betrachtet und von der Intermediären Plattform über das NOOTS weitergegeben werden. Dafür muss die Intermediäre Plattform im NOOTS eine entsprechende Stellung mit weitreichenden Zugriffsrechten auf Register erhalten. Dabei muss jedoch strikt darauf geachtet werden, dass jede Intermediäre Plattform trotzdem nur die Zugriffsrechte erhält, die für ihre jeweiligen Data Services notwendig sind, und nicht jede Intermediäre Plattform pauschal privilegierten Zugriff auf alle Data Provider des NOOTS erhält. Wie genau das zu regeln ist, ist rechtlich zu prüfen und wird in 5.8 Offener Punkt NOOTS-647 festgehalten.

Zudem sollte bei der Feinkonzeption einer Intermediären Plattform geprüft werden, welche Möglichkeiten existieren, zumindest ex-post anhand einer Auswertung von Protokolldaten Hinweise auf ungewöhnliches Abrufverhalten einzelner Evidence Requester zu erhalten und so potenzielle Missbrauchsfälle zumindest nachträglich verfolgen zu können.

Bei der umgekehrten Richtung, dass deutsche Data Consumer über die Intermediäre Plattform Nachweise aus dem europäischen Ausland anfordern, könnten die Mechanismen des NOOTS zum Identitätsmanagement von Behörden und zur abstrakten Berechtigungsprüfung genutzt werden, um sicherzustellen, dass die betreffende Behörde auf die Intermediäre Plattform zugreifen und im Rahmen ihrer Zuständigkeit grundsätzlich die betreffende Art von Nachweisen anfordern darf. Solange die übergreifenden NOOTS-Mechanismen noch nicht vollständig zur Verfügung stehen, ist dies ggf. durch lokale Maßnahmen der Intermediären Plattform zum gleichen Zweck zu ergänzen.

Bei der Umsetzung einer Intermediären Plattform ist zudem zu beachten, dass die Durchführungsverordnung zu Artikel 14 der SDG-Verordnung in einigen sicherheitsrelevanten Bereichen unmittelbare Vorgaben macht (Artikel 17, 28f DVO). So stellt die DVO explizite Vorgaben zu Art und Umfang der Protokollierung auf, die neben die ohnehin in Deutschland bereits bestehenden Anforderungen ebenfalls erfüllt werden müssen (Artikel 17 DVO). Hierzu gehört auch, dass eine technische Möglichkeit verfügbar sein muss, Protokolldaten ggf. im Rahmen der Aufklärung eines grenzüberschreitenden Missbrauchsverdachts für andere Behörden bereitzustellen. Zudem sind die Mitgliedstaaten u.a. verpflichtet, für die innerstaatliche Kommunikation der Intermediären Plattform mindestens ein mit dem grenzüberschreitenden AS4-Transportprotokoll vergleichbares Sicherheitsniveau zu garantieren (Artikel 28 Abs. 4 lit. a DVO).

Aufgrund der Konstruktion des EU-OOTS müssen Intermediäre Plattformen aus dem Internet erreichbar sein, sowohl für die Kommunikation mit den Common Services als auch zur Bereitstellung der Nutzeroberfläche. Zugleich kommunizieren Intermediäre Plattformen mit einem Teil der angeschlossenen zuständigen Behörden in Deutschland über gesicherte Verwaltungsnetze. In welchem Netz der Access Point liegt und wie die Intermediäre Plattform mit diesem zu kommunizieren hat, ist noch offen.

In jedem Fall muss die Intermediäre Plattform an die genannten Netze angebunden sein. Daraus ergibt sich die Notwendigkeit eines sicheren Managements des Netzübergangs, für das alle entsprechenden Vorgaben des BSI einzuhalten sind.

5.7.3 Verfügbarkeit, Antwortzeit und Last

Einen Hinweis auf die erforderliche Verfügbarkeit der Intermediären Plattform gibt Artikel 27 der Durchführungsverordnung zu Artikel 14 SDG-VO. Dort wird normiert, dass das EU-OOTS rund um die Uhr betrieben wird, sowie eine Mindestverfügbarkeit der Access Points und Preview-Spaces von 98% (exklusive planmäßiger Wartungen).

Diese Anforderung bezieht sich jedoch auf den Access Point, nicht auf die dahinter liegenden Teilnehmer des EU-OOTS, also die Data Provider, angeschlossenen Data Consumer oder Intermediären Plattform. Deren Verfügbarkeit wird in Service Level Agreements zwischen Kommission und Mitgliedstaaten festgelegt (Artikel 27 Abs. 1 DVO).

Für Antwortzeitverhalten und Lastfähigkeit einer Intermediären Plattform können aktuell keine präzisen Anforderungen benannt werden. Es ist jedoch zu beachten, dass Nachweisabrufe im EU-OOTS aus der interaktiven Benutzung eines Online-Antrags heraus erfolgen. Dies erfordert in jedem Fall ausreichend kurze, quasi-synchrone Reaktionszeiten.

5.8 Offene Punkte