Schlüssel in Hardware halten
Der Service sendet Signatur- oder Entschlüsselungsoperationen über den Providerweg; das HSM behält den privaten Schlüssel.
SERVICE-IDENTITÄTEN & HSM
Der kryptografische Auftrag bewegt sich. Der private Schlüssel nicht.
SYNRION x.ID verbindet verantwortliche Service-Identitäten, Zertifikats-Lifecycle und Policy mit hardwaregeschützten Schlüsselwegen für Utimaco, Thales Luna, Yubico YubiHSM 2 und Nitrokey NetHSM.
NUTZEN IN 30 SEKUNDEN
Service-Identitäten verdienen dieselbe Kontrolle wie Benutzeridentitäten.
Verantwortung sichtbar halten
Service, Konto, Zertifikat, Anwendung, Key Provider und Lifecycle-Zustand bleiben ausdrücklich miteinander verbunden.
Provider austauschbar halten
Die Architektur unterscheidet Windows CNG, Provider-KSP und HSM-spezifische Wege, statt alles hinter einem unbestimmten „HSM“-Begriff zu verstecken.
VON DER WINDOWS-ANWENDUNG ZUR HARDWARE
Was geschieht zwischen einer mTLS-Anwendung und dem HSM?
Das Zertifikat kann für Windows sichtbar sein, während der private Schlüssel nicht exportierbar in Hardware bleibt. Klare Schnittstellen machen Betrieb, Fehleranalyse und Providerwechsel kontrollierbar.
-
01
Die Anwendung startet eine authentisierte Verbindung
Ein Windows-Service oder eine .NET-Anwendung fordert TLS oder mTLS mit einem ausgewählten Zertifikat und Identitätskontext an.
-
02
Schannel nutzt Windows CNG
Der Windows-Sicherheitsstack löst Zertifikat und Schlüsselbezug auf und fordert die nötige Kryptooperation über den konfigurierten Providerweg an.
-
03
NCrypt adressiert den persistenten Schlüssel
Windows identifiziert das Private-Key-Objekt über seinen Key Storage Provider, statt eine exportierbare Schlüsseldatei zu lesen.
-
04
Der Provider-KSP sendet die Operation zum HSM
Der passende Utimaco-, Thales-Luna-, YubiHSM-2- oder keyONE-NetHSM-Providerweg übersetzt die Windows-Anforderung für sein Hardwareziel.
-
05
Das HSM führt die Private-Key-Operation aus
Signatur oder Entschlüsselung erfolgt innerhalb der geschützten Hardwaregrenze; nur das Ergebnis kehrt zum Anwendungsweg zurück.
-
06
x.ID hält Lifecycle- und Identitätskontext zusammen
Service, Zertifikat, Schlüsselort, Provider und Policy bleiben sichtbar, damit Erneuerung oder Migration nicht zur undokumentierten manuellen Übergabe wird.
DIE ARCHITEKTUR AUF EINEN BLICK
Die Operation durchläuft Windows und den Providerweg bis zum HSM. Der private Schlüssel bleibt innerhalb der Hardware-Sicherheitsgrenze.
TECHNISCHE TIEFE
Die Windows-Schnittstellen haben verschiedene Aufgaben.
Präzise Begriffe verhindern falsche Annahmen bei Fehleranalyse, Migration und Sicherheitsprüfung.
- Schannel
- Schannel ist das Windows-TLS-Sicherheitspaket, das viele .NET- und Windows-HTTP-Workloads verwenden. Es koordiniert zertifikatsbasierte TLS-Authentifizierung und ruft die erforderlichen Kryptoschnittstellen auf.
- BCrypt
- BCrypt ist die CNG-Primitivschicht für Algorithmen, Hashing, symmetrische Kryptografie und Low-Level-Kryptooperationen. Sie ist nicht der Speicher für persistente private Schlüssel.
- NCrypt
- NCrypt stellt persistente Schlüsseloperationen und Key Storage Provider bereit. Anwendung oder Schannel können damit einen Schlüssel adressieren, dessen privates Material hinter dem konfigurierten KSP bleibt.
- KSP und HSM
- Ein Key Storage Provider verbindet die Windows-Schlüsselabstraktion mit der hersteller- oder integrationsspezifischen HSM-Schnittstelle. Das HSM setzt Hardwarespeicherung, Autorisierung und Nicht-Exportierbarkeit durch.
- Service-Identität
- Das Konto oder der Workload am Zertifikat bleibt ein verantwortliches Lifecycle-Objekt. gMSA kann ein Windows-Servicekonto verwalten; mTLS und HSM-gestützte Schlüssel schützen den Service-zu-Service-Trust.
NACHWEIS & GRENZEN
Unterstützte Providerwege bleiben ausdrücklich sichtbar.
Jede HSM-Integration besitzt eigene Provider-, Authentifizierungs- und Betriebsanforderungen. x.ID macht den gemeinsamen Lifecycle sichtbar, ohne die Provider gleichzusetzen.
Utimaco-HSM-Referenzweg
Windows CNG und der Utimaco KSP bilden einen konkreten Referenzweg von der Anwendungsanforderung zur hardwaregeschützten Private-Key-Operation.
Thales Luna HSM
Thales-Luna-Provider- und Partitionskonzepte können in denselben kontrollierten Zertifikats- und Service-Identitäts-Lifecycle eingebunden werden.
Yubico YubiHSM 2
YubiHSM 2 kann Service- und Infrastrukturschlüssel über seinen unterstützten Provider- und Integrationsweg schützen.
Nativer Nitrokey-NetHSM-CNG-Weg
Windows CNG → keyONE NetHSM CNG KSP → keyONE Agent → Nitrokey NetHSM.
PASSENDES PRODUKT
SYNRION x.ID
SYNRION x.ID verbindet verifizierte Primäridentitäten, authentische Hardware und unabhängige Policy-Durchsetzung zu einer belastbaren Vertrauensentscheidung.
NÄCHSTER KONTROLLIERTER SCHRITT
Verfolgen Sie ein reales Servicezertifikat von der Anwendung bis zum HSM.
Wir ordnen Windows-Stack, Provider, HSM, CA, Servicekonto, Lifecycle und Recovery so, dass jede Verantwortung sichtbar wird.