Hardware Security Modules (HSM)

Hardware Security Modules (HSM)

Ein HSM ist ein gehärtetes Kryptomodul, das private Schlüssel schützt und kryptografische Operationen (z. B. Signaturen, Decryption) in einer Hardware‑Boundary ausführt. Für High‑Assurance‑PKI gilt in der Regel: CA‑Keys und besonders kritische Private Keys werden im HSM erzeugt und verlassen es nicht.

Einsatzbereiche in PKI/CLM

Root/Issuing‑CA KeysSchutz der Vertrauensbasis; Root idealerweise offline, Issuing online mit HSM‑Key‑Custody.
Code‑SigningHSM‑Keys und Dual‑Control‑Prozesse reduzieren Missbrauchsrisiken.
TLS für zentrale GatewaysLB/WAF/API‑Gateways: Schlüsselhaltung und Audit‑Nachweis sind häufig regulatorisch relevant.
Dokumenten‑/Identity‑SignaturenNachvollziehbare Schlüsselverwendung und belastbare Audit‑Artefakte.

Auswahl‑Checkliste

Assurance

Zertifizierungen, Physical Security, Rollenmodelle und Audit‑Fähigkeit.

Integration

Anbindungen an CA‑Software, Signatur‑Services, Gateways, Vaults und CI/CD‑Pipelines.

Betrieb

HA/Cluster, Backup/Restore, Schlüsselrotation, Notfallprozesse und Monitoring.

Crypto‑Agility

Algorithmus‑Mix, Migrationsfähigkeit und (falls relevant) PQC‑Roadmap.

HSM‑Hersteller (Auswahl) & Feature‑Vergleich

Der Vergleich ist bewusst herstellerübergreifend und zeigt typische, öffentlich kommunizierbare Merkmale. Details sind modell‑ und firmware‑abhängig und sollten im Beschaffungsprozess anhand konkreter Zertifizierungs‑IDs und Datenblätter validiert werden.

Dimension Thales Entrust Utimaco Securosys
Produktlinien (Beispiele) Luna (GP), payShield (Payment) nShield (GP) CryptoServer (GP), Atalla (Payment) Primus (E/X/S/CyberVault) + CloudHSM
Bereitstellungsoptionen
Network Appliance
PCIe
USB (Entry/Dev)
Network Appliance
PCIe
USB (Entry/Dev)
Network Appliance
PCIe (je nach Serie)
Network Appliance
CloudHSM (Hosted)
Tenant‑Fähigkeit / Isolation Partitionierung / virtuelle HSMs über Rollen und Policies. Logische Isolation über Domänen-/Security‑World‑Konzepte und RBAC. Slot-/Partition‑Konzepte je nach Modell/SDK; häufig in regulierten Umgebungen. Multi‑Tenant‑Optionen je nach Modell/Serie; Trennung über Domains/Policies.
Einordnung nach Größe (grob) Mittel → Groß (breites Portfolio, modellabhängig). Klein → Groß (breite GP‑Abdeckung, integrationsstark). Mittel → Groß (Assurance-/Performance‑Tiers, modellabhängig). Klein → Groß (Tiers + CloudHSM‑Option, modellabhängig).
HA & Ausfallsicherheit HA‑Pairs/Groups, Failover & Load‑Sharing (designabhängig). Failover/Load‑Balancing über Domänen‑Design und Client‑Konfiguration. Redundanz über Appliances/Hosts; häufig N+1 in CA‑Designs. Cluster‑Pattern (Failover/Load‑Balancing) + CloudHSM‑Optionen.
Schlüssel‑Migration Backup/Restore, Cloning und Wrapped Export/Import – policy‑abhängig. Migration häufig innerhalb einer Domäne/Security‑World (Backup/Restore). Backup‑Keys / Wrapped Export/Import je nach Policy/Modell. Wrapped Export/Import je nach Policy; Exit‑Plan früh festlegen.
Kosten (typisch, grob) On‑Prem CAPEX + Support; hosted/managed je nach Angebot. On‑Prem CAPEX + Support; häufig projekt-/integrationsgetrieben. Stark modell‑/zertifizierungsabhängig (GP vs. Payment/High‑Assurance). On‑Prem CAPEX; CloudHSM OPEX/Subscription.
Hinweis: Angaben sind modell‑ und firmware‑abhängig. Für Entscheidungen sind konkrete Zertifizierungs‑IDs, Threat‑Model, Betriebsprozesse (Backup/Restore, Quorum), Performance‑Profile und Integrationsanforderungen zu prüfen.

