Google Cloud Platform (GCP) – Einführung in Google Cloud HSM

Google Cloud HSM ist ein verwalteter Dienst auf der Google Cloud Platform (GCP), der FIPS 140-2 Level 3-validierte Hardware-Sicherheitsmodule (HSMs) als kryptografisches Backend für Google Cloud KMS (Key Management Service) bereitstellt. Dies ist wichtig, da die FIPS 140-2 Level 3-Hardwarevalidierung eine zwingende Voraussetzung für FedRAMP High-, PCI DSS- und eIDAS-qualifizierte Signatur-Workloads ist und standardmäßige softwaregeschützte Cloud KMS-Schlüssel diese Anforderung nicht erfüllen. Es wird empfohlen, für alle regulierten Workloads Cloud KMS-Schlüssel mit dem HSM-Schutzniveau zu erstellen, die automatische Schlüsselrotation zu aktivieren und Cloud-Audit-Logs so zu konfigurieren, dass jede kryptografische Operation mit einer authentifizierten Identität protokolliert wird.

Kurzantwort: Was ist Google Cloud HSM und wann benötigt man es?

Google Cloud HSM ist die HSM-basierte Schlüsselschutzebene innerhalb von Cloud KMS. Wenn Sie einen Cloud-KMS-Schlüssel mit dem Schutzlevel HSM erstellen, wird dieser auf FIPS 140-2 Level 3-validierter Hardware generiert, kryptografische Operationen werden innerhalb des HSM-Bereichs durchgeführt und das Schlüsselmaterial verlässt das HSM niemals im Klartext. Sie benötigen Cloud HSM, wenn Ihr Compliance-Framework FIPS 140-2 Level 3-Schlüsselschutz erfordert (FedRAMP High, PCI DSS für Schlüssel mit hohem Wert, eIDAS), wenn Sie eine Hardware-Attestierung benötigen, die belegt, dass das Schlüsselmaterial auf einem manipulationssicheren Gerät generiert wurde, oder wenn die Sicherheitsrichtlinie Ihres Unternehmens dedizierte Hardware für die Aufbewahrung von Verschlüsselungsschlüsseln auf GCP vorschreibt. Für Workloads, die keine Level 3-Hardwarevalidierung erfordern, sind Cloud-KMS-Software-geschützte Schlüssel auf FIPS 140-2 Level 1 einfacher und deutlich kostengünstiger.

Wichtige Erkenntnisse

• Cloud HSM verwendet nach FIPS 140-2 Level 3 validierte HSMs: Mit dem HSM-Schutzlevel in Cloud KMS erstellte Schlüssel werden ausschließlich innerhalb des HSM-Clusters generiert und verwendet. Schlüsselmaterial verlässt den HSM niemals unverschlüsselt. Der HSM-Cluster ist regional gebunden; Schlüssel können nicht außerhalb der GCP-Region, in der sie erstellt wurden, verschoben werden.
• Der Zugriff auf Cloud HSM erfolgt über dieselbe Cloud KMS API wie auf softwaregeschützte Schlüssel: Für den Wechsel von softwarebasierter zu HSM-basierter Schlüsselsicherung sind keine Anwendungsänderungen erforderlich. Die Schutzstufe wird bei der Schlüsselerstellung festgelegt und kann anschließend nicht mehr geändert werden.
• Die HSM-Firmware wird vom Hersteller kontrolliert und kann von Google nicht verändert werden: Die gesamte HSM-Firmware ist vom Hardwarehersteller digital signiert. Diese Kontrolle des Herstellers über die Firmware ist ein zentrales Sicherheitsmerkmal, das Google daran hindert, unautorisierte Codeänderungen in die HSM-Umgebung einzuführen.
• Cloud HSM unterstützt BYOK über Cloud KMS Importaufträge: Sie können Schlüsselmaterial in Ihrem eigenen HSM oder Schlüsselverwaltungssystem generieren, es verschlüsseln und mit dem HSM-Schutzniveau in Cloud KMS importieren. Cloud External Key Manager (Cloud EKM) unterstützt HYOK, wodurch der Schlüssel niemals in GCP gelangt.
• Die Cloud-HSM-Schlüsselversionen kosten 2.50 US-Dollar pro Monat und aktiver Version: Dies ist deutlich teurer als bei softwaregeschützten Schlüsselversionen (0.06 US-Dollar pro Monat). Nutzen Sie den HSM-Schutz nur, wenn er gesetzlich oder intern vorgeschrieben ist, um unnötige Kosten zu vermeiden.

Was ist Google Cloud HSM?

Google Cloud HSM ist ein verwalteter Cloud-Dienst innerhalb der Google Cloud Platform, der eine Hardware-Sicherheitsmodul-Infrastruktur (HSM) als Backend für die kryptografische Schlüsselspeicherung und -verarbeitung für Google Cloud KMS bereitstellt. Ein HSM ist ein dediziertes physisches Gerät, das kryptografische Schlüssel innerhalb einer manipulationssicheren Hardwaregrenze schützt, Schlüssel mithilfe von Hardware-Zufallszahlengeneratoren erzeugt und kryptografische Operationen (Verschlüsselung, Entschlüsselung, Signierung, Verifizierung) innerhalb dieser Grenze durchführt, sodass Schlüsselmaterial niemals im Klartext übertragen werden muss.

Wenn Sie in Cloud KMS einen Schlüssel erstellen und die HSM-Schutzstufe festlegen, weisen Sie Cloud KMS an, den Schlüssel im Cloud-HSM-Cluster zu generieren und zu speichern, anstatt in softwarebasierten Kryptografiemodulen. Der Zugriff auf den Cloud-HSM-Dienst erfolgt über dieselbe Cloud-KMS-API und dieselben Clientbibliotheken wie bei softwaregeschützten Schlüsseln. Bestehende Anwendungen, die Cloud KMS verwenden, benötigen keine Codeänderungen, um Cloud HSM zu nutzen; lediglich der Parameter für die Schutzstufe bei der Schlüsselerstellung ändert sich.

