Enterprise PKI · Digital Trust Engineering
SYNRION x.ID · ARCHITEKTUR
Vom kompakten Aufbau bis zur verteilten PKI: Entdecken Sie die Rollen, folgen Sie einem Request und sehen Sie, wo das Zertifikat entsteht.
Alle Services · Datenbank · CA
Das Einstiegspaket bringt alle benötigten x.ID-Services, die Datenbank und eine CA mit. Die zentrale Steuerung, Policy-Verarbeitung und CA-Anbindung sind im Paket zusammengefasst. Eine vorhandene eigene PKI ist für dieses Beispiel nicht Voraussetzung.
LDAP und Entra können bei Bedarf über eigene Outposts angebunden werden. Die kleine Darstellung vereinfacht den Aufbau, nicht die Sicherheitsprinzipien.
Browser · Agent · Hardwaretoken
Der Benutzer arbeitet mit Browser, x.ID Agent und Hardwaretoken. Die privaten Token-Schlüssel werden auf der Hardware erzeugt und bleiben dort.
Ein Jump Host ist in diesem kompakten Beispiel nicht als zusätzliche Voraussetzung dargestellt.
Im Paket enthalten
Die Datenbank für Inventar, Zuordnungen und Betriebsdaten wird mitgebracht. Du musst dafür kein eigenes Datenbanksystem bereitstellen.
Zertifikate im eigenen Setup
Die mitgelieferte CA stellt die Zertifikate für den Einstieg bereit. Der im Paket enthaltene CA Connector reicht die nach Policy geprüften Requests ein; der Agent übernimmt die Zertifikatsprovisionierung.
Die CA ist Bestandteil des Angebots, keine zusätzliche externe Voraussetzung.
YubiKey beim Benutzer
Der Benutzer verbindet sich per RDP mit dem Jump Host. Für PIV wird der lokale YubiKey als Smartcard in die Sitzung durchgereicht. Für FIDO muss der x.ID Agent auf dem Benutzerhost laufen.
Private Token-Schlüssel entstehen auf dem Hardwaretoken und verlassen ihn nicht.
Browser + x.ID Agent · PIV
Auf dem Jump Host öffnet der Benutzer die x.ID-Webseite. Dort läuft der Agent für die PIV-Provisionierung und greift auf den per RDP durchgereichten Token zu.
Der dargestellte Zertifikatsablauf ist PIV. Die FIDO-Agent-Platzierung ist davon getrennt.
OIDC
Der Browser authentifiziert den Benutzer beim Identity Provider. Nach der OIDC-Anmeldung greift der Benutzer auf den Core zu.
Authentifizierung ersetzt nicht die spätere Policy- und Quellenprüfung durch PEP.
Lifecycle und Policy-Routing
Der Core erledigt die zentrale Steuerung. Er ordnet Identität, Token und Request zu und wählt nach Policy den vorgesehenen Verarbeitungsweg, die Ziel-CA und das Template. Das ausgestellte Zertifikat gibt er an den Agent zurück.
Ein zentraler Core. Die Zeichnung zeigt logische Rollen, keine feste Anzahl von Servern.
Quellenprüfung + Signatur 1
PEP User gleicht den Request und die Policy gegen die zuständige Identitätsquelle ab und signiert den Request. Danach geht er direkt zum CA Connector oder nach Policy zur zusätzlichen Prüfung an PEP Admin.
Die Quelle kann AD / LDAP des zuständigen Forests oder Entra sein.
Erneute Prüfung + Signatur 2
PEP Admin prüft erneut gegen die zuständige Quelle und ergänzt eine zweite Signatur. Dieser Policy-Weg kann zu einer anderen CA und einem anderen Template führen als der direkte User-Weg.
Im Enterprise-Beispiel führt dieser Weg zum CA Connector B und zur CA B.
CA Connector
Outpost · CA-Anbindung
Der Connector reicht den signierten Request bei der ausgewählten CA ein. Er nimmt das ausgestellte Zertifikat entgegen und gibt es an den Core zurück.
Die Zertifikatsrückgabe läuft zum Core und anschließend zum Agent.
Outpost · andere PKI-Zone
Dieser Connector bedient die CA des Admin-Wegs. Hier wird der nach PEP User und PEP Admin zweifach signierte Request eingereicht. Das Zertifikat geht zurück an den Core.
Die PEP-Signaturen am Request sind von der CA-Signatur des Zertifikats zu unterscheiden.
Eine CA
User-Templates
Mehrere Templates
Der direkte User-Weg führt in diesem Beispiel zu CA A. Innerhalb der CA wird das passende Template nach Policy ausgewählt.
Im kompakten Setup reicht eine CA mit mehreren Templates. Die Policy bestimmt, welches Template für den jeweiligen Request verwendet wird.
Root-Vertrauen: beispielsweise RSA 4096 oder ECC P-521.
Admin-Templates
Der zusätzliche Admin-Weg führt hier bewusst zu einer anderen CA in einer getrennten PKI-Zone. Die Policy bestimmt Ziel-CA und Template.
Getrennte CAs sind eine mögliche Architektur. Beide Wege könnten nach Policy auch dieselbe CA nutzen.
Multi-Forest · Multi-Domain · Entra
AD / LDAP · Entra
Forest A mit Domains A1/A2 und Forest B mit Domains B1/B2 stehen beispielhaft für mehrere unabhängige Verzeichnisbereiche. Entra ist zusätzlich nativ angebunden. Jede PEP-Prüfung verwendet die jeweils zuständige Quelle.
Das kompakte Beispiel nutzt eine Domain in einem Forest. Entra kann ergänzend angebunden werden. Der jeweilige PEP prüft gegen die zuständige Quelle.
Lesende Quellenprüfung und schreibende Provisionierung sind getrennte Aufgaben.
Verzeichnis provisionieren
Der LDAP-Outpost übernimmt die Provisionierung in LDAP / Active Directory. Im Enterprise-Aufbau werden die zuständigen Forests und Domains über passende Anbindungen erreicht.
Dies ist ein eigener Aufgabenbereich neben PEP und CA Connector.
Cloud-Identitäten provisionieren
Der ENTRA-Outpost übernimmt die Provisionierung in Microsoft Entra ID. Er ist kein CA Connector und ersetzt keine PEP-Prüfung.
Entra bleibt als eigenständiges Ziel sichtbar.
Optional anbinden
Forest A / B · Domains A1 / A2 / B1 / B2
Ein Forest · eine Domain
Ziel der LDAP-Provisionierung. Zuständigkeiten und Freigaben werden pro Umgebung festgelegt.
Native Anbindung
Eigenständige Cloud-Identitätsquelle und Provisionierungsziel für den ENTRA-Outpost.
Vom Arbeitsplatz aus wird der Request an das enthaltene x.ID-System übergeben.
Der Core steuert den Vorgang. Die enthaltenen Policy-Dienste prüfen und signieren gemäß Konfiguration; der CA Connector übernimmt die Einreichung.
Die im Paket enthaltene CA stellt das Zertifikat aus. Eine zusätzliche eigene PKI ist im einfachen Setup nicht erforderlich.
Die enthaltenen Dienste geben das Zertifikat an den Agent zurück. Er provisioniert den Hardwaretoken; der private Token-Schlüssel bleibt auf der Hardware.
RDP zum Jump Host, PIV-Smartcard-Durchreichung und OIDC über AD FS oder Keycloak.
Nach der Anmeldung steuert der Core den Auftrag und wählt den Policy-Weg. Private Token-Schlüssel werden nicht übertragen.
PEP User prüft gegen die zuständige Identitätsquelle und setzt die erste Signatur. Danach bestimmt die Policy den weiteren Weg.
PEP User gleicht gegen die zuständige Identitätsquelle ab und setzt die erste Signatur. Danach geht der Request an PEP Admin, nicht direkt zur CA.
Quellenabgleich und erste PEP-Signatur. Danach führt der direkte Weg zum CA Connector.
PEP Admin erhält den bereits von PEP User signierten Request, prüft erneut gegen die zuständige Identitätsquelle und setzt die zweite Signatur. Erst danach geht es über CA Connector B zur CA B.
CA Connector B reicht den zweifach PEP-signierten Request bei CA B mit dem passenden Template ein.
Der CA Connector reicht den einfach PEP-signierten Request mit dem passenden Template bei der CA ein.
Die CA stellt das Zertifikat aus. Der zuständige Connector gibt es an den Core zurück.
Core → Agent auf dem JMP → durchgereichter YubiKey. Das Zertifikat wird provisioniert; der private Schlüssel bleibt auf dem Token.
Nach PEP User bestehen zwei alternative Wege: direkt zum CA Connector A oder mit zusätzlicher Quellenprüfung und zweiter Signatur über PEP Admin zum CA Connector B. Pro Request entscheidet die Policy; die beiden Wege laufen nicht gleichzeitig ab.
