La confidentialité des données est au cœur des préoccupations de beaucoup de monde de nos jours. Les méthodes de cryptage de données sont de plus en plus présentes, afin que personne ne puisse mettre la main sur des données sensibles. Personne ? Pas forcément, il y a toujours les administrateurs, qui avec leurs droits étendus et leurs accès privilégiés restent les grands maîtres des données.
Un petit exemple simple : imaginons qu’un utilisateur ayant des données à protéger veuille par exemple stocker des informations dans une table.

use tempdb
create table MaTableSecrete (Id int identity, Donnee varchar(1000))
insert into MaTableSecrete (Donnee) values ('Ceci est mon texte secret')

Il est clair que le premier venu disposant des droits sysadmin (comme par exemple le DBA gérant le système) n’aura pas de mal à lire les données. Alors pourquoi ne pas mettre toute cette gestion de secret du côté des applications clientes ? Et bien tout simplement parce que, parfois, le serveur peut avoir besoin de connaitre l’information en clair (ça peut par exemple être un mot de passe pour accéder à une ressource distante, ou quelque chose du genre…)
Heureusement, il est possible de crypter les données. Différentes méthodes sont possibles, le choix importe peu dans le cadre de cet article, prenons par exemple la fonction T-SQL ENCRYPTBYPASSPHRASE.

use tempdb
create table MaTableSecreteCryptee (Id int identity, Donnee varbinary(8000))
insert into MaTableSecreteCryptee (Donnee) select ENCRYPTBYPASSPHRASE('Ceci est la clé de codage','Ceci est mon texte secret')
select * from MaTableSecreteCryptee

On voit bien ici que l’administrateur de données devra aller un peu plus loin que le SELECT pour obtenir ses données.
Mais bon, supposons que le DBA soit un peu curieux. De nos jours, avec la mutualisation des ressources, on cherche à ne pas nécessairement acquérir une licence SQL Server pour chaque application. Il peut donc arriver qu’un DBA « principal » soit responsable du maintien de l’instance, et que d’autres personnes soient responsables de manière individuelle de données de chaque base et de leur sécurité.
Ce fameux DBA principal pourrait donc s’amuser à utiliser SQL Profiler pour tracer les instructions lancées sur une base donnée. Mais là, SQL Server sait protéger les informations, car tout ce que ce DBA un peu trop curieux verra est :

De même, pour d’autres fonctionnalités liées au cryptage, les petits curieux seront vite déçus…

CREATE SYMMETRIC KEY CLE_SECRETE WITH ALGORITHM = AES_256 ENCRYPTION BY PASSWORD = 'Ceci est mon mot de passe'

Par contre, lors de l’utilisation de procédures stockées dynamiques, même si l’instruction en elle-même est partiellement masquée, la chaîne en clair est parfaitement visible pour l’événement SQL :BatchStarting :

Mais avec une petite astuce, on peut aussi masquer aux DBA indiscrets les éléments privés :

DECLARE @Requete nvarchar(max)
SELECT @Requete =
	CASE WHEN 1=1
	THEN 'CREATE SYMMETRIC KEY CLE_SECRETE WITH ALGORITHM = AES_256 ENCRYPTION BY PASSWORD = ''Ceci est mon mot de passe'''
	ELSE EncryptByPassphrase('','')
	END
EXEC (@Requete)

n’est visible que de la manière suivante :

 Voilà pour la protection des données. Et pour ceux et celles qui s’interrogent sur le pourquoi du titre de cet article, je vous laisse le soin de lancer vous-même la requête suivante et d’en observer la trace dans le Profiler…

select ENCRYPTBYPASSPHRASE('Ceci est la clé de codage','Ceci est mon texte secret')