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

informatiques

Mémoire

MEMEL EMMANUEL LATHE

Maîtrise en informatique
Maî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 entreprise
privée comme publique. Le contrôle d’accès, qui représente une composante importante de la
sécurité des systèmes d’information, consiste à vérifier si un sujet possède les droits nécessaires
pour accéder à un objet [43]. Il est régi par des règles qui peuvent être exprimées en différents
langages. 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érentes
et complètes par rapport à une politique de sécurité donnée. Plusieurs outils de contrôle d’accès
sont applicables à cette fin. AVTAC (Automatic Validation Tool of Access Control) est un outil
sur 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 consists
on verifying whether a subject has the rights to access to an object. It is governed by rules that
can be expressed in different languages. Validation of access control also called compliance is
to check at regular intervals if the access control implemented rules are consistent and complete
with respect to a given security policy or not. Several access control tools are applicable to
this end. AVTAC (Automatic Validation Tool of Access Control) is the tool on which we made
our 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 3

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Authentification pour un système IAM . . . . . . . . . . . . . . . . . . . . . 4
1.3 Modèle d’habilitation pour un système IAM . . . . . . . . . . . . . . . . . . 8
1.4 Implémentation et contrôle pour un système IAM . . . . . . . . . . . . . . . 11
1.5 Outils de gestion des droits d’accès . . . . . . . . . . . . . . . . . . . . . . . 14
1.6 Normes et référentiels de sécurité . . . . . . . . . . . . . . . . . . . . . . . . 18
1.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2 Représentation des droits d’accès sous Windows et Linux 27

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2 Contrôle d’accès : définitions et politiques . . . . . . . . . . . . . . . . . . . 28
2.3 Contrôle d’accès sous Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.4 Contrôle d’accès sous Windows . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.5 Représentation graphique du contrôle d’accès . . . . . . . . . . . . . . . . . 46
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3 Contribution 51
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2 Architecture et vue d’ensemble . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3 Outils d’approvisionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.4 Processus de validation de droit d’accès . . . . . . . . . . . . . . . . . . . . 57
3.5 Traduction des droits d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.6 Récupération automatique des droits d’accès à partir de différentes machines 63
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

vi
Conclusion générale 67

A Scripts et documents XACML 69

A.1 Script d’extraction des droits d’accès Windows . . . . . . . . . . . . . . . . 69
A.2 Traduction des droits d’accès Linux vers XACML . . . . . . . . . . . . . . . 75
A.3 Grammaire BNF pour un sous-ensemble de XACML 3.0 . . . . . . . . . . . 77
A.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]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.2 Masquage des autorisations d’accès. . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1 SDDL Syntax [43]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.2 Traduction de SDDL vers XACML [43]. . . . . . . . . . . . . . . . . . . . . . . 61

ix
Liste des figures

1.1 Processus de synchronisation [60]. . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2 midPoint[31]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3 Architecture OpenIDM [31]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4 ITIL version 3 [65]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.1 Concepts de base pour le contrôle d’accès dans Linux . . . . . . . . . . . . . . . 30

2.2 Droit d’accès Linux : Exemple. . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3 ACL minimale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4 ACL étendue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.5 ACE de type accès accordé [13]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.6 ACE de type accès refusé [13]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.7 Structure d’un descripteur de sécurité [13]. . . . . . . . . . . . . . . . . . . . . . 45
2.8 Language SDDL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.9 Architecture Linux [53]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.10 GMC gestion des droits d’accès [21]. . . . . . . . . . . . . . . . . . . . . . . . . 48
2.11 Console de gestion Microsoft. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.12 Utilisateurs et groupes locaux. . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.13 Gestionnaire de sécurité Windows. . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.14 Fenêtre d’édition des ACE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.1 Architecture du cadriciel AVTAC [43]. . . . . . . . . . . . . . . . . . . . . . . . 52

3.2 Architecture de l’outil de validation [54] . . . . . . . . . . . . . . . . . . . . . . 54
3.3 Capture 1 d’écran de l’outil de validation. . . . . . . . . . . . . . . . . . . . . . 63
3.4 Capture 2 d’écran de l’outil de validation. . . . . . . . . . . . . . . . . . . . . . 64
3.5 Structure d’une MIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

xi
Remerciements

À mon Dieu
Que 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 enfants

Vous qui m’avez toujours soutenu, merci de me faire confiance et d’être pour moi une source
de motivation.

À mon père spirituel

Merci prophète de Dieu pour la source de bénédiction que tu es pour moi, l’Université Laval
est aujourd’hui une réalité grâce à toi.

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

À mon directeur de recherche, Dr Mohamed Mejri

Je tiens à vous dire merci pour votre motivation et votre patience dans l’élaboration de ce
projet de maîtrise. Je vous suis très reconnaissant d’avoir accepté de superviser ce travail.

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

À mes frères et sœurs

Je dis merci à tous ceux qui m’ont soutenu durant mes études, plus particulièrement à la famille
Gandonou, 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èmes
d’information, consiste à vérifier si un sujet demandant l’accès à un objet possède les droits
nécessaires pour le faire. Il est régi par des règles qui peuvent être exprimées dans un langage
tel 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 les
implé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 est
réellement implanté dans le système n’est pas toujours respectée. Par ailleurs, la complexité de
cette tâche d’analyse de conformité augmente considérablement quand nos systèmes (incluant
les équipements et les données qu’on protège, les personnes qui donnent les droits d’accès
et les personnes à qui l’on donne les droits d’accès) ou nos politiques de sécurité changent
constamment.
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 personnes
qui 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 ce

processus. En d’autres termes, il faut développer des outils qui sont capables d’aller chercher
régulièrement et automatiquement les droits d’accès attribués aux différents utilisateurs pour
les 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 techniques
permettant 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 des
diffé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 automatiquement
une 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 droits
d’accès sous Windows et Linux . Dans le chapitre 3, nous présentons notre contribution dans
l’élaboration de l’outil AVTAC. Finalement au chapitre 4, nous terminons par une conclusion
générale.

2
Chapitre 1

État de l’art des outils de contrôle

