Best Practices für Cloud HSM für Google Workspace

In diesem Dokument werden Best Practices für die Konfiguration von Cloud HSM für Google Workspace beschrieben, mit denen Sie Ihr Schlüsselmaterial vor versehentlichem oder unbefugtem Löschen und Zerstören schützen, eine hohe Verfügbarkeit und Langlebigkeit für kritische kryptografische Schlüssel gewährleisten und die Anforderungen von Vorschriften und Compliance erfüllen können.

Dieses Dokument richtet sich an Cloud-Architekten, Sicherheitsteams und Google Workspace-Administratoren, die für die Sicherheit und betriebliche Ausfallsicherheit der Verschlüsselungsschlüssel verantwortlich sind, die bei der clientseitigen Verschlüsselung (Client-Side Encryption, CSE) für Google Workspace verwendet werden. Es wird davon ausgegangen, dass Sie bereits mit Cloud HSM für Google Workspace vertraut sind und den Onboarding-Prozess abgeschlossen haben.

Verlust von Schlüsselmaterial verhindern

Sicherheitsrisiken können entstehen, wenn ein Hauptkonto eine Rolle innehat, die die Berechtigung zum Ausführen destruktiver Aktionen gewährt, insbesondere wenn diese außerhalb des üblichen Arbeitsbereichs des Hauptkontos liegen. Ein Nutzer mit einer zu weit gefassten Rolle „Projektinhaber“ (roles/owner) könnte beispielsweise das für die clientseitige Verschlüsselung von Google Workspace verwendete Schlüsselmaterial zerstören, wodurch die verschlüsselten Daten dauerhaft unzugänglich werden.

In den folgenden Abschnitten werden Praktiken beschrieben, mit denen das Risiko einer versehentlichen und böswilligen Zerstörung und Löschung von Schlüsseln verringert werden kann. Dazu werden Berechtigungen zum Zerstören oder Löschen des Cloud KMS-Schlüsselmaterials entfernt, das von der clientseitigen Verschlüsselung (CSE) von Google Workspace verwendet wird, und die Zerstörung von Schlüsseln eingeschränkt.

IAM-Ablehnungsrichtlinien auf Ordnerebene erzwingen

Mit IAM-Ablehnungsrichtlinien können Sie Hauptkonten Berechtigungen verweigern, auch wenn die Berechtigung anderweitig durch eine Rolle gewährt wird, die das Hauptkonto innehat. Auch wenn ein Nutzer die Rolle „Projektinhaber“ (roles/owner) hat, kann eine IAM-Ablehnungsrichtlinie auf Ordnerebene verhindern, dass er Schlüssel zerstört oder löscht. Wenn Sie Ihr Cloud HSM-Projekt in einen Ordner platzieren und eine Ablehnungsrichtlinie auf Ordnerebene anwenden, erstellen Sie eine Leitplanke, die die Zerstörung und Löschung von Schlüsseln verhindert, solange die Richtlinie erzwungen wird. Erzwungene Ablehnungsrichtlinien können nicht ohne eine Rolle wie „Administrator ablehnen“ (roles/iam.denyAdmin) für den Ordner aufgehoben werden.

Stellen Sie sicher, dass Ordnerverwaltungsrollen wie „Ordneradministrator“ (roles/resourcemanager.folderAdmin) und „Administrator ablehnen“ (roles/iam.denyAdmin) nur Hauptkonten gewährt werden, die nicht auch die Rolle „Cloud KMS-Administrator“ (roles/cloudkms.admin) für das Projekt haben, in dem sich Ihre Cloud HSM-Schlüssel befinden. Diese Aufteilung der Aufgaben sorgt dafür, dass kein einzelnes Hauptkonto Schlüssel verwalten und zerstören kann.

Legen Sie eine Ablehnungsrichtlinie basierend auf der folgenden Beispiel konfiguration fest:

displayName: Deny KMS key destruction and deletion
rules:
- description: "Denies destroy and delete permissions on Cloud KMS keys for all principals."
  denyRule:
    deniedPrincipals:
    - "principalSet://goog/public:all"
    deniedPermissions:
    - "cloudkms.googleapis.com/cryptoKeyVersions.destroy"
    - "cloudkms.googleapis.com/cryptoKeys.delete"

Weitere Informationen zu IAM-Ablehnungsrichtlinien finden Sie in der Übersicht zu IAM-Ablehnungsrichtlinien.

