Architekturableitung

Zusammenfassung. Diese Seite leitet die Architektur von WKL TrustBridge aus den Anforderungen ab. Sie geht in vier Schritten vor: Anforderungen mit ihrer Herkunft, daraus abgeleitete Sicherheitsziele, daraus folgende Entwurfsgrundsätze und schließlich die einzelnen Architekturentscheidungen mit den geprüften Alternativen und ihren Folgen. Wo eine Entscheidung aus Prüfersicht eine Schwäche hat, steht das ausdrücklich dabei, zusammen mit dem Ausgleich.

graph TD
  R[Regelwerke<br/>und Szenarien] --> A[Anforderungen<br/>A-01 bis A-24]
  A --> Z[Sicherheitsziele<br/>Z-1 bis Z-9]
  Z --> G[Entwurfsgrundsätze<br/>G-1 bis G-11]
  G --> E[Entscheidungen<br/>E-01 bis E-21]
  E --> K[Komponenten und Abläufe]
  E --> N[Nachweise]
  classDef s fill:#deecf9,stroke:#0078d4,color:#201f1e
  class R,A,Z,G,E,K,N s

Herkunft: R = Rechtsvorschrift, T = technische Empfehlung oder Standard, S = Szenario oder Schutzbedarf der Lieferkette. Die Regelwerke sind auf der Seite Grundlagen und Anforderungen erläutert.

Jede Entscheidung nennt die geprüften Alternativen und die Folgen. „Bewertung“ hält fest, wo eine Entscheidung aus Prüfersicht Schwächen hat.

Entscheidung. Nur der CA-Worker signiert. Er läuft nie im selben Prozess oder unter demselben Betriebssystemkonto wie ein Dienst mit HTTP-Eingang und hat keine eingehende Netzverbindung. Er liest Aufträge, prüft sie gegen ein lokales Regelwerk und signiert im Sicherheitsmodul.

Folgen. Ausstellung ist asynchron: Ein Antrag erzeugt einen Auftrag, das Zertifikat entsteht später. Schnittstellen dürfen nie auf die Signatur warten. Erfüllt: Z-1, Z-2 (G-1, G-4).

Entscheidung. Was ausgestellt werden darf, steht im lokalen Regelwerk des Workers (Datei auf dessen Host): zugelassene CAs je Profilklasse, Freigeber mit öffentlichen Schlüsseln, Laufzeiten, erlaubte Erweiterungen. Was ausgestellt und gesperrt wurde, steht in seinem lokalen, nur anfügbaren Register. Die Datenbank enthält Aufträge und Projektionen.

Folgen. Änderungen am Regelwerk sind ein Betriebsvorgang am Worker-Host, keine Klickaktion in der Verwaltung. Das Register muss gesichert und nach einer Wiederherstellung mit der Datenbank abgeglichen werden. Bewertung: Das Register wird zur einzigen Wahrheit über Ausstellung und Sperrung; sein Verlust wäre schwerwiegend. Daher Sicherung mit RPO nahe null und externer Anker des Kettenkopfs (siehe E-14). Erfüllt: Z-1, Z-4 (G-2).

Entscheidung. Ein manueller Auftrag wird freigegeben, indem eine im Regelwerk eingetragene Person den Hash des Auftrags mit ihrem persönlichen Schlüssel signiert. Standard ist eine Person, die nicht der Antragsteller ist; sicherheitsrelevante Profilklassen verlangen zwei verschiedene Personen. Automatische Profilklassen verlangen stattdessen eine Bestätigung (Attestierung) des Enrollments mit dessen Dienstschlüssel.

Bewertung. Die Regel „Antragsteller ist nicht Freigeber“ beruht bei einer einzelnen Freigabe auf einer Angabe, die der Worker nicht prüfen kann: Wer Verwaltung oder Datenbank kontrolliert und zugleich Freigeber ist, kann einen Antrag unter fremdem Namen einstellen und selbst freigeben. Die Aufgabentrennung ist kryptographisch belastbar erst mit zwei Freigeber-Signaturen. Für automatische Klassen gehört das Enrollment mit seinem Dienstschlüssel zur Vertrauensbasis – deshalb sind diese Klassen auf kurze Laufzeiten und den Namensraum des Partners beschränkt. Erfüllt: Z-1, Z-4 (G-3).

