{"id":171,"date":"2010-02-22T00:00:34","date_gmt":"2010-02-22T00:00:34","guid":{"rendered":"http:\/\/www.sqlserver.fr\/blog\/?p=171"},"modified":"2026-05-02T14:31:27","modified_gmt":"2026-05-02T12:31:27","slug":"select-without-query","status":"publish","type":"post","link":"https:\/\/www.sqlserver.fr\/blog\/select-without-query\/","title":{"rendered":"SELECT WITHOUT QUERY"},"content":{"rendered":"

La confidentialit\u00e9 des donn\u00e9es est au c\u0153ur des pr\u00e9occupations de beaucoup de monde de nos jours. Les m\u00e9thodes de cryptage de donn\u00e9es sont de plus en plus pr\u00e9sentes, afin que personne ne puisse mettre la main sur des donn\u00e9es sensibles. Personne ? Pas forc\u00e9ment, il y a toujours les administrateurs, qui avec leurs droits \u00e9tendus et leurs acc\u00e8s privil\u00e9gi\u00e9s restent les grands ma\u00eetres des donn\u00e9es.<\/span>
\nUn petit exemple simple : imaginons qu\u2019un utilisateur ayant des donn\u00e9es \u00e0 prot\u00e9ger veuille par exemple stocker des informations dans une table.<\/span><\/p>\n

use tempdb\r\ncreate table MaTableSecrete (Id int identity, Donnee varchar(1000))\r\ninsert into MaTableSecrete (Donnee) values ('Ceci est mon texte secret')<\/pre>\n
Il est clair que le premier venu disposant des droits sysadmin (comme par exemple le DBA g\u00e9rant le syst\u00e8me) n\u2019aura pas de mal \u00e0 lire les donn\u00e9es. Alors pourquoi ne pas mettre toute cette gestion de secret du c\u00f4t\u00e9 des applications clientes ? Et bien tout simplement parce que, parfois, le serveur peut avoir besoin de connaitre l\u2019information en clair (\u00e7a peut par exemple \u00eatre un mot de passe pour acc\u00e9der \u00e0 une ressource distante, ou quelque chose du genre\u2026)<\/span>
\nHeureusement, il est possible de crypter les donn\u00e9es. Diff\u00e9rentes m\u00e9thodes sont possibles, le choix importe peu dans le cadre de cet article, prenons par exemple la fonction T-SQL ENCRYPTBYPASSPHRASE.<\/span><\/p>\n
use tempdb\r\ncreate table MaTableSecreteCryptee (Id int identity, Donnee varbinary(8000))\r\ninsert into MaTableSecreteCryptee (Donnee) select ENCRYPTBYPASSPHRASE('Ceci est la cl\u00e9 de codage','Ceci est mon texte secret')\r\nselect * from MaTableSecreteCryptee<\/pre>\n
On voit bien ici que l\u2019administrateur de donn\u00e9es devra aller un peu plus loin que le SELECT pour obtenir ses donn\u00e9es.<\/span>
\nMais bon, supposons que le DBA soit un peu curieux. De nos jours, avec la mutualisation des ressources, on cherche \u00e0 ne pas n\u00e9cessairement acqu\u00e9rir une licence SQL Server pour chaque application. Il peut donc arriver qu\u2019un DBA \u00ab principal \u00bb soit responsable du maintien de l\u2019instance, et que d\u2019autres personnes soient responsables de mani\u00e8re individuelle de donn\u00e9es de chaque base et de leur s\u00e9curit\u00e9.<\/span>
\nCe fameux DBA principal pourrait donc s\u2019amuser \u00e0 utiliser SQL Profiler pour tracer les instructions lanc\u00e9es sur une base donn\u00e9e. Mais l\u00e0, SQL Server sait prot\u00e9ger les informations, car tout ce que ce DBA un peu trop curieux verra est :<\/span><\/p>\n\n\n\n\n
EventClass<\/strong><\/td>\nTextData<\/strong><\/td>\n<\/tr>\n
SQL :BatchStarting<\/td>\nuse tempdb
\ncreate table MaTableSecreteCryptee (Id int identity, Donnee varbinary(8000))
\n–*PREPARED QUERY————————————————————————————————————-
\nselect * from MaTableSecreteCryptee<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
De m\u00eame, pour d\u2019autres fonctionnalit\u00e9s li\u00e9es au cryptage, les petits curieux seront vite d\u00e9\u00e7us\u2026<\/span><\/p>\n
CREATE SYMMETRIC KEY CLE_SECRETE WITH ALGORITHM = AES_256 ENCRYPTION BY PASSWORD = 'Ceci est mon mot de passe'<\/pre>\n\n\n\n\n
EventClass<\/strong><\/td>\nTextData<\/strong><\/td>\n<\/tr>\n
SQL :BatchStarting<\/td>\n–*CREATE SYMMETRIC KEY—————————————————————————————<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Par contre, lors de l\u2019utilisation de proc\u00e9dures stock\u00e9es dynamiques, m\u00eame si l\u2019instruction en elle-m\u00eame est partiellement masqu\u00e9e, la cha\u00eene en clair est parfaitement visible pour l\u2019\u00e9v\u00e9nement SQL :BatchStarting :<\/span><\/p>\n\n\n\n\n\n
EventClass<\/strong><\/td>\nTextData<\/strong><\/td>\n<\/tr>\n
SQL :BatchStarting<\/td>\nexec (N’CREATE SYMMETRIC KEY CLE_SECRETE WITH ALGORITHM = AES_256 ENCRYPTION BY PASSWORD = \u00a0\u00bbCeci est mon mot de passe\u00a0\u00bb’)<\/td>\n<\/tr>\n
SP:StmtStarting<\/td>\n— ‘CREATE SYMMETRIC KEY’ was found in the text of this event.
\n— The text has been replaced with this comment for security reasons.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Mais avec une petite astuce, on peut aussi masquer aux DBA indiscrets les \u00e9l\u00e9ments priv\u00e9s :<\/span><\/p>\n
DECLARE @Requete nvarchar(max)\r\nSELECT @Requete =\r\n\tCASE WHEN 1=1\r\n\tTHEN 'CREATE SYMMETRIC KEY CLE_SECRETE WITH ALGORITHM = AES_256 ENCRYPTION BY PASSWORD = ''Ceci est mon mot de passe'''\r\n\tELSE EncryptByPassphrase('','')\r\n\tEND\r\nEXEC (@Requete)<\/pre>\n
n\u2019est visible que de la mani\u00e8re suivante :<\/span><\/p>\n\n\n\n\n\n
EventClass<\/strong><\/td>\nTextData<\/strong><\/td>\n<\/tr>\n
SQL :BatchStarting<\/td>\nDECLARE @Requete nvarchar(max)
\n–*ASSIGN—————————-
\n———————————————————————————————————————
\n————————————–
\nEXEC (@Requete)DROP SYMMETRIC KEY CLE_SECRETE<\/td>\n<\/tr>\n
SP:StmtStarting<\/td>\n— ‘CREATE SYMMETRIC KEY’ was found in the text of this event.
\n— The text has been replaced with this comment for security reasons.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\u00a0<\/span>Voil\u00e0 pour la protection des donn\u00e9es. Et pour ceux et celles qui s\u2019interrogent sur le pourquoi du titre de cet article, je vous laisse le soin de lancer vous-m\u00eame la requ\u00eate suivante et d\u2019en observer la trace dans le Profiler\u2026<\/span><\/p>\n
select ENCRYPTBYPASSPHRASE('Ceci est la cl\u00e9 de codage','Ceci est mon texte secret')<\/pre>\n","protected":false},"excerpt":{"rendered":"
La confidentialit\u00e9 des donn\u00e9es est au c\u0153ur des pr\u00e9occupations de beaucoup de monde de nos jours. Les m\u00e9thodes de cryptage de donn\u00e9es sont de plus en plus pr\u00e9sentes, afin que personne ne puisse mettre la main sur des donn\u00e9es sensibles. … Continuer la lecture →<\/span><\/a><\/p>\n","protected":false},"author":7,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-171","post","type-post","status-publish","format-standard","hentry","category-article_sql"],"_links":{"self":[{"href":"https:\/\/www.sqlserver.fr\/blog\/wp-json\/wp\/v2\/posts\/171","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sqlserver.fr\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.sqlserver.fr\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.sqlserver.fr\/blog\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/www.sqlserver.fr\/blog\/wp-json\/wp\/v2\/comments?post=171"}],"version-history":[{"count":23,"href":"https:\/\/www.sqlserver.fr\/blog\/wp-json\/wp\/v2\/posts\/171\/revisions"}],"predecessor-version":[{"id":1973,"href":"https:\/\/www.sqlserver.fr\/blog\/wp-json\/wp\/v2\/posts\/171\/revisions\/1973"}],"wp:attachment":[{"href":"https:\/\/www.sqlserver.fr\/blog\/wp-json\/wp\/v2\/media?parent=171"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.sqlserver.fr\/blog\/wp-json\/wp\/v2\/categories?post=171"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.sqlserver.fr\/blog\/wp-json\/wp\/v2\/tags?post=171"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}