Cloud Serie: Google stellt Cloud KMS Autokey in der Preview zur Verfügung

Die Verschlüsselung ist längst nicht nur, aber vor allem auch in der Public Cloud ein wichtiges Thema. Dabei geht es in der Public Cloud häufig primär um das Thema der Schlüsselverwaltung. Dieses Thema ist on prem in der Regel, wie ich meine zu unrecht, weniger hoch gewichtet. Aber dies ist ein anderes Thema.

Für sensible Daten muss man die Verschlüsselungsschlüssel in der Public Cloud selber verwalten können. Man nennt dies allgemein Customer Managed Encryption Key, kurz CMEK. Die meisten Public Cloud Provider stellen dazu verschiedene Möglichkeiten zur Verfügung, welche verschiedene  Schutzbedürfnisse adressieren. Neben der eigentlichen Schlüsselverwaltung unterscheiden sich diese Verfahren hauptsächlich darin, wo 1) diese Schlüssel generiert und gespeichert werden und vor allem 2) wo die eigentlich Ver- und Entschlüsselung der Daten stattfindet.

Was sich in der Theorie einfach und schön anhört, ist dann in der Praxis im Detail doch nicht ganz so trivial. Respektive wenn man es an einem Ort besonders sicher machen will, öffnet sich mindestens ein Spalt weit an anderer Stelle eine kleine Unsicherheit. Kurz: CMEK ist mit Aufwand in der Organisation verbunden. Man muss organisieren wie granular man Schlüsselbunde und Schlüssel definiert. Die Schlüsselrotationen müssen dann zum jeweiligen Produkt passen. Nicht bei allen Produkten haben Schlüsselrotationen einen unmittelbaren Effekt, weil die zu Grunde liegenden Daten nicht jedes Mal komplett neu verschlüsselt werden. Das alles muss wieder organisatorisch mit dem Berechtigungskonzept übereinstimmen und effizient sein, schliesslich muss man genau wissen, wer auf Schlüssel Zugriff hat, wer sie generieren und deaktivieren oder gar löschen darf.

Verwendet man, wie es sinnvoll ist, Infrastructur as Code (IaC), hat man in diesem Kontext meist das Problem, dass der User - ein persönlicher oder ein Service-User, je nach dem wie man es auf- und umgesetzt hat - eigentlich zu viele Rechte hat. Denn die IaC-Lösung, bspw. Terraform, braucht das Recht zur Schlüsselverwaltung, damit die notwendigen Ressourcen angelegt und verwaltet werden können. Das aber möchte man eigentlich nicht.

Nachdem wir nun ein paar Probleme mit CMEK aufgefrischt haben, hier ein Lichtblick von Google für die Google Cloud Platform GCP. Google hat vor 3 Wochen Cloud KMS Autokey vorgestellt. Zurzeit befindet sich das Feature noch in der Preview. (Update 24.09.2024: Cloud KMS Autokey ist nun offizielle verfügbar - GA).

Ich empfehle jedoch allen GCP Engineers/Administratoren, sich das Feature einmal anzuschauen. Es bietet unter anderem die folgenden Vorteile:

• Best practise und einheitliche Umsetzungen: Wenn Sie einen Schlüssel anfordern, generiert das Cloud KMS Autokey-Servicekonto automatisch Schlüssel in Übereinstimmung mit den in Cloud KMS Autokey eingebetteten Empfehlungen.
• Erstellung fein granularer Verschlüsselungsschlüssel: Ein neuer Schlüssel wird automatisch mit einer für jeden Ressourcentyp geeigneten Granularität erstellt, was Ihnen eine bessere Kontrolle über Vorgänge wie Crypto-Shredding ermöglicht, wenn Sie einen Schlüssel deaktivieren oder löschen müssen, ohne dass mehrere geschützte Ressourcen betroffen sind.
• Kürzere Wege ohne (Sicherheits-) Kompromisse: Sie erstellen schnell CMEK-geschützte Ressourcen, ohne dass ein Entwickler neue Schlüssel von einem anderen Team anfordern muss (weil er sinnvollerweise nicht selber berechtigt ist).
• Durchgehende Gewaltentrennung: Autorisierte User können einen Schlüssel direkt über das Cloud KMS Autokey-Servicekonto anfordern, wobei die Gewaltentrennung gewahrt bleibt.  So müssen bspw. User für Terraform oder andere IaC-Tools, nicht mehr mit erhöhten Privilegien für die Schlüsselerstellung berechtigt werden, was die Sicherheit insgesamt erhöht.