Entscheidung. Ein Auftrag ist ein vollständig aufgelöster Schnappschuss aller sicherheitsrelevanten Inhalte des künftigen Zertifikats, einmal als UTF-8-JSON erzeugt und danach byte-genau gespeichert, übertragen und signiert. Seine Kennung ist der SHA-256 über diese Bytes. Die Seriennummer erzeugt der Worker (mindestens 64 Bit Zufall).

Folgen. Was eine Person freigibt, ist bitgenau das, was ausgestellt wird. Die Verwaltungsanwendung muss den Auftrag aus genau den signierten Bytes anzeigen. Erfüllt: Z-1.

Entscheidung. Jeder Partner hat mindestens eine eigene ausstellende CA, deren Zertifikat per nameConstraints (kritisch) seinen DNS-Namensraum festlegt. Ein System ist genau ein dNSName darin. Subject, CN, O und eigene OIDs sind nie sicherheitsrelevant; andere SAN-Arten sind nur ausstellbar, wenn das CA-Zertifikat sie ebenfalls beschränkt.

Folgen. Die letzte Verteidigungslinie liegt bei der prüfenden Gegenstelle: Sie muss nameConstraints durchsetzen. Daraus folgt der Prüfer-Vertrag. Bewertung: Nicht jede TLS-Bibliothek setzt Namensbeschränkungen vollständig durch; der Prüfer-Vertrag muss in Partnerverträge eingehen und mit Testzertifikaten überprüfbar sein. Erfüllt: Z-1, Z-5 (G-6).

Entscheidung. Status wird über Sperrlisten (CRL) veröffentlicht, die der Worker vorab erzeugt: Gültigkeit 72 Stunden, neu alle 6 Stunden und sofort nach jeder Sperrung; CRL-Nummer streng steigend aus dem Register. Delta-Sperrlisten und OCSP werden nicht angeboten.

Folgen. Zwischen Sperrung und Kenntnis der Gegenstelle liegen bis zu sechs Stunden (Ladetakt). Der Puffer von 66 Stunden (Gültigkeit minus Takt) ist die Zeit, die der Betrieb zum Wiederherstellen eines ausgefallenen Workers hat. Erfüllt: Z-3 (G-4, G-5).

Entscheidung. Sperrlisten erreichen die Verteilung über die Datenbank und über einen zweiten Weg an ihr vorbei. Die Verteilung besitzt keinen Schlüssel, prüft jede Signatur und liefert die höchste gültige CRL-Nummer aus. Gesperrt werden kann auch an der Konsole des Worker-Hosts.

Alternative: nur ein Weg über die Datenbank – verworfen, weil ein Datenbankausfall dann nach spätestens 72 Stunden jede Prüfung scheitern ließe und niemand sperren könnte. Erfüllt: Z-3 (G-5).

Entscheidung. Ein hybrides Zertifikat trägt einen klassischen Subjektschlüssel und einen ML-DSA-Schlüssel (subjectAltPublicKeyInfo, 2.5.29.72); die CA signiert mit ML-DSA in altSignatureValue (2.5.29.74) und danach klassisch über den gesamten signierten Teil. Die Erweiterungen sind nicht kritisch.

Bewertung. Die Alternativsignatur ist trennbar: Wer künftig die klassische Signatur fälschen kann, kann ein Zertifikat ohne PQ-Erweiterungen erzeugen. Schutz besteht deshalb nur, wenn die Gegenstelle die Alternativsignatur verlangt und ein fehlendes Glied als ungültig wertet (Punkt 9 des Prüfer-Vertrags, kein stiller Rückfall nach G-8). Erfüllt: Z-6.

