Empfohlene Vorgehensweisen für die Verwendung von CMEKs

Auf dieser Seite finden Sie empfohlene Vorgehensweisen zum Konfigurieren 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. Er enthält Empfehlungen 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 kundenverwalteten Verschlüsselungsschlüsseln vertraut sind und den Cloud KMS-Überblick gelesen haben.

Auswählen, wo CMEK verwendet werden soll

Google empfiehlt die Verwendung von kundenverwalteten Verschlüsselungsschlüsseln, wenn Sie eine kryptografische Grenze um Ihre Daten oder die Daten Ihrer Kunden in der Cloud ziehen möchten. Weitere Informationen finden Sie unter Vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK).

Sie können manuell erstellte CMEKs oder von Autokey erstellte Schlüssel in kompatiblen Diensten verwenden, um die folgenden Ziele zu erreichen:

  • 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, wo Ihre Schlüssel verwendet werden müssen.

  • Sie können Daten, die durch Ihre Schlüssel geschützt sind, im Falle eines Offboardings 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 um Ihre Daten zu ziehen.

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

  • Sie müssen aktuelle oder zukünftige Vorschriften einhalten, die eines dieser Zielvorhaben erfordern.

Google empfiehlt außerdem, Compliance-Frameworks zu berücksichtigen, die für Ihre geschäftlichen Anforderungen gelten. Für verschiedene Compliance-Frameworks gelten unterschiedliche Anforderungen an die Verschlüsselung und das Schlüsselmanagement. 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, Ihnen helfen können, diese Anforderungen zu erfüllen.

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

Quelle des Schlüsselmaterials auswählen

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. Wenn möglich, empfehlen wir, Schlüsselmaterial in Cloud KMS zu generieren. Bei dieser Option besteht kein Risiko, dass das Rohschlüsselmaterial außerhalb von Cloud KMS offengelegt wird. Außerdem werden automatisch neue Schlüsselversionen basierend auf dem von Ihnen ausgewählten Schlüsselrotationszeitraum erstellt. Wenn Sie Ihr eigenes Schlüsselmaterial importieren müssen, 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 minimieren, dass beim Importieren Ihres Schlüssels das Rohschlüsselmaterial offengelegt wird?

  • Welche Auswirkungen hat es, wenn ich einen zuvor gelöschten Schlüssel noch einmal importiere, weil das Rohschlüsselmaterial außerhalb von Google Cloudaufbewahrt wurde?

  • Rechtfertigt der Vorteil des selbstständigen Importierens von Schlüsselmaterial den erhöhten operativen Aufwand und das erhöhte Risiko?

Schlüsselverwaltungs- und Schlüsselspeichermodelle auswählen

Beim Entwerfen Ihrer CMEK-Architektur müssen Sie entscheiden, wo und wie Ihre Schlüssel verwaltet werden. Im Idealfall wählen Sie ein Schlüsselverwaltungsmodell und ein Schlüsselspeichermodell aus, die aufeinander abgestimmt sind. Das von Ihnen ausgewählte Governance- und Speichermodell wirkt sich auf wichtige Konfigurationen aus, z. B. auf die Durchsetzung der Funktionstrennung.

Schlüssel-Governance

Die Schlüsselverwaltung beschreibt, wer in einer Organisation für die Verwaltung des Lebenszyklus Ihrer Cloud KMS-Ressourcen und die Aufrechterhaltung von Schutzmaßnahmen zur Steuerung der Verwendung von Cloud KMS verantwortlich ist. Es gibt verschiedene Ansätze für die Schlüsselverwaltung, die sich auf einem Spektrum von zentralisierter Verwaltung bis hin zu delegierter Verwaltung bewegen:

  • Zentrale Governance: Ein dediziertes Sicherheits- oder Plattformteam ist für die Verwaltung des Lebenszyklus aller kryptografischen Schlüssel in der gesamten Organisation verantwortlich. Dieses Modell wird häufig von stark regulierten Unternehmen mit strengen Compliance-Anforderungen gewählt.
  • Delegierte Governance: Ein zentrales Sicherheitsteam verwendet Guardrails, um Verschlüsselungsstandards vorzuschreiben, delegiert aber die Verantwortung für wichtige Lebenszyklusvorgänge an Anwendungsbesitzer in ihren Projekten. Diese Schutzmaßnahmen können Organisationsrichtlinien mit verwalteten Beschränkungen und benutzerdefinierten Einschränkungen sowie IAM-Zuweisungen und ‑Verweigerungsrichtlinien umfassen. Dadurch werden zentrale betriebliche Engpässe beseitigt.
