Chiffrement transparent des données

Article
05/30/2023

Vous pouvez prendre plusieurs précautions pour sécuriser la base de données telles que la conception d’un système sécurisé, le chiffrement de ressources confidentielles et la création d'un pare-feu autour des serveurs de base de données. Toutefois, pour un scénario dans lequel les supports physiques (tels que les lecteurs ou les bandes de sauvegarde) sont volés, une partie malveillante peut simplement restaurer ou attacher la base de données et parcourir les données. Une solution consiste à chiffrer les données sensibles dans la base de données et à protéger les clés utilisées pour chiffrer les données avec un certificat. Cela empêche toute personne qui ne dispose pas des clés d'utiliser les données, mais ce type de protection doit être planifié à l'avance.

Transparent Data Encryption (TDE) effectue le chiffrement d’E/S en temps réel et le déchiffrement des fichiers journaux de données et des fichiers journaux des transactions et des fichiers journaux PDW spéciaux. Le chiffrement utilise une clé de chiffrement de base de données stockée dans l’enregistrement de démarrage de base de données à des fins de disponibilité lors de la récupération. La clé DEK est une clé symétrique sécurisée à l’aide d’un certificat stocké dans la base de données principale de SQL Server PDW. Le chiffrement transparent des données protège les données « au repos », autrement dit les fichiers de données et les fichiers journaux. Il permet de se conformer à de nombreuses lois, règles et instructions établies dans différents secteurs professionnels. Cette fonctionnalité permet aux développeurs de logiciels de chiffrer des données à l’aide d’algorithmes de chiffrement AES et 3DES sans modifier les applications existantes.

Important

TDE ne fournit pas de chiffrement pour les données voyageant entre le client et le PDW. Pour plus d’informations sur le chiffrement des données entre le client et SQL Server PDW, consultez Provisionner un certificat.

TDE ne chiffre pas les données lors du déplacement ou de l’utilisation. Le trafic interne entre les composants PDW à l’intérieur de SQL Server PDW n’est pas chiffré. Les données stockées temporairement dans des mémoires tampons ne sont pas chiffrées. Pour atténuer ce risque, contrôlez l’accès physique et les connexions à SQL Server PDW.

Une fois sécurisée, la base de données peut être restaurée à l'aide du certificat approprié.

Remarque

Lorsque vous créez un certificat pour TDE, vous devez le sauvegarder immédiatement, ainsi que la clé privée associée. Dans l'éventualité où le certificat ne serait plus disponible ou que vous deviez restaurer ou attacher la base de données sur un autre serveur, vous devez disposer de sauvegardes du certificat et de la clé privée, sans quoi vous ne pourrez pas ouvrir la base de données. Le certificat de chiffrement doit être conservé même si le chiffrement transparent des données n'est plus activé sur la base de données. Même si la base de données n'est pas chiffrée, des parties du journal des transactions peuvent toujours être protégées, et le certificat peut être nécessaire pour certaines opérations tant que la sauvegarde complète de la base de données n'a pas été effectuée. Un certificat qui a dépassé sa date d'expiration peut toujours être utilisé pour chiffrer et déchiffrer les données avec le chiffrement transparent des données.

Le chiffrement du fichier de base de données est effectué au niveau de la page. Les pages d'une base de données chiffrée sont chiffrées avant d'être écrites sur le disque et déchiffrées lorsqu'elles sont lues en mémoire. Le chiffrement transparent des données n'augmente pas la taille de la base de données chiffrée.

L’illustration suivante montre la hiérarchie des clés pour le chiffrement TDE :

Displays the hierarchy

Utilisation du chiffrement transparent des données

Pour utiliser le chiffrement transparent des données, procédez comme suit : Les trois premières étapes ne sont effectuées qu’une seule fois, lors de la préparation de SQL Server PDW pour prendre en charge TDE.

