Willi Mako
┌ ┐ └ ┘
// PROTOCOL:

EDI-Kommunikation: Leitfaden für sicheren Datenaustausch

ID#E82-1D
STATUSREAD_ONLY
AUTHORSYS_ADMIN
TAGS [EDIFACT][NETZWERK][PROZESS][FEHLERBEHANDLUNG]

Vereinbarung von Kommunikationsparametern für den elektronischen Datenaustausch Leitfaden für beteiligte Parteien

Für einen sicheren, rechtsverbindlichen und effizienten elektronischen Datenaustausch (EDI) ist die vorherige Einigung auf technische und organisatorische Kommunikationsparameter essenziell. Dieser Leitfaden beschreibt strukturierte Schritte, um Übertragungswege, Adressen und Signaturverfahren verbindlich zu regeln.

1. Festlegung der Rahmenbedingungen

Vor dem operativen Austausch müssen die Parteien folgende Grundlagen klären:

a) Rechtliche und vertragliche Basis

  • Vereinbarung eines EDI-Rahmenvertrags: Ein schriftlicher Vertrag sollte die technischen und rechtlichen Aspekte des Datenaustauschs regeln, einschließlich:
    • Geltungsbereich (z. B. Art der auszutauschenden Daten, beteiligte Systeme),
    • Haftungsfragen bei Übertragungsfehlern oder Datenverlust,
    • Datenschutzbestimmungen (z. B. DSGVO-konforme Verarbeitung),
    • Laufzeit und Kündigungsfristen.
  • Compliance-Anforderungen: Branchen- oder länderspezifische Vorgaben (z. B. eIDAS-Verordnung für elektronische Signaturen, GoBD für steuerrelevante Daten) sind zu prüfen und umzusetzen.

b) Technische Kompatibilität

  • Protokolle und Standards: Die Wahl des Übertragungsprotokolls (z. B. AS2, SFTP, HTTPS, EDIFACT, XML) muss auf beiden Seiten unterstützt werden. Empfohlen wird die Nutzung etablierter Standards wie:
    • UN/EDIFACT (für internationale Handelsdaten),
    • ebXML (für strukturierte Geschäftsdokumente),
    • Peppol (für öffentliche Auftragsvergabe in der EU).
  • Datenformate: Einigung auf einheitliche Formate (z. B. JSON, XML, CSV) und ggf. Konvertierungsregeln für unterschiedliche Systeme.

2. Definition der Kommunikationsparameter

a) Übertragungswege

  • Sicherheitsanforderungen: Je nach Sensibilität der Daten sind verschlüsselte Kanäle (z. B. TLS 1.2/1.3 für HTTPS, PGP für E-Mails) oder dedizierte Netzwerke (z. B. VPN, Peppol) zu wählen.
    • Beispiele:
      • AS2: Häufig für EDI in der Logistik (z. B. mit MDN-Quittungen für Empfangsbestätigungen).
      • SFTP/FTPS: Für sichere Dateiübertragungen mit Authentifizierung.
      • APIs: Für Echtzeit-Austausch (z. B. REST oder SOAP mit OAuth 2.0).
  • Redundanz und Ausfallsicherheit: Backup-Übertragungswege (z. B. Fallback auf E-Mail mit Verschlüsselung) und Service-Level-Agreements (SLAs) für Verfügbarkeit sind zu vereinbaren.

b) Adressierung

  • Eindeutige Identifikatoren: Jede Partei benötigt eine eindeutige Adresse (z. B. AS2-ID, SFTP-Benutzername, Peppol-ID, E-Mail-Adresse mit S/MIME-Zertifikat).
    • Empfehlung:
      • Nutzung von Peppol-Participant-IDs (für EU-weite Interoperabilität),
      • DNS-basierte Adressen (z. B. edi.partner1.de) für AS2/SFTP,
      • Zertifikatsbasierte Authentifizierung (z. B. X.509-Zertifikate für TLS).
  • Testphase: Vor Produktivbetrieb sind Testübertragungen mit Dummy-Daten durchzuführen, um Adressen und Routing zu validieren.

