Vous êtes sur la page 1sur 46

C018SA-W4-S1

SEMAINE 4 : Contrôle d’Accès


1. Introduction
2. Modèle de contrôle d’accès
discrétionnaire (DAC)
3. Modèle de contrôle d’accès basé sur les
rôles (RBAC)
4. Modèle de contrôle d’accès obligatoire
(MAC)

Benjamin Nguyen Bases de données relationnelles


La sécurité des systèmes d’information
• Les bases de données stockent des données structurées, de grande qualité
Intérêt évident à les attaquer pour dérober de l’information
 Attaques internes (45% d’après le FBI)
 Attaques externes
• Nombreux sites à lister les attaques sur les SGBD
 DatalossDB
 Zataz
 …
• Sont évalué selon des standards :
e.g. Common Criteria for Information Technology
Security Evaluation (Common Criteria ou CC), norme
ISO/CEI 15408

3
Principaux attaquants

Utilisateur
Administrateur

Pirate

Hébergeur

Services
De renseignements

4
5

Principaux mécanismes de défense


9- Législation

2- Protection des 3- Contrôle d’accès 8- Anonymisation de


communications données

eur
rv
Se BD Extraction
Requêtes
Utilisateur
6- Contrôle
d’usage
5- Audit

4- Chiffrement des
données
7- Rétention limitée
1- Authentification des données

5
Le contrôle d’accès
• Précise :
 qui (utilisateurs)
 est autorisé à faire quoi (lectures, écritures, etc…)
 sur quelles données (tables, nuplets, …)
dans quelles conditions
• Format des règles :

Permission agir
avoir réaliser
sur Objet
(table, vue, nuplet)
Sujet avoir
Interdiction Action
(utilisateur) réaliser
Ensemble
agir d’objets
avoir réaliser
Obligation sur
6
Exemple : système de paie dans une entreprise
DRH Services Service X
Sujets = Financiers
Employés de l’entreprise Alice Eric
Bob Charlie Fiona
Diane …

Objets = RH Salaire
Information sur les Dossier Admin
employés
Paie Heures Sup
Actions : Accéder au salaire
Calculer la paye
Accéder aux HS

Mettre à jour le
Déménagement
dossier RH
7
Exemples de règles
• Indépendantes du contenu de l’objet auquel on accède
 Alice et Bob ont le droit de lire et modifier toutes les informations RH des dossiers admin tous les employés
 Charlie et Diane ont le droit de lire toutes les informations Salaire des employés
 Diane a le droit de lire toutes les informations Heures Sup des employés

• Dépendantes du contenu
Eric et Fiona ont le droit de lire les informations de
salaire de leur propre dossier

• Délégation
 Diana a le droit d’autoriser Charlie à lire les
informations Heures Sup

8
Le contrôle d’accès
Objectif :
• Ne permettre l’accès et la modification des données qu’aux personnes autorisés

Plusieurs méthodes :
 Contrôle d’accès obligatoire (MAC)
 Contrôle d’accès discrétionnaire (DAC)
 Contrôle d’accès basé sur les rôles (RBAC)
• Plus ou moins flexibles et plus ou moins sécurisées
• DAC est implémenté dans tous les SGBDs

9
Contrôle d’accès via des vues
DAF DRH
Admin
Id-E Nom Salaire Id-E Nom Tel Adresse Ville
1 Alice 2300 1 Alice 1 2345 Rue Monge Paris

2 Bob 1200 2 Bob 1 2346 Av EU Versailles

3 Charlie 3800 3 Charlie 1 2347 Pl Gordaine Bourges

4 Diane 1600 4 Diane 1 2348 Av d’Italie Paris

Vue « SF » Vue « DRH »


Id-E Nom Tel Adresse Ville Salaire

1 Alice 1 2345 Rue Monge Paris 2300

2 Bob 1 2346 Av EU Versailles 1200

3 Charlie 1 2347 Pl Gordaine Bourges 3800

10 4 Diane 1 2348 Av d’Italie Paris 1600


Table « EMP »
C018SA-W4-S2
SEMAINE 4 : Contrôle d’Accès
1. Introduction
2. Modèle de contrôle d’accès
discrétionnaire (DAC)
3. Modèle de contrôle d’accès basé sur les
rôles (RBAC)
4. Modèle de contrôle d’accès obligatoire (MAC)

Benjamin Nguyen Bases de données relationnelles


Le modèle DAC en SQL (92)

U P V
Utilisateur Permission Vue

Les objets sont


structurés
Par défaut :
tout est interdit

