Nachrichtenbroker. Funktionsbeschreibung Version 1.2. Aktualisiert am: 02. Januar 2017 Florian Muhlack, Dieter Schlüter und Florian Kuhn

Transkript

1 Funktionsbeschreibung Version 1.2 Aktualisiert am: 02. Januar 2017 Autoren: Florian Muhlack, Dieter Schlüter und Florian Kuhn Funktionsbeschreibung V1.2.docx Seite 1 von 23

2 Dokumentenstatusinformation Dokumentenname Funktionsbeschreibung V1.1.docx Ersterstellungsdatum Freitag, 2. November 2012 Versionsnummer 1.2 Historie Datum Änderung Person Erstellung Funktionsbeschreibung Version 1.0 Auslieferung an die fachlichen Leitstellen Abnahme durch die fachlichen Leitstellen Kleinere Korrekturen auf Rückmeldung von Fr. Coenen Aktualisierungen z.b. Auflistung der neu hinzugekommenen Dienste, Erweiterung um den XTA 2.0 Webservice Aktualisierung z.b. Auflistung der neu hinzugekommenen Dienste, Wegfall Transportdispatcher Florian Muhlack und Dieter Schlüter Herr Nadler (FB FHH) und Herr Schmidtke (ZIT S-H) Dieter Schlüter und Florian Muhlack Florian Muhlack Florian Kuhn Aktualisierungen: Statistikzahlen, Übersicht Dienstpakete Dieter Schlüter Funktionsbeschreibung V1.2.docx Seite 2 von 23

3 1 Kurzbeschreibung Definition Abgrenzung zu anderen Produkten Interessenlage der Kunden Vorteile des s Architektur Systemumgebungen Schutzbedarf Mandantenfähigkeit Begriffsabgrenzung Mandant Mandantenorientiertes Berechtigungskonzept Berechtigungsprüfung Verwaltung von Mandanten Vermittlungswege Kommunikation über das Intranet Der XTA-WS interne Systeme Kommunikation über das Internet/Verbindungsnetz des Bundes OSCI-Transport XTA Gatewaypostfächer Beispielszenarien Datenabruf nach 38 BMG Vermittlung über XTA Vermittlung über OSCI-Transport Datenübermittlung zwischen den Standesämtern Vermittlung über XTA Der Versand Der Empfang Vermittlung über OSCI-Transport Der Versand Der Empfang Statistikzahlen Vermittelte Nachrichten für die Jahre 2009 bis Vermittelte Nachrichten in 2016 nach Dienstpaketen Brokerdienste Übersicht Brokerdienste Übersicht Brokerdienste mit den dazugehörigen Schnittstellen...22 Funktionsbeschreibung V1.2.docx Seite 3 von 23

4 1 Kurzbeschreibung 1.1 Definition Der (MessageBroker) ist eine zentrale Vermittlungsstelle, die man sich als Datendrehscheibe vorstellen kann. Sie unterstützt und optimiert technisch und organisatorisch Kommunikationsvorgänge unterschiedlichster DV-Verfahren im Auftrag. Aufgabenschwerpunkt ist daher die sichere Maschine (Fachverfahren) zu Maschine (Fachverfahren) Kommunikation für XÖV-Nachrichten. Der ist eine zentrale egovernment Infrastrukturkomponente der Trägerländer. Zurzeit wird der von den Bundesländern Schleswig- Holstein, Hamburg, Sachsen-Anhalt und Bremen genutzt. Der steht in der Shared-Intranet DC des BSI-zertifizierten Rechenzentrums von (RZ²), so dass er von Systemen aus den jeweiligen Landesnetzen sowie internen Netzen genutzt werden kann. Um auch für über das Internet ankommende Systeme genutzt werden zu können, bedient sich der anderer egovernment-bausteine wie eines Intermediäres (des Governikus) und des GovernmentGateways. Auf Basis der zentralen egovernment Infrastrukturkomponente sind diverse fachverfahrensspezifische Brokerdienste (z.b. XMeld Datenübermittlungen oder xdomea elektronischer Aufgrabeschein ) implementiert. Dadurch kann den individuellen Fachverfahrensanforderungen Rechnung getragen werden. Dabei bietet der eine zentrale Infrastruktur zur Kommunikationsabwicklung, einen professionellen Rechenzentrumsbetrieb, eine Sende- und Empfangsbereitsschaft im 7*24 Stunden-Betrieb, eine professionelle Applikationsbetreuung, Brokerdienste, die die Kommunikation technisch und organisatorisch unterstützen und optimieren, diverse Dienstleistungen z.b. fachspezifischer Stammdatenservice Funktionsbeschreibung V1.2.docx Seite 4 von 23

