Gestion de la sécurité Une entité de sécurité est une identité

Gestion de la sécurité
Une entité de sécurité est une identité authentifiée qui peut recevoir l'autorisation d'accéder à un objet dans le
système de base de données. SQL Server fait la différence entre les entités de sécurité indivisibles qui sont des
entités uniques (telles que les connexions), et les ensembles d'entités de sécurité qui sont des ensembles d'identités
(tels que les rôles serveur fixes).
Les éléments sécurisables sont organisés en hiérarchies imbriquées appelées étendues qui peuvent également être
sécurisées.
Étendue du serveur
Les éléments sécurisables contenus dans l'étendue du serveur incluent :
• Des connexions.
• Des points de terminaison.
• Des bases de données.
Étendue de base de données
Les éléments sécurisables contenus dans l'étendue de base de données incluent :
• Des utilisateurs.
• Des rôles.
• Des rôles d'application.
• Des certificats.
• Des clés symétriques.
• Des clés asymétriques.
• Des assemblys.
• Des catalogues de texte intégral.
• Des événements DDL.
• Des schémas.
Étendue du schéma
Les éléments sécurisables contenus dans l'étendue du schéma incluent :
• Des tableaux.
• Des vues.
• Des fonctions.
• Des procédures.
• Des types.
• Des synonymes.
• Des agrégats.
Création de connexions
CREATE LOGIN [SERVERX\SalesDBUsers]
FROM WINDOWS
WITH DEFAULT_DATABASE = AdventureWorks
Connexion SQL non soumise à la stratégie de mot de passe définie pour le serveur.
CREATE LOGIN Ted
WITH PASSWORD = 'password',
DEFAULT_DATABASE = AdventureWorks,
CHECK_EXPIRATION = OFF,
CHECK_POLICY = OFF
Attribution d'un compte de connexion à un rôle serveur fixe
EXEC sp_addsrvrolemember 'ImcSF\GuyA', 'sysadmin';
GO

REMARQUE IMPORTANTE
SQL Server est installé avec le groupe administrateurs BUILTIN comme groupe d'administration système par
défaut. Par défaut, les utilisateurs sous Windows Vista qui sont membres du groupe Administrateurs Windows
ne bénéficient pas automatiquement de l'autorisation de se connecter à SQL Server et ils n'obtiennent pas
automatiquement les droits d'administrateur SQL Server. Sous Windows Vista, quand un utilisateur tente de se
connecter à SQL Server, il reçoit un message lui indiquant que le compte n'a pas les droits nécessaires pour se
connecter à SQL Server.
Délégation
SQL Server et Windows peuvent être configurés afin de permettre à un client connecté à une instance de SQL Server
de se connecter à une autre instance de SQL Server, en transmettant les informations d'identification d'un utilisateur
Windows authentifié. Cette organisation porte le nom de délégation. Dans le cadre d'une délégation, l'instance de
SQL Server à laquelle un utilisateur Windows s'est connecté à l'aide de l'authentification Windows emprunte
l'identité de cet utilisateur pour communiquer avec une autre instance. La délégation de compte de sécurité est
nécessaire pour les requêtes distribuées lorsqu'un mappage automatique est utilisé pour une connexion spécifique par
rapport à un serveur lié donné.
Contraintes liées à la délégation
Pour illustrer les contraintes liées à la délégation, prenons comme exemple le scénario suivant : un utilisateur se
connecte à un ordinateur client qui se connecte à un serveur en train d'exécuter une instance SQL Server,
SQLSERVER1. L'utilisateur souhaite exécuter une requête distribuée impliquant une base de données située sur un
serveur lié, SQLSERVER2. Ce scénario, dans lequel un ordinateur se connecte à un autre ordinateur pour se
connecter à un troisième ordinateur, est appelé double saut.
Remarque :
Un serveur lié doit être configuré pour la délégation même lorsqu'une application cliente, notamment SQL Server
Management Studio, qui établit une connexion à un serveur se trouve sur le même ordinateur que l'instance de SQL
Server interrogée.
Conditions requises pour le client
La connexion authentifiée Windows de l'utilisateur doit être habilitée à accéder à SQLSERVER1 et à
SQLSERVER2.
La propriété Active Directory de l'utilisateur, Le compte est sensible et ne peut pas être délégué, ne doit pas être
sélectionnée.
L'ordinateur client doit utiliser le protocole TCP/IP ou le protocole réseau de canaux nommés.
Conditions requises pour le premier serveur (intermédiaire) (SQLSERVER1)
Le serveur doit posséder un SPN inscrit par l'administrateur de domaine.
Le compte sous lequel SQL Server est en cours d'exécution doit être approuvé pour la délégation.
Le serveur doit utiliser le protocole TCP/IP ou le protocole réseau de canaux nommés.
Le second serveur, SQLSERVER2, doit être ajouté en tant que serveur lié. Pour ce faire, vous pouvez exécuter la
procédure stockée sp_addlinkedserver. Exemple :
EXEC sp_addlinkedserver 'SQLSERVER2', N'SQL Server'
Les connexions au serveur lié doivent être configurées de manière à prendre en charge le mappage automatique. Pour
ce faire, vous pouvez exécuter la procédure stockée sp_addlinkedsrvlogin. Exemple :
EXEC sp_addlinkedsrvlogin 'SQLSERVER2', 'true'