O
A Objet
Action =
N-uplet
=
R/W/etc…

13
Le modèle DAC
• DAC = Discretionary Access Control ou Contrôle d’Accès Discrétionnaire (i.e. à la discrétion du propriétaire de la
donnée)
• Principes
 Le créateur d’un objet est le propriétaire de cet objet
 Le propriétaire fixe la politique de contrôle d’accès sur cet objet
 Les sujets reçoivent des permissions (droits) pour réaliser des actions sur cet objet
 Les sujets ont l’autorisation de transférer certains permissions à d’autres sujets
• Modèle décentralisé
 Avantage : Souplesse
 Inconvénient : Difficulté à administrer

15
Le modèle DAC
• Les droits sont représentés sous forme de matrice
• Remplie par :
 Capacités (ligne, Capability List)
 Autorisations (colonne, Access Control List)
• La matrice peut être très grande…

RH Paie Salaire Heures …


Sup
Alice R/W
Bob R/W
Charlie R/W R/W

16
Expression du DAC en SQL : Commande GRANT
GRANT <liste privileges>
ON <table ou vue>
TO <liste utilisateurs>
[ WITH GRANT OPTION ] ;

• Privilèges : SELECT, INSERT, UPDATE, UPDATE(nom_colonne), DELETE


• WITH GRANT OPTION est optionnel et permet la délégation de droits

17
Expression du DAC en SQL : Commande REVOKE
REVOKE [GRANT OPTION FOR] <liste privileges>
ON <table ou vue>
FROM <liste utilisateurs>
[ RESTRICT / CASCADE ] ;

• RESTRICT / CASCADE : permet de gérer la délégation de droit. Supposons que D donne le droit de
délégation du privilège p à C, puis C le donne à B.
 CASCADE : si D révoque le droit à C alors B le perd
 RESTRICT : si D révoque le droit à C alors B le garde

18
Contrôle d’accès basé sur les vues : Fonctionnement
• Définition de Vues
• Droits donnés sur les vues
• Interrogation des vues et non des tables « primaires » par les utilisateurs
 Vue RH :

CREATE VIEW DRH AS


SELECT ID-E, NOM, ADRESSE, VILLE, TEL
FROM EMP
 Vue SF :

CREATE VIEW DAF AS


SELECT ID-E, NOM, SALAIRE
FROM EMP

Il suffit de contrôler l’accès aux vues


19
Fonctionnement

Alice, RH
Id-E Nom Tel Adresse Ville Salaire

Requête Q sur les tables 1 Alice 1 2345 Rue Monge Paris 2300

2 Bob 1 2346 Av EU Versailles 1200


CA sur la Vue 3 Charlie 1 2347 Pl Gordaine Bourges 3800
Contrôle ?
4 Diane 1 2348 Av d’Italie Paris 1600

Requête Q’
sur les vues
Id-E Nom Tel Adresse Ville

1 Alice 1 2345 Rue Monge Paris

2 Bob 1 2346 Av EU Versailles

3 Charlie 1 2347 Pl Gordaine Bourges


Requête Q’’
4 Diane 1 2348 Av d’Italie Paris
20
sur les tables
Exemples 1/2
• Alice et Bob ont le droit de lire et modifier toutes les informations RH des
dossiers admin tous les employés
GRANT SELECT, UPDATE ON DRH TO ALICE, BOB

• Charlie et Diane ont le droit de lire toutes les informations Salaire des employés
GRANT SELECT, UPDATE ON DAF TO CHARLIE, DIANE

21
Exemples 2/2
• Eric et Fiona ont le droit de lire les informations
de salaire de leur propre dossier
 On pourrait créer une vue par utilisateur avec
juste ses données
 On peut aussi utiliser un opérateur prédéfini SQL : CURRENT_USER

CREATE VIEW PERSO AS


SELECT SALAIRE FROM EMP WHERE ID-E = CURRENT_USER;

GRANT SELECT ON PERSO TO ERIC, FIONA

22
Expressivité
• Forte, mais complexe

« En l’absence de Diane, permettre à Charlie de gérer ses dossiers »


« Permettre l’accès aux données uniquement aux heures ouvrables »

1. Créer des tables pour gérer les meta-données ou utiliser des meta-données système
2. Créer des requêtes utilisant ces tables
3. Donner les droits

23
C018SA-W4-S3
SEMAINE 4 : Contrôle d’Accès
1. Introduction
2. Modèle de contrôle d’accès
discrétionnaire (DAC)
3. Modèle de contrôle d’accès basé sur
les rôles (RBAC)
4. Modèle de contrôle d’accès obligatoire
(MAC)

