Schlüsselmanagement in der Cloud : Bewertung der Funktionalität von Azure Key Vault und Cloud Key Management Service

Kryptografie und im Besonderen Verschlüsselung werden an verschiedenen Stellen des IT-Grundschutzes als mögliche Sicherheitsmaßnahmen genannt. Auch gesetzliche Vorgaben wie die EU-Datenschutzgrundverordnung (DSGVO) können dazu führen, dass man Verschlüsselung einsetzen oder noch einführen muss – all das gilt auch, wenn Daten mittels Cloud-Computing verarbeitet und gespeichert werden. Doch wie werden dann kryptografische Schlüssel gesichert?

In diesem Artikel werden die Schlüsselmanagement-Services von Microsoft Azure (kurz: Azure) und der Google Cloud Platform (kurz: GCP) vorgestellt und bewertet. Beide beschriebenen Cloud-Diensteanbieter gehören zu den Marktführern unter den Cloud-Diensteanbietern nach Gartner – die Wahl fiel auf Azure und GCP, da es sich in beiden Fällen um Angebote von „Infrastructure / Platform as a Service“ handelt (IaaS/PaaS).

Schlüsselmanagement-Dienste von Cloud-Anbietern sollten interessierte Kunden unbedingt bereits in der Planungsphase beachten und bewerten. Sie sollten kryptografische Schlüssel und wenn möglich auch Zertifikate sicher speichern, sodass Unberechtigte keinen Zugriff erhalten können und man vor Datenverlust geschützt ist – denn ohne eine Sicherung kryptografischer Schlüssel und Zertifikate sind verschlüsselte Daten ja nicht mehr dechiffrierbar, was einem Verlust dieser Daten gleichkommt.

Verfügbarkeit

Wie bei allen Cloud-Diensten führt ein Netzwerkausfall (Gefährdung G 0.9 „Ausfall oder Störung von Kommunikationsnetzen“) zur Nichterreichbarkeit – da dies ein genereller Aspekt der Cloud-Nutzung ist, wird auf diesen hier jedoch nicht weiter eingegangen.

Bei Ausfall des jeweiligen Cloud-Dienstes (Gefährdung G 0.11 „Ausfall oder Störung von Dienstleistern“), der zur Ver- und Entschlüsselung verwendet wird, ist naturgemäß damit keine (De-)Chiffrierung von Daten möglich – gegebenenfalls können auch Anwendungen ausfallen, wenn die darin verarbeiteten Daten sich nicht mehr entschlüsseln lassen. Zudem kann es zu einem Datenverlust kommen, wenn während des Ausfalls Daten gerade in der Ver- oder Entschlüsselungsphase waren.

Für Azure Key Vault wird eine Verfügbarkeit von 99,9 % pro Monat angegeben – dies entspricht einem tolerablen Ausfall von bis zu 43 Minuten. Somit kann Azure Key Vault der Schutzbedarfskategorie „sehr hoch“ hinsichtlich der Verfügbarkeit entsprechend. Sollte aufgrund von Vertraulichkeits- und Integritätsanforderungen ein dediziertes Hardware-Security-Module (HSM) oder ein HSM beim Kunden eingesetzt werden, so ist beim Einsatz für sehr hohen Schutzbedarf darauf zu achten, dass auch dort die Verfügbarkeitsanforderungen erfüllt sind.

Google sagt für seinen Cloud KMS und Cloud HSM Service lediglich eine Verfügbarkeit von 99,5 % pro Monat zu – dies entspricht einem tolerablen Ausfall von bis zu 3 Stunden und 36 Minuten. Entsprechend lassen sich diese Cloud-Dienste bis zur Schutzbedarfskategorie „hoch“ verwenden. Sollte aufgrund von Vertraulichkeitsüberlegungen ein HSM beim Kunden eingesetzt werden, dann ist wiederum darauf zu achten, dass die Verfügbarkeitsanforderungen auch hier erfüllt werden.

Standardmäßige Verschlüsselung

Damit kein Cloud-Kunde auf die Daten eines anderen Cloud-Kunden oder gar auf die Daten des Anbieters zugreifen kann, haben viele Cloud-Diensteanbieter bereits zur Mandatentrennung Verschlüsselungsmaßnahmen getroffen – so wird häufig der gesamte Datenverkehr verschlüsselt.

