Der Eclipse Dataspace Connector (EDC) – Architektur und Nutzen des Frameworks

Durch Kooperationen sowie dem Austausch, der Nutzung und Vernetzung von Daten-Assets, werden neue Geschäftsmodelle geschaffen. Damit wird die zukünftige Wettbewerbsfähigkeit von Unternehmen gesichert. Grundlage hierfür ist ein sicherer und zweckgebundener Austausch von Daten über die Grenzen von Unternehmen und Organisationen hinweg. Die Basis bilden dabei dedizierte Regeln und Richtlinien unter Wahrung der Datensouveränität.

EDC – ein Framework für sicheren Datenaustausch

Die „International Dataspaces“ (IDS) ist ein Konzept, wie souveräner und sicherer Datenaustausch über Unternehmens- und Organisationsgrenzen unter gleichzeitiger Wahrung der Datenhoheit ermöglicht werden kann.
Dabei wird der Austausch von Daten-Assets zwischen vertrauensvollen Teilnehmern entsprechend klar definierter Regeln und Richtlinien realisiert. Zentraler Aspekt ist dabei, dass Teilnehmer, welche Daten in einem Datenraum zur Verfügung stellen, jederzeit über die Datensouveränität verfügen. [8] Eclipse Dataspace Connector (EDC) ist ein Framework, dass das Konzept der IDS in die Tat umsetzen soll. [2] Dieser Blogpost betrachtet den EDC, das bisher Erreichte und den Zusammenhang mit anderen Standards und Projekten wie IDS und GAIA-X. Er liefert einen Einblick in die zugrunde liegende Architekturaspekte und Konzepte des EDC.

Kontext und Umwelt des Eclipse Dataspace Connector

Im Folgenden werden Initiativen und Standards aufgeführt die einen wesentlichen Einfluss auf die Entwicklung des EDCs haben.

International Data Spaces Association (IDSA)

Die International Data Spaces Association (IDSA) ist ein Verein mit dem Ziel, domänenübergreifende Datenräume zu schaffen. Der Datenaustausch soll dabei auf den Prinzipien der Selbstbestimmung und Kontrolle basieren. Die Kooperation soll über Branchengrenzen hinaus erfolgen können und die Unternehmensgröße kein limitierender Faktor sein. [1][4] Ergebnis soll ein de-facto Standard sowie ein Referenzarchitekturmodell für den sicheren und souveränen Datenaustausch zwischen vertrauenswürdigen Partnern sein – die IDS (International Data Spaces). [1]

International Data Spaces (IDS)

„Dataspaces“ (Datenräume) sind ein Ansatz zur Informationsintegration. [1] Dabei werden innerhalb eines Datenraumes Daten entsprechend fest definierter Regeln und klarer Rahmenbedingungen geteilt. Der dezentrale Ansatz der Datenräume zielt auf die Wahrung der digitalen Souveränität der Teilnehmenden sowie der Wahrung der Datenhoheit über deren Daten-Assets. Daten verbleiben dabei bis zu dessen Abruf beim Datenurheber bzw. der Datenurheberin. [9]

CATENA-X

Die CATENA-X Automotive Alliance verstehen sich als Pioniere in der Erstellung von Datenräumen und sind damit eine der treibenden Kräfte hinter der Entwicklung des EDC. [3] CATENA-X hat das Ziel, einen eigenen Datenraum für die Automobilindustrie zu schaffen und setzt auf den Ideen, der Infrastruktur und Technologien von GAIA-X auf. [19]

Eclipse Dataspace Connector (EDC)

Das Projekt Eclipse Dataspace Connector (EDC) bietet ein Connector-Framework für den souveränen, unternehmensübergreifenden Datenaustausch[7]. Der EDC wird in der Eclipse Foundation als FOSS (Free and Open Source Software) Lösung unter der Open Source-Lizenz Apache 2 Lizenz entwickelt und veröffentlicht. Dadurch wird freier und kommerzieller Einsatz des EDCs und die Erweiterbarkeit der Lösung ohne Lizenzkosten ermöglicht, sowie die Nutzung und Weiterverbreitung nur minimal beschränkt [10].
Ziel der EDC Initiative ist die Schaffung einer konkreten Implementierung, welche die Protokolle des IDS Standards umsetzt und Kompatibilität mit den Anforderungen des GAIA-X Projektes anstrebt. [7] [10] Der Austausch der Daten erfolgt dabei über definierte datensouveräne Verträge, welche automatisch ausgehandelt werden und so den Zugriff auf die Daten-Assets regeln.

