Cloudbasierte vs. lokale HSMs

Die Entscheidung zwischen Cloud-basierten und lokalen HSMs bestimmt, wer die physische Kontrolle über die sensibelsten kryptografischen Vorgänge Ihres Unternehmens hat. Ein Hardware-Sicherheitsmodul (HSM) ist ein dediziertes, manipulationssicheres Hardwaregerät, das kryptografische Schlüssel innerhalb eines nach FIPS 140-2 Level 3 validierten Bereichs generiert, speichert und verwaltet. Die Wahl zwischen dem Einsatz von HSMs im eigenen Rechenzentrum oder der Nutzung als Managed Cloud Service beeinflusst Ihr Schlüsselkontrollmodell, Ihr Latenzprofil, Ihre Compliance-Anforderungen, die Gesamtbetriebskosten und den Betriebsaufwand. Dieser Leitfaden behandelt alle Aspekte dieser Entscheidung, damit Sicherheits- und Infrastrukturteams das passende Modell für ihre spezifischen Anforderungen auswählen können.

Kurzantwort: Cloudbasiertes HSM oder lokales HSM?

Für die meisten Organisationen bieten cloudbasierte HSM-Dienste die gleiche kryptografische Sicherheit wie lokale HSMs – bei geringeren Gesamtbetriebskosten, schnellerer Bereitstellung und ohne den Aufwand der Hardwareverwaltung. Lokale HSMs sind dann die richtige Wahl, wenn Ihre Anwendung Latenzanforderungen im Submillisekundenbereich stellt, die durch Netzwerkzugriffe nicht erfüllt werden können, wenn regulatorische Vorgaben vorschreiben, dass Schlüssel eine bestimmte physische Einrichtung oder Gerichtsbarkeit ohne verfügbaren Cloud-HSM-Dienst nicht verlassen dürfen, oder wenn Sie in einer abgeschotteten Umgebung ohne Cloud-Anbindung arbeiten. Für Multi-Cloud- und Hybridumgebungen mit zentralisierter Schlüsselverwaltung ist ein HSM-as-a-Service eines Drittanbieters, der mehrere Anbieter umfasst, oft die praktischste Lösung.

Wichtige Erkenntnisse

• Die kryptografische Technologie ist dieselbe: Sowohl Cloud-basierte als auch lokale HSMs verwenden FIPS 140-2 Level 3-validierte Hardware, die dieselben kryptografischen Operationen ausführt. Das Bereitstellungsmodell bestimmt, wer die Hardware betreibt, nicht was sie leistet.
• Cloud-HSM reduziert den Betriebsaufwand, nicht die Sicherheit: Cloud-HSM-Dienste entlasten Ihr Team von Hardwarebeschaffung, Rechenzentrumsplatzbedarf, Firmware-Updates und HSM-Clusterverwaltung. Die kryptografische Barriere bleibt unabhängig vom Betreiber hardwareseitig gewährleistet.
• BYOK und HYOK benötigen HSM-generiertes Schlüsselmaterial: Sowohl BYOK (Bring Your Own Key) als auch HYOK (Hold Your Own Key) Implementierungen verwenden typischerweise ein lokales oder dediziertes Cloud-HSM als Schlüsselgenerierungsquelle, sodass die HSM-Wahl ein Bestandteil der Cloud-Schlüsselverwaltungsstrategie ist und nicht davon getrennt wird.
• Latenz ist die häufigste technische Einschränkung, die für On-Premises-Lösungen spricht: Anwendungen, die HSM-Reaktionszeiten im Submillisekundenbereich erfordern, tolerieren die Netzwerklatenz eines Cloud-HSM-API-Aufrufs nicht. Hochfrequenzhandel, Zahlungsabwicklung in großem Umfang und bestimmte PKI-Signaturvorgänge fallen in diese Kategorie.
• FIPS 140-2 Level 3 ist in beiden Modellen verfügbar: AWS CloudHSM, Azure Dedicated HSM und GCP Cloud HSM nutzen alle FIPS 140-2 Level 3-validierte Hardware. Gemeinsam genutzte Cloud-KMS-Dienste ohne dedizierte HSM-Ebene verwenden Level 2, nicht Level 3. Prüfen Sie die genaue Dienstebene, wenn Level 3 erforderlich ist.

Was ist ein Hardware-Sicherheitsmodul (HSM)?

Ein Hardware-Sicherheitsmodul (HSM) ist ein dediziertes physisches Rechengerät, das kryptografische Schlüssel schützt und kryptografische Operationen innerhalb einer manipulationssicheren Hardwaregrenze durchführt. HSMs sind speziell für die Schlüsselsicherheit entwickelt: Sie generieren Schlüssel mithilfe von Hardware-Zufallszahlengeneratoren, speichern diese in nicht exportierbarer Form innerhalb der Hardwaregrenze, führen kryptografische Operationen (Verschlüsselung, Entschlüsselung, Signierung, Verifizierung) innerhalb dieser Grenze durch, sodass das Schlüsselmaterial das Gerät niemals im Klartext verlassen muss, und erkennen physische Manipulationsversuche, indem sie das Schlüsselmaterial mit Nullen überschreiben.

Die Sicherheit eines HSM wird formal durch das NIST FIPS 140-2-Zertifizierungsprogramm (Federal Information Processing Standard) validiert. FIPS 140-2 definiert vier Sicherheitsstufen: Stufe 1 (einfaches kryptografisches Softwaremodul), Stufe 2 (manipulationssichere physische Sicherheit), Stufe 3 (manipulationsresistente physische Sicherheit mit identitätsbasierter Authentifizierung und Nullsetzung kritischer Sicherheitsparameter bei Manipulationserkennung) und Stufe 4 (vollständiger physischer Sicherheitsschutz gegen Umwelteinflüsse). FIPS 140-2 Stufe 3 ist die Standardanforderung für HSM-Implementierungen in Unternehmen und regulierten Umgebungen. Das NIST vollzieht derzeit die Umstellung auf FIPS 140-3, das mit ISO/IEC 19790 übereinstimmt; bestehende FIPS 140-2-Validierungen bleiben während der Übergangsphase gültig.

