Best Practices für die Verwendung von CMEKs

Auf dieser Seite finden Sie Best Practices für die Konfiguration der Verschlüsselung ruhender Daten mit vom Kunden verwalteten Verschlüsselungsschlüsseln (Customer-Managed Encryption Keys, CMEKs) für Ihre Google Cloud -Ressourcen. Dieser Leitfaden richtet sich an Cloud-Architekten und Sicherheitsteams und beschreibt Best Practices und Entscheidungen, die Sie beim Entwerfen Ihrer CMEK-Architektur treffen müssen.

In diesem Leitfaden wird davon ausgegangen, dass Sie bereits mit dem Cloud Key Management Service (Cloud KMS) und vom Kunden verwalteten Verschlüsselungsschlüsseln vertraut sind und den Cloud KMS-Deep Dive gelesen haben.

Vorläufige Entscheidungen

Die Empfehlungen auf dieser Seite richten sich an Kunden, die CMEKs zum Verschlüsseln ihrer Daten verwenden. Wenn Sie sich nicht sicher sind, ob Sie manuell oder automatisch erstellte CMEKs im Rahmen Ihrer Sicherheitsstrategie verwenden sollten, finden Sie in diesem Abschnitt eine Anleitung für diese vorläufigen Entscheidungen.

Entscheiden, ob CMEK verwendet werden soll

Wir empfehlen die Verwendung von CMEK zum Verschlüsseln inaktiver Daten in Google Cloud-Diensten, wenn Sie eine der folgenden Funktionen benötigen:

  • Sie sind Eigentümer Ihrer Verschlüsselungsschlüssel.

  • Sie haben die Kontrolle über Ihre Verschlüsselungsschlüssel und können sie verwalten, einschließlich der Auswahl des Speicherorts, des Schutzlevels, der Erstellung, der Zugriffssteuerung, der Rotation, der Verwendung und der Vernichtung.

  • Schlüsselmaterial in Cloud KMS generieren oder Schlüsselmaterial importieren, das außerhalb von Google Cloudverwaltet wird.

  • Legen Sie eine Richtlinie fest, in der angegeben ist, wo Ihre Schlüssel verwendet werden müssen.

  • Sie können Daten, die durch Ihre Schlüssel geschützt sind, im Falle einer Deaktivierung oder zur Behebung von Sicherheitsereignissen selektiv löschen (kryptografisches Löschen).

  • Erstellen und verwenden Sie Schlüssel, die für einen Kunden eindeutig sind, um eine kryptografische Grenze für Ihre Daten zu schaffen.

  • Administrator- und Datenzugriff auf Verschlüsselungsschlüssel protokollieren

  • Einhaltung aktueller oder zukünftiger Vorschriften, die eines dieser Ziele erfordern.

Wenn Sie diese Funktionen nicht benötigen, sollten Sie prüfen, ob die Standardverschlüsselung im Ruhezustand mitGoogle-owned and managed keys für Ihren Anwendungsfall geeignet ist. Wenn Sie nur die Standardverschlüsselung verwenden möchten, können Sie diesen Leitfaden beenden.

Manuelle oder automatische Schlüsselerstellung auswählen

In diesem Leitfaden werden Best Practices für Entscheidungen beschrieben, die Sie bei der Bereitstellung von CMEKs treffen müssen. Cloud KMS Autokey trifft einige dieser Entscheidungen für Sie und automatisiert viele Empfehlungen aus diesem Leitfaden. Die Verwendung von Autokey ist einfacher als die manuelle Bereitstellung von Schlüsseln und wird empfohlen, wenn die von Autokey erstellten Schlüssel alle Ihre Anforderungen erfüllen.