Benjamin Nguyen Bases de données relationnelles


Le modèle RBAC en SQL (99)
• Rôle = ensemble de privilèges
• Les accès des utilisateurs sont gérés en fonction de leur rôle organisationnel
• Objectif = faciliter l’administration des droits

R P V
Rôle Permission Vue

Structuration
des sujets

O
U A Objet
=
Utilisateur Action N-uplet

27
Opérations de gestion des rôles
CREATE ROLE <nom_role> ;
• Création d’un nouveau rôle nom_role

DROP ROLE <nom_role> ;


• Suppression du rôle nom_role

SET ROLE <liste_roles> ;


• Permet à un utilisateur d’activer un ensemble de rôles
pendant la durée d’une session SQL

28
Evolution de l’instruction GRANT
• Affectation des privilèges aux rôles
GRANT <liste privileges>
ON <table ou vue>
TO <liste roles>
[ WITH GRANT OPTION ] ;
• Affectation des rôles aux utilisateurs
GRANT <liste roles>
TO <liste utilisateurs>
• Rôle junior et rôle senior
GRANT <r1> TO <r2>
Le rôle r2 reçoit tous les privilèges du rôle r1

29
Hiérachie des rôles
• Spécialisation/Généralisation
 r1 est un rôle senior de r2 si chaque fois qu’un utilisateur joue le
rôle r1, cet utilisateur joue aussi le rôle r2
 Les feuilles de la hiérarchie ont plus de privilèges que la racine

Gestionnaire Paie Gestionnaire Heures Sup

Personnel DRH Personnel DAF

Personnel Administratif

30
Hiérachie des rôles
• Hiérarchie organisationnelle
 r1 est un rôle senior de r2 si un utilisateur jouant le rôle r1 est un
supérieur hiérarchique d’un utilisateur jouant le rôle r2
 Les feuilles de la hiérarchie ont plus de privilèges que la racine

Programmeur Technico-commercial

Comptable Chef de Projet

Directeur

31
Les contraintes
• Contrainte sur Utilisateur / Rôle
 Contrainte de type « Séparation des pouvoirs »
 Exemple : rôles comptable et chef de projet sont exclusifs

• Contrainte sur Session / Rôle


 Un utilisateur peut cumuler plusieurs rôles mais pas les activer dans une même session
 Contrainte de type « Séparation des tâches »

• Contrainte sur Rôle / Permission


 Un rôle ne doit pas pouvoir cumuler certaines

Permissions
 Exemple : une action + l’audit ou la validation de

cette action
 Autre contrainte de type « Séparation des tâches »

32
Le modèle RBAC complet RBAC0 : le noyau (URA + PRA)
Hiérarchies RBAC1 : Les hiérarchies
Users-Role RBAC2 : les contraintes
Assignment (URA) Permission-Role
Assignment (PRA)

U R P
Utilisateurs Rôles Permissions

.
.
.
S
Sessions
Contraintes
33
Vers ABAC (Attribute Based Access Control)
• Utilisation des valeurs d’un attribut pour définir les droits
e.g. attribut d’un utilisateur : une vidéo n’est visionnable que si l’utilisateur a plus de 18
ans

• On peut utiliser les attributs des utilisateurs, des ressources, des actions et des contextes

• Intégré depuis 2010 au modèle standard RBAC du NIST

34
C018SA-W4-S4
SEMAINE 4 : Contrôle d’Accès
1. Introduction
2. Modèle de contrôle d’accès
discrétionnaire (DAC)
3. Modèle de contrôle d’accès basé sur les
rôles (RBAC)
4. Modèle de contrôle d’accès
obligatoire (MAC)

Benjamin Nguyen Bases de données relationnelles


Les limites de DAC et RBAC
• DAC  l’application s’exécutant pour le compte d’un utilisateur hérite des droits de ce dernier
• RBAC  l’application s’exécutant pour le compte d’un utilisateur hérite des droits associés
aux rôles activés dans la session ouverte par ce dernier
 Risque de programmes malveillants :
 Cheval de Troie : programme qui a une fonctionnalité apparente mais qui contient des
fonctions cachées
 Objectif : transmission illégale d’informations vers le

bénéficiaire du piège

37
Le modèle MAC : une politique de sécurité multi-niveaux
• Niveaux de sécurité hiérarchiques
 Cloisonnement vertical : Unclassified < Confidentiel < Secret < Top Secret …
• Catégories
 Cloisonnement horizontal : DRH, DAF, etc…
