Schnittstellen und Integration

Zusammenfassung. WKL TrustBridge unterscheidet vier Arten von Schnittstellen: standardisierte Protokolle für Partnersysteme (ACME, EST, CMP), die öffentliche Verteilung von CA-Zertifikaten, Sperrlisten und Vertrauensbündeln per HTTP, eine fachliche Verwaltungs-API für Verwaltungsanwendung, Partnerportal und Automatisierung und die lokalen Schnittstellen von TLS-Adapter und Schlüsselagent auf jedem angebundenen Rechner. Standardisierte Endpunkte werden unverändert umgesetzt; eine eigene Schnittstelle gibt es nur, wo kein Standard existiert. Alle Wege führen zu denselben fachlichen Operationen und denselben Rechten.

• Protokolladapter – Komponente, die ein Standardprotokoll vollständig umsetzt (Nachrichten, Signaturen, Zustände, Fehlerformate) und die fachliche Entscheidung an den gemeinsamen Kern weitergibt.
• Fachlicher Kern – Verwaltung und Enrollment-Kern: Autorisierung, Mandant, Bildung des Auftrags, Audit.
• OData v4 – OASIS- und ISO/IEC-Standard für REST-Schnittstellen mit maschinenlesbarem Schema, Abfrageoptionen und Aktionen.
• Befehl – Operation, die über eine Zeile hinaus wirkt, einen Auftrag erzeugt oder ein Geheimnis zurückgibt; als OData-Aktion bzw. POST umgesetzt.

Ein Partnersystem soll für gewöhnliche PKI-Vorgänge keinen eigenen Client von TrustBridge brauchen. Deshalb werden standardisierte Endpunkte genau so umgesetzt, wie die Spezifikation sie beschreibt – einschließlich ihrer Pfade und Fehlerformate –, statt sie in eine eigene Namenskonvention zu übersetzen. Bei großen Anbietern privater CAs ist das Muster dasselbe: Systeme sprechen IETF-Protokolle, die Verwaltung eine eigene, ressourcenorientierte API.

Wrapper-Prinzip. Ein Adapter ist vollständig im Protokoll und dünn in der Fachlogik:

Der Kern muss nicht wissen, was eine ACME-Bestellung ist; er versteht: Ein autorisierter Teilnehmer beantragt ein Zertifikat für eine bestimmte Identität in einer bestimmten Profilklasse. Signiert wird weder im Adapter noch im Kern, sondern später im CA-Worker; kein Adapter wartet auf die Signatur.

Zusätzliche Pfadsegmente je CA oder Profil sind nach RFC 7030 zulässig.

Lightweight CMP ist in industriellen Geräten und Steuerungen verbreitet. TrustBridge bietet es für Profilklassen von Maschinen und Geräten an, mit Herstellerzertifikat (IEEE 802.1AR) als Nachweis der Erstausstattung. Wie bei ACME und EST erzeugt der Adapter nur einen Auftrag; signiert wird im CA-Worker.

SCEP wird nicht angeboten. Es authentisiert die Erstausstattung mit einem gemeinsamen Challenge-Kennwort, das den Anforderungen an die Erstausstattung nicht genügt. Geräteverwaltungen, die nur SCEP sprechen, werden über einen vorgelagerten Dienst mit EST oder CMP angebunden.

Die Verwaltungs-API ist die eine fachliche Schnittstelle für Verwaltungsanwendung, Partnerportal und Automatisierung. Alle drei durchlaufen dieselben Prüfungen, Rechte und Audit-Einträge; ob ein Befehl aus Access oder aus einem Skript kommt, macht keinen Unterschied.

Warum OData und nicht reine REST-Listen. Die Verwaltungsanwendung verknüpft Listen über einen ODBC-Treiber, der ausschließlich OData spricht; reine REST-Listen kann er nicht verknüpfen. OData ist ein REST-Standard; die daraus erzeugte OpenAPI-Beschreibung bedient Werkzeuge ohne OData. Eine zweite REST-Lesefläche neben den OData-Mengen würde dieselben Daten zweimal liefern und zweimal berechtigt und geprüft werden müssen.

Warum kein OAuth für Personen. Der ODBC-Treiber der Verwaltungsanwendung unterstützt Schlüssel in einer Kopfzeile, Windows-Anmeldung und Basic-Anmeldung, aber keine Bearer-Tokens. Für Personen bleibt es deshalb beim persönlichen Schlüssel mit zweitem Faktor.