Google empfiehlt eine zentrale Schlüsselverwaltung für Organisationen mit strengen behördlichen Anforderungen oder für Organisationen, die auf externe Schlüsselsysteme angewiesen sind, um den Schlüssel-Lebenszyklus zu verwalten.

Schlüsselspeicherung

Der Schlüsselspeicherort beschreibt, wo Cloud KMS-Ressourcen in einer Organisation erstellt werden. Es gibt zwei Hauptansätze für die Schlüsselspeicherung: Schlüsselspeicherung im dedizierten Projekt und Schlüsselspeicherung im selben Projekt.

  • Schlüsselspeicher im dedizierten Projekt: Ein dediziertes Schlüsselprojekt enthält Schlüssel, die für mehrere Anwendungen verwendet werden. Normalerweise hat jeder Umgebungsordner ein eigenes Schlüsselprojekt. Sie können Autokey mit Schlüsselspeicher im dedizierten Projekt verwenden. Weitere Informationen zum Schlüsselspeichermodell für dedizierte Projekte finden Sie unter Schlüsselspeicher im dedizierten Projekt.

  • Schlüsselspeicher im selben Projekt: Schlüssel werden im selbenGoogle Cloud -Projekt wie die Ressourcen gespeichert, die sie schützen. Das wird manchmal als „der Schlüssel folgt den Daten“ bezeichnet. Sie können Autokey mit dem Schlüsselspeicher im selben Projekt verwenden. Weitere Informationen zum Schlüsselspeichermodell im selben Projekt finden Sie unter Schlüsselspeicher im selben Projekt.

Google empfiehlt eine verteilte Schlüsselverwaltung, wenn die Priorität auf Entwicklergeschwindigkeit, Agilität und klarer Verantwortlichkeit liegt.

Die folgende Tabelle enthält Beispiele dafür, wie diese Governance- und Speichermodelle kombiniert werden können, um unterschiedliche Organisationsanforderungen zu erfüllen:

Governance-Modell Schlüsselspeicher im dedizierten Projekt Schlüsselspeicher im selben Projekt
Zentrale Governance

Vollständig zentralisierter Ansatz

Empfohlene Verwendung: Organisationen mit strengen behördlichen Anforderungen, die eine Isolation der Projektgrenzen vorschreiben.

Operative Auswirkungen: Hohe Komplexität bei der Einrichtung. Erfordert eine robuste Automatisierung (z. B. eine „Projektfabrik“), um Betriebsverzögerungen für Entwicklungsteams zu vermeiden.

Kontrollierte Inhaberschaft

Empfohlene Verwendung: Organisationen, die eine zentrale Sicherheitskontrolle benötigen, aber die Entwicklungsgeschwindigkeit maximieren möchten.

Operative Auswirkungen: Geringe Komplexität bei der Einrichtung. Bei der zentralen Sicherheit wird die Richtlinie mithilfe von Guardrails durchgesetzt, während sich die Schlüssel zur einfachen Verwaltung am selben Ort wie die Ressourcen befinden, die sie schützen.
Delegierte Governance

Nicht empfohlen

Die Einführung von projektübergreifender IAM-Komplexität macht die Delegation der Schlüsselverwaltung an Anwendungsteams zunichte.

Autonomous DevOps

Empfohlene Verwendung: Schnelle, dezentrale Organisationen mit einer starken DevOps-Kultur.

Operative Auswirkungen: Minimale Komplexität bei der Einrichtung. Anwendungsteams haben die volle Autonomie über Ressourcen und Schlüssel innerhalb ihrer Projektgrenzen.

Konsistente Architektur in allen Umgebungen verwenden

Wir empfehlen, für jede Anwendung dasselbe Schlüsselspeichermuster in Entwicklungs-, Test- und Produktionsumgebungen zu verwenden. Diese architektonische Konsistenz trägt dazu bei, dass Ihre IAM-Berechtigungen, Bereitstellungspipelines und Sicherheitskontrollen in niedrigeren Umgebungen gründlich getestet werden, bevor Sie sie in der Produktion bereitstellen. Wenn Sie unterschiedliche Architekturen für Ihre Umgebungen auswählen, besteht das Risiko von Konfigurationsabweichungen, die zu Bereitstellungsfehlern führen können.

Schlüsselspeicher im dedizierten Projekt

Bei einem Schlüsselspeichermodell mit dediziertem Projekt werden alle Schlüssel für einen bestimmten Umgebungsordner (z.B. „Production“) in einem zentralen, freigegebenen Schlüsselprojekt gespeichert. Berechtigungen für die Schlüsselverwaltung werden einem gemeinsamen Sicherheitsteam erteilt, das in der Regel auch den Lebenszyklus von Schlüsseln und Schutzmaßnahmen wie CMEK-Organisationsrichtlinien sowie IAM-Richtlinien und Rollenzuweisungen verwaltet.

