SQL Server 2016 :Toujours chiffré

SQL Server 2016 inclut une fonctionnalité de sécurité de base de données appelée Always Encrypted. Comme nous avons ajouté la prise en charge d'Always Encrypted au pilote ODBC SQL Server, nos clients pourront profiter de cette fonctionnalité.

Always Encrypted protège les données SQL Server au point où elles sont le plus susceptibles d'être attaquées :lorsque ces données sont utilisées. Par exemple, lors de transactions et de calculs. Cela diffère des fonctionnalités de chiffrement SQL Server existantes car elles nécessitent que les données soient déchiffrées avant que des opérations puissent être effectuées dessus.

La clé de chiffrement qui protège les colonnes Always Encrypted est stockée sur la machine de l'application. Cela signifie que SQL Server ne peut pas déchiffrer les données Always Encrypted. Si la machine SQL Server est compromise, l'attaquant ne pourra accéder qu'aux données Always Encrypted sous forme chiffrée.

Pour la plupart des utilisateurs, la fonctionnalité Always Encrypted sera transparente, c'est-à-dire qu'ils sont isolés du fonctionnement d'Always Encrypted et n'ont pas à changer ce qu'ils font pour bénéficier de la fonctionnalité.

Du côté de l'application, le chiffrement est effectué par le pilote logiciel qui fournit l'interface client pour SQL Server. Sous Linux et UNIX, il s'agit d'un pilote ODBC, qui crypte ou décrypte de manière transparente les données en fonction du sens de déplacement. Dans le cas du pilote Easysoft, Always Encrypted est activé en définissant un paramètre de chaîne de connexion.

Alors que les gens s'inquiètent de plus en plus de la sécurité de leurs données dans le cloud, Always Encrypted sera disponible dans Azure SQL, la version cloud payante de SQL Server. Le pilote ODBC d'Easysoft pour Azure SQL prendra donc également en charge Always Encrypted.

Procédure :Utilisation des données de colonne Always Encrypted sous Linux

Le pilote ODBC SQL Server d'Easysoft vous permet de mettre à jour et d'interroger les données contenues dans les colonnes Always Encrypted.

Créer la table et générer les clés de chiffrement

Ces étapes sont effectuées sur la machine SQL Server.

Dans SQL Server Management Studio 2016 CTP3 ou version ultérieure, créez une nouvelle base de données.
Dans la nouvelle base de données, créez une table contenant une ou plusieurs colonnes dont vous souhaitez chiffrer le contenu. Par exemple :
```
CREATE TABLE dbo.EncryptedTable( ID INT IDENTITY(1,1) PRIMARY KEY, LastName NVARCHAR(32), Salary INT NOT NULL);
```
Cliquez avec le bouton droit sur la base de données. Dans le menu contextuel, choisissez Tâches> Chiffrer les colonnes .
L'assistant Always Encrypted démarre.
Sur la sélection de colonne page, développez les tableaux et sélectionnez les colonnes que vous souhaitez chiffrer.
Choisissez un type de chiffrement pour chaque colonne.
Déterministe - chiffre toujours avec le même texte chiffré, ce qui permet d'effectuer des recherches d'égalité, des jointures et des regroupements.

Randomisé génère une valeur de texte chiffré différente pour le même texte brut, ce qui est plus sûr, mais ne prend en charge aucune opération.
Choisissez CEK_Auto1 (New) comme clé de chiffrement pour chaque colonne, qui est une nouvelle clé générée automatiquement. Choisissez Suivant .

Sur la page de configuration de la clé principale, acceptez les paramètres par défaut :

Champ	Valeur
Sélectionner la clé principale de la colonne	Générer automatiquement la clé principale de la colonne
Sélectionnez le fournisseur du magasin de clés	Magasin de certificats Windows
Sélectionner la clé principale de la colonne	Utilisateur actuel

