Eine verantwortliche Person
Die Primäridentität bleibt der eindeutige Eigentümer jeder zusätzlichen Rolle und jedes Zertifikats.
MULTI-IDENTITY YUBIKEY MANAGEMENT
Ein YubiKey. Mehrere Identitäten. Klare Zuständigkeit.
Benutzerkonto, Administration und weitere Rollen können einen YubiKey teilen. SYNRION x.ID ordnet jeder Identität ihre Zertifikate, Aussteller, PIV-Slots und Regeln zu. Das freigegebene Slotprofil bestimmt, was gemeinsam auf die Hardware passt.
NUTZEN IN 30 SEKUNDEN
Weniger physische Schlüssel, ohne Verantwortungen zu vermischen.
Getrennte Anwendungsfälle
Zertifikate, Domains und Rollen bleiben logisch zugeordnet. Gemeinsame Hardware ist dabei ausdrücklich keine physische Trennung von Administrationstiers.
Unabhängige Lifecycles
Eine Sekundäridentität lässt sich ausgeben, erneuern oder entfernen, ohne das gesamte Gerät zur unkontrollierten Ausnahme zu machen.
EIN TRÄGER · KONTROLLIERTE IDENTITÄTEN
Wie bleiben Identitäten auf gemeinsamer Hardware unterscheidbar?
Die Lösung ist nicht, den YubiKey als eine globale Identität zu behandeln. x.ID modelliert Person, jede Sekundäridentität, ihr Zertifikat und ihren erlaubten Einsatz als getrennte, aber verbundene Objekte.
-
01
Primäridentität verankern
Mit der verifizierten Person beginnen, die für die Hardware und jede darauf zugeordnete Sekundäridentität verantwortlich ist.
-
02
Rollen und Trust-Grenzen definieren
Sekundäridentitäten für getrennte Administrationstiers, Domains, Forests, Anwendungen oder Betriebsaufgaben anlegen.
-
03
Geeignete PIV-Slots zuordnen
Jede unterstützte Zertifikatsidentität in einem kontrollierten Slot platzieren und die Zuordnung für Administratoren und Prüfer sichtbar halten.
-
04
Ausgabe-Policy durchsetzen
Hardwarenachweis, Identität, Rolle und erforderliche Freigaben prüfen, bevor eine Sekundäridentität aktiv wird.
-
05
Jede Zuordnung im Zielverzeichnis pflegen
Zertifikat und starke Zuordnung für jede Identität im vorgesehenen AD- oder Entra-Kontext setzen, statt nur den Token-Slot zu dokumentieren.
-
06
Jede Identität gezielt betreiben
Die betroffene Identität erneuern, sperren oder entfernen und die übrigen freigegebenen Rollen auf demselben Schlüssel erhalten.
DIE ARCHITEKTUR AUF EINEN BLICK
Aktive Identitäten und S/MIME-Archivplätze bewusst verteilen – auch über Retired Slots.
TECHNISCHE TIEFE
Kapazität ist eine Architekturentscheidung, kein pauschales Versprechen.
Das physische Gerät kann Credentials konsolidieren. Die nutzbare Belegung muss jedoch gegen Hardware, Kryptografie, Anwendungen und organisatorische Trennungsregeln geplant werden.
- 24 Zertifikatsplätze sind nicht 24 vollständige Identitätsprofile
- Die hier beschriebenen PIV-fähigen YubiKeys bieten vier klassische und zwanzig Retired-Key-Management-Slots. Für x.ID gilt Firmware ab 5.3; einzelne Funktionen können neuere Firmware erfordern. Wie viele Identitäten hineinpassen, bestimmen Zertifikate je Identität, Anwendungen, S/MIME-Reservierungen und das freigegebene Slotprofil – nicht die Slotzahl allein.
- Retired Slots für aktive Identitäten und S/MIME-Archiv
- Die zwanzig Retired-Key-Management-Slots 82–95 sind im PIV-Modell für frühere Entschlüsselungsschlüssel vorgesehen. x.ID kann unterstützte Slots gezielt auch für aktive Identitäten mit individuellen CA-Profilen nutzen. Reservierte S/MIME-Archivplätze bleiben dafür frei. Firmware, Kryptografie, Zielanwendung und Policy müssen die jeweilige Belegung erlauben.
- Rollentrennung
- Eigene Zertifikate und Policies trennen die logischen Identitäten, nicht das physische Gerät. Die PIV-Anwendung verwendet eine gemeinsame PIN; ein Geräteverlust betrifft alle darauf liegenden Identitäten. Verlangt die Tier- oder Rollen-Policy getrennte Hardware, bleiben getrennte Schlüssel erforderlich.
- Rollback ohne privaten Schlüsselexport
- x.ID kann hardwareinterne Backup-/Rollback-Möglichkeiten für einen fehlgeschlagenen Vorgang nutzen. Privates PIV-Schlüsselmaterial verlässt dabei niemals den YubiKey. Es entsteht keine PFX-Datei und kein Schlüsselklon für ein Ersatzgerät. S/MIME-Archivierung bleibt eine eigene Slotplanung.
- Zuordnung in AD und Entra
- Mehrere Identitäten benötigen nicht nur getrennte Slots, sondern auch korrekte Zielzuordnungen. x.ID verbindet den LDAP-Pfad für userCertificate und X509:<SKI> mit dem nativen Azure-Connector-Pfad für Microsoft Entra ID.
NACHWEIS & GRENZEN
Was bei konsolidierten Identitäten kontrollierbar bleibt.
Entscheidend ist nicht die maximale Slot-Zahl. Entscheidend ist, Hardware zu reduzieren und trotzdem jede Identität verständlich und veränderbar zu halten.
Identität-zu-Slot-Zuordnung
Administratoren sehen, welche Sekundäridentität, welches Zertifikat und welcher Anwendungsfall zusammengehören.
Policy je Identität
Freigabe- und Lifecycle-Regeln können sich nach Rolle, Tier, Domain oder Anwendungskontext unterscheiden.
Kontrollierte Entfernung
Eine Rolle lässt sich entfernen, ohne automatisch alle übrigen Identitäten auf der Hardware zu verwerfen.
Zielsysteme bleiben konsistent
Entfernte oder erneuerte Identitäten werden auch in AD- und Entra-Zuordnungen gezielt nachgeführt.
PASSENDES PRODUKT
SYNRION x.ID
YubiKeys, Identitäten, PIV-Zertifikate und FIDO2 zentral im Browser verwalten. SYNRION x.ID verbindet native Entra-Anbindung mit Cloud-, On-Premises- oder Hybridbetrieb über Outpost-Connectoren. Das Portal ist auch mobil bedienbar; Freigabestatus und Voraussetzungen stehen in der Funktionsübersicht.
NÄCHSTER KONTROLLIERTER SCHRITT
Ordnen Sie Ihre Rollen, bevor Sie pro Identität einen Schlüssel kaufen.
Wir betrachten Tiers, Domains, Anwendungen und Trennungsvorgaben und zeigen, welche Identitäten Hardware teilen können, ohne Kontrolle zu verlieren.