Mit Autokey werden CMEKs für Sie bereitgestellt. Die von Autokey bereitgestellten CMEKs haben die folgenden Eigenschaften:

  • Schutzniveau:HSM.
  • Algorithmus:AES‑256 GCM.

  • Rotationszeitraum:ein Jahr.

    Nachdem ein Schlüssel von Autokey erstellt wurde, kann ein Cloud KMS-Administrator den Rotationszeitraum vom Standardwert ändern.

  • Aufgabentrennung:
    • Dem Dienstkonto für den Dienst werden automatisch Berechtigungen zum Verschlüsseln und Entschlüsseln für den Schlüssel erteilt.
    • Cloud KMS-Administratorberechtigungen gelten wie gewohnt für Schlüssel, die mit Autokey erstellt wurden. Cloud KMS-Administratoren können von Autokey erstellte Schlüssel ansehen, aktualisieren, aktivieren oder deaktivieren und löschen. Cloud KMS-Administratoren erhalten keine Berechtigungen zum Verschlüsseln und Entschlüsseln.
    • Autokey-Entwickler können nur die Erstellung und Zuweisung von Schlüsseln anfordern. Sie können keine Schlüssel ansehen oder verwalten.
  • Schlüsselspezifität oder Granularität:Die von Autokey erstellten Schlüssel haben eine Granularität, die je nach Ressourcentyp variiert. Dienstspezifische Informationen zur Schlüsselgranularität finden Sie unter Kompatible Dienste.

  • Standort:Autokey erstellt Schlüssel am selben Standort wie die zu schützende Ressource.

    Wenn Sie CMEK-geschützte Ressourcen an Standorten erstellen müssen, an denen Cloud HSM nicht verfügbar ist, müssen Sie den CMEK manuell erstellen.

  • Status der Schlüsselversion:Neu erstellte Schlüssel, die mit Autokey angefordert werden, werden als Primärschlüsselversion im Status „Aktiviert“ erstellt.
  • Benennung von Schlüsselbunden:Alle von Autokey erstellten Schlüssel werden in einem Schlüsselbund namens autokey im Autokey-Projekt am ausgewählten Standort erstellt. Schlüsselbunde in Ihrem Autokey-Projekt werden erstellt, wenn ein Autokey-Entwickler den ersten Schlüssel an einem bestimmten Standort anfordert.
  • Schlüsselbenennung:Für Schlüssel, die von Autokey erstellt werden, gilt die folgende Namenskonvention: PROJECT_NUMBER-SERVICE_SHORT_NAME-RANDOM_HEX
  • Schlüsselexport:Wie alle Cloud KMS-Schlüssel können auch Schlüssel, die von Autokey erstellt wurden, nicht exportiert werden.
  • Schlüssel-Tracking:Wie alle Cloud KMS-Schlüssel, die in CMEK-integrierten Diensten verwendet werden, die mit Schlüssel-Tracking kompatibel sind, werden von Autokey erstellte Schlüssel im Cloud KMS-Dashboard verfolgt.

Wenn Sie Anforderungen haben, die mit von Autokey erstellten Schlüsseln nicht erfüllt werden können, z. B. ein anderes Schutzniveau als HSM oder Dienste, die nicht mit Autokey kompatibel sind, empfehlen wir, manuell erstellte CMEKs anstelle von Autokey zu verwenden.

CMEK-Architektur entwerfen

Beim Entwerfen einer CMEK-Architektur müssen Sie die Konfiguration der verwendeten Schlüssel und die Verwaltung dieser Schlüssel berücksichtigen. Diese Entscheidungen wirken sich auf Ihre Kosten, den Betriebsaufwand und die einfache Implementierung von Funktionen wie Crypto-Shredding aus.

In den folgenden Abschnitten werden Empfehlungen für die einzelnen Designentscheidungen erläutert.

Zentrales CMEK-Schlüsselprojekt für jede Umgebung verwenden

Wir empfehlen, für jeden Umgebungsordner ein zentrales CMEK-Schlüsselprojekt zu verwenden. Erstellen Sie keine mit CMEK verschlüsselten Ressourcen im selben Projekt, in dem Sie Cloud KMS-Schlüssel verwalten. Dieser Ansatz trägt dazu bei, dass keine Verschlüsselungsschlüssel zwischen Umgebungen geteilt werden, und ermöglicht die Aufgabentrennung.

Das folgende Diagramm veranschaulicht diese Konzepte im empfohlenen Design:

  • Jeder Umgebungsordner hat ein Cloud KMS-Schlüsselprojekt, das separat von Anwendungsprojekten verwaltet wird.
  • Cloud KMS-Schlüsselbunde und -Schlüssel werden im Cloud KMS-Schlüsselprojekt bereitgestellt und diese Schlüssel werden zum Verschlüsseln von Ressourcen in den Anwendungsprojekten verwendet.
  • IAM-Richtlinien (Identity and Access Management) werden auf Projekte oder Ordner angewendet, um die Aufgabentrennung zu ermöglichen. Das Konto, mit dem Cloud KMS-Schlüssel im Cloud KMS-Schlüsselprojekt verwaltet werden, ist nicht dasselbe Konto, mit dem die Verschlüsselungsschlüssel in Anwendungsprojekten verwendet werden.

Empfohlene Cloud KMS-Ordner- und Projektstruktur

Wenn Sie Cloud KMS Autokey verwenden, muss für jeden Ordner, für den Autokey aktiviert ist, ein eigenes Cloud KMS-Schlüsselprojekt vorhanden sein.

Cloud KMS-Schlüsselbunde für jeden Standort erstellen

Sie müssen Cloud KMS-Schlüsselbunde an den Standorten erstellen, an denen Sie mit CMEK verschlüsselteGoogle Cloud -Ressourcen bereitstellen.

  • Für regionale und zonale Ressourcen muss ein Schlüsselbund und CMEK in derselben Region wie die Ressource oder am Standort global verwendet werden. Für Ressourcen in einer einzelnen Region und zonalen Ressourcen kann kein multiregionaler Schlüsselbund außer global verwendet werden.
  • Für multiregionale Ressourcen (z. B. ein BigQuery-Dataset in der Multiregion us) müssen ein Schlüsselbund und CMEK in derselben Multiregion oder Biregion verwendet werden. Für multiregionale Ressourcen kann kein regionaler Schlüsselbund verwendet werden.
  • Globale Ressourcen müssen einen Schlüsselbund und einen CMEK am Standort global verwenden.

