> Tech > Permissions accordées

Permissions accordées

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Pour accorder des permissions de base de données à  des utilisateurs ou à  des rôles ayant été ajoutés, vous pouvez commencer par l'utilisateur (en vous rappelant qu'un utilisateur SQL Server peut correspondre à  un groupe NT) ou le rôle, et attribuer les permissions. Mais vous pouvez aussi commencer par une

Permissions accordées

table, une
vue ou une procédure stockée et attribuer des permissions sur cet objet aux
utilisateurs appropriés ou aux rôles de bases de données définis par les utilisateurs.
Pour attribuer des permissions à  un utilisateur particulier, étendez la hiérarchie
du Gestionnaire d’Entreprise SQL Server et sélectionnez l’objet Utilisateurs
dans la base de données désirée. Dans la sous-fenêtre de droite, double-cliquez
sur le nom de l’utilisateur désiré pour ouvrir la boîte de dialogue Propriétés
des utilisateurs de la base de données. Cliquez sur le bouton Permissions pour
afficher les permissions de l’utilisateur vis-à -vis des objets de la base de
données, comme sur la Figure 5. Rappelez-vous que cette interface ne montre
que les permissions accordées spécifiquement à  cet utilisateur. Les permissions
qu’il détient en tant que membre d’un ou de plusieurs rôles ou groupes NT, ne
s’affichent pas ici. En fait, il n’est pas facile d’obtenir une liste des permissions
accumulées d’un utilisateur dans SQL Server.

On peut décider de faire appel à  de la main d’oeuvre de saisie pour
pouvoir insérer des enregistrements, mais pas pour les changer ou les détruire

Pour donner à  un utilisateur la permission en lecture sur une table ou une
vue, cochez la case Sélection. Si l’utilisateur a besoin de modifier les données,
vous cochez normalement les cases Insertion, Mise à  jour et Suppression. Vous
pouvez décider de faire appel à  de la main d’oeuvre de saisie des données pour
pouvoir insérer des enregistrements, mais pas pour les changer ou les détruire.
La destruction d’enregistrements relève de personnels ayant plus d’autorité
ou d’expérience. Pour refuser à  un utilisateur la permission de supprimer, cliquez
deux fois sur la case Suppression pour faire apparaître un X rouge, comme sur
la Figure 5. Vous serez peut-être amenés à  discuter des problèmes de permissions
des utilisateurs avec vos programmeurs. S’ils ont intégré des sécurités dans
les applications utilisées pour mettre à  jour la base de données, il ne sera
sans doute pas nécessaire de répéter l’effort. Il est toutefois plus sûr d’intégrer
une sécurité dans la base de données, car un utilisateur ne peut pas atteindre
alors les données en contournant ou en modifiant les applications. La table
Permissions montre que l’utilisateur Caesar peut sélectionner dans la table
Clients, ajouter ou mettre à  jour des données de clients, mais ne peut pas détruire
un client. La table montre aussi qu’il ne peut pas mettre à  jour les Territoires
des employés, mais n’oublions pas qu’il pourrait appartenir à  un groupe possédant
cette permission.
La colonne Exécution de la table Permissions régule la possibilité d’exécuter
des procédures stockées, c’est-à -dire des sous-programmes SQL Server écrits
en T-SQL que les applications peuvent appeler pour demander à  SQL Server d’effectuer
des tâches se rapportant à  la base de données. Les programmeurs les utilisent
parce qu’elles sont efficaces et offrent un autre niveau de sécurité. Si des
procédures stockées ont été écrites par les programmeurs, certains utilisateurs
auront besoin de la permission d’exécution sur la procédure pour les exécuter.
On peut généralement ignorer la colonne de déclaration d’intégrité référentielle,
sauf avis contraire des programmeurs. Lorsqu’un utilisateur entre des données
dans une table, il arrive parfois que SQL Server vérifie les données dans une
autre table. Par exemple, si un utilisateur entre un numéro d’article dans une
table commandes, SQL Server peut très bien se référer à  une table produits pour
vérifier si le numéro saisi est un numéro d’article valide. Pour que cette vérification
fonctionne, l’utilisateur a besoin de la permission Select sur la table produits
et de la permission Insert sur la table commandes. Dans certains cas, les utilisateurs
devront peut-être désigner une autre table pour vérifier la saisie de leurs
données, mais ils ne pourraient pas lire la table directement. L’utilisateur
a, dans ce cas, besoin de la permission de déclaration d’intégrité référentielle
au lieu de la permission Select.

Téléchargez cette ressource

Guide inmac wstore pour l’équipement IT de l’entreprise

Guide inmac wstore pour l’équipement IT de l’entreprise

Découvrez toutes nos actualités à travers des interviews, avis, conseils d'experts, témoignages clients, ainsi que les dernières tendances et solutions IT autour de nos 4 univers produits : Poste de travail, Affichage et Collaboration, Impression et Infrastructure.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010