Le chiffrement est transparent, car les requêtes SQL, les LDD et les opérations LMD fonctionnent normalement sans nécessiter de modifications de l'application. Les données sont automatiquement chiffrées avant d'être écrites sur le disque et déchiffrées lorsqu'elles sont lues en mémoire.
Hiérarchie des clés
AlloyDB Omni implémente une hiérarchie de clés à deux niveaux qui maintient une séparation stricte des tâches entre la base de données et l'infrastructure de sécurité gérée par l'utilisateur.
- Clés de chiffrement des données (DEK) : clés générées et détenues par AlloyDB Omni. Elles chiffrent les fichiers de données, le fichier WAL et les fichiers temporaires. AlloyDB Omni stocke les clés de chiffrement des données sur le disque, mais les encapsule avec votre KEK.
-
Clé de chiffrement de clé (KEK) : clé principale que vous gérez dans un service de gestion des clés (KMS) externe.
AlloyDB Omni utilise votre KEK pour chiffrer les DEK.
AlloyDB Omni n'accède à cette clé qu'au démarrage pour déchiffrer les clés de chiffrement des données. Votre KEK n'est jamais stockée de manière persistante sur le disque de la base de données.
-
Les paramètres d'emplacement et d'accès du KEK sont fournis par le biais de variables d'environnement et de l'indicateur d'initialisation
--tde-kek-url.
-
Les paramètres d'emplacement et d'accès du KEK sont fournis par le biais de variables d'environnement et de l'indicateur d'initialisation
Fonctionnement du TDE avec AlloyDB Omni
Lorsque TDE est activé, AlloyDB Omni sécurise vos données à l'aide d'un modèle de chiffrement multicouche qui s'intègre à un KMS externe.
- Initialisation et récupération de clés : lors de la phase de démarrage ou d'initialisation du cluster, le moteur AlloyDB Omni établit une connexion sécurisée à votre KMS. Il s'authentifie à l'aide d'un jeton Web JSON (JWT) et récupère la clé KEK.
- Développement des DEK : AlloyDB Omni utilise votre KEK pour développer les DEK, qui sont stockées sur le stockage local dans un état enveloppé. Ces DEK sont ensuite chargées en mémoire.
- Opérations transparentes sur les données :
- Écriture sur le disque : lorsque la base de données écrit des blocs de données, des enregistrements WAL ou des fichiers temporaires sur le disque physique, elle chiffre automatiquement les données à l'aide d'algorithmes AES-256 avant de les écrire.
- Lecture à partir du disque : lorsque la base de données doit lire des données en mémoire, elle déchiffre automatiquement les blocs à l'aide des DEK stockées en mémoire.
- Limites de sécurité : votre KEK n'est jamais stockée sur le disque de la base de données locale. Ainsi, même si le support de stockage physique est compromis, les données restent illisibles sans accès autorisé au coffre-fort externe.
Champ d'application et spécifications du chiffrement
AlloyDB Omni utilise des algorithmes AES-256 standards dans l'industrie pour sécuriser vos données.
- Fichiers de données (tables et index) : AES-256-XTS.
- Journaux de transaction (WAL) : AES-256-CTR.
- Fichiers temporaires : AES-256-XTS ou AES-256-CTR, selon le type de données temporaires.
- Fichiers cache du moteur de données en colonnes : AES-256-XTS.
- Fichiers de cache Chill : AES-256-XTS.
- Encapsulation de clé : AES-256-KWP.
Sauvegarde et haute disponibilité
Lorsque TDE est activé, les sauvegardes créées à l'aide de pgBackRest héritent de la configuration de chiffrement du cluster source. Cela garantit que vos données de sauvegarde restent protégées avec le même niveau de sécurité que votre base de données principale.
Pour les configurations HA, l'environnement de récupération doit être initialisé avec les mêmes variables d'environnement de coffre. Les variables d'environnement du coffre-fort doivent être disponibles sur tous les hôtes participants.
KMS et authentification compatibles
AlloyDB Omni est compatible avec HashiCorp Vault en tant que fournisseur KMS externe. AlloyDB Omni n'est compatible qu'avec le moteur de secrets KV-V2, et la seule méthode d'authentification acceptée est JWT.
Compatibilité avec les outils PostgreSQL
Les clusters compatibles avec le TDE sont compatibles avec tous les outils PostgreSQL intégrés, à l'exception deinitdb, de manière transparente via les variables d'environnement.
Si vous utilisez initdb, assurez-vous de transmettre explicitement l'URL du KEK.
Pour en savoir plus, consultez Créer un cluster compatible avec le chiffrement TDE.
Limites
- Vous ne pouvez pas activer le chiffrement TDE sur des clusters existants.
- Une fois activée, vous ne pouvez plus désactiver le TDE.
- Les mises à niveau de version majeure ne sont pas compatibles avec les clusters activés pour le chiffrement TDE.
- Vous ne pouvez pas restaurer des sauvegardes chiffrées sur des serveurs non chiffrés ni des sauvegardes non chiffrées sur des serveurs chiffrés.
- La rotation des DEK n'est pas prise en charge.
- La rotation des clés KEK est acceptée tant que le chemin de l'URL de la clé KEK reste le même.
- Vous ne pouvez pas
CREATE DATABASEavec la stratégieFILE_COPY. - Sur les clusters compatibles avec le chiffrement TDE, les sauvegardes Barman ne sont compatibles qu'avec le mode
rsync. La méthode de sauvegardepostgresn'est pas compatible.
Étapes suivantes
- Découvrez comment créer un cluster compatible avec le chiffrement TDE.