Die Erzwingung regionaler Schlüssel ist ein Teil einer Strategie zur Regionalisierung von Daten. Wenn Sie die Verwendung von Schlüsselbunden und Schlüsseln in einer definierten Region erzwingen, erzwingen Sie auch, dass Ressourcen mit der Region des Schlüsselbunds übereinstimmen müssen. Informationen zum Datenstandort finden Sie unter Datenstandort steuern.

Bei Arbeitslasten, die eine hohe Verfügbarkeit oder Funktionen zur Notfallwiederherstellung an mehreren Standorten erfordern, liegt es in Ihrer Verantwortung, zu beurteilen, ob Ihre Arbeitslast ausfallsicher ist, falls Cloud KMS in einer bestimmten Region nicht verfügbar ist. Beispielsweise kann ein nichtflüchtiger Compute Engine-Speicher, der mit einem Cloud KMS-Schlüssel aus Region A verschlüsselt ist, in einem Notfallwiederherstellungsszenario, in dem Region A nicht verfügbar ist, nicht in Region B neu erstellt werden. Um das Risiko dieses Szenarios zu verringern, können Sie die Verschlüsselung einer Ressource mit global-Schlüsseln planen.

Weitere Informationen finden Sie unter Den besten Standorttyp auswählen.

Wenn Sie Cloud KMS Autokey verwenden, werden Schlüsselbunde für Sie am selben Standort wie die Ressourcen erstellt, die Sie schützen.

Strategie für die Schlüsselgranularität auswählen

Granularität bezieht sich auf den Umfang und die Reichweite der beabsichtigten Verwendung der einzelnen Schlüssel. Ein Schlüssel, der mehrere Ressourcen schützt, ist beispielsweise weniger detailliert als ein Schlüssel, der nur eine Ressource schützt.

Manuell bereitgestellte Cloud KMS-Schlüssel für CMEK müssen im Voraus bereitgestellt werden, bevor eine Ressource erstellt wird, die mit dem Schlüssel verschlüsselt wird, z. B. ein nichtflüchtiger Compute Engine-Datenträger. Sie können sehr detaillierte Schlüssel für einzelne Ressourcen oder weniger detaillierte Schlüssel erstellen, die für mehrere Ressourcen wiederverwendet werden können.

Im Allgemeinen empfehlen wir die folgende Granularitätsstrategie:

  • Jeder Schlüssel schützt Ressourcen an einem einzelnen Standort, z. B. us-central1.
  • Jeder Schlüssel schützt Ressourcen in einem einzelnen Dienst oder Produkt, z. B. BigQuery.
  • Jeder Schlüssel schützt Ressourcen in einem einzelnen Google Cloud -Projekt.

Diese Empfehlung ist möglicherweise nicht die ideale Granularitätsstrategie für Ihre Organisation. Für die meisten Organisationen bietet diese Strategie ein gutes Gleichgewicht zwischen dem Aufwand für die Verwaltung vieler hochgranularer Schlüssel und den potenziellen Risiken der Verwendung weniger granularer Schlüssel, die von vielen Projekten, Diensten oder Ressourcen gemeinsam genutzt werden.

Schlüssel, die mit Cloud KMS Autokey erstellt wurden, entsprechen dieser Empfehlung.

Wenn Sie eine andere Granularitätsstrategie verfolgen möchten, sollten Sie die folgenden Kompromisse bei verschiedenen Mustern berücksichtigen:

Schlüssel mit hoher Granularität: z. B. ein Schlüssel für jede einzelne Ressource

  • Mehr Kontrolle beim sicheren Deaktivieren von Schlüsselversionen:Das Deaktivieren oder Zerstören einer Schlüsselversion, die für einen eingeschränkten Bereich verwendet wird, birgt ein geringeres Risiko, dass andere Ressourcen beeinträchtigt werden, als das Deaktivieren oder Zerstören eines freigegebenen Schlüssels. Das bedeutet auch, dass die Verwendung von Schlüsseln mit hoher Granularität dazu beiträgt, die potenziellen Auswirkungen eines manipulierten Schlüssels im Vergleich zur Verwendung von Schlüsseln mit niedriger Granularität zu verringern.
  • Kosten:Bei der Verwendung von detaillierten Schlüsseln müssen mehr aktive Schlüsselversionen verwaltet werden als bei einer Strategie mit weniger detaillierten Schlüsseln. Da die Cloud KMS-Preise auf der Anzahl der aktiven Schlüsselversionen basieren, führt eine höhere Schlüsselgranularität zu höheren Kosten.
  • Betrieblicher Aufwand:Die Verwendung von sehr detaillierten Schlüsseln kann Verwaltungsaufwand oder zusätzliche Tools für die Automatisierung erfordern, um eine große Anzahl von Cloud KMS-Ressourcen bereitzustellen und Zugriffssteuerungen für Dienst-Agents zu verwalten, damit sie nur die entsprechenden Schlüssel verwenden können. Wenn Sie Schlüssel mit hoher Granularität benötigen, ist Autokey möglicherweise eine gute Wahl, um die Bereitstellung zu automatisieren. Weitere Informationen zur Autokey-Schlüsselgranularität für die einzelnen Dienste finden Sie unter Kompatible Dienste.