5 1.2 Abgrenzung zu anderen Produkten Der hat keine eigene Internetempfangsschnittstelle, sondern bedient sich beim Empfang aus dem Internet anderer egovernment-komponenten z.b. Governikus, GovernmentGateway. Im Gegensatz zum Intermediär (Governikus) darf der Nachrichteninhalte im Rahmen der Auftragsdatenverarbeitung lesen. Außerdem bietet der über OSCI-Transport hinaus eine Vielzahl weiterer Transportprotokolle. Im Gegensatz zum Governikus MultiMessenger ( liegt der Schwerpunkt nicht auf der Mensch zu Mensch Kommunikation, sondern auf die Maschine zu Maschine Kommunikation. Im Gegensatz zu EGVP (Elektronisches Gerichts- und verwaltungspostfach) liegt der Schwerpunkt nicht auf der Mensch zu Mensch Kommunikation, sondern auf die Maschine zu Maschine Kommunikation. Außerdem bietet der über OSCI-Transport hinaus eine Vielzahl weiterer Transportprotokolle. 1.3 Interessenlage der Kunden Die Kunden wollen die rein kommunikationsbedingten Aufgaben ihrer Fachverfahren (Stichwort: Maschine zu Maschine) an einen zentralen Auftraggeber (hier ) outsourcen. Damit werden insbesondere folgende Ziele bezweckt: Erhöhung der Zuverlässigkeit Datensicherheit z.b. durch Protokollierung Kostenersparnis Standardisierung 1.4 Vorteile des s Der ist eine vergleichsweise preiswerte und extrem leistungsfähige Vermittlungsplattform, da außer den Applikations- und Datenbankservern keine weiteren Server und Lizenzen benötigt werden. Durch die Clusterfähigkeit und direkte Queue-Programmierung ist das System ausbaufähig. Funktionsbeschreibung V1.2.docx Seite 5 von 23

6 Ein weiterer Vorteil des s sind fachspezifische Stammdatenservices. Der stellt seine Daten (Behördendaten, Gemeindedaten, gebuchte Dienste) anderen egovernment-basislösungen zur Verfügung z.b. GovernmentGateway, Mehrländer Meldespiegeldatensystem Hamburg, Schleswig-Holstein und Sachsen-Anhalt, Spiegeldatenbank Gewerbe. Durch den eigens für die Applikationsbetreuung erstellten Brokerclient ist eine professionelle Applikationsbetreuung möglich. Da es sich beim um eine Eigenentwicklung handelt, können Softwareanpassungen flexibel und schnell gehandhabt werden. Es besteht eine DVDV-Anbindung für Routing, Behördenanfragen und Verifikation. Der kann synchron und asynchron über folgende Wege erreicht werden: o o Über das Internet und das Verbindungsnetz des Bundes mittels OSCI- Transport Version 1.2 Über die jeweiligen Landesnetze oder interne Netze mittels XTA in den Versionen 1 und 2. Der kann synchron und asynchron über folgende Wege zustellen: o o Über das Internet und das Verbindungsnetz des Bundes mittels OSCI- Transport Version 1.2 Über die jeweiligen Landesnetze oder interne Netze mittels XTA in den Versionen 1 und 2, diverse andere Webservice z.b. Gatewaypostfächer und sftp. Der bietet Konvertierungsmöglichkeiten wie z.b. XStatistik - PDF Eine verhältnismäßig schnelle Realisierung von neuen Fachdiensten ist durch die Nutzung vorhandener Bausteine möglich ( Generischer ). Durch umfangreiche Konfigurationsmöglichkeiten (z.b. welcher Kunde darf welchen Dienst nutzen, welchen Datenumfang und welches Datenformat erhält der Empfänger, wie lange sollen bei Nichterreichbarkeit des Empfängers die Zustellversuche laufen) können kundenspezifische und rechtliche Anforderungen berücksichtigt werden. Rechtskonformer Transport von Nachrichten Funktionsbeschreibung V1.2.docx Seite 6 von 23

7 Sicherheitsnachweis auf Basis der sich an die BSI Systematik orientierenden IT-Sicherheitsleitlinie für Anwendungen mit dem Schutzbedarf hoch Abbildung 1 Generischer 2 Architektur 2.1 Systemumgebungen Der ist eine Eigenentwicklung von. Er wurde programmiert in MS.NET und basiert auf dem Queuing des MS SQL-Servers. Die Stage- (Abnahme-) und Produktions-Umgebungen des s stehen im BSI-zertifizierten Rechenzentrum von (RZ²). Zusätzlich gibt es noch eine kombinierte Entwicklungs-/Fachtestumgebung. Diese steht in der RZ²-Cloud. Die Produktionsumgebung besteht aus folgenden Servern: Funktionsbeschreibung V1.2.docx Seite 7 von 23

8 3 virtuelle, geclusterte Applikationserver auf Basis der Microsoft Internet Information Services (II S) 2 virtuelle, failover Datenbank-Cluster ( = Verbund von Computern (Cluster)), in dem bei einem Ausfall eines Rechners ein zweiter Rechner dessen Aufgaben übernimmt) mit dem MS SQL Server 2.2 Schutzbedarf Der besitzt den Schutzbedarf hoch. Einer der Hauptgründe dafür ist die Vermittlung von personenbezogenen Daten mit entsprechendem Schutzbedarf wie z.b. Religion, Steuerdaten, Adoptionsdaten, Auskunftssperren, biometrische Daten für Ausweisanträge und Volkszugehörigkeiten. Um den Schutzbedarf zu gewährleisten, gibt es diverse Sicherheitsmaßnahmen auf Seiten des s z.b.: SSL-Authentifizierung nicht nur für alle Kundenbeziehungen, sondern auch bei der Kommunikation zwischen den verschiedenen Systemen bei z.b. Mehrländer Meldespiegeldatensystem SSL-Authentifizierung und Prüfung gegenüber Fachidentifikation und Kundenaccount Es werden nur SSL-Zertifikate aus den CAs und aus den CAs der PKI Verwaltung verwendet und akzeptiert. Extrem hoher Standard bei den generischen und fachspezifischen Sicherheitsprüfungen der software Sicherstellung der Protokollierung aller Fälle Umfangreiche Applikationsbetreuung Netztechnische Segmentierung der systeme Server- und Verfahrenshärtung mit an das Verfahren angepasster Härtung Aktuelle Windows-Betriebssysteme und SQL-Server Versionen Administrative Zugriffe nur über die Admin-Plattform Integrierte Datenbanksicherheit für die Verbindungen zum SQL-Server Nutzung eines gesonderten Virenscanservices für alle empfangenen Nachrichten 3 Mandantenfähigkeit 3.1 Begriffsabgrenzung Mandant Der ist mandantenfähig. Funktionsbeschreibung V1.2.docx Seite 8 von 23

