Best Practices für die Verwendung von CMEKs

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

In diesem Leitfaden wird davon ausgegangen, dass Sie mit dem Cloud Key Management Service (Cloud KMS) vertraut sind und den Detaillierten Artikel zu Cloud KMS gelesen haben.

Vorläufige Entscheidungen

Die Empfehlungen auf dieser Seite richten sich an Kunden, die ihre Daten mit CMEKs verschlüsseln. Wenn Sie sich nicht sicher sind, ob Sie manuell oder automatisch erstellte CMEKs als Teil Ihrer Sicherheitsstrategie verwenden sollten, finden Sie in diesem Abschnitt Informationen zu diesen vorläufigen Entscheidungen.

Entscheiden, ob CMEK verwendet werden soll

Wir empfehlen, CMEK zur Verschlüsselung von inaktiven Daten in Google Cloud-Diensten zu verwenden, wenn Sie eine der folgenden Funktionen benötigen:

  • Sie haben die Kontrolle über Ihre Verschlüsselungsschlüssel.

  • Sie können Ihre Verschlüsselungsschlüssel steuern und verwalten, einschließlich Speicherort, Schutzlevel, Erstellung, Zugriffssteuerung, Rotation, Verwendung und Vernichtung.

  • Generieren Sie Schlüsselmaterial in Cloud KMS oder importieren Sie Schlüsselmaterial, das außerhalb von Google Cloud verwaltet wird.

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

  • Daten, die durch Ihre Schlüssel geschützt sind, können bei Offboarding oder zur Behebung von Sicherheitsereignissen selektiv gelöscht werden (Crypto-Shredding).

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

  • Administratorzugriff und Datenzugriff auf Verschlüsselungsschlüssel protokollieren

  • Sie erfüllen aktuelle oder zukünftige Bestimmungen, die eines dieser Ziele erfordern.

Wenn Sie diese Funktionen nicht benötigen, prüfen Sie, ob die Standardverschlüsselung im Ruhezustand mit von Google verwalteten Schlüsseln für Ihren Anwendungsfall geeignet ist. Wenn Sie nur die Standardverschlüsselung verwenden möchten, können Sie diesen Leitfaden jetzt schließen.

Manuelle oder automatische Schlüsselerstellung auswählen

In diesem Leitfaden werden Best Practices für Entscheidungen beschrieben, die Sie bei der eigenständigen 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 Bereitstellung von Schlüsseln und wird empfohlen, wenn die von Autokey erstellten Schlüssel alle Anforderungen erfüllen.

Autokey stellt CMEKs für Sie bereit. Die von Autokey bereitgestellten CMEKs haben folgende 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 bearbeiten.

  • Aufgabentrennung:
    • Dem Dienstkonto für den Dienst werden automatisch Berechtigungen zum Verschlüsseln und Entschlüsseln des Schlüssels gewährt.
    • Cloud KMS-Administratorberechtigungen gelten wie gewohnt für von Autokey erstellte Schlüssel. Cloud KMS-Administratoren können von Autokey erstellte Schlüssel aufrufen, 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 Detaillierung:Die Detaillierung von Autokey-Schlüsseln variiert je nach Ressourcentyp. Dienstspezifische Details zur Schlüsselgranularität finden Sie unter Kompatible Dienste.

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

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

  • Status der Schlüsselversion:Neu erstellte Schlüssel, die mit Autokey angefordert werden, werden als Primärschlüsselversion im aktivierten Status erstellt.
  • Schlüsselbundbenennung:Alle von Autokey erstellten Schlüssel werden im Autokey-Projekt am ausgewählten Speicherort in einem Schlüsselbund namens autokey erstellt. Schlüsselringe in Ihrem Autokey-Projekt werden erstellt, wenn ein Autokey-Entwickler den ersten Schlüssel an einem bestimmten Standort anfordert.
  • Schlüsselbenennung:Von Autokey erstellte Schlüssel folgen dieser Benennungskonvention: PROJECT_NUMBER-SERVICE_SHORT_NAME-RANDOM_HEX
  • Schlüsselexport:Wie alle Cloud KMS-Schlüssel können auch von Autokey erstellte Schlüssel 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 erfasst.

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 dem Krypto-Schreddern aus.

