DEPARTEMENT D'INFORMATIQUE MEMOIRE · DEPARTEMENT D'INFORMATIQUE MEMOIRE Présenté par KHELIFA Nor...

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


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


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


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


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


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


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


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


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


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


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


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


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


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

http://fr.wikipedia.org/wiki/Ordinateur

http://fr.wikipedia.org/wiki/Ressource

http://fr.wikipedia.org/wiki/Droits_d%27acc%C3%A8s


• 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


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


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


- 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


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


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


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


_ 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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


_ 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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


<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


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


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


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


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


é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


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


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


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


• 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


<<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


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


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


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


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


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)


Chercher.N.Acteur ()

Chercher.N.Ascendant ()

AjouterAscendant ()

AscendantAjouter ()

SpécifierDescendants () Descendant (Nom.Acteur)


AjouterAscendant ()

Chercher.N.Acteur ()

Chercher.N.Descendant

DescendantAjouter

Figure 10. Diagramme de séquence du scénario « Créer Acteur ».


117

<<Interface>> <<Contrôle>> <<Entité>> : Utilisateur : PageCU :ContrôleCU : CasUtilisation

Atteindre ()

AffichagePageC.U ()

CréerCU ()

VérifierSyntaxe()

NouveauCU ()


Inexistante ()

CalculerNbre ()

Créer CU ()

AjouterCU ()DimTAB ()

MiseAJoursN ()ActiverHiéarchie()

BoiteHiéarchieActeur()

SpécifierAscendant () Ascendant (Nom.Acteur)


Chercher.N.CU ()

Chercher.N.CU ()

AjouterAscendant ()

AscendantAjouter ()

SpécifierDescendants () Descendant (Nom.CU)

VérifierExistance()

AjouterAscendant ()

Chercher.N.CU ()


Figure 11. Diagramme de séquence du scénario DescendantAjouter « Créer cas d’utilisation ».


<<Interface>> <<Contrôle>> <<Entité>> : Utilisateur : PageCU :ContrôleCU : CasUtilisation

Atteindre ()

AffichagePageC.U ()

CréerCU ()

VérifierSyntaxe()

NouveauCU ()


Inexistante ()

CalculerNbre ()

Créer CU ()

AjouterCU ()DimTAB ()

MiseAJoursN ()ActiverInclude ()

BoiteOrganisationC.U()

SpécifierInclude () Include (Nom.CU)


Chercher.N.CU ()

Chercher.N.CU ()

AjouterInclude ()

IncludeAjouter ()

SpécifierExtend () Extend (Nom.CU)


AjouterExtend ()

Chercher.N.CU ()


ExtendAjouter ()

Figure 12. Diagramme de séquence du scénario « Créer des relations entre cas d’utilisation ».

118


<<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


120


: Utilisateur : PageConfigRBAC : PageCU : Rôle

Atteindre ()

ConfigRole (CU)


ConfigRole (CU)


Choix (Acteur= CU)

<<Entité>> : Rôle

TypeChoix (CU,1)

mapping (CU,Role)

mappingR (Relation)

Choix (Role=N CU) <<Entité>>

TypeChoix (CU, N)


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).


121


: Utilisateur : PageConfigRBAC : PageAC/CU : Rôle

Atteindre ()

ConfigRole (CU/AC)


Créer()


<<Entité>> : Rôle

Nommer- Role ()

CréerRole (Nom)


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)


<<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 ()


Afficher Acteur-Role ()

Détect-Violation 4 () Afficher Acteur-User ()

<<Entité>> : Utilisateur


Afficher Résultats ()

Figure 16. Diagramme de séquence du scénario « Détecter les incohérences ». (cas d’utilisation)

122


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)


ActiverRole()

Attacher (session,Role)

VérifierCohérence ()

ResultatTest ()

AfficherRéultat ()

Figure 17. Diagramme de séquence du scénario « simulation des contraintes RBAC » (DSD)


<<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


<<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


<<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


<<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


<<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


<<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


<<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


<<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


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


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


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


<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>


<method-name> * <method-name>

</method>

</method-permission>

<method-permission>

<role-name>student</role-name>

<method>


<method-name> homeworks </method-name>

</method>

<method>


<method-name> getGrade </method-name>

</method>

</method-permission>

</assembly-descriptor>

Figure 1. Exemple Politique d’accès J2EE.

135


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


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


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


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


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


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


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


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


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


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


147


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

http://fr.wikipedia.org/wiki/JEE

http://fr.wikipedia.org/wiki/Sp%C3%A9cification

http://fr.wikipedia.org/wiki/Technique

http://fr.wikipedia.org/wiki/Java_%28technique%29

http://fr.wikipedia.org/wiki/Sun_Microsystems

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

http://fr.wikipedia.org/wiki/Unified_Modeling_Language

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

http://fr.wikipedia.org/wiki/Principe

http://fr.wikipedia.org/wiki/R%C3%A8gle

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é.

DEPARTEMENT D'INFORMATIQUE MEMOIRE · DEPARTEMENT D'INFORMATIQUE MEMOIRE Présenté par KHELIFA Nor...

Documents

Transcript of DEPARTEMENT D'INFORMATIQUE MEMOIRE · DEPARTEMENT D'INFORMATIQUE MEMOIRE Présenté par KHELIFA Nor...