Cloud HSM wird vollständig von Google verwaltet: Die physische HSM-Hardware, Firmware, Netzwerktechnik und Hochverfügbarkeit liegen in Googles operativer Verantwortung. Google stattet HSMs mit Mehrparteien-Autorisierungskontrollen, logischen und physischen Sicherheitsvorkehrungen sowie einer klaren Aufgabentrennung zwischen Cloud-HSM-Administratoren und Protokollierungsadministratoren aus. Die Verantwortung des Kunden liegt in der Konfiguration der Schlüsselrichtlinien, der IAM-Zugriffskontrolle, der Planung des Schlüsselwechsels und der Überwachung der Audit-Logs.

FIPS 140-2 Level 3 Validierung und ihre Bedeutung

FIPS 140-2 (Federal Information Processing Standard 140-2) ist der NIST-Standard, der Sicherheitsanforderungen für kryptografische Module definiert. Er spezifiziert vier Sicherheitsstufen:

Stufe 1 erfordert grundlegende kryptografische Softwarealgorithmen. Stufe 2 ergänzt diese um manipulationssichere physische Sicherheitsmaßnahmen (Siegel oder Beschichtungen, die Manipulationsspuren sichtbar machen). Stufe 3 bietet zusätzlich manipulationsresistente physische Sicherheitsmaßnahmen, die sensible Sicherheitsparameter bei Erkennung einer Manipulation aktiv zerstören und vor kryptografischen Operationen eine identitätsbasierte Authentifizierung erfordern. Stufe 4 bietet eine vollständige physische Sicherheitsarchitektur, die vor Angriffen aus der Umgebung schützt.

Standardmäßig werden Cloud-KMS-Software-geschützte Schlüssel gemäß FIPS 140-2 Level 1 validiert. Cloud-HSM-geschützte Schlüssel werden gemäß FIPS 140-2 Level 3 validiert. Dieser Unterschied ist für regulierte Workloads entscheidend: FedRAMP High, PCI DSS High-Assurance-Implementierungen und eIDAS-qualifizierte Signaturerstellungsgeräte (QSCDs) erfordern Level 3, nicht Level 1.

Eine entscheidende Sicherheitsfunktion von Cloud HSM besteht darin, dass die HSM-Firmware vom Hardwarehersteller digital signiert ist und Google sie weder erstellen noch verändern kann. Diese Kontrolle des Herstellers über die Firmware verhindert, dass Google Codeänderungen vornimmt, die die Sicherheitsgrenzen des HSM schwächen, Schlüsselmaterial exportieren oder die Manipulationsschutzmechanismen umgehen könnten. Alle Firmware-Updates des Herstellers sind signiert, einschließlich der Entwicklungs-Firmware für Testzwecke. Dadurch können Kunden kryptografisch bestätigen, dass ihre Schlüssel vom Hersteller generiert wurden und ausschließlich innerhalb der Hardwaregrenzen verbleiben.

Cloud-HSM-Schlüsselhierarchie und Speicherarchitektur

Google Cloud HSM verwendet eine mehrschichtige Schlüsselhierarchie, um Kundenschlüssel in der gesamten Cloud KMS-Infrastruktur zu schützen.

Root-Schlüssel: Auf dem HSM wird ein Root-Schlüssel generiert, der während seiner gesamten Lebensdauer die klar definierten Grenzen des HSM-Clusters nicht verlässt. Das Klonen des Root-Schlüssels zwischen HSMs innerhalb desselben regionalen Clusters ist zur Gewährleistung hoher Verfügbarkeit zulässig; der Root-Schlüssel wird jedoch niemals außerhalb des regionalen HSM-Clusters exportiert.

Kundenschlüsselverschlüsselung: Der Stammschlüssel dient zur Verschlüsselung ruhender Kundenschlüssel. Diese werden verschlüsselt im Schlüsselspeicher des Cloud KMS abgelegt. Wird ein Kundenschlüssel für eine kryptografische Operation benötigt, wird er in das HSM geladen, innerhalb der HSM-Grenzen mit dem Stammschlüssel entschlüsselt, für die Operation verwendet und anschließend der Klartextschlüssel aus dem HSM-Speicher gelöscht. Das HSM gibt niemals einen entschlüsselten Kundenschlüssel an einen Aufrufer zurück. Kundenschlüssel dürfen von HSMs ausschließlich für operative Zwecke verwendet werden.

Cloud-KMS-Schlüsselspeicher: HSMs werden nicht als permanenter Schlüsselspeicher verwendet (die Speicherkapazität der HSMs ist begrenzt). Kundenschlüssel werden mit dem HSM-Root-Schlüssel verschlüsselt und im Cloud-KMS-Schlüsselspeicher abgelegt. Dieser gewährleistet Verfügbarkeit, Dauerhaftigkeit, dauerhafte Speicherung und Schutz. Der Datenspeicher verwendet authentifizierte Verschlüsselung zur Speicherung der Kundenschlüssel. Alle Metadaten werden mittels HMAC authentifiziert, um Beschädigungen zu erkennen. Stündlich scannt ein Batch-Job alle Schlüssel und überprüft die HMAC-Gültigkeit sowie die erfolgreiche Entschlüsselung. Der Datenspeicher erstellt stündliche Snapshots für vier Tage, tägliche vollständige Backups auf Festplatte und Band sowie eine Änderungshistorie auf Zeilenebene für die Notfallwiederherstellung. Die Backups des Datenspeichers befinden sich in der zugehörigen GCP-Region und werden im Ruhezustand verschlüsselt. Die Datenspeicher-Techniker haben keinen Zugriff auf die Kundenschlüssel im Klartext.

Cloud-HSM-Bereitstellung und Sicherheitsinvarianten auf Systemebene

Google stellt Cloud-HSMs in einem Labor bereit, das mit physischen und logischen Sicherheitsvorkehrungen ausgestattet ist, einschließlich Mehrparteien-Autorisierungskontrollen, die verhindern, dass ein einzelner Administrator die HSM-Konfiguration kompromittiert. Die folgenden Systeminvarianten gelten für jeden Cloud-HSM-Cluster:

• Kundenschlüssel können nicht als Klartext extrahiert werden: Bei keinem Cloud-HSM-Vorgang werden unverschlüsselte Kundenschlüsseldaten an Anrufer, einschließlich Google-Mitarbeiter, zurückgegeben.
• Kundenschlüssel können nicht außerhalb der Ursprungsregion transferiert werden: In einem Cloud KMS-Schlüsselring erstellte Schlüssel sind an die GCP-Region dieses Schlüsselrings gebunden und können nicht in eine andere Region migriert werden.
• Alle Konfigurationsänderungen sind durch mehrfache Sicherheitsvorkehrungen geschützt: Änderungen an der HSM-Konfiguration erfordern eine Autorisierung durch mehrere Parteien, um eine Kompromittierung durch einen einzelnen Akteur zu verhindern.
• Administrative Vorgänge werden unter Berücksichtigung der Funktionstrennung protokolliert: Cloud-HSM-Administratoren und Protokollierungsadministratoren sind separate Rollen. Administratoren können ihre eigenen Audit-Protokolle weder ändern noch löschen.
• HSMs sind während ihres gesamten Betriebslebenszyklus vor Manipulationen geschützt: Physische Manipulationsschutzmechanismen sind von der Bereitstellung bis zur Außerbetriebnahme aktiv und erkennen und reagieren auf Versuche, bösartige Hardware oder Software einzuschleusen oder Geheimnisse zu extrahieren.

Wichtige Steuerungsmodelle: Natives Cloud-HSM, BYOK und HYOK

Cloud HSM unterstützt drei Schlüsselkontrollmodelle mit wesentlich unterschiedlichen Sicherheits- und Souveränitätseigenschaften.

Natives Cloud-HSM (von Google generiertes Schlüsselmaterial)

Im Standardmodell von Cloud HSM generiert Google das Schlüsselmaterial innerhalb des HSM-Clusters. Sie erstellen einen Cloud-KMS-Schlüssel mit der Schutzstufe HSM. Cloud KMS generiert diesen Schlüssel innerhalb des HSM, umschließt ihn mit dem HSM-Root-Schlüssel und speichert ihn im Cloud-KMS-Datenspeicher. Sie steuern, wer den Schlüssel verwenden darf (über IAM und Schlüsselrichtlinie), wann er rotiert wird und ob er deaktiviert oder gelöscht wird. Google verwaltet die HSM-Hardware und die Generierung des Schlüsselmaterials, kann den Schlüssel jedoch nicht ohne einen authentifizierten API-Aufruf gemäß Ihrer IAM-Richtlinie in Ihrem Namen verwenden.

Dieses Modell eignet sich für die meisten regulierten GCP-Workloads. Sie erhalten Hardware-Schutz gemäß FIPS 140-2 Level 3, regionale Schlüsselverwaltung, Hardware-Attestierung und Cloud-Audit-Logs pro Vorgang – ohne zusätzlichen Aufwand für die HSM-Hardwareverwaltung.

BYOK (Bring Your Own Key) via Cloud KMS Import Jobs

Cloud KMS-Importaufträge unterstützen den Import extern generierter Schlüsselmaterialien in Cloud KMS mit HSM als Zielschutzebene. Sie generieren 256-Bit-AES-Schlüsselmaterial (oder RSA/ECC-Schlüsselmaterial für asymmetrische Schlüssel) in Ihrem eigenen HSM oder Schlüsselverwaltungssystem, verschlüsseln es mit dem Verschlüsselungsschlüssel des Importauftrags (einem vom Importauftrag heruntergeladenen RSA-OAEP- oder AES-KWP-Schlüssel) und laden das verschlüsselte Material in Cloud KMS hoch. Sobald der Importauftrag das verschlüsselte Material empfängt, entschlüsselt er es im Cloud-HSM-Cluster mit dem privaten Schlüssel des Importauftrags und speichert das vom Kunden bereitgestellte Schlüsselmaterial unter HSM-Schutz.

BYOK erfüllt die Compliance-Anforderungen, die kundengeneriertes Schlüsselmaterial vorschreiben. Sie behalten das Original-Schlüsselmaterial in Ihrem eigenen HSM und können die importierte Kopie aus Cloud KMS löschen, um GCP die Nutzung des Schlüssels sofort zu entziehen. Beachten Sie, dass GCP während der Nutzung operativen Zugriff auf das Schlüsselmaterial hat (es muss für kryptografische Operationen in das HSM geladen werden). BYOK bietet Herkunftskontrolle und Widerrufsmöglichkeit, jedoch keinen vollständigen Zugriff für GCP.

HYOK (Hold Your Own Key) über Cloud External Key Manager

Cloud External Key Manager (Cloud EKM) ist der GCP-Dienst, der HYOK für Cloud KMS implementiert. Mit Cloud EKM gelangt der Verschlüsselungsschlüssel niemals in die GCP-Infrastruktur. Wenn ein Cloud-KMS-Vorgang den Schlüssel benötigt (z. B. zum Verschlüsseln einer BigQuery-Spalte oder eines Cloud-Storage-Objekts), ruft Cloud KMS Ihr externes Schlüsselverwaltungssystem über eine TLS-authentifizierte Verbindung auf, führt den Schlüsselvorgang in Ihrem externen KMS durch und sendet lediglich das Ergebnis an GCP zurück. GCP speichert nur den Chiffretext; ohne eine aktive Verbindung zu Ihrem externen Schlüsselverwaltungssystem kann GCP Ihre Daten nicht entschlüsseln.

Cloud EKM eignet sich für Daten, die Souveränitätsanforderungen unterliegen und deren GCP-Infrastruktur außerhalb Ihres Vertrauensbereichs liegt, oder für Workloads, bei denen Google als potenzieller Zugriffspunkt in Ihrem Bedrohungsmodell enthalten ist. Der operative Aufwand besteht darin, dass jeder Ver- und Entschlüsselungsvorgang eine latenzarme und hochverfügbare Verbindung zu Ihrem externen Schlüsselverwaltungssystem (KMS) erfordert. Jeder Ausfall Ihres externen KMS führt dazu, dass die GCP-Ressourcen, die diesen Schlüssel verwenden, nicht mehr erreichbar sind. Encryption Consulting bietet mit HSM as a Service die externe FIPS 140-2 Level 3-konforme Schlüsselverwaltungsinfrastruktur, die für Cloud EKM-basierte HYOK-Implementierungen benötigt wird.

