Direkt zum Hauptinhalt
Produkt

Kontrolle übernehmen: Kundenseitig verwaltete Schlüssel für Lakebase Postgres

Verschlüsselung über Speicher und Rechenleistung mit Widerrufssteuerung

von Ben Hagan

  • Lakebase CMK ermöglicht die Kontrolle des Kunden über Verschlüsselungsschlüssel, sodass Sie Schlüssel in Ihrem eigenen Cloud-KMS verwalten können, anstatt sich auf von Databricks verwaltete Standardwerte zu verlassen.
  • Sichern Sie den gesamten Datenlebenszyklus, indem Sie sowohl langfristige Speicher als auch ephemere Compute-Caches verschlüsseln.
  • Verwenden Sie Ihr KMS als technischen "Kill Switch", um Daten kryptografisch unzugänglich zu machen und aktive Compute-Instanzen zu beenden, was eine Notfalllösung für Postgres-Workloads mit hoher Compliance bietet.

Verschlüsselung im Ruhezustand ist ein Cloud-Standard, aber für Unternehmen, die in stark regulierten Umgebungen tätig sind, müssen Organisationen die Vertrauensbasis kontrollieren. Lakebase Customer Managed Keys (CMK) bietet diese Kontrolle, indem es Ihnen ermöglicht, Ihre eigenen Verschlüsselungsschlüssel aus Ihrem Key Management Service (KMS) z. B. AWS KMS, Azure Key Vault oder Google Cloud KMS zu verwenden, um Daten während des gesamten Lakebase-Lebenszyklus zu schützen und zu verwalten.

Lakebase Customer-Managed Keys (CMK) bietet im Gegensatz zu herkömmlichen verwalteten Datenbanken eine umfassende Verwaltung und Kontrolle über die gesamte Architektur. Während herkömmliche Datenbanken typischerweise nur den Speicher verschlüsseln, verwaltet Lakebase CMK sowohl den persistenten Speicher als auch die ephemere Rechenleistung.

Die Architektur der Lakebase-Verschlüsselung

Die Lakebase Architektur trennt Speicher und Rechenleistung in unabhängige Ebenen – ein Design, das elastische Skalierung und serverlose Vorgänge ermöglicht. Die Speicherebene (Pageserver und Safekeeper) verwaltet langlebige, persistente Daten im Objektspeicher und in lokalen Caches, während die Rechenebene unabhängige Postgres-Instanzen ausführt, die je nach Bedarf skaliert werden – nach oben, nach unten oder auf null.

Architekturdiagramm zeigt den Verschlüsselungsmechanismus über Cloud-verwaltete Schlüssel-Services, Databricks und die Durchsetzung von Schlüsseln durch Lakebase

Diese Trennung schafft eine einzigartige Herausforderung für die Verschlüsselung: Beide Ebenen (sowie alle ihre Caches in der gesamten Architektur) müssen verschlüsselt und unter Kundenkontrolle bleiben. Lakebase CMK löst dies durch ein hierarchisches Envelope-Verschlüsselungsmodell.

Die Schlüsselhierarchie

Envelope Encryption ist ein Sicherheitsmodell, bei dem Daten mit eindeutigen Datenschlüsseln (DEKs) verschlüsselt werden und diese Schlüssel selbst mit übergeordneten Schlüsseln verschlüsselt werden. Diese Hierarchie stellt sicher, dass Ihr CMK Ihre Cloud-KMS niemals verlässt – Databricks erhält nur verschlüsselte (gewrappte) Versionen der Schlüssel, die zum Entschlüsseln von Daten benötigt werden. Das Modell ermöglicht auch eine leistungsstarke Verschlüsselung im großen Maßstab, da das KMS nur zum Entpacken von Schlüsseln kontaktiert wird, nicht zum Verschlüsseln jedes Datenblocks. Diese Architektur ermöglicht nahtlose Schlüsselrotation und rechtzeitigen Widerruf, falls dies jemals erforderlich ist.

Die Hierarchie besteht aus drei Ebenen:

  1. Kundenseitig verwalteter Schlüssel (CMK): Die Vertrauensbasis in Ihrem Cloud-KMS (AWS KMS, Azure Key Vault oder Google Cloud KMS). Databricks sieht niemals den Klartext dieses Schlüssels.
  2. Schlüsselverschlüsselungsschlüssel (KEK): Ein transienter Schlüssel, der vom Databricks Key Manager Service zum Wrappen von Datenschlüsseln verwendet wird.
  3. Datenschlüssel (DEKs): Eindeutige Schlüssel, die für jedes Datensegment generiert werden. Diese werden zusammen mit den Daten in verschlüsseltem (gewrapptem) Zustand gespeichert.
Hierarchie der Envelope-Verschlüsselung

