sécurité sql server

SÉCURITÉ SQL SERVER
Description
SQL Server 2005 adopte une sécurité à deux niveaux : Moteur et base de données.
Que sont les schémas, rôles, rôles de serveur fixe, peut on intégrer la sécurité Active Directory à SQL Server,...
Ce tutorial est une synthèse de la gestion des droits du moteur de bases de données.
Tutorial
Ce document est un aide mémoire (de concepts portant sur la sécurité) quant à la manipulation d'instances SQL Server.
Basé sur les versions 2000 à 2005, il peut servir de base à la gestion de versions antérieures (la sécurité étant similaire,
avec quelques concepts en moins).
Ce document n'est pas un mode d'emploi des étapes à suivre pour effectuer des opérations de sécurité. Il est donc
indispensable de savoir manipuler SQL Server.
L'exploitation d'une instance SQL Server nécessite de tenir compte d'aspects sécuritaires. SQL Server impose la sécurité à
travers deux niveaux :


L'authentification au serveur,
Les droits d'accès au moteur de bases de données,
Authentification au serveur
L'authentification consiste à vérifier l'identité de l'utilisateur (login), qu'SQL Server gère sous la forme d'un objet «
connexion ». Seules les applications utilisant ces connexions auront le droit d'exploiter l'instance. Dans le cas contraire,
l'application se voit rejeté du système.
Lorsqu'une application tente d'accéder à une instance SQL Server, elle la contacte en usant d'une chaine de connexion.
Dans cette dernière nous retrouveront les paramètres permettant de situer le serveur (sur un réseau), d'identifier le
mode d'authentification, de
paramètres permettent également d'identifier la connexion utilisée par l'application.
Par analogie, la connexion est comme une clé permettant d'ouvrir la porte à l'instance SQL Server (pas encore à la base
de données, mais uniquement au moteur). La chaine de connexion permet de localiser la clé qui est rangée dans une
boite à clés.
Deux types d'authentifications existent :
« Authentification SQL Serveur »
Ce mode nécessite de fournir (dans la chaine de connexion à la base de données - coté application) un nom d'utilisateur
et un mot de passe.
Pour utiliser ce mode, il est nécessaire de créer une connexion (au sens SQL Server) basé sur le mode « SQL Server »,
nécessitant la saisie d'un mot de passe.
« Authentification Windows » (NTLM )
Ce mode peut être résumé à la situation suivante : puisque l'utilisateur s'est authentifié sur sa session Windows (AD, ou
locale), il est inutile de re vérifier son identité. Ensuite le protocole NTLM fait le reste.
Ce mode offre les avantages suivants :

Simplification et sécurisation de la chaine de connexion
Elle ne contient plus les informations d'authentification => nom d'utilisateur + mot de passe,

Exploitation de la sécurité Active Directory
L'ajout ou la suppression d'utilisateurs habilités à utiliser une base de données se voit géré en fonction des groupes AD
dans lesquels navigue l'utilisateur,

Simplification de l'authentification pour l'utilisateur
Il ne doit plus s'authentifier que sur sa session utilisateur, après, l'application accédant à la base ne lui demandera plus de
s'authentifier,