Abmessungen	Natives Cloud-HSM (von Google generiert)	BYOK (Importauftrag)	HYOK (Cloud EKM)
Schlüssel generiert von	Cloud-HSM-Cluster	Kunden-HSM (importiert in Cloud-HSM)	Kunde (tritt nie auf GCP auf)
FIPS 140-2 Stufe 3	Ja	Ja (importiertes Material im HSM gelagert)	Abhängig von externem KMS
GCP-Zugriff auf den Schlüssel während der Nutzung	Ja (innerhalb der HSM-Grenze)	Ja (innerhalb der HSM-Grenze)	Nein
GCP kann Daten entschlüsseln, wenn es dazu gezwungen wird.	Ja	Ja (solange sich der Schlüssel im Cloud KMS befindet).	Nein
Unabhängiger Widerruf	Schlüssel über die API deaktivieren oder löschen	Importiertes Material sofort löschen	Widerruf bei externem KMS
Automatische Schlüsseldrehung	Ja	Nein (manueller Reimport erforderlich)	Verwaltet durch ein externes KMS
Operative Komplexität	Niedrig	Medium	Hoch
Zusätzliche Kosten	2.50 $/Key-Version/Monat	2.50 $/Schlüsselversion/Monat + HSM-Kosten	0.04 $/10 Operationen + externe KMS-Kosten
Am besten geeignet,	Die meisten regulierten GCP-Workloads	Arbeitslasten, die die Herkunft von Kundenschlüsseln erfordern	Souveränitätsauflagen, Zero-Trust-Umgebungen

IAM-Modell für die Google Cloud HSM-Zugriffskontrolle

Die Zugriffskontrolle für Cloud-HSM-Operationen wird über Google Cloud IAM, Cloud KMS-Schlüsselressourcenrichtlinien und organisatorische Richtlinienbeschränkungen verwaltet. Das IAM-Modell für Cloud-HSM trennt drei operative Rollen, die sich nicht überschneiden dürfen.

Schlüsseladministrator (cloudkms.admin): Erstellt Schlüsselringe und Schlüssel, verwaltet Schlüsselversionen, konfiguriert Schlüsselrotationspläne, aktiviert und deaktiviert Schlüsselversionen und plant deren Löschung. Die Rolle des Schlüsseladministrators darf keinem Anwendungsdienstkonto oder keiner automatisierten Pipeline zugewiesen werden. Aktionen des Schlüsseladministrators werden in den Cloud-Audit-Protokollen als Administratoraktivitätsereignisse protokolliert, die nicht deaktiviert werden können.

Schlüsseloperator oder Krypto-Benutzer (cloudkms.cryptoKeyEncrypterDecrypter): Verwendet den Cloud-HSM-geschützten Schlüssel für Verschlüsselungs- und Entschlüsselungsvorgänge. Diese Rolle wird Anwendungsdienstkonten zugewiesen, die Daten mithilfe des HSM-Schlüssels verschlüsseln oder entschlüsseln müssen. Detailliertere Aufteilung: cloudkms.cryptoKeyEncrypter gewährt ausschließlich Verschlüsselung, cloudkms.cryptoKeyDecrypter Gewährt ausschließlich Entschlüsselungsrechte. Es gilt stets das Prinzip der minimalen Berechtigungen: Ein Dienst, der verschlüsselte Daten schreibt, benötigt die Berechtigung „Verschlüsseln“; ein Dienst, der verschlüsselte Daten liest, benötigt die Berechtigung „Entschlüsseln“; nur Dienste, die beides tun, benötigen die Berechtigung „Verschlüsseln/Entschlüsseln“.

Schlüsselanzeige (cloudkms.viewer): Zeigt Metadaten des Schlüssels an (Schutzstufe, Rotationsplan, Schlüsselstatus, Erstellungsdatum), ermöglicht aber keine kryptografischen Operationen mit dem Schlüssel und keine Verwaltung seines Lebenszyklus. Geeignet für Sicherheitsaudits, Überwachung und Compliance-Prüfungen, die Einblick in die Schlüsselkonfiguration benötigen, ohne operativen Zugriff zu haben.

Organisationspolitische Einschränkungen: Der GCP Organization Policy Service ermöglicht es Ihnen, Einschränkungen auf Organisations-, Ordner- oder Projektebene durchzusetzen, die für alle Cloud KMS-Schlüssel im Geltungsbereich gelten. Zu den wichtigsten Einschränkungen gehören: constraints/cloudkms.allowedProtectionLevels (durchsetzen, dass alle Schlüssel in bestimmten Projekten die HSM-Schutzstufe verwenden müssen), constraints/gcp.resourceLocations (Durchsetzung, dass Schlüsselringe nur in bestimmten Regionen für die Datenspeicherung erstellt werden können) und Deaktivierung des Imports und Exports von Schlüsselmaterial auf Organisationsebene. Diese Einschränkungen bilden eine zusätzliche Richtlinienebene über den individuellen IAM-Berechtigungen, ähnlich den AWS-Servicekontrollrichtlinien.

Schlüsselrotation für Cloud-HSM-Schlüssel

Cloud KMS unterstützt die automatische Schlüsselrotation für HSM-geschützte Schlüssel. Wenn Sie die automatische Rotation für einen Cloud-KMS-Schlüssel aktivieren, generiert Cloud KMS gemäß dem konfigurierten Zeitplan eine neue HSM-basierte Schlüsselversion. Diese neue Version wird zur primären Version und für alle neuen Verschlüsselungsvorgänge verwendet. Vorherige Versionen bleiben aktiviert und werden weiterhin zur Entschlüsselung von Daten verwendet, die mit diesen Versionen verschlüsselt wurden. Der Ressourcenname des Schlüssels bleibt unverändert; die Rotation erfolgt transparent für Anwendungen.

Die Rotationsintervalle für Schlüssel sind konfigurierbar und betragen für die meisten Anwendungen mit symmetrischen Schlüsseln mindestens 24 Stunden. Für Umgebungen mit hohen Compliance-Anforderungen wird ein Rotationsintervall von 90 Tagen empfohlen (entsprechend der PCI-DSS-Anforderung 3.7.4 zu Kryptoperioden) oder jährlich für standardmäßige regulierte Workloads. Bei jeder Rotation wird eine neue, FIPS 140-2 Level 3 HSM-konforme Schlüsselversion generiert und ein entsprechendes Ereignis in den Cloud-Audit-Logs protokolliert.