In den folgenden Abschnitten werden Empfehlungen für die einzelnen Designoptionen 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, die Freigabe von Verschlüsselungsschlüsseln zwischen Umgebungen zu verhindern und die Aufgabentrennung zu ermöglichen.

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üsselringe und ‑Schlüssel werden im Cloud KMS-Schlüsselprojekt bereitgestellt. 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 eine Aufgabentrennung zu ermöglichen. Der Nutzer, der Cloud KMS-Schlüssel im Cloud KMS-Schlüsselprojekt verwaltet, ist nicht derselbe Nutzer, der die Verschlüsselungsschlüssel in Anwendungsprojekten verwendet.

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 Speicherort erstellen

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

  • Für regionale und zonale Ressourcen müssen ein Schlüsselbund und ein CMEK in derselben Region wie die Ressource oder am Speicherort global verwendet werden. Für Ressourcen mit einer einzelnen Region und zonale Ressourcen kann nur der Schlüsselbund global verwendet werden.
  • Für multiregionale Ressourcen (z. B. ein BigQuery-Dataset in der multiregionalen Region us) müssen ein Schlüsselbund und ein CMEK in derselben multiregionalen oder dualen Region verwendet werden. Für multiregionale Ressourcen kann kein regionaler Schlüsselbund verwendet werden.
  • Für globale Ressourcen müssen ein Schlüsselbund und CMEK am Speicherort global verwendet werden.

Die Erzwingung regionaler Schlüssel ist ein Teil einer Strategie zur Datenregionalisierung. Wenn Sie die Verwendung von Schlüsselbünden und Schlüsseln in einer bestimmten Region erzwingen, erzwingen Sie auch, dass Ressourcen mit der Region des Schlüsselbunds übereinstimmen müssen. Informationen zum Datenstandort finden Sie unter Anforderungen an den Datenstandort und die Datenhoheit umsetzen.

Bei Arbeitslasten, für die Hochverfügbarkeit oder Notfallwiederherstellung an mehreren Standorten erforderlich sind, müssen Sie selbst prüfen, ob Ihre Arbeitslast für den Fall gewappnet ist, dass Cloud KMS in einer bestimmten Region nicht verfügbar ist. Ein Compute Engine-persistenter Datenträger, der mit einem Cloud KMS-Schlüssel von us-central1 verschlüsselt ist, kann beispielsweise in us-central2 nicht neu erstellt werden, wenn us-central1 in einem Notfall nicht verfügbar ist. Um das Risiko dieses Szenarios zu minimieren, können Sie eine Ressource mit global-Schlüsseln verschlüsseln.

Weitere Informationen finden Sie unter Besten Standorttyp auswählen.

Wenn Sie Cloud KMS Autokey verwenden, werden Schlüsselringe für Sie an demselben Speicherort wie die zu schützenden Ressourcen erstellt.

Strategie für den Detaillierungsgrad von Schlüsseln auswählen

Die Detaillierung bezieht sich auf den Umfang und die beabsichtigte Verwendung der einzelnen Schlüssel. Ein Schlüssel, der mehrere Ressourcen schützt, ist beispielsweise weniger granular als ein Schlüssel, der nur eine Ressource schützt.

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

Es gibt zwar kein allgemeingültiges Muster, aber Sie sollten die folgenden Vor- und Nachteile der verschiedenen Muster berücksichtigen:

Schlüssel mit hoher Detaillierung, z. B. ein Schlüssel für jede einzelne Ressource

  • Mehr Kontrolle zum sicheren Deaktivieren von Schlüsselversionen:Wenn Sie eine Schlüsselversion deaktivieren oder zerstören, die nur für einen begrenzten Umfang verwendet wird, ist das Risiko geringer, dass andere Ressourcen betroffen sind, als wenn Sie einen freigegebenen Schlüssel deaktivieren oder zerstören. Das bedeutet auch, dass die Verwendung von sehr detaillierten Schlüsseln die potenziellen Auswirkungen eines manipulierten Schlüssels im Vergleich zur Verwendung von Schlüsseln mit geringer Granularität verringert.
  • 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 sich die Cloud KMS-Preise nach der Anzahl der aktiven Schlüsselversionen richten, steigen die Kosten mit einer höheren Schlüsselgranularität.
  • Betrieblicher Overhead: Die Verwendung sehr detaillierter Schlüssel erfordert möglicherweise administrativen Aufwand oder zusätzliche Tools zur Automatisierung, um eine große Anzahl von Cloud KMS-Ressourcen bereitzustellen und Zugriffssteuerungen für Kundenservicemitarbeiter zu verwalten, damit sie nur die entsprechenden Schlüssel verwenden können. Wenn Sie Schlüssel mit hoher Detaillierung benötigen, ist Autokey eine gute Wahl, um die Bereitstellung zu automatisieren. Weitere Informationen zur Granularität von Autokey-Schlüsseln 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, jede Region und jede Umgebung

  • Vorsicht beim Deaktivieren von Schlüsselversionen: Das Deaktivieren oder Löschen einer Schlüsselversion, die für einen umfassenden 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 mit dieser Schlüsselversion verschlüsselten Ressourcen mit einer neuen Schlüsselversion sicher neu verschlüsselt werden, bevor Sie die alte Schlüsselversion deaktivieren. Bei vielen Ressourcentypen können Sie die Schlüsselnutzung ansehen, um zu ermitteln, wo ein Schlüssel verwendet wurde. Das bedeutet auch, dass die Verwendung von Schlüsseln mit geringer Granularität die potenziellen Auswirkungen eines manipulierten Schlüssels im Vergleich zur Verwendung von Schlüsseln mit hoher Granularität erhöhen kann.
  • Kosten: Bei weniger detaillierten Schlüsseln müssen weniger Schlüsselversionen erstellt werden. Die Cloud KMS-Preise richten sich nach der Anzahl der aktiven Schlüsselversionen.
  • Betrieblicher Overhead:Sie können eine bekannte Anzahl von Schlüsseln definieren und vorab bereitstellen. Die entsprechenden Zugriffssteuerungen sind dann mit weniger Aufwand möglich.

Schutzniveau für Schlüssel auswählen

Beim Erstellen eines Schlüssels müssen Sie die Schutzebene auswählen, die für jeden Schlüssel geeignet ist. Dabei müssen Sie Ihre Anforderungen an die mit CMEK verschlüsselten Daten und Arbeitslasten berücksichtigen. Die folgenden Fragen können Ihnen bei der Bewertung helfen:

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

  2. Müssen Ihre Schlüssel innerhalb der physischen Grenzen eines Hardware Security Modules (HSM) bleiben?

  3. Müssen Schlüsselmaterialien außerhalb von Google Cloud gespeichert werden?

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

Nach Möglichkeit von Google generiertes Schlüsselmaterial verwenden

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

Wenn Sie einen Schlüssel erstellen, müssen Sie entweder zulassen, dass Cloud KMS das Schlüsselmaterial für Sie generiert, oder außerhalb von Google Cloud generiertes Schlüsselmaterial importieren. Wir empfehlen, nach Möglichkeit die generierte Option auszuwählen. Bei dieser Option wird das Rohschlüsselmaterial nicht außerhalb von Cloud KMS freigegeben. Außerdem werden automatisch neue Schlüsselversionen basierend auf dem von Ihnen ausgewählten Rotationszeitraum erstellt. Wenn Sie die Option zum Importieren eigener Schlüsselmaterialien benötigen, sollten Sie die folgenden betrieblichen Überlegungen und Risiken der Verwendung des BYOK-Ansatzes (Bring Your Own Key) berücksichtigen:

  • Können Sie eine Automatisierung implementieren, um neue Schlüsselversionen konsistent zu importieren? Dazu gehören sowohl Cloud KMS-Einstellungen, mit denen Schlüsselversionen nur für den Import eingeschränkt werden, als auch Automatisierungen außerhalb von Cloud KMS, um Schlüsselmaterial konsistent zu generieren und zu importieren. Was passiert, wenn Ihre Automatisierung nicht wie erwartet eine neue Schlüsselversion erstellt?
  • Wie beabsichtigen Sie, das ursprüngliche Schlüsselmaterial sicher zu speichern oder in Treuhänderschaft zu geben?
  • Wie können Sie das Risiko verringern, dass beim Importieren von Schlüsseln das Rohschlüsselmaterial preisgegeben wird?
  • Was passiert, wenn Sie einen zuvor gelöschten Schlüssel noch einmal importieren, weil das Rohschlüsselmaterial außerhalb von Google Cloud aufbewahrt wurde?
  • Rechtfertigen die Vorteile des Importierens von Schlüsselmaterial durch Sie 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 Autoschlüssel verwenden, werden diese Einstellungen automatisch für Sie angewendet.

