Nouvelles Problématiques de Contrôle d Usage dans les Systèmes d Information

Transcription

1 Nouvelles Problématiques de Contrôle d Usage dans les Systèmes d Information Thierry Sans Frédéric Cuppens GET/ENST-Bretagne Département RSM, Campus de Rennes 2 rue de la Châtaigneraie BP Cesson Sévigné Cedex {thierry.sans,frederic.cuppens}@enst-bretagne.fr RÉSUMÉ. L évolution des systèmes d information pose de nouvelles problématiques de sécurité. Cet article a pour but, d une part, d identifier ces nouvelles problématiques et, d autre part, d identifier pourquoi les modèles de sécurité classiques et les architectures existantes sont inadéquats pour exprimer ces nouvelles exigences de sécurité. Au travers d une analyse critique du modèle UCON ABC, nous verrons quels sont les bases d un nouveau modèle de sécurité orienté contrôle d usage et quelles sont les problèmes liés à sa mise en œuvre. Enfin, nous traiterons des perspectives de recherche offertes par ces nouvelles problématiques. ABSTRACT. With the development of information systems technology, new security problems arise. This paper aims at identifying these new problems and then explains why classical security models and architectures are not sufficient to express these new security requirements. Through a critical analysis of the UCON ABC model, we define the basic concepts for a usage control oriented security model and present problems associated with its deployment. Finally, we investigate several research perspectives provided by usage control systems. MOTS-CLÉS : Contrôle d accès, Contrôle d usage, DRM, Modèles de sécurité, Architecture de contrôle d accès KEYWORDS: Access control, Usage control, DRM, Security model, Access control architecture

2 1. Introduction Les Systèmes d Information (SI) modernes évoluent rapidement. L information est de plus en plus distribuée, parfois même en dehors du domaine de contrôle du SI. Les modes d accès à l information ont changé, de nouveaux protocoles sont apparus pour échanger l information, tels que les protocoles Pair à Pair (P2P). Tous ces changements posent de nouveaux problèmes de sécurité auxquels les modèles et architectures de contrôle d accès existants ne peuvent faire face. Cet article a pour but de faire un point sur l évolution des SI et ainsi d identifier ces nouvelles problématiques de sécurité. Nous aurons une approche critique des solutions proposées dans la littérature et aborderons les solutions restant à mettre en œuvre pour répondre pleinement à ces nouvelles problématiques. Le reste de l article est organisé de la façon suivante. Dans la section 2, nous évoquerons comment la gestion de l information a évolué dans les SI. Nous poserons les nouvelles problématiques de sécurité induites par ces évolutions. Dans la section 3, nous verrons dans un premier temps quels sont les modèles de sécurité et les architectures de contrôle d accès existants. Nous verrons ensuite les limites de ces modèles et de ces architectures face aux évolutions des SI. Dans la section 4, nous présenterons un modèle de contrôle d usage définit par Park et Sandhu dans [PAR 04a]. Ce modèle tentera de répondre en partie aux nouveaux besoins de sécurité des SI. Dans la section 5, nous ferons une analyse critique du modèle et nous évoquerons les perspectives de recherches offertes par ces nouvelles problématiques de sécurité des SI. 2. Nouvelles problématiques des SI L apparition de nouveaux Business Models et l évolution des protocoles d échange d informations font que l information est de plus en plus distribuée, notamment de plus en plus déplacée du coté du client. Le fait que l information peut être hors du domaine de contrôle du SI traditionnel pose le problème du contrôle de cette information. Tout d abord, on doit protéger l information pour éviter une utilisation non contrôlée. Dans la plupart des cas, on se contentera de chiffrer le contenu, mais ce n est pas suffisant. Se pose ensuite le problème d avoir une application de confiance qui peut déchiffrer et contrôler l information de manière sûre afin que le client ne puisse pas accéder directement à l information en clair et ainsi contourner la protection. Ensuite, ne maîtrisant pas l information que l on souhaite protéger, on désire contrôler l usage et la diffusion de cette information. On veut donc pouvoir spécifier comment il est possible d utiliser cette information, de spécifier ces contraintes d utilisation. Toutes ces nouvelles problématiques vont au delà du contrôle d accès classique, on parle maintenant de contrôle d usage. Enfin, il s agit de définir des mécanismes permettant de mettre en œuvre ce contrôle d usage. Ces mécanismes devront être non falsifiables et surtout distribués là où est l information, c est-à-dire du coté du client.