Für importiertes BYOK-Schlüsselmaterial ist keine automatische Rotation verfügbar, da Cloud KMS keine neuen Versionen extern generierter Schlüssel erstellen kann. Sie müssen die BYOK-Rotation manuell verwalten: Generieren Sie neues Schlüsselmaterial in Ihrem externen HSM, erstellen Sie einen neuen Importauftrag für den Schlüssel, importieren Sie das neue Material als neue Schlüsselversion und legen Sie diese als primären Schlüssel fest. Dieser manuelle Prozess muss innerhalb Ihres definierten Kryptoperiodenbereichs geplant und ausgeführt werden, um die Compliance zu gewährleisten.

Die Löschung einer Schlüsselversion erfolgt nach einer obligatorischen 24-stündigen Frist (konfigurierbar bis zu 120 Tage). Innerhalb dieser Frist kann die Löschung abgebrochen werden. Nach Ablauf der Frist werden die Schlüsselversion und alle zugehörigen Daten endgültig gelöscht und können nicht wiederhergestellt werden. Die geplante Löschung einer HSM-Schlüsselversion generiert umgehend ein Ereignis im Cloud-Audit-Log (Administratoraktivität), sodass Sicherheitsteams versehentliche oder unautorisierte Löschungen erkennen und gegebenenfalls abbrechen können.

Cloud-Audit-Protokolle für Cloud-HSM-Operationen

Jeder Cloud-KMS- und Cloud-HSM-Vorgang erzeugt einen Eintrag im Cloud-Audit-Log. GCP Cloud-Audit-Logs sind der primäre Prüfpfad für alle Schlüsselverwaltungs- und kryptografischen Operationen auf GCP und stellen eine Compliance-Anforderung gemäß PCI DSS Requirement 10, dem HIPAA-Audit-Control-Standard (45 CFR 164.312(b)) und den FedRAMP AU-Kontrollen dar.

Administrator-Aktivitätsprotokolle (immer aktiviert, nicht deaktivierbar): Erfassung der Schlüsselerstellung, der Schlüsselversionserstellung, von Schlüsselversionsstatusänderungen (Aktivierung, Deaktivierung, geplante Löschung, Wiederherstellung), von Schlüsselrichtlinienaktualisierungen (IAM-Bindungsänderungen) sowie der Erstellung und des Abschlusses von Importaufträgen. Diese Protokolle werden permanent geschrieben und können von keinem Benutzer, auch nicht von Projektinhabern, deaktiviert werden.

Datenzugriffsprotokolle (explizit aktiviert): Erfassen kryptografische Operationen: Verschlüsseln, Entschlüsseln, Asymmetrisches Signieren, Asymmetrisches Entschlüsseln, MacSignieren, MacVerifizieren. Datenzugriffsprotokolle müssen für Cloud KMS explizit auf Projekt- oder Organisationsebene aktiviert werden. Nach der Aktivierung protokolliert jeder Verschlüsselungs- und Entschlüsselungsaufruf das anfragende Dienstkonto, den ARN der Schlüsselversion, den Zeitstempel und die aufrufende IP-Adresse oder das Dienstnetzwerk. Für regulierte Workloads ist die Aktivierung der Datenzugriffs-Audit-Protokolle für Cloud KMS obligatorisch.

Leiten Sie Cloud-Audit-Logs an Cloud Logging (Standardeinstellung) weiter und exportieren Sie sie zusätzlich zur Langzeitarchivierung in Cloud Storage (PCI DSS erfordert eine Aufbewahrungsdauer von 12 Monaten, davon sind 3 Monate sofort verfügbar). Konfigurieren Sie in Cloud Monitoring protokollbasierte Warnungen für folgende Ereignisse: geplante Löschung von Produktionsschlüsseln (sofortige Warnung); Änderungen an IAM-Bindungen in einem Cloud-KMS-Schlüsselring oder -Schlüssel; Entschlüsselungsvorgänge von Dienstkonten, die nicht in der Liste der für diesen Schlüssel zugelassenen Konten enthalten sind; und Verschlüsselungs- oder Entschlüsselungsvorgänge, die von einem unerwarteten Quellnetzwerk ausgehen.

Google Cloud HSM-Preise

Die Preisgestaltung von Cloud-HSM besteht aus zwei Komponenten: der Speicherung der Schlüsselversionen und den Aufrufen kryptografischer Operationen.

Speicherung von Schlüsselversionen: HSM-geschützte Schlüsselversionen kosten 2.50 $ pro aktiver Schlüsselversion und Monat. Softwaregeschützte Schlüsselversionen kosten 0.06 $ pro aktiver Schlüsselversion und Monat. Der Preisunterschied deckt die Kosten der dedizierten HSM-Hardwareinfrastruktur ab. Schlüsselversionen im Status „Zur Löschung vorgesehen“ oder „Zerstört“ werden nicht berechnet.

Kryptografische Operationen: Symmetrische Ver- und Entschlüsselungsvorgänge mit HSM-geschützten Schlüsseln kosten 0.03 US-Dollar pro 10,000 Operationen, genau wie bei softwaregeschützten Schlüsseln. Asymmetrische Signier- und Entschlüsselungsvorgänge kosten je nach Schlüsseltyp und Algorithmus zwischen 0.03 und 0.15 US-Dollar pro 10,000 Operationen. Cloud-EKM-Operationen (für HYOK) verursachen zusätzlich zu den Gebühren des externen KMS weitere 0.04 US-Dollar pro 10,000 Operationen.

