HSM-Auswahl für ADCS – Thales, Utimaco, YubiHSM im Vergleich

Ein Hardware-Security-Modul ist die Versicherung dafür, dass der private Schlüssel deiner CA niemals als Datei auf einer Festplatte landet – und damit auch nicht kopiert, gestohlen oder versehentlich gesichert werden kann. Meine klare Position: Für die Root CA in jedem regulierten Umfeld (NIS2, BSI, eIDAS, KRITIS) ist ein HSM kein Luxus, sondern Pflicht. Für den Mittelstand reicht oft ein YubiHSM 2 im niedrigen vierstelligen Bereich; Thales und Utimaco sind das, was du in Konzernen und bei qualifizierten Vertrauensdiensten siehst. Wer beim Audit das HSM-Häkchen nicht setzen kann, diskutiert länger, als das Gerät gekostet hätte.

Abb. 1: HSM-Klassen für ADCS – positioniert nach Schutzbedarf und Anschaffungskosten.

1. Was ein HSM überhaupt leistet – und was nicht

Ein HSM erzeugt und speichert kryptografische Schlüssel in dedizierter, manipulationssicherer Hardware. Der entscheidende Punkt: Der private Schlüssel verlässt das Gerät nie. Signaturen werden im HSM selbst berechnet – die CA schickt den zu signierenden Hash hinein und bekommt die Signatur zurück, ohne je den Schlüssel zu sehen. Bei einem Software-CSP liegt der Schlüssel dagegen geschützt, aber eben doch im Betriebssystem, und ist damit Teil jedes System-Backups.

Was ein HSM nicht leistet: Es macht eine schlecht konfigurierte CA nicht sicher. Wenn deine Templates anfällig für ESC1 sind, hilft das beste HSM nichts – der Angreifer fordert dann einfach ein legitimes Zertifikat an, das er missbrauchen kann. Das HSM schützt den Schlüssel, nicht die Ausstellungslogik. Beide Themen gehören zusammen gedacht.

2. Die drei Klassen im Vergleich

Der Markt lässt sich grob in drei Klassen einteilen: USB-Token-HSMs für den Einstieg, Netzwerk- und PCIe-HSMs für den professionellen Betrieb, und High-End-HSMs mit höchsten Zertifizierungsstufen für regulierte Konzerne und Vertrauensdienste.

Die ehrliche Einordnung: Das YubiHSM 2 ist technisch völlig ausreichend, um den privaten Schlüssel einer Mittelstands-Root sicher zu verwahren. Es skaliert nur nicht in Richtung Hochverfügbarkeit und Cluster-Betrieb, und seine Performance reicht nicht für Massen-Enrollment im Sekundentakt. Für eine Offline Root, die ein paar Mal im Jahr eine Sub-CA signiert, ist genau das aber irrelevant.

3. Wohin das HSM in der Architektur gehört

Die Platzierung folgt der Tier-Logik deiner PKI. Die Root CA bekommt ihr eigenes HSM in der Offline-Zone, die Issuing CAs ihres in der Produktiv-Zone. Niemals dasselbe physische Gerät für beide Tiers – das würde die Trennung zwischen Offline-Vertrauensanker und Online-Ausstellung aufheben.

Abb. 2: HSM-Anbindung in der zweistufigen PKI – getrennte Geräte pro Tier.

Für das Root-HSM eignet sich ein USB- oder PCIe-Gerät, das nur dann angesteckt oder freigeschaltet wird, wenn die Offline Root überhaupt hochgefahren wird. Das Issuing-HSM dagegen muss dauerhaft erreichbar sein und sollte bei mehreren Issuing CAs als Netzwerk-HSM gemeinsam genutzt werden – das spart Hardware und vereinfacht die Hochverfügbarkeit.

4. KSP-Anbindung und der erste Funktionstest

ADCS spricht mit dem HSM über einen Key Storage Provider (KSP), den der Hersteller mitliefert. Nach der Installation prüfst du mit Bordmitteln, ob der Provider registriert ist und Schlüssel erzeugen kann – bevor du die CA überhaupt installierst.

Praxis-Beispiel: Sparfuchs & Partner Steuerberatungs GmbH