d’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éation
et de mise en œuvre de politiques de contrôle d’accès sont avérés ; cependant cette solution
informatique 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és
organisationnelles (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 grandes
menaces, 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 de
sécurité de l’organisation, spécifie les attendus pour les quatre thèmes principaux de la gestion
d’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 de
nous acclimater avec les notions et la modélisation utilisées dans un processus de gestion des
identités et des droits d’accès. Il a aussi pour objectif de nous orienter à faire de bon choix
afin 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. Cette
justification est faite par un moyen d’authentification qui se base sur des composants de
diffé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 de
l’œil, etc.

Plusieurs services peuvent être mis en place pour faciliter l’authentification, mais celui qui
attirera notre attention et qui est le service d’authentification le plus mis en œuvre pour un
projet 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 sont
dans l’obligation d’accéder à plusieurs applications pour l’envoi de leurs courriels, la gestion
du support informatique, la gestion des fichiers de tout type.
À cause des exigences toujours plus rigoureuses en matière de sécurité, les utilisateurs doivent
entrer 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 afin
d’assurer la sécurité du réseau, par exemple par l’utilisation de mots de passe forts, la durée
de vie maximale du mot de passe, durée de vie minimale du mot de passe et conservation
d’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, sachant
que 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 la
base des paramètres de connexion authentifiés.

Avantages de l’authentification unique

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

• 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éseau
de l’entreprise. En effet elle donne lieu à une bonne gestion des droits accès, seuls les
utilisateurs 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 les
demandes 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’assistance
technique à ce sujet.
• Une optimisation du niveau de service
Attendu que le centre d’assistance technique est moins sollicité pour ce qui concerne la
gestion de réinitialisation, ses collaborateurs peuvent donc se focaliser sur le soutien des
usagers 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 des
employé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 devoir
reproduire cette action pour chacune des applications.

— L’authentification unique permet de produire un rapport sur le temps exact (date

et 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 de
doter 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 signaler
quelques inconvénients :

— Au niveau de la compatibilité, l’authentification unique a bien souvent des limites avec

plusieurs 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 de
faç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 associer
les solutions de l’authentification unique à d’autres facteurs d’authentification comme
les 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 un
problème (indisponibilité, dysfonctionnement, etc.) celui-ci empêche alors tout le système
d’information de fonctionner. Pour pallier ce problème, le recours a des serveurs secours
peut être envisagé.

Les composants du SSO

Un système d’authentification unique est composé d’au moins trois « segments », ces segments
spécifient des fonctionnalités qui donnent lieu à la mise en place de l’authentification. Ces trois
segments 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 capable
d’échanger avec l’agent d’authentification.
• L’agent d’authentification :
L’agent d’authentification est la jonction entre les applications et le serveur SSO. Sa
fonction est de vérifier que l’employé est authentifié. En cas d’échec de ce processus de
vé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 choix
doit être fonction d’une bonne vue d’ensemble du système d’information visé. En effet ce choix
est très conditionné par les normes de confiance établies entre plusieurs entités à fédérer au
sein du système d’authentification unique. Les architectures se subdivisent en deux modèles
que voici :

• Le modèle centralisé
La règle fondamentale ici est d’avoir soit un système de stockage de données (BD 4 ) de
tous les utilisateurs ou un annuaire. Cela donne lieu aussi à la centralisation de la gestion
de la politique de sécurité et des droits d’accès. On compte parmi les logiciels qui illustre
ce procédé, LemonLDAP.
Ce modèle est particulièrement désigné à des services qui appartiennent tous à une
même entité. Par exemple au sein d’une entreprise, la gestion des intergiciels est fondée
sur le modèle centralisé. En effet chaque entité (service) interdépendante a confiance
dans 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 à une
multitude 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 de
nuage), etc., avec un seul compte et une seule authentification.

• Le modèle fédératif
Dans 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’origine
de l’utilisateur et obtenir certains attributs de l’utilisateur (pour gérer le contrôle d’accès ou personnaliser les
contenus).[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 de
dé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 dont
il 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ôle
de leur propre politique de sécurité.
À titre d’exemple, considérons un partenariat commercial qui met en œuvre deux sites
web. 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 par
contre, des informations telles que son login et son courriel sont partagées dans le but
de 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 distingue
deux 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 ou

MAC 7 )

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

Dans un système IAM et dans la majorité des entreprises, le principal modèle d’habilitation
utilisé est RBAC 8 . Ce modèle repose sur la définition de rôles (ou profils) qui établissent le lien
en matière d’habilitation entre les utilisateurs et les ressources du SI. Nous nous intéresserons
donc 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, les
droits d’accès sont attribués à un rôle et si ce rôle est joint à un utilisateur ou à des groupes
d’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-entreprise
qu’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érentes
qui dépendent du lieu géographique où il exerce (Ex. : un conseiller qui travaille dans plusieurs
agences 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 notions
abstraites, et aussi de pouvoir distinguer la représentation d’une politique de sécurité de son
implémentation en utilisant différents processus de contrôle d’accès. OrBAC définit la notion
d’ « organisation » et spécifie les sujets, les objets et les actions respectivement en rôle (comme
dans 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 est
attribué à 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 aussi
de contexte et la définit comme étant une situation particulière qui détermine si une règle est
valide 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 forme
P ermission|P rohibition|Obligation(org; r; v; a; c), où org est une organisation, r un
rô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écrit
la 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épendamment
des règles spécifiées dans la politique. Pour illustrer formellement l’instanciation des règles de
sécurité, considérons l’expression suivante :
∀org ∈ Org, ∀s ∈ S, ∀α ∈ A, ∀o ∈ O, ∀r ∈ R, ∀a ∈ A, ∀v ∈ V, ∀c ∈ C,
P ermission(Org, r, v, a, c) ∧ Empower(org, s, r) ∧ Consider(org, α, a)∧
U se(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 le
contexte ‘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 aussi
de 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 et
de délégation, il s’agit du Risk-RBAC [59], qui est une évolution du modèle RBAC.
Le modèle RBAC R 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 CN F (u) : U → C et
pour tous les rôles on calcule le niveau minimum de confiance noté M LC(R) : R → C.
La valeur du risque attribué à un utilisateur u qui a un rôle R, noté rv(u, R), est compris
entre 0 et 1.
Ce calcul s’effectue de la façon suivante :

(
0, si CN F (u) ≥ M LC(R)
rv(u, R) = CN F (u)
1− M LC(R) , sinon

Comme spécifié plus haut, il est question également dans cet article de notion de délégation
et 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 son
rôle à u2 .
Ce calcul s’effectue de la façon suivante :

(
0, si CN F (u1 ) ≥ CN F (u2 )
del_rv(u, R) = CN F (u1 )
1− CN F (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’entreprise
est importante afin de garantir la validité des identités, des habilitations et des accès. Une
surcharge d’habilitation, l’utilisation de comptes utilisateurs désuets, la non-résiliation des
droits dans les systèmes de gestion d’accès sont une partie des risques traités par la gestion
du cycle de vie des identités. La mise en œuvre des processus métiers, et leur automatisation
assure à l’entreprise un bon contrôle des identités et une meilleure gestion des accès au sein
de l’entreprise. Pour ce faire nous allons définir les différents processus et techniques utilisés
par un système IAM afin de garantir une bonne gestion des identités, des habilitations et des
accè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ésions

et les écarts avec le modèle d’habilitations, la gestion des identités et des droits d’accès doit
se baser sur des processus d’approvisionnement automatique.

Alimenter chaque référentiel de façon manuelle et indépendamment est source d’erreurs, et

rend complexe la mise en place d’une politique de sécurité. Ce procédé représente également
une perte de temps et de productivité pour une entreprise.

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

Selon [42], l’objectif de l’approvisionnement dans un système IAM est d’interagir avec les
ressources 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 des
ressources 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ésignent
toutes les entités liées à la gestion de l’identité, en particulier les comptes, les groupes, les
rô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ès
consiste dans l’interaction de plusieurs applications. Pour relever ce défi dans le monde des
IAM, deux techniques sont souvent utilisés et demeurent incontournables de nos jours. Ce
sont : la réconciliation et la synchronisation.

Réconciliation

La réconciliation est le processus de synchronisation bidirectionnelle des objets entre différents

base de données et référentiels (LDAP, BD relationnelle) [33]. Elle s’applique principalement
aux objets utilisateurs, aux groupes et aux rôles. Pour effectuer la réconciliation, un outil
IAM analyse à la fois les systèmes sources et cibles afin de découvrir les différences qu’il faut
concilier. 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és
de 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 au
moteur 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ègles
statiques.

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 gestion
des identités et des accès. Le processus d’octroi de privilèges d’accès fournit un outil puissant
qui 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 aux
ressources 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 workflow
simple, 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 le
gestionnaire 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 gestionnaire
afin d’envoyer une notification par courrier électronique au gestionnaire approprié. Lorsque
le 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 de
l’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. Bon
nombre d’entre elles sont assignées à un environnement spécifique, et n’ont pas toujours les
mê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 par
la compagnie CA Technologies. Il fournit la capacité de gérer et de gouverner les identités des
utilisateurs et comme tout bon outil de gestion de droits d’accès répond à la question "Qui
a accès à quoi ?". D’une façon aisée et productive, CA IdentityMinder permet également de
gérer et de gouverner les outils nécessaires afin de prendre le contrôle des utilisateurs privilégiés
dans 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 du
temps son offre de gestion IAM, en rachetant la compagnie ID Focus en octobre 2008 et
Eurikify quelque temps après.

1.5.2 SetACL Studio

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

1.5.3 midPoint

midPoint [31] est un système d’approvisionnement d’identités . Le provisionning d’identités

est un sous champ de l’identité et de gestion des accès (IAM). Un logiciel de provisionnig
prend 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 un
nouvel 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 et
des 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, cependant
midPoint 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 de
services 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ème
informatique.
- IBM Security Access Manager for Enterprise Single Sign-On quant à elle utilise les fonctions
SSO 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’autorisation
des 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-section
1.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 rachats
on 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 gagner
en 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 dans
le monde de l’open source. LinID est principalement utilisé dans l’environnement Windows
où 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 en
Java. OpenIDM exploite JavaScript comme langage de script par défaut pour définir les règles
d’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 aux
organisations d’automatiser la gestion du cycle de vie de l’identité de l’utilisateur en temps
ré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é avec
les politiques et les exigences réglementaires à travers l’entreprise, cloud, les environnements
sociaux 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 le
contrôle des accès et l’administration des identités et améliore, en plus, la vérification de
conformité 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 qui
possèdent des droits d’accès inadaptés. Quest One Identity permet d’effectuer une découverte
approfondie 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 directory
de Windows.

1.5.8 Varonis Datadvantage

Varonis donne lieu à la gestion de permissions de fichier Windows, toutefois sa spécificité se
situe au niveau des alertes. En effet, Varonis permet de recevoir des alertes en temps réel sur
toute modification faite aux fichiers ou aux dossiers contenus dans les systèmes de fichiers
Windows et périphériques NAS 11 . Les administrateurs sont prévenus de tous changements
apporté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 fonctions
communes cependant, chacun d’eux se démarque par une spécificité propre à chaque outil. Ce
tableau est une illustration de certains critères que nous avons établis pour les outils cités plus
haut.

11. NAS : Network Attached Storage.

17
 Contrôle SSO Gestion SNMP Audits Script Gestion
d’accès des mots d’alertes
de passe
OpenIDM • • • • •
CA • • • •
Identity-
Minder
SetACL • • • • • •
studio
midPoint • • • • •
IBM • • • • •
Security
Identity
and
Access
Assu-
rance
Varonis • • • • • •
Datad-
vantage
Quest • • • • •
One
Identity
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 œuvre
par les gestionnaires de sécurité qui, alerté par un processus de sécurité (alerte, scan, plainte
utilisateur), s’appuie en général sur les résultats des fichiers logs. Vu cette façon de gérer
l’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 le
respect 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 à mettre
en œuvre sans l’utilisation de normes et de référentiels de sécurité. En effet, ces référentiels
garantissent une bonne cohérence des processus ainsi que de bonnes pratiques au sein de
l’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 pour
le 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 aux
entreprises. Cette norme propose plusieurs mesures de sécurité sur le plan organisationnel et
technique.

En 2005, deux normes sont éditées :

la norme ISO/CEI 17799, qui modifie les domaines et objectifs, et la norme ISO/CEI 27001
qui introduit la notion de Système de Management de la Sécurité de l’Information (SMSI). La
norme ISO 17799 se voit remplacer en 2007 par la norme ISO 27002, qui a été mise à jour en
2013, 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 de
procé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 de
conformité :
— 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 orientation

et un soutien de la part de la direction, conformément aux exigences métier et aux lois et
règlements en vigueur. Pour ce faire une mesure et des préconisations de mise en œuvre
sont définies dans cette norme pour chaque chapitre.
La mesure dans ce chapitre, recommande de définir un ensemble de politiques en matière de
sécurité de l’information qui soit approuvé par la direction diffusé et communiqué aux salariés
et aux tiers concernés.
La mise en œuvre préconisée des politiques de sécurité de l’information, traitent des exigences
créé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 orienter
toutes 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 moyens
de traitement de l’information.
La mesure dans ce chapitre, recommande d’établir, de documenter et de revoir une politique
du 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ôle
d’accès, des droits d’accès et des restrictions d’accès appropriés aux fonctions spécifiques de
l’utilisateur des actifs, avec la quantité de détails et la rigueur des mesures correspondant aux
risques 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 exigences
de 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ît
tous 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 et
appliqué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 et
indé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édures
et 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 revues
indé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 dans
un premier temps, que les responsables déterminent la manière de vérifier que les exigences
de sécurité de l’information définies dans les politiques, les normes et autres règlementations
applicables, 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ères
efficaces.
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 sur
la manière de construire, procéder, entretenir et optimiser un Système de Management de la
Sécurité de l’Information (SMSI) dans l’intention de maintenir la sécurité de l’information au
sein de l’entreprise. Pour ce faire, la norme ISO 27001 utilise une approche d’amélioration
continue 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 choix
des mesures de sécurité à mettre en place.
— DO : Ce stade permet d’établir un plan de traitement des risques afin que les objectifs du
SMSI 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 actions
correctives et préventives sont ainsi élaborées.

Nous allons maintenant voir selon [71], les sections qui sont en rapport avec l’analyse de
conformité 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 les
atteindre.
Dans la norme iso 27001 :2013, il est dit que l’organisation doit établir, aux fonctions et
niveaux 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 de
l’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 elle
consiste à 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és
afin de recueillir des informations permettant de déterminer si le système de management de la
sécurité de l’information est conforme aux exigences propres de l’organisation et aux exigences
de 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 les
gestionnaires, auditeurs et utilisateurs qui aide à évaluer les risques et à déterminer le niveau
de contrôle afin de mieux protéger l’organisation. En effet, COBIT est un référentiel pour la
gouvernance et l’audit des Systèmes d’Information développé par l’ISACA 12 . COBIT adopte
une approche orientée processus qui consiste à décomposer tout Système d’Information en 34
processus regroupés en 4 domaines. Ces domaines sont entre autres :

— Planification et Organisation : l’objectif principal définit un plan stratégique pour le

Système d’Information basé sur l’efficacité, l’architecture et la stratégie technologique
tout en tenant compte de la gestion de son investissement. Ce domaine comprend ce
qui concerne l’organisation du Système d’Information et ses relations avec la direction
quant à sa stratégie et le métier de l’entreprise. De plus, tout principe d’organisation
implique 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 processus
d’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écrits

dans 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 de

l’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’Information
dans 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 (Figure
1.4), ITIL est une bibliothèque qui dénombre, résume et expose les meilleures pratiques pour
un service informatique.
Au nombre de ces pratiques, on peut citer :

— La stratégie des services (service strategy) qui définit les processus comme la gestion
financiè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 service
de test et validation.

— L’exploitation des services (service operation) qui prend en charge les processus comme
la 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 à une
bonne gestion des identités et des droits d’accès. Nous avons également défini les différents
processus et techniques utilisés par un système IAM afin de garantir une bonne gestion des
identité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’aider
les 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 est
question de la représentation des droits d’accès sous Windows et Linux.

25
Chapitre 2

Représentation des droits d’accès sous

Windows et Linux

2.1 Introduction

La sécurisation des systèmes informatiques est un domaine ouvert uniquement à un certain

nombre 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é, la
confidentialité, 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ôle
d’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 le
faire. 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 des
infrastructures informatique, que dans la vie de tous les jours. Prenons le cas d’une personne
qui veut retirer de l’argent au guichet automatique, le contrôle d’accès se définit ici par le faite
de 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ème
de contrôle d’accès en s’appuyant sur des modèles comme le MAC 1 , DAC 2 , RBAC 3 , etc. Un
modèle de contrôle d’accès est la mise en œuvre d’une méthode définissant des règles pour la
ré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ès
sous Linux et Windows, et finalement dans la section 4 nous représenterons quelques interfaces
utilisateurs 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écouvre
une 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 qui
exécutent les actions dans le système.
— l’ensemble O des objets, aussi appelé "entités passives", qui supporte les actions. Les
sujets et les objets sont en général jugés aussi bien que des entités atomiques. Parmi
plusieurs modèles, on fait allusion au terme utilisateur plutôt qu’ objet. Ces deux termes
ne sont pas forcément distincts : par exemple, un processus peut parallèlement être un
utilisateur parce qu’il exécute des opérations et un objet, dans l’option où un deuxième
processus 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 sujets
sur 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 le
sujet 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 mieux
exprimer 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 de

l’ensemble des accès, à savoir tous les accès admis, mais dont le processus reste inachevé. On
note 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 sont
modifiables lors des phases de transitions, à l’encontre des paramètres de sécurité, qui sont
dé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’ensemble
des 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és
par 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 de
sé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 les
systè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. Le
restant des utilisateurs appelés Others sont considérés dans la définition des droits d’accès sur
un 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 le
seul à 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 qui
appartiennent à 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 trois
caractères traduit les droits d’accès du Owner Group et la troisième entité de caractères indique
les droits donnés au Others . (Voir Figure 2.1). Dès lors on parvient à trois entités de trois
caractè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 objet
s’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 le
pré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 indique
que la nature du fichier est un dossier, tandis que le caractère − quant à lui nous indique
que 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 que
le Owner a les droits de lecture, d’écriture et de "traversée"(c’est-à-dire qu’on peut voir les
sous-dossiers que le dossier contient) ; le Owner Group et le Others ont le droit de lecture et
de "traversée". Sous Linux, les droits d’accès sont modifiables le Owner où le root en utilisant
la 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 le
chemin 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 droits
du 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 le
fichier /etc/passwd.
setuid est un attribut de fichier spécial qui indique au système d’exécuter certains programmes
sous 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 niveau
des droits du groupe. Un exécutable affecté par le bit setgid peut donc être déclenché avec les
droits du groupe auquel il se rapporte.
En revanche, le comportement change lorsqu’il s’agit d’un répertoire. Quand il s’agit d’un
répertoire, tous les fichiers créés dans ce répertoire appartiennent au même groupe que le
ré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 cette
maniè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 dossier
backup 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 à un
fichier ou à un répertoire. S’il est assigné à un fichier, alors le fichier en question est chargé dans
la 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 supprimer
leurs 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 demeure
possible 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 point
chacun leurs propres améliorations, souvent très semblables les unes aux autres, des travaux
laborieux 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ère
du standard POSIX [35]. Elles sont employées comme une avancée de la notion traditionnelle
d’autorisation pour les objets système de fichiers. Les ACL donnent lieu à la mise en œuvre
des 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) sous
Linux. Ces entités englobent les autorisations lire (r), écrire (w) et exécuter (x) pour chacun
des trois types d’utilisateurs : le Owner, le group et les others. Par ailleurs, il est possible de
dé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 administrateurs
système jadis étaient obligés d’adopter plusieurs moyens pour contourner les limitations du
concept d’autorisation traditionnel.

32
Les ACL sont perçues comme une avancée de la notion traditionnelle d’autorisation d’accès
aux 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 groupe
propriétaire. Les listes de contrôle d’accès sont une fonctionnalité du Kernel Linux et sont
actuellement 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èles
d’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 les
autorisations de l’utilisateur propriétaire de l’objet. L’entrée groupe propriétaire spécifie les
autorisations 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 ou
chgrp. À ce moment-là, les entrées du propriétaire et du groupe propriétaire font allusion au
nouveau propriétaire et au nouveau groupe propriétaire.
Chacune des entrées (utilisateur nommé) spécifie les autorisations de l’utilisateur défini dans
le champ de qualification de l’entrée. Uniquement les entrées d’utilisateur nommé et de groupe
nommé 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 Textuelle

propriétaire user : :rwx
utilisateur nommé user :name :rwx
groupe propriétaire group : :rwx
groupe nommé group :name :rwx
masque mask : :rwx
autre other : :rwx

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

L’entrée masque, a pour rôle de restreindre les autorisations accordées par les entrées utilisateur
nommé, groupe nommé et groupe propriétaire en spécifiant, parmi ces entrées, les autorisations
qui 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 seulement
dans l’entrée en question ne sont pas en cours, et ne sont pas accordées. L’ensemble des
autorisations définies dans les entrées propriétaire et groupe propriétaire sont constamment en
cours. L’exemple du Tableau 2.2 explique ce processus.

33
 Type d’entrée Forme textuelle Autorisations
utilisateurs nommé user :emma :r-x r-x
masque 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 fichiers
et les répertoires.

Figure 2.3 – ACL minimale.

— Une ACL étendue est beaucoup plus développée. Elle inclus une entrée masque et peut
renfermer 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 de
fichiers (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 ces
commandes est présentée dans l’exemplaire suivant.

Exemple : Avant de créer le répertoire LSI, utilisons la commande umask pour spécifier les
autorisations 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étaire
tous les droits (0), en refusant au groupe le droit d’écrire (2) et en n’accordant aucun droit
aux autres utilisateurs (7). En réalité,umask masque les bits d’autorisation correspondants ou
les 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: avtac
user::rwx
group::r-x
other::---

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 ne
gé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’utilisateur
additionnel 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 qui
désigne les entrées ACL à modifier. La partie restante indique le nom du répertoire dans lequel
ces 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::rwx
user:emmanuel:rwx group::r-x
group:labo:rwx mask::rwx
other::---

En plus des entrées lancées pour l’utilisateur emmanuel et le groupe labo, une entrée mask
a été générée. Cette entrée de masque est spécifiée automatiquement afin que tous les droits
entrent en vigueur.
setfacl dispose automatiquement les entrées mask aux nouveaux paramètres sauf si nous
désactivions cette fonctionnalité avec -n.
mask détermine le maximum de droits d’accès en vigueur pour toutes les entrées de la classe
de groupe.
Les bits d’autorisation de la classe de groupe indiqué par la commande "ls -dl LSI" conviennent
maintenant à 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 une
ACL étendue.

Dépendamment du résultat de la commande ls, les droits de l’entrée de masque comprennent

l’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 vigueur
du groupe propriétaire coïncide à la partie commune avec les droits spécifiés pour le groupe
proprié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: avtac
user::rwx

36
user:emmanuel:rwx # effective: r-x
group::r-x
group:labo:rwx # effective: r-x
mask::r-x
other::---

Une fois la commande chmod exécutée, pour supprimer le droit écrire des bits de la classe de
groupe, 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 les
entrées dans lesquelles les bits d’autorisation en vigueur ne coïncident pas aux autorisations
d’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éfaut
s’appliquent uniquement aux répertoires et déterminent les autorisations qu’un objet Système
de 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 fichiers
et 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 par
dé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 cas
où le répertoire parent ne possède pas une ACL par défaut, les bits d’autorisation définis par
umask sont retranchés des droits remis par le paramètre mode, le résultat étant attribué au
nouvel objet.
En admettant que le répertoire parent dispose d’une ACL par défaut, les bits d’autorisation
attribués au nouvel objet se rapportent à la partie commune des autorisations du paramètre
mode et à celles spécifiées dans l’ACL par défaut. umask n’est pas pris en compte dans cette
circonstance.

Les exemples ci-après représentent les opérations essentielles des répertoires et des ACL par
dé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: avtac
user::rwx
user:emmanuel:rwx
group::r-x
group:labo:rwx
mask::rwx
other::---
default:user::rwx
default:group::r-x
default:group:labo:r-x
default:mask::r-x
default:other::---

getfacl retourne l’ACL d’accès et l’ACL par défaut. L’ACL par défaut est composée de toutes
les lignes débutant par default. Quoique nous ayons uniquement exécuté la commande setfacl
avec 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 fonctionnelles
seulement 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 un
sous-répertoire sousLSI qui hérite de l’ACL par défaut.

mkdir LSI/sousLSI

getfacl LSI/sousLSI

# file: LSI/sousLSI
# owner: memel
# group: avtac
user::rwx
group::r-x

38
group:labo:r-x
mask::r-x
other::---
default:user::rwx
default:group::r-x
default:group:labo:r-x
default:mask::r-x
default:other::---

Bien entendu, le nouveau répertoire sousLSI a les droits de l’ACL par défaut du répertoire
parent. L’ACL d’accès de sousLSI est la réplique exacte de l’ACL par défaut de LSI. L’ACL
par 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, en

l’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: avtac
user::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 sont
crées. La création des fichiers se fait donc avec les droits lire et écrire pour toutes les classes
d’utilisateurs, pourvu qu’il n’existe pas une restriction en plus dans umask ou dans l’ACL par
dé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ès
restreint 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 des
informations classifiées [39]. La sécurité du MAC est différente de celle du DAC à cause de
la politique de sécurité qui y est administrée de manière centrale, et aussi que les utilisateurs
n’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 dans
les 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 module
SELinux, qui examine la politique de sécurité de façon à déterminer si l’opération en cours
peut continuer. La politique de sécurité SELinux est loadée depuis la plateforme utilisateur, et
est modifiable pour faire face à plusieurs objectifs de sécurité. Beaucoup de modèles de MAC
passé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 OS
basé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 et
les 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 une

plateforme SELinux est :
aptitude install selinux-basics selinux-policy-default.

Le package selinux-policy-default comprend plusieurs de règles de base. Naturellement, ces

règles limitent les accès que pour quelques services mis en évidence. Les sessions utilisateur
n’étant pas limitées, il n’y a par conséquent peu de chance que SELinux empêche les opérations
admissibles des utilisateurs. Par contre, ceci donne lieu à un apport de surplus de sécurité pour
les 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 un
type.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 traces
SELinux 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çon
basique 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 de
configuration du chargeur d’amorçage GRUB 8 afin de compléter les paramètres souhaités. De
façon pratique il faut modifier le paramètre GRUB_CMDLINE_LINUX qui se trouve
dans /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 a
pour fonction de définir les rôles de l’utilisateur. Ces deux corrélations à savoir de l’utilisateur
vers l’identité SELinux et de l’identité vers les rôles s’établissent à l’aide de la commande
semanage.

À cette commande on pourra associer différents arguments entre autres : -a pour ajouter, -d
pour 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 la
corré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.c1023

rhertzog user_u None
root unconfined_u s0-s0:c0.c1023
system_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 un
ajout d’une nouvelle identité exige de spécifier d’un côté les rôles correspondants et d’un autre
un préfixe d’étiquetage qui va définir le type affecté aux fichiers (/home/utilisateur/* ). Le
choix 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 commande
qui 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_r

staff_u staff s0 s0-s0:c0.c1023 staff_r sysadm_r
sysadm_u sysadm s0 s0-s0:c0.c1023 sysadm_r
system_u user s0 s0-s0:c0.c1023 system_r
test_u staff s0 s0 staff_r user_r
unconfined_u unconfined s0 s0-s0:c0.c1023 system_r unconfined_r
user_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ès
sous Windows.

Objets

Un Objet est un composant sécurisable et protégeable par des permissions. Il peut se

matérialiser par un fichier, un répertoire, une clé de registre, un socket, un processus, un
thread, etc. Microsoft ne fournit pas un standard d’outils pour gérer les permissions sur
tous les objets. La plupart du temps, c’est au développeur d’administrer ses permissions
par 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 concerne
les 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 pour
un compte de sécurité donné et spécifie aussi les propriétés d’audit pour ce compte sur
l’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 permissions
attribuées au SID et un drapeau ou flag qui définit le type d’ACE (ACE de type accès
accordé, 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 objet

sécurisable qui inclus le SID du propriétaire de l’objet, son groupe primaire, et les deux
types 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 dans
un descripteur de sécurité au format texte. Ce langage permet entre autres d’écrire des
scripts ou d’automatiser l’application de sécurités sur un ensemble de données à partir
d’un fichier d’entrée au format texte.
Ainsi, la commande sc sdshow présente le descripteur de sécurité d’un service au format
SDDL.
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 le

contrôle d’accès. De façon classique, les systèmes Windows exploitent les listes de contrôle
d’accès discrétionnaire (DACL) pour consolider le contrôle des droits d’accès sur ces différents
objets (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 de
l’identifier de façon unique.

Lorsque le bit (masque) d’une ACE qui traduit la permission écrire a la valeur 1 et que l’ACE
est 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é alors
l’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ès
suivant [12] :
— les droits standards comme DELETE qui traduit le droit de supprimer un objet, WRITE_DAC
qui traduit le droit de modifier le DACL, et WRITE_OWNER qui traduit le droit de
changer le propriétaire de l’objet.
— les droits génériques à l’instar de GENERIC_READ, GENERIC_WRITE, GENERIC_EXECUTE
et GENERIC_ALL ;
Même si le propriétaire d’un objet n’a pas une entrée dans le DACL, il peut, de manière
implicite, 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 un
DACL 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 comme Windows, la notion d’interface homme-
machine est une entité fondamentale de leur architecture. En effet un système d’exploitation
se 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 est
le 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. On
parle 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 console
dans 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 versions
antérieures à Windows Vista et à partir de cette dernière, un autre outil c’est ajouter à CMD
il 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 est
tiré 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] et
KDE [18] qui sont les plus répandus et les gestionnaires de bureau allégé comme Lxde [19] et
Xfce [20]. En général, les distributeurs d’OS Linux offrent la possibilité de choisir un type de
gestionnaire de bureau à l’installation.

Pour le contrôle d’accès, les OS Linux et Windows offrent des interfaces graphiques pour
faciliter 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 ou
KDE, le contrôle d’accès sur les objets de type fichier et dossier est réalisé et est paramétrable
grâce à l’outil GNU Midnight Commander (GMC) [21] sur GNOME et KDE File Manager
sur KDE [22]. Pour montrer la gestion graphique du contrôle d’accès sous Linux, nous avons
fait 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 qui
décrivent les droits d’accès au fichier test, Il suffit de cliquer ([x]) sur la permission voulue afin
de 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ée
grâ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 (Voir
figure 2.11 et 2.12).

En pratique, pour tous les objets Windows, il suffit d’afficher la fenêtre des propriétés et
d’accéder à l’onglet sécurité pour visualiser et modifier les droits d’accès. La figure 2.13 et la
figure 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éfinit
la problématique liée à la gestion du contrôle d’accès et également de bien cerner les différents
modè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, on
peut 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 droits
d’accès. Toutefois, la prise de conscience sur les enjeux de la sécurité informatique en général
et des données personnelles en particulier par le grand public pourra jouer sur l’amélioration
des 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 modules
permet de faire l’analyse et la validation automatique des droits d’accès. En nous appuyant
sur une ontologie [55] et des outils de approvisionnement, nous allons détailler l’architecture
de 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 de
contraintes telles que : les contraintes numériques, booléennes, etc. La contrainte est utilisée
pour résoudre les problèmes de non-satisfaction. On utilise la programmation par contrainte
afin de résoudre les problèmes combinatoires et plus particulièrement les problèmes de grande
taille. Dans AVTAC [43], elle permet d’accélérer le traitement pour des opérations de recherche
et 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 comparer
deux ou plusieurs politiques de sécurité. Cette opération de comparaison vise à analyser les
liens 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 le
temps 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. Pour
qu’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 aux
utilisateurs 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 politique
de sécurité. (Voir section 3.4)

• Extension :

L’extension de notre framework est un outil de classification qui a pour objectif de présenter
des 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 modules
jouant chacun un rôle important dans le fonctionnement de outil, nous nous intéresserons entre
autres aux modules suivants :

— Outils d’approvisionnement
Les outils d’approvisionnement ont pour fonction de collecter les différents objets qui
traduisent 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 un
standard quant à la représentation des différents droits d’accès en XACML qui est un
langage défini pour le contrôle d’accès.
— Ontologie
L’ontologie aide à établir une analyse des droits d’accès afin de vérifier le respect ou non
d’une politique de sécurité donnée.
— Générateur de rapport
Le générateur de rapport produit un fichier (.pdf) sur lequel sont mentionnés les accès
non conformes à la politique de sécurité et fait une proposition corrective afin d’aider à
la conformité.

53
 Architecture
Générateur de rapport
Moteur de validation des droits d’accès
Politique de sécurité stocker Ontologie instanciée Opérations

 Qui a accès à quoi?

BD stockant la  Pour la politique de sécurité donnée quels
politique de P1 et
sont les accès valides?
sécurité
 Quel est le rôle pour un utilisateur donné?

Outil de provisioning
Traducteur XML

Linux Script Windows Script Routeur Script Appli Script Mac Script

Windows Objet Linux Objet Network Objet Software Objet

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, à collecter
les objets qui expriment les droits d’accès dans les différentes plateformes informatiques par
des scripts adaptés à chaque système.
Dans un deuxième temps, l’ontologie sera initialisée avec ces objets afin d’afficher les droits
d’accès valides et non valides selon une politique de sécurité donnée. Une série de requêtes
peut ê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 de
ré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 outils
d’approvisionnement se composent de plusieurs modules qui sont assignés soit à un système
d’exploitation (Objet Linux), soit à un programme (Objet programme) ou à un équipement
ré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 de
type accès en XACML, car ce langage est très riche de par sa sémantique et donc facilite la
traduction 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 (Voir
Annexe 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). Chaque
ensemble de politiques obéit à un algorithme de combinaison (Ralg) qui décrit la façon
de 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 à lui
traduit 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 un
script vbs (Voir Annexe A.1.) Le script proposé ci-dessous permet de récupérer les droits
d’accès de l’ensemble des fichiers contenu dans le dossier "test1 " afin de les consignés dans un
fichier texte "fichier.txt" en sortie.

Comme indiqué dans la section 2.4 (contrôle d’accès sous Windows), une entrée de contrôle
d’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 permet
de parcourir un répertoire et ses sous-répertoires dans le but de lire les autorisations (masque
d’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 de
dossiers/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 de
sous-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 dossier
test1 contient un seul fichier provisio.vbs.

File\Folder | Chemin\Nom | Owner | Sujet | permission | Autorisation

F|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_ALL_ACCESS
F|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_APPEND_DATA
F|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_DELETE
F|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_DELETE_CHILD
F|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_EXECUTE
F|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_READ_ATTRIBUTES
F|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_READ_CONTROL
F|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_READ_DATA
F|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_READ_EA
F|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_SYNCHRONIZE
F|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_WRITE_ATTRIBUTES
F|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_WRITE_DAC
F|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_WRITE_DATA
F|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_WRITE_EA
F|C:\test1\provisio.vbs|emmanuel|Administrateurs|Allowed|FILE_WRITE_OWNER
F|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_ALL_ACCESS
F|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_APPEND_DATA
F|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_DELETE
F|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_DELETE_CHILD
F|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_EXECUTE
F|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_READ_ATTRIBUTES
F|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_READ_CONTROL
F|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_READ_DATA
F|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_READ_EA
F|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_SYNCHRONIZE
F|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_WRITE_ATTRIBUTES
F|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_WRITE_DAC
F|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_WRITE_DATA
F|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_WRITE_EA
F|C:\test1\provisio.vbs|emmanuel|SystËme|Allowed|FILE_WRITE_OWNER
F|C:\test1\provisio.vbs|emmanuel|Utilisateurs|Allowed|FILE_READ_ATTRIBUTES
F|C:\test1\provisio.vbs|emmanuel|Utilisateurs|Allowed|FILE_READ_CONTROL
F|C:\test1\provisio.vbs|emmanuel|Utilisateurs|Allowed|FILE_READ_DATA
F|C:\test1\provisio.vbs|emmanuel|Utilisateurs|Allowed|FILE_READ_EA
F|C:\test1\provisio.vbs|emmanuel|Utilisateurs|Allowed|FILE_SYNCHRONIZE
F|C:\test1\provisio.vbs|emmanuel|Utilisateurs authentifiÈs|Allowed|FILE_ALL_ACCESS

56
F|C:\test1\provisio.vbs|emmanuel|Utilisateurs
F|C:\test1\provisio.vbs|emmanuel|Utilisateurs
F|C:\test1\provisio.vbs|emmanuel|Utilisateurs
F|C:\test1\provisio.vbs|emmanuel|Utilisateurs
F|C:\test1\provisio.vbs|emmanuel|Utilisateurs
F|C:\test1\provisio.vbs|emmanuel|Utilisateurs
F|C:\test1\provisio.vbs|emmanuel|Utilisateurs
F|C:\test1\provisio.vbs|emmanuel|Utilisateurs
F|C:\test1\provisio.vbs|emmanuel|Utilisateurs
F|C:\test1\provisio.vbs|emmanuel|Utilisateurs
F|C:\test1\provisio.vbs|emmanuel|Utilisateurs
authentifiÈs|Allowed|FILE_APPEND_DATA
authentifiÈs|Allowed|FILE_DELETE
authentifiÈs|Allowed|FILE_EXECUTE
authentifiÈs|Allowed|FILE_READ_ATTRIBUTES
authentifiÈs|Allowed|FILE_READ_CONTROL
authentifiÈs|Allowed|FILE_READ_DATA
authentifiÈs|Allowed|FILE_READ_EA
authentifiÈs|Allowed|FILE_SYNCHRONIZE
authentifiÈs|Allowed|FILE_WRITE_ATTRIBUTES
authentifiÈs|Allowed|FILE_WRITE_DATA
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 script
proposé ci-dessous permet de récupérer les droits d’accès de l’ensemble des fichiers contenus
dans le dossier Documents afin de les consignés dans un fichier texte portant le nom de la
distribution Linux "drsnake-debian._objet.txt".

Ainsi, nous avons le script suivant :

#!/bin/bash
ls -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 dossier
Documents 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]. Une
ontologie 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ésente
un individu concret relevant de cette classe. Une propriété représente une relation qui exprime
un type d’interaction entre les classes.
Dans ce point, il est question du peuplement (transfert de données) de l’ontologie par les
données collectées via les outils d’approvisionnement. Cette opération est effectuée de façon
automatique 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 est
recommandé 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 qui
est perceptible des dirigeants et autres membres de l’organisation. Alors, il est essentiel de
traduire ce document pour une utilisation informatique. Nonobstant l’établissement de plu-
sieurs langages informatiques tels que XACML, qui donne lieu à la spécification de politiques
de 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 œuvre
servent à 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 le
fichier PS.txt.
Générons une requête DL-Querry pour déterminer tous les droits d’accès qui ne sont pas
conformes à 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(Role
has(,ApourPermission(Permision
has(Access,PermissionSurRessource(Ressource
has (PS.txt) ) and FaireAction (Action has (Read) )))and Permision.
has(Deny,PermissionSurRessource (Ressource has(PS.txt)) and FaireAction (Action
has(Execute) and Action has(Write))))))
and
Utilisateur has(root,ApourRole(Role
has(,ApourPermission(Permission
has(Access,PermissionSurRessource(Ressource
has(PS.txt)) and FaireAction (Action
has(Read) and Action has(Write))))and Permission
has(Deny,PermissionSurResource (Ressource
has(PS.txt)) andFaireAction (Action has(Execute))))))

Ainsi pour l’analyse de conformité entre la validité des droits d’accès et la politique de
sé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 tous

les liens plausibles entre ces instances.

Une fois ces trois points accomplis, un rapport pdf est produit pour donner la liste des droits
d’accès valide et non valide. Nous verrons dans la section qui suit, une illustration pour nous
aider à 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 Actionnonpermise

root rw x
emmanuel r wx
any r wx

Dans l’utilisation de XACML pour la représentation des droits d’accès Linux, on va s’accorder
sur 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 comme
attributs appropriés : subject, resource et action.

En appliquant ces règles à l’exemple ci-dessus, on obtient alors un fichier XACML (Voir Annexe
A.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é pour
définir un format de chaîne de caractères dans le but de convertir le descripteur de sécurité en
texte. Nous avons ainsi besoin de définir la syntaxe du langage SDDL grâce à une grammaire
BNF, cela nous donne la table suivante :

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

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

- SDDL

0:S-1-5-21-718938447-1703640164-3469265397-1000
G:S-1-5-21-718938447-1703640164-3469265397-513
D: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, ACE}
ACE : := {ACE Type ; ACE Flag ; Rights ; SID}
DACL : := hace :{Ace}i
ACE Type : := A|D
ACE Flag : := CI | OI | NP
IO | ID | SA | FA
Rights : := 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-500
Group_SID : := BA | ...

Table 3.1 – SDDL Syntax [43].

Windows XACML
Security Descriptor ⇒ Policies
ACE ⇒ Rules
Rights, SID ⇒ Targets
ACE :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 XACML
qui 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 également
appel à 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é, on
accède à l’interface de la figure 3.4 où va se faire la validation de la cohérence et les quelques opérations
liées à la comparaison de politiques de sécurité.

3.6 Récupération automatique des droits d’accès à partir de

diffé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ès
sur des machines distantes (hôtes). Notre choix s’est porté sur le protocole SNMP 2 à cause de sa
fiabilité, sa sécurité et son évolutivité qui permet l’utilisation d’une arborescence pour la gestion des
variables.
SNMP permet le dialogue entre le superviseur et les agents (clients) afin de récupérer les objets
souhaité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, un
commutateur 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 des
informations 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 (machine
qui é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 serveur
python démarré, nous exécutons la commande snmpwalk comme suit :

snmpwalk -v3 -u Manu -l authPriv -A ManuSPassword -x AES -X ManuSSecondPassword

localhost: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 : Afficher
les 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’administration
manuelle 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 valides
selon une politique de sécurité donnée.
— À générer un rapport afin de permettre aux administrateurs de mieux appréhender l’apport de
solution 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 des
consé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 des
accès au SI. Il nous permet alors de maîtriser le risque opérationnel et de répondre aux contraintes
réglementaires.
Dans ce mémoire, nous avons d’une part fait une synthèse de l’état de l’art des différents outils et
techniques permettant la gestion des droits d’accès dans les réseaux informatiques et d’autre part de
dé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 pratiques
liées à une bonne gestion des identités et des droits d’accès. Aussi à l’aide d’exemples, nous avons fait
la 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 le
chapitre 2. Ceci a permis de comprendre comment se fait la gestion du contrôle d’accès sur les systèmes
d’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 des
outils 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 sur
des machines distantes Linux.

Perspective
En mettant en œuvre un framework à la place d’un outil ordinaire, on a ainsi permis à AVTAC de
couvrir 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ées
spé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)
Next
For Each objSubFolder In folder.SubFolders
list_folder_right(objSubFolder)
list_sub_folder(objSubFolder )
Next
End sub

sub list_folder_right (folder)

strFolderName = folder
SE_DACL_PRESENT = &h4
ACCESS_ALLOWED_ACE_TYPE = &h0
ACCESS_DENIED_ACE_TYPE = &h1

FILE_ALL_ACCESS = &h1f01ff
FOLDER_ADD_SUBDIRECTORY = &h000004
FILE_DELETE = &h010000
FILE_DELETE_CHILD = &h000040
FOLDER_TRAVERSE = &h000020
FILE_READ_ATTRIBUTES = &h000080
FILE_READ_CONTROL = &h020000
FOLDER_LIST_DIRECTORY = &h000001
FILE_READ_EA = &h000008

69
FILE_SYNCHRONIZE = &h100000
FILE_WRITE_ATTRIBUTES = &h000100
FILE_WRITE_DAC = &h040000
FOLDER_ADD_FILE = &h000002
FILE_WRITE_EA = &h000010
FILE_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 Then

arrACEs = objSD.DACL
For 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 If
If 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 If
If 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 If
If objACE.AccessMask AND FILE_DELETE Then
AccessType = "FILE_DELETE "
MonFic.Writeline "D"&"|"& folder&"|"& objSD.Owner.Name &
"|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType
End If
If 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 If
If objACE.AccessMask AND FOLDER_TRAVERSE Then

70
 AccessType = " FOLDER_TRAVERSE "
MonFic.Writeline "D"&"|"& folder&"|"& objSD.Owner.Name &
"|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType
End If
If 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 If
If 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 If
If 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 If
If 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 If
If objACE.AccessMask AND FILE_SYNCHRONIZE Then
AccessType = "FILE_SYNCHRONIZE "
MonFic.Writeline "D"&"|"& folder&"|"& objSD.Owner.Name &
"|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType
End If
If 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 If
If 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 If
If 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 Then
AccessType = "FILE_WRITE_EA "
MonFic.Writeline "D" &"|"& folder&"|"& objSD.Owner.Name &
"|" & objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType
End If
If 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 If
Next
Else
WScript.Echo "No DACL present in security descriptor"
End If

end sub

sub list_file_right (file)

strFileName = file
SE_DACL_PRESENT = &h4
ACCESS_ALLOWED_ACE_TYPE = &h0
ACCESS_DENIED_ACE_TYPE = &h1

FILE_ALL_ACCESS = &h1f01ff
FILE_APPEND_DATA = &h000004
FILE_DELETE = &h010000
FILE_DELETE_CHILD = &h000040
FILE_EXECUTE = &h000020
FILE_READ_ATTRIBUTES = &h000080
FILE_READ_CONTROL = &h020000
FILE_READ_DATA = &h000001
FILE_READ_EA = &h000008
FILE_SYNCHRONIZE = &h100000
FILE_WRITE_ATTRIBUTES = &h000100
FILE_WRITE_DAC = &h040000
FILE_WRITE_DATA = &h000002
FILE_WRITE_EA = &h000010
FILE_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 Then

arrACEs = objSD.DACL
For 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 If
If 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 If
If 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 If
If objACE.AccessMask AND FILE_DELETE Then
AccessType = "FILE_DELETE "
MonFic.Writeline "F" & "|" & file & "|" & objSD.Owner.Name & "|" & objACE.Trustee.Name&
"|"&Allowed_Denied &"|"& AccessType
End If
If 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 If
If objACE.AccessMask AND FILE_EXECUTE Then
AccessType = "FILE_EXECUTE "
MonFic.Writeline "F" & "|" & file & "|" & objSD.Owner.Name & "|" & objACE.Trustee.Name&
"|"&Allowed_Denied &"|"& AccessType
End If
If 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 If
If 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 If
If 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 If
If 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 If
If objACE.AccessMask AND FILE_SYNCHRONIZE Then
AccessType = "FILE_SYNCHRONIZE "
MonFic.Writeline "F" & "|" & file & "|" & objSD.Owner.Name & "|" &
objACE.Trustee.Name&"|"&Allowed_Denied &"|"& AccessType
End If
If 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 If
If 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 If
If 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 If
If 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 If
If 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 If
Next

74
Else
WScript.Echo "No DACL present in security descriptor"
End If

end sub

’Pour créer le fichier texte

Set 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 subprocess
from twisted.internet import reactor
from pysnmp.entity import engine, config
from pysnmp.entity.rfc3413 import cmdrsp, context
from pysnmp.carrier.twisted.dgram import udp
from pysnmp.carrier.twisted import dispatch
from pysnmp.proto.api import v2c
from 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 trimestre
2003, pages 30-43, Projet MP6, 2003.

[4] J. Rushby. “The Bell and La Padula Security Model”. Computer Science Laboratory, SRI
International, 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. John
Wiley 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 Assertion
Markup Language (SAML) V2.0.” 2005.

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

2003.

84
[29] N. Debaes ; P. Pezziardi ; B. Vincent, 2007In Gestion des identités : une politique pour le
systè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 Access
Control 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 in
Security and Privacy, pages 122-136, 1992.

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

[48] D. E. Bell ; L. J. La Padula. Secure computer system : Unifed exposition and multics
interpretation. 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 : Proceedings

of 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, IEEE
Computer 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 Family

of Models for Active and Enterprise-oriented Authorization Management”.Proceedings of the
IFIP 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 control
systems. 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ème
d’information. OCTO Technology.

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

[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_

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

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

[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