Gestion de droits d’accès dans des réseauxinformatiques

Mémoire

MEMEL EMMANUEL LATHE

Maîtrise en informatiqueMaître ès sciences (M.Sc.)

Québec, Canada

© MEMEL EMMANUEL LATHE, 2016

Résumé

La sécurité informatique est plus que jamais une préoccupation majeure de toute entrepriseprivée comme publique. Le contrôle d’accès, qui représente une composante importante de lasécurité des systèmes d’information, consiste à vérifier si un sujet possède les droits nécessairespour accéder à un objet [43]. Il est régi par des règles qui peuvent être exprimées en différentslangages. La validation de contrôle d’accès, également appelée analyse de conformité, consisteà vérifier, à intervalles réguliers, si ces règles de contrôle d’accès mises en œuvre sont cohérenteset complètes par rapport à une politique de sécurité donnée. Plusieurs outils de contrôle d’accèssont applicables à cette fin. AVTAC (Automatic Validation Tool of Access Control) est un outilsur lequel nous avons apporté notre contribution.

iii

Abstract

Computer security is more than ever a major concern for any private or public company.Access control which is an important component of security of information systems consistson verifying whether a subject has the rights to access to an object. It is governed by rules thatcan be expressed in different languages. Validation of access control also called compliance isto check at regular intervals if the access control implemented rules are consistent and completewith respect to a given security policy or not. Several access control tools are applicable tothis end. AVTAC (Automatic Validation Tool of Access Control) is the tool on which we madeour contribution.

v

Table des matières

Résumé iii

Abstract v

Table des matières vi

Liste des tableaux ix

Liste des figures xi

Remerciements xiii

Introduction 1

1 État de l’art des outils de contrôle d’accès 31.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Authentification pour un système IAM . . . . . . . . . . . . . . . . . . . . . 41.3 Modèle d’habilitation pour un système IAM . . . . . . . . . . . . . . . . . . 81.4 Implémentation et contrôle pour un système IAM . . . . . . . . . . . . . . . 111.5 Outils de gestion des droits d’accès . . . . . . . . . . . . . . . . . . . . . . . 141.6 Normes et référentiels de sécurité . . . . . . . . . . . . . . . . . . . . . . . . 181.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2 Représentation des droits d’accès sous Windows et Linux 272.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2 Contrôle d’accès : définitions et politiques . . . . . . . . . . . . . . . . . . . 282.3 Contrôle d’accès sous Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.4 Contrôle d’accès sous Windows . . . . . . . . . . . . . . . . . . . . . . . . . 422.5 Représentation graphique du contrôle d’accès . . . . . . . . . . . . . . . . . 462.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3 Contribution 513.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.2 Architecture et vue d’ensemble . . . . . . . . . . . . . . . . . . . . . . . . . 513.3 Outils d’approvisionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.4 Processus de validation de droit d’accès . . . . . . . . . . . . . . . . . . . . 573.5 Traduction des droits d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . 593.6 Récupération automatique des droits d’accès à partir de différentes machines 633.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

vi

Conclusion générale 67

A Scripts et documents XACML 69A.1 Script d’extraction des droits d’accès Windows . . . . . . . . . . . . . . . . 69A.2 Traduction des droits d’accès Linux vers XACML . . . . . . . . . . . . . . . 75A.3 Grammaire BNF pour un sous-ensemble de XACML 3.0 . . . . . . . . . . . 77A.4 Script d’extraction des droits d’accès Linux via SNMP . . . . . . . . . . . . 79

vii

Liste des tableaux

2.1 Types d’entrées ACL [36]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.2 Masquage des autorisations d’accès. . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1 SDDL Syntax [43]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.2 Traduction de SDDL vers XACML [43]. . . . . . . . . . . . . . . . . . . . . . . 61

ix

Liste des figures

1.1 Processus de synchronisation [60]. . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2 midPoint[31]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.3 Architecture OpenIDM [31]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.4 ITIL version 3 [65]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.1 Concepts de base pour le contrôle d’accès dans Linux . . . . . . . . . . . . . . . 302.2 Droit d’accès Linux : Exemple. . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.3 ACL minimale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.4 ACL étendue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.5 ACE de type accès accordé [13]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.6 ACE de type accès refusé [13]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.7 Structure d’un descripteur de sécurité [13]. . . . . . . . . . . . . . . . . . . . . . 452.8 Language SDDL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452.9 Architecture Linux [53]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472.10 GMC gestion des droits d’accès [21]. . . . . . . . . . . . . . . . . . . . . . . . . 482.11 Console de gestion Microsoft. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492.12 Utilisateurs et groupes locaux. . . . . . . . . . . . . . . . . . . . . . . . . . . . 492.13 Gestionnaire de sécurité Windows. . . . . . . . . . . . . . . . . . . . . . . . . . 492.14 Fenêtre d’édition des ACE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.1 Architecture du cadriciel AVTAC [43]. . . . . . . . . . . . . . . . . . . . . . . . 523.2 Architecture de l’outil de validation [54] . . . . . . . . . . . . . . . . . . . . . . 543.3 Capture 1 d’écran de l’outil de validation. . . . . . . . . . . . . . . . . . . . . . 633.4 Capture 2 d’écran de l’outil de validation. . . . . . . . . . . . . . . . . . . . . . 643.5 Structure d’une MIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

xi

Remerciements

À mon DieuQue toute la gloire te revienne pour cette étape, je te dis merci pour ton choix et ta fidélitésur ma vie.

À mon épouse et mes enfantsVous qui m’avez toujours soutenu, merci de me faire confiance et d’être pour moi une sourcede motivation.

À mon père spirituelMerci prophète de Dieu pour la source de bénédiction que tu es pour moi, l’Université Lavalest aujourd’hui une réalité grâce à toi.

À mes parentsReconnaissance et amour familial, plus particulièrement à mon père qui a accepté de financermes études, merci de croire en moi papa.

À mon directeur de recherche, Dr Mohamed MejriJe tiens à vous dire merci pour votre motivation et votre patience dans l’élaboration de ceprojet de maîtrise. Je vous suis très reconnaissant d’avoir accepté de superviser ce travail.

À mes collèguesMerci pour votre soutien, particulièrement à Etienne Sadio qui a été pour moi un appui ines-timable.

À mes frères et sœursJe dis merci à tous ceux qui m’ont soutenu durant mes études, plus particulièrement à la familleGandonou, la famille Angora, la famille Yao et la famille Lasme. Que Dieu vous bénisse !

xiii

Introduction

Motivation

La sécurité informatique est plus que jamais une préoccupation majeure de toute organisation.Le contrôle d’accès, qui représente une composante importante de la sécurité des systèmesd’information, consiste à vérifier si un sujet demandant l’accès à un objet possède les droitsnécessaires pour le faire. Il est régi par des règles qui peuvent être exprimées dans un langagetel que XACML [1].

Pour mieux protéger nos données et les équipements de nos systèmes informatiques, nos insti-tutions définissent des politiques de sécurité et utilisent différentes techniques et outils pour lesimplémenter. L’attribution et le contrôle de droits d’accès est souvent la principale technique.Cependant, la conformité entre ce qui est demandé par la politique de sécurité et ce qui estréellement implanté dans le système n’est pas toujours respectée. Par ailleurs, la complexité decette tâche d’analyse de conformité augmente considérablement quand nos systèmes (incluantles équipements et les données qu’on protège, les personnes qui donnent les droits d’accèset les personnes à qui l’on donne les droits d’accès) ou nos politiques de sécurité changentconstamment.Par exemple, il arrive assez souvent que des personnes qui ont complètement quitté une organi-sation bénéficient, par erreur, de leurs anciens accès. Il arrive souvent aussi que des personnesqui ont changé de poste ou de grade bénéficient, toujours par erreur, de leurs anciens accès.Pire encore, des données sensibles peuvent se trouver mal protégées.

Pour rendre l’analyse de conformité faisable et à coût raisonnable, il faut automatiser ceprocessus. En d’autres termes, il faut développer des outils qui sont capables d’aller chercherrégulièrement et automatiquement les droits d’accès attribués aux différents utilisateurs pourles différentes ressources et de les comparer avec la politique de sécurité actuelle.

C’est dans cet axe de recherche que se situe ce travail. En effet, nous proposons le développe-ment des outils permettant de récupérer automatiquement des droits d’accès et des techniquespermettant de les analyser.

1

Buts

L’objectif de ce travail de recherche est d’une part de faire une synthèse de l’état de l’art desdifférents outils et techniques permettant la gestion des droits d’accès dans les réseaux infor-matiques et d’autre part de développer des outils permettant de récupérer automatiquementune partie de ces droits d’accès et de les analyser.

Organisation

Ce mémoire est structuré comme suit : le chapitre 1 est consacré à l’état de l’art des ou-tils de gestion de contrôle d’accès . Ensuite, le chapitre 2 décrit la représentation des droitsd’accès sous Windows et Linux . Dans le chapitre 3, nous présentons notre contribution dansl’élaboration de l’outil AVTAC. Finalement au chapitre 4, nous terminons par une conclusiongénérale.

2

Chapitre 1

État de l’art des outils de contrôled’accès

1.1 Introduction

L’IAM (Identity and Access Management) a évolué en devenant un élément capital du sys-tème informatique dans les grandes et moyennes entreprises. Ses atouts en termes de créationet de mise en œuvre de politiques de contrôle d’accès sont avérés ; cependant cette solutioninformatique a été auparavant considérée comme très difficile à mettre en œuvre. Aussi, la né-cessité métier d’une bonne interaction entre les systèmes d’information et les différentes entitésorganisationnelles (acteurs externes) devient de plus en plus primordiale. Qu’il s’agisse d’uti-lisateurs internes ou externes à l’entreprise, ces identités peuvent exposer celle-ci à de grandesmenaces, si elles ne sont pas gérées et maintenues par des systèmes fiables et performants.

La gouvernance d’un système IAM, qui est très souvent intégrée à la gestion de la politique desécurité de l’organisation, spécifie les attendus pour les quatre thèmes principaux de la gestiond’identités et d’accès :

— l’Authentification de l’accès utilisateur ;

— l’Habilitation aux ressources du système d’information ;

— L’Implémentation de processus ;

— Le Contrôle des procédures de gestion et de validation.

Ce chapitre sera un bon repère dans la connaissance de l’IAM, car il nous permettra denous acclimater avec les notions et la modélisation utilisées dans un processus de gestion desidentités et des droits d’accès. Il a aussi pour objectif de nous orienter à faire de bon choixafin de réaliser parfaitement un projet IAM.

3

1.2 Authentification pour un système IAM

L’objectif de l’authentification est d’assurer la légitimité d’un accès à une ressource. Cettejustification est faite par un moyen d’authentification qui se base sur des composants dedifférents types :

— "Ce que je sais".Il s’agit d’une information confidentielle qu’un utilisateur indique pour prouver son iden-tité : un mot de passe, un NIP 1, etc.

— "Ce dont je dispose".Il s’agit d’un équipement de sécurité tenu par l’utilisateur qui donne lieu à un authen-tifiant permettant de prouver son identité : certificat numérique, token, badge d’accès,etc.

— "Ce que je suis".Il s’agit d’une marque propre à l’utilisateur : la signature, l’empreinte digitale, l’iris del’œil, etc.

Plusieurs services peuvent être mis en place pour faciliter l’authentification, mais celui quiattirera notre attention et qui est le service d’authentification le plus mis en œuvre pour unprojet IAM est : l’authentification unique ou SSO 2.

1.2.1 Authentification unique (SSO)

De nos jours, les entreprises ont à assurer la gestion d’un ensemble délicat d’applications ré-seau et d’applications Web qui fonctionnent sur des systèmes hétérogènes. Les utilisateurs sontdans l’obligation d’accéder à plusieurs applications pour l’envoi de leurs courriels, la gestiondu support informatique, la gestion des fichiers de tout type.À cause des exigences toujours plus rigoureuses en matière de sécurité, les utilisateurs doivententrer leur paramètre de connexion (identifiant / mot de passe) propre à chacune de ces ap-plications, ce qui peut avoir comme conséquence, et ce de façon courante, l’utilisation de n(nombre d’applications) combinaisons différentes.

Dans le contexte de la gouvernance des systèmes et de l’application des mesures de sécuritéd’informations (paramètres de stratégie de mot de passe), des dispositions ont été prises afind’assurer la sécurité du réseau, par exemple par l’utilisation de mots de passe forts, la duréede vie maximale du mot de passe, durée de vie minimale du mot de passe et conservationd’historique de mot de passe. Avec tout cela, des problèmes liés à la réinitialisation des mots

1. NIP : Numéro d’identification Personnel.2. SSO : Single Sign On.

4

de passe (coup de fil important de la part des utilisateurs pour réinitialiser leur mot de passe)et à "l’inconfortabilité" des utilisateurs (trop de mot de passe à gérer) se sont accentués.

C’est dans ce cadre qu’ont été élaborées les solutions d’authentification unique pour les entre-prises. Cette façon de s’authentifier permet aux utilisateurs de se loguer une seule fois, sachantque les processus de connexion aux applications dans la suite, sont gérés automatiquement.Ainsi, la solution de SSO logue automatiquement les utilisateurs à diverses applications sur labase des paramètres de connexion authentifiés.

Avantages de l’authentification unique

Les fonctions de l’authentification unique offrent plusieurs avantages aux entreprises parmilesquels :

• Une évolution dans le confort et dans le rendement des utilisateurs.Les employés disposent d’un accès simplifié et prompt à toutes les applications requises,ce qui augmente leur rendement.

• La restriction des risques au niveau de la sécurité.Les employés n’ont plus besoin d’écrire leurs accès secrets sur une feuille qui est suscep-tible d’être facilement interceptée vu qu’ils les laissent souvent sur le bureau.

• Une sécurité optimale du réseau d’entreprise.L’authentification unique empêche les utilisateurs non autorisés d’avoir accès au réseaude l’entreprise. En effet elle donne lieu à une bonne gestion des droits accès, seuls lesutilisateurs autorisés peuvent accéder aux applications pour lesquelles ils ont un accès.

• Le centre d’assistance technique est moins sollicité en ce qui concerne lesdemandes de réinitialisation.Les employés risquent moins d’omettre leurs accès secrets, car ils n’en ont qu’un seul àretenir, ce qui logiquement aide à réduire le nombre d’interventions du centre d’assistancetechnique à ce sujet.

• Une optimisation du niveau de serviceAttendu que le centre d’assistance technique est moins sollicité pour ce qui concerne lagestion de réinitialisation, ses collaborateurs peuvent donc se focaliser sur le soutien desusagers qui ont des problèmes plus critiques et ainsi développer leur niveau de service.

• Compatibilité aux exigences de conformité (PCI, HIPAA, SOx, etc.)Les fonctionnalités de l’authentification unique offrent plusieurs options de compatibi-lité :

— La gestion des authentifications prend en compte l’authentification forte (concaté-nation d’au moins deux facteurs d’authentification) sans entraver au confort desemployés.

5

— En une seule demande, l’authentification unique permet, et ce en une seul fois,l’interdiction de l’accès des employés à l’ensemble du réseau, à défaut de devoirreproduire cette action pour chacune des applications.

— L’authentification unique permet de produire un rapport sur le temps exact (dateet heure) auquel les comptes des utilisateurs ont reçu une autorisation d’accès.

— L’authentification unique donne lieu également à plusieurs vérifications supplémen-taires avant la connexion effective des employés, par exemple, il est possible dedoter les applications sensibles de l’entreprise d’une couche additionnelle de sécu-rité afin de vérifier que l’employé qui tente d’accéder au système y est bien autorisé.L’utilisation d’un badge ou d’un NIP est requise.

Inconvénients de l’authentification unique

Nonobstant les avantages que proposent les fonctions SSO, il est de même notable de signalerquelques inconvénients :

— Au niveau de la compatibilité, l’authentification unique a bien souvent des limites avecplusieurs applications (clients lourds) . Pour pallier ce problème, il faut implémenter,pour les applications non supportées, une interface qui permet au SSO d’authentifier defaçon automatique l’utilisateur.

— L’authentification unique peut aussi attenter à la sécurité, en effet elle permet d’accéderà plusieurs ressources une fois l’utilisateur logué. Pour pallier ce problème, il faut associerles solutions de l’authentification unique à d’autres facteurs d’authentification commeles certificats ou carte à puce.

— Le concept même de l’authentification unique peut également être considéré commeétant un risque, en effet si le module (serveur SSO) qui gère l’authentification a unproblème (indisponibilité, dysfonctionnement, etc.) celui-ci empêche alors tout le systèmed’information de fonctionner. Pour pallier ce problème, le recours a des serveurs secourspeut être envisagé.

Les composants du SSO

Un système d’authentification unique est composé d’au moins trois « segments », ces segmentsspécifient des fonctionnalités qui donnent lieu à la mise en place de l’authentification. Ces troissegments sont :

• Le serveur SSO : c’est le composant central de l’authentification unique, il gère :

— l’authentification des employés.

— le bon fonctionnement des sessions.

6

— la propagation d’identité 3 entre les applications.

• Les applications : Les applications sont utilisées par les utilisateurs finaux, elles doiventêtre compatibles avec le système d’authentification unique, c’est à dire être capabled’échanger avec l’agent d’authentification.

• L’agent d’authentification :L’agent d’authentification est la jonction entre les applications et le serveur SSO. Safonction est de vérifier que l’employé est authentifié. En cas d’échec de ce processus devérification, l’utilisateur est redirigé vers le serveur SSO.

Architectures de SSO

On dénombre plusieurs types d’architecture pour l’authentification unique, en plus des tech-niques utilisées. L’architecture d’un système d’authentification unique est révélatrice, ce choixdoit être fonction d’une bonne vue d’ensemble du système d’information visé. En effet ce choixest très conditionné par les normes de confiance établies entre plusieurs entités à fédérer ausein du système d’authentification unique. Les architectures se subdivisent en deux modèlesque voici :

• Le modèle centraliséLa règle fondamentale ici est d’avoir soit un système de stockage de données (BD 4) detous les utilisateurs ou un annuaire. Cela donne lieu aussi à la centralisation de la gestionde la politique de sécurité et des droits d’accès. On compte parmi les logiciels qui illustrece procédé, LemonLDAP.

Ce modèle est particulièrement désigné à des services qui appartiennent tous à unemême entité. Par exemple au sein d’une entreprise, la gestion des intergiciels est fondéesur le modèle centralisé. En effet chaque entité (service) interdépendante a confiancedans l’authentification approuvée par le centre d’authentification (serveur SSO).

On peut citer le compte Apple pour illustrer ce modèle. En effet il permet d’accéder à unemultitude de modules tels qu’ App store (Plateforme de téléchargement d’application),iTunes store (service de vente en ligne de musique, films, séries, etc.), iCloud (service denuage), etc., avec un seul compte et une seule authentification.

