AWS KMS vs. Azure Key Vault vs. GCP KMS

AWS KMS, Azure Key Vault und GCP Cloud KMS sind die Managed Services der drei führenden Cloud-Anbieter zum Generieren, Speichern und Verwenden von Verschlüsselungsschlüsseln. Die Wahl des richtigen Anbieters ist wichtig, da jeder Anbieter ein anderes Sicherheits- und Zugriffsmodell implementiert. Ein späterer Wechsel erfordert eine Überarbeitung Ihrer Verschlüsselungsstrategie. Wir empfehlen Ihnen daher, den passenden Service für Ihre primäre Cloud-Umgebung und Ihre nativen Workloads auszuwählen und Ihr Schlüsselverwaltungsmodell (nativ, BYOK oder HYOK) explizit festzulegen, bevor Sie die Anzahl Ihrer Schlüssel erhöhen.

Veröffentlicht: Juli 2021. Aktualisiert: August 2026. Geprüft vom Cloud Key Management Advisory Team von Encryption Consulting.

Wenn Sie ausschließlich AWS und Azure nutzen und keine GCP-Integration planen, bietet unser detaillierterer Vergleich von AWS und Azure KMS eine umfassendere Analyse dieser Zwei-Cloud-Lösung. Dieser Artikel behandelt alle drei Anbieter und richtet sich an Teams, die eine Gesamtbewertung vornehmen.

Was sind AWS KMS, Azure Key Vault und GCP Cloud KMS?

AWS Key Management Service (KMS), Azure Key Vault und Google Cloud Key Management Service (Cloud KMS) sind die Managed-Lösungen der jeweiligen Cloud-Anbieter zum Erstellen, Speichern und Verwenden kryptografischer Schlüssel, ohne dass eigene Hardware-Sicherheitsmodule (HSMs) betrieben werden müssen. Alle drei folgen demselben Konzept: Ein vom Dienst verwalteter Schlüsselverschlüsselungsschlüssel (KEK) schützt Datenverschlüsselungsschlüssel (DEKs), die wiederum Ihre eigentlichen Daten schützen. Der KEK selbst wird Ihnen niemals unverschlüsselt zurückgegeben. Die Unterschiede liegen in der Terminologie des Schlüsselmanagements , der IAM-Integration, den Standardeinstellungen für die Schlüsselrotation und dem Umfang, in dem Sie die Kontrolle über das Schlüsselmaterial außerhalb des Anbieters ausüben können.

AWS hat seine ursprüngliche Bezeichnung „Customer Master Key (CMK)“ vor Jahren in KMS-Schlüssel umbenannt. Die aktuelle AWS-Dokumentation unterscheidet zwischen kundenverwalteten Schlüsseln , AWS-verwalteten Schlüsseln und AWS-eigenen Schlüsseln . Azure Key Vault stellt Schlüssel in den Tarifen Standard (softwaregeschützt, mandantenfähig) und Premium (gemeinsamer HSM-Pool) sowie als separates Managed-HSM- Produkt für dedizierte Hardware für Einzelmandanten bereit. GCP Cloud KMS bietet Software- , HSM- und externe Schlüssel als drei unterschiedliche Schutzstufen innerhalb eines einzigen Dienstes an.

Wie unterscheiden sich native Schlüsselspeichermodelle?

Jeder Anbieter hat standardmäßig ein anderes Hardware-Validierungsniveau und eine andere Unterstützung für verschiedene Schlüsseltypen, was bestimmt, was Sie tun können, ohne auf einen Premium-Tarif umzusteigen.

Funktion	AWS-KMS	Azure Key Vault	GCP Cloud KMS
Standard-Schlüsselschutz	FIPS 140-2 validiertes HSM (alle Schlüssel)	Software (Standard) oder gemeinsam genutzter HSM-Pool (Premium)	Software, HSM oder extern, Auswahl pro Schlüssel
Dedizierte HSM-Option für einen einzelnen Mandanten	Über die CloudHSM-Integration	Managed HSM (FIPS 140-3 Level 3, Marvell LiquidSecurity)	Single-Tenant Cloud HSM
Unterstützte Schlüsseltypen	Symmetrisch, asymmetrisch (RSA, ECC), HMAC	RSA und elliptische Kurve (asymmetrisch); kein nativer symmetrischer Schlüsseltyp	Symmetrisch (AES-256) und asymmetrisch (RSA, ECC)
Wichtige Portabilität	Verlässt niemals die AWS-Region, in der es erstellt wurde.	Verlässt niemals den Tresorraum; Microsoft gibt an, keine Schlüsseldaten einsehen zu können.	Verlässt niemals den Platz am Schlüsselbund