9 Unter einem Mandanten wird eine am angeschlossene konkrete Institution (Behörde oder Firma) verstanden. Diese nimmt die Rolle als Autor bzw. Leser von Nachrichten wahr. Abbildung 2 Abgrenzung Fachverfahren XTA - Transportmedium Aus Sicht des s handelt es sich bei Mandanten um Accounts (Kundenpostfächer). Der Mandant bedient sich eines Fachverfahrens um Nachrichten mit Hilfe des s zu versenden bzw. zu empfangen. Dabei kann zwischen einem organisatorischen und einem technischen Mandantenbegriff unterschieden werden. Wie der Mandant geschnitten wird, ist allein Entscheidung des Auftraggebers und richtet sich insbesondere an den Möglichkeiten seines Fachverfahrens aus. Beispiel 1: Eine Ausländerbehörde (organisatorischer Mandant) repräsentiert einen Account (technischer Mandant) gemeinsam für die Spezifikationen XAusländer, XPersonenstand und XhD, weil diese durch ein gemeinsames Fachverfahren abgewickelt werden. Beispiel 2: Eine Ausländerbehörde (organisatorischer Mandant) repräsentiert drei Accounts (technische Mandanten) getrennt für die Spezifikationen XAusländer, XPersonenstand und XhD, weil diese durch verschiedene Fachverfahren abgewickelt werden oder das Fachverfahren eine Trennung erfordert Mandantenorientiertes Berechtigungskonzept Authentifizierung Zur Authentifizierung sind nur von WS-Interoperability zertifizierte Webservicestandards zugelassen. Die vom angebotenen Webserviceschnittstellen erlauben ausschließlich die SSL-Client-Authentifizierung. Funktionsbeschreibung V1.2.docx Seite 9 von 23