Par extension, dans le cas où une application nécessite l'exploitation de répertoires partagés, la gestion par AD
permet (lorsque l'utilisateur est noté membre du groupe utilisateur de mon application X) d'autoriser en une manipulation
l'accès au répertoire partagé relatif à mon application, et, aux accès à la base de données pour les droits relatif à un
simple utilisateur (p. exemple),

Ce mode permet également d'auditer plus précisément les opérations effectuées par les utilisateurs.
Pour exploiter ce mode sous SQL Server, il suffit, lors de la création d'une connexion (au sens SQL Server) de la lier à un
objet provenant de l'AD (ou de la machine locale).
Cet objet peut être un groupe ou un utilisateur.
Il faut également ajouter dans la chaine de connexion (coté application) l'attribut suivant : « trusted_connection = true »
Les droits d'accès au moteur de bases de données
Les droits d'accès au moteur de bases de données considèrent deux niveaux :


Droits sur le moteur
Droits d'accès aux bases de données
Les droits d'accès sur le moteur
Lorsque la connexion est créée, l'administrateur peut lui attribuer des droits sur l'administration du moteur de base de
données. Pour ce faire, SQL Server propose 8 « Rôles du serveur ». Ces rôles sont :
bulkadmin
Les membres du rôle serveur fixe bulkadmin peuvent exécuter
l'instruction BULK INSERT (La tâche d'insertion en bloc est le
moyen le plus rapide pour copier de gros volumes de données
dans une table ou une vue SQL Server).
dbcreator
Les membres du rôle de serveur fixe dbcreator peuvent créer,
modifier, supprimer et restaurer n'importe quelle base de
données.
diskadmin
Les membres du rôle de serveur fixe diskadmin peuvent g érer
les fichiers de base de données .
Les membres du rôle de serveur fixe processadmin peuvent g
processadmin érer les processus SQL Server .
Les membres du rôle serveur fixe securityadmin gèrent les
connexions et leurs propriétés. Ils peuvent accorder (GRANT),
refuser (DENY) et révoquer (REVOKE) les autorisations de
securityadmin niveau serveur. Ils peuvent également accorder (GRANT),
refuser (DENY) et révoquer (REVOKE) les autorisations de
niveau base de données. En outre, ils peuvent redéfinir les
mots de passe des connexions SQL Server.
serveradmin
Les membres du rôle serveur fixe serveradmin peuvent
modifier les options de configuration à l'échelle du serveur et
arrêter le serveur.
setupadmin
Les membres du rôle de serveur fixe setupadmin peuvent
ajouter et supprimer des serveurs liés, ainsi qu'exécuter
certaines procédures stockées système.
sysadmin
Les membres du rôle fixe sysadmin peuvent effectuer toute
activité sur le serveur. Par défaut, tous les membres du
groupe Windows BUILTIN\Administrateurs, le groupe
d'administrateurs locaux, sont membres du rôle de serveur fixe
sysadmin.
Pour une connexion servant uniquement à l'exploitation d'une base de données, aucun rôle serveur ne doit être affecté.
Les droits d'accès aux bases de données
Les droits d'accès aux bases de données reposent sur deux concepts :


