Considérations sur l’inter-base de données

à  l’utilisateur guest lorsque les
utilisateurs n’ont pas besoin d’accéder
directement aux objets de la base de
données. Ce genre de configuration
simplifie l’administration de la sécurité
parce tous les logins peuvent partager le contexte utilisateur guest. On peut
ajouter l’utilisateur guest aux bases de
données utilisateur au moyen de la
procédure stockée système sp_grantdbaccess.
Notons que SQL Server ajoute
automatiquement l’utilisateur guest
aux bases de données système master,
msdb et tempdb.

Vous pouvez utiliser votre connaissance
des chaînes de propriété interbase
de données pour contrôler l’utilisation
des objets de la base de données
maîtresse, particulièrement les procédures
stockées étendues et les procédures
stockées OLE Automation
(sp_OA*). Ces procédures sont très
utiles sur le plan applicatif mais peuvent
s’avérer très dangereuses si elles
sont mal utilisées. Par exemple, la procédure
stockée étendue xp_cmdshell
est à  la fois puissante et destructrice.
Elle peut exécuter virtuellement toute
commande de programme ou d’OS au
moyen d’une instruction T-SQL unique
et elle fournit une méthode simple et
efficace permettant aux applications
d’invoquer les utilitaires ligne de commande
comme DTSRUN ou bcp (bulk
copy program) directement sur le serveur
de base de données. Mais il faut
prendre de grandes précautions pour
que xp_cmdshell ne permette pas à 
des utilisateurs non autorisés d’exécuter
des commandes.

Par défaut, seuls les membres du
rôle serveur fixe sysadmin peuvent
exécuter xp_cmdshell. Un utilisateur
non sysadmin qui a une permission
EXECUTE sur xp_cmdshell peut exécuter
des commandes et programmes
d’OS ad hoc. Les utilisateurs non-sysadmin
ne sont limités que par le
contexte de sécurité d’OS xp_cmdshell,
qui est le compte SQLAgentCmd-
Exec local dans SQL Server 7.0, et par
le compte proxy SQL Server Agent
configurable dans SQL Server 2000. Les
membres du rôle serveur fixe sysadmin
obéissent au contexte de sécurité du
compte de service SQL Server.

Beaucoup croient, à  tort, que les utilisateurs non-sysadmin doivent
avoir des permissions EXECUTE
directes sur xp_cmdshell pour utiliser
la procédure. Tel n’est pas le cas, grâce
aux chaînes de propriété inter-base de
données. On peut interdire les commandes
ad hoc tout en laissant les applications
exploiter la fonctionnalité
xp_cmdshell en créant une procédure
stockée utilisateur possédée par DBO,
dans une base de données utilisateur
possédée par sa qui exécute xp_cmdshell.
La chaîne de propriété n’est pas
cassée parce que le propriétaire des
deux procédures (le DBO) est associé
au même login (sa). Les utilisateurs
n’ont besoin de permissions EXECUTE
que sur la procédure utilisateur, et ils
peuvent accéder à  la base de données
maîtresse en tant qu’utilisateur guest.

Cet accès indirect à  xp_cmdshell
procure un rideau de sécurité supplémentaire
parce que les utilisateurs sont
cantonnés à  l’utilisation du code qui se
trouve dans la procédure stockée.
Toutefois, il faut construire la commande
xp_cmdshell dans la procédure
stockée d’une manière qui empêche
les utilisateurs d’exécuter des commandes
autres que celles que vous leur
accordez.

Ainsi, une application pourrait
utiliser une procédure stockée pour
exporter des données d’une table dans
un fichier texte en exécutant l’utilitaire
ligne de commande bcp par l’intermédiaire
de xp_cmdshell. L’exemple de
procédure usp_UnsecureBC
PCommand, que montre le listing 3,
exécute le paramètre transmis directement
sans restriction. Par conséquent,
les utilisateurs qui ont des permissions
EXECUTE sur usp_UnsecureBCPCommand
ont les mêmes possibilités que
ceux qui ont des permissions EXECUTE
directes sur xp_cmdshell : ils
peuvent exécuter n’importe quelle
commande ad hoc. On peut combler
cette lacune de sécurité en utilisant la
procédure usp_SecureBCPCommand
du listing 4, qui n’accepte pas de commandes ad hoc. Les utilisateurs
sont cantonnés à  l’exportation de fichiers
vers un endroit prédéterminé.
De la même manière, on peut contrôler
l’accès aux autres objets de la base
de données maîtresse comme
xp_sendmail et les procédures
sp_OA*.

La propriété sa des bases de données
utilisateur présente certains
risques de sécurité. Les utilisateurs qui
ont des permissions pour créer une
procédure possédée par DBO dans
une base de données utilisateur possédée
par sa, peuvent créer et exécuter
une procédure qui exécute xp_cmdshell
sans restriction aucune. Par
conséquent, il faut passer au crible les
membres des rôles de base de données
fixes db_owner et ssl_admin dans
un environnement de production dans
lequel sa possède une base de données
utilisateur.