Fallstudie: Anbindung eines Lieferanten

Zusammenfassung. Diese Seite verfolgt einen vollständigen Ablauf von Anfang bis Ende: Ein Auftraggeber nimmt einen neuen Lieferanten in seine Lieferkette auf, beide vereinbaren eine Vertrauensbeziehung, das erste System des Lieferanten wird ausgestattet und baut die erste geschützte Verbindung zum Database Gateway des Auftraggebers auf. Später wird ein System kompromittiert und gesperrt, und schließlich endet die Zusammenarbeit. Der Auftraggeber betreibt TrustBridge selbst; der Lieferant, ein kleines Unternehmen, lässt seine Installation von einem Betriebspartner führen. Die Seite zeigt, wer welche Komponenten betreibt und wer wofür verantwortlich ist.

Begriffe

Auftraggeber – Unternehmen, das Lieferanten in seine Lieferkette aufnimmt und ihnen begrenzten Zugriff auf seine Dienste gewährt.
Lieferant – Partner, dessen Systeme Zertifikate aus seiner eigenen Hierarchie erhalten.
Betriebspartner – Unternehmen, das die Installation des Lieferanten im vereinbarten Umfang betreibt.
Prüfer-Vertrag – Regeln, die eine prüfende Gegenstelle einhalten muss, damit die Sicherheitszusagen bei ihr wirken.
Erstausstattung – erste Ausstellung für ein System, bei der TrustBridge es noch an keinem Zertifikat erkennen kann.

Beteiligte

Rolle	Im Beispiel	Betriebsmodell	Betreibt
Auftraggeber	Hersteller H, Database Gateway `daten.h.example`	Customer Managed	eigene TrustBridge-Installation, TLS-Adapter und Schlüsselagent vor dem Gateway
Lieferant	Lieferant L, Namensraum `l.example`, System `lager.l.example`	Managed	Systeme mit eigener Schlüsselerzeugung; persönliche Freigabe-Schlüssel und Verwahrer seiner Verantwortlichen
Betriebspartner	Betriebspartner P	–	Installation von L: CA-Worker, Sicherheitsmodul-Partition, Online-Dienste, Überwachung

Verantwortung

Aufgabe	Auftraggeber H	Lieferant L	Betriebspartner P
Beziehung vereinbaren	lädt ein, legt seine Richtung fest, gibt frei	prüft den Anker von H, legt seine Richtung fest, gibt frei	richtet die Seite von L technisch ein
Installation von L aufbauen	–	stellt Verwahrer für die Wurzel-Zeremonie	führt Installation und Zeremonie durch
Schlüssel der Systeme erzeugen	–	durchführend	–
Aufträge von L freigeben	–	durchführend	–
TLS-Adapter und Schlüsselagent bei L	–	stellt den Rechner bereit	installiert und überwacht
Berechtigung im Database Gateway	durchführend	–	–
Sperrung bei Kompromittierung	widerruft auf Wunsch die Beziehung	meldet, weist Sperrung an	führt Sperrung aus
Ende der Zusammenarbeit	widerruft seine Richtung	widerruft seine Richtung	entfernt die Beziehung aus der Installation von L

Ablauf bis zur ersten Verbindung

sequenceDiagram
  participant H as Auftraggeber H
  participant L as Lieferant L
  participant P as Betriebspartner P
  participant SL as lager.l.example
  participant GH as TLS-Adapter und Gateway H
  Note over H,P: Phase 1: Installation bei L
  P->>P: Installation, Schlüssel im Sicherheitsmodul
  L->>P: Verwahrer und Freigeber für die Zeremonie
  P->>P: Wurzel und ausstellende CA von L mit nameConstraints l.example
  Note over H,L: Phase 2: Beziehung
  H->>L: Einladung mit Anker von H und Prüfwert
  L-->>H: Bestätigung des Prüfwerts über zweiten Kanal, Anker von L
  H->>H: Richtung H zu L: Dienst daten.h.example, Zweck, PQ-Pflicht, Dauer
  L->>L: Richtung L zu H: Antwort von daten.h.example zulassen
  Note over L,SL: Phase 3: Erstes Zertifikat
  SL->>SL: Schlüsselpaar erzeugen
  SL->>P: CSR über EST mit Einmalwert
  L->>P: Freigabe als Signatur über den Auftragshash
  P-->>SL: Zertifikat und Agentenzertifikat
  Note over SL,GH: Phase 4: Erste Verbindung
  SL->>GH: Agenten vereinbaren das zusätzliche Geheimnis
  SL->>GH: TLS 1.3 mit Zertifikat, PSK und hybrider Gruppe
  GH->>GH: Kette, nameConstraints, Sperrstatus, Richtlinie
  GH->>GH: Gateway prüft die Regel für L
  GH-->>SL: freigegebene Daten

