IAM Gestion Des Identites Et Des Acces

IAM :
GESTION DES IDENTITES

ET DES ACCES
CONCEPTS ET ETATS DE LART
Rfrence : IAM - Gestion des identits et des accs : concepts et tats de lart
Date de dernire mise jour : 12/09/2013
Version du document : 1.1
Etat : en cours termin valid
Auteurs : Guillaume HARRY
Licence : Contenu sous licence Creative Commons CC-BY-NC-ND
Objet du document :
Ce document dcrit les concepts et les meilleures pratiques pour la gestion des identits et des
accs.
Contenu sous licence Creative Commons CC-BY-NC-ND
TABLE DES MISES A JOUR DU DOCUMENT

Version du
document
Date
Objet de la mise jour
1.0
01/06/2013
Cration du document
1.1
04/06/2013
Anonymisation des exemples
LISTE DES ABREVIATIONS

ABAC :
Attribute Based Access Control (anglais)

Contrle daccs bas sur les attributs (franais)
ACL :
Access Control List (anglais)

Liste de contrle des accs (franais)
CIL :
Correspondant Informatique et Liberts
CNIL :
Commission Nationale Informatique et Liberts
CRBAC : Constrained Role Based Access Control (anglais)

Contrle daccs bas sur les rles avec contraintes (franais)
CRBF :
Comit de Rglementation Bancaire et Financire
DAC :
Discretionary Access Control (anglais)

Contrle daccs discrtionnaires (franais)
HRBAC : Hierarchical Role Based Access Control (anglais)

Contrle daccs bas sur les hirarchies de rles (franais)
IAM :
Identity & Access Management (anglais)

Gestion des Identits et des Accs (franais)
IBAC :
Identity Based Access Control (anglais)

Contrle des accs bas sur lidentit (franais)
IdP :
Identity Provider (anglais)

Fournisseur didentit (franais)
IUP :
Identifiant Unique Personnel
MAC :
Mandatory Access Control (anglais)

Contrle daccs obligatoire (franais)
NIST :
National Institute of Standards and Technology
PDCA :
Plan Do Check Act/Adjust (anglais)

Planifier Dployer Contrler Agir/Ajuster (franais)
RBAC :
Role Based Access Control (anglais)

Contrle daccs base sur les rles (franais)
RP :
Relying Party (anglais)

Consommateur (franais)
SMSI
Systme de Management de la Scurit de lInformation
SoD :
Segregation of Duty (anglais)

Sparation des responsabilits (franais)
SOX :
Sarbanes-Oxley
SP :
Service Provider (anglais)

Fournisseur de service (franais)
SSO :
Single Sign-On (anglais)

Authentification unique (franais)
II
SOMMAIRE
1. I NTRODUCTION ............................................................................ 1
2. G ESTION DES IDENTITES .............................................................. 2
2.1 Dfinitions ............................................................................................................... 2
2.1.1 Identit.............................................................................................................. 2
2.1.2 Attributs et identifiants..................................................................................... 2
2.1.3 Fournisseurs de service et didentit ................................................................ 3
2.1.4 Fdration didentit ........................................................................................ 4
2.1.5 Gestion des identits ........................................................................................ 4
2.1.6 Exemples .......................................................................................................... 5
2.2 Modles ................................................................................................................... 7
2.2.1 Identit isole ................................................................................................... 7
2.2.2 Identit fdre ................................................................................................. 8
2.2.3 Identit centralise ......................................................................................... 10
2.3 Cadre rglementaire .............................................................................................. 14
3. G ESTION DES ACCES ................................................................... 16

3.1 Dfinitions ............................................................................................................. 16
3.1.1 Ressources et gestion des accs ..................................................................... 16
3.1.2 Comptes utilisateurs ....................................................................................... 16
3.1.3 Habilitations et contrle daccs .................................................................... 17
3.1.4 Rle, profil, groupe et primtre .................................................................... 17
3.1.5 Authentification et autorisation ...................................................................... 19
3.1.6 Exemples ........................................................................................................ 20
3.2 Modles ................................................................................................................. 21
3.2.1 Identity based access control (IBAC) ............................................................ 22
3.2.2 Mandatory Access Control (MAC) ................................................................ 22
3.2.3 Role Based Access Control (RBAC) ............................................................. 23
3.2.4 Attribute Based Access Control (ABAC) ...................................................... 25
3.2.5 Organization Based Access Control (OrBAC) .............................................. 25
3.2.6 Comparaison .................................................................................................. 26
3.3 Cadre rglementaire .............................................................................................. 26
3.3.1 Loi amricaine Sarbanes-Oxley ..................................................................... 26
3.3.2 Accords internationaux Ble II ...................................................................... 27
3.3.3 Loi de scurit financire (LSF) .................................................................... 28
3.3.4 CRBF 97-02 ................................................................................................... 28
4. B ONNES PRATIQUES .................................................................... 30

4.1 Normes .................................................................................................................. 30
4.1.1 ISO-24760 ...................................................................................................... 30
4.1.2 ISO-2700x ...................................................................................................... 30
4.2 Dmarche projet oriente gestion des identits et des accs ................................. 32
III
5. G LOSSAIRE ................................................................................. 34
6. B IBLIOGRAPHIE .......................................................................... 36
6.1
6.2
Rfrences documentaires ..................................................................................... 36

Rfrences Internet ................................................................................................ 37
A NNEXE 1. ISO 24760 (T ABLE DES MATIERES ) ................................. 38

A NNEXE 2. ISO-27002 (T ABLE DES MATIERES - C HAPITRE 11) ......... 39
A NNEXE 3. G ESTION DE PROJET ....................................................... 40
1.
2.
3.
4.
5.
Cycle de vie ............................................................................................................. 40

Cycle en cascade ...................................................................................................... 41
Cycle en V ............................................................................................................... 42
Cycle en spirale........................................................................................................ 44
Mthodes Agiles ...................................................................................................... 46
A NNEXE 4. T HE M ANIFESTO FOR A GILE S OFTWARE D EVELOPMENT 48

A NNEXE 5. G RILLE D EVALUATION TECHNIQUE ................................ 49
1. Gestion des identits ................................................................................................ 49
2. Gestion des accs ..................................................................................................... 50
IV
LISTE DES FIGURES

Figure 1 - Diagramme de classe du concept d'identit ............................................................... 2
Figure 2 Diagramme de classe des concepts dattribut et didentifiant .................................. 3
Figure 3 - Cycle de vie dune identit ........................................................................................ 5
Figure 4 Modle de gestion didentit : identit isole ..................................................... 7
Figure 5 - Modle de gestion didentit : identit fdre ................................................... 9
Figure 6 - Modle de gestion didentit : identit commune ............................................. 11
Figure 7 - Modle de gestion didentit : mta-identit ..................................................... 12
Figure 8 - Modle de gestion d'identit : Single Sign-On .................................................. 13
Figure 9 - Diagramme de classe des comptes .......................................................................... 17
Figure 10 - Diagramme de classe des habilitations .................................................................. 19
Figure 11 - Processus itratif PDCA de la norme ISO-27001 ................................................. 31
Figure 12 - Cycle de vie de projet en cascade .......................................................................... 41
Figure 13 - Cycle de vie de projet en V ................................................................................... 42
Figure 14 - Diagramme d'activit d'une dmarche itrative ..................................................... 44
Figure 15 - Diagramme d'activit de ralisation d'un prototype .............................................. 44
Figure 16 - Cycle de vie de projet en spirale ............................................................................ 45
Figure 17 - Cycle de vie en Agilit .................................................................................... 47
LISTE DES TABLEAUX

Tableau I - Exemple d'identits .................................................................................................. 6
Tableau II - Exemple de services ............................................................................................... 6
Tableau III - Synthse de l'exemple pour le modle didentit isole ....................................... 8
Tableau IV - Synthse de l'exemple pour le modle didentit fdre ................................... 10
Tableau V - Synthse de l'exemple pour le modle didentit commune ................................ 11
Tableau VI - Synthse de l'exemple pour le modle de mta-identit ..................................... 12
Tableau VII - Synthse de l'exemple pour le modle de Single Sign-On ................................ 13
Tableau VIII - Exemple de comptes utilisateurs ...................................................................... 20
Tableau IX - Exemple de rles applicatifs ............................................................................... 21
Tableau X - Exemple de profils ............................................................................................... 21
Tableau XI - Exemple de matrice ACL du modle IBAC ....................................................... 22
Tableau XII - Exemple d'implmentation du modle MAC .................................................... 23
Tableau XIII - Grille d'valuation technique : Rfrentiel intgr ........................................... 49
Tableau XIV - Grille d'valuation technique : Connecteurs .................................................... 49
Tableau XV - Grille d'valuation technique : Transformation ................................................. 49
Tableau XVI - Grille d'valuation technique : Provisioning .................................................... 50
Tableau XVII - Grille d'valuation technique : Gestion des rles ........................................... 50
Tableau XVIII - Grille d'valuation technique : Gestion des habilitations .............................. 50
Tableau XIX - Grille d'valuation technique : Gestion des mots de passe .............................. 51
Tableau XX - Grille d'valuation technique : Contrle et traabilit ....................................... 51
VI
1. Introduction
La notion dquipe virtuelle ou dentreprise virtuelle est ne dans les annes 1990 pour
dcrire les nouvelles formes de management et dchanges numriques inter-quipes ou interentreprises. Lorganisation virtuelle est dfinie comme une alliance temporaire
dorganisations (institutions, industries, entreprises, )
indpendantes, connectes,
gographiquement dissmines, incluant un haut niveau de confiance qui collaborent et
partagent leurs ressources et comptences dans le but de rpondre aux demandes des
clients [1]. Ce nouveau schma dorganisation a pour objectif de mener bien un projet et
prend fin quand la phase de production commence. Ainsi, lquipe forme de lensemble des
personnes impliques dans les diffrentes phases, incluant les membres des maitrises
douvrage, des maitrises duvre et des fournisseurs, peut tre dfinie comme une
organisation virtuelle.
1
Comme pour tout projet, le succs rside sur une relation de confiance autour du partage
des connaissances et des comptences. La communication est donc un facteur cl de russite
de ce type particulier dorganisation o les distances et la dmatrialisation sont une
difficult. En effet, toutes les personnes participantes doivent avoir accs aux informations et
outils mis en commun au moment opportun.
La flexibilit est une autre caractristique des organisations virtuelles. En effet, leur
nature dynamique est due la participation ponctuelle des membres. Les participants
rejoignent et quittent le projet en fonction des comptences requises dans les diffrentes
phases. La complexit se situe pour les coordinateurs dans la fourniture rapide dun accs aux
moyens mis en commun et dans la rvocation de ces autorisations aussitt aprs leur dpart.
Les responsables doivent galement sassurer que le savoir-faire acquis ainsi que les
ralisations soient prservs et partags mme aprs la fin de la collaboration.
Les technologies de linformation et de la communication mis en uvre ont alors pour
objectif de mettre en relation les membres de lquipe virtuelle et les systmes dinformations
des organisations physiques dorigine impliques dans le partenariat. La difficult rside alors
dans les diffrences au niveau des infrastructures et des politiques de scurits implmentes
par chacun des partenaires. Chacun dentre eux doit sinterconnecter avec les autres et
permettre le partage des ressources tout en prservant la scurit de sa propre organisation [2].
Tous doivent offrir un moyen de communication assurant lintgrit et la confidentialit des
donnes. De mme, ils doivent disposer dun moyen de vrifier lidentit des personnes et des
systmes qui prennent part dans la collaboration.
2
[1] M.R. Nami, A. Malekpour. Virtual Organizations : Trends and Models. Dans IFIP International Federation
for Information Processing, Volume 288; Intelligent Information Processing IV; Zhongzhi Shi, E. MercierLaurent, D. Leake, p 190199, 2008
[2] J. Magiera, A. Pawlak. Security Frameworks for virtual organizations. Dans Organizations: Systems and
Practices. Springer, pages 133-148, 2005
2. Gestion des identits

2.1 Dfinitions
2.1.1 Identit
Dans larticle Trust Requirements in Identity Management [3], lidentit est dfinie
comme un ensemble de caractristiques propres par lesquelles une personne ou une
organisation est connue ou reconnue. Ces lments peuvent tre dfinis, comme le nom,
ladresse, la nationalit, ou peuvent tre inns comme les empruntes digitales. Pour lidentit
dune organisation, les caractristiques sont acquises .
Le standard international ISO/IEC 24760-1 [4], bas sur la recommandation UIT-T Y.2720
rdige par l'Union Internationale des Tlcommunications, tend la dfinition didentit
l information utilise pour reprsenter une entit dans un systme dinformation et de
communication . Une entit reprsente une personne physique ou morale (organisation,
entreprise, ), une ressource (un objet tel quun matriel informatique, un systme
dinformation ou de communication) ou un groupe dentits individuelles.
3
Une entit peut possder plusieurs identits numriques. Chaque identit permet alors
dexposer des informations en fonction de lenvironnement. Ainsi, un individu peut prsenter,
par exemple, des informations publiques le concernant dans le cadre de son activit
professionnelle, ce qui reprsentera une identit, et dautres informations personnelles le
prsentant dans son contexte familial, ce qui dsignera une autre identit.
Une identit peut tre utilise dans plusieurs contextes. Conjointement, dans un mme
domaine, une entit peut tre incarne par plusieurs identits. De plus, plusieurs identits
dune mme entit peuvent partager les mmes caractristiques, ce qui implique que les
identits peuvent ne pas tre uniques dans un mme contexte.
Figure 1 - Diagramme de classe du concept d'identit
Dans le prsent document, le terme didentit fera rfrence une identit numrique
limite aux informations utilises dans le contexte professionnel dont lemployeur doit grer
le cycle de vie.
2.1.2 Attributs et identifiants
Lattribut dune identit dcrit une caractristique dune entit dans un contexte
dtermin [4]. Chaque attribut est dfini par un type, une valeur et un contexte. Il peut
ventuellement avoir un nom qui peut tre utilis pour le rfrencer. Un attribut certifi
[3] A. Jsang, J. Fabre, B. Hay, J. Dalziel, S. Pope. Trust Requirements in Identity Management. Australasian
Information Security Workshop 2005 volume 44, pages 99-108, 2005
[4] ISO/IEC 24760-1:2011(E). ISO/IEC, 20 pages, 2011

conforme par un organisme officiel et/ou digne de confiance est appel claim (la
traduction franaise tant affirmation ).
Lidentifiant est une information qui permet de distinguer sans ambigut une identit
dune autre pour un contexte donn. Lidentifiant peut tre un attribut. Dans ce cas, la valeur
dun identifiant ne peut pas tre utilise par plusieurs identits. De ce fait, il est gnralement
utilis dans le processus didentification qui est responsable de la reconnaissance de lidentit
dans un contexte. De mme quune entit peut possder plusieurs identits pour prsenter des
informations en fonction des contextes, une identit peut tre reprsente par plusieurs
identifiants.
Lidentifiant de rfrence est un identifiant pour un contexte donn qui ne changera pas
pendant la dure de vie de lentit quelle reprsente. Il doit perdurer tant que lentit doit tre
connue du domaine. Il peut mme durer plus longtemps, en fonction de la politique
darchivage laquelle est soumise lorganisation. Lidentifiant de rfrence ne pourra tre
utilis par une autre entit uniquement sous condition que lentit propritaire ne soit plus
rfrence dans le domaine et aprs une priode dtermine par la politique de scurit du
domaine.
Lidentifiant unique personnel (IUP) est un identifiant qui permet de dsigner une
entit. Sa valeur est donc la mme pour les toutes les identits dune mme entit. Deux
entits ne peuvent pas partager le mme identifiant unique personnel.
Les justificatifs didentit (en anglais : identity credentials ) sont des informations
qui peuvent tre utilises en tant quattestation de lidentit revendique par une entit. Il peut
sagir dune chane de caractre connue uniquement de lidentit (mot de passe) ou dune
empreinte digitale par exemple.
Figure 2 Diagramme de classe des concepts dattribut et didentifiant
2.1.3 Fournisseurs de service et didentit

Le fournisseur de service (SP : Service provider en anglais) est une ressource
informatique qui est le support la ralisation dune activit dune organisation (relle ou
virtuelle). Un fournisseur de service peut tre un systme dinformation de gestion ou le
systme qui pilote une machine commande numrique. Dans certains cas, laccs au service

est restreint et lidentit des utilisateurs doit tre vrifie avant de pouvoir lancer lexcution
dune tche.
Le fournisseur didentit (IdP : Identity provider en anglais) est un fournisseur de
service qui construit la reprsentation numrique des identits [5]. Il est notamment
responsable de la gestion des attributs et le garant de lalimentation de leurs valeurs.
5
Un fournisseur de service peut tre mis en uvre en corrlation avec le fournisseur

