Diese Seite wurde von der Cloud Translation API übersetzt.

Cloud HSM-Architektur

Autoren: Adit Sinha, Il-Sung Lee

Danksagungen: David Hale

Letzte Aktualisierung: Juni 2021

Dieses Thema bietet eine Übersicht über die Cloud HSM-Architektur.

Einführung

Obwohl Google Cloud alle inaktiven Kundendaten verschlüsselt, müssen einige Kunden, insbesondere solche, die Konformitätsvorschriften erfüllen müssen, die Kontrolle über die für die Verschlüsselung ihrer Daten verwendeten Schlüssel behalten. Für diese Kunden bietet Google Cloud Cloud HSM, einen Dienst zum Schutz von Schlüsseln mit einem Hardwaresicherheitsmodul.

Mit Cloud HSM können Sie Verschlüsselungsschlüssel generieren und kryptografische Vorgänge in gemäß FIPS 140-2 Level 3 zertifizierten HSMs ausführen. Der Dienst ist vollständig verwaltet, sodass Sie vertrauliche Arbeitslasten schützen können, ohne einen HSM-Cluster verwalten zu müssen. Der Dienst bietet eine Reihe von Vorteilen:

Globale Verfügbarkeit
Eine einfache, konsistente und einheitliche API
Autoscaling nach Nutzung
Zentrale Verwaltung und Einhaltung gesetzlicher Vorschriften

Cloud HSM ist in jeder Google Cloud-Region weltweit verfügbar, einschließlich multiregionaler Regionen, die sich über größere Geografien erstrecken. Sobald Sie Cloud HSM aktiviert haben, können Sie HSM-gestützte Schlüssel zum Schutz Ihrer Daten erstellen und verwenden. Dies gilt auch für Daten, die Sie in anderen Google Cloud-Diensten wie BigQuery, Cloud Storage und Persistent Disk speichern.

Da Cloud HSM und die HSM-Hardware von Google verwaltet werden, sparen Sie sich die Komplexität und den Aufwand bei der Verwaltung und Verwendung von HSM-gestützten Schlüsseln in der Produktion, während Ihre Daten strikt von anderen Mandanten und Diensten in Google Cloud isoliert sind. Die Cloud HSM API für Datenebene, die Teil der Cloud Key Management Service API ist, bietet eine vereinfachte, intuitive Nutzung.

Cloud HSM unterstützt HSM-gestützte, vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK), wenn CMEK-Schlüssel in Google Cloud unterstützt werden. Beispielsweise können Sie Daten in Cloud Storage-Buckets oder Cloud SQL-Tabellen mit einem von Ihnen verwalteten Cloud HSM-Schlüssel verschlüsseln.

Cloud HSM wurde entwickelt, um die Einhaltung von gesetzlichen Vorschriften, geografischen Einschränkungen und anderen Geschäftsregeln zu gewährleisten. Im Abschnitt Sicherheit und Vorschriften wird beschrieben, wie Sie mit Cloud HSM die Compliance vorhandener Schlüssel prüfen, Schlüssel sicher in Cloud HSM importieren und die Schlüsselherkunft aufrechterhalten.

Schließlich wird im Abschnitt Anfrageabläufe die Abfolge der Ereignisse angezeigt, die im Hintergrund ablaufen, wenn Sie einen Cloud HSM-Schlüssel erstellen, den Schlüssel direkt verwenden und ihn einer CMEK-Integration verwenden.

Cloud HSM-Verwaltung

Innerhalb von Cloud HSM werden Cluster von HSMs von einem Team aus Site Reliability Engineers (SREs) sowie von Technikern an jedem Standort des Google Cloud-Rechenzentrums verwaltet. Google kümmert sich um die physische Sicherheit, logische Sicherheit, Infrastruktur, Kapazitätsplanung, Geoerweiterung und Notfallwiederherstellungsplanung in Rechenzentren.

Abstraktion von HSM-Hardware

In der Regel kommunizieren Anwendungen direkt mit HSMs über PKCS#11 und über eine API zur Clusterverwaltung. Dies erfordert, dass Sie speziellen Code für Arbeitslasten pflegen, die HSM-gestützte Schlüssel verwenden oder verwalten.