Einschränkungen für Organisationsrichtlinien für die Zerstörung von Schlüsseln erzwingen

Neben IAM können Sie Sicherheitsleitplanken auf Organisations- oder Ordnerebene mithilfe von Einschränkungen für Organisationsrichtlinien erzwingen. Diese Einschränkungen fungieren als harte Anforderungen, die einschränken, welche Arten von Ressourcen erstellt und wie sie konfiguriert werden können. Erzwungene Einschränkungen für Organisationsrichtlinien können nicht umgangen werden, auch nicht von Hauptkonten, die die erforderlichen Berechtigungen zum Ausführen der verbotenen Aktion haben. Erzwungene Einschränkungen für Organisationsrichtlinien können nicht ohne eine Rolle wie „Administrator für Organisationsrichtlinien“ (roles/orgpolicy.policyAdmin) für die Organisation aufgehoben werden.

  • Mindestdauer für das Löschen (constraints/cloudkms.minimumDestroyScheduledDuration): Erfordert eine Mindestdauer für das geplante Löschen (z. B. 90 oder 120 Tage) für alle Schlüssel in der Organisation oder Ressource, in der die Richtlinie aktiviert ist. Diese Einschränkung verhindert, dass Nutzer den Wiederherstellungszeitraum unter den konfigurierten Mindestwert verkürzen.
  • Vor dem Löschen deaktivieren (constraints/cloudkms.disableBeforeDestroy): Erfordert, dass sich eine Schlüsselversion im Status DISABLED befindet, bevor sie zum Löschen vorgemerkt werden kann. Diese Einschränkung fügt dem Workflow für das Löschen einen obligatorischen Schritt hinzu und erhöht die Sichtbarkeit der Aktion in Audit-Logs.

Weitere Informationen finden Sie unter Löschen der Schlüsselversion kontrollieren.

Zeitraum für das Löschen von Schlüsseln maximieren

Wenn eine Schlüsselversion zum Löschen vorgemerkt wird, beginnt ein Zeitraum für das „vorläufige Löschen“. Solange sich eine Schlüsselversion im Status Zum Löschen vorgemerkt befindet, können Sie den Schlüssel wiederherstellen, um das Löschen des Schlüssels abzubrechen. Wenn Sie diesen konfigurierbaren Zeitraum auf die maximale Länge von 120 Tagen festlegen, haben Sie ausreichend Zeit, eine Schlüsselversion wiederherzustellen, die versehentlich oder böswillig zum Löschen vorgemerkt wurde. Sie können diesen Wert nur beim Erstellen des Schlüssels festlegen.

Wenn Sie eine Schlüsselversion wiederherstellen, die zum Löschen vorgemerkt wurde, wird der Status der Schlüsselversion auf DISABLED gesetzt. Sie müssen die Schlüsselversion dann wieder aktivieren, um den Zugriff auf Ihre verschlüsselten Google Workspace-Daten wiederherzustellen.

Mit dem folgenden gcloud CLI-Befehl wird ein HSM-basierter Schlüssel mit einer geplanten Löschdauer von 120 Tagen erstellt:

gcloud kms keys create KEY_NAME \
    --location LOCATION \
    --keyring KEY_RING \
    --purpose encryption \
    --protection-level hsm \
    --destroy-scheduled-duration 120d

Ersetzen Sie Folgendes:

  • KEY_NAME: Der Name des Schlüssels.
  • LOCATION: Der Cloud KMS-Speicherort des Schlüsselbunds.
  • KEY_RING: Der Name des Schlüsselbunds, der den Schlüssel enthält.

Wenn Sie diese Dauer für alle Schlüssel in Ihrer Organisation erzwingen möchten, anstatt sie für jeden Schlüssel festzulegen, können Sie eine benutzerdefinierte Einschränkung für Organisationsrichtlinien definieren und erzwingen. Mit der folgenden Beispielbeschränkung können Nutzer nur dann einen Schlüssel erstellen, wenn die geplante Löschdauer zwischen 90 und 120 Tagen liegt:

name: organizations/ORGANIZATION_ID/customConstraints/custom.limitScheduledDestruction
resourceTypes:
- cloudkms.googleapis.com/CryptoKey
methodTypes:
- CREATE
condition: "resource.destroyScheduledDuration >= duration('7776000s') && resource.destroyScheduledDuration <= duration('10368000s')"
actionType: ALLOW
displayName: Require scheduled destruction duration between 90 and 120 days
description: Allows key creation only if the destroyScheduledDuration is between 90 and 120 days.