• Le modèle fédératifDans ce modèle, le système Liberty Alliance 5 est le principal exemplaire, chaque entité

3. L’objectif de la propagation d’identités est double : déléguer l’authentification à l’établissement d’originede l’utilisateur et obtenir certains attributs de l’utilisateur (pour gérer le contrôle d’accès ou personnaliser lescontenus).[61]

4. BD = Base de données.5. Liberty Alliance, aussi connu sous le nom de Project Liberty, est un projet qui réunit des acteurs des

mondes industriel, informatique, bancaire et gouvernemental sous la forme d’un consortium. L’objectif est dedéfinir des ensembles de spécifications de protocoles de fédération d’identité et de communication entre services

7

administre une partie des données d’un utilisateur A en partageant les informations dontil dispose sur l’utilisateur A avec les entités partenaires.

Cette approche a été mise en œuvre pour faire face à la nécessité d’une gestion décen-tralisée des utilisateurs, où chacune des entités partenaires souhaite garder le contrôlede leur propre politique de sécurité.

À titre d’exemple, considérons un partenariat commercial qui met en œuvre deux sitesweb. L’utilisateur a un même compte pour les deux sites, mais il doit pour chacun spé-cifier quelques informations importantes, telles que son adresse de livraison. Mais parcontre, des informations telles que son login et son courriel sont partagées dans le butde cibler les goûts de l’utilisateur.

1.3 Modèle d’habilitation pour un système IAM

Il existe plusieurs modèles de contrôle d’accès bien documentés dans la littérature de la sécuritéinformatique et de nombreux articles en décrivent un grand nombre d’extensions. On distinguedeux catégories de modèle d’habilitation principal que sont :

— les modèles classiques (Modèles discrétionnaires ou DAC 6 et Modèles mandataires ouMAC 7)

— Les Modèles à rôles (RBAC)

Dans un système IAM et dans la majorité des entreprises, le principal modèle d’habilitationutilisé est RBAC 8. Ce modèle repose sur la définition de rôles (ou profils) qui établissent le lienen matière d’habilitation entre les utilisateurs et les ressources du SI. Nous nous intéresseronsdonc dans cette section du modèle RBAC et de ses dérivées.

1.3.1 Modèle RBAC

RBAC est présenté dans [28]. Dans ce modèle, la notion de rôle est le concept fondamental, lesdroits d’accès sont attribués à un rôle et si ce rôle est joint à un utilisateur ou à des groupesd’utilisateurs, alors ceux-ci obtiennent implicitement les droits d’accès à travers le rôle.Un rôle définit un ensemble de droits d’accès et est attribué à un ou plusieurs utilisateurs.Ainsi dans la gestion de RBAC, deux types de relations sont à considérer :- La relation entre les rôles et les utilisateurs.- La relation entre les rôles et les permissions.

web. Ces protocoles sont conçus pour être mis en œuvre aussi bien dans le cadre de déploiements intra-entreprisequ’inter-entreprise.[62]

6. Discretionary Access Control.7. Mandatory Access Control.8. Role-Based Access Control.

8

1.3.2 Extensions du modèle RBAC

Le modèle RBAC connaît quelques limites dès lors que l’employé a des fonctions différentesqui dépendent du lieu géographique où il exerce (Ex. : un conseiller qui travaille dans plusieursagences avec des fonctions différentes).Des modèles d’habilitations proches du modèle RBAC existent pour pallier ce genre de spéci-ficité :

— ORBAC 9 permet en plus des autorisations, de spécifier des interdictions et des obliga-tions tout en s’appuyant sur des notions de contexte.

— Risk-RBAC qui introduit la notion de risque et de délégation.

Modèle ORBAC

Le modèle OrBAC (Organization-based Access Control) [56] est une évolution de RBAC.Le concept principal de ce modèle est d’exprimer la politique de sécurité avec des notionsabstraites, et aussi de pouvoir distinguer la représentation d’une politique de sécurité de sonimplémentation en utilisant différents processus de contrôle d’accès. OrBAC définit la notiond’ « organisation » et spécifie les sujets, les objets et les actions respectivement en rôle (commedans RBAC). OrBAC utilise aussi la notion de vue (View-based Access Control "VBAC" [57]),et aussi la notion d’activités (Task-based Authorization Controls "TBAC" [58]). Un rôle estattribué à un groupe d’utilisateurs, aussi une activité est attribuée à une ou plusieurs actions,et une vue est attribuée à un ou plusieurs objets. OrBAC introduit également la notion ausside contexte et la définit comme étant une situation particulière qui détermine si une règle estvalide ou pas.

Dans OrBAC, la définition des autorisations se fait comme suit :

— Autorisation accordée ou Permission.

— Autorisation refusée ou Interdiction.

— Des règles d’obligations de la formePermission|Prohibition|Obligation(org; r; v; a; c), où org est une organisation, r unrôle, v une vue, a une activité et c un contexte.

On identifie deux paliers dans OrBAC : un palier abstrait dans lequel l’administrateur décritla politique de sécurité en utilisant des règles sur les notions abstraites (rôles, activités, vues),et un palier concret où des utilisateurs exécutent des actions sur des objets dépendammentdes règles spécifiées dans la politique. Pour illustrer formellement l’instanciation des règles desécurité, considérons l’expression suivante :∀org ∈ Org, ∀s ∈ S,∀α ∈ A, ∀o ∈ O,∀r ∈ R,∀a ∈ A,∀v ∈ V,∀c ∈ C,Permission(Org, r, v, a, c) ∧ Empower(org, s, r) ∧ Consider(org, α, a)∧Use(org, o, v) ∧Hold(org, s, α, o, c)

9. Organization based Acces Control.

9

→ Ispermitted(s, α, o)

L’interprétation donnée à cette expression est la suivante :si « dans l’organisation ‘org’, le rôle ‘r’ est autorisé à faire l’activité ‘a’ sur la vue ‘v’ quand lecontexte ‘c’ est vrai », et si « dans l’organisation ‘org’, le rôle ‘r’ est attribué au sujet ‘s’ », et si« dans l’organisation ‘org’, l’action ‘’ est incluse dans l’activité ‘a’», et si « dans l’organisation‘org’, l’objet ‘o’ est inclus dans ‘v’ » et si « le contexte ‘c’ est vrai pour le quadruplet (org, s,, o) », alors le sujet ‘s’ peut exécuter l’action ‘’ sur l’objet ‘o’.

Modèle Risk-RBAC

Il est capital d’introduire une relation d’ordre dépendamment de la valeur des objets et ausside définir des actions délimiter afin de sécuriser ces objets.

Le présent modèle d’accès de contrôle dans cette sous-section introduit la notion de risque etde délégation, il s’agit du Risk-RBAC [59], qui est une évolution du modèle RBAC.Le modèle RBACR est défini comme RBAC en y ajoutant une fonction de sécurité RF(fonction d’analyse de risque) et un ensemble de niveaux de confiance C.On affecte un niveau de confiance C à un utilisateur u ∈ U et on note CNF (u) : U → C etpour tous les rôles on calcule le niveau minimum de confiance noté MLC(R) : R→ C.La valeur du risque attribué à un utilisateur u qui a un rôle R, noté rv(u,R), est comprisentre 0 et 1.Ce calcul s’effectue de la façon suivante :

rv(u,R) =

0, si CNF (u) ≥MLC(R)

1− CNF (u)MLC(R) , sinon

Comme spécifié plus haut, il est question également dans cet article de notion de délégationet du risque correspondant à cette délégation.Il est noté del_rv(u1, u2) et traduit le risque produit sur les objets de u1 si u1 délègue sonrôle à u2.Ce calcul s’effectue de la façon suivante :

del_rv(u,R) =

0, si CNF (u1) ≥ CNF (u2)

1− CNF (u1)CNF (u2)

, sinon

.

10

1.4 Implémentation et contrôle pour un système IAM

La bonne gestion des processus d’entrée, sortie et mobilité des employés dans l’entrepriseest importante afin de garantir la validité des identités, des habilitations et des accès. Unesurcharge d’habilitation, l’utilisation de comptes utilisateurs désuets, la non-résiliation desdroits dans les systèmes de gestion d’accès sont une partie des risques traités par la gestiondu cycle de vie des identités. La mise en œuvre des processus métiers, et leur automatisationassure à l’entreprise un bon contrôle des identités et une meilleure gestion des accès au seinde l’entreprise. Pour ce faire nous allons définir les différents processus et techniques utiliséspar un système IAM afin de garantir une bonne gestion des identités, des habilitations et desaccès au sein de l’organisation.

1.4.1 Approvisionnement

Dans l’intention d’automatiser les tâches d’administration du SI et de repérer les incohésionset les écarts avec le modèle d’habilitations, la gestion des identités et des droits d’accès doitse baser sur des processus d’approvisionnement automatique.

Alimenter chaque référentiel de façon manuelle et indépendamment est source d’erreurs, etrend complexe la mise en place d’une politique de sécurité. Ce procédé représente égalementune perte de temps et de productivité pour une entreprise.

L’approvisionnement automatique, lorsque bien utilisé, garantira une bonne mise en œuvredes politiques d’habilitation sur le SI.

Selon [42], l’objectif de l’approvisionnement dans un système IAM est d’interagir avec lesressources externes en se connectant aux serveurs d’annuaire, aux systèmes d’application mé-tiers (RH, Administration...), et d’autres types de systèmes. Il récupère les informations desressources et les modifie également si nécessaire.Les responsabilités qui incombent au système d’approvisionnement sont en résumé :

— La gestion des objets sur les ressources (système cible / source). Les objets désignenttoutes les entités liées à la gestion de l’identité, en particulier les comptes, les groupes, lesrôles, les droits, les attributs de compte, etc. et on entend par gestion, l’exécution d’opé-rations telles que la récupération, création, modification et la suppression des objets.(CRUD)

— Fournir la possibilité de rechercher des objets de ressources.

— Détecter des changements sur la ressource (système cible / source)

— Masquer si nécessaire les informations obtenues à partir des ressources.

11

1.4.2 Réconciliation et synchronisation

L’un des grands challenges qui déterminent la gestion des identités et le contrôle des accèsconsiste dans l’interaction de plusieurs applications. Pour relever ce défi dans le monde desIAM, deux techniques sont souvent utilisés et demeurent incontournables de nos jours. Cesont : la réconciliation et la synchronisation.

Réconciliation

La réconciliation est le processus de synchronisation bidirectionnelle des objets entre différentsbase de données et référentiels (LDAP, BD relationnelle) [33]. Elle s’applique principalementaux objets utilisateurs, aux groupes et aux rôles. Pour effectuer la réconciliation, un outilIAM analyse à la fois les systèmes sources et cibles afin de découvrir les différences qu’il fautconcilier. La réconciliation ne peut donc être considérée comme un processus lourd et sert éga-lement de base pour l’analyse de conformité et peut être aussi utilisée dans les fonctionnalitésde rapports (reporting) .

Synchronisation

Pour expliquer le processus de synchronisation, nous allons utiliser la figure 1.1 comme illus-tration.

Figure 1.1 – Processus de synchronisation [60].

12

Des connecteurs placés sur des référentiels fournissent des événements ou des données aumoteur de synchronisation. Le moteur de synchronisation interprète les événements en entrée,éventuellement les modifie, puis achemine aux référentiels cibles les événements ou données àintégrer. Ce fonctionnement de répartition de données est automatisé et régi par des règlesstatiques.

1.4.3 Attribution de privilège d’accès

La méthode d’attribution des identités numériques constitue un aspect important de la gestiondes identités et des accès. Le processus d’octroi de privilèges d’accès fournit un outil puissantqui se sert des informations utilisateur existantes dans l’infrastructure d’annuaire de l’organi-sation, afin d’accroître le processus d’attribution et de révocation des comptes utilisateur auxressources d’informations. Au nombre des ressources, on peut citer :La messagerie électronique, le téléphone, les applications TI, les applications métiers et fonc-tionnelles, etc.

Les avantages liés à l’automatisation des processus sont nombreux, on peut citer entre autres :Une diminution des coûts et un accroissement de la productivité de façon radicale.

1.4.4 Workflow de validation

Bon nombre d’outils IAM de nos jours intègrent des moteurs de workflow 10 à leur architecture.L’implémentation de cette solution consiste à mettre en œuvre une application de workflowsimple, en général par une interface Web qui permet d’effectuer des étapes manuelles à l’in-térieur du processus d’attribution de privilèges d’accès automatique. Par exemple, considé-rons que l’embauche d’un employé exige l’approbation du gestionnaire, mais dans lequel legestionnaire peut seulement approuver ses nouveaux employés. Lorsque le personnel des res-sources humaines crée un compte employé, il saisit les informations relatives au gestionnaireafin d’envoyer une notification par courrier électronique au gestionnaire approprié. Lorsquele gestionnaire se connecte au site Web, il peut parcourir la liste des nouveaux employés àapprouver.

10. Le moteur de workflow est l’outil permettant de modéliser et d’automatiser les processus métiers del’entreprise.

13

1.5 Outils de gestion des droits d’accès

Il existe diverses applications pour la gestion des droits d’accès dans le monde IAM. Bonnombre d’entre elles sont assignées à un environnement spécifique, et n’ont pas toujours lesmêmes niveaux de tâche dépendamment de la fonction majeure que ces outils sont appelés àexercer. Ci-dessous, nous citons quelques outils de contrôle d’accès.

1.5.1 CA IdentityMinder

CA IdentityMinder [30] est un outil de gestion d’identité et de droit d’accès mise en œuvre parla compagnie CA Technologies. Il fournit la capacité de gérer et de gouverner les identités desutilisateurs et comme tout bon outil de gestion de droits d’accès répond à la question "Quia accès à quoi ?". D’une façon aisée et productive, CA IdentityMinder permet également degérer et de gouverner les outils nécessaires afin de prendre le contrôle des utilisateurs privilégiésdans les plateformes physiques, virtuels et de cloud computing. Élaborer pour être pratique àexploiter et productive, la gestion de CA IdentityMinder peut concourir à accroître l’efficacité,la sécurité et la conformité dans toute l’organisation. La compagnie CA a augmenté au fil dutemps son offre de gestion IAM, en rachetant la compagnie ID Focus en octobre 2008 etEurikify quelque temps après.

1.5.2 SetACL Studio

SetACL Studio est un outil de gestion pour des autorisations Windows. Cet outil administreles droits d’accès des utilisateurs et donne lieu à la mise en œuvre d’audits. Il possède uneinterface utilisateur très intuitive pour une bonne gestion des autorisations, sans oublier safonctionnalité qui se met en œuvre aussi bien sur le réseau qu’en local. Il est possible d’utiliserdes scripts afin de construire certaines automatisations dans l’élaboration et l’administrationde droits d’accès.

1.5.3 midPoint

midPoint [31] est un système d’approvisionnement d’identités . Le provisionning d’identitésest un sous champ de l’identité et de gestion des accès (IAM). Un logiciel de provisionnigprend en charge les tâches techniques (IT) qui se produisent quand un nouvel employé se jointà une entreprise, lorsque ses responsabilités changent, quand il quitte l’entreprise, quand unnouvel entrepreneur est inscrit et ainsi de suite. Ceci est appelé cycle de vie d’une identité :l’ensemble des événements et des tâches qui font en sorte que chaque «identité» a ce qu’il faut.midPoint est un outil complet qui permet de synchroniser plusieurs référentiels d’identités etdes bases de données, les gère et les rend disponibles sous une forme unifiée. Il appartientà la catégorie Identity Provisioning du champ Enterprise Identity Management, cependantmidPoint lui-même ne se limite pas à l’entreprise. Il peut tout aussi bien fonctionner pour les

14

services de cloud computing, les portails Internet, les opérateurs télécom et les fournisseurs deservices et ainsi de suite.

Figure 1.2 – midPoint[31].

1.5.4 IBM Security Identity and Access Assurance

Le logiciel IBM Security Identity and Access Assurance présente une solution pour la gouver-nance d’un système IAM. La solution IBM est composée de cinq progiciels dont :- IBM Security Identity Manager qui est une solution qui aide au niveau de la gestion d’iden-tité, elle donne lieu à la gestion de comptes utilisateur, de rôles, etc. dans tout le systèmeinformatique.- IBM Security Access Manager for Enterprise Single Sign-On quant à elle utilise les fonctionsSSO couplées avec d’autres facteurs d’authentification dans le but de renforcer l’accès utilisa-teurs à différentes applications.- IBM Security Access Manager for Web définit une plateforme pour la gestion d’autorisationdes applications web. Il aide également à déployer plusieurs applications sécurisées .- IBM Tivoli Federated Identity Manager utilise le modèle fédératif (vu dans la sous-section1.2.1) dans le but de partager les données de façon sécuritaire entre plusieurs organisations.- IBM Security QRadar Log Manager permet de faire la gestion et l’analyse de journaux (fi-chier log), ces dits fichiers pourront être utilisés afin de réduire le risque de menace de sécurité.Il est à noter que IBM a racheté Access360 en 2002 et Encentuate en mars 2008, ces rachatson permis à IBM de développer sa suite IAM en intégrant l’Entreprise Single Sign On (eSSO).

15

1.5.5 LinID

LinID est la seule suite logicielle de gestion d’identité "Open Source", qui permet de gagneren efficacité et en sécurité dans la gestion des données d’identité, d’accès et d’habilitation.Cette suite est développée par l’entreprise Linagora, une entreprise française qui oeuvre dansle monde de l’open source. LinID est principalement utilisé dans l’environnement Windowsoù est déployé un domaine active directory.

1.5.6 OpenIDM

OpenIDM, édité par ForgeRock, est un système de gestion d’identité open source écrit enJava. OpenIDM exploite JavaScript comme langage de script par défaut pour définir les règlesd’affaires pendant l’approvisionnement. Il est basé sur un outil d’approvisionnement nomméOpenICF qui est un framework que l’on peut utiliser avec java et .NET. OpenIDM permet auxorganisations d’automatiser la gestion du cycle de vie de l’identité de l’utilisateur en tempsréel, y compris la gestion des comptes utilisateurs et des droits d’accès dans les applications.Léger et agile, OpenIDM a été conçu pour aider les organisations à assurer la conformité avecles politiques et les exigences réglementaires à travers l’entreprise, cloud, les environnementssociaux et mobiles.

Figure 1.3 – Architecture OpenIDM [31].

16

1.5.7 Quest One Identity

Membre de la suite de Quest Software de l’entreprise DELL, Quest One Identity assure lecontrôle des accès et l’administration des identités et améliore, en plus, la vérification deconformité en consolidant l’automatisation et la génération de rapports.Quest One vous permet de trouver rapidement et facilement les comptes et les utilisateurs quipossèdent des droits d’accès inadaptés. Quest One Identity permet d’effectuer une découverteapprofondie des environnements Active Directory et accéder à la gouvernance de toute l’en-treprise.Il fonctionne sous Windows et est optimisé pour une architecture basée sur Active directoryde Windows.

1.5.8 Varonis Datadvantage

Varonis donne lieu à la gestion de permissions de fichier Windows, toutefois sa spécificité sesitue au niveau des alertes. En effet, Varonis permet de recevoir des alertes en temps réel surtoute modification faite aux fichiers ou aux dossiers contenus dans les systèmes de fichiersWindows et périphériques NAS 11. Les administrateurs sont prévenus de tous changementsapportés aux fichiers de configuration importants, les accès aux données sensibles, les événe-ments de refus d’accès et plus encore. Ils reçoivent ces alertes par courrier électronique, SNMP,journal des événements, syslog ou directement dans le système de gestion des informations etévénements de sécurité.

1.5.9 Étude comparative

Plusieurs outils IAM existent sur le marché du contrôle d’accès, ils ont plusieurs fonctionscommunes cependant, chacun d’eux se démarque par une spécificité propre à chaque outil. Cetableau est une illustration de certains critères que nous avons établis pour les outils cités plushaut.

11. NAS : Network Attached Storage.

17

Contrôled’accès

SSO Gestiondes motsde passe

SNMP Audits Script Gestiond’alertes

OpenIDM • • • • •CAIdentity-Minder

• • • •

SetACLstudio

• • • • • •

midPoint • • • • •IBMSecurityIdentityandAccessAssu-rance

• • • • •

VaronisDatad-vantage

• • • • • •

QuestOneIdentity

• • • • •

LinID • • • • •

Tous les outils IAM mentionnés ci-dessus ont en commun des politiques de sécurité statique.En outre, les procédés de validation de droits d’accès ainsi que l’audit sont mis en œuvrepar les gestionnaires de sécurité qui, alerté par un processus de sécurité (alerte, scan, plainteutilisateur), s’appuie en général sur les résultats des fichiers logs. Vu cette façon de gérerl’environnement de sécurité, il est indispensable de mettre en oeuvre des outils "Ontologiques",ayant une base formelle qui aideront à établir une analyse des droits d’accès afin de vérifier lerespect ou non d’une politique de sécurité donnée, et ce de façon automatique.

1.6 Normes et référentiels de sécurité

De nos jours, la gestion et la sécurité d’un Système d’Information sont difficiles à mettreen œuvre sans l’utilisation de normes et de référentiels de sécurité. En effet, ces référentielsgarantissent une bonne cohérence des processus ainsi que de bonnes pratiques au sein del’organisation. Plusieurs référentiels et normes existent, mais nous allons nous contenter d’en

18

présenter quelques-uns.

1.6.1 Norme ISO 27002

La norme ISO/CEI 27002 est une norme internationale concernant la sécurité de l’informa-tion, publiée en 2005 par l’ISO, dont le titre en français est "Code de bonnes pratiques pourle contrôle de la sécurité de l’information" . Elle fait partie de la suite ISO/CEI 27000.[66]

ISO 27002 définit un ensemble de bonnes pratiques de la sécurité de l’information adaptée auxentreprises. Cette norme propose plusieurs mesures de sécurité sur le plan organisationnel ettechnique.

En 2005, deux normes sont éditées :la norme ISO/CEI 17799, qui modifie les domaines et objectifs, et la norme ISO/CEI 27001qui introduit la notion de Système de Management de la Sécurité de l’Information (SMSI). Lanorme ISO 17799 se voit remplacer en 2007 par la norme ISO 27002, qui a été mise à jour en2013, cette mise à jour spécifie 18 chapitres, 35 objectifs de sécurité et 113 mesures de sécurité.On peut dès lors, définir un objectif comme étant le projet à réaliser par l’implémentation deprocédures de contrôle à l’intérieur d’une pratique TI et une mesure de sécurité quant à elle,l’ensemble de pratiques qui garantit que les objectifs seront accomplis [67].Voici le contenu (chapitres) de la norme ISO 27002 :

— Chapitre 1 : Champ d’application.

— Chapitre 2 : Termes et définitions.

— Chapitre 3 : Structure de la présente norme.

— Chapitre 4 : Évaluation des risques et de traitement.

— Chapitre 5 : Politiques de sécurité de l’information.

— Chapitre 6 : Organisation de la sécurité de l’information.

— Chapitre 7 : Sécurité des ressources humaines.

— Chapitre 8 : Gestion des actifs.

— Chapitre 9 : Contrôle d’accès.

— Chapitre 10 : Cryptographie.

— Chapitre 11 : Sécurité physique et environnementale.

— Chapitre 12 : Sécurité liée à l’exploitation.

— Chapitre 13 : Sécurité des communications.

— Chapitre 14 : Acquisition, développement et maintenance des systèmes d’information.

— Chapitre 15 : Relations avec les fournisseurs.

— Chapitre 16 : Gestion des incidents liés à la sécurité de l’informatique.

19

— Chapitre 17 : Aspects de la sécurité de l’information dans la gestion de la continuitéd’activité.

— Chapitre 18 : Conformité.

Nous allons maintenant voir selon [67], les chapitres qui sont en rapport avec l’analyse deconformité :

— Politiques de sécurité de l’information (chapitre 5)

— Contrôle d’accès (Chapitre 9)

— Conformité (chapitre 18)

Politiques de sécurité de l’information

L’objectif concernant ce chapitre est d’apporter à la sécurité de l’information une orientationet un soutien de la part de la direction, conformément aux exigences métier et aux lois etrèglements en vigueur. Pour ce faire une mesure et des préconisations de mise en œuvresont définies dans cette norme pour chaque chapitre.La mesure dans ce chapitre, recommande de définir un ensemble de politiques en matière desécurité de l’information qui soit approuvé par la direction diffusé et communiqué aux salariéset aux tiers concernés.La mise en œuvre préconisée des politiques de sécurité de l’information, traitent des exigencescréées par la stratégie d’entreprise sans oublier les réglementations, la législation et les contrats.Cette politique de sécurité comporte des précisions concernant :

— Une définition de la sécurité de l’information, ses objectifs et ses principes pour orientertoutes les activités relatives à la sécurité de l’information ;

— Des processus de traitement des dérogations et des exceptions.

Contrôle d’accès

L’un des objectifs concernant ce chapitre est de limiter l’accès à l’information et aux moyensde traitement de l’information.La mesure dans ce chapitre, recommande d’établir, de documenter et de revoir une politiquedu contrôle d’accès sur la base des exigences métier et de sécurité de l’information.La mise en œuvre préconise que les propriétaires des actifs déterminent des règles de contrôled’accès, des droits d’accès et des restrictions d’accès appropriés aux fonctions spécifiques del’utilisateur des actifs, avec la quantité de détails et la rigueur des mesures correspondant auxrisques associés en matière de sécurité de l’information.Selon la norme, il convient que la politique du contrôle d’accès tienne compte des exigencesde sécurité suivantes :

— exigences en matière de sécurité des applications métier ;

20

— cohérence entre la politique des droits d’accès et la politique de classification de l’infor-mation des différents systèmes et réseaux ;

— gestion des droits d’accès dans un environnement décentralisé mis en réseau qui reconnaîttous les types de connexions disponibles ;

— cloisonnement des rôles pour le contrôle d’accès, par exemple la demande d’accès, l’au-torisation d’accès et l’administration des accès ;

— annulation de droits d’accès.

Conformité

L’objectif de ce chapitre est de garantir que la sécurité de l’information est mise en œuvre etappliquée conformément aux politiques et procédures organisationnelles.La mesure dans ce chapitre, recommande d’une part, de procéder à des revues régulières etindépendantes de l’approche retenue par l’organisation pour gérer et mettre en œuvre la sécu-rité de l’information (à savoir le suivi des objectifs, les mesures, les politiques, les procédureset les processus relatifs à la sécurité de l’information) à intervalles définis ou lorsque des chan-gements importants sont intervenus.D’une autre part, elle recommande que les responsables revoient régulièrement la conformitédu traitement de l’information et des procédures dont ils sont chargés au regard des politiques,des normes de sécurité applicables et autres exigences de sécurité.La mise en œuvre préconise que la direction instaure une revue indépendante. Des revuesindépendantes sont nécessaires pour veiller à la pérennité de l’efficacité de l’approche de l’or-ganisation en matière de management de la sécurité de l’information. Elle préconise aussi dansun premier temps, que les responsables déterminent la manière de vérifier que les exigencesde sécurité de l’information définies dans les politiques, les normes et autres règlementationsapplicables, sont respectées. Et dans un deuxième temps, elle recommande d’envisager l’utili-sation d’outils de mesure et d’enregistrement automatisés pour procéder à des revues régulièresefficaces.Si la revue détecte une non-conformité, il convient que les responsables :

— déterminent les causes de la non-conformité ;

— évaluent la nécessité d’engager des actions pour établir la conformité ;

— mettent en oeuvre l’action corrective appropriée ;

— revoient l’action corrective entreprise pour vérifier son efficacité et identifier toute insuf-fisance ou faille.

1.6.2 Norme ISO 27001

L’ISO/CEI 27001 est une norme internationale de système de gestion de la sécurité de l’infor-mation de l’ISO et la CEI. Publiée en octobre 2005 et révisée en 2013, son titre est "Technolo-

21

gies de l’information - Techniques de sécurité - Systèmes de gestion de sécurité de l’information- Exigences". Elle fait partie de la suite ISO/CEI 27000. [63]

La norme ISO 27001 enseigne le personnel responsable de la sécurité dans les entreprises surla manière de construire, procéder, entretenir et optimiser un Système de Management de laSécurité de l’Information (SMSI) dans l’intention de maintenir la sécurité de l’information ausein de l’entreprise. Pour ce faire, la norme ISO 27001 utilise une approche d’améliorationcontinue connue sous le nom de PDCA (Plan-Do-Check-Act).

— PLAN : Dans cette phase, il s’agit de définir le périmètre, c’est à dire le domaine d’appli-cation du SMSI et spécifier les besoins en sécurité. À ce stade, une politique de sécuritéest élaborée, la réalisation de l’analyse des risques, le traitement des risques et le choixdes mesures de sécurité à mettre en place.

— DO : Ce stade permet d’établir un plan de traitement des risques afin que les objectifs duSMSI défini soient opérationnels. Il consiste également à déployer les mesures de sécuritésans oublier la formation du personnel.

— CHECK : La phase check comme son l’indique, consiste à détecter les erreurs. C’estégalement dans cette phase que se déroulent les audits et les contrôles internes.

— ACT : Le SMSI est optimisé au regard des résultats de la phase CHECK, des actionscorrectives et préventives sont ainsi élaborées.

Nous allons maintenant voir selon [71], les sections qui sont en rapport avec l’analyse deconformité dans l’approche de l’amélioration continue (PDCA).

Phase Do

C’est dans cette phase que les objectifs de sécurité sont définis ainsi que les plans pour lesatteindre.Dans la norme iso 27001 :2013, il est dit que l’organisation doit établir, aux fonctions etniveaux concernés, des objectifs de sécurité de l’information. Ces objectifs à leur tour doiventà leur tour :

— être cohérents avec la politique de sécurité ;

— être mesurables (si possible)

— tenir compte des exigences applicables à la sécurité de l’information, et des résultats del’appréciation et du traitement des risques ;

— être communiqués et aussi mis à jour quand cela est approprié.

Phase Check

Cette phase est l’une des plus importantes dans le processus d’analyse de conformité, car elleconsiste à détecter les incidents et les non-conformités.

22

Pour cette sous-section, l’organisation doit réaliser des audits internes à des intervalles planifiésafin de recueillir des informations permettant de déterminer si le système de management de lasécurité de l’information est conforme aux exigences propres de l’organisation et aux exigencesde la présente norme.Pour ce faire l’organisation doit :

— Planifier, établir, mettre en œuvre et tenir à jour un ou plusieurs programmes d’audit ;

— définir des critères d’audit et le périmètre de chaque audit ;

— sélectionner des auditeurs et réaliser des audits qui assurent l’objectivité et l’impartialitédu processus d’audit ;

— conserver des informations documentées comme preuves de la mise en œuvre des pro-grammes d’audit et des résultats d’audit.

Phase Act

Comme mentionné plus haut, cette phase donne lieu principalement à la mise en place d’ac-tions corrective. À cet effet, la norme recommande lorsqu’une non-conformité se produit,l’organisation doit :

— réagir à celle-ci et le cas échéant, traiter les conséquences ;

— évaluer s’il est nécessaire de mener une action pour éliminer les causes de la non-conformité, de sorte qu’elle ne se reproduise plus ;

— mettre en œuvre toutes les actions requises ;

— réviser l’efficacité de toute action corrective mise en œuvre.

1.6.3 COBIT

COBIT (Control Objectives for Business Related Technology) [64] est une approche pour lesgestionnaires, auditeurs et utilisateurs qui aide à évaluer les risques et à déterminer le niveaude contrôle afin de mieux protéger l’organisation. En effet, COBIT est un référentiel pour lagouvernance et l’audit des Systèmes d’Information développé par l’ISACA 12. COBIT adopteune approche orientée processus qui consiste à décomposer tout Système d’Information en 34processus regroupés en 4 domaines. Ces domaines sont entre autres :

— Planification et Organisation : l’objectif principal définit un plan stratégique pour leSystème d’Information basé sur l’efficacité, l’architecture et la stratégie technologiquetout en tenant compte de la gestion de son investissement. Ce domaine comprend cequi concerne l’organisation du Système d’Information et ses relations avec la directionquant à sa stratégie et le métier de l’entreprise. De plus, tout principe d’organisationimplique de traiter d’une part la gestion des ressources humaines et d’autre part, des

12. ISACA : Information System Audit Control Association

23

projets avec les critères de qualité et les risques associés tout en assurant la conformitéavec les besoins externes.

— Acquisition et mise en œuvre : ce domaine décrit dans une première partie les processusd’identification des solutions automatisées, d’acquisition, de la gestion d’actifs (infra-structure technologique, logiciels applicatifs) et leur adéquation avec les besoins métiers.Ensuite viennent lors de la mise en œuvre, le développement et la maintenance de pro-cédures, l’installation et l’accréditation des systèmes. Enfin, tout système étant évolutif,la gestion des changements est prise en compte.

— Livraison et Support : ce domaine comporte des processus équivalents à ceux décritsdans ITIL. Ce qui permet de retrouver :

- la définition et la gestion des niveaux de service, l’assistance aux clients et utilisateurs ;- la gestion de la performance et de la capacité ;- la gestion de la configuration ;- la gestion des incidents et des problèmes.

— Monitoring : ce dernier domaine s’occupe de la partie supervision des processus et del’aspect audit sous forme d’évaluation de l’adéquation du contrôle interne, souvent àpartir d’apports externes et indépendants.

En résumé, COBIT est un référentiel pour auditer l’activité du Système d’Informationdans l’environnement d’une grande organisation.

1.6.4 ITIL

ITIL (Information Technology Infrastructure Library) est une mise en œuvre de bonnes pra-tiques pour le management des processus informatiques [65]. Présentement en version 3 (Figure1.4), ITIL est une bibliothèque qui dénombre, résume et expose les meilleures pratiques pourun service informatique.Au nombre de ces pratiques, on peut citer :

— La stratégie des services (service strategy) qui définit les processus comme la gestionfinancière, la gestion du portefeuille des services, la gestion des demandes, etc. .

— La conception des services (service design), qui permet mettre en relation des processus,assurer la sécurité des informations, maintenir un niveau de stock permettant de répondreà la demande, etc. .

— La transition des services (service transition) qui est composé de processus donnant lieuà la gestion des changements, à la gestion des mises en production, sans oublier le servicede test et validation.

— L’exploitation des services (service operation) qui prend en charge les processus commela gestion des accès, la gestion des incidents, la gestion des problèmes, etc. .

24

Figure 1.4 – ITIL version 3 [65].

1.7 Conclusion

Dans ce chapitre, nous avons présenté les principes fondamentaux et les pratiques liées à unebonne gestion des identités et des droits d’accès. Nous avons également défini les différentsprocessus et techniques utilisés par un système IAM afin de garantir une bonne gestion desidentités, des habilitations et des accès au sein d’un système d’information. Finalement, uneébauche de quelques outils de contrôle d’accès et norme de sécurité ont été définies afin d’aiderles administrateurs à choisir la technologie adaptée à leur besoin.

Cette mise en œuvre des concepts et pratiques autour du contrôle d’accès vient nous confor-ter dans l’élaboration de nos travaux et nous permet d’aborder la partie suivante, où il estquestion de la représentation des droits d’accès sous Windows et Linux.

25

Chapitre 2

Représentation des droits d’accès sousWindows et Linux

2.1 Introduction

La sécurisation des systèmes informatiques est un domaine ouvert uniquement à un certainnombre de personnes regroupant des compétences et un savoir-faire avéré. En effet, la sé-curité informatique fait ressortir plusieurs notions telles que l’intégrité, la disponibilité, laconfidentialité, la non-répudiation et l’authentification des données circulant au sein d’un sys-tème d’information. Ainsi, l’un des axes principaux de la sécurité informatique est le contrôled’accès.

Le contrôle d’accès est la mise en œuvre de procédures permettant de vérifier qu’une entitévoulant avoir accès à une ressource bénéficie des droits ou habilitations nécessaires pour lefaire. Il se fait de façon générale en se basant sur une politique de sécurité.

En effet, cette méthode de contrôle d’accès peut être remarquée aussi bien dans le domaine desinfrastructures informatique, que dans la vie de tous les jours. Prenons le cas d’une personnequi veut retirer de l’argent au guichet automatique, le contrôle d’accès se définit ici par le faitede vérifier que la personne dispose de sa carte bancaire et du bon NIP.

Afin de sécuriser les ressources, plusieurs systèmes d’information mettent en œuvre un systèmede contrôle d’accès en s’appuyant sur des modèles comme le MAC 1, DAC 2, RBAC 3 , etc. Unmodèle de contrôle d’accès est la mise en œuvre d’une méthode définissant des règles pour larépartition des droits d’accès.

Dans ce chapitre, nous allons définir les notions qui environnent le contrôle d’accès dans la

1. MAC : contrôle d’accès obligatoire.2. DAC : contrôle d’accès discrétionnaire.3. RBAC : contrôle d’accès à base de rôles.

27

section 1 ; dans la section 2 et 3, il s’agira de montrer les représentations du contrôle d’accèssous Linux et Windows, et finalement dans la section 4 nous représenterons quelques interfacesutilisateurs de gestion de contrôle d’accès.

