Le contrôle d'accès permet de spécifier une partie de la politique de sécurité d'un SI (système d'informations). Une politique de CA (Contrôle d'accès) permet de définir qui a accès à quoi et sous quelles conditions. Les concepts fondamentaux utilisés en CA sont : les permissions, les interdictions (ou prohibitions), les obligations et la SoD (séparation des devoirs). Les permissions permettent d'autoriser une personne à accéder à des ressources. Au contraire les prohibitions interdisent à une personne d'accéder à certaines ressources. Les obligations lient plusieurs actions. Elles permettent d'exprimer le fait qu'une action doit être réalisée en réponse à une première action. La SoD permet de sécuriser une procédure en confiant la réalisation des actions composant cette procédure à des agents différents. Différentes méthodes de modélisation de politiques de contrôle d'accès existent. L'originalité de la méthode EB3Sec issue de nos travaux repose sur deux points :- permettre d'exprimer tous les types de contraintes utilisées en CA dans un même modèle,- proposer une approche de modélisation basée sur les événements. En effet, aucune des méthodes actuelles ne présente ces deux caractéristiques, au contraire de la méthode EB3Sec. Nous avons défini un ensemble de patrons, chacun des patrons correspond à un type de contraintes de CA. Un modèle réalisé à l'aide de la méthode EB3Sec peut avoir différentes utilisations :- vérification et simulation,- implémentation. La vérification consiste à s'assurer que le modèle satisfait bien certaines propriétés, dont nous avons défini différents types. Principalement, les blocages doivent être détectés. Ils correspondent à des situations où une action n'est plus exécutable ou à des situations où plus aucune action n'est exécutable. Les méthodes actuelles des techniques de preuves par vérification de modèles ne permettent pas de vérifier les règles dynamiques de CA. Elles sont alors combinées à des méthodes de simulation. Une fois qu'un modèle a été vérifié, il peut être utilisé pour implémenter un filtre ou noyau de sécurité. Deux manières différentes ont été proposées pour réaliser cette implémentation : transformer le modèle EB3Sec vers un autre langage, tel XACML, possédant une implémentation ayant déjà atteint la maturité ou réaliser un noyau de sécurité utilisant le langage EB3Sec comme langage d'entrée / Access control allows one to specify a part of the security Policy of an IS (information system). An AC (access control) policy defines which conditions must old for someone to have access to something. Main concepts used in AC are: permissions, prohibitions, obligations and SoD (separation of duty). Permissions allow someone to access to some resources. On the opposite, prohibitions forbid users to have access to some resources. Obligations link at least two actions: when a user performs an action, he must perform another one. SoD secures an action by dividing it in different tasks, and entrusting the execution of these tasks to different users. Many AC policies modelling methods already exist. The main particularities of the EB3Sec methods are:- All AC concepts can be expressed in a unique model,- This modelling method is event-based. No existing AC modelling methods presents these two characteristics. We define a set of patterns; each pattern corresponds to a specific AC constraint. An EB3Sec model can be used for different purposes:- Simulation and verification,- Implementation.Verifying a model consists in checking that the model complies with some properties that we have defined. Mainly, blocking must be detected. Blocking corresponds to a step of execution where no action can be executed or to situations where an action cannot be performed anymore. Current model checking methods cannot be used to check properties on dynamic AC constraints. Thus, model-checking techniques are combined to simulation techniques. Once a model is verified, it can be transformed in an implementation. To implement an EB3Sec model two ways can be considered: the EB3Sec model can be translated into an other language, such as XACML, which possesses a mature implementation, or a security kernel using EB3Sec as input language can be implemented
| Identifer | oai:union.ndltd.org:theses.fr/2012PEST1089 |
| Date | 04 May 2012 |
| Creators | Konopacki, Pierre |
| Contributors | Paris Est, Université de Sherbrooke, Laleau, Régine |
| Source Sets | Dépôt national des thèses électroniques françaises |
| Language | French |
| Detected Language | French |
| Type | Electronic Thesis or Dissertation, Text |
Page generated in 0.0018 seconds