Sollten Sie in diesen Clouds native Schlüssel, BYOK oder HYOK verwenden?

Verwenden Sie standardmäßig die nativen Schlüssel des jeweiligen Anbieters, wechseln Sie zu BYOK, wenn Sie die Herkunft eines Schlüssels nachweisen müssen, und reservieren Sie HYOK für die spezifischen Schlüssel, die laut Aufsichtsbehörde oder Vertrag niemals die Infrastruktur des Cloud-Anbieters berühren dürfen. Alle drei Cloud-Anbieter unterstützen alle drei Modelle, die Funktionsweise von HYOK unterscheidet sich jedoch so stark, dass eine Anpassung Ihrer Architektur erforderlich sein kann.

Modell	AWS-KMS	Azure Key Vault	GCP Cloud KMS
Ureinwohner	Vom KMS generierter Schlüssel, niemals exportierbar	Vault- oder Managed-HSM-generierter Schlüssel	Cloud-KMS-generierter Schlüssel
BYOK	Importieren Sie das Schlüsselmaterial mit RSA-Verschlüsselung; AWS verfügt über eine nutzbare Kopie.	Importieren Sie HSM-geschützte Schlüsseldaten aus einem lokalen HSM in ein Managed HSM.	Importieren Sie das Schlüsselmaterial (AES-256 verschlüsselt mit RSA 3072-Bit)
HYOK	Externer Schlüsselspeicher (XKS): Doppelte Verschlüsselung, der Schlüssel verlässt niemals Ihren externen Schlüsselmanager.	Externes Schlüsselmanagement (Vorschau): Verpacken/Entpacken wird an einen vom Kunden betriebenen EKM-Proxy delegiert; nicht durch die Managed HSM-SLA abgedeckt.	Cloud External Key Manager (EKM): Zweischichtige Verschlüsselung über Fortanix, Futurex oder Thales; eine Anfrage schlägt fehl, wenn der externe Schlüssel nicht erreichbar ist.

Jede HYOK-Implementierung birgt denselben Kompromiss: Sie erhalten nachweisbare Kontrolle über den Schlüssel, tragen aber das Betriebsrisiko der Verfügbarkeit Ihres externen Schlüsselmanagers. Google weist explizit auf die Nachteile hin – insbesondere bei Cloud Spanner führt ein EKM-Schlüssel, der länger als 30 Tage nicht erreichbar ist, zu dauerhaftem Datenverlust, da Google angibt, Daten, die durch einen nie besessenen Schlüssel geschützt sind, nicht wiederherstellen zu können. Weitere Informationen zum BYOK-vs.-HYOK-Kompromisse finden Sie in unserer Erklärung zu hybriden KMS- Systemen sowie zu dedizierten vs. gemeinsam genutzten HSMs, die erläutern, wie sich die Entscheidungen zur Schlüsselverwaltung und -isolation auf die HSM-Beschaffung auswirken.

Wie unterscheidet sich das IAM-Modell bei AWS, Azure und GCP?

Alle drei nutzen das allgemeine Identitätssystem ihrer Plattform für den Schlüsselzugriff, ergänzt durch ein KMS-spezifisches Berechtigungs- oder Richtlinienmodell – keines der Systeme hat ein separates Identitätssystem nur für Schlüssel erfunden.

• AWS-KMS Es kombiniert identitätsbasierte IAM-Richtlinien mit einer obligatorischen Schlüsselrichtlinie, die jedem KMS-Schlüssel zugeordnet ist, sowie temporären Berechtigungen für konto- oder dienstübergreifenden Zugriff. Die Konfiguration nach dem Prinzip der minimalen Berechtigungen bedeutet, den Zugriff zu verweigern. kms:CreateGrant außer wenn eine Verschlüsselungskontextbedingung mit einem genehmigten Schlüssel-ARN übereinstimmt.
• Azure Key Vault Unterstützt sowohl ältere Tresorzugriffsrichtlinien als auch Azure RBAC; Managed HSM verwendet ein separates, lokales RBAC-System, das von Azure-Abonnementadministratoren nicht überschrieben werden kann, und genau das ist der Sinn – es ist so konzipiert, dass sich selbst Microsoft-Supportmitarbeiter keinen Zugriff auf Schlüsselfunktionen gewähren können.
• GCP Cloud KMS wird vollständig durch Cloud-IAM-Rollen gesteuert, wie zum Beispiel roles/cloudkms.cryptoKeyEncrypterDecrypter nur für den Zugriff und roles/cloudkms.admin für das Management, wobei Google ausdrücklich eine Trennung der Aufgaben zwischen den beiden empfiehlt.

