Appliquer le chiffrement transparent des données (TDE) à SQL Server
Plusieurs clients utilisent SQL Server Transparent Data Encryption (TDE) quand ils déploient leurs bases de données SQL Server SAP dans Azure. La fonctionnalité TDE de SQL Server est entièrement prise en charge par SAP (voir la Note SAP #1380493).
Dans les cas où vous effectuez une migration hétérogène à partir d’un autre système SGBD, qui s’exécute localement, vers Windows/SQL Server exécuté dans Azure, vous devez créer votre base de données cible vide dans SQL Server à l’avance. À l’étape suivante, vous allez appliquer la fonctionnalité TDE de SQL Server, tout en continuant d’exécuter votre système de production local. La raison pour laquelle vous voulez effectuer cette séquence est que le processus de chiffrement de la base de données vide peut prendre un certain temps. Les processus d’importation SAP importent ensuite les données dans la base de données chiffrée pendant la phase de temps d’arrêt. La charge supplémentaire liée à l’importation dans une base de données chiffrée a un impact plus faible que le chiffrement de la base de données après la phase d’exportation dans la phase de temps d’arrêt. Des expériences ont été négatives lors de la tentative d’application du chiffrement TDE avec charge de travail SAP exécutée sur la base de données. Il est donc recommandé de traiter le déploiement de TDE comme une activité qui doit être effectuée sans charge de travail SAP sur la base de données.
Dans les cas où vous déplacez des bases de données SQL Server SAP d’un environnement local vers Azure, il est recommandé de vérifier sur quelle infrastructure vous pouvez obtenir le plus rapidement le chiffrement appliqué. Pour ce faire, gardez à l’esprit les points suivants :
- Vous ne pouvez pas définir le nombre de threads utilisés pour appliquer le chiffrement de données à la base de données. Le nombre de threads dépend principalement du nombre de volumes de disque sur lesquels les fichiers journaux et les fichiers de données SQL Server sont distribués. Cela signifie que plus il y a de volumes distincts, plus les threads sont engagés en parallèle pour effectuer le chiffrement. Une telle configuration est en contradiction avec la suggestion de configuration des disques indiquée plus haut, préconisant la création d’un seul ou d’un petit nombre d’espaces de stockage pour les fichiers de base de données SQL Server sur des machines virtuelles Azure. Une configuration comprenant un petit nombre de volumes conduirait à un petit nombre de threads exécutant le chiffrement. Un chiffrement à un seul thread lit des plages de 64 ko, les chiffre, puis écrit un enregistrement dans le fichier journal des transactions, indiquant que la plage a été chiffrée. Par conséquent, la charge sur le journal des transactions est modérée.
- Dans les versions antérieures de SQL Server, la compression de sauvegarde n’était plus efficace lorsque vous aviez chiffré votre base de données SQL Server. Ce comportement pouvait se transformer en problème si vous envisagiez de chiffrer votre base de données SQL Server en local, puis de copier une sauvegarde dans Azure pour restaurer la base de données dans Azure. La compression de sauvegarde de SQL Server permet généralement d’obtenir un taux de compression de facteur 4.
- SQL Server 2016 introduit de nouvelles fonctionnalités qui permettent de compresser des bases de données chiffrées de manière efficace.
- En cas d’application du chiffrement TDE avec une faible charge de travail SAP, vous devez tester votre configuration pour déterminer s’il est préférable d’appliquer TDE à votre base de données SAP locale ou de le faire dans Azure. Dans Azure, vous avez certainement plus de flexibilité en termes d’infrastructure de surapprovisionnement et réduisez l’infrastructure après l’application du chiffrement TDE.
Azure Key Vault
Azure propose le service Key Vault pour stocker les clés de chiffrement. D’un autre côté, SQL Server offre un connecteur pour utiliser Azure Key Vault en tant que magasin pour les certificats TDE.