10 Autorisierung Im Regelfall wird über das SSL-Zertifikat der Zugriff auf einen Account beim autorisiert. Wenn dem Zertifikat mehrere Accounts zugeordnet sind, gibt es zusätzlich die Möglichkeit optionale Attribute zu füllen. Diese Parameter zu den Absenderangaben identifizieren zusammen mit dem Zertifikat einen Account beim. Mandant und Account Es tritt immer eine konkrete Institution als Autor (Versand von Nachrichten) oder Leser (Empfang von Nachrichten) einer Nachricht auf. Diese Institution ist aus Sicht des Fachverfahrens ein Mandant. Eine Instanz des Fachverfahrens wird häufig von mehreren Behörden genutzt. Aus Sicht des s werden Accounts verwaltet. Accounts können wie folgt bestimmt werden: Alternative 1: Über ein Zertifikat, das nur für einen einzigen Mandanten gültig ist (Authentifizierung). Alternative 2: Über ein Zertifikat, das für mehrere Mandanten gültig ist (Authentifizierung) und die dazugehörigen mandantenspezifischen Informationen für die Behördenkennung (Autorisierung) Berechtigungsprüfung Es gibt eine mehrstufige Berechtigungsprüfung Schritt 1: Der Zugriff auf Accounts ist nur für netztechnisch auf die Webservices des s freigeschaltete Kunden möglich. Schritt 2: Der IIS der Web- und Applikationserver des s lässt nur Anfragen durch, deren SSL-Zertifikate gültig sind und deren gesamte Zertifikatsketten prüfbar sind. Schritt 3: Prüfung ob das SSL-Zertifikat in der datenbank bei den aktiven Accounts hinterlegt ist. Schritt 4: Prüfung ob die mandantenspezifischen Informationen passen. Schritt 5: Prüfung, ob eine Nachricht eindeutig einem Account zugeordnet werden kann. Diese Prüfung geschieht mit Hilfe der Angaben für die Autorisierung, der Authentifizierung und der Dienstebezeichnung. Schritt 6: Prüfung ob das verwendete Signaturzertifikat des Absenders im DVDV für die Absenderbehördenkennung hinterlegt ist (nur bei OSCI-Transport). Funktionsbeschreibung V1.2.docx Seite 10 von 23

11 Durch diese mehrstufige Berechtigungsprüfung wird gewährleistet, dass technische Mandanten nur eigene Nachrichten versenden und empfangen können. Dies gilt auch für die dazugehörigen Transportreports Verwaltung von Mandanten Die Einrichtung, Änderung, Inaktivierung und Löschung von Mandanten geschieht über den Brokerclient. Damit wird sichergestellt, dass nur über freigegebene Programme Änderungen vorgenommen werden. Außerdem gewährleisten zahlreiche Plausibilitäten, dass Mindeststandards bei den Mandantendaten garantiert werden z.b. kann kein Mandant ohne die erforderlichen Authentifizierungs- und Autorisierungsdaten angelegt werden. Ebenso werden Fehlbedienungen verhindert z.b. Löschung eines Mandanten mit noch vorhandenen Nachrichten. 4 Vermittlungswege Im folgenden Unterkapitel sollen die verschiedenen Vermittlungswege mit allen dazugehörigen Komponenten aufgezeigt und kurz erläutert werden. 4.1 Kommunikation über das Intranet Der XTA-WS Die XTA-WS-Schnittstelle ist für die Kommunikation innerhalb geschlossener Netze vorgesehen. Sie ist eine bundesweit einheitliche Schnittstelle und bietet den Vorteil, alle mit einem XTA-Client implementierten Fachverfahren ohne größeren Aufwand an den anschließen zu können, da diese Schnittstelle bundesweit spezifiziert ist. Die Spezifikation XTA-WS gibt es in zwei Versionen: XTA-WS 1: Die Dokumentation steht unter der Adresse zum Download zur Verfügung XTA-WS 2: Die Dokumentation steht unter der Adresse zum Download zur Verfügung Die Version XTA-WS 1 ist ein sogenannter Industriestandard. Die Nachfolgeversion XTA-WS 2 ist ein Projekt des IT-Planungsrates. Fachverfahren die derzeit noch nicht in der Lage sind, den XTA-WS des s durch einen implementierten XTA-Client anzusprechen, werden XTA-fähige Transportagenten zur Verfügung gestellt. Funktionsbeschreibung V1.2.docx Seite 11 von 23