c) Signaturen und Integrität

  • Elektronische Signaturen: Je nach Rechtsanforderung sind folgende Signaturstufen möglich:
    • Einfache Signatur (z. B. E-Mail-Signatur mit S/MIME),
    • Fortgeschrittene Signatur (z. B. mit qualifizierten Zertifikaten nach eIDAS),
    • Qualifizierte Signatur (höchste Beweiskraft, z. B. für Verträge).
    • Technische Umsetzung:
      • Nutzung von XAdES (für XML-Dokumente) oder CAdES (für binäre Daten),
      • Integration in Übertragungsprotokolle (z. B. AS2 mit Signaturprüfung).
  • Hash-Werte und Prüfsummen: Zusätzlich zu Signaturen können SHA-256-Hashes zur Integritätsprüfung verwendet werden.

3. Dokumentation und Change-Management

a) Technische Spezifikation

  • EDI-Leitfaden: Ein gemeinsames Dokument sollte folgende Punkte festhalten:

    • Übertragungsprotokoll und Ports,
    • Adressen und Authentifizierungsmethoden,
    • Signatur- und Verschlüsselungsverfahren,
    • Fehlerbehandlung (z. B. Retry-Mechanismen, Benachrichtigungen).

  • Beispiel-Tabelle für Parameter:

    Parameter Wert (Beispiel) Verantwortliche Partei
    Übertragungsprotokoll AS2 (TLS 1.2) Beide
    AS2-ID PARTNER1_AS2 / PARTNER2_AS2 Partner 1 / Partner 2
    Signaturverfahren XAdES-BES (qualifiziertes Zertifikat) Beide
    Empfangsbestätigung MDN (asynchron) Partner 2

b) Änderungsmanagement

  • Versionierung: Änderungen an Parametern (z. B. Zertifikatswechsel) sind mit Vorlauf anzukündigen und zu dokumentieren.
  • Testumgebung: Vor Produktivsetzung sind Änderungen in einer Staging-Umgebung zu validieren.

4. Monitoring und Eskalation

  • Protokollierung: Alle Übertragungen sind zu loggen (z. B. Zeitstempel, Statuscodes, Signaturprüfergebnisse). Tools wie Splunk oder ELK-Stack können zur Auswertung genutzt werden.
  • Eskalationswege: Klare Ansprechpartner für technische und fachliche Probleme sind zu benennen (z. B. EDI-Support-Team).
  • Regelmäßige Reviews: Halbjährliche Überprüfung der Parameter auf Aktualität (z. B. Zertifikatsgültigkeit, Protokoll-Updates).

5. Rechtliche Absicherung

  • Beweissicherung: Logs und signierte Dokumente sind gemäß gesetzlicher Aufbewahrungsfristen (z. B. 10 Jahre für steuerrelevante Daten) revisionssicher zu archivieren.
  • Vertragliche Sanktionen: Der EDI-Vertrag sollte Konsequenzen bei Nichteinhaltung der Parameter regeln (z. B. Schadensersatz bei Datenverlust durch unsichere Übertragung).

Zusammenfassung der Schritte

  1. Vertragliche Grundlage schaffen (EDI-Rahmenvertrag).
  2. Technische Standards und Protokolle abstimmen.
  3. Adressen und Authentifizierung eindeutig definieren.
  4. Signatur- und Verschlüsselungsverfahren festlegen.
  5. Dokumentation erstellen und Change-Management etablieren.
  6. Monitoring und Eskalationsprozesse implementieren.
  7. Rechtliche Absicherung durch Beweissicherung und Compliance-Prüfung.

Durch diese strukturierte Vorgehensweise minimieren beteiligte Parteien Risiken wie Datenverlust, Manipulation oder rechtliche Unwirksamkeit des Austauschs. Bei komplexen Anforderungen empfiehlt sich die Einbindung externer Berater (z. B. für Zertifikatsmanagement oder Protokollauswahl).

RELATED_NODES