VI.Gestion de la sécurité d’une base de données

SQL Server 2005 fait appel à trois mécanismes pour la sécurité :

• Mécanisme d’authentification
• Mécanisme d’autorisation
• Mécanisme de validation

Trois composants interviennent dans la sécurité :

• Entités de sécurité
• Entités sécurisables
• autorisations

A. Entités de sécurité

Ce sont les composants logiques qui doivent accéder aux ressources de SQL Server. On les localise à trois niveaux :

• OS Windows : ce sont les comptes d’utilisateur local, les comptes d’utilisateur de domaine et les groupes windows
• Serveur de base de données : au niveau du serveur on a des identifiants d’accès serveur. C’est un ensemble d’identité utilisateur enregistré et authentifié par SQL Serveur. Les rôles SQL Server sont un ensemble de connexion d’accès ayant des autorisations similaires.
• Base de données : ce sont des comptes d’accès ayant l’autorisation d’accéder à une base de données. Le rôle de base de données est un ensemble d’utilisateurs de base de données ayant des droits d’accès similaires. Le rôle d’application est utilisé pour accéder à la base de données à l’aide d’une application particulière.

B. Les sécurisables

Ce sont des objets auxquels accèdent des entités de sécurité telles qu’une base de base de données ou un service de base de données.

Au niveau de Windows il s’agit de clés de registre utilisés par SQL Server.

Au niveau SQL Server ce sont des hiérarchies imbriquées appelées portées :

• Portée serveur : elle inclut des connexions d’accès des base de données et des points de terminaisons créés au niveau du serveur.
• Portée Base de données : elle inclut des objets tels que les utilisateurs, les rôles d’applications, les assemblages, les catalogues de texte intégral, les schémas et les événements DDL qui sont crées au niveau de la base de données
• Portée de schémas : elle inclut des objets de base de données tels que les tables, les vues, les fonctions, les procédures et les types de contenu dans un schéma.

C. Les autorisables

L’accès aux sécurisables par les entités de sécurité peut être activé ou déasctiver en configurant les autorisations. Celles-ci conditionnent les niveaux auxquels les entités de sécurité ont accès aux sécurisables.

D. Création de connexions d’accès et d’utilisateurs

Sans connexion d’accès on ne peut pas accéder au serveur SQL. La première méthode est avec l’instruction transact-sql en tapant la commande create login

Etude de cas : Vous êtes l’administrateur de la société, le développeur Bouba vient d’être engagé, un nom de connexion doit être créé pour lui donner accès au serveur SQL. Le compte d’accès de Bouba doit comporter les paramètres suivants :

• Nom de connexion : Bouba
• Nom d’utilisateur :Boubaz
• Mode d’authentification : SQL Server
• Mot de passe : esp
• Stratégie de mot de passe : activé
• Langue par défaut : français

De plus Bouba doit être autorisé sur toutes les tables du schéma Production.

1. Création de compte d’accès

1ere méthode via Transact-SQL

Faire un clic droit sur AdventureWorks

Cliquer sur Nouvelle requête

Taper la commande create login bouba with PASSWORD='esp'

2eme méthode via Management Studio

Aller sur l’instance

Sécurité – Nouveau – Connexion

Nom : bouba

Authentification : SQL Server

2. Création de compte utilisateur

Aller sur AdventureWorks

Faire un clic droit sur Sécurité – Nouveau – Utilisateur

3. Création d’une assignation utilisateur

Pour permettre à Bouba de visualiser toutes les tables du schéma Production, une des solutions consisterait à en faire le propriétaire. Pour cela :

Dérouler Sécurité – Utilisateurs

Double-cliquer sur bouba

Aller sur Schéma par défaut – Parcourir

Cocher Production

Cliquer sur OK

E. Affectation de rôles

Le rôle est un objet de base de données auquel un ensemble d’autorisations sont octroyées. Les types de rôles sont :

• Rôle de base de données fixe
• Rôle de base de données défini par l’utilisateur
• Rôle d’application

1. Rôles de base de données fixes

Ils sont définis au niveau de la base de données et existent dans chaque base de données

Rôles de base de données fixes	Autorisations
Db_accessadmin	Ajouter, supprimer des utilisateurs, des groupes et des rôles de base de données
Db_backupoperator	Sauvegarder la base de données
Db_datareader	Lire des données à partir d’une table quelconque
Db_datawriter	Ajouter, modifier, supprimer des données d’une table quelconque
Db_ddladmin	Ajouter, modifier, supprimer des objets de base de données
Db_denydatareader	Restreindre la lecture des données d’une table quelconque
Db_denydatawriter	Restreindre la modification des données d’une table quelconque
Db_owner	Réaliser une activité quelconque de rôle de base de données
Db_securityadmin	Créer des schémas, changer des rôles de base de données et des rôles d’application
Public	Maintenir les autorisations par défaut