12 4.1.2 interne Systeme Der kommuniziert innerhalb des Rechenzentrums mit diversen internen Systemen wie z.b. egewerbe, diversen Goverment-Gatewayfachverfahren, sftp-servern. 4.2 Kommunikation über das Internet/Verbindungsnetz des Bundes OSCI-Transport Wie in 1.2 erwähnt, bedient sich der weiterer egovernment-komponenten für die Übermittlung von Nachrichten über das Internet bzw. das Verbindungsnetz des Bundes. Bei OSCI-Transport in der Version 1.2 ist dies der -Governikus (Intermediär). Bei OSCI-Transport handelt es sich um einen Protokollstandard für rechtssichere und medienbruchfreie Datenübermittlung im egovernment-umfeld XTA Die Schnittstelle XTA basiert auf der universellen, bundesweiten Schnittstelle XTA-WS in der Version (XTA-WS für XÖV Transport-Adapter- WebService). Wie oben beschrieben, ist die XTA-WS-Schnittstelle nur für die Kommunikation innerhalb geschlossener Netze vorgesehen. Damit diese Schnittstelle auch übers Internet nutzbar ist, wurde, basierend auf der XTA-WS-Schnittstelle, die spezifische Schnittstelle XTA geschaffen. Die Schnittstelle XTA ist nur mit Hilfe der Infrastruktur des GovernmentGateways nutzbar. Daher beinhaltet die Schnittstelle XTA auch die Erfordernisse der GovernmentGateway Ticketverwaltung. Bei diesem Szenario kommunizieren der XTA-Client als Komponente des Fachverfahrens und der XTA miteinander. Dabei nimmt der XTA alle Aufträge vom Webservice-Client synchron entgegen und transportiert diese je nach XÖV- Spezifikation synchron oder asynchron weiter. Der Versand von XÖV-Nachrichten kann zum Beispiel an einen anderen vom XTA verwalteten Account erfolgen oder an extern verwaltete Behörden/Institutionen. Für den sendenden XTA-Client ist vollkommen transparent, wie die Nachricht versandt wird und welches Transportszenario zur Anwendung kommt. Es werden unabhängig von der Versandart immer die gleichen Methoden, Parameter und Rückgabewerte genutzt. Die konkret genutzte Versandart kann dem abgeholten Transportprotokoll entnommen werden. Der XTA kann durch mehrere Webservice-Clients gleichzeitig angesprochen werden und deren Anfragen parallel verarbeiten. Funktionsbeschreibung V1.2.docx Seite 12 von 23

13 Der Zugang aus dem Internet erfolgt über die Infrastruktur des GovernmentGateways. Die Berechtigung zur Teilnahme an diesem Dienst wird über die Benutzerverwaltung einer Fachanwendung des GovernmentGateways geprüft. Bisher wird dieses Szenario von der GovernmentGateway Fachanwendung Aufgrabeschein Maschinenschnittstelle genutzt. Damit eine Teilnahme möglich ist, muss die teilnehmende Organisation/Firma durch einen sogenannten Masteruser im HamburgService registriert sein und den Dienst abonniert haben. Der Masteruser kann die Benutzer einrichten und verwalten, welche den Dienst tatsächlich nutzen sollen. Die Kommunikation mit dem XTA erfolgt ausschließlich mittels SSL- Verschlüsselung. Diese Schnittstellenversion erlaubt eine Authentifizierung und Autorisierung mittels Benutzerkennung und Passwort mit Hilfe der Methode Login, die das für die Nutzung der weiteren Methoden notwendige Sessionticket zur Verfügung stellt Gatewaypostfächer Der Versand an Gatewaypostfächer ist ein asynchrones Kommunikationsszenario. Auf die Gatewaypostfacher können die Behörden übers Internet zugreifen. Ein Beispiel für diesen Vermittlungsweg ist die Übermittlungen von Gewerbeanzeigen. 4.3 Beispielszenarien In diesem Kapitel wird jeweils ein Beispiel für synchrone und asynchrone Kommunikation aufgezeigt Datenabruf nach 38 BMG Im Folgenden wird der Versand und Empfang von Nachrichten am Beispiel des synchronen Datenabrufs nach 38 BMG über XTA und OSCI-Transport näher beschrieben. Hierbei handelt es sich um ein synchrones Kommunikationsszenario. Funktionsbeschreibung V1.2.docx Seite 13 von 23

14 Abbildung 3 synchrone Kommunikation beim Datenabruf nach 38 BMG Vermittlung über XTA Die abrufende Stelle Behörde A richtet über den XTA-Client Ihres Fachverfahrens eine Anfrage an den XTA-WS des s. Der führt folgende XTA-spezifische Plausibilitäten durch: Authentifizierungs- und Autorisierungsprüfungen Prüfung der übergebenen Parameter der XTA-WS Methode SendMessageSync Virenprüfung Prüfung ob es ein Dienstpaket für den übermittelten Nachrichtentyp gibt Übergabe der Nachricht an den Fachadapter ermittelten Fachadapter des s Der Fachadapter für die synchronen Datenabrufe führt folgende Plausibilitäten durch: Funktionsbeschreibung V1.2.docx Seite 14 von 23

