Cryptage transparent des données

Existe-t-il des meilleures pratiques lors de la configuration de TDE dans SQL Server 2008? Sur SQLMag, l'article "FAQ sur le chiffrement transparent des données" indique que le processeur peut avoir augmenté l'utilisation jusqu'à 30%?

Outre l'ajout de puissance du serveur, existe-t-il autre chose que les administrateurs de base de données font généralement lorsqu'ils activent TDE?

1. Quelques points supplémentaires que j'ai remarqués, c'est que si vous utilisez la fonction de compression de sauvegarde, cette fonctionnalité avec TDE ne fonctionne pas très bien. Nous avons remarqué un taux de compression très minime, presque négligeable. Considérez donc ce point de compression de sauvegarde si vous en utilisez un.

2. Je suis sûr que vous seriez au courant, mais juste pour ajouter, TDE est disponible pour l'édition Enterprise, alors pensez-y également lors de la configuration de SQL Server pour TDE.

3. TDE ne fournit pas le même contrôle granulaire, spécifique à un rôle d'utilisateur ou de base de données, que celui offert par le chiffrement au niveau de la cellule.

4. Assurez-vous que les clés de chiffrement sont stockées en toute sécurité dans un emplacement sécurisé accessible en cas de scénario de restauration. Familiarisez-vous avec la restauration d'une base de données qui a été chiffrée sur un nouveau serveur. (à l'origine un commentaire de Jonathan Fite ).

Tout d'abord, avant de crypter une base de données, effectuez une sauvegarde de la clé principale et du certificat et stockez-le hors ligne. N'attendez pas après avoir appliqué TDE pour ce faire. Stockez également les mots de passe dans un coffre de mots de passe et indiquez clairement quels mots de passe correspondent à quel objet; vous ne voulez vraiment pas en perdre la trace.

L'impact de TDE sur la base de données dépend entièrement de la charge de travail impliquée: j'ai récemment appliqué TDE à un entrepôt de données et l'impact sur les performances de la charge pendant la nuit n'était rien, ce qui suggère que le processus n'était pas lié au CPU. Cependant, cela peut ne pas être vrai pour votre base de données. Donc, si vous pouvez d'abord tester la charge de travail sur un environnement de développement, faites-le.

Ce ne sont pas seulement les données des fichiers qui sont cryptées: TDE cryptera également tempDB, donc si vous avez d'autres bases de données qui utilisent TempDB, vous remarquerez peut-être une baisse des performances. Les sauvegardes et les instantanés sont également cryptés.

Vérifiez également si cette base de données doit être restaurée dans d'autres environnements (par exemple, test ou UAT). Vous devrez restaurer le certificat utilisé pour chiffrer la base de données sur ces autres serveurs. Cela peut ne pas sembler trop problématique, mais si vous n'avez pas d'entreprise ou de développeur dans l'un de ces environnements, cela peut devenir coûteux. Une alternative à l'application de TDE dans l'ensemble de l'environnement consiste à restaurer la base de données dans une instance intermédiaire entreprise / développeur et à brouiller les données sensibles ou à supprimer le chiffrement et à créer une nouvelle sauvegarde à restaurer dans d'autres environnements. Ce deuxième choix n'est probablement pas le plus judicieux, mais c'est toujours une option ...

Lorsque vous activez TDE, deux verrous sont appliqués à la base de données: un verrou partagé et un verrou de mise à jour. TechNet le déclare pleinement:

Lorsque TDE est activé (ou désactivé), la base de données est marquée comme chiffrée dans la vue de catalogue sys.databases et l'état DEK est défini sur Chiffrement en cours. Le serveur démarre un thread d'arrière-plan (appelé analyse ou analyse de chiffrement) qui analyse tous les fichiers de base de données et les chiffre (ou les déchiffre si vous désactivez TDE). Pendant l'exécution du DDL, un verrou de mise à jour est pris sur la base de données. L'analyse de chiffrement, qui s'exécute de manière asynchrone avec la DDL, prend un verrou partagé. Toutes les opérations normales qui n'entrent pas en conflit avec ces verrous peuvent se poursuivre. Les opérations exclues incluent la modification de la structure du fichier et le détachement de la base de données. Alors que les écritures de base de données normales sur le disque à partir du pool de tampons sont chiffrées, les écritures du fichier journal peuvent ne pas l'être. L'analyse force également un basculement pour le fichier journal virtuel (VLF) pour garantir que les futures écritures dans le journal sont cryptées.

Mon expérience était sur des entrepôts de données qui étaient à peine utilisés pendant la journée et fortement utilisés pendant la nuit, j'ai donc pu appliquer le TDE avec un minimum de perturbations pendant la journée. Si vous chiffrez un OLTP en production, il est préférable de planifier cela pendant une fenêtre de maintenance pour minimiser les problèmes.

Edit: également sur le point de compression; s'il est vrai que TDE affecte la compression de sauvegarde, il n'affecte pas la compression de ligne / page / columnstore. Donc, si vous souhaitez équilibrer la perte de compression des sauvegardes, vous pouvez compresser des objets dans la base de données. Encore une fois, en fonction de votre charge de travail, vous pouvez / peut ne pas vouloir implémenter la compression sur votre base de données car cela stressera davantage le CPU. Il existe un excellent article TechNet sur l'implémentation de la compression: https://technet.microsoft.com/en-us/library/dd894051%28v=sql.100%29.aspx