Sécurité

des réseaux
Chapitre 3 : Politiques et modèles
de sécurité
1ère année Master RS

Dr. Lamia Hamza

Université de Bejaia
 Concepts de base

Une politique de sécurité est l’ensemble des lois, règles et

pratiques qui gèrent la façon dont l’information sensible et les
autres ressources sont gérées, protégées et distribuées à
l’intérieur d’un système spécifique.

La plupart des politiques de sécurité reposent sur les notions de

sujets, d’objets et de droits d’accès.

2
 Concepts de base

Un sujet est une entité active, correspondant à un processus qui

s’exécute pour le compte d’un utilisateur.

Un objet est une entité considérée comme passive qui contient

ou reçoit des informations (fichiers, relations dans une base de
données relationnelle, etc.).

Les actions (ou Opérations) permettent aux sujets de

manipuler les objets (lecture d’un fichier, requête dans une base
de données, etc.).
3
 Concepts de base

Exemple
sujets :
Ali et Ahmed: médecins
Anis et Amine : infirmiers
Meriem : secrétaire médicale
objets :
patients
dossier : médical ou administratif

actions :
consulter, modifier le dossier médical d’un patient
créer le dossier médical d’un patient
4
 Concepts de base

Les droits d’accès peuvent être symboliquement représentés

dans une matrice de droits d’accès dont les lignes représentent
les sujets et les colonnes représentent les objets.

Une cellule de la matrice contient donc les droits d’accès d’un

sujet sur un objet.

La matrice est gérée conformément aux règles définies dans la

politique de sécurité.

5
 Concepts de base

Exemple d’une matrice de contrôle d’accès :

6
 Modes d’accès

read (r)
lecture d’une information contenue dans un objet

write (w)
écriture d’une information dans un objet en voyant son contenu

append (a)
ajout d’une information à un objet sans voir son contenu

execute (x)
exécution d’un programme

own
possession d’un objet
7
 Modèles de sécurité

Les politiques de sécurité se classent en deux grandes

catégories :

Les politiques discrétionnaires (ou DAC pour Discretionary

Access Control)

Les politiques obligatoires (ou MAC pour Mandatory Access

Control).

Il existe également des variantes de ces politiques qui peuvent

mieux s’adapter à des organisations particulières, comme les
politiques basées sur la notion de rôles (ou RBAC pour Role-
Based Access Control).
8
 Politiques et modèles d’autorisation discrétionnaires (DAC)

Dans le cas d’une politique discrétionnaire, les droits d’accès à

chaque information sont manipulés librement par le responsable
de l’information (généralement le propriétaire), à sa discrétion.

Les droits peuvent être accordés par ce responsable:

 à chaque utilisateur ;
 à des groupes d’utilisateurs ;
 ou bien aux deux.

Ceci peut parfois amener le système dans un état d’insécurité.

Une politique discrétionnaire n’est applicable que dans la

mesure où il est possible de faire totalement confiance aux
utilisateurs et aux sujets qui s’exécutent pour leur compte. 9
 Politiques et modèles d’autorisation discrétionnaires (DAC)

Dans le modèle d’autorisation discrétionnaire un utilisateur

peut transmettre plus de droits que nécessaires à un autre
utilisateur.

Exemple de problème de la propagation des droits

Un droit d’accès peut être transmis sans que son propriétaire

soit informé :
 A donne un droit en lecture à B sur un de ses fichiers ;
 B copie ce fichier ;
 B étant propriétaire de la copie, transmet son droit de
lecture à C.

10
 Politiques et modèles d’autorisation discrétionnaires (DAC)
Modèle de Lampson (1971)

La structure de ce modèle est celle d’une machine à états où

chaque état est un triplet (S,O,M) avec :
 S désignant un ensemble de sujets ;
 O un ensemble d’objets ;
 M une matrice de contrôle d’accès.

Chaque cellule M(s,o) de cette matrice contient les droits

d’accès que le sujet s possède sur l’objet o.

Les droits correspondent généralement à des actions

élémentaires telles que “ lire ” ou “ écrire ”.
11
 Politiques et modèles d’autorisation discrétionnaires (DAC)
Modèle HRU (1976)

Le modèle HRU a été introduit par M.A. Harrison, W.L. Ruzzo et

J.D. Ullman. Comme dans le modèle de Lampson, HRU utilise
une matrice d’accès classique, la différence réside en ce que
HRU précise les commandes qui peuvent lui être appliquées.

Les seules opérations possibles sont données dans le tableau

suivant :

