Partager via

Chiffrement transparent des données (TDE)

  • Article

S’applique à : SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW)

Transparent Data Encryption (TDE) chiffre les fichiers de données de SQL Server, de la base de données Azure SQL et d’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, l’utilisateur peut prendre certaines précautions, à savoir :

  • 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 personne malveillante qui vole des supports physiques comme des disques 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 DEK est une clé symétrique, sécurisée par un certificat stocké dans la base de données master du serveur ou par une clé asymétrique protégée par un module EKM.

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, model ou 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 sur les canaux de communication, consultez Configurer le moteur de base de données SQL Server pour le chiffrement des 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 la base de données Azure SQL, SQL Database crée automatiquement le certificat de niveau serveur stocké dans la base de données master. 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 Transparent Data Encryption avec la base de données Azure SQL.

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 (DPAPI) Windows est à la racine de l’arborescence de chiffrement. Elle sécurise la hiérarchie des clés au niveau de la machine et est utilisée pour protéger la clé principale de service (SMK) de l’instance du serveur de base de données. La 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. Elle protège également 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 qui s’étend au certificat. Lorsque vous utilisez TDE, la DMK et le certificat doivent être stockés dans la base de données master. 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é de chiffrement de la base de données et les portions ALTER DATABASE) peuvent être configurés par l’utilisateur lorsque vous utilisez TDE sur SQL Database.

Diagramme illustrant l’architecture Transparent Data Encryption.

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 des bases de données pour lesquelles l’option TDE est activée sont également chiffrés à l’aide de la DEK. Par conséquent, lorsque vous restaurez ces sauvegardes, le certificat qui protège la 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 Présente l’option ALTER DATABASE qui est utilisée pour activer le TDE.

Vues catalogue et vues de gestion dynamique

La table suivante illustre les affichages catalogue TDE et les vues de gestion dynamique des 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 vue de gestion dynamique sys.dm_database_encryption_keys pour connaître l’état du chiffrement de la 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 la base de données contient un groupe de fichiers marqué READ ONLY, l’opération de chiffrement de la 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 les versions antérieures sont importés dans la base de données par SQL Server 2008 (10.0.x) et les versions ultérieures, et sont chiffrés par TDE.

Conseil

Pour surveiller les changements d’état TDE d’une base de données, utilisez SQL Server Audit ou l’audit de la base de données Azure SQL. Pour SQL Server, TDE est suivi dans le cadre du groupe d’actions d’audit DATABASE_OBJECT_CHANGE_GROUP, que vous trouverez dans Groupes d’actions d’audit et actions de 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
  • Passage d’une base de données ou d’un groupe de fichiers à l’état READ ONLY

Les opérations suivantes ne sont pas autorisées pendant les instructions CREATE DATABASE ENCRYPTION KEY, ALTER DATABASE ENCRYPTION KEY, DROP DATABASE ENCRYPTION KEY et ALTER DATABASE...SET ENCRYPTION :

  • 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
  • Passage d’une base de données ou d’un groupe de fichiers à l’état READ ONLY
  • Utilisation d’une commande ALTER DATABASE
  • 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 instructions CREATE DATABASE ENCRYPTION KEY, ALTER DATABASE ENCRYPTION KEY, DROP DATABASE ENCRYPTION KEYet ALTER DATABASE...SET ENCRYPTION :

  • Une base de données est en lecture seule ou comporte des groupes de fichiers en lecture seule.
  • Une commande ALTER DATABASE 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 DEK à l’aide d’une clé asymétrique, cette dernière 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 permettre de mieux contrôler l’analyse de chiffrement, SQL Server 2019 (15.x) intègre l’analyse TDE, qui est dotée d’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 vue de gestion dynamique de sys.dm_database_encryption_keys. 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 au moment où son analyse de chiffrement est suspendue, un message est enregistré dans le journal des erreurs pendant le démarrage. Le message indique qu’une analyse existante a été suspendue.

Important

La fonctionnalité de suspension et de reprise de l’analyse TDE n’est pas disponible actuellement dans la base de données Azure SQL, Azure SQL Managed Instance et Azure Synapse Analytics.

TDE et journaux des transactions

TDE protège les fichiers de données et les fichiers d’historique au repos. Le chiffrement de l’ensemble de la base de données après l’activation de TDE sur une base de données non chiffrée est une opération de données importante. De plus, le temps qu’elle prend dépend des ressources du système sur lequel cette base de données est exécutée. Les sys.dm_database_encryption_keys DMV peuvent être utilisées 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 est 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 durables 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 DMV sys.dm_db_log_info, qui indique également si le fichier d’historique est chiffré ou non à l’aide de la colonne vlf_encryptor_thumbprint disponible dans Azure SQL et SQL Server 2019 (15.x), ainsi que les versions ultérieures. Pour connaître l’état de chiffrement du fichier d’historique à l’aide de la colonne encryption_state de la vue sys.dm_database_encryption_keys, ci-après un échantillon 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 d’historique de SQL Server, consultez Le Journal des transactions.

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

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

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

La base de données système tempdb est chiffrée si une autre base de données de 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 base de données système tempdb, 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.

TDE et groupes de disponibilité

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 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 DEK sur le réplica principal.

TDE et données FILESTREAM

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

TDE et sauvegardes

Les certificats sont souvent utilisés dans Transparent Data Encryption pour protéger la clé DEK. Le certificat doit être créé dans la base de données master. Les fichiers de sauvegarde des bases de données pour lesquelles TDE est activé sont également chiffrés à l’aide de la DEK. Par conséquent, lorsque vous restaurez à partir de ces sauvegardes, le certificat protégeant la DEK doit être disponible. Autrement dit, en plus de sauvegarder la base de données, vous devez conserver des sauvegardes des certificats de serveur pour empêcher toute perte de données. La perte de données survient 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 DEK en utilisant la clé 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 DEK, effectuez une sauvegarde de fichier journal, puis une nouvelle sauvegarde complète de la base de données déchiffrée.

TDE et 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 la base de données Azure SQL, 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 OLTP en mémoire sont chiffrés si vous activez TDE. Cependant, les fichiers du groupe de fichiers MEMORY_OPTIMIZED_DATA ne sont pas chiffrés.

Recommandations 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 utilisée dans la copie des journaux de transaction ou la mise en miroir de bases 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 base de données master. Cette démarche entraîne l’accessibilité de la base de données chiffrée.

Un message du type suivant (erreur 33091) est émis après l’exécution de CREATE DATABASE ENCRYPTION KEY si le 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 dès leur création.

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. Toutefois, le certificat utilisé pour protéger sa clé DEK n’a pas été sauvegardé. Pour plus d’informations sur l sauvegarde d’un certificat, consultez BACKUP CERTIFICATE.

Contenu connexe