Chiffrement transparent des données (TDE)

  • Article

S’applique à :SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)

Transparent Data Encryption (TDE) chiffre SQL Server, Azure SQL Database et les fichiers de données Azure Synapse Analytics. Ce chiffrement est connu sous le nom de chiffrement de données au repos.

Pour sécuriser une base de données utilisateur, vous pouvez prendre des précautions telles que :

  • Concevoir un système sécurisé.
  • Chiffrer les ressources confidentielles.
  • Créer un pare-feu autour des serveurs de base de données.

Toutefois, une partie malveillante qui vole des supports physiques tels que des lecteurs ou des bandes de sauvegarde peut restaurer ou attacher la base de données et parcourir ses données.

Il existe une solution qui consiste à chiffrer les données sensibles dans une base de données et à utiliser un certificat pour protéger les clés qui chiffrent les données. Cette solution empêche quiconque ne disposant pas des clés d’utiliser les données. Vous devez cependant planifier ce type de protection à l’avance.

TDE assure un chiffrement et un déchiffrement des données et des fichiers journaux en E/S et en temps réel. Le chiffrement utilise une clé de chiffrement de base de données. L’enregistrement de démarrage de la base de données stocke la clé pour la mettre à disposition pendant la récupération. La clé DEK est une clé symétrique et est sécurisée par un certificat que la base de données du master serveur stocke ou par une clé asymétrique qu’un module EKM protège.

TDE protège les données au repos, c’est-à-dire les fichiers de données et les fichiers journaux. Il vous permet d’être en conformité avec de nombreuses lois, réglementations et directives établies dans différents secteurs d’activité. Cette possibilité permet aux développeurs de logiciels de chiffrer les données à l’aide des algorithmes de chiffrement AES et 3DES sans modifier les applications existantes.

Remarque

TDE n’est pas disponible pour les bases de données système. Il ne peut pas être utilisé pour chiffrer master, modelou msdb. tempdb est automatiquement chiffré lorsqu’une base de données utilisateur a activé TDE, mais ne peut pas être chiffrée directement.

TDE n’assure pas de chiffrement sur les canaux de communication. Pour plus d’informations sur le chiffrement des données entre les canaux de communication, consultez Configurer SQL Server Moteur de base de données pour chiffrer les connexions.

Rubriques connexes :

À propos du chiffrement transparent des données

Le chiffrement d’un fichier de base de données s’effectue au niveau de la page. Les pages au sein d’une base de données chiffrée sont chiffrées avant d’être écrites sur disque et déchiffrées au moment d’être lues en mémoire. TDE n’augmente pas la taille de la base de données chiffrée.

Informations applicables à SQL Database

Lorsque vous utilisez TDE avec Azure SQL Database, SQL Database crée automatiquement le certificat au niveau du serveur stocké dans la master base de données. Pour déplacer une base de données TDE sur SQL Database, vous n’avez pas besoin de déchiffrer la base de données pour l’opération de déplacement. Pour plus d’informations sur l’utilisation de TDE avec SQL Database, consultez chiffrement transparent des données avec Azure SQL Database.

Informations applicables à SQL Server

Après avoir sécurisé une base de données, vous pouvez la restaurer à l’aide du certificat adéquat. Pour plus d'informations sur les certificats, consultez SQL Server Certificates and Asymmetric Keys.

Après avoir activé TDE, sauvegardez immédiatement le certificat et la clé privée associée. Si le certificat devient indisponible ou si vous restaurez ou attachez la base de données sur un autre serveur, vous aurez besoin d’une sauvegarde du certificat et de la clé privée. À défaut, vous ne pourrez pas ouvrir la base de données. Les certificats stockés dans une base de données système autonome doivent également être sauvegardés.

Conservez le certificat de chiffrement même si vous désactivez TDE 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 rester protégées. Le certificat peut aussi vous être utile pour certaines opérations tant que vous n’effectuez pas une sauvegarde complète de la base de données.

Vous pouvez toujours utiliser un certificat dont la date d’expiration est passée pour chiffrer et déchiffrer des données avec TDE.

Hiérarchie de chiffrement

L’API de protection des données Windows (DPAPI) est à la racine de l’arborescence de chiffrement, sécurise la hiérarchie de clés au niveau de l’ordinateur et est utilisée pour protéger la clé principale du service (SMK) pour l’instance de serveur de base de données. Le SMK protège la clé principale de base de données (DMK), qui est stockée au niveau de la base de données utilisateur et protège les certificats et les clés asymétriques. Ces clés, à leur tour, protègent les clés symétriques, qui protègent les données. TDE utilise une hiérarchie similaire jusqu’au certificat. Lorsque vous utilisez TDE, le DMK et le certificat doivent être stockés dans la master base de données. Une nouvelle clé, utilisée uniquement pour TDE et appelée clé de chiffrement de base de données (DEK), est créée et stockée dans la base de données utilisateur.

L'illustration ci-dessous montre l'architecture du chiffrement TDE. Seuls les éléments au niveau de la base de données (la clé et ALTER DATABASE les parties de chiffrement de base de données) sont configurables par l’utilisateur lorsque vous utilisez TDE sur SQL Database.

Diagram showing the transparent data encryption architecture.

Activer TDE

Pour utiliser le chiffrement transparent des données, procédez comme suit :

S'applique à: SQL Server.

  1. Créez une clé principale.
  2. Créez ou procurez-vous un certificat protégé par la clé principale.
  3. Créez une clé de chiffrement de base de données et protégez-la à l’aide du certificat.
  4. Configurez la base de données pour qu’elle utilise le chiffrement.

L’exemple ci-dessous illustre le chiffrement et le déchiffrement de la base de données AdventureWorks2022 à l’aide d’un certificat nommé MyServerCert sur le serveur.

USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';
GO
CREATE CERTIFICATE MyServerCert WITH SUBJECT = 'My DEK Certificate';
GO
USE AdventureWorks2022;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE MyServerCert;
GO
ALTER DATABASE AdventureWorks2022
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. Pour consulter l’état de ces opérations, utilisez les vues catalogue et les vues de gestion dynamique décrits dans le tableau plus loin dans cet article.

Attention

Les fichiers de sauvegarde pour les bases de données avec TDE activés sont également chiffrés avec la clé DEK. Par conséquent, lorsque vous restaurez ces sauvegardes, le certificat qui protège la clé DEK doit être disponible. Par conséquent, au-delà de la sauvegarder de la base de données, pensez à conserver les sauvegardes des certificats de serveur. Si les certificats ne sont plus disponibles, vous perdrez des données.

Pour plus d'informations, consultez SQL Server Certificates and Asymmetric Keys.

Commandes et fonctions

Pour que les instructions suivantes acceptent les certificats TDE, utilisez une clé principale de base de données pour les chiffrer. Si vous les chiffrez par mot de passe uniquement, les instructions les rejettent en tant que chiffreurs.

Important

Si vous protégez les certificats par mot de passe après que TDE les a utilisés, la base de données devient inaccessible après un redémarrage.

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é qui chiffre une base de données
ALTER DATABASE ENCRYPTION KEY Change la clé qui chiffre une base de données
DROP DATABASE ENCRYPTION KEY Supprime la clé qui chiffre une base de données
Options ALTER DATABASE SET Explique l’option ALTER DATABASE utilisée pour activer TDE

Vues catalogue et vues de gestion dynamique

Le tableau suivant présente les vues de catalogue TDE et les vues de gestion dynamique (DMV).

Affichage catalogue ou vue de gestion dynamique Objectif
sys.databases Vue catalogue qui affiche des informations sur la base de données
sys.certificates Vue catalogue qui présente les certificats d’une base de données
sys.dm_database_encryption_keys Vue de gestion dynamique qui fournit des informations sur les clés de chiffrement d’une base de données et sur l’état de chiffrement

Autorisations

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

La consultation des métadonnées impliquées avec TDE nécessite l’autorisation VIEW DEFINITION sur un certificat.

À 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 pouvez utiliser le paramètre du mode mono-utilisateur pour la base de données pour effectuer des opérations de maintenance. Pour plus d’informations, consultez Définir une base de données en mode mono-utilisateur.

Utilisez la sys.dm_database_encryption_keys vue de gestion dynamique pour rechercher l’état du chiffrement de base de données. Pour plus d’informations, consultez la section Affichages catalogue et vues de gestion dynamique plus haut dans cet article.

Avec TDE, tous les fichiers et groupes de fichiers d’une base de données sont chiffrés. Si un groupe de fichiers d’une base de données est marqué READ ONLY, l’opération de chiffrement de base de données échoue.

Si vous utilisez une base de données dans la mise en miroir de bases de données ou la copie des journaux de transaction, les deux bases de données sont chiffrées. Les transactions de journal sont chiffrées quand elles passent de l’une à l’autre.

Important

Les index de recherche en texte intégral sont chiffrés dès lors qu’une base de données est définie pour le chiffrement. Ces index créés dans SQL Server 2005 (9.x) et versions antérieures sont importés dans la base de données par SQL Server 2008 (10.0.x) et versions ultérieures, et sont chiffrés par TDE.

Conseil

Pour surveiller les modifications apportées à l’état TDE d’une base de données, utilisez l’audit SQL Server ou l’audit Azure SQL Database. Pour SQL Server, TDE est suivi sous le groupe DATABASE_OBJECT_CHANGE_GROUPd’actions d’audit, que vous trouverez dans les groupes d’actions et actions d’audit SQL Server.

Limites

Les opérations suivantes ne sont pas autorisées pendant le chiffrement initial de la base de données, un changement de clé ou le déchiffrement de la base de données :

  • Suppression d’un fichier dans un groupe de fichiers de base de données
  • Suppression d’une base de données
  • Mise hors connexion d’une base de données
  • Détachement d'une base de données
  • Transition d’une base de données ou d’un groupe de fichiers dans un READ ONLY état

Les opérations suivantes ne sont pas autorisées pendant les CREATE DATABASE ENCRYPTION KEYinstructions , ALTER DATABASE ENCRYPTION KEYet ALTER DATABASE...SET ENCRYPTIONDROP DATABASE ENCRYPTION KEYles instructions :

  • Suppression d’un fichier dans un groupe de fichiers de base de données
  • Suppression d’une base de données
  • Mise hors connexion d’une base de données
  • Détachement d'une base de données
  • Transition d’une base de données ou d’un groupe de fichiers dans un READ ONLY état
  • Utilisation d’une ALTER DATABASE commande
  • Démarrage d’une sauvegarde de base de données ou de fichiers de base de données
  • Démarrage d’une restauration de base de données ou de fichiers de base de données
  • Création d’un instantané

Les opérations ou conditions suivantes empêchent les CREATE DATABASE ENCRYPTION KEYinstructions , , ALTER DATABASE ENCRYPTION KEYDROP DATABASE ENCRYPTION KEYet ALTER DATABASE...SET ENCRYPTION les instructions :

  • Une base de données est en lecture seule ou comporte des groupes de fichiers en lecture seule.
  • Une ALTER DATABASE commande est en cours d’exécution.
  • Une sauvegarde de données est en cours d’exécution.
  • Une base de données est à l’état hors connexion ou en cours de restauration.
  • Un instantané est en cours.
  • Des tâches de maintenance de base de données sont en cours d’exécution.

Pendant la création de fichiers de base de données, l’initialisation instantanée des fichiers n’est pas disponible quand TDE est activé.

Pour chiffrer une clé DEK avec une clé asymétrique, la clé asymétrique doit se trouver sur un fournisseur de gestion de clés extensible.

Analyse TDE

Pour activer TDE sur une base de données, SQL Server doit effectuer une analyse de chiffrement. L’analyse lit chaque page des fichiers de données dans le pool de mémoires tampons, puis réécrit les pages chiffrées sur disque.

Pour vous donner plus de contrôle sur l’analyse de chiffrement, SQL Server 2019 (15.x) introduit l’analyse TDE, qui a une syntaxe de suspension et de reprise. Vous pouvez ainsi suspendre l’analyse quand le système est soumis à une charge de travail intense ou pendant les heures de pointe et reprendre l’analyse à un moment ultérieur.

Pour suspendre l’analyse du chiffrement TDE, utilisez la syntaxe suivante :

ALTER DATABASE <db_name> SET ENCRYPTION SUSPEND;

De la même manière, utilisez la syntaxe suivante pour reprendre l’analyse du chiffrement TDE :

ALTER DATABASE <db_name> SET ENCRYPTION RESUME;

La colonne encryption_scan_state a été ajoutée à la sys.dm_database_encryption_keys vue de gestion dynamique. Elle indique l’état actuel de l’analyse du chiffrement. Il existe également une nouvelle colonne appelée encryption_scan_modify_date qui contient la date et l’heure du dernier changement d’état de l’analyse du chiffrement.

Si l’instance SQL Server redémarre pendant que son analyse de chiffrement est suspendue, un message est consigné dans le journal des erreurs au démarrage. Le message indique qu’une analyse existante a été suspendue.

Important

La fonctionnalité d’analyse TDE de suspension et de reprise n’est actuellement pas disponible dans Azure SQL Database, Azure SQL Managed Instance et Azure Synapse Analytics.

TDE et journaux des transactions

TDE protège les fichiers de données et les fichiers journaux au repos. Le chiffrement de la base de données entière après avoir activé TDE sur une base de données non chiffrée est une opération de données sizable et le temps nécessaire dépend des ressources système sur lesquelles cette base de données est en cours d’exécution. La sys.dm_database_encryption_keys DMV peut être utilisée pour déterminer l’état de chiffrement d’une base de données.

Lorsque TDE est activé, le Moteur de base de données force la création d’un nouveau journal des transactions, qui sera chiffrée par la clé de chiffrement de base de données. Tous les journaux générés par les transactions précédentes ou les transactions de longue durée actuelles entrelacées entre le changement d’état TDE ne sont pas chiffrés.

Les journaux des transactions peuvent être surveillés à l’aide de la vue DMV sys.dm_db_log_info , qui indique également si le fichier journal est chiffré ou non à l’aide de la vlf_encryptor_thumbprint colonne disponible dans Azure SQL et SQL Server 2019 (15.x) et versions ultérieures. Pour rechercher l’état de chiffrement du fichier journal à l’aide de la encryption_state colonne dans la sys.dm_database_encryption_keys vue, voici un exemple de requête :

USE AdventureWorks2022;
GO
/* The value 3 represents an encrypted state
   on the database and transaction logs. */
SELECT *
FROM sys.dm_database_encryption_keys
WHERE encryption_state = 3;
GO

Pour plus d’informations sur l’architecture du fichier journal SQL Server, consultez le journal des transactions.

Avant qu’une clé DEK ne change, la clé DEK précédente chiffre toutes les données écrites dans le journal des transactions.

Si vous modifiez un DEK deux fois, vous devez effectuer une sauvegarde de journal avant de pouvoir modifier à nouveau la clé DEK.

TDE et la base de données système tempdb

La tempdb base de données système est chiffrée si une autre base de données sur l’instance SQL Server est chiffrée à l’aide de TDE. Ce chiffrement peut avoir des conséquences sur le niveau de performance des bases de données non chiffrées sur la même instance SQL Server. Pour plus d’informations sur la tempdb base de données système, consultez la base de données tempdb.

TDE et la réplication

La réplication ne réplique pas automatiquement sous une forme chiffrée les données d’une base de données pour laquelle TDE est activé. Si vous voulez protéger les bases de données de distribution et d’abonné, activez TDE séparément.

La réplication d’instantané peut stocker les données dans des fichiers intermédiaires non chiffrés comme les fichiers BCP. La distribution initiale des données pour la réplication transactionnelle et de fusion le peut également. Au cours d’une réplication de ce type, vous pouvez activer le chiffrement pour protéger le canal de communication.

Pour plus d’informations, consultez Configurer le moteur de base de données SQL Server pour le chiffrement des connexions.

Groupes de disponibilité et TDE

Vous pouvez ajouter une base de données chiffrée à un groupe de disponibilité Always On.

Pour chiffrer les bases de données qui font partie d’un groupe de disponibilité, créez la clé principale et les certificats, ou la clé asymétrique (EKM) sur tous les réplicas secondaires avant de créer la clé de chiffrement de base de données sur le réplica principal.

Si un certificat est utilisé pour protéger la clé DEK, sauvegardez le certificat créé sur le réplica principal, puis créez le certificat à partir d’un fichier sur tous les réplicas secondaires avant de créer la clé DEK sur le réplica principal.

TDE et données FILESTREAM

Les données FILESTREAM ne sont pas chiffrées, même lorsque vous activez TDE.

TDE et sauvegardes

Les certificats sont couramment utilisés dans Transparent Data Encryption pour protéger la clé DEK. Le certificat doit être créé dans la master base de données. Les fichiers de sauvegarde des bases de données avec TDE activés sont également chiffrés à l’aide de la clé DEK. Par conséquent, lorsque vous effectuez une restauration à partir de ces sauvegardes, le certificat protégeant la clé DEK doit être disponible. Cela signifie qu’en plus de sauvegarder la base de données, vous devez conserver les sauvegardes des certificats de serveur pour éviter toute perte de données. La perte de données se produit si le certificat n’est plus disponible.

Supprimer TDE

Supprimez le chiffrement de la base de données avec l’instruction ALTER DATABASE.

ALTER DATABASE <db_name> SET ENCRYPTION OFF;

Pour voir l’état de la base de données, utilisez la vue de gestion dynamique sys.dm_database_encryption_keys.

Attendez la fin du déchiffrement avant de supprimer la clé DEK à l’aide de DROP DATABASE ENCRYPTION KEY.

Important

Sauvegardez la clé principale et le certificat utilisés pour TDE à un emplacement sûr. La clé principale et le certificat sont requis pour restaurer les sauvegardes qui ont été effectuées lors du chiffrement de la base de données avec TDE. Après avoir supprimé la clé DEK, effectuez une sauvegarde de journal suivie d’une nouvelle sauvegarde complète de la base de données déchiffrée.

TDE et l’extension du pool de mémoires tampons

Quand vous chiffrez une base de données à l’aide de TDE, les fichiers associés à l’extension du pool de mémoires tampons (BPE) ne sont pas chiffrés. Pour ces fichiers, utilisez des outils de chiffrement comme BitLocker ou EFS au niveau du système de fichiers.

TDE et OLTP en mémoire

Vous pouvez activer TDE sur une base de données contenant des objets OLTP en mémoire. Dans SQL Server 2016 (13.x) et Azure SQL Database, les enregistrements de journal OLTP en mémoire et les données sont chiffrés si vous activez TDE. Dans SQL Server 2014 (12.x), les enregistrements de journal OLTP en mémoire sont chiffrés si vous activez TDE, mais que les fichiers du MEMORY_OPTIMIZED_DATA groupe de fichiers ne sont pas chiffrés.

Instructions sur la gestion des certificats utilisés dans TDE

Vous devez sauvegarder le certificat et la clé principale de base de données lorsque la base de données est activée pour TDE et qu’elle est utilisée dans la copie des journaux de transaction ou la miroir ing de base de données. Les certificats stockés dans une base de données système autonome doivent également être sauvegardés.

Le certificat utilisé pour protéger la clé DEK ne doit jamais être supprimé de la master base de données. Cela entraîne l’accessibilité de la base de données chiffrée.

Un message semblable à celui suivant (erreur 33091) est déclenché après l’exécution CREATE DATABASE ENCRYPTION KEY du certificat utilisé dans la commande n’a pas déjà été sauvegardé.

Avertissement

le certificat utilisé pour chiffrer la clé de chiffrement de base de données n’a pas été sauvegardé. Vous devez immédiatement sauvegarder le certificat et la clé privée associée au certificat. 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.

La requête suivante peut être utilisée pour identifier les certificats utilisés dans TDE qui n’ont pas été sauvegardés à partir du moment où il a été créé.

SELECT pvt_key_last_backup_date,
    Db_name(dek.database_id) AS encrypteddatabase,
    c.name AS Certificate_Name
FROM sys.certificates c
INNER JOIN sys.dm_database_encryption_keys dek
    ON c.thumbprint = dek.encryptor_thumbprint;

Si la colonne pvt_key_last_backup_date est NULL, la base de données correspondant à cette ligne a été activée pour TDE, mais le certificat utilisé pour protéger sa clé DEK n’a pas été sauvegardé. Pour plus d’informations sur la sauvegarde d’un certificat, consultez BACKUP CERTIFICATE.

Contenu connexe