Bei Cloud HSM wird die Kommunikation mit dem HSM abstrahiert. Dazu werden Anfragen für HSM-gestützte Schlüssel über die Cloud Key Management Service API weitergeleitet. Die Abstraktion reduziert den Bedarf an HSM-spezifischem Code. Cloud HSM übernimmt die enge Integration von Cloud Key Management Service in Google Cloud.

Jede dieser Funktionen bietet erhebliche Sicherheitsvorteile. Die Cloud Key Management Service API reduziert die Bandbreite der verfügbaren HSM-Schnittstelle erheblich. So verringert sich das Risiko bei einer Kundensicherheitsverletzungen. Ein Angreifer kann beispielsweise keine vollständigen HSMs löschen. Versuche, einzelne Schlüssel zu löschen, werden innerhalb eines 24-Stunden-Sicherheitszeitraums behoben.

Durch die Einbindung von Cloud Key Management Service in Google Cloud können Sie den Zugriff auf HSM-Ressourcen mithilfe von Identity and Access Management (IAM) steuern. Als weit verbreiteter Mechanismus ist die IAM-Konfiguration weniger anfällig für Fehlkonfigurationen und Programmfehler als eine benutzerdefinierte HSM-Lösung.

Grafik: Cloud HSM-Architektur

Strikte geografische Trennung von Grund auf

In Cloud HSM können Sie Schlüssel global verfügbar machen oder strenge geografische Einschränkungen für Schlüssel erzwingen, die sie benötigen.

HSMs sind häufig in Partitionen unterteilt, sodass ein einzelnes physisches Gerät als mehrere logische Geräte arbeiten kann. Sie können Partitionen verwenden, um die Bereitstellungskosten zu reduzieren, wenn Sie die HSM-Verwaltung und -Schlüssel trennen müssen.

Jeder regionale Cloud HSM-Standort ist einem separaten Verpackungsschlüssel zugeordnet. Der Verpackungsschlüssel wird auf jede Partition in jedem HSM am Standort geklont, verlässt aber nie das HSM des Standorts. Dadurch können HSMs in derselben Region dieselben Kundenschlüssel bereitstellen. Außerdem wird sichergestellt, dass HSMs außerhalb der Region diese Schlüssel nicht bedienen können.

Cloud HSM erstellt auch Multiregionen über Verpackungsschlüssel. Alle Kundenschlüssel für eine Multiregion werden mit einem Verpackungsschlüssel in einer Partition an allen Standorten verpackt, die die Multiregion bilden. Der Dienst nutzt dieselbe Hardware für mehrere Regionen, bietet jedoch die gleiche starke Isolation zwischen Regionen und Multiregionen, die zwischen verschiedenen Regionen vorhanden sind.

Grafik: Cloud HSM-Geografie

Das Regionalisierungsschema hängt von der Replikation der Verpackungsschlüssel in die entsprechenden Partitionen ab. Jede Konfigurationsänderung muss von mehreren Mitgliedern des Cloud HSM-Teams genehmigt werden, bevor sie aktiv wird. Rechenzentrumstechniker können nicht auf eine HSM-Konfiguration, HSM-Laufzeit oder einen HSM-Speicher vor Ort zugreifen.

Zentrale Verwaltung

In einem traditionellen Rechenzentrum, in dem HSMs gehostet werden, ist die Verwaltung der HSMs und ihrer Ressourcen vollständig von der Verwaltung anderer kryptografischer Ressourcen getrennt. Cloud HSM ist eng in Google Cloud eingebunden, sodass Sie Ihre Cloud HSM-Ressourcen nahtlos verwalten können:

Sie verwalten Ihre HSM-gestützten Ressourcen zusammen mit Ihren anderen Schlüsseln in Cloud Key Management Service und extern verwalteten Schlüsseln im Cloud External Key Manager (Cloud EKM).
Sie verwalten den Zugriff auf HSM-gestützte Ressourcen in IAM.
Kostenberichte für kryptografische Vorgänge mit HSM-gestützten Schlüsseln werden in Cloud Billing gemeldet.
Sie können HSM-gestützte Schlüssel in allen Google Cloud-Diensten transparent verwenden, die das Verschlüsseln von Ressourcen mithilfe von vom Kunden verwalteten Verschlüsselungsschlüsseln (Customer-Managed Encryption Keys, CMEK) unterstützen. Bei CMEK-Integrationen müssen sich der CMEK-Schlüssel und die verschlüsselten Daten an kompatiblen geografischen Standorten befinden. Aufgrund der strengen geografischen Beschränkung der Cloud HSM-Schlüssel sind auch die gesamten Ver- und Entschlüsselungen der CMEK-Daten auch geografisch eingeschränkt.
Verwaltungsvorgänge für HSM-gestützte Ressourcen werden immer auf der API-Ebene in Cloud-Audit-Logs protokolliert. Sie können auch das Datenzugriffs-Logging aktivieren. Weitere Informationen finden Sie unter Audit-Logging-Informationen im Cloud Key Management Service.
Google arbeitet direkt mit dem HSM-Hersteller zusammen, um die Hardware und Software auf jedem HSM zu aktualisieren und Probleme in Echtzeit zu beheben. Im Falle eines Zero-Day-Exploits auf dem HSM kann Google betroffene Pfade für die betroffenen HSM-Cluster selektiv deaktivieren, bis der Exploit behoben ist.

Entwickler- und Nutzerfreundlichkeit

Da Google für die HSM-Verwaltung verantwortlich ist, bietet Cloud HSM Entwicklern und Endnutzern erhebliche Vorteile.

HSMs auf Google-Niveau

Wenn Sie sich auf Hardware verlassen, die lokal oder in Rechenzentren vorhanden ist, kann die Hardware einen Leistungsengpass verursachen oder zu einem Single Point of Failure werden. Cloud HSM ist so konzipiert, dass es äußerst unvorhersehbare Arbeitslasten und Hardwarefehler aufweist.

Alle Kundenschlüssel werden mit einem regionalen Verpackungsschlüssel in der KMS-Datenbank gespeichert und können nur von einem HSM in der Region entpackt werden als Teil eines kryptografischen Vorgangs. Dies hat mehrere Vorteile:

Die Langlebigkeit eines Schlüssels ist nicht an ein bestimmtes HSM oder eine Teilmenge von HSMs in einer Region gebunden.
Jeder Cloud HSM-Kunde nutzt die vollständige Skalierbarkeit und Verfügbarkeit der Cloud HSM-Cluster, die ihre Schlüssel bereitstellen.
Cloud HSM kann einen viel größeren Satz von Schlüsseln verarbeiten, die auf einem HSM gespeichert werden können.
Das Hinzufügen oder Ersetzen eines HSM ist schnell und sicher.

Einheitliches API-Design

Cloud HSM und Cloud Key Management Service haben eine gemeinsame API für Verwaltung und Datenebene. Die internen Details der Kommunikation mit einem HSM werden vom Aufrufer abstrahiert.

Daher sind keine Codeänderungen erforderlich, um eine vorhandene Anwendung zu aktualisieren, die Softwareschlüssel im Cloud Key Management Service verwendet, um HSM-gestützte Schlüssel zu unterstützen. Stattdessen aktualisieren Sie den Ressourcennamen des zu verwendenden Schlüssels.

Sicherheit und gesetzliche Vorschriften

Mit Cloud HSM können Sie die Compliance mit Vorschriften für Ihre Arbeitslasten in der Cloud erzwingen.

Attestierung von kryptografischem Schlüssel

Jedes Mal, wenn Sie einen Cloud HSM-Schlüssel generieren oder importieren, generiert das HSM eine Attestierungserklärung, die mit einem Signierschlüssel signiert ist, der der Partition zugeordnet ist. Die Anweisung enthält Informationen zu den Attributen Ihres Schlüssels. Der Signierschlüssel wird durch Zertifikatsketten gesichert, die sowohl in Google als auch im HSM-Hersteller gerootet sind. Sie können die Attestierungserklärung und die Zertifikate herunterladen, um die Authentizität der Anweisung zu prüfen und die Attribute des Schlüssels und des HSM zu validieren, das ihn erzeugt oder importiert hat.