2.2 Contrôle d’accès : définitions et politiques

Faisant référence au livre "Un cadre sémantique pour le contrôle d’accès" [2], on y découvreune représentation particulière en ce qui concerne la traduction des modèles d’accès.

Définition et notation :

-Entités

Les entités du système sont subdivisées en deux ensembles :

— l’ensemble S des sujets, aussi appelé "entités actives", qui représente les entités quiexécutent les actions dans le système.

— l’ensemble O des objets, aussi appelé "entités passives", qui supporte les actions. Lessujets et les objets sont en général jugés aussi bien que des entités atomiques. Parmiplusieurs modèles, on fait allusion au terme utilisateur plutôt qu’ objet. Ces deux termesne sont pas forcément distincts : par exemple, un processus peut parallèlement être unutilisateur parce qu’il exécute des opérations et un objet, dans l’option où un deuxièmeprocessus essaie de le stopper.

-Accès

L’ensemble des accès noté A, représentent les multiples modes d’accès exécutés par les sujetssur les objets. Cet ensemble inclut de façon générale les accès de type "read, write, execute,etc.". De façon formelle on peut décrire un accès A par un triplet (s, o, x) traduisant que lesujet s a accès à l’objet o selon le mode d’accès x.

-Paramètres de sécurité

Quelques informations liées aux entités sont utiles et essentielles afin d’être à même de mieuxexprimer une politique de sécurité dans un système d’information donné. Ces informationsémanent de ce que nous dénommerons les paramètres de sécurité et sa notation est ρ.

-État

Un état correspond à un instant donné du système et comprend toujours un descriptif del’ensemble des accès, à savoir tous les accès admis, mais dont le processus reste inachevé. Onnote cet ensemble Σ.

-Fonction de sécurité

Un état est tenu aussi de spécifier un groupe de fonctions de sécurité, qui joint les entités aux

28

paramètres de sécurité. Puisque ces fonctions de sécurité sont définies par les états, elles sontmodifiables lors des phases de transitions, à l’encontre des paramètres de sécurité, qui sontdéfinitifs pour une politique donnée.On définit Υ(σ), σ dans Σ, exprime le groupe des fonctions de sécurité de l’état σ.

Υ : Σ→ SF 4.

-Accès courant

Un accès courant traduit un accès qui a été admis, mais dont le processus reste inachevé.L’ensemble des accès courants est noté Λ. De même on à :

Λ : Σ→ ℘(A)

Où ℘(A) désigne l’ensemble des parties de A. Compte tenu un état σ, Λ(σ) traduit l’ensembledes accès courants du système dans l’état σ.

-Prédicat de sécurité

Une politique de sécurité décrit les états sûrs d’un système. Ces états sûrs sont déterminéspar un prédicat de sécurité et sa notation est Ω.

-Politique de sécurité

Une politique de contrôle d’accès se base sur des paramètres de sécurité. Les paramètres desécurité étant notés ρ, une politique de sécurité d’accès P[ρ] est traduite par un quintuple :

P[ρ] = (S,O,A,Σ,Ω)

où S est un ensemble de sujets, O un ensemble d’objets, A un ensemble de modes d’accès, Σ

l’ensemble des états du système et Ω un prédicat de sécurité caractérisant les états sûrs.

4. SF : Fonction de sécurité.

29

Figure 2.1 – Concepts de base pour le contrôle d’accès dans Linux

2.3 Contrôle d’accès sous Linux

2.3.1 Concepts de base pour le contrôle d’accès dans Linux

Sur Linux, le contrôle d’accès s’élabore conformément au modèle DAC. Effectivement, dans lessystèmes d’exploitation Linux, un objet, qui peut être un fichier ou un processus, se rapporteà un propriétaire appelé Owner et est aussi combiné à un groupe appelé Owner Group. Lerestant des utilisateurs appelés Others sont considérés dans la définition des droits d’accès surun objet.

Excepté l’utilisateur suprême (root) qui administre totalement tous les objets du système,uniquement le Owner peut accéder et modifier ses objets ; sans compter qu’il est également leseul à pouvoir déléguer des droits d’accès au Owner Group et aux Others.[9]

Les droits d’accès donnés à un objet sont traduits par trois entités de trois caractères quiappartiennent à l’ensemble : r, w, x,−.La première entité de trois caractères indique le droit d’accès du Owner, la deuxième de troiscaractères traduit les droits d’accès du Owner Group et la troisième entité de caractères indiqueles droits donnés au Others . (Voir Figure 2.1). Dès lors on parvient à trois entités de troiscaractères. Le premier caractère de chacune des entités accorde le droit de lecture s’il retourne"r", autrement il retourne "−" et le droit de lecture n’est pas accordé.Le deuxième caractère de chacune des entités accorde le droit d’accès en écriture sur un objets’il retourne "w" sinon il retourne "−" et le droit d’écriture n’est pas accordé.Le troisième caractère d’une entité accorde l’autorisation d’exécuter un objet s’il retourne "x"sinon il retourne "−" et le droit d’exécuter n’est pas accordé".

En exécutant la commande ls -l , on a les droits d’accès des différents fichiers ainsi que leprésente la figure 2.2.

Figure 2.2 – Droit d’accès Linux : Exemple.

Selon l’exemple, le premier caractère révèle la nature de l’objet. Le caractère d nous indiqueque la nature du fichier est un dossier, tandis que le caractère − quant à lui nous indiqueque la nature de l’objet est un fichier. Les caractères ci-après traduisent les droits d’accès

30

pour respectivement le Owner, Owner Group et Others. La valeur drwxr−xr−x signifie quele Owner a les droits de lecture, d’écriture et de "traversée"(c’est-à-dire qu’on peut voir lessous-dossiers que le dossier contient) ; le Owner Group et le Others ont le droit de lecture etde "traversée". Sous Linux, les droits d’accès sont modifiables le Owner où le root en utilisantla commande chmod.

Le bit setuid

Quand un utilisateur lance un programme, celui-ci s’exécute avec les droits de cet utilisateur.Mais souvent, on veut lancer une commande spéciale (en général réservé au super utilisateur)en tant que simple utilisateur. L’exemple le plus manifeste étant la commande passwd dont lechemin d’accès est /usr/bin/passwd qui est une commande root.

$ ls -l /usr/bin/passwd-rwsr-xr-x 1 root root 25036 2013-10-02 11:08 /usr/bin/passwd

En regardant les droits sur passwd, on s’aperçoit que ce fichier est affecté par le bit setuid :c’est-à-dire que lorsqu’un utilisateur lance la commande passwd, elle est lancée avec les droitsdu root, ainsi l’écriture pourra se faire dans le fichier /etc/passwd et l’utilisateur aura changéson mot de passe sans être root. Sans le setuid 5, l’utilisateur n’aurait pas pu écrire dans lefichier /etc/passwd.setuid est un attribut de fichier spécial qui indique au système d’exécuter certains programmessous un ID utilisateur spécifique.[36]Il est à noter que la notion de setuid n’existe pas pour les répertoires.

Le bit setgid

La théorie du setgid 6 est le même que le setuid pour un fichier, mais assurément au niveaudes droits du groupe. Un exécutable affecté par le bit setgid peut donc être déclenché avec lesdroits du groupe auquel il se rapporte.En revanche, le comportement change lorsqu’il s’agit d’un répertoire. Quand il s’agit d’unrépertoire, tous les fichiers créés dans ce répertoire appartiennent au même groupe que lerépertoire. Exemple : prenons le cas d’un répertoire contenant plusieurs utilisateurs qui tra-vaillent sur celui-ci pour un même projet, il est bon d’affecter le bit setgid au dossier, de cettemanière, les fichiers mis en œuvre appartiendront tous au même groupe.

drwxrws--- 2 tux projet1 48 Jan 19 10:12 backup

5. setuid = Set User ID.6. setuid = Set Group ID.

31

le s signifie que le bit setuid est défini pour l’autorisation du groupe. Le propriétaire du dossierbackup et les membres du groupe projet1 peuvent accéder au dit dossier.

Le sticky bit

L’utilisation du bit collant (sticky bit) est différente dépendamment de s’il appartient à unfichier ou à un répertoire. S’il est assigné à un fichier, alors le fichier en question est chargé dansla mémoire vive pour éviter d’avoir à le recueillir du disque dur à chacune de ces utilisations .Si ce bit appartient à un répertoire, alors son but est d’empêcher les utilisateurs de supprimerleurs fichiers respectifs. Les exemples spécifiques sont entre autres les répertoires /tmp et/var/tmp.

drwxrwxrwt 2 root root 1160 2002-11-19 17:15 /tmp

le t indique que le sticky bit est attribué au répertoire /tmp, dont l’accès en écriture demeurepossible par tous les utilisateurs, sans que ceux-ci se suppriment leurs fichiers.

2.3.2 Gestion des listes de contrôles d’accès sous Linux

La majorité de plusieurs développements du modèle de sécurité Linux demeurait des fonction-nalités du modèle d’accès discrétionnaire. Les groupes de recherche Unix, ont mis au pointchacun leurs propres améliorations, souvent très semblables les unes aux autres, des travauxlaborieux ont été consentis pour essayer de les standardiser.

Les ACL (listes de contrôle d’accès) POSIX pour Linux sont fondées sur la proposition premièredu standard POSIX [35]. Elles sont employées comme une avancée de la notion traditionnelled’autorisation pour les objets système de fichiers. Les ACL donnent lieu à la mise en œuvredes autorisations plus aisément que le concept d’autorisation traditionnel.

Avantage des ACL

En général, trois entités d’autorisations sont spécifiées pour chacun des objets (fichier) sousLinux. Ces entités englobent les autorisations lire (r), écrire (w) et exécuter (x) pour chacundes trois types d’utilisateurs : le Owner, le group et les others. Par ailleurs, il est possible dedéfinir les bits set user id et set group id comme nous l’avons vu plus haut.Cette notion élémentaire est absolument adaptée dans une grande partie des cas pratiques.Toutefois, pour les scénarios plus délicats ou les applications avancées, les administrateurssystème jadis étaient obligés d’adopter plusieurs moyens pour contourner les limitations duconcept d’autorisation traditionnel.

32

Les ACL sont perçues comme une avancée de la notion traditionnelle d’autorisation d’accèsaux fichiers. Elles donnent lieu à l’attribution de différentes autorisations à des utilisateurs ouà des groupes, même si ceux-ci ne se rapportent pas au propriétaire d’origine ou au groupepropriétaire. Les listes de contrôle d’accès sont une fonctionnalité du Kernel Linux et sontactuellement prises en charge par ReiserFS, Ext2, Ext3, JFS et XFS [36].Les ACL donnent lieu à la réalisation de scénarios complexes sans implanter des modèlesd’autorisation complexes au niveau de l’application.

Gestion des ACL

Le Tableau 2.1 affiche les six types possibles d’entrées ACL, chaque entrée spécifie les au-torisations d’un utilisateur ou d’un groupe d’utilisateurs. L’entrée propriétaire spécifie lesautorisations de l’utilisateur propriétaire de l’objet. L’entrée groupe propriétaire spécifie lesautorisations du groupe propriétaire de l’objet. Le super utilisateur quant à lui à la possibi-lité de modifier le propriétaire ou le groupe propriétaire à travers les commandes chown ouchgrp. À ce moment-là, les entrées du propriétaire et du groupe propriétaire font allusion aunouveau propriétaire et au nouveau groupe propriétaire.Chacune des entrées (utilisateur nommé) spécifie les autorisations de l’utilisateur défini dansle champ de qualification de l’entrée. Uniquement les entrées d’utilisateur nommé et de groupenommé ont un champ de qualification qui n’est pas vide. L’entrée autre spécifie les autorisa-tions du reste des utilisateurs (others).

Type Forme Textuellepropriétaire user : :rwxutilisateur nommé user :name :rwxgroupe propriétaire group : :rwxgroupe nommé group :name :rwxmasque mask : :rwxautre other : :rwx

Table 2.1 – Types d’entrées ACL [36].

L’entréemasque, a pour rôle de restreindre les autorisations accordées par les entrées utilisateurnommé, groupe nommé et groupe propriétaire en spécifiant, parmi ces entrées, les autorisationsqui sont en cours et les autorisations masquées.Quand des autorisations sont configurées dans l’une des entrées citées ainsi que dans le masque,elles sont en cours tandis que les autorisations incluses seulement dans le masque ou seulementdans l’entrée en question ne sont pas en cours, et ne sont pas accordées. L’ensemble desautorisations définies dans les entrées propriétaire et groupe propriétaire sont constamment encours. L’exemple du Tableau 2.2 explique ce processus.

33

Type d’entrée Forme textuelle Autorisationsutilisateurs nommé user :emma :r-x r-xmasque mask :: rw− rw−

autorisations en cours r–

Table 2.2 – Masquage des autorisations d’accès.

On compte deux classes basiques d’ACL :

— une ACL minimale, inclus seulement les entrées des types propriétaire, groupe proprié-taire et autre, qui se rapportent aux bits conventionnels d’autorisation pour les fichierset les répertoires.

Figure 2.3 – ACL minimale.

— Une ACL étendue est beaucoup plus développée. Elle inclus une entrée masque et peutrenfermer de multiples entrées de type utilisateur nommé et groupe nommé.

Figure 2.4 – ACL étendue.

Répertoire avec une ACL d’accès

Les autorisations d’accès de l’utilisateur et du groupe pour tous les types d’objets système defichiers (fichiers et répertoires) sont déterminées au moyen des ACL d’accès. Avec getfacl et

34

setfacl sur la ligne de commande, on peut visualiser et modifier les ACL. L’utilisation de cescommandes est présentée dans l’exemplaire suivant.

Exemple : Avant de créer le répertoire LSI, utilisons la commande umask pour spécifier lesautorisations d’accès qui seront masquées chaque fois qu’un objet est créé.La commande umask 027, spécifie les autorisations par défaut en accordant au propriétairetous les droits (0), en refusant au groupe le droit d’écrire (2) et en n’accordant aucun droitaux autres utilisateurs (7). En réalité,umask masque les bits d’autorisation correspondants oules désactive.

mkdir LSI crée le répertoire LSI avec les droits par défaut tels qu’ils sont spécifiés par umask.Employons ls -dl LSI pour s’assurer que tous les droits ont été attribués correctement.Voici le résultat de la commande :

drwxr-x--- ... memel avtac ... LSI

Avec getfacl LSI, examinons l’état initial de l’ACL. On obtient des informations comme :

# file: LSI# owner: memel# group: avtacuser::rwxgroup::r-xother::---

Les trois premières lignes donnent la description du nom, du propriétaire et du groupe pro-priétaire du répertoire. Les trois lignes suivantes affichent les trois entrées ACL propriétaire,groupe propriétaire et autre. En effet, dans le cas de l’ACL minimal, la commande getfacl negénère pas plus d’informations que la commande ls.Modifions l’ACL pour attribuer des droits de lecture, d’écriture et d’exécution à l’utilisateuradditionnel emmanuel et au groupe additionnel labo, de la façon suivante :

setfacl -m user:emmanuel:rwx,group:labo:rwx LSI

L’option -m demande à setfacl permet de modifier l’ACL existante. C’est un argument quidésigne les entrées ACL à modifier. La partie restante indique le nom du répertoire dans lequelces modifications ont été apportées.Utilisons la commande getfacl pour consulter la nouvlle valeur de l’ACL.

35

# file: LSI# owner: memel# group: avtac user::rwxuser:emmanuel:rwx group::r-xgroup:labo:rwx mask::rwxother::---

En plus des entrées lancées pour l’utilisateur emmanuel et le groupe labo, une entrée maska été générée. Cette entrée de masque est spécifiée automatiquement afin que tous les droitsentrent en vigueur.setfacl dispose automatiquement les entrées mask aux nouveaux paramètres sauf si nousdésactivions cette fonctionnalité avec -n.mask détermine le maximum de droits d’accès en vigueur pour toutes les entrées de la classede groupe.Les bits d’autorisation de la classe de groupe indiqué par la commande "ls -dl LSI" conviennentmaintenant à l’entrée mask.

drwxrwx---+ ... memel avtac ... LSI

La première colonne du résultat compte un signe + indiquant que cet élément possède uneACL étendue.

Dépendamment du résultat de la commande ls, les droits de l’entrée de masque comprennentl’accès en écriture. En général, de tels bits d’autorisation signifient que le groupe propriétaire(avtac) a aussi le droit d’écrire sur répertoire LSI. Toutefois, les droits d’accès en vigueurdu groupe propriétaire coïncide à la partie commune avec les droits spécifiés pour le groupepropriétaire et le masque (r − x).

Modifions l’entrée du masque avec setfacl ou chmod.Par exemple, faisons chmod g-w LSI.La commande ls -dl LSI donne le résultat suivant :

drwxr-x---+ ... memel avtac ... LSI

getfacl LSI affiche :

# file: LSI# owner: memel# group: avtacuser::rwx

36

user:emmanuel:rwx # effective: r-xgroup::r-xgroup:labo:rwx # effective: r-xmask::r-xother::---

Une fois la commande chmod exécutée, pour supprimer le droit écrire des bits de la classe degroupe, le résultat de la commande ls est suffisant pour savoir que les bits de masque devrontêtre modifiés en conséquence : le droit d’écrire est à nouveau restreint au propriétaire de LSI.Le résultat de getfacl soutient ce fait. Ce résultat inclut un commentaire pour toutes lesentrées dans lesquelles les bits d’autorisation en vigueur ne coïncident pas aux autorisationsd’origine, car elles sont filtrées dépendamment de l’entrée de masque. Les autorisations d’ori-gine peuvent être reconstituées en tout temps grâce à la commande chmod g+w LSI.

Répertoire avec une ACL par défaut

Les répertoires ont la possibilité de disposer d’une ACL par défaut. Les ACL par défauts’appliquent uniquement aux répertoires et déterminent les autorisations qu’un objet Systèmede fichiers hérite de son répertoire parent lors de sa création[36].

Il y a deux façons d’attribuer les permissions d’une ACL par défaut d’un répertoire aux fichierset aux sous-répertoires qu’il renferme :

— Un sous-répertoire hérite de l’ACL par défaut du répertoire parent en tant qu’ACL pardéfaut et ACL d’accès.

— Un fichier hérite d’une ACL par défaut en tant qu’ACL d’accès.

L’ensemble des appels système qui définissent les objets système de fichiers utilisent un pa-ramètre mode qui spécifie les droits d’accès pour le nouvel objet Système de fichiers. Au casoù le répertoire parent ne possède pas une ACL par défaut, les bits d’autorisation définis parumask sont retranchés des droits remis par le paramètre mode, le résultat étant attribué aunouvel objet.En admettant que le répertoire parent dispose d’une ACL par défaut, les bits d’autorisationattribués au nouvel objet se rapportent à la partie commune des autorisations du paramètremode et à celles spécifiées dans l’ACL par défaut. umask n’est pas pris en compte dans cettecirconstance.

Les exemples ci-après représentent les opérations essentielles des répertoires et des ACL pardéfaut :

1. Ajoutons une ACL par défaut au répertoire existant LSI par la commande suivante :

setfacl -d -m group:labo:r-x LSI

37

L’argument -d de la commande setfacl lui demande de faire les modifications suivantes (argu-ment -m) à l’ACL par défaut.

Examinons plus soigneusement la sortie de cette commande :

getfacl LSI

# file: LSI# owner: memel# group: avtacuser::rwxuser:emmanuel:rwxgroup::r-xgroup:labo:rwxmask::rwxother::---default:user::rwxdefault:group::r-xdefault:group:labo:r-xdefault:mask::r-xdefault:other::---

getfacl retourne l’ACL d’accès et l’ACL par défaut. L’ACL par défaut est composée de toutesles lignes débutant par default. Quoique nous ayons uniquement exécuté la commande setfaclavec une entrée pour le groupe labo de l’ACL par défaut, setfacl a de façon automatique copiétoutes les autres entrées de l’ACL d’accès dans le but de créer une ACL par défaut valide.Les ACL par défaut n’ont pas d’effet imminent sur les droits d’accès. Elles sont fonctionnellesseulement quand des objets système de fichiers sont créés. Ces objets héritent des droits pro-venant seulement de l’ACL par défaut de leur répertoire parent.

2. À l’intérieur de l’exemple ci-après, utilisons la commande mkdir pour créer dans LSI unsous-répertoire sousLSI qui hérite de l’ACL par défaut.

mkdir LSI/sousLSI

getfacl LSI/sousLSI

# file: LSI/sousLSI# owner: memel# group: avtacuser::rwxgroup::r-x

38

group:labo:r-xmask::r-xother::---default:user::rwxdefault:group::r-xdefault:group:labo:r-xdefault:mask::r-xdefault:other::---

Bien entendu, le nouveau répertoire sousLSI a les droits de l’ACL par défaut du répertoireparent. L’ACL d’accès de sousLSI est la réplique exacte de l’ACL par défaut de LSI. L’ACLpar défaut que ce répertoire doit céder à ses objets sous-jacent est aussi identique.

3. À l’aide de la commande touch créons un fichier monfichier dans le répertoire LSI, enl’occurrence, touch LSI/monfichier.La commande ls -l LSI/monfichier donnera ainsi en sortie :

-rw-r-----+ ... memel avtac ... LSI/monfichier

L’affichage de getfacl LSI/monfichier est la suivante :

# file: LSI/monfichier# owner: memel# group: avtacuser::rw-group::r-x # effective:r--group:labo:r-x # effective:r--mask::r--other::---

la commande touch dispose d’un paramètre mode qui a la valeur 0666 lorsque les fichiers sontcrées. La création des fichiers se fait donc avec les droits lire et écrire pour toutes les classesd’utilisateurs, pourvu qu’il n’existe pas une restriction en plus dans umask ou dans l’ACL pardéfaut .

Cette démarche renforce l’interaction correcte des applications, particulièrement des compi-lateurs, avec les ACL. A ce niveau on peut donc créer des fichiers ayant des droits d’accèsrestreint et les marquer par la suite comme exécutables.

39

2.3.3 SELinux

Security Enhanced Linux (SELinux) est l’implémentation d’un contrôle d’accès obligatoire(MAC). Il a été conçu pour répondre à une grande variété de besoins de sécurité, de l’uti-lisation générale, aux exigences des systèmes gouvernementaux et militaires exploitant desinformations classifiées [39]. La sécurité du MAC est différente de celle du DAC à cause dela politique de sécurité qui y est administrée de manière centrale, et aussi que les utilisateursn’ont aucun contrôle en ce qui concerne la politique de leurs ressources. Cette approche par-ticipe à contrôler les attaques qui exploitent des bogues ou des défauts de configuration dansles applications pour utilisateur.Sous SELinux, on attribue aux objets tels les fichiers, des étiquettes ou labels. Toutes les ré-actions entre les ensembles liés à la sécurité sont retenues par LSM 7 et données au moduleSELinux, qui examine la politique de sécurité de façon à déterminer si l’opération en courspeut continuer. La politique de sécurité SELinux est loadée depuis la plateforme utilisateur, etest modifiable pour faire face à plusieurs objectifs de sécurité. Beaucoup de modèles de MACpassés détenaient une politique fixe, qui délimitait leur application dans un cadre d’informa-tique générale.SELinux est installé sur plusieurs OS Linux et également activé par défaut sur tous les OSbasés sur Fedora.

Implémentation de SE Linux

D’après [41], le code source de SELinux est inséré dans les noyaux de base fournis par Debian etles programmes standards issus de la famille Unix. Ainsi on peut facilement utiliser SELinux.

La commande utilisée pour l’installation du paquetage et indispensable pour paramétrer uneplateforme SELinux est :aptitude install selinux-basics selinux-policy-default .

Le package selinux-policy-default comprend plusieurs de règles de base. Naturellement, cesrègles limitent les accès que pour quelques services mis en évidence. Les sessions utilisateurn’étant pas limitées, il n’y a par conséquent peu de chance que SELinux empêche les opérationsadmissibles des utilisateurs. Par contre, ceci donne lieu à un apport de surplus de sécurité pourles services système s’exécutant sur la machine.

Après l’installation des règles, il faut labelliser tous les fichiers vacants en leur affectant untype.Ce processus est possible en déclenchant de façon manuelle la commande fixfiles relabel .

La plateforme SELinux étant opérationnelle, il faut alors l’activer. Pour se faire, il faut ap-pliquer la variable selinux=1 au noyau de l’OS. La variable audit=1 initialise les tracesSELinux qui mémorisent les opérations non acceptées.

7. LSM : Linux Security Modules.

40

Finalement la variable enforcing=1 donne lieu à l’exécution des règles : en réalité, de façonbasique SELinux s’exécute en "mode permissive" (les opérations interdites sont tracées néan-moins elles sont tout de même autorisées). Il faut ainsi effectuer la modification du fichier deconfiguration du chargeur d’amorçage GRUB 8 afin de compléter les paramètres souhaités. Defaçon pratique il faut modifier le paramètre GRUB_CMDLINE_LINUX qui se trouvedans /etc/default/grub et exécuter update-grub. Au redémarrage, SELinux sera actif.

Gestion des identités dans SE Linux

Toutes les fois qu’un utilisateur s’authentifie, le système lui assigne une identité SELinux, qui apour fonction de définir les rôles de l’utilisateur. Ces deux corrélations à savoir de l’utilisateurvers l’identité SELinux et de l’identité vers les rôles s’établissent à l’aide de la commandesemanage .

À cette commande on pourra associer différents arguments entre autres : -a pour ajouter, -dpour supprimer, -m pour modifier, -l pour lister et -t pour indiquer un type.

semanage login -l liste les corrélations subsistantes entre ID utilisateurs et identités SE-Linux. Si un utilisateur n’a pas de corrélation précise, il aura l’identité affichée en face de_default_. La commande semanage login -a -s user_u utilisateur va affecter l’iden-tité user_u à l’utilisateur. Finalement, semanage login -d utilisateur va supprimer lacorrélation attribuée à l’utilisateur.

# semanage login -a -s user_u rhertzog# semanage login -l

Login Name SELinux User MLS/MCS Range

__default__ unconfined_u s0-s0:c0.c1023rhertzog user_u Noneroot unconfined_u s0-s0:c0.c1023system_u system_u s0-s0:c0.c1023# semanage login -d rhertzog