HSMs werden für eine breite Palette kryptografischer Anwendungen eingesetzt: zum Schutz privater Schlüssel für Zertifizierungsstellen (CAs) in PKI-Infrastrukturen, zum Generieren und Schützen von Verschlüsselungsschlüsseln für die transparente Datenverschlüsselung (TDE) von Datenbanken, zum Sichern privater Schlüssel für TLS-Zertifikate auf kritischen Endpunkten, zum Durchführen von Signaturvorgängen für die Codesignierung und Dokumentensignierung, zum Schützen von Schlüsseln für die PIN-Verschlüsselung und -Verifizierung von Zahlungskarten sowie zum Generieren des BYOK-Schlüsselmaterials, das in Cloud-Schlüsselverwaltungsdienste importiert wird.

Vor-Ort-HSMs: Volle Kontrolle, volle Verantwortung

Ein lokales HSM ist ein physisches Gerät, das Ihr Unternehmen erwirbt, in Ihrem eigenen Rechenzentrum oder Colocation-Rechenzentrum installiert, konfiguriert, betreibt und wartet. Die HSM-Hardware verbindet sich über Ihr internes Netzwerk mit Ihren Anwendungen und Ihrer Schlüsselverwaltungsinfrastruktur, typischerweise über PKCS#11, JCE (Java Cryptography Extension), Microsoft CNG (Cryptography Next Generation) oder REST-APIs, abhängig vom HSM-Modell und den Integrationsanforderungen der Anwendung.

Was Ihnen lokale HSMs bieten: Physischer Besitz und Kontrolle der kryptografischen Hardware und der darin gespeicherten Schlüssel. Keine Abhängigkeit von der Verfügbarkeit oder API eines Cloud-Anbieters für kryptografische Operationen. Latenzzeiten im lokalen Netzwerk unterhalb einer Millisekunde für hochfrequente kryptografische Operationen. Die Möglichkeit, Schlüsselzeremonien in einer physisch kontrollierten Umgebung zur Generierung privater CA-Schlüssel durchzuführen. Volle Einhaltung von Anforderungen zur Datensouveränität oder Lokalisierung, die vorschreiben, dass Schlüssel innerhalb einer bestimmten physischen Einrichtung oder eines bestimmten Zuständigkeitsbereichs verbleiben, in dem kein Cloud-HSM-Dienst verfügbar ist.

Kosten für On-Premise-HSMs: Anschaffungskosten für die Hardware (typischerweise 20,000 bis 40,000 US-Dollar pro Gerät, abhängig von Modell und Durchsatzkapazität). Zusätzliche Einheiten für Hochverfügbarkeits- (HA) und Disaster-Recovery-Cluster, in der Regel mindestens zwei Einheiten für einen ausfallsicheren Produktionsbetrieb. Lizenzen für die Management-Software. Rackplatz, Strom und Kühlung im Rechenzentrum. Zeitaufwand für qualifiziertes Personal für die Erstkonfiguration, Firmware-Updates, Partitionsverwaltung, Client-Softwarebereitstellung und den laufenden Betrieb. Hardware-Austauschzyklen (typischerweise 5 bis 7 Jahre). Physische Sicherheitsmaßnahmen für das Rechenzentrum, in dem sich das HSM befindet.

Wann lokale HSMs die richtige Wahl sind: Anwendungen mit strengen Latenzanforderungen, die keinen Netzwerk-Roundtrip zu einem Cloud-Dienst tolerieren (kryptografische Operationen im Submillisekundenbereich für Hochfrequenzhandel, PIN-Blockverarbeitung von Zahlungsterminals oder Echtzeit-Signatur-Pipelines); regulatorische Anforderungen, die die physische Schlüsselaufbewahrung in einer bestimmten Einrichtung oder einem Land vorschreiben, in dem kein Cloud-HSM-Dienst verfügbar ist; abgeschottete oder klassifizierte Umgebungen ohne Internetverbindung; Organisationen mit sehr hohem kryptografischem Transaktionsvolumen, bei denen die Preise für Cloud-API-Aufrufe deutlich höher sind als die für eigene Hardware; und Schlüsselzeremonien für die CA-Root-Key-Generierung, bei denen physische Anwesenheit und Zeugenverfahren erforderlich sind.

Cloudbasierte HSMs: Verwaltete Hardware, gemeinsam genutzt oder dediziert

Cloudbasierte HSMs sind FIPS-validierte HSM-Hardware, die von einem Cloud-Anbieter oder Drittanbieter betrieben wird und über eine authentifizierte API von Ihren Anwendungen genutzt wird. Die HSM-Hardware befindet sich physisch im Rechenzentrum des Anbieters. Ihre Anwendungen interagieren niemals direkt mit der HSM-Hardware; sie rufen die API des Anbieters auf, welche die kryptografische Operation an die zugrunde liegende HSM-Hardware weiterleitet und das Ergebnis zurückgibt.

Cloudbasierte HSM-Dienste lassen sich in zwei Kategorien mit wesentlich unterschiedlichen Sicherheitsmodellen einteilen:

Dedizierte (Single-Tenant) Cloud-HSM-Dienste

Dedizierte Cloud-HSM-Dienste stellen Ihrer Organisation ausschließlich physische HSM-Hardware zur Verfügung. Die Hardware und die HSM-Partitionen werden nicht mit den Schlüsseln oder kryptografischen Operationen anderer Kunden geteilt. Beispiele hierfür sind AWS CloudHSM (nutzt Luna Network HSM-Hardware, FIPS 140-2 Level 3, ca. 1.45 US-Dollar pro Stunde und Instanz), Azure Dedicated HSM (nutzt Entrust nShield Connect-Hardware, FIPS 140-2 Level 3) und Azure Payments HSM (nutzt Utimaco-Hardware für Zahlungs-HSM-Workloads). Bei einem dedizierten Cloud-HSM verwaltet der Cloud-Anbieter die physische Infrastruktur, hat aber keinen Zugriff auf Ihre Schlüssel oder die HSM-Partitionen. Sie verwalten die HSM-Software, die Partitionen und das Schlüsselmaterial selbst über die Verwaltungsschnittstelle des HSM.

Dedizierte Cloud-HSM-Dienste bieten ein Sicherheitsniveau, das dem von On-Premises-HSMs sehr nahe kommt: FIPS 140-2 Level 3-Validierung, Single-Tenant-Hardware und Ausschluss des Cloud-Anbieters vom Schlüsselzugriff. Die wichtigsten Unterschiede zu On-Premises-Lösungen sind die Netzwerklatenz von API-Aufrufen (typischerweise 1 bis 5 Millisekunden gegenüber unter einer Millisekunde bei lokalen Lösungen), die Verantwortung für das operative Management (Sie verwalten die HSM-Software und -Partitionen, aber nicht die physische Hardware) und das Preismodell (stundenweise Abrechnung gegenüber einmaliger Investition).

