Hardware Security Modules (HSM)
Private Schlüssel sicher gespeichert
Ein HSM ist ein gehärtetes Kryptomodul, das private Schlüssel schützt und kryptografische Operationen (z. B. Signaturen, Entschlüsselung) in einer Hardware‑Boundary ausführt. Für High‑Assurance‑PKI gilt in der Regel: CA‑Keys und besonders kritische private Schlüssel 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, physische Sicherheit, 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. |
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.
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‑/Monatsmodelle. 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.
Was möchten Sie jetzt tun?
Die Spezialisten der XELANED stehen Ihnen für die nächsten Schritte jederzeit zur Verfügung. Gemeinsam priorisieren wir Themen, klären Abhängigkeiten und wählen ein Vorgehen, das fachlich und organisatorisch zu Ihrer Umgebung passt.
Wissensaufbau
In einem kompakten Workshop klären wir Ziele, Ist‑Stand und die nächsten Schritte.
Projektplanung
Wir besprechen Scope, Abhängigkeiten und erstellen eine belastbare Vorgehensplanung.