Aus meiner Sicht adressiert Google damit die meisten der heutigen Schmerzpunkte bei der Anwendung von CMEK in der GCP.

Cloud Serie: GCP Cloud Storage hierachical namespace: Erste Einschätzung

Google hat kürzlich ein neues Cloud Storage Feature vorgestellt: Hierarchische Namespaces in Cloud Storage: https://cloud.google.com/blog/products/storage-data-transfer/understanding-new-cloud-storage-hierarchical-namespace - kurz: HNS.

Vor nicht all zu langer Zeit habe ich die Unterschiede zwischen Cloud Storage und einem File-System behandelt: https://ronnyfuchs.blogspot.com/2024/05/cloud-serie-gcp-filestore-vs-cloud.html

Das neue Feature der hierarchischen Namespaces behebt nun den Nachteil der Hierarchie. Allerdings sieht es so aus, dass man damit auch aus meiner Sicht gute Funktionen von Cloud Storage - wie bspw. Objektversionierung - verliert bei Nutzung dieser Funktion. Was ebenfalls nach wie vor nicht möglich zu sein scheint, ist der Objekt-Lock. Also dass ein Client ein Objekt blockieren kann. Natürlich bleibt, soweit ich gehen habe, auch die Tatsache, dass Objekte nur auf einmal geschrieben werden können. Das heisst, dass nicht binär an beliebigen Positionen in Objekten geschrieben werden kann. Man speichert jeweils das komplette Objekt.

Insgesamt ist mein Eindruck, dass wenn man eine Applikation wie einen Lucene-Index hat, welche viele Funktionen eines Filesystem braucht, man nach wie vor auf Filestore angewiesen ist.

Der Einsatzzweck des neuen Features ist aus meiner Sicht aktuell noch stark eingeschränkt. Insbesondere weil man das neue Feature gegenüber den für diese Option (noch) fehlenden Features abwägen muss. Wesentlich mehr Einsatzzwecke als Google selber im Bereich AI/ML auflistet, kommen wir gerade nicht in den Sinn.

Als Vorteil sehe ich, wenn man grosse Buckets manuell verwaltet. Da kann die hierarchische Organisation eine Vereinfachung bringen. Allerdings, ich wiederhole mich, braucht man gerade in diesem Szenario oft auch die Objekt-Versionierung, die gemäss Google bei diesem Feature fehlt.

Die Erweiterung ist aktuell in Preview. Es muss sich zeigen, mit welchen konkreten Eigenschaften die Erweiterung dann konkret in die ordentliche Verfügbarkeit (GA) gehen wird. Leider geht aus den aktuellen Informationen nicht klar hervor, welche Einschränkungen nur während der Preview gelten und welche auch (vorerst) in der GA noch vorhanden sein werden. Dies erschwert eine erste fundierte Einschätzung.

Und nicht ganz unwichtig für einen möglichen künftigen Einsatzentscheid wird das Preisschild sein. Stand heute sind noch keine Informationen öffentlich verfügbar, was das Pricing von HNS betrifft.

Fazit:

Sicher eine spannende Erweiterung, die man im Auge behalten sollte. Sobald mehr Informationen verfügbar sind, braucht es dazu eine erneute und fundiertere Beurteilung der möglichen Use Cases.