Implémentation de la sécurité par SQL Server

Implémentation de la sécurité par SQL Server
Un utilisateur passe par deux phases de sécurité lorsqu'il travaille avec Microsoft® SQL
Server™ : authentification et validation des autorisations. La phase d'authentification identifie
l'utilisateur qui utilise un compte de connexion d'accès et ne vérifie que l'autorisation de
connexion à un serveur SQL. Si l'authentification est validée, l'utilisateur est connecté à SQL
Server. L'utilisateur a ensuite besoin d'une autorisation pour accéder aux bases de données sur
le serveur, ce qui se fait par le biais d'un compte dans chaque base de données, mappé vers la
connexion d'accès de l'utilisateur. La phase de validation des autorisations détermine les
opérations que l'utilisateur a le droit d'effectuer dans la base de données SQL Server.
Validation des autorisations
Après qu'un utilisateur a été authentifié et autorisé à se connecter à Microsoft® SQL Server™
au moyen de sa connexion d'accès, un compte utilisateur est requis dans chaque base de
données à laquelle l'utilisateur doit accéder. La nécessité d'avoir un compte utilisateur dans
chaque base de données interdit aux utilisateurs de pouvoir se connecter à SQL Server et
d'accéder à toutes les bases de données d'un serveur.
Par exemple, si un serveur contient une base de données personnel et une base de données
recruiting, les utilisateurs qui doivent pouvoir accéder à la base de données recruiting mais
pas à la base de données personnel disposeront d'un compte utilisateur créé uniquement dans
la base de données recruiting.
Le compte utilisateur dans chaque base de données est utilisé pour appliquer des autorisations
de sécurité pour l'accès aux objets (tables, vues, procédures stockées, etc.) situés dans cette
base de données. Ce compte utilisateur peut être mappé depuis des comptes utilisateur
Microsoft Windows NT®, des groupes Windows NT dont l'utilisateur est membre, ou encore
des comptes de connexion d'accès SQL Server. S'il n'existe aucun compte mappé directement,
l'utilisateur peut être autorisé à travailler dans la base de données sous le compte invité, si
celui-ci existe. Les activités qu'un utilisateur est habilité à effectuer sont déterminées par les
autorisations attribuées au compte utilisé pour accéder à la base de données.
SQL Server accepte les commandes une fois que l'utilisateur s'est connecté à la base de
données. Ce dernier peut alors entrer des commandes ou choisir des options dans les menus
d'une application. Toutes les opérations réalisées par un utilisateur dans une base de données
sont communiquées à SQL Server par le biais d'instructions Transact-SQL. Lorsque SQL
Server reçoit une instruction Transact-SQL, il vérifie que l'utilisateur dispose des autorisations
requises pour exécuter l'instruction dans la base de données. Si l'utilisateur ne dispose pas des
autorisations appropriées, par exemple s'il n'est pas habilité à exécuter une instruction ou à
accéder à un objet utilisé par l'instruction dans la base de données, SQL Server renvoie une
erreur de permissions.

Configuration des comptes de sécurité
Chaque utilisateur doit accéder à Microsoft® SQL Server™ par le biais d'un compte de
connexion d'accès qui détermine si sa demande est acceptable (authentification). Cette
connexion d'accès doit ensuite être mappée vers un compte utilisateur SQL Server affecté au
contrôle des opérations effectuées dans la base de données (validation des autorisations). Il
s'ensuit que chaque connexion d'accès est mappée vers un compte utilisateur créé dans
chacune des bases de données auxquelles la connexion doit pouvoir accéder. Si aucun compte
utilisateur n'existe dans une base de données, l'utilisateur ne peut accéder à cette base de
données, même s'il est en mesure de se connecter à SQL Server.
La connexion d'accès est créée dans Microsoft Windows NT® plutôt que dans SQL Server.
Cette connexion d'accès (un compte utilisateur ou groupe Windows NT) reçoit ensuite
l'autorisation de se connecter à SQL Server.
La connexion d'accès est créée dans SQL Server.
Les comptes utilisateur SQL Server qui sont mappés vers des connexions d'accès (créées dans
Windows NT ou SQL Server), et qui permettent l'accès à la base de données, sont toujours
créés à l'intérieur de chaque base de données SQL Server.
Autorisations
Seuls les membres des rôles fixes de serveurs sysadmin ou securityadmin peuvent exécuter
la procédure sp_grantlogin.
Exemples
L'exemple suivant autorise l'utilisateur Windows NT Corporate\BobJ à se connecter à SQL
Server.
EXEC sp_grantlogin 'Corporate\BobJ'
Ou
EXEC sp_grantlogin [Corporate\BobJ]
B. Création d'un ID de connexion et une base de données par défaut
Cet exemple crée une connexion d'accès SQL Server pour l'utilisateur Albert, avec le mot de
passe « food » et la base de données par défaut corporate.