Wenn auf Daten zugegriffen werden muss, entpacken Lakebase-Komponenten den erforderlichen DEK mithilfe von Schlüsseln, die aus Ihrem KMS bezogen wurden. Im Falle eines Widerrufs schlägt das Entpacken fehl, wodurch die Daten kryptografisch unzugänglich werden. Als Teil dieses Prozesses werden alle ephemeren Recheninstanzen beendet, um den Zugriff auf zwischengespeicherte Daten zu entfernen.

CMK in der Praxis: Speicher und Rechenleistung

Die praktische Implementierung unterscheidet sich zwischen Speicher und Rechenleistung:

1. Persistenzschicht (Speicher)

Alle von Lakebase verwalteten Datensegmente, einschließlich WAL-Segmenten (Transaktionsprotokolle, die von Safekeeper gespeichert werden) und Datendateien, werden mit Schlüsseln verschlüsselt, die von Ihrem CMK geschützt werden. Dies bietet eine mehrschichtige Sicherheit: Daten im Ruhezustand werden durch Verschlüsselungsschlüssel geschützt, die Sie kontrollieren, nicht Databricks.

2. Ephemere Schicht (Rechenleistung)

Die Postgres-Compute-VM speichert ephemere Daten, die vom Betriebssystem und PostgreSQL verwendet werden – beispielsweise Leistungscaches, WAL-Artefakte, temporäre Dateien usw. Daher ist es entscheidend, dass all diese Daten ebenfalls unter einem CMK verwaltet werden. CMK schützt diese ephemeren Compute-Daten mit:

  • Pro Boot-Schlüssel: Jedes Mal, wenn eine Lakebase-Compute-Instanz startet, generiert sie einen eindeutigen ephemeren Schlüssel.
  • Automatisches Shredding: Bei CMK-Widerruf beendet der Lakebase Manager die Instanz, zerstört ephemere In-Memory-Schlüssel und macht lokale Festplattendaten unzugänglich.

Implementierung von CMK im Lakebase-Workflow

Die Implementierung folgt dem Standardmodell der Delegierung von Databricks Account zu Workspace. Diese Trennung der Zuständigkeiten stellt sicher, dass Sicherheitsadministratoren Schlüssel verwalten können, ohne Zugriff auf die Daten selbst zu benötigen. Sobald ein Schlüssel auf Workspace-Ebene konfiguriert ist, verwenden alle Lakebase-Projekte den CMK als Teil des Verschlüsselungs-Workflows.

Schritt 1: Schlüsselkonfiguration

Ein Account-Administrator erstellt eine Schlüsselkonfiguration in der Databricks Account Console. Dieses Objekt enthält die Schlüsselkennung (ARN für AWS KMS, Key Vault-URL für Azure oder Schlüssel-ID für Google Cloud KMS) und die IAM-Rolle oder den Dienstprinzipal, den Lakebase annehmen wird, um Wrap- und Unwrap-Vorgänge durchzuführen.

Schritt 2: Workspace-Bindung

Die Konfiguration wird dann einem bestimmten Workspace zugeordnet. Für Lakebase bedeutet dies:

  • Neue Projekte: Alle neuen Lakebase-Projekte erben automatisch den CMK des Workspaces.
  • Isolation: Unterschiedliche Workspaces können unterschiedliche CMKs verwenden, um Sicherheitsanforderungen für Mandanten oder Abteilungen zu erfüllen.

Schritt 3: Lebenszyklusverwaltung und Rotation

Lakebase unterstützt nahtlose Schlüsselrotation. Wenn Sie Ihren CMK in der Konsole Ihres Cloud-Anbieters rotieren:

  • Die Envelope-Verschlüsselungshierarchie ermöglicht eine nahtlose Rotation – Ihr CMK kann in Ihrem Cloud-KMS rotiert werden, ohne Daten neu zu verschlüsseln oder DEKs zu ändern.
  • Es ist keine Ausfallzeit oder manuelle Neuverschlüsselung erforderlich.

Sicherheitsüberprüfbarkeit

Da sich der CMK in Ihrem Cloud-Konto befindet, werden kryptografische Operationen gegen Ihren Schlüssel in der Audit-Dienst Ihres Anbieters protokolliert (AWS CloudTrail, Azure Monitor oder Google Cloud Audit Logs).

Beginnen Sie mit erweiterter Datensouveränität

Wenn Ihre Organisation das höchste Maß an kryptografischer Kontrolle über ihre Postgres-Workloads benötigt, ist Lakebase CMK jetzt für Kunden der Enterprise-Stufe verfügbar.

Bereit, Ihre Daten zu sichern? Kontaktieren Sie Ihr Databricks-Account-Team, um Customer Managed Keys für Ihren Workspace zu aktivieren, oder besuchen Sie unsere technische Dokumentation, um die erforderlichen IAM-Richtlinien und KMS-Konfigurationen zu überprüfen.

Noch kein Databricks-Kunde? Beginnen Sie mit einer Testversion.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag

Erhalten Sie die neuesten Beiträge in Ihrem Posteingang

Abonnieren Sie unseren Blog und erhalten Sie die neuesten Beiträge direkt in Ihren Posteingang.