Die standardmäßige Verschlüsselung von GCP chiffriert Kundendaten, bevor diese auf ein Laufwerk geschrieben werden. Hierzu werden die Kundendaten in Blöcke zerteilt und diese einzeln verschlüsselt (siehe Abb. 1). Die Datenverschlüsselungsschlüssel (Data-Encryption-Key, DEK) werden mittels Schlüsselverschlüsselungsschlüssel (Key-Encryption-Key, KEK) chiffriert und dieser im Schlüsseltresor-Dienst gespeichert und verwaltet, der auch zur Administration der Google-Dienste zum Einsatz kommt. Zur Entschlüsselung wird der KEK herangezogen, um die DEK zu entschlüsseln, sodass anschließend die Datenblöcke entschlüsselt und zusammengesetzt werden können.

Ähnlich funktioniert auch die standardmäßige Verschlüsselung des Speichers unter Azure, die ebenfalls blockweise erfolgt, wobei die Abläufe denen von Bitlocker ähneln. Die Schlüssel werden in einem von Microsoft betriebenen Schlüsseltresor-Dienst gespeichert. In beiden Fällen erfolgt die Verschlüsselung transparent, Cloud-Kunden müssen also nicht noch explizit dechiffrieren, wenn sie auf die Daten in der Cloud zugreifen möchten.

Software-Schlüsseltresore

Sowohl bei Azure als auch bei GCP können Software-Entwickler Geheimnisse, wie beispielsweise Passwörter oder kryptografische Schlüssel, in einem Software-Schlüsseltresor speichern – eine Ablage von Geheimnissen in der Applikation selbst ist daher nicht mehr notwendig, stattdessen wird eine sichere Speicherung zentral gesteuert. Bei Azure heißt dieser Software-Schlüsseltresor Azure Key Vault – bei GCP heißt er Cloud Key Management Service (Cloud KMS).

Im Azure Key Vault können Geheimnisse erstellt, verwaltet und sicher gespeichert werden. Weiterhin übernimmt der Dienst auch Aufgaben aus dem Schlüsselmanagement (z. B. das automatische Rotieren eines Schlüssels).

Im Cloud KMS können Kunden symmetrische und asymmetrische Schlüssel erstellen und verwalten (Letztere derzeit im Betatest) – auch dort können verwaltete Schlüssel automatisch rotiert werden. Eine Speicherung von Geheimnissen erfolgt, indem das Geheimnis in einem sogenannten Storage-Bucket gespeichert und dieser dann verschlüsselt wird. Eine Speicherung von Zertifikaten ist jedoch nicht möglich.

