I. Introduction▲
SQL Server est aujourd'hui un moteur de bases de données aboutit et performant. Néanmoins, son utilisation nécessite de tenir compte de particularités sécuritaires qui lui sont propres.
Par assimilation, beaucoup de mes collègues assimilent les concepts de moteur de bases de données et base de données (comme sous Access), or il est important pour la compréhension de la sécurité de distinguer les deux niveaux.
Le moteur (ou instance) constitue l'application qui exploite les bases de données, ces dernières sont de fichiers dans lesquels les données sont effectivement enregistrées.
- L'authentification au serveur,
- Les droits d'accès au moteur et aux bases de données,
II. 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é sa demande de connexion.
Lorsqu'une application tente d'accéder à une instance SQL Server, elle la contacte en utilisant d'une chaîne de connexion. Dans cette dernière nous retrouverons les paramètres permettant de situer le serveur (sur un réseau), d'identifier le mode d'authentification,…
Ces 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 de l'instance SQL Server (pas encore à la base de données, mais uniquement au moteur). La chaîne de connexion permet de localiser la clé qui est rangée dans une boîte à clés.
Deux types d'authentifications existent :
II-A. Authentification SQL Server▲
Ce mode nécessite de fournir, dans la chaîne de connexion à la base de données, côté 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ée sur le mode "SQL Server", nécessitant la saisie d'un mot de passe.
II-B. 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 revérifier son identité. Ensuite le protocole NTLM fait le reste.
- Simplification et sécurisation de la chaîne 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 chaîne de connexion, coté application, l'attribut suivant : " trusted_connection = true "
III. Les droits d'accès au moteur de bases de données ▲
- Droits sur le moteur
- Droits d'accès aux bases de données
III-A. 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 :
| Rôles | Descriptif |
|---|---|
| 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é.
III-B. Droits d'accès aux bases de données▲
- Les utilisateurs
- Les objets sécurisables
III-B-1. Les utilisateurs▲
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
| Rôles | Description |
|---|---|
| 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.
III-B-2. Les objets sécurisables▲
III-B-2-a. 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).
- 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.
III-B-2-b. Les objets▲
Les objets sécurisables sont des tables, procédures stockées, vues, …
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).
- 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.