Anwendungsfall

Wir empfehlen die Verwendung des Schlüsselmodells mit dediziertem Projekt, wenn Ihre Organisation strenge, zentrale Kontrolle über Verschlüsselungsschlüssel priorisiert, was häufig durch behördliche Anforderungen bedingt ist, oder wenn Schlüssel auf einem externen HSM gehostet werden.

Wenn Ihre Organisation einem Compliance-Framework unterliegt, das einen Cryptographic Officer oder Key Custodian erfordert, z. B. PCI DSS oder BSI C5, ist dieses Modell eine gute Wahl. Wenn Sie alle Schlüssel für eine Anwendung in einem einzelnen, dedizierten Schlüsselprojekt isolieren, können Sie die Rolle „Cloud KMS-Administrator“ nur einer kleinen, geprüften Gruppe von Sicherheitsadministratoren zuweisen. Dies kann Compliance-Prüfungen vereinfachen, da die Anzahl der Projekte, in denen Richtlinien für den Schlüsseladministrationszugriff überprüft werden müssen, begrenzt wird.

Hinweise

Dieser Ansatz kann zu projektübergreifenden IAM-Komplexitäten und potenziellen Engpässen für Entwicklungsteams führen. Um dieses Risiko zu minimieren, können Sie die automatisierte Projektbereitstellung implementieren, die manchmal auch als „Project Factory“ bezeichnet wird. Damit lassen sich die Schlüsselerstellung und die Zuweisung von Berechtigungen automatisieren. Alternativ können Sie Cloud KMS Autokey verwenden, um die On-Demand-Bereitstellung zu aktivieren, die die Aufgabentrennung unterstützt, auch für IaC-Pipelines (Infrastructure as Code).

Beispiel

Das folgende Diagramm zeigt ein Beispiel für eine Ressourcenhierarchie für eine Produktionsumgebung mit dem Schlüsselmodell für dedizierte Projekte:

  • Der Ordner „Prod“ enthält einzelne Ordner und Projekte für verschiedene Anwendungen sowie einen freigegebenen Ordner.
  • Die Anwendungsprojekte enthalten eine Vielzahl verschiedener Ressourcen wie Compute Engine-Instanzen und Cloud Storage-Buckets, aber keine Cloud KMS-Schlüssel.
  • Der Ordner „Shared“ enthält Ressourcen, die von den verschiedenen Anwendungen gemeinsam genutzt werden.
  • Im freigegebenen Ordner befindet sich ein dediziertes Schlüsselprojekt, in dem die Cloud KMS API aktiviert ist. Dieses Projekt enthält alle Schlüssel, die zum Schutz von Ressourcen im Ordner „Prod“ verwendet werden. Wenn Sie Cloud KMS Autokey verwenden, werden in diesem dedizierten Schlüsselprojekt Schlüssel von Autokey bereitgestellt.
  • Guardrails auf Organisations- und Ordnerebene wie Einschränkungen für Organisationsrichtlinien und IAM-Richtlinien erzwingen die Trennung von Aufgaben und andere Praktiken.
  • Entwickler können erweiterte Berechtigungen wie die Rolle „Projektinhaber“ in einem einzelnen Anwendungsordner oder Projekt haben, ohne dass ihnen Berechtigungen für das Schlüsselprojekt gewährt werden müssen.

Schlüsselspeicher im dedizierten Projekt

Schlüsselspeicher im selben Projekt

In diesem Modell werden Schlüssel im selben Projekt wie die Ressourcen gespeichert, die sie schützen. Schutzmaßnahmen für die Schlüsselverwaltung werden in der Regel von einem zentralen Sicherheitsteam implementiert, auch wenn Entwickler den Schlüssel-Lebenszyklus für ihre eigenen Anwendungen verwalten.

Anwendungsfall

Wir empfehlen die Verwendung des Schlüsselmodells für dasselbe Projekt, wenn die Entwicklergeschwindigkeit, Agilität und klare Verantwortlichkeit für Sie Priorität haben. Wenn Schlüssel und die Ressourcen, die sie schützen, am selben Ort gespeichert werden, stimmt die Schlüsselverantwortung mit der Datenverantwortung überein: Der Schlüssel folgt den Daten. Dieses Modell erleichtert die Übertragung der Verantwortlichkeiten für die Schlüsselverwaltung an die Inhaber von Arbeitslasten, die die Verantwortung für die Einhaltung der CMEK-Organisationsrichtlinien und die Verwaltung von Schlüssel-Lebenszyklusvorgängen in ihren Projekten übernehmen können.

Hinweise