EXEC sp_addlogin 'Albert', 'food', 'corporate'
Le propriétaire de base de données (dbo - DataBase Owner)
À l'intérieur de chaque base de données, chaque membre du rôle de serveur fixe sysadmin est
mappé vers un utilisateur particulier appelé dbo. Tout objet créé par un membre du rôle de
serveur fixe sysadmin appartient automatiquement à dbo.
Si par exemple, l'utilisateur Andrew, membre du rôle de serveur fixe sysadmin, crée une
table T1, celle-ci appartiendra à dbo et sera désignée par dbo.T1, et non Andrew.T1.
À l'inverse, si Andrew n'est pas membre du rôle de serveur fixe sysadmin mais seulement
membre du rôle de base de données fixe db_owner, et qu'il crée une table T1, celle-ci
appartiendra à Andrew et sera désignée par Andrew.T1.
dbo ne peut être supprimé.
Important Seuls les objets créés par des membres du rôle de serveur fixe sysadmin
appartiennent à dbo. Les objets créés par tout autre utilisateur, y compris les membres du rôle
de base de données fixe db_owner, qui ne sont pas également membres du rôle de serveur
fixe sysadmin :
 appartiennent à l'utilisateur qui crée l'objet, et non à dbo ;
 doivent être qualifiés avec le nom de l'utilisateur qui les a créés, lorsque des
utilisateurs autres que le créateur y font référence.
Le propriétaire d'objet de base de données
On appelle objets base de données les tables, les index, les vues, les déclencheurs et les
procédures stockées. Le propriétaire d'un objet base de données est celui qui le crée. Le
propriétaire de la base de données ou l'administrateur système doivent tout d'abord accorder à
l'utilisateur une autorisation de création d'un type d'objet particulier. Le propriétaire d'un objet
base de données peut ensuite créer un objet et accorder à d'autres utilisateurs l'autorisation de
l'utiliser.
Il n'existe pas de nom de connexion d'accès ni de mot de passe spécial pour les propriétaires
d'objets base de données. Le créateur d'un objet base de données dispose implicitement de
toutes les autorisations sur cet objet, mais il doit explicitement accorder des autorisations aux
autres utilisateurs afin qu'ils puissent accéder à l'objet.
Lorsque des utilisateurs accèdent à un objet créé par un autre utilisateur, cet objet doit être
qualifié avec le nom de son propriétaire ; dans le cas contraire, Microsoft® SQL Server™ ne
sait pas quel objet utiliser, car il peut exister plusieurs objets portant le même nom mais
appartenant à des utilisateurs différents. Si un objet n'est pas qualifié avec le nom de son
propriétaire lorsqu'il est référencé, par exemple my_table au lieu de owner.my_table, SQL
Server le recherche dans la base de données selon l'ordre suivant :

1. l'utilisateur courant en est propriétaire ;
2. dbo en est propriétaire.
Si l'objet est introuvable, un message d'erreur est renvoyé.
Supposons par exemple, que l'utilisateur John, membre du rôle de base de données fixe
db_owner, mais pas du rôle de serveur fixe sysadmin, crée la table T1. Tous les utilisateurs,
sauf John, voulant accéder à la table T1 devront la qualifier en spécifiant le nom d'utilisateur
John. Si T1 n'est pas qualifiée avec le nom d'utilisateur John, SQL Server commencera par
rechercher une table T1 appartenant à l'utilisateur actuel, puis appartenant à dbo. Si, ni
l'utilisateur actuel ni dbo, ne possèdent de table appelée T1, un message d'erreur sera renvoyé.
Si l'utilisateur actuel ou si dbo possède une table appelée T1, c'est cette table plutôt que la
table John.T1 qui sera utilisée.
Si le propriétaire d'un objet base de données doit être supprimé dans une base de données, les
objets lui appartenant doivent d'abord être supprimés ou leur propriété transférée à un autre
utilisateur.
Remarque SQL Server permet à tous les membres d'un rôle ou d'un groupe Windows NT
d'être spécifiés comme étant propriétaires d'un objet. Par exemple, pour créer la table
group_table appartenant au groupe Windows NT LONDON\Users, vous spécifierez
[LONDON\Users].group_table pour le nom complet de la table. Tous les membres du
groupe LONDON\Users disposeront des autorisations de propriétaire de l'objet base de
données sur group_table.
Voir aussi
L'utilisateur invité (guest)
Le compte utilisateur invité permet une connexion d'accès à une base de données, sans
compte utilisateur. Une connexion d'accès prend l'identité de l'utilisateur invité lorsque toutes
les conditions suivantes sont remplies :
 la connexion a accès à Microsoft® SQL Server™, mais ne peut accéder à la base de