Où, a est un droit.

12
 Politiques et modèles d’autorisation obligatoires (MAC)

Une politique de sécurité d’autorisation obligatoire impose des

règles d’autorisation incontournables qui s’ajoutent aux règles
discrétionnaires.

Une politique obligatoire suppose que les utilisateurs et les

objets aient été étiquetés :
 Classiquement, les objets se voient attribuer une
classification, tandis que les utilisateurs possèdent une
habilitation.
 Les règles qui gèrent les autorisations d’accès sont basées
sur une comparaison de l’habilitation de l’utilisateur et de la
classification de l’objet.
13
Politiques et modèles d’autorisation obligatoires (MAC) Modèle
de Bell-La Padula (1973)
Le modèle de Bell-La Padula (BLP) a été développé par David
Elliott Bell et Leonard J. La Padula pour formaliser la politique de
sécurité multi-niveau du Département de la Défense des États-
Unis.
Pour éviter la divulgation de l'information, deux caractéristiques
doivent être maintenues :
 No-read-up : Un sujet ne doit pas lire des informations
appartenant à un niveau supérieur car il peut connaître des
informations qui ne lui sont pas autorisées.
 No-write-down : Un sujet ne doit pas écrire dans des
informations de niveau inférieur car il peut révéler des secrets.

La politique de Bell-La Padula vise à assurer la confidentialité. 14

Politiques et modèles d’autorisation obligatoires (MAC) Modèle
de Biba (1977)

Le modèle de Biba ou modèle d'intégrité de Biba, développé par

Kenneth J. Biba vise à assurer l'intégrité au travers d'une règle
simple :

« pas d'écriture dans un niveau supérieur, pas de lecture d'un

niveau inférieur ».

Le modèle de Biba permet l'invocation : un sujet peut invoquer

un autre sujet seulement si le niveau d'intégrité du premier sujet
domine le niveau d'intégrité du deuxième.

15
 Politique et modèle de sécurité par rôles (RBAC)

Un rôle représente de façon abstraite une fonction identifiée

dans l’organisation (par exemple, chef de service, ingénieur
d’études, etc.).

À chaque rôle, on associe des permissions (ou privilèges),

ensemble de droits correspondant aux tâches qui peuvent être
réalisées par chaque rôle.

Exemple :

Si le docteur Dupont est à la fois chirurgien et directeur de

l’hôpital, en tant que chirurgien, il aura le droit d’accès aux
dossiers médicaux, alors qu’en tant que directeur, il pourra
accéder aux informations administratives. 16
 Politique et modèle de sécurité par rôles (RBAC)

Cette politique est régulièrement utilisée en entreprise, ou

chaque personne possède un rôle particulier qui lui donne accès
à certaines informations.

 Le rôle va permettre d’attribuer un ensemble de permissions à

un type d’utilisateurs :

 Plusieurs utilisateurs peuvent avoir le même rôle ;

 Un utilisateur peut avoir plusieurs rôles, qu’il pourra activer
au besoin.

17
 Politique et modèle de sécurité par rôles (RBAC)

L’applicabilité de ce modèle peut être :

1) Utilisation de rôles « hiérarchiques » :

un rôle « hiérarchiquement supérieur » possède toutes les
permissions des rôles « inférieurs »
Si RoleA ≥ RoleB alors toute permission accordée à RoleB est
aussi accordée à RoleA.

18
 Politique et modèle de sécurité par rôles (RBAC)

2) Contrôle des activations simultanées des rôles :

plusieurs rôles peuvent selon les cas être autorisés
simultanément pour un même utilisateur.

Ce type d’accès aux données apparait très proche de ce que

nous connaissons sous Windows notamment, par
l’intermédiaire de la gestion des comptes utilisateurs.

19
Sécurité des bases de données : Principe du moindre privilège

Ce principe stipule qu’un sujet ne doit disposer que des droits

d’accès minimum pour assurer l’exécution des tâches qui lui
sont assignées, pas un de plus.

Exemple :
ne pas donner les droits de l’administrateur à tout utilisateur d’un
système (système d’exploitation, SGBD).

20
 Sécurité des bases de données : Contrôle d’accès & SGBD

Sécuriser une base de données consiste à mettre en œuvre

une politique de sécurité dans un Système de Gestion de Base
de Données (SGBD) conformément à un modèle de sécurité.

 Une politique de sécurité doit viser deux propriétés

• complétude: tous les attributs sont protégés, même si la
protection indique accès libre
• cohérence: pas de conflit entre les différentes règles de
sécurité

