Article rédigé par Mathieu Boselli et Sylvain Sidambarom

 

Lorsque l’on travaille avec des données utilisateur, les problématiques de sécurité apparaissent très rapidement. Ces dernières ont pour but de distinguer les accès aux données, et de protéger les données utilisateur et la réputation de l’entreprise par la même occasion.

Dans un contexte où les données des utilisateurs sont de plus en plus soumises à des réglementations suite aux nombreux scandales de vols de données qui ont lieu sur diverses plateformes, il est intéressant de regarder du côté des bases de données chiffrées et s’intéresser à la manière de travailler avec.

Dans cet article, nous vous proposons un exemple d’utilisation d’une base de données SQL serveur où certaines données sont chiffrées : nous étudierons comment configurer une application ASP.NET Core afin d’utiliser cette base de données de façon transparente grâce à la fonctionnalité Always Encrypted de SQL Server.

 

 

Petit rappel sur le chiffrement

 

Qu’est-ce que le chiffrement ?

Le chiffrement consiste à rendre une information illisible de façon réversible grâce à un algorithme (un cadenas) et une clé. Il permet de rendre difficile la lecture de la donnée par un tiers ne possédant pas sa clef et son algorithme.

 

Un cas connu est celui des messageries chiffrées où le destinataire détient la clé privée de l’envoyeur et vice-versa, telles que WhatsApp, Telegram, Signal et Olvid.

Intéressons-nous maintenant  à la fonctionnalité Always Ecrypted de SQL Server.

 

Fonctionnement de Always Encrypted de SQL Server

 

SQL serveur va créer deux colonnes dans la base de données :

• La première va référencer la master key, son nom, le type de fournisseur et le lieu où trouver la clé ;
• La seconde colonne est la clé de chiffrement qui se base sur la master key définie précédemment. Elle contient son nom, le nom de la master key source, sa valeur binaire, ainsi que l’algorithme de chiffrement utilisé pour chiffrer sa valeur.

Dans cet article, nous vous proposons d’utiliser le fournisseur Azure Key Vault et de configurer Always Encrypted depuis SSMS.

 

 

 

Comment utiliser Always Encrypted depuis SSMS ?

Prérequis

Always Encrypted est disponible dans toutes les éditions de Azure SQL Database, à partir de SQL Server 2016 (13.x) et de tous les niveaux de service de SQL Database. Pour les versions antérieures à SQL Server 2016 (13.x) SP1, la fonctionnalité Always Encrypted était limitée à l’édition Enterprise.

Il faut également disposer d’une base de données existante ainsi que d’une table SQL ayant des données sensibles à chiffrer (ex : SSN, carte bancaire, numéro de Sécurité sociale, etc.). Pour notre cas d’utilisation, nous allons utiliser la table Customers ayant pour données sensibles le nom de famille.

 

Étape 1 : créer l’Azure Key Vault

Nous vous proposons de créer l’Azure Key Vault via l’azure cli. C’est ce composant que va contenir les master keys. La première étape est l’authentification :

Az login

 

Puis vous devez définir la souscription : pour cela vous pouvez, dans un premier temps, afficher toutes les souscriptions :

Az account list

Az account set –subscription {subscriptionId}

 

Il est désormais temps de créer l’Azure Key Vault. Pour rappel, le nom de l’Azure Key Vault doit être unique et le resource group doit déjà être créé.

az keyvault create --name {Name}  --resource-group {resourceGroupName} --location westeurope

 

Il faut désormais se rajouter quelques droits nécessaires à la création des clés depuis SSMS. Pour cela, vous devrez d’abord retrouver votre « objectId » en renseignant l’adresse email de votre compte azure AD.

az ad user show --id {Email}

 

Dernière étape, l’ajout de l’access policy. Il faut renseigner le nom de l’Azure Key Vault, votre object id, et les permissions associées.

az keyvault set-policy --name {Name} --object-id {ObjectId}  --key-permissions get list create wrapKey unwrapKey verify sign

 

 

Étape 2 : créer la Column Master Key et la Column Encryption Key via SSMS

 

Connectez-vous à votre base de données via SSMS puis faites un clic droit sur votre table qui contient les informations à chiffrer. Ensuite, sélectionnez Encrypt Columns...