Gemeinsam genutzte (mandantenfähige) Cloud-HSM-Dienste

Gemeinsam genutzte Cloud-HSM-Dienste verwenden partitionierte HSM-Hardware, die von mehreren Kunden gemeinsam genutzt wird. Ihre Schlüssel sind innerhalb des HSM logisch von den Schlüsseln anderer Kunden isoliert, die physische Hardware wird jedoch gemeinsam genutzt. Beispiele hierfür sind AWS KMS mit HSM-Schutz (FIPS 140-2 Level 2-validiert), GCP Cloud KMS mit HSM-Schutz (FIPS 140-2 Level 3-validiert für HSM-basierte Schlüssel) und Azure Key Vault Premium (HSM-geschützte Schlüssel). Diese Dienste werden vollständig verwaltet: Der Cloud-Anbieter verwaltet die Hardware, die HSM-Software und die Schlüsselverwaltungsplattform. Ihre Verantwortung beschränkt sich auf die Konfiguration der Schlüsselrichtlinien, die Zugriffskontrolle und die Verwaltung des Schlüssellebenszyklus über die API des Cloud-Anbieters.

Gemeinsam genutzte Cloud-HSM-Dienste bieten den geringsten Betriebsaufwand und die niedrigsten Kosten. Der Nachteil besteht darin, dass der Cloud-Anbieter die HSM-Hardware betreibt und auf die zugrunde liegende Infrastruktur zugreifen oder diese migrieren kann, selbst bei starker logischer Schlüsselisolation. Für die meisten Compliance-Rahmenwerke ist ein gemeinsam genutzter HSM-Dienst eines Cloud-Anbieters, der durch eine BAA, DPA oder andere vertragliche Regelungen abgesichert ist, ausreichend. Für Workloads, bei denen der Cloud-Anbieter keinen Zugriff auf wichtige Daten haben darf, ist ein dediziertes Cloud-HSM oder ein On-Premises-HSM erforderlich.

Tastensteuerungsmodelle: Native, BYOK und HYOK

Die Entscheidung für den HSM-Einsatz hängt eng mit dem Schlüsselkontrollmodell zusammen, das Ihre Compliance-Anforderungen oder Sicherheitsrichtlinien vorschreiben. Es gibt drei Schlüsselkontrollmodelle, und jedes hat unterschiedliche Auswirkungen auf das HSM.

Native Cloud-Schlüsselverwaltung (vom Anbieter verwaltete Schlüssel)

Der Cloud-Anbieter generiert und verwaltet alle Verschlüsselungsschlüssel in seiner eigenen Schlüsselmanagement-Infrastruktur. Ihre Schlüssel sind durch HSM-Hardware des Anbieters geschützt, Sie haben jedoch weder Einblick in noch Kontrolle über das physische Schlüsselmaterial. Sie können Schlüssel über die API des Anbieters verwenden, rotieren, deaktivieren und löschen, aber nicht unabhängig überprüfen, ob das Schlüsselmaterial gemäß Ihren Richtlinien generiert wurde. Dieses Modell erfordert keine Investitionen oder den Betrieb eines HSM-Systems Ihrerseits und eignet sich für die meisten gängigen Cloud-Workloads, bei denen der Prüfpfad des Schlüsselmanagements des Anbieters für Ihre Compliance-Anforderungen ausreicht.

BYOK (Bringen Sie Ihren eigenen Schlüssel mit)

BYOK bedeutet, dass Sie Verschlüsselungsschlüsselmaterial in einem von Ihnen kontrollierten HSM (lokal oder in einem dedizierten Cloud-HSM) generieren, dieses Schlüsselmaterial (sicher verpackt) exportieren und in den Schlüsselverwaltungsdienst des Cloud-Anbieters (AWS KMS, Azure Key Vault oder GCP Cloud KMS) importieren. Der Cloud-Anbieter verwendet Ihr importiertes Schlüsselmaterial, um die Datenverschlüsselungsschlüssel zu generieren, die Ihre Cloud-Daten schützen. Sie behalten das Quellschlüsselmaterial in Ihrem HSM und können es aus dem KMS des Cloud-Anbieters löschen, um diesem die Berechtigung zur Entschlüsselung Ihrer Daten sofort zu entziehen.

BYOK erfüllt regulatorische Anforderungen, die kundengeneriertes Schlüsselmaterial vorschreiben. Es benötigt entweder ein lokales HSM oder einen dedizierten Cloud-HSM-Dienst als Quelle für die Schlüsselgenerierung. Das KMS des Cloud-Anbieters hat während der Nutzung operativen Zugriff auf das Schlüsselmaterial; BYOK bietet Ihnen Herkunftsnachweis und Widerrufsmöglichkeit, jedoch keinen Zugriff ohne Zugriff seitens des Anbieters.

HYOK (Halte deinen eigenen Schlüssel)

HYOK bedeutet, dass der Verschlüsselungsschlüssel niemals in die Infrastruktur des Cloud-Anbieters gelangt. Ihre Anwendung oder eine clientseitige Bibliothek verschlüsselt Daten vor dem Hochladen in den Cloud-Speicher mithilfe eines Schlüssels, der in Ihrem eigenen HSM generiert und gespeichert wird (entweder lokal oder über einen Cloud-HSM-Dienst eines Drittanbieters, der nicht mit Ihrem Datenspeicheranbieter identisch ist). Der Cloud-Anbieter speichert ausschließlich den Chiffretext und kann Ihre Daten unter keinen Umständen entschlüsseln. HYOK erfordert entweder ein lokales HSM oder ein HSM-as-a-Service-Angebot eines Drittanbieters, das unabhängig von Ihrem Cloud-Speicheranbieter funktioniert. Es bietet maximale Datensouveränität, geht jedoch mit der höchsten betrieblichen Komplexität einher.

Abmessungen	Native Cloud-Schlüsselverwaltung	BYOK (Customer-Generated Key in Cloud KMS)	HYOK (Schlüsselanbieter außerhalb der Cloud)
HSM erforderlich	Nein (HSM des Anbieters)	Ja (zum Generieren und Speichern von Quellschlüsselmaterial)	Ja (um bei jeder Operation einen Schlüssel zu generieren und zu verwenden)
HSM-Bereitstellungsmodell	Unzutreffend	Lokales HSM oder dediziertes Cloud-HSM	Lokales HSM oder HSM von Drittanbietern als Dienstleistung
Anbieterzugriff auf den Schlüssel während der Nutzung	Ja	Ja (operativer Zugriff)	Nein
Zugriff des Anbieters auf Klartextdaten	Ja (per Schlüssel)	Ja (per Tastendruck während der Benutzung)	Nein
Unabhängiger Schlüsselwiderruf	Nur über die Provider-API	Ja (Quellmaterial aus Ihrem HSM löschen)	Ja (Widerrufen Sie den Widerruf umgehend bei Ihrem HSM)
Operative Komplexität	Niedrig	Medium	Hoch
Am besten geeignet,	Allgemeine Cloud-Workloads	Regulierte Sektoren, die eine wichtige Herkunftsnachweisführung erfordern	Geheim, durch staatliche Vorgaben vorgeschrieben, Zero-Trust