données par l'intermédiaire de son propre compte utilisateur ;
 la base de données contient un compte utilisateur invité.
Des autorisations peuvent être accordées à l'utilisateur invité comme à n'importe quel autre
compte utilisateur. L'utilisateur invité peut être supprimé et ajouté dans n'importe quelle base
de données, sauf dans les bases master et tempdb, où il doit exister en permanence. Par
défaut, un compte utilisateur invité n'existe pas dans une base de données nouvellement créée.
Par exemple, pour ajouter un compte utilisateur invité à une base de données nommée
Accounts, exécutez la requête suivante à partir de l'analyseur de requêtes SQL Server :
USE Accounts

GO
EXECUTE sp_grantdbaccess guest, guest
Création de rôles SQL Server définis par l'utilisateur
Lorsqu'un groupe d'utilisateurs doit effectuer un certain nombre d'activités spécifiques dans
Microsoft® SQL Server™ et qu'il n'existe pas de groupe Microsoft Windows NT®
correspondant, ou si vous ne disposez pas des autorisations requises pour gérer les comptes
utilisateur Windows NT, vous pouvez ajouter un rôle SQL Server dans la base de données.
Supposons par exemple, qu'une société forme un comité de bienfaisance regroupant des
employés de différents services, à plusieurs niveaux de l'organisation. Ces employés doivent
pouvoir accéder à une table de projet particulière dans la base de données. Aucun groupe
Windows NT existant ne regroupe uniquement ces employés, et il n'existe aucune raison d'en
créer un dans Windows NT. Un rôle de base de données SQL Server personnalisé,
CharityEvent, pourrait être créé pour ce projet, rôle auquel on ajouterait des utilisateurs
Windows NT individuels. Après affectation des autorisations, les utilisateurs appartenant au
rôle de base de données pourront accéder à la table. Les autorisations pour les autres
opérations portant sur la base de données ne sont pas affectées, et seuls ces utilisateurs
pourront travailler avec la table du projet.
Les rôles SQL Server existent au sein d'une base de données et ils ne peuvent porter que sur
une seule base de données.
Avantages liés à l'utilisation des rôles de bases de données :
 plusieurs rôles de bases de données peuvent être simultanément actifs pour n'importe
quel utilisateur ;
 Les rôles SQL Server peuvent contenir des utilisateurs et des groupes Windows NT, et
des utilisateurs SQL Server et d'autres rôles à condition que tous les utilisateurs,
groupes et rôles existent dans la base de données en cours ;
 un utilisateur peut appartenir à plusieurs rôles dans la même base de données ;
 un modèle évolutif est fourni pour configurer le niveau de sécurité requis à l'intérieur
d'une base de données.
Comme les utilisateurs peuvent appartenir simultanément à plusieurs rôles de base de données,
il ne leur est plus nécessaire d'emprunter l'identité (et les autorisations) d'autres utilisateurs au
moyen d'alias temporaires.
Remarque Un rôle de base de données est la propriété de l'utilisateur explicitement spécifié
comme étant le propriétaire lorsque le rôle est créé, ou de l'utilisateur l'ayant créé, si aucun
propriétaire n'a été spécifié. Le propriétaire du rôle détermine les utilisateurs pouvant être
ajoutés ou supprimés du rôle. Cependant, un rôle n'est pas un objet de base de données et, par
conséquent, il n'est pas possible d'ajouter plusieurs rôles du même nom, créés par et
appartenant à plusieurs utilisateurs, dans la même base de données.