Entscheidung. CA-Schlüssel entstehen im Sicherheitsmodul und bleiben dort, nicht exportierbar, klassisch wie ML-DSA. Es gibt keinen Software-Schlüssel für eine CA, auch nicht übergangsweise. Ein Modul ohne nicht exportierbares ML-DSA ist nicht zulässig. Der Worker prüft beim Start Fingerabdruck und Nicht-Exportierbarkeit; ein Schlüssel gehört zu genau einer CA.

Alternative: ML-DSA vorübergehend in Software – verworfen, weil ein einmal exportierbarer Schlüssel nicht nachträglich vertrauenswürdig wird. Erfüllt: Z-2.

Entscheidung. Die Wurzel-CA ist dauerhaft offline. Sie signiert ausstellende CAs nur in einer Zeremonie mit benannten Rollen. Was sie signiert, stammt nie aus dem Online-System: Schlüssel und Namensraum werden über einen zweiten Kanal bestätigt; über die Grenze gehen nur abschließend aufgezählte Artefakte. Erfüllt: Z-2 (A-19).

Entscheidung. In der Zertifizierungsstelle kommen Post-Quanten-Verfahren über einen gemeinsamen .NET-Baustein aus OpenSSL (ab 3.5); klassische Verfahren (RSA, ECDSA, AES, Hashes, ASN.1, X.509-Typen) bleiben bei der Kryptographie des .NET-Frameworks. Die Endpunktkomponenten sind eigenständige native Programme mit einer TLS-Bibliothek, die RFC 9973 unterstützt.

Erfüllt: Z-6, A-06.

Entscheidung. Die Verwaltung bedienen die Mitarbeiter einer Organisation und ihres Betriebspartners mit einer Access-Anwendung, die ausschließlich die Verwaltungs-API über HTTPS anspricht: Listen als OData-v4-Mengen über einen ODBC-Treiber, der nur HTTP spricht, Befehle über eine VBA-Klasse. Eine Datenbankverbindung aus dem Client ist ausgeschlossen.

Erfüllt: Z-5, A-10, A-20.

Entscheidung. Partnersysteme sprechen Standardprotokolle (ACME, EST), deren Adapter das Protokoll vollständig umsetzen und fachliche Entscheidungen an einen gemeinsamen Kern delegieren. Verwaltung und Automatisierung nutzen dieselbe fachliche API (OData v4 mit Aktionen) und dieselben Rechte.

Erfüllt: A-13, A-20 (G-7).

Entscheidung. Betriebsprotokoll (ohne Beweiswert), Sicherheitsaudit in der Datenbank (je Mandant verkettet, laufend extern kopiert) und manipulationsnachweisendes Register von Worker und Wurzel. Kettenköpfe gehen periodisch an einen nur anfügbaren Speicher außerhalb von Datenbank und Worker-Host.

Alternative: signierte Kettenköpfe mit einem eigenen Schlüssel – verworfen, weil ein nur anfügbarer externer Speicher dasselbe ohne zusätzlichen Schlüssel leistet. Erfüllt: Z-4.

Entscheidung. Fachliche Fremdschlüssel tragen den Mandanten; zusätzlich filtert Row-Level Security beim Lesen. Personen erhalten benannte Sichtbereiche (alle Mandanten, eine Gruppe, ein Mandant), damit sowohl der Support mit protokollierter Einsicht als auch ein internes Berechtigungsmodell einer Lieferkette abbildbar sind. Erfüllt: Z-5.

Entscheidung. WKL TrustBridge umfasst die Zertifizierungsstelle jeder Organisation, die bilateralen Vertrauensbeziehungen, die Schlüsselagenten mit lokalem Schlüsselvermittler, den TLS-Adapter und die Anbindung an Zielanwendungen wie den Database Gateway. Nicht dazu gehören Berechtigungen in den Zielanwendungen, Workload-Identitäten nach SPIFFE und Anmeldedienste für Personen.

