Gestion de la sécurité des accès

Introduction

Le contrôle d’accès représente une opération importante au niveau de la gestion de la sécurité sur un serveur de bases de données. La sécurisation des données nécessite une organisation des objets de façon indépendante des utilisateurs, ce qui est possible par les schémas. La sécurité passe également par un meilleur contrôle des autorisations et la possibilité d’accorder juste les privilèges nécessaires à chaque utilisateur pour qu’il puisse travailler de façon autonome.

Pour l’organisation de cette politique de sécurité, il faut prendre en compte l’organisation hiérarchique des éléments de sécurité, de façon à rendre la gestion des droits d’accès simple et efficace.

SQL Server s’appuie sur trois éléments clés qui sont :

Les entités de sécurité sont des comptes de sécurité qui disposent d’un accès au serveur SQL.

Les sécurisables représentent les objets gérés par le serveur. Ici, un objet peut être une table, un schéma ou une base de données par exemple.

Les autorisations sont accordées aux entités de sécurité afin qu’elles puissent travailler avec les sécurisables.

L’organisation hiérarchique permet d’accorder une autorisation (par exemple SELECT) sur un sécurisable de niveau élevé (par exemple le schéma) pour permettre à l’entité de sécurité qui reçoit l’autorisation d’exécuter l’instruction SELECT sur toutes les tables contenues...

Gestion des accès serveur

Avant de pouvoir travailler avec les données gérées par les bases, il faut dans un premier temps se connecter au serveur SQL. Cette étape permet de se faire identifier par le serveur SQL et d’utiliser par la suite tous les droits qui sont accordés à notre connexion. Il existe dans SQL Server deux modes de gestion des accès au serveur de base de données.

Attention : dans cette section, seule la partie connexion au serveur est abordée. Il est important de bien distinguer la connexion au serveur et l’utilisation de bases de données. La connexion au serveur permet de se faire identifier par le serveur SQL comme un utilisateur valide, pour utiliser, par la suite, une base de données : les données et les objets. L’ensemble de ces droits seront définis ultérieurement. Ces droits sont associés à un utilisateur de base de données, pour lequel correspond une connexion.

Gestion des utilisateurs de base de données

Après la définition des connexions (login) au niveau du serveur, il est nécessaire de définir des utilisateurs dans les différentes bases de données.

C’est au niveau des utilisateurs de base de données que seront attribués les droits d’utilisation des objets définis dans la base de données. Lors de la définition d’une connexion, la base de données par défaut permet de positionner le compte de connexion sur une base de données pour commencer à travailler. Cependant, la connexion ne pourra réellement travailler sur la base que s’il existe un compte d’utilisateur défini au niveau base et associé à la connexion. C’est un point de passage obligatoire, sauf si la connexion s’est vue attribuée des privilèges de haut niveau.

Les utilisateurs de base de données sont, en général, associés à une connexion au niveau du serveur. Cependant, l’utilisateur guest (qui est désactivé par défaut) n’est mappé à aucune connexion. Comme à n’importe quel compte utilisateur de base de données, des droits d’accès aux objets peuvent lui être accordés.

Le compte invité (guest) est activé sur les bases master et tempdb. Cela fait partie du mode de fonctionnement normal de SQL Server et il n’est pas possible de déroger à cette règle.

Si un utilisateur dispose d’une connexion à SQL Server mais s’il n’existe pas d’utilisateur de base de données lui permettant...

Gestion des schémas

L’objectif des schémas est de faciliter la gestion de la sécurité d’accès des utilisateurs vers les objets (tables, vues, procédures stockées, fonctions). Un peu comme sur un serveur de fichiers avec des dossiers et sous-dossiers où les fichiers vont être stockés, les droits d’accès sont posés en priorité sur les dossiers, ce qui sera plus simple que fichier par fichier. Pour le cas de SQL Server, les droits peuvent être posés sur les bases de données, les schémas et éventuellement sur les objets pour gérer une exception.

Dans le cas où on ne trouve pas de découpage logique de schémas pour une base de données, les objets seront placés dans le schéma par défaut à savoir dbo.

Pour accéder aux objets, même s’ils sont stockés dans le schéma par défaut de l’utilisateur, il est préférable de les nommer en utilisant leur schéma, c’est-à-dire nomSchema.nomObjet. Lors de l’utilisation d’un nom court (simplement le nom de l’objet sans le préfixer par le nom du schéma), SQL Server recherche l’existence de l’objet dans le schéma par défaut de l’utilisateur et ensuite dans le schéma dbo, donc si le nom de schéma est spécifié, cette étape n’a pas lieu d’être et cela optimise le temps de réponse des requêtes.

Gestion des droits

Tous les utilisateurs de base de données, y compris guest (l’invité), appartiennent au groupe public. Les droits qui vont être détaillés ci-dessous peuvent bien sûr être accordés directement à public.

Les droits sont organisés de façon hiérarchique par rapport aux éléments sécurisables du serveur.

Il est possible de gérer l’attribution de privilèges au niveau du serveur, de la base de données, du schéma ou bien directement de l’objet. Ainsi, les privilèges peuvent être accordés soit à un utilisateur de base de données, soit à une connexion.

