On demande parfois comment on peut crypter le code d’un objet de base de données (procédure stockée, trigger, fonction, vue, …) afin qu’un utilisateur ou qu’un groupe d’utilisateurs ne puisse pas en consulter le code.
Or il faut bien se rappeler que le cryptage d’un objet de base de données implique que celui-ci soit décrypté lors de chacune de ses exécutions, ce qui peut infliger au serveur de base de données une consommation de ressources élevée, peu souhaitable dans un environnement OLTP ou pour un serveur OLAP fortement sollicité.
Une alternative bien simple existe pourtant : le refus d’autorisation.
Voyons comment l’utiliser …
Nous allons créer une connexion et un utilisateur TOTO, et lui refuser le droit de voir la définition d’une procédure stockée.
Je me limite ici au cas d’une procédure stockée, mais le squelette est le même pour tout autre objet de base de données.
Si nous exécutons le script suivant, dans une session sous le login sa (connexion super-admnistrateur par défaut d’une instance SQL Server ) :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | -- Crée une connexion d'identifiant TOTO CREATE LOGIN TOTO WITH PASSWORD = '***' GO -- Change de contexte de base de données USE ELSUKET GO -- Crée un utilisateur de base de données CREATE USER TOTO FOR LOGIN TOTO GO -- Une petite procédure CREATE PROCEDURE PsTestDroits AS BEGIN SELECT 1 END GO -- Refuse l'autorisation du vue de la définition à l'utilisateur TOTO -- de la base de données ELSUKET DENY VIEW DEFINITION ON PsTestDroits TO TOTO |
Nous voyons, dans l’explorateur d’objet de SQL Server Management Studio:
Connectons nous maintenant comme le ferait l’utilisateur TOTO :
La nouvelle connexion s’ouvre dans l’explorateur d’objets avec le contexte de navigation dans la base de données de TOTO : on ne peut pas voir la procédure stockée PsTestDroits :
ElSuket