Prenez le contrôle : clés gérées par le client pour Lakebase Postgres

Le chiffrement au repos est une base du cloud, mais pour les entreprises opérant dans des environnements hautement réglementés, les organisations doivent contrôler la racine de confiance. Les clés gérées par le client (CMK) de Lakebase offrent ce contrôle en vous permettant d'utiliser vos propres clés de chiffrement de votre service de gestion des clés (KMS), par exemple AWS KMS, Azure Key Vault ou Google Cloud KMS, pour protéger et gérer les données tout au long du cycle de vie de Lakebase.

Les clés gérées par le client (CMK) de Lakebase offrent une gestion et un contrôle complets sur l'ensemble de l'architecture, contrairement aux bases de données gérées classiques. Alors que les bases de données traditionnelles ne chiffrent généralement que le stockage, Lakebase CMK gère à la fois le stockage persistant et le calcul éphémère.

L'architecture du chiffrement Lakebase

L'architecture de Lakebase sépare le stockage et le calcul en couches indépendantes, une conception qui permet une mise à l'échelle élastique et des opérations sans serveur. La couche de stockage (Pageserver et Safekeeper) conserve les données persistantes à long terme dans le stockage d'objets et les caches locaux, tandis que la couche de calcul exécute des instances Postgres indépendantes qui augmentent, diminuent ou se réduisent à zéro en fonction de la demande.

Cette séparation crée un défi unique pour le chiffrement : les deux couches (ainsi que tous leurs caches dans l'architecture) doivent être chiffrées et rester sous le contrôle du client. Lakebase CMK répond à cela grâce à un modèle hiérarchique de chiffrement par enveloppe.

La hiérarchie des clés

Le chiffrement par enveloppe est un modèle de sécurité où les données sont chiffrées avec des clés de données uniques (DEK), et ces clés sont elles-mêmes chiffrées par des clés de niveau supérieur. Cette hiérarchie garantit que votre CMK ne quitte jamais votre KMS cloud ; Databricks ne reçoit que des versions enveloppées (chiffrées) des clés nécessaires pour déchiffrer les données. Le modèle permet également un chiffrement haute performance à grande échelle, car le KMS n'est contacté que pour déballer les clés, et non pour chiffrer chaque bloc de données. Cette architecture permet une rotation transparente des clés et une révocation rapide si nécessaire.

La hiérarchie se compose de trois niveaux :

1. Clé gérée par le client (CMK) : La racine de confiance résidant dans votre KMS cloud (AWS KMS, Azure Key Vault ou Google Cloud KMS). Databricks ne voit jamais le texte brut de cette clé.
2. Clé de chiffrement de clé (KEK) : Une clé transitoire utilisée par le service de gestion des clés de Databricks pour envelopper les clés de données.
3. Clés de chiffrement de données (DEK) : Clés uniques générées pour chaque segment de données. Celles-ci sont stockées avec les données dans un état chiffré (enveloppé).

Lorsque les données doivent être accessibles, les composants Lakebase déballent la DEK nécessaire à l'aide de clés obtenues auprès de votre KMS. En cas de révocation, le déballage échouera, rendant les données cryptographiquement inaccessibles. Dans le cadre de ce processus, toutes les instances de calcul éphémères sont terminées pour supprimer l'accès aux données mises en cache.

CMK en pratique : stockage et calcul

L'implémentation pratique diffère entre le stockage et le calcul :

1. Couche de persistance (stockage)

Tous les segments de données gérés par Lakebase, y compris les segments WAL (journaux de transactions stockés par Safekeeper) et les fichiers de données, sont chiffrés avec des clés protégées par votre CMK. Cela offre une défense en profondeur : les données au repos sont protégées par des clés de chiffrement sous votre contrôle, et non par Databricks.

2. Couche éphémère (calcul)

La VM de calcul Postgres contient des données éphémères utilisées par le système d'exploitation et PostgreSQL, par exemple des caches de performance, des artefacts WAL, des fichiers temporaires, etc. Il est donc essentiel que toutes ces données soient également gérées sous une CMK. La CMK protège ces données de calcul éphémères avec :

• Clés par démarrage : Chaque fois qu'une instance de calcul Lakebase démarre, elle génère une clé éphémère unique.
• Destruction automatique : Lors de la révocation de la CMK, Lakebase Manager termine l'instance, détruisant les clés éphémères en mémoire et rendant les données du disque local inaccessibles.

Mise en œuvre de la CMK dans le flux de travail Lakebase

La mise en œuvre suit le modèle standard de délégation de compte à espace de travail Databricks. Cette séparation des tâches garantit que les administrateurs de sécurité peuvent gérer les clés sans avoir besoin d'accéder aux données elles-mêmes. Une fois qu'une clé est configurée au niveau de l'espace de travail, tous les projets Lakebase utilisent la CMK dans le cadre du flux de travail de chiffrement.

Étape 1 : Configuration de la clé

Un administrateur de compte crée une configuration de clé dans la console de compte Databricks. Cet objet contient l'identifiant de la clé (ARN pour AWS KMS, URL du Key Vault pour Azure ou ID de clé pour Google Cloud KMS) et le rôle IAM ou le principal de service que Lakebase assumera pour effectuer les opérations d'enveloppement et de déballage.

Étape 2 : Liaison de l'espace de travail

La configuration est ensuite mappée à un espace de travail spécifique. Pour Lakebase, cela signifie :

• Nouveaux projets : Tous les nouveaux projets Lakebase héritent automatiquement de la CMK de l'espace de travail.
• Isolation : Différents espaces de travail peuvent utiliser différentes CMK pour répondre aux exigences de sécurité multi-locataires ou multi-départementales.

Étape 3 : Gestion du cycle de vie et rotation

Lakebase prend en charge la rotation transparente des clés. Lorsque vous faites pivoter votre CMK dans la console de votre fournisseur de cloud :

• La hiérarchie de chiffrement par enveloppe permet une rotation transparente : votre CMK peut être pivotée dans votre KMS cloud sans ré-chiffrer les données ni modifier les DEK.
• Il n'y a aucun temps d'arrêt ni aucun ré-chiffrement manuel requis.

Audibilité de la sécurité

Étant donné que la CMK réside dans votre compte cloud, les opérations cryptographiques sur votre clé sont enregistrées dans le service d'audit de votre fournisseur (AWS CloudTrail, Azure Monitor ou Google Cloud Audit Logs).

Commencez avec une souveraineté des données améliorée

Si votre organisation exige le plus haut niveau de contrôle cryptographique sur vos charges de travail Postgres, Lakebase CMK est désormais disponible pour les clients du niveau Entreprise.

Prêt à sécuriser vos données ? Contactez votre équipe de compte Databricks pour activer les clés gérées par le client pour votre espace de travail, ou visitez notre documentation technique pour examiner les politiques IAM et les configurations KMS préalables.

Pas encore client Databricks ? Commencez avec un essai.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original