La protection des données est essentielle pour garantir la conformité de votre organisation aux normes de conformité réglementaires telles que le RGPD et pour répondre aux attentes de vos clients et partenaires commerciaux. Non seulement les violations de données peuvent entraîner de lourdes amendes, mais les dommages à la réputation peuvent être tout aussi importants. Pour vous aider, Microsoft SQL Server prend en charge 5 types de cryptage différents pour protéger les données. Cet article explique chacun d’eux et où ils doivent être utilisés.

Cryptage de transport SSL

Comme les sites Web qui sécurisent le trafic entre le navigateur et le serveur, SQL Server peut être configuré pour utiliser Secure Sockets Layer (SSL) pour chiffrer le trafic lorsqu’il circule entre l’instance du serveur et l’application cliente. De plus, le client peut valider l’identité du serveur à l’aide du certificat du serveur. SSL protège uniquement les données lorsqu’elles circulent sur le réseau, mais, contrairement à la plupart des autres formes de cryptage SQL Server, SSL est disponible dans toutes les versions prises en charge de SQL Server et dans toutes les éditions.

Avant d’activer SSL, vous devez installer un certificat sur le serveur SQL. La meilleure façon de le faire est de demander un certificat à votre propre autorité de certification d’entreprise (CA). Windows Server peut être configuré en tant qu’autorité de certification et vous pouvez configurer des clients afin qu’ils fassent confiance aux certificats qu’il émet. Alternativement, il est possible d’utiliser des certificats auto-signés, bien que cela soit mieux adapté aux environnements de test.

Chiffrement transparent des données SQL Server (TDE)

Le chiffrement transparent des données (TDE) dans SQL Server protège les données au repos en cryptant les données de base de données et les fichiers journaux sur le disque. Il fonctionne de manière transparente pour les applications existantes clientes, elles n’ont donc pas besoin d’être modifiées lorsque TDE est activé. TDE utilise un cryptage en temps réel au niveau de la page. Les pages sont chiffrées avant d’être écrites sur le disque, sans augmenter la taille de vos données et fichiers journaux, et les pages sont déchiffrées lorsqu’elles sont lues en mémoire. TDE est disponible uniquement dans les éditions Enterprise de SQL Server. Il fonctionne également pour Azure SQL Database, Azure SQL Data Warehouse et Parallel Data Warehouse.

Le chiffrement TDE a une structure hiérarchique, l’API de protection des données Windows (DPAPI) se trouvant au sommet de la hiérarchie et étant utilisée pour chiffrer la clé principale de service (SMK). Vous pouvez utiliser le SMK pour chiffrer les informations d’identification, les mots de passe de serveur liés et les clés principales de base de données (DMK) résidant dans différentes bases de données. Un DMK SQL est une clé symétrique qui protège les clés privées des certificats et les clés asymétriques stockées dans des bases de données.

SQL Server peut générer des certificats auto-signés à utiliser avec TDE ou vous pouvez demander un certificat à une autorité de certification (ce qui est l’approche la plus courante). Si vous décidez d’activer TDE, vous devez sauvegarder le certificat et la clé privée associée au certificat. Vous devrez restaurer ou joindre la base de données sur un serveur SQL différent. Si vous activez TDE sur une autre base de données SQL Server, la base de données système tempdb est également cryptée. Si vous désactivez TDE, vous devez conserver le certificat et la clé privée car des parties du journal des transactions peuvent rester cryptées jusqu’à ce que vous exécutiez une sauvegarde complète.

TDE nécessite également une clé de chiffrement de base de données (DEK), qui est soit une clé symétrique protégée à l’aide d’un certificat stocké dans la base de données principale, soit une clé asymétrique protégée par un service qui utilise la gestion des clés Extensible (EKM), comme Microsoft Azure Key Vault. Les fichiers de sauvegarde des bases de données compatibles TDE sont cryptés à l’aide du DEK, de sorte que lors des opérations de restauration, le certificat protégeant le DEK doit être disponible.

Les clés symétriques utilisent le même mot de passe pour chiffrer et déchiffrer les données. Les clés asymétriques utilisent un mot de passe pour chiffrer les données (clé publique) et un mot de passe différent pour déchiffrer les données (clé privée). Vous pouvez utiliser la commande CREATE CERTIFICATE pour créer des certificats et les commandes CREATE SYMMETRIC KEY et CREATE ASYMMETRIC KEY Transact-SQL pour créer des clés de chiffrement de base de données.

Cryptage de sauvegarde