• Classe d’accès = combinaison d’un niveau de sécurité et d’une catégorie
 Le niveau de sécurité d’une classe d’accès associée à un objet est
appelé niveau de classification
 Le niveau de sécurité d’une classe d’accès associée

à un utilisateur est appelé niveau d’accréditation


(Clearance)

38
Exemple
• Données
 Le salaire du directeur a un niveau de classification « Secret », et une catégorie « DAF »
 Le salaire d’un employé a un niveau de classification « Confidentiel », et une catégorie « DAF »

• Utilisateurs
 Alice a un niveau d’accréditation « Secret » et peut accéder à la DAF
 Bob a un niveau d’accréditation « Confidentiel »

et peut accéder à la DAF.

Est-ce qu’Alice peut communiquer le salaire du directeur à Bob ?

39
Fonctionnement
• La décision d’accès est prise en comparant les deux classes d’accès de l’objet et du sujet
 No read up : un sujet est autorisé à lire un objet seulement si sa classe d’accès domine la classe d’accès de l’objet
 No write down : un sujet est autorisé à écrire un objet seulement si sa classe d’accès est dominée par la classe
d’accès de l’objet

• Une classe d’accès c1 domine (≥) c2 ssi :


 Le niveau de sécurité de c 1 ≥ niveau de sécurité de c 2
 Les catégories de c1 c2
 Les deux classes c1 et c2 sont dites incomparables ssi
c1 ≥ c2 ni c2 ≥ c1 ne sont vérifiées

40
Exemple

1.000.000

« Secret »
« Secret » NO WRITE DOWN

1.000.000
???

« Confidentiel »
« Confidentiel »
41
Exemple
1.000.000

« Secret »
NO READ UP

1.000.000
???

« Confidentiel »
« Confidentiel »
42
Implémentation : Oracle Level Security
Niveaux de Sécurité
• Data Label
 Constitué de 3 composants (Level, Compartment, Group)
 Intégré aux tuples dans une colonne additionnelle (déclarée par le DSA)
 Valeurs définies par le DSA
• Level (niveau de sécurité)
 Obligatoire, unique, hiérarchique, dénotant la sensibilité de la donnée
 Exemple: Confidentiel, Secret, Top Secret, etc…

43
Implémentation : Oracle Level Security
Catégories
• Compartment
 Obligatoire, non unique, non hiérarchique, utilisé pour compartimenter les données
 Exemple: types de données, liste de projets ou de secteur d’activité
• Group
 Optionnel, non unique, potentiellement hiérarchique, utilisé pour isoler les données par
organisation
 Exemple: FBI, CIA, NSA

44
Implémentation : Oracle Level Security
Règles d’accès
Il y a obligation de remplir ces règles !

• Un user label est associé à chaque utilisateur


 Mêmes composants: Level, Compartment, Group

• Autorisations requises pour accéder aux données


Les 3 conditions ci-dessous sont requises
 UserLabel.level  DataLabel.level
 DataLabel.compartment  UserLabel.compartment
 UserLabel.group  DataLabel.group

45
Oracle Level Security : Exemple
(Confidentiel ;
Fichier Iran, Militaire ;
NSA, CIA)

(Confidentiel ; (Secret ;
Iran, Militaire, Nucléaire ; Iran ;
CIA) NSA, CIA)
46
Oracle Level Security : Extensions
• Autorisations complémentaires pouvant être données à un utilisateur ou une procédure stockée
 READ : Oracle ne vérifie plus les labels lors des SELECT
 les opérations update/delete/insert restent contrôlées
 FULL: Oracle ne vérifie plus aucun label mais les droits standard sur les objets continuent à s ’appliquer (ex: un GRANT SELECT ON T est
toujours requis pour interroger T)
 WRITEUP – WRITEDOWN: donne le droit au user d’augmenter (resp. réduire) le DataLabel.Level d’un tuple dans la limite de ses propres
capacités
 WRITEACCROSS: donne le droit de modifier Groups

et Compartment d’un DataLabel


• Performance
 Un test supplémentaire par tuple (sauf si READ, FULL)
 Création d’un index bitmap sur l’attribut Label recommandé

47
Conclusion sur le contrôle d’accès
• Principe Fondateur : Réaliser Agir sur

• DAC Sujet Action Objet


 Structuration des objets
• RBAC
 Structuration des sujets
• MAC
 Lutte contre les programmes malveillants
 Politiques lourdes et complexes à définir

Tout ceci ne fonctionne que si


l’attaquant passe par la porte d’entrée !

48