departement d'informatique memoire · departement d'informatique memoire présenté par...
Post on 25-Oct-2020
24 Views
Preview:
TRANSCRIPT
DEPARTEMENT D'INFORMATIQUE MEMOIRE
Présenté par
KHELIFA Nor Eddine
Pour obtenir
LE DIPLOME DE MAGISTER
Spécialité Informatique
Option : Sécurité des systèmes d’information
Intitulé :
Intégration du modèle de contrôle d’accès RBAC (Role Based Access control) dans les diagrammes UML (Cas d’Utilisation et Séquence).
Devant les membres du jury :
Président : LEBBAH Y.
Professeur à l’université d’Oran
Directeur : RAHMOUNI M.K. Professeur à l’université d’Oran
Examinateur : NAIT-BAHLOUL S.
Maître de conférence A à l’université d’Oran
Examinateur : YAGOUBI B. Maître de conférence A à l’université d’Oran
Sommaire Introduction Générale ……...………………………………………………………………… 1
Chapitre I : Sécurité et contrôle d’accès …………………………………………………....3
1. Introduction………………………………………………………………………………….4
2. Définition de la sécurité…………………………………………………………………….5
2.1. Les concepts de la sécurité de l’information…………………………………………....5
2.1.1. Sécurité par la sécurisation des couches d’un système…………………………….6
2.1.2. La sécurité vue Whitson. G………………………………………………………....6
2.1.2.1. La sécurité vue comme Théorie………………………………………...….6
2.1.2.2 La sécurité vue comme Procédé (process)……………….…...…………….7
a. Modèle présenté de Whitson.G……………………………………………7
b. AEGIS (Appropriate and Effective Guidance for Information Security...10
c. Modèle Eric M…………………………………………………………...12
2.1.2.3. La sécurité vue comme une gestion ……………………………………...10
3. Introduction sur les besoins de sécurité…………………………………………………...13
3.1. Besoin de sécurité comme fonction de Sécurité ………………………………………13
3.2. Besoin de sécurité comme besoins non fonctionnels………………………………….14
3.3. Besoin de sécurité comme Propriétés de Sécurité……………………………………..14
3.4. Besoin de sécurité comme négation des propriétés de sécurité ou de fonction du
système………………………………………………………………………………………..15
4. LE CONTROLE D’ACCES……………………………………………………………….16
4.1. Définition du contrôle d’accès ……………….………………………………………...16
4.2. Les Objectifs du Contrôle d’Accès …………………………………………………….17
4.3. La Politique de contrôle d’Accès ………………………………………………………17
4.4. Les Concepts de base d’une politique de contrôle d’accès …………………………….17
4.5. Les axes de la politique de contrôle d’accès……..……………………………………..17
4.6. Les Types de Contrôle d’Accès ………………………………………………………..18
4.6.1. MAC……………………………………………………………………………...18
4.6.2. DAC……………………………………………………………………………...19
4.6.1 .RBAC…………………………………………………………………………….20
5. Comparaison……………………………………………………………………………….20
6. Conclusion ………………………………………………………………………………...21
Chapitre II : RBAC et les différents travaux se rapportant à ce modèle………………..22
1. Introduction………………………………………………………………………………...23
2. Le Standard RBAC………………………………………………………………………...23
2.1. Le modèle de référence ……………………………………………………………….23
2.2. Les spécification fonctionnelle administrative et système du RBAC………………...23
3. Les composants du RBAC …………...…………………………………………………...24
3.1. Le noyau du RBAC……………………………………………………………………24
3.2. Hiérarchie RBAC……………………………………………………………………..26
3.2.1 Le RBAC hiérarchique général…………………………………………………26
3.2.2 Le RBAC hiérarchique restreint………………………………………………..28
3.3. Les contraintes RBAC………………………………………………………………...28
3.3.1. Séparation statique des devoirs (SSD) ……………………………………….29
3.3.2 Séparation dynamique des relations de devoir (DSD) ……...………………...30
3.3.3. Contrainte de pré-requis……………………………………………………….32
4. Les travaux sur le modèle RBAC…………………………………………………………32
4.1 AuthUML……………………………………………………………………………...32
4.2 SecureUML …………………………………………………………………………...34
4.3 Le Modèle Ahn et Hong………………………………………………………………36
4.4 Le modèle de Gut et Mark…………………………………………………………….38
4.5. Le modèle de Thuong et all …………………………………………………………..43
4.6. Le modèle de P.Marsical et all ………………………………………………………43
4.7. Le modèle de Indrakshi et all ………………………………………………………...45
5. Autres travaux……………………………………………………………………………...47
6. Mécanisme d’extension à partir d’ UML…………………………………………………..47
7. Conclusion………………………………………………..………………………………..49
Chapitre III : Analyse et conception du projet………...…………………………………50
1. Introduction………………………………………………………………………………...51
2. Motivation………………………………………………………………………………….52
3. Vue Globale sur le projet…………………………………………………………………..52
3.1 Instanciation du modèle d’application………………………………………………..53
3.2 Initier RBAC…………………………………………………………………………53
3.3 Instancier la politique contrôle d’accès……………………………………………….53
3.4 Détecter l’Incohérence entre politique de sécurité et modèle application……………54
3.5 Simulation…………………………………………………………………………….55
3.6 Génération du code…………………………………………………………………...55
4. Modèle de Conception……………………………………………………………………..55 5. Détail du procédé…………………………………………………………………………..57
5. 1. Instanciation du modèle d’application………………………………………………58
5.1.1 Analyse…………………………………………………………………………59
5.1.2. L’instanciation du graphe……………………………………………………..59
5.2. Initialisation des éléments du modèle RBAC………………………………………...62
5.2.1. Définition des rôles……………………………………………………………..63
5.2.1.a Acteur …………………………………………………………………..63
5.2.1. a.1 Le cas où chaque acteur joue un seul rôle ………………….63
5.2.1. a.2 Le cas où chaque acteur joue plusieurs rôles …………...….64
5.2.1.b Cas d’utilisation…………………………………………………………67
5.2.1. b.1 Un rôle représente un seul cas d’utilisation………………...67
5.2.1. b.2 Un rôle est défini à partir de plusieurs cas d’utilisation…….70
5.2.1.c L’association entre acteur et cas d’utilisation………………..………….71
5.2.2. Définir les utilisateurs………………………………………………………….72
5.2.3 Dérivation des permissions……………………………………………………..73
5.2.4. Dérivation des hiérarchies de rôle……………………………………………...75
5.3. Instancier Politique Contrôle d’accès…………………………………………………78
5.4 Détection de l’incohérence……………………………………………………………..79
5.4.1. Propagation……………………………………………………………………..80
5.4.2. Définition des contraintes………………………………………………………82
5.4.3. Détection………………………………………………………………………..85
5.5. Simulation…………………………………………………………………………….91
5.5.1 Simulation des contraintes dynamiques DSD :………………………………….92
5.5.2 Génération des scénarios………………………………………………………...94
5.6. Génération du code…………………………………………………………………...95
5.6.1. Génération basique des règles pour l’ EJB ……………………………………..95
5.6.2. Génération de l’infrastructure des contrôles d’accès……………………………96
5.6.3. Génération des permissions …………………………………………………….96
7. Conclusion ……………………………………………………………………………….99
Chapitre 4 : Modélisation………………………………………………………………….101
1. Description du processus ………………………………………………………………...102
2. L’analyse des besoins……………………………………………………………………..102
2.1 Spécification des cas d’utilisation……………………………………………………103
2.1. a. Identification des acteurs et des cas d’utilisation ………………………………..103
3. L’analyse …………………………………………………………………………………109
3.1. Spécification des diagrammes de classes…………………………………………….109
3.2. Spécification des diagrammes d’interaction…………………………………………114
Chapitre 5 : Implémentation et tests de l’application …………………………………..129
1. Introduction……. ………………………………………………………………………...130
2. RBAC dans les applications J2EE………………………………………………………..130
2.1. Les bases de l’ EJB…………………………………………………………………..131
2.2. RBAC pour EJB……………………………………………………………………...134
3. Exemple ………………………………………………………………………………….134
3.1 Exemple Banque …..………………………………………………………………...134
3.1.1 Vérification cohérence ……………………………………………………..…134
3.1.2 Simulation……………………………………………………………………. 139
3.2. Exemple questionnaire………………………………………………………………… 139
3.2.1 Générer du code.……………………………………………………………..142
Conclusion Générale………...……………………………………………………..……....143
Annexe………………………………………………………………………………………145
Bibliographie..…………………………………………………………………………… ..149
Introduction Général
Introduction Générale La sécurité revêt un aspect crucial dans le développement et la gestion des systèmes
informatiques modernes, et plus particulièrement le contrôle d’accès. Ce dernier est devenu le
souci majeur des développeurs de logiciel.
Plusieurs types de contrôle d’accès ont été proposés : le DAC (Discretionary Access Control),
le MAC (Mandatory Access Control), et enfin le RBAC (Role Based Access Control) : ce
modèle a pour concepts, premièrement, qu’à chaque utilisateur est assigné un rôle qui lui
permet d’accéder à des permissions et que, deuxièmement, la définition des contraintes est la
traduction de la politique de contrôle d’accès.
Toutefois, il est indispensable de considérer les besoins de sécurité dès les premières phases
du cycle de vie de développement de l’application.
En effet, les besoins de sécurité qui sont spécifiés dès les premières phases du cycle de vie du
logiciel affectent les phases qui suivent, et sont susceptibles de figurer dans le produit final. Il
est donc important de les intégrer et de les analyser durant les phases antérieures de
développement pour en assurer la cohérence.
Dans UML, les besoins sont spécifiés grâce au diagramme des cas d’utilisation et au
diagramme de séquence (modèle d’application) pour les exigences détaillées qui sont
considérées comme les premiers diagrammes utilisés dans plusieurs processus de
développement de logiciel tels que RUP et INOX…
Ainsi, nous nous sommes inspirés de cet état de fait pour élaborer notre projet. Ce projet
consiste à créer un environnement de développement d’applications sécurisé (contrôle
d’accès) dès les premières étapes du cycle de vie, c'est-à-dire intégrer le contrôle d’accès dès
la spécification des diagrammes de cas d’utilisation et de séquence.
Enfin, ce projet consiste à élaborer un outil basé sur une méthodologie qui permet d’analyser
les besoins de contrôle d’accès d’une application à partir des spécifications des besoins
fonctionnels. Cette étude nous a permis de concrétiser un outil de travail capable de :
1. Instancier le modèle de l’Application
2. Initier le RBAC
3. Instancier la Politique de Contrôle d’accès
4. Détecter les Incohérences
5. Simuler les créations et les destructions de sessions, ainsi que les créations de scénarios
(attaques)
6. Générer un code sécurisé.
1
Introduction Général
Notre document est structuré en 5 chapitres.
Chapitre 1 : il comprend des définitions de base concernant la sécurité, les différents
concepts de sécurité, les besoins de sécurité et enfin le contrôle d’accès ainsi que ses
différents types.
Chapitre 2 : dans ce chapitre, nous nous intéressons plus particulièrement au modèle RBAC.
Une définition détaillée des différents composants est proposée selon ANSI /NIST, ainsi que
les travaux les plus récents sur ce modèle. Cette étude nous a permis de comprendre les
mécanismes d’extension, ainsi que la construction d’un langage basé sur UML, et de
constituer une source d’inspiration pour l’élaboration de notre projet.
Chapitre 3 : il constitue le cœur de notre travail, nous y présentons la conception et l’analyse
de notre projet. Nous définissons tout d’abord, sous forme de diagramme d’activités, une vue
de haut niveau de notre méthodologie qui permet d’analyser les besoins de contrôle d’accès
de l’application. Ensuite, chaque activité est détaillée en utilisant les algorithmes et
diagrammes d’activités
Chapitre 4 : nous y proposons une modélisation selon ces différents aspects :
• Aspect fonctionnel : diagramme de cas d’utilisation.
• Aspect statique : diagramme de classes.
• Aspect dynamique : diagramme d’activités et diagramme de séquence.
Chapitre 5 : nous y exécutons notre application ainsi que les tests qui concerneront la
détection des incohérences, la simulation et les destructions de sessions ainsi que le code
sécurisé.
2
Chapitre I Sécurité et contrôle d’accès
1. Introduction « L’information s’impose comme un capital des plus précieux pour l’organisation »
L’information constitue avec les hommes, les équipements et les capitaux, une ressource
essentielle de l’entreprise.
Les flux d’information engendrent, coordonnent et contrôlent les flux matériels, financiers et
humains. Ils renseignent sur l’état des activités de l’organisation. Ces données, indispensables
pour le pilotage de l’entreprise, sont stockées dans un ordinateur et sont souvent soumises à
des attaques. Les attaquants sont des personnes qui, intentionnellement ou accidentellement,
compromettent le système en exploitant ses défaillances. L’attaquant manipule certains objets
dans le système avec un effet préjudiciable. Ces attaques (réalisées par des moyens techniques
et par l’ingénierie sociale) sont dirigées surtout sur les points d’entrée de l’entreprise, c'est-à-
dire les points d’accès à l’information (électronique ou physique), et ciblent trois objectifs:
Les données: les informations stockées dans les ordinateurs.
Les ressources: les ordinateurs eux-mêmes.
La réputation: un intrus usurpe l’identité de quelqu’un d’autre, tout ce qu’il fait semble
provenir de cet autre.
Ces cibles d’attaques informatiques ont un impact qui peut être extrêmement préjudiciable à
l’organisation et, par conséquent, l’entreprise sera globalement inopérante jusqu’à sa
paralysie. Pour remédier à cet état de fait, les développeurs de logiciels axent actuellement
leurs recherches sur le concept de sécurité des ordinateurs, et plus particulièrement sur le
contrôle d’accès des systèmes.
Avant d’aborder ce sujet (contrôle d’accès), nous avons jugé utile d’introduire dans ce
chapitre 1:
1) Une définition de base sur la sécurité de l’information en se fondant sur ce qui est
protégé (l’information), et sur ce que la sécurité représente.
2) Les différents concepts de la sécurité tels qu’ils sont présentés dans les récentes
publications et qui fournissent le meilleur support pour le développement de systèmes
sécurisés.
3) Une définition des différents types de besoins de sécurité qui sont définis de façon à
respecter certains objectifs de sécurité du composant. Ces composants ont besoin d’être
conçus selon l’environnement d’application où ils sont déployés.
4) Enfin, en ce qui concerne le contrôle d’accès, nous proposons: une définition, des
objectifs, une définition de la politique, ainsi qu’un panorama sur les différents types de
4
Chapitre I Sécurité et contrôle d’accès
contrôle d’accès, puis une comparaison des caractéristiques-clés de ces types de contrôle
d’accès.
2. Définitions de la Sécurité La sécurité de l’information est l’ensemble des mesures adoptées pour empêcher l’utilisation
non autorisée, le mauvais usage, la modification, ou le refus d’utilisation d’un ensemble de
connaissance, de données ou de moyens.
La sécurité de l’information ne garantit pas la sécurité de l’entreprise, ni celle de ses propres
informations, ou de ses systèmes informatiques.
Elle désigne les mesures préventives mises en place pour préserver les informations et les
moyens. Ces mesures protègent contre les menaces et contre l’exploitation des vulnérabilités.
Aussi, on ne peut pas définir le niveau de sécurité d’un produit et, en réalité, aucun produit ne
peut fournir une sécurité totale à une entreprise: les travaux des spécialistes de la sécurité se
limitent à assurer une protection optimale (idéale) aux informations, et non une solution
universelle.
2.1. Les concepts de la sécurité de l’information Chaque époque a eu son concept de sécurité, aucun de ces concepts n’a résolu a lui seul tous
les problèmes de sécurité. Cette évolution de concepts, à travers le temps, a permis de définir
qu’une sécurité efficace de l’information est la combinaison de certains concepts que l’on
peut formaliser par l’expression suivante:
Info-sec = Phys-sec + Com-sec + Em-sec + Compu-sec + Net-sec.
Sécurité physique: protége les biens physiques (Doc, Systèmes : murailles, gardes, cameras). Sécurité communication: protége la circulation de l’information (mots codés).
Sécurité des émissions: protége les lectures des émissions électroniques (analyse des signaux
électroniques).
Sécurité ordinateur: contrôle l’accès des systèmes.
Sécurité réseaux: vérifie la sécurité des réseaux locaux.
Dans ce qui suit, nous avons choisi quelques visions sur la sécurité proposées dans de récentes
publications:
5
Chapitre I Sécurité et contrôle d’accès
2.1.1. Sécurité par la sécurisation des couches du système
Lamsweeders [1] propose une approche définissant un système comme un ensemble de quatre
couches disposées l’une sur l’autre comme suit : Couche Application, Couche Système,
Couche Sécurité et Couche Cryptographique. Pour chaque couche, un ensemble de solutions
est proposé pour atteindre une sécurisation idéale du système.
La sécurité de ce système passe par la sécurisation de chaque couche du modèle comme le
montre la figure 1:
2.1.2. La sécurité vue par Whitson G.
Nous présentons les définitions proposées par Whitson [2] sur la sécurité informatique : Il existe trois aspects majeurs de la sécurité informatique :
a) Théorie (cryptographie et protocoles network).
b) Procédé (engineering de la sécurité de l’ordinateur).
c) Management (techniques qui exigent de maintenir le système en fonctionnement).
2.1.2.1. La Sécurité vue comme Théorie (cryptographie et protocoles de sécurité du réseau) :
Comme dans n'importe quel domaine, certaines parties de la sécurité informatique qui
représentent la théorie de base, sont présentées ci-dessous:
A. Cryptographie: on peut utiliser les clés publiques et privées pour le
chiffrement/déchiffrement des données. Les clés sont également utilisées pour
l'authentification des individus, lorsqu’ils ont l’autorisation d’accéder à un ordinateur via un
réseau (ou peut identifier quelqu'un qui est en cours d'accès), elles créent des signatures
digitales (numériques) utilisées pour signer des documents.
Couche Application
Couche Système
Couche Sécurité
Couche Cryptographique
Modèle de sécurité d’application
SSH, SSL, SHTTP….
Communication sécurisée, Authentification…
Crypt/Decryp, Sign…
Figure 1. La sécurisation des couches d’un système.
6
Chapitre I Sécurité et contrôle d’accès
B. Protocoles de sécurité réseau: il s'agit d’ajouter de la sécurité à des protocoles réseaux
onnus tels que S/MIME qui permet le cryptage de tout ou partie d'un message e-mail, ou de c
fournir des services de sécurité de base, comme Kerberos, qui est un des services
d'authentification général utilisé dans un environnement multi-réseaux de serveurs.
2.1.2.2. La Sécurité vue comme Procédé (Process)
Une grande partie de la sécurité informatique peut être examinée par le procédé de
construction des systèmes de sécurité informatique. Aujourd'hui, la plupart de ceux qui
développent des systèmes de sécurité informatique n’utilisent pas les techniques de
développement de systèmes de génie logiciel (prouvées). Ils utilisent des systèmes de sécurité
informatiques qui sont développés en utilisant une variété de techniques heuristiques intégrées
par des experts en sécurité expérimentés dans les systèmes de sécurité.
Dans ce qui suit, nous proposons trois procédés de développement d’application sécurisée.
A. Le Modèle de Whitson G.
La figure 2 montre une approche proposée par Whinston [2], elle est définie en quatre phases :
7
Chapitre I Sécurité et contrôle d’accès
Analyse
• Phase d’analyse : elle inclut les activités suivantes :
1. Examiner le réseau, annexer (répertorier) les ports ouverts du protocole TCP/UDP et
associer leurs vulnérabilités.
2. Analyser les risques des objets d’information de l’entreprise pour extraire les menaces,
ainsi que les ordres de priorité de leur sensibilité.
• Phase de conception : elle permet de créer une spécification formelle. Les techniques
sont:
1. L’arbre de menace (Ex: Figure 3) qui organise toutes les menaces sous forme d’arbre, ce
modèle utilise les ports logiques pour combiner entre les différentes menaces.
Rappelons que la phase de réalisation de l’arbre de menace inclut 5 étapes:
1. Définir un événement indésirable pour l’étude.
2. Comprendre le système.
3. Construire l’arbre de menace.
4. Évaluer l’arbre de menace.
Conception
Code et Déploiement
Test
Gestion
Exigence
Spécification
Prototype
Modifier Modifie
Modifier
Nouveau système Changer
Figure 2. Procédé d’ingénierie pour la sécurité des ordinateurs.
8
Chapitre I Sécurité et contrôle d’accès
Frein défaillant
Plaquette de frein
Capteur de frein
Contrôleur de frein
Cylindre de frein
Figure 3. Arbre de menace.
2. Les menaces sont modélisées à partir du diagramme UML, à travers le diagramme de
séquence. La séquence d’opérations représente l’exécution de la menace au niveau
modélisation. Wang et al. [3] utilisent cette approche pour tester la sécurité au niveau
implémentation.
• Phase de déploiement et code: dans cette phase l’utilisateur implémente son
application en considérant les phases précédentes.
• Phase de test: une large variété d’analyses, de simulations d’attaques et d’inspections
de registres de fichiers, est effectuée sur le prototype actuel du système de sécurité
informatique. Si des problèmes sur ce prototype sont découverts, alors on retourne à
l’analyse, on modifie les spécifications et la conception, et ensuite on déploie un
nouveau prototype.
9
Chapitre I Sécurité et contrôle d’accès
B. AEGIS (Appropriate and Effective Guidance for Information Security)
Flechais et al. [4] ont proposé la méthode AEGIS: une méthode d’ingénierie utilisée pour la
création de systèmes sécurisés. Basé sur le modèle en spirale (figure 5), AEGIS intègre les
besoins de sécurité dans le processus de développement.
La base de ce modèle est que la décision de sécurité est prise après la définition des besoins
de ressources en sécurité. Les concepteurs de ce modèle ont choisi le modèle UML pour la
modélisation des ressources, des risques, et des contrôles de sécurité (Figure 4).
Le modèle reconnaît trois types de participants : le directeur de projet, les experts en sécurité,
et les acteurs (utilisateurs, propriétaires, développeurs).
Le modèle est constitué de quatre sessions. Dans la première session, les acteurs aident le
directeur de projet à construire le modèle du système, en représentant les objets et leurs
relations. Ce modèle est présenté en UML dans la figure 4. La seconde session se focalise sur
le modèle des objets et les besoins de sécurité (les dépendances entre les objets doivent être
claires). Dans la troisième session, les risques, les menaces et les vulnérabilités sont identifiés.
La quatrième session consiste en la désignation et l’implémentation des différentes contre-
mesures.
10
Chapitre I Sécurité et contrôle d’accès
Opérateur Opérateur Honnête
Opérateur malveillant
Nœud Traitement
Contrôle
Application
Station
Exécute
Ressource
Donnée
Lien de communication
Traite
Transmis
Accès
Mesure de sécurité
Protége
Figure 4. Diagramme des relations entre les ressources du système.
11
Chapitre I Sécurité et contrôle d’accès
C. le Modèle Eric M. : Pour Eric [5], Le processus de sécurité de l’information est un
processus continuel composé de cinq phases: Evaluation, Politique, Implémentation,
Formation, Audit (figure 6).
Ce processus commence avec l’évaluation qui est réalisée pour déterminer la valeur des
ressources d’informations d’une entreprise, l’étendue des vulnérabilités et des menaces, ainsi
que l’importance de l’ensemble des risques pour l’entreprise. Une fois l’évaluation achevée,
on aborde la définition de la politique : cette tâche a pour but de préciser les objectifs de la
sécurité de l’entreprise, ainsi que les tâches à exécuter pour leur mise en œuvre. Ensuite,
l’audit permet de vérifier que les contrôles sont configurés conformément à la politique de
l’entreprise. Cependant, l’audit concerne trois aspects différents: les audits d’adhésion à la
politique, les évaluations périodiques de nouveaux projets, et les tests d’intrusion.
Analyse des risques
Analyse des
risques Révision et test
Commencer Révision et Analyse des Produit test Risques
Révision Finale
Plan Concept Projet Prototype 1
de base Prototype 2
Ajuster Intégration Corriger IuRéunir les besoins dentifier
tilisateur Conception initial Conception et tester conception
finale Plan
Validation des besoins
Code Code
Corriger et valider Test Unités Code Conception
Test de réception Charger
Figure 5. Modèle en spirale AEGIS de développement des applications.
12
Chapitre I Sécurité et contrôle d’accès
Politique Evaluation
Audit Implémentation
Formation
Figue 6. Processus de sécurité de l’information.
2.1.2.3. La Sécurité vue comme une Gestion
Une fois que le système de sécurité informatique a été déployé, il a besoin d’être géré pour
s'assurer qu'il fonctionne correctement. Les domaines majeurs de la gestion informatique
comprennent:
1. La Garantie de la confidentialité, l’intégrité, et la disponibilité de tous les actifs.
2. La Gestion du risque qui utilise l'analyse des risques, les arbres de menaces et d'autres
techniques pour maîtriser les risques des actifs.
3. L'Elaboration de Politiques de Sécurité, Procédures, Normes et Lignes Directrices.
4. La Formation, la Documentation et l'Assistance sécurité pour l'organisation.
5. La Préparation au rétablissement après un sinistre et la mise en œuvre des procédures
d'évitement de catastrophe.
3. Introduction sur les Besoins de Sécurité Les besoins de sécurité ou exigences de sécurité sont représentés ci-dessous tel qu’ils sont
exposés dans différents articles:
3.1. Le Besoin de sécurité comme Fonction de sécurité Dans cette approche, les besoins de sécurité sont considérés comme une sorte de mécanisme
utilisé comme protection externe, par exemple un Firewall, cette vision étant partagée avec le
NIST et ISO.
Néanmoins, cette approche laisse de coté des informations importantes telles que : quel est
l’objet qui nécessite une protection? Et pourquoi ce besoin de protection ?
13
Chapitre I Sécurité et contrôle d’accès
3.2. Le Besoin de sécurité comme besoin Non Fonctionnel : Kotonya [6] définit les besoins de sécurité comme des contraintes et des restrictions des
individus sur les besoins fonctionnels du système. Haley et al. [7] les décrit comme un besoin
pour améliorer la qualité des besoins fonctionnels et enfin, pour Alexandre [8], les besoins de
sécurité concernent essentiellement ce qui ne doit pas se produire.
3.2. A. Les Misuses cases (Cas Non Autorisés) Sindre et Alexandre [8,9] utilisent le diagramme des cas d’utilisation non seulement pour la
description des besoins fonctionnels des systèmes, mais aussi pour décrire les besoins de
sécurité à l’aide des cas non autorisés (misuse cases) et des acteurs non autorisés.
Pour chaque cas d’utilisation, on définit les vulnérabilités et les fonctions qui ne devront pas
être autorisées, ces fonctions représentent les misuse cases. Ces derniers sont liés au cas
d’utilisation par des associations et des dépendances (stéréotypés par: <<threaten>>,
<<Mitigate>>, <<exploit>>, etc.). Pour chaque cas abusif ou ensemble de cas non autorisés,
on détermine les acteurs non autorisés qui initient les cas non autorisés, ces derniers sont
représentés par des ellipses noires avec leurs noms en blanc, les acteurs non autorisés par un
stick man à tête noire, et la vulnérabilité par une ellipse à fond gris, comme le montre la figure
ci-dessous:
Nom cas non-autorisé
Nom Vulnérabilité
Nom de l’acteur non-
autorisé
Figure 7. Légende du cas non autorisé.
3.3. Le Besoin de sécurité comme Propriété de sécurité Les besoins de sécurité sont vus comme des propriétés de sécurité telles que l’intégrité, la
confidentialité, la disponibilité, la non-répudiation, la responsabilité de l’entité pour laquelle
la protection est exigée (ex: les bases de données).
14
Chapitre I Sécurité et contrôle d’accès
3.4. Le Besoin de sécurité comme Négation des Propriétés de sécurité ou de
Fonction du système
Lamsweeder [1] élabore les besoins de sécurité par la construction d’un anti-modèle, ce
dernier formalise les buts de sécurité en premier ordre de la logique linéaire temporelle
épistémique. Chaque but de sécurité se voit attribuer une négation de sa formulation
épistémique, modélisé comme suit.
KnowVag(v) ≡ x: Knowsag (x=v) ∃
Knows ag (P) ≡ Belief ag (P) ^ P.
La sémantique opérationnelle de Belief ag (P) est:
P est parmi les propriétés sauvegardées dans la mémoire locale de l’agent : ag.
Définition formelle des propriétés de sécurité :
1. Pour la confidentialité
Goal Avoid [SensitiveInfoKnowByUnautorised]
Formel Spec Ag:Agent, ob: objetct. ┐Autorized(ag,ob.info) => ┐ KnowVag(ob.info)
2. Pour la confidentialité
Goal Maintain [PrivateInfoKnowOnlyIfAutorizedByOwener ] Formel Spec ag, ag’:Agent, ob: objetct. KnowsVag(ob.info) Λ OwenedBy(ob.info,ag’) Λ ag≠ ag’ => AutorizedBy( ag, ob.info,ag’) 3. Pour l’intégrité
Goal Maintain [ObjectInfoChangeOnlyIfCorrect and autorized]
Formel Spec ag : Agent, ob: objetct, v:Valeur Ob.info ≡ v Λ o (ob.info ≠ v) Λ UnderControl(ob.info) => Autorized( ag, ob.info) Λ o Integrite (ob.info)
4. Pour la disponibilité
Goal Achieve [ObjectInfoUsableWheneNeedAndAutorized ]
Formel Spec ag: Agent, ob: object, v:Valeur
Needs (ag,ob.info) Λ Autorized( ag, ob.info) => <>≤d Using (ag, ob.info)
15
Chapitre I Sécurité et contrôle d’accès
La Négation des définitions formelles
1. Pour la Confidentialité:
KnowVag(ob.info) Λ ┐Autorized(ag,ob.info)
2. Pour la Privacy:
KnowsVag(ob.info) Λ OwenedBy(ob.info,ag’) Λ ag≠ ag’ Λ ┐ AutorizedBy( ag, ob.info,ag’)
3. Pour l’Intégrité:
Ob.info ≡v Λ o (ob.info ≠ v) Λ UnderControl(ob.info) ) Λ ( ┐ Autorized( ag, ob.info) V ┐ o Integrite (ob.info))
4. Pour la Disponibilité:
Needs (ag,ob.info) Λ Autorized( ag, ob.info) Λ ┐ <>≤d Using (ag, ob.info)
• Méthode de Construction des anti-modèles:
1. On cherche les Anti-buts par la spécification des définitions formelles niées.
2. Pour chaque Anti-but, les acteurs sont déterminés par la question : qui peut bénéficier de
cet Anti-but (Who)?
3. Pour chaque Anti-but et son Acteur correspondant, on doit se poser la question pourquoi
cet acteur a-t-il atteint cet anti-but de haut niveau (why)?
4. L’Élaboration du graphe de l’anti-but : on lie les acteurs à leurs Anti-buts correspondants.
5. Dériver les objets et les agents de l’anti-modèle à partir de la spécification des Anti–buts.
6. Opérationnaliser tous les Anti-besoins en terme de capacités potentielles de l’attaquant
malveillant correspondant (écoute, usurpation, déchiffrage, etc.).
4. LE CONTROLE D’ACCES
4.1. Définition du contrôle d’accès
Il est utile de rappeler que l’une des premières mesures en sécurité informatique consiste à
contrôler les différents accès possibles à un système d’information et à autoriser ou non un
certain nombre d’actions en fonction de l’utilisateur.
Il s’agit de limiter l’accès aux ressources du système d’information uniquement aux
utilisateurs, programmes, procédés ou systèmes autorisés.
Le contrôle d’accès est défini comme n’importe quel mécanisme par lequel un système
autorise ou interdit le droit à des entités actives (sujets) d’accéder à des entités passives
(objets), ou d’effectuer des opérations.
16
Chapitre I Sécurité et contrôle d’accès
Il consiste à vérifier si une entité (une personne, un ordinateur, etc.) désireuse d'accéder à une
ressource possède les droits nécessaires pour le faire.
4.2. Les Objectifs du contrôle d’accès: préserver la confidentialité, l’intégrité et la
disponibilité des données.
4.3. La Politique de contrôle d’accès Dans un système informatique, l’autorisation a pour but de ne permettre que les actions
légitimes, c’est-à-dire empêcher qu’un utilisateur puisse exécuter des opérations qui ne lui
sont pas permises. Pour définir quelles sont les opérations autorisées et celles qui sont
interdites, il faut établir une politique de contrôle d’accès. Le standard européen ITSEC
(Information Technology Security Evaluation Criteria) définit une politique de sécurité
comme étant “l’ensemble des lois, règles et pratiques qui régissent 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”.
4.4. Les Concepts de base d’une politique de contrôle d’accès Sujets : entités actives du système
• demandent des droits d’accès correspondant à l’autorisation d’exécuter des actions sur
les objets.
• incluent toujours les utilisateurs du système.
• incluent souvent les processus en cours d’exécution pour le compte des utilisateurs.
Objets : entités passives du système
• contiennent les informations et ressources à protéger.
Actions : moyens permettant aux sujets de manipuler les objets du système.
4.5. Les axes de la politique de contrôle d’accès Une politique de contrôle d’accès peut se développer dans trois directions distinctes: les
politiques de sécurité physique, administrative et logique.
• La politique de contrôle d’accès physique précise un ensemble de procédures et de
moyens qui protègent les locaux et les biens contre les accès physiques aux matériels
informatiques et de communication (gardiens, codes, badges, ...).
17
Chapitre I Sécurité et contrôle d’accès
• La politique de contrôle d’accès administrative définit un ensemble de procédures et
moyens qui traite de tout ce qui ressort de la sécurité, d’un point de vue
organisationnel, au sein de l’entreprise. La structure de l’organigramme ainsi que la
répartition des tâches (séparation des environnements de développement,
d’industrialisation et de production des applicatifs) en font partie. Les propriétés de
sécurité recherchées visent, par exemple, à limiter les cumuls ou les délégations
abusives de pouvoir, ou à garantir une séparation des pouvoirs. Odile PAP
• La politique de contrôle d’accès logique fait référence à la gestion du contrôle d’accès
logique, lequel repose sur un triple service d’identification, d’authentification et
d’autorisation. Elle spécifie qui a le droit d’accéder à quoi, et dans quelles
circonstances. Ainsi, tout utilisateur, avant d’utiliser le système, devra décliner son
identité (identification) et prouver qu’il est bien la personne qu’il prétend être
(authentification). Une fois la relation établie, les actions légitimes que peut acomplir
cet utilisateur sont déterminées par la politique d’autorisation.
4.6. Les Types de contrôle d’accès Plusieurs types ont été proposés pour répondre aux besoins de contrôle d’accès des
applications. Ces types de contrôle d’accès sont généralement classés en trois types: le DAC
(Discretionary Access Control: Contrôle d’Accès Discrétionnaire), le MAC (Mandatory
Access Control: le Contrôle d’Accès Obligatoire) et le RBAC (Role Based Access Control:
Contrôle d’Accès à Base de Rôle).
De nouveaux types tels que le TBAC (Access Contrôle Models for Task and Workflow), en
phase de développement, ont été proposés pour formaliser les exigences de sécurité pour un
large éventail d’applications.
4.6.1. Le MAC : c’est une méthode de gestion des droits des utilisateurs pour l’usage de
systèmes d’information. Le MAC est utilisé lorsque la politique de sécurité des systèmes
d’information impose que les décisions de protection ne doivent pas être prises par le
propriétaire des objets concernés, i.e que les décisions de protection doivent lui être imposées
par le système.
Les sujets et les objets sont classés sur la base des niveaux de sensibilité prédéfinis qui sont
utilisés dans le procédé de décision d’accès.
18
Chapitre I Sécurité et contrôle d’accès
Le contrôle d’accès obligatoire doit permettre d’associer et de gérer des attributs de sécurité
relatifs à cette politique sur les fichiers et processus du système.
- En résumé
Les niveaux de sécurité:
1. U: non classé
2. C: confidentiel
3. S: secret
4. T: top secret
Formant un ordre partiel: U< C < S < T
Qui sont assignés pour chaque :
1. Sujet (CLR)
2. Objet (CLS)
Un sujet ne peut accéder un objet que si sa clearance (autorisation) est supérieure ou égale à la
classe de l’objet.
4.6.2. Le DAC : c’est un genre de contrôle d’accès utilisé comme moyen de limiter l’accès
aux objets, basé sur l’identité des sujets ou des groupes auxquels ils appartiennent. Les sujets
et les objets sont recensés, et les règles d’autorisation d’accès pour chaque sujet et objet sont
spécifiées. Les commandes sont discrétionnaires, car un sujet avec une certaine autorisation
d’accès est capable de transmettre cette permission (peut-être indirectement) à n’importe quel
autre sujet (sauf restriction du contrôle d’accès obligatoire).
- En résumé
• Le système = Objet U Sujet.
• Objet et sujet sont énumérés.
• Autoriser (s, o)= {Ø, Lire, Ecrire, Exécuter}/ s Є Sujet, o Є Objet.
• Représentation:
Une matrice (n, m) tel que n = card (Sujet)
m = card (Objet).
Matrice (i, j) = {Ø, Lire, Ecrire, Exécuter}.
19
Chapitre I Sécurité et contrôle d’accès
4.6.3. Le RBAC : le contrôle d’accès à base de rôle est un type de contrôle d’accès à un
système d’information dans lequel chaque décision d’accès est basée sur le rôle assigné à
l’utilisateur. Un rôle découle généralement de la structure d’une entreprise. Les utilisateurs
exerçant des fonctions similaires peuvent être regroupés sous le même rôle. Un rôle,
déterminé par une autorité centrale, associe à un sujet des autorisations d’accès sur un
ensemble d’objets.
La modification des contrôles d’accès n’est pas nécessaire chaque fois qu’une personne
rejoint ou quitte une organisation. Par cette caractéristique, RBAC est considéré comme un
système « idéal » pour les entreprises dont la fréquence de renouvellement du personnel est
élevée. Ce type de contrôle est également référencé sous le nom de Non-discrimination
Access Control.
4.6.4. Comparaison Nous présentons ci-dessous un résumé sur les caractéristiques-clés des trois types de contrôle
d’accès.
MAC : - Basé sur l’administration;
- Règle le contrôle des flux d’information;
- Haut niveau de sécurité, d’où haute assurance, mais manque de flexibilité.
DAC : - Basé sur la possession, flexible, plus largement utilisé;
- Ne fournit pas un haut niveau de sécurité, d’où faible assurance.
RBAC : - Fournit une politique neutre/flexible;
- Satisfait le principe du moindre privilège;
- Satisfait la contrainte des séparations des devoirs;
- Caractéristiques administratives faibles;
- Capacité d’exprimer DAC, MAC, et les politiques spécifiques d’utilisateur en utilisant la
hiérarchie des rôles et les contraintes;
- Peut être facilement incorporé dans les technologies courantes;
20
Chapitre I Sécurité et contrôle d’accès
- Idéal pour des environnements multi-domaines lorsque les politiques sont exprimées en
utilisant les hiérarchies de rôles et les contraintes.
5. Conclusion Ce chapitre constitue, à partir de récentes publications, un résumé synthétique de l’état de l’art
actuel sur la sécurité de l’information en ce qui concerne :
- Les concepts de sécurité de l’information.
- Les différentes vues sur la sécurité.
- La Représentation d’un support pour le développement de systèmes de sécurité.
- Les différentes définitions sur les besoins de sécurité.
De chaque sujet traité dans ce chapitre, nous nous sommes inspirés d’une partie qui servira à
l’élaboration de notre projet.
Ensuite, nous nous sommes étendus sur le contrôle d’accès en essayant de fournir des
explications complètes et accessibles, et ce afin de mieux aborder le chapitre 2.
21
Chapitre II RBAC et les travaux se rapportant à ce modèle
1. Introduction Le RBAC est supposé fournir une structure viable pour adresser à grande échelle les besoins
de sécurité (contrôle d’accès) pour un très grand nombre d’entreprises. La conception de notre
projet s’est inspirée, à partir de récentes publications, d’une étude exhaustive des différents
travaux effectués au sein du RBAC, que nous avons choisi comme modèle de base, et que
nous exposerons plus particulièrement dans ce chapitre.
Dans ce chapitre nous traitons l’étude du RBAC en trois sections comme suit :
Dans la première section, nous définissons en détail les composants du modèle RBAC.
Dans la deuxième section, nous exposons les travaux les plus récents sur ce modèle.
Dans la troisième section, nous citons d’autres approches que nous avons jugés intéressantes à
proposer, et enfin nous concluons sur les mécanismes d’extension UML pour le RBAC.
2. Le standard RBAC Le standard RBAC a été proposé par le NIST [10] (National Institue of Standard and
Technology) en 2001 et formellement adopté par le standard ANSI en 2004. Il est utilisé pour
protéger les objets d’information (se rapportant désormais comme objets) contre des
utilisateurs non autorisés.
Le standard RBAC est composé de deux parties :
- Le modèle de référence RBAC.
- Les spécifications fonctionnelles administratives du RBAC. 2.1. Le modèle de référence : il définit l’ensemble des éléments de base du RBAC
(utilisateurs-rôles-permissions-opérations-objets) et les relations et fonctions qui sont incluses
dans le standard. Le modèle de référence a deux principaux objectifs :
a) Définir un vocabulaire (langage) commun et cohérent de termes, en spécifiant les
exigences.
b) Fixer le domaine des caractéristiques inclus dans le standard.
2.2. Les spécifications fonctionnelles, administratives et système du RBAC : elles
définissent les caractéristiques exigées du système RBAC. Ces caractéristiques se repartissent
en trois catégories : les opérations administratives, les réexamens administratifs, et la
fonctionnalité au niveau système.
23
Chapitre II RBAC et les travaux se rapportant à ce modèle
a) Les opérations administratives: elles permettent la création et le maintien de l’ensemble
des éléments et des relations pour la construction des différents composants du modèle RBAC
(ex : création et suppression des affectations de rôle à un utilisateur).
b) Le système des fonctions: ce sont les fonctions qui sont exigées, au cours de l'interaction
des utilisateurs avec un système informatique, par le modèle RBAC implémenté (ex : création
des sessions qui inclut l’activation et la désactivation des rôles).
c) Les fonctions réexamens : l’examen des résultats des actions créées par les fonctions
administratives (ex : les requêtes sur les éléments et les relations du modèle RBAC).
3. les composants du RBAC Le modèle de référence RBAC et la spécification fonctionnelle sont organisés en trois
composants qui sont le noyau, la hiérarchie et les contraintes.
3.1. Le noyau du RBAC
Le noyau du RBAC (Figure 1) englobe les aspects essentiels du RBAC. Le concept de base
du RBAC est que des rôles sont assignés à des utilisateurs, les permissions sont assignées à
des rôles, et les utilisateurs acquièrent des permissions en étant membres des rôles.
Le noyau du RBAC inclut la condition que l’affectation utilisateur-rôle et permission-rôle
peut être many to many (n à n). Ainsi, le même utilisateur peut se voir assigner plusieurs rôles
et un rôle peut être attribué à plusieurs utilisateurs. De même, pour les permissions, une seule
permission peut être assignée à plusieurs rôles, et un seul rôle peut être assigné à plusieurs
permissions.
Le noyau du RBAC inclut aussi le concept de session d’utilisateur qui permet l’activation et
désactivation sélective de rôles.
Finalement, le noyau du RBAC permet que les utilisateurs soient capables d’exercer
simultanément les permissions de multiples rôles.
24
Chapitre II RBAC et les travaux se rapportant à ce modèle
Formellement
— Les ensembles UTLISATEUR, ROLES, OPS, et OBS représentent les utilisateurs, rôles,
opérations, et objets, respectivement.
—UA ⊂ UTLISATEUR x ROLES, mappe les utilisateurs à des rôles (plusieurs à plusieurs) —Utilisateur_affecté (r : ROLES): le mappage du rôle r sur un ensemble d’utilisateurs.
Formellement: Utilisateur_affecté (r) = {u Є UTILISATEUR / (u, r) Є UA}.
—PRMS : (OPS, OBS), un ensemble de permissions.
—PA ⊂ PRMS x ROLES, relation de mappage des permissions sur les rôles, relation
plusieurs à plusieurs
—Permission_affecté(r : ROLES) : mappe un rôle sur un ensemble de permissions.
Formellement : Permission_affectée (r) = {p Є PRMS / (p, r) Є PA}.
—Ob (p: PRMS) → {op ⊂ OPS}, mappage permission opérations, qui donne l’ensemble des
opérations lié a une permission p.
—Ob (p: PRMS) → {ob ⊂ OBS}, mappage permission objet, qui donne l’ensemble des objets
liés à une permission p.
— SESSIONS, l’ensemble de sessions.
—Utilisateur_Sessions (u: UTLISATEUR) : mappage de l’utilisateur sur un ensemble de
sessions.
—Session_Roles (s: SESSIONS) : mappage de la session s sur un ensemble de rôles.
Formellement : session- rôles (si) = {r Є ROLES / (session_ utilisateur (si), r) Є UA}.
—Avail_Session_Perms(s:SESSIONS) : les permissions disponibles pour utilisateur dans une session, Formellement : Avail_Session_Perms(s) = U Permission_ affecté (r). r Є session_ rôles (s)
User Rôles
(UA) User (PA) Permission Assignement
Assignement OPS OBS
Permission Session Rôles User Session
Session
Figure 1. Le noyau RBAC.
25
Chapitre II RBAC et les travaux se rapportant à ce modèle
3.2. RBAC hiérarchique Elle ajoute l’exigence hiérarchique entre les rôles au support du modèle standard comme le
montre la figure 2.
Figure 2. La Hiérarchie RBAC.
La hiérarchie est mathématiquement un ordre partiel définissant la relation de supériorité
entre les rôles, par laquelle les rôles supérieurs obtiennent les permissions des rôles juniors, et
les rôles juniors obtiennent une adhésion des utilisateurs supérieurs. Ce critère reconnaît deux
types d’hiérarchies de rôles.
3.2.1. Le RBAC hiérarchique général
Le RBAC hiérarchique général permet de supporter le concept de hiérarchie multiple, qui
fournit la capacité d’héritage des permissions de deux rôles ou plus.
Formellement
RH: ROLES x ROLES
Soit l’ordre partiel ≥ tel que r1 ≥ r2:
[auth_permis (r2) ⊂ auth_permis (r1)]
[auth_user (r1) ⊂ auth_user (r2)]
Tel que:
auth_user (r) = {u Є UTLISATEUR / r’ >r, (u, r’) Є UA}
auth_permis (r) = {p Є PRMS / r’ >r, (p, r’) Є PA}
User Rôles
Session
OPS OBS
Permission
(UA) User Assignement
User Session
Session Rôles
(PA) Permission Assignement
Rôle Hiérarchie (RH)
26
Chapitre II RBAC et les travaux se rapportant à ce modèle
_ La représentation graphique des hiérarchies de rôles se fait par des structures comme le
montrent les figures ci-dessous :
Ingénieur 1 Ingénieur 1 Ingénieur 2 Production
Ingénieur 2 Production Qualité Qualité
Ingénieur 1 Ingénieur 2
Département Ingénieur
Figure 3.a. Arbre Inversé
Directeur
Chef _ projet 1 Chef _ projet 2
Ingénieur 1 Ingénieur 1 Ingénieur 2 Ingénieur 2 Production Qualité Production Qualité
Figure 3.b. Arbre.
27
Chapitre II RBAC et les travaux se rapportant à ce modèle
Directeur
Chef _ projet 1 Chef _ projet 2
Ingénieur 1 Ingénieur 1 Ingénieur 2 Ingénieur 2 Production Qualité Production Qualité
Ingénieur 1 Ingénieur 2
Département Ingénieur
Figure 3.c. Treillis.
Figure 3. Représentation graphique des hiérarchies de rôles.
3.2.2 Le RBAC hiérarchique restreint
Les systèmes peuvent imposer des restrictions sur la hiérarchie de rôles. Plus
communément, les hiérarchies sont limitées par de simples structures telles que arbres ou
arbres inversés.
Formellement r, r1,r2 Є ROLES, r ≥ r1 Λ r ≥ r2 => r1=r2.
3.3. Les contraintes RBAC.
Les contraintes constituent un aspect important du RBAC, et sont parfois la raison principale
d’utilisation du RBAC comme moyen d’analyser le contrôle d’accès. Les exemples communs
des contraintes du RBAC englobent la séparation statique du devoir, la séparation dynamique
du devoir et à cela, récemment, on a ajouté les contraintes pré-requis et les contraintes de
cardinalité, qui sont introduites dans [11].
28
Chapitre II RBAC et les travaux se rapportant à ce modèle
3.3.1. La Séparation statique des devoirs (SSD)
La contrainte de séparation statique des devoirs (SSD, en anglais SSD) vise à empêcher le
conflit d’intérêts qui apparaît lorsque des rôles en conflit sont associés à un même utilisateur
(les rôles qui ne peuvent pas être attribués à un même utilisateur).
Le conflit d’intérêts dans un rôle peut surgir comme le résultat d’un utilisateur obtenant une
autorisation pour des permissions liées avec les rôles en conflit. Un moyen de prévenir cette
forme de conflit d’intérêt est la séparation statique des devoirs (SSD).
SSD (RH)
Les contraintes de rôle SSD peuvent exister en absence ou en présence de hiérarchie des rôles
Les contraintes SSD sont définies par deux arguments: un ensemble de rôles rs qui comprend
deux rôles ou plus, et un nombre naturel n appelé la cardinalité avec la propriété de 2 ≤ n ≤
|rs| qui signifie qu’à un utilisateur peut être assigné moins que n rôles d’un ensemble de rôles
rs. Du point de vue politique, les relations SSD offrent un moyen puissant de faire respecter
les conflits d'intérêts et d'autres règles de séparation sur des ensembles d'éléments RBAC.
- Formellement
Formellement la séparation statique de devoirs peut être définie en absence et en présence de
hiérarchie.
a. Absence de hiérarchie
(rs ,n) Є SSD , t ⊂ rs : | t | ≥ n => ∩ Utilisateur_affecté (r) = Ø. r Є t
User Rôles
Rôle hiérarchie
(PA) permission(UA) User
Session
OPS assignement assignement OBS
Permission Session Rôles User
Session
Figure 4. SSD.
29
Chapitre II RBAC et les travaux se rapportant à ce modèle
b. Présence de hiérarchie :
| ≥ n => ∩ auth_user (r) = Ø.
la définition des entités mutuellement exclusives.
raintes SSD sont violées lorsqu’on affecte à un utilisateur un ensemble de rôles
ns des rôles aux
.3.2 La Séparation dynamique des relations des devoirs (DSD)
relations SSD, limite les
me une
(rs, n) Є SSD , t ⊂ rs : | t r Є t D’autre part, le SSD peut être utilisé pour
Pour cela, les contraintes SSD sont spécifiées pour n’importe quelle paire de rôles qui sont en
conflit.
Les cont
incluant une paire en SSD, ou lorsqu’un rôle hérite de deux rôles en SSD.
La séparation statique des devoirs place les contraintes sur les affectatio
utilisateurs. L'adhésion à un rôle peut empêcher l'utilisateur d'être membre d'un ou de
plusieurs autres rôles, en fonction des rôles SSD appliqués.
3
La séparation dynamique des relations du devoir (DSD), comme les
permissions qui sont disponibles pour un utilisateur. Toutefois, les relations DSD diffèrent des
relations SSD par le contexte dans lequel ces restrictions leurs sont imposées. Les exigences
DSD limitent la disponibilité des permissions en imposant des restrictions sur les rôles qui
peuvent être activés à l'intérieur d’une session ou entre deux sessions d'un utilisateur.
Les relations DSD, de même que les relations SSD, définissent les contraintes com
paire (ensemble de rôles, n) où n est un entier naturel ≥ 2, avec la propriété qu’aucune session
ne permet à l'utilisateur d'activer plus de rôles qu'il ne lui a été fixé.
User Rôles
Session
OPS OBS
Permission
(UA) User assignement
Session Rôles
(PA) permission Assignement
(RH) Rôle hiérarchie
SSD
DSD
Figure 5. DSD.
30
Chapitre II RBAC et les travaux se rapportant à ce modèle
Les propriétés DSD fournissent un support étendu (par rapport au temps) au principe du
oindre privilège dans leque r possède, à des moments différents, des
SD permet à un utilisateur d’être autorisé pour des rôles qui
m l chaque utilisateu
permissions spécifiques en fonction de la tâche exécutée.
Cela garantit que les permissions ne se prolongent pas au-delà du temps requis pour
l'exécution de leurs fonctions.
SSD fournit la possibilité de régler les conflits potentiels d’intérêt, au moment où un rôle est
assigné à un utilisateur. Le D
n’entraînent pas de conflit d’intérêts, mais qui produisent des violations de la politique quand
ils sont activés en même temps.
- Formellement
DSD est une collection de paires (rs, n) ou rs est un ensemble de rôle, n un nombre naturel tel
la propriété qu’aucun utilisateur ne peut activer n ou plus de rôles de
ES, n Є N, (rs,n) Є DSD, Sous_Role ⊂ rs,
a notion de rôles pré-requis est fondée sur la compétence et la pertinence. Les contraintes
e assigner un rôle à un utilisateur uniquement dans le
lle permet de limiter le nombre de création des éléments du modèle RBAC
.1 AuthUML : Alghathbar [12,13] présente un modèle formel utilisé pour analyser les
écification du modèle UML de l’application.
il
que n ≥ 2, avec
l’ensemble rs dans une dsd Є DSD.
rs ⊂ ROLES ,n Є N, (rs,n) Є DSD => n ≥ 2 Λ | rs | ≥ n, et s Є SESSION ,
rs Є ROLES, Sous_Role ⊂ ROL
Sous_Role ⊂ session- rôles (s) => | Sous_Role | < n.
3.3.3. Les Contraintes de pré-requis
L
pré-requises nécessitent qu’on ne puiss
cas où un rôle pré-requis lui a précédemment été affecté.
3.3.4. La contrainte de Cardinalité
E
4. Les travaux sur le modèle RBAC 4
besoins de contrôle d’accès dans la phase de sp
Ce modèle propose des prédicats dont l’instanciation de leurs variables dérive des
diagrammes de cas d’utilisation et de schémas d’opérations (un modèle proposé par [14]) :
permet de vérifier la consistance, la complétude et l’absence de conflit d’intérêts.
L’architecture générale de ce modèle (figure 6) est composée de quatre phases, chaque phase
étant constituée de plusieurs étapes :
31
Chapitre II RBAC et les travaux se rapportant à ce modèle
La première phase est la reformulation des besoins de contrôle d’accès sous forme
d’instanciation de variables de prédicats (proposée par AuthUML) : cette phase permet
d’unifier la forme d’écriture, ainsi que la vérification de la consistance et de l’absence de
conflit des besoins de contrôle d’accès. Dans la deuxième phase, les accès (formulés dans la
première phase) sont propagés aux hiérarchies d’acteurs et aux cas d’utilisation, et toute
inconsistance est résolue par les règles de résolution de conflit. Après ces deux phases, tous
les accès sont consistants, mais reste le problème de la complétude, qui est résolu par la prise
de décision, qui attribue des autorisations soit à une politique fermée, soit à une politique
ouverte.
Politique fermée : pas de permission d’accès, pas d’accès.
Politique ouverte : pas d’interdiction d’accès, l’accès est permis.
ort aux besoins de sécurité. La
ème phase, mais n’a pas de
, mais intervient à tous les niveaux précédents. Elle permet de contrôler les
Après cette étape, la consistance est revérifiée par rapp
troisième phase applique le même procédé que celui de la deuxi
prise de décision parce que les cas d’utilisation propagent leurs accès à toutes leurs
opérations.
La quatrième phase est différente des autres phases, celle-ci n’est pas exécutée d’une manière
séquentielle
séparations des devoirs au niveau des besoins, l’attribution des rôles aux utilisateurs, et
l’exécution des opérations.
32
Chapitre II RBAC et les travaux se rapportant à ce modèle
Niveau Opération
Validation des SoD
Correction des Niveau cas d’utilisation
Phase 1 Besoins
autorisations Phase 2 Phase 3 Phase 4
Réception Autorisation
contrainte
Représentation Autorisation
contrainte
Assurer consistance
et non conflit
Propagation
Résolution D’inconsistance
Prise de décision
Valider Consistance Propager
les accès au Opération
Résolution de l’inconsistant
Assurer les accès sans
conflit
Valider SOD durant les besoins
Valider SOD durant affect User-Role
Valider SOD exécution User-Role
Valider SOD durant
l’exécution des opération
Fixer les besoins
d’autorisations
Figure 6. Architecture AuthUML.
33
Chapitre II RBAC et les travaux se rapportant à ce modèle
4.2 SecureUML: dans ce modèle, Basin et al. [15,16] ont commencé par définir un modèle de
sécurité, c’est une extension de RBAC modélisée en UML. Pour définir un langage en UML,
une approche a été adoptée, en utilisant directement des MOF (Meta-Object Facility). Ces
derniers se focalisent directement sur le problème ainsi que sur ses domaines sans aucune
dépendance de UML (sémantiquement). Le résultat est un langage qui définit des domaines
spécifiques par un vocabulaire qui est plus concis que le vocabulaire utilisé par le langage à
base d’UML.
SecureUML définit une syntaxe abstraite (figure 7) de type : USER, ROLES, PERMISSION,
et les relations UserAssignement, PermissionAssignement et RoleHierarchique qui sont tirés
directement du modèle RBAC standard, à cela s’ajoute AutorisationContrainte qui est un
prédicat logique rattaché à Permission par l’association ContrainteAssignement ; le type
Ressource et Action correspondent à Operation et Object dans le modèle RBAC, ils servent de
base à l’interaction entre le modèle d’application et SecureUML.
Une ressource est une classe de base qui représente tous les éléments du langage de
modélisation du système que l’on veut protéger. Chaque ressource offre une ou plusieurs
actions et chaque action appartient à une seule ressource, qui est modélisée par l’agrégation
RessourceAction.
Role Permission
Ressource
Action
CompositeAction AtomicAction AuthorisationContraint Subject
User Groupe
RoleHiearchie
1 0..*
RessourceAction 0..* 0..* 1..* 0..* 1..* 0..*
PermissionAssignement ActionAssignement 0..*
0..* 0..* SubjectAssignement ContraintAssignement
0..* 0..* 0..1
Figure 7. Meta-Modèle SecureUML.
34
Chapitre II RBAC et les travaux se rapportant à ce modèle
On différencie entre deux catégories d’actions, qui sont formalisées en deux sous-types
d’Actions : AtomicAction et CompositeAction.
AtomicAction est une action de bas niveau qui peut être transformée directement dans une
action sur une plateforme cible tandis qu’à l’opposé, CompositeAction est une action de haut
niveau qui ne peut pas être mappée directement sur une plateforme cible.
a) L’utilisation
SecureUML laisse ouverte la nature de la ressource à protéger. Le schéma général de la
combinaison du modèle de sécurité avec le modèle de conception se fait à travers un dialecte
(figure 8), ce dernier identifie des primitives du langage de modélisation comme des
ressources à protéger.
La figure 8 nous indique que :
1) Le langage de modélisation de sécurité exprime les politiques de sécurité.
2) Le langage de modélisation de la conception du système traduit la construction du
modèle de conception.
3) Le dialecte fournit une passerelle à partir de la définition des points d’interaction entre
les deux modèles. Les éléments du modèle (2) sont classés comme ressources à
protéger.
b) Sémantique
SecureUML formalise la décision de contrôle d’accès qui dépend de deux types d’information
1) La décision de contrôle d’accès déclarative : elle dépend de l’information statique qui
est l’affectation d’un rôle à un utilisateur ou une permission.
SecureUML
Langage Privacy De modélisation sécurité
Dialecte
Langage de modélisation du système
Diagramme de classe
Etat transition
Figure 8. Schéma d’un langage de conception de sécurité.
35
Chapitre II RBAC et les travaux se rapportant à ce modèle
2) La décision de contrôle d’accès par programmation: elle dépend de l’information
dynamique, qui est la satisfaction des contraintes d’autorisation dans l’état actuel du
système.
4.3 Le modele Ahn et Hong : Ahn et Hong [17] présentent un AMF (Assurance
Management Framework) empirique considéré comme un nouveau MDD (Modele Driven
Development). Ce dernier transforme un modèle de conception formel de haut niveau en un
système exécutable. Cette approche repose sur l’utilisation du RBAC tel que défini dans le
NIST, et dans le langage RCL2000. Ce dernier langage est utilisé pour les spécifications
formelles des contraintes RBAC (figure 9).
Représentation du modèle Spécification des contraintes
Cette approche est constituée de quatre phases :
4.3.1. Représentation du modèle :
Les concepteurs ont représenté les éléments du RBAC sous forme de diagramme de classes
(figure 10), puis ils l’ont enrichi par six nouveaux éléments, pour résoudre le problème de
Modèle RBAC Contrainte RCL
Diagramme UML
Les contraintes OCL
Modèle / Contrainte de sécurité Formel
Représente Translater Détection / résolution conflit
Valider
Orienté système Modèle / contrainte de sécurité
Génération
Code Renforcé
Figure 9. Réalisation du modèle RBAC et des contraintes d’autorisation dans le AMF.
36
Chapitre II RBAC et les travaux se rapportant à ce modèle
conflits, SCR (static conflicting Role) et DCR (Dynamic conflicting Role) pour les SSD et
DSD ; puis SCP, DCP, SCU, DCU pour les conflits de permissions et d’utilisateurs.
SCP SCR SCU SetName : String SetName : String SetName : String PermSet : Set (Perm) RoleSet : Set (Role) UserSet : Set (User) SetCard: Integer SetCard: Integer SetCard: Integer AddPerm-SCP(p: Perm) AddRole-SCR(r :Role) AddUser-SCU(u:User) DeletePerm-SCP(p: Perm) DeleteRole-SCR(r :Role) DeleteUser-SCU(u:User) SetSCP-card(n ;intger) SetSCR-card(n ;intger) SetSCU-card(n ;intger)
4.3.2. Spécification des contraintes
Une fois que le modèle de représentation (en UML) du modèle RBAC à été déterminé, la
deuxième étape est de transformer un programme écrit en RCL2000 avec des expressions
écrites en OCL.
DCU SCP-Perm () :Set(Perm) SCR-Role() :Set(Role) SCUuser() :Set(User) SCP-Card() :integer SCR-Card() :integer SCU-Card() :integer SetName : String UserSet : Set (User) SetCard: Integer AddUser-DCU(u:User) DeleteUser-DCU(u:User) SetDCU-card(n ;intger) DCUuser() :Set(User) DCU-Card() :integer
DCP SetName : String PermSet : Set (Perm) SetCard: Integer AddPerm-DCP(p: Perm) DeletePerm-DCP(p: Perm) SetDCP-card(n ;intger) DCP-Perm () :Set(Perm) DCP-Card() :integer
User Name :String CreatSession () :Session DeletSession (Session) UserSession () :Set (Session) AssignedRole :SetRole() UserPermission():set(Permission) AutorisedRole() :set(Role) AutorisedPermission() :Set(Perm) CheckStaticContrainte() :Booleen CheckDynamicContrainte() :Booleen
Session Name :String AddActiveRole(r :Role) DropActiveRole(r :Role) SessionRole:Set(Role) SessionPermission:Set(Permission) AutorisedRole() :set(Role) AutorisedPermission() :Set(Perm) CheckAccess (op:operation,ob,objerct):bool CheckDynamicContrainte() :Booleen
Role Name :String AssignUser(u :user) DeassignUser(u :user) grantPermission(p :permission) revokPermission(p :permission) AssignedUser() :Set(u :user) RolePermission():Set(Permission) AutorisedUser() :Set(User) AutorisedPermission() :Set(Perm) AddSenior (r :Role) AddJunior (r :Role) DeleteSenior(r :Role) DeleteJunior (r :Role) All Senior(): Set (r :Role) AllJunior(): Set (r :Role) CheckStaticContrainte() :Booleen
Permission Name :String PermissionRole() :Set(Role) PermissionUser():Set(User) AutorisedUser() :Set(User) AutorisedPermission() :Set(Perm) CheckStaticContrainte() :Booleen
Operation Name : String
Objet Name : String
User
Session
Etablir
1
*
Session *
* role
Assigné
* *
User
role
* *
Assigné
Active
Operate
1..* 1..*
à à *
*
*
*
DCR SetName : String RoleSet : Set (Role) SetCard: Integer AddRole-DCR(r :Role) DeleteRole-DCR(r :Role) SetDCR-card(n ;intger) DCR-Role() :Set(Role) DCR-Card() :integer
Figure 10. Modèle RBAC représenté en diagramme de classes UML.
37
Chapitre II RBAC et les travaux se rapportant à ce modèle
4.3.3. Validation de la politique et du modèle
La figure 11 représente une méthodologie d’analyse, elle s’appuie sur deux principaux
éléments : les états du système représentés par le diagramme d’objets, et les contraintes du
RBAC.
Modèle RBAC (Diagramme Classe UML)
Etat du systeme (diagrammed’Objet UML)
4.3.4. Génération du Code
Le code généré pour cette approche est le code JAVA. Il permet à l’utilisateur de construire
une application réelle par la création d’une plateforme dépendante du code source à travers la
plateforme indépendante du code. Ainsi, les éléments du modèle UML, classe, attribut,
opération, association sont mappés directement en java avec leurs correspondants, classe,
attribut, opération. De plus, les types basiques de OCL sont mappés directement sur leurs
correspondants en JAVA. L’ensemble des types utilisés par OCL est implémenté sous forme
de librairie, en utilisant la fonction list ou set du langage JAVA. Cependant, les auteurs ont
implémenté deux fonctions du système qui sont : CheckStaticConstraints et
CheckDynamicConstraints pour les contraintes statiques et dynamiques.
4.4. Le modèle de Gut et mark: Gut et mark [18] proposent une méthode pour spécifier le
modèle RBAC à partir du modèle de scénario, l’idée étant de passer par des catalogues qui
servent d’intermédiaires pour ce passage comme le montre la figure12. Ainsi, les auteurs
proposent-ils une méthode d’ingénierie des rôles à partir des scénarios, ce procédé étant divisé
Instanciation d’une collection de conflit (UML Objet)
Instanciation
Contrainte RBAC (RCL/OCL)
Les paramètres RBAC Paramètres
Paramètres
Analyse Validation des règles
Evolue
Figure 11. Validation du modèle RBAC et les contraintes.
38
Chapitre II RBAC et les travaux se rapportant à ce modèle
en sept étapes comme le montre la figure 13, chaque étape étant une suite d’activités qui
déterminent des éléments ou des relations du modèle RBAC,
4.4.1. Identification et modèle d’un nouveau scénario : cette étape est définie selon les
activités suivantes : les utilisations du système sont déterminées et modélisées en scénarios
comme le montre la figure 14.
Scénario Modèle Catalogue Permission Perm_1= {opération,Object} Perm_2= {opération,Object} ………………. Perm_3= {opération,Object}
Catalogue Contrainte Perm_3 <exclud> Perm_9 Perm_2<exclud> Perm_1 …………. Max_card (Perm_n)=4
Travail Profile_1= {task_2… task_8} Profile_2= {task_1… task_5} ………….. Profile_n= {task_x ... task_y}
Définition des taches Task_1= scenario1 (s1, s2) Task_2= scenario1 (s6) ………….. Task n= scenario1 (s1, s2)
Modèle RBAC
Utiliser pour la définition
Dériver de
Réfère à
Dériver de Création en ce conformant à Composé de
Utiliser pour la définition
Consiste en Utiliser pour la définition
Figure 12. Modèle Interrelationnel.
Identification et modèle d’un nouveau scénario
Dériver les permissions des scénarios
Raffiner nouveau modèle
Identification et modèle d’un nouveau scénario
Définir les taches Les profils de travail
Définir Rôle hiérarchie Définir Modèle RBAC
1 2 3 4
7 6 5
Figure 13. Vue de haut niveau sur le procédé de l’ingénierie des rôles.
39
Chapitre II RBAC et les travaux se rapportant à ce modèle
Identification d’uneutilisation du système
4.4.2. Dérivation des permissions : pour chaque scénario, les opérations d’accès
correspondant à leur exécution sont déterminées et sauvegardées dans un catalogue de
permissions comme le montre la figure 15.
.
4.4.3. Identification des contraintes : les contraintes identifiées telles que : séparation des
devoirs, dépendance au temps, sont enregistrées dans le catalogue des contraintes comme le
montre la figure 16.
Mettre scénario
Attribuer un Nom
Figure 14. Processus de modélisation du procédé.
Choisir un scénario
Identification les opérations d’accès
Sauvegarde <opération, objet>
Figure 15. Processus de dérivation d’une permission.
40
Chapitre II RBAC et les travaux se rapportant à ce modèle
Choisir permissioncatalogue
Définir mutuel exclusif permissions
Définir les contraintes SSD
Figure 16. Processus définition des contraintes. 4.4.4. Affiner le modèle de scénario : cette activité analyse les scénarios et détecte s’il existe
des similitudes ou des généralisations à définir comme le montre la figure 17.
.
Choisir un modèle
Trouver les similitudes entre scénario
Enregistrer nouveau scénario
Figure 17. Raffinement du modèle de scénario. 4.4.5. Définir les taches : des scénarios différents sont utilisés pour définir les tâches. Les
taches sont utilisées pour identifier un travail, tout en se conformant au catalogue des
contraintes comme le montre la figure 18.
.
41
Chapitre II RBAC et les travaux se rapportant à ce modèle
Choisir un scénario, catalogue de permission, catalogue de contrainte
Associé un scénario a une tache
Associé une tache à un Travail
Figure 18. Définition d’une tache et travail. 4.4.6. Dérivation de la hiérarchie des rôles : les travaux obtenus et le catalogue des
permissions sont utilisés pour la création semi-automatique de la hiérarchie des rôles, comme
le montre la figure 19.
Choisir un travail et catalogue de permission
Choisir un travail et catalogue de permission
Identifier les rôles redondent
Identifier rôle junior
Définir une relation d’héritage
Supprimer la permission redondante
Figure 19. Dérivation hiérarchie des rôles. 4.4.7. Définir le Modèle RBAC : la hiérarchie des rôles, le catalogue des permissions et le
catalogue de contraintes servent comme entrée pour la définition du modèle RBAC comme le
montre la figure 20.
.
42
Chapitre II RBAC et les travaux se rapportant à ce modèle
Choisir rôle hiérarchie et catalogue de
contraintes
4.5. Le modèle de Thuong et al.: Thuong et al. [19] proposent MAC and UML for Secure
Software Design. Ce modèle permet d’analyser la sécurité dans une application modélisée en
UML. Elle se fait par l’intégration du MAC dans UML. Cependant, les auteurs de ce modèle
ont choisi trois diagrammes du modèle UML, qui sont les diagrammes de cas d’utilisation, de
séquence et de classes. Cette intégration se fait par l’attribution, à chaque élément du
diagramme de UML, d’une classification ou clearance. L’analyse se fera par la comparaison
des valeurs de leur niveau de sécurité à l’aide d’un algorithme.
Apres la définition du modèle UML (les trois diagrammes), toutes les entités (des trois
diagrammes) sont considérées comme objet ou sujet. Les concepteurs de ce modèle
considèrent les acteurs comme des sujets à qui on attribue une clearance, les autres éléments
comme objets auxquels on attribue une classification selon les règles suivantes (nous avons
choisi uniquement la partie concernant le diagramme des cas d’utilisation):
Acteur Acm, et cas d’utilisation Cui, Acm est sûrement associé avec Cui Acm.CLR ≥
Cui.CLS
Aci, Acj et Acj hérite de Aci Aci.CLR > Acj.CLR
Uci, Ucj et Ucj hérite de Uci Ucj.CLS > Uci.CLS
Uci, Ucj et Uci inclut Ucj Uci.CLS > Ucj.CLS
Uci, Ucj et Ucj étend Uci Uci.CLS > Ucj.CLS
4.6. Le modèle de P.Marsical et al. : P.Marsical et al. [20] suggèrent une approche orientée-
aspect pour la modélisation de la politique de contrôle d’accès. Ce modèle propose une
Supprimer rôles redondants
Identifier et définir les contraintes de Rôle
Fusionner rôles redondants
Insérer un nouveau rôle dans les rôles hiérarchie
Figure 20. Définition du modèle RBAC.
43
Chapitre II RBAC et les travaux se rapportant à ce modèle
extension du langage UML en définissant (figure 21) les diagrammes de sécurité et les
propriétés de sécurité.
Les diagrammes de sécurité fournissent une représentation des propriétés de sécurité comme
aspect séparé de la conception de l’application, et les propriétés de sécurité représentent des
éléments spécifiques des modèles de contrôle d’accès.
Diagramme d’utilisateur Diagramme partie rôle
Permission positive (pp)
Permission négative (pp)
Sous système d’infrastructure sécurisé
Permission positive (pp)
Permission négative (pp)
User-Role Affect (URA)
Séparation des devoirs
Propriété MAC
Simple sécurité
Intégrité Simple
Assignement utilisateur délégué
Autorité de délégation
Lire Stricte
Répercutions sur autorité
S.C S.C
S.C S.C
Composition
Diagramme de délégation
UML
Ecrire Stricte
Conception principale + aspect de sécurité
Meta modèle : UML+ caractéristique de sécurité sélectionné
Figure 21. Architecture générale du modèle de Marsical et all.
44
Chapitre II RBAC et les travaux se rapportant à ce modèle
4.7. Le modèle de Indrakshi et all [11] : les auteurs de cet article ont modélisé les éléments
du modèle RBAC avec le diagramme de classes template (voir figure 22), et les contraintes
par le diagramme d’objets associé au diagramme de classes template. Les contraintes sont
spécifiées comme des associations (SSD, DSD) ou des dépendances (pré-requises) ;
Ainsi, les contraintes du modèle RBAC sont visualisées à l’aide du diagramme d’objets
comme suit :
| Role Name :String AssignUser(u :user) DeassignUser(u :user) grantPermission(p :permission) revokPermission(p :permission) AssignedUser() :Set(u :user) RolePermission():Set(Permission) AutorisedUser() :Set(User) AutorisedPermission() :Set(Perm) AddSenior (r :Role) AddJunior (r :Role) DeleteSenior(r :Role) DeleteJunior (r :Role) All Senior(): Set (r :Role) AllJunior(): Set (r :Role) CheckStaticContrainte() :Booleen
|User Name :String CreatSession () :Session DeletSession (Session) UserSession () :Set (Session) AssignedRole :SetRole() UserPermission():set(Permission) AutorisedRole() :set(Role) AutorisedPermission() :Set(Perm) CheckStaticContrainte() :Booleen CheckDynamicContrainte() :Booleen
|Session Name :String AddActiveRole(r :Role) DropActiveRole(r :Role) SessionRole:Set(Role) SessionPermission:Set(Permission) AutorisedRole() :set(Role) AutorisedPermission() :Set(Perm) CheckAccess (op:operation,ob,objerct):bool CheckDynamicContrainte() :Booleen
|Permission Name :String PermissionRole() :Set(Role) PermissionUser():Set(User) AutorisedUser() :Set(User) AutorisedPermission() :Set(Perm) CheckStaticContrainte() :Booleen
|Opération Name : String
|Objet Name : String
SessionRole Usersession
userAffect PermAffect
permObjet PermOperation
SSD DSD RôleHiérarchie
Figure 22. Diagramme de classes template RBAC.
45
Chapitre II RBAC et les travaux se rapportant à ce modèle
4.7.1 Violation des SSD
ActeurHierachie u :User a1 : Rôle a2 : Rôle
SSD Rôle Assigned(user) Assigned(user)
a1: Role a2: Rôle SSD Rôle
a: Rôle a2 : Rôle
RôleHiérarchie SessionRole SessionRole RôleHiérarchie
a1 : Rôle a2 : Rôle P : permission P : permission SSD Rôle DSD Rôle
Figure 23. Utilisation du diagramme d’objets template pour visualiser la violation des SSD.
4.7.2 Violation des DSD
s: session
SessionRole SessionRole
a1 : Rôle a2 : Rôle DSD Rôle
Figure 24. Utilisation du diagramme d’objets template pour montrer la violation des DSD. 4.7.3 Violation des Pré-requis
u : User r1 : Rôle
a2 : Rôle a2 : Rôle PrerequisitRole P : permission P : permission
Prerequisit_Permission
Figure 25. Utilisation du diagramme d’objets template pour montrer la violation des pré-requis.
46
Chapitre II RBAC et les travaux se rapportant à ce modèle
5. Autres travaux 5.1. Fernandaz [21] fournit une méthodologie pour le développement des systèmes sécurisés
en utilisant les patterns, l’idée principale de cette approche est que les principes de sécurité
doivent être vérifiés à travers toutes les phases de développement du logiciel (collecte des
besoins, analyse, conception et implémentation) à la fin de chaque phase.
5.2. Vivas et al. [22] proposent une approche pour le développement des systèmes orientés-
entreprise où les besoins de sécurité sont intégrés dans le modèle du business, les besoins de
sécurité sont fixés à l’intérieur de la représentation fonctionnelle du système utilisant les
diagrammes UML, ensuite les spécifications UML sont transformées en représentations XMI
qui permettent le traitement automatique de la spécification et, finalement, la spécification
résultante est traduite dans une notation formelle pour le contrôle de la consistance, de la
vérification et de la validation.
5.3. Doan et al [23] incorporent RBAC, MAC et le temps de vie dans UML pour la
conception des applications sensibles au temps, le principe de cette approche est que le
processus de conception et d’intégration de la sécurité ne capte pas seulement l'état de
conception en cours, mais permet un suivi de tout le processus d’évolution de conception, via
la création et le maintien d'un ensemble d'instances de conception dans le temps.
5.4. UMLsec [24,25] : ce modèle proposé par Jan Jurjens [18] étend UML pour développer
des systèmes sécurisés, il fournit un UML profile où les besoins généraux de sécurité (comme
l’Intégrité, l’Echange Equitable, etc.) sont encapsulés en utilisant des stéréotypes. Il définit
aussi une sémantique formelle pour l’évaluation formelle des diagrammes UML contre les
défaillances. Pour analyser les spécifications de sécurité, on modélise d’une façon formelle le
comportement d’un attaquant potentiel.
6. Mécanismes d’extension d’UML pour la modélisation
D’après cet état de l’art, quatre principaux mécanismes peuvent être utilisés par UML pour la
modélisation, et qui ont été repris pour le modèle RBAC. Ces mécanismes sont représentés
ci-dessous:
1. Stéréotype et étiquette.
2. OCL.
47
Chapitre II RBAC et les travaux se rapportant à ce modèle
3. Extension du Méta-Langage UML
4. Création d’un nouveau Méta-Langage
1. Stéréotype et étiquette: le stéréotype fournit un mécanisme pour l’extension du Meta-
langage UML. Ainsi, le stéréotype est considéré comme Meta-élément défini par l’utilisateur,
sa structure correspond à une classe de base de UML, mais avec des buts différents. Un
exemple du modèle le plus connu qui l’utilise se trouve en section 5.4.
2. OCL est un langage formel utilisé pour exprimer les contraintes sur les diagrammes UML;
ces contraintes spécifient principalement les conditions que doit satisfaire le système à
modéliser, c’est-à-dire les principaux buts pour lesquels OCL est utilisé, et sont déterminées
par :
2. a. La spécification des invariants d’une classe et des types dans le Méta-Langage : cette
approche utilise OCL pour la spécification de la sécurité, en définissant des contraintes sur les
éléments décrits par les stéréotypes.
2. b. La spécification des invariants des stéréotypes : dans ce cas, OCL est utilisé pour la
spécification des propriétés de contrôle d’accès.
2. c. La description des pré et post-conditions des méthodes et des opérations : OCL permet la
spécification temporelle, cela peut être utilisé pour la description des besoins de sécurité
temporels.
Un exemple de modèle qui l’utilise se trouve en section 4.3.
3. Extension du Méta-Langage UML : dans cette approche, le Méta-Langage UML est
directement étendu pour spécifier les éléments de sécurité. MOF définit un méta-modèle
simple et des associations sémantiques permettant la description du Méta-Modèle dans
différents domaines d’objets à concevoir ou à analyser. Un exemple de modèle qui l’utilise se
trouve en section 4.6.
4. Création d’un nouveau Méta-Langage : un nouveau méta-langage est défini en utilisant les
spécifications d’un Méta-Langage de MOF comme langage, cela permet d’avoir un langage
48
Chapitre II RBAC et les travaux se rapportant à ce modèle
plus précis et plus concis que le langage UML. Un exemple de modèle qui l’utilise se trouve
en section 4.2.
7. Conclusion Nous avons présenté dans ce chapitre une définition détaillée du RBAC et les récents travaux
qui servent de base élémentaire à notre projet. Ainsi, nous nous sommes inspirés de
AuthUML et des travaux de Thuong et al pour choisir le diagramme des cas d’utilisation
comme diagramme de base, des travaux de Gut et al pour sa méthodologie pour l’ingénierie
des éléments du modèle RBAC, du modèle de Ahn et al. pour les étapes d’acheminement d’un
processus de développement et des travaux de Indrakshi et al. pour la visualisation des
contraintes.
49
Chapitre III Conception et analyse
1. Introduction Dans ce chapitre nous présentons la partie analyse et conception du projet. Nous rappelons
que notre projet consiste à élaborer une méthodologie qui permet d’analyser les besoins de
contrôle d’accès d’une application à partir des spécifications des besoins fonctionnels jusqu'à
la génération du code sécurisé tout en vérifiant la cohérence de l’application avec
la politique de sécurité .Un simulateur est ajouté, primo pour déceler les incohérences des
contraintes dynamiques avec l’application, secundo pour le déroulement des scénarios.
Nous sommes persuadés que la sécurisation de l’application commence dès l’ébauche du
développement de l’application. Le choix de cette étape (spécification des besoins
fonctionnels) dans le processus de développement de l’application n’est pas arbitraire, car
c’est un point déterminant entre le cahier des charges et la modélisation. Plusieurs chercheurs
ont proposé des modèles qui analysent la sécurité dans cette étape de développement
d’application, parmi eux AuthUML (Chapitre 2. section 4.1) et le Modèle de Thuong
(Chapitre 2 section 4.5) qui intègre le MAC (Chapitre 1 section 4.5.1). L’AuthUML ne
montre pas comment induire les éléments du modèle RBAC, alors que nous, nous proposons
dans notre modèle une grande partie concernant l’ingénierie des éléments du modèle RBAC
afin d’exploiter au mieux le processus de vérification ainsi que l’analyse de cohérence du
modèle RBAC. Pour cela, nous nous sommes inspirés du modèle de Gustaf et Mark (Chapitre
2 section 4.4) qui ont proposé, à partir des scénarios, un procédé d’ingénierie pour les rôles du
modèle RBAC.
Dans la deuxième partie, et après avoir spécifié les éléments du modèle RBAC, nous avons
axé notre étude sur la vérification de la cohérence de l’application avec la politique de sécurité
(contrôle d’accès). Nous proposons une nouvelle architecture basée sur les éléments du
modèle de conception (décrit dans la section 4). De cette façon, la découverte d’incohérences
passe par chaque pas dans le processus de spécification du modèle de conception, de même
que la vérification passe par toutes les étapes de définition des éléments. Dans cette partie,
nous avons dégagé une nouvelle approche différente de celle de la logique formelle. Nous
avons reporté le problème des contraintes RBAC (SSD, DSD, pré-requis) aux problèmes de la
théorie des graphes, ainsi le problème de vérification de contraintes est ramené aux problèmes
classiques de la théorie des graphes. Cependant ces graphes sont initiés, en se référant aux
travaux de [17], par le diagramme d’objets (instance du modèle de conception).
Pour tester les vulnérabilités de notre application au niveau modélisation, nous avons conçu
un simulateur qui offre la possibilité aux utilisateurs de créer des scénarios de menaces qui
51
Chapitre III Conception et analyse
sont supposés violer l’exécution normale de l’application, ainsi que la création de sessions
pour une vérification plus efficace des contraintes.
Après ces étapes (spécification, analyse des cohérences, et simulation), nous présentons un
générateur d’un squelette de code en JAVA. Dans cette partie, notre prétention n’est pas de
générer un code complet, mais uniquement la partie spécification de la politique de contrôle
d’accès sous la forme d’un fichier XML.
2. Motivation Pourquoi notre travail est-il axé sur les diagramme de cas d’utilisation et de séquence?
1) Ils sont considérés comme les premiers diagrammes, dans plusieurs processus de
développement (RUP, INOX….).
2) Un review 2006, intitulé <<Model Driven Security: From UML Models to Access
Control Infrastructures>>, place dans ces perspectives les cas d’utilisation.
3) D’autres modèles l’utilisent (AuthUML, MAC and UML for Secure Soft Design) pour
l’analyse de sécurité.
Pourquoi avons-nous choisi le RBAC ?
• Modèle standard depuis 2004.
• Bien adapté à l’entreprise.
• Le modèle a été décrit sous plusieurs facettes:
_ Logique prédicat : le standard.
_ Visuelle : UML.
• Depuis sa création, sont apparus de nombreux articles et reviews pour enrichir ce
modèle, dont les derniers plus récents (2010) sont ceux de Darwish et Beznosov [26]
et Colantonio et al. [27].
• Les contraintes du RBAC représentent la motivation principale pour contrôler l’accès
• Joshi at al. [28] affirme que le RBAC constitue la solution la plus attractive pour
fournir les propriétés de la sécurité.
3. Vue Globale du projet Notre projet est divisé en six grandes parties schématisées comme le montre la figure 1.
52
Chapitre III Conception et analyse
3.1. Instancier le modèle d’application
Dans cette étape, on identifie les éléments du diagramme de cas d’utilisations et leurs
scénarios sous forme de diagrammes de séquences de haut niveau. Généralement, le
diagramme de séquence spécifie les exigences détaillées du modèle.
3.2. Initier RBAC
Dans cette deuxième étape, les rôles et les permissions sont spécifiés à partir des éléments du
modèle d’application (cas d’utilisation, séquence). Après avoir analysé la documentation
UML [29, 30, 31,32], nous avons conclu qu’il existe trois éléments essentiels qui, selon leurs
niveaux d’abstraction et la politique de contrôle d’accès, permettent de définir les rôles. Ces
éléments sont : acteur, cas d’utilisation, et les associations entre acteurs et cas d’utilisation.
Les permissions sont identifiées à partir des opérations et des objets. L’utilisateur de
l’application introduit les utilisateurs du modèle RBAC.
3.3. Instancier la politique contrôle d’accès L’identification des contraintes est une partie sensible du procédé. Elle définit les restrictions
d’accès aux ressources du système. Ces contraintes peuvent être de différents types :
1. Séparation des devoirs.
2. Cardinalité.
3. Dépendance temporelle
4. Dépendance envers les entités.
5. Maximum d’opérations exécutées dans un intervalle de temps.
Notre intérêt s’est porté plus précisément sur les contraintes utilisées dans le modèle RBAC :
la séparation des devoirs, la cardinalité, et les dépendances des entités.
Initier RBAC
Détecter Incohérences
Instancier modèle Application
Simuler Générer code oui
Instancier Politique Contrôle d’accès
Non
Figure1. Vue de haut niveau de notre projet.
53
Chapitre III Conception et analyse
Pour cela, l’idéal serait que l’organisation pour laquelle on veut développer l’application ait
un administrateur de sécurité ayant une parfaite connaissance de l’organisme et pouvant ainsi
définir un cahier des charges de sa politique de contrôle d’accès.
Seulement cette tâche n’est pas simple : dans la plupart des organismes, on trouve un
administrateur réseau qui est chargé du bon fonctionnement du réseau ainsi que de sa sécurité
(firewall, anti-virus,…). Cet administrateur n’est pas concerné par la politique de contrôle
d’accès des informations sensibles. Le travail d’identification sera mené auprès des autorités
concernées par ces informations sensibles, et souvent par la consultation des documents
juridiques.
3.4. Détecter les Incohérences entre la politique de sécurité et le modèle
d’application
Cette partie du modèle est la plus importante, car elle permet de vérifier la cohérence entre la
politique de contrôle d’accès et le modèle d’application. Le principe est de comparer l’état du
système de notre modèle (diagramme d’objets) avec la politique de contrôle d’accès (les
contraintes RBAC). On introduit les contraintes SSD, DSD et pré-requises dans le diagramme
d’objets comme des relations stéréotypées entre deux entités de même type.
Ainsi, l’incohérence entre le modèle d’application et les séparations des devoirs est détectée
lorsque deux entités sont en relation, soit en SSD, soit en DSD, et sont utilisées par une autre
entité.
Les pré-requis sont eux définis entre deux entités et sont violés si, et seulement si, une entité
utilise uniquement son entité principale, sans son entité pré-requise.
Les cardinalités sont contrôlées par simple vérification du nombre de créations des éléments
ou d’objets utilisés.
Nous rappelons que [11] a utilisé cette approche (les contraintes comme des stéréotypes sur
les relations entre les objets) pour visualiser les contraintes du modèle RBAC, mais il n’a pas
montré comment détecter les incohérences.
Afin de vérifier l’existence de violations, nous avons choisi la théorie des graphes comme
moyen mathématique formel, ainsi les arcs et les sommets sont initiés par les trois étapes
décrites ci-dessus.
54
Chapitre III Conception et analyse
3.5. Simuler
Dans cette partie, nous proposons un simulateur qui permet de faire des tests sur le modèle
d’application, au niveau de la conception. Les tests concernent toutes les contraintes du
modèle RBAC, ainsi que la création de scénarios.
Dans le premier cas, plusieurs sessions sont créées, supprimées, des rôles activés, désactivés,
le simulateur nous informe sur le déroulement de l’application et nous signale toutes les
violations commises.
Dans le deuxième cas, on crée divers scénarios à travers des opérations, on lance les tests et,
selon les scénarios introduits, le simulateur indiquera les résultats qui permettront à
l’utilisateur de déceler les vulnérabilités de sa politique de contrôle d’accès.
3.6. Générer du code
Après le passage des étapes précédentes, nous présentons, dans cette phase, un générateur de
code pour la politique de contrôle d’accès.
Pour cela, nous avons choisi java, qui est devenu ces dernières années, la plateforme la plus
utilisée [33] pour l’implémentation des applications services web, plus précisément, les
Entreprise Java Beans (EJB). Les EJB représentent des objets distribués utilisés pour
encapsuler le corps de la logique business, et sont exécutés coté serveur. L’accès aux EJB est
protégé par les serveurs d’applications selon le modèle RBAC.
Le comportement général de chaque EJB peut être représenté par une classe EJB. Ce
comportement peut être modifié pour s’adapter à des configurations spécifiques ou à des
installations spécifiques de l’application. Cela se réalise avec le descripteur de déploiement,
un fichier en XML qui décrit les propriétés de l’EJB, incluant leur sécurité, leur persistance, et
leur comportement transactionnel.
Ainsi, notre travail ne concernera pas la partie logique business, mais uniquement la partie
implémentation de la politique de contrôle d’accès.
4. Modèle de Conception
Afin de bien structurer notre démarche, nous proposons un modèle de conception. Ce modèle
est composé des éléments du diagramme des cas d’utilisation et de séquence (modèle
d’application), qui sont combinés à ceux des éléments du modèle RBAC. Cette combinaison
se traduit par des relations entre des éléments des deux modèles.
55
Chapitre III Conception et analyse
Afin de modéliser le modèle d’application, nous nous sommes basés sur le modèle décrit dans
[32] pour la description du diagramme des cas d’utilisations et de séquence, et sur le modèle
décrit dans [11] pour le modèle RBAC. Pour notre modèle, le choix s’est porté sur l’utilisation
du diagramme de classes template.
La figure 1 définit le modèle de conception qui est constitué de classes template: Acteur,
Association, Cas d’utilisation, Scénario, Opération, Objets et leurs relations et, de plus: User,
Permission, Rôle, Session et leurs relations.
Les relations ajoutées sont:
1. La relation association entre utilisateur et acteur << UserAffectAct>> : elle exprime le fait
qu’un objet utilisateur devient un objet acteur dans le système.
2. Une relation dépendance <<représente>> entre acteur et rôle : elle exprime le fait que les
objets acteurs sont représentés par des objets rôles.
3. Une relation dépendance <<instance>> entre le rôle et le cas d’utilisation : cette relation
signifie qu’un objet cas d’utilisation est utilisé comme argument pour la définition des rôles.
4. Une relation dépendance <<Correspond>> entre rôle et l’association : cette relation
indique qu’un objet rôle peut être défini directement à partir du nom de l’association entre
acteur et cas d’utilisation (modèle [30]).
5. Une relation dépendance <<PermissionObjet>>, << PermissionOpér>> : elle indique que
les permissions générées dépendent des opérations introduites dans le modèle d’application.
_ Le choix des relations de dépendance est dû au fait que notre démarche s’appuie sur le
modèle d’application pour la définition des éléments du modèle RBAC.
56
Chapitre III Conception et analyse
Hiérarchie SSD DSD
5. Détail du procédé Dans ce qui suit, nous allons détailler les étapes de notre projet (section 3) à l’aide de
procédés (diagramme d’activités) et de fragments d’algorithmes.
Acteur
Nom : String AccorderAss AnnulerAss AddAsc(Ac) SupAsc(Ac) AddDes(Ac) SupDes(Ac) AddSSD() SupSSD() AddDSD() SupDSD() AssegnedUser() Ascendant() Descendant() SSDActeur():set(Acteur) DSDActeur() :set(Acteur)
Utilisateur
Nom : string CréerSession () SuprimerSession () AssignActeur DeassignActeur()
Association
Nom : string RelationAccess(User,Acteur)
Cas d’utilisation Nom: String CréerCasUtilisation SuprimerCasUtilisation Extend (CU) Includ(CU) Generalisation (CU)
Rôle
Nom : String CréerRole () AffecterActeur() AddAsc(R) SupAsc(R) AddDes(R)
Senior
Junior
Interface
Interface
SupDes(R) AddSSD(R) SupSSD(R) AddDSD(R)
Scenario (Séquence) Nom: String SeqEvenement : array[]
Opération Objet
Session Nom : string ActiveActeur() DesactiverActeur()
SSD DSD
Junior Senior
Figure 2. Diagramme de classes template du modèle de conception.
UserSession AffectaPermission
Includ
Extend
SessionActeur
Permission
Généralisation
UserAffectAct
Correspond
Représenté
User-Role Instancier
Attaché Session Role
PermissionObjet PermAffecter PermissionOpér
57
Chapitre III Conception et analyse
5. 1. Instanciation du modèle d’application Dans cette partie nous montrons la démarche à suivre pour spécifier les diagrammes de
cas d’utilisation et de séquence. Cette démarche est détaillée dans [29], que nous avons
reproduit en diagramme d’activités (figure 3).
Rappelons que les diagrammes de cas d’utilisation sont utilisés pour définir les exigences
fonctionnelles du système, et les diagrammes de séquence pour les exigences détaillées.
Identification des acteurs Définir les comportements attendus
Nommer les comportements Créer une hiérarchie d’acteurs
Factoriser les comportements
Mettre en relation Acteur, C.U Nommer les cas d’utilisation
Nommer les scénarios
Définir les opérations élémentaires
Définir Modèle D’application
Créer séquence
Figure 3. Processus de définition des diagrammes de cas d’utilisation.
58
Chapitre III Conception et analyse
5.1.1. Analyse
A chaque fois qu’un acteur, un cas d’utilisation, un scénario ou une opération est ajouté, un
objet correspondant est créé. Si une relation entre ces éléments existe, une instanciation de la
relation entre ces deux éléments est créée.
Cette partie sert a instancier des graphes qui seront par la suite utilisés pour l’analyse de la
sécurité. Les graphes utilisés sont:
GAc (VActeur, E R_Acteur), GCu (VCU, E R_CU), G Ac/CU (VActeur U VCU, E Ac/CU), G Scé/CU (VCUU
VScé, E Scé/CU), GScé/op (VopU VScé, E Scé/op).
A chaque graphe, on associe une matrice d’adjacence (Sommets-Sommets) pour la
représentation des relations entre différents nœuds. Par la suite, nous proposerons comment
instancier ces graphes.
5.1.1.a. L’instanciation du graphe
• Définition des types
Classe Nœud {
Nom: String;
Tab: tableau [n] en entier ;
}
Classe Relation {
Nom: String;
Noeud1: String;
Noeud2: String;
Type : entier ;
}
• Variables
Acteur, Cas_d’utilisation, Scénario, Opération : Tableau [n] de Nœud ;
RelationDi : tableau [n] de Relation ;
R-Acteur, R-CU, AcCu, CuSce, SceOp : Matrice [n] [n] d’entier ;
nbreAct, nbreCU, Nbrescénario, nbreOpe,nbrela : entier ;
• Fonctions
Fonction CherchezIndice (Tab : Tableau [n] de Nœud, str : string, n : entier) : entier
Variable: i en entier ;
Début
i ← 0 ;
59
Chapitre III Conception et analyse
Tant que (i < n) et (Tab[i].nom <> str)
Début
i ← i + 1 ;
Fin Tant que
Si (Tab[i].nom = = str) alors CherchezIndice ← i ;
Fin
• Si un nouveau acteur « Aci » est ajouté alors:
Acteur [i].nom ← ‘Aci’ ;
nbreAct ← nbreAct + 1;
• Si une relation de généralisation entre acteur acm et acteur ack est ajoutée:
RelationDi [l]. Noeud1← ‘acm’ ;
RelationDi [l]. Noeud2← ‘ack’ ;
RelationDi.Type = 1 ; (généralisation entre acteur)
nbrela ← nbrela+1 ;
i ← CherchezIndice (Acteur, ‘acm’, nbreAct) ;
j ← CherchezIndice (Acteur,’ ack’, nbreAct) ;
R_ Acteur[i] [j] ← 1; {i sera considéré comme fils et j le père}
• Si un cas d’utilisation « uc1 » est ajouté:
Cas_d’utilisation [i].nom ← ‘uc1’ ;
nbreCu ← nbreCu + 1 ;
• Si une relation entre deux cas d’utilisation ucm et uck est ajoutée:
RelationDi [l]. Noeud1← ‘ucm’ ;
RelationDi [l]. Noeud2← ‘uck’ ;
RelationDi.Type ← 2, 3 ou 4 ; {2 : généralisation entre Cas d’utilisation
3 : Include
4 : extend
}
Nbrela ← nbrela+1 ;
60
Chapitre III Conception et analyse
Si la relation est <<include>> : R-Cu [i] [j] ← 1 ;
Si la relation est <<Extend>> : R-Cu [i] [j] ← 2 ;
Si la relation est <<généralisation>> : R-Cu [i] [j] ← 3 ;
• La relation entre acteur i et cas d’utilisation j:
RelationDi [l]. Nom ← Association.Nom ; (si on utilise le modèle de [25])
RelationDi [l]. Noeud1← ‘Aci’ ;
RelationDi [l]. Noeud2← ‘ucj’ ;
RelationDi [l].Type ← 4 ;
nbrela← nbrela+1 ;
i ← CherchezIndice (Acteur, ‘aci’, nbreAct) ;
j ← CherchezIndice (Cas_d’utilisation, ‘cuj’, nbreCu) ;
AcCu[i] [j] ←1 ;
• Si un scénario sc1 est ajouté:
Scénario[i] .nom ← ‘sc1’ ;
Nbrescénario ← nbrescénario + 1 ;
• Liaison d’un cas d’utilisation Cui à un scénario scej :
RelationDi [l]. Noeud1← ‘Cui’ ;
RelationDi [l]. Noeud2← ‘scej’ ;
RelationDi.Type ← 5 ;
nbrela ← nbrela +1 ;
i ← CherchezIndice (Cas_d’utilisation, ‘cum’, nbreCu) ;
j ← CherchezIndice (Scénario, ‘scej’, Nbrescénario) ;
Cu-Scé[i] [j] ← 1 ;
• Si une opération Opi est ajoutée :
Opération [i].nom ← ‘opi’ ; nbreOpe ← nbreOpe +1 ;
• Si une opération Opj appartient à un scénario sci :
RelationDi [l]. Noeud1 ← ‘sci’ ;
61
Chapitre III Conception et analyse
RelationDi [l]. Noeud2← ‘opj’ ;
RelationDi.Type ← 6 ;
nbrela ← nbrela+1 ;
i ← CherchezIndice (Scénario, ‘sci’, Nbrescénario) ;
j ← CherchezIndice (Opération, ‘opj’, nbreOpe) ;
ScéOpé[i] [j] ← l ;
5. 2. Initialisation des éléments du modèle RBAC L’initialisation du modèle RBAC (voir figure 4) permet de définir les éléments qui sont : les
utilisateurs, les rôles, les permissions et leurs relations dans le modèle de conception.
Nous rappelons que la base du modèle RBAC est qu’un rôle est affecté à un utilisateur, un
rôle est associé à des permissions, un utilisateur ne peut accéder à des permissions qu’en
acquérant un rôle.
Un schéma pareil est défini dans les diagrammes de cas d’utilisation et de séquence (qui
représentent les scénarios sous forme d’opérations ordonnées), un acteur interagit avec un cas
d’utilisation, un cas d’utilisation est constitué de séquences d’opérations représentées par le
diagramme de séquence, un acteur accède à une séquence si, et seulement si, il interagit avec
le cas d’utilisation qui lui correspond.
Toutefois, la définition des rôles à partir du diagramme de cas d’utilisation est une tâche
délicate, car elle dépend du niveau d’abstraction du modèle ainsi que des termes utilisés dans
la politique de contrôle d’accès.
Le rôle est un comportement d’une entité active dans un contexte donné. Dans le diagramme
des cas d’utilisation, un acteur représente un ensemble cohérent de rôles joués par les
utilisateurs des cas d’utilisation. Ralph et al. [30] intègre la notion de rôle comme stéréotype
qui décore l’association entre acteur et cas d’utilisation et Gustaf et Mark [18] induisent les
rôles à partir du système.
Les permissions dans notre modèle sont définies à partir des opérations d’accès, c'est-à-dire
les opérations qui sont invoquées par des entités extérieures, cela est dû au fait qu’à ce niveau
(phase de spécification des besoins fonctionnels), le diagramme de séquence est utilisé pour la
définition des interactions entre le système et les objets extérieurs.
62
Chapitre III Conception et analyse
Modèle Application
5.2.1. Définition des rôles
La définition des rôles est une tâche très délicate, car elle dépend du procédé utilisé dans le
développement, ainsi que de la capacité du développeur à les définir. Pour cela, nous nous
sommes intéressés aux différentes vues qui permettent de les spécifier, et cela sous différents
angles. Notre étude nous a permis de distinguer trois éléments de base pour la génération:
1. Acteur.
2. Cas d’utilisation.
3. Association entre acteur et cas d’utilisation.
5.2.1.a. Acteur
Un acteur représente un ensemble de rôles joués par les utilisateurs de cas d’utilisation [29].
Lors de la modélisation du contexte du système, le développeur doit préciser les acteurs et
leurs rôles. C'est-à-dire que le développeur spécifie les acteurs et, ensuite, chaque acteur se
voit attribuer les rôles qu’il doit jouer. Dans ce cas de figure, on distingue : le cas où chaque
acteur joue un seul (1) rôle et le cas ou un acteur joue plusieurs rôles.
5.2.1. a.1. Le cas où chaque acteur joue un seul rôle
Dans ce cas, un acteur représente un seul et unique rôle [31], les relations entre acteurs sont
mappées directement sur les relations entre rôles, si un acteur ac1 hérite d’un autre acteur ac2
et ac1 est représenté par r1 et ac2 par r2 alors r1 hérite de r2.
Identification des permissions
Identification des Rôles Introduire Utilisateur
Identification de la hiérarchie des rôles
Figure 4. Processus de définition du modèle RBAC.
63
Chapitre III Conception et analyse
Si un acteur est lié à un cas d’utilisation, alors le rôle représentant l’acteur doit être lié à ce
même cas d’utilisation
5.2.1. a.1.1. Fragment de l’algorithme associé :
Partie déclaration
Rôle : Tableau [n] de Nœud ;
Ac-Rôle, Uc_Rôle, R_Rôle : matrice [n] [n] en entier ;
Nbrôle: entier;
• Tous les noms d’acteurs deviennent des noms de rôles :
Pour i ← 0 à nbreAct faire
Rôle [i].nom ←Acteur [i].nom ;
nbrôle ← nbrAct ;
• Chaque rôle est lié à l’acteur correspondant :
Pour i ← 0 à nbreAct faire Pour j ← 0 à nbrôle faire
Si (i == j) alors Ac- Rôle [i] [j] ← 1 ; (la diagonale)
• Chaque relation de généralisation entre acteurs devient une relation de
généralisation entre les rôles correspondants :
Pour tous i ← 0 à nbreAct faire Pour tous j ← 0 à nbreAct faire Si (R_ Acteur[i] [j] == 1) alors R_Rôle [j] [i] ← 1 ;
• Les cas d’utilisation correspondant aux acteurs reviennent aux rôles :
Pour tous i ← 0 à nbreAct faire Pour tous j ← 0 à nbreAct faire Si (AcUc[i] [j]=1) alors Uc_Rôle[i] [j] ← 1;
5.2.1. a.2. Le cas où chaque acteur joue plusieurs rôles
L’acteur est représenté par plusieurs rôles. Dans ce cas de figure, il faut s’assurer que, s’il
existe une relation de généralisation entre deux acteurs, alors les rôles qui décrivent l’acteur
père doivent être inclus dans les rôles de l’acteur fils, soit :
64
Chapitre III Conception et analyse
Soit : Ac1, Ac2 Є ACTEUR et
Rep (Aci)= {Ri1, Ri2,….Rin}
Si Ac2 hérite de Ac1 alors Rep (Ac2) ⊂ Rep (Ac1)…………………… (1)
• Démonstration
Soient les ensembles ACTEUR, ROLES, PRMS, UTLISATEUR, pour respectivement les
acteurs, les rôles, les permissions, et les utilisateurs.
Soit l’ensemble AR, l’ensemble des couples entre acteurs et rôles qui sont en relation, et UA
l’ensemble des couples d’utilisateurs qui sont liés aux acteurs, alors on définit :
authorized permissions(aci) ={p Є PRMS / ac’ ≥ aci (ac’ ,r) Є CR et r’ ≥ r (p, r’) Є PA }
authorized permissions (ri) = {p Є PRMS / r’ ≥ ri: (p, r’) Є PA}
Represented (aci) = {r Є ROLES / ac’ ≥ aci (ac’, r) Є CR}
Assigned_User (aci) = {u Є UTLISATEUR / (u, ac) Є UA}
On a
1) authorized permissions(ac1) = U authorized permissions(r i )
ri Є ac1
authorized permissions(ac2) = U authorized permissions(r i )
ri Є ac2Or ri , ri‘ Є Represented (aci) => U authorized permissions (r i) ⊂ U authorized permissions (r i’) ri Є ac1 ri‘Є ac2 Represented (aci) 2) On a C Represented (acj) = {r’0… r’k}. donc Assigned_User(Aci) ∩ Assigned_User(Acj) = Assigned_User(r’i) d’où Assigned_User(Aci) ⊂ Assigned_User(Acj) 5.2.1. a.2.1. Fragment de l’algorithme associé
• Création d’un rôle i et son inclusion dans un acteur acm :
Lire (Role [i].nom) ;
nbrole ← nbrole + 1 ;
65
Chapitre III Conception et analyse
Rôle [i]. Tableau [l] ← CherchezIndice (Acteur, acm,nbrActeur) ;
Acteur [CherchezIndice (Acteur, acm, nbrActeur)] .tableau[k] = i ;
Ac- Rôle [CherchezIndice (Acteur, acm, nbrActeur)] [i] = 1 ;
• Les cas d’utilisation correspondant aux acteurs reviennent aux rôles :
Pour tous i ← 0 à nbreAct faire Pour tous j ← 0 à nbreUC faire
Si (AcCu [i] [j]=1) alors
Pour tous k ← 0 à nbreRôle faire Si (Ac- Rôle[i] [k] = 1) alors
Uc_Rôle[i] [j] ← 1;
FinPour (j)
FinPour (i)
• Pour la relation (1)
L’idée de cet algorithme est que, s’il existe une relation (généralisation) entre acteurs, alors
tous les rôles qui représentent acteur père doivent appartenir à acteur fils.
L’algorithme est donné comme suit :
Fonction Fct_inclus (mat : matrice [] [] en entier, n, z, e : entier) : booléen
Variable
k: entier ;
Début
Fct_inclus ← true ;
Pour chaque k ← 0 à n faire Si (mat[z] [k]=0) alors
Si (mat [e] [k] =1) alors
Fct_inclus ←false ;
Fin
Variable
Erreur : matrice [2] [n] en entier
Début
i, j, l: entire;
l ← 0;
66
Chapitre III Conception et analyse
Pour tous i ← 0 à nbrAct faire Pour tous j ← 0 à nbrAct faire
Si (R_ Acteur[i] [j] =1) alors Début Si (Fct_inclus (Ac- Rôle, nbrole, i, j)) alors Début Erreur [0] [l] ← i ;
Erreur [1] [l] ← j ;
l =l+1 ;
Fin si Fin si. Fin Pour (j)
Fin Pour (i)
5.2.1.b. Cas d’utilisation
Dans ce cas de figure, il faut réunir les cas d’utilisation en plusieurs tâches de travail en
mesure de former une entité de travail, ils dépendent du niveau d’abstraction des cas
d’utilisation car, plus le niveau d’abstraction est élevé, plus il tend vers la définition d’un
rôle, et vice-versa.
On distingue deux cas : un rôle représente un seul cas d’utilisation et un rôle est défini à partir
de plusieurs cas d’utilisation.
5.2.1. b.1. Un rôle représente un seul cas d’utilisation
Cette approche permet de créer des rôles basiques adaptés à chaque cas d’utilisation, ainsi un
acteur qui se voit attribuer un certain nombre de cas d’utilisation sera amené à jouer les rôles
correspondant à ces cas.
La transformation se fait comme suite :
1. Chaque cas d’utilisation se transforme en son rôle correspondant.
2. Chaque Extend entre cas d’utilisation devient une relation de rôle pré-requis
entre les rôles correspondants.
67
Chapitre III Conception et analyse
3. Chaque Include entre cas d’utilisation devient une relation de rôle pré-requis
entre les rôles correspondants.
4. Chaque Généralisation entre cas d’utilisation devient une relation de
généralisation entre les rôles correspondants.
Toutefois l’étape (1) (cas d’utilisation représenté par un seul rôle) est une hypothèse, l’étape
(4) est évidente, tandis que l’étape (2) et (3) reste à prouver.
• Démonstration
Soit UC = {uc1, uc2,….ucn} et R = {r1, r2, …, rn}
Soit UA l’ensemble des utilisateurs qui sont rattachés à des acteurs, UR l’ensemble des rôles
qui sont affectés aux utilisateurs, et CA l’ensemble des acteurs qui sont en relation avec les
cas d’utilisation
Et soit :
auth_user (ri) = { u Є UTLISATEUR / r’ ≥ ri : (u, r’) Є UR}
auth_user(uci) ={ u Є UTLISATEUR/cu’ ≥ uci (cu’ ,ac) Є CA et ac’ ≥ ac (u, ac’) Є UA
}
Et soit : la fonction bijective Transforme telle que
Transforme : cas d’utilisation → ROLES
cu i → ri = Transforme(cu i)
Pour Include
Une relation include entre uc1 et uc2 est définie comme suit :
uc1 include uc2 le cas d’utilisation principal uc1 incorpore le comportement d’un autre cas
d’utilisation uc2 en un point d’insertion bien déterminé.
Uc1
Uc3 Uc4
Uc2
Uc5 Uc6include
Extend
r1
r5
r2
r3
r6
Transformation
Pre-requisite
r4
Pre-requisite
Figure 5. Résumé de transformation.
68
Chapitre III Conception et analyse
uc1 incorpore le comportement de uc2 => auth_user (uc1) ⊂ auth_user (uc2)
D’autre part on a : Transforme (uc1) = r1 et Transforme (uc2) = r2 donc
auth_user (r1) ⊂ auth_user (r2).
Cela veut dire que les utilisateurs ne peuvent pas exécuter un cas d’utilisation principal s’ils
n’ont pas accès aux cas d’utilisation incorporés. Les utilisateurs d’un cas d’utilisation
principal doivent avoir impérativement les attributions des opérations du cas d’utilisation
incorporé, ce sont les opérations (permissions) pré-requises à l’exécution du cas d’utilisation
principal, ainsi si r1 représente uc1 et r2 représente uc2 la démonstration sera évidente.
Pour Extend :
On a la relation entre les cas d’utilisation comme suit :
uc1 extend uc2 le cas d’utilisation de base englobe implicitement le comportement d’un
autre cas d’utilisation en un point spécifié.
uc1 étend le comportement de uc2 => auth_user (uc1) ⊂ auth_user (uc2)
D’autre part on a : transforme (uc1) = r1 et transforme (uc2) = r2 donc
auth_user (r1) ⊂ auth_user (r2).
Cela veut dire que l’utilisateur qui veut atteindre un cas d’utilisation étendu doit avoir
impérativement la possibilité d’interagir avec le cas d’utilisation de base.
5.2.1. b.1.1. Algorithme associé
• Tous les noms Cas d’utilisation transformés en noms de rôles :
Pour tous i ← 0 à n faire. Role [i].nom ← Cas_d’utilisation [i].nom
• Les relations entre cas d’utilisation seront transformées en relations entre rôles :
Pour tous i ← 0 à nbrôle faire. Début Pour tous j ← 0 à nbrôle faire. Début Si (R-Cu [i] [j] = 1) alors PréreqRôle[j] [i] ← 1;
Si (R-Cu [i] [j] = 2) alors Préreq_Rôle[j] [i] ← 1;
Si (R-Cu [i] [j] = 3) alors R_Rôle [i] [j] ← 1;
Uc_Rôle [cherchezIndice(Cas_d’utilisation ,Ucm, nbreCu)][i] ←1 ;
Fin Pour (j)
69
Chapitre III Conception et analyse
Fin Pour (i)
• Les acteurs correspondants aux cas d’utilisation reviennent aux rôles :
Pour tous i ← 0 à nbActeur. Pour tous j ← 0 à nbrRôle faire Si (AcUc[i] [j]=1) alors Ac_Rôle[i] [j] ← 1 ;
5.2.1. b.2. Un rôle est défini à partir de plusieurs cas d’utilisation
Dans ce cas de figure, on doit réunir les cas d’utilisation selon leurs fonctions, jusqu’à ce
qu’ils représentent une tâche bien définie. Une fois la tâche définie, on les regroupe pour
former une charge de travail qui peut être interprétée par un rôle.
Non
5.2.1. b.2.1. Analyse
Dans ce cas, les cas d’utilisation qui participent au comportement d’un rôle sont mis en
évidence dans la matrice UC-Role. Ainsi, à tout moment, on peut savoir quels sont les
constituants des rôles.
Dans une deuxième phase, chaque rôle est rattaché à l’acteur qui est en interaction avec le cas
d’utilisation qui forme le rôle.
Identifier un nouveau C.U
Vérifier son apport a la tâche
Inclure dans la tâche
Oui
Terminé
Définir une tâche
Non Terminé
Inclure dans la charge de travail
Générer un rôle
Nouvelle tâche
Terminer
Figure 6. Procédé de définition d’un rôle à partir des cas d’utilisation.
70
Chapitre III Conception et analyse
5.2.1. b.2.2. Fragment d’algorithme Associé
• Créer un rôle à partir de Cu1’ … Cu2’ :
Lire (Rôle [i].nom) ;
nbrole ← nbrôle + 1 ;
• Pour chaque cas d’utilisation ucm appartenant a Rôle i :
Rôle [i]. Tableau [l] ← Cherchez indice (Cas_d’utilisation, ucm, nbreCu) ;
UC- Rôle [Cherchez indice (Cas_d’utilisation, ucm, nbreCu)] [i] ← 1 ;
• Les acteurs correspondants aux cas d’utilisation reviennent aux rôles:
Pour tous i ← 0 à nbreAct faire Pour tous j ← 0 à nbreUC faire Si (AcUc[i] [j]=1) alors
Pour tous k ← 0 à nbreRôle faire Si (UC- Rôle[j] [k] = 1) alors
AC_Rôle[i] [k] ← 1;
5.2.1.c. L’association entre acteur et cas d’utilisation
Dans ce cas, les noms des rôles sont directement instanciés à partir des noms qui décorent les
associations entre les acteurs et les cas d’utilisation.
5.2.1.c.1. Analyse
Dans ce cas, l’attribut : Nom inclus dans l’objet association se trouvant entre l’objet Acteur et
l’objet cas d’utilisation, est utilisé pour nommer le rôle; ce rôle est lié à l’acteur et au cas
d’utilisation formant cette association.
• Créer un rôle à partir du nom de l’association entre acteur et cas d’utilisation :
Pour tous i ← 0 à nbrela faire
Si (RelationDi [i].Type = 4) alors
Rôle [i].nom ← RelationDi [i]. Nom ;
• Liaison du rôle au cas d’utilisation ‘cuk’ et l’acteur ‘acm’ de l’association :
Pour tous i ← 0 à nbrela faire
71
Chapitre III Conception et analyse
Si (RelationDi [i].Type = 4)
alors
Début
AC_rôle[cherchezIndice((Acteur, RelationDi [l]. Noeud1, nbrActeur)] [i] ←1 ;
UC_Rôle[cherchezIndice(Cas_d’utilisation, RelationDi [l]. Noeud2, nbreCu)] [i] ←1 ;
Fin si
5.2.2. Définir les utilisateurs
La définition des utilisateurs (une entité extérieure du système) concerne la création d’un
objet utilisateur qui va évoluer dans le système en devenant un acteur. Ainsi, l’utilisateur peut
exécuter toutes les opérations acquises à partir de cet acteur (par l’intermédiaire des cas
d’utilisation).
D’autre part, l’utilisateur, en devenant acteur, utilise les rôles (qui sont impartis à cet acteur),
pour avoir accès aux permissions.
Dans notre modèle, le choix de la relation entre l’utilisateur avec l’acteur est dû à deux raisons
: la première est que l’utilisateur dans la modélisation de son application considère que
l’acteur est l’entité extérieure du système. La deuxième est que l’ensemble des acteurs
représente tous les rôles générés (les rôles seront liés aux utilisateurs par composition).
5.2.2.1. Algorithme associé
Utilisateur : Nœud
User_Rôle User-Ac : tableau[n] [n] d’entier
nbreUser : entier
• Création d’un nouvel utilisateur useri :
Utilisateur.Nom ← ‘useri’ ;
nbreUser ← nbreUser+1 ;
• Rattâcher un utilisateur i a un acteur j:
User-Ac [i] [CherchezIndice (Acteur, ‘acteur j’, nbrActeur] ←1 ;
• Rattacher un utilisateur i au rôle correspondant :
Pour tous i ← 0 à nbreUser faire Pour tous j ← 0… nbreAct faire Si (User-Ac [i][j]=) alors
Pour tous k ← 0 à nbrRôle faire Si (Ac_Rôle[i] [j]=1) alors User_Rôle [k] [j] ← 1 ;
72
Chapitre III Conception et analyse
5.2.3. Dérivation des permissions
Le but de cette étape est d’identifier des permissions qui sont nécessaires à l’exécution d’un
scénario d’un cas d’utilisation, les résultats sont des objets permission.
Durant l’analyse, chaque scénario d’un cas d’utilisation est analysé, ensuite on prélève toutes
les opérations utilisées par l’utilisateur dans l’exécution de chaque scénario.
La figure 7 illustre un diagramme de séquence, qui est généralement utilisé pour représenter le
schéma d’un scénario: coté gauche, il y a le sujet qui est un acteur dans le système, l’objet est
représenté à droite, les flèches entre les deux entités sont des opérations que l’acteur invoque
dans l’objet.
Exécution Opération 2 ()
Exécution Opération 1 ()
Sujet
Optionnel : résultat2 ()
Optionnel : résultat1 ()
Invoquer Opération 2 ()
Invoquer Opération 1 ()
Classe : Objet
Figure 7. Un scénario.
Les permissions peuvent être abstraites ou basiques selon leur niveau d’abstraction : la
permission abstraite (ex: transfert d’argent) peut être composée de plusieurs permissions
basiques (ex : lire compte) et permissions abstraites. Les opérations exécutées dans les
scénarios sont des éléments de permission basique.
5.2.3.1. Analyse
Les opérations, telles que nous les utilisons ici, sont considérées comme des événements.
Ainsi, chaque opération est constituée d’un nom, d’arguments et d’un objet expéditeur et
receveur (selon le sens de la flèche dans le diagramme de séquence).
73
Chapitre III Conception et analyse
Nous considérons les opérations comme des objets nœuds, où les noms des opérations sont
des noms de nœuds et où le tableau des nœuds inclut les arguments de l’opération. Les objets
expéditeur et receveur demeurent un problème. Afin de pallier à ce problème, nous déclarons
une classe fille de la classe nœud qui ajoutera les éléments manquants (objets expéditeur et
receveur).
Les permissions sont des opérations d’accès, elles sont définies directement à partir
d’opérations où le nom d’expéditeur est l’utilisateur.
Une fois les permissions définies, on lie chaque permission à son rôle.
5.2.3.2. Algorithme associé
• Création d’une permission :
typeDef NoeudF fils de classe Nœud{
Texpéditeur : String ;
Receveur : String ;
}
TypeDef Perm {
Opé: String;
Objet: String;
}
Opération: tableau [n] de NoeudF ;
Permission : tableau [n] de perm ;
Si (Opération[i]. Texpéditeur = user) alors
Début
Permission [k]. opé ← Opération. Nom ;
Permission [k]. Objet ←Opération. Receveur ;
Opéperm [i] [k] ←1 ;
Nbrpermission ← Nbrpermission+1 ;
Fin Si
• Liaison d’une permission à un rôle:
Pour tous i ← 0 à Nbrpermission faire Début Pour tous j ← 0 à nbreOpe faire
74
Chapitre III Conception et analyse
Début
Si (Opéperm[j] [i] = 1) alors
Début
Pour tous k ← 0 à Nbrescénario faire Si (ScéOpé[k] [j]= 1) alors
Début
Pour tous m ← 0 à nbreCu faire Si (Cu-Scé[k] [j] ← 1) alors
Début
Pour tous s ← 0 à nbrRole faire
Si (Cu-R [k] [s] = 1) alors
role-permi[s][i] ← 1; Fin Si
Fin Si
Fin Si
Fin Pour (j)
Fin Pour (i)
5.2.4. Dérivation des hiérarchies de rôle
Une fois que les rôles liés à leurs permissions sont définis, nous nous intéressons aux
problèmes de redondances et de hiérarchie des rôles. Cette tâche correspond à la vérification
des permissions. Cette dernière (vérification) établit les tâches des rôles, ainsi que les
utilisateurs impliqués dans ces rôles.
Deux rôles sont identiques si, et seulement si, leurs ensembles de permissions assignés sont
égaux, ainsi que les utilisateurs affectés; les rôles (redondants) générés ne sont pas supprimés.
L’étape suivante est l’identification des rôles père et fils. Pour cette activité, deux rôles r1 et
r2 de l’ensemble des rôles sont en hiérarchie si l’ensemble des permissions de l’un des rôles
(soit r1: le père) est inclus dans l’ensemble des permissions de l’autre (soit r2: le fils) et les
utilisateurs affectés à r2 sont inclus dans l’ensemble des utilisateurs affectés à r1.
5.2.4.1. Fragment d’algorithme associé
Fonction Fct_Identique (mat : matrice [] [] en entier, n, z, e : entier) : Booléen ;
Variables
k ,s: entier
75
Chapitre III Conception et analyse
Début
Pour chaque k ← 0 à n faire Si ((mat[z] [k] = mat [e] [k]) alors s←s+1;
Si (s = n) alors Fct_Identique ← true
Sinon Fct_Identique ← false ;
Fin
Fonction Fct_inclus (mat : matrice [] [] en entier, n, z, e : entier) : Booléen
Variables
k: entier
Début
Fct_inclus = true
Pour chaque k ← 0 à n faire Si (mat[z] [k]=0) alors
Si (mat [e] [k] =1) alors
Fct_inclus ←false ;
Fin
• Si deux rôles sont identiques :
Identique : booléen ;
S, i, j, l, m : entier ;
m ← 0 ;
Pour chaque i ← 0 à nbrôle faire Début Pour chaque j ← i+1 à nbrôle faire Début
S←0 ;
Si (Fct_Identique (role-permi, Nbrpermission, i, j)) alors
Si ((Fct_Identique (User-Rôle, NbrUser, i, j)) alors
Début
Identique [0] [m] ← i ;
Identique [1] [m] ← j ;
m ← m+1 ;
Fin Si
76
Chapitre III Conception et analyse
Fin Pour (j)
Fin Pour (i)
• Pour détecter l’inclusion
Pour chaque i ← 0 à nbrôle faire Début Pour chaque j ← j+1 à nbrôle faire
Début
Inclus= true
si←0 ;
sj←0 ;
Pour chaque k← 0 à Nbrpermission faire Début si ← rôle-permi[i] [k] + s ;
sj ← rôle-permi[j] [k] + s ;
Fin Pour (k)
Si (si >sj) alors
Si (Fct_inclus (rôle-permi, Nbrpermission, i, j)) alors
Si (Fct_inclus (User-Rôle, NbrUser, i, j)) alors
Inclus ← false ;
Si non
Si (Fct_inclus (rôle-permi, Nbrpermission, j, i)) alors
Si (Fct_inclus (User-Rôle, NbrUser, j, i)) alors
Inclus ← false ;
Si (inclus) alors Rôle-Rôle [j] [i] ← 1 ;
Fin Pour (j)
Fin Pour (i)
Fin
77
Chapitre III Conception et analyse
5.3. Instanciation de la Politique de Contrôle d’Accès
La politique de contrôle d’accès se spécifie à travers l’instanciation des différentes contraintes
à différents niveaux. Ces contraintes concernent les séparations des devoirs statiques et
dynamiques, les pré-requis et les cardinalités.
La définition d’une contrainte dans notre modèle de conception revient à instancier une
relation entre deux éléments de même nature.
Dans notre approche, les rôles pré-requis peuvent être induits directement du modèle
d’application. Ils seront ainsi pris en compte, lors de cette étape, par l’instanciation de la
relation pré-requise, mais l’utilisateur peut en déclarer d’autres (relations pré-requises).
5.3.1. Algorithmes associé
• Si deux permissions p1 et p2 sont en SSD :
i← Cherchez indice (permission, p1, Nbrpermission) ;
j←Cherchez indice (permission, p2, Nbrpermission) ;
SSD_P [i] [j] = 1 ;
• Si deux rôles r1 et r2 sont en SSD:
I← CherchezIndice (Rôle, r1, nbrôle) ;
J← CherchezIndice (Rôle, r2, nbrôle) ;
SSD_R [i] [j] ← 1;
• Si deux Acteurs ac1 et ac2 sont en SSD :
I←CherchezIndice (Acteur, ac1, nbrActeur) ;
J← CherchezIndice (Acteur, ac2, nbrActeur) ;
SSD_A [i] [j] ← 1 ;
• Si deux rôles r1 et r2 sont en DSD :
I← Cherchez indice (Rôle, r1, nbrole) ;
J← Cherchez indice (Rôle, r2, nbrole) ;
DSD_R [i] [j] ←1 ;
• Si deux acteurs ac1 et ac2 sont en DSD :
I= Cherchez indice (Acteur, ac1, nbrActeur) ;
J= Cherchez indice (Acteur, ac2, nbrActeur) ;
DSD_A [i] [j] ←1 ;
• Si deux rôles r1 et r2 sont en pré requis :
I= Cherchez indice (Rôle, r1, nbrôle) ;
78
Chapitre III Conception et analyse
J← Cherchez indice (Rôle, r2, nbrôle) ;
Préreq_Role [i] [j] ← 1 ;
• Si deux permissions p1 et p2 sont en pré-requis :
I← Cherchez indice (permission, p1, Nbrpermission) ;
J← Cherchez indice (permission, p2, Nbrpermission) ;
Préreq_perm [i] [j] ← 1 ;
5.4. Détection de l’incohérence
La détection des incohérences passe par plusieurs étapes: ces étapes sont regroupées
séquentiellement en cinq niveaux.
Le choix de ces niveaux, dans notre modèle de conception, est lié aux phases qui permettent à
un utilisateur d’accéder à des permissions. Ainsi, un utilisateur devient un acteur dans un
système, un acteur joue un ou plusieurs rôles, le rôle permet l’accès aux permissions : de cette
manière, on analyse la sécurité à chaque phase.
Dans la figure 7, nous montrons comment procéder à l’analyse de l’application.
L’analyse passe par:
1. Niveau Rôle-Permission: à ce niveau, on contrôle les SSD et les pré-requis permission, on
a retiré les DSD car, dans notre modèle, les permissions n’ont pas de lien direct avec les
sessions.
2. Niveau Rôle-Rôle: à ce niveau, on contrôle les SSD, DSD et les rôles pré-requis mais,
avant ces étapes, une propagation de contraintes de permissions est exécutée. Lorsqu’il existe
une contrainte entre deux permissions, et qu’elles appartiennent à deux rôles différents, alors
ces deux rôles héritent la contrainte de ces deux permissions, mais la réciproque est fausse.
3. Niveau Rôle-Acteur: dans cette phase, on contrôle les SSD, DSD et les rôles pré-requis,
ainsi que les cardinalités (limitation du nombre de rôles que peut jouer un acteur).
4. Niveau Acteur-Acteur: dans cette étape, on commence par la propagation des contraintes
comme décrite précédemment (niveau 2), ensuite les contraintes seront vérifiées.
79
Chapitre III Conception et analyse
5. Niveau Utilisateur-Acteur: dans cette phase les contraintes de SSD, DSD et la cardinalité
sont vérifiées. La contrainte d’Acteur pré-requis n’existe pas parce que la relation n’existe pas
dans le méta-modèle UML. Si cette relation est violée au niveau rôle, alors elle sera détectée à
un niveau plus bas.
5.4.1. Propagation
Dans la définition de la politique de contrôle d’accès, on est amené à définir des contraintes à
différents niveaux dans le modèle de conception. Ces contraintes doivent être propagées à un
niveau supérieur dans le modèle. En effet, notre recherche se limite à plus de deux niveaux
(Ex : acteur-rôle), ainsi la propagation se produit comme suite:
Utilisateur -Acteur
Acteur -Acteur Rôle -Permission
Rôle -Rôle Acteur - Rôle
Vérification
Vérification SSD
Vérification DSD
Figure 8. Architecture de Détection de l’incohérence.
Contraintes Propagées
Contrainte Propagée
SSD
Vérification Pré-réquiste Permission
Vérification Cardinalité
Vérification SSD
Vérification DSD
Vérification Pré-réquiste Rôle
Vérification Cardinalité
Vérification SSD
Vérification SSD
Vérification DSD
Vérification Vérification DSD
Cardinalité
80
Chapitre III Conception et analyse
_ Si deux permissions sont en SSD, alors les rôles qui leur sont affectés seront en SSD.
_ Si deux rôles sont en SSD, alors les acteurs qui les représentent seront en SSD.
_ Si deux rôles sont en DSD, alors les acteurs qui les représentent seront en DSD.
5.4.1.1. Fragment d’algorithme Associé :
Fonction Fct_ Propagation (mat : matrice [][] en entier, n, z, e : entier ; var : Cmat: matrice [] [] en
entier)
Variable
k, m : entier ;
Début
Pour tous k ← 0 à n faire Si (mat[k] [z] = 1) alors
Pour tous m ← 0 à n faire Si (mat[m] [e] = 1) alors Cmat [m][k] ← 1 ;
Si non si (mat[k] [e] = 1) alors
Pour tous m ← 0 à n faire Si (mat[m] [z] = 1) alors Cmat [m][k] ←1 ;
Fin
• Algorithme de propagation des contraintes SSD des permissions vers les rôles :
Pour tous i ← 0 à Nbrpermission faire
Figure 9. Propagation des contraintes.
r1 : Rôle
p1 : Permission p2 : PermissionSSD permission
r2 : Rôle RolePerm RolePerm
SSD Rôle a1 : Acteur a2 : ActeurSSD Acteur Représente
Représente
r1:Rôle r2: Rôle SSD Role
a1 : Acteur a2 : ActeurDSD ActeurReprésente
Représente
r1:Rôle r2: Rôle DSD Role
81
Chapitre III Conception et analyse
Pour tous j ← 0 à Nbrpermission faire Si (SSD_P [i] [j] = 1) alors
Fct_ Propagation (rôle-permi, nbrôle, i, j, SSD_R) ;
• Algorithme de propagation des contraintes SSD des Rôles vers les acteurs :
Pour tous i ← 0 à nbrôle faire Pour tous j ← 0 à nbrôle faire Si (SSD_R [i] [j] = 1) alors
Fct_ Propagation (Ac- Rôle, nbrôle, i, j, SSD_A) ;
• Algorithme de propagation des contraintes DSD des Rôles vers les Acteurs :
Pour tous i ← 0 à nbrôle faire Pour tous j ← 0 à nbrôle faire Si (DSD_R [i] [j] = 1) alors
Fct_ Propagation (Ac- Rôle, nbrôle, i, j, DSD_A) ;
5.4.2. Définition des contraintes
Dans ce qui suit, nous définissons les contraintes par type (SSD, DSD, Pré-requis), par niveau
et selon l’architecture proposée dans la figure 8.
5.4.2. a. Séparation statique des devoirs
5.4.2. a.1. User-Acteur : Les contraintes sont violées si :
(u, ac1) et (u, ac2) Є UA et (ac1, ac2) Є SSD
u :User
UserAffectAct UserAffectAct
a1: Acteur a2: ActeurSSD Acteur
Figure 10. Utilisation du diagramme d’objets template pour montrer SSD acteur violation.
82
Chapitre III Conception et analyse
5.4.2. a .2. Acteur-Acteur
Les contraintes sont violées si:
1. l’acteur a1 généralise a2 et (a1, a2) Є SSD
2. deux acteurs parents a1 et a2 d’un même fils a3 et (a1, a2) Є SSD
a: Acteur
ActeurHierachie ActeurHierachie
ActeurHierachie a1 : Acteur a2 : Acteur a1 : Acteur a2 : Acteur
SSD Acteur SSD Acteur
Figure 11. Utilisation du diagramme d’objets template pour montrer SSD acteur violation.
5.4.2. a.3. Acteur-Rôle :
Les contraintes sont violées si:
r1 Є represented (Aci), r2 Є represented (Aci)/ (r1, r2) Є SSD
a1 : Acteur
Représente Représente
r1: Rôle r2:RôleSSD Acteur
Figure 12. Utilisation du diagramme d’objets template pour montrer SSD acteur et rôle violation.
5.4.2. a.4. Rôle-Rôle Les contraintes sont violées si :
1. l’acteur r1 généralise r2 et (r1, r2) Є SSD
2. deux rôles parents de r1 et r2 d’un même fils r3 et (r1, r2) Є SSD
a: Rôle RôleHiérarchie
a1 : Rôle a2 : Rôle RôleHiérarchie RôleHiérarchie
SSD Rôle a1 : Rôle a2 : Rôle
SSD Rôle Figure 13. Utilisation du diagramme d’objets template pour montrer les violations des SSD rôle.
83
Chapitre III Conception et analyse
5.4.2.a.5. Rôle –Permission Les contraintes sont violées si :
pi Є represented (Ri), pj Є represented (Rj) et (pi, pj) Є SSD r: Rôle PermAffecté PermAffecté p1 : permission P2 : permission SSD Rôle
Figure 14. Utilisation du diagramme d’objets template pour montrer les violations des SSD permission.
5.4.2.b. Séparation dynamique des devoirs 5.4.2. b.1. Utilisateur-Acteur Les contraintes sont violées si :
(u, ac1) et (u, ac2) Є UAS et (ac1, ac2) Є DSD
u :User UserAffectAct UserAffectAct
5.4.2. b.2. Acteur- Rôle Les contraintes sont violées si :
r1 Є represented (Aci), r2 Є represented (Aci) et (a1, r1) et (a2, r2) Є ARS et (r1, r2) Є DSD
a1 : Acteur
r1:Rôle r2:RôleDSD rôle
S:SessionSession Role
Représente
Session Role
Représente
Figure 15. Utilisation du diagramme d’objets template pour montrer DSD utilisateur/acteur violation.
Figure 16. Utilisation du diagramme d’objets template pour montrer DSD Acteur/Rôle
a1 : Acteur
s: SessionSessionActeur SessionActeur
a2 : ActeurDSD Acteur
84
Chapitre III Conception et analyse
5.4.2.c. Pré-requisite rôle Les contraintes sont violées dans les deux cas :
a1 : Acteur R : Rôle
5.4.2.d. Les cardinalités
Les cardinalités seront utilisées pour les restrictions, par exemple le nombre de sessions qu’un
utilisateur peut ouvrir, le nombre de rôles qui représentent un acteur, le nombre de
permissions attachées à un rôle, etc.
5.4.3. Détection Après visualisation des contraintes RBAC, une incohérence est détectée lorsqu’une entité est
en relation avec deux entités en conflits (le cas SSD et DSD), ou lorsqu’une relation avec une
entité est sans son entité pré- requise.
Aussi, nous avons développé notre recherche sur les entités qui peuvent être en relation de
généralisation successive comme le montre la figure 18:
r1:Rôle r2:Rôle
Représenté
R :Role
r1: Rôle r3:Rôle
SSD Rôle
r4:Rôle
r5:Rôle
r6:Rôle
r2:Rôle
r1: Rôle r2: Rôle r3: Rôle
SSD Rôle
Représenté Représenté
Hiérarchie Hiérarchie Hiérarchie
Hiérarchie
Hiérarchie
Hiérarchie
Figure 17. Utilisation du diagramme d’objets template pour montrer Pré-requisite Acteur/Rôle et Role/permission violation.
p1 : permission P2 : permission
PermAffecter
PrerequisitRole PrerequisitActeur
Figure18. Les violations des contraintes.
85
Chapitre III Conception et analyse
Nous avons utilisé la théorie des graphes pour déceler les incohérences statiques et
dynamiques.
Considérons les graphes initiés par les étapes précédentes, alors la recherche des incohérences
sera effectuée de deux manières selon le nombre de niveaux dans les phases de recherche :
a) Si la phase est composée de deux niveaux (Ex : Acteur–Rôle), dans ce cas, les entités
supérieures sont rattachées directement aux entités inférieures. Dans ce cas, on vérifie si deux
entités inférieures sont en conflit et rattachées à une même entité supérieure.
b) Si la phase est composée d’un seul niveau, dans ce cas, pour chacune des deux entités en
conflit, on vérifie s’il existe une relation de généralisation entre eux. C’est-à-dire que, pour
chaque paire de sommets en relation dans le graphes des contraintes (SSD, DSD), on vérifie
s’il existe une relation entre eux dans le graphe de relation.
Pour les pré-requis, nous cherchons dans la matrice des pré-requis l’existence d’un lien entre
deux sommets adébut et le sommet afin. La relation obtenue serait un pré-requis entre adébut et afin.
Ensuite, on vérifiera l’existence d’un chemin de longueur 2 entre le sommet afin et adébut dans
la matrice qui lie ces éléments avec les éléments supérieurs (Rôle-Permission). La violation
d’un pré-requis se traduit par l’inexistence de chemin.
5.4.3.1. Fragment d’algorithmes associé
Pour cette étape nous proposons les procédures suivantes :
Initialisation, Chemin–Arborescence, Détection, violation telle que :
a) Initialisation : cette procédure a pour entrée une matrice d’ordre n, et pour sortie
l’annulation de toutes les cellules de la matrice introduite.
b) Chemin-Arborescence : cette procédure a pour entrée une matrice d’adjacence d’ordre n,
et pour sortie une matrice qui contient tous les chemins à partir d’un sommet, comme suite :
1. copier la matrice d’adjacence pour tous i, j: u[i] [j] = MatAdjacence[i] [j].
2. Annuler W[n] [n], la matrice résultat de multiplication.
3. Annuler mat2 [n] [n], archive de tous les chemins.
4. Annuler f.
86
Chapitre III Conception et analyse
4. déterminer les chemins existants par le produit de la matrice d’adjacence, selon la loi :
W[i] [k] = ∑ u[i] [j] * MatAdjacence [j] [k].
5. calculer la somme : mat2 [i] [j]= mat2 [i] [j] + W[i] [j].
6. incrémenter f.
7. tant que f est inférieur à l’ordre de la matrice d’adjacence, retourner à l’étape 5.
c) Détection : cette procédure a pour entrée la matrice calculée dans la procédure (Chemin –
Arborescence) et la matrice des contraintes, et a pour sortie les erreurs.
Pour chaque nœud en contrainte, vérifier s’il appartient à la même racine.
d) Violation : cette procédure permet de contrôler, entre deux niveaux, les violations des
contraintes.
Procédure Initialisation (Mat1 matrice [] [] en entier, n : entier ; var : Mat1 matrice [] [] en
entier)
Variables
i, j :entier
Début
Pour tous i ← 0 à n faire Pour tous j ← 0 à n faire Mat1 [i] [j] ← 0 ;
Fin
Procédure Chemin -Arborescence (Mat1 : matrice [] [] en entier, n : entier ; var : Mat2
matrice [] [] en entier)
Variables
i, j, k, S,f: entier;
U, W: Matrice [n] [n] entier ;
Début
Initialisation (Mat2, n, Mat2)
Initialisation (W, n, W)
Pour tous i ←0 à n faire Pour tous j ← 0 à n faire U[i] [j] ← Mat1 [i] [j] ; (Copie de la matrice mat1 dans la matrice u)
87
Chapitre III Conception et analyse
f ← 0
Taque (f <n)
Début
Pour tous i ← 0 à n faire Début Pour tous j ← 0 à n faire Début S← 0 ; Pour tous k ← 0 à n faire Début S← S +U [i] [k] * Mat1 [k] [j] ; (Multiplication des matrices) Fin (k) W [i] [j] ← S; Fin (j) Fin (i) Pour tous i ← 0 à n faire Pour tous j ← 0 à n faire U [i] [j] ← W[i] [j];
Pour tous i ← 0 à n faire Début Pour tous j ← 0 à n faire Début
Mat2 [i] [j] ← Mat2 [i] [j] + W [i] [j]; (Addition des deux matrices)
Fin (i)
Fin (j)
F←F+1
Fin Tant que
Fin
88
Chapitre III Conception et analyse
Procédure Détection (mat2 matrice [] [] en entier, n : entier, cmat : matrice [] [] en entier ;
var Erreur matrice [] [] en entier)
Variable i, j, k, s,f: entier;
U, W: Matrice [n] [n] entier ;
Début f=0 ;
Pour tous i ← 0 à n faire Début Pour tous j ← 0 à n faire Début
Si (cmat[i] [j]=1) alors (si une contrainte existe entre i et j alors)
Pour tous k ← 0 à n faire si (mat2[k][i]>=1) et (mat2[k][j]>=1) alors
Erreur [0] [f] ←1 ; Erreur [1] [f] ← i ; Erreur [2] [f] ← j ; Erreur [3] [f] ← k; f ← f+1 ;
Fin si
Fin pour (k)
Fin si
Fin pour (j)
Fin pour (i)
Fin
Procédure violation (mat, SSD, DSD, pré: matrice [] [] d’entier ; n1, n2 : entier, var erreur :
matrice [] [] entier)
Variable
i, j, k, f en entier ; Début f=0 ; n←n1 ; a ← n2 ; Pour tous i ← 0 à n faire début Pour tous j ← 0 à n} faire début si(SSD[i][j]==1) alors début Pour tous k ← 0 à a faire début
89
Chapitre III Conception et analyse
si((mat [k][i]==1)&&(mat [k][j]==1))alors Début Erreur [0] [f] ← 1 ; Erreur [1] [f] ← i ; Erreur [2] [f] ← j ; Erreur [3] [f] ← k ; f ←f+1 ; Fin si Fin si Fin Pour (k) Si (DSD[i] [j] ==1) début Pour tous k ← 0 à a faire début if((Ac_Rôle [k][i]==1)&&(Ac_Rôle [k][j]==1)){ Erreur [0] [f] ← 2 ; Erreur [1] [f] ← i ; Erreur [2] [f] ← j ; Erreur [3] [f] ←k ; f←f+1 Fin si Fin Pour (k) Fin si if(pré[i][j]==1)début Pour tous k ← 0 à a faire if((Ac_Rôle[k][i]!=1)&&(Ac_Rôle [k][j]==1))début erreur [0][f] = 3 ; erreur [1][f] = i ; erreur [2][f] = j ; erreur [3][f]= k ; f←f+1 ; Fin si Fin Pour…. (k) Fin si Fin Pour …… (j) Fin Pour…... ..(i) Fin
• Algorithme Violation (User_Acteur, SSD_A, DSD_A, pre_A, nbrRôle, nbrActeur, erreurUA) ;
Chemin -Arborescence (R_ Acteur, nbrActeur, CR_ Acteur) ;
Détection (CR_ Acteur, nbrActeur, SSD_A, Erreur_AS) ;
Détection (CR_ Acteur, nbrActeur, DSD_A, Erreur_AD) ;
90
Chapitre III Conception et analyse
Violation (Ac- Rôle, SSD_R, DSD_R, pre_R, nbrRôle, nbrActeur, erreurAR) ;
Chemin -Arborescence (R_ Rôle, nbrRôle, CR_ Role) ;
Détection (CR_ Rôle, nbrRôle, SSD_R, Erreur_RS) ;
Détection (CR_ Rôle, nbrRôle, DSD_R, Erreur_AD) ;
Violation (Rôle_Perm, SSD_P, DSD_P, pre_P, nbrRôle, nbrPermission, erreurRP) ;
5.5. Simulation Dans cette partie, nous nous sommes intéressés à deux types de test que nous jugeons très
importants, et qui complètent notre recherche pour trouver les incohérences. Le premier est de
tester les contraintes dynamiques qui sont liées à la notion de sessions utilisées dans le
RBAC.
Notre simulation offre donc à l’utilisateur la possibilité de créer des sessions et d’activer des
rôles, comme si l’application au niveau modélisation se déroule réellement.
La deuxième étant la création de scénarios à partir des opérations, nous avons ajouté cette
simulation d’une part, pour compléter la première simulation et, d’autre part, pour approfondir
la recherche des incohérences.
Un exemple de ce que peut déceler cette simulation : la mise de deux rôles en conflit ne
signifie pas que les permissions qui les constituent le sont, mais leur séquence ment. Cela peut
être considéré comme une vulnérabilité de notre politique de contrôle d’accès. De ce fait,
notre simulation donne la possibilité de tester la politique de sécurité.
5.5.1 Simulation des contraintes dynamiques DSD
Dans cette partie nous nous sommes intéressés à la partie séparation dynamique des devoirs.
L’utilisateur de notre application introduit les modèles d’application (cas d’utilisation et
séquence) et la politique de contrôle d’accès ; de cette manière, il peut tester les contraintes.
La figure 14 montre l’utilisation de notre simulateur, ainsi on commence par la définition de
l’utilisateur qui crée une session. Une fois la session créée, l’utilisateur peut activer ou
Définir Utilisateur Définir Session Définir Rôle Contrôler contraintes
Figure 19. Processus d’utilisation de simulation.
91
Chapitre III Conception et analyse
désactiver des rôles qui lui sont rattachés. De cette manière, notre simulateur détecte les
violations commises.
5.5.1.1. Analyse
Pour notre simulation on utilise le diagramme d’objets (instance du diagramme de
conception).
Chaque fois qu’un utilisateur de notre simulation définit un utilisateur et une session, un objet
utilisateur et un objet session sont créés et mis en relation avec l’instanciation de la relation
UserSession du modèle de conception.
u1 : Utilisateur u2 : Utilisateur
Lorsque les sessions sont spécifiées, l’utilisateur de notre application peut activer ou
désactiver les rôles. A chaque rôle activé, un objet rôle est utilisé et sera rattaché à l’utilisateur
par l’instanciation de la relation <<User-rôle >>, et à l’objet session par l’instanciation de la
relation << Session Rôle>>.
Les séparations des devoirs statiques et dynamiques sont vérifiées à partir des graphes initiés
par les relations décrites précédemment (Session Rôle, User-rôle).
Aussi les cardinalités sur ces relations sont vérifiées (si le nombre d’utilisateurs utilisant le
même rôle dépasse la valeur maximum).
r1:Rôle r2:RôleDSD Acteur
S:Sessio
r3:Rôle
Session Role Session Role Session Role
Session 1 s2 : Session
UserSession 1 2 UserSession UserSession
s1 : Session s3 : Session Session 3 s4 : Session
1 2 3 UserSession UserSession
Figure 20. Création de plusieurs sessions par plusieurs utilisateurs.
Figure 21. Violation de contrainte SSD.
92
Chapitre III Conception et analyse
La procédure de détection des DSD est similaire à celle de détection des SSD. A chaque
activation un nœud est créé, à chaque désactivation un nœud est supprimé. Si l’une des
contraintes (SSD, DSD) est violée, le simulateur l’indiquera.
Pour réussir la détection de violation des contraintes, nous nous sommes appuyés sur deux
matrices.
La première concerne la séparation statique des devoirs, la matrice UserRôle est utilisée pour
indiquer que l’utilisateur a activé ou désactivé un rôle indépendamment des sessions (le cas
où l’utilisateur ouvre plusieurs sessions), cette matrice peut être utilisée aussi pour vérifier si
les cardinalités sont respectées.
La deuxième concerne la séparation dynamique des devoirs, dans ce cas la matrice session
indiquera les rôles qui sont activés ou désactivés au sein d’une session et par un utilisateur;
cette matrice peut être utilisée aussi pour vérifier les rôles pré-requis (si le rôle est activé
avant son rôle pré-requis).
5.5.1.2. Fragment d’algorithme Associé
Soit la création d’une session s1 par l’utilisateur Ui
Lire (Session [i]. Nom) ;
• Et l’activation d’un rôle rm :
SessionRole [i] [m] ← 1 ;
• la désactivation du rôle rj, qui était déjà activé :
SessionRole [i] [j] ← 0 ;
• Les incohérences sont détectées : Violation (SessionRole, SSD_A, DSD_A, pre_A, nbrRôle, nbrActeur) ;
Introduire user Définir Scénario Créer session
Vérifier contrainte
Figure 22. Processus Génération de scénario.
93
Chapitre III Conception et analyse
5.5.2. Génération des scénarios
Les scénarios, modélisés par le diagramme de séquence, sont représentés par une séquence
d’opérations.
Cette partie du simulateur offre la possibilité de regrouper ces opérations pour définir des
scénarios, le cas idéal pour nous serait que ces scénarios représentent des menaces.
Nous nous sommes inspirés de [3] qui a modélisé les menaces sous forme de diagramme de
séquence, en utilisant les opérations pour détecter, au niveau de l’exécution, les menaces
envers le système.
Dans le simulateur, l’utilisateur introduit une séquence d’opérations (menaces) pour s’assurer
de l’efficacité de notre politique à prévenir toute menace. Dans ce cas, à chaque session,
l’utilisateur de notre application peut créer des scénarios à partir des opérations déjà
existantes.
5.5.2.1. Analyse
Le simulateur offre à l’utilisateur la possibilité d’ordonner tout ou partie des opérations qui
sont introduites dans le modèle de conception.
L’utilisateur commence par nommer un scénario et, à chaque scénario, est lié un ensemble
d’opérations.
A chaque fois que l’utilisateur ajoute une opération, un objet est créé et, par conséquent,
l’utilisateur peut générer ses scénarios. L’objet opération est détruit lorsque l’utilisateur
supprime une opération.
Chaque opération d’accès sera traitée comme permission, ainsi des objets permission sont
créés, cela est dû aux contraintes (au niveau permissions) qui sont définies dans le modèle
RBAC, les objets permissions étant liés à leurs objets utilisateurs. Ainsi, on obtient une
arborescence où l’utilisateur sera la racine.
Les contraintes, de type DSD ou SDD entre les permissions, seront introduites sous forme de
relations (instanciation d’une relation SDD ou DSD dans le modèle de conception). On aura
ainsi la création de cycles.
5.6. Génération du code Dans ce qui suit, nous montrerons comment transformer les éléments du modèle de
conception en un système EJB exécutable.
94
Chapitre III Conception et analyse
Dans un premier temps, nous nous sommes intéressés à la génération du code lié à
l’application.
5.6.1. Génération basique des règles pour l’ EJB
La génération basique définit les entités, attributs, les méthodes, et les associations. Le résultat
de la transformation est un fragment de code source écrit dans une syntaxe concrète de la
plateforme EJB, en code source Java ou en XML dans le descripteur de déploiement.
Une entité est transformée en un composant EJB de type entité bean avec toutes les interfaces
nécessaires et les implémentations de classe, ainsi une méthode <créer> est générée pour la
création d’une instance de cette entité. Le composant lui-même est défini par une entrée dans
le descripteur de déploiement de type entité comme le montre le fragment de code suivant:
<entity> <ejb-name> < /ejb-name > <local-home> < / local-home > <local> < / local > <ejb-class> < /ejb-class > ….. </entity>
Une méthode est transformée en une déclaration de méthode dans l’interface du composant de
l’entité bean et, dans le stub méthode, dans l’implémentation de la classe correspondante.
1) Pour chaque attribut, des méthodes d’accès en lecture et écriture sont générées pour la
manipulation des valeurs des attributs des informations persistantes qui sont utilisées dans le
serveur d’application. Ce dernier détermine comment est stockée la valeur de l’attribut dans la
base de données.
2) Les éléments d’associations sont analogues à ceux des attributs, une méthode d’accès est
générée pour la lecture des objets d’association (pour l’ajout ou la suppression d’un objet à
une association).
5.6.2. Génération de l’infrastructure des contrôles d’accès
Nous définissons les règles qui translatent le modèle de conception à un EJB sécurisé qui est
basé sur la déclaration et sur la programmation.
95
Chapitre III Conception et analyse
Chaque permission est translatée en un élément XML équivalent de type : <méthode-permission>, utilisé pour la partie déclaration du contrôle d’accès de l’EJB. Cette partie
permet de renforcer la partie statique de la politique de contrôle d’accès.
Notre modèle ne prend pas en considération la partie contrainte d’autorisation qui est source
de la partie programmation décrite dans [15]. Cette dernière n’a pas été développée.
5.6.3. Génération des permissions
La génération des méthodes de permission peut être divisée en deux parties : générer des
acteurs et leur assigner des méthodes.
EJB ne supporte pas la hiérarchie des Acteurs, ainsi les acteurs père sont liés directement
aux permissions, alors que les Acteurs fils sont liés à ces permissions par héritage
(indirectement).
Les permissions liées à un acteur sont définies par composition de relation, comme le montre
la formule ci-dessous dans le modèle de conception.
Soient les ensembles Acteurs, Cas d’utilisation, Séquences, Opérations, Permissions qui
représentent respectivement les acteurs, les cas d’utilisations, les séquences, les opérations et
les permissions.
Soient :
AU ⊂ (Acteur x Cas d’utilisation) : un ensemble de couples (Acteur, cas d’utilisation) qui
existe dans le modèle de conception.
US ⊂ (Cas d’utilisation x Séquence) : un ensemble de couples (cas d’utilisation, Séquence)
qui existe dans le modèle de conception.
SO ⊂ (Séquence x Opération) : un ensemble de couples (Séquence x opération) qui existe
dans le modèle de conception.
OP ⊂ Opération x Permission: un ensemble de couples (opération, permission) qui existe
dans le modèle de conception.
La formule de décision d’accès sera formulée comme suite:
ac1, ac2 Є Acteur uc1, uc2 Є Cas d’utilisation, op1, op2 Є Opération, p Є Permission
Access (ac1, p) = ac1 ≥ acteur ac2 ^ AU (ac2, uc1) uc1 ≥ Cas d’utilisation uc2 ^
US (uc2, s1) ^ SO (s, op1) op1 ≥ Operation op2 ^ OP (op1, p).
Finalement pour chaque Acteur élément dans cet ensemble, un élément
96
Chapitre III Conception et analyse
role-name est généré
< role-name > nom du Acteur </role-name>
L’ensemble des méthodes est généré par chaque permission comme suite : premièrement,
pour chaque permission, on détermine l’ensemble des opérations qui sont directement liées
par l’association <OperationAssignement>. Deuxièmement, pour chaque opération dans
l’ensemble des opérations, on détermine les opérations filles, et on les ajoute dans le même
ensemble.
5.6.4. Analyse La figure ci-dessous représente le diagramme d’activités qui définit le processus pour la
génération du code par les activités suivantes :
97
Chapitre III Conception et analyse
1. La propagation des permissions (le problème cité dans 5.6.3) :
a. Identifier les permissions d’un acteur père aci par composition.
b. Identifier les acteurs fils de l’acteur père acj.
c. assigner les permissions induites de l’étape a aux acteurs induits de l’étape b.
2. Identifier un acteur et générer du code :
a. Identifier tous les acteurs
b. Pour chaque acteur une déclaration dans le fichier XML est définie de type
<security-role>
<description/>
Identifier méthode permission
Identifier un nouveau Acteur
Générer Code Approprié
[Non Terminé]
[Terminé]
Identifier un Acteur
Assigner les méthodes
[Non Terminé]
[Terminé]
Propagation des permissions
Figure 23. Diagramme d’activités pour la génération de code.
98
Chapitre III Conception et analyse
<role-name> nom acteur <role-name>
<security-role>
3. Identifier Méthode permission : pour chaque acteur une méthode permission est
générée qui contient toutes les méthodes qui lui sont accessibles.
4. Sous la forme générale :
<method-permission>
<role-name>Nom Acteur </role-name>
<method>
<ejb-name>nom de la Classe </ejb-name>
<method-name> nom Opération </method-name>
</method>
< method-permission >
4. Assigner les méthodes :
Réalisée par l’ajout de l’assertion suivante pour chaque opération accessible pour un
acteur dans le corps de la <mehode-permission>
<method>
<ejb-name>Gradebook</ejb-name>
<method-name> getGrade </method-name>
</method>
6. Conclusion Au départ, notre idée était d’introduire directement les contraintes dans le modèle
d’application sans recourir au modèle RBAC. Ce point de vue était inexact dans le sens où,
premièrement, les contraintes dynamiques ne pouvaient pas être représentées, deuxièmement
parfois les contraintes de la politique de contrôle d’accès sont exprimées en des termes qui
n’ont pas le même niveau d’abstraction que le modèle d’application.
Pour mener à bien notre projet, nous sommes passés par plusieurs étapes :
La première étape était l’ingénierie des éléments du modèle RBAC. Ces éléments sont les
utilisateurs, les rôles et les permissions. Pour ces deux derniers éléments, nous avons proposé
une méthodologie qui permet de les induire.
La deuxième étape concerne l’introduction de la politique de contrôle d’accès sous forme de
contraintes RBAC.
99
Chapitre III Conception et analyse
La troisième étape vise la détection de l’incohérence, nous avons divisé notre modèle
d’application en plusieurs phases où chaque phase correspond à deux entités en relation dans
le modèle d’application (de l’utilisateur jusqu à la permission)
La quatrième étape permet de déceler les incohérences des contraintes dynamiques et les
vulnérabilités de la politique de contrôle d’accès.
Dans ce chapitre nous avons présenté la conception et l’analyse qui représentera la solution la
plus judicieuse du contrôle d’accès au niveau spécification fonctionnelle d’une application,
car nous avons combiné les modèles les plus utilisés dans le domaine de la sécurité (RBAC)
et le modèle d’application (UML). Cette approche sera modélisée dans le prochain chapitre.
100
Chapitre IV Modélisation
1. Description du processus
En procédant à la modélisation de cette application, nous avons utilisé que quatre diagrammes
parmi les neuf (diagrammes) proposés par le langage UML. Ce choix nous a suffi pour bien
modéliser notre application, il nous a permis de présenter les trois principales vues proposées
par UML : la vue statique, la vue fonctionnelle et la vue dynamique à travers respectivement
les aspects suivants :
• Aspect fonctionnel : diagramme de cas d’utilisation.
• Aspect statique : diagramme de classes.
• Aspect dynamique : diagramme d’activités et diagramme de séquence.
Lors de la conception, nous avons entrepris une démarche basée sur le processus RUP. Dans
ce qui suit, nous allons détailler les différents workflows dont nous nous sommes servis :
• L’analyse des besoins
• La spécification des cas d’utilisation
• La spécification détaillée des exigences
L’analyse est définie en trois étapes
• La spécification des diagrammes de classes d’analyse
• La spécification des diagrammes d’interaction
• La spécification des diagrammes d’activités de navigation
La conception est définie en une seule étape
• La spécification des diagrammes de classes de conception
L’implémentation et les tests: (Chapitre 5)
• La génération du code.
2. L’analyse des besoins
La collecte, l’analyse, la définition des besoins de haut niveau et des caractéristiques de notre
application permettent d’offrir à l’utilisateur un moyen de spécifier les éléments du modèle
RBAC, de vérifier la cohérence de la politique de sécurité avec les exigences de l’application,
de simuler à travers la création de sessions et de scénarios et, enfin, de générer du code. Ces
102
Chapitre IV Modélisation
quatre étapes nous permettent d’atteindre l’objectif de notre application et d’avoir un
ensemble d’outils capables de contrôler l’accès dès les premières phases du développement
de l’application.
2.1 Spécification des cas d’utilisation
Dans cette partie nous allons spécifier les exigences de notre application, en particulier les cas
d’utilisation.
Avant d’entamer notre modèle de cas d’utilisation, nous devons :
• Identifier les cas d’utilisation
• Ajouter des relations entre les cas d’utilisation
2.1. a) Identification des cas d’utilisations
103
Chapitre IV Modélisation
1. Introduire des éléments d’applications : ce cas d’utilisation regroupe toutes les
données introduites par l’utilisateur final de notre application, cela concerne la définition
des éléments du modèle d’application, la définition des éléments du modèle RBAC, ainsi
que la spécification des contraintes
2. Introduire les éléments des diagrammes : ce cas d’utilisation offre la possibilité aux
utilisateurs d’introduire les éléments résultants de leur collecte des besoins tels que les cas
d’utilisation et les Acteurs, etc. Cette possibilité s’effectue directement en saisissant leurs
noms et leurs relations.
3. Définir les éléments de RBAC : ce cas d’utilisation à pour objectif de définir les
éléments du modèle RBAC. Nous avons proposé trois possibilités pour ingénierie des
rôles, qui ont comme base les éléments du modèle d’application (introduit dans la section
1), ce qui explique <<Extend>> entre ces deux cas < Introduire les éléments des
diagrammes > et < Définir les éléments de RBAC>
4. Spécifier les contraintes : il permet d’introduire la politique de contrôle d’accès sous
forme de contraintes. La politique de contrôle d’accès est obtenue en définissant les règles
et les restrictions d’accès des différents éléments du modèle.
Spécifier les Contraintes
Définir les éléments de RBAC
Introduire les éléments d’application
Vérification de cohérence
Introduire les éléments des diagrammes
<<Include >>
<<Extend >>
<<Include >>
Simulation
<<Extend >> <<Include >>
Utilisateur
<<Extend >>
<<Extend >>
Génération du Code
Figure1. Vue de haut niveau des cas d’utilisation de l’application.
104
Chapitre IV Modélisation
5. Vérification de la cohérence : le but de ce cas d’utilisation est de vérifier la cohérence
des relations entre éléments du modèle d’application (cas d’utilisation 1) avec la politique
de sécurité introduite par la définition des contraintes (cas d’utilisation 3) .Cette vérification
s’effectue en utilisant le diagramme d’objets template
6. Simulation : ce cas d’utilisation offre aux utilisateurs de notre application la possibilité
de tester l’efficacité de leur politique de sécurité, en donnant la possibilité de changer les
paramètres du modèle tels que : créer des sessions ainsi que l’Activation /Désactivation des
rôles, faire varier les opérations d’un rôle, etc.
7. Génération du code : l’objectif de ce cas d’utilisation est de générer un code exécutable,
écrit dans un langage de programmation JAVA (langage très répandu au niveau des articles
les plus récents)
Définir Acteur
1. Définir Acteur : ce cas d’utilisation permet de définir les acteurs en introduisant leur
nom; ce cas d’utilisation regroupe aussi toutes les opérations élémentaires (telles que la
modification, la suppression, etc.) d’un acteur à ce niveau.
2. Définir cas d’utilisation : ce cas d’utilisation à pour objectif la définition d’un cas
d’utilisation en introduisant son nom, ce cas d’utilisation regroupe aussi toutes les opérations
Définir cas d’utilisation
Définir relation entre C.U et Acteur
Définir Relation entre C.U
Définir Séquence d’opérations
Définir Relation entre Acteur
<<Extend>> <<Extend>>
<<Include>>
<<Extend>>
<<Extend>>
Figure2. Vue de haut niveau des cas d’utilisation et introduction des éléments du modèle d’application.
105
Chapitre IV Modélisation
élémentaires (telles que la modification, la suppression, etc.) d’un cas d’utilisation à ce
niveau.
Toutefois, un cas d’utilisation peut inclure un ou plusieurs scénarios qui sont représentés par
une séquence d’opérations dans le diagramme de séquences
3. Définir la séquence d’opération : le but de ce cas d’utilisation est de permettre
l’introduction des opérations selon leur ordre séquentiel, c’est-à-dire un scénario parmi ceux
que peut représenter un cas d’utilisation
4. Définir relation entre C.U et Acteur : l’objectif de ce cas d’utilisation est de donner aux
utilisateurs de cas d’utilisation la possibilité de mettre en relation tous les cas d’utilisation du
modèle avec leurs acteurs correspondants dans le modèle. Ce cas d’utilisation regroupe aussi
toutes les opérations élémentaires (telles que la modification, la suppression, etc.) d’une
relation.
5. Définir Relation entre C.U : l’objectif de ce cas d’utilisation est d’offrir aux utilisateurs
des cas d’utilisation la possibilité de mettre en relation tous les cas d’utilisation introduits
dans le modèle, en prenant en considération tous les types de relation utilisés <<Include>>,
<<Extend>>, <<Généralization>>, ce cas d’utilisation regroupe aussi toutes les opérations
élémentaires (telles que la modification, la suppression, etc.) d’une relation.
6. Définir Relation entre Acteurs : l’objectif de ce cas d’utilisation est d’offrir aux
utilisateurs des cas d’utilisation la possibilité de mettre en relation tous les Acteurs du
modèle, en prenant en considération les <<Généralization>>, ce cas d’utilisation regroupe
aussi toutes les opérations élémentaires (telles que la modification, la suppression, etc.) d’une
relation.
<<Include>>Définir Rôle Définition Acteur
Définition à partir C.U
Définition C.U et acteur
Définir des permissions
Définition Séquence Opérations
Définir des Users
<<Include>>
<<Extend>><<Include>>
<<Include>>
Figure3. Vue de haut niveau des cas d’utilisation et définition des éléments du modèle RBAC.
106
Chapitre IV Modélisation
1. Définir Rôle : ce cas d’utilisation à pour but d’introduire les rôles. Dans notre approche,
nous avons constaté trois manières différentes d’extraire ces rôles, soit à partir des acteurs,
soit à partir des cas d’utilisation ou à partir des cas d’utilisations et acteurs. Par conséquent,
on inclut les cas d’utilisation qui définissent ces rôles.
2. Définir les permissions : ce cas d’utilisation à pour but de définir les permissions. Dans
notre approche, on déduit les permissions à partir des opérations utilisées dans les séquences.
3. Définir les Utilisateurs : ce cas d’utilisation permet d’introduire les utilisateurs à qui sont
assignés différents rôles, ce cas d’utilisation regroupe aussi toutes les opérations élémentaires
(telles que la modification, la suppression, etc.) des utilisateurs.
<<Include>> Définir SSD
1. Définir SSD : ce cas d’utilisation permet d’introduire les séparations statiques des devoirs
entre les rôles et les permissions, en introduisant une exclusion entre ces deux entités.
2. Définir DSD : l’objectif de ce cas d’utilisation est d’introduire les séparations dynamiques
des devoirs entre les rôles et les permissions en introduisant une exclusion entre ces deux
entités.
3. Définir Pre-Requisite Rôle : le but de ce cas d’utilisation est d’introduire les pré-requis
des devoirs entre les rôles et les permissions
4. Définir cardinalité : ce cas d’utilisation offre à l’utilisateur la possibilité de définir les
cardinalités sur les objets.
Définir DSD
Définir Pre-Requisite Rôle
Définir cardinalité
Définition des rôles
Définition des Acteurs
<<Include>>
<<Include>> <<Include>>
<<Include>>
<<Include>>
Définition des relations
<<Include>>
Figure 4. Vue de haut niveau des cas d’utilisation Spécification des contraintes.
107
Chapitre IV Modélisation
Vérifier SSD
Vérifier DSD
Introduire les éléments d’application
Vérifier Pre- requisite Rôle
Vérifier cardinalité
Figure 5. Vue de haut niveau des cas d’utilisation contrôle de 1. Vérifier SSD : ce cas d’utilisation vise à contrôler si une contrainte de séparation statique
des devoirs existe dans le modèle d’application introduit par l’utilisateur, on l’obtient par le
contrôle au niveau des éléments du modèle RBAC, puis au niveau des éléments du modèle
d’application.
2. Vérifier DSD : ce cas d’utilisation vise à contrôler si une contrainte de séparation
dynamique des devoirs existe dans le modèle d’application introduit par l’utilisateur, on
l’obtient par le contrôle au niveau des éléments du modèle RBAC, puis au niveau des
éléments du modèle d’application.
3. Vérifier Pre-requisite Role : ce cas d’utilisation vise à contrôler si une contrainte de Pré-
réquis des devoirs existe dans le modèle d’application introduit par l’utilisateur, on l’obtient
par le contrôle au niveau des éléments du modèle RBAC, puis au niveau des éléments du
modèle d’application
4. Vérifier relation : les cardinalités peuvent être utilisées comme un moyen de restriction
d’accès à un nombre prédéfini d’objets, ce cas d’utilisation permet de vérifier le respect de
cette contrainte (ex : nombre de rôles que représente l’acteur)
108
Chapitre IV Modélisation
3. L’analyse :
L’analyse est le processus qui, en partant de l’examen des besoins, produit un modèle
conceptuel du système à développer.
L’analyse d’un cas d’utilisation consiste à élaborer ses diagrammes de séquence et ses
diagrammes de classes avec des objets d’analyse. Les objets d’analyse sont des instances de
classes d’analyse qui représentent des éléments majeurs ayant des comportements et des
responsabilités dans le système. Il est recommandé de donner aux cas d’utilisation un sens en
utilisant le langage du domaine d’application
Les classes d’analyse peuvent être reparties en trois catégories :
Les classes Interface, Entité et de Contrôle
Les classes Interface : elles représentent les objets des interfaces entre acteur et système. Les
exemples classiques sont les écrans de saisie, etc.
Les classes Entité : ce sont les objets décrits dans les cas d’utilisation et qui représentent les
objets persistants.
Les classes de Contrôle : elles représentent les objets qui sont des activités système assez
significatives pour être nommées, telles que les vérifications, les suppressions, les mises à
jours et, enfin, les modifications…
Comme toutes les classes, ces classes d’analyse entretiennent des relations qui sont illustrées
dans les diagrammes de classes, où les acteurs peuvent aussi être représentés pour spécifier
les rôles propres aux interfaces de ces diagrammes. Les associations entre objets obéissent
aux règles ci-dessous
• Les acteurs n’interagissent qu’avec les objets interfaces
• Les objets entités n’interagissent qu’avec des objets contrôles
• Les objets contrôle interagissent avec tous les objets
3.1. Spécification des diagrammes de classes
Avant de passer aux diagrammes d’analyse, il faut introduire les concepts fondamentaux
d’UML, à savoir les classes, les associations et les attributs pour la modélisation du domaine.
Pour aboutir à cette modélisation, nous devons :
109
Chapitre IV Modélisation
• Identifier les classes.
• Identifier les relations entre les classes.
• Identifier les associations entre les classes.
En prenant les cas d’utilisation un par un, nous avons essayé d’identifier les classes
participantes. Une fois les classes identifiées, nous avons ajouté les attributs et les
associations nécessaires pour répondre aux besoins d’informations.
110
Chapitre IV Modélisation
<<Interface>> Utilisateur PageActeur
Public String Nom
Public AfficherBoiteActeur() Public AjouterAscendant () Public SupprimerAscendant() Public AjouterDescendant () <<Contrôle>> Public SupprimerDescendant() Public AffecterC.U() ControleActeur
Public Ascendant () Public descendant () Public String Cas d’utilisation [0..50] Public VérfierExistance() Public MiseAjoursN Public ChercherN Public AjouterAscendant <<Interface>> Public AjouterAscendant ()
¨Page-Cas d’utilisation Public SupprimerAscendant() Public AjouterDescendant ()
Public String Cas d’utilisation Public SupprimerDescendant() Public AjouterAscendant ()
<<Interface>> Public SupprimerAscendant() Page-Opération Public AjouterInclude ()
Public SupprimerInclude () Public AjouterExtend () Public String Nom Public SupprimerExtend() Public int N Public AjouterDescendant () Public SupprimerDescendant() Public AffecterC.U()
Public OpVar() Public EffecterCU()
Public Ascendant () Public EffecterSeq() Public AffecterNum() Public descendant ()
<<Contrôle>> ControleCas d’utilisation
Public String Cas d’utilisation [0..50]
<<Contrôle>> ControleOpération Public VérfierExistance()
Public MiseAjoursN Public String Operation Public ChercherN Public AjouterAscendant Public MiseAjoursN() Public AjouterAscendant () Public ChercherN() Public SupprimerAscendant() Public AjouterVariableOperation() Public AjouterDescendant () Public AjouterVariableOperation () Public SupprimerDescendant()
Public AjouterInclude () Public SupprimerInclude() Public AjouterExtend () Public SupprimerExtend ()
<<Entité>> Cas utilisation <<Entité>>
Opération <<Entité>> Public String Role [50] Acteur Public String Operation [50] Public static String relation [50][50]
Public static String relation [50][50] Public ajouterCU () Public String Acteur [50] Public ajouterOp () Public supprimerCU() Public static String relation [50][50] Public supprimerOp() Public ajouterRelation () Public ajouterRelation () Public supprimerRelation () Public ajouterAC () Public supprimerRelation Public supprimerAC()
Public ajouterRelation () Public supprimerRelation ()
Figure 6. Diagramme de classes d’analyse des cas d’utilisation ‘Introduire des éléments de l’application’.
111
Chapitre IV Modélisation
Utilisateur <<Interface>> Page SpeficationRBAC
InitierRole(Acteur) InitierRole(CasUtilisation) InitierRole(Ac-CU) InitierPermission() InitierUser()
<<Interface>> <<Interface>> <<Interface>> RoleActeur RoleCU RoleAC/UC
Public AfficherListeActeur() Public AfficherListeActeur() Public DéfinirRelation () Public IntroduireRôle() Public IntroduireRôle() Public AffecterRôleCU() Public AffecterRôleActeur() Public DifinirTache () Public DéfinirRelation () Public DéfinirRelation ()
<<Contrôle>> ContrôleRole <<Entité>>
Permission
Public String Rôle [50] Public Choix(Ac,1) Public String static permission [50][50] Public Choix( Ac,n) Public Choix(CU,1) Public ajouterRôle () Public Choix(CU,n) Public supprimerRôle() Public CréerRole()
Public CréerRelation() Public Mapping(Ac,r) Public Mapping(CU,r) Public VérifierCohérence() Public Analyser Opération()
<<Entité>> Role
Public String Rôle [50] Public static String Relation [50][50] Public ajouterRôle () Public supprimerRôle() Public ajouterRelation () Public supprimerRelation ()
Figure 7. Diagramme de classes d’analyse des cas d’utilisation ‘Initialisation des éléments du RBAC’.
112
Chapitre IV Modélisation
Utilisateur
<<Interface>> Vérification-Cohérence Publique booléen vérifU-A Publique booléen vérifA-A Publique booléen vérifA-R Publique booléen vérifR-R Publique booléen vérifR-P Public Lancer () Publique vérifU-A() Publique vérifA-A () Publique vérifA-R() Publique vérifR-R() Publique vérifR-P() Publique afficher Résultat()
<<Controle>> Cohérence
Publique Fct_ Propagation() Publique Initialisation
Publique Violation ()
Publique Chemin -Arborescence ()
Publique Détection ()
<<Entité>> Acteur <<Entité>> <<Entité>>
Rôle Permission Public String Acteur [50]
Public String Rôle [50] Public String Rôle [50] Public static String relation [50][50] Public static String Relation [50][50] Public String static permission [50][50] Public ajouterAC () Public ajouterRôle () Public ajouterRôle () Public supprimerAC() Public supprimerRôle() Public supprimerRôle() Public ajouterRelation () Public ajouterRelation () Public supprimerRelation () Public supprimerRelation ()
Figure 8. Diagramme de classes d’analyse des cas d’utilisation ‘Détection des incohérences’.
113
Chapitre IV Modélisation
User <<Interface>> Simulation
Public String User Public String session Public String Rôle
Public IntroduireUser() Public CréerSession Public DetruireSession() Public ActiverRole Public DesactiverRôle() Public lancer()
<<Interface>> Simulation
Public String Rôle Public String Opération Public ModifierActeur(Rôle)
Public Modifier Rôle (Permission) Public Lancer () Public Afficherrésultat ()
<<Contrôle>> Simulation
Public Verifier SSD () Public Pre-requisiterôle PublicVérifierCardinalité ()
<<Entité>> Rôle
Public String Rôle [50] Public static String Relation [50][50] Public ajouterRôle () Public supprimerRôle() Public ajouterRelation () Public supprimerRelation ()
<<Entité>> Acteur
Public String Acteur [50] Public static String relation [50][50] Public ajouterAC () Public supprimerAC() Public ajouterRelation () Public supprimerRelation ()
<<Entité>> Permission
Public String Rôle [50] Public String static permission [50][50]
<<Controle>> Cohérence
Publique Fct_ Propagation() Publique Initialisation
Publique Violation ()
Publique Chemin -Arborescence ()
Publique Détection ()
Public ajouterRôle () Public supprimerRôle()
Figure 9. Diagramme de classes d’analyse des cas d’utilisation ‘Simulation’.
114
Chapitre IV Modélisation
3.2. Spécification des diagrammes d’interaction Dans cette partie de l’analyse nous avons généré les diagrammes de séquence à partir des
ation dynamique décrivant toutes les
diagrammes de classes d’analyse présentés ci-dessus.
Les diagrammes de séquence donnent une représent
interactions possibles entre l’utilisateur et les différents éléments de notre application qui sont
décrits comme un ensemble d’objets d’analyse.
115
Chapitre IV Modélisation
116
<<Interface>> <<Contrôle>> <<Entité>> : Utilisateur : PageActeur :ContrôleActeur : Acteur
Atteindre ()
AffichagePageActeur ()
CréerActeur ()
VérifierSyntaxe()
NouvelActeur () ()
VérifierExistence()
Inexistante ()
CalculerNbre ()
Créer Acteur ()
AjouterActeur ()DimTAB ()
MiseAJoursN ()ActiverHiéarchie()
BoiteHiéarchieActeur()
SpécifierAscendant () Ascendant (Nom.Acteur)
VérifierExistence()
Chercher.N.Acteur ()
Chercher.N.Ascendant ()
AjouterAscendant ()
AscendantAjouter ()
SpécifierDescendants () Descendant (Nom.Acteur)
VérifierExistence()
AjouterAscendant ()
Chercher.N.Acteur ()
Chercher.N.Descendant
DescendantAjouter
Figure 10. Diagramme de séquence du scénario « Créer Acteur ».
Chapitre IV Modélisation
117
<<Interface>> <<Contrôle>> <<Entité>> : Utilisateur : PageCU :ContrôleCU : CasUtilisation
Atteindre ()
AffichagePageC.U ()
CréerCU ()
VérifierSyntaxe()
NouveauCU ()
VérifierExistence()
Inexistante ()
CalculerNbre ()
Créer CU ()
AjouterCU ()DimTAB ()
MiseAJoursN ()ActiverHiéarchie()
BoiteHiéarchieActeur()
SpécifierAscendant () Ascendant (Nom.Acteur)
VérifierExistence()
Chercher.N.CU ()
Chercher.N.CU ()
AjouterAscendant ()
AscendantAjouter ()
SpécifierDescendants () Descendant (Nom.CU)
VérifierExistance()
AjouterAscendant ()
Chercher.N.CU ()
Chercher.N.Descendant
Figure 11. Diagramme de séquence du scénario DescendantAjouter « Créer cas d’utilisation ».
Chapitre IV Modélisation
<<Interface>> <<Contrôle>> <<Entité>> : Utilisateur : PageCU :ContrôleCU : CasUtilisation
Atteindre ()
AffichagePageC.U ()
CréerCU ()
VérifierSyntaxe()
NouveauCU ()
VérifierExistence()
Inexistante ()
CalculerNbre ()
Créer CU ()
AjouterCU ()DimTAB ()
MiseAJoursN ()ActiverInclude ()
BoiteOrganisationC.U()
SpécifierInclude () Include (Nom.CU)
VérifierExistence()
Chercher.N.CU ()
Chercher.N.CU ()
AjouterInclude ()
IncludeAjouter ()
SpécifierExtend () Extend (Nom.CU)
VérifierExistence()
AjouterExtend ()
Chercher.N.CU ()
Chercher.N.Descendant
ExtendAjouter ()
Figure 12. Diagramme de séquence du scénario « Créer des relations entre cas d’utilisation ».
118
Chapitre IV Modélisation
<<Interface>> <<Interface>> <<Contrôle>>
: Utilisateur : PageConfigRBAC : PageActeur : Rôle
Atteindre ()
ConfigRole (Acteur)
AfficherPageconfig ()
ConfigRole (Acteur)
AfficherPageconfigRole ()
Choix (Acteur=Rôle)
<<Entité>> : Rôle
TypeChoix (Ac,1)
mapping (Ac,Role)
mappingR (Relation)
Choix (Acteur=N Rôle)<<Entité>> : Permission TypeChoix (Ac, N)
VérifierCohérence()
CréerRole()
CréerRelation()
AnalyseOpération()
CréerPermission()
Figure 13. Diagramme de séquence du scénario « initier le modèle RBAC » (Acteur).
119
Chapitre IV Modélisation
120
<<Interface>> <<Interface>> <<Contrôle>>
: Utilisateur : PageConfigRBAC : PageCU : Rôle
Atteindre ()
ConfigRole (CU)
AfficherPageconfig ()
ConfigRole (CU)
AfficherPageconfigRole ()
Choix (Acteur= CU)
<<Entité>> : Rôle
TypeChoix (CU,1)
mapping (CU,Role)
mappingR (Relation)
Choix (Role=N CU) <<Entité>>
TypeChoix (CU, N)
VérifierCohérence()
CréerRole()
CréerRelation()
AnalyseOpération()
: Permission DefinirTache ()
CréerPermission()
Figure 14. Diagramme de séquence du scénario « initier le modèle RBAC » (CU).
Chapitre IV Modélisation
121
<<Interface>> <<Interface>> <<Contrôle>>
: Utilisateur : PageConfigRBAC : PageAC/CU : Rôle
Atteindre ()
ConfigRole (CU/AC)
AfficherPageconfig ()
Créer()
AfficherPageconfigRole ()
<<Entité>> : Rôle
Nommer- Role ()
CréerRole (Nom)
VérifierExistence()
Créer ()
Définir Hiéarchie ()
Ajouter-Relation ()
Créer Relation ()
ConfigurerFigure RBAC à partir de la relation acteur Cas d’utilisation
Figure 15. Diagramme de séquence du scénario « Initier le modèle RBAC ». (Acteur/CU) d’utilisation)
Chapitre IV Modélisation
<<Interface>> <<Contrôle>> : Utilisateur : Vérifier- Cohérence : Contrôle –Cohérence
Atteindre ()
Lancer-Vérif ()
Afficher-Interface ()
Vérifier ()
<<Entité>> : Permission
<<Entité>> : Rôle
Détect-Violation1 ()
Afficher Perm-Role ()
Détect-Violation 2 ()
<<Entité>> : Acteur
Afficher Role-Role ()
Détect-Violation 3 ()
Afficher Acteur-Role ()
Détect-Violation 4 () Afficher Acteur-User ()
<<Entité>> : Utilisateur
Détect-Violation 5 ()
Afficher Résultats ()
Figure 16. Diagramme de séquence du scénario « Détecter les incohérences ». (cas d’utilisation)
122
Chapitre IV Modélisation
123
<<Contrôle>> : Utilisateur <<Interface>> : Simulation : Simulation
Atteindre ()
<<Entité>> : Elément
Simulation <Création session>fff
AfficherBoiteSim()
IntroduireUser()IntroduireUser(Nom)
Vérifierexistence()
CréerSession()
Attacher (User, Session)
VérifierCohérence()
ActiverRole()
Attacher (session,Role)
VérifierCohérence ()
ResultatTest ()
AfficherRéultat ()
Figure 17. Diagramme de séquence du scénario « simulation des contraintes RBAC » (DSD)
Chapitre IV Modélisation
<<Interface>> : Utilisateur : Simulation
<<Contrôle>> : Simulation
<<Entité>> : Elément
Atteindre ()
AfficherSim ()
DéfinirSénario
Définirpermission
Lancer Test ()
VérifierCohérence ()
ChargerParamètre()Charger paramètre ()
DéfinirRésultat ()
AfficherRésultat ()
Figure 18. Diagramme de séquence du scénario « Simulation sur les scénarios ».
124
Chapitre IV Modélisation
<<Interface>> <<Entité>> : Utilisateur <<Contrôle>> : GénérationCode : Ficher XML : GénCode
Atteindre ()
AfficherGénCode ()
GénérerCode() <<Entité>> : Elément
Exécuter génCode()
DéfinirEléent()
Charger()
Transformer XML()
Figure 19. Diagramme de séquence du scénario « Génération de code ».
125
Chapitre IV Modélisation
<<Page>> Acteur
<<Action>> CréerActeur
<<Action>> VerifierExistance
<<Action>> DefinirHiearchie
<<Action>> VerifierCohérence
<<Action>> Ajouter
[Non]
<<Action>> DefinirAssociation
[Non]
<<Action>> Verifier
[Ajouter]
<<Action>> Ajouter
[Ajouter] [Non]
<<Action>> Ajouter
[Ajouter]
Figure 20. Diagramme d’activités : Vérification de la cohérence.
126
Chapitre IV Modélisation
<<Page>> C.U
<<Action>> CréerC.U
<<Action>> VerifierExistance
<<Action>> DefinirHiearchie
<<Action>> VerifierCohérence
<<Action>> Ajouter
[Non]
<<Action>> DefinirAssociation
[Ajouter]
<<Action>> Ajouter
[Ajouter]
[Non]
<<Action>> Verifier
<<Action>> Ajouter
[Ajouter]
[Non]
<<Action>> DefinirExtend
<<Action>> DefinirExtend
<<Action>> VérifierExistance
<<Action>> Ajouter
[Non]
[Ajouter]
Figure 21. Diagramme d’activités : Définition des cas d’utilisation.
127
Chapitre IV Modélisation
<<Page>> Simulation
<<Action>> IdentifierUser
<<Action>> CréerSession
<<Action>> ActiverRole
<<Action>> DésactiverRole
<<Action>> LancerTest
<<Action>> <<Page>> Échec Succès
Figure 22. Diagramme d’activités : simulation sur les contraintes
128
Chapitre IV Modélisation
<<Page>> DéfinirRBAC
<<Action>> DéfinirPermission
<<Action>> DéfinirRôle
<<Page>> <<Page>> [AC/CU] [Acteur] Définir_CU->Role DéfinirAC->Role
[CU]
<<Page>> DéfinirUC->Role
<<Action>> RegrouperCU
<<Action>> DéfinirTache
<<Action>> DéfinirRole
<<Action>> Définir Rôle
<<Action>> VerificationCohérence
[CU= 1 Role] [Ac= n Role]
[Ac= n Role]
[Ac= 1 Role]
<<Action>> Définir Relation
<<Action>> VérificationCohérence
<<Action>> Affectation Permission
129
Chapitre IV Modélisation
<<Page>> Simulation
<<Page>> <<Page>> Acteur CU
<<Action>> RedéfinirRole
<<Action>> <<Action>> RedéfinirTache RedéfinirOpération
<<Action>> VérifierCardinalité
<<Action>> VérifierSSD
<<Action>> VérifierPréRole
<<Page>> VérifierPréRole
<<Page>> VérifierPréRole
Figure 24. Diagramme d’activités : Simulation sur les scénarios.
130
Chapitre IV Modélisation
<<Page>> GénérationCode
<<Action>> GénérerCode
<<Action>> Transformer
<<Action>> CréerFichier
<<Fichier>> <<Fichier>> Fichier JAVA Fichier XML
Figure 25. Diagramme d’activités : Génération du code.
131
Chapitre IV Modélisation
132
Chapitre V Implémentation et tests de l’application
1. Introduction Nous avons détaillé la partie analyse et conception dans le chapitre 3, suivi de la partie
modélisation dans le chapitre 4. Le chapitre 5 sera consacré à la partie implémentation, qui
constitue la concrétisation de notre méthodologie en utilisant comme langage de
programmation le C ++ Builder.
Ainsi, nous avons implémenté toutes les étapes décrites dans le chapitre 3 et modélisés dans le
chapitre 4. Ces étapes sont l’instanciation du modèle d’application, du modèle RBAC et de la
politique de contrôle d’accès. Ensuite, l’implémentation des algorithmes (dans le chapitre 3)
se chargera de détecter toutes les incohérences entre l’application introduite et la politique de
contrôle d’accès. L’application donne aussi la possibilité à l’utilisateur de simuler la création
et la destruction des sessions, l’activation et la désactivation des rôles, et enfin la génération
du code (partie politique du contrôle d’accès).
Dans ce qui suit, nous avons voulu montrer la relation entre RBAC et la plate forme J2EE, qui
constituera le sujet de la section 2 suivi des tests de notre application. Dans notre cas, nous
avons choisi deux exemples qui testeront différemment notre application. Le premier
exemple, pris de l’article [11], concernera une banque et sera utilisé pour tester notre analyse
d’incohérences avec la politique de contrôle d’accès tout en procédant aux simulations. Le
deuxième exemple, extrait de l’article [19], sera utilisé comme test pour la génération du
code.
2. RBAC dans les applications J2EE Les applications J2EE sont réparties en quatre tiers : tiers systèmes d’information, tiers
business, tiers web, tiers client.
a) Le tiers système d'information détient les technologies de stockage persistantes,
généralement des systèmes de management de bases de données.
b) Le tiers business est constitué d'objets distribués qui mettent en œuvre (implémentent) les
fonctionnalités de base, ou la logique business de l’application. Ces objets distribués sont
fréquemment mis en œuvre (implémentés) par les EJBs.
Les EJBs s'exécutent dans les contenants EJB et fournissent un grand nombre de services
automatisés, tels que le suivi et la gestion des transactions.
c) Le tiers web est la partie d’application qui génère des documents qui sont affichés par le
navigateur sur les clients de l’application. Ce tiers comprend les technologies telles que les
132
Chapitre V Implémentation et tests de l’application
servlets. Les servlets génèrent souvent des pages HTML qui sont servies aux clients par les
serveurs Web.
d) Le tiers client inclut des composants qui s'exécutent sur les ordinateurs clients et
interagissent avec le serveur. Souvent, le tiers client se compose de navigateurs qui affichent
le contenu généré par le tiers Web. Le tiers client peut aussi inclure des applications qui
interagissent directement avec les EJBs dans le tiers business ou, moins souvent, avec des
composants de stockage de données dans le tiers systèmes d'information.
2.1. Les bases de l’ EJB L’EJB encapsule la logique business des applications J2EE. L’EJB est responsable de la
connexion des systèmes existants (ex : les bases de données) pour effectuer les transactions et
pour récupérer les informations pour le compte des utilisateurs.
Les EJBs individuels sont des composants autonomes qui peuvent être assemblés dans
l’application. Le comportement général de chaque EJB est représenté par une classe d'EJB et,
éventuellement, un certain nombre de classes d’aide (helper). Ce comportement peut être
modifié pour s'adapter à une configuration spécifique ou alors à une installation spécifique de
l'application. Cette modification s’effectue avec un descripteur de déploiement, un fichier
XML qui décrit les propriétés des EJBs, en incluant leur sécurité, le suivi, et le comportement
transactionnel. Cette approche reflète la philosophie d’un composant basé sur le
développement dans J2EE:
Les développeurs de EJBs se concentrent sur la mise en œuvre (implémentation) de la logique
business.
Les assembleurs d’application se concentrent sur la composition des EJBs pour former des
applications.
Enfin, les exploitants d'application se concentrent sur la création de configurations de ces
applications, en incluant la configuration de leurs aspects de sécurité.
Cette répartition des responsabilités signifie que l’exploitant peut ne pas être familier avec les
détails de la mise en oeuvre (implémentation) des EJBs, et être toujours forcé de préciser le
cahier de charges de la politique de contrôle d'accès concernant ces beans. Notre analyse
automatisée est particulièrement précieuse dans ces situations.
Au sein du contenant EJB, chaque instance d'un EJB est représentée par 2 objets : l’un est
l'EJB objet réel et l'autre est l’EJB objet de l'interface.
133
Chapitre V Implémentation et tests de l’application
L'EJB objet réel est celui dont les méthodes implémentent la logique business et maintiennent
l'état de l'EJB. Cet objet peut être complexe et peut utiliser d'autres objets.
L’EJB objet de l'interface est utilisé pour toutes les communications entre l'objet d'EJB et les
clients qui font appel à ses méthodes.
Pour la communication avec les clients distants, les objets d'interface EJB emploient
normalement le protocole RMI. L’objet d'interface EJB peut ne pas inclure certaines des
méthodes dans l'objet EJB. Les méthodes d’EJB, qui ne sont pas incluses dans l’objet de
l’interface d’EJB, ne peuvent pas être appelées par les clients. Ce mécanisme offre un moyen
pratique de concevoir quelques méthodes définies par un EJB invisible pour les clients.
Quand un serveur d'applications J2EE déploie un objet dans EJB, il génère et déploie
automatiquement l'objet d'interface correspondant EJB à partir d'une interface produite par le
développeur d'applications ou l'assembleur.
Chaque classe EJB (par opposition à un composant EJB) est associée à des objets EJB. Ces
derniers peuvent être utilisés par les clients pour obtenir des références d’objets d'interface
EJB correspondants aux objets EJB de cette classe. Si un nouvel objet EJB est créé et
déployé, ou si un objet EJB existant est réutilisé et déterminé par le serveur d'application, une
référence à un objet HOME EJB est obtenue par les clients via les services de noms Java, cela
exige que chaque classe EJB utilisée par une application soit liée à un nom unique. De même
pour les objets EJB, les objets home EJB sont créés par le serveur d'applications basé sur une
interface qui est fournie par le développeur d'applications ou de l'assembleur.
En plus de l’interface EJB et des objets home d’interface, l’interface locale EJB et les
OBJETS HOME local d’EJB peuvent être utilisés. Ces objets sont utilisés pour la méthode de
communication au sein du contenant EJB. Donc, même les clients distants ne peuvent pas
communiquer avec les EJB interface locale. Du point de vue des performances, l’invocation
des méthodes d'objets EJB interface locale est efficace, parce que, contrairement à
l’invocation des méthodes à distance, les arguments et les résultats des appels de méthodes
locaux sont passés par référence plutôt que par valeur. Du point de vue sécurité, l'utilité des
objets d'interface locale EJB est de permettre la confiance des composants, tels que les
servlets et JSP, EJB, d'appeler des méthodes sensibles de EJB objets, alors que ces méthodes
ne peuvent pas être appelées par des clients distants directement semblables à l'interface
d'EJB et d'accueil interface locale objects. EJB et les objets à domicile sont créés par les
serveurs d'applications basés sur des interfaces fournies par les développeurs d'applications ou
assembleurs.
134
Chapitre V Implémentation et tests de l’application
<assembly-descriptor>
<security-role>
<description>
Any student at the university
</description>
<role-name>student</role-name>
<security-role>
<security-role>
<description/>
<role-name>professor</role-name>
<security-role>
<method-permission>
<role-name>professor</role-name>
<method>
<ejb-name>Gradebook</ejb-name>
<method-name> * <method-name>
</method>
</method-permission>
<method-permission>
<role-name>student</role-name>
<method>
<ejb-name>Gradebook</ejb-name>
<method-name> homeworks </method-name>
</method>
<method>
<ejb-name>Gradebook</ejb-name>
<method-name> getGrade </method-name>
</method>
</method-permission>
</assembly-descriptor>
Figure 1. Exemple Politique d’accès J2EE.
135
Chapitre V Implémentation et tests de l’application
2.2. RBAC pour EJB Le mécanisme de contrôle d’accès J2EE est basé sur RBAC, le contrôle d’accès basé sur les
rôles. Le modèle utilisé pour le contrôle d’accès identifie les rôles, ou types des différents
clients et spécifie les fonctionnalités de l’EJB pouvant être accédées par un rôle donné.
La Figure 2 donne un exemple de spécification de la politique de contrôle d’accès J2EE pour
le Gradebook, ou deux rôles étudiant et professeur sont identifiés : selon cette politique, le
professeur a le droit d’accéder à toutes les méthode de l’EJB interface de Gradebook EJB,
indiqué par le symbole *, alors que l’étudiant a uniquement le droit d’appeler la méthode
Homework et Getgard.
A noter que, par défaut, tous les rôles peuvent accéder à toutes les méthodes qui ne sont pas
mentionnées explicitement dans le modèle.
Public interface gradebook extends javax .ejb. ejboject
public void adhomework (homework h) throws remotexception :
public void adhomework (homework h) throws remotexception ;
public set homeworks() throws remotexception
public void setgrade (grade g , student s , homework h ) throws remotexception ;
public map getallgrades (student s) throws remotexception ;
Figure 2. Interface EJB pour l’exemple GradeBook
3. Exemples :
3.1. Exemple Banque [11]
Le cahier de charges fonctionnel et la politique de contrôle d’accès sont tirés de [18], ainsi
nous avons modélisé en diagramme de cas d’utilisation qui servira d’entrée à notre
application.
136
Chapitre V Implémentation et tests de l’application
Créer compte
Caissier
Politique de contrôle d’accès
SSD {(Caissier, Comptable), (Caissier, Agent de prêt), (Agent de prêt, Comptable), (Agent de prêt, Directeur Comptable), (RSC, Directeur Comptable)} DSD {(CSR, Agent de prêt)} Pré-requisite Acteur :(Comptable, Directeur Comptable)
Modifier compte
Supprimer compte
R.S.C
Créer Livre
Comptable
Créer Prêt
Modifier Prêt
Directeur Comptable
Modifier Affichage
Agent de prêt
Figure 3. Diagramme de cas d’utilisation Banque (Acteur).
137
Chapitre V Implémentation et tests de l’application
Figure 4. Interface Application Définition les éléments RBAC : Rôle.
DSD
Si un nouvel acteur « gestionnaire de succursale » est introduit, tel que :
CSR : Rôle Directeur Comptable : Rôle SSD
Cassier : Rôle
Agent Prêt: Rôle
Comptable : Rôle
Hiéarchie SSD Pré - requis
SSD
SSD
SSD
Figure 5. Diagramme d’objets de l’exemple.
138
Chapitre V Implémentation et tests de l’application
R.S.C
Directeur de comptabilitéGestion de succursale
Agent de prêt
Figure 6. Diagramme de cas d’utilisation (Acteur).
Figure 7. Interface application Définition RBAC.
139
Chapitre V Implémentation et tests de l’application
3.1.1 Vérification de la cohérence Les violations sont détectées et affichées comme suit :
CSR : Rôle
Cassier : Rôle
Agent Prêt: Rôle
Directeur de comptabilité : Rôle
Comptable : Rôle
Hiérarchie
DSD SSD
SSD Pré - requis
SSD
SSD
SSD
Hiérarchie Hiérarchie Gestionnaire Succursale : Rôle
Hiérarchie
Figure 8. Diagramme d’objets de l’exemple.
140
Chapitre V Implémentation et tests de l’application
Figure 9. Interface application Vérification de cohérence. 3.1.2. Simulation
Pour la simulation, prenons un utilisateur qui ouvre une session et active successivement les
rôles suivants : CSR, caissier et, enfin, Agent de prêt.
Dans la première activation, le simulateur ne détecte aucune violation et, dans la deuxième
(caissier), c’est la même chose, car aucune contrainte n’est suggérée entre ces deux rôles dans
la politique de contrôle d’accès.
Dans la troisième activation, l’utilisateur active le rôle (Agent de prêt) qui est en DSD avec
CSR : aussi cette violation est détectée et affichée, une autre violation celle de SSD entre
agent de prêt et caissier sera aussi détectée.
141
Chapitre V Implémentation et tests de l’application
Figure 10. Interface application Simulation.
3.2. Exemple questionnaire [19] :
Dans ce qui suit nous présentons un exemple illustratif pris de l’article [18]
142
Chapitre V Implémentation et tests de l’application
Modèle d’application
Ajouter nouveau nom
Ajouter question
Ajouter question Spéciale
Staff -c
Classer les questions
<<Include>>
<<extend>> Junior Senior Staff -c Staff -c
Ajouter catégorie de question
Figure 11. Diagramme de cas d’utilisation du cas : Nouveau questionnaire
:Système
S_Staff OnSubmit -s
Survey Title Search
Add survey header
Update_survey_ Liste
Figure 12. Diagramme de séquence du cas d’utilisation « Ajouter un nom »
143
Chapitre V Implémentation et tests de l’application
Figure 13. Interface application Définition RBAC. Pour cette exemple nous
R_ Ajouter nouveau nom
R_Ajouter question
R_Ajouter question Spécial
R_Ajouter catégorie de question
R_Classer les questions
Pré-Réquisite Rôle
Pré-Réquisite Rôle Hiérarchie Rôle
Figure 14. Diagramme d’objets de l’exemple 2.
144
Chapitre V Implémentation et tests de l’application
3.2.1 Génération du code
Figure 15. Interface application Génération du code
145
Conclusion générale
Conclusion Générale et perspectives Dans ce mémoire nous avons proposé une démarche qui permet de réduire l’écart qui existe
entre les modèles d’application et les modèles de sécurité, et cela en intégrant le modèle
RBAC dans le processus de développement de l’application basé sur UML.
Pour cela nous avons adapté le modèle RBAC dans les diagrammes de cas d’utilisation et de
séquence, en combinant les éléments des deux modèles (RBAC et UML) au sein du modèle
de conception que nous avons proposé.
Ce modèle de conception sert de base pour la spécification des éléments du modèle RBAC, et
pour la politique de contrôle d’accès.
Une fois le modèle de conception spécifié nous avons :
1. procédé à une vérification de la cohérence de la politique de contrôle d’accès avec le
modèle d’application.
2. proposé un simulateur qui offre à l’utilisateur la possibilité de créer des sessions et
d’activer des rôles, comme si l’application, au niveau modélisation, se déroule
réellement.
3. proposé un générateur de code (Contrôle d’accès)
Nous pensons ainsi avoir conçu un environnement qui permet à la fois à l’utilisateur
de créer des applications sécurisées et d’effectuer des tests au niveau conception.
Enfin, nous terminons notre mémoire en présentant plusieurs perspectives que nous
exposons dans ce qui suit :
_ Etendre l’intégration du modèle RBAC sur le reste des digrammes de UML.
_ Compléter la partie génération code, en proposant un générateur visant la partie logique
de l’EJB.
_ Proposer un système d’aide à la résolution en cas de présence de vulnérabilité dans le
Simulateur
_ Unifier les modèles de contrôle d’accès (DAC, MAC, RBAC…)
146
Conclusion générale
147
Conclusion générale
148
Annexe
Index Abstraction Caractéristique essentielle d’une entité qui la distingue de toutes les autres entités, définissant ainsi une frontière claire par rapport à l’observateur. ACL Access control list : liste de contrôle d’accès. Antivirus Programme Antivirus- logiciel qui scanne la mémoire et les périphérique de stockage d’un ordinateur pour identifier, isoler et éliminer des virus. Certain peuvent vérifier les fichiers à la volée, au fur et à mesure que l’ordinateur les reçoit. Agent de menace Objet qui peut commetre une attaque (cheval de Troie). Asset Information qui a une valeur dans l’organisation. Besoin Caractéristique, propriété ou comportement attendu du système. Cardinalité Nombre d’éléments contenus dans un ensemble. Comportement Effet d’un événement qui peut être observé, résultats compris. Contexte Ensemble d’éléments reliés dans un but précis. DAC Discretionary Access Control - Le Contrôle d'Accès Discrétionnaire est un genre de contrôle d'accès défini par TCSEC. EJB Enterprise JavaBeans est une architecture de composants logiciels côté serveur pour la plateforme de développement JEE. Elément Constituant atomique d’un modèle. Condition ou situation qui se produit lors de la vie d’un objet. Ingénierie sociale : emploi de moyens non techniques pour obtenir un accès non autorisé (contacter des personnes, feindre d’être un employé, etc.) JEE Java Enterprise Edition, ou Java EE (anciennement J2EE), est une spécification pour la technique Java de Sun plus particulièrement destinée aux applications d’entreprise.
148
Annexe
MAC Mandatory Access Control- Contrôle d'Accès Obligatoire : c’est une méthode de gestion des droits des utilisateurs. Menace Perte potentielle de la valeur de l’Asset à cause de sa vulnérabilité. La menace est présentée sous la forme d’un tuple : ACTION (qui exploiterait l’Asset) l’ASSET, et le PREJUDICE préalable. Elle est décrite sous la forme suivante : causerait Action( X ) ----------------- Asset ( Y ) ------------------- Préjudice ( Z ) Ex : Supprime enregistrement des clients Perte de revenu De la société à la société Les descriptions de menace sont générées en énumérant les Assets impliqués dans le système. Les buts de la sécurité sont trouvés en faisant la prévention (prevent ou avoid) des risques liés aux menaces possibles. Mécanisme de sécurité : c’est une technique spécifique comme la cryptographie. Meta-classe Classe dont les instances sont des classes. OCL Object Constraint Language – Langage d'Expression des Contraintes utilisé par UML. Or-BAC Organisational Based Access Control – Contrôle d’Accès Basé sur l’Organisation. RBAC Role Based Access Control – Contrôle d’Accès Basé sur les Rôles. Rôle Comportement d’une entité active dans un contexte donné. Sauvegarde : utilisation de mécanismes de sécurité pour protéger l’Asset. Scénario de risque : C’est la démarche pour analyser les risques et proposer des scénarios de risques. Ensuite, on analyse les scénarios afin d’expliciter les causes potentielles et les conséquences.
149
Annexe
RISQUE Evénement redouté (ER) CAUSES CONSEQUENCES Evènements ayant fait naître (ER) Effets, Impacts
Action
Niveau de Vraisemblance et de Gravité
Action
Prévention ACTION CORRECTIVES Protection Agit sur la vraisemblance (fréquence, probabilité) Agit sur la gravité Scénario Séquence spécifique d’actions qui illustre un comportement. Système Un ensemble d'éléments interagissant entre eux selon un certain nombre de principes ou règles. TBAC Temporal Based Access Control – Contrôle d’Accès Basé sur le Temps. Template Elément paramétré Vue Projection dans un modèle, ou vue à partir d’une perspective donnée ou d’une position avantageuse, qui masque les entités qui ne représente pas d’intérêt pour cette perspective. Vulnérabilité : propriété de certains objets du système qui peut permettre une attaque. Acronymes des principaux organismes et standard de sécurité ANSI American National Standards Institute.
CCITSE Common Criteria for Information Technology Security Evaluation.
CERT Computer Emergency Response Team.
ETSI Institut européen des Normes de Télécommunication.
IEEE Institute of Electronical and Electronics Engineers.
ISO International Organization for Standardization.
150
Annexe
ITSEC Information Technology Security Evaluation Criteria.
NIST National Institute of Standards and Technology.
TCSEC Trusted Computer System Evaluation Criteria.
151
Bibliographie [1] A.V. Lamsweerde, Elaborating security requirement by construction of
international Anti-model, IEEE, 2004.
[2] G. Whitson, Computer security: theory, process and management, ACM, 2003.
[3] L. Wang, E. Wong, D. Xu, A threat model driven Approach for security testing, IEEE,
2007.
[4] I. Flechais, M.A Sasse, S.M.V. Hailes, Bringing Security Home: A process for
developing secure and usable system, ACM 1-58113-880-6/04/04, New Security
Paradigms Workshop, 2004.
[5] Eric M., Sécurité des réseaux, CampusPress, 2001.
[6] G. Kotonya I. Sommervilles, Requirements Engenring: Process and techniques,
United Kingdom, John Wiley and Sons, 1998.
[7] C.B. Haley, J.D. Moffett, R. Laney, B. Nuseibeh, A Framework for Security
Requirements Engineering, ACM, 1-59593-085-X/06/0005, 2006.
[8] I. Alexandre, Misuse cases: Use case with hostile intent, IEEE, 2003.
[9] G. Sindre, A.L. Opdahl: Templates for Misuse Case Description, REFSQ; 2001.
[10] F.D. Ferraiolo, R. Sandhu, S. Gavrila, D.R. Kuhn, R.Chandramouli,
Proposed NIST standard for role-based access control, ACM Transaction on
Information and System Security, Vol. 4, No. 3, Page 224-274, 2001.
[11] I. Ray, N. Li, R. France, D. Kim, Using UML to Visualize Role-Based Access Control
Constraints, ACM, 2004.
[12] K. Alghathbar, D. Wijesekera, AuthUML: A Three-phased framework to analyze
access control specifications in Use Case, ACM, 1-58113-781-8/03/0010, 2003.
[13] K. Alghathbar, Validating the enforcement of access control policies and separation
of duty principle in requirement engineering, Information and software technology,
Information and Software Technology 49, 142–157, 2007.
[14] S. Sendall, A. Strohmeier From Use Cases to System Operation
Specifications, UML 2000, 1-15, 2000.
[15] D. Basin, J. Doser, T. Lodderstedt, Model Driven Security for Process Oriented
Systems, ACM, 2003.
[16] D. Basin, J. Doser, T. Lodderstedt, Model Driven Security: From UML Models to
Access Control Infrastructures, ACM, Vol. 15, No. 1, 2006.
[17] G.J. Ahn, H. Hu, Towards Realizing a Formal RBAC Model in Real Systems,
152
SACMAT’07, ACM 9781595937452/ 07/0006, 2007.
[18] G. Neuman, M. Strembeck, A Scenario-driven Role Engineering Process for
Functional RBAC Roles, ACM, 2002.
[19] T. Doan, S. Demurjian, T.C. Ting, A. Ketteri, MAC and UML for Secure Software
Design, ACM, 2004.
[20] J. Pavlich-Mariscal, L. Michel, S. Dermujian, Enhancing UML to modele custom
security Aspect, Processings of the 11 th international workshop on aspect oriented
Modeling, 2007.
[21] E.B. Fernandez. A methodology for secure software design. In Software Engi-
neering Research and Practice, pages 130-136, 2004.
[22] J.L. Vivas, J.A. Montenegro, J. Lopez, Towards a business process-driven
framework for security engineering with the UML, In Proceedings of the 6th
Information Security Conference, ISC'03, pages 381-395, Bristol, U.K., 2003.
[23] T. Doan, L.D. Michel, S.A. Demurjian. A formal framework for secure
design and constraint checking in UML. In Proceedings of the International
Symposium on Secure Software Engineering, ISSSE'06, Washington, DC, Mars
2006.
[24] J. Jurjens, Secure Systems Development with UML, Springer Verlag, 2004.
[25] J. Jurjen, P. Gerhard, W. Guido, Use Case Oriented Development of Security-Critical
Systems, ACM, 2003.
[26] W. Darwish, K. Beznosov, Analysis of ANSI RBAC Support in COM+, Computer
Standards & Interfaces, doi:10.1016/j.csi.2009.12.00, 2010.
[27] A. Colantonio, R. Di Pietro, A. Ocello, N. Verde, Taming role mining complexity in
RBAC, Computer Security, 5 4 8 – 5 6 4, 2010.
[28] J. Joshi, A. Ghafoor, W.G. Aref, E.H. Spafford, Digital government security
infrastructure design challenges, IEEE Comput, 33, 2, Feb. 66 – 72, 2001.
[29] G. Boosh, J. Rumbauh., I. Jacobson., UML: Le Guide de l’utilisateur, la référence,
Eyrolles, 1998.
[30] D. Ralph, E. Gregor, M.K. Jochen, On the Integration of Roles in the UML,
Technical Report N°. 214, University of Paderborn, 2000.
[31] M. Lai, UML : La notation unifiée de modélisation objet, de Java aux EJB, DUNOD,
2000.
[32] ISO/IEC, Unified Modeling Language Specification Version 1.4.2; formal/05-
04-01, ISO/IEC 19501:2005(E).
153
[33] G. Naumovich, P. Centonze: Static analyses of role based access control in J2EE
Application, 2004.
[34] C. Talhi, D. Mouheb, V. Lima, M. Debbebi, L. Wang, M. Pouzandi, Usability of
security specification approches for UML design : A survey, Journal of Object
technologies, 2009.
[35] S. Wagner, D.M. Fernandez, S. Islam, K. Lochmann, A Security Requirements
Approach for Web Systems, 2009.
[36] Inconnue, Sécurité optimale, le guide d’un ex–hacker, CampusPress, 2001.
[37] N. Belharet, Recherche opérationnelle : la théorie des graphe et la programmation
dynamique, pages bleues, 2003.
[40] M. Gondran, M. Minoux, Graphes et Algorithmes, Eyrolles, 1987.
[42] J.B.D. Joshi, W.G. Aref, A. Ghafoor, E.H. Spaford, Security model for web based
Application, ACM Vol 44, N° 2, 2001.
[43] P.Y.A. Ryan, Mathematical Models of Computer security, Springer, FOSAD 2000
LNCS 2171, pp.1-62, 2001.
[44] F.D. Ferraiolo, R. Sandhu, D.R. Kuhn, RBAC Standard Rationale Comments on “A
Critique of ANSI Standard on Role-Based Access Control”, IEEE, 2007.
[45] R. Villarroel, E. Fernandez-medina, M. Piattini, Secure information systems
development: a survey and comparison, Computer security, 2005.
[46] Inconnue, Sécurité optimale, le guide d’un ex–hacker, CampusPress, 2001.
[47] R.S. Sandhu, J.S. Edward, L.C. Hal, L.F. Charles, E. Youmank,
Role-Based Access Control Models, IEEE, 1996.
[48] S. Karsten, G. Ahn, G. Martin, M. Lars, Specification and Validation of
Authorisation Constraints Using UML and OCL, Springer, 2006.
154
Résumé :
Notre travail consiste à analyser le contrôle d’accès des premières
phases de développement de l’application modélisé en UML, et cela en
intégrant le modèle de contrôle d’accès RBAC dans les diagrammes cas
d’utilisation et séquence, qui sont considérés comme les premiers diagrammes
dans plusieurs processus de développement, cette intégration se traduit par un
diagramme de classe template qui définie les éléments du modèle RBAC et
UML.
L’analyse ce fait a travers la détection des incohérences existante
entre la politique de contrôle d’accès et le modèle d’application (modélisé en
UML), nous avons utilisé la théorie de graphe comme moyen formel pour la
détection de incohérence.
Nous avons ajouté un simulateur qui permet de déceler les
incohérences des contraintes dynamiques
Et enfin nous avons ajouté un générateur de code en XML qui
permet de généré du code partie sécurité.
Mot clés :
Sécurité ; Contrôle d’accès ; UML ; RBAC ; Analyse ; Processus de
développement ; Environnement de sécurité.
top related