Mit der Zertifikatskette können Sie Folgendes prüfen:

Die HSM-Hardware und -Firmware sind echt.
Die HSM-Partition und HSM werden von Google verwaltet.
Das HSM befindet sich im FIPS-Modus.

Mit dem Inhalt der Attestierungserklärung können Sie Folgendes prüfen:

Der Schlüssel kann nicht extrahiert werden.
Der Schlüssel wurde für Ihre CryptoKeyVersion generiert.
Der öffentliche Schlüssel in einem asymmetrischen Schlüsselpaar entspricht einem privaten HSM-gestützten Schlüssel.
Das Schlüsselmaterial eines importierten symmetrischen Schlüssels entspricht dem verpackten Wert.

Sicherer Schlüsselimport direkt in HSMs

Sie können vorhandene Schlüssel sicher in Cloud HSM importieren, um eine Sicherung Ihres Schlüsselmaterials außerhalb von Google Cloud zu verwalten oder bestimmte Arbeitslasten zu Google Cloud zu migrieren. Der Schlüsselimportprozess erlaubt Google keinen direkten Zugriff auf das entpackte Schlüsselmaterial. Cloud HSM stellt Ihnen eine Attestierungserklärung für den von HSM generierten Verpackungsschlüssel zur Verfügung, um zu prüfen, ob ein Zugriff aufgetreten ist.

Der Schlüsselimport erhöht das Sicherheits- und Compliance-Risiko, da Nutzer Schlüssel aus unbekannten Quellen importieren können. Mithilfe separater Cloud IAM-Rollen können Sie jedoch genau steuern, wer Schlüssel in ein Projekt importieren kann. Importierte Schlüssel können durch die Attestierungserklärung unterschieden werden, die das HSM beim Import generiert.

Weitere Informationen finden Sie unter Schlüssel in den Cloud Key Management Service importieren.

Strikte Sicherheitsverfahren schützen die HSM-Hardware

Gemäß FIPS 140-2 Level 3 haben HSM-Geräte integrierte Mechanismen, um die physische Manipulation zu schützen und Beweise zu liefern.

Zusätzlich zu den Zusicherungen, die von der HSM-Hardware selbst bereitgestellt werden, wird die Infrastruktur für Cloud HSM gemäß dem Sicherheitsdesign der Infrastruktur von Google verwaltet.

Dokumentierte, überprüfbare Verfahren schützen die Integrität jedes HSM während der Nutzerverwaltung, Bereitstellung und in der Produktion:

Alle HSM-Konfigurationen müssen von mehreren Cloud HSM-Site-Reliability Engineers (SREs) geprüft werden, bevor das HSM in einem Rechenzentrum bereitgestellt werden kann.
Nach der Inbetriebnahme eines HSM kann die Konfigurationsänderung nur von mehreren Cloud HSM-SREs initiiert und geprüft werden.
Ein HSM kann nur Firmware empfangen, die vom HSM-Hersteller signiert ist.
HSM-Hardware ist nicht direkt mit einem Netzwerk verbunden.
Server, auf denen HSM-Hardware gehostet wird, können keine nicht autorisierten Prozesse ausführen.

Dienst- und Mandantenisolation

Die Cloud HSM-Architektur stellt sicher, dass HSMs vor böswilligen oder versehentlichen Störungen durch andere Dienste oder Mandanten geschützt sind.

Ein HSM, das Teil dieser Architektur ist, akzeptiert nur Anfragen von Cloud HSM und der Cloud HSM-Dienst akzeptiert nur Anfragen vom Cloud Key Management Service. Cloud Key Management Service erzwingt, dass Aufrufer die entsprechenden IAM-Berechtigungen für die Schlüssel haben, die sie verwenden möchten. Nicht autorisierte Anfragen erreichen keine HSMs.