Cloudbasierte vs. lokale HSMs: Vollständiger Vergleich

Abmessungen	Lokales HSM	Dedizierter Cloud-HSM	Gemeinsamer Cloud-HSM-Dienst
FIPS 140-2 Stufe 3	Ja	Ja	Abhängig von der Serviceebene (Stufe 2 oder 3)
Physische Schlüsselverwahrung	Deine Organisation	Cloud-Anbieter (nur Hardware; kein Schlüsselzugriff)	Cloud-Anbieter (Hardware und Infrastruktur)
Hardwareverwaltung	Deine Organisation	Cloud-Anbieter (Hardware); Sie verwalten die HSM-Software	Cloud-Anbieter (vollständig verwaltet)
Vorab-Kapitalkosten	20,000 bis über 40,000 US-Dollar pro Gerät	Keine Präsentation	Keine Präsentation
Laufendes Kostenmodell	Personalaufwand, Lizenzen, Rechenzentrumskosten	Stündlich pro Instanz (ca. 1.45 $/Std. für AWS CloudHSM)	Pro API-Aufruf + Gebühr für die Schlüsselspeicherung
Bereitstellungszeit	Wochen bis Monate (Beschaffung, Montage, Konfiguration)	Minuten bis Stunden	Minuten
Latency	Submillisekunde (lokales Netzwerk)	1 bis 5 ms (Netzwerk-API-Roundtrip)	1 bis 10 ms (gemeinsame Service-API)
Hohe Verfügbarkeit	Erfordert mehrere Appliances und eine HA-Konfiguration.	Verfügbar über Multi-Instanz-Cluster oder Cross-AZ	In den Managed Service integriert
Betriebsaufwand	Hoch (Firmware, Partitionen, Clusterverwaltung, Personal)	Mittel (HSM-Software und Partitionsverwaltung)	Niedrig (nur Schlüsselrichtlinien und Zugriffsverwaltung)
Skalierbarkeit	Begrenzt durch die Hardwarekapazität; Erweiterung erfordert Beschaffung	Fügen Sie bei Bedarf Instanzen hinzu.	Skaliert automatisch
Multi-Cloud-Unterstützung	Ja (jede Anwendung kann eine Verbindung herstellen).	Beschränkt auf das Ökosystem dieses Anbieters.	Anbieterspezifisch
Compliance-Verantwortung	Vollständig Ihre Organisation	Gemeinsam genutzt (Anbieter verwaltet Hardware-Konformität)	Hauptanbieter
Luftabgeschottete Umgebungen	Ja	Nein	Nein
BYOK-Quellenfähigkeit	Ja	Ja	Eingeschränkt (einige Anbieter unterstützen es)
Am besten geeignet,	Niedrige Latenz, luftgetrennt, strenge Lokalisierung, HYOK	FIPS Level 3, BYOK, Multi-Cloud mit dedizierter Hardware	Allgemeine Cloud-Workloads, verwaltete Einfachheit

IAM-Modell für die HSM-Zugriffskontrolle

Unabhängig davon, ob Sie HSMs lokal oder in der Cloud einsetzen, ist die Zugriffskontrolle genauso wichtig wie die Hardware selbst. Ein FIPS 140-2 Level 3 HSM mit permissiven Zugriffskontrollen ist nicht sicherer als ein Software-Schlüsselspeicher. Das IAM-Modell für HSMs trennt drei unterschiedliche Rollen, die sich nicht überschneiden dürfen.

Die Rolle des HSM-Administrators umfasst das Erstellen und Verwalten von HSM-Partitionen, das Festlegen von Partitionsrichtlinien, die Verwaltung der HSM-Clusterzugehörigkeit, das Durchführen von Firmware-Updates und die Durchführung von Schlüsselzeremonien. In lokalen Umgebungen übernimmt dies typischerweise ein dediziertes Mitglied des HSM-Betriebsteams mithilfe der Hardware-Authentifizierung des HSM (PED oder Smartcard). Bei Cloud-HSM-Diensten authentifiziert sich der Administrator an der HSM-Management-API mit Hardware-Tokens oder starken Anmeldeinformationen. Die Administratorrolle darf niemals von Anwendungen oder automatisierten Pipelines verwendet werden.

Die Rolle des Schlüsselverwalters (Kryptobeauftragter) erstellt, importiert, exportiert (sofern zulässig), rotiert und löscht Schlüsselobjekte innerhalb einer zugewiesenen Partition. Diese Rolle ist für den Schlüssellebenszyklus im HSM verantwortlich. In einem Cloud-HSM-Kontext entspricht dies der Rolle, die Schlüsselrichtlinien in AWS KMS, Azure Key Vault oder GCP Cloud KMS verwaltet. Aktionen des Schlüsselverwalters sollten bei wichtigen Schlüsseloperationen (Generierung des Stammschlüssels der Zertifizierungsstelle, Löschung des Hauptschlüssels) eine Vier-Augen-Kontrolle erfordern und protokolliert werden.

Anwendungsrolle (Kryptobenutzer): Nutzt Schlüssel innerhalb des HSM für kryptografische Operationen (Verschlüsseln, Entschlüsseln, Signieren, Verifizieren), kann aber keine Schlüssel erstellen, löschen oder exportieren. In Cloud-KMS-Diensten entspricht dies der Zuweisung der spezifischen Berechtigungen für kryptografische Operationen an das Dienstkonto oder die IAM-Rolle der Anwendung (kms:Decrypt für Anwendungen, die nur entschlüsseln; kms:Sign für Anwendungen, die nur signieren), ohne Berechtigungen zur Schlüsselverwaltung. Anwendungsrollen sollten auf bestimmte Schlüssel beschränkt sein und keinen umfassenden Zugriff auf alle Schlüssel in einer Partition oder einem Schlüsselspeicher erhalten.

Schlüsselrotation mit HSMs