Die Sparfuchs & Partner Steuerberatungs GmbH, ein kleiner Dienstleister mit unter 80 Mitarbeitern, aber hohen Compliance-Anforderungen durch den Umgang mit Mandantendaten, brauchte eine PKI, die ein BSI-orientiertes Audit übersteht – bei einem Budget, das keinen Konzern-Schrank zulässt.

Die Maßnahme: Ein YubiHSM 2 für die Offline Root, ein zweites als geklonter Backup-Token, sicher im Bankschließfach verwahrt. Die Issuing CA lief zunächst mit Software-KSP, mit der Option, später ebenfalls auf ein HSM zu wechseln, falls das Audit es verlangt. So lag der Schlüssel der wichtigsten Komponente – der Root – von Anfang an in Hardware.

Das Ergebnis: Das Audit-Häkchen für den HSM-geschützten Root-Schlüssel war gesetzt, die Gesamtkosten blieben im niedrigen vierstelligen Bereich. Der entscheidende Punkt war die Priorisierung: HSM-Schutz da, wo er am meisten zählt – bei der Root –, statt das knappe Budget gleichmäßig zu verteilen.

Verwandte Themen

Häufige Fragen (FAQ)

Brauche ich überhaupt ein HSM für ADCS?

Für die Root CA in jedem regulierten Umfeld – NIS2, BSI IT-Grundschutz, eIDAS, KRITIS – lautet die Antwort ja. Für die Issuing CAs hängt es vom Schutzbedarf ab. Technisch geht ADCS auch mit Software-Schlüsseln, aber sobald jemand Audit-Fragen stellt, willst du das HSM-Häkchen setzen können.

Reicht ein YubiHSM 2 oder brauche ich Thales?

Für den Mittelstand reicht ein YubiHSM 2 in den allermeisten Fällen völlig aus – es verwahrt den privaten Schlüssel der Root sicher und kostet nur einen niedrigen vierstelligen Betrag. Thales und Utimaco brauchst du, wenn höchste Zertifizierungsstufen, Cluster-Hochverfügbarkeit oder Massen-Enrollment gefordert sind, typisch in Konzernen und bei qualifizierten Vertrauensdiensten.

Was passiert, wenn das HSM kaputtgeht?

Ohne Backup-Konzept ist dann der CA-Schlüssel unwiederbringlich verloren – und damit die gesamte CA. Genau deshalb brauchst du entweder ein zweites HSM mit Schlüssel-Cloning oder einen verschlüsselten, sicher verwahrten Export im Herstellerverfahren. Den Restore solltest du einmal real durchgespielt haben, bevor du produktiv gehst.

Kann ich Root- und Issuing-CA dasselbe HSM nutzen lassen?

Solltest du nicht. Die Root gehört in die Offline-Zone, die Issuing CAs in die Produktiv-Zone – ein gemeinsames Gerät würde diese Trennung aufheben und den Vertrauensanker dem Online-Risiko aussetzen. Mehrere Issuing CAs dürfen sich dagegen ein Netzwerk-HSM teilen.

Wie bindet ADCS ein HSM technisch an?

Über einen Key Storage Provider (KSP), den der HSM-Hersteller mitliefert. Bei der CA-Installation gibst du den KSP explizit an, etwa über -CryptoProviderName. Der private Schlüssel wird dann im HSM erzeugt und verlässt es nie – alle Signaturen berechnet das Gerät selbst.

Macht ein HSM meine CA automatisch sicher?

Nein. Ein HSM schützt den privaten Schlüssel, nicht die Ausstellungslogik. Wenn deine Vorlagen für ESC1 anfällig sind, fordert ein Angreifer einfach ein legitimes, missbrauchbares Zertifikat an – das beste HSM hilft dann nichts. Schlüsselschutz und Template-Härtung gehören zusammen.

Nächste Schritte mit boddenberg.de

Die HSM-Frage ist immer auch eine Architektur- und Compliance-Frage – und genau da lohnt sich ein erfahrener Blick von außen. Drei Wege, wie ich dich unterstütze:

Schick mir eine kurze Mail mit deinem Szenario, und du bekommst innerhalb eines Werktags eine Einschätzung, welcher Weg am sinnvollsten ist.

Kontakt: Uli Boddenberg · boddenberg.de · Dortmund