HSM-gestützte Schlüssel unterliegen auch Kontingenten für kryptografische Vorgänge. Diese Kontingente schützen Ihre Fähigkeit, Ihre Arbeitslasten auszuführen, da unbeabsichtigte oder böswillige Versuche einer Überlastung des Dienstes verhindert werden. Die Standardkontingente, 3.000 QPM für asymmetrische kryptografische Vorgänge und 30.000 QPM für symmetrische kryptografische Vorgänge basieren auf beobachteten Nutzungsmustern. Die Kontingente liegen deutlich unter der Dienstkapazität und können auf Anfrage erhöht werden.

Anfrageabläufe

In diesem Abschnitt wird gezeigt, wie die oben dargestellten Architekturarbeiten in der Praxis durch die Schritte für verschiedene Anfragetypen umgesetzt werden. Diese Abläufe hervorheben die Cloud HSM-spezifischen Teile. Weitere Informationen zu den allgemeinen Schritten für alle Schlüssel finden Sie im Whitepaper Cloud Key Management Service.

Schlüssel erstellen

Wenn Sie einen HSM-gestützten Schlüssel erstellen, erstellt die Cloud Key Management Service API das Schlüsselmaterial nicht, sondern fordert das HSM zum Erstellen des Schlüssels an.

Ein HSM kann Schlüssel nur an Standorten erstellen, die es unterstützt. Jede Partition auf einem HSM enthält einen Verpackungsschlüssel, der dem Speicherort eines Cloud Key Management Service entspricht. Der Verpackungsschlüssel wird von allen Partitionen gemeinsam genutzt, die den Standort des Cloud Key Management Service unterstützen. So sieht der Schlüsselerstellungsprozess aus:

Der Google Front End Service (GFE) leitet die Anfrage zur Schlüsselerstellung an einen Cloud Key Management Service-Server an dem Standort weiter, der der Anfrage entspricht.
Die Cloud Key Management Service API prüft die Identität des Aufrufers und die Berechtigung des Anrufers, Schlüssel im Projekt zu erstellen. Außerdem muss der Aufrufer ein ausreichendes Kontingent für Schreibanfragen haben.
Die Cloud Key Management Service API leitet die Anfrage an Cloud HSM weiter.
Cloud HSM verbindet sich direkt mit dem HSM. Das HSM:
1. Erstellt den Schlüssel und verpackt ihn mit dem standortspezifischen Verpackungsschlüssel.
2. Erstellt die Attestierungserklärung für den Schlüssel und signiert sie mit dem Partitionssignaturschlüssel.
Nachdem Cloud HSM den verpackten Schlüssel und die Attestierung an den Cloud Key Management Service zurückgibt, verpackt die Cloud Key Management Service API den mit HSM verpackten Schlüssel gemäß der Schlüsselhierarchie des Cloud Key Management Service und schreibt ihn in das Projekt.

Dieses Design stellt sicher, dass der Schlüssel nicht außerhalb eines HSM entpackt oder verwendet werden kann, nicht aus dem HSM extrahiert werden kann und nur im entpackten Zustand an den von Ihnen gewünschten Speicherorten vorhanden ist.

Das folgende Diagramm zeigt die Unterschiede beim Erstellen von Cloud HSM-Schlüsseln und Softwareschlüsseln im Cloud Key Management Service.

Diagramm: HSM-Schlüsselerstellung

Kryptografische Vorgänge

Wenn Sie einen kryptografischen Vorgang im Cloud Key Management Service ausführen, müssen Sie nicht wissen, ob Sie einen HSM-gestützten oder Softwareschlüssel verwenden. Wenn die Cloud Key Management Service API feststellt, dass ein Vorgang einen HSM-gestützten Schlüssel umfasst, leitet er die Anfrage an ein HSM am selben Standort weiter.