Schlüsselrotation in einem HSM-Kontext bedeutet, dass innerhalb des HSM neues Schlüsselmaterial generiert wird, um bestehende Schlüssel nach einem festgelegten Zeitplan zu ersetzen. Die Funktionsweise der Rotation hängt davon ab, ob das HSM einen Hauptschlüssel (der andere Schlüssel umschließt) oder einen Datenverschlüsselungsschlüssel (der Daten direkt verschlüsselt) schützt.

Rotation des Hauptschlüssels in Cloud-KMS mit HSM-Unterstützung: Wenn Sie die automatische Rotation für einen kundenseitig verwalteten Schlüssel in AWS KMS oder Azure Key Vault aktivieren, generiert der Dienst gemäß dem konfigurierten Zeitplan (in der Regel jährlich) neues, HSM-gestütztes Schlüsselmaterial. Vorhandene, mit der vorherigen Schlüsselversion verschlüsselte Daten bleiben entschlüsselbar; das KMS behält die vorherigen Schlüsselversionen bei. Neue Verschlüsselungsvorgänge verwenden das neue Schlüsselmaterial. Die Schlüssel-ID und der ARN bleiben unverändert; die Rotation erfolgt transparent für Anwendungen.

Schlüsselrotation für lokale HSMs und BYOK: Die Schlüsselrotation für lokale HSMs erfordert die Generierung neuen Schlüsselmaterials im HSM, dessen Verteilung an alle Systeme oder Anwendungen, die den Schlüssel verwenden, die erneute Verschlüsselung aller mit dem alten Hauptschlüssel geschützten Datenverschlüsselungsschlüssel und die Archivierung des alten Schlüsselmaterials gemäß Ihrer Aufbewahrungsrichtlinie. Für BYOK-Schlüssel mit importiertem Material in einem Cloud-KMS ist keine automatische Rotation verfügbar. Sie müssen neues Material in Ihrem HSM generieren, es exportieren und in das Cloud-KMS importieren, es als primäre Version festlegen und den Übergangszeitraum für alle abhängigen Workloads verwalten.

Rotation von CA-Privatschlüsseln für PKI: HSMs, die CA-Privatschlüssel schützen, erfordern eine spezielle Behandlung bei der Rotation, da die Rotation eines CA-Privatschlüssels die Ausstellung eines neuen CA-Zertifikats und die Verteilung des neuen Vertrauensankers an alle vertrauenden Parteien erfordert. Die CA-Schlüsselrotation ist ein geplantes PKI-Ereignis, kein routinemäßiger automatisierter Vorgang, und erfordert die Abstimmung mit allen Systemen, die der CA vertrauen. Die Schlüsselzeremonieverfahren des HSM (Doppelkontrolle, M-von-N-Quorum-Authentifizierung) gelten auch für die CA-Schlüsselgenerierung.

Audit-Protokollierung für HSM-Operationen

Die Protokollierung von HSM-Audit-Logs ist eine Compliance-Anforderung gemäß PCI DSS, FedRAMP, HIPAA und den meisten anderen Frameworks, die kryptografische Kontrollen vorschreiben. Das Protokoll muss jeden administrativen Vorgang (Partitionserstellung, Schlüsselerstellung, Schlüssellöschung, Richtlinienänderungen) und jeden kryptografischen Vorgang (Signieren, Verifizieren, Verschlüsseln, Entschlüsseln, Wrappen, Entpacken) erfassen, der vom oder über das HSM in Verbindung mit einer authentifizierten Identität durchgeführt wird.

Lokale HSM-Auditprotokollierung: Physische HSMs generieren intern Auditprotokolle und können diese an einen SIEM- oder Syslog-Server weiterleiten. Das Auditprotokoll des HSM wird vom HSM selbst signiert, um Manipulationen zu erkennen. Die Weiterleitung der Auditprotokolle an einen manipulationssicheren Protokollspeicher außerhalb des Geräts, bevor das interne Protokoll des HSM voll ist, ist eine betriebliche Anforderung, die lokale HSM-Teams explizit verwalten müssen.

Cloud-HSM-Auditprotokollierung: Cloud-HSM- und Cloud-KMS-Dienste sind in die native Auditprotokollierung des Cloud-Anbieters integriert. In AWS wird jeder KMS-API-Aufruf in CloudTrail protokolliert, einschließlich der anfragenden Identität, des Schlüssel-ARN, des Vorgangstyps und des Zeitstempels. In Azure werden Key Vault- und Dedicated-HSM-Vorgänge in Azure Monitor protokolliert. In GCP erscheinen Cloud-KMS- und Cloud-HSM-Vorgänge in Cloud-Auditprotokollen. Diese Cloud-Auditprotokolle sind automatisch manipulationssicher (der Anbieter gewährleistet die Protokollintegrität) und lassen sich dank nativer Integrationen problemlos an SIEM-Plattformen weiterleiten.

Warnung bei den folgenden HSM-Audit-Ereignissen unabhängig vom Bereitstellungsmodell: jede Schlüssellöschung oder Planung der Löschung; jede Richtlinienänderung an einem wichtigen Schlüssel oder einer Partition; jede kryptografische Operation durch eine Identität, die nicht in der Liste der genehmigten Anwendungsrollen enthalten ist; jeder fehlgeschlagene Authentifizierungsversuch gegen das HSM; und jeder Versuch, Schlüsselmaterial aus einer als nicht exportierbar konfigurierten Partition zu exportieren.

Multi-Cloud-HSM-Architektur

Organisationen, die mit mehreren Cloud-Anbietern zusammenarbeiten, stehen vor einer spezifischen HSM-Herausforderung: Der dedizierte HSM-Dienst jedes Cloud-Anbieters ist auf dessen Infrastruktur beschränkt, und die HSM-Dienste der Cloud-Anbieter sind nicht anbieterübergreifend vernetzt. Eine AWS CloudHSM-Instanz kann GCP-Workloads nicht direkt bedienen, und ein dediziertes Azure HSM kann ohne zusätzliche Tools keine Schlüssel für den AWS KMS-Import generieren. Drei Muster adressieren die Multi-Cloud-HSM-Architektur:

• Lokales HSM als zentrale Schlüsselinstanz: Ein lokales HSM-Cluster dient als zentrale Schlüsselgenerierungs- und Speicherinstanz für alle Umgebungen. Die im lokalen HSM generierten Schlüssel werden exportiert (verschlüsselt) und als BYOK-Schlüssel in die KMS-Systeme der Cloud-Anbieter importiert. Das lokale HSM ist die maßgebliche Quelle für alle Schlüsseldaten; die KMS-Dienste der Cloud-Anbieter greifen auf diese Daten zu. Dieses Modell bietet die stärkste zentrale Kontrolle, erfordert jedoch eine hohe Verfügbarkeit und Erreichbarkeit des lokalen HSM für alle Cloud-Umgebungen.
• HSM-as-a-Service von Drittanbietern für verschiedene Cloud-Anbieter: Ein HSM-Dienst eines Drittanbieters, der unabhängig von den drei großen Cloud-Anbietern ist, stellt eine zentrale HSM-Infrastruktur bereit, die für Workloads in allen Cloud-Umgebungen zugänglich ist. Der HSM-Dienst generiert Schlüssel und stellt diese Anwendungen in jeder Cloud über eine einheitliche API zur Verfügung. Dadurch wird das Problem der anbieterspezifischen HSM-Silos ohne die Notwendigkeit lokaler Hardware beseitigt, und er dient als Schlüsselgenerierungsquelle für BYOK (Bring Your Own Key) über alle Cloud-Anbieter hinweg. (Encryption Consulting) HSM als Service Dieses Modell bietet eine FIPS 140-2 Level 3 HSM-Infrastruktur, die über Cloud-Umgebungen zugänglich ist.
• Dedizierter HSM pro Cloud mit zentralisierter Schlüsselverwaltung: Implementieren Sie in jedem Cloud-Anbieter einen dedizierten Cloud-HSM-Dienst (AWS CloudHSM in AWS, Azure Dedicated HSM in Azure) und verwalten Sie diese als separate Schlüsselautorisierungen für Workloads in der jeweiligen Cloud. Nutzen Sie eine zentrale Governance-Plattform für das Schlüsselmanagement, um die Transparenz aller Schlüssel über alle HSM-Instanzen hinweg zu gewährleisten, einheitliche Schlüsselrichtlinien durchzusetzen und Audit-Logs zu aggregieren. Dieses Modell ist zwar betrieblich am komplexesten, vermeidet aber netzwerkübergreifende Abhängigkeiten bei kryptografischen Operationen.

Compliance-Überlegungen für den HSM-Einsatz

Unterschiedliche Compliance-Rahmenwerke legen unterschiedliche HSM-Anforderungen fest. Die Abstimmung Ihrer HSM-Bereitstellung auf die jeweilige Anforderungssprache verhindert sowohl eine unzureichende Compliance (Verwendung von Level 2, wo Level 3 erforderlich ist) als auch Überinvestitionen (Bereitstellung von lokalen HSMs, obwohl ein verwalteter Cloud-HSM-Dienst die Anforderung erfüllt).

PCI DSS v4.0.1 (verpflichtend ab 31. März 2025): Schreibt vor, dass kryptografische Schlüssel zum Schutz von Karteninhaberdaten an so wenigen Orten wie möglich gespeichert werden müssen. Schlüsselverwaltungsprozesse müssen den Schutz der Schlüssel vor Offenlegung und Missbrauch gewährleisten (Anforderung 3.7.1). HSMs werden ausdrücklich als zulässige Schlüsselverwaltungstechnologie genannt. PCI DSS schreibt kein bestimmtes FIPS-Level für das HSM vor, verlangt jedoch, dass das Schlüsselverwaltungssystem sicher und auditierbar ist. Cloud-HSM-Dienste, die für den PCI-Geltungsbereich verwendet werden, müssen sich innerhalb der PCI-DSS-zertifizierten Infrastruktur des Anbieters befinden.

FedRAMP (NIST SP 800-53 Rev. 5): Die SC-12-Kontrolle (Kryptografische Schlüsselerzeugung und -verwaltung) verlangt, dass Schlüssel mithilfe von NSA-zugelassener oder NIST-empfohlener Schlüsselverwaltungstechnologie erzeugt, kontrolliert und verteilt werden. FedRAMP High erfordert zusätzlich FIPS 140-2- oder FIPS 140-3-Level-3-validierte kryptografische Module. AWS CloudHSM, Azure Dedicated HSM und GCP Cloud HSM mit HSM-Schutzstufe erfüllen diese Anforderung. Standardmäßige gemeinsam genutzte Cloud-KMS-Dienste auf FIPS 140-2 Level 2 erfüllen die Level-3-Anforderung von FedRAMP High nicht.

eIDAS und qualifizierte Signaturen (EU): Qualifizierte elektronische Signaturen gemäß eIDAS erfordern qualifizierte Signaturerstellungsgeräte (QSCDs), die mindestens den Anforderungen von FIPS 140-2 Level 3 oder Common Criteria EAL4+ entsprechen müssen. EU-Organisationen, die qualifizierte Zertifikate oder Signaturen ausstellen, benötigen entweder lokale HSMs oder dedizierte Cloud-HSMs in der EU mit den entsprechenden Validierungen.

HIPAA schreibt keine spezifischen HSM-Anforderungen vor, verlangt aber angemessene Sicherheitsvorkehrungen für Verschlüsselungsschlüssel zum Schutz elektronischer Gesundheitsdaten (ePHI). Ein Cloud-HSM-Dienst mit dokumentierten Zugriffskontrollen, Protokollierung und einer unterzeichneten Vereinbarung zur Auftragsverarbeitung (Business Associate Agreement, BAA) mit dem Anbieter erfüllt die technischen Sicherheitsanforderungen von HIPAA für den Schlüsselschutz.

Leitfaden zur HSM-Implementierung

Nutzen Sie die folgenden Kriterien, um das richtige HSM-Bereitstellungsmodell für die Anforderungen Ihrer Organisation zu ermitteln.

1. Ermitteln Sie Ihre Latenzanforderung: Wenn Ihre Anwendung HSM-Reaktionszeiten im Submillisekundenbereich erfordert, ist ein lokales HSM die einzige Option. Sind 1 bis 10 Millisekunden akzeptabel, sind Cloud-HSM-Dienste eine sinnvolle Alternative.
2. Ermitteln Sie Ihre FIPS-Level-Anforderung: Wenn FIPS 140-2 Level 3 erforderlich ist (FedRAMP High, bestimmte PCI- oder eIDAS-Standards), überprüfen Sie, ob der von Ihnen evaluierte Cloud-Dienst Level 3 und nicht nur Level 2 erfüllt. Gemeinsam genutzte Cloud-KMS-Dienste unterscheiden sich je nach Anbieter und Tarif.
3. Identifizieren Sie Ihr Schlüsselkontrollmodell: Wenn die native Schlüsselverwaltung des Anbieters akzeptabel ist, verwenden Sie das gemeinsame KMS des Cloud-Anbieters mit HSM-Schutz. Wenn BYOK erforderlich ist, benötigen Sie ein lokales HSM oder ein dediziertes Cloud-HSM zur Generierung von Schlüsselmaterial. Wenn HYOK erforderlich ist, benötigen Sie ein HSM, das vollständig außerhalb des Cloud-Anbieters operiert, der Ihre Daten speichert.
4. Ermitteln Sie Ihre Anforderungen an die Datensouveränität: Wenn Vorschriften vorschreiben, dass Schlüssel ein bestimmtes Land oder eine bestimmte Einrichtung niemals verlassen dürfen und an diesem Standort kein Cloud-HSM-Dienst verfügbar ist, ist ein lokales HSM erforderlich. Falls ein Cloud-HSM-Dienst in der erforderlichen Gerichtsbarkeit verfügbar ist, überprüfen Sie die vertraglichen Garantien für den Datenspeicherort.
5. Ermitteln Sie Ihre Multi-Cloud-Strategie: Wenn Sie mit mehreren Cloud-Anbietern arbeiten und eine zentrale Schlüsselverwaltung benötigen, sollten Sie einen HSM-as-a-Service eines Drittanbieters oder einen lokalen HSM-Cluster als zentrale Schlüsselinstanz in Betracht ziehen.
6. Berechnen Sie die Gesamtbetriebskosten: Vergleichen Sie die Hardware- und Betriebskosten für eine On-Premises-Lösung mit den stündlichen Preisen für Cloud-HSM bei Ihrem erwarteten Transaktionsvolumen. Bei niedrigen bis mittleren Volumina bietet Cloud-HSM niedrigere Gesamtbetriebskosten. Bei sehr hohen kryptografischen Transaktionsraten (Millionen von Operationen pro Stunde) kann dedizierte On-Premises-Hardware kostengünstiger sein.
7. Beurteilung der Einsatzfähigkeit: On-Premises-HSM erfordert Personal mit spezifischen HSM-Kenntnissen für Betrieb und Wartung. Cloud-HSM-Dienste reduzieren diesen Bedarf, beseitigen ihn aber nicht vollständig. Verfügt Ihr Unternehmen nicht über dedizierte HSM-Betriebsexpertise, senkt ein Managed Cloud HSM Service oder ein HSM-as-a-Service-Angebot eines spezialisierten Anbieters das Betriebsrisiko erheblich.

Wie Verschlüsselungsberatung helfen kann

Encryption Consulting ist ein Beratungsunternehmen für angewandte Kryptografie mit Zertifizierungen nach ISO/IEC 27001:2022 und SOC 2. Wir unterstützen Organisationen bei der Auswahl, Implementierung und dem Betrieb von HSM-Infrastrukturen für Cloud- und On-Premise-Umgebungen – von der ersten Anforderungsanalyse bis hin zur kontinuierlichen Erstellung von Compliance-Nachweisen.

• HSM als Dienstleistung: Verschlüsselungsberatung HSM als Service Bietet eine dedizierte FIPS 140-2 Level 3 HSM-Infrastruktur als Managed Service, die für Workloads in Cloud- und On-Premise-Umgebungen verfügbar ist. Geeignet als BYOK- und HYOK-Schlüsselgenerierungsquelle, als zentrale Multi-Cloud-Schlüsselautorisierung und als Managed-Alternative zur Bereitstellung und zum Betrieb eigener HSM-Hardware. Unterstützt durch ISO/IEC 27001:2022-zertifizierte Prozesse.
• PKI als Dienstleistung: Für Organisationen, die HSMs zum Schutz privater CA-Schlüssel verwenden, bietet Encryption Consulting die passende Lösung. PKI als Service Bietet eine vollständig verwaltete private Zertifizierungsstelle mit HSM-gestützter Speicherung der Zertifizierungsschlüssel, ACME-automatisierter Zertifikatsausstellung und Integration mit allen gängigen Cloud-Plattformen. Dadurch entfällt die Notwendigkeit, lokale HSMs ausschließlich zum Schutz der PKI-Zertifizierungsschlüssel zu betreiben.
• HSM-Beratungs- und Implementierungsdienste: Wenn Sie lokale HSMs einsetzen oder Cloud-HSM-Dienste evaluieren, ist Encryption Consulting der richtige Ansprechpartner. HSM-Dienste Die Leistungen umfassen die Auswahl und Dimensionierung von HSMs, das Design von Hochverfügbarkeitsclustern, die Integration von PKCS#11 und REST-APIs in Anwendungen, die Verfahren zur Schlüsselerstellung für die Generierung von CA-Root-Schlüsseln, die Dokumentation zur FIPS-Konformität sowie die laufende operative Unterstützung.
• CBOM Secure: Verschlüsselungsberatung CBOM Secure Erkennt und inventarisiert alle kryptografischen Assets in Ihren Cloud- und On-Premises-Umgebungen, einschließlich HSM-geschützter Schlüssel, Cloud-KMS-Schlüssel und Zertifikate. Erstellt eine kryptografische Stückliste (CBOM) im CycloneDX-Format, die Schlüssel ohne HSM-Schutz, Schlüssel mit bevorstehendem Rotationsdatum und Schlüssel mit veralteten Algorithmen identifiziert.
• PQC-Bereitschaft: Das NIST finalisierte im August 2024 die Post-Quanten-Kryptographiestandards FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA). NIST IR 8547 deutet darauf hin, dass RSA und ECC für neue Anwendungsfälle um das Jahr 2030 als veraltet gelten werden. HSMs müssen vor diesem Übergang Post-Quanten-Algorithmen unterstützen, und nicht alle aktuellen HSM-Hardwarekomponenten lassen sich allein durch Firmware-Updates aufrüsten. (Encryption Consulting) PQC-Bereitschaft Der Service bewertet den Migrationspfad Ihrer HSM-Infrastruktur nach der Quantenmigration und entwirft die Reihenfolge für das HSM-Upgrade oder den Austausch.

Um Ihre Anforderungen an die HSM-Implementierung zu besprechen, wenden Sie sich an Encryption Consulting.

Fazit