Für andere Anwendungsfälle wie die clientseitige Verschlüsselung können Sie die verfügbaren Schlüsselzwecke 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 Zeitraum für die Schlüsselrotation zu ermitteln. Die Häufigkeit der Schlüsselrotation hängt von den Anforderungen Ihrer Arbeitslasten ab, die sich auf Vertraulichkeit oder Compliance beziehen. 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 können weiterhin verwendet werden, um zuvor mit dieser Version verschlüsselte Daten zu entschlüsseln. Wenn Sie einen Schlüssel rotieren, werden Daten, die mit früheren Schlüsselversionen verschlüsselt wurden, nicht automatisch neu verschlüsselt.

Durch häufiges Schlüsselrotieren wird die Anzahl der Nachrichten begrenzt, die mit derselben Schlüsselversion verschlüsselt werden. Das Risiko und die Folgen eines Schlüsselmissbrauchs werden dadurch reduziert.

Wenn Sie Autokey verwenden, werden Schlüssel mit einem Standardrotationszeitraum von einem Jahr erstellt. Sie können den Rotationszeitraum für Schlüssel nach der Erstellung ändern.

Entsprechende Zugriffssteuerungen anwenden

Wir empfehlen, bei der Planung von Zugriffssteuerungen 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 zu weitreichenden Zugriffsberechtigungen zu verringern.

Verstöße gegen dieses Prinzip und damit verbundene Probleme können automatisch durch Schwachstellenergebnisse für IAM im Security Command Center erkannt werden.

Aufgabentrennung planen

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

Wenn Sie CMEK verwenden, um die Speicherung verschlüsselter Daten mit Google Cloud-Diensten zu verwalten, wird die IAM-Rolle für die Verwendung von Verschlüsselungsschlüsseln dem Dienstagenten 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 einzelnen Aufgabenbereichen verknüpft sind:

IAM-Rolle Beschreibung Kennzeichnung gemäß NIST SP 800-152
roles/cloudkms.admin Ermöglicht 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 kryptografischen Schlüsselverwaltung
roles/cloudkms.viewer Ermöglicht get- und list-Vorgänge. Audit-Administratoren

Verstöße gegen dieses Prinzip und damit verbundene Probleme können automatisch durch Sicherheitslücken-Ergebnisse für Cloud KMS im Security Command Center erkannt werden.

CMEK konsequent erzwingen

In den folgenden Abschnitten werden zusätzliche Steuerelemente beschrieben, mit denen Risiken wie inkonsistente Schlüsselnutzung oder versehentliches Löschen oder Vernichten minimiert werden können.

Projektpfändungen erzwingen

Wir empfehlen, Projekte mit Sperren zu schützen, um ein versehentliches Löschen zu vermeiden. Wenn eine Projektpfändung erzwungen wird, kann das Cloud KMS-Schlüsselprojekt erst gelöscht werden, wenn die Pfändung aufgehoben wird.

CMEK-Schlüssel erforderlich machen

Wir empfehlen, die Verwendung von CMEKs in Ihrer gesamten Umgebung mithilfe von Einschränkungen von Organisationsrichtlinien durchzusetzen.

Mit constraints/gcp.restrictNonCmekServices können Sie Anfragen zum Erstellen bestimmter Ressourcentypen blockieren, ohne einen CMEK-Schlüssel anzugeben.

Mindestdauer für die geplante Vernichtung angeben

Wir empfehlen, eine Mindestdauer für die geplante Vernichtung festzulegen. Das Löschen von Schlüsseln ist ein irreversibler Vorgang, der zu Datenverlusten führen kann. Standardmäßig wird in Cloud KMS ein Zeitraum von 30 Tagen für den Status Zum Löschen vorgemerkt (manchmal auch Vorläufig gelöscht genannt) verwendet, bevor das Schlüsselmaterial endgültig gelöscht wird. So bleibt bei versehentlichem Löschen noch etwas Zeit, um den Schlüssel wiederherzustellen. Es ist jedoch möglich, dass ein Nutzer mit der Rolle „Cloud KMS-Administrator“ einen Schlüssel mit einer geplante Dauer für das Löschen von nur 24 Stunden erstellt. Das ist möglicherweise nicht ausreichend, um ein Problem zu erkennen und den Schlüssel wiederherzustellen. Die Dauer für Zerstörung geplant kann nur bei der Schlüsselerstellung festgelegt werden.