15 Prüfung ob das Dienstpaket vom Kunden gebucht worden ist. Schema- und Encodingprüfung Prüfung ob der Dienst in der angeforderten Version noch erlaubt ist Prüfung der Behördenkategorie mit Hilfe des DVDVs Wenn in der Anfrage das Element Sicherheitsbehörde gesetzt ist, wird dies gegen die Behördenkategorie verifiziert Prüfung ob die Anfrage intern oder über DVDV geroutet werden muss Prüfung ob der Leser das erforderliche Dienstpaket anbietet Prüfung der Antwort (Schema, Encoding, Version, Viren) Die von der Auskunft gebenden Stelle zurückgelieferte Antwort leitet der über den XTA-WS an das Fachverfahren der Behörde A weiter. Da die Kommunikation synchron erfolgt, ist das Fachverfahren der Behörde A nach dem Senden seiner Anfrage so lange blockiert, bis es eine Antwort auf die Anfrage empfangen hat. Dies dauert im Regelfall nur wenige Sekunden Vermittlung über OSCI-Transport Die abrufende Stelle der Behörde B sendet eine Anfragenachricht an den OSCI-Account des -Governikus. Die Anfragenachricht wird dann an die dort hinterlegte Webserviceadresse des s weitergeleitet. Der führt OSCI-Transport spezifische Plausibilitäten durch: Prüfung der Ref-ID des Inhaltsdatencontainers Inhaltscontainers Virenprüfung Prüfung, ob es sich um ein XML handelt Prüfung des Signaturalgorithmus Auswertung aller Zertifikatsinformationen des OSCI-Laufzettels (Online-Prüfung, Offline-Prüfung, Mathematische Prüfung) Prüfung, ob für den übermittelten Nachrichtentyp ein Dienstpaket hinterlegt ist und der Empfang erlaubt ist Prüfung, ob die Absenderbehördenkennung im DVDV vorhanden ist Prüfung ob das Signaturzertifikat des Absenders zur Kategorie und Behördenschlüssel der Absenderbehördenkennung (DVDV-Client-Zertifikat) passt Prüfung ob die Kennung des Lesers einem Kunden zugeordnet werden kann Prüfung ob ein Dienstpaketadapter für den übermittelten Nachrichtentyp hinterlegt ist Danach kommen die vom Fachadapter für die synchronen Datenabrufe durchgeführten Plausibilitäten (siehe ). Die von der Auskunft gebenden Stelle zurückgelieferte Antwort leitet der mittels OSCI-Transport an das Fachverfahren der Behörde B weiter. Funktionsbeschreibung V1.2.docx Seite 15 von 23

16 4.3.2 Datenübermittlung zwischen den Standesämtern Es wird die asynchrone Kommunikation beim Versand und Empfang von Nachrichten aus dem Fachstandard XPersonenstand über OSCI-Transport und XTA näher beschrieben. Abbildung 4 asynchrone Kommunikation bei der Datenübermittlung zwischen den Standesämtern Vermittlung über XTA Der Versand Der XTA-Client des Fachverfahrens des Standesamt A bzw. der Transportagent sendet die Nachricht an einen Webservice des s (siehe 4.1). Der führt analog dem Beispiel unter diverse Plausibilitäten durch. Sollten alle Prüfungen des s erfolgreich gewesen sein, erfolgt die Zustellung der empfangenen Nachricht an das Postfach des Standesamt B Der Empfang Die Verwaltung des Standesamt B holt die Nachricht mittels eines XTA-Clients ab und verarbeitet diese weiter. Funktionsbeschreibung V1.2.docx Seite 16 von 23

17 Vermittlung über OSCI-Transport Der Versand setzt als Intermediär den Governikus der Fa. Governikus KG ein. Auf dem -Governikus befinden sich neben hunderter anderer Postfächer auch die Intermediärspostfächer des s. Diese sind nach fachlichen und lasttechnischen Gesichtspunkten getrennt. Der holt alle eingegangene Nachricht aus seinem XPersonenstands- Intermediärspostfach in voreingestellten Zeitintervallen ab. Dazu gehören auch die vom Standesamt C via OSCI-Transport übermittelten Nachrichten. Der führt analog dem Beispiel unter diverse Plausibilitäten durch. Sollten alle generischen Prüfungen des s erfolgreich gewesen sein, erfolgt die Zustellung der empfangenen Nachricht an das Postfach des kunden z.b. Standesamt B Der Empfang Siehe Statistikzahlen 5.1 Vermittelte Nachrichten für die Jahre 2009 bis 2016 Nachrichten Nachrichten Abbildung 5 Diagramm Anzahl vermittelter Nachrichten Funktionsbeschreibung V1.2.docx Seite 17 von 23