Schlüssel mit geringer Granularität, z. B. ein Schlüssel für jede Anwendung, für jede Region und für jede Umgebung:

  • Sicheres Deaktivieren von Schlüsselversionen erfordert Sorgfalt:Das Deaktivieren oder Löschen einer Schlüsselversion, die für einen großen Bereich verwendet wird, erfordert mehr Sorgfalt als das Deaktivieren oder Löschen eines sehr detaillierten Schlüssels. Sie müssen dafür sorgen, dass alle Ressourcen, die mit dieser Schlüsselversion verschlüsselt sind, sicher mit einer neuen Schlüsselversion neu verschlüsselt werden, bevor Sie die alte Schlüsselversion deaktivieren. Bei vielen Ressourcentypen können Sie die Schlüsselverwendung ansehen, um herauszufinden, wo ein Schlüssel verwendet wurde. Das bedeutet auch, dass die potenziellen Auswirkungen eines kompromittierten Schlüssels bei Verwendung von Schlüsseln mit geringer Granularität im Vergleich zur Verwendung von Schlüsseln mit hoher Granularität größer sein können.
  • Kosten:Wenn Sie weniger detaillierte Schlüssel verwenden, müssen weniger Schlüsselversionen erstellt werden. Die Cloud KMS-Preise richten sich nach der Anzahl der aktiven Schlüsselversionen.
  • Betrieblicher Aufwand:Sie können eine bekannte Anzahl von Schlüsseln definieren und vorab bereitstellen. So ist weniger Aufwand erforderlich, um für angemessene Zugriffssteuerungen zu sorgen.

Schutzstufe für Schlüssel auswählen

Beim Erstellen eines Schlüssels liegt es in Ihrer Verantwortung, das Schutzniveau auszuwählen, das für jeden Schlüssel basierend auf Ihren Anforderungen an die mit CMEK verschlüsselten Daten und Arbeitslasten geeignet ist. Die folgenden Fragen können Ihnen bei der Bewertung helfen:

  1. Benötigen Sie eine der CMEK-Funktionen? Die Funktionen sind auf dieser Seite unter Entscheiden, ob CMEK verwendet werden soll aufgeführt.

  2. Muss Ihr Schlüsselmaterial innerhalb der physischen Grenzen eines Hardware Security Module (HSM) bleiben?

  3. Muss das Schlüsselmaterial außerhalb von Google Cloudgespeichert werden?

Autokey unterstützt nur das HSM-Schutzniveau. Wenn Sie andere Schutzstufen benötigen, müssen Sie die Schlüssel selbst bereitstellen.

Nach Möglichkeit von Google Cloudgeneriertes Schlüsselmaterial verwenden

Dieser Abschnitt gilt nicht für Cloud EKM-Schlüssel.

Wenn Sie einen Schlüssel erstellen, müssen Sie entweder Cloud KMS das Schlüsselmaterial für Sie generieren lassen oder manuell Schlüsselmaterial importieren, das außerhalb von Google Cloudgeneriert wurde. Wir empfehlen, nach Möglichkeit die generierte Option auszuwählen. Bei dieser Option wird das Rohschlüsselmaterial nicht außerhalb von Cloud KMS verfügbar gemacht und es werden automatisch neue Schlüsselversionen basierend auf dem von Ihnen ausgewählten Schlüsselrotationszeitraum erstellt. Wenn Sie die Option zum Importieren Ihres eigenen Schlüsselmaterials benötigen, empfehlen wir, die folgenden betrieblichen Aspekte und Risiken der Verwendung des BYOK-Ansatzes (Bring Your Own Key) zu berücksichtigen:

  • Können Sie die automatische Importierung neuer Schlüsselversionen implementieren? Dazu gehören sowohl Cloud KMS-Einstellungen zum Einschränken von Schlüsselversionen auf den Import als auch die Automatisierung außerhalb von Cloud KMS zum konsistenten Generieren und Importieren von Schlüsselmaterial. Welche Auswirkungen hat es, wenn durch Ihre Automatisierung nicht zum erwarteten Zeitpunkt eine neue Schlüsselversion erstellt wird?
  • Wie beabsichtigen Sie, das ursprüngliche Schlüsselmaterial sicher zu speichern oder zu hinterlegen?
  • Wie können Sie das Risiko verringern, dass bei Ihrem Prozess zum Importieren von Schlüsseln das Rohschlüsselmaterial offengelegt wird?
  • Welche Auswirkungen hat es, wenn ich einen gelöschten Schlüssel noch einmal importiere, weil das Rohschlüsselmaterial außerhalb von Google Cloudaufbewahrt wurde?
  • Rechtfertigt der Vorteil des Imports von Schlüsselmaterial durch Sie selbst den erhöhten operativen Aufwand und das erhöhte Risiko?