Das GFE leitet die Anfrage an den entsprechenden Standort an einen Cloud Key Management Service-Server weiter. Die Cloud Key Management Service API verifiziert die Identität des Aufrufers, die Berechtigung des Aufrufers für den Zugriff auf den Schlüssel und die Ausführung des Vorgangs und das Kontingent des Projekts für kryptografische Vorgänge.
Die Cloud Key Management Service API ruft den verpackten Schlüssel aus dem Datenspeicher ab und entschlüsselt eine Ebene der Verschlüsselung mithilfe des Masterschlüssels des Cloud Key Management Service. Der Schlüssel ist weiterhin mit dem HSM-Verpackungsschlüssel für den KMS-Standort verpackt.
Die Cloud Key Management Service API erkennt, dass das Schutzlevel HSM ist, und sendet den teilweise entpackten Schlüssel zusammen mit den Eingaben an den kryptografischen Vorgang an Cloud HSM.
Cloud HSM verbindet sich direkt mit dem HSM. Das HSM:
1. Prüft, ob der verpackte Schlüssel und seine Attribute nicht geändert wurden.
2. Entpackt den Schlüssel und lädt ihn in seinen Speicher.
3. Führt den kryptografischen Vorgang aus und gibt das Ergebnis zurück.
Die Cloud Key Management Service API übergibt das Ergebnis an den Aufrufer.

Kryptografische Vorgänge mit HSM-gestützten Schlüsseln werden vollständig innerhalb eines HSM am konfigurierten Standort ausgeführt und nur das Ergebnis ist für den Aufrufer sichtbar.

Dieses Diagramm zeigt den Unterschied zwischen dem Erstellen von Cloud HSM-Schlüsseln und Softwareschlüsseln in Cloud Key Management Service.

Diagramm: HSM-Verschlüsselungsvorgänge

CMEK-Integrationen

Mit CMEK und Cloud HSM können Sie Ihre Daten in ausgewählten Google Cloud-Diensten mit HSM-Schlüsseln schützen. Wenn Sie einen CMEK-fähigen Dienst für die Verwendung von Cloud HSM-Schlüsseln konfigurieren möchten, müssen Sie nur einen Schlüssel mit einem HSM-Schutzlevel auswählen, wenn Sie der dienstspezifischen Anleitung folgen.

Wenn ein Aufrufer Daten in einen CMEK-fähigen Dienst liest oder schreibt, benötigt er weder eine direkte Berechtigung zur Verwendung des Schlüssels noch muss er wissen, ob der Schlüssel in einem HSM gespeichert ist.

Der Ablauf für einen CMEK-Vorgang ähnelt sehr dem für einen normalen kryptografischen Vorgang mit den folgenden Ausnahmen:

Die Anfrage vom CMEK-fähigen Dienst wird im Google-Netzwerk initiiert und muss das GFE nicht durchlaufen.
Die Cloud Key Management Service API prüft, ob das Dienstkonto für den CMEK-fähigen Dienst die erforderlichen Berechtigungen zur Verwendung des Schlüssels hat. Die Cloud Key Management Service API validiert keine Berechtigungen für den Endnutzer des CMEK-fähigen Dienstes.

Cloud HSM ist der Hardwareschlüsselverwaltungsdienst von Google Cloud. Es bietet eine Reihe unterschiedlicher Vorteile für Nutzer, die inaktive Daten mit HSM-Schlüsseln schützen möchten. Der Dienst wurde mit dem Prinzip des gesperrten API-Zugriffs auf die HSMs, einem mühelosen Skalierungsvorgang und einer engen Regionalisierung der Schlüssel entwickelt.

Cloud HSM bietet CMEK-Unterstützung für die wichtigsten Dienste und das Vorhandensein von Cloud HSM in jeder Google Cloud-Region (einschließlich Multiregionen und globaler Regionen). Der Dienst trägt dazu bei, Ihre sensiblen Daten überall einfach zu schützen, und zwar mit einem Schlüssel, der durch FIPS 140-2 Level 3-Geräte geschützt ist.

Wenn Sie diesen Artikel kommentieren möchten, kontaktieren Sie uns unter cloudhsm-feedback@google.com.

Weitere Informationen

Weitere Informationen finden Sie in den folgenden Ressourcen:

Whitepaper:

Sonstige Dokumentation: