YubiKey-Verwaltung mit x.ID: Fragen und Antworten.

PIV steht für Personal Identity Verification. Auf einem kompatiblen Security Key stellt die PIV-Anwendung definierte Slots für private Schlüssel und X.509-Zertifikate zur Authentifizierung, Signatur oder Schlüsselverwaltung bereit.

PIV Attestation ist ein kryptografischer Nachweis, dass ein unterstützter privater Schlüssel auf dem YubiKey erzeugt und nicht von außen importiert wurde.

x.ID kann Attestation zu einer verpflichtenden Bedingung des Enrollments machen. Der Schlüssel wird im vorgesehenen PIV-Slot erzeugt, die verfügbare Attestation Chain geprüft und die Policy entscheidet vor der Zertifikatsausgabe, ob der Hardwarenachweis ausreicht.

Ja. x.ID steuert FIDO2-Geräteanwendungen über USB und NFC. Zum Funktionsumfang gehören außerdem Entra-FIDO2-Vorprovisionierung mit persönlicher PIN-Übergabe und zentrale Erfassung discoverable FIDO2-Credentials auf unterstützten YubiKeys ab Firmware 5.8. Der jeweilige Freigabestatus ist direkt bei der Funktion ausgewiesen.

Passkeys sind an den jeweiligen Dienst gebundene Public-Key-Credentials und auf Phishing-Resistenz ausgelegt. Ihre tatsächliche Sicherheit hängt trotzdem von Authenticator, Geräteschutz, Registrierung, Recovery und der durchgesetzten Policy ab.

Inventory erkennt Bestand und Zustand. Register nimmt den PIV-Token unter Verwaltung und kontrolliert den Management Key. Assign ordnet ihn einer verantwortlichen Identität zu. Erst Enroll erzeugt Schlüssel, CSR und Zertifikat und stellt den vorgesehenen Zielzustand her.

PIV-fähige YubiKeys ab Firmware 5.3 sind für den x.ID-PIV-Lifecycle freigegeben. Gemeint ist die Firmwareversion, nicht eine Modellbezeichnung. Ein reiner FIDO-Security-Key ohne PIV-Anwendung gehört nicht dazu.

Thales SafeNet eToken Fusion, Nitrokey 3 und Swissbit-Token sind in x.ID-Lifecycle-Prozesse eingebunden. Den aktuellen Freigabestatus finden Sie direkt bei dieser Antwort. Nicht alle Funktionen sind mit jedem Token verfügbar; der Funktionsumfang hängt vom konkreten Modell und dessen Firmware ab.

Die hier beschriebenen PIV-fähigen YubiKeys besitzen 24 PIV-Zertifikatsplätze: vier klassische Slots und zwanzig Retired-Key-Management-Slots. Das bedeutet nicht automatisch 24 Identitäten: Signatur, Verschlüsselung und archivierte Entschlüsselungsschlüssel belegen ebenfalls Plätze.

Nein. x.ID kann die Retired-Key-Management-Slots auch für aktive Identitäten nutzen und ihnen individuell CA-Vorlagen oder Certificate Profiles zuordnen. Zusätzlich lässt sich festlegen, wie viele Plätze für alte S/MIME-Entschlüsselungsschlüssel reserviert bleiben.

Ja. x.ID kann mehrere Zertifikate auf einem YubiKey installieren, die anhand der jeweiligen Zertifikatvorlagen oder Certificate Profiles unterschiedlicher angebundener CAs ausgestellt wurden.

Ja. Eine verifizierte Primäridentität kann für getrennte Sekundäridentitäten verantwortlich bleiben, die auf demselben YubiKey für verschiedene Rollen, Tiers, Domains oder Anwendungen verwendet werden.

Mit der Sperraktion widerruft x.ID die betroffenen Zertifikate einschließlich CRL-Veröffentlichung und bereinigt AD-/LDAP- und Entra-Zuordnungen. Der Benutzer bekommt einen neuen YubiKey mit neuen Schlüsseln – keinen vorbereiteten Schlüsselklon. Für das eigene Enrollment nutzt er einen zuvor freigegebenen Rückfallzugang.

Nein. Gemeint sind vier klassische Schlüsselrollen: PIV-Authentifizierung, digitale Signatur, Schlüsselmanagement für Verschlüsselung und Kartenauthentifizierung. Ein passendes Zertifikat kann von mehreren Anwendungen genutzt werden; Rolle und Anwendung sind nicht dasselbe.

Alte verschlüsselte E-Mails benötigen weiterhin den passenden privaten Entschlüsselungsschlüssel. x.ID kann dafür Archivslots im TemplateMapping reservieren. Diese Plätze stehen dann nicht für zusätzliche Identitäten zur Verfügung.

Beim erstmaligen Register eines bereits benutzten YubiKeys wird dieser nach dem vereinbarten Integrationsverfahren vollständig zurückgesetzt und neu aufgenommen. Vorhandene Schlüssel und Zertifikate werden dabei gelöscht. Inventory allein ist dagegen eine Bestandsaufnahme ohne diesen Reset.