Den richtigen Schlüsselzweck und Algorithmus für Ihre Anforderungen auswählen

Wenn Sie einen Schlüssel erstellen, müssen Sie den Zweck und den zugrunde liegenden Algorithmus für den Schlüssel auswählen. Für CMEK-Anwendungsfälle können nur Schlüssel mit dem symmetrischen Zweck ENCRYPT_DECRYPT verwendet werden. Für diesen Schlüsselzweck wird immer der Algorithmus GOOGLE_SYMMETRIC_ENCRYPTION verwendet, der AES-Schlüssel (Advanced Encryption Standard) mit 256 Bit im Galois Counter Mode (GCM) nutzt, die mit Cloud KMS-internen Metadaten aufgefüllt sind. Wenn Sie Autokey verwenden, werden diese Einstellungen automatisch angewendet.

Für andere Anwendungsfälle wie die clientseitige Verschlüsselung sollten Sie die verfügbaren Schlüsselverwendungszwecke und ‑algorithmen prüfen, um die für Ihren Anwendungsfall am besten geeignete Option auszuwählen.

Rotationszeitraum auswählen

Wir empfehlen Ihnen, den für Ihre Anforderungen geeigneten Schlüsselrotationszeitraum festzulegen. Die Häufigkeit der Schlüsselrotation hängt von den Anforderungen Ihrer Arbeitslasten in Bezug auf Vertraulichkeit oder Compliance ab. Beispielsweise kann die Schlüsselrotation mindestens einmal jährlich erforderlich sein, um bestimmte Compliance-Standards zu erfüllen. Für besonders sensible Arbeitslasten können Sie auch einen kürzeren Rotationszeitraum wählen.

Nach dem Rotieren eines symmetrischen Schlüssels wird die neue Version als primäre Schlüsselversion markiert und für alle neuen Anfragen zum Schutz von Informationen verwendet. Die alten Schlüsselversionen bleiben verfügbar, um alle zuvor verschlüsselten Daten zu entschlüsseln, die mit dieser Version geschützt sind. Wenn Sie einen Schlüssel rotieren, werden Daten, die mit früheren Schlüsselversionen verschlüsselt wurden, nicht automatisch neu verschlüsselt.

Durch die häufige Schlüsselrotation wird die Anzahl der Nachrichten begrenzt, die mit derselben Schlüsselversion verschlüsselt werden. Dies trägt dazu bei, das Risiko und die Folgen eines Schlüsselmissbrauchs zu verringern.

Wenn Sie Autokey verwenden, werden Schlüssel mit einem standardmäßigen Schlüsselrotationszeitraum von einem Jahr erstellt. Sie können den Rotationszeitraum für Schlüssel ändern, nachdem sie erstellt wurden.

Angemessene Zugriffssteuerungen anwenden

Wir empfehlen, bei der Planung der Zugriffssteuerung die Prinzipien der geringsten Berechtigung und der Aufgabentrennung zu berücksichtigen. In den folgenden Abschnitten werden diese Empfehlungen vorgestellt.

Prinzip der geringsten Berechtigung anwenden

Berücksichtigen Sie beim Zuweisen von Berechtigungen zum Verwalten von CMEKs das Prinzip der geringsten Berechtigung und gewähren Sie die Mindestberechtigungen, die zum Ausführen einer Aufgabe erforderlich sind. Wir empfehlen dringend, einfache Rollen zu vermeiden. Weisen Sie stattdessen vordefinierte Cloud KMS-Rollen zu, um das Risiko von Sicherheitsvorfällen im Zusammenhang mit überprivilegiertem Zugriff zu minimieren.

Verstöße gegen diesen Grundsatz und damit zusammenhängende Probleme können automatisch durch Security Command Center-Ergebnisse zu Sicherheitslücken für IAM erkannt werden.

Aufgabentrennung planen

Verwalten Sie separate Identitäten und Berechtigungen für Personen, die Ihre Verschlüsselungsschlüssel verwalten, und für Personen, die sie verwenden. NIST SP 800-152 definiert eine Aufgabentrennung zwischen dem Kryptografiebeauftragten, der die Dienste eines kryptografischen Schlüsselverwaltungssystems aktiviert und verwaltet, und einem Nutzer, der diese Schlüssel zum Ver- oder Entschlüsseln von Ressourcen verwendet.