Sizing‑Leitplanken (klein / mittel / groß)

Die Anzahl Ihrer Zertifikate ist vor allem eine CLM‑Größe (Inventory, Renewals, Deployments). Ein HSM wird typischerweise nach kryptografischer Last (Signaturen/s, Concurrency, Algorithmus‑Mix) und nach HA/DR‑Zielen dimensioniert. Die Werte dienen als Orientierungsrahmen; belastbares Sizing erfordert Messwerte.

Umgebung Zertifikats‑Inventar (CLM) Issuance/Rotation (Peak) HSM‑Last (Peak Sign‑Ops/s) Typisches Zielbild
Klein < 50k < 5k Zertifikate/Tag < 200 1–2 HSMs (N+1), wenige Tenants/Partitionen
Mittel 50k – 500k 5k – 50k Zertifikate/Tag 200 – 2.000 2–4 HSMs (Cluster/HA), Segmentierung nach Umgebungen/Teams
Groß > 500k > 50k Zertifikate/Tag > 2.000 Mehrere Cluster/Regionen, klare Tenants, DR‑Design

Erforderliche Sizing‑Eingaben

Peak‑Issuance (Zert/min), Algorithmus‑Mix (RSA/ECC), Concurrency, RTO/RPO, Tenants/Partitionen sowie Key‑Policies (Export/Cloning zulässig?).

HA‑Cluster, Migration & Runbooks

N+1 als MindeststandardFür kritische Trust‑Domains: mindestens zwei HSMs je Domäne (Failover/Load‑Sharing).
Cluster/FleetHA‑Groups, Load‑Balancing und Service‑Redundanz; in Cloud‑Szenarien häufig Multi‑AZ/Region‑Pattern.
Key‑BackupsBackup‑HSM, Quorum/M‑of‑N, Operator‑Cards oder Wrapped Backups. Restore regelmäßig testen.
MigrationIn der Regel innerhalb einer Hersteller‑Logik am einfachsten; Cross‑Vendor nur mit Export unter Wrapping/Policy.
RunbooksKey‑Ceremony, Rotation, Break‑Glass, DR‑Failover sowie Audit‑Artefakte und Rollen klar dokumentieren.
RTO/RPOFailoverBackup‑CeremonyLeast Privilege

Kosten: typische Treiber (CAPEX vs. OPEX)

On‑Prem (CAPEX)

Anschaffung (Appliance/PCIe/USB) plus jährlicher Support. Berücksichtigen Sie HA (mind. N+1), Backup‑Hardware und Audit‑Nachweise.

Cloud/Hosted (OPEX)

Stunden-/Monats‑Modelle. Kostentreiber sind HA‑Units/Regionen, Tenancy‑Optionen, Logging/Compliance‑Funktionen und Transaktionslast (modellabhängig).

Orientierung

On‑Prem‑General‑Purpose‑HSMs liegen in vielen Projekten im fünfstelligen Bereich pro Gerät (zzgl. Support). CloudHSM‑/Hosted‑Modelle sind häufig OPEX‑getrieben. Konkrete Preise hängen von Performance‑Tier, Zertifizierungen, Tenancy und SLA ab.

HSM‑Anforderungen gezielt ableiten

Definieren Sie Anforderungen an HSM (Modul F) – inkl. Key‑Protection, HA/DR, Backup und Schlüssel‑Migration – mit transparenter Zeitschätzung.