didentit afin de grer les aspects lis lauthentification (processus de vrification de
lexactitude dun ou plusieurs attributs dune identit) pour les autres fournisseurs de service
de lorganisation. Dans ce cas, ce fournisseur de service est un support la notion de
confiance voque pour les organisations virtuelles et la politique de scurit de
lorganisation.
Le consommateur didentit (RP : Relying Party en anglais) est un fournisseur de
service dont lutilisation ncessite lauthentification des identits prsentes par un
fournisseur didentit. En fonction du domaine dactivit de lorganisation et du type de
service rendu, un consommateur didentit peut tre soumis au respect dune ou plusieurs lois
(cf. les paragraphes Cadre juridique des chapitres Gestion des identits et Gestion
des accs ). Dans ce cas, lorganisation est contrainte la mise en place doutils de contrles
et de gestion des processus lis aux identits.
Un domaine didentit correspond lensemble compos dun fournisseur didentits et
des consommateurs didentits pour lesquels une identit est connue et utilisable. Le concept
de contexte voqu prcdemment peut tre un domaine didentit.
2.1.4 Fdration didentit
Une fdration didentit est un accord entre plusieurs domaines didentits qui spcifie
comment les diffrentes parties prenantes peuvent changer des informations relatives aux
identits. Laccord dfinit les protocoles utiliss, les formats des donnes et les procdures de
protection et daudit. Lidentit ainsi fdre pourra tre utilise dans les diffrents domaines
de la fdration.
2.1.5 Gestion des identits
Le CLUSIF [6] dfinit la gestion des identits comme la gestion du cycle de vie des
personnes (embauche, promotion, mutation, dpart, etc.) au sein de la socit et les impacts
induits sur le systme dinformation . Ces changements ont des consquences sur les
informations connues et gres par le domaine didentit de lorganisation.
6
En effet, avant de travailler au sein dune quipe, une relation contractuelle est tablie
avec la personne, que ce soit directement pour ce qui concerne un employ, par
lintermdiaire dun partenaire ou par lintermdiaire dune socit de service pour un
prestataire. Ce contrat dfinit la mission de lindividu qui inclut des informations telles que le
rsultat attendu, la date de dbut de mission et sa dure. En contre partie du travail fourni,
lorganisation sengage rmunrer lindividu directement ou via son organisation
dappartenance, selon le type de relation tablie. Le contrat permet galement dinitier les
dmarches administratives telles que lenregistrement auprs du service de comptabilit qui
initiera le processus de paiement de la paie ou de la facture. Il est galement le socle qui
[5] E. Bertino, K. Takahashi. Identity Management: Concepts, technologies and systems. Artech House, 194
pages, 2010
[6] A. Balat, R. Bergeron, A. Butel, M. Cottreau, F. Depierre, G. Khouberman, L. Mourer, W. Poloczanski.
Gestion des identits. CLUSIF, 63 pages, 2007

permet de mettre fin au processus de paiement. A partir de ces informations, une identit peut
tre construite puis enregistre auprs du fournisseur didentit.
Ensuite, lorsque la personne commence son contrat, lidentit quil doit prsenter auprs des
fournisseurs de service est active, afin de lui permettre dinteragir avec les ressources utiles
sa mission.
A la fin de ladite mission, lidentit peut tre suspendue, donc temporairement inutilisable,
sil est prvu de la rutiliser pour un prolongement de contrat par exemple. Une autre
possibilit consiste archiver lidentit. Cela implique que les informations lui tant lies ne
sont plus exploitables pour lauthentifier auprs du domaine. Par contre, lensemble, ou une
sous-partie, des informations archives peut tre rutilis pour construire une nouvelle identit
(processus de restauration).
Aprs un dlai tabli par lorganisation et par la loi, toutes les informations relatives
lidentit sont supprimes (cf. chapitre Cadre rglementaire ).
Figure 3 - Cycle de vie dune identit
De plus, selon la norme ISO/IEC 24760 [4], la gestion des identits inclut la
gouvernance, les politiques, les processus, les donnes, les technologies et les standards
permettant notamment :
dauthentifier les identits,
dtablir la provenance des informations des identits,
dtablir le lien entre les informations sur les identits et les entits,
de maintenir jour les informations sur les identits,
dassurer lintgrit des informations sur les identits,
de fournir les justificatifs didentit et les services pour faciliter lauthentification dune
entit en tant quidentit reconnue,
dajuster les risques de scurit lis au vol dinformation par exemple.
2.1.6 Exemples
Une personne travaillant pour une organisation peut tre connue sous plusieurs identits.
Ce cas de figure se prsente notamment lorsque la personne travaille pour plusieurs ples ou

occupe diffrentes fonctions. En effet, dans le contexte de lactivit dingnieur quune
personne exerce au sein dun dpartement, son organisation le connat par exemple sous
lidentit Ingnieur CNRS Jean Perrin du dpartement uuu . Paralllement, il peut tre
charg dune mission dencadrement dans un autre dpartement. Dans ce cas, ltablissement
lui fournit et gre lidentit Manager du dpartement xxx J.B. Perrin . Conjointement ces
activits, en tant quemploy, son employeur produit lidentit Employ Jean-Baptiste
Perrin . Ces identits ne sont valables que pour le contexte Entreprise . Dans le cas o
lentreprise est une des filiales dun groupe, ces identits pourraient ne pas tre connues des
autres filiales du groupe, selon que le contexte soit fix au niveau du groupe ou de la filiale.
Les caractristiques appartenant chaque identit ne sont pas ncessairement
communes et les attributs les prsentant sont construits indpendamment. Par ailleurs, les
identits ne sont pas obligatoirement lies. Ainsi, les identits Ingnieur et Manager
peuvent tre lies lidentit Employ permettant cette dernire davoir accs
certaines informations des autres identits. Inversement, les deux premires identits sont
indpendantes et nont pas de visibilit sur les informations dautres identits.
Tableau I - Exemple d'identits
Ingnieur
Manager
Employ
Nom
Prnom
Date de naissance
Lieu de naissance
Diplmes
PERRIN
Jean
30 septembre
-
PERRIN
J.B.
30 septembre
-
Quotit de travail
Affectation
Employeur
Identifiant
Justificatif didentit
50%
Dpartement uuu
50%
Dpartement xxx
PERRIN
Jean-Baptiste
30 septembre
LYON
Agrgation de
physique
Doctorat s sciences
physiques
100%
-
jean-baptiste.perrin
Certificat numrique
JBP
@zer1yuioP
153545
azertyuiop
Lorganisation met disposition un service de compte-rendu dactivit, un service de

dpt et consultation de documents techniques pour les ingnieurs, un service de gestion des
congs, un service daccs au dossier pour la retraite pour les employs, un service de saisie
des demandes de moyens pour le service et un service de gestion du budget du dpartement
destination des responsables de dpartement.
Tableau II - Exemple de services
Service
Identit utilisatrice potentielle
Compte-rendu de lactivit (Crac)
Ingnieur
Dpt et consultation de documents techniques (Doc)
Ingnieur
Gestion du budget du service (Bdg)

Saisie des demandes de moyens (Ddm)
Manager
Manager
Dossier de retraite (Ret)
Employ
Gestion des congs (Cge)
Employ
2.2 Modles
Dans un domaine didentit, le partage des attributs utiliss par les mcanismes
didentification (association de lidentifiant et dun justificatif didentit ; lidentification est
souvent ralise conjointement lauthentification) implique pour les fournisseurs de service
de partager les risques en cas de corruption dune identit. Les diffrents modles de gestion
des donnes permettent donc de dporter les risques et les charges dadministration
diffrents niveaux. Diffrents modles de gestion des identits peuvent cohabiter au sein de la
mme organisation. A. Jsang, J. Fabre, B. Hay, J. Dalziel et S. Pope [3] proposent les trois
modles suivants de gestion des identits.
2.2.1 Identit isole
Dans ce modle, chaque fournisseur de service utilise son propre domaine didentit,
donc, son propre fournisseur didentit. Un utilisateur doit utiliser un identifiant et un
justificatif didentit diffrents pour sauthentifier auprs de chacun des domaines.
Du point de vue de chacun des fournisseurs didentit, la gestion des identits est plus
simple. De plus, en cas de corruption didentit dans un domaine didentit, les autres
fournisseurs de service ne sont pas impacts. Ce modle a galement lavantage de permettre
de dfinir un niveau de scurit diffrent pour les justificatifs didentits (longueur du mot de
passe, nombre de justificatifs prsents, etc.).
Cependant, cette approche peut devenir complexe du point de vue de lutilisateur. En
effet, ce dernier doit rpter les tapes dauthentification et didentification auprs de chacun
des domaines didentit rattachs aux fournisseurs de services. De ce fait, il doit grer et se
souvenir dautant didentifiants et dinformations utiles lauthentification que de services
auxquels il doit accder. Cela augmente donc le risque doubli ou de perte de ces
informations, surtout pour les services auxquels il naccde que rarement. De plus, cette
situation peut tre source de faible adhrence la politique de scurit de lorganisation qui
sera juge trop contraignante.
Le schma ci-dessous reprsente laccroissement du nombre de domaines didentit et
par consquent du volume dinformation ncessaire en fonction du nombre de fournisseurs de
services.
Figure 4 Modle de gestion didentit : identit isole
Dans le cadre de lexemple dcrit prcdemment, lutilisation du modle didentit

isole implique que chaque service que la personne doit utiliser correspond un contexte
unique. De ce fait, elle doit manipuler autant didentits que de services. Ainsi, pour le service
de gestion des congs, la personne prsente lidentit Employ - Congs pour le domaine

didentit Congs , qui est un driv de lidentit Employ CNRS dcrite
prcdemment. Ce contexte ayant son propre fournisseur didentit, il doit grer le cycle de
vie de cette identit, ce qui inclut la mise jour des informations, dont le justificatif didentit
et la gnration dun ou plusieurs identifiants. Pour utiliser les cinq autres services dcrits
prcdemment, la personne doit prsenter cinq autres identits distinctes potentiellement
dissemblables. En effet, les fournisseurs didentit peuvent utiliser des informations proches
mais pourtant diffrentes. Les informations sont donc rpliques proportionnellement au
nombre de services les utilisant. Cela augmente le risque derreur due une rupture dans la
chane dapprovisionnement. De plus, cette situation est aggrave par le cycle de mise jour
des informations et de renouvellement des justificatifs. Ces derniers sont grs par des
fournisseurs didentits indpendants qui forcent ainsi lutilisation de six justificatifs
diffrents dans le cadre de lexemple comme illustr dans le tableau suivant. En effet, les
consommateurs didentits peuvent demander des contraintes diffrentes sur les justificatifs
didentit. Par exemple, pour les mots de passe, la chane de caractre doit contenir un
nombre minimum de caractres, de chiffres, de symboles ou non en fonction de la politique de
scurit du fournisseur de service.
Tableau III - Synthse de l'exemple pour le modle didentit isole
Fournisseur
de service
SP Crac
SP Doc
SP Bdg
SP Ddm
SP Ret
SP Cge
Domaine
didentit
Crac
Doc
Bdg
Ddm
Ret
Cge
Fournisseur
didentit
IdP Crac
IdP Doc
IdP Bdg
IdP Ddm
IdP Ret
IdP Cge
Nom
PERRIN
PERRIN
PERRIN
PERRIN
PERRIN
Prnom
Jean
Jean-Baptiste
J.B.
Jean-Baptiste
JB
Affectation
Identifiant
fourni et
utilis
Dept uuu
jean.perrin
@uuu.cnrs.fr
Dept uuu
jb.perrin
@uuu.cnrs.fr
Dept xxx
jean.perrin
@xxx.cnrs.fr
Justificatif
didentit
fourni et
utilis
Certificat
numrique
uuu.cnrs.fr
azertyuio
@zer1yui0 Certificat
numrique
xxx.cnrs.fr
Dept xxx
j-b.perrin
153545
@xxx.cnrs.fr
JPB
Je@nPerr1n JPB
2.2.2 Identit fdre

Dans larticle Trust Requirements in Identity Management [3], la fdration
didentit est dfinie comme un ensemble daccords, standards et technologies permettant
un groupe de fournisseurs de service de reconnatre les identifiants provenant dautres
fournisseurs de services appartenant la fdration. La fdration donne aux utilisateurs
lillusion de nutiliser quun seul et unique identifiant alors quil continue en prsenter un
diffrent chaque fournisseur de service.
Dans une architecture didentit fdre, chaque fournisseur de service utilise son
propre fournisseur didentit, mais est capable daccepter les identits provenant dautres
fournisseurs. Laccs un fournisseur de service peut alors se faire au travers dune identit
dun fournisseur didentit autre que le sien. Comme pour le modle isol, une personne est
connue par une identit par service au minimum, mais cette personne na pas toutes les
utiliser. Une correspondance est tablie entre les identifiants des identits appartenant au
mme utilisateur dans le domaine didentit fdr. Quand un utilisateur est authentifi auprs

dun premier fournisseur de service en utilisant un de ses identifiants et le justificatif qui lui
est associ, tous les identifiants sont alors reconnus auprs de lensemble des fournisseurs
didentits de la fdration. Pour accder un autre fournisseur de service, lutilisateur nest
alors pas soumis directement aux processus dauthentification et didentification, car les
informations sous-jacentes ont t transmises.
Figure 5 - Modle de gestion didentit : identit fdre
Ce schma illustre les avantages de la fdration pour lutilisateur par rapport au modle
de gestion prcdent, o chaque fournisseur de service utilisait indpendamment son propre
domaine didentit. En employant une identit fdre, du point de vue de lutilisateur, les
informations ncessaires aux processus d'authentification et didentification sont les mmes
quelques soient les fournisseurs de services sollicits. Il existe donc autant de domaines
didentit, de fournisseurs didentit, didentits que de services, mais lutilisateur nen na
pas conscience.
Dans le cadre de lexemple dcrit prcdemment, le modle didentit fdre permet
dutiliser un unique couple identifiant-justificatif didentit quel que soit le service demand
au sein dune mme fdration. Ainsi, lorganisation peut dployer une fdration
Ingnieur pour lensemble des services lis aux activits dingnieur. Dans ce cas, la
personne
ne
manipule
quun
seul
couple
identifiant-justificatif
didentit
( jean.perrin@uuu.cnrs.fr - Certificat numrique uuu.cnrs.fr ). Lidentit correspondante
( Ingnieur - Crac ) est alors certifie par le fournisseur didentit Crac et de ce fait
automatiquement accepte par les autres fournisseurs didentit de la fdration. Ensuite, une
quivalence est tablie par le fournisseur didentit impacts Doc , permettant de prsenter
lidentit Ingnieur - Doc au service Doc .
Une autre fdration Manager peut tre mise en place pour les services mis disposition
des responsables de dpartement. Dans ce cas, lidentifiant j-b.perrin@xxx.cnrs.fr assorti
du certificat numrique xxx.cnrs.fr peut permettre dutiliser le service de gestion du budget
du dpartement sous lidentit Manager - Bdg et le service de saisie des demandes de
moyen sous lidentit Manager - Ddm . De mme, une fdration peut tre mise en place
pour simplifier lutilisation des services mis disposition pour la gestion des ressources
humaines.
Par contre, aucune interaction nest possible nativement entre les diffrentes fdrations.
Seule une fdration de fdration peut permettre dtablir des correspondances entre les
domaines didentit.
Tableau IV - Synthse de l'exemple pour le modle didentit fdre
Fournisseur
de service
Crac
Doc
Bdg
Ingnieur
Domaine
didentit
Ddm
Ret
Manager
Cge
RH
Fournisseur
didentit
IdP Crac
IdP Doc
IdP Bdg
IdP Ddm
IdP Ret
IdP Cge
Nom
PERRIN
PERRIN
PERRIN
PERRIN
PERRIN
Prnom
Jean
Jean-Baptiste
J.B.
Jean-Baptiste
JB
Affectation
Identifiant
fourni
Dept uuu
jean.perrin
@uuu.cnrs.fr
Dept uuu
jb.perrin
@uuu.cnrs.fr
Dept xxx
jean.perrin
@xxx.cnrs.fr
Dept xxx
j-b.perrin
@xxx.cnrs.fr
153545
JPB
Justificatif
didentit
fourni
Certificat
numrique
uuu.cnrs.fr
azertyuio
@zer1yui0
Certificat
numrique
xxx.cnrs.fr
Je@nPerr1n JPB
Identifiant
utilis
Justificatif
didentit
utilis
jean.perrin@uuu.cnrs.fr
j-b.perrin@xxx.cnrs.fr
Certificat numrique uuu.cnrs.fr Certificat numrique xxx.cnrs.fr
153545
Je@nPerr1n
2.2.3 Identit centralise