EDC Architektur

Bei der Architektur des EDCs liegt der Fokus auf Erweiterbarkeit. Im Folgenden werden die Umsetzung dieses Prinzips, sowie weitere Architekturaspekte des EDCs dargestellt.

Der Konnektor

Zentrale Komponente ist der Konnektor, der die einzelnen Teilnehmer eines Datenraums miteinander verbindet und somit den Endpunkt für den eigentlichen Datenaustausch bildet. Er übernimmt für angebundene Anwendungen die automatische Vertragsverhandlung und den anschließenden Austausch der Daten-Assets.

Control- und Data Plane

Ein zentraler Architekturaspekt ist die Trennung der Control- und Data Plane (Verwaltungs- und Datenübertragungsschicht) des Konnektors.
Der Verwaltungsschicht kommen dabei folgende zentralen Aufgaben zu:

• Datenabfragen (welche Daten werden angeboten)
• Verbindungsaufbau (Connectivity)
• Authentifizierung (bevor ein Austausch von Daten erfolgen kann, erfolgt die Überprüfung der Identität über ein Identity Provider)
• automatische Vertragsverhandlung
• Durchsetzung von Richtlinien (Policy Enforcement)
• Auditierung und Prüfung. [8]

Nach erfolgreicher Verhandlung ist die Data Plane für die Übertragung und den Empfang der Daten verantwortlich. Unternehmen speichern dabei ihre Daten-Assets in einer Vielzahl von Speicherlösungen. Hier kommen häufig proprietäre Speicherlösungen zum Einsatz. Durch den Einsatz der Java Service Provider Interface (SPI) ist sowohl die Data Plane als auch die Control Plane über einen Extension Mechanismus erweiterbar.

Contract & Policies

Der Austausch von Daten in Datenräumen erfolgt nach definierten Richtlinien. Dabei wird im EDC Kontext zwischen Verwendungsrichtlinien („Usage Policies“) und Zugangsrichtlinien („Access Policies“) unterschieden. Die Verwendungsrichtlinien können dabei folgende Dimensionen abbilden:

• Verwendungsrichtlinien
  • Verwendungsrichtlinien definieren, für welchen Zweck die Daten genutzt werden dürfen. [7]
    • Zeitliche Dimension (beispielweise, dass Daten nach einem definierten Zeitraum gelöscht werden müssen)
    • Geografischen Dimension wie der Richtlinie, dass Daten im Inland oder in der Europäischen Union verbleiben müssen.
    • Zweckgebundene Dimensionen wie beispielsweise, dass Daten nur für einen bestimmten Zweck, wie der Verwendung in der Qualitätskontrolle oder der Verwendung für ML-Training, genutzt werden dürfen.
    • Anforderung an die Datenverarbeitung. So kann definiert sein, dass Daten vor der Verarbeitung anonymisiert werden müssen.
    • Bezüglich der Datenspeicherung kann definiert sein, dass Daten nur in zertifizierte Cloud-Umgebungen gespeichert werden dürfen.
• Zugangsrichtlinien
  • Zugangsrichtlinien definieren, durch wen die Daten genutzt werden dürfen.
    • Richtlinien, welche besagen, dass Daten nur mit definierten Teilnehmern oder Gruppen geteilt werden wie beispielsweise „Assets werden nur mit Partnern geteilt“ [7]

Richtlinien können dabei beliebig verknüpft wie auch negiert werden. Der Provider kann somit den Zugang auf die Daten und die Verwendung der Daten durch den Konsumenten präzise spezifizieren.
Die Richtlinien werden durch den „Policy Engine“ geprüft und verarbeitet. Somit wird sichergestellt, dass die Daten nur mit den gewünschten Partnern geteilt und nur der beabsichtigten Verwendung zugeführt werden.

Wie wird Identität und Vertrauen im Datenraum hergestellt?

Das Vertrauen im Datenraum kann sowohl zentral als auch dezentral organisiert sein.

Im zentralen Szenario wird die Vertrauensstellung durch eine zentrale Dataspace Authority umgesetzt, an welche die Identitäts-Provider angebunden sind. [11] Dezentral kann die Vertrauensstellung der Teilnehmer durch das DID:Web Verfahren aufgebaut werden.
Verpflichtend ist, dass zumindest ein Identitäts-Provider im Datenraum existiert, welcher die Identität aller angebundenen Teilnehmer sicherstellt. [11] Folgende Implementierungen stehen aktuell im EDC Projekt zur Verfügung: [18]