Wenn Sie CMEK verwenden, um die Verschlüsselung ruhender Daten mit Google Cloud -Diensten zu verwalten, wird die IAM-Rolle für die Verwendung von Verschlüsselungsschlüsseln dem Dienst-Agent des Google Cloud -Dienstes zugewiesen, nicht dem einzelnen Nutzer. Wenn ein Nutzer beispielsweise Objekte in einem verschlüsselten Cloud Storage-Bucket erstellen möchte, benötigt er nur die IAM-Rolle roles/storage.objectCreator. Der Cloud Storage-Dienst-Agent im selben Projekt (z. B. service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com) benötigt die IAM-Rolle roles/cloudkms.cryptoKeyEncrypterDecrypter.

In der folgenden Tabelle sind die IAM-Rollen aufgeführt, die in der Regel mit den jeweiligen Aufgabenbereichen verknüpft sind:

IAM-Rolle Beschreibung NIST SP 800-152-Bezeichnung
roles/cloudkms.admin Bietet Zugriff auf Cloud KMS-Ressourcen, mit Ausnahme von eingeschränkten Ressourcentypen und kryptografischen Vorgängen. Kryptografischer Officers
roles/cloudkms.cryptoKeyEncrypterDecrypter Bietet die Möglichkeit, Cloud KMS-Ressourcen nur für encrypt- und decrypt-Vorgänge zu verwenden. Nutzer des Systems zur Verwaltung kryptografischer Schlüssel
roles/cloudkms.viewer Ermöglicht get- und list-Vorgänge. Audit-Administratoren
Verstöße gegen diesen Grundsatz und damit zusammenhängende Probleme können automatisch durch Security Command-Ergebnisse zu Sicherheitslücken für Cloud KMS erkannt werden.

CMEK konsistent erzwingen

In den folgenden Abschnitten werden zusätzliche Kontrollen beschrieben, mit denen Sie Risiken wie eine inkonsistente Schlüsselverwendung oder versehentliches Löschen oder Vernichten verringern können.

Projektsperren durchsetzen

Wir empfehlen, Projekte durch Sperren zu schützen, um versehentliches Löschen zu vermeiden. Wenn eine Projektsperre erzwungen wird, kann das Cloud KMS-Schlüsselprojekt erst gelöscht werden, wenn die Sperre entfernt wird.

CMEK-Schlüssel erforderlich machen

Wir empfehlen, die Verwendung von CMEK in Ihrer Umgebung mit Einschränkungen für Organisationsrichtlinien zu erzwingen.

Verwenden Sie constraints/gcp.restrictNonCmekServices, um Anfragen zum Erstellen bestimmter Ressourcentypen ohne Angabe eines CMEK-Schlüssels zu blockieren.

Mindestdauer für die geplante Löschung erforderlich

Wir empfehlen, eine Mindestdauer für zum Löschen geplant festzulegen. Das Löschen eines Schlüssels ist ein unwiderruflicher Vorgang, der zu Datenverlust führen kann. Standardmäßig verwendet Cloud KMS eine Dauer von 30 Tagen für Zum Löschen vorgemerkt (manchmal auch Zeitraum für vorläufiges Löschen genannt), bevor das Schlüsselmaterial unwiederbringlich gelöscht wird. So haben Sie etwas Zeit, einen Schlüssel wiederherzustellen, falls er versehentlich gelöscht wurde. Es ist jedoch möglich, dass jemand mit der Rolle „Cloud KMS-Administrator“ einen Schlüssel mit einer Dauer von nur 24 Stunden für das geplante Löschen erstellt. Das ist möglicherweise nicht ausreichend Zeit, um ein Problem zu erkennen und den Schlüssel wiederherzustellen. Die Dauer für Zur Vernichtung geplant kann nur beim Erstellen des Schlüssels festgelegt werden.

Wenn ein Schlüssel zum Löschen vorgemerkt ist, kann er nicht für kryptografische Vorgänge verwendet werden. Alle Anfragen zur Verwendung des Schlüssels schlagen fehl. Prüfen Sie in dieser Zeit die Audit-Logs, um sicherzugehen, dass der Schlüssel nicht verwendet wird. Wenn Sie den Schlüssel wieder verwenden möchten, müssen Sie ihn vor Ablauf des Zeitraums zum Löschen vorgemerkt wiederherstellen.

Damit alle erstellten Schlüssel eine Mindestdauer für die geplante Vernichtung haben, empfehlen wir, die Einschränkung der Organisationsrichtlinie constraints/cloudkms.minimumDestroyScheduledDuration mit mindestens 30 Tagen oder der gewünschten Dauer zu konfigurieren. Diese Organisationsrichtlinie verhindert, dass Nutzer Schlüssel mit einer Dauer für den Status Zum Löschen vorgemerkt erstellen, die unter dem in der Richtlinie angegebenen Wert liegt.

Zulässige Schutzstufen für CMEKs erzwingen

Wir empfehlen, Ihre Anforderungen an die Schlüsselschutzstufen in Ihrer Umgebung mithilfe von Einschränkungen für Organisationsrichtlinien einheitlich durchzusetzen.