Dans ce modle, seuls un identifiant et un justificatif sont utiliss par les fournisseurs de
service. A. Jsang, J. Fabre, B. Hay, J. Dalziel et S. Pope [3] donnent trois exemples
dimplmentation de ce type de gestion didentit.
Identit commune
Dans ce modle, une entit unique agit en tant que fournisseur didentit pour
lensemble des fournisseurs de service. Le mode de fonctionnement est mi-chemin entre le
modle didentit isole et le modle didentit fdre du point de vue de lutilisateur. En
effet, ce dernier doit rpter les processus dauthentification et didentification avant de
pouvoir utiliser un service. Cependant, le domaine didentit rattach chacun des
fournisseurs de service est le mme. De ce fait, lutilisateur utilise les mmes informations
didentifiant et de justificatif quel que soit le fournisseur de service sollicit, ce qui simplifie
laccs aux diffrents services.
Avec ce type dimplmentation le fournisseur didentit unique est un point central et
sensible pour lensemble des fournisseurs de service. En effet, en cas de dfaillance ou de
modification au niveau du domaine didentit, toutes les entits dpendantes sont impactes.
De ce fait, ce modle de gestion impose que chaque fournisseur de service li au domaine
didentit unique soit dclar explicitement. Dans le cas contraire, il est difficile dvaluer les
consquences dun changement ou dune altration vis--vis des services mis disposition de
lutilisateur par le biais de cette architecture.
10
Figure 6 - Modle de gestion didentit : identit commune
Dans le cadre de lexemple dcrit prcdemment, le modle didentit commune permet

dutiliser un unique couple identifiant-justificatif didentit quel que soit le service demand,
comme dans le modle didentit fdre. De ce fait, une seule identit est prsente aux
diffrents services du domaine RH . Lunique fournisseur didentit doit donc construire
une identit qui contient les informations ncessaires aux diffrents services. Un protocole
daccord doit donc tre accept par les diffrents fournisseurs concernant le contenu et la
forme des informations. Ainsi lidentit Employ doit contenir lidentifiant 153545
connu par le service Ret ainsi que lidentifiant JPB connu par le service Cge . Par
contre les deux services doivent tre capables de reconnatre le justificatif didentit
Je@nPerr1n . De mme, dans les exemples prcdents, les valeurs de lattribut prnom
des identits Employ - Ret et Employ - Cge ntaient pas quivalentes, alors que le
modle didentit commune impose que cet attribut soit partag.
Tableau V - Synthse de l'exemple pour le modle didentit commune
Fournisseur
de service
Crac
Doc
Bdg
Ddm
Ret
Cge
Ingnieur
Manager
RH
IdP Chercheur
IdP DU
IdP RH
PERRIN
PERRIN
PERRIN
Jean-Baptiste
J.B.
Jean-Baptiste
Affectation
Dpartement uuu
Dpartement xxx
Identifiant
applicatif 1
Identifiant
applicatif 2
jean.perrin@xxx.cnrs.fr
153545
jb.perrin
@uuu.cnrs.fr
j-b.perrin
@xxx.cnrs.fr
JPB
Identifiant
utilis
153545
Domaine
didentit
Fournisseur
didentit
Nom
Prnom
Justificatif
didentit
utilis
Je@nPerr1n
Mta-identit
La mise en uvre dun domaine de mta-identit permet aux fournisseurs de service de

partager des informations relatives aux identits. Par exemple, une correspondance peut tre
11

tablie entre les identifiants des diffrents domaines didentit et un mta-identifiant
(identifiant du domaine de mta-identit) qui nest pas connu de lutilisateur. Cet identifiant
particulier permettant de dsigner de faon unique une entit quelques soient les identits dans
les domaines concerns, la notion de mta-identifiant se rapproche de la notion didentifiant
unique personnel.
Les justificatifs peuvent tre lis au mta-identifiant. Dans ce cas, les justificatifs sont
les mmes pour tous les domaines didentits concerns. Du point de vue de lutilisateur, cette
architecture peut tre perue comme un mcanisme de synchronisation des justificatifs entre
les diffrents domaines didentit.
Figure 7 - Modle de gestion didentit : mta-identit
Cette approche est un moyen de faciliter lintgration de diffrents domaines didentit,

comme lors de la fusion de plusieurs organisations. Ainsi, le modle de mta-identit permet
des domaines didentit isols de mettre en commun des informations et viter la rplication
des informations. Dans le cadre de lexemple didentit isole dcrit prcdemment, la mise
en uvre dun domaine de mta-identit Ingnieur permet dunifier les informations
fournies par les fournisseurs didentit Crac et Doc . La gestion de ces informations est
alors dlgue au fournisseur de mta-identit Ingnieur . Par ailleurs, le fournisseur de
service Crac doit tre capable dtablir une correspondance entre lidentifiant fourni
jean.perrin@uuu.cnrs.fr et le mta-identifiant fsd15f7s51f2s74 afin de pouvoir
accepter le justificatif didentit sous forme de certificat numrique. De mme, le fournisseur
de service Doc doit pouvoir faire le lien entre lidentifiant fourni jb.perrin@uuu.cnrs.fr
et le mta-identifiant fsd15f7s51f2s74 . Pour lingnieur, le domaine de mta-identit
permet de grer moins de justificatifs didentit. Cependant, contrairement aux modles
didentit fdre ou commune, la personne doit continuer utiliser des identifiants diffrents.
Cette architecture permet de restreindre le volume de donnes, mais la difficult est de mettre
en place un mcanisme qui permet de lier les informations gres par le fournisseur didentit
Crac celles du fournisseur didentit Doc .
Tableau VI - Synthse de l'exemple pour le modle de mta-identit
Fournisseur
de service
Crac
Doc
Bdg
Ddm
Ret
Cge
Domaine
didentit
Crac
Doc
Bdg
Ddm
Ret
Cge
Fournisseur
didentit
Nom
IdP Crac
IdP Doc
IdP Bdg
IdP Ddm
IdP Ret
IdP Cge
PERRIN
PERRIN
PERRIN
PERRIN
12

Fournisseur
de service
Prnom
Affectation
Identifiant
fourni
Crac
Bdg
Ddm
Jean-Baptiste
J.B.
Dpartement uuu
Dpartement xxx
jean.perrin
@uuu.cnrs.fr
jb.perrin
@uuu.cnrs.fr
jean.perrin
@xxx.cnrs.fr
Ret
Jean-Baptiste
j-b.perrin
@xxx.cnrs.fr
JB
153545
JPB
Manager
RH
fsd15f7s51f2s74
dg4d5h7d54s2
23s4fgsd564fds6

Justificatif
de
mta-identit
Cge
Ingnieur
Domaine de
mta-identit
Mtaidentifiant
Doc
Je@nPerr1n
Single Sign-On (SSO)
Lapproche Single Sign-On est similaire une fdration didentit, mais aucune
correspondance didentit nest ncessaire, car il nexiste quun seul fournisseur didentit.
Dans cette architecture, un utilisateur na besoin de sauthentifier quune seule fois (en anglais
single sign-on ) auprs dun fournisseur de service. Il est alors authentifi de facto auprs
des autres fournisseurs de service.
Le modle Single Sign-On peut tre associ au modle de fdration didentit,
permettant une authentification unique inter-domaine.
Figure 8 - Modle de gestion d'identit : Single Sign-On
Dans le cadre de lexemple dcrit prcdemment, ce modle didentit permet dutiliser

un unique couple identifiant-justificatif didentit quel que soit le service demand au sein du
domaine didentit. Ainsi, comme dans le cas dune fdration, lorganisation peut dployer
un domaine de SSO Ingnieur pour lensemble des services lis aux activits dingnieur.
Dans ce cas, la personne ne manipule quun seul couple identifiant-justificatif didentit
( jean.perrin@uuu.cnrs.fr - Certificat numrique uuu.cnrs.fr ) lors de la connexion au
service Crac . Lidentit correspondante ( Ingnieur ) est alors automatiquement
reconnue par le service Doc , permettant de lutiliser sans phase dauthentification
pralable.
Tableau VII - Synthse de l'exemple pour le modle de Single Sign-On
Fournisseur
de service
Domaine
didentit
Crac
Doc
Bdg
Ingnieur
Ddm
Manager
13
Ret
Cge
RH

Fournisseur
de service
Fournisseur
didentit
Nom
Prnom
Affectation
Identifiant
fourni
Justificatif
didentit
fourni
Crac
Doc
Bdg
Ddm
Ret
Cge
IdP Chercheur
IdP DU
IdP RH
PERRIN
PERRIN
PERRIN
Jean-Baptiste
J.B.
Jean-Baptiste
Dpartement uuu
Dpartement xxx
153545
Je@nPerr1n
2.3 Cadre rglementaire

La loi franaise Informatique et Liberts n 78-17 du 6 janvier 1978 modifie par la loi
du 6 aot 2004 dfinit les principes respecter lors de la collecte, du traitement et de la
conservation des donnes personnelles. Cette loi est applicable ds quil existe un traitement
automatis ou un fichier manuel, cest--dire un fichier informatique ou un fichier papier
contenant des informations personnelles relatives des personnes physiques.
La Commission Nationale Informatique et Liberts (CNIL) veille la mise en uvre
des principes de la loi Informatique et Liberts dont ceux :
de pertinence des donnes : les donnes personnelles doivent tre adquates, pertinentes
et non excessives au regard des objectifs poursuivis ,
de dure limite de conservation de donnes : les informations ne peuvent pas tre
conserves de faon indfinie dans les fichiers informatiques ; une dure de conservation
doit tre tablie en fonction de la finalit de chaque fichier (par exemple : le temps de la
prsence du salari pour une application de gestion des carrires, cinq ans pour un fichier
de paie, deux ans aprs le dernier contact avec le candidat un emploi pour un fichier de
recrutement),
de scurit et de confidentialit : lemployeur, en tant que responsable du traitement, est
astreint une obligation de scurit : il doit prendre les mesures ncessaires pour garantir
la confidentialit des donnes et viter leur divulgation des tiers non autoriss . Larticle
34 prcise que le responsable du traitement est tenu de prendre toutes prcautions utiles,
au regard de la nature des donnes et des risques prsents par le traitement, pour prserver
la scurit des donnes et, notamment, empcher quelles soient dformes, endommages,
ou que des tiers non autoriss y aient accs .
du principe de transparence : la loi garantit aux personnes laccs linformation relative
aux traitements auxquels sont soumises des donnes les concernant et les assure de la
possibilit dun contrle personnel. Le responsable de traitement des donnes personnelles
doit avertir ces personnes ds la collecte des donnes et en cas de transmission de ces
donnes des tiers.
Larticle 226-17 du code pnal rprime la non observation de ces principes de
prcaution par des dispositions particulirement lourdes. En effet, le fait de procder ou de
faire procder un traitement de donnes caractre personnel sans mettre en uvre les
mesures prescrites larticle 34 de la loi n78-17 du 6 janvier 1978 prcite est puni de cinq
ans demprisonnement et de 300 000 damende . Par ailleurs, larticle 226-22 est
galement applicable, suite la plainte dune victime dindiscrtion, mme sil sagit dune
14

simple ngligence. Il prcise que le fait, par toute personne qui a recueilli, loccasion de
leur enregistrement, de leur classement, de leur transmission ou dune autre forme de
traitement, des donnes caractre personnel dont la divulgation aurait pour effet de porter
atteinte la considration de lintress ou lintimit de sa vie prive, de porter, sans
autorisation de lintress, ces donnes la connaissance dun tiers qui na pas qualit pour
les recevoir est puni de cinq ans demprisonnement et de 300 000 damende .
Le Correspondant Informatique et Liberts (CIL) se positionne en intermdiaire entre le
responsable des traitements des donnes concernes et la CNIL. Il doit avoir une connaissance
approfondie de lorganisation responsable des traitements. De ce fait, il doit tre un employ.
Il est responsable de la cration et de la mise jour de la liste des traitements effectus, ainsi
que de la publication de cette liste. Il veille galement au respect des principes de la protection
des donnes personnelles. Il a un rle dinformation pour les personnes au sujet de lexistence
de leurs droits daccs, de rectification et dopposition.
15
3. Gestion des accs

3.1 Dfinitions
3.1.1 Ressources et gestion des accs
Afin de permettre de raliser ses projets en toute scurit, une organisation doit grer les
accs aux ressources dont elle dispose.
Comme voqu prcdemment lors de la dfinition du concept didentit, une ressource
dsigne un fournisseur de service identifi par un libell tel quun systme dinformation ou
de communication.
La gestion des accs permet de sassurer de mettre disposition de chacune des personnes
impliques dans les projets de lorganisation, tout instant, tous les moyens ncessaires la
ralisation de la mission qui leur a t confie, et que ces moyens soient chaque instant
limits au juste ncessaire [5].
Par la politique de gestion des accs, les accs aux ressources sont limits par des
contraintes tablies par lorganisation dont les dfinitions sont dveloppes dans les
paragraphes suivants :
Mode dauthentification et contrle daccs ;
Primtre daccs ;
Rles, profils et groupes autoriss.
3.1.2 Comptes utilisateurs
Un compte est un ensemble dinformations compos d un identifiant, un mot de passe
(ou un justificatif didentit dune autre nature) et plusieurs attributs supplmentaires en
fonction de lenvironnement dans lequel il est cr [6]. Un compte peut donc tre la
reprsentation informatique dune identit. Il existe trois principaux types de comptes : le
compte utilisateur, le compte dadministration et le compte de service.
Le compte utilisateur est associ une entit utilisateur. Il est utilis pour se connecter aux
ressources dun contexte auprs desquelles la personne est habilite.
Le compte global est un compte utilisateur unique quune personne utilise pour tous les
processus dauthentification et autorisation de lensemble des ressources de lorganisation.
Le compte dadministration permet une entit daccder une unique ressource et den
assurer la gestion. Cependant, il nest pas associ une entit, ce qui implique quil ne doit
pas tre connu des rfrentiels didentit. Son utilisation doit tre limite aux tches
techniques qui ne peuvent pas tre ralises au travers des rles (cf. dfinition ci-aprs)
dadministration. Il est souvent cr lors de linstallation dune application avec des valeurs
dattributs prdfinies. Cest pour cette raison quil est prfrable de dsactiver tous les
comptes de cette nature. En effet, les mots de passe tant affects avec une valeur par dfaut
linstallation, ils sont connus de tous et prsentent donc une faille de scurit importante [7].
Le compte de service fonctionnel ou technique est associ une entit ressource. Il permet de
sauthentifier (ou simplement sidentifier) auprs dune autre ressource pour accder ses
services. Les droits daccs octroys ce compte sont limits. Aucune personne nest
autorise utiliser ce type de compte.
7
[7] G. Harry. Failles de scurit des applications Web. CNRS, 38 pages, 2012
16
Figure 9 - Diagramme de classe des comptes
3.1.3 Habilitations et contrle daccs

Le CLUSIF [6] dcrit une habilitation comme un droit deffectuer une action sur une
ressource. Elle est associe un primtre qui limite quand et comment cette ressource peut
tre utilise par une entit. Les habilitations sont attribues en fonction des besoins des
mtiers au sein de lorganisation.
F. Ferraiolo, D. R. Kuhn et R. Chandramouli [8] dfinissent un contrle daccs comme
un processus pour vrifier les habilitations affectes une entit.
8
Les contrles daccs sont un des moyens dassurer la scurit de linformation qui peut
tre dfinie par trois concepts complmentaires :
La confidentialit est lassurance quune information ne peut tre lue que par les entits
qui en ont le droit ;
Lintgrit est la protection de linformation contre des modifications par des entits qui
nen ont pas le droit ;
La disponibilit est la capacit mettre linformation disposition quand les entits en ont
besoin.
Les contrles daccs permettent dassurer la confidentialit et lintgrit de
linformation. La disponibilit de linformation dpend de celle des mcanismes mis en uvre
pour assurer les contrles daccs. En effet, si le moyen de raliser les contrles daccs est
inutilisable, alors linformation ne peut tre ni lue, ni modifie, la rendant indisponible.
3.1.4 Rle, profil, groupe et primtre
Les termes de rle, de profil et de groupe sont souvent confondus, alors que ce sont des
concepts manipuls rgulirement dans la gestion des identits et des accs.
Un rle est un ensemble dhabilitations ncessaires un type dutilisation dune
ressource. Un rle applicatif est un rle propre une seule fonction et appartient une seule
application. Il est recommand dutiliser les rles applicatifs comme unique moyen
daccorder des habilitations un compte. De ce fait, les rles permettent de matriser les
permissions octroyes et de dceler les conflits entre les droits.
De mme, un rle ne doit pas tre octroy directement un compte utilisateur. Il est
prfrable de les attribuer au travers des profils mtiers qui regroupent lensemble des rles
[8] D. F. Ferraiolo, D. R. Kuhn, R. Chandramouli. Role-Based Access Control, Second Edition. Artech House,
381 pages, 2007
17

ncessaires la ralisation dune mission. Un profil correspond donc gnralement une
fonction exerce au sein dune organisation.
Lorsque des entits doivent obtenir les mmes habilitations spcifiques, mais que leurs
profils ne correspondent pas, elles peuvent tre regroupes en groupes statiques ou
dynamiques. Par exemple, des personnes participant un projet ont besoin de pouvoir
partager des documents au sein dun espace de travail collaboratif. Un groupe statique est
constitu par une liste exhaustive des comptes utilisateurs devant obtenir une habilitation
particulire. Lutilisation de ce type de groupe nest pas recommande lorsque la liste doit
voluer souvent. Dans ce cas, il est prfrable dopter pour un groupe dynamique qui est
gnr sur la base dun critre tel que la prsence ou la valeur dun attribut dans les comptes
utilisateurs. Dans le cadre de lexemple sur les projets, tous comptes utilisateurs possdant
lattribut Administrateur Systme et Rseau font partie du groupe du mme nom qui leur
donne le droit de dposer et de modifier des documents dans le rpertoire Architecture
informatique et leur permet galement de lire tous les comptes-rendus davancement du
projet. Par contre, une liste statique de comptes utilisateur tablie quels sont ceux qui ont la
capacit de dposer et modifier ces rapports. Les groupes permettent donc de faciliter la
gestion massive dhabilitations indpendamment des rles.
Comme voqu prcdemment, une habilitation est soumise un primtre applicatif
qui restreint les capacits dutilisation dune ressource.
Le primtre temporel interdit les accs une ressource en dehors des priodes autorises. Il
peut tre assign un compte utilisateur, un rle ou une ressource. Les restrictions sont
exprimes en fonction de trois critres cumulables :
La priode, dfinie par une date de dbut et une date de fin, nautorise lutilisation de la
ressource cible que si la tentative daccs est opre entre ces deux dates ;
La plage horaire, dfinie par une heure de dbut et une heure de fin, nautorise lutilisation
de la ressource cible que si la tentative daccs est ralise entre les heures spcifies ;
Le calendrier, dfini par une liste de jours calendaires, une liste de semaines ou une liste
de mois, nautorise lutilisation de la ressource cible que si la tentative daccs est opre
un jour appartenant une des listes cites.
Le primtre gographique limite les accs une ressource en fonction du lieu partir duquel
un utilisateur tente de se connecter. Il peut tre affect un compte ou un rle. Lensemble
des habilitations lies au profil du compte utilisateur volue alors en fonction du lieu de
prsence de la personne auquel il appartient, permettant ainsi par exemple dempcher la
manipulation dinformations confidentielles partir de points daccs non fiables. Les
restrictions sont de trois types :
Le poste de travail physique, identifi par un numro dinventaire ou une adresse IP,
partir duquel lorganisation souhaite autoriser ou interdire certaines oprations ;
Un lieu, un groupe de lieu ou une zone gographique dans laquelle le poste de travail doit
se situer lors de la tentative de connexion pour obtenir le droit dutiliser la ressource
cible ;
Une typologie daccs pour permettre les accs la ressource. Il peut sagir dun accs par
le rseau de lorganisation, un rseau mis disposition par un partenaire ou un rseau
priv ddi.
Le primtre fonctionnel limite lexcution de traitements applicatifs en fonction de la valeur
ou de la nature des informations fournies en paramtre. Il peut tre assign un rle. Les
donnes peuvent tre relatives par exemple un secteur gographique, laffectation au sein
de lorganisation ou au type dappareil utilis pour se connecter.
18
Figure 10 - Diagramme de classe des habilitations
3.1.5 Authentification et autorisation

Comme voqu lors de la dfinition de la gestion didentit, lauthentification est le
processus qui permet de vrifier que lidentit revendique par une entit est lgitime. Elle est
base sur un ou plusieurs mcanismes de reconnaissance :
Quelque chose que lentit connat comme par exemple un mot de passe ou un numro
personnel didentification (code PIN) ;
Quelque chose que lentit possde, telle quune carte ou une cl ;
Une caractristique physique telle quune empreinte digitale ou rtinienne.
Lauthentification est plus sre si plusieurs techniques sont utilises conjointement [6]. En
effet, un mot de passe peut tre devin, une cl peut tre perdue et une reconnaissance faciale
peut tre fausse cause des marges derreur. Aussi, lutilisation dune technique ne fournit
pas un niveau de scurit suffisant. Il faut en utiliser plusieurs pour diminuer les risques
derreur ou de falsification. Le mode dauthentification peut tre dtermin en fonction du
rle associ aux comptes utilisateurs ou de la ressource utilise.
Lautorisation est le processus responsable dtablir les habilitations dont dispose une
identit au travers dun compte et du profil qui lui est associ ou des groupes auxquels il
appartient. Ce processus dtermine donc ce quune identit a le droit de faire pour chacune
des ressources qui lui est mise disposition. Des modles dautorisation daccs sont exposs
dans le paragraphe Modles des gestions daccs .
Ces deux concepts sont utiliss conjointement pour les contrles daccs, le processus
dautorisation tant dpendant du bon fonctionnement de lauthentification. En effet, si le
moyen dauthentifier une identit nest pas sr, alors il nest pas possible de garantir que les
autorisations soient accordes la bonne entit. Dans ce cas, le contrle daccs ne permet pas
dassurer la confidentialit et lintgrit des informations quil doit protger.
19

3.1.6 Exemples
Pour la gestion, lorganisation met disposition plusieurs ressources : un service de
gestion du budget du dpartement nomm Bdg et un service de rapports dcisionnels pour
le pilotage de lorganisme nomm Rpt . Le service Bdg offre la possibilit de saisir des
commandes et de produire des rapports analytiques dtaills ou synthtiques sur les dpenses
et les subventions. Pour se connecter ce service, il est ncessaire de disposer dun compte.
Ainsi, pour un responsable de dpartement connu sous lidentit Manager du dpartement
xxx - J.B. Perrin un compte utilisateur Bdg-JBP est cr. Pour son assistante,
lorganisation produit lidentit Gestionnaire du dpartement xxx - G. Mineur laquelle
est li le compte utilisateur Bdg-GM . Par ailleurs, lentreprise dispose dune quipe de la
production applicative responsable du maintien en condition oprationnelle (MCO) des
ressources laquelle appartient l Exploitant Joseph Licklider . A ce titre, lquipe dispose
dun compte dadministration Bdg-ADMIN . De plus, pour produire des rapports au niveau
de ltablissement, la ressource Rpt doit accder la ressource Bdg , ce qui est
ralisable au travers du compte de service Bdg-READ .
Tableau VIII - Exemple de comptes utilisateurs
Compte
Information
Bdg-GM
Bdg-JBP
Bdg-READ
Bdg-ADMIN
Identit
reprsente
Gestionnaire du
dpartement xxx
G. Mineur
Manager du
dpartement xxx
J.B. Perrin
Ressource Rpt
Non applicable
Nom
G. Mineur
J.B. Perrin
Rapport
ADMIN
Affectation
Dpartement xxx
Dpartement xxx
Production
applicative
Type de compte
Utilisateur
Utilisateur
Service
Administration
Personne
manipulant le
compte
Ressource cible
Gabrielle MINEUR
Jean-Baptiste
PERRIN
Non applicable
Joseph
LICKLIDER
Service Bdg
Service Bdg
Service Bdg
Service Bdg
Identifiant
GM
JBP
READ
ADMIN
Justificatif
didentit
G@brie11e
@zer1yuioP
f&jdsu_oehy
myEXP1@cnt
Le service Bdg offre la possibilit de :

lire (action read ) ou saisir/modifier (action write ) des commandes pour un
primtre fonctionnel limit au dpartement et lanne,
lire (action read ) ou saisir/modifier (action write ) les crdits allous pour un
primtre fonctionnel limit au dpartement et lanne,
lire (action read ) ou gnrer (action execute ) des rapports sur le budget pour un
primtre fonctionnel limit au dpartement,
lire (action read ) les informations techniques des journaux vnementiels,
Dmarrer et arrter (action execute ) le service Bdg .
Les habilitations lies ces fonctionnalits sont octroyes au travers de rles valides
uniquement pour la ressource Bdg . Le tableau suivant montre laffectation des
habilitations et leur primtre sur les rles Intendance Dpartement , Management
Dpartement , Lecture budget Dpartement , Rapport budget Dpartement et
MCO .
20

Tableau IX - Exemple de rles applicatifs
Profil
Intendance
dpartement
Manager
dpartement
Lecture budget
dpartement
Rapport budget
dpartement
MCO
Dpartement
Dpartement
Dpartement
Dpartement
read, write
-
read,write
read
read
Rapport
read
execute
Informations
techniques
read
Service
execute
Rle
Primtre
Commandes
Crdits
Un compte utilisateur ayant le profil Manager , tel que Bdg-JBP , doit obtenir les
habilitations saisir les crdits allous son dpartement, lire tout type dinformation lies
son dpartement durant son mandat et en gnrer les rapports. Pour ce faire, ce profil se voit
octroyer les rles Management dpartement , Lecture budget dpartement et Rapport
budget dpartement . Conjointement, un compte utilisateur ayant le profil Gestionnaire ,
tel que Bdg-GM , doit obtenir lhabilitation saisir des commandes et visualiser des
rapports sur le budget du dpartement daffection et lanne en cours. A cet effet, ce profil
dispose des rles Intendance dpartement et Lecture budget dpartement . Un compte
ayant le profil Lecture , tel que le compte de service Bdg-READ , doit disposer des
habilitations permettant de lire des informations budgtaires pour lensemble des
dpartements dans lapplication Bdg . Pour rpondre ce besoin, ce profil dispose du rle
Lecture budget dpartement sur lensemble des dpartements enregistrs. Un compte
dadministration, utilis notamment par l Exploitant Joseph Licklider , doit tre habilit
dmarrer et arrter le service Bdg , accder aux informations techniques lies aux
vnements applicatifs et pouvoir lancer la gnration de rapports en cas de dfaillance.
Ainsi, le profil Production applicative possde les rles MCO et Rapport budget
dpartement .
Tableau X - Exemple de profils
Profil
Gestionnaire
Manager
Lecture
Production
applicative
Primtres
dept, anne
Primtres
dept, anne
Primtres
dept, anne
Sans limite
Rle
Intendance
dpartement
Management
dpartement
Lecture budget
dpartement
Rapport budget
dpartement
MCO
Primtres
dept, anne
-
Primtres
dept, anne
Primtres
dept, anne
Sans limite
3.2 Modles
Comme voqu prcdemment, le contrle des accs revt plusieurs aspects pour
assurer la scurit des ressources et des informations. Il repose sur lutilisation de diffrentes
notions telles que les identits avec les modles IBAC, les rles avec le modle RBAC ou les
primtres avec des modles tels quABAC ou OrBAC.
21

3.2.1 Identity based access control (IBAC)
F. Cuppens et N. Cuppens-Boulahia [9] prsentent le modle IBAC comme tant
historiquement le premier type de contrle daccs. Bien quintroduit par B. Lampson en
1971, il est toujours utilis par les systmes dexploitation sur les marchs des ordinateurs
personnels, avec Microsoft Windows par exemple, et des serveurs avec les systmes Unix et
Linux. Ce modle repose sur une matrice compose dun ensemble fini dentits, de
ressources cibles et de rgles. Il conduit ltablissement dune liste exhaustive
dautorisations daccs (ACL : Access Control List en anglais). Cela implique que tout
accs non explicitement autoris est interdit. Ainsi, les habilitations sont affectes directement
aux comptes utilisateurs. Ainsi chaque droit est assign nominativement.
9
Le tableau suivant est un exemple de matrice ACL pour les comptes utilisateurs et
habilitations dcrits dans lexemple dcrit prcdemment. Ainsi le responsable du
dpartement xxx nouvellement nomm ne pourra saisir les crdits que pour lanne en cours
mais pourra consulter les crdits et rapports de lensemble des annes.
Tableau XI - Exemple de matrice ACL du modle IBAC
Bdg-GM
Bdg- JBP
read, write
read
read
read, write
read
read
Crdits dpartement xxx 2011
read
read
read
Crdits dpartement xxx 2012
read
read, write
read
Rapport dpartement xxx 2011

Rapport dpartement xxx 2012
read
read
read
read,execute
execute
execute
Informations techniques
read
Service
read
Commandes dpartement xxx 2011

Commandes dpartement xxx 2012
Bdg-READ Bdg-ADMIN
Une des implmentations du modle IBAC est le contrle daccs discrtionnaire

(DAC : Discretionary Access Control en anglais) qui repose sur la notion de propritaire
de la ressource. Ce dernier a le contrle total sur la ressource quil a cre et dont il est
responsable. Il dtermine ainsi quelle entit a droit quel type daction sur sa ressource.
La complexit des ACLs augmente en fonction du nombre didentits et du nombre de
ressources puisquil faut lister exhaustivement les autorisations pour chacune des
combinaisons. En effet, lors la mise disposition dune nouvelle ressource ou larrive dun
nouvel utilisateur, la liste des autorisations doit tre mise jour. Les modles qui suivent
permettent de faciliter la gestion des habilitations.
3.2.2 Mandatory Access Control (MAC)
Dans le cas o le propritaire dun systme dinformation ne doit pas tre responsable
de la gestion de la scurit sous-jacente, les modles de type MAC permettent de limiter les
accs en fonction de la sensibilit des donnes. Dans cet objectif, les entits cibles sont
hirarchises en diffrents niveaux de scurit (MLS : multi-level security en anglais)
appels labels.
En 1973, D. Bell et L. LaPadula ont dvelopp un modle o un niveau minimum de scurit
est requis pour avoir le droit daccder la ressource. Ce niveau dfinit le niveau
dhabilitation de lutilisateur. De mme, un niveau de scurit est affect la ressource. Ce
[9] F. Cuppens, N. Cuppens-Boulahia. Les modles de scurit. Dans Scurit des systmes d'information,
(Trait IC2, srie Rseaux et tlcoms). Herms, pages 13-48, 2006
22

niveau dtermine le niveau de classification de la ressource. Lutilisateur na alors accs la
ressource que si son niveau dhabilitation est suprieur ou gal au niveau de classification de
la ressource. De plus, pour une application, un niveau dexcution, appel niveau courant, est
galement dfini. Le niveau courant dune application est toujours infrieur ou gal au niveau
dhabilitation de lutilisateur responsable de lexcution de lapplication. La condition no
read up implique quune application ne peut accder en lecture des informations que si le
niveau courant de lapplication est suprieur ou gal au niveau de classification de la
ressource qui gre ces donnes. De mme, la condition no write down suppose quune
application ne peut transmettre des informations une ressource que si son niveau courant est
infrieur ou gal au niveau de classification de la ressource cible. Ce modle de contrle des
accs est galement appel Rule Based Access Control (RuBAC), car les accs sont rgis par
des rgles.
Dans le cadre des restrictions voques dans lexemple de comptes utilisateurs dcrit
prcdemment, les niveaux dhabilitation peuvent tre dfinis sur cinq niveaux. Ainsi, les
informations gres par la ressource Bdg sont classifies de niveau 3. Les comptes
utilisateurs devant sy connecter doivent donc disposer dune habilitation de niveau suprieur
ou gal 3. Ainsi, le compte Bdg-GM dispose du niveau dhabilitation 4, Bdg-JBP du
niveau dhabilitation 5. Le compte Bdg-ADMIN responsable de lexcution du service a
un niveau dhabilitation minimum, ce qui implique quil a le niveau dhabilitation 3. Le
niveau courant de lapplication Bdg doit donc tre infrieur ou gal au niveau
dhabilitation 3 du compte Bdg-ADMIN . Pour respecter la contrainte no read up , le
niveau courant de lapplication Bdg doit galement tre suprieur au niveau de
classification 3 des informations, ce qui implique que le niveau courant de lapplication doit
tre fix 3. Par ailleurs, la contrainte no write down implique que la ressource Rpt ,
qui doit tre en mesure lire des donnes de la ressource Bdg , doit avoir un niveau de
classification suprieur ou gal au niveau courant 3 de lapplication Bdg . De plus, tant
tabli que laccs aux informations de la ressource Rpt requiert le niveau dhabilitation le
plus lev, le niveau de classification de la ressource Rpt est impos 5 obligeant dfinir
le niveau courant de lapplication Rpt 5.
Tableau XII - Exemple d'implmentation du modle MAC
Niveau
Habilitation
Classification
Compte
BdgGM
Compte
BdgJBP
Compte
Bdg-ADMIN
Courant
Ressource
Bdg
Ressource
Rpt
En 1986, D. Bell propose une version tendue de ce modle o le niveau courant dune
application nest plus dtermin par un unique niveau mais par un intervalle de niveaux, ce
qui offre plus de flexibilit. Dans ce cas, une application peut accder en lecture toute
information dont la classification est comprise entre la borne infrieure et la borne suprieure
du niveau courant de lapplication. Ce modle est proche de celui utilis actuellement par le
systme de gestion de bases de donnes Oracle via loption Label Security pour segmenter les
donnes.
3.2.3 Role Based Access Control (RBAC)
Contrairement au modle IBAC o les habilitations sont octroyes directement
lutilisateur, dans le modle RBAC, labor par le National Institute of Standards and
Technology (NIST) partir de 1992 [7], les habilitations sont affectes des rles. La gestion
23