Le wizard Always Encrypted s’affiche. Sélectionnez Column Selection.

Vous devez cocher la ou les colonnes à chiffrer avec un Encryption Type défini par SQL Server.

 

 

Choix du type de chiffrement

 

Deux types de chiffrement sont proposés :

• Chiffrement déterministe (« deterministic »)
• Chiffrement randomisé (« randomized »)

 

Le chiffrement déterministe permet pour une même valeur d’avoir le même résultat chiffré. Ce type de chiffrement supporte les opérations de recherche et d’égalité lors de jointure, et l’indexation.

Contrairement au chiffrement déterministe, le chiffrement randomisé garantit que le résultat chiffré sera toujours différent pour une même valeur. Il est donc plus sûr que l’option précédente, cependant aucune des opérations supportées par le chiffrement déterministe n’est possible. En d’autres termes, il est plus intéressant de privilégier un chiffrement déterministe dans le cas où la donnée peut être utilisée comme référence ou comme moyen d’identification. Nous pouvons citer ainsi des numéros de compte bancaire, de Sécurité sociale ou encore un numéro de téléphone.

Le chiffrement randomisé peut être utilisé sur des données ne permettant pas une identification claire ou raisonnablement restreinte : on peut citer comme exemple une adresse ou une date de naissance.

 

Configuration de la Master Key

 

Afin de pouvoir chiffrer des données, il est nécessaire d’avoir une master key afin que l’ensemble des clés de chiffrement puisse en dériver. Deux options s’offrent à vous : stocker la master key via un certificat Windows sur votre machine locale ou utiliser Azure Key Vault afin de stocker cette master key sur le Cloud. Ici nous avons choisi la seconde option.

Sélectionnez Azure Key Vault puis connectez-vous en utilisant les mêmes identifiants que l’utilisateur qui a les droits définis précédemment. Ensuite sélectionnez l’Azure Key Vault créé précédemment.

 

 

Désormais, allez dans Summary et cliquez sur Finish. La Column  Master Key va se générer sur l’Azure Key Vault.

 

 

Si la génération des clés échoue, analysez le rapport généré. Il se peut que l’utilisateur n’ait pas les droits requis. Dans ce cas, refaites la manipulation azure cli set-policy en renseignant l’objectId de l’utilisateur connecté.

Si toutefois vous voulez passer par un script SQL et non par le wizard, il faudra exécuter les scripts suivants :

 

Point de vigilance : Notez toutefois que le script SQL ne génère pas la Column Master Key dans Azure Key Vault ; il fait juste la référence.

Dès lors, la nouvelle définition de notre table est la suivante :

 

Notez l’ajout de code qui permet de définir le type de chiffrement sur la colonne LastName. On y retrouve les éléments suivants :

• La collation Latin1_General_BIN2
• La référence à la clé de chiffrement utilisée pour cette colonne [CEK_Auto1]
• Le type de chiffrement Deterministic
• L’algorithme utilisé pour chiffrer la colonne AEAD_AES_256_CBC_HMAC_SHA_256 (pour en savoir plus, nous vous invitons à consulter la documentation Microsoft).

 

Étape 3 : création de l’App Registration et assignation des droits sur Key Vault

 

Nous allons maintenant créer une app registration et générer son client Secret afin de lui attribuer des droits côté applicatif pour déchiffrer les données. Pour cela, nous allons utiliser le portail Azure.

Dans un premier temps, allez sur l’Azure AD et sélectionnez App registrations.

 

 

Puis ajoutez une nouvelle App registration :

 

Ensuite, il faut générer un nouveau client secret dans l’onglet Certificate & Secrets en renseignant une description.

 

Lorsque la secret key (Value) a été générée, mettez-la de côté : vous vous en servirez plus tard.

Point de vigilance : Au rafraichissement de la page, la secret key n’est plus visible.

 

Pensez également à mettre de côté le clientId et le tenantId de votre organisation. Pour cela, revenez sur l’overview de l’app registration : vous y trouverez le clientId et le tenantId.

 

Dernière étape avant le code : l’assignation des rôles. Pour cela, il faut aller sur l’Azure Key Vault créé précédemment puis ajouter un nouvel access policy.

 

Dans Keys Permissions, cochez les cases Get, Unwrap Key et Verify.

 

 