Dieses Modell gibt Anwendungsteams mehr Autonomie, erfordert aber eine sorgfältige Überprüfung der IAM-Rollen in jedem Projekt, um das Prinzip der geringsten Berechtigung durchzusetzen. Dieses Modell kann die betriebliche Komplexität für Organisationen erhöhen, die BYOK (Bring Your Own Key) implementieren oder Cloud EKM-Schlüssel verwenden, da der Aufwand für die Koordination zwischen den Systemen hoch ist.

Beispiel

Das folgende Diagramm zeigt ein Beispiel für eine Ressourcenhierarchie für eine Produktionsumgebung mit dem Schlüsselverwaltungmodell für dasselbe Projekt:

  • Der Ordner „Prod“ enthält einzelne Ordner und Projekte für verschiedene Anwendungen.
  • Die Anwendungsprojekte enthalten eine Vielzahl verschiedener Ressourcen wie Compute Engine-Instanzen und Cloud Storage-Buckets, einschließlich aller Cloud KMS-Schlüssel, die diese Ressourcen schützen.
  • Wenn Sie Cloud KMS Autokey verwenden, werden Schlüssel von Autokey im Ressourcenprojekt bereitgestellt.
  • Schutzmaßnahmen auf Organisations- und Ordnerebene wie Einschränkungen für Organisationsrichtlinien und IAM-Richtlinien erzwingen die Trennung von Aufgaben und andere Praktiken. Wenn Sie Autokey nicht verwenden, ist möglicherweise eine sorgfältigere Konfiguration erforderlich, um die Trennung von Aufgaben zu erzwingen.
  • Wenn Sie Autokey nicht verwenden, benötigen Entwickler erweiterte Cloud KMS-Berechtigungen für das Ressourcenprojekt. Wenn Sie Autokey verwenden, benötigen sie nur die dienstspezifischen Rollen für die Ressourcen, die sie erstellen möchten, z. B. die Rolle „BigQuery-Nutzer“ oder „Compute-Administrator“.

Schlüsselspeicher im selben Projekt

Aufgabentrennung erzwingen

Unabhängig von Ihrem Speichermodell müssen Sie separate Identitäten und Berechtigungen für diejenigen verwalten, die Ihre Verschlüsselungsschlüssel verwalten, und diejenigen, die sie verwenden. Um das Prinzip der geringsten Berechtigung und die strikte Aufgabentrennung zu erzwingen, weisen Sie IAM-Rollen basierend auf bestimmten betrieblichen Verantwortlichkeiten zu.

In der folgenden Tabelle ist die empfohlene Rollentrennung für Cloud KMS zusammengefasst:

Zuständigkeit Empfohlene Rolle Zusammenfassung der Berechtigungen

Schlüsselverwaltung, z.B. Schlüssellebenszyklen und Governance

Dazu können menschliche Administratoren und IaC-Principals gehören, die erhöhte Berechtigungen benötigen.

 Cloud KMS-Administrator (roles/cloudkms.admin)
  • Schlüssel und zugehörige Ressourcen erstellen, rotieren, aktivieren, deaktivieren und löschen.
  • IAM-Richtlinien verwalten.

Bereitstellung von Ressourcen, z.B. Erstellung von CMEK-geschützten Ressourcen

Dazu können menschliche Entwickler und IaC-Principals ohne erhöhte Berechtigungen gehören.

Dienstspezifische Administrator- oder Bearbeiterrollen wie die folgenden:

  • BigQuery-Nutzer (roles/bigquery.user)
  • Compute-Administrator (roles/compute.admin)
 Wählen Sie Schlüssel beim Erstellen von Ressourcen aus.

Schlüsselverwendung, z.B. Verschlüsselung und Entschlüsselung

Weisen Sie diese Rolle nur Dienst-Agents zu. Für Schlüssel, die in CMEK-Integrationen verwendet werden, benötigen menschliche Identitäten diese Berechtigungen nicht.

Wenn Sie Autokey verwenden, wird diese Rolle dem Dienst-Agent automatisch zugewiesen.

 Cloud KMS CryptoKey-Verschlüsseler/Entschlüsseler (roles/cloudkms.cryptoKeyEncrypterDecrypter) Daten mit dem Schlüssel verschlüsseln und entschlüsseln
Mit Autokey erstellte Schlüssel entsprechen automatisch diesen Grundsätzen.

Rechteausweitung mit geringsten Berechtigungen für IaC-Pipelines anwenden

Viele Organisationen automatisieren die Ressourcenbereitstellung mithilfe von IaC-Pipelines (Infrastruktur als Code) wie Terraform-Runnern. Die Art und Weise, wie Sie Ihren Schlüsselspeicher gestalten, wirkt sich direkt auf den Sicherheitsstatus dieser Pipelines aus.

