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 ausführen zu können. 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 eigentlich keinen Zugriff haben sollte.
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 Dies gilt als Best Practice.
In Cloud KMS erfordert die Aufgabentrennung eine strikte Unterscheidung zwischen den folgenden Rollen:
- Schlüsselmanager: Identitäten, die berechtigt sind, den Lebenszyklus von Schlüsseln zu verwalten, einschließlich Erstellung, Löschung, Rotation und Statusänderungen, z. B. Nutzer mit der Rolle Cloud KMS-Administrator.
- Schlüsselnutzer: Identitäten, die berechtigt sind, Schlüssel für Verschlüsselung, Entschlüsselung, Signierung oder Signaturprüfung zu verwenden, z. B. 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 Prinzipal 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 in Diensten mit CMEK-Integration.
Wenn Sie eine Leitplanke erstellen möchten, um diese Empfehlung zu erzwingen, können Sie IAM-Ablehnungsrichtlinien verwenden, um Verschlüsselungs- und Entschlüsselungsberechtigungen von anderen Hauptkonten als Dienstkonten zu entfernen. Weitere Informationen zur sicheren Verwendung von IAM-Rollen finden Sie unter IAM sicher verwenden.
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.
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.
Schlüsselspeicher im selben Projekt: Schlüssel werden im selbenCloud de Confiance -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.
Governance und Speicher abstimmen
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. |
Schlüsselspeicher im selben Projekt
Um die Trennung von Aufgaben bei 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üsseladministratoren die Berechtigungen zum Verschlüsseln und Entschlüsseln 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 durch den Schlüssel geschützt wird. Weitere Informationen finden Sie unter Autokey mit Schlüsselspeicher im selben Projekt aktivieren.
Schlüsselspeicher im dedizierten Projekt
Im dedizierten Projektschlüsselspeichermodell werden dedizierte Schlüsselprojekte von einem zentralen Sicherheitsteam verwaltet, das über Schlüsselverwaltungsberechtigungen 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 dedizierter Projektschlüsselspeicherung für einen Ordner aktivieren, um die automatisierte Schlüsselerstellung mit dem zentralen Schlüsselspeichermodell zu ermöglichen. Weitere Informationen finden Sie unter Autokey mit dedizierter Projektschlüsselspeicherung einrichten.
Compliance automatisieren und überwachen
Cloud de Confiance bietet die folgenden Tools zum Automatisieren und Überwachen Ihrer Sicherheitsgrenzen:
- Cloud KMS Autokey: Autokey unterstützt sowohl den Schlüsselspeicher im dedizierten Projekt als auch den Schlüsselspeicher im selben Projekt. In beiden Fällen wird die Funktionstrennung automatisiert, indem die Rolle für die Schlüsselnutzung automatisch dem erforderlichen Dienst-Agent und nicht der Person gewährt wird, die den Schlüssel anfordert. Autokey wurde für die Unterstützung von Infrastructure-as-Code-Pipelines entwickelt, für die keine erhöhten Berechtigungen zum Erstellen von Schlüsseln erforderlich sind.
- Security Command Center: Achten Sie auf Ergebnisse zu KMS-Rollentrennung, um alle Principals zu erkennen, einschließlich eines Projektinhaber oder eines Google-Dienstkontos, die sowohl administrative als auch kryptografische Berechtigungen für einen einzelnen Schlüssel haben.
- Messwerte für die CMEK-Verschlüsselung: Mit dem Dashboard Verschlüsselungsmesswerte können Sie die Einhaltung der Grundsätze zur Trennung von Aufgaben in der gesamten Organisation überprüfen.