Contrôle d’accès 

La politique de sécurité doit se composée de trois sous–politiques de contrôle : d’accès

physique, administratif et logique. Il faut focaliser particulièrement sur la politique de
contrôle d’accès logique et aux modèles de protection et mécanismes nécessaires pour la
réaliser Le modèle de base de toutes les politiques de contrôle d’accès est montré sur la figure
suivante :

l’opération en une requête qu’il passe au moniteur de référence qui contrôle l’accès aux
ressources. Si le sujet est autorisé à accéder à l’objet selon la politique de sécurité en vigueur,
l’accès à l’objet va être accordé et l’opération peut se dérouler normalement.

Une matrice de contrôle d’accès décrit quels sont les droits d’un sujet sur les ressources du
système.

La matrice de contrôle d’accès est une structure qui contient une ligne par sujet et une colonne
par objet dans le système. La cellule à l’intersection d’une ligne et d’une colonne décrit les
droits d’accès du sujet sur l’objet. La figure suivante montre un exemple de matrice de
contrôle d’accès.
Le modèle de contrôle d’accès basé sur la matrice de contrôle d’accès ne prévoit aucune
interprétation particulière du sujet, de l’objet ou du droit d’accès, mais ce sont normalement
des entités primitives du système.
La granularité de la définition du sujet et de l’objet dépend du système. Quelques définitions
répandues sont : un utilisateur, un processus ou une machine pour les sujets et un fichier, une
relation dans une base de données ou une variable dans un programme pour les objets.
Remarquons que les sujets ont normalement aussi une entrée comme objet dans la matrice.
Ceci permet de contrôler le droit d’envoyer un message à un utilisateur ou un événement à un
processus.

Quelques exemples des droits d’accès sont : le droit de lire, écrire, rajouter à la fin ou exécuter
un fichier pour un système de fichiers, le droit de lire ou modifier une relation dans une base
de données, le droit d’envoyer ou recevoir un message pour un canal de communication ou le
droit de lire ou modifier une variable dans un programme.
Un modèle de protection qui se base directement sur la matrice de contrôle d’accès donne une
description formelle du modèle et définissent la sûreté d’un système comme la propriété qu’il
n’existe pas de fuite des droits d’accès dans le système, c’est–à–dire que le seul moyen
d’entrer un droit d’accès particulier dans la matrice est l’insertion du droit par un sujet
autorisé. Leur analyse montre que la sûreté du modèle n’est pas déterministe en général,
même si la sûreté d’un système particulier dans une configuration particulière peut être
prouvée. Ceci indique qu’il va probablement être difficile de prouver la sûreté d’un système
de protection particulier qui se base sur la matrice de contrôle d’accès.

Une habilitation (“clearance”) est associée à chaque utilisateur. L’habilitation spécifie le

niveau de sécurité auquel l’utilisateur est autorisé à accéder. Une liste de sous–classes
autorisées est normalement associée à l’habilitation, qui limite les informations auxquelles
l’utilisateur habilité peut accéder (“need to know principle”).

Pour pouvoir accéder à l’information, le sujet doit avoir une habilitation égale (ou supérieure)
à la classification de l’information et avoir la sous–classe de l’information dans sa liste des
sous–classes autorisées. L’habilitation d’un sujet spécifie donc en même temps à quel niveau
l’autorité militaire lui fait confiance et le niveau et la nature des informations qu’il a besoin de
connaître.

Mécanismes de contrôle d’accès

Le système doit donc représenter cette matrice d’une façon qui peut être utilisée par le
l’autorité de l’organisation, elle doit être revue selon la politique interne de l’organisme
La matrice de contrôle d’accès décrite auparavant doit être stockée dans sa totalité dans un
endroit sûr est protégé avec une classification ( à discuter )

Liste de contrôle d’accès

Une liste de contrôle d’accès (“Access Control List” ou “ACL”) est associée à chaque
ressource. Elle liste tous les sujets (l’identité de l’utilisateur ou du rôle) qui sont autorisés à
accéder à la ressource et leurs droits d’accès. Toutes les cellules vides sont supprimées.
Le moniteur de référence autorise l’accès à la ressource si le sujet est listé dans l’ACL de
celle–ci. Ceci implique que les ACLs fonctionnent uniquement si l’identité du sujet est
connue sur le site qui gère la ressource.
Il faut qu’un sujet ait le droit de modifier l’ACL pour pouvoir déléguer un droit d’accès. Le
droit de modifier l’ACL est très puissant, il faut donc limiter l’ensemble des sujets qui le
possèdent. Ceci a pour conséquence une politique de protection très statique où les droits
d’accès changent peu.
L’efficacité de la vérification du droit d’accès est un problème pour l’utilisation des listes de
contrôle d’accès.

Liste de capacités :

Une liste de capacités est associée à chaque sujet. Elle contient une entrée (la capacité) pour
chaque ressource à laquelle le sujet peut accéder. La capacité identifie la ressource et décrit
les droits d’accès. Il n’existe pas d’entrée associée à la ressource dans la liste de capacités si le
sujet n’a pas le droit de l’utiliser. La possession de la capacité est normalement un critère
nécessaire et suffisant pour accéder à la ressource. Il faut donc s’assurer qu’un utilisateur ne
peut pas fabriquer des capacités pour les ressources pour lesquelles il n’a pas déjà le droit.

Contrôle d’accès :
Le moniteur de référence autorise l’accès si la capacité est valable, c’est–à–dire qu’elle n’a
pas été créé.
La liste de capacités permet facilement de répondre à la question : “quelles sont les ressources
auxquelles un sujet peut accéder