Utilisez Suivant bouton pour passer au Résumé page. Choisissez Terminer .
Attendez que l'assistant se termine, puis choisissez Fermer .

Exportation des certificats

Pour transférer les certificats sur la machine Linux, vous devez d'abord les exporter sur Windows.

Dans une fenêtre d'invite de commande, saisissez certmgr , pour lancer le composant logiciel enfichable Certificats.
Le nouveau certificat Always Encrypted sera disponible sous Certificats - Utilisateur actuel > Personnel > Certificats .
Cliquez avec le bouton droit sur le certificat (qui s'appellera quelque chose comme Always Encrypted Auto Certificate1 ). Dans le menu contextuel, choisissez Toutes les tâches > Exporter .
L'assistant d'exportation de certificat démarre. Choisissez Suivant .
Choisissez Oui, exporter la clé privée .
Acceptez les valeurs par défaut dans la page Exporter le format de fichier. Choisissez Suivant .
Fournissez un mot de passe lorsque vous y êtes invité. Choisissez Suivant .
Nommez et enregistrez le certificat lorsque vous y êtes invité. Par exemple, CMK_Auto1.pfx .
Utilisez Suivant et Terminer boutons pour terminer l'assistant.

Installation des certificats sous Linux

Transférez les certificats exportés vers la machine Linux à partir de laquelle vous souhaitez accéder aux colonnes Always Encrypted :

Copiez le certificat que vous venez d'exporter vers ~/ssl/private sur la machine Linux ou UNIX sur laquelle vous avez installé le pilote ODBC SQL Server.
~ est le répertoire personnel de l'utilisateur qui exécutera l'application qui se connecte à SQL Server via le pilote Easysoft ODBC. ~/ssl/private est l'emplacement à partir duquel la couche OpenSSL intégrée au pilote tentera de charger un certificat personnel. Créez le répertoire s'il n'existe pas. Par exemple :
```
$ mkdir -p ~/ssl/private$ cd ~/ssl/private$ mv /tmp/CMK_Auto1.pfx .
```
Pour utiliser le certificat avec le pilote ODBC SQL Server, vous devez supprimer la phrase secrète qu'il contient. Pour ce faire, OpenSSL doit être installé sur la machine. (Ceci n'est nécessaire que pour supprimer la phrase secrète. Pour les autres opérations, le pilote ODBC SQL Server utilise une couche OpenSSL intégrée.) Supprimez la phrase secrète à l'aide des commandes suivantes. Lorsque vous êtes invité à saisir la phrase secrète après la seconde commande, appuyez sur RETURN sans rien saisir. Cela définira la phrase de passe sur rien.
```
$ openssl pkcs12 -in CMK_Auto1.pfx -nodes -out temp.pemEntrez le mot de passe d'importation :*******MAC vérifié OK$ openssl pkcs12 -export -in temp.pem -out nopassphrase.p12Entrez le mot de passe d'exportation :vérification - Entrez le mot de passe d'exportation : $
```
Pour charger le certificat, le pilote ODBC SQL Server utilise les métadonnées qu'il reçoit de SQL Server concernant la colonne chiffrée. Le nom du certificat que le pilote reçoit de SQL Server se présente sous la forme my/thumbprint . Vous devez utiliser cette convention de dénomination pour le certificat. Utilisez OpenSSL pour afficher l'empreinte numérique du certificat, puis renommez le certificat dans un sous-répertoire nommé my :
```
$ openssl x509 -in temp.pem -fingerprint -noout | tr -d ":"SHA1 Fingerprint=EFC1940E545941D6C05C763361403F55A5DEF0E8$ mkdir my$ cp nopassphrase.p12 my/EFC1940E545941D6C05C763361403F55A5DEF0E8$ ln -s my My
```
Remarque Lors des tests, nous avons remarqué que SQL Server nommait parfois le certificat My/thumbprint . Le lien symbolique dans l'exemple ci-dessus contourne cette incohérence.

Installation du pilote ODBC SQL Server

