Die Aufgabentrennung ist ein Konzept, mit dem verhindert werden soll, dass ein Hauptkonto allein über alle Berechtigungen verfügt, die notwendig sind, um bösartige Aktionen auszuführen. Im Cloud Key Management Service könnte eine solche Aktion z. B. darin bestehen, dass ein Nutzer mit einem Schlüssel auf Daten zugreift und sie entschlüsselt, obwohl er keinen gültigen Grund für den Zugriff hat.
Die Aufgabentrennung ist eine Form der Unternehmenssteuerung, die in der Regel in größeren Organisationen umgesetzt wird. Sie dient dazu, Sicherheits- und Datenschutzvorfälle sowie Fehler zu vermeiden und gilt als Best Practice.
In Cloud KMS erfordert die Aufgabentrennung eine strikte Unterscheidung zwischen den folgenden Rollen:
- Schlüsselmanager: Hauptkonten, die berechtigt sind, den Lebenszyklus von Schlüsseln zu verwalten, einschließlich Erstellung, Löschung, Rotation und Statusänderungen. Dazu gehören beispielsweise Nutzer mit der Rolle Cloud KMS-Administrator.
- Schlüsselnutzer: Hauptkonten, die berechtigt sind, Schlüssel zu verwenden, einschließlich Verschlüsselung, Entschlüsselung, Signierung oder Signaturprüfung. Dazu gehören beispielsweise Nutzer mit der Rolle Cloud KMS CryptoKey Encrypter/Decrypter.
Wenn Sie Cloud KMS-Schlüssel für vom Kunden verwaltete Verschlüsselungsschlüssel verwenden, empfehlen wir, dass das Dienstkonto das einzige Hauptkonto ist, das berechtigt ist, den Schlüssel für die Verschlüsselung und Entschlüsselung zu verwenden. Weitere Informationen dazu, wie CMEK-Integrationen den Ressourcenzugriff verarbeiten, finden Sie unter Ressourcenzugriff durch CMEK-integrierte Dienste verarbeiten.
Wenn Sie eine Leitplanke erstellen möchten, um diese Empfehlung zu erzwingen, können Sie IAM-Ablehnungsrichtlinien verwenden, um anderen Hauptkonten als Dienstkonten die Berechtigungen für die Verschlüsselung und Entschlüsselung zu entziehen. Weitere Informationen zur sicheren Verwendung von IAM-Rollen finden Sie unter IAM sicher verwenden.
Schlüssel-Governance
Die Schlüssel-Governance beschreibt, wer in einer Organisation für die Verwaltung des Lebenszyklus Ihrer Cloud KMS-Ressourcen und die Aufrechterhaltung von Leitplanken zur Steuerung der Verwendung von Cloud KMS verantwortlich ist. Es gibt verschiedene Ansätze für die Schlüssel-Governance, von der zentralen Governance bis zur delegierten Governance:
- Zentrale Governance: Ein dediziertes Sicherheits- oder Plattformteam ist für die Verwaltung des Lebenszyklus aller kryptografischen Schlüssel in der Organisation verantwortlich. Dieses Modell wird häufig von stark regulierten Unternehmen mit strengen Compliance-Anforderungen gewählt.
- Delegierte Governance: Ein zentrales Sicherheitsteam verwendet Leitplanken, um Verschlüsselungsstandards vorzuschreiben, delegiert aber die Verantwortung für Vorgänge im Lebenszyklus von Schlüsseln an Anwendungsbesitzer in ihren Projekten. Diese Leitplanken können Organisationsrichtlinien mit verwalteten Beschränkungen und benutzerdefinierten Einschränkungen sowie IAM-Zuweisungen und -Ablehnungsrichtlinien umfassen. Dadurch werden zentrale operative Engpässe vermieden.
Schlüsselspeicherung
Die Schlüsselspeicherung beschreibt, wo Cloud KMS-Ressourcen in einer Organisation erstellt werden. Es gibt zwei Hauptansätze für die Schlüsselspeicherung: Schlüsselspeicher im dedizierten Projekt und Schlüsselspeicher im selben Projekt.
- Schlüsselspeicher im dedizierten Projekt: Ein dediziertes Schlüsselprojekt enthält Schlüssel, die für mehrere Anwendungen verwendet werden. In der Regel hat jeder Umgebungsordner ein eigenes Schlüsselprojekt. Sie können Autokey mit Schlüsselspeicher im dedizierten Projekt verwenden.
- Schlüsselspeicher im selben Projekt: Schlüssel werden im selben Google Cloud Projekt wie die Ressourcen gespeichert, die sie schützen. Manchmal wird dies als „Der Schlüssel folgt den Daten“ bezeichnet. Sie können Autokey mit Schlüsselspeicher im selben Projekt verwenden.
Governance und Speicherung abstimmen
Die folgende Matrix enthält Beispiele dafür, wie diese Governance- und Speichermodelle kombiniert werden können, um die unterschiedlichen Anforderungen von Organisationen 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 gesetzlichen Anforderungen, die die Isolation von Projektgrenzen vorschreiben. Betriebliche Auswirkungen: Hohe Einrichtungskomplexität. Erfordert eine robuste Automatisierung (z. B. eine „Projektfabrik“), um betriebliche Verzögerungen für Entwicklungsteams zu vermeiden. |
Gesteuerte Inhaberschaft Empfohlene Verwendung: Organisationen, die eine zentrale Sicherheit Aufsicht benötigen, aber die Geschwindigkeit der Entwickler maximieren möchten. Betriebliche Auswirkungen: Geringe Einrichtungskomplexität. Die zentrale Sicherheit erzwingt Richtlinien mithilfe von Leitplanken, während sich Schlüssel zur einfacheren 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 widerspricht dem Zweck, die Schlüsselverwaltung an Anwendungsteams zu delegieren. |
Autonome DevOps Empfohlene Verwendung: Dezentrale Organisationen mit hoher Geschwindigkeit und einer starken DevOps-Kultur. Betriebliche Auswirkungen: Minimale Einrichtungskomplexität. Anwendungsteams haben innerhalb ihrer Projekt grenzen die volle Autonomie über Ressourcen und Schlüssel. |
Schlüsselspeicher im selben Projekt
Um die Aufgabentrennung in der Schlüsselverwaltung im selben Projekt zu erzwingen, müssen IAM-Rollen strikt getrennt werden. Sie können beispielsweise IAM-Ablehnungsrichtlinien verwenden, um Ihren Schlüsselmanagern die Berechtigungen für die Verschlüsselung und Entschlüsselung zu entziehen.
Sie können Autokey mit Schlüsselspeicher im selben Projekt für ein Projekt oder einen Ordner aktivieren, um die automatische Schlüsselerstellung im selben Projekt wie die Ressource zu ermöglichen, die der Schlüssel schützt. Weitere Informationen finden Sie unter Autokey mit Schlüsselspeicher im selben Projekt aktivieren.
Schlüsselspeicher im dedizierten Projekt
Im Modell für die Schlüsselspeicherung im dedizierten Projekt werden dedizierte Schlüsselprojekte von einem zentralen Sicherheitsteam verwaltet, das über Berechtigungen zur Schlüsselverwaltung im Schlüsselprojekt verfügt, aber keinen Zugriff auf Projekte hat, die die durch diese Schlüssel geschützten Ressourcen enthalten.
Sie können Autokey mit Schlüsselspeicher im dedizierten Projekt für einen Ordner aktivieren, um die automatische Schlüsselerstellung mit dem zentralen Schlüsselspeichermodell zu ermöglichen. Weitere Informationen finden Sie unter Autokey mit Schlüsselspeicher im dedizierten Projekt einrichten.
Compliance automatisieren und überwachen
Google Cloud bietet die folgenden Tools zum Automatisieren und Überwachen Ihrer Sicherheitsgrenzen:
- Cloud KMS Autokey: Autokey unterstützt sowohl die Schlüsselspeicherung im dedizierten Projekt als auch die Schlüsselspeicherung im selben Projekt. In beiden Fällen wird die Aufgabentrennung automatisiert, indem die Rolle für die Schlüsselnutzung automatisch dem erforderlichen Dienst-Agenten zugewiesen wird, nicht der Person, die den Schlüssel anfordert. Autokey wurde entwickelt, um Infrastruktur-als-Code-Pipelines zu unterstützen, die keine erhöhten Berechtigungen für die Schlüsselerstellung benötigen.
- Security Command Center: Überwachen Sie die Ergebnisse von KMS Role Separation, um Hauptkonten zu erkennen, einschließlich eines Projektinhaber oder eines Google-Dienstkontos, die sowohl administrative als auch kryptografische Berechtigungen für einen einzelnen Schlüssel haben.
- CMEK-Verschlüsselungsmesswerte: Mit dem Dashboard Encryption metrics können Sie prüfen, ob die Aufgabentrennung in der gesamten Organisation eingehalten wird.