Begründung. Die Zertifizierungsstelle allein liefert Identitäten, aber keine Zusammenarbeit: Zwischen Organisationen braucht es die Beziehung, die Durchsetzung an der Verbindung und den Schutz des Verkehrs. Die Sicherheitsregeln der Zertifizierungsstelle bleiben dabei unverändert: Sie erzeugt keine Schlüssel für andere und kennt kein Sitzungsgeheimnis (G-11). SPIFFE-Identitäten sind URI-Namen, die das Identitätsmodell (genau ein DNS-Name je System) nicht vorsieht. Erfüllt: Z-8, Z-9.

Entscheidung. Organisationen erkennen Vertrauensanker der Gegenseite je Beziehung an. Die freigegebene Beziehung erreicht TLS-Adapter und Schlüsselagenten als vom CA-Worker der Organisation signiertes Vertrauensbündel mit steigender Nummer und begrenzter Laufzeit.

Folgen. Jede Organisation pflegt ihre Beziehungen selbst; neue Partner brauchen eine Vereinbarung mit jeder Organisation, mit der sie arbeiten. Erfüllt: Z-8 (G-2, G-9).

Entscheidung. Schlüsselagenten vereinbaren über ML-KEM, authentisiert mit ML-DSA-Agentenzertifikaten, ein Geheimnis je Beziehung und Rechnerpaar. Der TLS-Adapter bringt es als externen PSK mit der Erweiterung tls_cert_with_extern_psk (RFC 9973) in den Handshake von TLS 1.3 ein, im Modus psk_dhe_ke mit hybrider Gruppe und gegenseitiger Zertifikatsauthentisierung.

Bewertung. RFC 9973 wertet den PSK ausdrücklich nicht als Authentisierung. Die Authentisierung bleibt bei den hybriden Zertifikaten (E-08); das zusätzliche Geheimnis stärkt die Vertraulichkeit und bindet die Verbindung an die Beziehung. Erfüllt: Z-9 (G-8, G-11).

Entscheidung. Das Geheimnis gelangt vom Schlüsselagenten über einen Schlüsselvermittler auf demselben Rechner zum TLS-Adapter. Es verlässt den Rechner nie und wird nicht auf Datenträger geschrieben.

Alternative: zentraler Schlüsseldienst, der Geheimnisse an Endpunkte verteilt – verworfen, weil er alle Verbindungen kennen würde und damit die Vertrauensbasis um ein Online-Ziel mit höchstem Wert erweiterte. Erfüllt: Z-9 (G-1, G-11).

Entscheidung. TLS 1.3 nimmt ein neues externes Geheimnis nur beim Verbindungsaufbau auf. Der TLS-Adapter ersetzt deshalb jede Verbindung, sobald sie die in der Beziehung festgelegte Höchstdauer erreicht, durch eine neue mit dem aktuellen Geheimnis, bevor die alte endet. Sitzungswiederaufnahme ist für Beziehungsverbindungen abgeschaltet.

Erfüllt: Z-9.

Entscheidung. Im Modell Managed betreibt ein Betriebspartner die Installation einer Organisation. Freigeber und Verwahrer sind ausschließlich Personen der Organisation; CA-Schlüssel liegen in einem Sicherheitsmodul oder einer Partition, die nur dieser Organisation zugeordnet ist. Ein Wechsel des Betreibers verläuft über eine neue CA-Generation, nicht über einen Schlüsselexport.

Alternative: Betriebspartner als Freigeber im Auftrag – verworfen, weil er dann im Namensraum der Organisation ausstellen könnte, ohne dass sie mitwirkt. Erfüllt: Z-1, Z-2.

• Keine Wirksamkeit. Ob eine Entscheidung ihr Ziel erreicht, belegt das Nachweisverfahren der zugehörigen Zusage auf der Seite Sicherheitszusagen.
• Keine Vollständigkeit der Anforderungen. Die Anforderungen stammen aus den Regelwerken und Szenarien auf der Seite Grundlagen und Anforderungen, nicht aus jeder denkbaren Pflicht eines Kunden.