L’accès aux bases de données

le leur refuser à  d’autres. Un profil SQL
Server n’a aucun droit vis-à -vis d’une base de données tant qu’il n’a pas été
défini comme utilisateur de cette base de données. Cette tâche peut être abordée
de deux manières : côté utilisateur ou côté base de données. La boîte de dialogue
Propriété du profil permet de permettre à  un utilisateur d’accéder à  plusieurs
bases de données. On peut également aller à  la base de données, ouvrir la boîte
de dialogue Nouvel utilisateur de la base de données et ajouter les profils de
tous les utilisateurs aptes à  utiliser la base de données. La Figure 4 montre
comment utiliser l’onglet Accès à  la base de données de la boîte de dialogue Propriétés
du profil pour ajouter un utilisateur à  une ou plusieurs bases de données. Il
est possible de spécifier un nom d’utilisateur différent du profil, mais je ne
recommande pas cette pratique parce qu’elle risque d’être source de confusion
pour l’administrateur.
Lorsque des profils sont ajoutés à  titre d’utilisateurs de bases de données, ils
peuvent être placés dans des rôles de base de données, un concept qui fait sa
première apparition dans SQL Server 7.0. Tout comme les rôles des serveurs, les
rôles des bases de données peuvent se comparer aux groupes locaux dans lesquels
sont placés les profils SQL Server. Ils sont similaires aux groupes globaux Windows.
Comme un rôle de serveur, un rôle de base de données possède un ensemble de permissions
prédéfinies. Ces permissions peuvent être accordées directement aux utilisateurs,
mais dans de nombreux cas, il suffit de placer les utilisateurs dans les bons
rôles pour leur donner toutes les permissions dont ils ont besoin. Un utilisateur
peut être membre de plusieurs rôles et accumuler ainsi une variété de permissions
combinées. Tout rôle refusant l’accès annule toutes les autres permissions des
utilisateurs. Comme pour les rôles de serveurs, les rôles des bases de données
prédéfinis ne peuvent pas être modifiés. Il est possible d’ajouter des rôles de
bases de données détenant toutes les permissions voulues, mais on peut combiner
des rôles existants pour accorder aux utilisateurs exactement le niveau d’accès
voulu. L’appartenance aux rôles peut être modifiée à  tout moment ; il ne faut
pas nécessairement attribuer à  un profil tous ses rôles, lorsqu’on l’ajoute en
tant qu’utilisateur d’une base de données.
Le rôle de base de données public est identique au groupe Tout le monde de Windows
NT. SQL Server place dans le rôle public tout profil auquel est accordé l’accès
à  la base de données. On ne peut pas supprimer des utilisateurs du rôle public,
ni le détruire. Par défaut, le rôle public ne possède aucune permission vis-à -vis
d’une base de données que vous créez. Ne vous laissez pas induire en erreur par
l’exemple de la base de données Northwind de la Figure 4. C’est une base de données
de test et tout le monde est donc censé pouvoir consulter ses données.
Le
rôle de base de données public est identique au groupe Tout le monde de Windows
NT
Les utilisateurs devant sélectionner des données dans une base de données
doivent être placés dans le rôle db_datareader. Ceux qui ont besoin de modifier
des données doivent se trouver à  la fois dans les rôles db_datareader et db_datawriter.
Si un groupe NT doit accéder à  une base de données, mais qu’un de ses membres
ne doit pas avoir cet accès, vous pouvez placer le profil SQL Server du groupe
dans les rôles db_datareader et db_datawriter et celui de ce membre dans les rôles
db_denydatareader et db_denydatawriter.
L’utilisation des rôles db_datareader et db_datawriter peut poser un problème.
Certaines bases de données utilisent des vues pour imposer la sécurité. Une vue
est une spécification prédéfinie de ce que l’utilisateur est autorisé à  voir.
Par exemple, une vue peut être un sous-ensemble des données d’une table, qui ne
laisse voir que certaines colonnes et en cache d’autres contenant des données
confidentielles. En utilisant des vues pour imposer la sécurité, vous ne donnez
pas directement aux utilisateurs l’accès aux tables de la base de données, mais
des permissions spécifiques vis-à -vis de certaines vues. Les rôles db_datareader
et db_datawriter ne peuvent pas être utilisés parce qu’ils donnent aux utilisateurs
l’accès à  toutes les tables de la base de données.
Si vous devez déléguer une partie de votre autorité d’administration sur une base
de données, sachez que deux rôles de base de données confèrent une autorité limitée
à  leurs membres. Un membre du rôle db_accessadmin peut ajouter un profil SQL Server
existant à  la base de données en tant qu’utilisateur. Un membre du rôle db_securityadmin
peut alors attribuer des permissions spécifiques sur des objets, tels que des
tables et des vues, à  tout utilisateur de la base de données. Pour charger quelqu’un
d’effectuer ces deux tâches à  la fois, il suffit d’ajouter son profil aux deux
rôles.
Le rôle db_backupoperator est conçu sur le même principe que le groupe Opérateur
de sauvegarde NT. Ses membres ne peuvent lire la base de données que pour effectuer
une sauvegarde et peuvent très bien n’avoir aucun autre accès aux données. Ce
rôle peut sauvegarder une base de données, mais pas la restaurer. Cette tâche
est réservée à  l’Administrateur de la base de données ou à  son propriétaire.
Dans le cas d’une base de données de test ou de développement ou si la base de
données de production subit des modifications, les programmeurs doivent se trouver
dans le rôle db_ddladmin. Les membres de ce rôle peuvent créer, modifier et supprimer
des objets de la base de données. Ne vous souciez pas du rôle db_owner. Tout objet
se trouvant dans SQL Server a un propriétaire et, par défaut, quiconque crée une
base de données en est aussi le propriétaire.
Le Gestionnaire d’Entreprise SQL Server ne montre pas les permissions détenues
par chaque rôle de base de données. Pour en savoir plus à  ce sujet, consultez
SQL Server Books Online (BOL), auquel on peut accéder à  partir du dossier du programme
SQL Server 7.0 ou des nombreuses options d’Aide du Gestionnaire d’Entreprise.
Comme vous allez le découvrir, les rôles prédéfinis sont souples, mais s’ils ne
répondent pas à  tous vos besoins, vous avez deux options. L’une consiste à  attribuer
des permissions directement aux utilisateurs. L’autre, à  ajouter vos propres rôles
de bases de données, en leur donnant les permissions nécessaires, puis à  leur
ajouter des utilisateurs. Pour ajouter un rôle à  partir du Gestionnaire d’Entreprise,
étendez la base de données, cliquez à  droite sur Rôles et sélectionnez Nouveau
rôle de base de données. Dans la boîte de dialogue, entrez un nom pour le nouveau
rôle, sélectionnez Rôle standard et ajoutez les utilisateurs qui seront ses membres.
Pour définir des permissions, il faut quitter la boîte de dialogue pour créer
le rôle. Puis double-cliquez sur le rôle et attribuez les permissions. Vous pouvez,
bien entendu, retourner ultérieurement et modifier à  la fois l’appartenance du
rôle et les permissions que vous lui avez attribuées.