Einsatzszenarien

Zusammenfassung. Diese Seite beschreibt, warum Vertrauen zwischen Organisationen eine eigene Infrastruktur braucht, was das den einzelnen Zielgruppen bringt, wofür WKL TrustBridge eingesetzt wird, wie die Beteiligten in typischen Abläufen zusammenwirken und wofür TrustBridge ausdrücklich nicht gedacht ist. Allen Szenarien gemeinsam ist der Ausgangspunkt: Mehrere unabhängige Organisationen arbeiten zusammen, jede mit eigenen Systemen, Netzen und Regeln, und jede will genau so viel Vertrauen gewähren, wie die Zusammenarbeit braucht, und es jederzeit wieder entziehen können.

• Partner – eine Organisation der Lieferkette, technisch vertreten durch ihre ausstellende CA.
• System – ein Rechner, Dienst oder Gerät eines Partners, identifiziert durch genau einen DNS-Namen im Namensraum des Partners.
• Prüfende Gegenstelle – ein System, das ein Zertifikat entgegennimmt und prüft, etwa ein Server, der ein Client-Zertifikat verlangt (mTLS); in TrustBridge in der Regel der TLS-Adapter.
• Profilklasse – Kategorie von Zertifikaten mit festen Regeln für Inhalt, Laufzeit und Freigabe; manuelle Klassen verlangen die Freigabe durch eine Person, automatische eine Bestätigung des Enrollments.
• Vertrauensbeziehung – bilaterale Vereinbarung zweier Organisationen mit einer Beziehungsrichtlinie je Richtung.

In einer Lieferkette tauschen Systeme verschiedener Unternehmen Daten aus: Ein Auftraggeber stellt Produktionsdaten bereit, ein Lieferant pflegt einen Teil der Geschäftsanwendungen, ein Dienstleister wartet Anlagen. Heute ruht diese Zusammenarbeit oft auf einer Mischung aus VPN, Vertrauen in ein gemeinsames Netz, zentralen Konten, Zertifikaten verschiedener Herkunft, manuell gepflegten Ausnahmen und Verträgen. Das funktioniert, solange es wenige Partner sind. Mit jedem weiteren Partner wird es schwerer zu sagen, wer worauf zugreifen darf, warum, seit wann und wie man es wieder beendet.

Fünf Gründe sprechen dafür, dieses Vertrauen nicht nebenbei zu verwalten, sondern über eine eigene Infrastruktur:

1. Identität über Unternehmensgrenzen. Ein Zertifikat einer öffentlichen Zertifizierungsstelle belegt die Kontrolle über einen Domänennamen, nicht die Zugehörigkeit zu einem bestimmten Partner. Eine Lieferkette braucht die zweite Aussage: Dieses System gehört zu Partner A und darf nur im Namensraum von Partner A auftreten. TrustBridge setzt das mit einer Namensbeschränkung je Partner durch (nameConstraints nach RFC 5280).
2. Vertrauen ist zweiseitig, nicht Mitgliedschaft. Vertraut A dem Partner B und B dem Partner C, folgt daraus nicht, dass A dem Partner C vertraut. Jede Beziehung wird zwischen genau zwei Organisationen vereinbart und ist für jede Richtung einzeln festgelegt.
3. Gesetzliche Pflicht zur Sicherheit der Lieferkette. Die NIS2-Richtlinie und das BSI-Gesetz verpflichten erfasste Einrichtungen, die Sicherheit ihrer Lieferbeziehungen und den Einsatz von Kryptographie zu regeln (§ 30 Abs. 2 Nr. 4 und Nr. 8 BSIG). Nachweisbare Ausstellung, Freigabe und Sperrung sind eine prüfbare Antwort darauf.
4. Der Übergang zu Post-Quanten-Verfahren. Der europäische Fahrplan verlangt, Anwendungen mit hohem Risiko – PKI wird ausdrücklich genannt – bis Ende 2030 auf quantensichere Verfahren umzustellen. Vertrauensanker gelten oft zehn bis zwanzig Jahre; Daten, die heute aufgezeichnet werden, können später entschlüsselt werden. Deshalb schützt TrustBridge Verbindungen schon heute zusätzlich mit einem Post-Quanten-Geheimnis und stellt hybride Zertifikate aus.
5. Kontrolle über Schlüssel und Widerruf. Wer mit Partnern zusammenarbeitet, muss die Zusammenarbeit auch beenden können, ohne auf einen Dritten zu warten, und nachweisen können, wer welche Freigabe erteilt hat.

Zero Trust und gegenseitiges Vertrauen schließen sich nicht aus. Zero Trust heißt, keinem Benutzer, Gerät, Dienst oder Netzbereich stillschweigend zu vertrauen. Gegenseitiges Vertrauen heißt in TrustBridge, dass zwei Organisationen vereinbarte kryptographische Identitäten und Bedingungen prüfen können. Auch danach wird jede einzelne Operation von der Zielanwendung gesondert berechtigt.

Ein Lieferant (Partner A) pflegt einen Teil der Geschäftsanwendungen eines Auftraggebers (Partner B) und ruft dafür automatisiert Daten ab. Bisher brauchte er dafür einen VPN-Zugang und Anmeldedaten der Datenbank. Mit TrustBridge vereinbaren beide eine Beziehung, und der Lieferant erreicht genau die freigegebenen Daten über den Database Gateway.