Créez une clé principale dans la base de données maître.
Utilisez sp_pdw_database_encryption pour activer TDE sur sql Server PDW. Cette opération modifie les bases de données temporaires afin de garantir la protection des données temporaires futures et échouera en cas de tentative lorsqu’il existe des sessions actives qui ont des tables temporaires. sp_pdw_database_encryption active le masquage des données utilisateur dans les journaux système PDW. (Pour plus d’informations sur le masquage des données utilisateur dans les journaux système PDW, consultez sp_pdw_log_user_data_masking.)
Utilisez sp_pdw_add_network_credentials pour créer des informations d’identification qui peuvent s’authentifier et écrire dans le partage où la sauvegarde du certificat sera stockée. Si des informations d’identification existent déjà pour le serveur de stockage prévu, vous pouvez utiliser les informations d’identification existantes.
Dans la base de données master, créez un certificat protégé par la clé principale.
Sauvegardez le certificat dans le partage de stockage.
Dans la base de données utilisateur, créez une clé de chiffrement de base de données et protégez-la par le certificat stocké dans la base de données master.
Utilisez l’instruction ALTER DATABASE pour chiffrer la base de données à l’aide de TDE.

L’exemple suivant illustre le chiffrement de la base de données à l’aide AdventureWorksPDW2012 d’un certificat nommé MyServerCert, créé dans SQL Server PDW.

Tout d’abord : activez TDE sur sql Server PDW. Cette action n’est nécessaire qu’une seule fois.

USE master;  
GO  
  
-- Create a database master key in the master database  
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';  
GO  
  
-- Enable encryption for PDW  
EXEC sp_pdw_database_encryption 1;  
GO  
  
-- Add a credential that can write to the share  
-- A credential created for a backup can be used if you wish  
EXEC sp_pdw_add_network_credentials 'SECURE_SERVER', '<domain>\<Windows_user>', '<password>';

Deuxièmement : Créez et sauvegardez un certificat dans la base de données master. Cette action n’est nécessaire qu’une seule fois. Vous pouvez avoir un certificat distinct pour chaque base de données (recommandé), ou vous pouvez protéger plusieurs bases de données avec un seul certificat.

-- Create certificate in master  
CREATE CERTIFICATE MyServerCert WITH SUBJECT = 'My DEK Certificate';  
GO  
  
-- Back up the certificate with private key  
BACKUP CERTIFICATE MyServerCert   
    TO FILE = '\\SECURE_SERVER\cert\MyServerCert.cer'  
    WITH PRIVATE KEY   
    (   
        FILE = '\\SECURE_SERVER\cert\MyServerCert.key',  
        ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>'   
    )   
GO

Dernière : Créez la clé DEK et utilisez ALTER DATABASE pour chiffrer une base de données utilisateur. Cette action est répétée pour chaque base de données protégée par TDE.

USE AdventureWorksPDW2012;  
GO  
  
CREATE DATABASE ENCRYPTION KEY  
WITH ALGORITHM = AES_128  
ENCRYPTION BY SERVER CERTIFICATE MyServerCert;  
GO  
  
ALTER DATABASE AdventureWorksPDW2012 SET ENCRYPTION ON;  
GO

Les opérations de chiffrement et de déchiffrement sont planifiées sur des threads d'arrière-plan par SQL Server. Vous pouvez consulter l'état de ces opérations à l'aide des affichages catalogue et des vues de gestion dynamique mentionnés dans la liste fournie plus loin dans cette rubrique.

Attention

Les fichiers de sauvegarde des bases de données pour lesquelles le chiffrement transparent des données est activé sont également chiffrés à l'aide de la clé de chiffrement de base de données. En conséquence, lorsque vous restaurez ces sauvegardes, le certificat qui protège la clé de chiffrement de base de données doit être disponible. Cela signifie qu'en plus de sauvegarder la base de données, vous devez vous assurer que vous conservez des sauvegardes des certificats du serveur pour empêcher toute perte de données. Une perte de données interviendra si le certificat n'est plus disponible.

Commandes et fonctions

Les certificats TDE doivent être chiffrés par la clé principale de base de données pour être acceptés par les instructions suivantes.

Le tableau suivant fournit des liens et des explications pour les commandes et les fonctions TDE.

Commande ou fonction	Objectif
CREATE DATABASE ENCRYPTION KEY	Crée une clé permettant de chiffrer une base de données.
ALTER DATABASE ENCRYPTION KEY	Modifie la clé qui permet de chiffrer une base de données.
DROP DATABASE ENCRYPTION KEY	Supprime la clé qui était utilisée pour chiffrer une base de données.
ALTER DATABASE	Présente l'option ALTER DATABASE qui est utilisée pour activer le chiffrement transparent des données.

Affichages catalogue et vues de gestion dynamique

Le tableau suivant indique les affichages catalogue et les vues de gestion dynamique du chiffrement transparent des données.

Affichage catalogue ou vue de gestion dynamique	Objectif
sys.databases	Affichage catalogue qui affiche des informations sur la base de données.
sys.certificates	Affichage catalogue qui indique les certificats inclus dans une base de données.
sys.dm_pdw_nodes_database_encryption_keys	Vue de gestion dynamique qui fournit des informations pour chaque nœud, sur les clés de chiffrement utilisées dans une base de données et l’état du chiffrement d’une base de données.

Autorisations

Chaque fonctionnalité et commande TDE requiert des autorisations individuelles, décrites dans les tableaux précédents.

L’affichage des métadonnées impliquées avec TDE nécessite l’autorisation CONTROL SERVER .

À propos de l’installation

Lorsqu'une analyse de rechiffrement est en cours pour une opération de chiffrement de la base de données, les opérations de maintenance sur la base de données sont désactivées.

Vous trouverez l’état du chiffrement de base de données à l’aide de la vue de gestion dynamique sys.dm_pdw_nodes_database_encryption_keys . Pour plus d’informations, consultez la section Affichages catalogue et Vues de gestion dynamique plus haut dans cet article.

Restrictions

Les opérations suivantes ne sont pas autorisées pendant les CREATE DATABASE ENCRYPTION KEYinstructions ou les ALTER DATABASE ENCRYPTION KEYDROP DATABASE ENCRYPTION KEYALTER DATABASE...SET ENCRYPTION instructions.

Suppression de la base de données
Utilisation d’une ALTER DATABASE commande.
Démarrage d’une sauvegarde de base de données.
Démarrage d’une restauration de base de données.

Les opérations ou conditions suivantes empêchent les instructions ou DROP DATABASE ENCRYPTION KEYALTER DATABASE...SET ENCRYPTION les CREATE DATABASE ENCRYPTION KEYinstructions. ALTER DATABASE ENCRYPTION KEY

Une ALTER DATABASE commande est en cours d’exécution.
Une sauvegarde de données est en cours d'exécution.

Lors de la création de fichiers de base de données, l'initialisation instantanée des fichiers n'est pas disponible lorsque le chiffrement transparent des données est activé.

Zones non protégées par TDE

TDE ne protège pas les tables externes.

TDE ne protège pas les sessions de diagnostic. Les utilisateurs doivent être prudents de ne pas interroger avec des paramètres sensibles pendant que les sessions de diagnostic sont en cours d’utilisation. Les sessions de diagnostic qui révèlent des informations sensibles doivent être supprimées dès qu’elles ne sont plus nécessaires.

Les données protégées par TDE sont déchiffrées lorsqu’elles sont placées dans la mémoire PDW SQL Server. Les vidages de mémoire sont créés lorsque certains problèmes se produisent sur l’appliance. Les fichiers de vidage représentent le contenu de la mémoire au moment de l’apparence du problème et peuvent contenir des données sensibles dans un formulaire non chiffré. Le contenu des vidages de mémoire doit être examiné avant qu’ils ne soient partagés avec d’autres personnes.

La base de données master n’est pas protégée par TDE. Bien que la base de données master ne contienne pas de données utilisateur, elle contient des informations telles que des noms de connexion.

Chiffrement transparent des données et journaux de transactions

L’activation d’une base de données pour utiliser TDE a pour effet de zéro la partie restante du journal des transactions virtuelles pour forcer le journal des transactions virtuelles suivant. Cela garantit qu'aucun texte en clair n'est conservé dans les journaux des transactions après que la base de données a été définie pour le chiffrement. Vous trouverez l’état du chiffrement du fichier journal sur chaque nœud PDW en affichant la encryption_state colonne dans la sys.dm_pdw_nodes_database_encryption_keys vue, comme dans cet exemple :

WITH dek_encryption_state AS   
(  
    SELECT ISNULL(db_map.database_id, dek.database_id) AS database_id, encryption_state  
    FROM sys.dm_pdw_nodes_database_encryption_keys AS dek  
        INNER JOIN sys.pdw_nodes_pdw_physical_databases AS node_db_map  
           ON dek.database_id = node_db_map.database_id AND dek.pdw_node_id = node_db_map.pdw_node_id  
        LEFT JOIN sys.pdw_database_mappings AS db_map  
            ON node_db_map .physical_name = db_map.physical_name  
        INNER JOIN sys.dm_pdw_nodes AS nodes  
            ON nodes.pdw_node_id = dek.pdw_node_id  
    WHERE dek.encryptor_thumbprint <> 0x  
)  
SELECT TOP 1 encryption_state  
       FROM dek_encryption_state  
       WHERE dek_encryption_state.database_id = DB_ID('AdventureWorksPDW2012 ')  
       ORDER BY (CASE encryption_state WHEN 3 THEN -1 ELSE encryption_state END) DESC;

Toutes les données écrites dans le journal des transactions avant une modification de la clé de chiffrement de base de données seront chiffrées à l'aide de la clé de chiffrement de base de données précédente.

Journaux d’activité PDW

SQL Server PDW gère un ensemble de journaux destinés à la résolution des problèmes. (Notez que ce n’est pas le journal des transactions, le journal des erreurs SQL Server ou le journal des événements Windows.) Ces journaux d’activité PDW peuvent contenir des instructions complètes en texte clair, dont certaines peuvent contenir des données utilisateur. Les exemples classiques sont des instructions INSERT et UPDATE . Le masquage des données utilisateur peut être activé ou désactivé explicitement à l’aide de sp_pdw_log_user_data_masking. L’activation du chiffrement sur SQL Server PDW active automatiquement le masquage des données utilisateur dans les journaux d’activité PDW afin de les protéger. sp_pdw_log_user_data_masking peut également être utilisé pour masquer les instructions lorsque vous n’utilisez pas TDE, mais cela n’est pas recommandé, car il réduit considérablement la capacité de l’équipe Support Microsoft à analyser les problèmes.

Chiffrement transparent des données et base de données système tempdb

La base de données système tempdb est chiffrée lorsque le chiffrement est activé à l’aide de sp_pdw_database_encryption. Cette opération est requise pour que n’importe quelle base de données puisse utiliser TDE. Cela peut avoir un effet de performances pour les bases de données non chiffrées sur la même instance de SQL Server PDW.

Gestion de clés

La clé de chiffrement de base de données (DEK) est protégée par les certificats stockés dans la base de données master. Ces certificats sont protégés par la clé principale de base de données (DMK) de la base de données master. Le DMK doit être protégé par la clé principale de service (SMK) afin d’être utilisé pour TDE.

Le système peut accéder aux clés sans nécessiter d’intervention humaine (par exemple, fournir un mot de passe). Si le certificat n’est pas disponible, le système génère une erreur expliquant que la clé DEK ne peut pas être déchiffrée tant que le certificat approprié n’est pas disponible.

Lors du déplacement d’une base de données d’une appliance vers une autre, le certificat utilisé pour protéger sa clé DEK doit d’abord être restauré sur le serveur de destination. Ensuite, la base de données peut être restaurée comme d’habitude. Pour plus d’informations, consultez la documentation standard de SQL Server, à l’adresse Déplacer une base de données protégée par TDE vers un autre serveur SQL Server.

Les certificats utilisés pour chiffrer les clés DEK doivent être conservés tant qu’il existe des sauvegardes de base de données qui les utilisent. Les sauvegardes de certificat doivent inclure la clé privée du certificat, car sans la clé privée, un certificat ne peut pas être utilisé pour la restauration de la base de données. Ces sauvegardes de clés privées de certificat sont stockées dans un fichier distinct, protégé par un mot de passe qui doit être fourni pour la restauration de certificat.

Restauration de la base de données master

La base de données master peut être restaurée à l’aide de DWConfig, dans le cadre de la récupération d’urgence.

Si le nœud de contrôle n’a pas changé, c’est-à-dire si la base de données master est restaurée sur la même appliance et inchangée à partir de laquelle la sauvegarde de la base de données master a été effectuée, le DMK et tous les certificats sont lisibles sans action supplémentaire.
Si la base de données master est restaurée sur une autre appliance ou si le nœud de contrôle a été modifié depuis la sauvegarde de la base de données master, des étapes supplémentaires seront nécessaires pour régénérer le DMK.
1. Ouvrez le DMK :
```
OPEN MASTER KEY DECRYPTION BY PASSWORD = '<password>';  
```
2. Ajoutez le chiffrement par SMK :
```
ALTER MASTER KEY   
    ADD ENCRYPTION BY SERVICE MASTER KEY;  
```
3. Redémarrez l’appliance.

Mettre à niveau et remplacer Machines Virtuelles

Si un DMK existe sur l’appliance sur laquelle la machine virtuelle de mise à niveau ou de remplacement a été effectuée, le mot de passe DMK doit être fourni en tant que paramètre.

Exemple d’action de mise à niveau. Remplacez ********** par votre mot de passe DMK.

setup.exe /Action=ProvisionUpgrade ... DMKPassword='**********'

Exemple d’action pour remplacer une machine virtuelle.

setup.exe /Action=ReplaceVM ... DMKPassword='**********'

Pendant la mise à niveau, si une base de données utilisateur est chiffrée et que le mot de passe DMK n’est pas fourni, l’action de mise à niveau échoue. Pendant le remplacement, si le mot de passe correct n’est pas fourni lorsqu’un DMK existe, l’opération ignore l’étape de récupération DMK. Toutes les autres étapes sont effectuées à la fin de l’action de remplacement de machine virtuelle, mais l’action signale l’échec à la fin pour indiquer que des étapes supplémentaires sont requises. Dans les journaux d’installation (situés dans \ProgramData\Microsoft\Microsoft\Microsoft SQL Server Parallel Data Warehouse\100\Logs\Setup\\<time-stamp>\Detail-Setup), l’avertissement suivant s’affiche près de la fin.

*** WARNING \*\*\* DMK is detected in master database, but could not be recovered automatically! The DMK password was either not provided or is incorrect!

Exécutez cette instruction manuellement dans PDW et redémarrez l’appliance après cela pour récupérer DMK :

OPEN MASTER KEY DECRYPTION BY PASSWORD = '<DMK password>';  
ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY;

Utilisez les étapes de la restauration du paragraphe base de données maître pour récupérer la base de données, puis redémarrez l’appliance.

Si le DMK existait avant mais n’a pas été récupéré après l’action, le message d’erreur suivant est déclenché lorsqu’une base de données est interrogée.

Msg 110806;  
A distributed query failed: Database '<db_name>' cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server errorlog for details.

Impact sur les performances

L’impact sur les performances de TDE varie selon le type de données que vous avez, la façon dont elles sont stockées et le type d’activité de charge de travail sur le PDW SQL Server. Lorsqu’elles sont protégées par TDE, les E/S de lecture, puis le déchiffrement des données ou le chiffrement, puis l’écriture de données sont une activité intensive du processeur et auront plus d’impact lorsque d’autres activités gourmandes en processeur se produisent en même temps. Étant donné que TDE chiffre tempdb, TDE peut affecter les performances des bases de données qui ne sont pas chiffrées. Pour obtenir une idée précise des performances, vous devez tester l’ensemble du système avec vos données et votre activité de requête.

Les liens suivants contiennent des informations générales sur la façon dont SQL Server gère le chiffrement. Ces articles peuvent vous aider à comprendre le chiffrement SQL Server, mais ces articles n’ont pas d’informations spécifiques à SQL Server PDW et ils traitent des fonctionnalités qui ne sont pas présentes dans SQL Server PDW.

Voir aussi

ALTER DATABASE
CREATE MASTER KEY
CREATE DATABASE ENCRYPTION KEY
BACKUP CERTIFICATE
sp_pdw_database_encryption
sp_pdw_database_encryption_regenerate_system_keys
sp_pdw_log_user_data_masking
sys.certificates
sys.dm_pdw_nodes_database_encryption_keys

Partager via

Chiffrement transparent des données

Utilisation du chiffrement transparent des données

Commandes et fonctions

Affichages catalogue et vues de gestion dynamique

Autorisations

À propos de l’installation

Restrictions

Zones non protégées par TDE

Chiffrement transparent des données et journaux de transactions

Journaux d’activité PDW

Chiffrement transparent des données et base de données système tempdb

Gestion de clés

Restauration de la base de données master

Mettre à niveau et remplacer Machines Virtuelles

Impact sur les performances

Voir aussi

Commentaires

Ressources supplémentaires

Partager via

Chiffrement transparent des données

Utilisation du chiffrement transparent des données

Commandes et fonctions

Affichages catalogue et vues de gestion dynamique

Autorisations

À propos de l’installation

Restrictions

Zones non protégées par TDE

Chiffrement transparent des données et journaux de transactions

Journaux d’activité PDW

Chiffrement transparent des données et base de données système tempdb

Gestion de clés

Restauration de la base de données master

Mettre à niveau et remplacer Machines Virtuelles

Impact sur les performances

Contenu associé

Voir aussi

Commentaires

Ressources supplémentaires