Si vous avez besoin de stocker des données confidentielles dans votre base de données, vous pouvez utiliser le cryptage des données . SQL Server prend en charge le chiffrement avec des clés symétriques, des clés asymétriques, des certificats et des phrases de mot de passe. Je suppose que vous, le lecteur, connaissez déjà ces termes. Dans cet article, je vais me concentrer sur deux des nombreuses options de chiffrement fournies par SQL Server :
- Chiffrement transparent des données (TDE)
- Toujours chiffré (AE)
Cryptage transparent des données
Le chiffrement transparent des données (TDE) protège les données au repos lorsqu'elles ne sont pas utilisées. Lorsque les données sont utilisées, SQL Server les déchiffre automatiquement. Vous pouvez utiliser le TDE pour le chiffrement et le déchiffrement en temps réel des données et des fichiers journaux. Vous chiffrez les données avec la clé de chiffrement de la base de données (DEK) , qui est une clé symétrique. Il est stocké dans l'enregistrement de démarrage de la base de données et est donc déjà disponible pendant le processus de récupération de la base de données. Vous protégez la DEK avec un certificat dans la base de données principale. Vous pouvez également utiliser une clé asymétrique au lieu du certificat; cependant, la clé asymétrique doit être stockée dans un module EKM. TDE utilise uniquement les cryptages AES et Triple DES. TDE a été implémenté pour la première fois dans SQL Server avec la version 2012.
Vous ne pouvez utiliser TDE que sur des bases de données utilisateur. Vous ne pouvez pas exporter la clé de chiffrement de la base de données. Cette clé est utilisée uniquement par le moteur de base de données SQL Server. Les utilisateurs finaux ne l'utilisent jamais. Même si vous changez le propriétaire de la base de données, vous n'avez pas besoin de régénérer la DEK.
TDE chiffre les données au niveau de la page. De plus, il crypte également le journal des transactions. Vous devez sauvegarder le certificat utilisé pour protéger la DEK et la clé privée utilisée pour protéger le certificat immédiatement après avoir activé TDE. Si vous devez restaurer ou attacher la base de données chiffrée à une autre instance de SQL Server, vous devez restaurer à la fois le certificat et la clé privée, sinon vous ne pourrez pas ouvrir la base de données. Notez à nouveau que vous n'exportez pas la DEK, car elle fait partie de la base de données elle-même. Vous devez conserver et maintenir le certificat utilisé pour protéger la DEK même après avoir désactivé le TDE sur la base de données. En effet, certaines parties du journal des transactions peuvent encore être chiffrées. Le certificat est nécessaire jusqu'à ce que vous effectuiez la sauvegarde complète de la base de données.
Toujours chiffré
SQL Server 2016 Enterprise Edition introduit un nouveau niveau de cryptage, à savoir Always Encrypted (AE) fonctionnalité. Cette fonctionnalité permet le même niveau de protection des données que le chiffrement des données dans l'application cliente. En fait, bien qu'il s'agisse d'une fonctionnalité SQL Server, les données sont chiffrées et déchiffrées côté client. Les clés de chiffrement ne sont jamais révélées au moteur de base de données SQL Server. De cette façon, un DBA ne peut pas non plus voir les données sensibles sans les clés de chiffrement, simplement en ayant des autorisations sysadmin sur l'instance SQL Server avec les données chiffrées. De cette façon, AE fait une séparation entre les administrateurs qui gèrent les données et les utilisateurs qui possèdent les données.
Touches AE
Vous avez besoin de deux clés pour Always Encrypted. Tout d'abord, vous créez la clé principale de colonne (CMK) . Ensuite, vous créez la clé de chiffrement de colonne (CEK) et protégez-le avec le CMK. Une application utilise la CEK pour chiffrer les données. SQL Server stocke uniquement les données chiffrées et ne peut pas les déchiffrer. Cela est possible car les clés principales des colonnes ne sont pas vraiment stockées dans une base de données SQL Server. Dans la base de données, SQL Server stocke uniquement le lien vers ces clés. Les clés principales de colonne sont stockées en dehors de SQL Server, dans l'un des emplacements possibles suivants :
- Magasin de certificats Windows pour l'utilisateur actuel
- Magasin de certificats Windows pour la machine locale
- Service Azure Key Vault
- Un module de sécurité matériel (HSM) , qui prend en charge Microsoft CryptoAPI ou Cryptography API :Next Generation
Les clés de chiffrement des colonnes sont stockées dans la base de données. Dans une base de données SQL Server, seule la partie chiffrée des valeurs des clés de chiffrement de colonne est stockée, ainsi que les informations sur l'emplacement des clés principales de colonne. Les CEK ne sont jamais stockées sous forme de texte brut dans une base de données. Comme mentionné, les clés CMK sont en fait stockées dans des magasins de clés externes de confiance.
Utilisation des touches AE
Une application peut utiliser les clés AE et le chiffrement à l'aide d'un pilote compatible AE, comme le fournisseur de données .NET Framework pour SQL Server version 4.6 ou supérieure, le pilote Microsoft JDBC pour SQL Server 6.0 ou supérieur, ou le pilote Windows ODBC pour SQL Server version 13.1 ou supérieure. plus haut. L'application doit envoyer des requêtes paramétrées à SQL Server. Le pilote compatible AE fonctionne avec le moteur de base de données SQL Server pour déterminer quels paramètres doivent être chiffrés ou déchiffrés. Pour chaque paramètre qui doit être chiffré ou déchiffré, le pilote obtient les métadonnées nécessaires au chiffrement à partir du moteur de base de données, y compris l'algorithme de chiffrement, l'emplacement de la CMK correspondante et la valeur chiffrée de la CEK correspondante. Ensuite, le pilote contacte le magasin CMK, récupère le CMK, déchiffre le CEK et utilise le CEK pour chiffrer ou déchiffrer le paramètre. Ensuite, le pilote met en cache la CEK, afin d'accélérer la prochaine utilisation de la même CEK. La figure suivante montre graphiquement le processus.
La figure représente l'ensemble du processus en étapes :
- L'application client crée une requête paramétrée
- L'application cliente envoie la requête paramétrée au pilote compatible AE
- Le pilote compatible AE contacte SQL Server pour déterminer les paramètres nécessitant un chiffrement ou un déchiffrement, l'emplacement du CMK et la valeur chiffrée du CEK
- Le pilote compatible AE récupère le CMK et déchiffre le CEK
- Le pilote compatible AE crypte le(s) paramètre(s)
- Le pilote envoie la requête au moteur de base de données
- Le moteur de base de données récupère les données et envoie le jeu de résultats au pilote
- Le pilote effectue le déchiffrement, si nécessaire, et envoie le jeu de résultats à l'application cliente
Types de chiffrement AE
Le moteur de base de données n'opère jamais sur les données en texte brut stockées dans les colonnes chiffrées. Cependant, certaines requêtes sur les données cryptées sont possibles, selon le type de cryptage. Il existe deux types de cryptage :
- Chiffrement déterministe , qui génère toujours la même valeur chiffrée pour la même valeur d'entrée. Avec ce chiffrement, vous pouvez indexer la colonne chiffrée et utiliser des recherches de points, des jointures d'égalité et des expressions de regroupement sur la colonne chiffrée. Cependant, un utilisateur malveillant pourrait essayer de deviner les valeurs en analysant les modèles des valeurs chiffrées. Ceci est particulièrement dangereux lorsque l'ensemble de valeurs possibles pour une colonne est discret, avec un petit nombre de valeurs distinctes.
- Cryptage aléatoire , qui chiffre les données de manière imprévisible.
Démo AE :Création des objets
Il est temps de montrer comment AE fonctionne à travers un code de démonstration. Commençons par créer et utiliser une base de données de démonstration.
USE master; IF DB_ID(N'AEDemo') IS NULL CREATE DATABASE AEDemo; GO USE AEDemo; GO
Ensuite, créez le CMK dans l'interface graphique SSMS. Dans l'Explorateur d'objets, actualisez le dossier Bases de données pour voir la base de données AEDemo. Développez ce dossier de base de données, développez le sous-dossier Security, puis le sous-dossier Always Encrypted Keys, puis cliquez avec le bouton droit sur le sous-dossier Column Master Key et sélectionnez l'option New Column Master Key dans le menu contextuel. Dans la zone de texte Nom, écrivez AE_ColumnMasterKey et assurez-vous de sélectionner l'option Windows Certificate Store - Local Machine dans la liste déroulante Key Store, comme le montre la figure suivante.
Vous pouvez vérifier si le CMK a été créé avec succès avec la requête suivante.
SELECT * FROM sys.column_master_keys;
Ensuite, vous créez la CEK. Dans SSMS, dans l'Explorateur d'objets, cliquez avec le bouton droit sur le sous-dossier Column Encryption Keys juste sous le sous-dossier Column Master Key et sélectionnez l'option New Column Encryption Key dans le menu contextuel. Nommez le CEK AE_ColumnEncryptionKey et utilisez le CMK AE_ColumnMasterKey pour le chiffrer. Vous pouvez vérifier si la création de la CEK a réussi avec la requête suivante.
SELECT * FROM sys.column_encryption_keys;
Actuellement, seuls les nouveaux classements binaires, les classements avec le BIN2 suffixe, sont pris en charge pour AE. Par conséquent, créons un tableau avec des classements appropriés pour les colonnes de caractères.
CREATE TABLE dbo.Table1 (id INT, SecretDeterministic NVARCHAR(10) COLLATE Latin1_General_BIN2 ENCRYPTED WITH (COLUMN_ENCRYPTION_KEY = AE_ColumnEncryptionKey, ENCRYPTION_TYPE = DETERMINISTIC, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256') NULL, SecretRandomized NVARCHAR(10) COLLATE Latin1_General_BIN2 ENCRYPTED WITH (COLUMN_ENCRYPTION_KEY = AE_ColumnEncryptionKey, ENCRYPTION_TYPE = RANDOMIZED, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256') NULL );
Démo AE :Insertion des données
Vous pouvez maintenant essayer d'insérer une ligne de données avec l'instruction suivante.
INSERT INTO dbo.Table1 (id, SecretDeterministic, SecretRandomized) VALUES (1, N'DeterSec01', N'RandomSec1');
Vous obtenez l'erreur 206, texte d'erreur :"Clash de type d'opérande :nvarchar est incompatible avec nvarchar (4000) chiffré avec (encryption_type ='DETERMINISTIC', encryption_algorithm_name ='AEAD_AES_256_CBC_HMAC_SHA_256', column_encryption_key_name ='AE_ColumnEncryptionKey', column_encryption_key_database_name') =' . SQL Server ne peut pas chiffrer ou déchiffrer les données. Vous devez modifier les données à partir d'une application cliente. Vous pouvez effectuer un ensemble limité d'opérations sur la table à partir de SQL Server. Par exemple, vous pouvez utiliser l'instruction TRUNCATE TABLE sur une table avec des colonnes AE.
J'ai créé une application console Windows cliente très simple en Visual C#. L'application récupère en fait simplement les clés et insère une seule ligne dans la table créée avec le code ci-dessus. Voici le code C#.
using System;
using System.Collections.Generic;
using System.Data;
using System.Data.SqlClient;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace AEDemo
{
class Program
{
static void Main(string[] args)
{
string connectionString = "Data Source=localhost; “ +
“Initial Catalog=AEDemo; Integrated Security=true; ” +
“Column Encryption Setting=enabled";
SqlConnection connection = new SqlConnection(connectionString);
connection.Open();
if (args.Length != 3)
{
Console.WriteLine("Please enter a numeric “ +
“and two string arguments.");
return;
}
int id = Int32.Parse(args[0]);
{
using (SqlCommand cmd = connection.CreateCommand())
{
cmd.CommandText = @"INSERT INTO dbo.Table1 “ +
“(id, SecretDeterministic, SecretRandomized)" +
" VALUES (@id, @SecretDeterministic, @SecretRandomized);";
SqlParameter paramid= cmd.CreateParameter();
paramid.ParameterName = @"@id";
paramid.DbType = DbType.Int32;
paramid.Direction = ParameterDirection.Input;
paramid.Value = id;
cmd.Parameters.Add(paramid);
SqlParameter paramSecretDeterministic = cmd.CreateParameter();
paramSecretDeterministic.ParameterName =
@"@SecretDeterministic";
paramSecretDeterministic.DbType = DbType.String;
paramSecretDeterministic.Direction = ParameterDirection.Input;
paramSecretDeterministic.Value = "DeterSec1";
paramSecretDeterministic.Size = 10;
cmd.Parameters.Add(paramSecretDeterministic);
SqlParameter paramSecretRandomized = cmd.CreateParameter();
paramSecretRandomized.ParameterName =
@"@SecretRandomized";
paramSecretRandomized.DbType = DbType.String;
paramSecretRandomized.Direction = ParameterDirection.Input;
paramSecretRandomized.Value = "RandomSec1";
paramSecretRandomized.Size = 10;
cmd.Parameters.Add(paramSecretRandomized);
cmd.ExecuteNonQuery();
}
}
connection.Close();
Console.WriteLine("Row inserted successfully");
}
}
}
Vous pouvez exécuter le code C# à partir de Visual Studio en mode débogage ou générer l'application. Ensuite, vous pouvez exécuter l'application AEDemo.exe à partir de l'invite de commande ou à partir de SSMS en mode SQMCMD.
Démonstration AE :lecture des données
Après avoir exécuté l'application, vous devriez essayer de lire les données de la même session dans SSMS que vous avez utilisée pour créer la table.
SELECT * FROM dbo.Table1;
Vous ne pouvez voir que les données cryptées. Ouvrez maintenant une deuxième fenêtre de requête dans SSMS. Faites un clic droit dans cette fenêtre et choisissez Connexion, puis Modifier la connexion. Dans la boîte de dialogue Connexion, cliquez sur le bouton Options en bas. Tapez AEDemo pour le nom de la base de données, puis cliquez sur l'onglet Paramètres de connexion supplémentaires. Dans la zone de texte, entrez "Column Encryption Setting=enabled" (sans les guillemets doubles). Cliquez ensuite sur Connecter.
Essayez à nouveau d'insérer une ligne à partir de SSMS. Utilisez la requête suivante.
INSERT INTO dbo.Table1 (id, SecretDeterministic, SecretRandomized) VALUES (2, N'DeterSec2', N'RandomSec2');
J'ai encore une erreur. Cette version SSMS que j'utilise ne peut toujours pas paramétrer les insertions ad hoc. Cependant, essayons de lire les données avec la requête suivante.
SELECT * FROM dbo.Table1;
Cette fois, la requête fonctionne, et vous obtenez le résultat suivant :
Id SecretDeterministic SecretRandomized
— ——————– —————-
1 DeterSec1 AléatoireSec1
2 DeterSec2 AléatoireSec2
Limites AE
Vous avez déjà vu certaines limitations d'Always Encrypted, notamment :
- Seuls les classements BIN2 sont pris en charge pour les chaînes
- Vous ne pouvez indexer que les colonnes avec un chiffrement déterministe et utiliser un ensemble limité d'opérations T-SQL sur ces colonnes
- Vous ne pouvez pas indexer des colonnes avec un chiffrement aléatoire
- AE est limité aux éditions Enterprise et Developer uniquement
- Travailler avec AE dans SSMS peut être pénible
Veuillez vous référer à la documentation en ligne pour une liste plus détaillée des limitations AE. Cependant, veuillez également noter les points forts de l'AE. Il est simple à mettre en œuvre car il ne nécessite aucune modification dans une application, hormis la modification des chaînes de connexion. Les données sont cryptées de bout en bout, de la mémoire du client au stockage de la base de données en passant par le réseau. Même les DBA ne peuvent pas afficher les données dans SQL Server uniquement; même les DBA ont besoin d'accéder au stockage de clé en dehors de SQL Server pour lire le CMK. AE et d'autres options de chiffrement dans SQL Server offrent un ensemble complet de possibilités, et c'est à vous et au problème métier que vous résolvez de sélectionner la méthode appropriée.
Conclusion
Le cryptage transparent des données est extrêmement simple à utiliser. Cependant, la protection des données est très limitée. TDE protège uniquement les données au repos. Cependant, Always Encrypted est vraiment une fonctionnalité puissante. Il n'est pas encore trop complexe à mettre en œuvre, et les données sont totalement protégées. Même un DBA ne peut pas le voir sans avoir accès aux clés de cryptage. Espérons que les limitations d'AE, en particulier la limitation de classement, seront supprimées dans les futures versions de SQL Server.