Le pilote ODBC SQL Server fournit non seulement la couche de connectivité entre l'application et SQL Server, mais il gère également le chiffrement/déchiffrement des données stockées dans les colonnes Always Encrypted.

Installez et mettez sous licence le pilote ODBC SQL Server. Pour savoir comment procéder, reportez-vous à la documentation du pilote ODBC SQL Server. Si votre application est 64 bits, téléchargez la version 64 bits du pilote ODBC. Sinon, utilisez la version 32 bits du pilote, quelle que soit l'architecture du système d'exploitation.

Une source de données ODBC contient les informations de chaîne de connexion qui permettent au pilote ODBC SQL Server de se connecter à l'instance SQL Server cible. Sur notre machine, les sources de données ODBC sont stockées dans /etc/odbc.ini . Cet extrait de source de données montre les paramètres pertinents pour les colonnes Always Encrypted :

[SQLSERVER_2016]Driver=Easysoft ODBC-SQL Server SSL # Doit utiliser la version SSL de driverServer=machine\sqlserver_instanceDatabase=database_with_always_encrypted_dataUser=user # Cela peut être une connexion Windows ou SQL Server. à # insérer dans une colonne Always Encrypted définie sur Enabled

Remarque Si votre connexion échoue avec l'erreur "La connexion SSL a échoué dans l'appel système", votre système ne dispose pas d'un "dispositif aléatoire". Voir l'Entropy attribut dans le manuel du pilote ODBC SQL Server pour plus d'informations sur ce qu'il faut faire à ce sujet.

Insérer des données dans une colonne toujours chiffrée

Nous avons maintenant créé une table vide avec des colonnes Always Encrypted et configuré notre ordinateur client Linux afin que le pilote ODBC SQL Server puisse fonctionner avec Always Encrypted Data. Ensuite, nous devons remplir le tableau avec des données.

Pour insérer des données dans une colonne Always Encrypted, une application doit :

