Partie 2 : Les différents chiffrements

Nous avons le plaisir de vous proposer un résumé, divisé en trois parties, d’une étude interne sur le chiffrement SQL Server. Découvrez sans plus attendre la seconde partie du résumé de cette étude.

Chiffrement TLS de la connexion

Afin d’augmenter la sécurité des applicatifs, nous pouvons communiquer avec le serveur SQL en chiffrant les communications à l’aide de TLS. Pour cela , il est nécessaire d’installer un certificat SSL, attribué à partir d’une autorité de certification publique sur le serveur (à l’aide de la MMC par exemple).

Avant de configurer et utiliser TLS 1.2 sur le serveur SQL, il est important de vérifier qu’une mise à jour n’est pas nécessaire.

Configuration de SQL Server :

A l’aide du « Gestionnaire de configuration SQL Server »

Sur le client :

• Exporter le certificat (sans la clé privée) du serveur et l’importer sur le client.
• Installer le « client natif SQL Server ».
• Cliquer avec le bouton droit sur « Configuration de SQL Server Native Client », puis cliquer sur « Propriétés ».
• Cliquer sur « Oui » dans la page « Indicateurs », dans la zone « Forcer le chiffrement du protocole »

Chiffrement Transparent TDE

Le chiffrement TDE a été introduit avec SQL Server 2008 Entreprise. Il est pour la première fois disponible avec SQL 2019 en version Standard, son principal objectif est de protéger les données en chiffrant les fichiers physiques. Les fichiers de données MDF et le journal LDF sont également concernés par ce chiffrement.

La technologie a été créée afin que le processus de chiffrement soit complètement transparent pour les applications qui accèdent à la base de données. Le but du processus est de chiffrer les pages avant de les écrire dans les fichiers, à la lecture les pages sont donc déchiffrées puis placées en RAM. Les données sont ensuite chiffrées « au repos ». Lors des opérations (SELECT) avec déchiffrement, les données en RAM ne sont cependant pas chiffrées.

Si une base de données utilise TDE, alors la base de données TEMPDB sera également chiffrée.
Il est également important de savoir que le chiffrement / déchiffrement s’effectue par le CPU du serveur SQL, les données qui transitent sur le réseau ne sont donc pas chiffrées. Il est alors possible de mixer cette solution avec la solution de connexion TLS.

Afin de mettre en place le chiffrement TDE, il convient de :

• Créer la Master Key dans « master »
• Créer le certificat protégé par la Master Key
• Créer une clé de chiffrement dans la base de données (Database Encryption Key : DEK)
• Activer le chiffrement dans les options de la base de données
• Sauvegarder le Certificat et de la Master Key (hors site)
• S’assurer que le compte SQL allant effectuer le Backup soit « db_backupoperator »

Tips SQL :

• Création de Master Key :
  USE MASTER;
  CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘MasterKeyPassword’;
  GO
• Création du certificat :
  USE MASTER;
  CREATE CERTIFICATE myCertificate WITH SUBJECT = ‘My Certificate’, START_DATE = ’01/01/2021′, EXPIRY_DATE = ’31/12/2029′;
  GO
• Création de la clé de chiffrement dans la base client :
  USE MADB;
  CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_128 ENCRYPTION BY SERVER CERTIFICATE myCertificate;
  GO
• Activation du chiffrement TDE sur la base client :
  ALTER DATABASE MADB SET ENCRYPTION ON;
  GO

Lors de l’activation ou la désactivation du TDE sur la base de données, la mise en action est directe. Ce qui veut dire qu’un journal non tronqué contiendra des enregistrements non chiffrés ainsi que des enregistrements chiffrés. Lors de la désactivation de TDE et de la suppression de la clé de chiffrement ainsi que du certificat, il faut alors penser à tronquer le journal de transactions, sous peine de voir la base de données refuser de se monter après un reboot serveur, si cela n’est pas fait.

Concernant le backup, le serveur devant recevoir une restauration de la base de données doit posséder le certificat de chiffrement présent dans la base. Si cela est respecté, il n’y aura aucun problème avec Veeam.

Chiffrement de colonnes de tables

La sauvegarde chiffrée offre plusieurs avantages. Elle permet tout d’abord de sécuriser les données sauvegardées, mais surtout de ne restaurer les sauvegardes chiffrées que sur un serveur ou une instance disposant du certificat ou de la clé de chiffrement asymétrique utilisée. Ces éléments contribuent à s’assurer que les informations du système informatique ne puissent pas être volées et lues par quelqu’un qui souhaite les utiliser à des fins malveillantes.

Pour protéger des données, une base de données n’a pas forcément besoin d’être complètement chiffrée. Il est tout à fait possible de chiffrer uniquement certaines données, comme une adresse email, un numéro de compte, un numéro de carte de crédit, etc. Dans ce cas, SQL Server propose la fonctionnalité de chiffrement de colonnes. Il est également possible, avec ce procédé, de chiffrer plusieurs colonnes avec des clés différentes afin de proposer, par exemple, une vue « Documents confidentiels » et une autre « Documents top Secret ».