18 5.2 Vermittelte Nachrichten in 2016 nach Dienstpaketen XMeld Datenübermittlungen XMeld Datenabrufe synchron XAusländer Datenübermittlungen XPersonenstand Datenübermittlungen XMeld XMeldIT Filetransfer XMeld VAMS xdomea Aufgrabeschein XhD Bundesdruckerei sonstige Abbildung 6 Diagramm Nachrichten nach Dienstpaketen 6 Brokerdienste 6.1 Übersicht Brokerdienste Funktionsbeschreibung V1.2.docx Seite 18 von 23

19 Brokerdienstname Kurzbeschreibung des Brokerdienstes Spezifikation Art der Vermittlung produktiv seit XMeld Datenübermittlung XMeld Meld IT Filetransfer DatMLRaw egewerbe Datenübermittlungen (DÜ) auf Basis von XMeld z.b. Rückmeldungen, Fortschreibungen, Datenaustausch mit dem Bundeszentralamt für Steuern und der Rentenversicherung, Führungszeugnisanträge, Datenübermittlungen an Ausländerzentralregister, Bundesverwaltungsamt, Landesrundfunkanstalten, Kirche, Statistische Landesämter, Wehrverwaltung, Kraftfahrtbundesamt, Bundeszentralregister. Erstaufbau und Aktualisierung eines zentral gespiegelten Meldedatenbestandes der Länder Hamburg, Sachsen-Anhalt und Schleswig-Holstein. Außerdem werden die für die Erzeugung von zentralen Mitteilungsdienstdateien erforderlichen Daten vor/nach Änderung abgeholt. Mit dem Dienstpaket Filetransfer werden Daten transportiert, für die es keine speziellen fachlichen Dienstpakete gibt. Es gibt z.b. folgende Anwendungsbereiche: Übermittlung von Druckdateien für Wählerverzeichnisse und Wahlbenachrichtigungskarten, Anfragen an das Gewerbezentralregister, Datenübermittlungen an die Polizei und das LaSD, Früherkennungsuntersuchungen bei Kindern, Schülerdaten Erstaufbau und Aktualisierung eines zentralen gespiegelten Gewerbebestandes. Auf Basis der Aktualisierungen werden Weiterleitungen für diverse Empfänger generiert und übermittelt. Ebenso werden im GovermentGateway erzeugte Gewerbemeldungen an die Gewerbeämter weitergeleitet. XMeld asynchron Jan XMeld asynchron Juni 2007 Filetransfer asynchron Aug XStatistik asynchron Sept XMeld VAMS Vorausgefüllter Meldeschein XMeld synchron Okt Funktionsbeschreibung V1.2.docx Seite 19 von 23

20 xdomea Baupruef Weiterleitungen von Daten zwischen den Beteiligten im Baugenehmigungsverfahren. Dies sind sowohl kunden, wie auch GovermentGateway-Fachverfahren. xdomea asynchron April 2009 XhD BDr Kommunikationsprozesse zwischen Pass-, Personalausweis- und Ausländerbehörden einerseits und der Bundesdruckerei andererseits. Dabei handelt es sich um die Abwicklung von Bestellvorgängen für Reisepässe, Personalausweise, Reiseausweise und elektronische Aufenthaltstitel. XhD asynchron u. synchron (Expressbestellungen) Juni 2010 XhD Sperrdienst xdomea eags XAusländer Datenübermittlungen XPersonenstand Datenübermittlungen XAusländer BAMFsync Sperrmeldungen der Personalausweis- und Ausländerbehörden mit dem zentralen Sperrdienst beim Bundesverwaltungsamt. Weiterleitungen von Daten zwischen den Beteiligten für den elektronischen Aufgrabeschein. Dies sind sowohl kunden, wie auch GovermentGateway- Fachverfahren. Datenübermittlungen auf Basis XAusländer z.b. zwischen Ausländerbehörden, Melde- und Ausländerbehörden, Standesämtern und Ausländerbehörden und Ausländerbehörden und dem Bundesamt für Migration und Flüchtlinge Datenübermittlungen (DÜ) auf Basis XPersonenstand z.b. Nachrichtenaustausch zwischen Standesämter, DÜ an Meldebehörden, das zentrale Testamentsregister, Standesamt I in Berlin, Statistik und Gesundheitsbehörden. Nachrichtenaustausch zwischen Standesämtern und Ausländerbehörden Synchroner Versand und Empfang mit dem Bundesamt für Migration und Flüchtlinge XhD synchron Okt xdomea asynchron Juni 2011 XAusländer asynchron Nov XPersonenstand asynchron April 2012 XAusländer synchron Nov Funktionsbeschreibung V1.2.docx Seite 20 von 23