des habilitations est alors simplifie. En effet, par exemple, lors de lenregistrement dun
nouvel utilisateur, il suffit de lui attribuer les rles ncessaires la ralisation de sa mission au
lieu de lui octroyer lensemble des habilitations sous-jacentes. Ainsi, dans lexemple des rles
applicatifs, lors de sa prise de fonction, un gestionnaire se voit attribuer le rle Intendance
dpartement au travers de son compte utilisateur. Il a alors accs en lecture, en saisie aux
commandes effectues par le dpartement pour lanne en cours.
Par ailleurs, le NIST propose plusieurs dclinaisons du modle RBAC [10]. Le modle
RBAC hirarchique (HRBAC : hierarchical role based access control en anglais) prend en
compte les liens de parent entre rles. Ainsi lorsquune habilitation est octroye ou enleve
un rle parent, les rles fils en hritent et acquirent, ou respectivement perdent, cette
habilitation. HRBAC supporte deux types de hirarchie. La variante gnrale ( General
Hierarchical RBAC en anglais) accepte des hritages ascendants et descendants multiples.
Par opposition, dans la variante limite ( Limited Hierarchical RBAC en anglais) un rle
ne peut hriter que dun seul parent. Dans le cadre de lexemple des rles applicatifs, le rle
Lecture budget dpartement est commun aux profils Gestionnaire et Manager . Ce
rle est donc ncessaire lorsque les rles Intendance dpartement et Management
dpartement sont affects. La modlisation de ces rles peut alors tre simplifie en
dfinissant Lecture budget dpartement comme rle parent de Intendance dpartement
et Management dpartement . Seuls ces deux derniers rles sont alors octroys, car ils
hritent des habilitations du rle parent Lecture budget dpartement .
La seconde dclinaison du modle RBAC permet la gestion des conflits dintrts induits par
des rles incompatibles octroys un mme utilisateur. En effet, le modle RBAC avec
contraintes (CRBAC : constrained role based access control en anglais) assure la
sparation des responsabilits (SoD : Segregation of Duty en anglais) en empchant le
cumul dhabilitations contradictoires. Ainsi, dans les exemples de rle dcrits prcdemment,
un compte ne peut pas tre associ en mme temps aux rles Intendance dpartement et
Management dpartement qui reprsentent deux fonctions dans lorganisme qui ne
peuvent tre exerces par une seule personne au sein dun dpartement. Par ailleurs, la mise
en uvre de la sparation statique des responsabilits (en anglais : static separation of
duty ) implique la dfinition de rgles daffectation de rles. Ladministrateur responsable
des accs ne peut alors pas affecter des rles incompatibles. Ainsi un utilisateur appartenant
un rle ne peut pas se voir attribu un rle rendu interdit par ces rgles. La sparation
dynamique des responsabilits (en anglais : dynamic separation of duty ) permet de ne pas
retirer un rle en cas de non-respect des rgles, mais simplement de le rvoquer
temporairement au moment o lutilisateur demande se connecter la ressource.
10
La mise en place dun systme de contrle daccs bas sur le modle RBAC au sein
dune organisation requiert la mise en uvre dune stratgie de dfinition des rles (en
anglais : role engineering ) qui nest pas une tche aise. Il existe deux principaux types
dapproche bottom-up (du bas vers le haut) et top-down (du haut vers le bas)
complts par des approches hybrides.
Pour les organisations disposant dj dun systme de gestion des droits daccs la dmarche
bottom-up permet de construire des rles en examinant les habilitations existantes. Des outils
de rolemining permettent dacclrer cette recherche [11]. Ils exploitent des algorithmes de
datamining, chacun ayant un objectif diffrent, tel que minimiser le nombre de rles
11
[10] D. F. Ferraiolo , R. Sandhu , S. Gavrila , D. R. Kuhn , R. Chandramouli. Proposed NIST standard for rolebased access control. ACM Transactions on Information and System Security v.4 n.3, pages 224-274, 2001
[11] M. Frank, J. M. Buhmann , D. Basin. On the definition of role mining. Proceeding of the 15th ACM
symposium on Access control models and technologies, pages 35-44, 2010
24

dcouverts, tablir les hirarchies de rles ou dcouvrir un nombre faible de rles possdant le
plus grand dnominateur commun dhabilitations. Cependant les droits inutiliss rsiduels
peuvent perturber cette analyse et mener des dfinitions de rles qui nont aucune
correspondance avec des concepts mtier.
A linverse, la dmarche top-down tudie par itrations successives les fonctions mtiers pour
en dduire les habilitations et les rles inhrents. La difficult rside alors dans lexhaustivit
et la granularit des rles. En effet, des rles trop larges admettent trop de droits et des rles
trop restreints vont augmenter la difficult dadministration.
Lapproche hybride consiste rechercher les rles par lapproche bottom-up et les affiner
ensuite par confrontation avec les informations collectes par lapproche top-down.
Le modle RBAC est aujourdhui un standard qui permet notamment la mise en
conformit vis--vis de la loi Sarbanes-Oxley (cf. paragraphe cadre rglementaire ). Il
sadresse plus particulirement aux organisations dont la dfinition des mtiers et des
missions est fige et volue peu. Dans le cas contraire, des exceptions seront ncessaires pour
autoriser des accs spcifiques ou temporaires. Cette situation implique la mise en place dune
liste annexe de contrle daccs, comme dans le modle IBAC. Il nest alors plus possible de
se baser sur les dfinitions des rles et des profils pour dterminer qui possde quel type
daccs sur quelle ressource.
3.2.4 Attribute Based Access Control (ABAC)
Le modle ABAC, dfini par L. Wang, D. Wijesekera, S. Jajodia [12], propose de
dfinir les droits daccs en fonction des caractristiques des identits. A linstar du modle
IBAC, la politique des droits daccs peut tre matrialise par une matrice, mais en ne se
basant pas sur les identits. De ce fait, les droits daccs une ressource ou un service sont
dfinis pour un ou plusieurs attributs que les identits sont susceptibles de possder. Ce
paradigme offre donc plus de flexibilit. De plus, en dfinissant un attribut se rapprochant de
la notion de rle, ABAC permet de simuler le comportement dun modle RBAC, mais le
gnralise en ne limitant pas les droits daccs aux seuls utilisateurs prsents dans
lorganisation. Il permet notamment de dterminer des droits daccs avec une granularit
plus fine. De plus, en dfinissant un rle comme un ensemble dattributs, il est plus facile de
grer les conflits. Par ailleurs, la gestion des droits daccs est facilite, car elle ne ncessite
pas dinformations supplmentaires. Cependant, la scurit des accs repose alors sur les
valeurs affectes aux attributs et donc sur la qualit et lintgrit des informations lies aux
identits.
12
Dans le cadre des exemples dcrits prcdemment, le modle ABAC implique que
loctroi de lattribut Resp dept un compte utilisateur a pour effet de donner accs
automatiquement aux lignes de crdits et rapports. Lattribut Resp dept peut tre peru
comme la matrialisation du profil Manager .
3.2.5 Organization Based Access Control (OrBAC)
Avec le modle OrBAC [9], lorganisation est perue dun point de vue abstrait comme
un ensemble dactivits que les rles ont la permission, interdiction ou obligation de raliser
au travers des vues. Tout comme dans RBAC, il est possible dutiliser la notion dhritage
pour les rles. Concrtement, les habilitations sont octroyes des sujets pour des actions sur
des objets au travers de matrices trois dimensions.
[12] L. Wang, D. Wijesekera, S. Jajodia. A logic-based framework for attribute based access control.
Proceedings of the 2004 ACM workshop on Formal methods in security engineering, pages 45-55, 2004
25

Ce modle semble permettre une gestion plus fine des droits daccs, mais reste
cependant peu implmente.
3.2.6 Comparaison
Quelque soit le modle implment au sein dune organisation, lobjectif est de limiter
la capacit daction des entits utilisatrices des ressources au strict ncessaire pour raliser
leurs missions.
Dans le modle IBAC, les contrles daccs reposent sur une liste exhaustive dhabilitations
pour chaque compte autoris.
Le modle RBAC permet de diminuer la taille de liste des habilitations. Les contrles daccs
sont raliss sur les rles attribus aux comptes. Les rles applicatifs sont octroys en fonction
du profil mtier.
Dans le modle ABAC, les contrles daccs vrifient la prsence et la valeur dattributs
applicatifs dfinis au niveau des comptes. Il est alors possible de simuler le comportement
RBAC en calquant les attributs sur la dfinition des rles.
Dans le modle OrBAC les autorisations ou interdictions reposent sur des expressions
contextuelles dfinies daprs la structure organisationnelle de ltablissement.
Le modle MAC sappuie sur le contrle des flux. Des contraintes sont dfinies sur les
donnes et les ressources. Le niveau dhabilitation dun compte dtermine alors sil a le droit
ou non daccder aux informations.
3.3 Cadre rglementaire

Bien que toutes les organisations ne soient pas concernes par les lois encadrant le
comportement des entreprises prives, celles qui sont lies la scurit de linformation vont
tre exposes dans les paragraphes suivants afin de prsenter les bnfices et les contraintes
lies la gestion des accs. De plus, essayer de sen rapprocher permet de diminuer les
risques relatifs la scurit.
3.3.1 Loi amricaine Sarbanes-Oxley
La loi Sarbanes-Oxley (SOx) fut vote par le congrs amricain en juillet 2002 dans le
but de redonner confiance aux investisseurs dans les marchs financiers suite aux scandales
ENRON et WORLCOM. D. F. Ferraiolo, D. R. Kuhn et R. Chandramouli [8] prcisent que la
loi implique pour les entreprises cotes aux Etats-Unis et leurs filiales, y compris ltranger,
ou qui empruntent sur le march amricain que les contrles internes et les processus utiliss
pour la production des rapports financiers soient certifis auprs de la Securities and
Exchange Commission . Limpact pour les systmes dinformation est un contrle accru sur
lutilisation des logiciels dont lorganisation dpend pour ses donnes financires. Cela inclut
galement les outils de gestion des transactions, des donnes comptables, personnelles,
dinventaire et toute autre donne qui peut tre utilise pour la production des rapports
financiers. La surveillance doit assurer que tout changement soit opr par une personne
autorise et selon un processus certifi.
Trois sections sont applicables aux systmes dinformation :
1. La section 302 implique que le comit excutif certifie la compltude et lexactitude des
rapports financiers de lorganisation ;
2. La section 404 contraint lorganisation maintenir des procdures et des structures de
contrles internes adquats pour la production de rapports financiers . Les contrles
internes doivent tre valids par des auditeurs externes pour assurer de leur authenticit,
vrifier les renseignements sur site et avertir des insuffisances. Les responsables encourent
des pnalits sils dissimulent labsence ou linsuffisance de contrles ;
26

3. La section 409 requiert la prsentation dans les plus brefs dlais des rapports aux
investisseurs et rgulateurs de toute information concernant un changement dans les
finances ou les oprations de lorganisation.
La section 404 de Sarbanes-Oxley est plus particulirement lie la gestion des
identits et des accs. Dans ce paragraphe le terme adquat concernant les contrles
internes nest pas explicitement dfini. Cependant, quelques bonnes pratiques sont cites dont
les suivantes :
Contrles renforcs sur les identifiants et les permissions lies aux identifiants,
Surveillance rigoureuse des attributions, mises jour ou rvocations de privilges,
incluant des capacits daudit complet,
Sparation des responsabilits pour laccs ou la modification dinformations financires,
Contrle et audit des modifications prsentant qui les a ralises, quand et par quels
moyens,
Suivi et contrle renforc sur la mise jour et les changements effectus sur les logiciels,
Documentation sur la configuration et la maintenance des logiciels,
Installation ds que possible des mises jour de scurit avec criture dans les traces
daudit,
Documentation complte sur les contrles internes dficients qui rduisent les capacits de
lorganisation raliser les objectifs cits prcdemment.
La mise en uvre de Sarbanes-Oxley peut tre coteuse, mais elle offre lopportunit de
mettre en place des processus internes srs. De plus, de part ces obligations, les organisations
certifies ISO-27001 (cf. paragraphe Norme ISO-2700x ) respectent automatiquement
Sarbanes-Oxley.
Les outils de gestion des identits et des accs des grands diteurs sont compatibles avec
la mise en conformit Sarbanes-Oxley.
3.3.2 Accords internationaux Ble II
Le comit Ble sur le Contrle Bancaire runit les principales autorits de contrle
bancaire du monde. En 1988, il publia un premier accord, Ble I , sur la gestion des risques
de crdit et la quantit de fonds propres minimaux pour les banques pour faire face
dventuelles pertes. En 1992, il fut dclin en diffrentes lois dans les pays du G10.
En 2004, le comit Ble publia une seconde srie daccords, Ble II qui prend en
compte plus de catgories de risques et amliore le calcul et la gestion de ces risques [13]. Ils
ont pour objectifs une meilleure transparence des entreprises, la protection des pargnants et
un renforcement des contrles. Lensemble des obligations qui composent cette rforme est
scinde selon trois piliers :
Pilier I : Disposer dun montant de fonds propres pour couvrir les risques,
Pilier II : Les autorits disposent de pouvoirs renforcs pour imposer des exigences de fonds
propres suprieurs ceux envisags par lentreprise,
Pilier III : Obligation de publier des informations compltes sur la nature, le volume et les
mthodes de gestion des risques ainsi que ladquation de leurs fonds propres.
13
Pour tre conforme au premier pilier, lorganisation doit disposer dune analyse
conomique des risques pour en connatre et ensuite limiter les impacts sur son bilan. Les
risques sont rpartis en trois catgories : risques de crdit, risques de marchs et risques
[13] G. Chamoret, F. Chavoutier, M. Copitet, J-P Godard, P. Grassart, J. Mauferon, L. Mourer, T. Ramard, G.
Remy. La rforme BLE 2, une prsentation gnrale. CLUSIF, 28 pages, 2004
27