Ein auf allen drei Anbietern funktionierendes Least-Privilegy-Setup folgt unabhängig vom Anbieter denselben fünf Schritten:

1. Trennen Sie Produktions- und Nicht-Produktionsschlüssel in verschiedenen Konten, Abonnements oder Projekten, damit eine kompromittierte Testidentität niemals einen Produktionsschlüssel erreichen kann.
2. Vergeben Sie Berechtigungen zum Verschlüsseln/Entschlüsseln (Verwenden) und zur Schlüsselverwaltung an verschiedene Rollen – niemals an dieselbe Rolle.
3. Jede Berechtigung sollte auf eine bestimmte Schlüsselressource beschränkt werden, niemals auf einen Platzhalter, und zwar mithilfe von Ressourcen-ARNs (AWS), bereichsbezogenen RBAC-Zuweisungen (Azure) oder IAM-Bedingungen (GCP).
4. Für jede Aktion, die einen Schlüssel oder Tresor löschen oder dessen Löschung planen kann, ist eine Multi-Faktor-Authentifizierung (MFA) oder ein Workflow für privilegierten Zugriff erforderlich.
5. Überprüfen Sie die Zugriffsrechte vierteljährlich mithilfe der jeweiligen anbietereigenen Tools – IAM Access Analyzer (AWS), Azure AD-Zugriffsüberprüfungen (Azure) oder IAM Recommender (GCP).

Wie funktioniert die Schlüsselrotation in den einzelnen Diensten?

Die Rotation erfolgt bei symmetrischen Schlüsseln in allen drei Diensten automatisch, jedoch unterscheiden sich der konfigurierbare Bereich und die festen Grenzwerte so stark, dass dies Auswirkungen auf Ihre Compliance-Dokumentation haben kann.

• AWS-KMSDie automatische Rotation symmetrischer Schlüssel ist zwischen 90 und 2,560 Tagen (ca. sieben Jahren) konfigurierbar. Asymmetrische und HMAC-Schlüssel sind davon ausgeschlossen und müssen durch die Erstellung eines neuen Schlüssels rotiert werden. Importiertes Schlüsselmaterial unterstützt die Rotation auf Abruf, bis zu zehnmal während der gesamten Lebensdauer des Schlüssels. Die ersten beiden Rotationen eines Schlüssels erhöhen die Kosten um jeweils 1 US-Dollar pro Monat; danach ist die Preiserhöhung begrenzt.
• Verwaltetes HSM von Azure Key VaultDie Richtlinien für die automatische Schlüsselrotation basieren auf der Erstellung oder dem Ablaufdatum und haben ein Mindestintervall von 28 Tagen. Microsoft empfiehlt, die Schlüssel gemäß NIST SP 800-57 mindestens alle zwei Jahre zu rotieren. Jeder Schlüssel ist auf maximal 100 Versionen begrenzt; Rotationen werden auf dieses Limit angerechnet. Standard- und Premium-Key-Vault (ohne Managed-HSM) bieten keine integrierte automatische Schlüsselrotation und verwenden in der Regel Azure Automation oder Event Grid zur Rotationssteuerung.
• GCP Cloud KMSDie automatische Rotation symmetrischer Schlüssel ist von einem Tag bis zu 100 Jahren konfigurierbar; asymmetrische Signatur- und Verschlüsselungsschlüssel sind von der automatischen Rotation ausgeschlossen. Die Rotation eines Schlüssels deaktiviert oder verschlüsselt keine Daten, die durch ältere Schlüsselversionen geschützt sind – diese Versionen müssen nach ihrer Außerkraftsetzung manuell deaktiviert oder gelöscht werden.

Was sollten Sie in den einzelnen Cloud-Umgebungen protokollieren und überwachen?

Aktivieren Sie die Protokollierung, bevor Sie Ihren ersten Schlüssel in einem der drei Dienste erstellen, und nicht erst, nachdem ein Vorfall diese Frage aufwirft.

