sync Funktionsbaustein: Datenaustauschfeedback
| Eigenschaft | Wert |
|---|---|
| Kennung | DArch-FBS-DAU |
| Hauptfähigkeit | E-Government |
| Geschäftsfähigkeit | E-Gov-Basisdienste |
| Version | 0.3 (13.05.2026) |
| GovStack-Bezug | Information Mediator Building Block |
| Referenzprodukte | FIT-Connect (FITKO), Eclipse Dataspace Connector (EDC), NOOTS (FITKO), Dataspace Protocol (DSP) |
summarize 1 Management Summaryfeedback
Der Baustein „Datenaustausch" sorgt für den vertraulichen und sicheren Austausch von Daten in einer Systemumgebung, die die erforderlichen IT-Sicherheitsbedingungen erfüllt. Diese Umgebung ist auf die Anforderungen eines Datenaustauschs sowohl innerhalb der Bundesverwaltung als auch zwischen der Bundesverwaltung und der Zivilgesellschaft sowie Ländern und Kommunen abgestimmt. Der Baustein stellt keine eigene Datenhaltung bereit und ist produktneutral beschrieben.
Datenaustausch und Nachweisdatenabruf (NDA) ergänzen sich. Der Baustein Datenaustausch beschreibt den generischen, sicheren Transport von Daten zwischen Systemen (z. B. Antragsdaten, Bescheide, Ereignisse). Der Baustein Nachweisdatenabruf beschreibt den gezielten Abruf von Nachweisdaten aus Registern nach dem Once-Only-Prinzip (NOOTS/OOTS). DAU transportiert Daten, NDA beschafft sie aus autoritativen Quellen. In der Praxis nutzt der Nachweisdatenabruf den Datenaustausch als Transportschicht.
description 2 Beschreibungfeedback
Der Baustein vermittelt den sicheren Austausch von Daten zwischen Behörden untereinander (G2G), zwischen Behörden und Unternehmen (G2B) sowie innerhalb der föderalen IT-Infrastruktur. Die Umgebung übernimmt dabei auch die Konvertierung von Dokumenten unterschiedlichen Formats in verschiedene Standard- und Zielformate. Die Kommunikation mit Bürger:innen erfolgt über den Baustein Postfach und Interaktion.
Der Baustein beinhaltet zudem Funktionalitäten zum Empfangen und Verteilen von Ereignissen (z. B. Informationen zu Datenänderungen oder Nachrichten). Sendersysteme liefern Ereignisse inklusive eines Ereignistyps an den Dienst. Empfängersysteme melden sich für den Empfang von Ereignissen zu bestimmten Ereignistypen an und erhalten Benachrichtigungen, wenn ein neues Ereignis auftritt.
2.1 Abgrenzungfeedback
Der Baustein umfasst nicht die Serviceintegration als Teil des Bausteins Applikationsintegration. Er umfasst nicht Funktionalitäten, die für die Steuerung von Prozessen benötigt werden. Der Baustein ist nicht für den Austausch von Ereignissen innerhalb einer Behörde oder Schutzzone gedacht; dort kommen interne Messaging-Systeme zum Einsatz.
Der Baustein adressiert den Transport von Daten. Für den Abruf von Nachweisdaten aus Registern (Once-Only-Prinzip, Einwilligungsmanagement, Registerlandkarte) ist der Baustein Nachweisdatenabruf (NDA) zuständig. In der Zusammenarbeit stellt der Datenaustausch den sicheren Kanal bereit, über den NOOTS oder andere Systeme Nachweisdaten übermitteln.
menu_book 3 Terminologiefeedback
Die folgende Tabelle definiert die zentralen Fachbegriffe des Datenaustausch-Bausteins. Die Begriffe sind produktneutral gefasst und orientieren sich an den gängigen Standards und Spezifikationen.
| Begriff | Definition |
|---|---|
| API | Application Programming Interface |
| BSI | Bundesamt für Sicherheit in der Informationstechnik |
| DAU | Datenaustausch (Funktionsbaustein-Kennung) |
| Datenformat-Konvertierung | Umwandlung von Daten oder Dokumenten aus einem Quellformat in ein standardisiertes Zielformat |
| DSP | Dataspace Protocol – offener Standard für souveränen Datenaustausch zwischen Datenraum-Teilnehmern (IDSA/Eclipse) |
| DSGVO | Datenschutz-Grundverordnung |
| DVDV | Deutsches Verwaltungsdiensteverzeichnis |
| EDC | Eclipse Dataspace Connector – Open-Source-Referenzimplementierung des Dataspace Protocol |
| Empfängersystem | System, das übermittelte Daten vom Datenaustausch-Dienst abruft oder empfängt |
| Ende-zu-Ende-Verschlüsselung | Verschlüsselung der Nutzdaten bereits im Sendersystem, sodass nur das Empfängersystem entschlüsseln kann |
| Ereignis (Event) | Strukturierte Nachricht über eine Datenänderung oder einen Statuswechsel, die an abonnierende Systeme verteilt wird |
| Ereignistyp | Klassifikation eines Ereignisses, über die Empfängersysteme Abonnements steuern |
| G2B | Government-to-Business |
| G2C | Government-to-Citizen |
| G2G | Government-to-Government |
| JWE | JSON Web Encryption (RFC 7516) |
| JWK | JSON Web Key (RFC 7517) |
| JWS | JSON Web Signature (RFC 7515) |
| LeiKa | Leistungskatalog der öffentlichen Verwaltung mit standardisierten Leistungsidentifikatoren |
| NDA | Nachweisdatenabruf (Funktionsbaustein-Kennung) |
| NOOTS | National Once Only Technical System |
| OOTS | Once Only Technical System (EU) |
| PKI | Public Key Infrastructure |
| PVOG | Portalverbund Online-Gateway |
| SDG-VO | Single Digital Gateway Verordnung (EU 2018/1724) |
| Sendersystem | System, das Daten (z. B. Antragsdaten, Bescheide, Ereignisse) zur Übermittlung an den Datenaustausch-Dienst übergibt |
| SET | Security Event Token (RFC 8417) |
| Submission | Eine einzelne Einreichung bestehend aus Metadaten, Fachdaten und optionalen Anlagen |
| V-PKI | Verwaltungs-PKI |
| Verwaltungs-PKI | Zertifikatsinfrastruktur des BSI für die Bundesverwaltung, Wurzelzertifizierungsstelle beim BSI |
| VS-NfD | Verschlusssache – Nur für den Dienstgebrauch |
| XÖV | XML in der öffentlichen Verwaltung |
| Zuständigkeitsfindung | Automatisierte Ermittlung des zuständigen Empfängersystems über Verzeichnisdienste (z. B. PVOG, DVDV) |
| Zustellpunkt | Konfigurierter Empfangsendpunkt eines Systems mit Angaben zu akzeptierten Datenformaten und kryptographischen Schlüsseln |
settings 4 Kernfunktionalitätenfeedback
Der Baustein bündelt sechs Kernfunktionalitäten, die den sicheren und regelbasierten Datenaustausch zwischen Organisationen ermöglichen. Die Funktionalitäten sind abstrakt beschrieben und können durch verschiedene Produkte und Protokolle implementiert werden.
4.1 Datenaustausch initiieren und steuernfeedback
Der synchrone und asynchrone Datenaustausch kann zentral gesteuert und bei Bedarf unterbrochen werden. Das umfasst die sichere Anbindung von verschiedenen Datenquellen und die regelbasierte Steuerung des Datenflusses. Die angebundenen, aufrufenden Systeme werden registriert und authentifiziert. Austauschregeln (z. B. erlaubte Datenformate, Nutzungszwecke) werden zentral verwaltet.
4.2 Formate erkennen und konvertierenfeedback
Verschiedene Daten- und Dokumentenformate können identifiziert und gemäß Vorgaben in Standardformate konvertiert werden, damit sie von den empfangenden Systemen bearbeitet werden können. Auf dem Rückkanal können die Daten wieder in das ursprüngliche Format konvertiert werden. Das verhindert Medienbrüche, wenn unterschiedliche Systeme unterschiedliche Formate erwarten (z. B. XÖV, JSON, PDF/A).
4.3 Datenschutz prüfenfeedback
Ausgehende Daten werden daraufhin geprüft, ob sie die Datenschutzanforderungen einhalten. Ist dies nicht der Fall, werden die Daten entweder nicht übermittelt oder sie werden pseudonymisiert. Diese Prüfung findet vor der Übertragung statt und ist Teil der regelbasierten Steuerung.
4.4 Ereignisse empfangen und verarbeitenfeedback
Informationen, die als Datenänderungen in einem System auftreten oder als Nachrichten von externen Quellen eingehen, können kontinuierlich erfasst und ausgewertet werden. Dieser Prozess ermöglicht es, in Echtzeit auf relevante Ereignisse zu reagieren und automatisierte Aktionen auszulösen.
4.5 Abonnierte Ereignisse verteilenfeedback
Informationen über Datenänderungen oder Nachrichten können an abonnierende Systeme gesendet werden. Die Empfänger werden in Echtzeit über relevante Aktualisierungen informiert und können darauf reagieren oder diese weiter verarbeiten.
4.6 Verteilabonnements nach Ereignistyp verwaltenfeedback
Abonnements können basierend auf den spezifischen Ereignistypen organisiert und verwaltet werden. Das ermöglicht eine gezielte und effiziente Verteilung von Ereignissen an die entsprechenden Empfängersysteme.
shield 5 Querschnittsanforderungenfeedback
Die Querschnittsanforderungen leiten sich aus den BSI-Richtlinien, der DSGVO und den Architekturprinzipien des D-Stacks ab. Sie gelten unabhängig von der konkreten Produktwahl für alle Datenaustausch-Funktionalitäten.
5.1 Verschlüsselungfeedback
Antragsdaten und sensible Inhalte müssen Ende-zu-Ende-verschlüsselt übertragen werden. HTTPS allein reicht nicht aus, wenn besonders schutzbedürftige personenbezogene Daten verarbeitet werden. Die Verschlüsselung muss nach aktuellen BSI-Vorgaben (TR-02102-1) erfolgen. Je nach Einsatzszenario kann VS-NfD-konformer Datenaustausch erforderlich sein.
5.2 Authentifizierung und Autorisierungfeedback
Sender und Empfänger müssen sich gegenseitig authentifizieren. Die Autorisierung erfolgt regelbasiert und kann über verschiedene Mechanismen realisiert werden (z. B. OAuth 2.0 Client Credentials, Verifiable Credentials, Policy-basierte Zugriffskontrolle). Zertifikate müssen aus vertrauenswürdigen Quellen stammen (z. B. Verwaltungs-PKI, Gaia-X Trust Framework).
5.3 Nachvollziehbarkeitfeedback
Statusänderungen und Austauschvorgänge müssen kryptographisch nachweisbar protokolliert werden. Das geht über einfache Datenbank-Einträge hinaus: signierte Empfangsbestätigungen und Statusereignisse ermöglichen eine revisionssichere Dokumentation.
5.4 Datenschutzfeedback
Die Verarbeitung personenbezogener Daten muss DSGVO-konform erfolgen. Daten werden nur zweckgebunden übermittelt. Einwilligungen und Berechtigungen werden geprüft, bevor Daten das Sendersystem verlassen.
checklist 6 Funktionale Anforderungenfeedback
Die funktionalen Anforderungen beschreiben die Leistungsmerkmale des Bausteins unabhängig von einem konkreten Produkt. Die Priorisierung folgt RFC 2119 (MUST/SHOULD/MAY).
| Anforderung | Beschreibung | Priorität |
|---|---|---|
| Ende-zu-Ende-Verschlüsselung | Daten werden im Sendersystem verschlüsselt und erst im Empfängersystem entschlüsselt | MUST |
| Vertrauenswürdige Zertifikate | Verschlüsselungs- und Signaturschlüssel basieren auf Zertifikaten aus anerkannten PKIs | MUST |
| Zustellpunkt-Konfiguration | Empfänger konfigurieren akzeptierte Leistungen, Regionen, Datenformate und Schlüssel | MUST |
| Zuständigkeitsfindung | Automatische Ermittlung des Empfängers über Verzeichnisdienste bei unbekanntem Adressaten | MUST |
| Signierte Empfangsbestätigungen | Kryptographisch nachweisbare Quittungen für empfangene Daten | MUST |
| Eskalation bei Nicht-Abholung | Automatische Benachrichtigung und ggf. Ablehnung bei Zeitüberschreitung | MUST |
| Formatkonvertierung | Konvertierung zwischen gängigen Verwaltungsformaten (XÖV, JSON, PDF/A) | SHOULD |
| Ereignisbasierte Benachrichtigung | Abonnierbare Ereignisse für Datenänderungen und Statuswechsel | SHOULD |
| SDKs und Onboarding-Unterstützung | Offizielle SDKs in gängigen Programmiersprachen mit integrierter Zertifikatsprüfung | SHOULD |
| Bidirektionale Kommunikation | Rückfragen und Nachreichungen innerhalb eines Austauschvorgangs | MAY |
| VS-NfD-konformer Austausch | Verschlüsselung und Transport nach VS-NfD-Vorgaben bei erhöhtem Schutzbedarf | MAY |
database 7 Datenstrukturenfeedback
Der Baustein verarbeitet pro Austauschvorgang (Submission) drei Datensatzarten: Metadaten, Fachdaten und Anlagen. Alle drei müssen verschlüsselt übertragen werden. Die konkreten Formate hängen von der jeweiligen Produktimplementierung ab.
7.1 Submission (Austauschvorgang)feedback
| Bestandteil | Beschreibung |
|---|---|
| Metadatensatz | Angaben zum Vorgang: Leistungsidentifikator, Absender, Empfänger, Zeitstempel, Datenformat-Versionen |
| Fachdatensatz | Die eigentlichen Nutzdaten (z. B. Antragsdaten, Bescheid, strukturierte Register-Antwort) |
| Anlagen | Optionale Binärdateien (z. B. PDF-Dokumente, Nachweise, Bilder) |
7.2 Zustellpunkt (Destination)feedback
Ein Zustellpunkt beschreibt den Empfangsendpunkt eines Systems:
| Feld | Beschreibung |
|---|---|
| Leistungen | Identifikatoren der akzeptierten Verwaltungsleistungen (z. B. LeiKa-IDs) |
| Regionen | Regionale Zuordnung des Empfängers |
| Datenformate | Akzeptierte Schemata und Formatversionen |
| Verschlüsselungsschlüssel | Öffentlicher Schlüssel des Empfängers für die Ende-zu-Ende-Verschlüsselung |
| Kontaktinformation | Technischer Ansprechpartner für Eskalationen |
7.3 Statusereignisfeedback
Ein Statusereignis dokumentiert eine Zustandsänderung eines Austauschvorgangs (z. B. „eingegangen", „angenommen", „abgelehnt"). Es enthält den Ereignistyp, einen Zeitstempel und optionale Fehlerbeschreibungen. Die Signatur des Ereignisses verknüpft den Statuswechsel kryptographisch mit den tatsächlich übertragenen Daten.
api 8 Service-Schnittstellenfeedback
Die Service-Schnittstellen sind funktional beschrieben und können durch unterschiedliche Protokolle und Produkte realisiert werden. Offene Standards (z. B. JSON, REST, XÖV) und dokumentierte APIs sind die Grundlage. Schnittstellen sind maschinenlesbar (z. B. OpenAPI) und durch Code-Beispiele in gängigen Sprachen (z. B. Python, JavaScript, TypeScript) veranschaulicht.
| Schnittstelle | Zweck |
|---|---|
| Datenübertragung | Einreichung und Abruf verschlüsselter Daten (synchron oder asynchron) |
| Zuständigkeitsermittlung | Ermittlung des zuständigen Empfängers über Verzeichnisdienste |
| Authentifizierung | Token-basierte oder zertifikatsbasierte Authentifizierung von Sender und Empfänger |
| Schlüsselabruf | Abruf des öffentlichen Empfangsschlüssels für die Ende-zu-Ende-Verschlüsselung |
| Statusabfrage | Abfrage und Benachrichtigung über Statusänderungen eines Austauschvorgangs |
| Ereignis-Abonnement | Registrierung und Verwaltung von Abonnements für bestimmte Ereignistypen |
8.1 Weitere Diensteschnittstellenfeedback
Der Baustein interagiert mit den Diensten Identity und Access Management, Betriebsplattform und Netzinfrastruktur. Bei Bedarf wird VS-NfD-konformer Datenaustausch über diese Schnittstellen ermöglicht.
account_tree 9 Interne Workflowsfeedback
Der Baustein ist in die föderale IT-Infrastruktur eingebettet und interagiert mit mehreren Basisdiensten und Funktionsbausteinen des D-Stacks. Die folgende Übersicht zeigt die direkten Abhängigkeiten.
Abhängigkeiten im D-Stack:
- Zentrales Nutzenden-Frontend (ZNF): Sendet Antragsdaten verschlüsselt an den Datenaustausch-Dienst
- PKI: Stellt Zertifikate für Verschlüsselung und Signaturprüfung bereit
- Authentifizierung (AUT): Stellt Zugriffstoken für den Zugriff auf die Schnittstellen bereit
- Vorgangs- und Sachbearbeitung: Empfängt Daten zur Weiterverarbeitung
- Nachweisdatenabruf (NDA): Nutzt den Datenaustausch als Transportschicht für Registerdaten
- Postfach und Interaktion: Ergänzender Kanal für die direkte Kommunikation mit Bürger:innen
- Digitale Brieftasche (DBT): Perspektivisch Zustellschiene für wallet-signierte Anträge (EUDI Wallet)
library_books 10 Weiterführende Informationen und Quellenfeedback
Dieser Abschnitt bündelt die normativen Quellen, Referenzprodukte und verwandte Bausteine.
10.1 Referenzprodukte und Initiativenfeedback
| Produkt / Initiative | Domäne | Beschreibung |
|---|---|---|
| FIT-Connect | Hoheitlicher Antragstransport (G2C, G2G) | Einheitliche Zustellschnittstelle der FITKO für die Anbindung von Online-Diensten an Fachverfahren. Produktiv seit April 2022. |
| Eclipse Dataspace Connector (EDC) | Souveräne Datenräume (B2B, B2G) | Open-Source-Referenzimplementierung des Dataspace Protocol. Eingesetzt in Catena-X, Gaia-X und weiteren EU-Datenräumen. |
| NOOTS | Registerdatenabruf (Once-Only) | Nationale Vermittlungsinfrastruktur für den automatisierten Nachweisabruf aus Registern. |
| Dataspace Protocol (DSP) | Datenraum-Standard | Offener Standard der IDSA/Eclipse für souveräne Datenraum-Kommunikation (Contract Negotiation, Data Transfer). |
| EU-OOTS | Grenzüberschreitender Nachweis-Austausch | EU Once Only Technical System für den Austausch von Nachweisen zwischen Mitgliedstaaten. |
Eine Gegenüberstellung dieser Initiativen enthält der Baustein Souveräner Datenaustausch zwischen Registern.
10.2 Normative Standardsfeedback
- BSI TR-02102-1 (Kryptographische Verfahren)
- BSI TR-03107-1 (Elektronische Identitäten)
- BSI TR-03116-4 (eCard-Projekte der Bundesregierung)
- RFC 7515 – JSON Web Signature (JWS)
- RFC 7516 – JSON Web Encryption (JWE)
- RFC 7517 – JSON Web Key (JWK)
- RFC 8417 – Security Event Token (SET)
- GovStack Information Mediator Building Block
- XÖV-Standards der KoSIT
10.3 Verwandte Bausteinefeedback
- Zentrales Nutzenden-Frontend (ZNF) – Sendet Antragsdaten über den Datenaustausch-Dienst
- Postfach und Interaktion – Kommunikation mit Bürger:innen
- PKI – Verwaltungs-PKI-Zertifikate
- Authentifizierung (AUT) – Authentifizierung und Autorisierung
- Vorgangs- und Sachbearbeitung – Empfangsseitige Verarbeitung
- Nachweisdatenabruf (NDA) – Registerdatenabruf nach dem Once-Only-Prinzip
- Digitale Brieftasche (DBT) – EUDI-Wallet-Integration
- Siegeln und Signieren – V-PKI-Vertrauensbasis und Business Wallets
- Souveräner Datenaustausch – Vergleich NOOTS, OOTS, SIMPL, Eclipse Dataspace