Um die Bereitstellung von Cloud KMS-Schlüsseln zu automatisieren, müssen Ihren IaC-Pipelines administrative Rollen mit hohen Berechtigungen zugewiesen werden, damit sie Schlüssel generieren und IAM-Richtlinien ändern können. Wenn ein Angreifer die IaC-Pipeline manipuliert, kann er die vollständige administrative Kontrolle über Ihre Schlüsselverwaltungsebene erlangen.

  • Wenn Sie die Schlüssel in einem dedizierten Projekt speichern, benötigt die Pipeline Administratorzugriff auf das zentrale Cloud KMS-Projekt. Wenn die Pipeline manipuliert wird, kann dies die Schlüsselverwaltungsebene für Ihre gesamte Organisation offenlegen.
  • Wenn Sie den Schlüsselspeicher im selben Projekt verwenden, benötigt die Pipeline nur Administratorzugriff auf das Ressourcenprojekt. Dadurch wird das potenzielle Risiko auf die jeweilige Anwendung beschränkt, es müssen aber weiterhin erhöhte Berechtigungen innerhalb des Projekts verwaltet werden.

Cloud KMS Autokey begegnet diesem Risiko, indem die Schlüsselbereitstellung an einen sicheren, von Google verwalteten Dienst-Agenten delegiert wird. So können Sie eine Pipeline mit den geringsten Berechtigungen für die laufende Schlüsselbereitstellung implementieren:

  • Pipelines mit geringen Berechtigungen: Für die IaC-Pipeline ist nur die Rolle „Cloud KMS Autokey User“ (roles/cloudkms.autokeyUser) mit geringen Berechtigungen erforderlich, um einen Schlüssel anzufordern, indem eine KeyHandle-Ressource erstellt wird.
  • Automatisierte Bereitstellung: Das Erstellen von Schlüsseln und das Aktualisieren von IAM-Richtlinien werden im Hintergrund vom von Google verwalteten Cloud KMS-Dienst-Agenten übernommen.
  • Begrenztes Risiko: Durch die Minimierung der Berechtigungen, die Ihrer Pipeline gewährt werden, wird vermieden, dass Ihren Bereitstellungspipelines erweiterte Berechtigungen zum Erstellen von Schlüsseln oder Sicherheitsadministratorberechtigungen oder die Möglichkeit zum Zuweisen von Helferrollen gewährt werden. Dadurch wird das Risiko einer Pipeline-Gefährdung erheblich reduziert.

Für eine IaC-Pipeline, die Autokey ermöglicht, ist eine permissive Rolle wie „Cloud KMS Autokey Admin“ (roles/cloudkms.autokeyAdmin) erforderlich. Wenn Sie also IaC-Pipelines verwenden, um die Autokey-Aktivierung zu verwalten, müssen Sie auch die Aufgabentrennung auf einzelne IaC-Hauptkonten anwenden.

Entscheiden, ob Sie Autokey verwenden möchten

Nachdem Sie sich für eine Architektur für die Schlüsselspeicherung entschieden haben, müssen Sie festlegen, wie die Schlüssel bereitgestellt werden. Wir empfehlen, die Schlüsselerstellung nach Möglichkeit mit Cloud KMS Autokey zu automatisieren, um manuellen Aufwand und Konfigurationsfehler zu reduzieren. Autokey bietet integrierte Unterstützung für beide Speichermodelle:

  • Autokey mit Schlüsselspeicher im selben Projekt: Entwickler können Schlüssel in ihren eigenen Projekten bei Bedarf nahtlos generieren und dabei zentrale Richtlinien einhalten. Sie können Autokey mit Schlüsselspeicher im selben Projekt pro Projekt oder für alle Projekte in einem Ordner aktivieren.
  • Autokey mit Schlüsselspeicher im dedizierten Projekt: Entwickler können nahtlos Schlüssel im Namen von Ressourcen in anderen Projekten in einem zentralen Schlüsselprojekt generieren. Sie aktivieren Autokey mit Schlüsselspeicher im dedizierten Projekt auf Ordnerebene.

Die folgenden empfohlenen Vorgehensweisen werden bei der Verwendung von Autokey automatisiert:

  • Schlüssel am selben Standort wie die Ressource erstellen, die durch die Schlüssel geschützt wird
  • Aufgabentrennung zwischen Schlüsseladministratoren und Ressourceninhabern aufrechterhalten
  • IAM-Rollenberechtigungen für neue Schlüssel gewähren
  • Verwenden Sie das Schutzniveau HSM.
  • Empfohlene Granularitätsstrategien
  • Automatische Schlüsselrotation alle 365 Tage planen

