Upload
batomen-danny
View
1.019
Download
2
Embed Size (px)
DESCRIPTION
Au cœur de la sécurité des systèmes d'information, la gestion et le contrôle des identités et des accès est devenu une des préoccupations majeures pour les directeurs des systèmes d'information. La vitesse avec laquelle l'entreprise doit s'adapter (fusions, acquisitions, repositionnements sur le cœur de métier, consolidations, externalisations, ...) sur un marché mondial hyperconcurrentiel a imposé le décloisonnement des systèmes d'information. Pour l'entreprise étendue, les services en réseau ou services web ouvrent la voie à une nouvelle forme d’urbanisation des systèmes d'information capable d'accompagner cette évolution frénétique (Voir l'entreprise en réseau s'expose) . La gestion des identités des acteurs internes comme externes de cette nouvelle architecture orientée service (SOA) est alors un enjeu majeur, pas uniquement sécuritaire mais aussi organisationnel.
Citation preview
UNIVERSITE DE PICARDIE JULES VERNE
UNIVERSITE ABDELMALEK ESSAADI
ETUDES ET RECHERCHES
Effectué du 05 Mai au 05 Novembre 2012
Par
Ghislain Danny BATOMEN YANGA
Gisèle MEKUATE DEFO
Master M1 MIAGE Méthodes Informatiques Appliquées à la Gestion des Entreprises
Tuteur de projet : M. Yasser El Khamlichi
MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET
DE LA RECHERCHE
ACADEMIE D’AMIENS
----------------------
LES SYSTEMES DE GESTION DES IDENTITES ET DES ACCES :
MISE EN ŒUVRE ET APPORT POUR LA SECURITE D’UNE
ORGANISATION
Promotion de Janvier 2012 – Semestre 1
Année Académique 2011 – 2012
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
ii ii
LISTE DES FIGURES ........................................................................................................................iv INTRODUCTION ............................................................................................................................ 1 Première partie : Généralités ........................................................................................................ 2 Chapitre 1 : Pourquoi un système de gestion des identités et des accès ? ....................................... 3
1.1. Etats des lieux ........................................................................................................................ 3 1.2. Justificatif d’un projet de gestion des identités et des accès ................................................ 4
1.2.1. Garantie de traçabilité et d’auditabilité .......................................................................... 5 1.2.2. Réduction des coûts d’administration............................................................................. 5 1.2.3. Amélioration de l’efficacité et de la réactivité ................................................................ 5 1.2.4. Amélioration de la sécurité ............................................................................................. 6
Chapitre 2 : Les concepts .............................................................................................................. 7
2.1. Les concepts de base ............................................................................................................. 7 2.1.1. Utilisateur ........................................................................................................................ 7 2.1.2. Compte ............................................................................................................................ 7 2.1.3. Rôle .................................................................................................................................. 8 2.1.4. Profil ................................................................................................................................ 8 2.1.5. Poste opérationnel .......................................................................................................... 8 2.1.6. Groupe ............................................................................................................................. 8 2.1.7. Périmètre ......................................................................................................................... 8 2.1.8. Mode d’authentification ................................................................................................. 9 2.1.9. Ressource ........................................................................................................................ 9 2.1.10. Environnement de SI ................................................................................................... 9 2.1.11. Environnement externe ............................................................................................... 9
2.2. Les concepts avancés : Fédération d’identités .................................................................... 10 2.2.1. L’identité fédérée .......................................................................................................... 10 2.2.2. La répartition des responsabilités ................................................................................. 10 2.2.3. Confiance entre les partenaires. ................................................................................... 11 2.2.4. La gestion d’identités fédérées ou Federated Identity Management ........................... 11
Deuxième partie : La gestion des identités et des accès pour la sécurité de l’information ............. 12 Chapitre 3 : La gestion des identités ............................................................................................ 13
3.1. Notions d’identités ............................................................................................................... 13 3.1.1. Définition ....................................................................................................................... 13 3.1.2. Utilité et gestion ............................................................................................................ 14
3.2. Modèles de gestion d’identités ........................................................................................... 15 3.2.1. Modèle isolé de gestion des identités ........................................................................... 15 3.2.2. Modèle centralisé de gestion des identités .................................................................. 16
3.2.2.1. Modèle commun de gestion des identités ............................................................ 16 3.2.2.2. Domaine d’identité avec authentification unique : SSO ....................................... 16
3.3. La fédération d’identités ...................................................................................................... 17 3.3.2. Objectif de la Fédération d’identité ............................................................................. 18
Table des matières
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
iii iii
3.3.3. Langages pour l’échange de l’information de sécurité ................................................. 19 3.4. Technologies de gestion d’identités .................................................................................... 20
3.4.1. Kerberos ........................................................................................................................ 20 3.4.2. Radius ............................................................................................................................ 20 3.4.3. Infrastructure à clé publique ......................................................................................... 21
Chapitre 4 : La gestion des accès ................................................................................................. 23
4.1. La gestion d’accès : le concept ............................................................................................. 23 4.1.1. Définition ....................................................................................................................... 23 4.1.2. Principe de fonctionnement .......................................................................................... 23
4.2. Modèles de gestion d’accès ................................................................................................. 25 4.2.1. Modèle RBAC ................................................................................................................. 25 4.2.2. Modèle MAC .................................................................................................................. 27 4.2.3. Modèle DAC ................................................................................................................... 27
4.3. Architectures de gestion d’accès ......................................................................................... 28 4.3.1. Architectures AAA ......................................................................................................... 28 4.3.2. Infrastructures de gestion à base de politiques ............................................................ 29
Troisième partie : Implémentations et expérimentations ............................................................ 31 Chapitre 5 : Les solutions de contrôle d’accès .............................................................................. 32
5.1. Architectures de gestion d’accès ......................................................................................... 32 5.2. Les solutions de gestion d’identités et de droits d’accès .................................................... 33
5.2.1. Les solutions propriétaires ............................................................................................ 33 5.2.2. Les solutions propriétaires ............................................................................................ 35
Chapitre 6 : Implémentation d’une solution de contrôle d’accès .................................................. 37
6.1. Environnement de travail .................................................................................................... 37 6.2. Présentation d’Active Directory ........................................................................................... 38
6.2.1. Active Directory et services d'accès et d'identité .......................................................... 38 6.2.2. Arborescence Active Directory ...................................................................................... 39
6.3. Création d’une nouvelle forêt avec Windows Server 2008 ................................................. 40 6.4. Gestion des utilisateurs et des ordinateurs ......................................................................... 41
6.4.1. Unité d’organisation ...................................................................................................... 41 6.4.2. Compte d’utilisateurs .................................................................................................... 42 6.4.3. Groupe Active Directory ................................................................................................ 44 6.4.4. Implémentation de la gestion a base des rôles en utilisant des groupes ..................... 45 6.4.5. Mises des machines clientes dans le domaine .............................................................. 48
6.5. Amélioration de la sécurité et piste d’audit ........................................................................ 48 6.5.1. Délégation des autorisations administratives ............................................................... 49
6.5.1.1. Approche de la délégation .................................................................................... 49 6.5.1.2. Délégation des comptes utilisateurs. .................................................................... 49
6.5.2. Configuration des paramètres de mot de passe et de verrouillage .............................. 52 6.5.2.1. Configuration des stratégies de comptes du domaine ......................................... 52 6.5.2.2. Stratégie de mot de passe affinée ......................................................................... 54
6.5.3. Audit de l’authentification de connexion ...................................................................... 54 6.6. Configuration du service DNS .............................................................................................. 56
CONCLUSION GENERALE ............................................................................................................. 59 BIBLIOGRAPHIE ........................................................................................................................... xv
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
iv iv
LISTE DES FIGURES LISTE DES FIGURES
Première partie : Généralités et définition des concepts ................................................................ 2 Chapitre 1 : Pourquoi un système de gestion des identités et des accès ? ....................................... 3 Figure 1.1 : Existant standard de la gestion des identités et des droits d’accès .................................. 4 Figure 1.2 : Flux de mise à jour après la mise en place d’une gestion centralisée .............................. 6 Chapitre 2 : Les concepts .............................................................................................................. 7 Figure 2.1 : la fédération d’identités ............................................................................................. 11 Deuxième partie : La gestion des identités et des accès pour la sécurité de l’information ............. 12 Chapitre 3 : La gestion des identités ............................................................................................ 13 Figure 3.1 : Entités, identités et identificateurs .................................................................................... 14 Figure 3.2 : Modèle isolé de gestion des identités ................................................................................ 15 Figure 3.3 : le modèle commun de gestion d’identités ......................................................................... 16 Figure 3.4 : le domaine d’identité avec authentification unique .......................................................... 17 Chapitre 4 : La gestion des accès ................................................................................................. 23 Figure 4.1 : Modèle RBAC de base ....................................................................................................... 25 Troisième partie : Implémentations et expérimentations ............................................................ 31 Chapitre 6 : Implémentation d’une solution de contrôle d’accès .................................................. 37 Figure 6.1 : Information système générale ........................................................................................... 37 Figure 6.2 : Arborescence Active Directory ........................................................................................... 40 Figure 6.4 : Informations d’un utilisateur .............................................................................................. 43 Figure 6.5 : Liste des utilisateurs de l’OU « Personnels » ...................................................................... 44 Figure 6.6 : Les groupes de rôles ........................................................................................................... 46 Figure 6.7 : Utilisateurs membres d’un groupe ..................................................................................... 46 Figure 6.8 : les propriétés d’un dossier partagé .................................................................................... 47 Figure 6.9: Les autorisations.................................................................................................................. 47 Figure 6.10 : Les groupes de règles ....................................................................................................... 48 Figure 6.11 : Postes de l’OU « Privés » .................................................................................................. 48 Figure 6.12 : Délégation de contrôle ..................................................................................................... 50 Figure 6.15 : Les paramètres de stratégies de mot de passe ................................................................ 53 Figure 6.16 : Les paramètres de stratégie de verrouillage du compte ................................................. 54 Figure 6.17 : Les stratégies affinées ...................................................................................................... 54 Figure 6.18 : Paramètres d’audit ........................................................................................................... 55 Figure 6.19 : Observateur d’événements .............................................................................................. 56 Figure 6.20 : La zone de recherche directe du domaine ....................................................................... 57 Figure 6.21 : Assistant de création de la zone de recherche inversée .................................................. 57
Liste des figures
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
1 1
INTRODUCTION
De plus en plus d’entreprises et d’organismes appréhendent l’intérêt d’une mise en place du
système d’information pour la gestion des identités et la sécurité des accès. Ce système est perçu
comme un maillon clé dans la chaine de sécurité des organisations Elle permet de renforcer le niveau
de sécurité général en garantissant la cohérence dans l’attribution des droits d’accès aux ressources
hétérogènes du système d’information.
Notre étude porte sur ces systèmes de gestion d’identités et de droits d’accès, et c’est
l’occasion pour nous de comprendre les concepts, l’architecture, les modèles utilisés pour la mise en
place d’un tel système.
L’étude ainsi réalisée a été découpée en trois(03) parties : dans la première partie nous avons
aborder les « généralités » afin de maîtriser toutes les notions et concepts qui tournent autour des
systèmes de gestion d’identités et même de comprendre l’intérêt d’un système de gestion
d’identités et de droits d’accès : dans la seconde partie dénommé « gestion des identités et des
droits d’accès » nous avons présenté les modèles, architectures et technologies (protocoles) utilisés
pour la gestion des identités et des habilitations ; et enfin dans la troisième partie « implémentation
d’une solution des gestions de identités et des droits d’accès» c’était l’occasion pour nous d’étudier
non seulement les solutions de gestion d’identités et d’accès offerts sur le marché mais aussi
d’expérimenter une de ces solutions à travers son implémentation.
Introduction
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
2 2
Première partie : Généralités
1ère partie :
Généralités et définition
des concepts
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
3 3
CHAPITRE 1 : CONTEXTE GENERAL DU PROJET Chapitre 1 : Pourquoi un système de gestion des identités et des accès ?
1.1. Etats des lieux
De nos jours, la multiplication et la diversité de systèmes de contrôle d’accès liés aux systèmes
d'exploitation et aux applications est devenue particulièrement contre-productive. En effet, chaque «
système» (OS, NOS, messagerie, groupware, applications métiers, ERP, CRM, etc.) est protégé par
une procédure de contrôle d'accès spécifique. De fait, chaque fonction à réaliser peut nécessiter un
code d’accès et des droits associés. Cette multiplicité de contrôles d’accès est source de confusion
pour l'utilisateur qui, par exemple, perd ou oublie ses mots de passe. Il lui reste alors deux solutions :
soit il sollicite le service de help-desk, au risque de l’engorger en lui faisant perdre trop de temps à
réinitialiser très souvent des mots de passe, soit il note lesdits codes sur un support à sa portée pour
ne plus les oublier ! Bien entendu, aucune de ces solutions n’est satisfaisante…
D’une manière générale, chaque système d’exploitation et/ou application est géré par un
administrateur unique ; de fait, toute vision globale est impossible. Dans ce cas, l’administration
autonome de chaque système est particulièrement source d’erreurs, de vulnérabilités et de perte de
temps. Par exemple, ne pas avoir la vision globale sur les droits de l’ensemble des utilisateurs peut
engendrer des problèmes de responsabilité (devenus importants dans le cadre des nouvelles lois ou
réglementations), tel qu’un acheteur qui validerait sa propre commande.
Généralement, les nouveaux arrivants se voient attribuer plus ou moins rapidement certaines
ressources (un bureau, un téléphone, un badge d’accès, un PC, etc.), mais ne peuvent pas travailler,
faute de droits d'accès. Ceci est notamment du au fait que le délai d’attribution des ressources et des
droits est trop long, que les circuits d’attribution sont trop « lourds», etc. Ils doivent même souvent
se débrouiller seuls : trouver le bon responsable pour l'accès à telle base de données, à telle
application, à l’Intranet, etc. La liste des interlocuteurs est à la mesure de la complexité du Système
d’Information.
D’autre part, on est rarement certain d'avoir supprimé tous les droits dont disposait un employé
partant ou d’avoir mis à jour les droits d’un employé en cas de changement de fonction. Le Système
d’Information regorge souvent de comptes dits « fantômes» (dormants et/ou périmés).
De plus, les comptes techniques génériques, installés par défaut, par les systèmes d’exploitation
et/ou les applications, ne sont pas toujours modifiés, voire supprimés, induisant d’autres failles. Ceci
étant d’autant plus grave que ces mots de passe sont facilement accessibles sur Internet… De même,
certaines personnes utilisent, lorsqu’elles arrivent dans l’entreprise, des comptes utilisateurs
«génériques» et partagés, simplement du fait de la durée importante de création de leur propre
compte.
Chapitre 1 : Pourquoi un système de
gestion des identités et des accès ?
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
4 4
Enfin, l’audit et la traçabilité sont souvent les parents pauvres de la mise en œuvre des droits
d’accès des utilisateurs. Pourtant, de plus en plus, les entreprises doivent respecter des normes, des
lois et/ou des réglementations strictes en matière de politique de contrôle interne.
La figure ci-dessous illustre l’état des lieux « standard »de la gestion des identités et des droits
d’accès dans une organisation
Figure 1.1 : Existant standard de la gestion des identités et des droits d’accès
1.2. Justificatif d’un projet de gestion des identités et des accès
Comme nous l’avons vu précédemment, l’absence de gestion globale des identités et des droits
d’accès peut générer de nombreux problèmes, parmi lesquels :
la perte de productivité due aux délais d’obtention des droits d’accès,
une charge importante d’administration (multiplication des administrateurs, réinitialisation
des mots de passe, etc.),
l’impossibilité de tracer les actions d’administration des droits et d’en contrôler la cohérence
et la pertinence,
la difficulté d’auditer les accès aux ressources,
des entorses au principe de séparation des tâches,
le non-respect des contraintes légales et/ou réglementaires (par exemple au travers d’un
mauvais paramétrage des règles de gestion).
La justification d’un projet de gestion des identités et des droits d’accès reposera sur les
améliorations suivantes :
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
5 5
1.2.1. Garantie de traçabilité et d’auditabilité
Il s’agit ici des principales lois et réglementations impliquant le SI et ayant des impacts directs sur
les aspects traitant de la sécurité (en particulier traçabilité et auditabilité)
D’une manière générale, ces lois et règlements « imposent» au Système d’Information des
exigences de :
continuité d’activité,
séparation des tâches : par exemple, une même personne ne doit pas à la fois commander
une fourniture ou prestation et valider sa réception,
traçabilité et d’auditabilité : permettant de valider « qui a fait quoi » au sein du système
d’information, et « qui a habilité qui », de respect de la vie privée.
Déroger à ces exigences peut entraîner un risque juridique pour les responsables de l’entreprise.
1.2.2. Réduction des coûts d’administration
Un système de gestion des identités et des droits d’accès permet d’alléger la charge de travail de
l’équipe de « support informatique» (administration, help desk). Cet allègement résulte d’une part
de l’automatisation de tâches de gestion de comptes (réduction du nombre d’administrateurs) et
d’autre part de la diminution du nombre d’appels d’utilisateurs (perte ou oubli de nombreux mots de
passe, relance de demandes d’accès, etc. .).
Le système de gestion des identités peut permettre aux utilisateurs la gestion directe de certains
aspects de leur profil (par exemple le mot de passe, l’adresse, les numéros de téléphone, etc.).
1.2.3. Amélioration de l’efficacité et de la réactivité
Un système de gestion des identités et des droits d’accès permet de réduire le nombre
d’interventions humaines par une automatisation de la propagation des droits sur les différents
environnements concernés. La conséquence est à la fois une réduction des délais de mise à
disposition des droits d’accès et une réduction des sources d’erreur (prise en compte systématique
de tous les besoins liés à l’activité de l’utilisateur, garantie de cohérence dans les droits attribués).
Les gains générés concernent à la fois les utilisateurs internes (gain de productivité) et externes
(amélioration de la qualité du service et de l’image de l’entreprise).
Sur un autre plan, lors d’une fusion ou d’une acquisition, il faut fournir le plus rapidement
possible un accès aisé aux ressources rassemblées d’entreprises auparavant autonomes. Là encore,
une solution de gestion des identités et des droits d’accès aidera à relever ce défi au
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
6 6
Travers d’un service d’intégration des informations multi-plates-formes permettant de connecter
les systèmes de chaque entreprise à la plupart des systèmes (nouveaux ou préexistants) de la
nouvelle entité.
1.2.4. Amélioration de la sécurité
Un système de gestion des identités et des droits d’accès permet de renforcer la sécurité. Une
telle approche conduit à établir des liens entre toutes les applications, bases de données et
annuaires en s’appuyant sur des notions de rôle et de profil. Cette solution offre un point unique de
gestion des règles de sécurité pour l’ensemble des systèmes concernés. Elle permet de créer
simplement des règles d’accès et de sécurité, en cohérence avec la Politique de Sécurité des
Systèmes d’Information et les besoins métier, puis de les propager automatiquement à tous les
systèmes de l’entreprise.
La gestion centralisée des identités permet d’éliminer une source considérable d’erreurs
d’administration pouvant causer des failles de sécurité d’accès au SI de l’entreprise. Elle permet
également de résilier complètement et immédiatement les droits d’accès sur l’ensemble des
systèmes lorsque des salariés ou personnels extérieurs quittent l’entreprise ou changent
d’affectation et supprimer ainsi les comptes « fantômes ».
En mettant en place des processus maîtrisés d’habilitation, le système permet d’impliquer les
responsables métiers dans le circuit d’habilitation et de ne plus laisser au seul administrateur
technique la maîtrise des droits d’accès.
La figure ci-dessous illustre les flux d’information d’une organisation ayant un système de gestion
des identités et des accès
Figure 1.2 : Flux de mise à jour après la mise en place d’une gestion centralisée
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
7 7
Chapitre 2 : Les concepts
Dans ce chapitre nous allons présenter les concepts utilisées dans le domaine de la sécurité des
systèmes d’information.
2.1. Les concepts de base
Les concepts de base portent sur les utilisateurs, groupes, profils,… donc il est question
d’expliciter ses notions parfois ambiguë.
2.1.1. Utilisateur
Désigne une personne physique : les employés d’entreprise, les prestataires, les partenaires et
les clients de l’entreprise qui, de par leur fonction, exercent une activité ayant vocation à leur
permettre de bénéficier des applications et des ressources mises à disposition par l’entreprise. Toute
personne déclarée dans un référentiel central de sécurité et de gestion des habilitations est
identifiée par un identifiant unique, un nom, un prénom, une durée de validité, un état (actif ou
suspendu), les périmètres d’accès autorisés….
2.1.2. Compte
À chaque personne peuvent être associés des comptes d’accès aux différents systèmes et
applications. Le compte est défini par l’identifiant d’accès, un mot de passe (ou un authentifiant
d’une autre nature), et plusieurs attributs supplémentaires en fonction de l’environnement dans
lequel il est crée comme: la politique de mot de passe associée, l’accès externe autorisé ou non,
l’état du compte, les modes d’authentification autorisés etc.
Il existe quatre types de comptes :
Compte global : il est unique à un utilisateur et identifie cet utilisateur dans le référentiel de
gestion des habilitations et est utilisé par tous les processus d’attribution des droits.
Compte utilisateur : Ce compte donne l’accès à un utilisateur dans un environnement
particulier auquel cet utilisateur est habilité. Exemples : compte d’OS, de NOS, de
messagerie, de LDAP.
Compte d’administration : Ce compte donne l’accès à un administrateur dans un
environnement particulier. Ce compte n’est pas associé à une personne. Il ne correspond
donc à aucune entrée dans le référentiel central de gestion des habilitations et son usage est
limité aux actes d’administration techniques des applications et environnements.
Chapitre 2 : Les concepts
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
8 8
Compte technique ou de service fonctionnel : Ces comptes sont utilisés par les composants
d’un système pour accéder aux services applicatifs et/ou données d’un autre système.
2.1.3. Rôle
Un rôle définit les permissions nécessaires à l’utilisation des objets (applications et/ou des
ressources).Une habilitation donne à un utilisateur un ensemble de permissions dans une
application. Elle est attribuée en fonction du poste opérationnel au sein de l’organisation et non à
titre individuel. C’est le poste opérationnel qui détermine les rôles et les périmètres nécessaires.
2.1.4. Profil
Un profil regroupe un ensemble de rôles nécessaires à l’exécution d’une fonction métier. Le
profil peut également être vu comme un package de rôles applicatifs ou un niveau supérieur dans la
hiérarchie des.
Un utilisateur peut avoir un ou plusieurs profils.
Le profil correspond généralement à la fonction exercée par l’acteur affecté au poste
opérationnel ainsi qu’à son niveau d’expertise. Il peut aussi correspondre à un ensemble
d’habilitations spécifiques.
2.1.5. Poste opérationnel
Le poste opérationnel (position de travail) correspond à une fonction métier exercée au sein d’un
élément de structure (service, département, …). Un poste opérationnel est toujours défini au sein
d’un et un seul élément de structure. Le responsable de structure indique les postes qui lui sont
attribués.
Un poste peut éventuellement être partagé par plusieurs acteurs.
Le poste opérationnel n’est pas modélisé dans le référentiel central.
2.1.6. Groupe
Les utilisateurs peuvent être regroupés, dans le référentiel central, en groupes statiques ou
dynamiques. Ces groupes sont utilisés pour faciliter la gestion en masse des habilitations.
2.1.7. Périmètre
Le périmètre est utilisé par les applications et/ou systèmes pour affiner le contrôle d’autorisation
qu’ils réalisent.
Le périmètre peut être associé à : une personne, un compte (uniquement dans le cas de
limitation des autorisations d’accès à des ressources d’un environnement) et un rôle.
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
9 9
Le périmètre peut être :
Temporel : permet de restreindre les possibilités d’accès d’un utilisateur dans le temps en
utilisant une période, une plage horaire ou un calendrier
Géographique : permet de restreindre les possibilités d’accès d’un utilisateur en fonction du
lieu à partir duquel il accède au SI.
Fonctionnel : permet de gérer la sécurité applicative : le programme autorisera ou non
certains traitements en fonction des données qui lui seront communiquées par le système
d’habilitation (identifiant acteur, poste de travail, éventuellement lieu de présence ou
d’affectation d’utilisateur, etc.).
2.1.8. Mode d’authentification
Certaines applications critiques imposent un mode d’authentification particulier (authentification
forte). Le système d’authentification fournit (dans le contexte de sécurité) l’information indiquant le
mode d’authentification utilisé lors de l’ouverture de la session. Cette information est exploitée par
le système de contrôle d’accès et /ou l’application.
Le mode d’authentification peut être associé à : un rôle, une ressource.
2.1.9. Ressource
La ressource est définie par : un libellé, les modes d’authentification nécessaires pour y accéder,
les périmètres d’accès autorisés, les rôles ou les groupes de comptes autorisés sur cette ressource.
Une ressource peut être : une ou des adresses IP des serveurs, une URL, une commande de
lancement d’une application….
2.1.10. Environnement de SI
Le terme d’environnement du SI désigne un ensemble de ressources et de processus (système,
sous-système, application, etc.) dont les droits d’accès sont gérés par un système de contrôle unique
et autonome et administré par l’entité responsable.
Exemples : les fichiers, répertoires, files d’attente, services de NOS, les fichiers, répertoires d’OS,
les ressources et les services applicatifs, les messageries et groupware, les bases de données
relationnelles,
2.1.11. Environnement externe
Le terme d’environnement externe désigne un ensemble de ressources et de processus
(système, sous-système, application, etc.) gérés par des tiers et dont les droits d’accès sont gérés par
un système de contrôle autonome et administrés par l’organisme tiers. Dans certains cas le contrôle
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
10 10
d’accès peut s’appuyer sur les informations de sécurité fournies par le SI de l’entreprise (identité
et/ou rôle).
L’intégration avec ce type d’environnement peut être faite de deux manières :
- délégation complète d’administration des habilitations et d’authentification
- provisioning du référentiel tiers.
Le développement constant des échanges commerciaux entre les partenaires via l’Internet est un
facteur important de multiplication des infrastructures mettant en œuvre ce type d’interaction. Le
besoin des possibilités d’intégration rapide des nouveaux partenaires a stimulé les multiples travaux
de normalisation.
Le concept général d’architecture permettant l’interaction entre les systèmes autonomes des
différents partenaires porte le nom de « Fédération des Identités ».
2.2. Les concepts avancés : Fédération d’identités
La fédération d’identité ou authentification répartie est un partage d’informations d’identité
concernant les utilisateurs d’un établissement avec un ou plusieurs organismes partenaires qui vise à
permettre l’accès à distance contrôlé et sécurisé aux ressources de ces partenaires.
Les solutions de fédération d’identités s’appuient sur quelques concepts tels que :
2.2.1. L’identité fédérée
C’est un ensemble d’attributs fédérés, c’est-à-dire d’informations relatives à l’identité provenant
de différentes sources et pouvant être mises en commun, apporte des gains fonctionnels pour
l’utilisateur : la possibilité de partager son identité entre les différents systèmes, ou pour
l’entreprise ; la possibilité de s’associer avec d’autres partenaires au sein d’une fédération, afin que
les identités d’un domaine puissent donner accès aux services d’un autre domaine sans être obligé
de mettre en œuvre une gestion lourde (et souvent pratiquement impossible) de gestion des
identités des utilisateurs de chaque partenaire.
2.2.2. La répartition des responsabilités
La propagation d’identités et la fédération inter partenaires s’appuient sur une organisation tri
partite
un fournisseur d’identité (Identity Provider ou IDP) : chargé d’authentifier l’utilisateur et de
gérer son identité (enregistrement, provisioning, gestion de comptes et de mots de passe),
un fournisseur de services (Service Provider ou SP) : chargé de lui fournir des services en
fonction de ses habilitations sur la base des informations fournies par le fournisseur
d’identités à qui il fait confiance, l’utilisateur.
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
11 11
2.2.3. Confiance entre les partenaires.
Tous les mécanismes de fédération d’identités se basent sur le principe fondamental d’existence
d’une relation de confiance entre les partenaires qui ont décidé de collaborer. Il est primordial que
ces relations de confiance soient établies et gérés sur trois niveaux :
métier où seront définis les services concernés par la fédération, les engagements de qualité
de service et les conditions de mise en œuvre. En particulier le fournisseur de service pourra
exiger une garantie de fiabilité et de niveau d’authentification de la part du fournisseur
d’identité,
légal où seront formalisées et contractualisées les exigences métier et définis les moyens et
les procédures de résolution de cas de litiges,
technique où seront définis les moyens techniques de mise en œuvre des liens sécurisés
entre les sites, les formats de jetons de sécurité et les processus de validation de
l’authenticité des informations échangées.
2.2.4. La gestion d’identités fédérées ou Federated Identity Management
C’est une façon standardisée de gérer de bout en bout le cycle de vie des identités, au sein de
l’entreprise et entre les entreprises,
Son rôle est de:
• étendre les pratiques de gestion des identités de l’entreprise,
• simplifier la gestion des identités au-delà des frontières de l’entreprise,
• faciliter l’intégration métier des partenaires via des relations de confiance et le partage
d’information dans un environnement sécurisé.
Figure 2.1 : la fédération d’identités
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
12 12
Deuxième partie : La gestion des identités et des accès pour la sécurité de l’information
2ème partie : La gestion des identités
et des accès pour la sécurité de l’information
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
13 13
Chapitre 3 : La gestion des identités
Dans ce chapitre, nous décrivons le concept de l’identité et les modèles de gestion d’identité
traditionnels. Nous détaillons, par la suite, la fédération d’identité qui offre des solutions aux
contraintes sécuritaires imposées par le déploiement d’un réseau distribué. Nous décrivons, en
détail, les langages utilisés pour l’échange de l’information de sécurité dans le cadre d’une
fédération.
3.1. Notions d’identités
3.1.1. Définition
Une identité est une représentation d’une entité dans un domaine d’application spécifique. Il
permet de singulariser, nommer, isoler une entité prise parmi un ensemble.
A priori, on attend d’une identité, qu’elle soit associée à une entité unique : une hypothèse
simplificatrice considère qu’une identité unique ne pourra jamais être associée à plusieurs entités
différentes. Il ne faut pas la confondre avec une identité commune, qui est associée à des entités
élémentaires ayant une relation de groupe. Ainsi, dans une famille l’identité commune est donnée
par le nom de famille, qui devient alors une caractéristique appartenant aux différents membres du
groupe. Dans la mesure où le fournisseur de services est concerné, ce dernier traite l’entité réelle (la
famille) et non pas un ensemble d’individus.
Une entité peut avoir des identités multiples, certaines pouvant être des synonymes. Suivant le
contexte, une entité peut avoir de zéro à N identités. Par exemple, dans une université, une
personne peut avoir deux identités : l’une en qualité d’étudiant parce qu’elle prépare un doctorat,
l’autre en qualité d’enseignant parce qu’elle exerce en qualité d’ATER (Attaché Temporaire
d’Enseignement et de Recherche). Les règles d’enregistrement des identités dans un domaine
spécifique déterminent si une entité a le droit d’avoir plusieurs identités dans ce domaine spécifique.
Une personne peut toujours avoir plusieurs identités dans des domaines différents. Par exemple, une
personne peut avoir une identité associée en tant que client d’une banque et une autre identité
associée car il est employé d’une entreprise.
On comprend dès lors les difficultés sous jacentes qui naissent de la création et de la
manipulation des identités dans un système. Une identité est construite à partir d’un ensemble de
caractéristiques nommées des “identificateurs”. Ces caractéristiques peuvent avoir diverses
propriétés telles qu’être temporaires ou permanentes, auto choisies par l’entité ou bien affectées
par une autorité, avoir une portée limitée à une organisation, ou bien transgresser cette même
organisation.
Les caractéristiques retenues pour la construction d’une identité peuvent être Différentes selon
le type d’entités identifiées. Par exemple, la date de naissance est valable pour des personnes ; par
contre, le numéro national d’enregistrement est valable seulement pour une organisation.
Chapitre 3 : La gestion des identités
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
14 14
La relation entre entités, identités et caractéristiques/identificateurs est présentée dans ci-dessous :
Figure 3.1 : Entités, identités et identificateurs
La Figure ci-dessus illustre le fait qu’une entité, une personne ou une organisation, peut avoir
plusieurs identités, et où chaque identité est construite à partir d’un ensemble de caractéristiques
qui peuvent être des identificateurs uniques (ou non uniques). La séparation entre les deux notions «
identité » et « identificateurs » n’est pas toujours évidente. Le terme identité est généralement
utilisé dans le sens d’un identificateur spécialement quand l’identité est reconnue par un seul
identificateur dans un contexte donné. Un domaine d’identité est un domaine où chaque identité est
unique. En définissant un espace de noms d’identificateurs uniques dans un domaine, des relations
de type « un à un » entre identités et identificateurs sont possibles. Toutes les caractéristiques des
identités ne peuvent être des identificateurs uniques d’où la nécessité de l’établissement d’un
espace de nom qui soit conforme aux normes.
3.1.2. Utilité et gestion
Au-delà de la construction d’une identité, viennent se greffer toutes les problématiques
associées aux actions que l’on peut exercer en revendiquant cette identité. Le simple fait de disposer
d’une identité, donne un certain nombre de prérogatives vis-à-vis d’une organisation.
Chaque fois qu’un fournisseur de services veut mettre ses services et ses ressources à la
disposition des autres, il doit vérifier l’identité de l’utilisateur demandant le service ou la ressource et
s’assurer qu’il a bien le droit d’utiliser ce service ou cette ressource. Dans ce contexte, la gestion des
identités consiste en l’attribution d’un identificateur unique et d’attributs à l’utilisateur durant la
phase d’enregistrement de ce dernier. Ces identificateurs et attributs sont vérifiés par le fournisseur
de services pour prendre sa décision (autoriser/refuser l’accès de l’utilisateur à la ressource
demandée).
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
15 15
Plusieurs technologies sont utilisées de nos jours pour gérer les identités dans un domaine de
sécurité ou au moins, permettre aux administrateurs IT des organisations de contrôler les identités
des utilisateurs internes et externes. Nous entendons par gérer une identité le fait de vérifier
l’identité d’une entité à travers des moyens physiques (par exemple, rencontre de l’entité en
question), attribuer à cette entité les accréditations (identificateurs et caractéristiques uniques) et
enfin l’authentifier chaque fois qu’elle désire accéder à un service protégé.
3.2. Modèles de gestion d’identités
Les modèles de gestion d’identité expliquent comment un administrateur donne des
identificateurs aux utilisateurs afin qu’ils soient reconnus et authentifiés par les fournisseurs de
services.
3.2.1. Modèle isolé de gestion des identités
Le modèle de gestion des identités le plus courant permet aux fournisseurs de services d’agir en
tant que fournisseurs d’identificateurs et d’attributs pour leurs clients. Il leur incombe alors de
contrôler l’espace de noms pour la mise en œuvre d’un service donné et d’affecter les identifiants
aux utilisateurs. Un utilisateur recevra un identificateur unique et des attributs pour
l’authentification (par exemple, des mots de passe) ; Si un usager met en œuvre simultanément
plusieurs services, il doit alors recevoir de tels éléments en provenance de chacun des fournisseurs
de services avec qui il communique. Les utilisateurs sont obligés de gérer des identités égales au
nombre de fournisseurs de services qu’ils veulent contacter pour demander des services.
Figure 3.2 : Modèle isolé de gestion des identités
Cette approche fournit des moyens pour une gestion des identités simple par les fournisseurs de
services mais qui devient rapidement ingérable pour les utilisateurs. Ceci rend ces systèmes
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
16 16
inadaptés aux environnements distribués collaboratifs où le nombre d’utilisateurs et de ressources
partagées ne cesse d’augmenter. En effet, la croissance du nombre de services en ligne induit au fait
que les utilisateurs deviennent débordés par les identificateurs et les attributs qu’ils doivent gérer. La
perte ou l’oubli de ces identificateurs et attributs coûtent chers aux fournisseurs de services qui
doivent mettre en place un centre de support (helpdesk) pour la récupération de ces éléments et
répondre aux demandes des utilisateurs.
3.2.2. Modèle centralisé de gestion des identités
Pour apporter une solution au problème de plus en plus critique d’exploitation des modèles
isolés, on peut alors chercher à centraliser l’information au sein d’un système. Un tel modèle se
décompose alors en un ensemble de sous modèles :
3.2.2.1. Modèle commun de gestion des identités
Pour ce modèle, un seul fournisseur d’identificateurs et d’attributs est utilisé par tous les
fournisseurs de services pour gérer les comptes de leurs utilisateurs. Dans ce cas de figure, une seule
autorité endosse les responsabilités d’identifier, d’affecter et de valider l’identité des utilisateurs
communiquant avec l’ensemble des fournisseurs de services .Un utilisateur s’authentifie auprès de
l’ensemble de fournisseurs de services en utilisant les mêmes identificateurs et attributs.
Figure 3.3 : le modèle commun de gestion d’identités
3.2.2.2. Domaine d’identité avec authentification unique : SSO
Cette approche étend le modèle de gestion des identités commun en permettant aux
utilisateurs de s’authentifier auprès d’un seul fournisseur de services du domaine et d’être par la
suite considérés comme authentifiés auprès des autres fournisseurs. Cette approche est
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
17 17
communément appelée authentification unique ou SSO parce qu’un utilisateur doit s’authentifier
une seule fois pour accéder à l’ensemble de services offerts par les fournisseurs du domaine
Figure 3.4 : le domaine d’identité avec authentification unique
Un exemple à citer utilisant ce modèle c’est Microsoft Windows Live ID (anciennement .Net
Passport) [Windows Live] qui est une implémentation de SSO pour le commerce électronique.
Windows Live ID permet, grâce à une unique adresse de messagerie et à un mot de passe, de se
connecter sur tous les sites web autorisés. L’affectation d’attributs et l’authentification des
utilisateurs sont deux fonctions centralisées sous le contrôle de Microsoft.
3.3. La fédération d’identités
3.3.1. Principe de fonctionnement
La fédération d’identité *Clusif 2007+ ou authentification répartie est un partage d’informations
d’identité concernant les utilisateurs d’un établissement, avec une organisation partenaire qui vise à
permettre l’accès à distance contrôlé et sécurisé aux ressources de ce partenaire.
La fédération concrétise, pour un groupement d’organisations, l'interconnexion de leurs services
d'authentification et l'utilisation d'un ensemble commun d'attributs utilisateurs.
Un établissement qui gère un ensemble d'utilisateurs (identificateurs et attributs) est appelé
fournisseur d'identités (IdP : Identity Provider). Un fournisseur de services (SP) est une entité (e.g.
établissement, administration, entreprise, etc.) qui propose une ressource numérique en ligne au
sein de la fédération.
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
18 18
Etablir une fédération d’identité entre organisations revient à définir un cercle de confiance
entre des fournisseurs d’identité et des fournisseurs de services de sorte que ces derniers acceptent
des accréditations émises par les fournisseurs d’identité pour leurs propres utilisateurs
Techniquement, les relations de confiance entre les membres d'une fédération reposent sur des
certificats électroniques et des métas donnés partagées. En outre, la confiance s'établit
administrativement entre les participants de la fédération au travers d'une convention (e.g. signature
de contrats entre organisations).
Une même organisation peut participer à plusieurs fédérations et gérer des partenariats de
manière bilatérale. Elle peut également jouer à la fois le rôle de fournisseur d'identités et de
fournisseur de services. La fédération d'identité est fondée sur deux concepts :
la délégation de l'authentification qui consiste à authentifier l'utilisateur depuis le service
d'authentification interne (organisation mère de l’utilisateur), et non pas depuis celui du
fournisseur de l'application (fournisseur de service)
la propagation des attributs utilisateurs qui permet de prolonger depuis l’organisation mère
de l’utilisateur l’exploitation d’un identifiant unique et des attributs de comptes internes afin
de communiquer avec le fournisseur de services.
3.3.2. Objectif de la Fédération d’identité
L’intérêt de l’adoption du principe de fédération d’identité est le fait que la fédération ne fait
qu’utiliser les moyens d’authentification, d’autorisation et de sécurisation implémentés par les
organisations partenaires ce qui favorise un déploiement rapide et à faible coût du réseau
collaboratif en évitant un blocage qui pourrait naître de l’absence d’un mécanisme commun
d’authentification.
Les principaux objectifs d’une fédération d’identité sont :
L’interconnexion de tout ou partie des Systèmes d’Information des organisations d’une façon
sécurisée et aisée,
Le partage de ressources de manière contrôlée et sécurisée. De ce fait, elle fournit le moyen
d’échanger de l’information de sécurité entre les domaines de sécurité *Federation 2007+.
Cette information permet de « reconnaître » un utilisateur au niveau du site partenaire et de
prendre la décision d’autorisation (autoriser/refuser l’accès de l’utilisateur à la ressource
demandée). Avec la fédération d’identité, l’hétérogénéité des systèmes d’authentification
(RADIUS, Kerberos, ICP X.509, etc.) des partenaires n’est plus un problème. Chaque
partenaire utilise les systèmes d’authentification et d’accréditation déployés au niveau de
son SI, gère les comptes et les accréditations de ses propres utilisateurs et transmet aux sites
partenaires l’information de sécurité qui sert à la prise de décision d’autorisation.
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
19 19
3.3.3. Langages pour l’échange de l’information de sécurité
Etant donné que dans le cadre d’un réseau distribué collaboratif, les systèmes déployés sont
plutôt hétérogènes, il s’est révélé indispensable d’exprimer l’information de sécurité dans un langage
qui soit compréhensible par tous les systèmes et les technologies existants : un langage indépendant
des plateformes ce qui permet un meilleur dimensionnement et favorise le passage à l’échelle. Ainsi,
un besoin de langages standardisés, pour l’expression de l’information de sécurité et pour offrir le
moyen de surpasser les limites des plateformes implémentées aux niveaux des sites partenaires, est
né.
L’information de sécurité (preuve d’authentification et les accréditations d’un utilisateur),
échangée entre les sites partenaires, peut être exprimée en utilisant des standards tels que Security
Assertion Markup Language (SAML) ou bien des spécifications telles que Web Services-Federation
(WS-Federation).
Sécurity Assertion Markup Language : SAML
SAML suppose qu’une entité (utilisateur ou application) possède déjà une identité unique gérée
par un IdP qui fournit localement un service pour authentifier cette entité. SAML ne spécifie pas (et
ne s’intéresse pas à) comment le service d’authentification local est implémenté ; c’est de cette
manière qu’il fournit une solution à l’hétérogénéité des systèmes d’authentification implémentés
chez les différentes organisations.
SAML 2.0, dans sa conception, fournit des solutions pour l’authentification unique(SSO),
interaction de Services Web en plus de la fédération d’identité. Ceci, dans le but de faire collaborer
des entités appartenant à des domaines de sécurité différents.
Web Services Fédération : WS-Fédération
WS-Federation, une spécification définie par IBM, Microsoft et d’autres sociétés, propose aux
organisations un moyen pour l’échange d’identités et d’attributs entre systèmes d’authentification et
d’autorisation distribués.
Le cadre de fédération défini par la spécification s’appuie sur la famille de spécifications
destinées aux Services Web WS-*. WS-Federation repose, en particulier, sur WS-Security3 et WS-
Trust4 et définit de nouveaux mécanismes de fédération étendant ces différentes spécifications. En
fait, l’objectif visé par WS Federation est d’aborder les exigences d’identités et de sécurité des
applications et des services Web. Ceci n’était pas un objectif de base lors de la définition du standard
SAML 2.0.
Les mécanismes de fédération définis dans la spécification WS-Federation peuvent être utilisés
par :
- Des Web Services (application cliente) supportant les mécanismes de WS-Security e
- WS-Trust et, pouvant communiquer avec un Web Service (application serveur)
- Des navigateurs Web étant donné que la spécification définit les mécanismes nécessaires à
l’encapsulation de messages WS-* en messages HTTP.WS-Federation adopte une approche
d’émission/d’échange de jetons de sécurité
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
20 20
En définitive des langages pour l’échange de l’information de sécurité, SAML 2.0 et WS-
Federation sont similaires en termes de fonctionnalités offertes.
Leurs spécifications introduisent les briques nécessaires à la gestion des cas de figures traitant la
fédération d’identité et le Web SSO.
D’un côté, SAML 2.0 est une spécification autonome. Le standard définit les profils et les
protocoles nécessaires à la prise en considération des cas de figures sans s’appuyer sur d’autres
technologies ou spécifications. De son côté, WS-Federation et en raison de son approche
composable, permet le déploiement des cas d'utilisation de différentes manières, mais cela se fait au
détriment de la simplicité. WS-Federation s’appuie sur WS-Trust, WSSecurityPolicy et sur d’autres
standards et spécifications pour traiter un cas d’utilisation. C’est cette approche composable qui
permet à WS-Federation d’être plus adaptée, que le standard SAML 2.0, aux architectures orientées
services (Web Services) en ce qui concerne la prise en considération de contraintes telles que la
propagation de l’identité du demandeur d’un Web Service, la délégation entre Web Services, etc.
3.4. Technologies de gestion d’identités
Parmi les technologies existantes qui fournissent un moyen de contrôler l’identité sans toutefois
être un vrai et un système complet de gestion des identités, nous citons :
3.4.1. Kerberos
Kerberos, créé au Massachusetts Institute of Technology (MIT), est un protocole d’identification
réseau conçu pour fournir un mode d’authentification forte pour les applications clients/serveurs en
utilisant le principe de chiffrement à clé secrète. Kerberos [Kerberos 1996] [Kerberos 2005] utilise un
système de tickets au lieu de mots de passe en texte clair ; ce principe renforce la sécurité du
système et empêche que des personnes non autorisées interceptent les mots de passe des
utilisateurs. Le ticket joue le rôle d'une carte d'identité à péremption assez courte.
L’identification Kerberos est utilisée par des protocoles/applications tels que Windows Server
2000, le serveur Web Apache, le client de transfert de fichiers FileZilla, etc.
Dans cette solution deux points particuliers sont à noter : les mécanismes de Chiffrement
renforcent l’aspect sécuritaire en proposant l’exploitation d’un système de gestion de clés. Le
système de tickets quant à lui offre une décorrélation entre celui qui en réclame l’obtention et
l’usage que l’on peut en faire. A la limite, en supposant que préalablement il y ‘ait eu une usurpation
d’identité réalisée en amont, le pirate peut obtenir très légitimement un droit d’accès à une
ressource sans qu’aucun mécanisme ne permette de revenir en arrière.
3.4.2. Radius
Remote Authentication Dial-In User Service (RADIUS), mis au point par la société Livingston
Enterprises, est un protocole client/serveur permettant de centraliser des données d'identification.
RADIUS [RADIUS 2000a] [RADIUS 2000b] est conçu pour gérer les connexions d'utilisateurs à des
services distants, et notamment ce qui relève de la politique d'autorisation, des droits d'accès et de
la traçabilité. Il base son identification sur le principe du couple nom d’utilisateur/mot de passe.
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
21 21
Le protocole RADIUS repose principalement sur un serveur RADIUS, relié à une base
d'identification (base de données, annuaire, etc.) et un client RADIUS, appelé Network Access Server
(NAS), faisant office d'intermédiaire entre l'utilisateur final et le serveur. L'ensemble des transactions
entre le client RADIUS et le serveur RADIUS est chiffré et authentifié grâce à un secret partagé. Le
serveur RADIUS peut transmettre les requêtes du client à d'autres serveurs RADIUS.
En termes de sécurité, les données transportées par RADIUS transitent en clair, seul le mot de
passe (de l’utilisateur final) est chiffré.
La sécurité impose la sécurisation des échanges entre les utilisateurs et le serveur par sécurité
physique ou à travers des solutions comme les Réseaux Privés Virtuels (VPN) [Scott et al. 1999].
RADIUS n'offre pas de mécanisme d’identification du serveur; il est alors tentant dans le cadre de
certaines attaques de se faire passer pour un serveur afin de récolter des noms et mots de passe.
Pour remédier à toutes ces faiblesses, des extensions ont été proposées pour RADIUS :
a) Extensible Authentication Protocol (EAP) [Saillard 2003] conçu pour étendre les fonctions du
protocole RADIUS à des types d'identification plus complexes. EAP permet ainsi une
identification mutuelle du client et du serveur.
b) Diameter [Calhoun et al. 2003] qui n'est pas vraiment une extension mais un successeur du
protocole RADIUS, est basé sur Transmission Control Protocol (TCP) alors que RADIUS est en
User Datagram Protocol (UDP)
Diameter utilise des attributs de grande taille et il est destiné aux échanges entre serveurs sur
des liaisons sûres en utilisant Internet Protocol Security (IPsec) et Transport Layer Security (TLS) par
exemple.
RADIUS est conçu pour fonctionner dans des réseaux d’infrastructures explicitement configurés
(réseaux des fournisseurs d’accès Internet, réseaux locaux sans fil, etc.). Il n’est pas adapté aux
réseaux d’ordinateurs et des stations de travail. En plus, il n’offre pas la fonctionnalité
d’authentification unique comme Kerberos.
Le principe de fonctionnement de Kerberos et de RADIUS repose respectivement sur La notion
de tickets et des mots de passe pour l’authentification des utilisateurs auprès des contrôleurs de
domaine (respectivement KDC et le serveur RADIUS). Afin de renforcer le niveau d’authentification
offert par les mots de passe et les tickets de services, la notion de clés publiques et de certificats
numériques est introduit. Clés publiques et certificats numériques sont gérés au niveau
d’infrastructures appelées Infrastructures à Clés Publiques.
3.4.3. Infrastructure à clé publique
Les Infrastructures à Clés Publiques ou PKI sont un ensemble de composants
Physiques (ordinateurs, équipements cryptographiques), de procédures humaines (vérification,
validation) et de logiciels (systèmes et applications) en vue de gérer le cycle de vie des certificats
numériques. Un certificat numérique est une carte d'identité numérique dont l'objet est d'identifier
une entité physique ; c’est un lien entre l'entité physique (le sujet) et l'entité numérique (clé
publique).
Une clé publique est une quantité numérique, attachée à une ressource ou un individu, qui
la distribue aux autres afin qu'ils puissent lui envoyer des données chiffrées ou pour qu’il puisse
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
22 22
déchiffrer sa signature. A chaque clé publique correspond une clé privée qui va être transmise à
l’entité physique avec son certificat numérique.
Une clé privée est une quantité numérique secrète attachée à une ressource ou à un
individu, lui permettant de déchiffrer des données chiffrées avec la clé publique correspondante ou
d'apposer une signature au bas de messages envoyés vers des destinataires.
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
23 23
Chapitre 4 : La gestion des accès
Il est évident que la gestion des identités des utilisateurs à elle seule n’est pas suffisante surtout
dans des environnements ouverts où les contraintes de sécurité pèsent énormément sur les
organisations membres. En effet, il ne suffit pas de répondre à la question : « qui peut accéder à la
ressource » mais en plus, il faut préciser « il peut faire quoi une fois qu’il a accédé ».
Les solutions telles que le SSO et la fédération d’identité étudiée dans le chapitre 3 offrent un
certain niveau d’autorisation lié à l’identité de l’utilisateur. En effet, avec le SSO, un utilisateur
s’authentifie une seule fois auprès d’un système et depuis, il peut accéder à tous les autres systèmes
qui sont dans le même domaine de confiance de ce système. De même pour la fédération d’identité
mais avec en plus l’accès à des systèmes qui se trouvent dans d’autres domaines de sécurité. Mais,
de notre point de vue et, dans les cas de figures où les contraintes de sécurité sont énormes, un tel
type d’autorisation n’est pas suffisant et devra être amélioré et renforcé. Dans ce chapitre, nous
expliciterons le concept de contrôle d’accès, puis présenterons les modèles existants de gestion des
accès et enfin nous expliciterons les architectures de gestion d’autorisation utilisées.
4.1. La gestion d’accès : le concept
4.1.1. Définition
Par la gestion des accès, nous entendons les systèmes qui peuvent avoir recours aux services
d'authentification et d'autorisation, afin de mieux maîtriser l'utilisation d'un réseau de ressources.
Chaque ressource, fournie par une organisation, est protégée par des règles qui la rendent accessible
uniquement aux entités ayant les accréditations nécessaires.
4.1.2. Principe de fonctionnement
La gestion des habilitations est basée sur les principes suivants :
tout accès au Système d’Information est conditionné par une authentification et une
autorisation. L’authentification peut être déléguée à un système tiers de confiance,
tout acteur du système est déclaré d’une manière unique dans un référentiel central de
sécurité en tant que personne physique et peut disposer de comptes dans différents
environnements et de permissions dans les applications en fonction des habilitations
accordées. La cohérence de ces informations est maintenue automatiquement par le système
de gestion des habilitations,
toute habilitation est attribuée en fonction du poste opérationnel au sein de l’organisation
et non à titre individuel. Le poste opérationnel détermine les rôles et les périmètres
Chapitre 4 : La gestion des accès
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
24 24
nécessaires. Le poste opérationnel (position de travail) correspond à une fonction métier
exercée au sein d’un élément de structure,
un utilisateur peut avoir un ou plusieurs profils. L’attribution se fait en fonction du poste
opérationnel de l’utilisateur,
un profil regroupe un ensemble de rôles nécessaires à l’exécution d’une fonction métier,
un rôle définit les permissions nécessaires à l’utilisation d’une application ou des ressources,
Les définitions des rôles, profils ainsi que l’attribution des profils aux personnes se font via un
outil central qui propage ensuite les informations nécessaires vers toutes les applications et
environnements concernés. L’association personne / rôle applicatif (ou profil applicatif) est
gérée hors application, lorsque l’application l’autorise. Cela permet d’éviter d’avoir à
développer une gestion des droits des utilisateurs dans l’application,
l’association personne / rôle applicatif est gérée de façon statique et explicite dans l’annuaire
de sécurité (plutôt que de façon dynamique à base de règles de gestion organisationnelles).
L’évaluation des droits, par le système de contrôle d’accès, doit être basée pour l’essentiel
sur la consultation de ce rôle applicatif explicite (pas d’interprétation de règles complexes
dans le processus d’autorisation),
un contrôle permanent de l’adéquation des profils attribués aux rôles effectifs des
personnes, la définition des droits d’accès aux ressources ou aux groupes de ressources est
administré dans les environnements cibles via les outils natifs de ces environnements. Les
administrateurs locaux continuent de gérer les ressources elles-mêmes et leurs associations
avec les habilitations,
le contrôle d’accès lui-même est assuré soit par les composants du socle technique (cas de
ressources et applications Web) soit par les mécanismes natifs des environnements (OS,
NOS, messagerie, groupware, etc) soit par les applications.
Il est à noter donc que les informations nécessaires à la gestion des habilitations sont distribuées
dans différents référentiels. On distingue :
a. le référentiel des habilitations, référentiel mis à jour lors de la gestion des utilisateurs,
des habilitations et des mots de passe,
b. les annuaires de sécurité, qui ne contiennent qu’une partie des données du référentiel
des habilitations (par exemple, les profils n’y figurent pas) et sont utilisés par les services
d’authentification et d’autorisation, tels que :
o Systèmes d’exploitation,
o Sous systèmes de gestion des droits,
o LDAP,
o NOS (Network Operating Systems) et systèmes de partage des fichiers,
o Messageries et systèmes collaboratifs.
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
25 25
4.2. Modèles de gestion d’accès
4.2.1. Modèle RBAC
Le modèle de sécurité RBAC (Role Based Access Control) est principalement issu d'Internet afin
de prendre en compte des applications déployées sur de vastes organisations ou des applications
inter-organisations (Extranet par exemple). Ce modèle permet en particulier de simplifier
l'administration des droits et de prendre en compte la délégation de l'administration.
Le modèle RBAC modélise des fonctions métiers plutôt que des accès à des ressources
informatiques. Un rôle correspond à une fonction au sein d'une organisation. Le principe de base du
RBAC est que deux utilisateurs ayant les mêmes rôles ont les mêmes droits sur le système.
Modèle RBAC de base
Le standard propose un modèle de base (Core RBAC) ainsi que les extensions présentées dans
les sous-chapitres suivants.
Les concepts manipulés par le modèle RBAC sont les suivants : USERS (utilisateurs), ROLES, OBS
(objets), OPS (opérations), PRMS(Permissions), SESSIONS.
Suivant le schéma ci-dessus :
Figure 4.1 : Modèle RBAC de base
Principe de privilège minimum
Le fonctionnement de ce modèle et l’intégrité du système sont garantis si l’attribution des
permissions respecte le principe de privilège minimum.
Ce principe exige que l’utilisateur ne dispose pas de plus de droits que nécessaire à son travail.
Ce qui implique que les permissions affectées à un rôle constituent le strict minimum nécessaire à
l’accomplissement des tâches relatives à ce rôle.
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
26 26
Modèle RBAC hiérarchique
Le modèle RBAC hiérarchique (Hierarchical RBAC) ajoute au modèle de base le support de
hiérarchie des rôles.
La hiérarchie établit les liens de parenté entre plusieurs niveaux des rôles et permet aux rôles «
parents » de disposer des permissions attribuées aux rôles « enfants ».
Le standard admet deux types de hiérarchies :
a) Le modèle hiérarchique général (General Hierarchical RBAC) : cette variante établie des
relations multiples entre plusieurs « parents » et « enfants »,
b) Le modèle hiérarchique limité (Limited Hierarchical RBAC) : cette version limite la
relation à une simple structure d’arborescence. Ce qui veut dire qu’un rôle ne peut avoir
qu’un seul « parent ».
Cette extension du modèle permet une administration plus efficace dans les grandes structures
qui gèrent de très nombreuses permissions d’un grand nombre d’utilisateurs. D’autre part ce
principe permet de bien gérer les situations où certains rôles différents (du niveau supérieur) doivent
bénéficier de certaines permissions communes.
Modèle RBAC avec contraintes
Le modèle RBAC avec contraintes (Constrained RBAC) ajoute au modèle la contrainte de
séparation des pouvoirs. Cette contrainte permet d’inclure dans le modèle la gestion de conflits
d’intérêts et assurer que les utilisateurs bénéficieront des permissions selon la politique définie par
l’organisation et ne pourront pas abuser de cumul non contrôlé de droits.
a) Séparation Statique des Pouvoirs (SSD - Static Separation of Duty Relations)
La contrainte de séparation des pouvoirs est utilisée pour assurer le respect de la politique des
habilitations. Un conflit d’intérêts peut arriver (dans un système du type RBAC) quand l’utilisateur
obtient simultanément les droits associés à des rôles incompatibles.
L’exclusion mutuelle de certains rôles est spécifiée par les règles de SSD. Ces règles sont
interprétées lors du processus d’affectation des rôles par l’administrateur et l’empêchent d’affecter
des rôles incompatibles au même utilisateur. De cette manière, à une personne qui bénéficie d’un
rôle, on ne pourra pas affecter un deuxième rôle interdit par la règle de SSD.
b) Séparation Dynamique des Pouvoirs (DSD - Dynamic Separation of Duty Relations)
La séparation dynamique limite comme la SSD les rôles accessibles à un utilisateur. Par contre le
contexte est différent. La limitation n’est pas exploitée au moment de l’affectation des rôles mais au
moment de leur activation dans une session. Dans une même session, un utilisateur a la possibilité
de ne pas activer tous ses rôles, mais uniquement le sous-ensemble de ses rôles nécessaires à la
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
27 27
réalisation de la tâche à accomplir. Ce mécanisme permet de garantir l’application des permissions
minimales nécessaires dans une période d’exécution d’une tâche. On peut parler, dans ce contexte,
de révocation temporaire des privilèges. La mise en œuvre de ce mécanisme peut se révéler très
complexe et le plus souvent n’est pas réalisée.
4.2.2. Modèle MAC
En opposition avec le DAC où le propriétaire d’une ressource jouit de tous les droits sur une
ressource qu’il a créée, le modèle Mandatory Access Control est utilisé quand la politique de sécurité
d’une organisation définit que :
a) les décisions de protection d’une ressource ne doivent pas être sous la responsabilité de
son propriétaire,
b) le système doit mettre en œuvre les mécanismes permettant de respecter la politique de
sécurité et interdire au propriétaire d’une ressource d’agir à sa guise.
Afin d’aboutir à ces principes, ce modèle introduit la notion d’accès aux ressources en regard de
la sensibilité des informations qu’elles contiennent et repose sur la labellisation systématique de ces
ressources et des utilisateurs du système considéré. En hiérarchisant ces entités en plusieurs niveaux
de confiance et sensibilité, puis en les labélisant en conséquence, on aboutit à une décomposition à
laquelle il faudra ensuite ajouter des règles d’accès. On notera qu’un système informatique adhérant
à ce principe est dit multi-level security (MLS).
Les labels suivent une logique hiérarchique (ex: Confidentiel, Secret, Très secret, non classifié) et
décrivent ainsi différents niveaux d’habilitation. Les droits d’accès aux ressources sont attribués en
fonction du niveau d’habilitation de l’utilisateur et sont définis selon la problématique de sécurité à
adresser : Confidentialité ou Intégrité.
4.2.3. Modèle DAC
Le DAC (Discretionary Access Controls) est un modèle conceptuel dont le principe est de limiter
l’accès à des objets en regard de l’identité des utilisateurs (humain, machines, etc.) et/ou des
groupes auxquels ils appartiennent. Les contrôles sur une ressource sont dits discrétionnaires dans le
sens où un utilisateur avec une autorisation d'accès définie est capable de la transmettre
(indirectement ou directement) à n'importe quel autre utilisateur.
Ce modèle est principalement utilisé au sein d’implémentations informatiques car les notions
développées sont surtout adaptées à la gestion d’accès sur des ressources informatiques. Ainsi, les
implémentations adhérant à ce concept, doivent mettre en œuvre des mécanismes permettant
d’enregistrer un ensemble de droits d’accès ou d’actions représentées sous la forme d’une matrice
de contrôle d’accès.
Fichier Gisèle Fichier Danny
Gisèle rwx r
Léa r
Danny r rwx
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
28 28
Parmi les différentes implémentations réalisées, les plus connues sont :
Protection Bits: Popularisée par les systèmes Unix, cette implémentation représente la
matrice de droits d’accès par colonne. Son principe consiste à définir pour une ressource
si elle est partagée pour tous les utilisateurs, un groupe ou seulement son propriétaire,
Access Control Lists (ACLs): Le principe des ACLs implémente la matrice de contrôle
d’accès par colonne en créant des listes d’utilisateurs pouvant accéder à la ressource
et/ou des listes d’utilisateurs interdits d’accès à celle-ci,
Capabilities: Comme pour les ACL une liste est créée, mais elle est liée à un utilisateur et
non à une ressource, ainsi la représentation de la matrice est faite par ligne.
4.3. Architectures de gestion d’accès
4.3.1. Architectures AAA
Une architecture d’autorisation doit complémenter le concept de fédération d’identité que nous
avons adopté pour l’échange d’information de sécurité sur les utilisateurs entre les fournisseurs
d’identité et les fournisseurs de services.
Des architectures d’autorisation bâties autour d’un serveur unique qui assure des fonctionnalités
d’authentification, d’autorisation et de comptabilité (AAA : Authentication Authorization Accounting)
se révèlent comme une solution possible pour répondre aux besoins relevés en termes de gestion
d’accès (qui a droit de faire quoi, comment et dans quelles circonstances).
Les entités de base qui participent à une autorisation dans le cadre d’une architecture AAA sont :
- Un utilisateur qui demande un service,
- L’organisation de tutelle de l’utilisateur concomitante du contrat établi et qui doit vérifier
sous une forme active ou passive si l’utilisateur est habilité ou non à déclencher l’exécution
du service,
- Le serveur AAA du fournisseur de services qui autorise l’accès au service en se basant sur le
contrat signé avec l’organisation mère de l’utilisateur et
- L’équipement du fournisseur de services dédié à l’approvisionnement du service
Ce concept de serveur AAA permet de faire la rupture définitive entre services d’authentification
et d’autorisation d’un côté et les applications gérées d’un autre côté mais, ça reste une solution de
gestion centralisée.
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
29 29
Figure 4.2 : Architecture AAA
4.3.2. Infrastructures de gestion à base de politiques
Les systèmes de gestion à base de politiques sont une solution de remplacement des ACLs
intégrées habituellement aux applications gérées. Elles rendent la gestion plus dynamique et
évolutive. Avec une telle approche, pour une autorisation efficace, deux actions doivent être
réalisées :
- Une décision d’autorisation doit être prise après consultation de politiques et,
- La décision doit être appliquée.
Ces deux fonctions sont accomplies par deux entités distinctes nommées
Respectivement PDP (Policy Décision Point) et PEP (Policy Enforcement Point).
Un PDP est une entité logique qui prend des décisions d’autorisation en considérant les
informations suivantes :
o La ressource demandée et l’action requise (consultation, modification, etc.),
o L’entité qui demande la ressource et,
o La politique qui gère l’accès à la ressource.
Un PEP est une entité logique qui applique la décision d’autorisation prise par le PDP. C’est le PEP
qui réalise techniquement l’attribution ou le refus d’une demande d’accès à une ressource. Les
interactions entre PDPs et PEPs peuvent suivre l’un des modèles suivants :
Modèle Agent, permet à l’utilisateur d’adresser sa requête de demande de ressource, à une
partie tierce (le serveur d’autorisation : PDP/PEP). Ce dernier joue le rôle d’agent entre
l’utilisateur et l’équipement fournissant le service.
Modèle Push, L’utilisateur adresse sa requête directement au fournisseur de service (i.e. la
ressource demandée) et en particulier, au serveur d’autorisation (PDP) qui gère l’accès à la
ressource
Modèle Pull. Le modèle Pull laisse la responsabilité de la récupération de l’information
d’autorisation au PEP seul. Une fois que l’utilisateur a demandé l’accès à une ressource
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
30 30
4.3.3. Infrastructures de gestion des privilèges
Une IGP fournit un cadre d’autorisation basé sur les attributs des utilisateurs pour gérer les
accès aux ressources et aux services. L’utilisation de certificats d’attributs rend le service
d’autorisation plus flexible et rigide et, c’est pour cette raison que nous avons adopté le concept
d’IGP pour bâtir une architecture de contrôle d’accès.
Une IGP fournit un cadre dans lequel il est possible d’appliquer la politique d’autorisation
d’accès ou d’attribution au niveau des applications ou des ressources en fonction du rôle des
utilisateurs ou de leur appartenance à un groupe. Un rôle dépend de la position de l’utilisateur (e.g.
ingénieur, cadre, technicien) dans son organisation de rattachement. Le processus de définition de
rôles est fondé sur une analyse approfondie de la façon dont fonctionne une organisation et intègre
une contribution d'un large éventail d'utilisateurs dans une organisation.
En d’autres termes, une IGP permet l’allocation, la délégation, la révocation et le retrait des
privilèges ou droits des utilisateurs d’une façon électronique.
Au sein d’une Infrastructure de Gestion de Privilèges, des politiques de contrôle d’accès gérant
l’accès aux ressources protégées doivent être définies, évaluées et appliquées. Ces politiques de
contrôle d’accès viennent remplacer les listes de contrôle d’accès (ACLs) qui étaient définies et
intégrées aux ressources auxquelles elles s’appliquent.
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
31 31
Troisième partie : Implémentations et expérimentations
3ème partie : Implémentations et
expérimentations
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
32 32
Chapitre 5 : Les solutions de contrôle d’accès
Dans ce chapitre, il sera question d’étudier quelques logiciels de gestion d’identités et des droits
d’accès qui sont présents actuellement sur le marché, tant sur l’environnement windows et
l’environnement linux.
5.1. Architectures de gestion d’accès
De nombreuses offres de solutions de gestion des identités et des droits d’accès existent sur le
marché ; et de plus en plus d’entreprise ont du mal à faire un choix de solutions optimales en
présence de ces nombreux logiciels d’IAM.
Cependant une solution de gestion d’accès doit respecter au minimum certains critères et c’est à
partir de ces critères que le choix des logiciels présentés ci-dessous s’est opérer. Parmi les critères de
choix d’une solution de gestion des identités et des accès nous avons retenus:
Facilité de déploiement et de configuration
Ce critère est intéressant car il n’est pas question de demander à l’entreprise de modifier la
structure de son système d’information. La solution devra être déployé et configuré facilement
indépendamment de l’existant.
Approche adoptée pour gérer la fédération
Ce critère permet d’évaluer la facilité de l’intégration de l’outil à l’existant dans l’entreprise et
définir la stratégie de déploiement de l’outil dans l’infrastructure TI.
Conformité au langage d’échange de l’information SAML 2 et WS-Federation
Un outil qui ne supporte pas les langages SAML ou WS-Federation, ne pourra pas être utilisé
sinon un problème d’hétérogénéité surgit.
Possibilité de fédérer l’identité entre les web-services
Ce critère permet d’évaluer l’efficacité de l’outil car un jour ou l’autre, les organisations auront à
traiter des identités dans le cadre d’architectures orientées services.
Le coût de la solution
Ce critère est toujours critique dans le choix d’une solution à déployer par les organisations.
Support pour différents systèmes hétérogènes
Chapitre 5 : Les solutions de
contrôle d’accès
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
33 33
Un outil de fédération qui va s’intégrer au SI d’une organisation doit supporter les systèmes
d’authentification déployés et utilisés jusqu’à présent par l’organisation. Une remise à zéro ne sera
jamais acceptée.
Niveau de sécurité offerte
Ceci présente un critère critique pour les organisations qui vont accepter d’ouvrir leurs SI aux
partenaires en s’appuyant sur l’outil de fédération. En aucun cas, les organisations n’accepteront de
se baser sur une solution de fédération pouvant leur risquer la perte de leurs actifs.
Respect de la vie privée
Ceci pourrait être critique ou pas, tout dépend de la stratégie adoptée par les partenaires
concernant la conservation de la vie privée des entités communicantes.
5.2. Les solutions de gestion d’identités et de droits d’accès
5.2.1. Les solutions propriétaires
Tivoli Identity management d’ IBM
IBM Tivoli Identity Manager est une solution d'applications des accès utilisateur basée sur des
règles qui gère les rôles, identités et droits d'accès des utilisateurs dans toute l'infrastructure
informatique. Ce logiciel sécurisé de gestion des identités est facile à déployer et à utiliser. Il permet
aux organisations de se mettre en conformité avec les réglementations, de gérer les risques et
autorise une collaboration sécurisée.
Tivoli Identity Manager permet de réaliser des économies et d'améliorer la productivité grâce à
l'automatisation, le libre-service utilisateur et d'autres innovations.
IBM propose aussi la solution pour l’identité fédérée dénommé Tivoli Federated Identity
Manager (TFIM).
Identity & accès management d’Evidian
Des centaines de milliers d'utilisateurs accèdent à leurs applications chaque jour par
l'intermédiaire des solutions de gestion de l'authentification d'Evidian. Le single sign-on (SSO)
simplifie leur travail car ils n'ont pas besoin de mots de passe pour accéder à leurs applications. Cela
réduit considérablement la charge du help desk, assurant un retour sur investissement rapide. Les
accès aux PC et aux applications peuvent faire l'objet d'une authentification forte par carte à puce,
badge radio, biométrie ou mot de passe à usage unique. La demande de mot de passe en self-service
(SSPR) rend les utilisateurs autonomes : les employés en déplacement ne sont jamais bloqués parce
qu'ils ont oublié leurs données d'authentification.
Avec les solutions IAM d'Evidian, les entreprises déploient la gestion des identités et un
workflow d'approbation pour s'assurer que les utilisateurs individuels respectent la politique d'accès
aux applications. Les solutions d'Evidian sont conçues pour être adaptables et compatibles avec les
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
34 34
processus d'entreprise, notamment en termes de disponibilité et de mobilité. Ainsi, la sécurité
renforce l'activité de l'entreprise.
Oracle Identity and accès management
La suite complète d'Oracle offre le meilleur retour sur investissement : sécurité accrue, coûts
administratifs allégés, grande évolutivité et la garantie de support d'un leader du marché. Les
solutions offertes de sont :
Oracle Access Management Suite Plus
Oracle Access Manager
Oracle Adaptive Access Manager
Oracle Directory Services Plus
Oracle Enterprise Single Sign-On Suite
Oracle Entitlements Server
Oracle Identity Analytics
Oracle Identity Federation
Oracle Identity Manager
Oracle Identity & Access Management Suite Plus
Oracle Information Rights Management
Oracle Management Pack for Identity Management
Oracle Role Manager
Oracle Security Governor for Healthcare
Oracle Web Services Manager
Oracle Identity and accès management est présenté comme l’offre de solutions la plus
complète.
Services Active directory de Microsoft
Les services Active Directory sont utilisés dans la plateforme système Windows server et
incluent : Les services de certificats Active Directory (AD CS),
Les services de domaine Active Directory (AD DS),
Les services AD FS (Active Directory Federation Services),
Les services AD LDS (Active Directory Lightweight Directory Services) et les services AD RMS
(Active Directory Rights Management Services).
Ces services seront expérimentés dans le chapitre suivant
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
35 35
5.2.2. Les solutions propriétaires
Plusieurs solutions libres existent mais de nombreuses critiques sont apportés notamment :
souvent hétérogènes et non-interopérable, complexes à mettre en œuvre, souvent de qualité
médiocre, souvent mal supportées, souvent peu industrialisés, souvent peu robuste.
Cependant, Nous avons pu étudier quelques des solutions open source de gestion d’identité et
d’accès :
Internet2 shibboleth
Shibboleth est une suite de logiciels développée par le consortium Internet2, fournissant une
solution complète de fédération d’identités.
Les trois briques Shibboleth sont le fournisseur de services, le fournisseur d’identités et le
service de découverte (ou WAYF).
Le fournisseur de services est un module d'authentification pour le serveur Web ; il permet de :
- déléguer l'authentification des utilisateurs à un fournisseur d'identités ;
- transmettre le profil utilisateur ;
- gérer le contrôle d'accès de manière optionnelle.
Le fournisseur d'identités est une application Java (servlet) ; il permet de gérer l'authentification
des utilisateurs, en réponse à la requête d'un fournisseur de services. L'authentification peut être
déléguée à un serveur CAS (Central Authentication Service) : l'authentification se fait par login/mot
de passe ou certificat électronique ou encore propose les deux ; les attributs de l'utilisateur sont
extraits d'un annuaire LDAP, d'une base SQL ou bien calculés, puis propagés au fournisseur de
services.
Le service de découverte (WAYF) permet à un utilisateur de sélectionner son organisme de
rattachement, c'est-à-dire celui auprès duquel il pourra s'authentifier. Le service de découverte
propose un menu déroulant à l'utilisateur avec la liste des fournisseurs d'identités reconnus.
FederID
FederID est une solution qui intègre les projets libres suivants :
- Authentic : un fournisseur d'identités basé sur lasso (Liberty Alliance SSO) capable d'utiliser
un annuaire LDAP comme base d'authentification.
- LemonLDAP::NG : un portail SSO compatible Liberty Alliance, dont les autorisations sont
gérées directement dans l'annuaire LDAP.
- InterLDAP : un outil de gestion de contenu d'annuaires LDAP et fournisseur d'attributs sur un
cercle de confiance Liberty Alliance.
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
36 36
OpenIAM
Multiplate-forme (Unix, mac,windows), openIAM est la solution open source de gestion d’accès
et d’identité qui fournit les services tel que : provisionning, gestion des mots de passe, administration
déleguée, synchronisation active, moteur de workflow… Elle inclut les connecteurs pour LDAP,
Active Directory, Google Apps et les bases de données relationnelles.
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
37 37
Chapitre 6 : Implémentation d’une solution de contrôle d’accès
Dans ce chapitre, il sera question de présenter la solution de contrôle d’accès Active Directory et ses services et de le mettre en œuvre par son déploiement.
6.1. Environnement de travail
La solution Active Directory est implémentée dans l’environnement serveur Windows Server
2008 R2.
Pour ce qui est de Windows Server 2008 R2, la version Windows Serveur 2008 R2 Edition Enterprise
a été utilisé.
Nous avons installé ce système serveur en dual boot sur une machine physique aux
caractéristiques telles que nous la voyons sur la copie d’écran :
Figure 6.1 : Information système générale
Nous avons bénéficié des nouvelles fonctionnalités de Windows Server 2008 R2 tel que Hyper-V
pour virtualiser les rôles de serveur et client sous forme de machines virtuelles séparées s’exécutant
sur l’unique ordinateur physique, sans avoir à acquérir un logiciel tiers.
Pour cela, nous avons créé 03 machines virtuelles (01 serveur et 02 clients) :
Les caractéristiques d’un poste serveur sont :
• Matériel : Processeur 1 Ghz, RAM 512 Mo, DD 40 Go, architecture 64bits
• Logiciel : Windows Server 2008 R2 Edition Entreprise
Les caractéristiques d’un poste client sont :
• Matériel : Processeur 1 Ghz, RAM 512 Mo, DD 20 Go, architecture 32bits
• Logiciel : Windows XP, Windows 7
Chapitre 6 : Implémentation d’une
solution de contrôle d’accès
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
38 38
6.2. Présentation d’Active Directory
Active Directory est le nom du service d'annuaire (au sens informatique) de Microsoft. AD
permet de regrouper toutes les informations concernant le réseau, que ce soient les utilisateurs, les
machines ou les applications. L'utilisateur peut ainsi trouver facilement des ressources partagées, et
les administrateurs peuvent contrôler leurs utilisations grâce à des fonctionnalités de sécurisation
des accès aux ressources répertoriées.
AD a pour objectif de permettre la gestion des comptes, des ordinateurs, des ressources et de la
sécurité de façon centralisée, dans le cadre d’un domaine. Un domaine constitue un ensemble
d’utilisateurs et de machines dont le contrôle est centralisé.
6.2.1. Active Directory et services d'accès et d'identité
Active Directory fournit la solution d'identité et d'accès (IDA) pour les réseaux d'entreprise
fonctionnant sous le système d'exploitation Windows®. IDA est nécessaire pour préserver la sécurité
des ressources de l'entreprise telles que les fichiers, les e-mails, les applications et les bases de
données. L'infrastructure IDA devrait effectuer les opérations suivantes :
Stocker des informations sur les utilisateurs, les groupes, les ordinateurs et les autres
identités. Comme nous l'avons vu, une identité est une représentation d'une entité qui
effectue des actions dans le réseau de l'entreprise. Par exemple, un utilisateur ouvre des
documents dans un dossier partagé sur un serveur. Vous savez que le document est
sécurisé avec des autorisations sur une liste ACL. L'accès au document est géré par le
sous-système de sécurité du serveur qui compare l'identité de l'utilisateur aux identités
de la liste ACL pour déterminer si la demande d'accès de l'utilisateur doit être accordée
ou refusée. Des ordinateurs, des groupes, des services et d'autres objets effectuent
également des actions sur le réseau ; ils doivent être représentés par des identités. Parmi
les informations stockées sur une identité, il y a les propriétés qui identifient de manière
unique l'objet, telles qu'un nom d'utilisateur ou un SID et le mot de passe de l'identité. Le
magasin d'identités est donc un composant d'une infrastructure IDA. La banque de
données Active Directory, également appelée annuaire est un magasin d'identités.
L'annuaire lui-même est hébergé et géré par un contrôleur de domaine : un serveur
jouant le rôle AD DS.
Authentifier une identité. Le serveur n'accorde pas à l'utilisateur l'accès au document à
moins qu'il ne soit sûr de la validité de l'identité présentée dans la demande d'accès. Pour
valider l'identité, l'utilisateur fournit des secrets connus uniquement par lui-même et
l'infrastructure IDA. Ces secrets sont comparés aux informations du magasin d'identités
lors d'un processus appelé authentification.
Dans un domaine Active Directory, un protocole appelé Kerberos est utilisé pour
authentifier les identités. Lorsqu'un utilisateur ou un ordinateur ouvre une session sur le
domaine, Kerberos authentifie ses informations d'identification et émet un ensemble
d'informations appelé ticket d'accord de ticket (TGT). Pour que l'utilisateur puisse se
connecter au serveur et demander le document, une requête Kerberos est envoyée à un
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
39 39
contrôleur de domaine avec le TGT qui permet d'identifier l'utilisateur authentifié. Le
contrôleur de domaine envoie à l'utilisateur un autre ensemble d'informations appelé
ticket de service qui identifie l'utilisateur authentifié sur le serveur. L'utilisateur présente
le ticket de service au serveur qui l'accepte comme preuve d'authentification de
l'utilisateur.
Ces transactions Kerberos conduisent à une connexion réseau unique, ou authentification
unique. Après l'ouverture de session initiale de l'utilisateur ou de l'ordinateur et la remise
d'un TGT, l'utilisateur est authentifié dans l'ensemble du domaine et peut recevoir des
tickets de service qui l'identifient auprès de n'importe quel service. Toute cette activité de
tickets est gérée par les clients et services Kerberos intégrés à Windows et est
transparente pour l'utilisateur.
Contrôler l'accès. L'infrastructure IDA est responsable de la protection des informations
confidentielles telles que les informations stockées dans le document. L'accès aux
informations confidentielles doit être géré conformément aux stratégies de l'entreprise.
L'ACL sur le document reflète une stratégie de sécurité composée d'autorisations qui
spécifient des niveaux d'accès pour des identités particulières. Le sous-système de
sécurité du serveur dans cet exemple effectue la fonctionnalité de contrôle d'accès dans
l'infrastructure IDA.
Fournir une piste d'audit. Une entreprise peut souhaiter surveiller les modifications et les
activités au sein de l'infrastructure IDA. Elle doit donc fournir un mécanisme permettant
de gérer les audits.
Les services de domaine Active Directory constituent le plus important composant d'une
infrastructure IDA, mais d'autres composants IDA sont aussi pris en charge par Windows Server
2008. Avec Windows Server 2008, Microsoft a regroupé un certain nombre de composants
auparavant distincts dans une plate-forme IDA intégrée.
• Services AD LDS (Active Directory Lightweight Directory Services)
• Services de certificats Active Directory (AD CS)
• Services AD RMS (Active Directory Rights Management Services)
• Services ADFS (Active Directory Federation Services)
Chacun de ces services joue un rôle dans l'extension d'IDA pour prendre en charge des configurations
et des scénarios plus complexes.
6.2.2. Arborescence Active Directory
Une arborescence Active Directory est composée de :
• La forêt : ensemble d’un ou plusieurs domaines Active Directory
• L'arbre : Représente le domaine et toutes ses ramifications. domaine.com,
sous1.domaine.com, sous2.domaine.com et projet.sous1.domaine.com forment un arbre
• Le domaine : constitue les feuilles de l'arborescence.
projet.sous1.domaine.com peut-être un domaine au même titre que domaine.com
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
40 40
Figure 6.2 : Arborescence Active Directory
Dans le cadre de ce travail, en partant du principe que l’on a qu’un seul domaine, on va donc avoir
une forêt composé d’un domaine qui sera le domaine racine.
6.3. Création d’une nouvelle forêt avec Windows Server 2008
Avant d'installer le rôle AD DS sur un serveur et promouvoir son action en contrôleur de
domaine, vous devez planifier votre infrastructure Active Directory. Les informations à rassembler
pour créer un contrôleur de domaine pour notre projet test sont les suivantes :
Nom de l’ordinateur SRVDC01
Nom DNS du domaine twmicronics.ads
Configuration IP pour le contrôleur de domaine
IP v4 : 192.168.11.1
Masque : 255.255.255.0
DNS : 192.168.11.1
Nous allons maintenant installer et configurer un contrôleur de domaine Windows Server 2008
« SRVDC01 ».
Cette étape s'effectue en exécutant l'Assistant Installation des services de domaine Active
Directory. Cet Assistant, également appelé DCPromo car il peut être lancé à l'aide de la commande
dcpromo.exe, vous guide à travers les étapes du processus de sélection de la configuration du
déploiement, en ajoutant des fonctions de contrôleur de domaine supplémentaires telles que le rôle
DNS (TWMicronics.ads), en définissant le niveau fonctionnel de la forêt (Windows Server 2008 R2),
en spécifiant l'emplacement des fichiers Active Directory (par défaut) et en configurant le Mot de
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
41 41
passe administrateur de restauration des services d'annuaire. Ce mot de passe est utilisé lors de la
restauration d'Active Directory à partir d'une sauvegarde.
Une fois l’installation d’Active Directory terminée, redémarrez le serveur.
Vous devez maintenant trouver en plus dans les « Outils d'administration », « DNS » et « Utilisateurs
et ordinateurs Active Directory ».
6.4. Gestion des utilisateurs et des ordinateurs
6.4.1. Unité d’organisation
Une unité d’organisation (OU, Organizational Unit) est un conteneur dans lequel on va pouvoir
mettre des utilisateurs, des groupes, des ordinateurs ainsi que d’autres OU.
On peut grâce aux OU représenter une certaine architecture pouvant ou non représenter la
structure de l’entreprise.
Des stratégies de groupes peuvent être affectées à une OU et on pourra déléguer
l’administration de celle-ci et son contenu à un administrateur par exemple.
On peut donc donner les autorisations à un utilisateur, de modifier les objets contenus dans une
OU par exemple. Avec la structure d’OU que l’on peut mettre en place, la délégation d’administration
est simplifiée et la gestion plus facile en séparant les différents privilèges accordées en fonction des
différentes OU.
Dans ce travail de recherche, nous allons créer une architecture de test à partir des OUs pour
simuler l’architecture d’une entreprise.
On va crée ensuite des groupes et des utilisateurs de test que l’on va répartir dans ces OUs en
fonction de leur rôle. Des stratégies de groupes vont être finalement appliquées aux OUs pour
fournir une infrastructure au sein de laquelle les paramètres peuvent être définis de façon
centralisée, puis déployés dans les ordinateurs et pour les utilisateurs de l'entreprise.
Pour créer une OU il suffit de faire un clic droit à l’endroit où l’on veut créer l’OU et de faire,
« Nouveau » puis de choisir « Unité d’Organisation » :
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
42 42
Figure 6.3 : Architecture Active Directory de l’entreprise
6.4.2. Compte d’utilisateurs
Un objet utilisateur, appelé généralement compte d'utilisateur, contient le nom et le mot de
passe de l'utilisateur qui servent d'informations d'identification d'ouverture de session. Un objet
utilisateur contient également d'autres attributs qui décrivent et gèrent l'utilisateur.
Nous allons créer des utilisateurs que nous allons répartir dans ces OU en fonction de leur rôle.
Des autorisations vont être finalement appliquées aux OU pour accorder ou non aux utilisateurs
présents dans ces OU des tâches d’administrations, comme par exemple la gestion des utilisateurs, la
gestion des ordinateurs de l’entreprise ou encore la gestion du serveur DNS (Domain Name System).
Certains utilisateurs peuvent donc avoir plusieurs rôles d’administration à gérer et l’on peut avoir des
utilisateurs avec plus ou moins de privilèges que d’autres.
Certaines pourront par exemple crée de nouveaux utilisateurs alors que d’autres ne pourront que
modifier les informations de comptes déjà existants.
Il existe beaucoup de scénarios possibles que l’on peut appliquer à une l’entreprise. Cela dépend par
exemple du niveau de sécurité que l’on veut pouvoir garantir, du nombre d’administrateurs délégués
que l’on veut avoir, du nombre de tâches d’administration à effectuer ou encore de la complexité de
l’architecture de l’entreprise.
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
43 43
Pour créer un objet utilisateur :
Cliquez avec le bouton droit de la souris sur l'UO ou le conteneur dans lequel vous voulez créer
l'utilisateur, pointez sur Nouveau et cliquez sur Utilisateur. Puis vous remplissez les champs par les
informations souhaitées comme illustrée dans la page suivante :
Figure 6.4 : informations d’un utilisateur
Chaque utilisateur devra pouvoir se connecter par le login suivant :
Première lettre du prénom, nom complet, par exemple Danny BATOMEN devra taper : DBatomen
Le mot de passe sera Miage12
Les utilisateurs ne pourront pas changer de mot de passe. La figure ci-dessous représente la liste des
utilisateurs de l’OU « Personnels » :
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
44 44
Figure 6.5 : Liste des utilisateurs de l’OU « Personnels »
6.4.3. Groupe Active Directory
Les groupes dans Active Directory servent à rassembler plusieurs objets comme des utilisateurs
ou des ordinateurs dans une même entité pour simplifier l’administration.
Lors de l’installation de l’annuaire AD, le système installe certains groupes et utilisateurs par
défaut avec des droits et des autorisations prédéfinis. Comme par exemple à l’installation de
Windows Seven où le système installe les comptes « administrator » et « guest » par défaut.
Il existe plusieurs sortes de groupes, on différentie ceux-ci avec une caractéristique appelée
« étendue de groupe » ou « Group Scope ». Celle-ci va permettre de restreindre l’accès à des objets
de la forêt.
On peut observer trois sortes de groupes :
Domain Local Groups
Généralement ce groupe est utilisé lorsque l’on veut appliquer des autorisations pour l’accès à
une application. On ne peut assigner des autorisations que sur les ressources se trouvant dans le
même domaine que là où le groupe a été crée.
On peut ajouter des utilisateurs de n’importe quel domaine au groupe « Domain Local Groups ».
Global Groups
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
45 45
On utilise souvent ce type de groupe pour rassembler des utilisateurs afin de simplifier
l’administration. Dans ce groupe, on ne peut ajouter que des utilisateurs faisant partis du même
domaine que le « Global Groups » créé.
Universal Groups
Ce type de groupe est généralement utilisé lorsque l’on veut partager des ressources entres
plusieurs domaines par exemple ou lorsque l’on veut regrouper plusieurs « Global Groups » entre
eux. On peut ajouter des utilisateurs de n’importe quel domaine à ce groupe.
Dans ce projet, l’utilisation de groupes universelle est inutile étant donné que l’on a qu’un seul
domaine.
6.4.4. Implémentation de la gestion a base des rôles en utilisant des groupes
Pour améliorer la gestion des accès aux ressources de notre organisation, nous avons décidé
d'implémenter la gestion à base de rôles. La gestion à base de rôle est un concept utilisé en
informatique et dans la protection des informations et elle est accessible avec les fonctions standards
d'Active Directory. IGDLA est l'implémentation de la gestion à base de rôles en utilisant des groupes
Active Directory.
La première opération consistera à déterminer les personnes autorisées à accéder aux
informations des ventes. Nous devons créer des groupes afin de gérer l'accès à ces informations
confidentielles. Selon les règles de l'entreprise par exemple, les employés du département Ventes et
Marketing et de l'équipe des Finances sont autorisés à consulter les dossiers des ventes. De plus,
l’utilisateur Guy WASSEU nécessite un accès en lecture.
Nous allons implémenter la gestion à base de rôles en utilisant des groupes et la meilleure
pratique de stratégie d'imbrication de groupes, IGDLA. Nous allons créer différents étendues et types
en utilisant le composant logiciel enfichable Utilisateurs et ordinateurs.
1) Créer des groupes de rôles avec Utilisateurs et ordinateurs Active Directory
• Créez les groupes de sécurité globaux, par exemple Sales dans l'UO Groupes\Roles.
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
46 46
Figure 6.6 : Les groupes de rôles
• Puis ajouter des utilisateurs au groupe de rôles.
Figure 6.7 : Utilisateurs membres d’un groupe
2) Créer des groupes de gestion des accès aux ressources.
• Créez par exemple le groupe de sécurité local de domaine ACL_Sales Folders_Read dans l'UO
Groups\Access.
• Affecter des autorisations au groupe de gestion des accès aux ressources
• Dans D:\Data, créez le dossier Sales.
• Cliquez avec le bouton droit de la souris sur le dossier Sales, puis cliquez sur Propriétés et sur
l'onglet Sécurité.
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
47 47
Figure 6.8 : les propriétés d’un dossier partagé
• Cliquez sur Modifier et sur Ajouter.
• Tapez ACL_ et appuyez sur ENTRÉE.
Notez que lorsque vous utilisez un préfixe pour les noms de groupe, tel que ACL_ pour les groupes
d'accès aux ressources, vous pouvez les retrouver rapidement.
• Cliquez sur ACL_Sales Folders_Read et sur OK.
• Vérifiez que le groupe a bien reçu l'autorisation de lecture et d'exécution.
Figure 6.9: Les autorisations
• Cliquez sur OK pour fermer la boîte de dialogue ouverte.
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
48 48
Figure 6.10 : Les groupes de règles
Déterminer les rôles et les utilisateurs qui peuvent accéder à une ressource.
• Ajoutez Sales, Finances, et Guy WASSEU au groupe ACL_Sales Folders_Read.
6.4.5. Mises des machines clientes dans le domaine
Avec votre client XP ou Seven, intégrez le domaine TWMicronics.ads (clic droit > propriétés sur le
poste de travail, onglet nom de l'ordinateur).
Indiquez un nom d'utilisateur du groupe Admins du domaine pour vous connecter.
La copie d’écran suivante illustre les postes client mis dans le domaine de l’OU « PC Privés »:
Figure 6.11 : Postes de l’OU « Privés »
6.5. Amélioration de la sécurité et piste d’audit
La sécurité est au centre des préoccupations de la plupart des entreprises d'aujourd'hui.
Alors que les organisations œuvrent à la suppression des privilèges administratifs superflus qui ont
été attribués par le passé aux utilisateurs, elles s'efforcent également de verrouiller et de gérer les
privilèges accordés aux administrateurs eux-mêmes. Pour gérer la sécurité de l’administration
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
49 49
d’Active Directory, il est indispensable de comprendre comment certaines tâches d’administration
sont déléguées et comment l’audit des activités liées à l’authentification est effectué.
6.5.1. Délégation des autorisations administratives
Pour augmenter la sécurité au maximum dans l’annuaire Active Directory, il est recommandé
d’utiliser le principe du moindre privilège. Un utilisateur à qui on confie une tâche d’administration,
doit seulement pourvoir exécuter les tâches associées à son rôle.
On crée donc un compte spécifiquement pour chaque tâche d’administration à qui on attribue
un certains nombres d’autorisations en fonction du rôle du compte. Aucune autre action ne doit
pouvoir être effectuée à partir de ce compte. De cette façon le principe du moindre privilège est
respecté.
Si un utilisateur est chargé de la gestion des comptes par exemple, il ne doit pas pouvoir
intervenir sur la configuration DNS du serveur ou pouvoir supprimer des ordinateurs de l’annuaire.
6.5.1.1. Approche de la délégation
Les politiques de sécurité étant généralement différentes au sein des divisions et les équipes IT
mêmes, il convient de trouver une solution afin de déléguer les tâches nécessaires au travail de
chacun sans pour autant compromettre la sécurité de tout le domaine Active Directory.
La structure d’un domaine Active Directory est organisée par défaut de façon hiérarchique. Il est en
effet possible de déléguer des tâches au niveau d’une forêt, d’un site, d’un domaine ou bien même
d’une unité d’organisation. De plus, chaque objet possédant des attributs avec des DACL
(Discretionary Access ControlList) associées à ces derniers, il est également possible de déléguer des
options de façon assez fine (réinitialiser le mot d’un utilisateur, autoriser la désactivation d’un
compte utilisateur, etc.). Nous passerons à la pratique un peu plus loin.
Avant de vous lancez dans la configuration de la délégation de votre Active Directory, il convient de
bien étudier les besoins auxquels vous devez répondre.
6.5.1.2. Délégation des comptes utilisateurs.
Passons maintenant à la pratique en déléguant deux actions particulièrement utiles à la hotline
et au support informatique d’une entreprise. Ces services n’ayant pas pour vocation d’effectuer des
tâches administratives lourdes sur l’Active Directory, il serait démesuré d’ajouter ces derniers au
groupe « Administrateurs du domaine » par exemple.
Parmi les besoins les plus demandés par ces services afin de répondre aux demandes utilisateurs,
vous trouverez notamment le droit de joindre un poste à un domaine Active Directory et le droit de
réinitialiser les mots de passe des utilisateurs.
Les délégations s’effectuent généralement sur tout ou partie des objets d’une unité d’organisation
ou d’un domaine. Cela a pour but de simplifier l’administration et la gestion des droits de votre
Active Directory. Inutile de vous rappelez qu’il est d’ailleurs impératif de garder une trace des
délégations effectuées afin de faciliter l’administration quotidienne et les opérations de dépannage
en cas de problème.
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
50 50
Prenons comme besoin celui du service de support technique qui souhaite pouvoir déverrouiller les
comptes d’utilisateurs, réinitialiser les mots de passe et imposer aux utilisateurs de changer de mot
de passe à la prochaine ouverture de session.
Cette autorisation se limitera aux comptes d'utilisateur standard et ne permettra pas au support
technique de modifier les mots de passe de comptes administratifs. Vous allez également déléguer
au groupe Administrateurs de comptes d’utilisateurs l’autorisation de créer et supprimer des
comptes d’utilisateurs, ainsi qu’un contrôle total sur les comptes d’utilisateurs. Tous les membres du
groupe utilisateurs font partie du même OU nommé utilisateurs.
Afin de déléguer ces droits, Microsoft met à disposition un assistant délégation. Pour cela, placez-
vous au niveau de l’objet ou du conteneur parent depuis lequel vous souhaitez effectuer une
délégation de droits. Dans la plupart des cas, cette délégation s’effectue au niveau d’une unité
d’organisation.
• Faites alors un clic avec le bouton droit de la souris sur l’objet et choisissez Délégation de
contrôle.
Figure 6.12: délégation de contrôle
• Cliquez sur Suivant dans l’écran de bienvenue. L’assistant vous demande alors de
sélectionner les utilisateurs ou groupes pour lesquels les droits délégués seront attribués.
• Cliquez sur Ajouter puis tapez le nom de votre groupe et Vérifier les noms puis OK.
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
51 51
Figure 6.13: Ajout d’un compte
• Une fois le ou les groupe(s) ajouté(s), cliquez sur Suivant.
Vous pouvez maintenant choisir le niveau de permissions qui sera appliqué à l’objet délégué.
Vous avez le choix entre choisir des délégations prédéfinies pour des tâches courantes ou bien de
définir une tâche personnalisée à déléguer.
Dans notre exemple, nous pourrions choisir les tâches prédéfinies mais celles-ci permettraient
trop de droits comparés à ce que nous souhaitons autorisés.
• Choisissez donc de Créer une tâche personnalisée à déléguer afin de pouvoir effectuer
une délégation très granulaire puis cliquez sur Suivant.
• Choisissez de déléguer le contrôle Seulement des objets suivants dans le dossier et
cochez ObjetsUtilisateur puis Suivant.
• Sélectionnez alors le ou les types d’autorisations que vous souhaitez déléguer aux
utilisateurs.
Dans notre exemple l’attribut Modifier le mot de passe(ou Change Password en anglais) est
utilisé pour la réinitialisation du mot de passe et les attributs Lire lockout Time(ou Read lockout
Time) et Ecrire Lockout Time(ou Write lockout Time) sont utilisés pour déverrouiller un compte
utilisateur. Les deux derniers attributs ne sont visibles qu’en cochant la cases spécifiques aux
propriétés car comme son nom l’indique, ils sont spécifiques à l’objet Utilisateur.
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
52 52
Figure 6.14 : les autorisations a délégué
• Une fois les trois cases cochées, cliquez sur Suivant.
Une fenêtre récapitulative indique les différents choix effectués au cours de l’assistant
délégation.
• Sur la page de Fin de l’Assistant Délégation de contrôle, cliquez sur Terminer., les ACL
(liste de contrôle d’accès) seront modifiés sur l’OU Utilisateur.
6.5.2. Configuration des paramètres de mot de passe et de
verrouillage
Afin d’améliorer la sécurité et de contrôler l’authentification pour le domaine AD DS de
l’entreprise. Nous devons appliquer une stratégie de mot de passe précise pour tous les comptes
d'utilisateur, ainsi qu'une stratégie de mot de passe plus stricte pour des comptes administratifs
sensibles sur le plan de la sécurité.
6.5.2.1. Configuration des stratégies de comptes du domaine
Active Directory prend en charge un seul ensemble de stratégies de mot de passe et de
verrouillage par domaine. Ces stratégies sont configurées dans un objet GPO étendu au domaine. Un
nouveau domaine contient un objet GPO appelé Stratégie de domaine par défaut. Celui-ci est lié au
domaine et il contient les paramètres par défaut des stratégies de mot de passe, de verrouillage de
compte et Kerberos.
Les stratégies de mot de passe et de verrouillage se composent des éléments suivants :
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
53 53
Tout au long de ce travail, nous allons modifier ces paramètres en modifiant la stratégie de domaine
par défaut.
• Exécutez le composant logiciel enfichable Gestion des stratégies de groupe
• Modifiez l’objet GPO Stratégie de domaine par défaut.
• Configurez les paramètres de stratégie de mot de passe ci-dessous. Conservez-les valeurs par
défaut des autres paramètres.
- Durée de vie maximale du mot de passe : 90 jours
- Longueur minimale du mot de passe : 10 caractères
Figure 6.15 : Les paramètres de stratégies de mot de passe
• Configurez le paramètre de stratégie de verrouillage de compte ci-dessous.
- Conservez les valeurs par défaut des autres paramètres.
- Seuil de verrouillage de compte : 5 tentatives d’ouverture de session non valides.
Stratégies Paramètre par défaut
Stratégie de mot de passe
Conserver l’historique des mots de passe 24 mots de passe
Durée de vie maximale du mot de passe 42 jours
Durée de vie minimale du mot de passe 1 jour
Enregistrer les mots de passe en utilisant un chiffrement réversible
Désactivé
Le mot de passe doit respecter des exigences de complexité
Activé
Longueur minimale du mot de passe 7 caractères
Stratégie de verrouillage du compte
Durée de verrouillage des comptes Non défini
Réinitialiser le compteur de verrouillages Non défini
Seuil de verrouillage du compte 0 tentatives d’ouverture de session non valide
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
54 54
Figure 6.16 : Les paramètres de stratégie de verrouillage du compte
• Fermez l’Éditeur de gestion des stratégies de groupe et la Gestion des stratégies de groupe.
6.5.2.2. Stratégie de mot de passe affinée On pouvait remplacer la stratégie de mot de passe et de verrouillage du domaine par le biais d’une
nouvelle fonctionnalité de Windows Server 2008 appelée stratégie de mot de passe et de
verrouillage affinée, souvent abrégée sous la forme stratégie de mot de passe affinée. La stratégie de
mot de passe affinée permet de configurer une stratégie qui s’applique à un ou plusieurs groupes ou
utilisateurs du domaine comme illustrée sur la diapositive suivante :
Figure 6.17 : Les stratégies affinées
6.5.3. Audit de l’authentification de connexion
Une stratégie d’audit définit les types d’événements de sécurité que Windows Server 2008
enregistre dans le journal de sécurité sur chaque ordinateur. Windows Server 2008 consigne les
événements dans le journal de sécurité de l’ordinateur lorsque l’événement se produit.
La configuration d’une stratégie d’audit pour un ordinateur permet de :
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
55 55
suivre l’aboutissement ou l’échec d’événements tels que les ouvertures de session, la lecture
d’un fichier donné par un certain utilisateur, ainsi que les modifications apportées à un
compte d’utilisateur ou une appartenance de groupe et aux paramètres de sécurité ;
réduire les risques d’utilisation non autorisée des ressources ;
conserver un enregistrement des activités des utilisateurs et administrateurs.
Utilisez l’Observateur d’événements pour voir les événements que Windows Server 2008
enregistre dans le journal de sécurité.
Dans ce travail, nous allons utiliser la Stratégie de groupe pour activer l’audit des connexions
réussies et celles ayant échoué, qui ont été initiées par les utilisateurs du domaine twmicronics.ads.
Nous génèrerons ensuite des événements de connexion et examinerons les entrées résultantes dans
les journaux d’événements.
1. Configurer l’audit des événements de connexion aux comptes
• Exécutez la Gestion des stratégies de groupe
• Modifiez l’objet de stratégie de groupe de la stratégie par défaut des contrôleurs de domaine
pour activer l’audit des événements de connexion aux comptes qui ont réussi et ceux qui ont
échoué.
Figure 6.18 : paramètres d’audit
• Fermez l’Éditeur de gestion des stratégies de groupe.
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
56 56
2. Configurer l’audit des événements de connexion
• Créez un objet de stratégie de groupe (GPO) lié à l’UO Servers\Important Project. Nommez
l’objet GPO Server Lockdown Policy.
• Modifiez la stratégie Server Lockdown Policy pour activer l’audit des événements de
connexion aux comptes qui ont réussi et ceux qui ont échoué.
• Fermez l’Éditeur de gestion des stratégies de groupe et la Gestion des stratégies de groupe.
3. Forcer une actualisation de la Stratégie de groupe
Le client de stratégie de groupe du poste récupère la configuration (par défaut au bout de 90 à
120 minutes) qui est applicable à l’ordinateur et/ou à l’utilisateur connecté.
Pour forcer l'application des GPO, vous pouvez utiliser la commande : gpupdate /force
4. Examiner les événements de connexion
• Exécutez l'Observateur d'événements pour identifier les événements ayant échoué et les
événements réussis dans le journal Sécurité.
Figure 6.19 : observateur d’événements
6.6. Configuration du service DNS
DNS (Domain Name System) est un service de noms qui fait la correspondance (le mappage)
entre les noms d’ordinateurs (nom d’hôte) et les adresses IP. C’est une base de données
distribuée hiérarchisée.
• Exécutez la console Gestionnaire DNS « Démarrer », « Outils d’administration », « DNS »
• Développez le noeud sur « Zone de recherche directe (nom du serveur : ici SRVDC01) », vous
remarquez que dans le volet d’informations (la partie droite de la console), on trouve des
dossiers (encadrés en rouge sur la copie d'écran) qui sont indispensables au bon
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
57 57
fonctionnement du serveur et des stations XP, Vista et Seven ainsi qu'aux éventuels autres
serveurs du réseau.
Figure 6.20 : La zone de recherche directe du domaine
• Créer une « Zone de recherche inversée » en faisant clic droit sur « Zone de recherche
inversée (nom du serveur : ici SRVDC01), « Nouvelle zone » »
• « Zone principale », Rentrez le « ID réseau »
Figure 6.21: Assistant de création de la zone de recherche inversée
• « Suivant », « Suivant » et « Terminer ».
• Créez un pointeur correspondant au serveur dans la zone de recherche inversée.
• Redémarrez le serveur DNS.
• Puis vérification du DNS avec la commande « nslookup ».
La commande « nslookup » est intégrée au système d'exploitation.
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
58 58
« nslookup » permet de tester la résolution des noms d'hôtes en adresses IP et inversement. On
utilise « nslookup » pour vérifier le bon fonctionnement du serveur DNS.
Lorsque l'on tape nslookup en mode texte, une invite de commande apparaît. Le nom d'hôte et
l'adresse IP du serveur DNS par défaut sont affichés.
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
59 59
CONCLUSION GENERALE
Le sujet consacré a notre étude portant sur « les systèmes de gestion d’identités et
droits d’accès : mise en œuvre et apport pour la sécurité d’une organisation » a été
l’occasion pour nous de comprendre et d’expérimenter les concepts liés au domaine de la
sécurité informatique.
Un tel système dans une organisation est une solution centralisé adapté pour la gestion
de ces acteurs (partenaires, clients, employés…) et le contrôle d’accès aux ressources
(matérielles ou logicielles).Sa mise en place est certes couteuses, mais le retour sur
investissement est très visible car facilite largement l’administration des acteurs, et accroît
fortement la productivité au sein d’une organisation.
De nombreuses entreprises dans le monde sont conscients de l’apport d’un système de
gestion d’identités et d’accès, c’est pourquoi plusieurs solutions existe sur le marché afin de
satisfaire les demandeurs car chacun ayant des besoins spécifiques. Par conséquent le
domaine de la sécurité informatique est constamment en évolution pour intégrer les
nouvelles technologies.
Conclusion Générale
Les systèmes de gestion des identités et des accès :
Mise en œuvre et apport pour la sécurité d’une organisation
Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012
xv xv
BIBLIOGRAPHIE
Livres, Documents [Abi Haidar et al. 2006] Abi Haidar D., Cuppens-Boulahia N., Cuppens F. et DebarH.,"An extended
RBAC profile of XACML", CCS, USA, November 2006.
[Abou El Kalam et al. 2003] Abou El Kalam A., Baida R., Balbiani P., Benferhat S., Cuppens
[Federation 2007] "The business value of identity federation", a Computer Associates white
*Clusif 2007+ Fédération d’identité, "Gestion des Identités", dossier technique, groupe
"Gestion des identités", juillet 2007.
[Kamel et al. 2006] Kamel M., Benzekri A., Barrère F., Nasser B., "Information Security
[Kerberos 1996] Kerberos, http://www.ietf.org/rfc/rfc1964.txt, 1996
[Kerberos 2005] Kerberos, http://www.ietf.org/rfc/rfc4120.txt, 2005
[Saillard 2003] Saillard C., "802.1X : Solution d'authentification sécurisée pour le futur réseau sans fil
de l'Université Louis Pasteur", Centre Réseau Communication, Université Louis Pasteur, Strasbourg,
2003.
*Scott et al. 1999+ Scott C., Wolfe P., Erwin M., "Virtual Private Networks", O’REILLY, 211 p., ISBN 1-
56592-529-7, 1999.
Webographie
[AAA 2000a] AAA Authorization Framework,
http://www.ietf.org/rfc/rfc2904.txt?number=2904, 2000
[AAA 2000b] AAA Authorization Requirements,
http://www.ietf.org/rfc/rfc2906.txt?number=2906, 2000
[Windows Live] Windows Live ID, http://msdn2.microsoft.com/fr-fr/library/aa479889.aspx
Bibliographie