Frédéric Cuppens et Nora Cuppens-Boulahia

Transcription

1 Les modèles de sécurité Frédéric Cuppens et Nora Cuppens-Boulahia Abstract L objectif des modèles de sécurité est de donner une expression des besoins de sécurité des systèmes d informations (SI). Depuis le début des années 70, de très nombreux modèles ont été proposés. Nous nous intéressons, dans ce chapitre, à trois catégories de modèles : les modèles de contrôle d accès, de flux et d usage. Comme les utilisateurs d un SI n ont pas tous les mêmes droits d accès aux informations gérées par le SI, l objectif d un modèle de contrôle d accès est d exprimer une politique d autorisation. Les limites des modèles de contrôle d accès sont connues ; ils ne prennent pas en compte les attaques que peuvent réaliser les applications piégées par Chevaux de Troie. Des modèles de contrôle de flux ont donc été définis pour traiter ce problème. Plus récemment, pour prendre en compte les nouveaux besoins de sécurité présent dans certaines applications telles que la gestion des droits électroniques (DRM), des modèles de contrôle d usage ont été proposés. Dans tous les cas, un modèle de sécurité doit inclure la possibilité d exprimer une politique d administration qui spécifie qui peut gérer et mettre à jour la politique de sécurité. 1 Introduction Le début des années 70 a vu la définition des premiers modèles de sécurité : modèle de contrôle d accès [30] et de contrôle de flux [5]. Depuis, de nombreux modèles de sécurité ont été définis. L objectif de ce chapitre est de faire le point sur les principaux travaux menés sur ce sujet au cours des trente dernières années. Dans ce chapitre, nous ne considèrons pas les modèles conçus pour analyser les protocoles de sécurité, en particulier les protocoles cryptographiques. Ces modèles (voir par exemple [?]) ont été proposés pour analyser des propriétés telles que l authentification, la non répudation ou la fraicheur d une information. Dans ce chapitre, nous nous intéressons d abord aux modèles de contrôle d accès proposés pour modéliser des politiques d autorisation. Dans ce contexte, l un des premiers modèles proposés fut celui de Harrison, Ruzzo et Ullman (HRU, voir [26]). HRU a deux composantes : un modèle de contrôle d accès et un modèle d administration. Le modèle de contrôle d accès repose sur l identité des entités, d où le nom de I-BAC (Identity Based Access Control) pour désigner cette partie du modèle HRU. L administration est dite discrétionnaire, d où le nom de modèle discrétionnaire (ou DAC, Discretionary Access Control) que l on a tendance à utiliser pour désigner l ensemble du modèle HRU. Plusieurs limites sont apparues à l usage du modèle I-BAC. En particulier, le manque de structuration de ce modèle rend complexe l expression et la gestion d une politique d autorisation. De nombreux autres modèles ont ensuite été proposés. Ces modèles ont introduit de nombreux concepts pour davantage structurer l expression de la politique d autorisation : rôles, tâches, vues, équipes. Le modèles Or-BAC (Organization Based Access Control, voir [29]) permet de structurer l expression de la politique d autorisation en utilisant l ensemble de ces concepts. Des modèles à base de règles (Rule-BAC voir par exemple [27, 8] ont été proposés pour exprimer des politiques d autorisation incluant des règles de contrôles d accès dynamiques. L expression de ce besoin dans le modèle Or-BAC est également possible grâce à l introduction du concept de contexte. Les premiers modèles de contrôle d accès ne permettaient que d exprimer des autorisations positives ou permissions. Les modèles plus récents offrent également la possibilité d exprimer des 1

2 autorisations négatives ou interdictions. Ces modèles facilitent l expression de règles de contrôles d accès présentant des exceptions mais posent le problème de la gestion des conflits entre permissions et interdictions. Nous examinerons, dans la section 2.8, les principales stratégies de résolution de conflits qui ont été proposées dans la littérature. On sait depuis la définition du modèle de Bell et LaPadula [5] que les modèles de contrôle d accès ne permettent pas de prende en compte le problème des applications piégées, encore appelées Cheval de Troie. Bell et LaPadula ont ainsi défini le premier modèle de contrôle de flux (ou de type MAC, Mandatory Access Control). Cependant, ce premier modèle ne résoud pas tous les problèmes, en particulier la possibilité pour un Cheval de Troie de transmettre illégalement des informations via un canal caché. Le modèle de non-interférence [24] permet de traiter ce problème mais conduit à un cloisonnement strict du à l hypothèse extrême que toutes les applications peuvent être piégées par un Cheval de Troie. Dans la pratique, le modèle de Non Interférence s avère difficilement applicable. Des modèles plus récents permettant d assouplir les hypothèses trop pessimistes du modèle de non interférence ont ainsi été proposés. Nous présenterons en particulier dans ce chapitre les modèles de Bell et LaPadula étendu [4], DTE [?] et causalité [10]. Tous ces modèles de sécurité doivent inclure un modèle d administration pour exprimer qui peut définir et mettre à jour une politique d autorisation représentée dans ces modèles. Le premier modèle d administration est le modèle de type discrétionnaire proposé par HRU [26]. Ce premier modèle permet d administrer une politique d autorisation exprimée dans le modèle I-BAC. De très nombreux autres modèles d administration discrétionnaire ont ensuite été proposés et le modèle TAM (Typed Access Matrix, voir [?]) est peut-être le plus abouti dans ce domaine. Mais, l expression d une politique d administration dans ces modèles restent limitée. Plus récemment, de nouveaux modèles adaptés aux modèles RBAC (Role Based Access Control) ou Or-BAC ont été définis. Ces modèles sont auto-administrés, c est-à-dire la politique d administration s exprime en utilisant les mêmes concepts que ceux utilisés pour exprimer la politique d autorisation. Nous verrons également comment exprimer les besoins d administration dans les modèles de contrôle de flux de type MAC en contrôlant la déclassification. Enfin, dans les nouvelles applications plus ouvertes ne reposant plus nécessairement sur une architecture client-serveur, les modèles de contrôle d accès ou de contrôle de flux ne sont plus complètement adaptés. De nouveaux modèles voient le jour pour répondre aux besoins de contrôle d usage (voir par exemple, le modèle ABC [?]). Ces modèles ne limitent plus la politique de sécurité à l expression de permissions et d interdictions mais introduisent également le concept d obligation. Ces nouveaux modèles devraient, par exemple, être mis en œuvre dans les applications de gestion des droits électroniques (DRM) ou les services web. Le plan de ce chapitre est le suivant. Les sections 2 et 3 sont respectivement consacrées aux modèles de contrôle d accès et de contrôle de flux. La section 4 s intéresse aux modèles d administration. Enfin, la section 5 propose une synthèse et ouvre des perspectives sur les nouveaux modèles de contrôle d usage. 2 Contrôle d accès 2.1 Modèle I-BAC Nous désignons par I-BAC (Identity Based Access Control) le premier modèle de contrôle d accès proposé dans la littérature (voir [30]). Ce modèle introduit les concepts fondamentaux de sujet, d action et d objet : Le sujet est l entité active du SI. Il désigne le plus souvent un utilisateur ou une application s exécutant pour le compte d un utilisateur. L objet est l entité passive du SI. Il désigne une information ou une ressource à laquelle un sujet peut accéder pour réaliser une action. 2

3 L action désigne l effet recherché lorsqu un sujet accède à un objet. On peut par exemple désirer lire ou mettre à jour l information contenue dans un objet ou bien recopier le contenu d un objet dans un autre objet. L objectif du modèle I-BAC est de contrôler tout accès direct des sujets aux objets via l utilisation des actions. Ce contrôle est basé sur l identité du sujet et l identificateur de l objet, ce principe de contrôle d accès donnant son nom au modèle I-BAC. Le modèle I-BAC introduit ensuite le concept de politique d autorisation. Dans I-BAC, une politique d autorisation correspond à l expression d un ensemble d autorisations positives (ou permissions) ayant le format suivant : un sujet a la permission de réaliser une action sur un objet. La possibilité de spécifier dans un modèle de contrôle d accès des autorisations négatives (ou interdictions) ne sera offerte que beaucoup plus récemment. Nous examinons les modèles offrant cette possibilité dans la section 2.8. En fait, dans I-BAC, on suppose implicitement que la politique de contrôle d accès est fermée, c est-à-dire par défaut tous les accès sont interdits. La politique d autorisation spécifie donc des permissions et on refusera l accès si la politique d autorisation ne permet pas de dériver que l accès est explicitement permis. Pour représenter une politique d autorisation, le modèle proposé dans [30] introduit également un autre concept fondamental, celui de matrice de contrôle d accès qui sera ensuite repris dans plusieurs autres modèles (voir par exemple [26]). Dans une matrice de contrôle d accès, les lignes et colonnes de la matrice correspondent respectivement à l ensemble des sujets et des objets du SI. Les cases de la matrice représentent l ensemble des permissions qu un sujet donné possèdent sur un objet donné. Le modèle de type I-BAC est aujourd hui implanté dans la plupart des systèmes d exploitation actuels, tels que Windows, Unix ou Linux. Pour mettre en œuvre un tel modèle dans un SI, on n implante pas directement la matrice de contrôle d accès. Il existe en fait deux grandes approches possibles suivant que l implantation repose sur une décomposition en lignes ou en colonnes de la matrice. La décomposition en colonnes consiste à associer, à chaque objet, un descripteur appelé liste de contrôle d accès, qui représente l ensemble des sujets ayant des accès sur l objet considéré avec, pour chaque sujet, l ensemble des actions que ce sujet peut réaliser sur cet objet. La décomposition en ligne consiste à associer à chaque sujet, un ensemble de capacités, représentant l ensemble des objets auxquels le sujet peut accéder avec, pour chaque objet, l ensemble des actions que le sujet peut réaliser sur cet objet. A l usage, une limite importante du modèle I-BAC est apparue : la politique d autorisation devient rapidement complexe à exprimer et administrer. Il est en effet nécessaire d énumérer les autorisations pour chaque sujet, action et objet. En particulier, lorsqu un nouveau sujet ou objet est créé, il est nécessaire de mettre à jour la politique d autorisation pour définir les nouvelles permissions associées à ce sujet ou objet. Pour pallier ce problème, des modèles ont plus récemment été définis. Tous ces modèles ont en commun de proposer une expression plus structurée de la politique d autorisation. Nous présentons dans les sections suivantes, les modèles proposant respectivement une structuration des sujets, des actions et des objets. 2.2 Modèle R-BAC Le modèle RBAC (Role Based Access Control, voir [34]) propose de structurer l expression de la politique d autorisation autour du concept de rôle. Un rôle est un concept organisationnel : des rôles sont affectés aux utilisateurs conformément à la fonction de ces utilisateurs joue dans l organisation. Le principe de base du modèle R-BAC est de considérer que les autorisations sont directement associées aux rôles. Dans R-BAC, les rôles reçoivent donc des autorisations de réaliser des actions 3

4 sur des objets. Comme I-BAC, le modèle R-BAC ne considère que des autorisations positives (permissions) et fait donc l hypothèse que la politique est fermée. Un autre concept introduit par le modèle R-BAC est celui de session. Pour pouvoir réaliser une action sur un objet, un utilisateur doit d abord créer une session et, dans cette session, activer un rôle qui a reçu l autorisation de réaliser cette action sur cet objet. Si un tel rôle existe et si cet utilisateur a été affecté à ce rôle, alors cet utilisateur aura la permission de réaliser cette action sur cet objet une fois ce rôle activé. Lorsqu un nouveau sujet est créé dans le SI, il suffit d affecter des rôles à ce sujet pour que ce sujet puisse accéder au SI conformément aux permissions accordées à cet ensemble de rôles. Comparé au modèle I-BAC, la gestion de la politique d autorisation s en trouve simplifiée puisqu il n est plus nécessaire de mettre à jour cette politique chaque fois qu un nouveau sujet est créé. Dans le cas général, n importe quel ensemble de rôles peut être affecté à un utilisateur et un utilisateur peut activer dans une session n importe quel sous-ensemble des rôles qui lui ont été affectés. Le modèle R-BAC introduit la notion de contrainte pour spécifier des politiques d autorisation incluant des situations plus restrictives. Ainsi, une contrainte de séparation statique spécifie que certains rôles, par exemple médecin et infirmier, ne peuvent pas être simultanément affectés à un utilisateur. Une contrainte de séparation dynamique spécifie que, même si certains rôles peuvent être affectés à un utilisateur, par exemple médecin libéral et chirurgien, ces rôles ne peuvent pas être activés simultanément dans une même session. Dans R-BAC, il est également possible d organiser les rôles de façon hiérarchique. Les rôles héritent les autorisations des autres rôles qui lui sont hiérarchiquement inférieurs. Lorsqu un rôle r 1 est hiérarchiquement supérieur à un rôle r 2, on dit que r 1 est un rôle senior de r 2. Le modèle R-BAC constitue aujourd hui un standard [21]. De nombreux SI mettent en œuvre ce standard, par exemple Unix Solaris à partir de la version 8 ou l API Authorization Manager RBAC de Windows Server Modèle T-BAC Dans les modèles I-BAC et R-BAC, les actions correspondent généralement à des commandes élémentaires, comme la lecture du contenu d un objet ou l écriture dans un objet. Dans les applications récentes, le besoin apparaît de contrôler la réalisation d actions composites, appelées tâches ou activités. Par exemple, dans une agence de voyage, la tâche d achat d un billet d avion se décompose en plusieurs actions plus élémentaires telles que la réservation du billet, le paiement du billet et l édition d une facture. Le besoin de contrôle sur des activités composites est en particulier présent dans les applications de type workflow [3]. Le modèle T-BAC (Task Based Access Control, voir [36]) fut le premier modèle à introduire le concept de tâche. D autres modèles ont ensuite été développés pour contrôler l exécution des activités dans un workflow (voir [9, 39]). En particulier, l utilisateur ne doit obtenir une permission que lorsque c est nécessaire pour poursuivre l exécution de l activité considérée ( just in time permission). Ainsi, dans l exemple d achat d un billet d avion, la permission d éditer une facture ne doit être activée qu après la réservation et l achat du billet. 2.4 Modèle V-BAC Les modèles R-BAC et T-BAC ont respectivement introduit les concepts de rôle et de tâche pour structurer les sujets et les actions. Pour faciliter l expression et la gestion d une politique d autorisation, nous avons également besoin d un concept pour structurer les objets. Parmi les modèles de contrôle d accès proposant une telle structuration des objets, on peut citer le modèle de sécurité proposé par SQL pour les bases de données relationnelles. L expression d une politique de sécurité en SQL repose sur le concept de vue. Nous désignerons donc par V-BAC (View Based Access Control) ce type de modèle de contrôle d accès. Intuitivement, dans une base de données relationnelle, une vue correspond au résultat d une requête SQL auquel on a donné un nom. Ce concept de vue est ensuite utilisé pour structurer l expression 4

5 d une politique d autorisation à l aide des instructions GRANT (qui permet d accorder une nouvelle permission à un utilisateur) et REVOKE (qui permet de supprimer une permission que possédait un utilisateur). Une vue constitue donc un moyen efficace pour accorder un accès à l ensemble des objets contenus dans la vue. A noter que ces objets sont parfois virtuels dans la mesure où une vue SQL n est pas matérialisée. SQL/3 [31], qui correspond à la dernière évolution de la norme SQL, propose d étendre le modèle V-BAC en combinant les concepts de vue et de rôle pour structurer les objets et les sujets. On peut ainsi définir le modèle VR-BAC. Le concept de vue ne se limite pas au modèle relationnel. On pourrait aussi l utiliser dans un système d exploitation. Actuellement, la plupart des systèmes d exploitation ne proposent que le concept de répertoire pour structurer l expression de la politique d autorisation. En utilisant le concept de vue, on pourrait par exemple définir une vue contenant l ensemble des objets ayant pour suffixe.doc et appartenant au répertoire /pierre/projet1 et utiliser cette vue dans l expression de la politique d autorisation du système d exploitation. Dans ce cas, une syntaxe reposant sur XPath pourrait être proposée pour exprimer la politique d autorisation. C est déjà l approche utilisée pour spécifier une politique d autorisation pour documents XML (voir par exemple [7, 23]). 2.5 Modèle T-MAC Dans les applications récentes, il est souvent nécessaire de considérer plusieurs organisations simultanément. Par exemple, dans les applications de services web, un utilisateur d une certaine organisation peut souhaiter accéder aux données appartenant à une autre organisation. Une organisation est une entité structurée. Par exemple, un hôpital correspond à une organisation qui se décompose en plusieurs sous-organisations : les différents départements de l hôpital, les différents services de ces départements, etc. Chaque organisation gère en général sa propre politique d autorisation. Certaines organisations peuvent également être créées dynamiquement en fonction des activités que doit prendre en charge l hôpital. Par exemple, une équipe de soin peut être créée pour prendre en charge un patient particulier. Cette organisation pourra ensuite être dissoute une fois les activités réalisées. Remarquons que les autorisations d un sujet dépendent non seulement du rôle du sujet mais également de l organisation dans laquelle ce sujet exerce son rôle. Ce problème a été identifié dans le modèle T-MAC. Le modèle T-MAC (Team Based Access Control, voir [37]) introduit la notion d équipe. Dans T-MAC, des autorisations sont associées aux rôles ainsi qu aux équipes. Les autorisations que possède un sujet résultent de la combinaison des autorisations associées aux rôles exercés par le sujet et des autorisations associées à l équipe à laquelle est affecté le sujet. Plusieurs combinaisons (par exemple, l union des autorisations) sont envisagées. En fait, le modèle T-MAC est incorrect car il introduit deux relations binaires : rôle-autorisation et équipe-autorisation. Si l on introduit la notion d équipe, il est en fait nécessaire de considérer une relation ternaire équipe-rôle-autorisation pour spécifier que les autorisations dépendent non seulement du rôle mais aussi de l équipe dans laquelle est exercée ce rôle. A l aide d une telle relation ternaire, on pourra ainsi facilement spécifier que les autorisations du rôle médecin change suivant qu il s agit d un médecin dans une équipe de garde ou d un médecin dans une équipe d urgence. Cette imperfection du modèle T-MAC a été corrigée dans le modèle Or-BAC, que nous allons présenté maintenant. 2.6 Modèle Or-BAC Le modèle Or-BAC (Organization Based Access Control, voir [29]) reprend les concepts de rôle, d activité, de vue et d organisation introduites respectivement dans les modèles R-BAC, T-BAC, V-BAC et T-MAC. Dans Or-BAC, l expression d une politique d autorisation est centrée sur le 5

6 concept d organisation (contrairement à R-BAC où la politique d autorisation est centrée sur le concept de rôle). Les concepts de rôles, de vues et d activités sont des concepts organisationnels. Chaque organisation définit ainsi les rôles, les activités et les vues dont elle souhaite réglementer l accès en appliquant une politique d autorisation. Le modèle Or-BAC introduit donc trois relations relevant-role, relevant-activity et relevant-view pour spécifier respectivement les rôles, les activités et les vues gérés par l organisation. Ensuite, chaque organisation spécifie les affectations des sujets aux rôles en utilisant la relation ternaire empower. On peut remarquer que cette modélisation permet, par exemple, de considérer qu un même sujet est affecté à des rôles différents suivant l organisation considérée. De façon similaire, deux autres relations ternaires consider et use permettent de respectivement spécifier, pour chaque organisation, les relations entre action et activité d une part, et entre objet et vue d autre part. Le modèle Or-BAC offre également la possibilité de spécifier des role-definition, view-definition et activity-definition. Une role-definition est une condition logique qui, si elle est satisfaite, permet de conclure qu un sujet se trouve automatiquement affecté au rôle correspondant à la role-definition. De façon similaire, une view-definition et une activity-definition correspondent à des conditions logiques pour gérer respectivement les vues et les activités. Une politique d autorisation s exprime en spécifiant, pour chaque organisation considérée, les activités que les rôles ont la permission de réaliser sur les vues. La politique d autorisation s exprime donc de façon complètement indépendante des ensembles de sujets, actions et objets gérés par le SI. On parle ainsi de politique d autorisation organisationnelle. Le modèle propose une règle de passage pour dériver automatiquement, d une politique d autorisation organisationnelle, les permissions concrètes s appliquant aux sujets, actions et objets. Cette règle spécifie que, dans une organisation donnée, si un sujet est affecté à un certain rôle, un objet est utilisé dans une certaine vue, une action implante une certaine activité et si la politique d autorisation de cette organisation spécifie que ce rôle a la permission de réaliser cette activité sur cette vue, alors on peut dériver que ce sujet a la permission de réaliser cette action sur cet objet. Dans Or-BAC, on peut également définir des hiérarchies de rôles (comme dans R-BAC), mais aussi d activités, de vues et d organisations. Chacune de ces hiérarchies est associée à un mécanisme d héritage des permissions (voir [16] pour plus de détail). La définition de ces hiérarchies permet une expression plus modulaire de la politique d autorisation organisationnelle. 2.7 Modèles d autorisations dynamiques et contextuelles Dans la pratique, de nombreuses autorisations ne sont pas statiques mais dépendent de conditions qui, si elles sont satisfaites, permettent d activer dynamiquement les autorisations. Dans ce cas, on parle souvent d autorisations contextuelles. Ainsi, les autorisations peuvent dépendre de contextes temporels (par exemple permission pendant les heures de travail), contextes géographiques (par exemple, permission à l intérieur de l enceinte sécurisée de l entreprise), de contextes provisionnels (permission si d autres actions ont au préalablement été réalisées comme dans le cas d un workflow). D autres types de contextes peuvent être également être définis (voir [20] pour une proposition de taxonomie). Pour représenter ces autorisations contextuelles, plusieurs modèles de contrôle d accès à base de règles ont été proposés (modèles de type Rule-BAC, voir [27, 8]). Dans ces modèles, une politique d autorisation correspond à un enesemble de règles de la forme condition permission qui spécifient qu une permission peut être dérivée lorsqu une certaine condition est satisfaite. Les modèles de type Rule-BAC repose sur la logique du premier ordre qui est, dans le cas général, indécidable. Face à ce problème, la plupart de ces modèles propose d utiliser Datalog pour avoir une procédure de décision en temps polynomial à condition que les règles respectent certaines restrictions syntaxiques (voir [38] pour plus de détail). Comparés aux modèles présentés dans les sections précédentes, les modèles Rule-BAC présentent une expressivité plus grande, utile pour spécifier des autorisations contextuelles. En contrepar- 6

7 Abstract level Activity Context Role Permission View Consider Empower Organization Use Concrete level Action Subject Is_permitted Object Figure 1: Structure du modèle Or-BAC tie, on perd malheureusement la structuration de la politique d autorisation que permettaient l introduction des concepts de rôle, d activité, de vue et d organisation. Le modèle Or-BAC offre également la possibilité d exprimer des autorisations contextuelles. Pour cela, le concept de contexte est explicitement introduit dans le modèle. La définition d un contexte correspond à une condition logique qui permet de conclure que l on se trouve dans le contexte lorsque cette condition est satisfaite. Remarquons que chaque organisation définit ses contextes ce qui permet de modéliser que la définition d un contexte tel que heure de travail peut varier d une organisation à une autre. En fait, dans la section 2.6, nous avons volontairement simplifié l expression d une politique d autorisation organisationnelle en Or-BAC. Dans le cas général, une autorisation spécifie qu un rôle a la permission de réaliser une activité sur une vue dans un contexte particulier. La règle de passage pour dériver les permissions concrètes s appliquant aux sujets, actions et objets est aussi légèrement plus coomplexe que celle présentée dans la section 2.6 puisqu une permission ne doit être activée que lorsque la condition contextuelle correspondante est satisfaite (voir [20]). Pour conclure cette section, remarquons qu Or-BAC impose les mêmes contraintes syntaxiques que celle imposée par Datalog de manière à conserver une procédure de décision calculable en temps polynomial même lorsque l on considère des autorisations contextuelles. Le modèle Or-BAC offre donc une expressivité comparable à celle des autres modèles de type Rule-BAC tout en proposant une expression très structurée de la politique d autorisation. 2.8 Modèles d autorisations positives et négatives Initialement, les modèles de contrôle d accès ne permettaient que d exprimer des autorisations positives (permissions). Récemment, des modèles offrant également la possibilité d exprimer des autorisations négatives (interdictions) ont été proposés [6, 27, 9]. Combiner des autorisations positives et négatives dans une politique d autorisation est intéressant pour plusieurs raisons : Certaines politiques d autorisation sont plus faciles à décrire en terme d interdictions que de permissions. Par exemple, considérer une règle spécifiant que l accès à une certaine vidéo est interdite aux personnes de moins de 12 ans. 7

8 Lorsque la politique d autorisation doit être mise à jour, il est parfois plus simple d insérer une interdiction que de supprimer une permission existante. La combinaison des permissions et interdictions constitue un moyen simple pour exprimer des règles présentant des exceptions. Par exemple, on peut considérer les règles suivantes : (1) Les infirmiers ont l interdiction d accéder au dossier médical des patients, mais (2) En situation d urgence, les infirmiers ont la permission d accéder au dossier médical du patient concerné par l urgence. Dans ce cas, la règle (2) doit être interprétée comme une exception de la règle (1). Dans la suite, on dira que la politique d autorisation est mixte lorsqu elle inclut des autorisations positives et négatives. Remarquons que dans une politique d autorisation mixte, on peut faire l hypothèse que la politique est ouverte ou fermée. Une politique ouverte considère qu un accès est accepté si la politique d autorisation ne permet pas de dériver que l accès est explicitement interdit. Il s agit donc de l hypothèse inverse de la politique fermée déjà introduite dans la section 2.1. Un nouveau problème apparait lorsque l on considère des politiques d autorisation mixtes : celui de la gestion des conflits entre les autorisations positives et négatives. En effet, pour un sujet, une action et un objet donnés, il est possible que la politique d autorisation permette de dériver que l accès est à la fois permis et interdit. Pour résoudre ces situations de conflits, plusieurs stratégies ont été proposées dans la littérature. Certaines approches (voir par exemple [27]) ne considèrent que des stratégies simples, telles que les interdictions l emportent toujours sur les permissions, ou les permissions l emportent toujours sur les interdictions. Ces stratégies ne conviennent pas pour traiter le problème des exceptions. En effet, si une interdiction agit comme exception à une permission, alors cette interdiction doit l emporter sur cette permission. Mais, dans le cas contraire, c est-à-dire si une permission agit comme exception à une interdiction, alors c est la permission qui doit l emporter sur l interdiction. Pour rendre compte de stratégies plus élaborées permettant de gérer les exceptions, plusieurs modèles [6, 19] ont proposé d introduire des priorités entre les règles de la politique d autorisation. La plupart des pare-feux donnent des exemples représentifs de mise en œuvre de ce type de stratégies. En effet, on peut interpréter les règles de filtrage d un pare-feu comme un ensemble d autorisations positives (dans le cas où la décision de la règle de filtrage est d accepter le paquet) ou négatives (dans le cas où la décision est de rejeter le paquet). La priorité entre règles de filtrage correspond en général à l ordre dans lequel les règles ont été écrites. Ainsi, lorsque plusieurs règles s appliquent sur un même paquet, la décision finale correspond à celle de la première règle applicable (stratégie dite du first matching ). L ordonnancement des règles constitue donc un moyen simple, mais efficace pour résoudre les conflits dans une politique d autorisation mixte. Cependant, cette ordonnancement rend la politique d autorisation plus complexe à exprimer et à mettre à jour. En effet, d autres problèmes peuvent apparaître : le masquage (shadowing) et la redondance. L anomalie de masquage apparaît lorsqu une règle devient inapplicable car des règles plus prioritaires seront systématiquement appliquées avant elle. L anomalie de redondance existe lorsqu une règle peut être supprimé sans que cela change la politique d autorisation. Par exemple, si l on considère les deux règles suivantes : (1) L accès à la vidéo V est interdite aux personnes de moins de 12 ans, (1) L accès à la vidéo V est interdite aux personnes de moins de 16 ans. Alors la règle (1) est redondante. Détecter ces anomalies dans une politique d autorisation est important car (1) elles sont souvent révélatrices d erreur dans l expression de la politique d autorisation, (2) même si elles ne correspondent pas à des erreurs, l élimination de ces anomalies permet de réduire le nombre de règles de la politique d autorisation. Dans le cas des pare-feux, [2] propose un algorithme pour détecter certaines anomalies dans un ensemble de règles de filtrage. Cet algorithme n étant malheureusement pas complet, un autre algorithme permettant de détecter et éliminer toutes les anomalies a ensuite été proposé dans [15]. 8

9 3 Contrôle de flux Pour bien comprendre l intérêt des modèles de contrôle de flux, il faut d abord revenir sur le concept de sujet introduit dans la section 2.1. Nous avons indiqué qu un sujet correspondait à un utilisateur ou une application s exécutant pour le compte d un utilisateur. Dans le cas d un utilisateur, on suppose que celui-ci peut essayer de violer la politique d autorisation en accèdant illégalement à des objets. Mais s il obtient légalement une information, on suppose également qu il ne va pas volontairement transmettre cette information à un autre utilisateur qui n aurait pas le droit de connaître cette information. Par exemple, on suppose qu un médecin ne va pas volontairement transmettre le contenu du dossier médical d un de ses patients à une personne non autorisée. Il faut naturellement que l organisation mette en place des procédures pour que cette hypothèse soit justifiée (par exemple habilitation, serment d Hippocrate mais aussi sensibilisation des utilisateurs aux risques informatiques). En revanche, on ne peut pas toujours faire les mêmes hypothèses si le sujet est une application s exécutant pour le compte d un utilisateur. En effet, certaines applications peuvent être piégées. On parle alors de Cheval de Troie. Un Cheval de Troie peut avoir divers objectifs malveillants visant à porter atteinte à la confidentialité, l intégrité ou bien la disponibilité des informations du SI. Dans le cas de la confidentialité, l objectif de l application est d accéder à des informations et de volontairement transmettre ces informations vers un utilisateur qui n a pas la permission d y accéder. Cet utilisateur est le bénéficiaire du piège ; il peut s agir par exemple du concepteur de l application, d un agent chargé de sa maintenance ou d un utilisateur qui a réussi à remplacer l application légitime par une application piègée. Pour illustrer ce problème, considérons un médecin qui utilise son SI pour consulter les dossiers médicaux de ses patients. Supposons également que ce médecin puisse utiliser son SI pour consulter un dictionnaire médical via Internet et que ce médecin utilise une seule application pour à la fois consulter les dossiers médicaux et accéder au dictionnaire médical. Si cette application est piégée, alors il est possible que cette application utilise la connexion Internet pour transmettre, à l insu du médecin, des informations contenues dans les dossiers médicaux. Les modèles de contrôle d accès présentés dans la section 2 ne permettent pas d empêcher les actions malveillantes d une telle application piégée. En effet, cette dernière peut réaliser son attaque sans violer la politique d autorisation : elle consulte légitimement les dossiers médicaux et ensuite utilise l accès Internet qui permet d accéder au dictionnaire médical pour transmettre les dossiers médicaux vers le bénéficiaire du piège. Cela ne veut pas dire que ces modèles de contrôle d accès sont inutiles. Mais, si l on veut empêcher les attaques par Chevaux de Troie, il faut seulement utiliser ces modèles pour définir la politique d autorisation des utilisateurs et des applications de confiance, c est-à-dire des applications que l on peut garantir sans piège. Pour contrôler l exécution des applications qui ne sont pas de confiance, d autres modèles, appelés modèles de contrôle de flux (ou MAC, Mandatory Access Control), ont été définis. L objectif de ces modèles est précisément d assurer le confinement des applications pour empêcher les attaques par Chevaux de Troie. Comme plusieurs modèles de type MAC pour la confidentialité ont été définis, nous présentons ici les principaux : modèle de Bell et LaPadula, Non Interférence, Bell et LaPadula étendu et Causalité. Nous présentons ensuite les modèles de type MAC pour l intégrité. Les modèles de contrôle de flux pour la confidentialité et l intégrité sont complémentaires : ils doivent être combinés pour garantir ces deux propriétés de sécurité dans le SI. 3.1 Modèle de Bell et LaPadula Le modèle de Bell et LaPadula [5] fut le premier modèle de type MAC proposé. L objectif de ce modèle est de définir des contraintes pour contrôler l exécution des applications de manière à empêcher les attaques par Chevaux de Troie contre la confidentialité. Le modèle de Bell et LaPadula considère des politiques de sécurité de type MAC particulière, dite politique de sécurité multi-niveaux. Dans ce type de politique d autorisation, on introduit un ensemble partiellement ordonné de niveaux de sécurité, par exemple Non-classifié (NC), Confidentiel 9

10 Z1 L1 L2 Z2 Z3 L4 L3 Figure 2: Passage d une politique de type I-BAC vers une politique de type MAC (C) et Secret (S). Tous les utilisateurs doivent avoir reçu un tel niveau de sécurité pour pouvoir accéder au SI ; il s agit du niveau d habilitation de l utilisateur. On affecte également un niveau de sécurité à tous les objets gérés par le SI ; il s agit du niveau de classification de l utilisateur. La politique d autorisation associée aux utilisateurs est simple : un utilisateur n a la permission de lire un objet que si son niveau d habilitation est supérieur ou égal au niveau de classification de l objet lu. Sinon, l utilisateur a l interdiction de lire cet objet. On appelle habituellement cette condition No Read Up. En revanche, on suppose que les applications peuvent être piégées. Une application travaille pour le compte d un utilisateur. Le niveau d exécution, encore appelé niveau courant, d une application est choisi par l utilisateur mais doit être inférieur ou égal au niveau d habilitation de cet utilisateur. Pour empêcher une application de lire des objets interdits, on impose qu une application ne peut lire un objet que si son niveau courant est supérieur au niveau de classification de l objet. On appelle également cette condition No Read Up. Comme le niveau courant d une application est toujours inférieur ou égal au niveau d habilitation de l utilisateur exécutant l application, la condition de No Read Up sur les applications implique la condition de No Read Up sur les utilisateurs. Mais, dans le modèle de Bell et LaPadula, on souhaite également empêcher qu un Cheval de Troie puisse transmettre le contenu d un objet lu vers un utilisateur u qui aurait l interdiction de lire cet objet. Dans ce modèle, on suppose que le Cheval de Troie effectuera cette transmission illégale en recopiant le contenu de l objet lu dans un autre objet que u pourra lire. Pour înterdire ce flux illégal, on impose qu une application ne peut écrire dans un objet que si le niveau courant de l application est inférieur ou égal au niveau de classification de l objet. On appelle cette condition No Write Down ou propriété étoile. Le but unique de la condition de No Write Down est d empêcher un Cheval de Troie de réaliser une attaque contre la confidentialité. Elle n empêche pas une attaque contre l intégrité au cours de laquelle une application tenterait de modifier illégalement des objets. Ce n est pas l objectif du modèle de Bell et LaPadula d empêcher ce type d attaque. Des modèles ont été définis pour cela (voir section??). Le passage d une politique d autorisation de type I-BAC vers une politique multi-niveaux de type MAC est toujours possible. A titre d exemple, considérons le schéma de la figure 2. Z1, Z2 et Z3 sont trois ensembles d objets et l on suppose que Z1 Z2, Z1 Z3 = et Z3 Z2. On suppose que le système est utilisé par quatre utilisateurs s1, s2, s3 et s4. Supposons par exemple, que dans une politique d autorisation de type I-BAC, Z1 est l ensemble des objets accessibles en lecture par s1, Z2 est celui accessible en lecture par s2 et Z3 celui accessible par s3 et s4 (on suppose que s3 et s4 ont les mêmes droits d accès en lecture). Dans ce cas, on introduit quatre niveaux de sécurité L1, L2, L3 et L4, avec L3 < L2, L4 < L1 et L4 < L2. s1 est habilité au niveau L1, s2 au niveau L2 et, s3 et s4 au niveau L3. Les objets reçoivent les classifications suivantes : Objets de Z1 Z2 classés L1 10

11 Objets de Z2 (Z1 Z3) classés L2 Objets de Z3 classés L3 Objets de Z1 Z2 classés L4 Soit par exemple une application exécutée par s1 au niveau L1. Ce programme pourra lire l ensemble des objets de Z1. En revanche, il ne pourra pas écrire dans Z1 Z2 pour éviter un éventuel flux vers s2 (dans l hypothèse où le programme serait piégé). On peut remarquer que le passage I-BAC à MAC est faisable mais peut générer dans la pratique un grand nombre de niveaux. 3.2 Modèle de Non Interférence Dès la définition de leur modèle, Bell et LaPadula avaient observé que celui-ci ne permettait de contrôler que les Chevaux de Troie qui essayent de transmettre illégalement des informations par recopie dans un fichier. D autres moyens de transmettre illégalement des informations existent que peut exploiter un Cheval de Troie. Ces moyens sont connus sous le nom de canaux cachés. La principe général d un canal caché consiste à transmettre des informations de façon codée sous forme de 0 et de 1 en frappant aux murs. Traditionnellement, on distingue deux types de canaux cachés : canaux cachés de stockage et canaux temporels. Un canal de stockage utilise une ressource non protégée du système (par exemple, en bloquant/débloquant l accès à un registre) pour transmettre des informations. Un canal temporel exploite une ressource temporelle (par exemple, en faisant varier l exécution d une application). Plusieurs modèles de contrôle de flux ont été proposés pour prendre en compte les canaux cachés [32, 35, 28]. Le plus connu est le modèle de non interférence [24, 25, 22]. Ce modèle permet de renforcer le modèle de Bell et LaPadula en empêchant les attaques des Chevaux de Troie contre la confidentialité, même via des canaux cachés de stockage. En revanche, le modèle de non-interférence ne contrôle pas les canaux cachés temporels. Le principe du modèle est le suivant. Soient A 1 et A 2 deux applications s exécutant respectivement aux niveaux L 1 et L 2. Si L 1 = L 2, alors A 1 et A 2 peuvent s échanger des informations. Si L 1 > L 2, alors le flux d informations de A 2 vers A 1 est autorisé. En revanche, tout flux de A 1 vers A 2 est interdit. Enfin si L 1 et L 2 ne sont pas comparables, aucun flux entre A 1 et A 2 n est autorisé. Plusieurs formalisations du principe de non interférence ont été proposées. On présente ici celle de Goguen et Meseguer [24]. Soit SI un système d information. Ce SI permet aux utilisateurs d exécuter des applications. Soit Seq(SI) l exécution d une certaine séquence d applications dans SI. Chaque application est exécutée avec un certain niveau de sécurité. Si L est un certain niveau de sécurité, on définit P urge(seq(si), L), l exécution obtenue en supprimant de Seq(SI) toutes les applications qui n ont pas été exécutées avec un niveau inférieur ou égal à L. Enfin, au cours de l exécution d une séquence d applications, un utilisateur s obtient certains résultats (outputs) fournis par le SI. Les résultats obtenus par s au cours de l exécution d une séquence Seq(SI) est notée Output(s, Seq(SI)). On dit alors que le système satisfait la propriété de non interférence si pour toute séquence Seq et pour tout utilisateur s, on a : Output(s, Seq(SI)) = Output(s, P urge(seq(si), L)) où L représente le niveau d habilitation du sujet s. Intuitivement, cette condition exprime que, pour un utilisateur ayant un niveau d habilitation L, tout se passe comme si seules des applications de niveau inférieur à L avaient été exécutées dans le système. La propriété de non-interférence est difficile à vérifier dans la pratique car elle concerne l exécution d une séquence d applications. Des conditions suffisantes, dite de unwinding plus simples ont été proposées [24, 25] pour vérifier qu une application particulière vérifie la condition de noninterférence. Plus récemment, les travaux de Smith et Volpano [40] basés sur la théorie des types 11

12 permettent de vérifier que le code source d un programme est non interférent. Ces travaux peuvent être appliqués à l analyse statique de codes mais les conditions à vérifier sont pessimistes : l exécution de certains programmes peut ne pas être interférente alors que ces programmes seront rejetés par l analyse statique. 3.3 Modèle de Bell et LaPadula étendu La principale limite de la non-interférence est que cette condition est très restrictive à mettre en œuvre 1. Dans la pratique, elle a été uniquement appliquée avec succès sur de petits systèmes, par exemple des logiciels embarqués à bord de carte à puce. Toutes les autres tentatives d appliquer la non interférence à des systèmes plus importants tels que des systèmes d exploitation ou des systèmes de gestion de bases de données n ont pas abouti à des solutions commercialisables car les solutions développées se sont avérées trop contraignantes à utiliser. Pour de tels systèmes, le besoin de modèles de sécurité plus flexibles est évident. Pourquoi? Parce que la non-interférence adopte le point de vue extrême que tous les programmes sont potentiellement malveillants et peuvent contenir un Cheval de Troie cherchant à transmettre illégalement des informations. Une telle hyptohèse n est pas réaliste dans la pratique. Plus précisément, elle rend impossible la spécification de certaines fonctionnalités nécessaires dans la plupart des systèmes, par exemple des fonctions de chiffrement ou de déclassification. En effet, ces fonctions ont pour objectif de produire en sortie des résultats qui auront un niveau de classification strictement inférieur au niveau de classification des données fournies en entrées de ces fonctions. Un modèle plus réaliste est le modèle de Bell et LaPadula étendu proposé dans [4]. Au lieu d associer un niveau courant à chaque application, ce modèle associe un intervalle de niveaux [L 1, L 2 ] avec L 1 L 2. Une application peut ainsi lire tout objet dont la classification est inférieure à L 2 et écrire dans tout objet de classification supérieure à L 1. Ceci permet la déclassification. Si l on soupçonne une application de pouvoir contenir un Cheval de Troie, alors il faut imposer que L 1 = L 2. L exécution de l application est alors contrôlée par les mêmes conditions de sécurité que le modèle de Bell et LaPadula strict. En revanche, si L 1 L 2, alors l application ne doit pas contenir de Cheval de Troie. On dit alors que l application est de confiance. Une fonction de déclassification peut ainsi être implantée par une application de confiance. Il faut empêcher qu une application qui contient un Cheval de Troie puisse appeler une application de confiance, par exemple une fonction de déclassification, pour transmettre illégalement des informations interdites. Pour cela, il faut imposer une condition pour contrôler l invocation d une application par une autre application : si A et A sont deux application associées respectivement aux intervalles [L 1, L 2 ] et [L 1, L 2], alors A peut invoquer A si et seulement si L 1 L 1 et L 2 L 2. Ainsi, une application qui n est pas de confiance (c est-à-dire telle que L 1 = L 2 ) ne peut jamais invoquer un application de confiance (c est-à-dire telle que L 1 L 2). Le modèle de Bell et LaPadula étendu est proche du modèle actuellement mis en œuvre dans OLS (Oracle Label Security)??, le module implantant une politique de sécurité multi-niveaux sous Oracle à partir de la version 8i. Ce modèle est beaucoup plus flexible à mettre en œuvre que les modèles de Bell et LaPadula strict et de Non Interférence. On peut cependant remarquer que le modèle de Bell et LaPadula étendu présente la limite suivante : il est impossible de modéliser une application réalisant certains transferts d informations entre deux niveaux L 1 et L 2 qui ne sont pas comparables. En effet, on ne peut pas considérer une application A travaillant sur [L 1, L 2 ] car [L 1, L 2 ] n est pas un intervalle si L 1 et L 2 ne sont pas comparables. 3.4 Modèle de Causalité L intérêt du modèle de Bell et LaPadula étendu est qu il est plus souple que Non Interférence. Mais il présente aussi un inconvénient car, comme le modèle de Bell et LaPadula strict, il ne permet pas 1 La même remarque est valable pour le modèle de Bell et LaPadula. 12

13 de contrôler les canaux cachés. Le modèle de causalité [10, 11] est un modèle de contrôle de flux basé sur l analyse des dépendances causales qui contrôle les canaux cachés (y compris temporels) et qui est plus souple à mettre en œuvre que Non Interférence. A chaque sujet s, on associe un ensemble d objets que s a le droit d observer noté Droit(s). On associe également à s un ensemble Obs(s) qui représente l ensemble des observations que s à réaliser sur le système. La propriété de causalité est satisfaite si Obs(s) dépend causalement de Droit(s) (voir [10] pour plus de détails). En fonction des objets qui sont inclus dans l ensemble Droit(s), il est possible de définir plusieurs politiques de contrôle de flux différentes : 1. Causalité sur les inputs [10]. Dans ce cas, on suppose que seules les données introduites par les utilisateurs sont de confiance. Toutes les données produites en exécutant des applications dans le système ne sont pas de confiance car elles peuvent avoir été calculées par un programme contenant un Cheval de Troie. On suppose donc que Droit(s) = {In(s ) niv(s ) niv(s)} c est-à-dire s a le droit d observer toutes les données introduites par les autres sujets s ayant un niveau d habilitation inférieur ou égal à s. Causalité sur les inputs est une propriété que l on peut comparer à Non Interférence. Causalité sur les inputs présente plusieurs avantages (voir [11]). En particulier, le modèle permet de considérer qu une même donnée est introduite par un sujet à plusieurs niveaux de sécurité différents. Cette possibilité permet de prendre en compte une opération de déclassification gérée à l extérieure du SI, chose impossible avec Non Interférence. 2. Causalité étendue. Il est possible d ajouter à Droit(s) des données produites par une application de confiance (par exemple, le résultat d une opération de déclassification). 3. Possibilité d exprimer des politiques d autorisation de type Muraille de Chine [14]. Dans ce type de politique d autorisation [13], il est possible d accéder séparément à certaines données mais ces données ne peuvent pas être agrégées à cause de conflits d intérêt entre les sources ayant émis ces données. Pour modéliser ce type de politique d autorisation avec Causalité, il faut considérer que l ensemble des droits d un sujet évolue au cours du temps. 4. Possibilité de contrôler l évolution dynamique des niveaux de classification d un objet ou le niveau courant associé à une application [12]. 3.5 Modèle de Biba La définition usuelle du contrôle d accès obligatoire spécifie que les restrictions sur le flux des informations se font indépendamment des actions de l utilisateur. Bien que cette définition fait souvent référence au modèle de Bell et LaPadula, plusieurs systèmes mettent en place ce type de contrôle pour garantir des propriétés d intégrité (banques, hopitaux, etc.). Le premier modèle traitant de la protection de l intégrité est celui de Biba?? appelé également Bell et LaPadula à l envers (Bell and LaPadula upside down). En effet, Biba a constaté que la confidentialité et l intégrité sont des concepts duals. La confidentialité est une contrainte sur qui est permis de lire la donnée alors que l intégrité est une contrainte sur qui a le droit de l écrire ou de la modifier. Ainsi, dans le modèle de Bell et LaPadula, l information ne peut pas circuler vers les niveaux inférieur pour éviter la fuite de données sensibles. Inversement, dans le modèle de Biba, les informations ne peuvent migrer vers des hauts niveaux d intégrite sinon les données piégées (virus, cheval de troie, etc.) en provenance de niveaux d intégrité faibles contamineraient les données saines de niveaux d intégrité supérieures. Formulées autrement, ces contraintes correspondraient à des propriétés duales à celles de Bell et LaPadula, No Write Up et No Read Down. Cependant, le modèle de Biba n empêche pas l action d un Cheval de Troie mais permet de confiner son effet à certains niveaux d intégrité. C est une conséquence du No Write Up : le Cheval de Troie ne 13

14 pourra pas attaquer les données ayant un niveau d intégrité supérieur au niveau où le Cheval de Troie a été installé. En ce sens, modèle proche de la Sand Box de Java. De plus, pas de possibilité pour l attaquant de piloter le Cheval de Troie à distance grâce au No Read Down. Bien entendu, La dualité avec le modèle de Bell et LaPadula fait que le modèle de Biba souffre également du problème soulevé par Maclean [?] et discuté dans la section BLPE concernant le principe de tranquilité. Pour éviter ce problème de statisme des labels, une solution adoptée dans les systèmes assurant des propriétés d intégrité sur la base du modèle de Biba est l utilisation d une politique de type Low Water Mark dans laquelle le label d intégrité d un objet est affecté au niveau le plus bas en lecture par le processus qui l a créé. C est la cas dans LOMAC [?], une version étendue de Linux, qui utilise cette approche pour gérer les problèmes des programmes pièges provenant du réseau public. Bien entendu, cette implantation ne peut stopper un virus infectant le niveau d intégrité faible de se multiplier et d envoyer ses clônes vers le réseau public. 3.6 Modèle Boebert&Kaine et DTE Boebert et Kain ont introduit une implantation du modèle de non-interférence, type enforcement (TE), mise en oeuvre dans le système Lock??, et qui a évoluée plus tard vers le modèle DTE. Ce modèle est basé sur un moniteur de référence composé d une unité de gestion de la mémoire (MMU) qui contrôle les privilèges conventionnels de lecture, écriture, etc. et un composant de gestion des objets labélisés (TOP) qui est en charge de la protection de l état du système. Le TOP initialise les tables de définition des privilèges que contrôle le MMU. Des attributs de sécurité sont associés aux sujets et aux objets et le TOP doit effectuer les comparaisons adéquates entre ces attributs de sécurité pour établir des droits d accès conformément à la politique de sécurité envisagée dans le MMU. Dans ce modèle, les attributs de sécurité associées aux sujets et aux objets sont de trois types : le label de confidentialité est associé aux sujets et aux objets, l identité de l utilisateur initiant la fonction, est associée aux sujet l exécutant. Le deuxième attribut de sécurité qui lui est équivalent pour les objets est une liste de contrôle d accès (ACL) associés aux objets. elle est constituée des identités des utilisateurs possédant des permissions d accès aux contenus des objets ainsi que le nombre maximum d accès autorisés pour chaque couple (utilisateur, pivilège), le domaine d exécution du sujet est associé au sujet et correspond à l encodage du soussystème dont il fait partie. Pour les objets, le troisième attribut de sécurité est le type de l objet et il correspond au format de l information contenue dans l objet en question. La détermination des droits d accès à attribuer à un sujet donné pour avoir accès à un objet donné se base sur les trois attributs de sécurité cités ci-avant. Ainsi, pour la mise en oeuvre de la politique d accès obligatoire, le TOP effectue une comparaison entre les niveaux de sécurité des sujets et des objets. Ensuite, il calcule un ensemble initial de droits d accès conformément à l algorithme défini dans la section 3. Pour la mise en oeuvre de la politique d accès discrétionnaire, le TOP vérifie par la suite la liste de contrôle d accès (ACL) des objets. Lorsqu une entrée dans l ACL correspond à la partie utilisateur du contexte de sécurité du sujet, elle est comparée avec les droits d accès définis dans l ensemble initial qui traduit la politique d accès obligatoire. Tout droit d accès dans cet ensemble initial qui n apparaît pas dans l ACL est supprimé. On obtient donc un nouvel ensemble de droits d accès. Enfin, la troisième étape de détermination des droits d accès se base sur une comparaison du domaine du sujet et du type de l objet auquel il veut avoir accès. Chaque sujet est considéré comme également un objet et donc, son second attribut de sécurité est une liste de types d objets accessibles par le domaine du sujet et le nombre d accès maximal permis à chacun de ces types. En fait, l agrégation de ces listes de définition de domaines constitue la table DDT (Domain Definition Table). Ainsi, le TOP, pour effectuer le contrôle domaine-type, il consulte les lignes de la DDT 14

15 pour retrouver le domaine du sujet concerné par cette vérification, puis repère le type de l objet dont il est question et ensuite compare le résultat de cette entrée identifiée avec l ensemble de droits d accès intermédiaire calculé auparavant. Tout droit apparaissant dans cet ensemble et qui n est pas défini dans la DDT est supprimé. Le résultat est l ensemble final des droits d accès qui est transmis au MMU. Cependant, il y a lieu de tenir compte également des changements au niveau des domaines qui peuvent se produire suite à un effet de bord d un appel de procédures. Si la procédure en question ne peut être exécutée dans le domaine de l appelant, soit l appel est illégal ou alors un chagement de domaine est nécessaire pour le satisfaire. Ce type d information sur les possibilités de changer de domaine sont enregistrés dans une autre table DTT (Domaine Transition Table). Lorsqu un appel nécessite un changement de domaine, le moniteur de référence suspend le sujet appelant et active le sujet appelé avec son contexte de sécurité le temps de Ainsi, le modèle TE, traite le problème de l intégrité en s orientant plutôt vers l isolation de l action plutôt que de l utilisateur. En d autres termes, les domaines sont utilisés pour astreindre les actions à s exécuter uniquement dans une seule enclave et d une seule façon ; si l accès n est pas autorisé à ce domaine, l action ne peut être exécutée. Cette approche permet de prévenir des accès non autorisés à travers des chemins non conventionnels. On peut reconnaître derrière cette approche, une structure très utilisée dans la conception de systèmes sécurisés réels : les pipelines. Un aspect non traité bien qu important dans des modèles de politique de sécurité à niveaux hiérarchisés, comme Bell et LaPadula (aspect maquillé sous la dénomination de applications de confiance ) et dans ceux plus orientés intégrité comme le modèle de Biba. Le modèle TE traduit les états possibles de non-interférence par la définition de la DDT et les transitions d états par la DTT. L intégrité est alors assurée par un contrôle strict de ces tables, ce qui semble être un objectif raisonnablement accessible bien que le stockage et la gestion d un grand nombre de tables peut être complexe. Ce modèle offre également une grande flexibilité. Pour pouvoir effectuer certaines actions préalablement définies selon un critère de tâche, d équipe, de groupe ou encore de rôle, l utilisateur doit avoir accès au bon domaine. D autres restrictions d accès à des programmes ou les fichiers accessibles dans ce domaine à cet utilisateur peuvent être adjointes sinon le système deviendrait assez rapidement difficile à gérer. Avant de refermer cette section, il est important de signaler que DTE n est qu une extension du modèle TE. Les principales différences sont : les matrices d expression de la politique de sécurité ont disparu au profit d un langage de politique de sécurité intuitif, l utilisation d une hiérarchie de labels de sécurité à la Bell et LaPadula ou Biba n est pas exigée et des possibilités de transitions entre domaines de façon automatique est rendue possible. Ce modèle a été mise en oeuvre dans le système d exploitation SELinux??, mais avec l apport d autres mécanismes basés sur les modèles RBAC et IBAC. Dans SELinux, des exigences d implantation ont nécessité l abandon du concept de domaine au profit de type pour faciliter l expression de la politique d accès et permettre des intéractions entre objets. 4 Administration L administration consiste en la création et la maintenance des éléments constituant la politique de sécurité tels que les utilisateurs, les actions, les objets, les rôles, les labels de sécurité, les droits, etc. La spécification de la politique de sécurité et sa mise à jour sont les deux tâches les plus importantes d administration. Elle est différente selon le modèle de sécurité adopté (contrôle d accès, contrôle de flux, etc.) pour définir la politique à mettre en oeuvre. Elle peut être centralisée ou distribuée selon la flexibilité du modèle. Les modèles d administration ne sont pas nombreux (voir figure??) et s explique par l intérêt faible qui leur a été porté. La complexité des tâches attribuer aux administrateur de sécurité et la multiplication des brèches de sécurité résultant d une mauvaise gestion plutôt que d un mauvais modèle de sécurité font que les travaux récents [?] en matière de contrôle d accès, de flux et d usage prêtent une attention particulière à la définition des modèles d administration de la sécurité. 15

16 4.1 Modèle DAC L administration du modèle Id-BAC est souvent de type discrétionnaire. Elle repose sur la notion de propriétaire : chaque objet a un propriétaire qui décide quels sont les sujets qui ont accès à cet objet. Il est souvent le créateur de l objet et dispose de tous les droits sur cet objet. Ce plein contrôle dont le propriétaire dispose sur ses ressources, lui donne aussi la possibilité de déléguer à un autre sujet le droit d accorder des droits sur certaines d entre-elles. Le plus célèbre modèle discrétionnaire est le modèle HRU qui a été défini en 1976 par Harrison, Ruzzo et Ullman []. C est un modèle matriciel défini à partir d un ensemble de sujets, d un ensemble d objets et d un ensemble fini de règles. Ces règles décrivent dans quelles conditions on peut modifier le contenu de la matrice d accès. Les primitives de ces règles sont les suivantes: donner un droit r à un sujet s sur un objet o créer un sujet s créer un objet o enlever un droit r à un sujet s sur un objet o détruire un sujet s détruire un objet o (possible si ce n est pas un sujet) La matrice d accès est conçue telle que les colonnes correspondent aux droits exercés sur un objet tandis que les lignes correspondent aux droits que possèdent un sujet. La mise en œuvre de ce modèle est coûteuse en mémoire lorsque le nombre des utilisateurs est important. La constitution de groupes d utilisateur peut être envisagée afin de limiter la taille de la matrice. Cependant la constitution et la maintenance de ces groupes sont délicates, car un sujet peut appartenir à plusieurs groupes. Le modèle HRU a néanmoins l avantage d être simple à décrire et permet une modélisation simple de plusieurs systèmes de protection. Il offre la possibilité de vérifier qu il n y a pas d ajout aléatoire de droits dans la matrice d accès. On peut ainsi analyser les problèmes de sûreté et de sécurité. En général, les modèles DAC sont assez statiques car une fois que la matrice d accès est en place, sa modification peut être complexe si elle est grande. Ils ont néanmoins l avantage d avoir une politique décentralisée. 4.2 Modèle TAM Le modèle HRU a été conçu pour étudier le problème de sûreté. Le problème de sûreté consiste à savoir si on peut créer ou non un droit qui n existait pas auparavant suite à une exécution d une séquence de commandes. Un système de contrôle d accès est dit sûr si on ne peut pas créer un nouveau droit dans ces conditions. Il se trouve que dans le modèle HRU tel qui a été défini, le problème de sûreté est indécidable. Il existe cependant des cas particuliers du modèle HRU pour lesquels on peut décider de la sûreté du système. Plusieurs chercheurs ont proposé des modèles pour résoudre ce problème de sûreté: Jones, Lipton, Snyder, Denning en proposant le modèle Take-Grant en 79 [?], Ravi S. Sandhu dans les années 80 avec SPM (schematic protection model)[?] puis dans les années 90 avec le modèle TAM [?]. Les primitives utilisées dans le modèle TAM sont identiques à celles de HRU mais les sujets et les objets sont typés. Ces types et les droits ne sont pas prédéfinis dans le modèle, ce qui permet une politique de sécurité plus flexible. L une des premières modifications du modèle TAM afin d obtenir un problème décidable est que le système est monotone, c est à dire qu il ne possède pas de requête de destruction ou de suppression. Pour obtenir un système monotone on se limite donc à trois primitives (celles pour donner un droit, créer un objet ou un sujet). On obtient alors le modèle 16

17 MTAM (Monotonic TAM). Dans ce modèle modifié de TAM on arrive à obtenir la décidabilité mais le problème est encore NP-SPACE complet. Ravi S. Sandhu arrive à rendre le problème décidable en temps polynomiale en ajoutant une nouvelle contrainte, celle d avoir un arrangement acyclique [?] de MTAM. Cette propriété permet d éliminer des boucles liées aux héritages. Pour cela, on regarde quels sont les objets ou sujets dit de type enfant. Si l une des composantes d une commande α est de créer un sujet (ou un objet) X i de type t i alors on dit que ce sujet (ou cet objet) est de type enfant dans α. Les sujets et objets qui ne sont pas du type enfant sont du type parent. Ensuite, on crée un graphe orienté avec une flèche reliantles sujets (ou objets) de type parent aux sujets (ou objets) qui leurs sont associés de type enfant ; si ce graphe est acyclique alors on a un arrangement acyclique de MTAM et on remplit alors les conditions pour une décidabinilté du problème de sûreté du système en temps polynomial. ATAM [?], est une autre extension de TAM. ATAM a l avantage d apporter de bons résultats au niveau des propriétés de sécurité, et de garder un grand pouvoir d expression. Ainsi, le modèle ATAM ajoute des contraintes de respect d invariants de sécurité pour toute exécution d une quelconque séquence de commandes. Ce qui a permi la réintroduction des opérations de destruction ou de suppression. Ainsi, avec MTAM et ATAM ont obtient des modèles qui restent expressifs et dont les propriétés de sûreté sont décidables avec une complexité raisonnable. Cependant, malgré les progrès considérables qui ont été effectués, les applications pratiques de ces modèles sont quasi-inexistantes. 4.3 Modèle ARBAC ARBAC (Administrative Role-based Access Control) [] gère les politiques de contrôle d accès centrés sur les rôles. Il a subi trois évolutions ARBAC97, ARBAC99 et ARBAC02. ARBAC97 [] est le premier modèle d administration de RBAC au moyen de rôles et de conditions prérequises. Il permet de gérer une politique RBAC de façon décentralisé sans fuite de droits mais bien que les rôles et les permissions administratives soient basés sur une approche RBAC, ils sont définis de façon entièrement différentes des rôles et permissions usuels. Il utilise trois composantes URA (Uer Role Assignment)pour l affectation des utilisateur aux rôles, PRA (Role Permission Assignment)pour l affectation des permisions au rôle et RRA (Role Role Assignment) pour la création des hiérarchies de rôles. Dans ce modèle, la gestion de la hiérarchie de rôles at l attribution des permissions se fait par une autorité centrale. En revanche, la gestion des utilisateur et l attribution ou révocation des permissions à ces utilisateurs peut être laissée à des responsables d unités en leur affectant des rôles administratifs. On note cependant que ARBAC n est pas un modèle autoadministré. Il crée de nouvelles règles d affectations (can assign) et de révocation (can revoke) pour les besoins d administration. D autre part, les relations d attribution des permissions aux rôles ou d attribution des rôles aux utilisateurs sont des relations ternaires. Ainsi, les conditions prérequises dépendent du rôle administratif et du rôle ordinaire. Mais, il semble que ces conditions prérequises ne dépendent généralement que des rôle usuels et devraient plutôt être considérées comme de simples contraintes sur ces rôles usuels. ARBAC ne traite pas le problème de création des rôles et il n offre aucun mecanisme de délégation. Les aspects contextuels ne sont pas traités. Ainsi, il n est pas possible d exprimer qu un rôle administratif a la permission d attribuer des permissions à un rôle donné uniquement pendant les heures de bureau ou uniquement dans le cas où il utilise son propre ordinateur personnel. ARBAC99 s est intéressé aux aspects mobilité et ARBAC02, a proposé des solutions pour améliorer ARBAC97 mais aucune de ces deux extensions ne résoud les faiblesses précisées ci-avant. 4.4 Modèle AdOr-BAC AdOr-BAC est un modèle d administration pour le modèle Or-BAC. L expression de la politique d administration dans ce modèle se fait en logique classique de la même façon que la spécification de la politique de sécurité dans Or-BAC. Ainsi, Or-BAC est un modèle auto-administré. 17

18 Ce modèle fournit un bon compromis entre l administration complètement centralisée et rigide telle que celle adoptée pour les modèles de type MAC et celle complètement décentralisée et difficile à contrôlée comme c est le cas dans la gestion des modèles de type DAC. En effet, AdOr-BAC est un modèle qui offre la possibilité d avoir plusieurs niveaux d administration, contrairement aux autres modèles qui dans la majorité des cas sont des modèles à deux niveaux. Un niveau pour le contrôle d accès et un niveau d administration, Ainsi, lors de la création d une politique Or-BAC, il est possible d attribuer la tâche initiale de création de la politique à un seul utilisateur possédant le rôle de concepteur de politique de sécurité. Cet utilisateur particulier a la permission de définir des rôles d administration des organisation et spécifier les permissions à associer à ces rôles. De cette façon, il est possible d avoir une gestion décentralisée de la politique de sécurité. Les rôles administratifs créés peuvent avoir leur autorité restreinte de façon à éviter la fuite des droits. AdOrBAC comporte trois composantes principales URA, PRA. L affectation d un sujet à un rôle se fait par l insertion d un objet dans la vue URA. De la même façon, l affectation d une permission à un rôle se fait en insérant un objet dans la vue PRA. PRA correspond ici à une sorte de guichet qui attribue un ticket à un rôle pour une activité donnée, dans une vue donnée et un contexte donné. L administrateur peut donner à un médecin le droit de consulter le dossier d un patient pendant les heures de la journée; une règle qui autorise les sujets ayant le rôle médecin à réaliser l activité consulter le dossier du patient dans la vue UPA entre huit heures et vingt heures est ainsi créée. L UPA sert à affecter des privilèges à des utilisateurs, ce qui en fait une composante intéressante pour la gestion des aspects de délégation. 4.5 Administration dans les modèles de type MAC L administration de ce type de modèle consiste à définir les droits de gérer les labels de sécurité des sujets et des objets. Pour les modèle MAC plus flexibles où l évolution des attributs de sécurité est permise, il s agit également de définir qui a le droit d exécuter les opérations de déclassification des objets. Une autorité unique et centralisée détermine le critère d attribution des habilitations aux sujets et les classifications aux objets ; les sujets sont complètement écartés de l administration des droits. Pour attribuer ces labels, cette autorité d administration doit se baser sur les propriétés de flux d information du modèle MAC telles que définies dans la section label Contrôle de flux. Par conséquent, il lui est nécessaire d analyser la sensibilité des objets, les liens entre ces objets en particulier lorsqu ils sont de sensibilité différente, veiller au maintien des classifications une fois attribuées et enfin certifier les sujets auxquels elle doit affecter un label de sécurité hautement sensible. Il s en suit donc une complexité et une rigidité dans la gestion lorqu il s agit de les appliquer dans des systèmes réels en particulier dans le cas des applications réseau. Mis à part pour certains systèmes d exploitation (voir sections 3.1 et 3.3, il existe très peu de mis-en-œuvre du modèle MAC et donc de son administration. Récemment, Jon A. Solworth et Robert H. Sloan ont créé une nouvelle classe de contrôle administratif pour ce type de modèles à labels [?] Security Property Based Administrative Controls. Ils affirment que leur modèle peut éliminer les problèmes de sécurité et conserver les propriétés d intégrité et confidentialité dans la gestion administrative. Cependant, ils ne donnent que les grandes lignes pour créer cette classe et les preuves présentées comportent des points quelque peu flou. Leur modèle est constitué d utilisateurs, d objets, de labels de sécurité, de permissions et de groupes. Ils lient les groupes à leurs droits par des fonctions. Par exemple, r(l) désigne le groupe qui peut lire les objets de label l. Ils définisent les types d actions possibles : les actions ordinaires (créer,lire, écrire un objet; ajouter un nouveau membre au groupe,...), les actions administratives qui ne violent aucune propriété de sécurité (créer de nouveaux groupes, créer de nouveaux labels, etc.) et les actions administratives qui peuvent affecter directement ou indirectement les propriétés de sécurité. Ils introduisent une relation binaire mayflow(l, l ) : le groupe peut écrire l après avoir lu l, et une relation didf low, plus prioritaire que mayf low, qui modifie la hiérarchie dans le groupe. La 18

19 relation mayflow permet de créer un treillis des groupes liés à un label l et ainsi de les hiérarchiser alors que la relation didf low rétablit les propriétés de sécurité suite à des actions administratives. Dans le modèle SPBAC, la conservation des propriétés de confidentialité et d intégrité est basée sur la détermination des effets des actions administratives sur les actions ordinaires (non-administratives) et en éliminant les autorisations qui violent les propriétés de sécurité (SecurityP ropertyapprovals). Toutefois, ce modèle d administration de modèle de type MAC nécessite un contrôle accru des flots d information. Il peut donc s avérer très coûteux en temps et en ressource. De plus, les définitions liées aux trois types d actions sur lesquelles se reposent les relations mayf low et didf low sont assez confuses. 5 Synthèse et perspectives 5.1 Synthèse du contrôle d accès Le premier modèle de contrôle d accès de type DAC est encore largement utilisé dans la plupart des SI. Ce modèle repose sur une politique d autorisation de type I-BAC permettant de spécifier les actions que des sujets peuvent réaliser sur des objets sous forme d une matrice de contrôle d accès. L administration de ce modèle est dite discrétionnaire. Le modèle R-BAC est apparu au milieu des années 90 et connait un succès croissant. Ce modèle, simple à utiiser, introduit le concept organisationnel de rôle pour structurer l expression de la politique d autorisation. Ce modèle constitue un standard et est aujourd hui mis en œuvre dans de nombreux systèmes d exploitation ou de gestion de bases de données. Le modèle R-BAC dispose également d un modèle d administration, ARBAC, mais qui n est encore que rarement implanté dans toute sa généralité, la plupart des réalisations ne proposant que des rôles d administration prédéfinis. Plus récemment, le modèle Or-BAC propose une expression complètement structurée d une politique d autorisation organisationnelle. Ce modèle inclut la possibilité d exprimer des autorisations dépendant de conditions contextuelles ainsi que des autorisations négatives (interdictions). Le modèle d administration AdOr-BAC a également été défini et permet une administration distribuée d une politique d autorisation Or-BAC. Dans ce modèle, un administrateur peut exprimer une politique d autorisation de façon complètement indépendante de l implantation qui sera ensuite faite de cette politique. Ce principe fait de Or-BAC un bon candidat pour utiliser ce modèle comme point central d expression, de gestion et d administration de la politique d autorisation d un SI. Les travaux en cours sur ce modèle [18] ont pour objectif d ensuite définir une démarche pour décomposer la politique de manière à configurer les différents composants de sécurité intervenant dans l architecture d un SI, tels que, par exemple, pare-feu, VPN, système de détection d intrusions, système d exploitation ou systèmes de gestion de bases de données. 5.2 Synthèse du contrôle de flux Les premiers modèles de type MAC, tels que Bell et LaPadula ou non interférence, avaient comme objectif d imposer un cloisonnement strict entre les applications. Dans la pratique, la mise en œuvre de ces modèles dans des SI ont abouti à des solutions trop rigides pour être utilisables. Ces premiers modèles de type MAC avaient comme objectif de mettre en œuvre une politique d autorisation multi-niveaux. La conséquence est que l on a tendance à identifier les modèles de type MAC à ce type de politique d autorisation. Cette vision est erronée. Tant que l on ne considère pas les problèmes des Chevaux de Troie, une politique multi-niveaux peut être vue comme une politique d autorisation comme les autres : les utilisateurs reçoivent un niveau d habilitation, les objets un niveau de classification et un utilisateur ne peut lire un objet que si le niveau d habilitation du sujet est supérieur ou égal au niveau de classification de l objet. En sens inverse, on peut appliquer un modèle de type MAC à n importe quelle politique d autorisation. Nous avons illustré cette possibilité dans le cas d une politique d autorisation de type I-BAC (voir 19

20 section 3.1). De façon similaire, il est possible de contrôler les flux entre rôles dans une politique de type R-BAC. Dans tous les cas, les contrôles de type MAC doivent être appliquées de façon appropriée, c est-àdire pour empêcher un Cheval de Troie de réaliser une attaque contre la confidentialité ou l intégrité. Ces contrôles ne doivent pas être appliqués aux utilisateurs ni aux applications dites de confiance sous peine de rendre le modèle inutilement restrictif. Les modèles de Bell et LaPadula étendu ou de DTE l ont bien compris en proposant des solutions plus souples à mettre en œuvre que Bell et LaPadula strict ou Non Interférence. Ces modèles ont d ailleurs été respectivement implantés dans la version multi-niveaux de Oracle (OLS) et dans SELinux. Cependant, des travaux sont encore nécessaires pour obtenir le même niveau de formalisation que Non Interférence. Des recherches sont en cours sur le modèle de causalité pour définir un tel modèle. 5.3 Vers le contrôle d usage Les modèles de contrôle d accès classiques permettent de spécifier si un sujet à l autorisation de réaliser une action sur un objet du SI. Eventuellement, une condition contextelle peut être associée à l autorisation ; cette condition doit être satisfaite avant que l action puisse être réalisée. Avec le développement des applications de gestion de droits électroniques (DRM, Digital Right Management), il faut être capable de spécifier des conditions qui doivent être satisfaites non seulement avant mais aussi pendant ou après qu une action soit réalisée. Par exemple, un serveur permettant d écouter des morceaux de musique doit pouvoir spécifier que le paiement doit s effectuer avant, pendant ou bien après l écoute du morceau. Pour exprimer ce type de politique d autorisation, les modèles de contrôle d accès ne sont plus suffisants. C est la raison pour laquelle des modèles de contrôle d usage commencent à être proposés. Le modèle ABC (Authorization, Obligation and Condition) [33] a été spécialement conçu pour exprimer des politiques de sécurité incluant des contraintes de contrôle d usage. L expression d une contrainte à satisfaire avant l utilisation d un objet peut s exprimer sous forme d une autorisation contextuelle. En revanche, les contraintes à satisfaire pendant ou après l utilisation d un objet correspondent à des obligations que l utilisateur doit respecter. Le modèle NOMAD [17] repose sur une formalisation en logique temporelle et déontique pour exprimer des obligations contextuelles à respecter avant, pendant ou après l exécution d une action. On peut également spécifier un délai au bout duquel une certaine obligation sera considérée violée si l action n a pas été réalisée. La mise en œuvre de ce modèle dans un environnement de DRM est en cours d étude. Pour conclure ce chapitre, remarquons que le besoin de contrôle d usage ne se limite pas aux applications de DRM. Par exemple, le nouveau concept de SGBD hippocratique, à savoir de SGBD donnant l assurance du respect d un serment de confidentialité, a été introduit dans [1]. Un tel SGBD se doit de respecter un ensemble de principes fondateurs parmi lesquels : préciser l objectif d utilisation de chaque donnée collectée sur un utilisateur, recueillir le consentement de l utilisateur vis à vis de cet objectif, ne stocker que l information strictement nécessaire à l atteinte de cet objectif et uniquement pendant le laps de temps strictement nécessaire, ne pas divulguer cette information à des tiers sans autorisation préalable de l utilisateur, assurer l exactitude et la sécurité des données collectées, donner à l utilisateur la possibilité de consulter les informations qui le concernent et enfin offrir des outils permettant à un tiers de contrôler que tous ces principes sont bien respectés. Le standard P3P (Platform for Privacy Preferences) promu par le W3C est également un moyen donné aux utilisateurs pour mieux contrôler l usage des informations que les sites Web accumulent sur eux. 20