• AWSCloudTrail erfasst jeden KMS-Verwaltungsaufruf (Erstellen, Rotieren, Deaktivieren, Bearbeiten von Richtlinien) und jeden kryptografischen Aufruf (Verschlüsseln, Entschlüsseln, Generieren von Datenschlüsseln), einschließlich der aufrufenden Identität und der Quell-IP-Adresse.
• AzureKey Vault gibt eine AuditEvent Die Diagnoseprotokollkategorie wird über die Azure Monitor-Diagnoseeinstellungen ermittelt und kann zur langfristigen Aufbewahrung an Log Analytics, einen Event Hub oder einen Speicher weitergeleitet werden.
• GCP: Cloud-Audit-Protokolle zeichnen sowohl Administratoraktivitäten (Verwaltungsvorgänge, immer aktiv, kann nicht deaktiviert werden) als auch Datenzugriffsprotokolle (Schlüsselverwendung, muss explizit aktiviert werden) für jeden Cloud-KMS-Schlüssel auf.

Egal für welche Cloud Sie sich entscheiden, speisen Sie diese Protokolle in ein SIEM-System ein und lassen Sie sich speziell über das Löschen von Schlüsseln, Richtlinienänderungen und Export- oder Wrap-/Unwrap-Ereignisse in Bezug auf HYOK-Schlüssel alarmieren – dies sind die Aktionen, die eine routinemäßige Schlüsseloperation in einen Vorfall verwandeln.

Wie schneiden AWS KMS, Azure Key Vault und GCP Cloud KMS im Kostenvergleich ab?

Keines der drei Preismodelle lässt sich eindeutig vergleichen – AWS berechnet pro Schlüssel, GCP berechnet pro Schlüsselversion pro Schutzstufe und Azure berechnet pro Operation zuzüglich eines separaten HSM-Schlüsselzuschlags.

Provider	Grundschlüsselkosten	Einkauf & Prozesse	HYOK / externe Option
AWS-KMS	1.00 €/Schlüssel/Monat, pauschal unabhängig vom Schlüsseltyp	0.03 $/10,000 Anfragen (20,000 kostenlos/Monat)	Externer Schlüsselspeicher: dieselbe Gebühr von 1 US-Dollar pro Monat, zuzüglich der Kosten für Ihre eigene Schlüsselverwaltungsinfrastruktur.
Azure Key Vault	Software-Schlüssel: keine separate Speichergebühr; HSM-geschützte Schlüssel: ca. 1–5 US-Dollar/Schlüssel/Monat, gestaffelt nach Datenvolumen.	~0.03 $/10,000 Operationen (Software), ~0.15 $/10,000 für erweiterte Schlüsseloperationen	Externes Schlüsselmanagement: Vorschau, noch kein separater Preis veröffentlicht
GCP Cloud KMS	0.06 $/Schlüsselversion/Monat (Software), 1.00 $/Schlüsselversion/Monat (HSM)	0.03 $/10,000 Operationen (0.15 $/10,000 für bestimmte HSM-Operationen)	EXTERNAL/EXTERNAL_VPC (EKM): 3.00 $/Schlüsselversion/Monat

Die genauen Preise für Azure variieren je nach Region und werden zum Zeitpunkt der Erstellung dieses Dokuments nicht als feste globale Preise auf der Microsoft-Preisseite veröffentlicht. Die oben genannten Zahlen dienen daher lediglich als Richtwerte. Bitte prüfen Sie die aktuellen regionalen Preise, bevor Sie Ihr Budget festlegen. Ein Cloud-HSM für einen einzelnen Mandanten auf der GCP kostet pauschal etwa 3,500 US-Dollar pro Monat und beinhaltet 15,000 Lizenzschlüssel ohne zusätzliche Kosten. Dies kann bei tatsächlicher Skalierung günstiger sein als die Abrechnung pro Lizenz für ein HSM.

Wie sieht eine Multi-Cloud-Schlüsselverwaltungsarchitektur aus?

Wenn Sie alle drei Cloud-Dienste nutzen oder dies planen, behandelt das sicherere Design die KMS-Systeme der einzelnen Anbieter als regionale Kontrollinstanz unter einer zentralen Schlüssel- und Zertifikatsverwaltungsebene, anstatt drei unabhängige Datenquellen zu verwenden, die sich im Laufe der Zeit auseinanderentwickeln. Diese Ebene verfolgt, welche Schlüssel wo existieren, welches Schutzniveau und welche Rotationsrichtlinie jeweils verwendet wird und welches Team dafür zuständig ist – eine Aufgabe, die weder AWS KMS, Azure Key Vault noch GCP Cloud KMS anbieterübergreifend für Sie erledigen.