Puis sélectionnez l’app registration dans la partie Principal.

 

 

Et voilà, tout est configuré côté infrastructure pour l’Always Encrypted. Nous allons donc passer au code !

 

Étape 4 : l’accès à la donnée chiffrée

 

Accéder à la donnée via SSMS

 

Voici le type de résultat que l’on observe par défaut après l’activation du chiffrement :

 

 

Pour voir les données en clair, il vous faudra activer l’Always Encrypted. Pour cela, lors de la connexion, sélectionnez Options, puis cochez Enable Always Encrypted dans l’onglet Always Encrypted.

 

 

Dès lors, on peut de nouveau avoir accès aux données à condition de s’être authentifié avec un compte ayant accès aux clés de chiffrements dans Azure Key Vault :

 

Les requêtes SQL de type LMD (select avec clause WHERE, update, insert, delete avec clause WHERE) sur des colonnes chiffrées ne sont pas supportées. Pour remédier à ce problème, il vous faudra activer la paramétrisation pour l’Always Encrypted.

Pour cela, allez dans  Query > Query Options…

 

 

Dans Execution > Advanced, cochez Enable Parameterization for Always Encrypted :

 

 

Maintenant, votre SSMS est opérationnel pour afficher (avec clause WHERE), insérer, mettre à jour ou supprimer des données chiffrées en passant par des paramètres. Voici un exemple pour chaque instruction :

 

 

 

 

 

Accéder à la donnée via une application web API

Nous vous proposons également un exemple concret d’accès aux données via une application web API.

L’API exposera trois routes :

• Une première pour récupérer la donnée ;
• Une deuxième pour persister la donnée ;
• Une troisième pour mettre à jour la donnée.

Ici, nous initialisons votre Azure key Vault afin d’avoir accès à la master key en utilisant les informations précédemment mises de côté.

 

Startup.cs

 

Ci-dessous se trouve la classe définissant le contexte de la base de données. Dans la mesure où nous utilisons Entity Framework en database first, nous devons préciser la façon dont notre modèle sera mappé à la table.

 

EncryptedDbContext.cs

 

Par défaut, Entity Framework paramétrise toutes les requêtes qu’il envoie au serveur. C’est par conséquent transparent pour le développeur.

IMPORTANT : afin de lire la donnée chiffrée, il est impératif de définir le type SQL exact de la colonne. Dans cet exemple, nous utilisons le modelBuilder.

Vous trouverez ci-dessous le contrôleur permettant de réaliser les opérations de lecture, écriture et mise à jour :

 

CustomerController.cs

 

Ci-dessous notre modèle de données utilisé pour la lecture, l’écriture, et la mise à jour des données :

 

Models

 

Une couche de sécurité supplémentaire

 

A travers cet article, nous avons vu comment la configuration – et l’utilisation – d’une base de données contenant des données chiffrées avec SQL Server, est relativement simple du point de vue de sa mise en place en base de données, de son intégration côté application cliente ainsi que des accès pour sécuriser l’ensemble des clés nécessaires à son usage.

Cette solution apporte une couche de sécurité supplémentaire, non pas sur l’accès aux données mais sur l’accès aux informations que ces données contiennent. Elle n’empêche en aucun cas le vol des données mais limite fortement leur exploitation à condition que les clés soient elles-mêmes sécurisées.

Vous disposez désormais d’une option supplémentaire pour sécuriser un peu plus vos données sensibles. À vous de jouer…

 

Tout savoir sur la Data privacy et la Transparency

Pour approfondir le sujet, nous vous invitons à télécharger dès à présent notre livre blanc “Entreprises : quelles pratiques pour sécuriser vos données ?”

 

 

Retrouvez également tous nos articles sur la gestion transparente et sécurisée des données :

• Data Privacy & Transparency : la protection des données en entreprise
• Droit à l’oubli : Quel impact sur la donnée ? Quelles procédures mettre en place ?
• Chiffrement homomorphe : comment protéger les données personnelles et garantir leur non déchiffrement ?
• Sécurité des lignes et des colonnes avec Databricks
• Comment protéger une infrastructure Cloud contre la fuite de données ?

 

 

 

Article rédigé par Mathieu Boselli et Sylvain Sidambarom