semanage user -l énumère les corrélations entre identités SELinux et les rôles. Faire unajout d’une nouvelle identité exige de spécifier d’un côté les rôles correspondants et d’un autreun préfixe d’étiquetage qui va définir le type affecté aux fichiers (/home/utilisateur/* ). Lechoix se fera donc parmi les préfixes suivants : user , staff et sysadm .Le préfixe « staff » produira des fichiers typés, ex : staff_home_dir_t . La commandequi permet de créer une identité est semanage user -a -R rôles -P préfixe identité .Finalement, une identité sera supprimée grâce à la commande semanage user -d identité .

8. GRUB : GRand Unified Bootloader.

41

# semanage user -a -R ’staff_r user_r’ -P staff test_u# semanage user -l

Labeling MLS/ MLS/SELinux User Prefix MCS Level MCS Range SELinux Roles

root sysadm s0 s0-s0:c0.c1023 staff_r sysadm_r system_rstaff_u staff s0 s0-s0:c0.c1023 staff_r sysadm_rsysadm_u sysadm s0 s0-s0:c0.c1023 sysadm_rsystem_u user s0 s0-s0:c0.c1023 system_rtest_u staff s0 s0 staff_r user_runconfined_u unconfined s0 s0-s0:c0.c1023 system_r unconfined_ruser_u user s0 s0 user_r# semanage user -d test_u

2.4 Contrôle d’accès sous Windows

Définitions

D’après [13], nous allons définir plusieurs termes afin de mieux appréhender le contrôle d’accèssous Windows.

Objets

Un Objet est un composant sécurisable et protégeable par des permissions. Il peut sematérialiser par un fichier, un répertoire, une clé de registre, un socket, un processus, unthread, etc. Microsoft ne fournit pas un standard d’outils pour gérer les permissions surtous les objets. La plupart du temps, c’est au développeur d’administrer ses permissionspar des programmes alors qu’il crée et manipule un objet.

ACL

Une ACL est une liste de contrôle d’accès qui administre les permissions d’accès aux ob-jets du système. Elle comprend des entrées de contrôle d’accès ACE 9. En ce qui concerneles ACL, on en distingue deux types :Les ACL systèmes ou SACL et les ACL discrètes ou DACL.Une SACL (System Access Control List) est une liste de contrôle d’accès qui spécifie lesévènements audités lors des tentatives d’accès à un objet sécurisé.Une DACL (Discretionary Access Control List) est une liste de contrôle d’accès discré-tionnaire parce qu’elle est administrée par le propriétaire de l’objet. Une DACL admi-nistre les permissions sur un objet sécurisé en spécifiant qui est habilité à accéder au dit

9. ACE : Access Control Entry.

42

Figure 2.5 – ACE de type accès accordé [13].

objet.

ACE

Une entrée de contrôle d’accès ACE est la structure qui enregistre les permissions pourun compte de sécurité donné et spécifie aussi les propriétés d’audit pour ce compte surl’objet en question. Une ACL peut avoir zéro ou plusieurs ACE.

Une ACE inclus un SID 10, un masque d’accès de 32 bits qui spécifie les permissionsattribuées au SID et un drapeau ou flag qui définit le type d’ACE (ACE de type accèsaccordé, ACE de type accès refusé et ACE de type Audit system).

Descripteur de sécurité

Le descripteur de sécurité SD (Security Descriptor) est la structure liée à tout objetsécurisable qui inclus le SID du propriétaire de l’objet, son groupe primaire, et les deuxtypes de listes d’ACL (DACL et SACL).

SDDL

10. Security Identifiers

43

Figure 2.6 – ACE de type accès refusé [13].

Le langage de définition des descripteurs de sécurité SDDL (Security Descriptor Defi-nition Langage) est un langage qui spécifie et exporte les informations contenues dansun descripteur de sécurité au format texte. Ce langage permet entre autres d’écrire desscripts ou d’automatiser l’application de sécurités sur un ensemble de données à partird’un fichier d’entrée au format texte.

Ainsi, la commande sc sdshow présente le descripteur de sécurité d’un service au formatSDDL.La syntaxe est la suivante :

[<ServerName>] sc sdshow <ServiceName>

Toutefois si la commande est exécutée localement le paramètre [<ServerName>] peutêtre omis.

Contrôle d’accès

MS Windows met en œuvre le modèle de contrôle d’accès discrétionnaire (DAC) pour lecontrôle d’accès. De façon classique, les systèmes Windows exploitent les listes de contrôled’accès discrétionnaire (DACL) pour consolider le contrôle des droits d’accès sur ces différentsobjets (fichier, dossier, clé de registre...). C’est pourquoi le descripteur de sécurité peut admi-nistrer l’accès à tout objet.Dans Windows, il est question également du concept de sujet (Principal Security) qui est

44

Figure 2.7 – Structure d’un descripteur de sécurité [13].

Figure 2.8 – Language SDDL.

constitué d’utilisateurs, processus, etc. À chaque sujet est assigné un SID qui permet del’identifier de façon unique.

Lorsque le bit (masque) d’une ACE qui traduit la permission écrire a la valeur 1 et que l’ACEest de type accès refusé alors l’ACE interdit le droit de modifier les permissions de l’objet.Par ailleurs, si le bit identique a la valeur 1 et que le l’ACE est de type accès accordé alorsl’ACE autorise le droit de modifier les permissions de l’objet.

45

La structure du masque d’accès est constituée de bits qui équivalent aux types de droits d’accèssuivant [12] :

— les droits standards commeDELETE qui traduit le droit de supprimer un objet,WRITE_DACqui traduit le droit de modifier le DACL, et WRITE_OWNER qui traduit le droit dechanger le propriétaire de l’objet.

— les droits génériques à l’instar deGENERIC_READ,GENERIC_WRITE,GENERIC_EXECUTEet GENERIC_ALL ;

Même si le propriétaire d’un objet n’a pas une entrée dans le DACL, il peut, de manièreimplicite, lire et modifier les permissions de son objet.

Lorsqu’un objet n’a pas de DACL, Windows permet l’accès total à tous les utilisateurs ; au-trement, Windows examine les ACE qui sont dans le DACL de l’objet. Tout ACE dans unDACL d’un objet définit le droit d’accès accepté ou exclu pour l’utilisateur.[13]Le système analyse tous les ACE progressivement jusqu’à l’obtention d’une action ci-après :

— Un accès refusé (voir Figure 2.6)

— Un ou plusieurs accès acceptés (voir Figure 2.5).

2.5 Représentation graphique du contrôle d’accès

Dans les différents systèmes d’exploitation Linux commeWindows, la notion d’interface homme-machine est une entité fondamentale de leur architecture. En effet un système d’exploitationse fonde autour d’un noyau qui gère les opérations de bas niveau ; le noyau se charge égale-ment de la gestion des entrées/sorties, et d’une interface système (Shell en anglais) [14] qui estle diminutif d’interface utilisateur du système d’exploitation comme le montre la figure 2.9.Toutes les interactions entre le système d’exploitation et les utilisateurs se font via le Shell.Ce dernier peut être divisé en deux catégories que sont :

— l’interface en ligne de commande (CLI, pour Command Line Interface) ;

— l’interface graphique pour utilisateur (GUI, pour Graphical User Interface).

Tous les systèmes d’exploitation dernière génération intègrent ces deux formes de Shell. Onparle de mode console si un système d’exploitation utilise seulement le CLI et de mode gra-phique s’il utilise une GUI. En mode graphique, il existe des outils pour émuler une consoledans une fenêtre ; sous Linux, ce type d’outil est communément appelé terminal et sous Win-dows, c’est l’outil CMD pour Commande MS DOS qui émule une console dans les versionsantérieures à Windows Vista et à partir de cette dernière, un autre outil c’est ajouter à CMDil s’agit de l’application PowerShell [15].

Dans cette section nous nous intéresserons aux interfaces graphiques de Linux et de Windows.Sous Linux l’interface graphique est le serveur X et sous Windows c’est l’explorateur Windows

46

Figure 2.9 – Architecture Linux [53].

qui assume ce rôle. Dans les deux cas de figure, on parle d’environnement de bureau qui esttiré de la métaphore du bureau [16].

Cependant, la particularité de Linux qui a plusieurs déclinaisons affecte le nombre de gestion-naires de l’environnement de bureau. Ainsi, on a les gestionnaires de bureau GNOME [17] etKDE [18] qui sont les plus répandus et les gestionnaires de bureau allégé comme Lxde [19] etXfce [20]. En général, les distributeurs d’OS Linux offrent la possibilité de choisir un type degestionnaire de bureau à l’installation.

Pour le contrôle d’accès, les OS Linux et Windows offrent des interfaces graphiques pourfaciliter la gestion du contrôle d’accès.

47

Figure 2.10 – GMC gestion des droits d’accès [21].

2.5.1 Interface de gestion du contrôle d’accès sur Linux

Sous les différentes distributions de Linux dont le gestionnaire de bureau est GNOME ouKDE, le contrôle d’accès sur les objets de type fichier et dossier est réalisé et est paramétrablegrâce à l’outil GNU Midnight Commander (GMC) [21] sur GNOME et KDE File Managersur KDE [22]. Pour montrer la gestion graphique du contrôle d’accès sous Linux, nous avonsfait une capture d’écran du GMC sous une machine Ubuntu comme le montre la figure 2.10.

On peut remarquer que sur la fenêtre dans la partie permission il y a les informations quidécrivent les droits d’accès au fichier test, Il suffit de cliquer ([x]) sur la permission voulue afinde l’attribuer au fichier et de cliquer à nouveau ([ ]) pour enlever une permission.

2.5.2 Interface de gestion du contrôle d’accès sur Windows

Dans les systèmes d’exploitation Microsoft Windows, la gestion du contrôle d’accès est réaliséegrâce à l’explorateur de fichier qui permet de gérer les droits d’accès et, moins connue, le MMC(Microsoft Management Console) [24] à travers son module utilisateurs et groupes locaux (Voirfigure 2.11 et 2.12).

En pratique, pour tous les objets Windows, il suffit d’afficher la fenêtre des propriétés etd’accéder à l’onglet sécurité pour visualiser et modifier les droits d’accès. La figure 2.13 et lafigure 2.14 montrent respectivement une représentation graphique des descripteurs de sécuritéet de l’interface de gestion des ACE du dossier Sample Pictures.

Étant donnée la popularité des OS Windows, les administrateurs peuvent, en utilisant l’inter-

48

Figure 2.11 – Console de gestion Microsoft.

Figure 2.12 – Utilisateurs et groupes locaux.

Figure 2.13 – Gestionnaire de sécurité Windows.

49

Figure 2.14 – Fenêtre d’édition des ACE.

face graphique, faire une gestion rigoureuse du contrôle d’accès. Et cela en utilisant l’explora-teur de fichier et l’application MMC de Microsoft.

2.6 Conclusion

Le contrôle d’accès est l’un des fondements de la sécurité informatique. Dans plusieurs entre-prises, la fonction principale des administrateurs en sécurité est de gérer l’accès aux ressources,sans oublier l’analyse de conformité et l’audit.Alors, il est capital de mettre l’accent sur l’analyse des besoins des administrateurs qui définitla problématique liée à la gestion du contrôle d’accès et également de bien cerner les différentsmodèles de contrôle d’accès et d’en déterminer le choix par rapport aux objectifs de sécurité.Bien que la notion d’interface personne-machine soit présente dans la structure des OS, onpeut faire le constat que pour la gestion du contrôle d’accès, l’aspect interface en ligne de com-mande est privilégié et qu’il faut avoir les compétences qu’il faut pour la gestion fine des droitsd’accès. Toutefois, la prise de conscience sur les enjeux de la sécurité informatique en généralet des données personnelles en particulier par le grand public pourra jouer sur l’améliorationdes interfaces graphiques pour la gestion des droits d’accès.

50

Chapitre 3

Contribution

3.1 Introduction

Dans ce chapitre, nous présentons AVTAC 1 qui est un framework dont l’un des modulespermet de faire l’analyse et la validation automatique des droits d’accès. En nous appuyantsur une ontologie [55] et des outils de approvisionnement, nous allons détailler l’architecturede notre outil et montrer les processus utilisés pour l’analyse de conformité.

3.2 Architecture et vue d’ensemble

AVTAC est constitué de plusieurs modules qui sont décrits ci-dessous :

• Outils de résolution des contraintes :

Une contrainte est une relation entre différentes variables. On distingue différents types decontraintes telles que : les contraintes numériques, booléennes, etc. La contrainte est utiliséepour résoudre les problèmes de non-satisfaction. On utilise la programmation par contrainteafin de résoudre les problèmes combinatoires et plus particulièrement les problèmes de grandetaille. Dans AVTAC [43], elle permet d’accélérer le traitement pour des opérations de rechercheet faciliter l’analyse et les interprétations.

• Outil de comparaison des politiques :

L’outil de comparaison de politique comme son nom l’indique si bien, est utilisé pour comparerdeux ou plusieurs politiques de sécurité. Cette opération de comparaison vise à analyser lesliens entre les politiques. L’objectif est d’amener des éléments de réponse de façon formelles

1. AVTAC : Automatic Validation Tools of Access Control

51

Figure 3.1 – Architecture du cadriciel AVTAC [43].

aux interrogations suivantes :En considérant deux politiques de sécurité exprimées en XACML P1 et P2.

— P1 est-il équivalent à P2 ?

— P1 est-il une extension de P2 ?

— P1 est-il une restriction de P2 ?

— P1 est-il divergent de P2 ?

• Outil de calcul de distance :

Mesurer la distance entre les politiques de sécurité définit la similarité ou la non-similaritéentre deux politiques. Afin de réduire la complexité des calculs de la similarité ainsi que letemps de traitements, l’utilisation de métriques demeure une solution.Il est important de savoir que toutes les mesures de similarité ne sont pas des métriques. Pourqu’elle soit une métrique, une mesure d doit satisfaire les 4 conditions suivantes :

— Positivité : d(x; y) ≥ 0.

— Identité : d(x; y) = 0⇔ x = y.

— Symétrie : d(x; y) = d(y;x).

52

— Inégalité triangulaire : d(x; z) ≤ d(x; y) + d(y; z).

• Outil d’analyseur de logs :

L’analyseur de logs permet de repérer et de faire une analyse prédictive des évènements mal-veillants sur le système. Il permet d’avoir les différents profils de comportements liés auxutilisateurs dans le but d’une meilleure optimisation des ressources allouées.

• Outil de validation d’accès :

Cet outil donne lieu à la vérification de la politique de sécurité implémentée dans le sys-tème. Elle permet donc d’assurer la conformité des droits d’accès par rapport à la politiquede sécurité. (Voir section 3.4)

• Extension :

L’extension de notre framework est un outil de classification qui a pour objectif de présenterdes critères de classification qui sont en relation avec le contrôle d’accès, le but étant d’aiderà l’agencement des rôles et des ressources de données.

L’outil AVTAC est une application développée en JAVA et FLEX doté de nombreux modulesjouant chacun un rôle important dans le fonctionnement de outil, nous nous intéresserons entreautres aux modules suivants :

— Outils d’approvisionnementLes outils d’approvisionnement ont pour fonction de collecter les différents objets quitraduisent un droit d’accès dans une plateforme donnée. C’est dans ce module que monétude de recherche vient contribuer à l’outil AVTAC. Ils permettent aussi d’établir unstandard quant à la représentation des différents droits d’accès en XACML qui est unlangage défini pour le contrôle d’accès.

— OntologieL’ontologie aide à établir une analyse des droits d’accès afin de vérifier le respect ou nond’une politique de sécurité donnée.

— Générateur de rapportLe générateur de rapport produit un fichier (.pdf) sur lequel sont mentionnés les accèsnon conformes à la politique de sécurité et fait une proposition corrective afin d’aider àla conformité.

53

Windows Objet Linux Objet Network Objet Software Objet

Traducteur XML

Linux Script Windows Script Routeur Script Appli Script Mac Script

Outil de provisioning

P1

Politique de sécurité stocker Ontologie instanciée

Moteur de validation des droits d’accès

Générateur de rapport

BD stockant la politique de

sécurité

et

Opérations

Architecture

Qui a accès à quoi? Pour la politique de sécurité donnée quels

sont les accès valides? Quel est le rôle pour un utilisateur donné?

Figure 3.2 – Architecture de l’outil de validation [54]

La démarche, comme illustrée dans la figure 3.2, consiste dans un premier temps, à collecterles objets qui expriment les droits d’accès dans les différentes plateformes informatiques pardes scripts adaptés à chaque système.Dans un deuxième temps, l’ontologie sera initialisée avec ces objets afin d’afficher les droitsd’accès valides et non valides selon une politique de sécurité donnée. Une série de requêtespeut être effectuée grâce au langage de requête de l’ontologie DL-query.Finalement, un rapport sera généré afin de permettre aux administrateurs de mieux appré-hender l’apport de solution pour les droits d’accès non valide.

3.3 Outils d’approvisionnement

Les outils d’approvisionnement alimentent le système de validation, ils ont pour fonction derécupérer les droits d’accès dans les différentes plateformes qui constituent le système infor-matique d’une organisation. Aussi, pour s’adapter à un environnement spécifique, les outilsd’approvisionnement se composent de plusieurs modules qui sont assignés soit à un systèmed’exploitation (Objet Linux), soit à un programme (Objet programme) ou à un équipementréseau (Objet réseau).

Dans le but d’améliorer la qualité de l’outil de validation, la représentation des droits d’accès

54

des différentes plateformes se doit d’être standardisée. À cet effet, on traduira les objets detype accès en XACML, car ce langage est très riche de par sa sémantique et donc facilite latraduction des objets. Aussi XACML permet aisément de représenter une politique de sécuritéet dans la pratique de cette traduction nous nous appuierons sur une grammaire BNF (VoirAnnexe A.3). Cette grammaire BNF a été spécifiée à l’aide d’une formalisation d’un sous-ensemble de XACML-3.0 et se compose d’éléments suivants :

— Un ensemble de politiques (PolicySet)

— Un PolicySet est constitué d’autres politiques (Policy) et de règles (Rules). Chaqueensemble de politiques obéit à un algorithme de combinaison (Ralg) qui décrit la façonde combiner les décisions de ses politiques.

— Une règle se compose d’une cible (Target), d’un effet (REffect), et d’une condition (At-tEnv). Une cible représente l’objet sur lequel la règle s’applique et l’effet quant à luitraduit la décision d’accès qui peut être Permit ou Deny.

Dans la section 3.5, nous allons explorer les détails de cette traduction.

3.3.1 Script d’extraction des droits d’accès Windows

La récupération des droits d’accès dans un environnement Windows est plus efficace via unscript vbs (Voir Annexe A.1.) Le script proposé ci-dessous permet de récupérer les droitsd’accès de l’ensemble des fichiers contenu dans le dossier "test1" afin de les consignés dans unfichier texte "fichier.txt" en sortie.

Comme indiqué dans la section 2.4 (contrôle d’accès sous Windows), une entrée de contrôled’accès (ACE) est la structure qui enregistre les permissions pour un compte de sécuritédonné et spécifie aussi les propriétés d’audit pour ce compte sur un objet. Ce script permetde parcourir un répertoire et ses sous-répertoires dans le but de lire les autorisations (masqued’accès) contenues dans les ACE. Il spécifie également :

— Le type de l’objet : Un dossier ou un fichier

— Le chemin d’accès de l’objet

— Le propriétaire de l’objet

— Le sujet (Utilisateurs ou groupe)

— La permission (accepté ou refusé)

— L’autorisation qui définit le droit d’accès à l’objet.

C’est le lieu de rappeler qu’il existe deux types d’autorisations dans une ACE :

— Des autorisations standards : lecture ; écriture ; affichage du contenu du dossier ; modi-fication ; contrôle total ; lecture et exécution.

— Des autorisations spécifiques : Parcours du dossier/exécution du fichier ; création dedossiers/ajout de données ; lecture des autorisations ; liste du dossier/lecture de don-

55

nées ; écriture d’attributs ; modification des autorisations ; lecture des attributs ; écri-ture d’attributs étendus ; appropriation ; lecture des attributs étendus ; suppression desous-dossiers et de fichiers ; synchronisation ; création de fichiers/écriture de données ;suppression.

Le résultat du script ci-dessus produit en sortie ce fichier txt tout en sachant que le dossiertest1 contient un seul fichier provisio.vbs.

File\Folder | Chemin\Nom | Owner | Sujet | permission | AutorisationF|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_ALL_ACCESSF|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_APPEND_DATAF|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_DELETEF|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_DELETE_CHILDF|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_EXECUTEF|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_READ_ATTRIBUTESF|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_READ_CONTROLF|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_READ_DATAF|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_READ_EAF|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_SYNCHRONIZEF|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_WRITE_ATTRIBUTESF|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_WRITE_DACF|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_WRITE_DATAF|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_WRITE_EAF|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_WRITE_OWNERF|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_ALL_ACCESSF|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_APPEND_DATAF|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_DELETEF|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_DELETE_CHILDF|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_EXECUTEF|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_READ_ATTRIBUTESF|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_READ_CONTROLF|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_READ_DATAF|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_READ_EAF|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_SYNCHRONIZEF|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_WRITE_ATTRIBUTESF|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_WRITE_DACF|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_WRITE_DATAF|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_WRITE_EAF|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_WRITE_OWNERF|C:\test1\provisio.vbs|emmanuel|Utilisateurs|Allowed|FILE_READ_ATTRIBUTESF|C:\test1\provisio.vbs|emmanuel|Utilisateurs|Allowed|FILE_READ_CONTROLF|C:\test1\provisio.vbs|emmanuel|Utilisateurs|Allowed|FILE_READ_DATAF|C:\test1\provisio.vbs|emmanuel|Utilisateurs|Allowed|FILE_READ_EAF|C:\test1\provisio.vbs|emmanuel|Utilisateurs|Allowed|FILE_SYNCHRONIZEF|C:\test1\provisio.vbs|emmanuel|Utilisateurs authentifiÈs|Allowed|FILE_ALL_ACCESS

56

F|C:\test1\provisio.vbs|emmanuel|Utilisateurs authentifiÈs|Allowed|FILE_APPEND_DATAF|C:\test1\provisio.vbs|emmanuel|Utilisateurs authentifiÈs|Allowed|FILE_DELETEF|C:\test1\provisio.vbs|emmanuel|Utilisateurs authentifiÈs|Allowed|FILE_EXECUTEF|C:\test1\provisio.vbs|emmanuel|Utilisateurs authentifiÈs|Allowed|FILE_READ_ATTRIBUTESF|C:\test1\provisio.vbs|emmanuel|Utilisateurs authentifiÈs|Allowed|FILE_READ_CONTROLF|C:\test1\provisio.vbs|emmanuel|Utilisateurs authentifiÈs|Allowed|FILE_READ_DATAF|C:\test1\provisio.vbs|emmanuel|Utilisateurs authentifiÈs|Allowed|FILE_READ_EAF|C:\test1\provisio.vbs|emmanuel|Utilisateurs authentifiÈs|Allowed|FILE_SYNCHRONIZEF|C:\test1\provisio.vbs|emmanuel|Utilisateurs authentifiÈs|Allowed|FILE_WRITE_ATTRIBUTESF|C:\test1\provisio.vbs|emmanuel|Utilisateurs authentifiÈs|Allowed|FILE_WRITE_DATAF|C:\test1\provisio.vbs|emmanuel|Utilisateurs authentifiÈs|Allowed|FILE_WRITE_EA

3.3.2 Script d’extraction des droits d’accès Linux

Dans Linux, nous avons fait le choix de récupérer les droits d’accès via un script bash. Le scriptproposé ci-dessous permet de récupérer les droits d’accès de l’ensemble des fichiers contenusdans le dossier Documents afin de les consignés dans un fichier texte portant le nom de ladistribution Linux "drsnake-debian._objet.txt".

Ainsi, nous avons le script suivant :

#!/bin/bashls -R -l $PWD/* >> /home/emmanuel/Documents/$HOSTNAME._objet.txt

Le résultat du script ci-dessus produit en sortie ce fichier txt tout en sachant que le dossierDocuments contient 4 fichiers et un dossier doc.

-rwxrw-rw- 1 emmanuel emmanuel 415 28 mar 2013 /home/emmanuel/Documents/scrip1-rw-r--r--. 1 emmanuel emmanuel 115 18 mai 2012 /home/emmanuel/Documents/scrip2-rw-r--r--. 1 emmanuel emmanuel 926 10 mai 2012 /home/emmanuel/Documents/tableau2-rw-r--r-- 1 emmanuel emmanuel 17 12 aoû 2014 /home/emmanuel/Documents/test

/home/emmanuel/Documents/doc:total 2-rw-r--r-- 1 emmanuel emmanuel 1912 6 mar 20:13 drsnake-debian._group.txt-rw-r--r-- 1 emmanuel emmanuel 3474 6 mar 20:13 drsnake-debian._user.txt

3.4 Processus de validation de droit d’accès

Le processus de validation des droits d’accès se subdivise en trois points à savoir :-l’instanciation de l’ontologie.

57

-La mise en œuvre de la politique de sécurité par des requêtes DL-query.-La sollicitation d’un raisonneur pour l’analyse de conformité.

• Instanciation de l’ontologie :

Avant d’aborder ce point, donnons une définition pratique d’une ontologie selon [55]. Uneontologie est une collection ordonnée des descriptions de classes, de propriétés et d’instances.Une classe représente un concept du domaine défini par l’ontologie. Une instance représenteun individu concret relevant de cette classe. Une propriété représente une relation qui exprimeun type d’interaction entre les classes.Dans ce point, il est question du peuplement (transfert de données) de l’ontologie par lesdonnées collectées via les outils d’approvisionnement. Cette opération est effectuée de façonautomatique grâce à l’API de gestion de l’ontologie.Effectivement, avec l’aide de parseurs XML, les droits d’accès sont respectivement assignésà leur classe vers les propriétés qui les déterminent. Ce processus pouvant être long, il estrecommandé de l’exécuter une fois et ensuite de déterminer seulement les instances qui ontété modifiées afin d’effectuer la mise à jour de l’ontologie.

• Mise en œuvre de la politique de sécurité :

La politique de sécurité d’une organisation est souvent décrite dans un document texte quiest perceptible des dirigeants et autres membres de l’organisation. Alors, il est essentiel detraduire ce document pour une utilisation informatique. Nonobstant l’établissement de plu-sieurs langages informatiques tels que XACML, qui donne lieu à la spécification de politiquesde sécurité, il est important de se servir de cette politique pour générer plusieurs requêtes DL-query afin d’interroger automatiquement l’ontologie. En réalité, les requêtes mises en œuvreservent à vérifier la validité ou non des droits d’accès.À titre d’exemple, prenons une politique de sécurité qui stipule que le groupe des administra-teurs ont accès qu’en lecture à un fichier PS.txt et que le root seul a le droit d’écriture sur lefichier PS.txt.Générons une requête DL-Querry pour déterminer tous les droits d’accès qui ne sont pasconformes à cette politique :

— les instances de l’ontologie sont :

? Action atomique : read, write, execute (pour lecture, écriture et exécution) ;

? Utilisateur : root ;

? Groupe : root ;

? Permission : accept, deny ;

58

? Rôle : néant ;

? Ressource : PS.txt ;

— Exécution de la commande ls -l pour afficher les droits d’accès du fichier PS.txt ;

# ls -l-rw-r--r-- 1 root root 0 20 dec. 9:49 PS.txt

— Traduction de la politique en une requête DL-Query :

Groupe has(root,ApourRole(Rolehas(,ApourPermission(Permisionhas(Access,PermissionSurRessource(Ressourcehas (PS.txt) ) and FaireAction (Action has (Read) )))and Permision.has(Deny,PermissionSurRessource (Ressource has(PS.txt)) and FaireAction (Actionhas(Execute) and Action has(Write))))))andUtilisateur has(root,ApourRole(Rolehas(,ApourPermission(Permissionhas(Access,PermissionSurRessource(Ressourcehas(PS.txt)) and FaireAction (Actionhas(Read) and Action has(Write))))and Permissionhas(Deny,PermissionSurResource (Ressourcehas(PS.txt)) andFaireAction (Action has(Execute))))))

Ainsi pour l’analyse de conformité entre la validité des droits d’accès et la politique desécurité, on aura comme résultat, les instances de la requête suivantes :

1. Un utilisateur root a le droit d’écriture.

2. Les autres utilisateurs ont le droit de lecture.

3. Aucun utilisateur n’a le droit d’exécution.

• Sollicitation d’un raisonneur

Le raisonneur permet de valider la cohérence des instances de l’ontologie et de concevoir tousles liens plausibles entre ces instances.

Une fois ces trois points accomplis, un rapport pdf est produit pour donner la liste des droitsd’accès valide et non valide. Nous verrons dans la section qui suit, une illustration pour nousaider à mieux cerner tout le processus de l’outil.

3.5 Traduction des droits d’accès

3.5.1 Traduction des droits d’accès Linux vers XACML

Sous Linux, la représentation des droits d’accès est affichée grâce à la commande ls -l.

59

Soit :

-rw-r--r-- 1 root emmanuel 0 15 Déc 14:34 test.txt

on peut extraire les droits d’accès suivant :

Utilisateur Actionpermise Actionnonpermiseroot rw x

emmanuel r wxany r wx

Dans l’utilisation de XACML pour la représentation des droits d’accès Linux, on va s’accordersur les règles suivantes :

• L’application de l’algorithme de combinaison first - applicable

• Chaque action permise et action non permise est traduite en une règle XACML avec commeattributs appropriés : subject, resource et action.

En appliquant ces règles à l’exemple ci-dessus, on obtient alors un fichier XACML (Voir AnnexeA.2.)

3.5.2 Traduction de droits d’accès Windows vers XACML

Sous Windows, le SDDL (Security descriptor definition langage) est le langage approprié pourdéfinir un format de chaîne de caractères dans le but de convertir le descripteur de sécurité entexte. Nous avons ainsi besoin de définir la syntaxe du langage SDDL grâce à une grammaireBNF, cela nous donne la table suivante :

En nous appuyons sur la syntaxe SDDL, on peut maintenant établir une corrélation entre leslangages SDDL et XACML.

Ces deux phases ayant été accomplies, on peut produire un exemple de traduction d’un droitd’accès Windows vers XACML.Soit le SDDL du fichier test.txt suivant :

- SDDL

0:S-1-5-21-718938447-1703640164-3469265397-1000G:S-1-5-21-718938447-1703640164-3469265397-513D:AI(D;;CC;;;\S-1-5-21-718938447-1703640164-3469265397-1001)(A;ID;FA;;;BA)

60

Security Descriptor : := Owner_SID ;Group_SID ; DACL

DACL : := Dacl-flag, ACEACE : := ACE Type ; ACE Flag ; Rights ; SID

DACL : := 〈ace :Ace〉ACE Type : := A | DACE Flag : := CI | OI | NP

IO | ID | SA | FARights : := GA | GR | GW | GX | ...

SID : := S-1-5-21domaine-500| S-1-1-0

DACL Flag : := P | AR | AI| AU | SY | ...

Owner_SID : := S-1-5-21domaine-500Group_SID : := BA | ...

Table 3.1 – SDDL Syntax [43].

Windows XACMLSecurity Descriptor ⇒ PoliciesACE ⇒ RulesRights, SID ⇒ TargetsACE :Type ⇒ Effect

Ralg =fisrt-applicable

Table 3.2 – Traduction de SDDL vers XACML [43].

En appliquant les règles de traduction de SDDL vers XACML, on obtient le document XACMLqui suit :

<POLICY first-applicable><TARGET><AnyOf><AllOf>

<Match MatchID = string-equal><AttrValue> text.txt < /AttrValue><AttributeDesignator Category= resource AttributeId= resource-id DataType= string MustBePresent= boolean />

</Match ></All0f> </AnyOf> </TARCET><RULE Permit><TARGET><AnyOf><All0f>

<Match MatchID = string-equal><AttrValue> 0:S-1-5-21-718938447-1703640164-3469265397-1000</AttrValue> <AttributeDesignator Category= Subject AttributeId =subject-id DataType= string MustBepresent= boolean />

61

</Match ></All0f></AnyOf></TARGET>

</RULE<RULE Deny><TARGET><AnyQf><AllOf>

<Match MatchID = string-equal><AttrValue> S-1-5-21-718938447-1703640164-3469265397-1001 </AttrValue><AttributeDesignator Category= Subject AttrtbuteId =subject-id DataType= string MustBepresent= boolean />

</Match ></All0f></AnyOf><AnyOf><AllOf><Match MatchID = string-equal><AttrValue> CC < /AttrValue><AttributeDesignator Category= action AttrtbuteId =action-id DataType= strtng MustBePresent= boolean />

</Match ></All0f> </AnyOf>

</TARGET></RULE><RULE Permit>

<TARGET><AnyOf><AllOf><Match MatchID = string-equal><AttrValue> BA < /AttrValue><AttributeDesignator Gategory = Subject AttributeID =subject-id DataType = string MustBePresent= boolean />

</Match ></All0f> </AnyOf><AnyOf><All0f><Match MatchID = string-equal>

<Attrvalue> FA < /AttrValue><AttributeDesignator Category= action AttributeId =action-id DataType= String MustBePresent= boolean /></Match>

</All0f> </AnyOf> </TARGET></RULE >

</POLICY >

3.5.3 Outil de validation

Comme le montre la figure 3.3, l’outil de validation se divise en plusieurs parties :

— Le Chargeur de fichier XACML (Get from File) permet de recueillir les droits d’accès à vérifierà partir d’un fichier XACML existant.

— L’outil de scan réseau (Get from Network) quant à lui permet de faire une découverte réseau et

62

déterminer les postes sur lesquels on peut collecter les droits d’accès. Ce processus fait égalementappel à la fonction d’extraction des outils d’approvisionnement.

— La liste des machines (Machine) dont les droits d’accès seront vérifiés.

— La liste des objets (Access list) à instancier dans l’ontologie.

— Les boutons de traitement pour commencer le processus de validation (Get access, Access-Validation, Xacml Policies Formal Validation).

Figure 3.3 – Capture 1 d’écran de l’outil de validation.

Cette première interface permet de faire l’instanciation de l’ontologie. Ensuite une fois complété, onaccède à l’interface de la figure 3.4 où va se faire la validation de la cohérence et les quelques opérationsliées à la comparaison de politiques de sécurité.

3.6 Récupération automatique des droits d’accès à partir dedifférentes machines

Dans le cadre de l’utilisation des outils de gestion des droits d’accès dans une architecture client-serveur,il nous faut impérativement un protocole de communication qui permettra d’extraire les droits d’accèssur des machines distantes (hôtes). Notre choix s’est porté sur le protocole SNMP 2 à cause de safiabilité, sa sécurité et son évolutivité qui permet l’utilisation d’une arborescence pour la gestion desvariables.SNMP permet le dialogue entre le superviseur et les agents (clients) afin de récupérer les objetssouhaités dans la MIB 3.

2. SNMP : Simple Network Management Protocol.3. MIB : Management Information Base.

63

Figure 3.4 – Capture 2 d’écran de l’outil de validation.

Une MIB est un ensemble d’informations structuré sur une entité réseau, par exemple un routeur, uncommutateur ou un serveur. Ces informations peuvent être récupérées ou modifiées par SNMP. [68]

La MIB possède une structure hiérarchisée : les informations sont rassemblées en arbre. Chacune desinformations possède un OID (object identifier) et un nom. (Voir figure 3.5)

Figure 3.5 – Structure d’une MIB.

Dans le cadre pratique de cette ébauche, avec SNMP comme support, nous avons élaboré un script

64

qui permet de récupérer les droits d’accès sur une machine distante Linux.(Voir Annexe A.4).

Ce script est écrit dans le langage de programmation python et est enregistré dans le fichier script.py.Il est à noter qu’avant d’exécuter ce script, l’outil pysnmp[69] doit être installé sur le serveur (machinequi émet la requête). La commande pour démarrer le serveur python se fait en ligne de commande(invité de commande) en précisant le chemin d’accès vers le fichier script.py. Ensuite, une fois le serveurpython démarré, nous exécutons la commande snmpwalk comme suit :

snmpwalk -v3 -u Manu -l authPriv -A ManuSPassword -x AES -X ManuSSecondPasswordlocalhost:2222 .1.4

snmpwalk est une commande Unix qui permet d’interroger une machine pourvue d’un agent SNMP àtravers le réseau.[70]La commande ci-dessus qui est associée au script script.py s’interprète de la façon suivante : Afficherles droits d’accès (ls -l) de la machine distante avec les paramètres suivants :

- Version de SNMP : V3 (version 3) ;- Nom de l’hôte : Manu ;- Le niveau de sécurité : authPriv ;- Le mot de passe d’authentification : ManuSPassword ;- Le protocole de chiffrement : AES (Advanced Encryption Standard) ;- Le mot de passe du chiffrement : ManuSSecondPassword ;- Port d’écoute : La connexion sur la machine distante se fait en utilisant le port 2222 ;- OID Mib : Une branche Mib est créée dynamiquement et porte l’OID 1.4 ;

Définitivement, notre script (script.py) permet de récupérer les droits d’accès d’une machine Linux(Manu), les accès étant sur une Mib qu’on a créée dynamiquement (class MibCryptoShare(MibScalarInstance)),en toute sécurité (authentification et chiffrement).

3.7 Conclusion

L’analyse de conformité est incontournable pour la prévention des failles de sécurité et des pertes finan-cières. De nos jours, les systèmes informatiques sont tellement évolutifs et variés que l’administrationmanuelle rend pratiquement impossible la gestion des droits d’accès. AVTAC, une solution d’automa-tisation informatique, assure la sécurité et garantit une bonne gestion automatique des droits d’accès.Les principales fonctionnalités de l’outil de validation consistent :

— À collecter les objets qui expriment les droits d’accès dans les différentes plateformes informa-tiques par des scripts adaptés à chaque système.

— À initialiser l’ontologie avec ces objets afin d’afficher les droits d’accès valides et non validesselon une politique de sécurité donnée.

— À générer un rapport afin de permettre aux administrateurs de mieux appréhender l’apport desolution pour les droits d’accès non valide.

65

Conclusion générale

Le cycle de vie des utilisateurs au sein d’une organisation et les processus qui y sont associés ont desconséquences directes sur leurs droits dans le système informatique.

Un système complet de gestion des identités doit ainsi donner une vue globale des habilitations et desaccès au SI. Il nous permet alors de maîtriser le risque opérationnel et de répondre aux contraintesréglementaires.Dans ce mémoire, nous avons d’une part fait une synthèse de l’état de l’art des différents outils ettechniques permettant la gestion des droits d’accès dans les réseaux informatiques et d’autre part dedévelopper des outils permettant de récupérer automatiquement ces droits d’accès et de les analyser.

Dans le chapitre 1, nous avons décrit de façon générale, les principes fondamentaux et les pratiquesliées à une bonne gestion des identités et des droits d’accès. Aussi à l’aide d’exemples, nous avons faitla synthèse de quelques outils de contrôle d’accès sans oublier de définir quelques normes de sécurité.

Une revue de littérature portant sur le contrôle d’accès sous Windows et Linux a été élaborée dans lechapitre 2. Ceci a permis de comprendre comment se fait la gestion du contrôle d’accès sur les systèmesd’exploitation les plus utilisés dans le monde de l’informatique.

Le chapitre 3 a été consacré à la présentation du framework AVTAC ainsi qu’au développement desoutils de provisioning pour une meilleure gestion automatique des droits d’accès, sans oublier le méca-nisme de validation de ceux-ci et l’outil développé avec SNMP qui permet de récupérer les objets surdes machines distantes Linux.

Perspective

En mettant en œuvre un framework à la place d’un outil ordinaire, on a ainsi permis à AVTAC decouvrir l’ensemble des aspects de la gestion des droits d’accès et de l’analyse de conformité. De plus,d’autres outils pourront être ajoutés pour enrichir notre framework, il s’agit entre autres :

— Des outils pour récupérer les objets de type accès dans certaines plateformes systèmes (Androïd,IOS, MacOS...), des équipements réseau (routeurs, switch, hub..) et aussi des bases de donnéesspécifiques.

— Des outils capables de récupérer les droits d’accès sur des machines distantes Windows.

67

Annexe A

Scripts et documents XACML

A.1 Script d’extraction des droits d’accès Windows

sub list_sub_folder (folder)For Each objFile In folder.Files

list_file_right(objFile)NextFor Each objSubFolder In folder.SubFolders

list_folder_right(objSubFolder)list_sub_folder(objSubFolder )

NextEnd sub

sub list_folder_right (folder)

strFolderName = folderSE_DACL_PRESENT = &h4ACCESS_ALLOWED_ACE_TYPE = &h0ACCESS_DENIED_ACE_TYPE = &h1

FILE_ALL_ACCESS = &h1f01ffFOLDER_ADD_SUBDIRECTORY = &h000004FILE_DELETE = &h010000FILE_DELETE_CHILD = &h000040FOLDER_TRAVERSE = &h000020FILE_READ_ATTRIBUTES = &h000080FILE_READ_CONTROL = &h020000FOLDER_LIST_DIRECTORY = &h000001FILE_READ_EA = &h000008

69

FILE_SYNCHRONIZE = &h100000FILE_WRITE_ATTRIBUTES = &h000100FILE_WRITE_DAC = &h040000FOLDER_ADD_FILE = &h000002FILE_WRITE_EA = &h000010FILE_WRITE_OWNER = &h080000

Set objWMIService = GetObject("winmgmts:")Set objFolderSecuritySettings = _objWMIService.Get("Win32_LogicalFileSecuritySetting=’" & strFolderName & "’")intRetVal = objFolderSecuritySettings.GetSecurityDescriptor(objSD)

intControlFlags = objSD.ControlFlags

If intControlFlags AND SE_DACL_PRESENT ThenarrACEs = objSD.DACLFor Each objACE in arrACEs

Allowed_Denied = ""If objACE.AceType = ACCESS_ALLOWED_ACE_TYPE Then

Allowed_Denied = "Allowed"ElseIf objACE.AceType = ACCESS_DENIED_ACE_TYPE Then

Allowed_Denied = "Denied"End IfIf objACE.AccessMask AND FILE_ALL_ACCESS Then

AccessType = "FILE_ALL_ACCESS"MonFic.Writeline "D"&"|"& folder&"|"& objSD.Owner.Name &"|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FOLDER_ADD_SUBDIRECTORY Then

AccessType = "FOLDER_ADD_SUBDIRECTORY"MonFic.Writeline "D"&"|"& folder&"|"& objSD.Owner.Name &"|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_DELETE Then

AccessType = "FILE_DELETE "MonFic.Writeline "D"&"|"& folder&"|"& objSD.Owner.Name &"|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_DELETE_CHILD Then

AccessType = "FILE_DELETE_CHILD "MonFic.Writeline "D"&"|"& folder&"|"& objSD.Owner.Name &"|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FOLDER_TRAVERSE Then

70

AccessType = " FOLDER_TRAVERSE "MonFic.Writeline "D"&"|"& folder&"|"& objSD.Owner.Name &"|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_READ_ATTRIBUTES Then

AccessType = "FILE_READ_ATTRIBUTES "MonFic.Writeline "D"&"|"& folder&"|"& objSD.Owner.Name &"|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_READ_CONTROL Then

AccessType = "FILE_READ_CONTROL "MonFic.Writeline "D"&"|"& folder&"|"& objSD.Owner.Name &"|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FOLDER_LIST_DIRECTORY Then

AccessType = " FOLDER_LIST_DIRECTORY "MonFic.Writeline "D"&"|"& folder&"|"& objSD.Owner.Name &"|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_READ_EA Then

AccessType = "FILE_READ_EA "MonFic.Writeline "D"&"|"& folder&"|"& objSD.Owner.Name &"|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_SYNCHRONIZE Then

AccessType = "FILE_SYNCHRONIZE "MonFic.Writeline "D"&"|"& folder&"|"& objSD.Owner.Name &"|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_WRITE_ATTRIBUTES Then

AccessType = "FILE_WRITE_ATTRIBUTES "MonFic.Writeline "D" &"|"& folder&"|"& objSD.Owner.Name &"|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_WRITE_DAC Then

AccessType = "FILE_WRITE_DAC "MonFic.Writeline "D" &"|"& folder&"|"& objSD.Owner.Name &"|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FOLDER_ADD_FILE Then

AccessType = " FOLDER_ADD_FILE "MonFic.Writeline "D" &"|"& folder&"|"& objSD.Owner.Name &"|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End If

71

If objACE.AccessMask AND FILE_WRITE_EA ThenAccessType = "FILE_WRITE_EA "MonFic.Writeline "D" &"|"& folder&"|"& objSD.Owner.Name &"|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_WRITE_OWNER Then

AccessType = "FILE_WRITE_OWNER "MonFic.Writeline "D" &"|"& folder&"|"& objSD.Owner.Name &"|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfNext

ElseWScript.Echo "No DACL present in security descriptor"

End If

end sub

sub list_file_right (file)

strFileName = fileSE_DACL_PRESENT = &h4ACCESS_ALLOWED_ACE_TYPE = &h0ACCESS_DENIED_ACE_TYPE = &h1

FILE_ALL_ACCESS = &h1f01ffFILE_APPEND_DATA = &h000004FILE_DELETE = &h010000FILE_DELETE_CHILD = &h000040FILE_EXECUTE = &h000020FILE_READ_ATTRIBUTES = &h000080FILE_READ_CONTROL = &h020000FILE_READ_DATA = &h000001FILE_READ_EA = &h000008FILE_SYNCHRONIZE = &h100000FILE_WRITE_ATTRIBUTES = &h000100FILE_WRITE_DAC = &h040000FILE_WRITE_DATA = &h000002FILE_WRITE_EA = &h000010FILE_WRITE_OWNER = &h080000

Set objWMIService = GetObject("winmgmts:")Set objFileSecuritySettings = _objWMIService.Get("Win32_LogicalFileSecuritySetting=’" & strFileName & "’")intRetVal = objFileSecuritySettings.GetSecurityDescriptor(objSD)

72

intControlFlags = objSD.ControlFlags

If intControlFlags AND SE_DACL_PRESENT ThenarrACEs = objSD.DACLFor Each objACE in arrACEs

Allowed_Denied = ""If objACE.AceType = ACCESS_ALLOWED_ACE_TYPE Then

Allowed_Denied = "Allowed"ElseIf objACE.AceType = ACCESS_DENIED_ACE_TYPE Then

Allowed_Denied = "Denied:"End IfIf objACE.AccessMask AND FILE_ALL_ACCESS Then

AccessType = "FILE_ALL_ACCESS "MonFic.Writeline "F" & "|" & file & "|" & objSD.Owner.Name &"|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_APPEND_DATA Then

AccessType = "FILE_APPEND_DATA "MonFic.Writeline "F" & "|" & file & "|" & objSD.Owner.Name & "|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_DELETE Then

AccessType = "FILE_DELETE "MonFic.Writeline "F" & "|" & file & "|" & objSD.Owner.Name & "|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_DELETE_CHILD Then

AccessType = "FILE_DELETE_CHILD "MonFic.Writeline "F" & "|" & file & "|" & objSD.Owner.Name & "|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_EXECUTE Then

AccessType = "FILE_EXECUTE "MonFic.Writeline "F" & "|" & file & "|" & objSD.Owner.Name & "|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_READ_ATTRIBUTES Then

AccessType = "FILE_READ_ATTRIBUTES "MonFic.Writeline "F" & "|" & file & "|" & objSD.Owner.Name & "|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_READ_CONTROL Then

AccessType = "FILE_READ_CONTROL "

73

MonFic.Writeline "F" & "|" & file & "|" & objSD.Owner.Name & "|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_READ_DATA Then

AccessType = "FILE_READ_DATA "MonFic.Writeline "F" & "|" & file & "|" & objSD.Owner.Name & "|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_READ_EA Then

AccessType = "FILE_READ_EA "MonFic.Writeline "F" & "|" & file & "|" & objSD.Owner.Name & "|" &objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_SYNCHRONIZE Then

AccessType = "FILE_SYNCHRONIZE "MonFic.Writeline "F" & "|" & file & "|" & objSD.Owner.Name & "|" &objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_WRITE_ATTRIBUTES Then

AccessType = "FILE_WRITE_ATTRIBUTES "MonFic.Writeline "F" & "|" & file & "|" & objSD.Owner.Name & "|" &objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_WRITE_DAC Then

AccessType = "FILE_WRITE_DAC "MonFic.Writeline "F" & "|" & file & "|" & objSD.Owner.Name & "|" &objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_WRITE_DATA Then

AccessType = "FILE_WRITE_DATA "MonFic.Writeline "F" & "|" & file & "|" & objSD.Owner.Name & "|" &objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_WRITE_EA Then

AccessType = "FILE_WRITE_EA "MonFic.Writeline "F" & "|" & file & "|" & objSD.Owner.Name & "|" &objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfIf objACE.AccessMask AND FILE_WRITE_OWNER Then

AccessType = "FILE_WRITE_OWNER "MonFic.Writeline "F" & "|" & file & "|" & objSD.Owner.Name & "|" &objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType

End IfNext

74

ElseWScript.Echo "No DACL present in security descriptor"

End If

end sub

’Pour créer le fichier texteSet FSys = CreateObject("Scripting.FileSystemObject")Set MonFic = FSys.CreateTextFile("C:\Users\emmanuel\Desktop\manu\test.txt")MonFic.Writeline "File\Folder | Chemin\Nom | Owner | Sujet | permission | Autorisation "

Set objFso = CreateObject("Scripting.FileSystemObject")Set objMyFolder = objFso.GetFolder("C:\Users\emmanuel\Desktop\manu")list_sub_folder objMyFolder

A.2 Traduction des droits d’accès Linux vers XACML

<POLICY first-applicable><TARGET><AnyOf><AllOf>

<Match MatchID = string-equal><AttrValue> test.txt < /AttrValue><AttributeDesignator Category= resource AttributeId= resource-id DataType= string MustBePresent= boolean />

</Match ></All0f> </AnyOf> </TARCET><RULE Deny>

<TARGET><AnyOf><All0f><Match MatchID = string-equal>

<AttrValue> root < /AttrValue><AttributeDesignator Category= Subject AttributeId =subject-id DataType= string MustBepresent= boolean />

</Match ></All0f></AnyOf><AnyOf><A110f><Match MatchID = string-equal>

<AttrValue> x < /AttrValue><AttributeDesignator Category= action AttributeId =action-id DataType= string MustBePresent= boolean />

</Match ></All0f> </AnyOf>

</TARCET></RULE ><RULE Permit>

75

<TARGET><AnyOf><All0f><Match MatchID = string-equal>

<AttrValue> root < /AttrValue><AttributeDesignator Category= Subject AttributeId =subject-id DataType= string MustBePresent= boolean />

</Match ></All0f> </AnyOf><AnyOf><All0f>

<Match MatchID = stzing-equal><AttrValue> r < /AttrValue>

<AttributeDesignator Category= action AttributeId =action-id DataType= string MustBePresent= boolean />

</Match ></AllOf><All0f>

<Match MatchID = string-equal><AttrValue> w < /AttrValue>

<AttributeDesignator Category= action AttributeId =action-id DataType= string MustBePresent= boolean /></Match >

</All0f> </AnyOf> </TARGET></RULE ><RULE Deny>

<TARGET><AnyOf><All0f><Match MatchID = string-equal>

<AttrValue> emmanuel < /AttrValue><AttributeDesignator Category= Subject AttributeId =group-id DataType= strang MustBePresent= boolean />

</Match ></All0f> </AnyOf>

<AnyOf><All0f><Match MatchID = string-equal><AttrValue> x < /AttrValue><AttributeDesignator Category= action AttributeId =action-id DataType= string MustBePresent= boolean /></Match > </All0f>

<Allof><Match MatchID = string-equal><AttrValue> w < /AttrValue><AttributeDesignator Category= actaon AttributeId =action-id DataType= string MustBePresent= boolean />

</Match ></All0f> </AnyOf> </TARGET>

</RULE >

76

<RULE Permit><TARGET><AnyOf><All0f>

<Match MatchID = string-equal><AttrValue> emmanuel < /AttrValue>

<AttributeDesignator Category= Subject AttributeId =group-id DataType= string MustBePresent= boolean /></Match >

</All0f> </AnyOf><AnyOf><AllOf>

<Match MatchID = string-equal><AttrValue> r < /AttrValue><AttributeDesignator Category= action AttributeId =action-id DataType= string MustBePresent= boolean />

</Match ></AllOf> </AnyOf> </TARGET>

</RULE ><RULE Deny>

<TARGET><AnyOf><AllOf><Match MatchID = string-equal><AttrValue> x < /AttrValue><AttributeDesignator Categor/= action AttributeId =action-id DataType= string MustBePresent= boolean />

</Match > </AllOf><AllOf><Match MatchID = string-equal><AttrValue> w < /AttrValue><AtrributeDesignator Category= action AttributeId =action-id DataType=string MustBePresent= boolean />

</Match ></AllOf> </AnyOf> </TARGET>

</RULE ><RULE Permit><TARGET><AnyOf><AllOf>

<Match MatchID = string-equal><AttrValue> r < /AttrValue><AttributeDesignator Category= action AttributeId =action-id DataType= string MustBePresent= boolean />

</Match > </AllOf></AllOf> </AnyOf> </TARGET>

</RULE ></POLICY >

A.3 Grammaire BNF pour un sous-ensemble de XACML 3.0

77

78

A.4 Script d’extraction des droits d’accès Linux via SNMP

# -*- coding: utf-8 -*-"""Created on Mon Mar 31 19:51:36 2014@author: Manu

"""

import subprocessfrom twisted.internet import reactorfrom pysnmp.entity import engine, configfrom pysnmp.entity.rfc3413 import cmdrsp, contextfrom pysnmp.carrier.twisted.dgram import udpfrom pysnmp.carrier.twisted import dispatchfrom pysnmp.proto.api import v2cfrom pysnmp import debug

# Create SNMP engine with autogenernated engineID and pre-bound

# to socket transport dispatcher

snmpEngine = engine.SnmpEngine()

snmpContext = context.SnmpContext(snmpEngine)

# --- create custom Managed Object Instance ---

mibBuilder = snmpContext.getMibInstrum().getMibBuilder()

MibScalar, MibScalarInstance = mibBuilder.importSymbols(

’SNMPv2-SMI’, ’MibScalar’, ’MibScalarInstance’)

class User:

def __init__(self, username, auth, enc, securitylevel, authProtocol, encProtocol):

self.username=username

self.auth=auth

self.enc=enc

79

self.securitylevel=securitylevel

self.authProtocol=authProtocol

self.encProtocol=encProtocol

class ACL:

MODE_RW, MODE_RO = range(2)

def __init__(self, user=’’, mode=MODE_RO):

self.user = user

self.mode = mode

class MibCryptoShare(MibScalarInstance):

def __init__(self, banner):

self.value = subprocess.check_output(["ls","-l"]);

self.scalar = MibDefaultScalar((1,4))

MibScalarInstance.__init__(self, (1,4), (0,), v2c.OctetString())

def getValue(self, name, idx):

return self.getSyntax().clone(self.value)

class MibDefaultScalar(MibScalar):

def __init__(self, oid):

self.oid=oid

MibScalar.__init__(self, self.oid, v2c.OctetString())

80

user_max = User(username=’Manu’,

auth=’ManuSPassword’,

enc=’ManuSSecondPassword’,

securitylevel=’authPriv’,

authProtocol=config.usmHMACMD5AuthProtocol,

encProtocol=config.usmAesCfb128Protocol)

acl_max = ACL(user_max, ACL.MODE_RW)

crypto = MibCryptoShare("CryptoShare Test for SNMP Protocol")

mibBuilder.exportSymbols(

’DOCUMENT_MIB’, MibScalar((1,4), v2c.OctetString()), crypto)

# Instantiate and register Twisted dispatcher at SNMP engine

snmpEngine.registerTransportDispatcher(dispatch.TwistedDispatcher())

# UDP over IPv4

config.addSocketTransport(

snmpEngine,

udp.domainName,

udp.UdpTwistedTransport().openServerMode((’127.0.0.1’, 2222))

81

)

config.addV3User(

snmpEngine, user_max.username,

user_max.authProtocol, user_max.auth,

user_max.encProtocol, user_max.enc

)

config.addVacmUser(snmpEngine, 3, user_max.username, user_max.securitylevel,

(1,4), (1,4))

# Get default SNMP context this SNMP engine serves

snmpContext = context.SnmpContext(snmpEngine)

# Register SNMP Applications at the SNMP engine for particular SNMP context

cmdrsp.GetCommandResponder(snmpEngine, snmpContext)

cmdrsp.SetCommandResponder(snmpEngine, snmpContext)

cmdrsp.NextCommandResponder(snmpEngine, snmpContext)

cmdrsp.BulkCommandResponder(snmpEngine, snmpContext)

# Run Twisted main loop

print "Manu’s server started!";

reactor.run();

82

Bibliographie

[1] T. Moses and S. Godik. “eXtensible Access Control Markup Language (XACML)”. Ver-sion 2.0, Feb. 2005 “http ://docs.oasis-open.org/xacml/access_control-xacml-2.0-core-spec-cd-01.pdf”

[2] M. Jaume & C. Morisset. “Un Cadre sémantique pour le contrôle d’accès.”. TSI (Tech-nique et Science Informatiques), pages 951-976, 2008.

[3] A. Kalam & Y. Deswarte. “un modèle de contrôle d’accès basé sur les organisations.”.Cahiers francophones de la recherche en sécurité de l’information Numéro II, 1er trimestre2003, pages 30-43, Projet MP6, 2003.

[4] J. Rushby. “The Bell and La Padula Security Model”. Computer Science Laboratory, SRIInternational, Menlo Park, CA, Draft Technical Note. 1986.

[5] F. Giunchiglia ; R. Zhang ; B.Crispo ; “RelBAC : Relation Based Access Control,” Se-mantics, Knowledge and Grid, 2008. SKG ’08. Fourth International Conference on , vol., no.,pp.3,11, 3-5 Dec. 2008.

[6] J. Ma ; K. Adi ; M. Mejri ; L. Logrippo, “Risk analysis in access control systems,”Privacy Se-curity and Trust (PST), 2010 Eighth Annual International Conference on , vol., no., pp.160,166,17-19 Aug. 2010.

[8] E. Bertino ; A. Bonatti ; E. Ferrari, “Trbac : A temporal role-based access control mo-del.”. ACM Trans. Inf. Syst. Secur. 4, 3 (2001), 191–233.

[9] A. Grunbacher “Posix access control lists on linux.”In USENIX Annual Technical Confe-rence, FREENIX Track, USENIX (2003), 259–272.

[10] J. Anderruthy Registre Windows Vista : architecture, administration, script, réparation, :personnalisation, optimis. Editions ENI, 2007.

[11] Access control entries. “http ://technet.microsoft.com/en-us/library/cc961995.aspx.”

[12] How AccessCheck Works (windows).“http ://msdn.microsoft.com/en-us/library/windows/desktop/aa446683(v=vs.85).aspx.”

83

[13] E. Dreux La sécurité sous Windows Vista Editions ENI, 2009.

[14] C. BLAESS, Shells linux et unix par la pratique. Editions Eyrolles, 2007.

[15] G. Lapointe ; S. Bray, Automating Sharepoint 2010 with Windows Powershell 2.0. JohnWiley Sons, 2011.

[16] Métaphore du bureau. “http ://fr.wikipedia.org/wiki/Environnement_de_bureau”

[17] M. Anwari, GNOME 3 Application Development Beginner’s Guide Packt Publishing Ltd,2013.

[18] D. Powell ; R. Bernstein,Practical KDE. Que Corp., 1999.

[19] L. Groupe, Lxde : Debian, Knoppix, Mandriva Linux, Fedora, Frugalware, Arch Linux,Lubuntu, Slitaz Gnulinux, U-Lite General Books LLC, 2010.

[20] XFCE, X. Desktop environment. URL : http ://www. xfce.org.

[21] Gnu midnight commander. URL : https ://www.midnight-commander.org

[22] Dolphin file manager. URL : https ://www.kde.org/applications/system/dolphin/.

[23] Selinux gui overview. URL : http ://pandeyarpit.wordpress.com/selinux-anintroduction/selinux-gui-overview/.

[24]Microsoft management console. URL : http ://technet.microsoft.com/fr-fr/library/bb742441.aspx.

[25] Dossier technique Gestion des identites CLUSIF, 63 pages, 2007.

[26] E. Bertino ; K. Takahashi, Identity Management : Concepts, Technologies, and Systems.Artech House, 2011.

[27] S. Cantor ; I. Moreh ; S. Philpott ; E. Maler, “Metadata for the OASIS Security AssertionMarkup Language (SAML) V2.0.” 2005.

[28] D. F. Ferrailo ; D. R. Kuhn ; and R. Chandramouli, Role-Based Access Control. April2003.

84

[29] N. Debaes ; P. Pezziardi ; B. Vincent, 2007In Gestion des identités : une politique pour lesystème d’information, Octo Technology, 214 pages.

[30] CA IdentityMinder. URL : https ://support.ca.com/cadocs

[31] OpenIDM. URL : https ://wikis.forgerock.org/confluence/display/openidm/Home

[32] Activiti . URL : http ://activiti.org

[33] Repository. URL : http ://fr.wikipedia.org/wiki/Dépôt_(informatique)

[34] http ://www.cgi.com/sites/default/files/white-papers/gestion_de_l_identite.pdf

[35] Linux Posix . URL https ://fr.wikipedia.org/wiki/Access_Control_List#Sous_UNIX.

[36] Le bit setgid . URL : http ://guidalinux.altervista.org/suselinux-manual_fr-10.1-10/cha.acls.html

[38] ACL . URL : http ://users.suse.com/ãgruen/acl/linux-acls/online/

[39] SE Linux. https ://www.nsa.gov/research/selinux/

[40] SE Linux. URL : http ://debian-handbook.info/browse/fr-FR/stable/sect.selinux.html

[41] SE Linux . URL : http ://www.selinuxproject.org/page/Main_Page

[42] midPoint . URL : https ://www.evolveum.com/midpoint/

[43] M. Mejri ; A. Khadija and E. Sadio A Framework for Automatic Auditing of AccessControl in Windows and Linux Systems/. (2013).

[44] B. Lampson. Protection and access control in operating systems. In Operating Systems,Infotech State of the Art Report 14, 1972, pp 309-326, 1972.

[45] A. Harrison ; W. Ruzzo and J. Ullman. Protection in operating systems. Commun. ACM,19(8) :461471, 1976.

[46] S. Sandhu. The typed access matrix model. In Proc. IEEE Symposium on Research inSecurity and Privacy, pages 122-136, 1992.

85

[47] G. Martella ; P. Samarati ; S. Castano ; M. G. Fugini, Database Security. Addison-WesleyACM Press, 1995.

[48] D. E. Bell ; L. J. La Padula. Secure computer system : Unifed exposition and multicsinterpretation. Proc. IEEE Computer Society Symposium on Research in Security and Pri-vacy, pp. 215-228., March 1976.

[49] D. Brewer and M. Nash. The chinese wall security policy. Proc. IEEE Computer So-ciety Symposium on Research in Security and Privacy, pp. 215-228., April 1989.

[50] E. Bertino ; J. W. Byun ; Y. Sohn. Systematic control and management of data inte-grity. Proceedings of the eleventh ACM symposium on Access control models and technologies,June 2006.

[51] DAC . URL : http ://fr.wikipedia.org/wiki/Contrôle_d’accès_discrétionnaire

[52] HRU . URL : http ://fr.wikipedia.org/wiki/Modèle_HRU

[52] C. Dima. Introduction à la sécurité. URL : http ://lacl.u-pec.fr/dima/securite/secu3.pdf

[53]Operating System - Linux. URL : http ://www.tutorialspoint.com/operating_system/os_linux.htm

[54] Ontologie : https ://fr.wikipedia.org/wiki/Ontologie_(informatique)

[55] B. Bennett ; C. Fellbaum, 2006Formal Ontology in Information Systems : Proceedingsof the Fourth International Conference, IOS Press, 373 pages.

[56] A. Kalam ; P. Balbiani ; S. Benferhat ; F. Cuppens ; Y. Deswarte ; C. Saurel, “OrBAC”.IEEE 4th International Workshop on Policies for Distributed Systems and Networks, IEEEComputer Society Press, Como, Italy, 4-6 June 2003, pp. 120-131.

[57] T. Fink, M. Koch, C. Oancea. “Specification and Enforcement of Access Control in Hetero-geneous Distributed Applications”.International Conference on Web Services (ICWS- Europe),2003, pp. 88-100.

[58] R. K. Thomas, R. S. Sandhu, “Task-based Authorization Controls (TBAC) : A Familyof Models for Active and Enterprise-oriented Authorization Management”.Proceedings of theIFIP WG11.3 Workshop on Database Security, August 1997, pp. 166-181.

86

[59] J. Ma ; K. Adi ; M. Mejri & L. Logrippo, (2010, August). Risk analysis in access controlsystems. In Privacy security and trust (PST), 2010 Eighth annual international conference on(pp. 160-166).

[60] N. Debaes & B. Vincent (2007). Gestion des identités : une politique pour le systèmed’information. OCTO Technology.

[61]Objectifs de la propagation d’identités : https ://fr.wikipedia.org/wiki/Shibboleth_(fédération_d%27identité)

[62] Liberty Alliance : https ://fr.wikipedia.org/wiki/Liberty_Alliance

[63] ISO/CEI 27001 : https ://fr.wikipedia.org/wiki/ISO/CEI_27001

[64] CobiT : https ://fr.wikipedia.org/wiki/CobiT

[65] Information Technology Infrastructure Library : https ://fr.wikipedia.org/wiki/Information_Technology_Infrastructure_Library

[66] ISO/CEI 27002 : https ://fr.wikipedia.org/wiki/ISO/CEI_27002

[67] ISO/IEC 27002 :2013 Information technology — Security techniques — Code of practicefor information security controls (second edition) : http ://www.iso27001security.com/html/27002.html#Section9

[68]Management information base : https ://fr.wikipedia.org/wiki/Management_information_base

[69] PySNMP : http ://pysnmp.sourceforge.net/contents.html

[70] snmpwalk : http ://pysnmp.sourceforge.net/contents.html

[71] ISO/IEC 27001 :2013 Information technology — Security techniques — Information se-curity management systems - Requirements

87