sequenceDiagram
  participant A as lager.partner-a.example
  participant TA as TLS-Adapter Partner A
  participant TB as TLS-Adapter Partner B
  participant G as Database Gateway von B
  A->>TA: Anfrage
  TA->>TB: TLS 1.3, Client-Zertifikat, zusätzliches PQ-Geheimnis
  TB->>TB: Kette bis zum Anker der Beziehung, nameConstraints, Sperrliste
  TB->>TB: Dienst und Zweck in der Richtlinie von B
  TB->>G: Anfrage mit Partneridentität
  G->>G: Regel für Partner A prüfen
  G-->>TB: freigegebene Daten
  TB-->>TA: Antwort
  TA-->>A: Antwort

Was die Sicherheit trägt. Der Auftraggeber erkennt den Lieferanten nicht am Feld O oder CN, sondern an der ausstellenden CA, die er in die Beziehung aufgenommen hat. Weil diese CA per nameConstraints auf partner-a.example beschränkt ist, kann auch eine fehlerhafte oder böswillige Ausstellung bei A kein Zertifikat für einen Namen von B erzeugen, das die Prüfung besteht. Was der Lieferant lesen oder ändern darf, entscheidet allein der Gateway. Den Ablauf im Einzelnen beschreibt Anbindung an den Database Gateway.

Ein Dienstleister (Partner C) wartet für drei Monate eine Anlage des Auftraggebers. Er braucht Zugriff auf zwei Dienste, für diesen Zweck und für diese Zeit.

1. Der Auftraggeber vereinbart mit C eine Beziehung. In seiner Richtung lässt er genau die beiden Dienste zu, setzt die Dauer auf drei Monate und verlangt das zusätzliche Post-Quanten-Geheimnis.
2. C hat keine eigene PKI. Er erhält eine Partner-CA in der Hierarchie des Auftraggebers; die Verantwortlichen von C geben die Zertifikate ihrer Systeme über das Partnerportal selbst frei.
3. Nach drei Monaten läuft die Beziehung ab. Neue Verbindungen kommen nicht mehr zustande, ohne dass jemand ein Konto sperren oder einen VPN-Zugang abbauen muss.
4. Endet die Zusammenarbeit früher, widerruft der Auftraggeber seine Richtung sofort.

Industrielle Geräte eines Partners erhalten ein Zertifikat mit kurzer Laufzeit und erneuern es selbstständig, ohne dass eine Person jede Erneuerung freigibt.

1. Das Gerät erzeugt sein Schlüsselpaar selbst und sendet einen CSR über EST (simpleenroll) oder Lightweight CMP, bei der Erneuerung mit seinem bisherigen Zertifikat.
2. Für die erste Ausstellung weist es sich mit dem Nachweis aus, den seine Profilklasse verlangt: einem vorab hinterlegten Einmalwert, seinem Herstellerzertifikat (IEEE 802.1AR) oder einer TPM-Attestierung.
3. Das Enrollment prüft, dass der Antrag zur automatischen Profilklasse passt und im Namensraum des Partners liegt, bildet den Auftrag und bestätigt ihn mit seinem Dienstschlüssel.
4. Der CA-Worker prüft die Bestätigung gegen sein Regelwerk und stellt aus.
5. Erneuert wird, sobald nur noch ein Drittel der Laufzeit übrig ist; die Mindestlaufzeit beträgt drei Tage, damit ein Ausfall des Enrollments von einem Tag nicht zum Ablauf führt.

Ein Server von Partner A gilt als kompromittiert; sein Zertifikat muss sofort unbrauchbar werden.

Grenze. Zwischen Sperrung und dem nächsten Abruf einer Gegenstelle vergehen bis zu sechs Stunden. Wer schneller wirken muss, widerruft zusätzlich die Beziehung: Das neue Vertrauensbündel erreicht die TLS-Adapter der widerrufenden Organisation innerhalb einer Stunde, auf Anforderung sofort.

Ausfall der Datenbank. Auch ohne Datenbank kann gesperrt werden: an der Konsole des Worker-Hosts. Die Sperrliste erreicht die Verteilung über einen zweiten Weg an der Datenbank vorbei.

Alle Systeme von Partner A sollen auf einen Schlag ihren Zugang verlieren.

Zwei Partner vereinbaren, dass ihre Verbindung auch gegen künftige Quantencomputer geschützt sein soll. Zwei Schutzziele sind zu unterscheiden:

Die erste Bedrohung ist dringender, weil der Angriff heute beginnt. Die zweite wird dringend, bevor ein Quantencomputer existiert, weil Vertrauensanker lange gelten. Beide Anforderungen trägt die Beziehungsrichtlinie ein; der TLS-Adapter setzt sie bei jeder Verbindung durch.

Ein Partner betreibt eine Schnittstelle, die sowohl beliebige HTTPS-Clients als auch Partnersysteme bedient.

TrustBridge zwingt keinem gewöhnlichen HTTPS-Client eine proprietäre Komponente auf. Hybride Zertifikate bleiben für klassische Prüfer lesbar: Die Alternativsignatur steht in nicht kritischen Erweiterungen, die ein Prüfer ohne PQ-Unterstützung übergeht.

Ein einzelnes Unternehmen nutzt TrustBridge für seine eigenen Dienste und Geräte. Es ist dann ein Mandant mit einer oder mehreren ausstellenden CAs; Beziehungen bestehen zwischen Organisationseinheiten oder Standorten mit eigenen Namensräumen.