Ersetzen Sie ORGANIZATION_ID durch die numerische ID Ihrer Organisation.

Weitere Informationen zum Konfigurieren der geplanten Löschung Dauer finden Sie unter Schlüsselversionen löschen und wiederherstellen. Weitere Informationen zur Verwendung benutzerdefinierter Einschränkungen für Organisationsrichtlinien mit Cloud KMS finden Sie unter Benutzerdefinierte Einschränkungen für Organisationsrichtlinien für Cloud KMS erstellen.

Infrastruktur und Projekt schützen

Die zuvor in diesem Dokument beschriebenen Leitplanken konzentrieren sich auf die Verhinderung der Zerstörung und Löschung von Schlüsseln. Sie benötigen jedoch auch Leitplanken, um die Löschung des Schlüsselprojekts zu verhindern. Verwenden Sie die folgenden Leitplanken, um die Projektumgebung zu schützen, in der sich Ihre Google Workspace-Schlüssel befinden.

Projektsperren erzwingen

Eine Projektsperre verhindert, dass ein Projekt gelöscht wird. Auch ein Nutzer mit der Rolle „Projektinhaber“ (roles/owner) kann das Projekt nicht beenden, solange eine Sperre aktiv ist. Dies ist die effektivste Methode, um die versehentliche oder unbefugte Löschung des Projekts zu verhindern, in dem sich Ihre Google Workspace-Schlüssel befinden.

Weitere Informationen zu Projektsperren finden Sie unter Projekte mit Sperren schützen.

Wiederherstellungszeitraum für Projekte

Wenn ein Projekt erfolgreich gelöscht wurde, z. B. nachdem eine Projektsperre (Vorschau) entfernt wurde, beginnt der 30-tägige Wiederherstellungszeitraum. Während dieser Zeit kann ein Nutzer mit der Rolle „Project Owner“ (roles/owner) oder „Organisationsadministrator“ (roles/resourcemanager.organizationAdmin) das Projekt wiederherstellen. Nach 30 Tagen werden das Projekt und alle darin enthaltenen Schlüssel dauerhaft gelöscht.

Wir empfehlen, Projektsperren beizubehalten und den Wiederherstellungszeitraum nur als letztes Mittel zu verwenden.

Weitere Informationen zur Projektwiederherstellung finden Sie unter Gelöschtes Projekt wiederherstellen.

VPC Service Controls verwenden

VPC Service Controls ermöglicht Ihnen die Definition eines Sicherheits perimeters um Ihr Cloud HSM-Projekt. So wird sichergestellt, dass auf die Cloud KMS API nur über vertrauenswürdige Netzwerke oder bestimmte Identitäten zugegriffen werden kann. Dadurch wird das Risiko unbefugter administrativer Aktionen außerhalb Ihrer Unternehmenseinheit verringert.

Souveränität über Schlüsselmaterial mit importierten Schlüsseln (BYOK) gewährleisten

Für die meisten Organisationen empfehlen wir, dass Cloud HSM Schlüsselmaterial für Sie generiert und verwaltet.

Wenn Sie jedoch die Funktion „Bring your own key“ (BYOK) benötigen, können Sie Ihr Schlüsselmaterial lokal generieren und in Cloud HSM importieren. Mit diesem BYOK-Ansatz können Sie Anforderungen erfüllen, z. B. eine unabhängige, lokale Kopie Ihres Schlüsselmaterials aufzubewahren, um die Anforderungen an die Datenhoheit zu erfüllen oder sich von einem katastrophalen Verlust von Schlüsselmaterial zu erholen. Dieser Ansatz bietet Ihnen eine unabhängige Kopie des Schlüsselmaterials, das Sie neu importieren können, wenn die Schlüsselversion in Cloud KMS zerstört wird.

In dieselbe Version neu importieren

Mit Cloud KMS können Sie identisches Schlüsselmaterial in die zerstörte Schlüsselversion neu importieren, sodass die Ressourcen-ID und der URI mit der ursprünglich importierten Schlüsselversion übereinstimmen. So können Sie weiterhin dieselben Google Workspace-Konfigurationen verwenden. Wenn Sie eine Schlüsselversion neu importieren, die in einer Google Workspace-Konfiguration verwendet wird, wird der Datenzugriff wiederhergestellt, sobald der Import der Schlüsselversion abgeschlossen ist.