3 Le domaine du DRM (Digital Rights Management) [ROS 01] pose toutes ces problématiques. Comment contrôler une information que je ne maîtrise plus, qui n est plus dans un domaine sous ma protection (chez le client final)? Comment spécifier les termes d utilisation de cette information? Dans le cas où ces mécanismes peuvent être définis, comment les garantir? 3. Spécifier et déployer le contrôle d accès Lorsque l on souhaite sécuriser un SI, la première question que l on doit se poser est : à quelles menaces ce SI doit-il faire face? L analyse de risque permet d identifier les menaces qui pèsent sur le SI. La politique de sécurité a pour but de réglementer le SI afin de mettre en place des protections efficaces pour répondre aux menaces identifiées par l analyse de risque. Une fois cette politique définie, il faut pouvoir la mettre en œuvre, i.e. configurer les composants de sécurité du système afin d appliquer la politique de sécurité sur le SI. Dans la première partie, nous ferons un rapide état de l art sur les modèles de sécurité permettant d exprimer une politique. Nous dégagerons les limites de ces modèles dans le cas des nouvelles problématiques exprimées précédemment. De même, nous évoquerons les architectures de contrôle d accès existantes afin de comprendre pourquoi elles ne sont plus adéquates pour les SI mettant en œuvre du contrôle d usage Spécifier la politique de sécurité La politique de sécurité vise à réglementer l accès aux informations du SI. Une politique de sécurité peut-être rédigée de manière non-formelle, i.e. sous la forme d un ensemble d exigences à mettre en œuvre lorsque seront définies les applications permettant d accéder aux information du SI. De manière plus formelle, le but de la politique de sécurité est de définir la matrice de contrôle d accès. C est à partir de cette matrice de contrôle d accès qu une application va pouvoir prendre une décision suite à une requête d accès au SI. Cette matrice est un ensemble de règles exprimant qu un sujet identifié peut exécuter une certaine action sur un objet géré par le SI : Le sujet est l entité active du système. Il désigne le plus souvent un utilisateur ou une application qui va interagir avec le SI. L objet est l entité passive de notre SI. Il désigne une information ou une ressource à laquelle un sujet peut accéder 1. L action désigne l effet recherché lorsqu on accède à un objet. On peut par exemple désirer lire ou écrire une information, ou bien, calculer une équation. Afin d identifier les entités du SI et de construire la matrice de contrôle d accès, on utilise des modèles de sécurité. Plusieurs modèles ont été proposé dans la littérature. Le premier modèle DAC [DAC87] est un modèle raisonnant directement sur la matrice de contrôle d accès. Ce modèle définit également des mécanismes d administration de la matrice. Le modèle MAC [BEL 76] est un modèle particulier. En plus de définir la matrice de contrôle d accès, il permet de contrôler les flux d information dans le SI. 1. "Accéder" dans le sens de "manipuler" une information ou "d utiliser" une ressource

4 Le modèle RBAC [SAN 96] propose une première abstraction des sujets en rôles. Les règles portent non plus directement sur les sujets mais sur les rôles. Tout sujet ajouté au SI obtient automatiquement des droits en fonction des rôles qu il joue dans le SI. L avantage d utiliser ce genre de modèles formels pour exprimer la politique de sécurité, est de pouvoir raisonner sur la politique de sécurité et vérifier la cohérence de celle-ci. En effet lorsque le nombre d entités de notre SI augmente, la simple matrice n est plus adaptée pour superviser la sécurité. L abstraction en rôle est une première avancée pour structurer la politique, mais, elle n est plus suffisante face à la complexité des systèmes à grande échelle et fortement distribués. Pour permettre une meilleure définition de ces systèmes, nous avons besoin d un modèle plus expressif. Tout d abord, ce modèle doit permettre une plus grande structuration de la politique afin de pouvoir décomposer la politique et en faciliter sa définition. Ensuite, il doit être possible d exprimer plus que de simples autorisations, mais aussi des interdictions, ou des obligations qui devront être remplies lors de l accès au SI. Enfin il faut pouvoir exprimer des règles soumises à des conditions sur l état du système ou sur le contexte de l accès au système. Typiquement, ces modèles sont inopérants pour spécifier le contrôle d usage définit précédemment. Plus récemment, le modèle Or-BAC [KAL 03] été proposé pour répondre à ces différents besoins. Il semble donc être un bon candidat pour exprimer les besoins de sécurité du contrôle d usage. Nous reviendrons sur ce point dans la suite de cette présentation Mettre en œuvre la politique de sécurité Une fois la politique définie, il faut implanter cette politique dans le SI. Pour cela, il faut exprimer la politique dans un langage d expression de droits (REL : Right Expression Language). Ce langage va permettre de configurer les composants (les applications) chargés de la mise en œuvre du contrôle. Dans la littérature, on parle de moniteur de référence (Reference Monitor). Le moniteur de référence est l application à laquelle s adresse un sujet désirant accéder aux informations du SI. Il est chargé d évaluer la requête et de prendre une décision sur la légitimité de cet accès en accord avec la politique. Par la suite, il doit appliquer cette décision en donnant l accès ou pas à l objet. Le moniteur de référence peut-être situé du coté serveur (SRM : Server-side Reference Monitor) ou bien du coté client (CRM : Client-side Reference Monitor). Dans le cas d un SRM, l information est donc protégée de manière centralisée du coté du serveur. Elle ne doit jamais être stockée en clair sur le client. C est la problématique classique du contrôle d accès traditionnel. Par exemple, les informations bancaires d un utilisateur sont stockées et protégées sur un serveur bancaire et jamais sur le poste client. Dans le cas d un CRM, l information se trouve sur le client. Pour éviter que l information soit accessible en contournant le moniteur de référence, l information est chiffrée sur le client. Le problème du tiers de confiance se pose ensuite [PEA 02, ERI 03]. Peut-on faire confiance au moniteur de référence situé chez le client? Est-il possible de détourner ou modifier le moniteur de manière à contourner la politique de sécurité?

5 Les systèmes DRM utilisent souvent cette architecture où l information et le moniteur de référence sont situés chez le client. Prenons l exemple de la distribution de musique en ligne de type B2C. L utilisateur final télécharge un morceau de musique protégé (chiffré) sur un site marchand. Le fichier est accompagné d une licence d utilisation (politique de sécurité) qui l autorise à lire le morceau de musique sous certaines conditions. A l aide du lecteur approprié (Moniteur de référence), il sera capable d interpréter la licence et, si les conditions sont satisfaites, de lire le morceau de musique. Pour définir le moniteur de référence, deux architectures ont été proposées. La première est un standard de l ISO sur la sécurité des architectures dans les systèmes ouverts (Security Framework in Open Systems) [ISO 01]. La seconde est un ensemble de RFCs (Request For Comments) de l IETF [LAA 00] : l architecture AAA (Authentication, Authorization, and Accounting) qui est un ensemble de recommandations concernant l authentification, le contrôle d accès et l audit. Ces architectures définissent deux composants principaux pour le moniteur de référence. Le premier composant est un module de décision, il raisonne sur la politique de sécurité pour décider de la légitimité d une requète au SI. Pour le standard ISO, le composant se nomme ADF (Access control Decision Facility). Dans les recommandations de l IETF, il se nomme PDP (Policy Decision Point). Le second composant est un module d application ; il est chargé d appliquer la décision et ainsi de donner l accès (ou non) à l information. Pour le standard ISO, le composant se nomme AEF (Access control Enforcement Facility). Dans les recommandations de l IETF, il se nomme PEP (Policy Enforcement Point). L avantage de ces architectures est qu elles sont, d après leurs spécifications, modulaires. Chaque composant est indépendant et communique avec les autres via un protocole spécifié. Cette modularité facilite la distribution du contrôle d accès dans le SI. Néanmoins, les composants et les protocoles de communication existants ont été spécifiés pour le contrôle d accès traditionnel et non pas pour le contrôle d usage. L aspect dynamique induit par le contrôle d usage ne peut pas être mis en œuvre dans ces architectures classiques à cause du manque d interaction entre les composants. Pour mettre en œuvre le contrôle d usage, nous avons besoin d une architecture plus dynamique, prenant en compte des politiques de sécurité qui peuvent évoluer au cours de l accès. Lorsque le module de décision s aperçoit que la politique ou les conditions d application de cette politique ont évolué, il doit en notifier le module d application sans qu il n ait eu a le solliciter de nouveau. Or cette interaction n est pas possible dans les architectures existantes. Dans le modèle UCON ABC [PAR 04a], présenté dans la section suivante, Park et Sandhu mettent en évidence qu un modèle de contrôle d usage ne peut être mis en application avec l architecture ISO telle qu elle est définie. Une nouvelle spécification du module de décision et du module d application doit être définie pour ces besoins. 4. UCON ABC : Un modèle de contrôle d usage Dans le modèle UCON ABC [PAR 04a], J.Park et R.Sandhu définissent le contrôle d usage comme une généralisation du contrôle d accès dans le sens où l on va évaluer la politique avant l accès mais aussi pendant l accès à une information. La politique de sécurité est un ensemble de permissions (autorisations), d obligations et de conditions.

6 Figure 1. Processus de contrôle d accès et d usage 4.1. Processus de contrôle Lorsqu un sujet désire accéder à une information du SI, il s adresse au moniteur de référence et forge une requête d accès (request). Ensuite, le processus de contrôle va décider de la légitimité de la requête en autorisant (ou non) le sujet à réaliser son accès. Ce processus de contrôle est illustré par le schéma état transition de la figure 1 issu de [ZHA 04]. Dans le contrôle d accès traditionnel, le processus de contrôle va évaluer la politique de sécurité avant que ne soit effectué l accès à l information. Dans le modèle UCON ABC, ce contrôle est dit préliminaire à l accès (pre). La décision sera soit de permettre (permit) soit de rejeter (deny) l accès. Afin de contrôler l usage lors d un accès, il faut pouvoir réévaluer la politique pendant l accès. Dans le modèle UCON ABC, ce contrôle est dit en cours de l accès (ongoing). Lors de l accès, la décision sera : soit de continuer à autoriser l accès (access), soit de révoquer l accès (revoke). Dans le cas où l utilisateur aura été autorisé à accéder à l information jusqu au terme de son action, le système sera notifié que l accès est terminé (end) Modèle basé sur les attributs Le modèle UCON ABC est basé sur une description des sujets et des objets par des attributs qui représentent les propriétés de ces entités. La politique de sécurité est définie par un ensemble de prédicats portant sur ces attributs. Dans le cadre du contrôle d usage, la politique de sécurité est dite dynamique, c est-à-dire qu elle peut changer pendant l accès à l information. Dans ce modèle, le changement dynamique de la politique de sécurité va se traduire par un changement des valeurs d attributs. On parle alors d attributs mutables 2. La modification d un attribut peut intervenir soit avant l accès à l information (pre), soit pendant l accès à l information (ongoing), soit à la fin de l accès (post). La mutabilité des attributs est traitée plus en détails dans [PAR 04b]. 2. Un attribut non-mutable est un attribut qui peut changer mais sous l intervention d un administrateur et non pas par un effet de bord de l accès à l information

7 Figure 2. Matrice des modèles UCON ABC 4.3. La famille UCON ABC Dans le modèle UCON ABC, la politique est exprimée avec des relations ternaires entre le sujet, l action et l objet. Ces relations sont de trois types : Les autorisations (ou permissions) sont définies à partir des attributs d un sujet et d un objet. Elles expriment sous quelles conditions le sujet est autorisé à accéder à l information représentée par l objet. Les obligations vérifient qu un ensemble de conditions sont toujours satisfaites lorsqu un sujet veut, ou est en train d accéder à un objet. Les conditions portent sur l environnement ou sur l état du système. Les obligations et les conditions sont différentes des autorisations dans le sens où la validation d une seule autorisation est suffisante pour valider l accès, alors que toutes les obligations et les conditions doivent être remplies pour autoriser l accès. Les conditions sont différentes des obligations car elles ne portent pas sur les attributs des sujets et des objets. Ainsi, un changement dynamique de la politique n a aucun effet sur l évaluation des conditions. Par contre, un changement de l état du système peut changer une décision portant sur un ensemble de conditions. UCON ABC est une famille de modèles. Comme le montre la figure 2, les différents modèles sont définies suivant : Si le contrôle est effectué avant (pre) ou pendant l accès (on). Si la décision porte sur des autorisations (A), des obligations (B) ou des conditions (C). Si les attributs ne changent pas (immutable), ou bien s ils changent avant (pre), pendant (ongoing) ou après (post) l accès Les modèles "préliminaires" Dans les modèles dit préliminaires, la décision d accepter une requête d accès est prise avant l accès à l information. Prendre une décision consistera à évaluer l ensemble des autorisations, obligations et conditions associées à une requête donnée avant d autoriser (ou non) l accès à l information.

8 UCON prea0 est le modèle d autorisation préliminaire sans modification des attributs. Il correspond à l approche classique du contrôle d accès telle que l abordent les modèles DAC, MAC et RBAC existants. Les modèles UCON prea1 et UCON prea3 autorisent respectivement la modification des attributs avant et après l accès. Par exemple, en appliquant UCON PreA1, on peut modéliser le cas classique dans le domaine du DRM où un utilisateur possède un compte prépayé pour écouter de la musique. Avant de lui autoriser l accès, on va vérifier que son solde est suffisant et le débiter avant qu il n écoute le morceau choisi. A partir du modèle UCON PreA3, on peut modéliser une facturation suivant la consommation. Un utilisateur autorisé peut lire un morceau de musique, son nombre d écoutes est comptabilisé et une facture lui est adressée. La manière d implémenter ce paiement périodique n est pas inclus dans le modèle lui-même et fait partie d une plus large réflexion sur les obligations générales et sur la gestion de flux. UCON preb0 est le modèle d obligation préliminaire sans modification des attributs. Il permet de modéliser, par exemple, qu un utilisateur doit accepter les termes d une charte d utilisation avant d accéder à l information. Avec UCON preb1, on peut définir que cette charte doit être acceptée seulement par les nouveaux utilisateurs. Ainsi, une fois la charte acceptée, on modifie un attribut du sujet exprimant qu il n est plus utilisateur novice du système. On peut aussi combiner les modèles en UCON preb13, et demander à ce que l utilisateur approuve à nouveau cette charte lors d un nouvel accès s il a dépassé un temps t d utilisation du SI. Les modèles UCON prec sont définis sur l état du système. Ces conditions étant indépendantes des attributs, seul le modèle UCON prec0 est pertinent. A partir de ce modèle, il est possible de modéliser par exemple une contrainte temporelle ou spatiale qui doit être vérifiée pour accorder l accès Les modèles en cours Dans les modèles dit en cours, la décision doit être réévaluée continuellement 3 pendant l accès à l information. Prendre une décision sera d évaluer l ensemble des autorisations, obligations et conditions associées à une requête donnée pendant que l utilisateur exécute cette requête. UCON ona0 est le modèle d autorisation en cours sans modification des attributs. Les modèles UCON ona1, UCON ona2 et UCON ona3 permettent respectivement de mettre à jour les attributs avant, pendant et après l accès à l information. En appliquant le modèle UCON ona13, il est possible de modéliser un nombre limite d utilisateurs du SI. Lorsqu un nouvel utilisateur arrive, on désire révoquer l utilisateur ayant la plus longue session d utilisation du système. Au moment de l accès, on définit un attribut correspondant au début de la session. Lors de l utilisation, si un autre utilisateur arrive, la plus ancienne session sera révoquée. Lorsqu un utilisateur quitte le SI, sa session est supprimée. De la même manière, avec UCON ona123 il est possible de modéliser 3. Périodiquement ou suivant des événements donnés. Le modèle UCON ABC ne spécifie pas quand la politique doit d être vérifiée.

9 un système de révocation en fonction de la plus longue période d inactivité d un utilisateur. Pendant l accès, si un utilisateur est inactif, un attribut définit le moment où l utilisateur a commencé à être inactif. De la même manière, UCON onb0 correspond au modèle d obligation en cours sans modification des attributs. Dans le cas d un fournisseur d accès Internet gratuit, ce modèle permet d exprimer qu un utilisateur doit avoir un bandeau publicitaire ouvert pendant que sa connexion est active. De même les modèles UCON onb1, UCON onb2 et UCON onb3 permettent la modification de ces attributs pendant le processus de contrôle. Sur le même exemple, avec UCON onb12, on peut exprimer qu un utilisateur doit avoir son bandeau de publicité ouvert pendant les 10 premières minutes de connexion. Ou bien, que l utilisateur doit cliquer sur un bandeau publicitaire toutes les 30 minutes de connexion. Avec le modèle UCON onb3, on peut exprimer qu un utilisateur doit voir un bandeau publicitaire après 30 heures de connexions mensuelles. Le nombre d heures accumulées est mise à jour à chaque fin de connexion. Pour les mêmes raisons que les modèles de conditions préliminaires, seul UCON onc0 existe pour les conditions en cours. Avec ce modèle on peut exprimer qu un utilisateur peut utiliser sa connexion Internet gratuite seulement pendant certains moments de la journée. 5. Discussion UCON ABC est le premier modèle à prendre en compte que la politique de sécurité doit non seulement s appliquer lors d une demande d accès, mais aussi qu elle doit être évaluée au cours de l accès à l information lorsqu on veut contrôler l usage de l information. Malgré cela, le modèle UCON ABC ne fournit pas véritablement de langage d expression de droits. En effet, la définition de la politique de sécurité est similaire à l approche XACML [MOS 05]. Ces approches reposent sur une description des entités par des attributs. La politique sera ensuite exprimée à partir de ces attributs. Bien que ce genre d approche soit très souple à utiliser, la manière de modéliser et de structurer la politique n est pas guidée par le modèle. L expressivité et la complexité de la politique de sécurité reposent sur une bonne modélisation des attributs. Ces approchent n apportent aucune solution aux problématiques de structuration lorsqu on est confronté à un SI complexe. Le modèle UCON ABC prend en compte les aspects provisionnels [HAL 03, JAJ 01] dans l expression de la politique de sécurité. Cela va au delà d une simple règle de sécurité de la matrice de contrôle d accès et permet d exprimer une condition sur une entrée de la matrice. Dans UCON ABC, ces conditions peuvent être exprimées à l aide de règles d autorisations, d obligations et de conditions. La notion de condition représente des contraintes sur l état du système. Ces contraintes ne reposant pas sur les attributs du système, le modèle ne définit pas comment exprimer ces contraintes et encore moins les mécanismes pour pouvoir les vérifier. Les notions d autorisation et d obligation portent uniquement sur les attributs. La notion d autorisation est proche de la règle d autorisation de la matrice de contrôle d accès, mais la notion d obligation apparaît quelque peu ambiguë. J.Park et R.Sandhu définissent

10 les obligations comme des conditions provisionnelles portant sur les sujet et les objets [JAJ 01]. Elle ne correspond pas à la notion d obligation telle qu on la retrouve dans la littérature [BET 02]. Une obligation correspond à une contrainte globale sur l utilisation du SI, mais non relative à un accès particulier. Les auteurs de UCON ABC se justifient en disant que cette notion d obligation globale ne fait pas partie du modèle de sécurité car le modèle ne raisonne que sur l interprétation de la politique face à une requête donnée. Le modèle UCON ABC laisse une autre question en suspend, celle de la mise en œuvre du modèle. En effet, il ne spécifie pas comment la politique de sécurité doit être vérifiée, ni comment elle doit être appliquée. En considérant que le modèle UCON ABC sert de support au module de décision, il ne spécifie pas comment vérifier les obligations et les conditions. Doit-on les vérifier à intervalle de temps régulier? Doit-on attendre un événement provenant d un changement de la politique 4 ou d un changement de l état du système? Ces questions marquent bien la différence entre la définition d un modèle de contrôle d usage pour exprimer la politique et sa mise en œuvre. Nous avons besoin d une architecture adéquate pour supporter une mise en œuvre dynamique de la vérification de la politique de sécurité. Dans [ZHA 04], Zhang et al. utilisent TLA (Temporal Logic of Actions) pour exprimer un ensemble de propriétés temporelles que doivent vérifier une telle architecture pour implémenter l approche par contrôle d usage. Néanmoins, ils ne proposent aucune spécification du système. 6. Conclusion et Perspectives Les aspects contrôle d usage apparaissent comme un besoin évident pour réglementer les SI. Néanmoins, les modèles de sécurité et les architectures de contrôle d accès existants sont insuffisants pour répondre à ces exigences. Tous d abord, les modèles classiques de sécurité ne sont pas suffisamment expressifs pour exprimer une politique de contrôle d usage. Un modèle plus expressif devra, d une part, permettre de spécifier aussi bien les permissions, les interdictions et les obligations générales du SI. D autre part, il devra permettre de définir des règles de sécurité dépendant d un contexte d application. Dans [CUP 03], F. Cuppens et A. Miège définissent une taxonomie de ces contextes d utilisations et identifient les mécanismes permettant de les vérifier. Ensuite, afin de répondre à la complexité des SI, nous devons disposer d un modèle permettant de structurer la politique de sécurité. D une part pour en faciliter sa définition et son administration. D autre part, pour pouvoir plus facilement la distribuer sur les composants de sécurité. Cette notion de structuration est primordiale pour les problèmes de passage à l échelle des SI fortement complexes. Récemment, Le modèle OrBAC [KAL 03] permet de complètement abstraire l expression de la politique par rapport aux composants de sécurité du SI et de structurer la politique avec la notion d organisation. Un modèle de contrôle d usage doit également permettre de spécifier 4. Lors d une modification des attributs

11 des contrôles avant, pendant et après l accès à une ressource par un sujet via une action particulière. Dans [CUP 05], un nouveau modèle appelé Nomad est proposé. Dans ce modèle, l exécution d une action par un sujet est représentée par différentes étapes : le sujet doit d abord demander l exécution de l action (request), il passe alors dans l état d attente (waiting), il peut ensuite éventuellement commencer l exécution de l action (start), ce qui le fait passer dans l étape de réalisation (during) qui se termine par l achèvement de l action (done). Alors que les modèles de contrôle d accès classiques ne permettent de règlementer que l étape start, l avantage de Nomad est qu il permet d associer des contraintes de sécurité aux différentes étapes d exécution de l action. Ce modèle semble donc bien adapté à l expression de politiques de contrôle d usage. Enfin, nous devons disposer d un architecture adéquate et modulaire pour pouvoir mettre en œuvre une politique de contrôle d usage. Les architectures existantes sont conçues de manière modulaire. Elles permettent la distribution des composants du système de contrôle d accès. Néanmoins, ces architectures apparaissent inadaptées pour mettre en œuvre des politiques de contrôle d usage. En effet, l application d une politique de contrôle d usage nécessite l évaluation de la politique au fur et à mesure que le système évolue. Lors de la mise en œuvre, ces aspects dynamiques se traduiront par une forte interaction entre le module de décision et le module d application de cette décision. Hormis la problématique de contrôle d usage étudiée dans cette article, la complexité des SI apporte de nouvelles perspectives dans la mise en œuvre de ce type de contrôle. Tout d abord lorsque le contrôle est déplacé du coté du client, on doit pouvoir faire confiance à l application qui va réaliser ce contrôle. Cette notion de tiers de confiance [PEA 02, ERI 03] reste le talon d Achille pour les SI fortement distribués. Ensuite, les SI font de plus en plus face à des utilisateurs qui ne sont pas a priori connus du système. La question n est plus de définir à qui je peux faire confiance, mais comment je vais leur faire confiance. C est la notion de gestion de la confiance étudiée dans [BLA 96]. Enfin, les aspects de protection de la vie privée [KOR 02] sont de plus en plus présents dans la définition de politiques de sécurité. Autoriser un utilisateur à accéder à son SI suppose que le SI va manipuler des informations lui appartenant. L utilisateur doit avoir la garantie par le SI que ces informations resteront sous son propre contrôle. 7. Bibliographie [BEL 76] BELL D. E., LAPADULA L. J., «Secure Computer Systems : Unified Exposition and Multics Interpretation», rapport n o ESD-TR , MTR-2997, Rev. 1, March 1976, MITRE Corporation, Bedfort, MA. [BET 02] BETTINI C., JAJODIA S., S.WANG X., WIJESEKERA D., «Obligation Monitoring in Policy Management», International Workshop, Policies for Distributed Systems and Networks (Policy 2002), Monterey, California, USA, June [BLA 96] BLAZE M., FEIGENBAUM J., LACY J., «Decentralized Trust Management», The 1996 IEEE Symposium on Security and Privacy (SSP 96), Oakland, CA, May 1996.

12 [CUP 03] CUPPENS F., MIÈGE A., «Modelling Contexts in the Or-BAC Model», 19th Applied Computer Security Associates Conference (ACSAC 2003), Las Vegas, Nevada, December [CUP 05] CUPPENS F., CUPPENS-BOULAHIA N., SANS T., «Nomad : A Security Model with Non Atomic Actions and Deadlines», 18th IEEE Computer Security Foundations Workshop (CSFW), Aix en Provence, France, June [DAC87] «A Guide to Understanding Discretionary Access Control in Trusted Systems», [ERI 03] ERICKSON J. S., «Fair Use, DRM and Trusted Computing», Communication of the ACM, vol. 46, n o 4, [HAL 03] HALPERN J. Y., WEISSMAN V., «Using First-Order Logic to Reason about policies», 16th IEEE Computer Security Foundation Workshop (CSFW 03), Pacific Grove, California, June [ISO 01] ISO INTERNATIONAL ORGANIZATION FOR STANDARDIZATION, «Information technology Open Systems Interconnection Security Frameworks in Open Systems Part 3 :Access Control, ISO/IEC », rapport, August 2001, ISO JTC 1. [JAJ 01] JAJODIA S., KUDO M., SUBRAHMANIAN V., «Provisional Authorizations», GHOSH A., Ed., E-commerce Security and Privacy, Kluwer Academic Publishers, 2001, p [KAL 03] KALAM A. A. E., BAIDA R. E., BALBIANI P., BENFERHAT S., CUPPENS F., DESWARTE Y., MIÈGE A., SAUREL C., TROUESSIN G., «Organization Based Access Control (Or-BAC)», IEEE 4th International Workshop on Policies for Distributed Systems and Networks (Policy 2003), Lake Come, Italy, June [KOR 02] KORBA L., KENNY S., «Applying Digital Rights Management Systems to Privacy Right Management», Journal of Computer and Security,, [LAA 00] DE LAAT C. T., GROSS G. M., GOMANS L., VOLLBRECHT J. R., SPENCE D. W., «Generic AAA architecture, RFC 2903», rapport, August 2000, IETF Internet Working Group. [MOS 05] MOSES T., «extensible Access Control Markup Language (XACML) Version 2.0», rapport, February 2005, OASIS. [PAR 04a] PARK J., SANDHU R., «The UCON ABC Usage Control Model», ACM Transactions on Information and System Security,, [PAR 04b] PARK J., ZHANG X., SANDHU R., «Attribute Mutability in Usage Control», 18th Annual IFIP WG 11.3 Working Conference on Data and Applications Security, Sitges, Spain, July [PEA 02] PEARSON S., «Trusted Computing Platforms : TCPA Technology In Context», Prentice Hall PTR, July [ROS 01] ROSENBLATT W., ROSENBLATT B., TRIPPE W., «Digital Rights Management : Business and Technology», Wiley, Decembre [SAN 96] SANDHU R. S., COYNE E. J., FEINSTEIN H. L., YOUMAN C. E., «Role-Based Access Control Models», IEEE Computer, vol. 29, n o 2, 1996, p [ZHA 04] ZHANG X., PARK J., PARISI-PRESICCE F., SANDHU R., «A Logical Specification for Usage Control», 9th Symposium on Access Control Models and Technologies (SACMAT 04), Yorktown Heights, NY, June 2004.