21
 Sécurité des bases de données : DAC & SGBD

 Modèle de sécurité SQL: utilisateurs, opérations SQL, objets

(tables, vues, attributs)
 À la création d’un objet, son propriétaire a tous les droits, y
compris celui d’accorder ou de révoquer des privilèges à
d’autres utilisateurs
 Un privilège est composé des éléments suivants
 utilisateur qui accorde le privilège
 utilisateur qui reçoit le privilège
 Objet
 action permise
 transmission possible du privilège
22
 Sécurité des bases de données : DAC & SGBD

Exemple

• si Alice est propriétaire de la relation R, elle peut accorder le

privilège de la consulter (SELECT) à Bob
• si elle indique que ce privilège est transmissible, Bob pourra à
son tour accorder ce privilège à un autre utilisateur
• si Alice révoque le privilège à Bob, alors Bob et tous ceux qui
ont reçu ce privilège de Bob perdent l’accès à la relation R

23
 Sécurité des bases de données : DAC & SQL

Deux éléments de SQL interviennent :

1) Le mécanisme de vues qui est utilisé pour cacher des
données sensibles à des utilisateurs non autorisés ;
2) Le sous-système d'autorisation qui permet aux
utilisateurs ayant des privilèges particuliers d'attribuer
sélectivement et dynamiquement ces privilèges à d'autres
utilisateurs, et de révoquer ensuite ces privilèges, s'ils le
souhaitent.
SQL offre deux commandes pour octroyer ou révoquer des
privilèges : GRANT, REVOKE

24
 Sécurité des bases de données : DAC & SQL

Syntaxe de GRANT
GRANT (liste de privilèges | ALL)
ON liste d’objets
TO liste d’utilisateurs | PUBLIC
[WITH GRANT OPTION]

avec :
ALL : tous les privilèges que le donneur peut accorder
PUBLIC : tous les utilisateurs connus du système
WITH GRANT OPTION : indique que le receveur pourra
transmettre les privilèges qui lui sont octroyés

25
 Sécurité des bases de données : DAC & SQL

Syntaxe de REVOKE
REVOKE [GRANT OPTION FOR] (privilèges | ALL)
ON liste d’objets
FROM liste d’utilisateurs
[{RESTRICT | CASCADE}]
avec :
CASCADE : la révocation concerne les utilisateurs cités dans la clause
FROM ainsi que ceux à qui ces privilèges ont été récursivement
transmis.
RESTRICT : la révocation ne concerne que les utilisateurs cités dans
la clause FROM
GRANT OPTION FOR
ce n’est pas les privilèges qui sont révoqués, mais le droit de le
26
transmettre
 Sécurité des bases de données : DAC & SQL

RESTRICT / CASCADE
 supposons que p soit un privilège sur un objet et que
l'utilisateur Bob accorde p à l'utilisateur Alice, qui à son tour
l'accorde à l'utilisateur Charlie

 que se passe-t-il maintenant si Bob révoque p à Alice?

le privilège p détenu par Charlie doit être « abandonné » car il
provient de l'utilisateur Alice qui ne le détient plus

 L'objectif de l'option RESTRICT / CASCADE est d'éviter

l'abandon de privilèges
27
 Sécurité des bases de données : DAC & SQL

La structure des commandes pertinentes en SQL

28
 Sécurité des bases de données : DAC & SQL

Considérons une relation Employe qui indique, pour un individu

donné, s'il s'agit d'un homme ou d'une femme et quel est son
âge, son salaire et sa profession. Nous définissons la vue
suivante sur la relation Employe :

CREATE VIEW Emp_Programmeur AS

SELECT Nom, H/F, Profession
FROM Employe
WHERE Employe.Profession = "Programmeur" ;

Cette vue ne contient que les employés dont la profession est

programmeur et pour ces employés, on donne uniquement le
nom, la profession et s'il s'agit d'un homme ou d'une femme.
29
 Sécurité des bases de données : DAC & SQL

Le mécanisme de vues ne permet pas de spécifier les opérations

que certains utilisateurs sont autorisés à exécuter. Cette fonction
est réalisée par l'instruction GRANT.
GRANT SELECT, DELETE
ON Emp_Programmeur
TO Imad, Amine, Sarra;

Cette instruction donne l'autorisation aux utilisateurs Imad,

Amine et Sarra de sélectionner et de supprimer n'importe quel n-
uplet de la vue Emp_Programmeur.

30
 Sécurité des bases de données : MAC

 Comment obtenir un niveau élevé de protection sur les