Conditions requises pour le second serveur (SQLSERVER2)
Si vous utilisez le protocole réseau TCP/IP, le serveur doit avoir un SPN inscrit par l'administrateur de domaine.
Le serveur doit utiliser le protocole TCP/IP ou le protocole réseau de canaux nommés.
Nom principal de service (SPN)
Pour prendre en charge l'authentification mutuelle sous Kerberos, il est nécessaire qu'une instance de SQL Server
2005 associe un nom principal de service (SPN) au compte sous lequel elle s'exécutera, par exemple, un compte
système local ou un compte d'utilisateur de domaine. Les détails spécifiques relatifs à une inscription de nom SPN
par une instance déterminée de SQL Server 2005 dépendent du type de compte de service sous lequel elle a été
configurée. Si SQL Server 2005 s'exécute sous le compte système local ou le compte de service réseau, les noms
SPN doivent être inscrits sous le nom de l'ordinateur. Si SQL Server 2005 s'exécute sous un compte d'utilisateur de
domaine, les noms SPN doivent être inscrits sous le nom de l'utilisateur du domaine.
Syntaxe pour SetSPN.exe
setspn { -A SPN | -D SPN | -L } service_account
Arguments
-A : Ajoute le nom SPN spécifié au compte.
-D : Supprime le nom SPN spécifié du compte.
-L : Affiche la liste de tous les noms SPN inscrits dans le compte.
Exemples
Si une instance de SQL Server s'exécute en tant qu'utilisateur de domaine (MyDomain\MySQLAccount) sur un
ordinateur nommé MySQLHost, les commandes suivantes peuvent être utilisées pour définir les noms SPN
appropriés :
setspn –A http/MySQLHost MyDomain\MySQLAccount
setspn –A http/MySqlHost.Mydomain.Mycorp.com MyDomain\MySQLAccount
LES SERVEURS LIES
Une configuration de serveurs liés permet à SQL Server d'exécuter des commandes sur les sources de données
OLE°DB hébergées par des serveurs distants. Les serveurs liés offrent les avantages suivants :
L’accès aux serveurs distants ;
La possibilité d'émettre des requêtes, des mises à jour, des commandes et des transactions partagées sur des sources
de données hétérogènes situées dans les différents services de l'entreprise ;
La possibilité de traiter diverses sources de données de manière identique.

Composants des serveurs liés :
Une définition de serveur lié spécifie les objets suivants :
Un fournisseur OLE°DB
Une source de données OLE°DB
Un fournisseur OLE°DB représente une DLL qui gère une source de données spécifique et interagit avec elle. Une
source de données OLE DB identifie la base de données spécifique accessible via OLE DB. Bien que les sources de
données interrogées au moyen des définitions de serveurs liés soient d'ordinaire des bases de données, des
fournisseurs OLE°DB existent pour différents fichiers et formats de fichiers, dont les fichiers texte, les données
incluses dans des feuilles de calcul et les résultats de recherches de contenu.
Le fournisseur OLE°DB de Microsoft SQL Native Client (PROGID: SQLNCLI) est le fournisseur OLE°DB officiel
de SQL Server.
Remarque :
Les requêtes distribuées SQL Server ont été conçues pour être utilisées avec tout fournisseur OLE DB qui
implémente les interfaces OLE DB requises. Toutefois, SQL Server 2005 n'a été testé que par rapport au fournisseur
OLE DB de SQL Native Client et à certains autres fournisseurs.
Requêtes distribuées
Les requêtes distribuées accèdent à des données provenant de multiples sources de données hétérogènes. Ces sources
de données peuvent être stockées sur le même ordinateur ou sur des ordinateurs différents. Microsoft SQL Server
2005 prend en charge les requêtes distribuées à l'aide de OLE DB.

Les utilisateurs de SQL Server peuvent recourir aux requêtes distribuées pour l’acces aux données suivantes :
Données distribuées stockées dans plusieurs instances de SQL Server
Données hétérogènes stockées dans diverses sources de données relationnelles et non relationnelles, accessibles en
utilisant un fournisseur OLE DB
Les fournisseurs OLE DB exposent des données dans des objets tabulaires appelés ensembles de lignes. SQL Server
permet de référencer les ensembles de lignes des fournisseurs OLE DB dans des instructions Transact-SQL comme
s'il s'agissait de tables SQL Server.
Les tables et les vues dans les sources de données externes peuvent être référencées directement dans les instructions
Transact-SQL SELECT, INSERT, UPDATE et DELETE. Étant donné que les requêtes distribuées utilisent OLE DB
comme interface sous-jacente, elles peuvent accéder non seulement aux systèmes de gestion de bases de données
relationnelles traditionnels (DBMS) dotés de processeurs de requête SQL, mais également aux données gérées par
des sources de données dont les fonctions et le degré de sophistication sont variables. À partir du moment où le
logiciel qui possède les données les expose dans un ensemble de lignes tabulaire par l'intermédiaire d'un fournisseur
OLE DB, ces données peuvent être utilisées dans des requêtes distribuées.
Remarque :
Utiliser des requêtes distribuées dans SQL Server équivaut à se servir de la fonctionnalité de table liée par
l'intermédiaire de ODBC. Cette fonctionnalité, précédemment prise en charge par Microsoft, est désormais
disponible dans SQL Server par OLE DB, qui assure l'interface avec les données externes.
Par exemple : la requête distribuée suivante référence les tables Production.Product et Sales.SalesOrderDetails de
la base de données AdventureWorks sur le serveur lié SEATTLESales :
SELECT p.Name, sod.SalesOrderID
FROM SEATTLESales.AdventureWorks.Production.Product p
INNER JOIN SEATTLESales.AdventureWorks.Sales.SalesOrderDetail sod
ON p.ProductID = sod.ProductID
ORDER BY p.Name ;