Da Cloud KMS Autokey die laufende Schlüsselbereitstellung und ‑zuweisung übernimmt, wird durch die Verwendung von Autokey ein Großteil des Aufwands für die Einrichtung benutzerdefinierter Richtlinien, Tools und Betriebsverfahren reduziert. Das vereinfacht sowohl den anfänglichen als auch den laufenden Aufwand. Sie müssen jedoch weiterhin operative Schutzmaßnahmen festlegen und Kontrollen für die Erkennung und Überwachung konfigurieren, um eine einheitliche Governance in Ihrer Organisation zu gewährleisten.

Compliance und Autokey

Viele Compliance-Vorschriften erfordern, dass Sie letztendlich die Kontrolle über Ihre Verschlüsselungsschlüssel behalten, unabhängig von Ihrem Cloud-Dienstanbieter.

Die Übertragung der Routineaufgaben der Schlüsselbereitstellung an Cloud KMS Autokey verstößt nicht gegen diesen Standard. Autokey fungiert ausschließlich als Automatisierungsmodul, das Ihre vordefinierten Richtlinien ausführt. Sie behalten die letztendliche Inhaberschaft, Autorität und kryptografische Kontrolle durch drei primäre Mechanismen:

  • Ihr Crypto Officer behält die alleinige Kontrolle über die Schlüssel. Nur Ihre Administratoren können Schlüsselversionen deaktivieren, rotieren oder löschen. Der Autokey-Dienst kann diese Lebenszyklusaktionen nicht ausführen.
  • Ihre Administratoren legen genau fest, wo Autokey aktiviert ist und welche Identitäten Schlüssel anfordern können. Sie können Autokey deaktivieren oder Berechtigungen jederzeit auf jeder Ebene der Ressourcenhierarchie widerrufen. Die Automatisierung wird dann sofort beendet.
  • Jeder von Autokey generierte Schlüssel, jede zugewiesene Berechtigung und jede angepasste Richtlinie wird in Cloud Logging aufgezeichnet. So erhalten Prüfer einen kontinuierlichen, automatisierten Audit-Trail, um die Einhaltung der Vorgaben zu überprüfen.

Anstatt die Governance zu schwächen, wird die Compliance durch die Delegierung der Bereitstellung an Autokey gestärkt. Es ersetzt manuelle, fehleranfällige Konfigurationsschritte durch die programmatische Durchsetzung der Aufgabentrennung und Pipelinesicherheit und erfüllt so die strengen Kontrollanforderungen von Compliance-Programmen wie NIST SP 800-152 und PCI DSS.

Empfohlene Praktiken für die Schlüsselverwaltung einhalten

Google empfiehlt Praktiken für Schlüsselspeicherort, Schutzlevel, Rotationszeitplan, Granularität und Berechtigungen. Sie können diese Methoden entweder mit dem automatisierten Ansatz mit Cloud KMS Autokey oder durch manuelle Konfiguration implementieren. Im Dashboard für Verschlüsselungsmesswerte können Sie sehen, wie gut Ihre Schlüssel diesen Praktiken entsprechen. Mit Security Command Center-Ergebnissen zu Sicherheitslücken können Sie Verstöße gegen die Funktionstrennung erkennen.

Speicherort des Schlüssels

Wenn Sie manuelles CMEK verwenden, müssen Sie Cloud KMS-Schlüsselbunde an den Standorten erstellen, an denen Sie Google Cloud Ressourcen bereitstellen möchten, die mit CMEK verschlüsselt sind. Sie müssen dies tun, bevor Sie die Schlüssel erstellen können.

  • Für regionale und zonale Ressourcen muss ein Schlüsselbund und ein Schlüssel in derselben Region wie die Ressource oder am Standort global verwendet werden. Für Ressourcen in einer einzelnen Region und zonalen Ressourcen kann kein anderer multiregionaler Schlüsselbund als global verwendet werden.
  • Für multiregionale Ressourcen (z. B. ein BigQuery-Dataset in der multiregionalen Region us) müssen ein Schlüsselbund und ein Schlüssel in derselben multiregionalen Region verwendet werden. Für multiregionale Ressourcen kann kein regionaler Schlüssel verwendet werden.
  • Für globale Ressourcen muss ein Schlüsselbund und ein Schlüssel am Standort global verwendet werden.

In den meisten Fällen werden diese Einschränkungen vom Google Cloud-Dienst durchgesetzt.

Die Durchsetzung der Verwendung regionaler Schlüssel ist ein wichtiger Bestandteil einer erfolgreichen Strategie zur Regionalisierung von Daten. Wenn Sie die Verwendung von Schlüsselbunden und Schlüsseln in einer bestimmten Region erzwingen, erzwingen Sie auch, dass Ressourcen der Region des Schlüsselbunds entsprechen müssen. Informationen zum Datenstandort finden Sie unter Datenstandort steuern. Weitere Informationen finden Sie unter Geeigneten Standort 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. Wenn Sie eine geeignete Strategie für die Schlüsselgranularität auswählen, können Sie die NIST-Empfehlung einhalten, dass jeder Schlüssel einen bestimmten Zweck hat.