Phase	Kritischer Punkt	Wie TrustBridge ihn löst
1 Installation	Der Betriebspartner darf nicht im Namen von L ausstellen	Freigeber und Verwahrer sind ausschließlich Personen von L; die Sicherheitsmodul-Partition ist nur L zugeordnet
2 Beziehung	Der Anker der Gegenseite darf nicht unterwegs ausgetauscht werden	Prüfwert über einen zweiten Kanal; Aufnahme nur mit Freigabe einer Person
2 Beziehung	H soll nur genau das öffnen, was L braucht	Richtlinie je Richtung: ein Dienst, ein Zweck, eine Dauer
3 Erstes Zertifikat	L muss sein System als echt ausweisen	Einmalwert mit Frist, über einen getrennten Weg an den Verantwortlichen übergeben
4 Verbindung	Zertifikat ist keine Berechtigung	Gateway berechtigt jede Anfrage nach seiner eigenen Regel

Laufender Betrieb

Die Zertifikate von lager.l.example und seines Schlüsselagenten erneuern sich automatisch über EST, sobald nur noch ein Drittel ihrer Laufzeit übrig ist. Die Schlüsselagenten von L und H erneuern das gemeinsame Geheimnis alle zehn Minuten; die TLS-Adapter rotieren die Verbindung spätestens nach einer Stunde, ohne dass die Anwendung von L eine Unterbrechung bemerkt.

Kompromittierung und Sperrung

sequenceDiagram
  participant L as Lieferant L
  participant P as Betriebspartner P
  participant W as CA-Worker von L
  participant H as Auftraggeber H
  participant GH as TLS-Adapter H
  L->>P: Meldung: lager.l.example kompromittiert
  L->>P: Sperrauftrag freigegeben
  P->>W: Sperrung des System- und Agentenzertifikats
  W->>W: Sperrung im Register, neue Sperrliste
  L->>H: Information über den Vorfall
  GH->>GH: neue Sperrliste geladen, Zertifikat abgelehnt
  H->>H: optional: Beziehung bis zur Klärung aussetzen

Spätestens nach dem nächsten Ladezyklus ist das Zertifikat bei H unbrauchbar. Will H schneller handeln, setzt H seine Richtung der Beziehung aus; das neue Vertrauensbündel erreicht seine TLS-Adapter sofort. Fällt währenddessen die Datenbank von L aus, sperrt P an der Konsole des Worker-Hosts von L, mit Freigabe einer Person von L.

Ende der Zusammenarbeit

H widerruft seine Richtung der Beziehung. Ab sofort kommen keine neuen Verbindungen von L zustande; bestehende enden innerhalb der Frist der Richtlinie. L widerruft ebenfalls seine Richtung. Die Zertifikate von L bleiben für seine Beziehungen zu anderen Auftraggebern gültig. Register und Verbindungsprotokolle bleiben bei beiden Organisationen für den Nachweis erhalten.

Wechselt L später den Betriebspartner oder übernimmt den Betrieb selbst, entsteht in der neuen Umgebung eine neue CA-Generation; H nimmt deren Anker in die Beziehung auf. Private Schlüssel werden dabei nicht herausgegeben.

Varianten der Anbindung

Variante	Ablauf	Aufwand beim Auftraggeber
Lieferant mit eigener Installation (wie oben)	bilaterale Beziehung zwischen zwei Installationen	eine Beziehung je Lieferant
Lieferant ohne eigene Installation	H stellt eine Partner-CA in seiner Hierarchie mit Namensbeschränkung auf `l.example` aus; die Verantwortlichen von L geben über das Partnerportal frei	Zeremonie für die Partner-CA; eine Beziehung je Lieferant
Lieferant mit bestehender Unternehmens-PKI	L bringt den Anker seiner PKI in die Beziehung ein und stattet die beteiligten Systeme mit TLS-Adapter und Schlüsselagent aus	Prüfung des fremden Ankers und seiner Namensbeschränkung vor der Aufnahme

Bei der dritten Variante gelten die Zusagen zu Freigabe, Register und Statusauskunft für die Zertifikate, die TrustBridge selbst ausstellt. Für die Ausstellung in der bestehenden PKI bleibt deren Betrieb in der Verantwortung des Lieferanten.

Was diese Fallstudie nicht zeigt

Keine Vertragsgestaltung zwischen Auftraggeber, Lieferant und Betriebspartner.
Keine Regeln des Database Gateway im Einzelnen; sie beschreibt die Dokumentation des Gateways.
Keine Anbindung mehrerer Standorte eines Lieferanten; sie folgt demselben Muster mit einem Namensraum je Standort.