Les utilisateurs
Les objets sécurisables
Les utilisateurs et rôles
Lorsqu'une connexion est créée, elle ne peut à elle seule accéder aux ressources du moteur de base de données (bases,
tables, fonctionnalités,...), il est nécessaire de l'associer à un utilisateur de la/des bases de données concernées par la
connexion.
Une fois l'utilisateur créé, il est indispensable de lui attribuer des rôles (par défaut, il est db_owner)
Les rôles sont des conteneurs d'utilisateurs, l'équivalent sous Windows sont les groupes.
D'origine SQL Server propose 10 rôles
db_accessadmin
Les membres peuvent ajouter ou supprimer l'accès des
connexions Windows, des groupes Windows et des
connexions SQL Server.
Les membres du rôle de base de données fixe
db_backupoperator db_backupoperator peuvent sauvegarder la base de
données.
db_datareader
Les membres du rôle de base de données fixe
db_datareader peuvent lire toutes les données de toutes
les tables utilisateur.
db_datawriter
Les membres du rôle de base de données fixe
db_datawriter peuvent ajouter, supprimer et modifier des
données dans toutes les tables utilisateur.
ddladmin
Les membres du rôle de base de données fixe
db_ddladmin peuvent exécuter n'importe quelle
commande DDL (Data Definition Language) dans une base
de données.
Les membres du rôle de base de données fixe
db_denydatareader db_denydatareader ne peuvent lire aucune donnée des
tables utilisateur d'une base de données.
db_denydatawriter
Les membres du rôle de base de données fixe
db_denydatawriter ne peuvent ajouter, modifier ou
supprimer aucune donnée des tables utilisateur d'une
base de données.
db_owner
Les membres du rôle de base de données fixe db_owner
peuvent réaliser toutes les activités de configuration et
de maintenance sur la base de données.
db_securityadmin
Les membres du rôle de base de données fixe
db_securityadmin peuvent modifier l'appartenance au
rôle et gérer les autorisations.
public
Hormis ces rôles, l'administrateur peut en définir de nouveaux.
Pour chaque nouveau rôle créé, il est possible de définir les droits affectés par objet sécurisable.
Les objets sécurisables
Les schémas
Un Schéma est un conteneur d'objets sécurisables.
Ce concept permet de regrouper les objets (tables, store proc,...) en fonction de critères particuliers (propre à la
conception de la base). La seule règle de regroupement est de ne pas disposer de deux objets portant le même nom dans
le même schéma.
Le schéma étant un conteneur d'objets sécurisables, il est possible de définir des droits par membre utilisateur du schéma
(qui donc s'appliqueront sur tous les éléments du schéma : tables, store proc,...)
Avant SQL Server 2005, les concepts de schéma et d'utilisateur (propriétaire) étaient assimilés.
Par défaut, le schéma dbo existe, et constitue le schéma par défaut. Tout objet sécurisable est toujours rattaché à un
schéma (si l'administrateur n'en précise pas un lors de la création, il s'agit de dbo).
Exemple d'utilisation de schéma :
Soit une base de données contenant 5 tables (T1, T2, T3, T4, T5),
Le schéma TABLES_PROD contient comme tables T1, T2, T3,
Le Rôle Admin_PROD contient les utilisateurs U1, U2
Le Rôle USER_PROD contient les utilisateurs U3, U4
Le schéma TABLE_PROD contient comme membre le rôle ADMIN_PROD (avec tous les droits),
Dès lors, seuls les utilisateurs membres d'ADMIN_PROD pourront effectuer des requêtes sur les tables.
Les objets
Les objets sécurisables sont des tables, store procedures, views, ...
Conseils
Les points qui suivent visent à simplifier la sécurisation d'une application en considérant 1 utilisateur (utilisateur unique
ne pouvant qu'exploiter les données du serveur).
1.
Groupe AD permettant de globaliser les utilisateurs de l'application
Rechercher le groupe Active Directory dans lequel chaque utilisateur est susceptible d'utiliser l'application, à défaut
créer un groupe Active Directory propre aux utilisateurs de l'application.
2.
Création de la connexion de base de données
Création de la connexion en liaison avec le groupe cité au point 1. Vérifier que cette connexion ne soit pas membre d'un
rôle de serveur fixe.
3.
Affectation des droits nécessaires à l'exploitation de la base
Création de l'utilisateur de base de données en liaison avec la connexion citée au point précédent. Vérifier que ce
dernier n'est pas membre du rôle db_owner. Les deux seuls rôles qui lui sont attribués sont : db_datareader,
db_datawriter.
4.
Gérer les utilisateurs Active Directory afin que les élus soient membre du groupe considéré au point 1 afin de
leur permettre l'accès à la base de données.
SQL Server 2005 only !
Les points qui suivent visent à simplifier la sécurisation d'une application en considérant 2 utilisateurs, et une base de
données comportant deux « schémas ».
Le premier schéma (appelé Schéma A) contient toutes les tables propre à l'utilisation des données classique d'une
application X. Le second schéma (appelé Schéma B) contient toutes les tables propre à l'utilisation des données sensibles
de l'application X.
Le premier utilisateur (U1) a les droits d'accès sur le schéma A. Le second utilisateur (U2) dispose des droits d'accès sur le
schéma A et sur le schéma B.

Groupes Active Directory
Créer/rechercher le groupe contenant les utilisateurs de type U1, idem pour U2.

Création des connexions SQL Server
Créer les connexions SQL Server pour les deux groupes cités au point 1.

Création des utilisateurs à la base de données
Pour chaque connexion créée au point 2, créer l'utilisateur associé.

Affectation des droits sur les schémas
Créer deux rôles, le premier donnant les droits de lecture/écriture sur le schéma A, le second donnant les droits de
lecture/écriture sur le schéma B (Insert + Delete + Select + Execute).
Pour plus d'information sur les permissions :
Documentation en ligne SQL Server - moteur de base de données SQL Server - Considérations de sécurité pour les bases de
données et les applications de base de données

Affectation des membres
Pour le premier rôle cité ci dessus, attribuer les utilisateurs U1 et U2 comme membre.
Pour le second rôle cité ci-dessus, n'attribuer que l'utilisateur U2.
ANNEXE : Présentation Power Point 2007
La sécurité SQL Server se réalise à deux niveaux :
-> Instance SQL Server
-> Droits d'accès au moteur de bases de données
L'authentification constitue le premier niveau de sécurité, il peut être de type SQL Server (nécessitant un nom
d'utilisateur et un mot de passe) ou intégré à la sécurité Windows (prenant en charge les utilisateur et groupes provenant
d'un domaine Active Directory)
Lors de la connexion à un serveur, l'application s'exécute dans un cadre de sécurité.
La sécurité SQL Server consiste à utiliser une connexion basée sur un nom d'utilisateur et un mot de passe. Ces dernier
sont (en général) enregistré sur la machine qui héberge l'application cliente accédant à l'instance SQL Server.
L'utilisation de ce mode de connexion nécessitera de prévoir un mode de sécurité dans l'application (de type table
utilisateur-mot de passe) en plus des sécurités inhérente au réseau d'entreprise pour l'accès aux ressources partagées
(réseau, répertoire,...).
Dans le cas d'active directory, la connexion SQL Server est liée à un utilisateur (ou groupe) Windows (ou Active Directory).
Ainsi intégrée à la sécurité de l'entreprise, la gestion se voit centralisée. Dès qu'un utilisateur est placé dans le groupe
d'utilisateur adhoc, il se voit autorisé l'accès aux bases de données propre qui le concerne !
Liaison des objets sécurisable avec les objets concernés en fonction de droits d'accès