Im Allgemeinen empfehlen wir, jeden Schlüssel so zu verwenden:

  • Wird für ein einzelnes Google Cloud Projekt verwendet.
  • Wird an einem einzelnen Ort verwendet, z. B. us-central1.
  • Wird in einem einzelnen Dienst oder Produkt verwendet, z. B. BigQuery.
  • Wenn möglich, für eine einzelne Ressource verwendet, z. B. einen einzelnen Cloud Storage-Bucket.

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 diese Granularitätsrichtlinien befolgen, können Sie Schlüsselversionen leichter sicher deaktivieren oder löschen und das Risiko einer versehentlichen oder böswilligen Schlüsselzerstörung wird begrenzt.

Schutzstufe für Schlüssel auswählen

Beim Erstellen eines Schlüssels liegt es in Ihrer Verantwortung, die Schutzstufe auszuwählen, die 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. Haben Sie spezielle Anforderungen an Isolation, Datenresidenz oder regulatorische Anforderungen? Prüfen Sie, ob Ihre Arbeitslast eine der folgenden Sicherheitsanforderungen erfüllt:

    • Externer Speicher: Verwenden Sie manuelles CMEK mit Cloud EKM. Wir empfehlen das Schutzniveau EXTERNAL_VPC, um die Verfügbarkeit zu verbessern.
    • Dedizierte Hardware: Verwenden Sie manuelles CMEK mit Single-Tenant Cloud HSM.

    Andernfalls fahren Sie mit der nächsten Frage fort.

  2. Möchten Sie die automatisierte Schlüsselbereitstellung und ‑lebenszyklusverwaltung nutzen?

    • Verwenden Sie in diesem Fall Cloud KMS Autokey. Mit Autokey werden automatisch Schlüssel mit dem Schutzniveau „Multi-tenant Cloud HSM“ erstellt. Auch wenn Sie softwarebasierte Schlüssel akzeptieren, empfehlen wir, die höhere Sicherheitsbaseline von Cloud HSM zu akzeptieren, um von der Automatisierung zu profitieren, die Autokey bietet.

    • Falls nicht, fahren Sie mit der nächsten Frage fort.

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

    • Verwenden Sie in diesem Fall Multi-tenant Cloud HSM.
    • Andernfalls verwenden Sie softwarebasierte Schlüssel.

Rotationszeitraum auswählen

Cloud KMS unterstützt die automatische Schlüsselrotation von softwaregestützten und hardwaregestützten symmetrischen Schlüsseln, wie sie für CMEK verwendet werden. Für softwarebasierte Schlüssel empfehlen wir den branchenüblichen Rotationszeitraum von 90 Tagen. Für Cloud HSM-Schlüssel empfehlen wir den branchenüblichen Rotationszeitraum von 365 Tagen. Externe Schlüssel müssen gemäß dem von Ihnen ausgewählten Zeitplan manuell rotiert werden.

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

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.

Prinzip der geringsten Berechtigung anwenden

Halten Sie sich beim Zuweisen von IAM-Rollen an das Prinzip der geringsten Berechtigung. Wir empfehlen dringend, einfache Rollen wie „Inhaber“, „Bearbeiter“ und „Betrachter“ zu vermeiden. Gewähren Sie stattdessen vordefinierte Cloud KMS-Rollen, um das Risiko von Sicherheitsvorfällen im Zusammenhang mit überprivilegiertem Zugriff zu verringern. Wenn ein Hauptkonto beispielsweise nur Schlüsselmaterial importieren muss, weisen Sie ihm die Rolle „Cloud KMS-Importer“ (roles/cloudkms.importer) anstelle der freizügigeren Rolle „Cloud KMS-Administrator“ (roles/cloudkms.admin) zu.

Operative Vorkehrungen treffen

In den folgenden Abschnitten werden Kontrollen beschrieben, die Sie implementieren können, um Risiken wie eine inkonsistente Schlüsselnutzung oder versehentliches Löschen oder Vernichten zu minimieren.

Projektsperren erzwingen

Wir empfehlen, Projekte mit Sperren zu schützen (Vorabversion), um ein versehentliches Löschen Ihrer Cloud KMS-Projekte und der darin enthaltenen Schlüssel zu verhindern. Solange eine Projektsperre aktiv ist, kann das Projekt erst gelöscht werden, wenn die Sperre entfernt wird. Bei Projekten, die Cloud KMS-Schlüssel enthalten, wird so eine mögliche Ursache für das versehentliche Löschen von Schlüsseln verhindert.

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.