Nein. In keinem x.ID-Prozess verlässt privates PIV-Schlüsselmaterial den YubiKey. Hardwareinterne Backup-/Rollback-Funktionen für fehlgeschlagene Vorgänge sind kein exportierbares Schlüsselbackup. Auch ein PFX-Import ist nicht vorgesehen.

Ja. Der webbasierte CoreService kann in der Cloud, On-Premises oder als Teil einer hybriden Architektur betrieben werden. Outpost-Connectoren binden Verzeichnisse, CAs und getrennte Umgebungen passend an. Damit folgt der Aufbau Ihrer IT-Strategie, statt einen bestimmten Betriebsort vorauszusetzen.

Ja. Im Predeployment kann das Serviceteam PIV-Token wie YubiKeys vorab erfassen und unter Verwaltung nehmen. Mit aktiviertem Auto-Inventory wird die Inventarisierung automatisiert; Auto-Register übernimmt die Registrierung. So lässt sich auch ein größerer Bestand vorbereiten, bevor Geräte einzelnen Personen zugeordnet und Zertifikate ausgestellt werden.

x.ID prüft vor der Zertifikatsausstellung Identität, Hardware und Richtlinien. Angeforderte Attribute im Certificate Signing Request (CSR) werden gegen die aktuelle zuständige Identitätsquelle geprüft – je Forest über LDAP oder nativ über Entra.

Ja. x.ID ist für Multi-Forest-, Multi-Domain- und Multi-CA-Umgebungen ausgelegt und hält deren Verwaltungs- und Trust-Grenzen weiterhin sichtbar.

mTLS bedeutet, dass sich beide Verbindungsenden mit Zertifikaten authentifizieren. Ein Outpost verbindet sich ausgehend mit seinem konfigurierten Upstream: direkt mit dem zentralen Dienst oder über einen weiteren Outpost.

Nein. Outposts können sternförmig, hintereinander oder in einer gemischten Topologie verbunden sein. So lassen sich auch mehrstufig segmentierte Netze über definierte Verbindungswege anbinden. Die Administration kann erkennen, welche Outposts verbunden sind.

LDAP Connector und Azure Connector sind getrennte Wege zu Active Directory und Microsoft Entra ID. Sie lesen den Identitätskontext und pflegen die jeweils vorgesehenen Zertifikatszuordnungen.

Ja. Core, Datenbank, Microsoft AD CS und Agent können auf einem geschützten Windows Server ab 2019 zusammenlaufen. Microsoft SQL Server wird editionsübergreifend unterstützt; PostgreSQL ist ebenfalls verfügbar. Eine AD-Domäne und ein HSM sind nicht zwingend.

Nein. userCertificate enthält im Active Directory veröffentlichte Zertifikate. altSecurityIdentities kann die starke SKI-Zuordnung zur Identität enthalten. Der Windows-Zertifikatsspeicher ist dagegen der lokale Zertifikatsbestand für Benutzer oder Computer.

Das Enrollment erfolgt im empfohlenen Standard durch den per OIDC authentifizierten Endbenutzer. SSO kann die vorhandene Windows-Anmeldung über WIA oder eine Entra-Anmeldung nutzen. Eine administrative Ausstellung ist konfigurierbar, wird von keyONE aber ausdrücklich nicht empfohlen.

Der x.ID Agent läuft auf dem Client oder auf einem Jump Host mit unterstützter Smartcard-Umleitung. Ohne lokale Installation bedeutet nicht ohne Agent. Der YubiKey bleibt am Rechner des Benutzers; der Agent kommuniziert per mTLS mit dem Core.

Weil die Dienste, die Identität und Policy durchsetzen, besonders privilegierte Trust-Komponenten sind. Ihre Zertifikats-, Signatur- und Schutzschlüssel sollten hardwaregeschützt werden, wo das Risikomodell dies verlangt.

Sensible Secrets wie Management Keys, PUKs und weitere Zugangsdaten werden verschlüsselt in SQL Server oder PostgreSQL gespeichert. Jeder Management Key und jede PUK sind individuell, ohne benutzerübergreifende Ableitung. Inventar, Zertifikate und Status sind dagegen für berechtigte Funktionen lesbare Betriebsdaten.

x.ID führt den Vertrauensentzug unmittelbar in den angebundenen Zielsystemen aus: Die betroffenen Zertifikate werden über den CA Connector mit Sperrgrund widerrufen und die CRL wird veröffentlicht. Die betroffenen Zertifikatseinträge und SKI-Zuordnungen werden in AD/LDAP, im Windows-Zertifikatsspeicher und in Microsoft Entra ID bereinigt. Es bleibt nicht bei einem Statuswechsel im Inventar.