oprationnels. Ces derniers incluent les risques relatifs la scurit des biens et des
personnes, les risques informatiques lis aux dveloppements et la maintenance des
programmes, traitements et services de tlcommunications.
Chaque tape du processus de gestion des risques doit tre prise en compte : lidentification,
lanalyse, le traitement ainsi que son financement. Par ailleurs, les paragraphes 670 676
prcisent que lestimation des risques doit reposer, entres autres, sur des bases dincidents et
de pertes couples des outils danalyse de scnario. Les bases dincidents permettent de
disposer dun historique des sinistres constats et leur frquence, ce qui permet dassurer un
suivi des volutions des diffrents risques et des mesures correctrices mises en uvre. Les
outils danalyse de scnario doivent aider construire des modles statistiques de prvision
des risques partir de lhistorique de la base des pertes.
Lobligation de transparence du troisime pilier implique de rendre compte dans un
rapport des procdures de gestion des risques mises en place, notamment du systme de
contrle interne. Ce dernier doit assurer un suivi des risques oprationnels, dont celui de
conflit dintrt. Pour cela, lorganisation doit implmenter un systme dapprobations et
dautorisations pour veiller la sparation des responsabilits. Lorganisation doit galement
protger les accs et lutilisation des actifs et des informations dtenus par la banque.
En 2010, une premire version du troisime accord, Ble III , fut publie. Il ajuste les
exigences de fonds, mais ne prend pas en compte les origines de la crise des subprime .
Son impact est faible sur les systmes dinformation conformes Ble II.
3.3.3 Loi de scurit financire (LSF)
La loi franaise n 2003-706 du 1 aot 2003 de scurit financire s'applique toutes les
socits anonymes ainsi qu'aux socits faisant appel l'pargne publique. Elle ne sapplique
donc pas aux grands groupes. A linstar de la loi amricaine Sarbanes-Oxley, la loi de scurit
financire repose principalement sur une responsabilit accrue des dirigeants, un renforcement
du contrle interne et une rduction des sources de conflits d'intrt.
Le contrle interne doit permettre lamlioration de la communication en temps rel et
la fiabilisation de la production dinformations, rpondant ainsi au besoin de transparence.
Pour cela, lorganisation doit tre capable de retracer le processus de gnration de
linformation depuis lorigine des donnes jusquaux dcisions qui sen sont suivies.
Lorganisation doit donc mettre en place des outils de documentation permettant de
dcrire les activits et les processus inhrents de gnration de rapports et de gestion de
contenu pour conserver, grer et mettre disposition les informations de l'entreprise.
3.3.4 CRBF 97-02
Inspir des dmarches internationales comme celles du Comit de Ble, le Rglement
97-02 du Comit de Rglementation Bancaire et Financire (CRBF) dcrit les obligations de
contrle interne pour les tablissements de crdit. Il est fond sur cinq thmes principaux : le
systme de contrle des oprations et des procdures internes, l'organisation comptable et du
traitement de l'information, les systmes de mesure des risques et des rsultats, les systmes
de surveillance et de matrise des risques ainsi que le rle des organes excutifs et dlibrants.
Il en rsulte quune entreprise assujettie doit mettre en uvre un systme de contrle
des oprations, des systmes de surveillance et de matrise des risques ainsi quun systme de
documentation et dinformation. De plus, lorganisme doit mettre en place des procdures de
suivi des actions correctrices vis--vis des obligations de conformit.
Par ailleurs, larticle 4n stipule que ltablissement doit dvelopper un plan de
continuit de lactivit permettant la ralisation des tches et services indispensables en cas de
28

scnario de crise, ainsi quun plan de retour planifi aux conditions normales quand le
problme est rsolu.
29
4. Bonnes pratiques
4.1 Normes
Bien quil ne soit pas ncessaire de suivre au sein dune organisation les normes dcrites
ci-aprs, il est prfrable de respecter le vocabulaire qui y est dfini. De plus, il nest pas
forcment souhaitable datteindre le niveau dexigence de la norme ISO-27002, notamment
pour des raisons de cots, mais tendre sen rapprocher permet de mettre en place un niveau
de scurit satisfaisant.
4.1.1 ISO-24760
La norme ISO-24760 cite prcdemment est un ensemble de prescriptions concernant
la gestion des identits divis en trois parties.
La premire partie (ISO-24760 A framework for identity management - Part 1 :
Terminology and concepts [4], cf. annexe 1 ISO-24760 ) est consacre la dfinition des
concepts lis aux identits. Les notions dcrites sont reprises et explicites dans le prsent
document.
La seconde partie (ISO-24670 A framework for identity management - Part 2 :
Reference architecture and requirements) ne sera publie officiellement quen dcembre 2013.
Elle proposera une architecture pour la mise en uvre de la gestion des identits.
La troisime partie (ISO-24760 A framework for identity management - Part 3 :
Practice) qui est galement en cours de rdaction dtaillera la mise en pratique de
larchitecture dfinie dans la seconde partie de la norme.
4.1.2 ISO-2700x
Les normes 2700x sont une famille de normes traitant de la scurit de linformation o
la gestion des identits et des accs y est voque.
ISO/IEC 27000:2009 : Information security management systems - Overview

and vocabulary
Publie en 2009, la norme ISO/CEI 27000 prsente les concepts qui sont manipuls
dans les autres normes ISO-2700x. Elle dcrit notamment la notion de mesure de scurit (en
anglais : control ) comme tant un moyen de gestion du risque, comprenant les
politiques, les procdures, les lignes directrices, les pratiques ou l'organisation, qui peuvent
tre de nature administrative, technique, managriale ou juridique . Le systme de
management de la scurit de linformation (SMSI) est prsent comme une partie du
systme de management global, base sur une approche du risque li l'activit, visant
tablir, mettre en uvre, exploiter, surveiller, rexaminer, tenir jour et amliorer la scurit
de l'information . Le processus de qualit PDCA (en anglais : Plan-Do-CheckAct/Adjust ; en franais : Planifier-Dployer-Contrler-Agir/Ajuster ) y est prsent
brivement.
ISO/IEC 27001:2005
Requirements
Information
security
management
systems
Publie en 2005, la norme ISO/IEC 27001 dfinit les exigences pour mettre en uvre,
documenter, exploiter et faire voluer un SMSI dont le modle cyclique PDCA est le support.
Cette dmarche itrative est compose de quatre tapes. La phase de planification concerne la
conception du SMSI. La phase de dploiement correspond la ralisation de ce qui a t
planifi. La phase de contrle permet de vrifier quil nexiste pas dcart entre ce qui a t
30

planifi et ce qui a t implment. La phase daction permet de corriger les carts constats
lors de ltape prcdente.
Figure 11 - Processus itratif PDCA de la norme ISO-27001
ISO/IEC 27002:2005 : Code of practice for information security management
Publie en 2005, la norme ISO/IEC 27002 est un recueil de bonnes pratiques sur la
scurit de linformation. Elle propose un ensemble de mesures de scurit organisationnelles
et techniques, mais aucune solution technique. Le chapitre 11 expose notamment des mesures
consacres la gestion des identits et des accs dans le but de matriser laccs
linformation (cf. annexe 2 ISO-27002 chapitre 11 ) [14]. La politique de contrle des
accs inclut des exigences par exemple autour des profils daccs utilisateur normaliss pour
les rles courants au sein de lorganisme ou de l annulation de droits daccs . Le souschapitre 11.2 dcrit les mesures relatives la gestion de laccs utilisateur, dont
lenregistrement des utilisateurs, des privilges et des mots de passe.
14
ISO/IEC 27003:2010 : Information

implementation guidance
security
management
system
Publie en 2010, la norme ISO/IEC 27003 contient un guide pratique de mise en uvre
du SMSI suivant le processus PDCA et respectant les exigences de la norme ISO-27002.
ISO/IEC 27004:2009 :
Measurement
Information
security
management
system
Publie en 2009, la norme ISO/IEC 27004 fournit des mtriques permettant dvaluer le
niveau defficacit du SMSI et par consquent le niveau de scurit de lorganisation.
ISO/IEC 27005:2011 : Information security risk management
Publie en 2008 et rvise en 2011, la norme ISO/IEC 27005 contient un guide de

gestion du risque. Elle repose sur les concepts en scurit de linformation dfinis par la
norme ISO/IEC 27001.
ISO/IEC 27006:2011 : Requirements for bodies providing

certification of information security management systems
audit
and
Publie en 2009 et rvise en 2011, la norme ISO/IEC 27006 est un recueil dexigences
destination des organismes qui procdent l'audit et la certification ISO 27001.
ISO/IEC 27007:2011 : Guidelines for information security management

systems auditing
Publie en 2011, la norme ISO/IEC 27007 est un recueil dinstructions pour l'audit et la
certification ISO 27001 dun SMSI.
[14] ISO/CEI 27002:2005(F). ISO/IEC, 130 pages, 2005
31
ISO/IEC 27008:2011 : Guidelines for auditors on information security

controls
Publie en 2011, la norme ISO/IEC 27008 est un recueil dinstructions destination des
auditeurs accrdits pour vrifier la qualit dimplmentation des mesures de scurit dcrites
dans la norme ISO 27002.
4.2 Dmarche projet oriente gestion des identits et des accs

Lobjectif dun projet de gestion des identits et des accs est de grer les utilisateurs et
leurs habilitations afin darriver dterminer qui a le droit daccder quoi. La difficult de
ce type de projet voque lors des retours dexprience rside dans la complexit des
systmes dinformation existants qui ne permettent pas de construire un ensemble cohrent
dinformations. En effet, les informations sont rparties dans de nombreux rfrentiels. De ce
fait, il nexiste aucun moyen dtablir aisment la relation entre identit et habilitations et
didentifier les profils mtiers ou les rles applicatifs. Cest pourquoi il est conseill dtablir
au pralable une cartographie qui prend en compte tous les systmes dinformation permettant
de recueillir des informations sur les personnes, les comptes utilisateurs, les profils mtiers,
les rles ainsi que les ressources auxquels ils accdent.
La cartographie doit permettre de mettre en vidence des besoins. Ltape suivante
consiste donc fixer les priorits tant au niveau du systme dinformation global quau niveau
fonctionnel. Les diffrents niveaux de priorit vont dfinir les objectifs que le systme de
gestion des identits et des accs devra atteindre. Chaque besoin doit tre associ un
responsable ou une matrise douvrage mtier qui devient alors un des commanditaires, appel
sponsor, du projet. La gestion des identits ayant un impact sur les processus lis aux
ressources humaines, au moins en tant que consommateur des informations, un responsable
doit donc tre impliqu au plus tt dans le projet.
Une difficult supplmentaire voque lors des retours dexprience de projets de
gestion des identits est une dure trop importante qui est responsable de la diminution de
limplication des quipes fonctionnelles. Lors de projets qui suivent des dmarches
squentielles (cf. annexe 3 Gestion de projet ), le manque de visibilit sur lavancement du
projet peut dmotiver les clients du projet. Cest pourquoi les cabinets de conseil et
dintgration prconisent de suivre une mthode itrative avec des livrables visibles chaque
tape.
La dmarche prconise est donc proche des modles Agiles (cf. annexe 3 Gestion de
projet ). Chaque itration, dune dure nexcdant pas un mois, doit permettre de livrer un
composant de la gestion des identits et des accs auquel sera associ un sponsor
correspondant au product owner des mthodes Agiles.
Les diffrentes tapes sinscrivent dans un schma long terme reposant sur trois
phases.
La premire phase consiste btir une base solide pour les services de gestion des identits et
des accs. Ce socle repose sur la connaissance des associations compte-identit. Pour cela il
est ncessaire de nettoyer et mettre en cohrence les diffrents systmes et de mettre en place
un identifiant unique personnel.
La seconde phase est le dploiement des services de gestion des identits et des accs. Elle
intgre la formalisation et lautomatisation des processus de gestion des habilitations. Elle a
pour objectif doffrir un moyen de grer les accs et den raliser un audit et de produire des
rapports.
32

La dernire phase doit fournir une gestion fine des rles. Elle dbute par une
rconciliation des rles et des accs afin de dterminer qui accde quelle application, quel
compte, selon quelle rgle et avec quels privilges. Lobjectif est de fournir un moyen de
grer intuitivement cet ensemble dinformation.
33
5. Glossaire
ABAC, 21, 25, 26
ACL, 22
Agilit, 32, 40, 46
Attribut, 2, 3, 6, 7, 16, 18, 25, 26
Authentification, 4, 5, 7, 9, 10, 13, 16, 19,
51
Autorisation, 1, 15, 16, 18, 19, 22, 25, 26,
51
Ble, 27, 28
Ble I, 27
Ble II, 27
Ble III, 28
Cartographie, 32
CIL, 15
Claim, 3
CNIL, 14, 15
Compte, 16, 17, 19, 24, 26, 32, 33, 50, 51
Compte dadministration, 16
Compte de service, 16
Compte global, 16
Compte utilisateur, 16, 17, 18, 19, 22,
24, 32, 40, 47
Confidentialit, 1, 14, 17
Consommateur didentit, 4
Contrle daccs, 17
CRBF, 28
Credentials Voir Justificatif didentit
Crystal, 46
DAC, 22
Disponibilit, 17
Domaine didentit, 4, 7, 8, 9, 10, 12
Entit, 2, 3, 10, 12, 16, 17, 18, 19, 22, 26
Feature Driven Development, 46
Fdration didentit, 4, 8, 13
Fournisseur didentit, 4, 5, 7, 8, 10, 13
Fournisseur de service, 3, 4, 7, 8, 9, 10, 11,
13, 16
Gestion des identits et des accs
Gestion des accs, 16, 26, 27, 30
Gestion des identits, 4, 5, 7, 19, 27, 30,
32
Groupe, 16, 17, 18, 19
Habilitation, 17, 18, 19, 22, 23, 24, 25, 26,
32, 50
IBAC, 21, 22, 23, 25, 26
Identifiant, 3, 7, 8, 9, 10, 12, 16, 27
Identifiant de rfrence, 3
Identifiant unique personnel, 3, 12, 32
Mta-identifiant, 12
Identification, 3, 7, 9, 10, 19, 28, 39, 51
Identit, 1, 2, 3, 4, 5, 7, 8, 16, 19, 21, 22,
25, 30, 32
Cycle de vie, 4
Identit centralise, 13
Identit fdre, 8, 9, 10
Identit isole, 10
Mta-identit, 11, 12
IdP Voir Fournisseur d'identit
Incrment, 46
Intgrit, 1, 17, 19, 25, 50
Itration, 25, 32, 44, 46, 47
Iteration planning, 46
Justificatif d'identit, 3, 7, 10, 12, 16
Label, 22
Loi de scurit financire, 28
MAC, 22, 26
Mle, 46
Mesure de scurit, 30, 31
MLS, 22
NIST, 24
Niveau
Niveau courant, 23
Niveau dhabilitation, 22, 23, 26, 51
Niveau de classification, 23
Niveau de scurit, 7, 19, 22, 31
OrBAC, 21, 25, 26
PDCA, 30, 31
Primtre, 16, 17, 18, 21, 50, 51
Primtre fonctionnel, 18
Primtre gographique, 18
Primtre temporel, 18
Product backlog, 46
Product owner, 32, 46
Profil, 16, 17, 18, 19, 25, 26, 31, 32, 41
Prototype, 44, 45
RBAC, 21, 23, 24, 25, 26
Constrained RBAC, 24
Hierarchical RBAC, 24
General Hierarchical RBAC, 24
Limited Hierarchical RBAC, 24
Role engineering, 24
Rolemining, 24
Ressource, 1, 2, 3, 5, 16, 17, 18, 19, 21, 22,
23, 24, 25, 26, 32
Rle, 16, 17, 18, 19, 21, 23, 24, 25, 26, 31,
32, 33, 41, 43, 50
34

RP Voir Consommateur d'identit
RuBAC, 23
Sarbanes-Oxley, 25, 27, 28
Scrum, 46
Segregation of Duty Voir Sparation des
responsabilits
Sparation des responsabilits, 24, 27, 28
Sparation dynamique, 24
Sparation statique, 24
SMSI, 30, 31
SP Voir Fournisseur de service
Sponsor, 32, 48
Sprint, 46, 47
Sprint backlog, 46, 47
Sprint planning, 46
Sprint review, 47
SSO, 13
Synchronisation, 12, 47, 50
Test Driven Development, 42, 47
User story, 46
Utilisateur, 4, 7, 8, 9, 10, 12, 13, 16, 18,
22, 23, 24, 25, 31, 32, 40, 46, 50
XP, 46
35
6. Bibliographie
6.1 Rfrences documentaires
[1] M.R. Nami, A. Malekpour. Virtual Organizations: Trends and Models. Dans IFIP
International Federation for Information Processing, Volume 288; Intelligent Information
Processing IV, Zhongzhi Shi, E. Mercier-Laurent, D. Leake, pages 190199, 2008
[2] J. Magiera, A. Pawlak. Security Frameworks for virtual organizations. Dans
Organizations: Systems and Practices. Springer, pages 133-148, 2005
[3] A. Jsang, J. Fabre, B. Hay, J. Dalziel, S. Pope. Trust Requirements in Identity
Management. Australasian Information Security Workshop 2005 volume 44, pages 99108, 2005
[4] ISO/IEC 24760-1:2011(E). ISO/IEC, 20 pages, 2011
[5] E. Bertino, K. Takahashi. Identity Management: Concepts, technologies and systems.
Artech House, 194 pages, 2010
[6] A. Balat, R. Bergeron, A. Butel, M. Cottreau, F. Depierre, G. Khouberman, L. Mourer, W.
Poloczanski. Gestion des identits. CLUSIF, 63 pages, 2007
[7] G. Harry. Failles de scurit des applications Web. CNRS, 38 pages, 2012
[8] D. F. Ferraiolo, D. R. Kuhn, R. Chandramouli. Role-Based Access Control, Second
Edition. Artech House, 381 pages, 2007
[9] F. Cuppens, N. Cuppens-Boulahia. Les modles de scurit. Dans Scurit des systmes
d'information, (Trait IC2, srie Rseaux et tlcoms). Herms, pages 13-48, 2006
[10] D. F. Ferraiolo, R. Sandhu, S. Gavrila, D. R. Kuhn, R. Chandramouli. Proposed NIST
standard for role-based access control. ACM Transactions on Information and System
Security v.4 n.3, pages 224-274, 2001
[11] M. Frank, J. M. Buhmann , D. Basin. On the definition of role mining. Dans
Proceeding of the 15th ACM symposium on Access control models and technologies,
pages 35-44, 2010
[12] L. Wang, D. Wijesekera, S. Jajodia. A logic-based framework for attribute based
access control. Dans Proceedings of the 2004 ACM workshop on Formal methods in
security engineering, pages 45-55, 2004
[13] G. Chamoret, F. Chavoutier, M. Copitet, J-P Godard, P. Grassart, J. Mauferon, L.
Mourer, T. Ramard, G. Remy. La rforme BLE 2, une prsentation gnrale. CLUSIF,
28 pages, 2004
[14]
ISO/CEI 27002:2005(F). ISO/IEC, 130 pages, 2005
[15]
L. Audibert. UML 2 de l'apprentissage la pratique. Ellipses, 298 pages, 2009
[16] W. W. Royce. Managing the Development of Large Software Systems : concepts and
techniques. Dans Proceedings of the 9th international conference on Software
Engineering, pages 1-9, 1970
[17] J. McDermid, K. Ripken. Life cycle support in the Ada environment. ACM SIGAda
Ada Letters, v.III n.1, pages 57-62, 1983
[18]
K. Beck. Test Driven Development: By Example. Pearson Education, 240 pages, 2002
36