Cloud KMS Autokey erforderlich

Wenn Sie alle Ihre CMEKs mit Cloud KMS Autokey erstellen, werden Ihre Schlüssel einheitlich erstellt. Wenn Sie diese Konsistenz erzwingen möchten, können Sie einen Ordner so konfigurieren, dass CMEKs erforderlich sind, die von Autokey erstellt wurden, und verhindern, dass manuell erstellte Schlüssel für CMEK verwendet werden. Informationen zum Konfigurieren dieser Einschränkungen finden Sie unter Autokey-Verwendung erzwingen.

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 einem dauerhaften Datenverlust führen kann. Standardmäßig verwendet Cloud KMS einen Zeitraum von 30 Tagen für den Status Zum Löschen vorgemerkt (manchmal auch Zeitraum für das vorläufige 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 Admin“ 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 des Status Löschen 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 Organisationsrichtlinien-Einschränkung 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 kürzer ist als der in der Richtlinie angegebene Wert.

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.

Wenn Sie die Verwendung von Autokey erzwingen, werden alle Schlüssel hardwaregestützt sein.

Aufdeckungskontrollen für CMEKs konfigurieren

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

Audit-Logging aktivieren und zusammenfassen

Wir empfehlen, Cloud KMS-Audit-Logs zur Administratoraktivität 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 dies zu einem erheblichen Logvolumen führen und sich auf Ihre Kosten auswirken, da für jeden Vorgang von jedem Dienst, der CMEKs verwendet, Datenzugriffsprotokolle erstellt werden. Bevor Sie Datenzugriffsprotokolle aktivieren, sollten Sie einen klaren Anwendungsfall für die zusätzlichen Protokolle definieren und prüfen, wie sich Ihre Protokollierungskosten erhöhen.

Security Command Center für Cloud KMS-Schwachstellenergebnisse aktivieren

Security Command Center generiert Ergebnisse zu Sicherheitslücken, 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.

Monitoring und Abhilfemaßnahmen

Wir empfehlen, die Überprüfung der Schlüsselnutzung und die Einhaltung der empfohlenen Vorgehensweise zu einem zentralen Bestandteil Ihrer Monitoring-Strategie zu machen, da sie als entscheidende Kontrollmaßnahme dient, um Risiken und Fehlkonfigurationen in Ihrer CMEK-Einrichtung zu erkennen. Verfolgen Sie diese Ergebnisse, priorisieren Sie sie gemäß Ihren Sicherheitsverfahren und beheben Sie sie umgehend. Die folgenden Tools helfen Ihnen, Probleme zu identifizieren, die Sie beheben können, um Ihren Sicherheitsstatus zu verbessern:

  • Dashboard Verschlüsselungsstatistiken: Sie können Verschlüsselungsstatistiken aufrufen, um zu sehen, welche Ressourcen mit einem CMEK geschützt sind und wie gut diese CMEKs an den empfohlenen Praktiken ausgerichtet sind. Sie können Probleme identifizieren, die behoben werden müssen, indem Sie Listen von Ressourcen ansehen, die nicht durch einen CMEK geschützt sind, und Listen von Schlüsseln, die nicht vollständig den empfohlenen Vorgehensweisen entsprechen.

  • Dashboard Schlüsselnutzung: Sie können 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 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 reaktivieren. Die Informationen im Dashboard Schlüsselnutzung sind auch über die Cloud KMS Inventory API verfügbar.

Wir empfehlen Ihnen, 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.

Zusammenfassung der Best Practices

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

Thema Aufgabe
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 von den Schlüsseln geschützt werden.
Cloud KMS-Schlüsselbunde Erstellen Sie Cloud KMS-Schlüsselbunde für jeden Standort, 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 Cloudgespeichert werden muss. Wählen Sie „Single-tenant Cloud HSM“ aus, wenn Ihr Schlüsselmaterial auf dedizierten Partitionen auf Google Cloud-eigenen Hardwaresicherheitsmodulen (HSMs) gehostet werden muss. Wählen Sie Multi-Tenant Cloud HSM aus, wenn Ihr Schlüsselmaterial in Google Cloud-eigenen HSM-Clustern (Hardware Security Module) gehostet werden kann, die mit anderen Google Cloud Kunden geteilt werden. 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 Separate Berechtigungen für Schlüsseladministratoren und Identitäten, die Schlüssel verwenden, beibehalten.
Projektsperren Verwenden Sie Projektsperren, um ein versehentliches Löschen Ihrer wichtigsten Projekte zu verhindern.
CMEKs erzwingen 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