21 Filetransfer ZS Sync XMeld Datenabrufe XInneres Datenübermittlungen XStatistik XGewerbeanzeige xdomea AFM Übermittlung von Informationen der Liefersysteme an das ZS (ZS steht für Zentrales Speichersystem. Das ZS ist eine Architekturkomponente für die Speicherung von Informationen für das Hamburger Informationsregister.) mit Hilfe des s. Zugriffe gemäß 38 BMG: Einfache Behördenauskunft, Sicherheitsbehörden, Erweiterte Behördenauskunft. Einheitliche Übermittlung von Nachrichten innerhalb der Standards XMeld, XPersonenstand und XAusländer (z.b. Weiterleitung bei Nicht- Zuständigkeit, Rückweisungsnachrichten) Übermittlung von Gewerbemeldungen an empfangsberechtigte Stellen z.b. Industrie- und Handelskammern, Handwerkskammern, Immissionsschutzbehörden, Arbeitsschutzbehörden, Deutsche Gesetzliche Unfallversicherung, Zollverwaltung, Registergerichte, Statistische Landesämter, Lebensmittelüberwachungsbehörden, Landkreise Übermittlung von Antrags- und Fallmanagement Daten im Kontext EU-DLR (z.b. Beantragung kleiner Waffenschein) Filetransfer synchron Januar 2014 XMeld asynchron und synchron Oktober 2015 XInneres asynchron Oktober 2015 XStatistik asynchron Januar 2016 xdomea asynchron Februar 2016 Asyl Online Auskunft Abfragen an das Workflow- und Dokumenten Management System beim Bundesamt für Migration und Flüchtlinge XAusländer (angelehnt) synchron März 2016 Asyl DÜ Quartierumzug Datenübermittlung von Aufnahmeeinrichtungen an die Ausländerbehörde Hamburg XAusländer (angelehnt) asynchron Mai 2016 Datatransfer MTD Auf Basis der Änderungsmitteilungen an das Mehrländer Spiegeldatensystem werden Mitteilungsdienste für verschiedene Empfänger erstellt und vermittelt. Datatransfer (XMeld angelehnt) asynchron August 2016 Funktionsbeschreibung V1.2.docx Seite 21 von 23

22 6.2 Übersicht Brokerdienste mit den dazugehörigen Schnittstellen Schnittstelle Versand Empfang Brokerdienste Intranet (XTA- WS) 1 Internet (OSCI) 2 Intranet (WS) 3 Internet (Gateway- PF) 4 Intranet (sftp) 5 Intranet (XTA- WS) 6 Internet (XTA NB) 7 Internet (OSCI) 8 XMeld DÜ x x x x XMeld Meld IT x x x Filetransfer x x x x DatMLRaw egewerbe x x x x XMeld VAMS x x x x x xdomea Baupruef x x x x XhD BDr x x x x Erläuterungen: 1 Versand an das -Postfach, Abholung über die XTA-WS Schnittstelle 2 Versand über OSCI-Transport Versand an interne Webservices z.b. an den Webservice der Mehrländer MeldespiegeldatenSystem 4 Versand über geschlossene Netze an Gatewaypostfächer. Der Gateway-User holt die Nachricht aus seinem Gatewaypostfach ab. 5 Versand über sftp 6 Empfang über die bundesweit einheitliche XTA-WS Schnittstelle 7 Empfang über das Internet mittels eines Gateway-Fachverfahrens über die Schnittstelle XTA 8 Empfang über das Internet mittels eines OSCI-Accounts auf dem Governikus Funktionsbeschreibung V1.2.docx Seite 22 von 23

23 XhD Sperrdienst x x x xdomea eags x x x x x XAusländer DÜ x x x x XPersonenstand DÜ x x x x XAusländer BAMFsync x x x Filetransfer ZS Sync x x x XMeld Datenabrufe x x x x x xdomea AFM x x x x XInneres DÜ x x x x XStatistik XGewerbeanzeige x x x x Asyl Online Auskunft x x x Asyl DÜ Quartierumzug x x Datatransfer MTD x x Funktionsbeschreibung V1.2.docx Seite 23 von 23