[19] B. W. Boehm. A Spiral Model of Software Development and Enhancement. ACM
SIGSOFT Software Engineering Notes, Volume 11 n.4, pages 14-24, 1986
[20] A. Cockburn. Agile software development. Addison-Wesley Longman Publishing Co.,
278 pages, 2002
6.2 Rfrences Internet
Bearing Point. Amliorer la gestion de lidentit et des droits, quels gains pour une
DRH ?, disponible sur : http://blogrh.bearingpoint.com (consult le 23/04/2012)
CLUSIF. Club de la Scurit de lInformation

http://www.clusif.asso.fr (consult le 25/04/2012)
ITFACTO. Conformit des accs : Identits, annuaire, SSO, disponible sur :

http://www.guidescomparatifs.com/Conformite_des_acces_identites_annuaire_mot_de_pa
sse.asp (consult le 10/08/2012)
Identropy. The Identropy Blog, disponible sur : http://www.identropy.com/blog/ (consult

le 24/04/2012)
ISO. We're ISO, the International Organization for Standardization. We develop and
publish International Standards., disponible sur : http://www.iso.org (consult le
25/04/2012)
Agence Nationale de le Scurit des Systmes dInformation. Portail de la scurit

informatique, disponible sur : http://www.securite-informatique.gouv.fr (consult le
25/04/2012)
Agence Nationale de le Scurit des Systmes dInformation. Actualits, guides,

publications, disponible sur : http://www.ssi.gouv.fr (consult le 25/04/2012)
Franais,
Source des icnes libres de droits dutilisations : http://findicons.com
37
disponible
sur :
Annexe 1. ISO 24760
(Table des matires)
F OREWORD ......................................................................................
IV
I NTRODUCTION .................................................................................
1 S COPE ............................................................................................ 1
2 N ORMATIVE REFERENCES .............................................................. 1
3 T ERMS AND DEFINITIONS ............................................................... 1
3.1 General terms............................................................................................................
3.2 Identification.............................................................................................................
3.3 Authenticating an identity ........................................................................................
3.4 Management of identity............................................................................................
3.5 Federation .................................................................................................................
3.6 Privacy protection .....................................................................................................
1
3
4
5
6
7
4 S YMBOLS AND ABBREVIATED TERMS .............................................. 8

5 I DENTITY ....................................................................................... 8
5.1 General ..................................................................................................................... 8
5.2 Identity information .................................................................................................. 9
5.3 Identifier ................................................................................................................... 10
6 A TTRIBUTES .................................................................................. 10
6.1 General ..................................................................................................................... 10
6.2 Types of attribute ...................................................................................................... 11
6.3 Domain of origin ...................................................................................................... 11
7 M ANAGING IDENTITY INFORMATION .............................................. 12

7.1 General ..................................................................................................................... 12
7.2 Identity lifecycle ....................................................................................................... 12
8 I DENTIFICATION ............................................................................ 14
8.1 General .....................................................................................................................
8.2 Verification ...............................................................................................................
8.3 Enrolment .................................................................................................................
8.4 Registration...............................................................................................................
14
15
15
15
9 A UTHENTICATION .......................................................................... 16
10 M AINTENANCE ............................................................................. 16
11 IMPLEMENTATION ASPECTS ......................................................... 16
12 P RIVACY ...................................................................................... 17
B IBLIOGRAPHY ................................................................................. 18
I NDEX OF TERMS .............................................................................. 20
38
Annexe 2. ISO-27002
(Table des matires - Chapitre 11)
11 C ONTROLE D ACCES .................................................................... 62

11.1 Exigences mtier relatives au contrle daccs ...................................................... 62
11.1.1 Politique de contrle daccs ............................................................................. 62
11.2 Gestion de laccs utilisateur ..................................................................................
11.2.1 Enregistrement des utilisateurs ..........................................................................
11.2.2 Gestion des privilges ........................................................................................
11.2.3 Gestion du mot de passe utilisateur ...................................................................
11.2.4 Rexamen des droits daccs utilisateurs ..........................................................
63
64
65
65
66
11.3 Responsabilits utilisateurs ....................................................................................

11.3.1 Utilisation du mot de passe ................................................................................
11.3.2 Matriel utilisateur laiss sans surveillance.......................................................
11.3.3 Politique du bureau propre et de lcran vide ....................................................
67
67
68
68
11.4 Contrle daccs au rseau .....................................................................................

11.4.1 Politique relative lutilisation des services en rseau .....................................
11.4.2 Authentification de lutilisateur pour les connexions externes .........................
11.4.3 Identification des matriels en rseau ................................................................
11.4.4 Protection des ports de diagnostic et de configuration distance .....................
11.4.5 Cloisonnement des rseaux ...............................................................................
11.4.6 Mesure relative la connexion rseau ...............................................................
11.4.7 Contrle du routage rseau ................................................................................
69
69
70
71
71
71
72
73
11.5 Contrle daccs au systme dexploitation ...........................................................

11.5.1 Ouverture de sessions scurises .......................................................................
11.5.2 Identification et authentification de lutilisateur ...............................................
11.5.3 Systme de gestion des mots de passe ...............................................................
11.5.4 Emploi des utilitaires systme ...........................................................................
11.5.5 Dconnexion automatique des sessions inactives .............................................
11.5.6 Limitation du temps de connexion ....................................................................
73
73
75
75
76
77
77
11.6 Contrle daccs aux applications et linformation ............................................. 77

11.6.1 Restriction daccs linformation.................................................................... 78
11.6.2 Isolement des systmes sensibles ...................................................................... 78
11.7 Informatique mobile et tltravail .......................................................................... 79
11.7.1 Informatique mobile et tlcommunications ..................................................... 79
11.7.2 Tltravail .......................................................................................................... 80
39
Annexe 3. Gestion de projet

Un projet de gestion des identits et des accs repose sur lensemble des informations
sur les personnes et comptes utilisateurs existants et venir. Dans le cycle de vie du projet, la
phase initiale de spcification doit donc prendre en compte les systmes dinformations
actuels ainsi que le besoin de pouvoir augmenter le primtre avec lajout de nouvelles
applications de lorganisme ou de certains partenaires.
1. Cycle de vie
L. Audibert [15] rappelle que tout logiciel ou systme dinformation suit un cycle de vie
divis en cinq tapes dont chacune englobe un ensemble dactivits.
La phase de spcification et danalyse des besoins permet de dfinir lensemble des besoins
auxquels devra rpondre le futur systme. Il en rsulte gnralement un document de
spcifications issu des dialogues entre les quipes mtiers et les quipes de dveloppement.
La phase de conception permet de dfinir larchitecture gnrale du produit attendu en se
basant sur les spcifications dfinies prcdemment. A lissue de cette phase un planning
gnral est dcid et une bauche de linterface graphique peut tre propose.
La phase de codage est le moment o les quipes de dveloppement produisent le code
oprationnel.
La phase de test permet dexaminer et valider la qualit du produit en se basant sur plusieurs
critres. Ainsi, les tests dacception doivent vrifier que le produit rpond aux attentes
spcifies lors de la phase de spcifications. Les tests dintgration permettent de sassurer
que les diffrents lments du systme produit sinterfacent correctement avec les autres
systmes dinformation de lorganisation. Les tests unitaires, qui doivent tre rdigs pendant
la phase de codage, refltent le comportement de lapplication. Ils permettent galement de
connaitre quelles portions de code oprationnel ont t testes et sont conformes aux
spcifications.
La phase de maintenance a pour but de corriger ou faire voluer le produit livr.
La mise en production peut tre considre comme une tape intermdiaire. Cette tape
consiste dployer le systme dans lenvironnement cible et ouvrir laccs aux utilisateurs.
15
Ce dcoupage de projet peut tre gr selon plusieurs modles dont lutilisation dpend
du type de projet et de la ractivit attendue. Les mthodes dites classiques imposent des
modles stricts o les tapes sont clairement dfinies avec une production importante de
documentation, ce qui convient gnralement de gros projets. A loppos, les mthodes dites
Agiles suivent des modles itratifs orients davantage sur le code oprationnel que sur la
documentation, permettant ainsi des livraisons plus frquentes.
[15] L. Audibert. UML 2 de l'apprentissage la pratique. Ellipses, 298 pages, 2009
40
2. Cycle en cascade
En 1970, W. W. Royce [16] a publi le modle en cascade (en anglais : Waterfall
model ). Le projet, proche du mode de gestion des projets industriels, est alors un
enchainement linaire dtapes avec un retour possible sur les prcdentes. Chaque tape se
termine une date prdtermine par la livraison de documents ou de modules logiciels. De
plus, une nouvelle phase ne peut dbuter que si la prcdente est compltement acheve et
valide, ce qui implique que les livrables attendus sont jugs satisfaisants.
16
Figure 12 - Cycle de vie de projet en cascade
Ce type de cycle de vie, simple comprendre et implmenter, convient aux projets o

la qualit a plus dimportance que les cots ou les dlais, et dont les besoins sont clairement
dfinis et stables. Dans le cas contraire, la prise en compte de nouveaux besoins ncessite de
drouler toute la cascade depuis le dbut. De plus, le client nest impliqu quau dbut du
projet et il ne peut tester le produit qu la fin du processus.
Dans le cadre dun projet de gestion des identits et des accs, les besoins peuvent
voluer. En effet, le dploiement de nouveaux services implique notamment la dfinition de
nouveaux profils ainsi que de nouveaux rles applicatifs qui doivent tre pris en compte,
mme aprs la phase de spcification. De ce fait, ce modle de gestion de projet ne convient
pas aux projets de gestion des identits et des accs.
[16] W. W. Royce. Managing the Development of Large Software Systems : concepts and techniques.
Proceedings of the 9th international conference on Software Engineering, pages 1-9, 1970
41
3. Cycle en V
En 1983, J. McDermid et K. Ripken [17] ont dvelopp un modle de cycle de vie pour
pallier au manque de ractivit inhrent au modle prcdent. Pour cela, chaque livrable doit
tre test pour chacune des tapes. Lomniprsence des tests en parallle des activits garantit
la qualit du produit final. En fonction du jalon, la nature des tests diffre. Ainsi les
spcifications sont valides par des tests fonctionnels, galement appels tests de recette, dont
le droulement suit des scnarii dcrits dans les documents de spcification. Idalement, ils
sont automatiss, ou raliss par des personnes indpendantes de lquipe de dveloppement.
Ces tests ntant excuts quune seule fois la fin du projet (sauf si le produit livr nest pas
jug satisfaisant), il serait coteux de les automatiser.
Les tests dintgration ont pour but de valider que les dveloppements raliss sinterfacent
correctement avec les systmes dinformation existants.
Les tests unitaires ont pour objectif de vrifier que des portions du code oprationnel se
comportent comme le dveloppeur la prvu. Pour le dveloppement de ces tests, il est
conseill de suivre le modle de dveloppement men par les tests (en anglais : Test Driven
Development ) [18]. Ce processus suit quatre tapes :
1. Ecrire un premier test,
2. Vrifier qu'il choue (car le code qu'il teste n'existe pas) afin de vrifier que le test est
valide,
3. Ecrire le code minimal suffisant pour que le test sexcute correctement sans erreur,
4. Vrifier que le test nchoue plus,
5. Amliorer et complter le code tout en gardant les mmes fonctionnalits.
17
18
Figure 13 - Cycle de vie de projet en V
A linstar du modle en cascade, le modle en V prend difficilement en charge de

nouveaux besoins ou la modification des spcifications. En effet, leffet tunnel induit par les
modles squentiels montre quune erreur dans la formulation ou linterprtation des
spcifications ne peut tre dtecte qu la fin du cycle. En effet, la matrise douvrage nest
implique quen dbut et fin de cycle, ce qui peut reprsenter plusieurs mois dintervalle pour
un gros projet.
Bien que plus nombreuses que dans un cycle en V, les possibilits de prise en compte de
nouveaux besoins restent faibles. En effet, dans le cadre dun projet de gestion des identits et
des accs, aprs la phase de spcification, la mise disposition dun nouveau service, ne peut
tre prise en compte quau moment des tests dintgration. De plus, ces changements
impliqueraient la remise en cause du travail effectu jusqu la phase des tests unitaires.
[17] J. McDermid, K. Ripken. Life cycle support in the Ada environment. ACM SIGAda Ada Letters, v.III n.1,
pages 57-62, 1983
[18] K. Beck. Test Driven Development: By Example. Pearson Education, 240 pages, 2002
42

Lutilisation de ce type de cycle de vie pour un projet de gestion des identits et des accs
implique que lajout dune application, de laquelle dcoule de nouveaux rles, impose un
projet propre avec le droulement complet du cycle de vie. De ce fait, ce modle nest pas
recommand dans le cas dun projet de gestion des identits et des accs.
43
4. Cycle en spirale
En 1988, B. W. Boehm [19] a introduit les notions ditration et de prototypage dans le
cycle de vie dun projet informatique pour pallier au manque de visibilit inhrent aux
dmarches squentielles.
19
Une itration correspond lexcution du cycle de vie pour un sous-ensemble des

spcifications qui se conclut par la livraison dun produit oprationnel. La prise en compte de
lensemble des spcifications ncessitant plusieurs itrations, lquipe fonctionnelle du projet
dispose rgulirement dun outil quelle peut soumettre lensemble des tests voqus avec le
cycle en V. Cette dmarche permet de rajuster rgulirement les spcifications, budgets et
dlais. Une itration peut prendre en compte des spcifications qui ont dj fait lobjet dune
itration, ce qui offre une capacit de raction face lvolution des besoins.
Figure 14 - Diagramme d'activit d'une dmarche itrative
Un prototype est une ralisation partielle de ltape de codage qui simule le

comportement dun sous-ensemble des fonctionnalits attendues. Les rgles de codage ne sont
alors pas ncessairement suivies. Le prototype na pas vocation tre dploy. En effet, le but
est que les dveloppeurs soumettent leur comprhension des spcifications. Ce dialogue
permet de diminuer les risques en sassurant diffrents jalons du projet que les choix
dimplmentation rpondent aux besoins des clients du projet. En effet, le prototype est
soumis lvaluation de lquipe fonctionnelle du projet et peut subir des modifications
jusqu ce quil soit valid. Cest seulement partir de cette tape que les activits du projet
peuvent continuer.
Figure 15 - Diagramme d'activit de ralisation d'un prototype
Le modle en spirale, propos par B. W. Boehm, divise le cycle de vie global dun
projet en minimum trois itrations (reprsentes graphiquement par des spirales) qui suivent
chacune un cycle de vie complet compos de quatre phases :
1. Dtermination des objectifs partir de lanalyse des besoins ou du rsultat des cycles
prcdents,
2. Analyse des risques avec une phase ddie au prototypage,
3. Dveloppements et tests. Dans la dernire spirale il est possible de suivre une dmarche
squentielle telle que la cascade ou le V,
4. Validation du rsultat puis planification.
[19] B. W. Boehm. A Spiral Model of Software Development and Enhancement. ACM SIGSOFT Software
Engineering Notes, Volume 11 n.4, pages 14-24, 1986
44