Kostenoptimierung: Cloud KMS bietet keine vergleichbare Funktion wie AWS KMS mit dem S3-Bucket-Schlüssel zur Reduzierung der API-Aufrufkosten. Bei umfangreichen GCP-Workloads mit Cloud Storage, BigQuery oder anderen Diensten, die KMS-Aufrufe pro Objekt erfordern, empfiehlt sich die Zwischenspeicherung des Datenverschlüsselungsschlüssels (DEK) auf Anwendungsebene, sofern Ihre Sicherheitsrichtlinie dies zulässt. DEK-Caching bedeutet, dass die Anwendung den Klartext-DEK einmal pro Sitzung oder Zeitfenster von Cloud KMS abruft und ihn lokal für mehrere Verschlüsselungs-/Entschlüsselungsvorgänge verwendet. Dadurch wird das Volumen der Cloud-KMS-API-Aufrufe deutlich reduziert. Der Nachteil besteht darin, dass der Klartext-DEK für die Dauer des Cache-Fensters im Arbeitsspeicher der Anwendung gespeichert wird.

Cloud-HSM in Multi-Cloud- und Hybridarchitekturen

Cloud HSM ist ein GCP-nativer Dienst, der auf die GCP-Infrastruktur beschränkt ist. Organisationen, die sowohl GCP als auch andere Cloud-Anbieter oder On-Premise-Umgebungen nutzen, benötigen eine explizite Strategie für eine einheitliche Schlüsselverwaltung über die gesamte Infrastruktur hinweg. Drei Ansätze bieten hierfür Lösungen:

• Cloud-natives HSM mit einheitlicher Governance: Nutzen Sie Cloud HSM für GCP-Workloads, AWS CloudHSM für AWS-Workloads und Azure Dedicated HSM für Azure-Workloads. Implementieren Sie jedoch eine zentrale Plattform für das Schlüssellebenszyklusmanagement, die Schlüsselbestand, Rotationsstatus, Compliance-Status und Audit-Logs über alle drei Plattformen hinweg aggregiert. Dadurch bleiben die native Cloud-Performance und die FIPS-Level-3-Validierung in jeder Cloud erhalten, während gleichzeitig cloudübergreifende Transparenz für die Erfassung von Compliance-Nachweisen gewährleistet wird.
• Zentralisierte BYOK-Steuerung von einem externen HSM: Generieren Sie sämtliche Schlüsselmaterialien von einem einzigen externen HSM oder HSM-as-a-Service, der unabhängig von allen Cloud-Anbietern ist. Importieren Sie abgeleitete Schlüssel als BYOK-Schlüssel (mit HSM-Schutzstufe) in Cloud KMS für GCP-Workloads, in AWS KMS für AWS-Workloads und in Azure Key Vault für Azure-Workloads. Die gesamte Verschlüsselung über alle Clouds hinweg lässt sich auf eine einzige autoritative Schlüsselquelle mit einem einzigen Widerrufspunkt zurückführen. (Encryption Consulting) HSM als Service bietet die externe FIPS 140-2 Level 3 HSM-Infrastruktur für dieses Modell, die gleichzeitig von GCP, AWS und Azure aus zugänglich ist.
• Cloud-EKM mit einem gemeinsamen externen Schlüssel (HYOK über alle Clouds hinweg): Nutzen Sie GCP Cloud EKM für GCP-Workloads und entsprechende externe Schlüsselreferenzen in AWS und Azure. Alle Clouds greifen dabei auf dasselbe externe Schlüsselverwaltungssystem (KMS) zu. GCP, AWS und Azure speichern jeweils nur den Chiffretext; das externe KMS verwaltet die Schlüssel und führt alle Entschlüsselungsvorgänge durch. Dies ist das stärkste Cloud-übergreifende Souveränitätsmodell, erfordert jedoch eine hohe Verfügbarkeit des externen KMS für alle Cloud-Workloads.

Konformität: PCI DSS, FedRAMP, HIPAA und eIDAS

PCI DSS v4.0.1 (verpflichtend ab 31. März 2025): Cloud HSM erfüllt Anforderung 3.7.1 (Schlüsselgenerierung mittels HSM oder anderer branchenüblicher Technologie), wenn die Schlüssel zum Schutz von Karteninhaberdaten mit HSM-Schutzstufe erstellt werden. Cloud-Audit-Logs für Cloud-KMS-Datenzugriffsereignisse erfüllen Anforderung 10 (Protokollierung und Überwachung). Die Schlüsselrotationspläne von Cloud KMS unterstützen Anforderung 3.7.4 (periodische Schlüsselrotation). Die PCI-DSS-zertifizierte Infrastruktur von GCP (Google Cloud ist auf der PCI-SSC-Website als Level-1-Dienstleister gelistet) deckt die Cloud-HSM-Infrastrukturschicht ab; der Kunde bleibt für die IAM-Konfiguration, die Schlüsselrichtlinie und die Kontrollen auf Anwendungsebene verantwortlich.

FedRAMP: Cloud-HSM-geschützte Schlüssel erfüllen die FedRAMP-High-Anforderungen an FIPS 140-2 Level 3-validierte kryptografische Module gemäß SC-12 (Kryptografische Schlüsselerzeugung und -verwaltung) und SC-28 (Schutz ruhender Informationen). Google Cloud-Dienste, einschließlich Cloud KMS und Cloud HSM, sind gemäß FedRAMP High autorisiert. Standardmäßige Cloud-KMS-Software-geschützte Schlüssel (Level 1) erfüllen die FedRAMP-High-Anforderungen der Stufe 3 nicht; für FedRAMP-High-Daten ist ein HSM-Schutz erforderlich.

HIPAA: Cloud HSM erfüllt die technischen Sicherheitsvorkehrungen gemäß HIPAA für die Verschlüsselung und Entschlüsselung (45 CFR 164.312(a)(2)(iv)) von ruhenden elektronischen Gesundheitsdaten (ePHI), wenn GCP-Dienste, die ePHI verschlüsseln, Cloud-HSM-geschützte Schlüssel verwenden. Die Vereinbarung zur Auftragsverarbeitung (Business Associate Agreement, BAA) von Google deckt Cloud KMS und Cloud HSM ab und berechtigt sie somit zur Verarbeitung von ePHI-Daten. Die Datenzugriffsereignisse der Cloud-Audit-Protokolle für Cloud KMS erfüllen den HIPAA-Audit-Control-Standard (45 CFR 164.312(b)).

