Anbindung an den Database Gateway

Zusammenfassung. Der WKL Database Gateway ist der naheliegende erste Einsatz von TrustBridge: Eine bestehende Geschäftsanwendung eines Lieferanten braucht Zugriff auf Daten eines Auftraggebers. Der Gateway regelt, welche Datenoperationen erlaubt sind; TrustBridge liefert ihm die geprüfte Identität des Partnersystems und schützt die Verbindung dorthin. Der TLS-Adapter steht als einziger Zugang vor dem Gateway und gibt ihm Organisation, Dienst und Zweck der Verbindung weiter; der Gateway berechtigt jede Anfrage nach seinen eigenen Regeln. Der Lieferant braucht dafür weder ein Konto im Netz des Auftraggebers noch Anmeldedaten der Datenbank. TrustBridge funktioniert auch ohne Gateway; die Anbindung ist eine Möglichkeit, keine Voraussetzung.

• Database Gateway – Datendienst von WKL, der Datenbanken über HTTP und OData erreichbar macht und jede Anfrage nach Regeln je Alias berechtigt.
• Alias – im Gateway veröffentlichte Datenquelle mit eigener Verbindung und eigenen Regeln.
• Vertrauenswürdiger Proxy – vorgeschalteter Dienst, dessen weitergegebene Identität der Gateway übernimmt, weil er ausschließlich über diesen Dienst erreichbar ist.
• Partneridentität – die vom TLS-Adapter geprüfte Kombination aus Organisation, Dienstname und Beziehung einer Verbindung.

sequenceDiagram
  participant LA as Anwendung des Lieferanten
  participant TL as TLS-Adapter Lieferant
  participant TA as TLS-Adapter Auftraggeber
  participant GW as Database Gateway
  participant DB as Datenbank
  Note over TL,TA: 1. Beziehung ist vereinbart, Richtlinie beider Seiten aktiv
  LA->>TL: Anfrage an den Gateway
  TL->>TA: 2. TLS 1.3 mit Zertifikaten, zusätzlichem PQ-Geheimnis, hybrider Gruppe
  TA->>TA: Kette, Namensraum, Sperrstatus, Richtlinie prüfen
  TA->>GW: Anfrage mit Partneridentität und Zweck
  GW->>GW: 3. Regel des Alias für diese Identität prüfen
  GW->>DB: 4. erlaubte Operation ausführen
  DB-->>GW: Ergebnis
  GW-->>TA: Antwort, Operation protokolliert
  TA-->>TL: Antwort
  TL-->>LA: Antwort

1. Beziehung vereinbaren. Auftraggeber und Lieferant vereinbaren eine begrenzte Vertrauensbeziehung. Der Auftraggeber lässt in seiner Richtung genau die Dienste des Lieferanten zu, die den Gateway erreichen sollen, für den Zweck des Zugriffs und mit den kryptographischen Anforderungen, die er verlangt.
2. Gegenseitig prüfen und Verbindung schützen. Die TLS-Adapter beider Seiten bauen eine gegenseitig authentisierte TLS-1.3-Verbindung auf, zusätzlich geschützt durch das Post-Quanten-Geheimnis der Schlüsselagenten. Der Adapter des Auftraggebers prüft Kette, Namensraum, Sperrstatus und Beziehungsrichtlinie und gibt die Partneridentität an den Gateway weiter.
3. Rechte prüfen. Der Gateway prüft die Anfrage nach der Regel des Alias für diese Partneridentität: welche Tabellen und Sichten, welche Operationen, welche Zeilen.
4. Ausführen und nachweisen. Die erlaubte Operation wird ausgeführt und im Protokoll des Gateways festgehalten, zusammen mit der Partneridentität. Der Verbindungsaufbau steht im Protokoll des TLS-Adapters.

Ob ein VPN dadurch entfällt, hängt davon ab, wofür es sonst noch genutzt wird. Für den Datenzugriff über den Gateway braucht der Lieferant keinen Zugang zum übrigen Netz des Auftraggebers.

graph TD
  subgraph AG [Netz des Auftraggebers]
    TA[TLS-Adapter<br/>einziger Zugang von außen]
    GW[Database Gateway<br/>Regeln je Alias]
    DB[(Datenbank)]
    KA[Schlüsselagent]
  end
  EXT[Systeme der Partner]
  EXT -->|TLS 1.3, Port des Adapters| TA
  KA ==>|externer PSK| TA
  TA -->|Partneridentität, lokal| GW
  GW --> DB
  classDef onl fill:#f3f2f1,stroke:#605e5c,color:#201f1e
  classDef auth fill:#fff4ce,stroke:#8a6d00,color:#201f1e
  classDef par fill:#deecf9,stroke:#0078d4,color:#201f1e
  classDef pq fill:#dff6dd,stroke:#107c10,color:#201f1e
  class TA,DB onl
  class GW auth
  class EXT par
  class KA pq
  style AG fill:#ffffff,stroke:#8a8886,color:#201f1e

Die Einrichtung Schritt für Schritt beschreibt So binden Sie einen Lieferanten an den Database Gateway an.

Die Anwendung des Lieferanten spricht ihren lokalen TLS-Adapter an, als läge der Gateway auf demselben Rechner oder im eigenen Netz. Das gilt für eigene Anwendungen über HTTP und OData ebenso wie für Microsoft Access, Excel oder Power BI über den WKL OData ODBC Driver oder den Gateway-Client. Die Anwendung braucht weder Zertifikate noch Schlüssel; beides verwaltet TrustBridge auf dem Rechner.

• Keine Regeln des Gateways. Wie Regeln, Aliasse und Anmeldeverfahren funktionieren, beschreibt die Dokumentation des Database Gateway.
• Kein Schutz der Strecken innerhalb eines Netzes. Die Verbindung zwischen TLS-Adapter und Gateway sowie zwischen Gateway und Datenbank schützt der Betreiber nach seinen eigenen Regeln.
• Keine Pflicht, den Gateway zu verwenden. TrustBridge schützt ebenso Verbindungen zu anderen Anwendungen; die Anbindung an den Gateway ist eine von mehreren.
• Keine Aussage, dass ein VPN in jeder Umgebung entfällt.