La premire itration de lanalyse des besoins et des risques permet de placer les
fonctions critiques dans le premier cycle de prototypage et de dveloppement. Ainsi, les
objectifs et les dveloppements prendre en compte dans les itrations suivantes auront un
risque dimpact minimis sur les itrations antrieures.
Figure 16 - Cycle de vie de projet en spirale
Lvaluation rpte des besoins, des risques et des dveloppements propre ce modle
permet de contrler rgulirement si les dlais et budgets seront respects, contrairement aux
dmarches squentielles o ils ne peuvent tre vrifis qu lapproche de la date de livraison.
De plus, le client du projet est plus impliqu dans la vie du projet que dans les modles
linaires, o son action est limite la phase de rdaction du cahier des charges et la
validation du produit final.
La dmarche en spirale permet des interactions plus frquentes entre les diffrentes
quipes engages dans un projet par rapport aux modles linaires. Cependant, aprs la phase
de spcification, les besoins peuvent tre ajusts, mais il nest pas facile de prendre en compte
dimportantes modifications ou ajouts. En effet, ce type de changement implique de reprendre
compltement lanalyse de risque qui reprsente une part important du projet dans le cycle en
spirale.
Dans le cadre dun projet de gestion des identits et des accs, ce type de cycle de vie
permet de prendre en compte de nouveaux besoins induits par le dploiement de nouveaux
services. Cependant, les possibilits sont limites. Les spcifications doivent intgrer la
capacit de modification du primtre des applications sans imposer la ralisation dune
nouvelle analyse de risque qui peut tre longue et coteuse. Cette possibilit particulire doit
tre teste au plus tt lors de la ralisation dun prototype. Le cycle de vie itratif semble donc
envisageable pour des projets de gestion des identits et des accs. Cependant le cycle de vie
en spirale nest pas le plus adapt cause des impacts financiers et en dlai des analyses de
risque.
45
5. Mthodes Agiles
En 2001, dix-sept experts en dveloppement logiciel se sont runis pour prsenter leurs
mthodes (Adaptive Software Development, XP, Scrum, Crystal, Feature Driven
Development, Dynamic System Development Method (DSDM) et pragmatic
programming ) [20]. Suite lanalyse des avantages de chacune de ces mthodes, ils ont
extrait quatre valeurs fondamentales et douze principes pour constituer le manifeste des
mthodes de dveloppement Agiles (cf. annexe 4 The Manifesto for Agile Software
Development ).
20
Afin dobtenir un produit oprationnel rpondant aux attentes des utilisateurs, les
dmarches Agiles reposent sur les quatre rgles fondamentales suivantes.
Les individus et leurs interactions plutt que les processus et les outils,
Des logiciels oprationnels plutt quune documentation exhaustive,
La collaboration avec les clients plutt que la ngociation contractuelle,
Ladaptation au changement plutt que le suivi dun plan.
Pour mettre en pratique ces principes, les mthodes Agiles prconisent un cycle itratif
et incrmental incluant notamment les phases de spcification, dveloppement et validation.
Par rapport la dmarche en spirale, en Agilit le cycle est complt par la notion
dincrment mme si la notion est proche de celle ditration, dans le cas de lincrment, le
dcoupage du projet en sous-ensemble ne se fait plus au niveau des spcifications, mais au
niveau des composants. Un seul ensemble de composants est dvelopp par incrment.
Chaque incrment vient sintgrer au premier incrment du projet appel le noyau. La mise en
uvre de cette division des besoins et des composants, se fait au travers de Sprints . Le
sprint correspond une tape dun mois maximum dont les objectifs sont dfinis dans le
carnet du sprint, le Sprint backlog . Le sprint backlog spcifie les fonctionnalits qui
doivent tre dveloppes ou corriges lors du sprint. Les mthodes agiles ayant pour principe
de privilgier la ralisation de code fonctionnel plutt que la rdaction de documentation
technique ou fonctionnelle, cette dernire peut faire lobjet dun sprint ddi. Par ailleurs, la
plus grande partie des fonctions de loutil est dfinie en dbut de projet dans le carnet du
produit, le Product backlog . Chaque cas dutilisation est dcrit dans une User story
laquelle sont affectes une priorit et une estimation du volume de travail ncessaire pour le
dvelopper, le tester et le valider.
De plus, les mthodes Agiles prnent la collaboration entre les personnes impliques
dans et par le projet, ce qui requiert notamment lintgration de la matrise douvrage et des
utilisateurs au cours du dveloppement. Pour rpondre ces besoins, lquipe projet inclut un
propritaire du produit (en anglais : Product owner ) qui est un expert du mtier. Il va jouer
le rle du client. Il doit tre capable de dfinir les spcifications fonctionnelles, dtablir la
priorit des fonctionnalits dvelopper ou corriger et valider les fonctionnalits dveloppes.
Afin de favoriser le dialogue, les mthodes Agiles prvoient plusieurs types de runions
qui sont programmer diffrents moments du projet.
Avant chaque sprint, une runion de planification, le Sprint planning ou Iteration
planning , permet de slectionner dans le product backlog les fonctions implmenter qui
constitueront le sprint backlog en fonction des priorits du client.
Durant le sprint, la mle permet lquipe de se regrouper pendant quinze minutes
maximum quotidiennement pour voquer les problmes rencontrs dans la journe,
ventuellement y assigner des dveloppeurs supplmentaires, mais sans chercher les
[20] A. Cockburn. Agile software development. Addison-Wesley Longman Publishing Co., 278 pages, 2002
46

rsoudre. Lidentification des problmes peut tre facilite par la mise en place dune plateforme dintgration continue. Ce type doutil permet de compiler, vrifier et tester
automatiquement lensemble du code oprationnel ds quun nouvel lment est publi, ce qui
implique de suivre le modle Test Driven Development voqu prcdemment. Cette
runion permet galement de vrifier que toutes les user stories du sprint backlog seront
termines la date de fin prvue de litration.
A la fin du sprint, une runion de rtrospective, la Sprint review , permet de capitaliser sur
les problmes rencontrs, les solutions mises en uvre, ainsi que les causes de perte
defficacit et de qualit. Cest galement loccasion de prsenter le rsultat du sprint avec la
dmonstration des nouvelles fonctions ou des corrections.
La mise en uvre de ces concepts permet doffrir de la souplesse au projet et de donner
de la visibilit au client sur les ralisations.
Figure 17 - Cycle de vie en Agilit
Cette mthode est applicable pour le dveloppement initial dun projet mais aussi lors
de la maintenance applicative.
Dans le cadre dun projet de gestion des identits et des accs, la livraison ditrations
simples et successives peut permettre dassembler les informations sur les personnes et les
comptes utilisateurs au fur et mesure de la prise en compte de nouveaux systmes
dinformation. La difficult de synchronisation entre toutes les applications impactes est
alors rpartie sur plusieurs itrations. Lvolution des besoins tant la base de ce type de cycle
de vie, il convient parfaitement aux projets de gestion des identits et des accs.
47
Annexe 4. The Manifesto for Agile Software

Development
Seventeen anarchists agree:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan. That is, while we value the items on the
right, we value the items on the left more.
We follow the following principles:
Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
Welcome changing requirements, even late in development. Agile processes harness
change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with
a preference to the shorter timescale.
Business people and developers work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers and users
should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity.the art of maximizing the amount of work not done.is essential.
The best architectures, requirements and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin
Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick,
Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
www.agileAlliance.org
48
Annexe 5. Grille dvaluation technique

Les critres de la grille dvaluation sont issus en partie du cahier des charges de
gouvernance des accs mis disposition gratuitement par la socit guidescomparatifs.com.
1. Gestion des identits

Tableau XIII - Grille d'valuation technique : Rfrentiel intgr
Critres
Complments
La solution peut-elle utiliser un rfrentiel intgr ?
Annuaire LDAP
Base de donnes relationnelle
Autre
La solution est-elle compatible SAML ?
Compatible CAS, Shibboleth ?
Tableau XIV - Grille d'valuation technique : Connecteurs
Critres
Complments
Quels sont les connecteurs vers d'autres annuaires supports ?
Active Directory
Microsoft Exchange
NIS
OpenLDAP V3
Autre
Quels sont les connecteurs fichiers supports ?
Attribute-value pair text files

Delimited text file
Fixed-width text files
LDIF
Autre
Quels sont les connecteurs bases de donnes supports ?
Microsoft SQL Server

Oracle Database
MySQL
PostgreSQL
Autre
Quels sont les autres connecteurs supports ?
DSML 2.0
SAP
Autre
Peut-on dvelopper ses propres connecteurs ?

La solution permet-elle de dtecter des changements dans les
sources de donnes ?
Tableau XV - Grille d'valuation technique : Transformation
Critres
Complments
La solution permet-elle de traiter les donnes en entre et en sortie

d'un connecteur ?
Concatnation de chane
Oprations arithmtiques
Extraction de chanes
Autre
Quel langage de programmation est support pour le traitement

des donnes ?
Perl
PHP
C, C++
C#
Visual Basic
C#, .Net
XSLT
Java
JavaScript
Autre
49

Tableau XVI - Grille d'valuation technique : Provisioning
Critres
Complments
La synchronisation des informations est-elle gre par la solution ?
De manire vnementielle
Ncessite des actions manuelles
Autre
La solution permet-elle de crer, supprimer et modifier des entres

dans les applications via les connecteurs ?
La solution permet-elle de mettre en place un processus de
cration, modification ou suppression des comptes applicatifs au
travers des diffrents connecteurs (par exemple, cration de
l'entre dans l'application de ressources humaines en premier,
puis dans Active Directory, puis dans Novell Netware) ?
Par configuration graphique

Par programmation au niveau des
rgles de jointure et de transformation
La solution permet-elle de crer des comptes en masse ?

La solution permet-elle d'anticiper la cration de compte ?
La solution permet-elle la cration de comptes de test ?
La solution permet-elle de propager les informations rapidement ?
En moins de 30s
En temps rel
Sur vnement
La solution permet-elle de dsactiver temporairement un

utilisateur ou un groupe (pas d'authentification possible) ?
Priode de dsactivation
Dsactivation d'un utilisateur
Dsactivation d'un groupe ou d'un rle
Autre
2. Gestion des accs

Tableau XVII - Grille d'valuation technique : Gestion des rles
Critres
Complments
La solution supporte-t-elle des rles ?
Groupe dynamique
Groupe dynamique avec mise jour
automatique d'un attribut pour tous les
utilisateurs
La solution permet-elle de renommer les rles selon un langage

mtier ?
La solution permet-elle de prendre en compte la sparation des
responsabilits dans la dfinition des rles ?
La solution permet-elle de dfinir des exceptions l'intrieur de
rles paramtrs ?
La solution permet-elle de grer l'intgrit rfrentielle
(suppression automatique d'un membre d'un groupe en cas de
suppression de l'entre utilisateur associe) ?
Tableau XVIII - Grille d'valuation technique : Gestion des habilitations
Critres
Complments
La solution permet-elle d'envoyer rgulirement aux utilisateurs

une revue des utilisateurs sous leur responsabilit, afin de leur
faire valider ou invalider les accs de leur quipe ?
Peut-on dfinir
-la frquence ?
-la forme ?
-le primtre ?
Autre(s) paramtre(s)
La solution est-elle en mesure de mettre en uvre des processus

d'escalade dans le processus de certification des habilitations ?
Exemple: pour procdure provisoire de

dlgation lors de l'absence du
responsable
La solution produit-elle un reporting sur les revues

d'habilitation ?
50

Critres
Complments
La solution permet-elle de gnrer des alertes ?
Temps donn au processus de

certification
Niveaux d'habilitations
Habilitations exceptionnelles
Autre
Lors de l'autorisation d'une personne accder une application,

une fonction de workflow est-elle disponible pour informer et faire
valider par les personnes habilites l'autorisation de cet accs ?
Tableau XIX - Grille d'valuation technique : Gestion des mots de passe
Critres
Complments
La solution permet-elle de chiffrer les mots de passe ?

La solution gre-t-elle l'historique du mot de passe ?
Si Oui, peut-on paramtrer la limite de l'historique (par exemple,
10 derniers)
La solution permet-elle de grer le changement du mot de passe ?
Si Oui, peut-on forcer le changement du mot de passe la
premire connexion ?
En cas de gestion de mot de passe, peut-on forcer le changement
du mot de passe rgulirement ?
La solution gre-t-elle l'expiration du mot de passe ?
La solution permet-elle de contrler le contenu du mot de passe ?
La solution permet-t-elle le blocage d'un compte en cas d'erreur de
mot de passe ?
Nombre de tentatives
Dlai entre deux tentatives
Autre
La solution pert-elle de synchroniser les mots de passe avec Active

Directory ?
Tableau XX - Grille d'valuation technique : Contrle et traabilit
Critres
Complments
La solution dispose-t-elle de fonctions de traabilit ?
Peut-on dfinir
-la frquence ?
-la forme ?
-le primtre ?
Autre(s) paramtre(s)
Quels sont les vnements couverts par le module de traabilit ?
Authentification
Gestion de mot de passe
Workflow d'approbation
Modification de rle
Autre
Quel est le mode de gestion du module de supervision/traabilit ?
Traabilit passive
Gestion d'vnement / ractivit sur
vnement
Dans le cas d'une gestion ractive sur vnement, quel est le

primtre couvert par le dclenchement d'action ?
Par exemple 3 checs didentification +

1 russite sur 1 minute peuvent laisser
supposer une tentative d'intrusion
Quelles sont les actions possibles dclenches par le module de

supervision actif ?
Envoi de mail
Dconnexion d'accs
Autre
La solution dispose-t-elle de modles de rapports prdfinis ?
51

IAM Gestion Des Identites Et Des Acces

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IAM Gestion Des Identites Et Des Acces

Uploaded by

Copyright:

Available Formats

IAM :

GESTION DES IDENTITES

Contenu sous licence Creative Commons CC-BY-NC-ND

TABLE DES MISES A JOUR DU DOCUMENT

Objet de la mise jour

Anonymisation des exemples

Contenu sous licence Creative Commons CC-BY-NC-ND

LISTE DES ABREVIATIONS

Attribute Based Access Control (anglais)

Access Control List (anglais)

Correspondant Informatique et Liberts

Commission Nationale Informatique et Liberts

CRBAC : Constrained Role Based Access Control (anglais)

Comit de Rglementation Bancaire et Financire

Discretionary Access Control (anglais)

HRBAC : Hierarchical Role Based Access Control (anglais)

Identity & Access Management (anglais)

Identity Based Access Control (anglais)

Identity Provider (anglais)

Identifiant Unique Personnel

Mandatory Access Control (anglais)

National Institute of Standards and Technology

Plan Do Check Act/Adjust (anglais)

Role Based Access Control (anglais)

Relying Party (anglais)

Systme de Management de la Scurit de lInformation

Segregation of Duty (anglais)

Service Provider (anglais)

Single Sign-On (anglais)

Contenu sous licence Creative Commons CC-BY-NC-ND

3. G ESTION DES ACCES ................................................................... 16

4. B ONNES PRATIQUES .................................................................... 30

Contenu sous licence Creative Commons CC-BY-NC-ND

Rfrences documentaires ..................................................................................... 36

A NNEXE 1. ISO 24760 (T ABLE DES MATIERES ) ................................. 38

Cycle de vie ............................................................................................................. 40

A NNEXE 4. T HE M ANIFESTO FOR A GILE S OFTWARE D EVELOPMENT 48

Contenu sous licence Creative Commons CC-BY-NC-ND

LISTE DES FIGURES

Contenu sous licence Creative Commons CC-BY-NC-ND

LISTE DES TABLEAUX

Contenu sous licence Creative Commons CC-BY-NC-ND

Contenu sous licence Creative Commons CC-BY-NC-ND

2. Gestion des identits

Figure 1 - Diagramme de classe du concept d'identit

Contenu sous licence Creative Commons CC-BY-NC-ND

Figure 2 Diagramme de classe des concepts dattribut et didentifiant

2.1.3 Fournisseurs de service et didentit

Contenu sous licence Creative Commons CC-BY-NC-ND

Un fournisseur de service peut tre mis en uvre en corrlation avec le fournisseur

Contenu sous licence Creative Commons CC-BY-NC-ND

Figure 3 - Cycle de vie dune identit

Contenu sous licence Creative Commons CC-BY-NC-ND

Lorganisation met disposition un service de compte-rendu dactivit, un service de

Identit utilisatrice potentielle

Compte-rendu de lactivit (Crac)

Dpt et consultation de documents techniques (Doc)

Gestion du budget du service (Bdg)

Dossier de retraite (Ret)

Gestion des congs (Cge)

Contenu sous licence Creative Commons CC-BY-NC-ND

Figure 4 Modle de gestion didentit : identit isole

Dans le cadre de lexemple dcrit prcdemment, lutilisation du modle didentit