éléments d'un SGBD?

 contrôle d'accès obligatoire : les principaux vendeurs de

SGBD (Oracle, Informix, Sybase) ont tous une version
MAC de leur système.

31
 Sécurité des bases de données : MAC

 Modèle simplifié de Bell-La Padula

 soit S, un ensemble d’utilisateurs du système du SGBD

 soit O, un ensemble d'objets (tables, relations, n-uplets,
etc.)
 une relation d'ordre partiel ≤ sur les étiquettes N (Niveau)
ou L (pour Level), aussi appelées classes d'accès
 soit fs : S L et fo : O L, assignant respectivement des
classes d'accès aux utilisateurs et aux objets

32
 Sécurité des bases de données : MAC

 Règle de simple sécurité (No-read-up): un sujet s peut lire un

objet o seulement si sa classe d'accès domine celle de l'objet,
c'est-à-dire fo(o) ≤ fs(s)

 Règle étoile (No-write-down) : un sujet s peut modifier un

objet o seulement si sa classe d'accès est dominée par celle
de l'objet, c'est-à-dire fs(s) ≤ fo(o)

33
 Sécurité des bases de données : MAC

La mise en œuvre d'une politique de sécurité multi-niveaux

(MAC) dans un SGBD pose quelques problèmes :

 Choix et interprétation d'une granularité de classification ;

 Gestion des leurres ;

 etc.

34
 Granularité de la classification

Dans le cas des bases de données relationnelles, plusieurs

granularités ont été proposées dans la littérature, les
granularités les plus courantes étant le n-uplet et l'attribut de
n-uplet.

Considérons la relation Employe déjà cité :

Si l'on attribue le niveau de classification Secret au n-uplet

Employe(Samy,H,30,2000E,Programmeur), cela signifie que
l'information «Samy est un employé masculin ayant 30 ans,
gagnant 2000E et travaillant comme programmeur » est
classée au niveau Secret.
35
 Granularité de la classification

Ce niveau de classification n’est pas très fin, pourquoi ?

 Samy est un employé
 Samy est un homme
 Samy a 30 ans
 Samy gagne 2000 euros
 Samy est programmeur

Toutes ces informations sont au même niveau

Une gestion de SGBD nécessite l’ajout d’un attribut TC (Tuple-
Class) qui décrit le niveau
Employé(Nom, H/F, Age, Salaire, Profession, TC)
Employé(Nom, P, H, P, Age, C, Salaire, S, Profession, C)
Avec :
• C = Confidentiel, P = Public, S= Secret 36
 Granularité de la classification

Exemple de classe d’accès :

• la relation Réservations [P]

• les lettres entre crochets indique la classe d'accès
• pour chaque attribut, la classe d'accès suit la valeur de l’attribut

37
 Gestion des leurres

Un leurre est une information fausse introduite dans une base de

données multiniveaux, en général, pour protéger l'existence
d'une information sensible.

38
 Gestion des leurres

Supposons que la base de données contienne l'information

Salaire(Samy,2000E),
c'est-à-dire « le salaire de Samy est 2000E ».
Supposons que cette information soit classée au niveau Secret :
[Secret]Salaire(Samy,2000E)

Supposons également que le salaire de Samy soit unique et que

la base de données contienne l'information Salaire(Samy,1500E)
et que cette information soit classée au niveau Public :
[Public]Salaire(Samy,1500E)

39
 Gestion des leurres

Supposons qu'un utilisateur u de niveau Public pose la requête :

Quel est le salaire de Samy ?

Supposons que la base de données réponde « vous n'avez pas

le droit de connaître cette information ».

L'utilisateur u peut alors déduire de cette réponse que le salaire

de Samy est classé secret

$ x, [Secret]Salaire(Samy,x)

40
 Gestion des leurres

On peut, considérer que cette dernière information est elle-même

secrète :

[Secret]( $ x, [Secret]Salaire(Samy,x))

Dans ce cas, la base de données ne peut plus répondre à u

« vous n'avez pas le droit de connaître cette information ».

L'utilisation d'un leurre est alors nécessaire et la base de données

multi-niveaux va alors répondre que le salaire de Samy est
1500E.

41
 Exercices supplémentaires

Exercice 1 :
Que signifie « contrôle d'accès basé sur les attributs (ABAC) » ?

Exercice 2 :
Que signifie « contrôle d'accès par chiffrement (KP-ABE et CP
ABE)»?

42
 FIN DU
CHAPITRE 3

43