Sowohl Google als auch Microsoft haben sich einer sicheren Entwicklung verschrieben. Microsoft hat dazu den Security Development Lifecycle (SDL) entworfen und weiterentwickelt (www.microsoft.com/en-us/securityengineering/sdl) – Google verweist ebenfalls auf eine sichere Entwicklung und geht dabei vor allem darauf ein, dass das Unternehmen Sicherheitsbibliotheken entwickelt und bereitstellt (vgl. etwa https://cloud.google.com/security/overview/whitepaper), weiterhin werde neue Software ausführlich getestet. Man darf daher wohl von einer sicheren Entwicklung beider Software-Schlüsseltresore ausgehen, zumal deren Konzeption vorsieht, dass Mitarbeiter von Microsoft oder Google die in den Tresoren enthaltenen Geheimnisse weder anzeigen noch extrahieren können.

Damit ein Dienst oder eine Applikation auf den jeweiligen Software-Schlüsseltresor zugreifen darf, muss eine Authentifizierung und Autorisierung durchgeführt werden. Diese Authentifizierung wird bei Azure über das integrierte Berechtigungsmanagement (Azure Active Directory) gesteuert. Die Autorisierung erfolgt über die rollenbasierte Zugriffsteuerung (Role-Based Access Control, RBAC), wenn es um die Verwaltung des Azure Key Vaults geht – geht es um den Zugriff auf im Azure Key Vault gespeicherte Daten, erfolgt die Autorisierung über Zugriffsrichtlinien. Ganz ähnlich werden auch Benutzern oder Diensten für Cloud KMS Berechtigungen zugewiesen: Dies kann automatisch oder durch den Nutzer erfolgen. Eine Berechtigung zum Zugriff auf Cloud KMS lässt sich über die in GCP verwendeten IAM-Richtlinien zuweisen.

Sofern man die Best Practices für Cloud KMS beziehungsweise Azure Key Vault einhält, werden die Authentifizierungs- und Autorisierungsmethoden sowohl für Azure Key Vault als auch Cloud KMS in dieser Untersuchung als grundsätzlich ausreichend angesehen. Zugriffe und Aktionen in den Software-Schlüsseltresoren lassen sich zudem mittels der plattformeigenen Monitoring- und Protokollierungsfunktionen überwachen.

Für Geheimnisse und Schlüssel in GCP steht neben den Hochverfügbarkeitsmechanismen allerdings kein gesonderter Datensicherungsdienst zur Verfügung. In Azure kann man hingegen einen Datensicherungsdienst beauftragen – zudem können die über Azure Key Vault exportierbaren Geheimnisse, kryptografischen Schlüssel und Zertifikate exportiert und so einer lokalen Datensicherung zugeführt werden.

Hardware-Schlüsseltresore

Ein Hardware-Security-Module (HSM) ist eine manipulationsgesicherte Hardware, in der kryptografisches Material gesichert vorgehalten werden kann – beispielsweise Schlüssel- (KEK) oder Daten-Verschlüsselungsschlüssel (DEK). HSMs können den Nutzer überdies beim Schlüsselmanagement unterstützen, indem sie neben dem sicheren Speichern beispielsweise auch Schlüsselableitungen durchführen.

HSMs sind speziell auf den Schutz kryptografischer Daten ausgelegt: Je nach Bauart können sie Vibrations- und/oder Öffnungsdetektoren besitzen, sodass das Gerät weder entwendet noch geöffnet werden kann, ohne dass gespeicherte Schlüssel sicher vernichtet würden. Für den Fall eines Stromausfalls besitzen HSMs typischerweise einen Batteriepuffer, um dennoch ein sicheres Löschen zu gewährleisten.

Bei beiden betrachteten Cloud-Diensten können HSMs in unterschiedlichen Formen zum Einsatz kommen: Bei GCP können die von Google als Cloud-Dienst angebotenen HSMs verwendet werden, die FIPS-140-2-Level-3-zertifiziert sind. Diese HSM-Cluster werden von Google verwaltet, beispielsweise führt das Unternehmen also notwendige Patches durch – die HSMs teilt man sich aber auch mit anderen Cloud-Kunden, ihre Konfiguration erfolgt über das Frontend des Cloud KMS.

Auch bei Azure sind HSM-Cluster verfügbar, die mit anderen Cloud-Kunden geteilt werden – ähnlich wie bei Google managt man diese über das Azure Key Vault. Die von Microsoft eingesetzten HSMs sind FIPS-140-2-Level-2-zertifiziert: Der Unterschied zwischen Level 2 und Level 3 liegt vor allem in der physischen Detektion möglicher Angriffe auf das Gerät. Sofern die regulatorische Anforderung besteht, ein Level-3-zertifiziertes HSM einzusetzen, kann man auf den von Azure angebotenen Service dedizierter HSM ausweichen, bei dem die Systeme ausschließlich von einem Kunden genutzt und verwaltet werden. Allerdings lässt sich dieser Service nur für wenige Einsatzszenarien verwenden – zum Beispiel, wenn Anwendungen in die Cloud auf virtuelle Maschinen migriert werden und diese bisher ebenfalls das Schlüsselmanagement mittels HSM durchgeführt haben.

Bei GCP gibt es eine andere Alternative: Hier lässt sich ein lokales HSM verwenden, um einen Schlüssel zu generieren, der dann als KEK fungiert und mit dem man in den Diensten Google Cloud Storage und Google Compute Engine Datenblöcke entschlüsseln kann – dabei wird der vom Cloud-Kunden erzeugte Schlüssel im RAM verarbeitet und nicht in der Cloud gespeichert.

In Azure werden lokale HSMs ähnlich, aber nicht identisch eingesetzt: In beiden Fällen ist das lokale HSM des Cloud-Kunden am Ver- und Entschlüsselungsprozess beteiligt und kann zur Schlüsselgenerierung verwendet werden. Dieser Schlüssel wird dann im ersten Szenario – „Bring Your Own Key“ – gesichert in das Azure Key Vault übertragen, dort gespeichert und anschließend für Ver- und Entschlüsselungsoperationen verwendet.

Im zweiten Szenario werden hingegen alle Ver- und Entschlüsselungsoperationen lokal im HSM des Kunden durchgeführt – das bezeichnet Microsoft als „Host Your Own Key“. Allerdings unterstützen die meisten Azure-Dienste dieses Verfahren nicht, weswegen es nur sehr eingeschränkt eingesetzt werden kann. Weiterhin sollte man hierbei auch bedenken, dass alle Cloud-Dienste, die Zugriff auf den Ver- und Entschlüsselungsmechanismus benötigen, dann auf ein solches lokales HSM zugreifen können.

Bewertung der Schlüsselmanagement-Dienste

Die Bewertungen zu den Schlüsselmanagement-Diensten von Azure sind in den Tabellen 1 und 2 aufgeführt – Tabelle 3 enthält die Bewertungen zu GCP. Die Autoren haben dabei diejenigen G0-Gefährdungen betrachtet, die entsprechend der IT-Grundschutz Methodik (BSI Standard 200-2) „direkt relevant“ sind. Weiterhin wurden noch folgende cloud-spezifische Gefährdungen betrachtet, die in den Umsetzungshinweisen des Bausteins OPS.2.2 in Maßnahme OPS2.2.M7 „Erstellung eines Sicherheitskonzeptes für die Cloud-Nutzung“ erwähnt werden:

• C 0.1 „Fehlende Portabilität von Daten“
• C 0.2 „Gemeinsame Nutzung der Cloud-Infrastruktur durch mehrere Institutionen (multi-tenancy)“
• C 0.3 „Unbefugter Zugriff auf Informationen zum Beispiel durch Administratoren des Cloud-Diensteanbieters oder Dritte“

Die cloudspezifische Gefährdung C 0.3 umfasst die Gefährdungen G 0.14 „Ausspähen von Informationen (Spionage)“, G 0.30 „Unberechtigte Nutzung oder Administration von Geräten und Systemen“ und G 0.32 2 „Missbrauch von Berechtigungen“, die nicht gesondert betrachtet werden, da sie für den Betrachtungsgegenstand nicht als „direkt relevant“ einzustufen sind.

Hinsichtlich der Bewertung ist abschließend anzumerken, dass natürlich auch ein „grün“ markierter Cloud-Dienst sicher konfiguriert werden muss und es vorkommen kann, dass bestimmte Maßnahmen nicht kostenfrei sind – so könnte etwa eine Kosten/Nutzen-Entscheidung dazu führen, dass ein wichtiger Dienst nicht zum Einsatz kommt.

Bei einem „rot“ markierten Cloud-Dienst kann es hingegen dennoch zu einem Einsatz kommen, wenn beispielsweise ein Risiko schlicht akzeptiert wird.

Sind neben dem IT-Grundschutz noch weitere Anforderungen an die Datensicherheit zu stellen (z. B. im Rahmen von Geheimhaltungsvorgaben), sind die Bewertungen der Cloud-Dienste natürlich in deren Lichte zu überprüfen und gegebenenfalls zu überarbeiten.

Fazit

Dieser Artikel gibt einen Überblick über die unterschiedlichen Schlüsselmanagement-Dienste bei der Google Cloud Platform und Microsoft Azure. Diese Schlüsselmanagement-Dienste bilden ein wichtiges Fundament für den Einsatz von Kryptografie in Cloud-Diensten. Trotz seines Umfangs kann dieser Beitrag nur einen kleinen Ausschnitt liefern, um Cloud-Dienste anhand der eingesetzten Sicherheitsdienste (hier der Verschlüsselung) zu bewerten.

Die Bewertungen der Schlüsselmanagement-Möglichkeiten bei Azure und GCP zeigen, dass gerade dann, wenn lokale HSM-Lösungen zum Einsatz kommen, weitergehende Maßnahmen durch den Kunden notwendig werden und sich daher der Aufwand für diese deutlich erhöht. Weiterhin zeigen die Ergebnisse, dass gerade Microsoft Azure Cloud-Dienste an den Markt bringt, wenn diese aufgrund regulatorischer Vorgaben notwendig werden – hier ist als Beispiel das dedizierte HSM angeführt, das fast ausschließlich nur für Lift&Shift-Projekte eingesetzt werden kann.

Ansonsten zeigt die Auswertung, dass die Sicherheitsmaßnahmen hinsichtlich der Schlüsselmanagement-Dienste der beiden Cloud-Anbieter – anders als noch vor ein paar Jahren – nahezu gleichauf liegen.

Inés Atug ist Senior Expert bei der HiSolutions AG – zu ihren Schwerpunkten gehören Kryptografie, Cloud-Security und kritische Infrastrukturen.

Literatur

[1] Google, Übersicht über das Sicherheitsdesign der Infrastruktur von Google, Januar https://cloud.google.com/security/infrastructure/design/
[2] Google, Inaktive Daten in der Google Cloud Platform verschlüsseln, April 2017, https://cloud.google.com/security/encryption-at-rest/default-encryption/
[3] Google, Verschlüsselung bei der Übertragung in Google Cloud, Dezember 2017, https://cloud.google.com/security/encryption-in-transit/
[4] Microsoft, Isolation in der öffentlichen Azure-Cloud, Oktober 2019, https://docs.microsoft.com/de-de/azure/security/fundamentals/isolation-choices
[5] Microsoft, Übersicht über die Azure-Verschlüsselung, September 2018, https://docs.microsoft.com/de-de/azure/security/fundamentals/encryption-overview