eIDAS (EU): Qualifizierte elektronische Signaturen gemäß eIDAS erfordern qualifizierte Signaturerstellungsgeräte (QSCDs), die mindestens FIPS 140-2 Level 3 oder Common Criteria EAL4+ erfüllen. Die FIPS 140-2 Level 3-Validierung von Cloud HSM ist mit dieser Anforderung an die HSM-Schutzgrenze kompatibel. EU-Organisationen, die qualifizierte Signaturen oder qualifizierte Siegel auf GCP implementieren, sollten sicherstellen, dass die verwendete GCP-Region Cloud HSM bereitstellt und die Gesamtarchitektur die Anforderungen ihrer nationalen Aufsichtsbehörde an die QSCD-Klassifizierung erfüllt.

Cloud-HSM vs. Cloud-KMS-Softwareschutz: Entscheidungshilfe

Verwenden Sie die folgenden Kriterien, um zu entscheiden, ob ein Schlüssel in Cloud KMS die HSM- oder die Software-Schutzebene verwenden soll.

Kriterium	Cloud-HSM verwenden (HSM-Schutzstufe)	Cloud-KMS-Software verwenden (Software-Schutzstufe)
FIPS 140-2 Level 3 erforderlich	Ja (FedRAMP High, einige PCI DSS, eIDAS)	Nein (Stufe 1 ausreichend)
Hardware-Attestierung erforderlich	Ja	Nein
Wichtiges Material muss in spezieller Hardware aufbewahrt werden.	Ja	Nein
Datentyp	ePHI, PAN, klassifiziert, reguliert	Allgemeine Arbeitslasten, interne Daten
Kostensensitivität	Höherer Preis (2.50 $/Key-Version/Monat)	Niedriger (0.06 $/Schlüsselversion/Monat)
BYOK-Anforderung	Unterstützt (über Cloud KMS Importaufträge)	Unterstützt (über Cloud KMS Importaufträge)
HYOK-Anforderung	Cloud EKM verwenden (der Schlüssel gelangt niemals in GCP)	Cloud EKM verwenden (der Schlüssel gelangt niemals in GCP)

Wie Verschlüsselungsberatung helfen kann

Encryption Consulting ist ein auf angewandte Kryptografie spezialisiertes Unternehmen mit Zertifizierungen nach ISO/IEC 27001:2022 und SOC 2. Wir unterstützen Organisationen bei der Konzeption, Implementierung und Prüfung von Google Cloud HSM-Konfigurationen für GCP-Workloads – von der ersten Architektur bis hin zur kontinuierlichen Erstellung von Compliance-Nachweisen.

• GCP-Schlüsselverwaltungsarchitektur: Wir entwerfen Ihre Cloud-KMS- und Cloud-HSM-Architektur, einschließlich der Auswahl des Schutzniveaus pro Schlüsseltyp, der Strategie für Schlüsselringe und deren Speicherort für die Datenresidenz, der IAM-Rollenstruktur mit Funktionstrennung, der Organisationsrichtlinien zur Durchsetzung der HSM-Schutzanforderungen, der BYOK-Import-Workflows und der Cloud-EKM-Integration für HYOK-Workloads. Siehe unsere Cloud-Datenschutzdienste.
• HSM als Service für Cloud EKM und BYOK: Für HYOK-Implementierungen mit Cloud EKM oder BYOK-Implementierungen, die eine FIPS 140-2 Level 3-Schlüsselgenerierung außerhalb von GCP erfordern, bietet Encryption Consulting die entsprechende Lösung an. HSM als Service Die externe HSM-Infrastruktur wird bereitgestellt. Schlüssel, die im HSM as a Service generiert werden, können über Importaufträge für BYOK in Cloud KMS importiert werden oder als externer Schlüssel dienen, auf den Cloud EKM für HYOK verweist, wodurch die Schutzgrenze gemäß FIPS 140-2 Level 3 außerhalb von GCP aufrechterhalten wird.
• CBOM Secure für GCP Key Discovery: GCP-Umgebungen mit vielen Projekten weisen häufig inkonsistente Schlüsselschutzniveaus über Cloud Storage-Buckets, BigQuery-Datasets, GKE-Cluster und Compute Engine-Festplatten hinweg auf. Encryption Consulting bietet hierfür Lösungen. CBOM Secure Erkennt und inventarisiert alle Cloud KMS-Schlüsselkonfigurationen, Schutzstufen, Rotationsstatus und IAM-Richtlinienbindungen in GCP-Projekten und generiert eine kryptografische Stückliste (CBOM) im CycloneDX-Format, die Schlüssel mit Softwareschutz, bei denen HSM erforderlich ist, Schlüssel ohne Rotationspläne und übermäßig permissive IAM-Bindungen identifiziert.
• PCI DSS- und FedRAMP-Konformitätshinweis: Wir ordnen Ihre Cloud-HSM-Konfiguration den spezifischen Anforderungen von PCI DSS v4.0.1 (Anforderungen 3.7.1, 3.7.4 und 10), FedRAMP High (SC-12, SC-28), den technischen Sicherheitsvorkehrungen von HIPAA und den eIDAS-QSCD-Anforderungen zu. Wir identifizieren Lücken, erstellen die erforderlichen Nachweise zur Konformität und unterstützen Sie bei Anfragen von QSA- und FedRAMP-Gutachtern. Weitere Informationen finden Sie hier. Compliance-Beratungsdienste.
• PQC-Bereitschaft für Cloud-HSM: 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. GCP Cloud HSM unterstützt derzeit die asymmetrischen Schlüssel RSA und ECDSA, die vor diesem Zeitpunkt auf Post-Quanten-Algorithmen migriert werden müssen. Googles Roadmap für die Post-Quanten-Bereitschaft von Cloud HSM und Cloud KMS wird stetig weiterentwickelt. (Encryption Consulting) PQC-Bereitschaft Der Service ordnet Ihren GCP-Schlüsselbestand dem Zeitplan der Post-Quantum-Migration zu und entwirft die Reihenfolge der Schlüsselrotation und des Algorithmusübergangs.

Um Ihre GCP Cloud HSM-Architektur oder Ihre Compliance-Anforderungen zu besprechen, wenden Sie sich an Encryption Consulting.

Fazit