Solange ein Schlüssel zum Löschen vorgemerkt ist, kann er nicht für kryptografische Vorgänge verwendet werden und alle Anfragen zur Verwendung des Schlüssels schlagen fehl. Überwachen Sie in dieser Zeit die Prüfprotokolle, um festzustellen, ob der Schlüssel nicht verwendet wird. Wenn Sie den Schlüssel wieder verwenden möchten, müssen Sie ihn vor Ablauf des Zeitraums, in dem die Vernichtung geplant ist, restore.

Damit alle erstellten Schlüssel eine Mindestdauer für die geplante Vernichtung einhalten, empfehlen wir, die Einschränkung der Organisationsrichtlinie constraints/cloudkms.minimumDestroyScheduledDuration auf mindestens 30 Tage oder die gewünschte Dauer zu konfigurieren. Diese Organisationsrichtlinie verhindert, dass Nutzer Schlüssel mit einer geplanten Dauer für das Löschen erstellen, die kürzer als der in der Richtlinie angegebene Wert ist.

Zulässige Schutzniveaus für CMEKs erzwingen

Wir empfehlen, Ihre Anforderungen an die Schutzebenen von Schlüsseln mithilfe von Einschränkungen in den Organisationsrichtlinien einheitlich in Ihrer Umgebung durchzusetzen.

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

Aufdeckungskontrollen für CMEKs konfigurieren

Google Cloud bietet verschiedene Prüfmechanismen für CMEKs. In den folgenden Abschnitten erfahren Sie, wie Sie diese für Cloud KMS relevanten Steuerelemente aktivieren und verwenden.

Audit-Logging aktivieren und zusammenfassen

Wir empfehlen, Audit-Logs für Cloud KMS-Administratoraktivitäten (zusammen mit Audit-Logs für Administratoraktivitäten für alle Dienste) an einem zentralen Ort für alle Ressourcen in Ihrer Organisation zusammenzuführen. So können Sicherheitsteams oder Prüfer alle Aktivitäten im Zusammenhang mit dem Erstellen oder Ändern von Cloud KMS-Ressourcen auf einmal überprüfen. Eine Anleitung zum Konfigurieren von Senken für aggregierte Logs finden Sie unter Logs Ihrer Organisation zusammenfassen und speichern.

Optional können Sie Protokolle für den Datenzugriff 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 dies zu einem erheblichen Logvolumen führen und sich auf Ihre Kosten auswirken, da für jeden Vorgang jedes Dienstes, der CMEKs verwendet, Logs zum Datenzugriff erstellt werden. Bevor Sie Logs für den Datenzugriff aktivieren, empfehlen wir Ihnen, einen klaren Anwendungsfall für die zusätzlichen Logs zu definieren und zu prüfen, wie sich Ihre Logging-Kosten erhöhen.

Schlüsselnutzung überwachen

Mit der Cloud KMS Inventory API können Sie die Schlüsselnutzung einsehen, um Google Cloud-Ressourcen in Ihrer Organisation zu identifizieren, die von Cloud KMS-Schlüsseln abhängen 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 geschützten Ressourcen überwachen. Im Dashboard werden auch Daten angezeigt, auf die aufgrund eines deaktivierten oder gelöschten Schlüssels nicht zugegriffen werden kann. Sie können dann Maßnahmen ergreifen, z. B. die nicht zugänglichen Daten löschen oder den Schlüssel wieder aktivieren.

Sie können auch Cloud Monitoring mit Cloud KMS verwenden, um Benachrichtigungen für kritische Ereignisse festzulegen, z. B. wenn ein Schlüssel zum Löschen geplant wird. Mit Cloud Monitoring können Sie ermitteln, warum ein solcher Vorgang ausgeführt wurde, und bei Bedarf einen optionalen Downstream-Prozess auslösen, um den Schlüssel wiederherzustellen.

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

Security Command Center für Ergebnisse zu Cloud KMS-Sicherheitslücken aktivieren

Security Command Center generiert Sicherheitslücken-Ergebnisse, die Fehlkonfigurationen im Zusammenhang mit Cloud KMS und anderen Ressourcen hervorheben. Wir empfehlen, Security Command Center zu aktivieren und diese Ergebnisse in Ihre bestehenden Sicherheitsmaßnahmen einzubinden. Dazu gehören Probleme wie öffentlich zugängliche Cloud KMS-Schlüssel, Cloud KMS-Projekte mit der zu permissiven Rolle owner oder IAM-Rollen, die gegen die Aufgabentrennung verstoßen.