• OAuth2 Identity Service
• DAPS
• DID:Web

OAuth2 Identity Service

Der OAuth2 Identity Service ist eine Erweiterung, die eine Identity-Service Implementierung auf Basis des OAuth 2.0 Protokolls zur Verfügung stellt. Die Aufgabe des Service ist der Austausch von OAuth 2.0 Bearer Tokens. Der Service ermöglicht die Anbindung des EDC an gängige IAM Systeme.
Diese Form der Authentifizierung ist erforderlich, um kompatibel zu den Anforderungen des GXFS-DE GAIA-X Federated Service Deutschland zu sein. [7]

Dynamic Attribute Provisioning Service (DAPS)

Bei DAPS handelt es sich um einen Attributs-Server, der die Anreicherung der Identitäten von Organisationen und Konnektoren mit zusätzlichen Attributen ermöglicht. Die Aufgabe des DAPS ist die Ausstellung von JSON Web Tokens (JWT) als OAuth 2.0 Bearer Tokens. Mittels dieser Tokens erfolgt die Autorisierung an anderen Konnektoren. Der DAPS agiert dabei als IDS Identity Provider für den EDC. [15] [17] DAPS ist eine Komponente die im Kontext des IDS durch die Fraunhofer Gesellschaft entwickelt wird. [7]

Verteiltes Identitätssystem mit DID:Web

Das DID:Web Verfahren nutzt das DNS (Domain Name System) um Vertrauen im Datenraum aufzubauen.
Die Vertrauensstellung wird wesentlich durch zwei Faktoren bestimmt: Zum einen durch die Reputation der Domäne.
Zum anderen, muss ein DID-Dokument, welches in der Domäne veröffentlich wird, als vertrauenswürdig eingestuft sein. Das DID-Dokument ist eine JSON Datei, dessen Position über den DNS beim Aufruf der DID-Web Adresse zurückgegeben wird. [16] Das DID-Dokument kann dabei Informationen zu einem Public Key Verfahren enthalten, das für die Authentifizierung oder Autorisierung genutzt werden kann. [6] DID:Web ist erforderlich um eine Kompatibilität bezüglich GAIA-X und IDSA zu erreichen. [7]

Der EDC befindet sich aktuell in der Entwicklung, ist jedoch bei den großen europäischen Projekten GAIA-X und CATENA-X im Einsatz [5]. Dabei wird die Praxistauglichkeit des EDC erprobt, da das Framework an konkreten Use Cases ausgerichtet und weiterentwickelt wird. [13] Dies lässt zudem die Annahme zu, dass im Umfeld des EDC weitere FOSS Anwendungen entstehen werden, die den Austausch von Daten unter den Prämissen der Souveränität, Interoperabilität, Sicherheit, Vertrauen und Transparenz weiter vereinfachen und diese Lösungen für den Einsatz in KMU (kleine und mittlere Unternehmen) attraktiv werden lässt. KMUs haben die Möglichkeit, diese Standardlösungen für die Entwicklung neuer Geschäftsmodelle durch Kooperationen mit anderen Firmen oder Organisationen zu nutzen. Der Reifegrad des EDCs wird durch den Einsatz in der Praxis weiter erhöht.
Interessante Themen, die einen maßgeblichen Einfluss auf den Erfolg des EDCs haben können sind:

• Welche weiteren quelloffenen Anwendungen werden sich im Umfeld des EDCs entwickeln?
• Wie wird die Anlage und Verwaltung der EDC Policies und Contracts umgesetzt?
• Wie komplex ist die Entwicklung von weiteren „Extensions“, allem voran von proprietären Speicherlösungen?
• Kann die Lösung einfach und kosteneffizient durch KMUs eingesetzt, an eigene Lösungen adaptiert und umgesetzt werden?

EDC verspricht ein interessantes und vielversprechendes Projekt mit dem Potential das Framework für den Datenaustausch in Internationalen Datenräumen zu werden. Der EDC ist aktuell unter der Version v0.0.1 released. [2] Zeitpunkt und Umfang des ersten Major Releases kann somit richtungsweisend für die weitere Entwicklung und die Zukunft des EDC sein.

Mehr über IoT-Systemintegration erfahren

Quellen: