Bienvenue dans mon dernier article, où nous plongerons dans la hiérarchie de chiffrement au sein de SQL Server. Il semble y avoir beaucoup de confusion autour de la sécurité de SQL Server, en particulier en ce qui concerne le chiffrement transparent de la base de données et les sauvegardes chiffrées. Dans cet article, nous nous concentrerons sur les concepts de clés maîtresses de service, de clés maîtresses de base de données et de certificats de serveur.

Commençons par comprendre la différence entre les clés symétriques et les clés asymétriques. Les clés symétriques sont rapides et faciles à appliquer, utilisant le même descripteur de sécurité pour le chiffrement et le déchiffrement. En revanche, les clés asymétriques offrent des couches supplémentaires de protection avec une paire de clés publique et privée pour le chiffrement et le déchiffrement, bien que ce processus soit plus lent et nécessite plus de puissance CPU.

Clé maîtresse de service

En haut de la hiérarchie de chiffrement se trouve la clé maîtresse de service. Cette clé est une clé symétrique utilisée dans l’instance SQL Server pour chiffrer les détails de connexion distants tels que les serveurs liés. Elle est créée par la configuration de SQL Server et générée par l’API de protection des données Windows, unique à chaque instance en fonction de la manière dont elle est générée. Les sauvegardes de la clé doivent être conservées, mais elles ne doivent pas être restaurées entre les instances.

Clé maîtresse de base de données

La prochaine clé symétrique utilisée est la clé maîtresse de base de données (DMK). Cette clé est principalement créée dans la base de données principale et est utilisée pour sécuriser les descripteurs de chiffrement à l’échelle du serveur, tels que les certificats utilisés dans le chiffrement transparent de la base de données (TDE) ou les sauvegardes chiffrées. Des clés maîtresses de base de données peuvent également être créées dans les bases de données utilisateur pour le chiffrement au niveau des objets. Pour les fonctions de chiffrement à l’échelle du serveur, la clé maîtresse de base de données doit être créée manuellement lors de sa première utilisation.

Il est important de noter que lors de la restauration d’une DMK à partir d’une autre instance, le comportement par défaut est de créer la clé sans chiffrement par la clé maîtresse de service. Cela signifie que la clé doit être ouverte manuellement à chaque fois que vous restaurez la base de données, ce que l’interface graphique utilisateur ne peut pas faire. Pour utiliser la DMK restaurée, vous devrez l’ouvrir et définir le chiffrement par la clé maîtresse de service.

Certificats auto-signés

Un certificat auto-signé est une clé asymétrique créée et marquée par le moteur de base de données SQL Server. Ces certificats sont généralement considérés comme non sécurisés car ils ne sont pas créés et signés par un fournisseur de certificats reconnu. Cependant, la sécurité des certificats auto-signés dépend de la capacité du service d’application à utiliser des bibliothèques de chiffrement et des algorithmes reconnus pour produire des certificats avec un degré élevé de sécurité.

Chiffrement transparent de la base de données

Lors de la configuration du chiffrement transparent de la base de données (TDE), nous suivons un processus spécifique. Tout d’abord, nous créons la clé maîtresse de base de données, puis le certificat dans la base de données principale, et enfin, la clé symétrique dans la base de données utilisateur. Une fois ces étapes terminées, nous pouvons activer le chiffrement pour la base de données.

Sauvegardes chiffrées

Pour créer des sauvegardes chiffrées, nous commençons également par créer la clé maîtresse de base de données et le certificat dans la base de données principale. Après avoir sauvegardé le certificat, nous pouvons utiliser le code suivant pour activer le chiffrement pour notre sauvegarde de base de données.

BACKUP DATABASE [AdventureWorks2014_ENCBACKUP] TO
DISK = N'E:\Bak\MSSQL12.INST1\MSSQL\Backup\AdventureWorks2014_ENCBACKUP.bak'
WITH INIT, MEDIANAME = N'Sauvegarde chiffrée'
NAME = N'AdventureWorks2014_ENCBACKUP-Sauvegarde complète de la base de données',
COMPRESSION, ENCRYPTION ( ALGORITHM = AES_256, SERVER CERTIFICATE = [MyNewCert] )

Comprendre la hiérarchie de chiffrement dans SQL Server est crucial pour mettre en œuvre une protection sécurisée des données. Les différents niveaux sont protégés par un parent jusqu’à la racine, où la clé maîtresse de service se trouve en tant que principal racine. Il est recommandé de suivre les processus de TDE et de sauvegarde chiffrée pour comprendre pleinement ce qui se passe et assurer la sécurité de votre environnement SQL Server.

N’hésitez pas à poser des questions ou à laisser des commentaires dans la discussion, je serai ravi de vous aider.