Les groupes de disponibilité sont fantastiques pour les solutions de haute disponibilité/de reprise après sinistre, et je suis sûr que les autres administrateurs de base de données seront d'accord avec moi. Cependant, il y aura des moments où nous devrons considérer attentivement certaines précautions et étapes supplémentaires pour éviter les mauvaises surprises. Par exemple, tout réplica secondaire devient le réplica principal actuel pour quelque raison que ce soit, et notre objectif est de ne pas laisser cela se produire.
Il existe deux options de cryptage fournies par SQL :sql tde contre toujours crypté. Dans cet article, je vais présenter un scénario qui oblige le DBA à accorder une attention particulière aux détails. Comme le titre l'indique, il vous guidera dans la bonne façon de gérer le cryptage des données dans les bases de données qui font partie de la configuration du groupe de disponibilité AlwaysOn.
Considérations initiales
J'utiliserai Transparent Data Encryption (TDE) comme technologie pour construire mon dossier. Il s'applique à toutes les versions prises en charge de SQL Server. Il est important de mentionner que cette fonctionnalité est disponible uniquement dans les éditions SQL Server suivantes :
- Évaluation SQL Server 2019, Standard, Développeur, Entreprise
- Évaluation SQL Server 2017, Développeur, Entreprise
- Évaluation SQL Server 2016, Développeur, Entreprise
- Évaluation SQL Server 2014, Développeur, Entreprise
- Évaluation SQL Server 2012, Développeur, Entreprise
- Centre de données SQL Server 2008R2, évaluation, développeur, entreprise
- Évaluation SQL Server 2008, Développeur, Entreprise
Voyons comment nous pouvons utiliser TDE (Transparent Data Encryption) dans SQL Server Standard Edition. Tout d'abord, nous devons créer une DMK (Database Master Key) pour chiffrer les données. Ensuite, nous créons un certificat et une clé pour pouvoir déchiffrer les données tout en y accédant. N'oubliez pas de sauvegarder le certificat et enfin d'activer le cryptage.
Remarque : La fonctionnalité TDE n'est pas prise en charge dans SQL Server Express Edition.
Cet article ne couvrira pas les étapes de création d'un groupe de disponibilité, et je m'appuie sur celui déjà construit à des fins de test. Vous pouvez en savoir plus sur le déploiement des groupes de disponibilité SQL Server AlwaysOn sur Linux.
L'environnement est basé sur Windows, mais les principes seront très similaires si vous utilisez différentes plates-formes (par exemple, SQL Server sur Linux ou Azure SQL Managed Instances).
Qu'est-ce que le chiffrement des données temporaires
La principale raison pour laquelle nous utilisons TDE est la sécurité des données et des fichiers journaux pour votre base de données SQL. Pour éviter que vos données personnelles ne soient volées, c'est une bonne idée de les défendre, de plus ce processus de cryptage est très simple. Avant que la page ne soit écrite sur le disque, les fichiers sont chiffrés au niveau de la page. Chaque fois que vous souhaitez accéder à vos données, elles sont décryptées. Après la mise en œuvre de TDE, vous aurez besoin d'un certificat spécifique et d'une clé pour restaurer ou attacher la base de données. C'est ce qu'est un algorithme de chiffrement.
Microsoft Exemple de groupe de disponibilité SQL Server
Mon groupe de disponibilité de test se compose de 2 répliques, chacune dans sa propre machine virtuelle. Voici les propriétés de base :
Comme vous pouvez le voir, il n'y a rien d'extraordinaire, juste quelques répliques utilisant le mode de validation synchrone et le mode de basculement manuel.
La capture d'écran suivante illustre une base de données appelée "test". Il est ajouté au groupe de disponibilité SQL Server AlwaysOn et il est dans l'état synchronisé.
Comment activer TDE dans SQL Server
Voici les étapes pour activer SQL Server TDE pour la base de données "test". Remarque :nous exécuterons les étapes suivantes dans le réplica principal actuel.
Étape 1
Créez une clé principale dans la base de données principale.
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';
Étape 2
Créez un certificat protégé par la clé principale.
CREATE CERTIFICATE TestCertificate WITH SUBJECT = 'My test Certificate';Étape 3
Créez la clé de chiffrement de la base de données (DEK) et protégez-la avec le certificat créé à l'étape 2.
USE test;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TestCertificate;
Étape 4
Définissez la base de données "test" pour utiliser le chiffrement.
ALTER DATABASE test
SET ENCRYPTION ON;
Comment vérifier si TDE est activé ?
Une fois que vous avez terminé, vous devez confirmer que le chiffrement transparent des données dans SQL Server est activé pour la base de données "test".
Dans les Propriétés de la base de données section, allez dans les Options page. Là, faites attention à l'État zone en bas de la fenêtre. Le chiffrement activé la valeur doit être True .
Vous pouvez également exécuter le code TSQL suivant pour le confirmer :
SELECT name,is_encrypted
FROM sys.databases
WHERE name = 'test'
Problème de gestion des clés et de certification
Remarque : Ne soyez pas surpris si vous découvrez que tempdb est également crypté. C'est parce que tempdb est l'endroit où toutes sortes d'opérations ont lieu (par exemple, le tri, les jointures par hachage, etc.), en utilisant les données de toutes les bases de données. Par conséquent, si au moins une base de données utilisateur est chiffrée, les opérations de cette base de données particulière peuvent aller dans tempdb qui devra renvoyer ces données à la base de données utilisateur. Par conséquent, renvoyer des données non chiffrées représenterait le problème.
Vous pouvez en savoir plus sur le chiffrement des sauvegardes dans SQL Server pour améliorer la sécurité de votre base de données.
Vous pouvez utiliser le code TSQL suivant pour confirmer qu'il existe une clé principale de base de données pour la base de données "test" qui est chiffrée par le certificat (comme exécuté à l'étape 3) :
SELECT
DB_NAME(database_id) AS DB,
create_date,
key_algorithm,
key_length,
encryptor_thumbprint,
encryptor_type
FROM sys.dm_database_encryption_keys
WHERE DB_NAME(database_id) = 'test'
Jusqu'ici tout va bien, du moins pour la réplique primaire. Mais que se passe-t-il si nous interrogeons sys.databases vue système pour confirmer l'état de chiffrement de la base de données "test" dans le réplica secondaire ?
Le groupe de disponibilité réplique tout ce qui concerne la base de données d'un réplica à un autre. Cependant, le réplica secondaire indique clairement qu'il n'est pas chiffré.
Vérifions notre réplique secondaire pour tout indice à ce sujet :
L'état de la base de données est "Pas de synchronisation / Suspect" - pas beau du tout. Cependant, après avoir inspecté le journal des erreurs du réplica secondaire, je peux voir ce qui suit :
2021-04-10 00:40:55.940 spid39s Error: 33111, Severity: 16, State: 3.
2021-04-10 00:40:55.940 spid39s Cannot find server certificate with thumbprint '0xDF36E3D052086AA05BBB1C64A72A2CAB5A98F240'.
2021-04-10 00:40:55.950 spid39s Error: 33111, Severity: 16, State: 3.
2021-04-10 00:40:55.950 spid39s Cannot find server certificate with thumbprint '0xDF36E3D052086AA05BBB1C64A72A2CAB5A98F240'.
2021-04-10 00:40:55.950 spid39s Always On Availability Groups data movement for database 'test' has been suspended for the following reason: "system" (Source ID 2; Source string: 'SUSPEND_FROM_REDO'). To resume data movement on the database, you will need to resume the database manually. For information about how to resume an availability database, see SQL Server Books Online.
2021-04-10 00:40:55.950 spid39s Error: 3313, Severity: 21, State: 2.
2021-04-10 00:40:55.950 spid39s During redoing of a logged operation in database 'test', an error occurred at log record ID (34:743:1). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.
Le problème principal est que le certificat utilisé pour chiffrer la clé de chiffrement de la base de données de la base de données "test" (étape 3) n'est pas présent dans le réplica secondaire.
Pourquoi ?
Parce que les groupes de disponibilité ne répliquent pas les données des bases de données système. Le certificat de serveur manquant réside dans la base de données principale du réplica principal.
Comment vérifier et configurer un certificat TDE dans SQL Server
Générons une sauvegarde du certificat du serveur dans la base de données maître du réplica principal. Ensuite, restaurez-le dans la base de données maître du réplica secondaire.
Utilisez le code TSQL suivant pour générer la sauvegarde à partir du réplica principal actuel qui a la base de données "test" avec TDE activé :
USE master;
GO
BACKUP CERTIFICATE TestCertificate
TO FILE = 'C:\temp\TestCertificate.cer'
WITH PRIVATE KEY (file='C:\temp\TestCertificate.pvk',
ENCRYPTION BY PASSWORD='<YourStrongPasswordHere>');
Avant de tenter de restaurer le certificat dans le réplica secondaire, vérifiez d'abord si la clé principale de la base de données existe dans la base de données principale. Si ce n'est pas le cas, créez-le exactement comme à l'étape 1.
Utilisez le code TSQL suivant pour restaurer le certificat dans le réplica secondaire. Remarque :Assurez-vous de copier d'abord les fichiers .cer et .pvk dans le répertoire cible.
USE master;
GO
CREATE CERTIFICATE TestCertificate
FROM FILE = 'C:\temp\TestCertificate.cer'
WITH PRIVATE KEY (
FILE = N'C:\temp\TestCertificate.pvk',
DECRYPTION BY PASSWORD = '<YourStrongPasswordHere>'
);
Ainsi, même après restauration du certificat dans le Réplica Secondaire, l'état de la base de données « test » reste le même :
Étant donné que le mouvement de données pour la base de données "test" est en pause, reprenons-le manuellement pour voir si nous avons de la chance cette fois :
Oui! L'opération a réussi. La base de données "test" est non seulement entièrement synchronisée et saine, mais également chiffrée avec TDE.
De plus, après l'exécution du basculement manuel pour échanger les rôles des répliques, tout continue de fonctionner parfaitement bien.
Conclusion
La solution présentée a parfaitement fonctionné. Cependant, ce n'est peut-être pas idéal dans tous les cas, surtout si vous êtes un administrateur de base de données qui aime planifier et faire les choses de la manière « correcte ». Je vois "correct" comme suit :
- Supprimer la base de données du groupe de disponibilité
- Exécutez toutes les étapes pour activer le chiffrement transparent des données dans le réplica où la base de données est lue/écrite.
- Sauvegardez le certificat du serveur à partir du réplica principal.
- Copiez le fichier de sauvegarde à l'emplacement ou aux emplacements du ou des réplicas secondaires.
- Restaurez le certificat dans la base de données principale.
- Rajoutez la base de données au groupe de disponibilité.
- Assurez-vous que l'état opérationnel de la base de données est correct et prévu (en fonction de votre configuration particulière).
Je lance des guillemets doubles pour "correct" parce que dans la façon dont j'ai présenté la solution, j'ai obtenu la base de données dans le réplica secondaire marqué comme Suspect. Cela seul soulèverait probablement de nombreux drapeaux / alertes / pointages du doigt indésirables. Il s'agit d'un bruit inutile que vous pouvez facilement éviter en prenant en compte toutes les considérations pour planifier et implémenter correctement TDE dans une configuration de groupe de disponibilité Always On.
Pour conclure cet article, je vous laisse avec la hiérarchie de cryptage officielle utilisée pour TDE, que Microsoft a publiée sur son site Web. Ce que j'aimerais que vous gardiez à l'esprit, c'est l'endroit où chaque élément est créé (soit dans la base de données principale ou utilisateur), afin que vous puissiez surmonter tout problème/surprise potentiel avec les groupes de disponibilité.
Si vous ne le savez pas, SQL Complete peut grandement vous aider à configurer Always Encrypted, qui est une autre technologie utile pour protéger les données sensibles.
Gardez à l'esprit que vous devrez tenir compte de la même chose que celle décrite dans cet article si vous envisagez d'utiliser Always Encrypted dans un scénario de groupe de disponibilité Always On. Cependant, les fonctionnalités introduites par SQL Complete v6.7 sont conçues pour s'assurer que vous réussissez dès le départ.