Die vollständige Referenzarchitektur finden Sie in unserem Leitfaden zur Multi-Cloud-PKIaaS-Architektur für AWS, Azure und GCP . Um zu verstehen, warum dies bereits vor der Nutzung von drei Clouds relevant ist, bietet unser Schulungszentrum Informationen zum Multi-Cloud-Schlüsselmanagement und den gemeinsamen Funktionen kommerzieller Schlüsselmanagementlösungen.

Welche Einschränkungen hat jeder Dienst?

• AWS-KMS: Ein Schlüssel verlässt niemals die Region, in der er erstellt wurde. Daher benötigt eine Multi-Region-Strategie explizite Multi-Region-Schlüssel und keinen Standardwert. KMS kann einen Datenschlüssel nicht zum Ver- oder Entschlüsseln in Ihrem Namen verwenden, daher müssen Anwendungen dies selbst handhaben.
• Azure Key Vault: Die externe Schlüsselverwaltung befindet sich noch in der Vorschauphase, ist nicht durch die Managed HSM SLA abgedeckt und unterstützt nur das Ein- und Auspacken; Managed HSM begrenzt jeden Schlüssel auf 100 Versionen, und häufige Rotationen werden auf diese Obergrenze angerechnet.
• GCP Cloud KMSCloud EKM unterstützt derzeit nur drei namentlich genannte externe Partner für das Schlüsselmanagement (Fortanix, Futurex, Thales); die Rotation eines Schlüssels verschlüsselt Daten unter alten Versionen nie automatisch neu, daher müssen ausgemusterte Versionen manuell bereinigt werden, um Kosten und Risiken zu kontrollieren.

Entscheidungscheckliste: Auswahl zwischen AWS KMS, Azure Key Vault und GCP Cloud KMS

1. Beginnen Sie dort, wo Ihre Workloads bereits vorhanden sind. Die native Integration mit Ihren Rechen-, Speicher- und Datenbankdiensten wiegt die geringfügigen Funktionsunterschiede zwischen den drei KMS-Angeboten auf.
2. Legen Sie Ihr Schlüsselsteuerungsmodell pro Datenklassifizierung fest.nicht nur einmal für die gesamte Organisation – nativ für die meisten Arbeitslasten, BYOK, wenn wichtige Herkunftsnachweise dokumentiert werden müssen, HYOK nur dann, wenn dies von einer Aufsichtsbehörde oder einem Vertrag vorgeschrieben ist.
3. Ordnen Sie Ihre Rotationsrichtlinie den tatsächlichen Beschränkungen jedes Anbieters zu. — Insbesondere die Mindestlaufzeit von 28 Tagen und die Beschränkung auf 100 Versionen bei Azure Managed HSM müssen von vornherein berücksichtigt werden und dürfen nicht erst bei einem Audit entdeckt werden.
4. Modellkosten bei Ihrem tatsächlichen Schlüssel- und BetriebsvolumenNicht die in der Überschrift genannte Zahl pro Schlüssel oder pro Operation – die Preisgestaltung von GCP pro Schutzstufe und die gestaffelten HSM-Schlüsselgebühren von Azure ändern sich beide bei großem Umfang erheblich.
5. Wenn Sie heute mehr als eine Cloud betreiben oder dies innerhalb der nächsten 18 Monate erwartenEvaluieren Sie eine zentrale Schlüssel- und Zertifikatsverwaltungsschicht, bevor Sie drei unabhängige, voneinander abweichende KMS-Konfigurationen abgleichen müssen.

Was würde Encryption Consulting empfehlen?