Die Anmeldung von Personen – persönlicher Schlüssel in einer Kopfzeile, zweiter Faktor über einen Einmalcode, Sitzung in einer Kopfzeile – ist an den Möglichkeiten des ODBC-Treibers der Verwaltungsanwendung ausgerichtet. Diese Ausrichtung darf das Sicherheitsniveau nicht bestimmen; die folgende Analyse bewertet die Anmeldung deshalb gegen die einschlägigen Bedrohungen.

Windows-Anmeldung. In Windows-Domänen melden sich Personen alternativ über Kerberos (Negotiate) an. Damit entfällt das gespeicherte Inhabergeheimnis; mit einer Chipkarten-Anmeldung an Windows ist die Anmeldung phishing-resistent. Die Sicherheit hängt dann an der Domäne; jede Organisation wählt das Verfahren für ihre Personen.

Eine Freigabe ist keine angemeldete Bestätigung, sondern eine Signatur der Person über den Hash des Auftrags. Der Ablauf über die API:

sequenceDiagram
  participant P as Person
  participant A as Verwaltungsanwendung
  participant V as Verwaltungs-API
  P->>A: Auftrag öffnen
  A->>V: Auftragsbytes abrufen
  V-->>A: Bytes, unverändert
  A->>A: SHA-256 bilden, mit Kennung vergleichen,<br/>Inhalt aus genau diesen Bytes anzeigen
  P->>A: freigeben
  A->>A: Hash mit persönlichem Schlüssel signieren
  A->>V: Aktion: Freigabe einreichen (Signatur)
  V->>V: speichern, nicht prüfen
  Note over V: Die Prüfung macht der CA-Worker

Die API bezeugt nichts und prüft die Signatur nicht; sie reicht sie weiter. Der Freigabe-Schlüssel liegt auf einer Chipkarte oder einem Sicherheitsschlüssel mit PIV-Funktion und verlangt für jede Signatur die PIN der Person.

Befehle der Verwaltungs-API ändern Zustände nur in der Datenbank; das Ergebnis des CA-Workers erscheint später als Projektion. Für die Verwaltungsanwendung heißt das: Nach einem Befehl wird der Auftrag erneut gelesen, nicht auf eine Antwort des Workers gewartet.

Den Übergang nach „Freigabe vollständig“ setzt der CA-Worker, weil nur er die Freigaberegeln seines Regelwerks kennt. Bis dahin zeigt die API die eingereichten Freigaben an.

Die Verwaltungsanwendung ist das Werkzeug der Mitarbeiter einer Organisation und ihres Betriebspartners (Systemverwaltung, Partnerverwaltung, Support). Sie ist eine Access-Anwendung, die ausschließlich die Verwaltungs-API anspricht: Listen sind verknüpfte OData-Mengen, Befehle laufen über eine VBA-Klasse. Eine Datenbankverbindung aus dem Client ist ausgeschlossen.

Das Partnerportal ist die Weboberfläche für Verantwortliche eines Partners, dessen ausstellende CA in der Hierarchie des Auftraggebers liegt. Es nutzt dieselbe Verwaltungs-API mit einem Sichtbereich je Partner: Anträge stellen, eigene Aufträge freigeben, Inventar und Sperrstatus des eigenen Namensraums einsehen, Sperrungen auslösen. Partner mit eigener Installation verwenden ihre eigene Verwaltungsanwendung.

• Kein SCEP und keine Schlüsselerzeugung für Antragsteller.
• Keine Identitätsversorgung kurzlebiger Workloads über die SPIFFE-Workload-API. TrustBridge vergibt genau einen DNS-Namen je System; URI-Namen sind nicht vorgesehen.
• Keine Gestaltung der Verwaltungsanwendung und des Partnerportals. Diese Seite beschreibt die Schnittstelle, die sie nutzen, nicht ihre Oberfläche.

• RFC 8555 – ACME: Verzeichnis, Konten, Bestellungen, Nachweise, External Account Binding (Abschnitt 7.3.4).
• RFC 7030 – EST: Endpunkte unter /.well-known/est/, Authentisierung, optionale Pfadsegmente.
• RFC 9483 – Lightweight CMP Profile: Profil für industrielle Geräte.
• OData Version 4.01: Protokoll, Schemaformat, Abfrageoptionen.
• RFC 9745 – Deprecation-Kopfzeile und RFC 8594 – Sunset-Kopfzeile: Ankündigung des Endes einer API-Fassung.