Le cryptage de sauvegarde fonctionne comme TDE mais crypte les sauvegardes SQL au lieu des données actives et des fichiers journaux. Le cryptage de sauvegarde est disponible dans SQL Server 2014 et versions ultérieures. Vous pouvez spécifier un chiffrement AES 128, AES 192, AES 256 ou Triple DES et utiliser un certificat ou une clé asymétrique stockée dans EKM. De plus, il est possible d’activer simultanément le cryptage TDE et de sauvegarde, bien que vous deviez utiliser différents certificats ou clés.

Tout comme avec TDE, si vous activez le cryptage de sauvegarde, vous devez également sauvegarder le certificat ou la clé. Sans la clé ou le certificat, le fichier de sauvegarde ne peut pas être utilisé pour restaurer des données. Les sauvegardes peuvent également être chiffrées lors de l’utilisation de la sauvegarde gérée SQL Server vers Microsoft Azure.

Il convient de noter que si vous utilisez un certificat pour chiffrer les sauvegardes, vous devez disposer du certificat d’origine lors de la restauration des données. Cela signifie que le certificat doit avoir la même empreinte que lors de la création de la sauvegarde. Le renouvellement des certificats ou leur modification de quelque manière que ce soit peut entraîner une modification de l’empreinte digitale.

Chiffrement au niveau des colonnes/cellules

Disponible dans toutes les éditions de SQL Server, le chiffrement au niveau des cellules peut être activé sur les colonnes contenant des données sensibles. Les données sont chiffrées sur le disque et restent chiffrées en mémoire jusqu’à ce que la fonction DECRYPTBYKEY soit utilisée pour les déchiffrer. Par conséquent, bien que les données SQL soient cryptées, elles ne sont pas sécurisées au-delà de la simple utilisation d’une fonction dans le contexte de l’utilisateur pour les déchiffrer. De plus, comme une fonction est nécessaire pour déchiffrer les données, les applications clientes doivent être modifiées pour fonctionner avec un cryptage au niveau de la cellule.

Gestion des clés de chiffrement

Comme avec TDE, vous devez créer une clé principale (DMK) avant d’utiliser le chiffrement au niveau de la cellule. Il existe quatre options pour chiffrer les informations à l’aide d’un cryptage au niveau de la cellule :

• Vous pouvez utiliser une phrase secrète pour chiffrer et déchiffrer les données, mais vous devez chiffrer les procédures et fonctions stockées; sinon, la phrase secrète est accessible dans les métadonnées.
• Les clés asymétriques offrent une sécurité renforcée mais peuvent avoir un impact sur les performances.
• Les clés symétriques sont généralement assez solides et offrent un bon équilibre entre sécurité et performances.Les certificats
• offrent également un bon équilibre entre sécurité et performances, et ils peuvent être associés à un utilisateur de base de données.

Toujours crypté

Toujours crypté crypte les données sensibles dans les applications clientes sans révéler les clés de chiffrement au moteur de base de données, assurant la séparation entre les propriétaires de données et les gestionnaires de données. Par exemple, avec Toujours Crypté activé, vous pouvez être sûr que les administrateurs de votre base de données ne pourront pas lire les données sensibles. Comme son nom l’indique, les données sont cryptées au repos et si elles sont utilisées dans un système tiers, tel qu’Azure.

Always Encrypted peut être configuré pour des colonnes de base de données individuelles. Deux types de clés sont utilisés: clés de chiffrement de colonne et clés principales de colonne. Les clés de chiffrement de colonne protègent les données d’une colonne et les clés principales de colonne sont des  » clés de protection des clés  » qui chiffrent une ou plusieurs clés de chiffrement de colonne. Les clés principales de colonne sont stockées dans des magasins de clés de confiance externes, tels qu’Azure Key Vault.

Le processus de chiffrement est transparent pour les applications clientes mais nécessite un pilote spécial sur les ordinateurs clients. Always Encrypted est disponible dans SQL Server 2016 et versions ultérieures, mais uniquement dans les éditions Enterprise. En raison des exigences supplémentaires du côté client, Always Encrypted est le mieux adapté aux situations dans lesquelles la séparation des propriétaires et des gestionnaires de données est une exigence principale.

Consultant informatique et auteur spécialisé dans les technologies de gestion et de sécurité. Russell a plus de 15 ans d’expérience dans l’informatique, il a écrit un livre sur la sécurité Windows et il a co-écrit un texte pour la série Official Academic Course (MOAC) de Microsoft.