Für eine Single-Cloud-Umgebung empfiehlt sich der Einsatz des nativen KMS dieser Cloud – alle drei sind ausgereifte, FIPS-konforme Dienste. Die Entscheidung wird erst dann wirklich schwierig, wenn Sie zwei oder mehr Clouds nutzen, da weder AWS KMS, Azure Key Vault noch GCP Cloud KMS eine übergreifende Übersicht über die anderen Clouds bieten. In unseren Projekten haben sich vor allem Organisationen als schwierig erwiesen, die die KMS jeder Cloud unabhängig voneinander eingeführt und anschließend versucht haben, Governance-Lösungen nachträglich zu implementieren. Wir empfehlen, Ihr Schlüsselverwaltungsmodell (nativ, BYOK oder HYOK) sowie Ihre Rotations- und Protokollierungsstandards zentral über HSM-as-a-Service für FIPS-konforme, anbieterübergreifende Schlüsselverwaltung festzulegen, bevor einzelne Teams die Standardeinstellungen ihrer Cloud-Konsole übernehmen. Benötigen Sie eine externe Bewertung Ihrer aktuellen Multi-Cloud-Schlüsselverwaltung? Unsere Cloud-Datenschutz-Bewertung vergleicht AWS-, Azure- und GCP-Umgebungen mit den NIST- und CIS-Kontrollen.

Häufig gestellte Fragen

Welches System ist sicherer: AWS KMS, Azure Key Vault oder GCP Cloud KMS?

Alle drei sind FIPS-validierte Managed Services von Anbietern mit langjähriger Sicherheitsbilanz. Keiner ist bei der standardmäßigen Verwendung nativer Schlüssel grundsätzlich weniger sicher als die anderen. Die wesentlichen Sicherheitsunterschiede zeigen sich im Detail: Hardware-Validierungsstufe pro Ebene, ob HYOK allgemein verfügbar oder noch in der Vorschauphase ist und wie umfassend IAM und Protokollierung konfiguriert werden – nicht im Logo des Anbieters.

Kann ich denselben Verschlüsselungsschlüssel für AWS, Azure und GCP verwenden?

Nicht direkt. Der native Schlüssel jedes Anbieters verlässt systembedingt nie dessen Grenzen. Die beste Annäherung an einen gemeinsamen Schlüssel über mehrere Clouds hinweg ist HYOK: Dabei werden die Schlüsseldaten in einem eigenen externen Schlüsselmanager gespeichert, auf den jede Cloud zugreift (z. B. AWS External Key Store, Azure External Key Management oder GCP Cloud EKM). So kann eine einzige Schlüsselquelle mehrere Clouds bedienen, allerdings wird der externe Schlüsselmanager dadurch zu einem Single Point of Failure für alle diese Clouds.

Ist Azure Key Vault Managed HSM dasselbe wie HYOK?

Nein. Managed HSM ist eine dedizierte Hardwarelösung für einen einzelnen Mandanten, die weiterhin innerhalb der Microsoft-Infrastruktur läuft – es handelt sich um eine leistungsfähigere Option für native Schlüssel, nicht um eine externe. Das Azure-Äquivalent zu HYOK ist die externe Schlüsselverwaltung, eine separate Preview-Funktion, die das Verpacken und Entpacken von Schlüsseln an einen Schlüsselmanager delegiert, der außerhalb von Azure ausgeführt wird.

Warum berechnet GCP für externe (EKM-)Schlüssel mehr als für HSM-Schlüssel?

Google berechnet für die Schlüsselversionen EXTERNAL und EXTERNAL_VPC 3.00 US-Dollar pro Monat, das Dreifache des HSM-Tarifs von 1.00 US-Dollar pro Monat. Der Grund dafür ist, dass jede kryptografische Operation mit einem EKM-Schlüssel einen Live-Netzwerkzugriff auf den externen Schlüsselmanager erfordert, anstatt eines lokalen HSM-Aufrufs. Diese zusätzliche Latenz und Abhängigkeit ist auch der Grund, warum Google ausdrücklich davor warnt, dass der Verlust des Zugriffs auf einen externen Schlüssel zu dauerhaftem und unwiederbringlichem Datenverlust führen kann.

Benötige ich eine Multi-Cloud-Schlüsselverwaltungsstrategie, wenn ich derzeit nur eine Cloud nutze?

Nicht sofort, aber es lohnt sich, Ihr Schlüsselverwaltungsmodell, Ihre Rotationsrichtlinie und Ihren Protokollierungsstandard so festzulegen, als ob Sie eine zweite Cloud hinzufügen würden. Denn diese Entscheidungen nachträglich anzupassen, ist deutlich aufwändiger, als sie von Anfang an konsequent zu definieren. Falls eine zweite Cloud bereits geplant ist, sollten Sie die entsprechende Governance-Ebene jetzt und nicht erst nach der Migration einrichten.

Kontaktieren Sie [email protected] , wenn Sie Unterstützung bei der Prüfung oder Architektur des Schlüsselmanagements in AWS, Azure und GCP benötigen.