Explication du chiffrement SQL Server : TDE, chiffrement au niveau des colonnes et plus

La protection des données est essentielle pour garantir que votre organisation est conforme aux normes de conformité réglementaire telles que le GDPR 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 aider, Microsoft SQL Server prend en charge 5 types différents de chiffrement pour protéger les données. Cet article explique chacun d'eux et où ils doivent être utilisés.

Chiffrement du 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) afin de chiffrer le trafic lorsqu'il se déplace entre l'instance du serveur et l'application cliente. De plus, le client peut valider l'identité du serveur en utilisant le certificat du serveur. SSL protège uniquement les données lorsqu'elles traversent le réseau, mais, contrairement à la plupart des autres formes de chiffrement 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 devrez installer un certificat sur le SQL Server. La meilleure façon de faire cela est de demander un certificat auprès de votre propre autorité de certification d'entreprise (CA). Windows Server peut être configuré en tant que CA et vous pouvez configurer les clients de manière à ce 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.

SQL Server Transparent Data Encryption (TDE)

La Transparent Data Encryption (TDE) dans SQL Server protège les données au repos en chiffrant les données de la base de données et les fichiers journaux sur le disque. Elle fonctionne de manière transparente pour les applications clientes existantes, de sorte qu'elles n'ont pas besoin d'être modifiées lorsque TDE est activé. TDE utilise un chiffrement 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 fichiers de données et de 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. Elle fonctionne également pour Azure SQL Database, Azure SQL Data Warehouse et Parallel Data Warehouse.

Le chiffrement TDE a une structure hiérarchique, avec l'API de protection des données Windows (DPAPI) au sommet de la hiérarchie et utilisée pour chiffrer la clé maître de service (SMK). Vous pouvez utiliser la SMK pour chiffrer les identifiants, les mots de passe des serveurs liés et les clés maîtres de base de données (DMK) résidant dans différentes bases de données. Une DMK SQL est une clé symétrique qui protège les clés privées des certificats et des clés asymétriques stockées dans les bases de données.

SQL Server peut générer des certificats auto-signés pour une utilisation avec TDE ou vous pouvez demander un certificat auprès d'une CA (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 aurez besoin de restaurer ou d'attacher la base de données sur un autre SQL Server. Si vous activez TDE sur une autre base de données SQL Server, la base de données système tempdb est également chiffrée. Si vous désactivez TDE, vous devriez conserver le certificat et la clé privée car des parties du journal des transactions pourraient rester chiffrées jusqu'à ce que vous effectuiez 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 par un certificat stocké dans la base de données principale, soit une clé asymétrique protégée par un service utilisant la Gestion Extensible des Clés (EKM), tel que Microsoft Azure Key Vault. Les fichiers de sauvegarde des bases de données activées TDE sont chiffrés en utilisant la DEK, donc pendant les opérations de restauration, le certificat protégeant la 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 autre mot de passe pour déchiffrer les données (clé privée). Vous pouvez utiliser la commande CREATE CERTIFICATE pour créer des certificats, et les commandes Transact-SQL CREATE SYMMETRIC KEY et CREATE ASYMMETRIC KEY pour créer des clés de chiffrement de base de données.

Chiffrement des sauvegardes

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

Tout comme avec TDE, si vous activez le chiffrement 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 les données. Les sauvegardes peuvent également être chiffrées lors de l'utilisation de SQL Server Managed Backup vers Microsoft Azure.

Il est important de noter que si vous utilisez un certificat pour chiffrer les sauvegardes, vous devez disposer du certificat original lors de la restauration des données. Cela signifie que le certificat doit avoir la même empreinte digitale que lors de la création de la sauvegarde. Renouveler les certificats ou les modifier de quelque manière que ce soit peut entraîner un changement 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 chiffrées, elles ne sont pas sécurisées au-delà de la simple utilisation d'une fonction dans le contexte utilisateur pour les déchiffrer. De plus, étant donné qu'une fonction est nécessaire pour déchiffrer les données, les applications clientes doivent être modifiées pour fonctionner avec le chiffrement au niveau des cellules.

Gestion des clés de chiffrement

Comme avec TDE, vous devez créer une clé principale (DMK) avant d'utiliser le chiffrement au niveau des cellules. Il existe quatre options pour chiffrer les informations en utilisant le chiffrement au niveau des cellules :

• Vous pouvez utiliser une phrase secrète pour chiffrer et déchiffrer les données, mais vous devez chiffrer les procédures stockées et les fonctions ; sinon, la phrase secrète peut être 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 suffisamment robustes et offrent un bon équilibre entre sécurité et performance.
• Les certificats offrent également un bon équilibre entre sécurité et performance, et ils peuvent être associés à un utilisateur de base de données.

Toujours chiffré

Always Encrypted chiffre 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 une séparation entre les propriétaires de données et les gestionnaires de données. Par exemple, avec Always Encrypted activé, vous pouvez être sûr que vos administrateurs de base de données ne pourront pas lire les données sensibles. Comme le nom l'indique, les données sont chiffrées au repos et si 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 : les clés de chiffrement de colonne et les clés principales de colonne. Les clés de chiffrement de colonne protègent les données dans une colonne et les clés principales de colonne sont des ‘clés protégeant les 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 externes de confiance, comme 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 les versions ultérieures, mais uniquement dans les éditions Enterprise. En raison des exigences supplémentaires côté client, Always Encrypted est mieux adapté aux situations où la séparation des propriétaires et des gestionnaires de données est une exigence principale.