Mit constraints/cloudkms.allowedProtectionLevels können Sie erzwingen, dass für neue Schlüssel, Schlüsselversionen und Importjobs die von Ihnen zugelassenen Schutzstufen verwendet werden müssen.

Aufdeckungskontrollen für CMEKs konfigurieren

Google Cloud bietet verschiedene Erkennungsmechanismen für CMEKs. In den folgenden Abschnitten wird beschrieben, wie Sie diese Steuerelemente für Cloud KMS aktivieren und verwenden.

Audit-Logging aktivieren und zusammenfassen

Wir empfehlen, Cloud KMS-Audit-Logs zur Administratoraktivität (zusammen mit Admin-Aktivitätslogs für alle Dienste) für alle Ressourcen in Ihrer Organisation an einem zentralen Ort zusammenzufassen. So kann ein Sicherheitsteam oder ein Prüfer alle Aktivitäten im Zusammenhang mit dem Erstellen oder Ändern von Cloud KMS-Ressourcen gleichzeitig prüfen. Eine Anleitung zum Konfigurieren aggregierter Logsenken finden Sie unter Logs Ihrer Organisation zusammenfassen und speichern.

Optional können Sie Datenzugriffsprotokolle aktivieren, um Vorgänge zu protokollieren, bei denen die Schlüssel verwendet werden, einschließlich Verschlüsselungs- und Entschlüsselungsvorgängen. Bei der Verwendung von CMEKs kann ein erhebliches Logvolumen entstehen und sich auf Ihre Kosten auswirken, da für jeden Vorgang von jedem Dienst, der CMEKs verwendet, Datenzugriffsprotokolle erstellt werden. Bevor Sie Datenzugriffs-Logs aktivieren, sollten Sie einen klaren Anwendungsfall für die zusätzlichen Logs definieren und prüfen, wie sich Ihre Logging-Kosten erhöhen.

Schlüsselnutzung überwachen

Mit der Cloud KMS Inventory API können Sie die Schlüsselnutzung ansehen, um Google Cloud Ressourcen in Ihrer Organisation zu identifizieren, die von Cloud KMS-Schlüsseln abhängig sind und durch diese geschützt werden. Mit diesem Dashboard können Sie den Status, die Nutzung und die Verfügbarkeit Ihrer Schlüsselversionen und der entsprechenden Ressourcen, die sie schützen, überwachen. Im Dashboard werden auch Daten angezeigt, auf die aufgrund eines deaktivierten oder gelöschten Schlüssels nicht zugegriffen werden kann. So können Sie Maßnahmen ergreifen, z. B. die nicht zugänglichen Daten löschen oder den Schlüssel wieder aktivieren.

Sie können Cloud Monitoring mit Cloud KMS verwenden, um Benachrichtigungen für kritische Ereignisse wie das Planen eines Schlüssels zum Löschen einzurichten. Mit Cloud Monitoring können Sie nachvollziehen, warum ein solcher Vorgang ausgeführt wurde, und bei Bedarf einen optionalen Downstream-Prozess zum Wiederherstellen des Schlüssels auslösen.

Wir empfehlen, einen Betriebsplan zu erstellen, um automatisch Ereignisse zu erkennen, die Sie für wichtig halten, und das Dashboard zur Schlüsselnutzung regelmäßig zu überprüfen.

Security Command Center für Cloud KMS-Schwachstellenergebnisse aktivieren

Security Command Center generiert Sicherheitslücken-Ergebnisse, in denen Fehlkonfigurationen im Zusammenhang mit Cloud KMS und anderen Ressourcen hervorgehoben werden. Wir empfehlen, Security Command Center zu aktivieren und diese Ergebnisse in Ihre bestehenden Sicherheitsvorgänge zu integrieren. Diese Ergebnisse umfassen Probleme wie öffentlich zugängliche Cloud KMS-Schlüssel, Cloud KMS-Projekte mit der übermäßig permissiven Rolle owner oder IAM-Rollen, die gegen die Aufgabentrennung verstoßen.

Compliance-Anforderungen ermitteln

Für verschiedene Compliance-Frameworks gelten unterschiedliche Anforderungen an die Verschlüsselung und die Schlüsselverwaltung. Ein Compliance-Framework beschreibt in der Regel die allgemeinen Grundsätze und Ziele der Verwaltung von Verschlüsselungsschlüsseln, schreibt aber nicht vor, welches bestimmte Produkt oder welche Konfiguration die Compliance erreicht. Es liegt in Ihrer Verantwortung, die Anforderungen Ihres Compliance-Frameworks zu verstehen und zu wissen, wie Ihre Kontrollen, einschließlich der Schlüsselverwaltung, diese Anforderungen erfüllen können.

Informationen dazu, wie Google Cloud Dienste die Anforderungen verschiedener Compliance-Frameworks erfüllen können, finden Sie in den folgenden Ressourcen:

Zusammenfassung der Best Practices

In der folgenden Tabelle sind die Best Practices zusammengefasst, die in diesem Dokument empfohlen werden:

Thema Aufgabe
Entscheiden, ob CMEK verwendet werden soll Verwenden Sie CMEK, wenn Sie eine der Funktionen benötigen, die durch CMEK aktiviert werden.
Manuelle oder automatische Schlüsselerstellung auswählen Verwenden Sie Cloud KMS Autokey, wenn die Eigenschaften der von Autokey erstellten Schlüssel Ihren Anforderungen entsprechen.
Cloud KMS-Schlüsselprojekte Verwenden Sie für jede Umgebung ein zentrales Schlüsselprojekt. Erstellen Sie Cloud KMS-Ressourcen nicht im selben Projekt wie die Google Cloud-Ressourcen, die durch die Schlüssel geschützt werden.
Cloud KMS-Schlüsselbunde Cloud KMS-Schlüsselbunde für jeden Speicherort erstellen, an dem Sie Google Cloud-Ressourcen schützen möchten.
Schlüsselgranularität Wählen Sie ein Muster für die Schlüsselgranularität aus, das Ihren Anforderungen entspricht, oder verwenden Sie Autokey, um Schlüssel automatisch mit der empfohlenen Granularität für jeden Dienst bereitzustellen.
Schutzniveau Wählen Sie Cloud EKM aus, wenn Ihr Schlüsselmaterial außerhalb von Google Cloudgespeichert werden muss. Wählen Sie Cloud HSM aus, wenn Ihr Schlüsselmaterial auf Google Cloud-eigenen Hardwaresicherheitsmodulen (HSMs) gehostet werden kann. Wählen Sie Softwareschlüssel aus, wenn Sie Cloud HSM oder Cloud EKM nicht benötigen. Hinweise zur Auswahl eines Schutzniveaus
Schlüsselmaterial Verwenden Sie für Schlüsselmaterial, das auf Google Cloudgehostet wird, nach Möglichkeit von Google Cloudgeneriertes Schlüsselmaterial. Wenn Sie importiertes Schlüsselmaterial verwenden, implementieren Sie Automatisierung und Verfahren, um Risiken zu minimieren.
Schlüsselzweck und Algorithmus Alle CMEK-Schlüssel müssen den symmetrischen Schlüsselzweck ENCRYPT_DECRYPT und den Algorithmus GOOGLE_SYMMETRIC_ENCRYPTION verwenden.
Rotationszeitraum Verwenden Sie die automatische Schlüsselrotation, um sicherzustellen, dass Ihre Schlüssel planmäßig rotiert werden. Wählen Sie einen Rotationszeitraum aus, der Ihren Anforderungen entspricht, idealerweise mindestens einmal pro Jahr. Verwenden Sie eine häufigere Schlüsselrotation für sensible Arbeitslasten.
Geringste Berechtigung Weisen Sie die am stärksten beschränkten vordefinierten Rollen zu, die Ihre Hauptkonten zum Ausführen ihrer Aufgaben benötigen. Verwenden Sie keine einfachen Rollen.
Aufgabentrennung Verwalten Sie separate Berechtigungen für Schlüsseladministratoren und Identitäten, die Schlüssel verwenden.
Projektsperren Verwenden Sie Projektsperren, um ein versehentliches Löschen Ihrer wichtigsten Projekte zu verhindern.
CMEKs erforderlich machen Verwenden Sie die Einschränkung constraints/gcp.restrictNonCmekServices.
Mindestdauer für die geplante Löschung erforderlich Verwenden Sie die Einschränkung constraints/cloudkms.minimumDestroyScheduledDuration.
Zulässige Schutzstufen für CMEKs erzwingen Verwenden Sie die Einschränkung constraints/cloudkms.allowedProtectionLevels.
Audit-Logging aktivieren und zusammenfassen Audit-Logs zu Administratoraktivitäten für alle Ressourcen in Ihrer Organisation zusammenfassen. Überlegen Sie, ob Sie die Protokollierung von Vorgängen mit Schlüsseln aktivieren möchten.
Schlüsselnutzung überwachen Verwenden Sie die Cloud KMS Inventory API oder die Google Cloud -Konsole, um die Schlüsselnutzung zu analysieren. Optional können Sie Cloud Monitoring verwenden, um Benachrichtigungen für sensible Vorgänge wie das Planen des Löschens eines Schlüssels einzurichten.
Security Command Center für Cloud KMS aktivieren Überprüfen Sie die Ergebnisse zu Sicherheitslücken und integrieren Sie die Überprüfung von Ergebnissen zu Sicherheitslücken in Ihre Sicherheitsvorgänge.
Compliance-Anforderungen prüfen Überprüfen Sie Ihre Cloud KMS-Architektur und vergleichen Sie sie mit allen Compliance-Anforderungen, die Sie einhalten müssen.

Nächste Schritte