Utilisez une insertion paramétrée, c'est-à-dire INSERT INTO EncryptedTable VALUES (?, ?).
Cela permet au pilote ODBC SQL Server de faire la différence entre les valeurs de colonne (qu'il doit chiffrer) et le texte de l'instruction SQL (qui doit rester en texte brut ; avec Always Encrypted, rappelez-vous que SQL Server ne fait aucun déchiffrement).
Décrivez explicitement le type de données des paramètres.
SQL Server ne fournit pas les informations nécessaires sur une colonne Always Encrypted pour que le pilote ODBC SQL Server découvre le type de données à l'aide de SQLDescribeParam .

Voici un exemple Perl qui montre comment procéder :

# Utilisez Perl DBI / DBD:ODBC pour insérer des données dans les colonnes Always Encrypted.use strict;use warnings;use DBI;my $data_source =q/dbi:ODBC:SQLSERVER_2016/;my $h =DBI->connect( $data_source) ou die "Impossible de se connecter à $data_source :$DBI::errstr";$h->{RaiseError} =1;my $s =$h->prepare(q/insert into EncryptedTable values(?, ?)/);my $lastname='Smith';my $salary=25000;# Définir le type de données des colonnes cibles.# Impossible d'utiliser SQLDescribeParam avec des colonnes Always Encrypted.$s->bind_param(1, $lastname, DBI ::SQL_WVARCHAR);$s->bind_param(2, $salary, DBI::SQL_INTEGER);$s->execute($lastname,$salary);$h->disconnect;

Voici un exemple en C qui montre comment procéder :

#include #include #include #include #include #include #include #define LASTNAME_LEN 6SQLHENV henv =SQL_NULL_HENV ; // EnvironnementSQLHDBC hdbc =SQL_NULL_HDBC ; // Descripteur de connexionSQLHSTMT hstmt =SQL_NULL_HSTMT ; // Instruction handleSQLRETURN retcode;SQLCHAR strLastName[]="Jones";SQLINTEGER pSalary=25000;SQLLEN lenLastName=0;int main () { // Attribuer l'environnement retcode =SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &henv); // Définir le retcode de la version ODBC =SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER*)SQL_OV_ODBC3, 0); // Allouer la connexion retcode =SQLAllocHandle(SQL_HANDLE_DBC, henv, &hdbc); // Se connecter au DSN retcode =SQLConnect(hdbc, (SQLCHAR*) "MyDSN", SQL_NTS, (SQLCHAR*) NULL, 0, NULL, 0); // Allocate Statement Handle retcode =SQLAllocHandle(SQL_HANDLE_STMT, hdbc, &hstmt); // Lie les paramètres à tous les champs retcode =SQLBindParameter(hstmt, 1, SQL_PARAM_INPUT, SQL_C_CHAR, SQL_WVARCHAR, LASTNAME_LEN, 0, strLastName, LASTNAME_LEN, &lenLastName); retcode =SQLBindParameter(hstmt, 2, SQL_PARAM_INPUT, SQL_C_LONG, SQL_INTEGER, 0, 0, &pSalary, 0, NULL); retcode =SQLPrepare(hstmt, (SQLCHAR*)"INSERT INTO [dbo].[EncryptedTable] ([LastName],[Salary]) VALUES (?,?)", SQL_NTS); lenLastName=strlen((char*)strLastName); retcode =SQLExecute(hstmt);exit :printf ("\nComplete.\n"); // Descripteurs libres // Instruction if (hstmt !=SQL_NULL_HSTMT) SQLFreeHandle(SQL_HANDLE_STMT, hstmt); // Connexion if (hdbc !=SQL_NULL_HDBC) { SQLDisconnect(hdbc); SQLFreeHandle(SQL_HANDLE_DBC, hdbc); } // Environnement if (henv !=SQL_NULL_HENV) SQLFreeHandle(SQL_HANDLE_ENV, henv); renvoie 0 ;}

Maintenant que les colonnes sont remplies, nous pouvons utiliser isql pour récupérer les données :

$ /usr/local/easysoft/unixODBC/bin/isql.sh -v SQLSERVER_2016SQL> select * from EncryptedTable+----+----------+-------- ----+| identifiant | Nom | Salaire |+----+----------+------------+| 1 | forgeron | 25000 |+----+----------+------------+

La journalisation des pilotes était activée dans notre source de données. L'extrait suivant du journal du conducteur montre que :

SQL Server fournit le nom du certificat en tant que méta-informations sur la colonne.
Les données de la colonne sont chiffrées côté SQL Server et restent donc chiffrées en transit. Le pilote ODBC SQL Server sur le client déchiffre les valeurs de colonne, puis les renvoie en texte brut à l'application.

1. M.S.S.Q.L._.C.E.R.T.I.F.I.C.A.T.E._.S.T.O.R.E.7.C.u.r.r.e.n.t.U.s.e.r./.m.y./.7.2.8.8.1.8.C.5.F.B.2.C.6.E.B.F.C.4.9.5.3.D.B.C.1.2 .8.9.0.8.3.E..R.S.A._.O.A.E.P.......8.I.D.................@.......... L.a.s.t.N.a.m.e........Q.......8....S.a.l.a.r.y...........2. PKTDUMP :colonne chiffrée.);...'A..zs..I..N.]r..p.-..$....S;.].km6.....3cr.OhR ..j*.....fj....ARN{V.F.....DETAIL :EVP_DecryptInit renvoie 1DETAIL :EVP_DecryptUpdate renvoie 1, 0DETAIL :EVP_DecryptUpdate renvoie 1, 16DETAIL :EVP_DecryptFinal renvoie 1, 0PKTDUMP :dataS.m.i.t.h. Voir aussi
  Utilisation de données protégées avec Azure Key Vault depuis Linux
 Utilisation de données protégées avec un magasin de clés personnalisé à partir de Linux