Datendrehscheibe

Funktionsweise

Die Datendrehscheibe erlaubt den sicheren Transport von Daten von einem Ort über einen gesicherten Kanal, z.B. ein Netz des Bundes, zu einem anderem Ort.

Der erste Schritt besteht darin die Daten mit einem zufälligem Schlüssel zu verschlüsseln. Dieser Schlüssel wird anschließend selbst mit einem zufälligem Schlüssel verschlüsselt und anschließend asymmetrisch mit dem public key des Empfängers verschlüsselt. Der generierte Schlüssel zur entschlüsselung des Schlüssels wird mit dem private key des Empfängers asymmetrisch verschlüsselt.

Der Resultierende Payload wird nun an den Anfang der Datei geschrieben bevor diese final mit dem eigentlichem Verschlüsselungskey verschlüsselt auf den S3 hochgeladen wird.

Der Empfänger kann nun mithilfe seines Private Keys und dem Public Key des Senders die Daten entschlüsseln.

Alle Komponenten verschicken und empfangen Daten auf diesem Weg. Ein Import sendet an die Übersetzungsschicht, die Übersetzungsschicht sendet an den Export.

Um Zertifikatsrotierung zu gewährleisten werden auch die Public Keys mit einem private key des csp der wiederum mit einem master key signiert wird, zentral abgelegt. Die Aufgabe der Hinterlegung übernimmt eine zentrale Stelle (in diesem Fall das CSP).

Key Distribution und Rotation

Alle Public Keys werden mit dem aktuellem CSP Private Key verschlüsselt im Bucket des CSP (oder einer anderen zentralen Stelle) veröffetlicht. Der aktuelle public des CSP wird im selben Bucket mit dem Master Key verschlüsselt veröffentlicht.

Die Rotation findet über die zentrale Stelle statt, diese Koordiniert auch mit den IDPs und Clients erneuerungen der Keys und Laufzeiten selbiger.

Post Quantum Cryptography

Alle Verschlüsselungsmechanismen können jederzeit ausgetauscht werden. Der Basiscode erlaubt die Nutzung eigener envelope, open und Verschlüsselungsmechanismen. Auf diesem Wege ist auch gewährleistet potenziell den Mechanismus gegen PQC Algorithmen auszutauschen. Die Standardimplentierung greift auf RSA (mindestens 4096 bit) und AES-256 zurück.

Import von der Datendrehscheibe

Für Nutzende

Importe der Datendrehscheibe werden als sortierte reihenbasierte Struktur übermittelt. Dabei werden transitive Abhängigkeiten in der Sortierung zuerst übermittelt. Eine parallele Abarbeitung des Streams ist relativ unproblematisch. Sobald einer der Threads auf den ersten Record trifft, dergestalt einer anderen Natur, muss eine Synchronisierungsphase stattfinden. Sobald alle weiteren Reihen verarbeitet werden, kann mit der Verarbeitung der weiteren Reihen fortgefahren werden.

Für die Entwicklung

Der Import erwartet eine sortierte Reihenbasierte Struktur. Jede Reihe teilt seine Natur über die record property mit. Beispiel:

{ "record": "user", "user": "test1", ... }

Sortiert muss die Struktur in dem Sinne sein, das transitive Abhängigkeiten nicht out of order ausgeliefert werden.

Negativ Beispiel:

In diesem Beispiel wird eine zuordnung einer Gruppe zu früh mitgeteilt, wenn die Gruppe noch gar nicht übermittelt wurde. Dies sorgt bei dem Import im Zielsystem für Fehler.

{ "record": "user", "user": "test1", ... }
{ "record": "mgroup", "user": "test1", ... }
{ "record": "group", "user": "test1", ... }

Positiv Beispiel:

{ "record": "user", "user": "test1", ... }
{ "record": "group", "id": "id", "name": "groupname" }
{ "record": "role", "id": "id", "name": "rolename" }
{ "record": "mgroup", "groupId": "id", "userId": "id" }
{ "record": "mrole", "roleId": "id", "userId": "id" }
{ "record": "mgrole", "roleId": "id", "groupId": "id" }

Export vom IDP

Der Export erwartet eine reihenbasierte Struktur, eine sortierung ist nicht notwendig. Jede Reihe teilt seine Natur über die record property mit.

Beispiel:

{ "record": "user", "user": "test1", ... }
{ "record": "group", "id": "id", "name": "groupname" }
{ "record": "role", "id": "id", "name": "rolename" }
{ "record": "mgroup", "groupId": "id", "userId": "id" }
{ "record": "mrole", "roleId": "id", "userId": "id" }
{ "record": "mgrole", "roleId": "id", "groupId": "id" }

Nutzung

Zuallererst wird die Konfiguration benötigt. Diese kann im root Verzeichnis als .dvcrc Datei abgelegt werden und ist im JSON format.

Einen Teil dieser Konfiguration muss von der zentralen Stelle definiert werden welche die verschiedenen S3 Server konfiguriert und Access Credentials mitteilt.

Als Docker Container (empfohlen)

Import

Für die Referenzimplementierung des Imports benötigen wir in diesem Beispiel eine Konfiguration für eine Keycloak API und darüberhinaus den clients part der von der zentralen Stelle vorgegeben definiert wird. Außerdem definieren wir noch den Namen des Identity Providers der im Keycloak erstellt wurde über die idp Property. Der Beispielimport ordnet so automatisch die Accounts bereits dem IDP zu.

Hier das Beispiel:

{
  "keycloak": {
    "client": {
      "baseUrl": "https://keycloak.de/auth",
      "realmName": "test"
    },
    "credentials": {
      "grantType": "client_credentials",
      "clientId": "admin-cli",
      "clientSecret": "secret"
    }
  },
  "clients": {
    "n1": {
      "name": "test",
      "s3": {
        "bucket": "example",
        "endPoint": "test.wx-one.com",
        "region": "us-east-1",
        "port": 443,
        "useSSL": true,
        "accessKey": "test",
        "secretKey": "test"
      }
    },
    "csp": {
      "name": "csp",
      "s3": {
        "bucket": "test",
        "endPoint": "test.wx-one.com",
        "region": "us-east-1",
        "port": 443,
        "useSSL": true,
        "accessKey": "test",
        "secretKey": "test"
      }
    }
  },
  "idp": "oidc"
}

docker run --rm -v config.json:/home/node/.dvcrc:ro -v master.pub:/home/node/master.pub:ro -v service.pem:/home/node/service.pem:ro -v service.key:/home/node/service.key:ro dvc node import.js

Translate

Der Translate Layer benötigt lediglich die Konfiguration der zentralen Stelle. Die jeweiligen Konfigurationen der Targets werden dynamisch ermittelt.

{
  "clients": {
    "idp": {
      "name": "test",
      "s3": {
        "bucket": "example",
        "endPoint": "test.wx-one.com",
        "region": "us-east-1",
        "port": 443,
        "useSSL": true,
        "accessKey": "test",
        "secretKey": "test"
      }
    },
    "csp": {
      "name": "csp",
      "s3": {
        "bucket": "test",
        "endPoint": "test.wx-one.com",
        "region": "us-east-1",
        "port": 443,
        "useSSL": true,
        "accessKey": "test",
        "secretKey": "test"
      }
    }
  }
}

docker run --rm -v config.json:/home/node/.dvcrc:ro -v master.pub:/home/node/master.pub:ro -v service.pem:/home/node/service.pem:ro -v service.key:/home/node/service.key:ro dvc

Export

Die Referenzimplementierung des Export benötigt die Konfiguration einer Datenbank und die Konfiguration der zentralen Stelle.

{
  "clients": {
    "n1": {
      "name": "test",
      "s3": {
        "bucket": "example",
        "endPoint": "test.wx-one.com",
        "region": "us-east-1",
        "port": 443,
        "useSSL": true,
        "accessKey": "test",
        "secretKey": "test"
      }
    },
    "csp": {
      "name": "csp",
      "s3": {
        "bucket": "test",
        "endPoint": "test.wx-one.com",
        "region": "us-east-1",
        "port": 443,
        "useSSL": true,
        "accessKey": "test",
        "secretKey": "test"
      }
    }
  },
  "database": {
    "user": "keycloak",
    "host": "localhost",
    "database": "keycloak",
    "password": "password",
    "port": 5555
  }
}

docker run --rm -v config.json:/home/node/.dvcrc:ro -v master.pub:/home/node/master.pub:ro -v service.pem:/home/node/service.pem:ro -v service.key:/home/node/service.key:ro dvc node export.js

Direkt

Translate

node translate.js

Import

node import.js

Export

node export.js