Représentation abstraite du modèle de contrôle d’accès

5.2.1 Attribute Based Access Control . . . . 94

5.2.2 Vision d’architecture. . . . 95

5.3 Représentation formelle du modèle de contrôle d’accès . . . . 96

5.3.1 Modélisation des règles de contrôle d’accès. . . . 97

5.3.2 Modélisation de politiques de contrôle d’accès. . . . 100

5.3.3 PolicySet . . . . 104

5.3.4 Synthèse . . . . 107

5.4 Délégation . . . . 107

5.4.1 Présentation formelle de délégation . . . . 108

5.4.2 Délégation externe. . . . 111

5.4.3 Application des modèles sur l’exemple de motivation . . . . 111

5.5 Conclusion . . . . 112

5.1 Introduction

Ayant présenté la première partie concernant l’architecture de collaboration ainsi que la gestion

des ressources et identités numériques, nous aborderons dans ce chapitre la gestion du contrôle

d’accès aux ressources partagées au sein des communautés de collaborationOpenPaaSRSE.

5.2 Représentation abstraite du modèle de contrôle d’accès

Avant toute chose, nous tenons à rappeler brièvement les principaux besoins et problèmes liés

à la gestion des autorisations dans les communautés OpenPaaS RSE. D’abord, nous avons le

par-tage user-centric(cf. section Contrôle d’accès, chapitre Problématique et motivations) auquel

Chapitre 5. Contrôle d’accès

est associée la problématique de la vérification automatique de la consistance et la cohérence des

politiques de contrôle d’accès. Cela nous oriente vers un choix de langage formel de politiques. Le

partage user-centric donne aux acteurs le pouvoir de définir des permissions sur des ressources

ap-partenant à leurs entreprises. Ainsi, il faut que les entreprises aient leur autonomie pour garder le

contrôle sur leurs ressources partagées. Par ailleurs, le modèle de règles nécessite une grande

flexi-bilité dans un environnement hétérogène tel que le RSE, car les attributs identitaires par rapport

auxquels les politiques sont définis (le rôle par exemple) peuvent être hétérogènes et parfois avec

une sémantique non-symétrique entre deux ou plusieurs entreprise. En outre, nous avons également

souligné l’importance d’avoir la possibilité de définir des autorisations négatives (interdiction) pour

permettre à un propriétaire d’une ressource partagée (acteur/entreprise) de s’opposer (suspendre)

à une autorisation d’accès à la ressource en question. Ceci implique en outre la nécessité d’envisager

des stratégies de combinaison entre des règles et des politiques. D’un autre côté, nous avons présenté

et mis en évidence les avantages de la prise en compte du contexte, qui est davantage fructueuse dans

le cas où le contexte est exploité d’une manière dynamique et en temps réel afin d’adapter le

com-portement du mécanisme de décision. Pour cela, nous avons convenu qu’il est plus judicieux d’opter

pour une approche événementielle (i.e., basée sur les événements). Pour finir, nous avons discuté la

possibilité d’avoir des autorisations particulières, comme la délégation qui consiste en une

permis-sion temporaire. Par conséquent, notre choix du langage de politique a été guidé par la précédente

contrainte d’un formalisme“logique”ajouté au besoin d’inclure le temps pour la gestion des

permis-sions. Notre choix s’est porté sur la logique temporelleEvent-calculusqui est un langage formel basé

sur une logique de premier ordre, et par ailleurs doté d’un raisonneur automatique“Dec-Reasoner”

(cf. section Vers une implantation formelle de XACML, chapitreÉtat de l’art). Le modèle de contrôle

d’accès que nous proposons dans le cadre de cette thèse tient compte de l’intégralité de ces besoins.

5.2.1 Attribute Based Access Control

Par rapport aux nécessités que nous avons relevées dans le contexte du RSE, ABAC nous permet

de répondre aux besoins suivants :

— Flexibilité du modèle de règle : car grâce à ABAC, nous avons la possibilité de définir des

attributs supplémentaires et les combiner sous la même règle,e.g.le grade, les compétences,

l’adresse IP, la réputation, le type de terminal,etc..

— Possibilité de définir des interdictions : par le biais de l’ajout de l’attributtype, qui prend

comme valeur“Permit”pour une règle d’autorisation, ou“Deny”pour une règle d’interdiction.

— Autonomie des entreprises : puisqu’elles peuvent définir des contraintes supplémentaires

voire même des règles/politiques entières complémentaires à celles définies par les acteurs.

— Considération du contexte : grâce à la flexibilité des règles par rapport aux attributs

uti-lisés pour leurs définitions, entre autres le temps, ce qui permet également de définir des

permissions éphémères,i.e., délégation.

Un de nos objectifs en matière de contrôle d’accès dans OpenPaaSRSE est la possibilité de

dé-finir des autorisations temporaires. Par conséquent, nous avons fait le choix d’implanter le modèle

5.2. Représentation abstraite du modèle de contrôle d’accès

ABAC grâce à un langage formel qui inclut la gestion du temps, à savoir la logiqueEvent-calculus.

Dans la section suivante, nous présentons notre formalisme du modèle de contrôle d’accès basé sur

Event-calculus. Cependant, afin d’élucider le déroulement du processus du contrôle d’accès, nous

présenterons d’abord l’architecture de contrôle d’accès inspirée de XACML.

5.2.2 Vision d’architecture

Notre vision du RSE est principalement fondée sur le concept de communauté. La figure. 5.1

montre l’architecture de notre framework de contrôle d’accès dans chaque communauté du RSE.

Cette architecture est inspirée de l’architecture basique de XACML (cf. chapitreÉtat de l’art).

Néan-moins, nous l’avons étendu (par rapport à nos besoinOpenPaaS) avec un autre module de gestion

de la confiance.

1. Community Enforcement Service (CES): ce composant est l’interface entre l’acteur et le

système de contrôle d’accès de la communauté. Il sert en outre de pont entre le reste des

composants du framework.

2. Community Information Store (CIS): la base d’information de la communauté où les

attri-buts des ressources, acteurs et les organisations sont enregistrées.

3. Community Administration Store (CAdS): la base principale dans laquelle sont ajoutées,

administrées et stockées les politiques et règles de contrôle d’accès de la communauté.

4. Community Decision Service (CDS) : ce module est responsable de la prise de décision

finale vis-à-vis de toute requête reçue. Plus précisément, à la réception d’une requête, leCDS

recherche les politiques et règles duCAdScorrespondantes au sujet, génère par la suite les

patrons Event-calculus et enfin met en application les politiques vis-à-vis de la requête en

question au moyen du raisonneurDec-Reasoner.

5. Community Trust Service (CTS): ce service gère la réputation et la confiance numérique

des acteurs de la communauté. Pour évaluer et mettre à jour la réputation d’un acteur donné,

leCTSinteragit d’un côté avec leCESpour récupérer les informations de session courante de

l’acteur en question, et de l’autre côté interagit avec leCISpour récupérer les traces

d’inter-actions historiques de l’acteur.

Les différentes étapes illustrées dans la figure5.1peuvent être divisées en deux processus

paral-lèles et complémentaires, à savoir : le processus principal de contrôle d’accès (Bloc A) et un processus

complémentaire d’évaluation de la confiance numérique (Bloc B).

Trois modules sont impliqués dans le processus d’évaluation de la confiance, à savoir : leCES, le

CTSet leCIS. Le module principal dans ce processus est bien leCTS. Ce dernier interagit en premier

lieu (étape 1*) avec leCESpour récupérer les informations sur le comportement de l’acteur pendant

sa session courante. Ensuite (étape 2*), il récupère des informations sur l’historique d’évaluation de

la confiance de l’acteur en guise de paramètres pour la procédure d’évaluation de la confiance et la

réputation courante du même acteur.

Chapitre 5. Contrôle d’accès

CIS

CTS

CDS

CAdS

politiques

CES

2

1

3

Gestion règles et politiques

Service-Web Raisoneur logique Acteur Acteur (Demandeur d'accès) acteurs ressources règles Entreprise

1*

2*

Bloc A (Contrôle d'accès) Bloc B (Gestion de confiance)

3'

F

IGURE

5.1 – Architecture globale du frame-work de contrôle d’accès OpenPaaS.

Parallèlement, le processus du contrôle d’accès inclut quatre modules du framework, à savoir :

CES,CIS,CDSetCAdS. LeCAdSest le conteneur des politiques de sécurité, le noyau autour duquel

tout le framework est fondé. Il s’agit d’une base de données administrée par les entreprises ainsi que

les acteurs à travers l’insertion, la modification et la suppression de règles et politiques de contrôle

d’accès. Le composant principal dans le processus de prise de décision est leCDS. Afin qu’il puisse

prendre une décision d’autorisation d’accès (Étape 3), le CDSinteragit directement avec le CAdS

(étape 3’) pour récupérer les règles et politiques par rapport aux attributs d’une requête reçue, qui

lui sont transmis par leCES. Le CESpeut récupérer des métadonnées (contextuelles par exemple)

sur le sujet, l’objet et la requête avant de les transmettre au CDS (étape 2). Une fois la décision

prise par leCDSet transmise auCES, ce dernier se charge de notifier l’acteur de la décision en lui

autorisant ou refusant l’accès à la ressource demandée.

Dans le document Sécurité des ressources collaboratives dans les réseaux sociaux d'entreprise (Page 98-101)