Weitere Informationen zum erneuten Importieren einer zerstörten Schlüsselversion, siehe Zerstörte Schlüsselversion neu importieren.

Erweiterter Schutz mit Cloud HSM für einzelne Mandanten

Für Kunden, die ein Höchstmaß an Isolation benötigen, bietet Cloud HSM für einzelne Mandanten dedizierte HSM-Partitionen. Ihre Cloud HSM-Instanz für einzelne Mandanten wird mithilfe der Quorum-Authentifizierung erstellt und verwaltet. Dazu ist die Genehmigung einer konfigurierten Mindestanzahl von Quorum-Mitgliedern vor kritischen Vorgängen wie dem Löschen der Cloud HSM-Instanz für einzelne Mandanten erforderlich. So wird verhindert, dass ein einzelnes kompromittiertes Konto Ihre Cloud HSM-Instanz für einzelne Mandanten zerstört. Die folgenden Praktiken gelten, wenn Sie Cloud HSM für einzelne Mandanten verwenden. Weitere Informationen finden Sie unter Quorum-basierte Authentifizierung.

Infrastruktur und Schlüssel über verschiedene Projekte hinweg trennen

Erstellen Sie die Cloud HSM-Instanz für einzelne Mandanten und Ihre Google Workspace-Schlüssel in separaten Projekten. Durch die Trennung der Ressourcenprojekte wird sichergestellt, dass ein Nutzer mit Administratorrollen für das Schlüsselprojekt keine Berechtigung für die zugrunde liegende Cloud HSM-Instanz für einzelne Mandanten hat. Diese Aufteilung der Aufgaben zwischen Infrastrukturverwaltung und Schlüsselverwaltung verringert das Risiko unbefugter Aktionen auf Infrastrukturebene.

Weitere Informationen zu Cloud HSM für einzelne Mandanten finden Sie in der Übersicht zu Cloud HSM für einzelne Mandanten.

Zusammenfassung der Best Practices

In der folgenden Tabelle sind die in diesem Dokument empfohlenen Best Practices zusammengefasst:

Thema Aufgabe
IAM-Ablehnungsrichtlinien Erzwingen Sie Ablehnungsrichtlinien auf Ordnerebene, um die Zerstörung und Löschung von Schlüsseln zu blockieren, auch für Nutzer mit hohen Berechtigungen.
Einschränkungen für Organisationsrichtlinien Erzwingen Sie Einschränkungen, um einen Mindestwiederherstellungszeitraum festzulegen und zu verlangen, dass Schlüssel deaktiviert werden, bevor sie zerstört werden können.
Zeitraum für das Löschen
  • Erstellen Sie Ihren Schlüssel mit dem Wert Zum Löschen vorgemerkt auf maximal 120 Tage. Alternativ können Sie eine kürzere Dauer auswählen, aber sie muss lang genug sein, damit Schlüssel wiederhergestellt werden können, wenn sie zum Löschen vorgemerkt werden.
  • Sie können eine benutzerdefinierte Einschränkung für Organisationsrichtlinien verwenden, um sicherzustellen, dass alle Schlüssel mit einer für Ihre Anforderungen geeigneten Dauer erstellt werden.
Projektsperren Erzwingen Sie Projektsperren, um die Löschung des Projekts zu verhindern, in dem sich Ihre Verschlüsselungsschlüssel befinden.
VPC Service Controls-Perimeter Definieren Sie einen VPC Service Controls-Perimeter, um den Zugriff auf die Cloud KMS API auf vertrauenswürdige Netzwerke und Identitäten zu beschränken.
BYOK-Neuimport Generieren Sie Schlüsselmaterial lokal und verwenden Sie den Neuimport, um zerstörte Schlüsselversionen wiederherzustellen, ohne Ressourcennamen zu ändern.
Projektübergreifende Architektur Wenn Sie Cloud HSM für einzelne Mandanten verwenden, trennen Sie die Cloud HSM-Instanz für einzelne Mandanten und die Schlüssel über verschiedene Projekte hinweg, um die Aufteilung der Aufgaben zu erzwingen.

Nächste Schritte