Cloudbasierte und lokale HSMs nutzen dieselbe validierte kryptografische Hardwaretechnologie. Das Bereitstellungsmodell bestimmt, wer die Hardware betreibt, welche Latenz- und Kostenstruktur gilt und wie sich das HSM in Ihr Schlüsselverwaltungsmodell (nativ, BYOK oder HYOK) integriert. Für die meisten Organisationen bieten Cloud-HSM-Dienste, insbesondere dedizierte Single-Tenant-Dienste, eine vergleichbare Sicherheit wie lokale HSMs bei deutlich geringerem Betriebsaufwand und niedrigeren Gesamtbetriebskosten. Lokale HSMs bleiben die richtige Wahl für Anforderungen an Latenzzeiten im Submillisekundenbereich, abgeschottete Umgebungen und Regionen, in denen kein Cloud-HSM-Dienst die Anforderungen an die Datenlokalisierung erfüllt.

Die Entscheidung ist nicht eindeutig. Viele Organisationen kombinieren verschiedene Modelle: ein lokales oder Drittanbieter-HSM als BYOK-Schlüsselgenerierungsinstanz, Cloud-KMS-Dienste als operative Schlüsselverwaltungsschicht für Cloud-Workloads und Cloud-HSM-Dienste für spezifische, sicherheitskritische Workloads, die FIPS 140-2 Level 3 in der Cloud-Umgebung erfordern. Die eigentliche operative Komplexität liegt in der korrekten Konzeption dieser Architektur und der Pflege des IAM-Modells, des Rotationsplans und der Audit-Protokollierung über alle Schichten hinweg.

Häufig gestellte Fragen

Worin besteht der Unterschied zwischen Cloud-basierten HSMs und On-Premises-HSMs?

Cloudbasierte HSMs sind FIPS-validierte Hardware-Sicherheitsmodule, die von einem Cloud-Anbieter oder Drittanbieter in einem entfernten Rechenzentrum betrieben und über eine Netzwerk-API angesteuert werden. On-Premises-HSMs sind physische Geräte, die in Ihren eigenen Räumlichkeiten installiert werden. Beide nutzen dieselbe kryptografische Hardware und können die FIPS 140-2 Level 3-Validierung erreichen. Der Hauptunterschied liegt darin, wer die Hardware betreibt, wer physischen Zugriff hat, wie das Latenzprofil aussieht und ob es sich um Investitions- oder Betriebskosten handelt.

Welches System ist sicherer: Cloud-basierte HSMs oder lokale HSMs?

Beide Varianten können die FIPS 140-2 Level 3-Zertifizierung erreichen. Die Sicherheit hängt stärker von der Bereitstellungskonfiguration und den Schlüsselverwaltungspraktiken als vom Bereitstellungsmodell ab. Bei On-Premises-Lösungen verwahrt Ihr Unternehmen die physischen Schlüssel selbst. Gut konfigurierte dedizierte Cloud-HSM-Dienste bieten eine vergleichbare oder sogar höhere Sicherheit als schlecht gewartete On-Premises-Cluster. Das Risikoprofil eines dedizierten Single-Tenant-Cloud-HSM eines großen Anbieters ist für die meisten Bedrohungsmodelle mit dem eines On-Premises-HSM vergleichbar.

Was ist BYOK und in welchem ​​Zusammenhang steht es mit der Wahl des Schulfachs?

BYOK (Bring Your Own Key) bedeutet, dass Sie Verschlüsselungsschlüsselmaterial in Ihrem eigenen HSM generieren und in das KMS eines Cloud-Anbieters importieren. Ein lokales HSM oder ein dediziertes Cloud-HSM dient als BYOK-Schlüsselgenerierungsquelle. Der Cloud-Anbieter verwendet Ihr importiertes Material für Verschlüsselungsvorgänge, die Quelle bleibt jedoch in Ihrem Besitz. HYOK geht noch einen Schritt weiter: Der Schlüssel gelangt niemals in die Infrastruktur des Cloud-Anbieters, sodass eine clientseitige Verschlüsselung mit einem vollständig in Ihrem eigenen HSM verwalteten Schlüssel erforderlich ist.

Wie hoch sind die Kosten für ein Cloud-basiertes HSM im Vergleich zu einem On-Premises-HSM?

AWS CloudHSM berechnet ca. 1.45 US-Dollar pro Stunde und Instanz, etwa 1,040 US-Dollar pro Monat für eine einzelne Instanz bzw. 2,100 US-Dollar pro Monat für einen HA-Cluster mit zwei Instanzen. Lokale HSMs erfordern Vorabinvestitionen von 20,000 bis 40,000 US-Dollar oder mehr pro Appliance, zuzüglich Lizenzen für die Managementsoftware, Rechenzentrumskosten und Personalaufwand. CloudHSM bietet niedrigere Gesamtbetriebskosten (TCO) bei geringen bis mittleren Transaktionsvolumina. Lokale Lösungen können sich bei sehr hohen kryptografischen Transaktionsraten, bei denen die Kosten für API-Aufrufe erheblich ansteigen, als kostengünstiger erweisen.

Unterstützen Cloud-HSMs FIPS 140-2 Level 3?

Dedizierte Cloud-HSM-Dienste bieten folgenden Schutz: AWS CloudHSM nutzt Luna Networks HSM-Hardware gemäß FIPS 140-2 Level 3, Azure Dedicated HSM verwendet Entrust nShield Connect gemäß Level 3 und GCP Cloud HSM bietet Level-3-Schutz für HSM-basierte Schlüssel. Gemeinsam genutzte Cloud-KMS-Dienste ohne dedizierte HSM-Ebene verwenden Level 2, nicht Level 3. Prüfen Sie stets die genaue Dienstebene und das Schutzniveau, wenn Level 3 eine spezifische Compliance-Anforderung darstellt.

Wann sollte sich eine Organisation für lokale HSMs anstelle von Cloud-HSMs entscheiden?

Wählen Sie eine On-Premises-Lösung, wenn: die Anwendung kryptografische Antwortzeiten im Submillisekundenbereich erfordert, die eine Cloud-API nicht erfüllen kann; regulatorische Anforderungen vorschreiben, dass die Schlüssel an einem bestimmten physischen Standort oder in einem bestimmten Zuständigkeitsbereich aufbewahrt werden müssen, wo kein Cloud-HSM-Dienst verfügbar ist; die Umgebung vom Internet getrennt ist; oder das Volumen kryptografischer Transaktionen so hoch ist, dass die Kosten für Cloud-API-Aufrufe die Kosten der eigenen Hardware übersteigen. In den meisten anderen Anwendungsfällen bieten Cloud-HSM-Dienste gleichwertige Sicherheit bei geringerem Betriebsaufwand.