Dans ce cas, il est possible d’utiliser des utilisateurs SQL qui ont accès à une seule des clés de chiffrement ou aux deux. En fonction de l’utilisateur, l’accès à une donnée peut être différent. Les données sont chiffrées « au repos » et lors d’opération SELECT avec déchiffrement, les données en RAM ne sont pas chiffrées.

Mise en place :

• Créer une clé de chiffrement Master Key dans la base client
• Créer un certificat autosigné pour le serveur SQL
• Configurer une clé de chiffrement symétrique
• Chiffrer la ou les colonnes
• Tester la solution

Tips T-SQL :

• Création de Master Key :
  USE MADB;
  GO
  CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘MasterKeyPassword’;
  GO
• Création du certificat :
  USE MADB
  CREATE CERTIFICATE myCertificate WITH SUBJECT = ‘My Certificate’, START_DATE = ’01/01/2021′, EXPIRY_DATE = ’31/12/2029′;
  GO
• Création d’une clé de chiffrement symétrique :
  USE MADB;
  GO
  CREATE SYMMETRIC KEY mySymKey WITH ALGORITHM = AES_256 ENCRYPTION BY CERTIFICATE myCertificate;
  GO

• Ajout d’une colonne chiffrée :
  USE MADB;
  GO
  ALTER TABLE maTable ADD myCol_Encrypted varbinary(MAX);
  GO
• Mise à jour d’une table :
  USE MADB;
  GO
  OPEN SYMMETRIC KEY mySymKey DECRYPTION BY CERTIFICATE myCertificate;
  UPDATE maTable SET myCol_Encrypted = EncryptByKey (Key_GUID(‘mySymKey’), myCol) FROM maTable;
  GO
  CLOSE SYMMETRIC KEY mySymKey;
  GO
• Droits nécessaire pour déchiffrer une colonne :
  USE MADB;
  GRANT VIEW DEFINITION ON SYMMETRIC KEY::mySymKey TO myUser;
  GO
  GRANT VIEW DEFINITION ON Certificate::[myCertificate] TO myUser;
  GO
  GRANT CONTROL ON Certificate::[myCertificate] To myUser;
  GO
• Lecture d’une colonne chiffrée dans une application :
  USE MADB;
  GO
  OPEN SYMMETRIC KEY mySymKey DECRYPTION BY CERTIFICATE myCertificate;
  SELECT myID, myCol_Encrypted AS ‘Encrypted Data’, CONVERT(varchar, DecryptByKey(myCol_Encrypted)) AS ‘Decrypted Data’ FROM maTable;
  GO

Chiffrement « Toujours chiffré »

Le chiffrement avec TDE possède plusieurs défauts :

• Seules les données écrites sont chiffrées (protège les données au repos)
• Il nécessite de chiffrer toute la base de données
• Toutes les données sont chiffrées de la même manière

La sortie du chiffrement « Toujours chiffré » corrige ces défauts :

• Les données sont chiffrées au repos, en mouvement et en mémoire
• On peut choisir de chiffrer une seule colonne
• TEMPDB n’est pas chiffré
• 2 choix de chiffrement : Déterministe (pour les indexes) et Random

Il est cependant nécessaire de mettre à jour le pilote de base de données utilisé par le logiciel client afin qu’il supporte cette nouvelle fonctionnalité. Le chiffrement / déchiffrement est automatiquement réalisé par le pilote de base de données.

Points de vigilance en cas de l’utilisation de ce chiffrement :

• Les seules opérations que le Moteur de base de données peut effectuer sur les données chiffrées sont les comparaisons d’égalité (disponibles seulement avec le chiffrement déterministe).
• La taille des colonnes en base de données grandit (généralement le double).
• Attention aux types de données à chiffrer (datetime à transformer en datetime2).
• Attention à MAX pour varchar(MAX) et nvarchar(MAX) qui provoquent des erreurs de types lors du déchiffrement.
• Les Tables optimisées mémoire (in-memory OLTP) ne sont pas supportées.
• Les colonnes chiffrées de manière déterministe doivent être en Collation BIN2.
• On ne peut pas chiffrer une colonne IDENTITY.
• Les types de données : XML, IMAGE, NTEXT, TEXT, HIERARCHYID, SQL_VARIANT, GEOGRAPHY, GEOMETRY, ROWVERSION, ainsi que les types définis par les utilisateurs (user-defined types) ne sont pas supportés.
• Nécessite au miniumum dotNet 4.6
• Full Text Search non supporté

En attendant la suite

C’est ici que se termine la deuxième partie de ce résumé consacré à l’étude sur le chiffrement SQL Server. La partie suivante concernera le masquage dynamique des données et les conseils de Net4All sur le sujet.. En attendant, n’hésitez pas à consulter le reste du contenu de notre blog, ou à nous contacter pour en savoir plus.