Google Cloud HSM bietet hardwaregestützten Schlüsselschutz gemäß FIPS 140-2 Level 3 für GCP-Workloads über die Cloud KMS API. Bestehende Cloud KMS-Kunden müssen ihre Anwendungen nicht anpassen. Der HSM-Schutz ist die optimale Wahl für regulierte Workloads, die eine Hardware-Validierung der Stufe 3 erfordern: FedRAMP High, PCI DSS-Karteninhaberdaten, HIPAA ePHI und eIDAS-qualifizierte Signaturen. Für Workloads, die keine Stufe 3 benötigen, bieten softwaregeschützte Cloud KMS-Schlüssel eine vergleichbare API-Funktionalität zu deutlich geringeren Kosten.

Die wichtigsten operativen Entscheidungen für Cloud HSM betreffen die Auswahl des Schutzniveaus bei der Schlüsselerstellung (nachträglich nicht änderbar), die Gestaltung der IAM-Rollen mit Trennung von Schlüsseladministrator und Schlüsseloperator, die Aktivierung von Cloud-Audit-Logs-Datenzugriffsereignissen für Cloud KMS (standardmäßig deaktiviert), die Konfiguration des Rotationsplans sowie die Integration von BYOK oder Cloud EKM, falls regulatorische Anforderungen die Herkunft der Kundenschlüssel oder Zero-GCP-Zugriffssouveränität vorschreiben. Diese Aspekte bereits in der Architekturphase korrekt zu definieren, ist deutlich einfacher, als sie nachträglich in eine bestehende GCP-Umgebung zu integrieren, wenn im Rahmen einer Compliance-Prüfung Lücken aufgedeckt werden.

Häufig gestellte Fragen

Was ist Google Cloud HSM?

Google Cloud HSM ist ein verwalteter Cloud-Dienst, der nach FIPS 140-2 Level 3 validierte Hardware-Sicherheitsmodule als Schlüsselspeicher und Backend für kryptografische Operationen für Google Cloud KMS bereitstellt. Schlüssel, die mit dem HSM-Schutzniveau erstellt werden, werden innerhalb des HSM-Clusters generiert, alle kryptografischen Operationen werden innerhalb des HSM durchgeführt, und das Schlüsselmaterial verlässt das HSM-Netzwerk niemals im Klartext. Der Zugriff auf Cloud HSM erfolgt über dieselbe Cloud KMS-API wie auf softwaregeschützte Schlüssel; es sind keine Anwendungsänderungen erforderlich.

Welche FIPS-Validierungsstufe verwendet Google Cloud HSM?

Google Cloud HSM verwendet HSMs, die nach FIPS 140-2 Level 3 validiert sind. Dies erweitert die Anforderungen an manipulationssichere physische Sicherheit und identitätsbasierte Authentifizierung im Vergleich zu Level 2. Die HSM-Firmware wird vom Hardwarehersteller digital signiert; Google kann die HSM-Firmware weder erstellen noch verändern. Standardmäßige Cloud-KMS-Software-geschützte Schlüssel sind nach FIPS 140-2 Level 1 validiert. Für die hohen Sicherheitsanforderungen von FedRAMP High und PCI DSS sowie für eIDAS-qualifizierte Signaturen ist Level 3 erforderlich, wodurch Cloud HSM die korrekte Schutzstufe bietet.

Worin besteht der Unterschied zwischen Cloud-KMS-softwaregeschützten Schlüsseln und Cloud-HSM-Schlüsseln?

Softwaregeschützte Schlüssel werden gemäß FIPS 140-2 Level 1 validiert und in den kryptografischen Softwaremodulen von Cloud KMS generiert. HSM-geschützte Schlüssel werden gemäß FIPS 140-2 Level 3 validiert und innerhalb des HSM-Hardwareclusters generiert, wobei alle Operationen innerhalb der HSM-Grenzen ausgeführt werden. Die Cloud KMS-API ist für beide Varianten identisch; lediglich der bei der Schlüsselerstellung festgelegte Parameter `protection_level` unterscheidet sich. Der HSM-Schutz kostet 2.50 US-Dollar pro Schlüsselversion und Monat, der Software-Schutz hingegen nur 0.06 US-Dollar.

Unterstützt Google Cloud HSM BYOK?

Ja. Mit Cloud KMS Import Jobs können Sie Schlüsselmaterial in Ihrem eigenen HSM generieren und es mit HSM als Zielschutzebene in Cloud KMS importieren. Das importierte Material wird im Cloud HSM-Cluster gespeichert und verwendet. Cloud External Key Manager (Cloud EKM) unterstützt HYOK, wobei der Schlüssel niemals in GCP gelangt und alle kryptografischen Operationen Ihr externes Schlüsselverwaltungssystem zur Laufzeit aufrufen.

Wie funktioniert die Tastenrotation in Google Cloud HSM?

Cloud KMS unterstützt die automatische Schlüsselrotation für HSM-geschützte Schlüssel. Eine neue, vom HSM generierte Schlüsselversion wird gemäß dem konfigurierten Zeitplan erstellt (mindestens alle 24 Stunden; für Compliance-Workloads werden 90 Tage empfohlen). Die neue Version wird für neue Verschlüsselungen primär verwendet; vorherige Versionen bleiben für die Entschlüsselung erhalten. Der Ressourcenname des Schlüssels bleibt unverändert; die Rotation erfolgt transparent für Anwendungen. Für BYOK-Schlüssel mit importiertem Material ist die automatische Rotation nicht verfügbar; Sie müssen neues Schlüsselmaterial manuell als neue Version importieren.

Was kostet Google Cloud HSM?

HSM-geschützte Schlüsselversionen kosten 2.50 $ pro aktiver Schlüsselversion und Monat. Softwaregeschützte Schlüsselversionen kosten 0.06 $ pro Monat. Symmetrische kryptografische Operationen kosten 0.03 $ pro 10,000 Operationen für beide Schutzstufen. Asymmetrische Operationen kosten je nach Schlüsseltyp 0.03 $ bis 0.15 $ pro 10,000 Operationen. Cloud EKM (HYOK) kostet zusätzlich 0.04 $ pro 10,000 Operationen. Schlüsselversionen im Status „Zerstört“ werden nicht berechnet.