Les droits accordés au niveau du serveur sont particuliers et relèvent plus de droits pour des administrateurs délégués. Au niveau bases de données, il existe également des droits concernant des accès administratifs, mais aussi des droits concernant l’accès des utilisateurs aux objets. Ces mêmes droits peuvent également être posés sur les schémas ou directement sur les objets (il y a héritage des droits sur ces trois niveaux de la même manière que sur un serveur de fichiers entre les dossiers et les fichiers). 

SQL Server gère les privilèges avec les trois commandes suivantes :

C’est-à-dire qu’un privilège peut être accordé (GRANT) ou bien retiré (REVOKE) s’il a été accordé. L’instruction DENY permet d’interdire l’utilisation d’un privilège particulier même si le privilège en question a été accordé soit directement, soit par l’intermédiaire d’un rôle.

Contexte d’exécution

Le contexte d’exécution est directement lié à la connexion et à l’utilisateur de base de données associé. Le contexte d’exécution permet d’établir la liste des actions possibles et celles qui ne le sont pas. Cette liste est établie à partir des privilèges accordés à l’utilisateur soit directement, soit par l’intermédiaire de rôles.

Dans certains cas, il peut être nécessaire et souhaitable de modifier le contexte d’exécution afin de profiter de privilèges étendus, mais uniquement dans le cadre d’un script, d’une procédure ou d’une fonction.

Associée au contexte d’exécution, il est nécessaire de bien comprendre la notion de chaîne de propriétés dans SQL Server.

Par exemple, l’utilisateur Paul a reçu de Marie le droit d’utiliser (SELECT) une vue que possède Marie. La requête SELECT, à l’origine de cette vue, fait référence à une table également possédée par Marie. Paul ne dispose d’aucun privilège sur cette table, pourtant il sera en mesure d’utiliser la vue sans soucis car les deux objets (vue et table) ont le même propriétaire.

Dans le cas où la vue de Marie que Paul interroge accède à une table dont Marie n’est pas la propriétaire, alors les privilèges accordés à Paul sont vérifiés afin de savoir si Paul possède les privilèges nécessaires pour exécuter la requête.

EXECUTE AS

À l’aide de cette instruction, il est possible de demander à se connecter sur la base en utilisant une connexion différente de celle en cours. Cette instruction peut...

Rôles

Les rôles sont des ensembles de permissions. Ces ensembles existent à trois niveaux distincts : serveur, base de données et application. Les rôles permettent de regrouper les droits et de gérer plus facilement les différents utilisateurs et les connexions. Il est en effet toujours préférable d’attribuer des droits à des rôles puis d’accorder les rôles aux utilisateurs. Avec une telle structure, l’ajout et la modification de droits ou d’utilisateur sont beaucoup plus simples.

Il est possible de définir un rôle comme un ensemble nommé de privilèges. Pour faciliter la gestion des droits, SQL Server propose des rôles prédéfinis aussi appelés fixes car il n’est pas possible d’ajouter ou bien de supprimer des privilèges dans ces rôles.

Ces rôles fixes sont définis à deux niveaux :

En plus de ces rôles fixes, il est possible de gérer des rôles. Il convient alors de définir un nom unique pour définir un rôle, puis d’accorder un ou plusieurs privilèges en respectant une procédure en tout point similaire à celle utilisée pour accorder des permissions à des utilisateurs. Ces rôles peuvent être définis à trois niveaux :

Les rôles permettent une gestion simplifiée des privilèges puisqu’il est possible ainsi de définir des profils types de privilèges, puis d’accorder à chaque utilisateur de base de données, un ou plusieurs profils de façon à lui fournir toutes les autorisations dont il a besoin pour travailler sur la base.

L’utilisateur dispose au final de l’ensemble des privilèges...

L’accès aux données distantes

SQL Server permet à un utilisateur connecté localement d’exécuter une requête sur un serveur distant. Ce processus s’appuie sur la liaison entre les serveurs. Lorsque la liaison est établie entre deux serveurs, le serveur qui réceptionne de la part de l’un de ses utilisateurs une demande d’exécution d’une requête sur un autre serveur transmet la requête au serveur distant.

Dans le schéma suivant, un utilisateur connecté sur serveur1 peut demander l’exécution d’une requête sur serveur2 sans avoir à se connecter sur serveur2. En effet, comme les deux serveurs sont liés, c’est serveur1 qui se charge d’exécuter la requête sur serveur2.

L’avantage des serveurs liés est que c’est le serveur qui prend en charge la connexion sur le serveur distant. Cette opération est transparente pour l’utilisateur final.

Avant de pouvoir travailler avec un serveur lié, il faut l’inscrire sur le serveur local puis définir une politique de gestion des connexions établies sur le serveur lié.

La notion de serveurs liés permet à SQL Server d’établir une relation de confiance avec des sources ODBC, OLE DB... qui offrent l’avantage d’accéder aux serveurs distants, d’émettre des requêtes, des opérations de mise à jour, des commandes et des transactions partagées sur des sources de données hétérogènes.