x.ID hält den Auftrag vor und setzt die Verarbeitung automatisch und unmittelbar fort, sobald das Ziel wieder erreichbar ist. Das gilt auch für Sperraufträge und die Bereinigung von Verzeichniszuordnungen. Ein vorübergehender Verbindungsverlust beendet den Prozess nicht.

Bei erkannten YubiKey-Treiberfehlern während Register oder Deregistrierung kann x.ID die Geräteverbindung automatisch neu initialisieren. Das unterstützt die Fortsetzung des vorgesehenen Prozesses.

Bei jeder Zertifikatserneuerung erzeugt x.ID einen neuen privaten Schlüssel auf dem YubiKey. Geänderte Geräte- und Anwendungsvorgaben werden dabei übernommen. Administrative Sperrungen führt x.ID unabhängig von dieser Erneuerung aus.

Den Überlappungszeitraum gibt die Zertifikatvorlage vor; x.ID liest und beachtet diese Vorgaben. Während einer zulässigen Überlappung wird das alte Zertifikat nicht allein wegen der regulären Erneuerung gesperrt. Administrative Sperrung oder Verlust sind davon getrennte Prozesse.

Über einen vorher freigegebenen Recovery-Weg Ihres Unternehmens. Dafür kann ein abgesicherter Jump Host eine passwortbasierte Anmeldung erlauben, während im normalen Betrieb die vorgesehenen starken Anmeldeverfahren bestehen bleiben. Dieser Ablauf wird im Vorprojekt vereinbart.

Nach Anmeldung über den freigegebenen Rückfallweg kann der Benutzer seine PIV-PIN im Self-Service neu setzen. Alternativ kann eine berechtigte Administration die individuelle PUK bereitstellen. Beim nächsten Enrollment ändert x.ID diese PUK wieder.

x.ID protokolliert alle Lifecycle-Aktionen. Das aktuelle Zertifikat und die aktuellen Attribute bleiben sichtbar. Auditberichte können angezeigt und als CSV oder Excel exportiert werden. Betriebs- und Auswertungsdaten lassen sich auch über die API mit berechtigter Rolle abfragen.

Im Core werden Auditberichte nicht nachträglich bearbeitet. Berechtigte Benutzer können sie anzeigen oder herunterladen; die Berichtserstellung erfolgt unter dem gMSA-Dienstkonto des Core.

x.ID setzt keine feste produktseitige Aufbewahrungsgrenze. Die mögliche Historie richtet sich nach Datenbankkapazität und Betriebsplanung. Ihr Unternehmen legt Aufbewahrung, Archivierung und Löschung fest.

Die Installation ist einschließlich HSM-Anbindung und Zertifikats-/Schlüsseleinrichtung vollständig gescriptet und dokumentiert. Damit lässt sich die Umgebung nachvollziehbar neu aufbauen. Für Datenbank-Backups und die erforderlichen Server-/HSM-Schlüsselsicherungen ist der Kunde verantwortlich.

Als regulären Ausgangspunkt empfiehlt keyONE einen Core mit geplantem, getestetem Wiederaufbau. Besondere Verfügbarkeitsanforderungen werden im Projekt bewertet. Ein Multi-Core-Betrieb ist kein pauschal empfohlenes Standardsetup.

Das Serviceteam kann einen YubiKey in Entra ID für den vorgesehenen Benutzer vorprovisionieren. Anschließend erfolgt die persönliche PIN-Übergabe. Während der Vorbereitung befindet sich der Schlüssel am Support-Rechner, später am Benutzerrechner. Tenant-Registrierung und PIN-Übergabe bleiben getrennte Schritte.

Ja, agentless* auf dem Benutzer-PC im unterstützten Jump-Host-Betrieb. Mitarbeiter und Administratoren bedienen das Webportal; eine zentral bereitgestellte SYNRION-Komponente übernimmt die Gerätekommunikation. Der YubiKey bleibt beim Benutzer.

SYNRION x.ID verbindet Unternehmen, Benutzer, Identitäten und den physischen YubiKey mit dem erfassten Bestand. Die gemeinsame Sicht umfasst PIV-Zertifikate und discoverable FIDO2-Credentials. Mitarbeiter und berechtigte Verantwortliche erhalten ihre jeweilige Portalsicht.

Die wiederholte FIDO2-Erfassung unterstützt geeignete YubiKeys ab Firmware 5.8. Nach der Autorisierung kann die Erfassung im unterstützten Lifecycle-Ablauf erneut erfolgen.

Sie verbindet Gerätebestand und Identitätszuordnung mit dokumentierten Lifecycle-Vorgängen. Das unterstützt die Prüfung von Unternehmensvorgaben und die Nachvollziehbarkeit von Änderungen. Persönliche Sicht und Unternehmensübersicht richten sich nach den jeweiligen Berechtigungen.

Ja. Mitarbeiter und Administratoren können das x.ID-Webportal mit ihren jeweiligen Berechtigungen auch auf mobilen Geräten im Browser bedienen. Dafür ist keine lokale SYNRION-Anwendung für die Portaloberfläche erforderlich.