2.2 Les méthodes de vérification des
politiques de contrôle d'accès
Pour spécifier et vérifier les politiques de
contrôle d'accès, plusieurs langages et outils ont
été développés. Ces mécanismes de
contrôle d'accès spécifient quels sujets sont (ou ne sont
pas) autorisés à effectuer quelles actions spécifiques
à quelle(s) ressource(s). Les plus connus dans la littérature
sont : XACML (eXtensible Access Control Markup Language)[16] [7], PONDER [13],
EPAL (Enterprise Privacy Authorization Language) [14], ASL (Authorization
Specification Language) [15],.... Ils permettent de définir plusieurs
règles de politiques de contrôle d'accès, et parce qu'ils
n'offrent aucun mécanisme pour éviter les conflits et les
incohérences, ils proposent des outils (tels que Alloy analyser, Ponder
toolkit, Margrave, ... ) pour valider les politiques. Dans chaque règle,
on retrouve :
~ Un sujet qui peut être un utilisateur, une machine, un
processus, un programme, etc,
~ Un objet qui peut être un fichier, une base de
données, une machine, un programme, etc,
~ Un droit d'accès qui désigne l'ensemble des
actions qu'un sujet a la permission d'effectuer sur un objet (lire,
écrire, modifier, etc.),
~ Un contexte qui est une contrainte qui lie le sujet, le
droit d'accès et l'objet (contexte temporel, contexte spatial, etc.).
Ces éléments devront être
évalués par le système de contrôle d'accès
avant de générer une décision d'accès à
l'objet qui peut être positive ou négative.
8
Dans un but d'illustration, nous utiliserons le modèle
OrBAC pour montrer comment modéliser la politique de
sécurité d'une organisation. Nous verrons également
comment à partir de JProlog nous pouvons arriver à valider une
politique de sécurité car, la plupart des langages de
contrôle d'accès ci-dessus ne fournissent aucun moyen pour valider
les politiques ou règles de sécurité et aussi, les outils
qu'ils proposent ne sont pas à notre disposition.
3 Modélisation et validation d'une politique de
sécurité
Les attaques 9 auxquelles les organisations sont
généralement exposées, ont permis de développer des
stratégies de sécurité 10 en vue de
protéger le réseau et d'éviter que les systèmes
soient compromis. Toutes ces directives sont définies de manière
globale par la politique de sécurité qui fixe les objectifs de
sécurité auxquels l'organisation devra se conformer en vue de
garantir la protection des ressources de son système. Elles abordent
différentes techniques de défense parmi les quelles le
contrôle d'accès qui nous intéresse.
Il sera donc question dans cette section, de proposer la
politique de contrôle d'accès que pourrait adopter une PME; de
présenter la modélisation de cette politique en utilisant le
modèle OrBAC, ce qui permettra d'étayer le fonctionnement et
maîtriser la complexité de cette politique de
sécurité; et enfin de la valider.
3.1 Le modèle générique
Il est important de se rappeler que dans OrBAC les
règles de sécurité ne sont pas spécifiées
pour chaque sujet, objet et action. Or, il est primordial d'identifier
clairement ces concepts dès la conception. Nous proposons un
modèle générique utilisant le formalisme UML pour la
spécification de ses entités vues comme objets abstraits. Car,
nonobstant le fait qu'il n'existe pas de langage ou d'outil pour
modéliser OrBAC, UML est un langage standard qui a un domaine
d'application très étendu, il a une grande capacité
à décrire des niveaux d'abstractions, à
hiérarchiser des représentations, à enrichir facilement un
modèle et son utilisation est libre de droit.
Ce modèle générique est une
représentation abstraite d'une politique de sécurité
devant être conforme au modèle OrBAC et de son fonctionnement au
sein d'une organisation. Il sert à spécifier la politique de
sécurité indépendamment de l'implantation qui en sera
faite.
Grâce au formalisme UML, nous pouvons modéliser
de manière plus expressive et moins complexe, les éléments
fondamentaux de la politique de sécurité d'une organisation tels
que : les sous
9. Attaques : les intrusions systèmes, les
accès non autorisés, les interceptions et usurpations
d'identités et de mots de passes, les dénis de service ...
10. Stratégies de sécurité :
définition des rôles et responsabilités des utilisateurs,
définition des comportements autorisés et ceux qui ne le sont
pas, ...
9
organisations, les différents rôles, les
différentes activités, les vues et les contextes. La figure 2
présente notre modèle générique.
FIGURE 2 Modèle Abstrait de la politique
Les types d'accès que sont les permissions, les
obligations, les interdictions et les recommandations permettent d'exprimer les
règles contextuelles qui existent entre les éléments
fondamentaux. Notre modélisation décrit uniquement les types
d'accès permission et obligation car selon [12], les recommandations
peuvent être vues comme étant des permissions et les interdictions
sont en fait des non permissions.
Dans la section suivante, nous présentons la
modélisation concrète des règles de sécurité
issue du modèle abstrait.
| 
