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 . |
| processadmin | Les membres du rôle de serveur fixe processadmin peuvent g érer les processus SQL Server . |
| securityadmin | 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 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. |
| db_backupoperator | Les membres du rôle de base de données fixe 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. |
| db_denydatareader | Les membres du rôle de base de données fixe 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).
- 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. - 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. - 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. - 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