2. Rôles de base de données définis par l’utilisateur

Il est possible de créer ses propres rôles de base de données pour boucler plusieurs et leur assigner un ensemble commun d’autorisations. Ceci permet de configurer un ensemble d’autorisations à assigner à des utilisateurs d’une base de données.

La commande create role permet de le faire.

3. Rôle d’application

C’est une entité de sécurité de base de données qui permet à une application de fonctionner avec ses propres privilèges.

La commande create application role permet de le faire

4. Assignation de rôles aux utilisateurs de base de données

Chaque rôle se voit assigner un ensemble d’autorisations. Pour assigner des autorisations à un utilisateur, un rôle peut être assigné à un utilisateur où celui-ci peut être autorisé à devenir un membre du rôle.

Dérouler AdventureWorks – Sécurité – Utilisateurs

Double-cliquer sur bouba

Aller dans l’onglet Appartenance au rôle de base de données pour lui assigner un rôle

F. Affectation d’autorisations

Après avoir créé les entités de sécurité, les sécurisables, les autorisations doivent être assignées aux entités de sécurité pour définir le niveau d’accès aux éléments sécurisables qu’elles détiennent.

1. Octroi d’autorisations au niveau du serveur

Au niveau du serveur, les autorisations peuvent être octroyées aux connexions d’accès. Les connexions d’accès peuvent être autorisées à accéder aux objets du serveur ou à accomplir des activités au niveau du serveur telles que la modification et la création de base de données.

Les autorisations communément utilisées pouvant être octroyées au niveau du serveur sont :

• Alter any database
• Alter any endpoint
• Alter any login
• Create any database
• Create any endpoint
• Shutdown
• View any database
• View any definition
• View server state

2. Octroi d’autorisations au niveau de la base de données

Au niveau de la base de données, les utilisateurs doivent pouvoir accomplir des activités telles que la création d’un schéma. Les autorisations octroyées aux éléments sécurisables telles que les schémas, les utilisateurs, les assemblages et les objets service broker. Les autorisations sont :

• Create schema
• Create service
• Create asymetric key
• Create symetric key
• Create contract
• Create queue
• Create role

EXEMPLE : Octroi avec base de données

use AdventureWorks

grant select

on schema::Production

to bouba

3. Octroi d’autorisations au niveau des schémas

Au niveau des schémas, des autorisations peuvent être octroyées pour des éléments sécurisables telles que les tables, les vues, les procédures stockées et les types. Les autorisations sont :

• Create table
• Create function
• Create view
• Create procedure
• Delete
• Update
• Execute
• Insert
• Select
• Alter any user
• View database state
• 
  

EXEMPLE :

use AdventureWorks

grant create procedure

to bouba

Dérouler AdventureWorks – Tables

Faire un clic droit sur la table Person.Contact

Cliquer sur Propriétés – Autorisations – Ajouter – Parcourir

Choisir l’utilisateur bouba

Cliquer sur OK

G. Révocation d’autorisations

Il est parfois nécessaire de supprimer les autorisations octroyées aux utilisateurs.

EXEMPLE :

revoke alter

on schema::Sales

from bouba

H. Chiffrement des données

En plus de restreindre l’accès à la base de données et aux objets de la base de données, il est possible d’ajouter une couche de sécurité supplémentaire en chiffrant les données. Si les données sont chiffrées, elles restent sécurisées même si un utilisateur non autorisé accède à la base de données. Les données et objets de base de données tels les procédures ou fonctions peuvent être chiffrées à l’aide des clés ou certificats.

1. Création de clé

Une clé est une valeur appliquée à une fonction cryptographique pour chiffrer ou déchiffrer une valeur de données sécurisées. Il faut distinguer les clés symétriques et les clés asymétriques.

Pour les clés symétriques c’est une valeur qui est utilisée aussi bien pour le chiffrement que pour le déchiffrement de données.

EXEMPLE : Clé symétrique

create symetric key SymKey

with algorithm= TRIPLE_DES

encryption by password='mot-de-passe'

EXEMPLE : Clé asymétrique

create asymetric key AsymKey

with algorithm= RSA_2048

encryption by password='mot-de-passe'

2. Création de certificat

Un certificat peut être utilisé dans une base de données SQL Server pour ajouter une signature digitale à un objet de base de données tel qu’une procédure stockée ou une fonction.

use AdventureWorks

create certificate AwCustCert

encryption by password='mot-de-pass'

with subject='cert for adventureWorks Customers',

start_date='01/04/2008',

expiry_date='09/04/2008'