Compliance-Anforderungen prüfen

Unterschiedliche Compliance-Frameworks haben unterschiedliche Anforderungen an die Verschlüsselung und Schlüsselverwaltung. Ein Compliance-Framework beschreibt in der Regel die allgemeinen Prinzipien und Ziele der Verschlüsselungsschlüsselverwaltung, enthält aber keine Vorgaben für das jeweilige Produkt oder die Konfiguration, mit der die Compliance erreicht wird. Sie sind dafür verantwortlich, die Anforderungen Ihres Compliance-Frameworks zu kennen und zu verstehen, wie Ihre Kontrollmechanismen, einschließlich der Schlüsselverwaltung, diese Anforderungen erfüllen können.

In den folgenden Ressourcen erfahren Sie, wie Sie mit Google Cloud-Diensten die Anforderungen verschiedener Compliance-Frameworks erfüllen können:

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 durch CMEK aktivierten Funktionen benötigen.
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 keine Cloud KMS-Ressourcen im selben Projekt wie die Google Cloud-Ressourcen, die durch die Schlüssel geschützt werden.
Cloud KMS-Schlüsselbunde Erstellen Sie Cloud KMS-Schlüsselbunde für jeden Speicherort, an dem Sie Google Cloud-Ressourcen schützen möchten.
Detaillierungsgrad des Schlüssels 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 Cloud gespeichert werden muss. Wählen Sie Cloud HSM aus, wenn Ihr Schlüsselmaterial auf von Google verwalteten Hardwaresicherheitsmodulen (HSMs) gehostet werden kann. Wählen Sie Softwareschlüssel aus, wenn für Ihre Anforderungen kein Cloud HSM oder Cloud EKM erforderlich ist. Weitere Informationen zur Auswahl eines Schutzniveaus
Schlüsselmaterial Verwenden Sie für in Google Cloud gehostetes Schlüsselmaterial nach Möglichkeit von Google generiertes Schlüsselmaterial. Wenn Sie importierte Schlüsselmaterialien 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 Mit der automatischen Schlüsselrotation können Sie dafür sorgen, dass Ihre Schlüssel regelmäßig rotiert werden. Wählen Sie einen Rotationszeitraum aus, der Ihren Anforderungen entspricht, idealerweise mindestens einmal pro Jahr. Verwenden Sie für sensible Arbeitslasten eine häufigere Schlüsselrotation.
Geringste Berechtigung Weisen Sie die am stärksten eingeschränkten vordefinierten Rollen zu, die es Ihren Hauptkonten ermöglichen, ihre Aufgaben auszuführen. Verwenden Sie keine einfachen Rollen.
Aufgabentrennung Verwenden Sie separate Berechtigungen für Schlüsseladministratoren und Hauptberechtigte, die Schlüssel verwenden.
Projektpfändungen Verwenden Sie Projektsperren, um das versehentliche Löschen Ihrer wichtigsten Projekte zu verhindern.
CMEKs erzwingen Verwenden Sie die Einschränkung constraints/gcp.restrictNonCmekServices.
Mindestdauer für die geplante Vernichtung angeben Verwenden Sie die Einschränkung constraints/cloudkms.minimumDestroyScheduledDuration.
Zulässige Schutzniveaus 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 das Logging von Vorgängen mithilfe von Schlüsseln aktivieren möchten.
Schlüsselnutzung überwachen Verwenden Sie die Cloud KMS Inventory API oder die Google Cloud Console, um die Schlüsselnutzung zu analysieren. Optional können Sie mit Cloud Monitoring Benachrichtigungen für sensible Vorgänge wie das Löschen eines Schlüssels einrichten.
Security Command Center für Cloud KMS aktivieren Prüfen Sie die Ergebnisse zu Sicherheitslücken und integrieren Sie die Prüfung der Ergebnisse in Ihre Sicherheitsabläufe.
Compliance-Anforderungen prüfen Prüfen Sie Ihre Cloud KMS-Architektur und vergleichen Sie sie mit den Compliance-Anforderungen, die Sie einhalten müssen.

Nächste Schritte