LES SYSTEMES DE GESTION DES IDENTITES ET DES ACCES : MISE EN ŒUVRE ET APPORT POUR LA SECURITE...

UNIVERSITE DE PICARDIE JULES VERNE

UNIVERSITE ABDELMALEK ESSAADI

ETUDES ET RECHERCHES

Effectué du 05 Mai au 05 Novembre 2012

Par

Ghislain Danny BATOMEN YANGA

Gisèle MEKUATE DEFO

Master M1 MIAGE Méthodes Informatiques Appliquées à la Gestion des Entreprises

Tuteur de projet : M. Yasser El Khamlichi

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET

DE LA RECHERCHE

ACADEMIE D’AMIENS

----------------------

LES SYSTEMES DE GESTION DES IDENTITES ET DES ACCES :

MISE EN ŒUVRE ET APPORT POUR LA SECURITE D’UNE

ORGANISATION

Promotion de Janvier 2012 – Semestre 1

Année Académique 2011 – 2012

Les systèmes de gestion des identités et des accès :

Mise en œuvre et apport pour la sécurité d’une organisation

Ghislain Danny BATOMEN YANGA, Gisèle MEKUATE DEFO MIAGE M1 2011 – 2012

ii ii

LISTE DES FIGURES ........................................................................................................................iv INTRODUCTION ............................................................................................................................ 1 Première partie : Généralités ........................................................................................................ 2 Chapitre 1 : Pourquoi un système de gestion des identités et des accès ? ....................................... 3

1.1. Etats des lieux ........................................................................................................................ 3 1.2. Justificatif d’un projet de gestion des identités et des accès ................................................ 4

1.2.1. Garantie de traçabilité et d’auditabilité .......................................................................... 5 1.2.2. Réduction des coûts d’administration............................................................................. 5 1.2.3. Amélioration de l’efficacité et de la réactivité ................................................................ 5 1.2.4. Amélioration de la sécurité ............................................................................................. 6

Chapitre 2 : Les concepts .............................................................................................................. 7

2.1. Les concepts de base ............................................................................................................. 7 2.1.1. Utilisateur ........................................................................................................................ 7 2.1.2. Compte ............................................................................................................................ 7 2.1.3. Rôle .................................................................................................................................. 8 2.1.4. Profil ................................................................................................................................ 8 2.1.5. Poste opérationnel .......................................................................................................... 8 2.1.6. Groupe ............................................................................................................................. 8 2.1.7. Périmètre ......................................................................................................................... 8 2.1.8. Mode d’authentification ................................................................................................. 9 2.1.9. Ressource ........................................................................................................................ 9 2.1.10. Environnement de SI ................................................................................................... 9 2.1.11. Environnement externe ............................................................................................... 9

2.2. Les concepts avancés : Fédération d’identités .................................................................... 10 2.2.1. L’identité fédérée .......................................................................................................... 10 2.2.2. La répartition des responsabilités ................................................................................. 10 2.2.3. Confiance entre les partenaires. ................................................................................... 11 2.2.4. La gestion d’identités fédérées ou Federated Identity Management ........................... 11

Deuxième partie : La gestion des identités et des accès pour la sécurité de l’information ............. 12 Chapitre 3 : La gestion des identités ............................................................................................ 13

3.1. Notions d’identités ............................................................................................................... 13 3.1.1. Définition ....................................................................................................................... 13 3.1.2. Utilité et gestion ............................................................................................................ 14

3.2. Modèles de gestion d’identités ........................................................................................... 15 3.2.1. Modèle isolé de gestion des identités ........................................................................... 15 3.2.2. Modèle centralisé de gestion des identités .................................................................. 16

3.2.2.1. Modèle commun de gestion des identités ............................................................ 16 3.2.2.2. Domaine d’identité avec authentification unique : SSO ....................................... 16

3.3. La fédération d’identités ...................................................................................................... 17 3.3.2. Objectif de la Fédération d’identité ............................................................................. 18

Table des matières




iii iii

3.3.3. Langages pour l’échange de l’information de sécurité ................................................. 19 3.4. Technologies de gestion d’identités .................................................................................... 20

3.4.1. Kerberos ........................................................................................................................ 20 3.4.2. Radius ............................................................................................................................ 20 3.4.3. Infrastructure à clé publique ......................................................................................... 21

Chapitre 4 : La gestion des accès ................................................................................................. 23

4.1. La gestion d’accès : le concept ............................................................................................. 23 4.1.1. Définition ....................................................................................................................... 23 4.1.2. Principe de fonctionnement .......................................................................................... 23

4.2. Modèles de gestion d’accès ................................................................................................. 25 4.2.1. Modèle RBAC ................................................................................................................. 25 4.2.2. Modèle MAC .................................................................................................................. 27 4.2.3. Modèle DAC ................................................................................................................... 27

4.3. Architectures de gestion d’accès ......................................................................................... 28 4.3.1. Architectures AAA ......................................................................................................... 28 4.3.2. Infrastructures de gestion à base de politiques ............................................................ 29

Troisième partie : Implémentations et expérimentations ............................................................ 31 Chapitre 5 : Les solutions de contrôle d’accès .............................................................................. 32

5.1. Architectures de gestion d’accès ......................................................................................... 32 5.2. Les solutions de gestion d’identités et de droits d’accès .................................................... 33

5.2.1. Les solutions propriétaires ............................................................................................ 33 5.2.2. Les solutions propriétaires ............................................................................................ 35

Chapitre 6 : Implémentation d’une solution de contrôle d’accès .................................................. 37

6.1. Environnement de travail .................................................................................................... 37 6.2. Présentation d’Active Directory ........................................................................................... 38

6.2.1. Active Directory et services d'accès et d'identité .......................................................... 38 6.2.2. Arborescence Active Directory ...................................................................................... 39

6.3. Création d’une nouvelle forêt avec Windows Server 2008 ................................................. 40 6.4. Gestion des utilisateurs et des ordinateurs ......................................................................... 41

6.4.1. Unité d’organisation ...................................................................................................... 41 6.4.2. Compte d’utilisateurs .................................................................................................... 42 6.4.3. Groupe Active Directory ................................................................................................ 44 6.4.4. Implémentation de la gestion a base des rôles en utilisant des groupes ..................... 45 6.4.5. Mises des machines clientes dans le domaine .............................................................. 48

6.5. Amélioration de la sécurité et piste d’audit ........................................................................ 48 6.5.1. Délégation des autorisations administratives ............................................................... 49

6.5.1.1. Approche de la délégation .................................................................................... 49 6.5.1.2. Délégation des comptes utilisateurs. .................................................................... 49

6.5.2. Configuration des paramètres de mot de passe et de verrouillage .............................. 52 6.5.2.1. Configuration des stratégies de comptes du domaine ......................................... 52 6.5.2.2. Stratégie de mot de passe affinée ......................................................................... 54

6.5.3. Audit de l’authentification de connexion ...................................................................... 54 6.6. Configuration du service DNS .............................................................................................. 56

CONCLUSION GENERALE ............................................................................................................. 59 BIBLIOGRAPHIE ........................................................................................................................... xv




iv iv

LISTE DES FIGURES LISTE DES FIGURES

Première partie : Généralités et définition des concepts ................................................................ 2 Chapitre 1 : Pourquoi un système de gestion des identités et des accès ? ....................................... 3 Figure 1.1 : Existant standard de la gestion des identités et des droits d’accès .................................. 4 Figure 1.2 : Flux de mise à jour après la mise en place d’une gestion centralisée .............................. 6 Chapitre 2 : Les concepts .............................................................................................................. 7 Figure 2.1 : la fédération d’identités ............................................................................................. 11 Deuxième partie : La gestion des identités et des accès pour la sécurité de l’information ............. 12 Chapitre 3 : La gestion des identités ............................................................................................ 13 Figure 3.1 : Entités, identités et identificateurs .................................................................................... 14 Figure 3.2 : Modèle isolé de gestion des identités ................................................................................ 15 Figure 3.3 : le modèle commun de gestion d’identités ......................................................................... 16 Figure 3.4 : le domaine d’identité avec authentification unique .......................................................... 17 Chapitre 4 : La gestion des accès ................................................................................................. 23 Figure 4.1 : Modèle RBAC de base ....................................................................................................... 25 Troisième partie : Implémentations et expérimentations ............................................................ 31 Chapitre 6 : Implémentation d’une solution de contrôle d’accès .................................................. 37 Figure 6.1 : Information système générale ........................................................................................... 37 Figure 6.2 : Arborescence Active Directory ........................................................................................... 40 Figure 6.4 : Informations d’un utilisateur .............................................................................................. 43 Figure 6.5 : Liste des utilisateurs de l’OU « Personnels » ...................................................................... 44 Figure 6.6 : Les groupes de rôles ........................................................................................................... 46 Figure 6.7 : Utilisateurs membres d’un groupe ..................................................................................... 46 Figure 6.8 : les propriétés d’un dossier partagé .................................................................................... 47 Figure 6.9: Les autorisations.................................................................................................................. 47 Figure 6.10 : Les groupes de règles ....................................................................................................... 48 Figure 6.11 : Postes de l’OU « Privés » .................................................................................................. 48 Figure 6.12 : Délégation de contrôle ..................................................................................................... 50 Figure 6.15 : Les paramètres de stratégies de mot de passe ................................................................ 53 Figure 6.16 : Les paramètres de stratégie de verrouillage du compte ................................................. 54 Figure 6.17 : Les stratégies affinées ...................................................................................................... 54 Figure 6.18 : Paramètres d’audit ........................................................................................................... 55 Figure 6.19 : Observateur d’événements .............................................................................................. 56 Figure 6.20 : La zone de recherche directe du domaine ....................................................................... 57 Figure 6.21 : Assistant de création de la zone de recherche inversée .................................................. 57

Liste des figures




1 1

INTRODUCTION

De plus en plus d’entreprises et d’organismes appréhendent l’intérêt d’une mise en place du

système d’information pour la gestion des identités et la sécurité des accès. Ce système est perçu

comme un maillon clé dans la chaine de sécurité des organisations Elle permet de renforcer le niveau

de sécurité général en garantissant la cohérence dans l’attribution des droits d’accès aux ressources

hétérogènes du système d’information.

Notre étude porte sur ces systèmes de gestion d’identités et de droits d’accès, et c’est

l’occasion pour nous de comprendre les concepts, l’architecture, les modèles utilisés pour la mise en

place d’un tel système.

L’étude ainsi réalisée a été découpée en trois(03) parties : dans la première partie nous avons

aborder les « généralités » afin de maîtriser toutes les notions et concepts qui tournent autour des

systèmes de gestion d’identités et même de comprendre l’intérêt d’un système de gestion

d’identités et de droits d’accès : dans la seconde partie dénommé « gestion des identités et des

droits d’accès » nous avons présenté les modèles, architectures et technologies (protocoles) utilisés

pour la gestion des identités et des habilitations ; et enfin dans la troisième partie « implémentation

d’une solution des gestions de identités et des droits d’accès» c’était l’occasion pour nous d’étudier

non seulement les solutions de gestion d’identités et d’accès offerts sur le marché mais aussi

d’expérimenter une de ces solutions à travers son implémentation.

Introduction




2 2

Première partie : Généralités

1ère partie :

Généralités et définition

des concepts




3 3

CHAPITRE 1 : CONTEXTE GENERAL DU PROJET Chapitre 1 : Pourquoi un système de gestion des identités et des accès ?

1.1. Etats des lieux

De nos jours, la multiplication et la diversité de systèmes de contrôle d’accès liés aux systèmes

d'exploitation et aux applications est devenue particulièrement contre-productive. En effet, chaque «

système» (OS, NOS, messagerie, groupware, applications métiers, ERP, CRM, etc.) est protégé par

une procédure de contrôle d'accès spécifique. De fait, chaque fonction à réaliser peut nécessiter un

code d’accès et des droits associés. Cette multiplicité de contrôles d’accès est source de confusion

pour l'utilisateur qui, par exemple, perd ou oublie ses mots de passe. Il lui reste alors deux solutions :

soit il sollicite le service de help-desk, au risque de l’engorger en lui faisant perdre trop de temps à

réinitialiser très souvent des mots de passe, soit il note lesdits codes sur un support à sa portée pour

ne plus les oublier ! Bien entendu, aucune de ces solutions n’est satisfaisante…

D’une manière générale, chaque système d’exploitation et/ou application est géré par un

administrateur unique ; de fait, toute vision globale est impossible. Dans ce cas, l’administration

autonome de chaque système est particulièrement source d’erreurs, de vulnérabilités et de perte de

temps. Par exemple, ne pas avoir la vision globale sur les droits de l’ensemble des utilisateurs peut

engendrer des problèmes de responsabilité (devenus importants dans le cadre des nouvelles lois ou

réglementations), tel qu’un acheteur qui validerait sa propre commande.

Généralement, les nouveaux arrivants se voient attribuer plus ou moins rapidement certaines

ressources (un bureau, un téléphone, un badge d’accès, un PC, etc.), mais ne peuvent pas travailler,

faute de droits d'accès. Ceci est notamment du au fait que le délai d’attribution des ressources et des

droits est trop long, que les circuits d’attribution sont trop « lourds», etc. Ils doivent même souvent

se débrouiller seuls : trouver le bon responsable pour l'accès à telle base de données, à telle

application, à l’Intranet, etc. La liste des interlocuteurs est à la mesure de la complexité du Système

d’Information.

D’autre part, on est rarement certain d'avoir supprimé tous les droits dont disposait un employé

partant ou d’avoir mis à jour les droits d’un employé en cas de changement de fonction. Le Système

d’Information regorge souvent de comptes dits « fantômes» (dormants et/ou périmés).

De plus, les comptes techniques génériques, installés par défaut, par les systèmes d’exploitation

et/ou les applications, ne sont pas toujours modifiés, voire supprimés, induisant d’autres failles. Ceci

étant d’autant plus grave que ces mots de passe sont facilement accessibles sur Internet… De même,

certaines personnes utilisent, lorsqu’elles arrivent dans l’entreprise, des comptes utilisateurs

«génériques» et partagés, simplement du fait de la durée importante de création de leur propre

compte.

Chapitre 1 : Pourquoi un système de

gestion des identités et des accès ?




4 4

Enfin, l’audit et la traçabilité sont souvent les parents pauvres de la mise en œuvre des droits

d’accès des utilisateurs. Pourtant, de plus en plus, les entreprises doivent respecter des normes, des

lois et/ou des réglementations strictes en matière de politique de contrôle interne.

La figure ci-dessous illustre l’état des lieux « standard »de la gestion des identités et des droits

d’accès dans une organisation

Figure 1.1 : Existant standard de la gestion des identités et des droits d’accès

1.2. Justificatif d’un projet de gestion des identités et des accès

Comme nous l’avons vu précédemment, l’absence de gestion globale des identités et des droits

d’accès peut générer de nombreux problèmes, parmi lesquels :

la perte de productivité due aux délais d’obtention des droits d’accès,

une charge importante d’administration (multiplication des administrateurs, réinitialisation

des mots de passe, etc.),

l’impossibilité de tracer les actions d’administration des droits et d’en contrôler la cohérence

et la pertinence,

la difficulté d’auditer les accès aux ressources,

des entorses au principe de séparation des tâches,

le non-respect des contraintes légales et/ou réglementaires (par exemple au travers d’un

mauvais paramétrage des règles de gestion).

La justification d’un projet de gestion des identités et des droits d’accès reposera sur les

améliorations suivantes :




5 5

1.2.1. Garantie de traçabilité et d’auditabilité

Il s’agit ici des principales lois et réglementations impliquant le SI et ayant des impacts directs sur

les aspects traitant de la sécurité (en particulier traçabilité et auditabilité)

D’une manière générale, ces lois et règlements « imposent» au Système d’Information des

exigences de :

continuité d’activité,

séparation des tâches : par exemple, une même personne ne doit pas à la fois commander

une fourniture ou prestation et valider sa réception,

traçabilité et d’auditabilité : permettant de valider « qui a fait quoi » au sein du système

d’information, et « qui a habilité qui », de respect de la vie privée.

Déroger à ces exigences peut entraîner un risque juridique pour les responsables de l’entreprise.

1.2.2. Réduction des coûts d’administration

Un système de gestion des identités et des droits d’accès permet d’alléger la charge de travail de

l’équipe de « support informatique» (administration, help desk). Cet allègement résulte d’une part

de l’automatisation de tâches de gestion de comptes (réduction du nombre d’administrateurs) et

d’autre part de la diminution du nombre d’appels d’utilisateurs (perte ou oubli de nombreux mots de

passe, relance de demandes d’accès, etc. .).

Le système de gestion des identités peut permettre aux utilisateurs la gestion directe de certains

aspects de leur profil (par exemple le mot de passe, l’adresse, les numéros de téléphone, etc.).

1.2.3. Amélioration de l’efficacité et de la réactivité

Un système de gestion des identités et des droits d’accès permet de réduire le nombre

d’interventions humaines par une automatisation de la propagation des droits sur les différents

environnements concernés. La conséquence est à la fois une réduction des délais de mise à

disposition des droits d’accès et une réduction des sources d’erreur (prise en compte systématique

de tous les besoins liés à l’activité de l’utilisateur, garantie de cohérence dans les droits attribués).

Les gains générés concernent à la fois les utilisateurs internes (gain de productivité) et externes

(amélioration de la qualité du service et de l’image de l’entreprise).

Sur un autre plan, lors d’une fusion ou d’une acquisition, il faut fournir le plus rapidement

possible un accès aisé aux ressources rassemblées d’entreprises auparavant autonomes. Là encore,

une solution de gestion des identités et des droits d’accès aidera à relever ce défi au




6 6

Travers d’un service d’intégration des informations multi-plates-formes permettant de connecter

les systèmes de chaque entreprise à la plupart des systèmes (nouveaux ou préexistants) de la

nouvelle entité.

1.2.4. Amélioration de la sécurité

Un système de gestion des identités et des droits d’accès permet de renforcer la sécurité. Une

telle approche conduit à établir des liens entre toutes les applications, bases de données et

annuaires en s’appuyant sur des notions de rôle et de profil. Cette solution offre un point unique de

gestion des règles de sécurité pour l’ensemble des systèmes concernés. Elle permet de créer

simplement des règles d’accès et de sécurité, en cohérence avec la Politique de Sécurité des

Systèmes d’Information et les besoins métier, puis de les propager automatiquement à tous les

systèmes de l’entreprise.

La gestion centralisée des identités permet d’éliminer une source considérable d’erreurs

d’administration pouvant causer des failles de sécurité d’accès au SI de l’entreprise. Elle permet

également de résilier complètement et immédiatement les droits d’accès sur l’ensemble des

systèmes lorsque des salariés ou personnels extérieurs quittent l’entreprise ou changent

d’affectation et supprimer ainsi les comptes « fantômes ».

En mettant en place des processus maîtrisés d’habilitation, le système permet d’impliquer les

responsables métiers dans le circuit d’habilitation et de ne plus laisser au seul administrateur

technique la maîtrise des droits d’accès.

La figure ci-dessous illustre les flux d’information d’une organisation ayant un système de gestion

des identités et des accès

Figure 1.2 : Flux de mise à jour après la mise en place d’une gestion centralisée




7 7

Chapitre 2 : Les concepts

Dans ce chapitre nous allons présenter les concepts utilisées dans le domaine de la sécurité des

systèmes d’information.

2.1. Les concepts de base

Les concepts de base portent sur les utilisateurs, groupes, profils,… donc il est question

d’expliciter ses notions parfois ambiguë.

2.1.1. Utilisateur

Désigne une personne physique : les employés d’entreprise, les prestataires, les partenaires et

les clients de l’entreprise qui, de par leur fonction, exercent une activité ayant vocation à leur

permettre de bénéficier des applications et des ressources mises à disposition par l’entreprise. Toute

personne déclarée dans un référentiel central de sécurité et de gestion des habilitations est

identifiée par un identifiant unique, un nom, un prénom, une durée de validité, un état (actif ou

suspendu), les périmètres d’accès autorisés….

2.1.2. Compte

À chaque personne peuvent être associés des comptes d’accès aux différents systèmes et

applications. Le compte est défini par l’identifiant d’accès, un mot de passe (ou un authentifiant

d’une autre nature), et plusieurs attributs supplémentaires en fonction de l’environnement dans

lequel il est crée comme: la politique de mot de passe associée, l’accès externe autorisé ou non,

l’état du compte, les modes d’authentification autorisés etc.

Il existe quatre types de comptes :

Compte global : il est unique à un utilisateur et identifie cet utilisateur dans le référentiel de

gestion des habilitations et est utilisé par tous les processus d’attribution des droits.

Compte utilisateur : Ce compte donne l’accès à un utilisateur dans un environnement

particulier auquel cet utilisateur est habilité. Exemples : compte d’OS, de NOS, de

messagerie, de LDAP.

Compte d’administration : Ce compte donne l’accès à un administrateur dans un

environnement particulier. Ce compte n’est pas associé à une personne. Il ne correspond

donc à aucune entrée dans le référentiel central de gestion des habilitations et son usage est

limité aux actes d’administration techniques des applications et environnements.

Chapitre 2 : Les concepts




8 8

Compte technique ou de service fonctionnel : Ces comptes sont utilisés par les composants

d’un système pour accéder aux services applicatifs et/ou données d’un autre système.

2.1.3. Rôle

Un rôle définit les permissions nécessaires à l’utilisation des objets (applications et/ou des

ressources).Une habilitation donne à un utilisateur un ensemble de permissions dans une

application. Elle est attribuée en fonction du poste opérationnel au sein de l’organisation et non à

titre individuel. C’est le poste opérationnel qui détermine les rôles et les périmètres nécessaires.

2.1.4. Profil

Un profil regroupe un ensemble de rôles nécessaires à l’exécution d’une fonction métier. Le

profil peut également être vu comme un package de rôles applicatifs ou un niveau supérieur dans la

hiérarchie des.

Un utilisateur peut avoir un ou plusieurs profils.

Le profil correspond généralement à la fonction exercée par l’acteur affecté au poste

opérationnel ainsi qu’à son niveau d’expertise. Il peut aussi correspondre à un ensemble

d’habilitations spécifiques.

2.1.5. Poste opérationnel

Le poste opérationnel (position de travail) correspond à une fonction métier exercée au sein d’un

élément de structure (service, département, …). Un poste opérationnel est toujours défini au sein

d’un et un seul élément de structure. Le responsable de structure indique les postes qui lui sont

attribués.

Un poste peut éventuellement être partagé par plusieurs acteurs.

Le poste opérationnel n’est pas modélisé dans le référentiel central.

2.1.6. Groupe

Les utilisateurs peuvent être regroupés, dans le référentiel central, en groupes statiques ou

dynamiques. Ces groupes sont utilisés pour faciliter la gestion en masse des habilitations.

2.1.7. Périmètre

Le périmètre est utilisé par les applications et/ou systèmes pour affiner le contrôle d’autorisation

qu’ils réalisent.

Le périmètre peut être associé à : une personne, un compte (uniquement dans le cas de

limitation des autorisations d’accès à des ressources d’un environnement) et un rôle.




9 9

Le périmètre peut être :

Temporel : permet de restreindre les possibilités d’accès d’un utilisateur dans le temps en

utilisant une période, une plage horaire ou un calendrier

Géographique : permet de restreindre les possibilités d’accès d’un utilisateur en fonction du

lieu à partir duquel il accède au SI.

Fonctionnel : permet de gérer la sécurité applicative : le programme autorisera ou non

certains traitements en fonction des données qui lui seront communiquées par le système

d’habilitation (identifiant acteur, poste de travail, éventuellement lieu de présence ou

d’affectation d’utilisateur, etc.).

2.1.8. Mode d’authentification

Certaines applications critiques imposent un mode d’authentification particulier (authentification

forte). Le système d’authentification fournit (dans le contexte de sécurité) l’information indiquant le

mode d’authentification utilisé lors de l’ouverture de la session. Cette information est exploitée par

le système de contrôle d’accès et /ou l’application.

Le mode d’authentification peut être associé à : un rôle, une ressource.

2.1.9. Ressource

La ressource est définie par : un libellé, les modes d’authentification nécessaires pour y accéder,

les périmètres d’accès autorisés, les rôles ou les groupes de comptes autorisés sur cette ressource.

Une ressource peut être : une ou des adresses IP des serveurs, une URL, une commande de

lancement d’une application….

2.1.10. Environnement de SI

Le terme d’environnement du SI désigne un ensemble de ressources et de processus (système,

sous-système, application, etc.) dont les droits d’accès sont gérés par un système de contrôle unique

et autonome et administré par l’entité responsable.

Exemples : les fichiers, répertoires, files d’attente, services de NOS, les fichiers, répertoires d’OS,

les ressources et les services applicatifs, les messageries et groupware, les bases de données

relationnelles,

2.1.11. Environnement externe

Le terme d’environnement externe désigne un ensemble de ressources et de processus

(système, sous-système, application, etc.) gérés par des tiers et dont les droits d’accès sont gérés par

un système de contrôle autonome et administrés par l’organisme tiers. Dans certains cas le contrôle




10 10

d’accès peut s’appuyer sur les informations de sécurité fournies par le SI de l’entreprise (identité

et/ou rôle).

L’intégration avec ce type d’environnement peut être faite de deux manières :

- délégation complète d’administration des habilitations et d’authentification

- provisioning du référentiel tiers.

Le développement constant des échanges commerciaux entre les partenaires via l’Internet est un

facteur important de multiplication des infrastructures mettant en œuvre ce type d’interaction. Le

besoin des possibilités d’intégration rapide des nouveaux partenaires a stimulé les multiples travaux

de normalisation.

Le concept général d’architecture permettant l’interaction entre les systèmes autonomes des

différents partenaires porte le nom de « Fédération des Identités ».

2.2. Les concepts avancés : Fédération d’identités

La fédération d’identité ou authentification répartie est un partage d’informations d’identité

concernant les utilisateurs d’un établissement avec un ou plusieurs organismes partenaires qui vise à

permettre l’accès à distance contrôlé et sécurisé aux ressources de ces partenaires.

Les solutions de fédération d’identités s’appuient sur quelques concepts tels que :

2.2.1. L’identité fédérée

C’est un ensemble d’attributs fédérés, c’est-à-dire d’informations relatives à l’identité provenant

de différentes sources et pouvant être mises en commun, apporte des gains fonctionnels pour

l’utilisateur : la possibilité de partager son identité entre les différents systèmes, ou pour

l’entreprise ; la possibilité de s’associer avec d’autres partenaires au sein d’une fédération, afin que

les identités d’un domaine puissent donner accès aux services d’un autre domaine sans être obligé

de mettre en œuvre une gestion lourde (et souvent pratiquement impossible) de gestion des

identités des utilisateurs de chaque partenaire.

2.2.2. La répartition des responsabilités

La propagation d’identités et la fédération inter partenaires s’appuient sur une organisation tri

partite

un fournisseur d’identité (Identity Provider ou IDP) : chargé d’authentifier l’utilisateur et de

gérer son identité (enregistrement, provisioning, gestion de comptes et de mots de passe),

un fournisseur de services (Service Provider ou SP) : chargé de lui fournir des services en

fonction de ses habilitations sur la base des informations fournies par le fournisseur

d’identités à qui il fait confiance, l’utilisateur.




11 11

2.2.3. Confiance entre les partenaires.

Tous les mécanismes de fédération d’identités se basent sur le principe fondamental d’existence

d’une relation de confiance entre les partenaires qui ont décidé de collaborer. Il est primordial que

ces relations de confiance soient établies et gérés sur trois niveaux :

métier où seront définis les services concernés par la fédération, les engagements de qualité

de service et les conditions de mise en œuvre. En particulier le fournisseur de service pourra

exiger une garantie de fiabilité et de niveau d’authentification de la part du fournisseur

d’identité,

légal où seront formalisées et contractualisées les exigences métier et définis les moyens et

les procédures de résolution de cas de litiges,

technique où seront définis les moyens techniques de mise en œuvre des liens sécurisés

entre les sites, les formats de jetons de sécurité et les processus de validation de

l’authenticité des informations échangées.

2.2.4. La gestion d’identités fédérées ou Federated Identity Management

C’est une façon standardisée de gérer de bout en bout le cycle de vie des identités, au sein de

l’entreprise et entre les entreprises,

Son rôle est de:

• étendre les pratiques de gestion des identités de l’entreprise,

• simplifier la gestion des identités au-delà des frontières de l’entreprise,

• faciliter l’intégration métier des partenaires via des relations de confiance et le partage

d’information dans un environnement sécurisé.

Figure 2.1 : la fédération d’identités




12 12

Deuxième partie : La gestion des identités et des accès pour la sécurité de l’information

2ème partie : La gestion des identités

et des accès pour la sécurité de l’information




13 13

Chapitre 3 : La gestion des identités

Dans ce chapitre, nous décrivons le concept de l’identité et les modèles de gestion d’identité

traditionnels. Nous détaillons, par la suite, la fédération d’identité qui offre des solutions aux

contraintes sécuritaires imposées par le déploiement d’un réseau distribué. Nous décrivons, en

détail, les langages utilisés pour l’échange de l’information de sécurité dans le cadre d’une

fédération.

3.1. Notions d’identités

3.1.1. Définition

Une identité est une représentation d’une entité dans un domaine d’application spécifique. Il

permet de singulariser, nommer, isoler une entité prise parmi un ensemble.

A priori, on attend d’une identité, qu’elle soit associée à une entité unique : une hypothèse

simplificatrice considère qu’une identité unique ne pourra jamais être associée à plusieurs entités

différentes. Il ne faut pas la confondre avec une identité commune, qui est associée à des entités

élémentaires ayant une relation de groupe. Ainsi, dans une famille l’identité commune est donnée

par le nom de famille, qui devient alors une caractéristique appartenant aux différents membres du

groupe. Dans la mesure où le fournisseur de services est concerné, ce dernier traite l’entité réelle (la

famille) et non pas un ensemble d’individus.

Une entité peut avoir des identités multiples, certaines pouvant être des synonymes. Suivant le

contexte, une entité peut avoir de zéro à N identités. Par exemple, dans une université, une

personne peut avoir deux identités : l’une en qualité d’étudiant parce qu’elle prépare un doctorat,

l’autre en qualité d’enseignant parce qu’elle exerce en qualité d’ATER (Attaché Temporaire

d’Enseignement et de Recherche). Les règles d’enregistrement des identités dans un domaine

spécifique déterminent si une entité a le droit d’avoir plusieurs identités dans ce domaine spécifique.

Une personne peut toujours avoir plusieurs identités dans des domaines différents. Par exemple, une

personne peut avoir une identité associée en tant que client d’une banque et une autre identité

associée car il est employé d’une entreprise.

On comprend dès lors les difficultés sous jacentes qui naissent de la création et de la

manipulation des identités dans un système. Une identité est construite à partir d’un ensemble de

caractéristiques nommées des “identificateurs”. Ces caractéristiques peuvent avoir diverses

propriétés telles qu’être temporaires ou permanentes, auto choisies par l’entité ou bien affectées

par une autorité, avoir une portée limitée à une organisation, ou bien transgresser cette même

organisation.

Les caractéristiques retenues pour la construction d’une identité peuvent être Différentes selon

le type d’entités identifiées. Par exemple, la date de naissance est valable pour des personnes ; par

contre, le numéro national d’enregistrement est valable seulement pour une organisation.

Chapitre 3 : La gestion des identités




14 14

La relation entre entités, identités et caractéristiques/identificateurs est présentée dans ci-dessous :

Figure 3.1 : Entités, identités et identificateurs

La Figure ci-dessus illustre le fait qu’une entité, une personne ou une organisation, peut avoir

plusieurs identités, et où chaque identité est construite à partir d’un ensemble de caractéristiques

qui peuvent être des identificateurs uniques (ou non uniques). La séparation entre les deux notions «

identité » et « identificateurs » n’est pas toujours évidente. Le terme identité est généralement

utilisé dans le sens d’un identificateur spécialement quand l’identité est reconnue par un seul

identificateur dans un contexte donné. Un domaine d’identité est un domaine où chaque identité est

unique. En définissant un espace de noms d’identificateurs uniques dans un domaine, des relations

de type « un à un » entre identités et identificateurs sont possibles. Toutes les caractéristiques des

identités ne peuvent être des identificateurs uniques d’où la nécessité de l’établissement d’un

espace de nom qui soit conforme aux normes.

3.1.2. Utilité et gestion

Au-delà de la construction d’une identité, viennent se greffer toutes les problématiques

associées aux actions que l’on peut exercer en revendiquant cette identité. Le simple fait de disposer

d’une identité, donne un certain nombre de prérogatives vis-à-vis d’une organisation.

Chaque fois qu’un fournisseur de services veut mettre ses services et ses ressources à la

disposition des autres, il doit vérifier l’identité de l’utilisateur demandant le service ou la ressource et

s’assurer qu’il a bien le droit d’utiliser ce service ou cette ressource. Dans ce contexte, la gestion des

identités consiste en l’attribution d’un identificateur unique et d’attributs à l’utilisateur durant la

phase d’enregistrement de ce dernier. Ces identificateurs et attributs sont vérifiés par le fournisseur

de services pour prendre sa décision (autoriser/refuser l’accès de l’utilisateur à la ressource

demandée).




15 15

Plusieurs technologies sont utilisées de nos jours pour gérer les identités dans un domaine de

sécurité ou au moins, permettre aux administrateurs IT des organisations de contrôler les identités

des utilisateurs internes et externes. Nous entendons par gérer une identité le fait de vérifier

l’identité d’une entité à travers des moyens physiques (par exemple, rencontre de l’entité en

question), attribuer à cette entité les accréditations (identificateurs et caractéristiques uniques) et

enfin l’authentifier chaque fois qu’elle désire accéder à un service protégé.

3.2. Modèles de gestion d’identités

Les modèles de gestion d’identité expliquent comment un administrateur donne des

identificateurs aux utilisateurs afin qu’ils soient reconnus et authentifiés par les fournisseurs de

services.

3.2.1. Modèle isolé de gestion des identités

Le modèle de gestion des identités le plus courant permet aux fournisseurs de services d’agir en

tant que fournisseurs d’identificateurs et d’attributs pour leurs clients. Il leur incombe alors de

contrôler l’espace de noms pour la mise en œuvre d’un service donné et d’affecter les identifiants

aux utilisateurs. Un utilisateur recevra un identificateur unique et des attributs pour

l’authentification (par exemple, des mots de passe) ; Si un usager met en œuvre simultanément

plusieurs services, il doit alors recevoir de tels éléments en provenance de chacun des fournisseurs

de services avec qui il communique. Les utilisateurs sont obligés de gérer des identités égales au

nombre de fournisseurs de services qu’ils veulent contacter pour demander des services.

Figure 3.2 : Modèle isolé de gestion des identités

Cette approche fournit des moyens pour une gestion des identités simple par les fournisseurs de

services mais qui devient rapidement ingérable pour les utilisateurs. Ceci rend ces systèmes




16 16

inadaptés aux environnements distribués collaboratifs où le nombre d’utilisateurs et de ressources

partagées ne cesse d’augmenter. En effet, la croissance du nombre de services en ligne induit au fait

que les utilisateurs deviennent débordés par les identificateurs et les attributs qu’ils doivent gérer. La

perte ou l’oubli de ces identificateurs et attributs coûtent chers aux fournisseurs de services qui

doivent mettre en place un centre de support (helpdesk) pour la récupération de ces éléments et

répondre aux demandes des utilisateurs.

3.2.2. Modèle centralisé de gestion des identités

Pour apporter une solution au problème de plus en plus critique d’exploitation des modèles

isolés, on peut alors chercher à centraliser l’information au sein d’un système. Un tel modèle se

décompose alors en un ensemble de sous modèles :

3.2.2.1. Modèle commun de gestion des identités

Pour ce modèle, un seul fournisseur d’identificateurs et d’attributs est utilisé par tous les

fournisseurs de services pour gérer les comptes de leurs utilisateurs. Dans ce cas de figure, une seule

autorité endosse les responsabilités d’identifier, d’affecter et de valider l’identité des utilisateurs

communiquant avec l’ensemble des fournisseurs de services .Un utilisateur s’authentifie auprès de

l’ensemble de fournisseurs de services en utilisant les mêmes identificateurs et attributs.

Figure 3.3 : le modèle commun de gestion d’identités

3.2.2.2. Domaine d’identité avec authentification unique : SSO

Cette approche étend le modèle de gestion des identités commun en permettant aux

utilisateurs de s’authentifier auprès d’un seul fournisseur de services du domaine et d’être par la

suite considérés comme authentifiés auprès des autres fournisseurs. Cette approche est




17 17

communément appelée authentification unique ou SSO parce qu’un utilisateur doit s’authentifier

une seule fois pour accéder à l’ensemble de services offerts par les fournisseurs du domaine

Figure 3.4 : le domaine d’identité avec authentification unique

Un exemple à citer utilisant ce modèle c’est Microsoft Windows Live ID (anciennement .Net

Passport) [Windows Live] qui est une implémentation de SSO pour le commerce électronique.

Windows Live ID permet, grâce à une unique adresse de messagerie et à un mot de passe, de se

connecter sur tous les sites web autorisés. L’affectation d’attributs et l’authentification des

utilisateurs sont deux fonctions centralisées sous le contrôle de Microsoft.

3.3. La fédération d’identités

3.3.1. Principe de fonctionnement

La fédération d’identité *Clusif 2007+ ou authentification répartie est un partage d’informations

d’identité concernant les utilisateurs d’un établissement, avec une organisation partenaire qui vise à

permettre l’accès à distance contrôlé et sécurisé aux ressources de ce partenaire.

La fédération concrétise, pour un groupement d’organisations, l'interconnexion de leurs services

d'authentification et l'utilisation d'un ensemble commun d'attributs utilisateurs.

Un établissement qui gère un ensemble d'utilisateurs (identificateurs et attributs) est appelé

fournisseur d'identités (IdP : Identity Provider). Un fournisseur de services (SP) est une entité (e.g.

établissement, administration, entreprise, etc.) qui propose une ressource numérique en ligne au

sein de la fédération.




18 18

Etablir une fédération d’identité entre organisations revient à définir un cercle de confiance

entre des fournisseurs d’identité et des fournisseurs de services de sorte que ces derniers acceptent

des accréditations émises par les fournisseurs d’identité pour leurs propres utilisateurs

Techniquement, les relations de confiance entre les membres d'une fédération reposent sur des

certificats électroniques et des métas donnés partagées. En outre, la confiance s'établit

administrativement entre les participants de la fédération au travers d'une convention (e.g. signature

de contrats entre organisations).

Une même organisation peut participer à plusieurs fédérations et gérer des partenariats de

manière bilatérale. Elle peut également jouer à la fois le rôle de fournisseur d'identités et de

fournisseur de services. La fédération d'identité est fondée sur deux concepts :

la délégation de l'authentification qui consiste à authentifier l'utilisateur depuis le service

d'authentification interne (organisation mère de l’utilisateur), et non pas depuis celui du

fournisseur de l'application (fournisseur de service)

la propagation des attributs utilisateurs qui permet de prolonger depuis l’organisation mère

de l’utilisateur l’exploitation d’un identifiant unique et des attributs de comptes internes afin

de communiquer avec le fournisseur de services.

3.3.2. Objectif de la Fédération d’identité

L’intérêt de l’adoption du principe de fédération d’identité est le fait que la fédération ne fait

qu’utiliser les moyens d’authentification, d’autorisation et de sécurisation implémentés par les

organisations partenaires ce qui favorise un déploiement rapide et à faible coût du réseau

collaboratif en évitant un blocage qui pourrait naître de l’absence d’un mécanisme commun

d’authentification.

Les principaux objectifs d’une fédération d’identité sont :

L’interconnexion de tout ou partie des Systèmes d’Information des organisations d’une façon

sécurisée et aisée,

Le partage de ressources de manière contrôlée et sécurisée. De ce fait, elle fournit le moyen

d’échanger de l’information de sécurité entre les domaines de sécurité *Federation 2007+.

Cette information permet de « reconnaître » un utilisateur au niveau du site partenaire et de

prendre la décision d’autorisation (autoriser/refuser l’accès de l’utilisateur à la ressource

demandée). Avec la fédération d’identité, l’hétérogénéité des systèmes d’authentification

(RADIUS, Kerberos, ICP X.509, etc.) des partenaires n’est plus un problème. Chaque

partenaire utilise les systèmes d’authentification et d’accréditation déployés au niveau de

son SI, gère les comptes et les accréditations de ses propres utilisateurs et transmet aux sites

partenaires l’information de sécurité qui sert à la prise de décision d’autorisation.




19 19

3.3.3. Langages pour l’échange de l’information de sécurité

Etant donné que dans le cadre d’un réseau distribué collaboratif, les systèmes déployés sont

plutôt hétérogènes, il s’est révélé indispensable d’exprimer l’information de sécurité dans un langage

qui soit compréhensible par tous les systèmes et les technologies existants : un langage indépendant

des plateformes ce qui permet un meilleur dimensionnement et favorise le passage à l’échelle. Ainsi,

un besoin de langages standardisés, pour l’expression de l’information de sécurité et pour offrir le

moyen de surpasser les limites des plateformes implémentées aux niveaux des sites partenaires, est

né.

L’information de sécurité (preuve d’authentification et les accréditations d’un utilisateur),

échangée entre les sites partenaires, peut être exprimée en utilisant des standards tels que Security

Assertion Markup Language (SAML) ou bien des spécifications telles que Web Services-Federation

(WS-Federation).

Sécurity Assertion Markup Language : SAML

SAML suppose qu’une entité (utilisateur ou application) possède déjà une identité unique gérée

par un IdP qui fournit localement un service pour authentifier cette entité. SAML ne spécifie pas (et

ne s’intéresse pas à) comment le service d’authentification local est implémenté ; c’est de cette

manière qu’il fournit une solution à l’hétérogénéité des systèmes d’authentification implémentés

chez les différentes organisations.

SAML 2.0, dans sa conception, fournit des solutions pour l’authentification unique(SSO),

interaction de Services Web en plus de la fédération d’identité. Ceci, dans le but de faire collaborer

des entités appartenant à des domaines de sécurité différents.

Web Services Fédération : WS-Fédération

WS-Federation, une spécification définie par IBM, Microsoft et d’autres sociétés, propose aux

organisations un moyen pour l’échange d’identités et d’attributs entre systèmes d’authentification et

d’autorisation distribués.

Le cadre de fédération défini par la spécification s’appuie sur la famille de spécifications

destinées aux Services Web WS-*. WS-Federation repose, en particulier, sur WS-Security3 et WS-

Trust4 et définit de nouveaux mécanismes de fédération étendant ces différentes spécifications. En

fait, l’objectif visé par WS Federation est d’aborder les exigences d’identités et de sécurité des

applications et des services Web. Ceci n’était pas un objectif de base lors de la définition du standard

SAML 2.0.

Les mécanismes de fédération définis dans la spécification WS-Federation peuvent être utilisés

par :

- Des Web Services (application cliente) supportant les mécanismes de WS-Security e

- WS-Trust et, pouvant communiquer avec un Web Service (application serveur)

- Des navigateurs Web étant donné que la spécification définit les mécanismes nécessaires à

l’encapsulation de messages WS-* en messages HTTP.WS-Federation adopte une approche

d’émission/d’échange de jetons de sécurité




20 20

En définitive des langages pour l’échange de l’information de sécurité, SAML 2.0 et WS-

Federation sont similaires en termes de fonctionnalités offertes.

Leurs spécifications introduisent les briques nécessaires à la gestion des cas de figures traitant la

fédération d’identité et le Web SSO.

D’un côté, SAML 2.0 est une spécification autonome. Le standard définit les profils et les

protocoles nécessaires à la prise en considération des cas de figures sans s’appuyer sur d’autres

technologies ou spécifications. De son côté, WS-Federation et en raison de son approche

composable, permet le déploiement des cas d'utilisation de différentes manières, mais cela se fait au

détriment de la simplicité. WS-Federation s’appuie sur WS-Trust, WSSecurityPolicy et sur d’autres

standards et spécifications pour traiter un cas d’utilisation. C’est cette approche composable qui

permet à WS-Federation d’être plus adaptée, que le standard SAML 2.0, aux architectures orientées

services (Web Services) en ce qui concerne la prise en considération de contraintes telles que la

propagation de l’identité du demandeur d’un Web Service, la délégation entre Web Services, etc.

3.4. Technologies de gestion d’identités

Parmi les technologies existantes qui fournissent un moyen de contrôler l’identité sans toutefois

être un vrai et un système complet de gestion des identités, nous citons :

3.4.1. Kerberos

Kerberos, créé au Massachusetts Institute of Technology (MIT), est un protocole d’identification

réseau conçu pour fournir un mode d’authentification forte pour les applications clients/serveurs en

utilisant le principe de chiffrement à clé secrète. Kerberos [Kerberos 1996] [Kerberos 2005] utilise un

système de tickets au lieu de mots de passe en texte clair ; ce principe renforce la sécurité du

système et empêche que des personnes non autorisées interceptent les mots de passe des

utilisateurs. Le ticket joue le rôle d'une carte d'identité à péremption assez courte.

L’identification Kerberos est utilisée par des protocoles/applications tels que Windows Server

2000, le serveur Web Apache, le client de transfert de fichiers FileZilla, etc.

Dans cette solution deux points particuliers sont à noter : les mécanismes de Chiffrement

renforcent l’aspect sécuritaire en proposant l’exploitation d’un système de gestion de clés. Le

système de tickets quant à lui offre une décorrélation entre celui qui en réclame l’obtention et

l’usage que l’on peut en faire. A la limite, en supposant que préalablement il y ‘ait eu une usurpation

d’identité réalisée en amont, le pirate peut obtenir très légitimement un droit d’accès à une

ressource sans qu’aucun mécanisme ne permette de revenir en arrière.

3.4.2. Radius

Remote Authentication Dial-In User Service (RADIUS), mis au point par la société Livingston

Enterprises, est un protocole client/serveur permettant de centraliser des données d'identification.

RADIUS [RADIUS 2000a] [RADIUS 2000b] est conçu pour gérer les connexions d'utilisateurs à des

services distants, et notamment ce qui relève de la politique d'autorisation, des droits d'accès et de

la traçabilité. Il base son identification sur le principe du couple nom d’utilisateur/mot de passe.




21 21

Le protocole RADIUS repose principalement sur un serveur RADIUS, relié à une base

d'identification (base de données, annuaire, etc.) et un client RADIUS, appelé Network Access Server

(NAS), faisant office d'intermédiaire entre l'utilisateur final et le serveur. L'ensemble des transactions

entre le client RADIUS et le serveur RADIUS est chiffré et authentifié grâce à un secret partagé. Le

serveur RADIUS peut transmettre les requêtes du client à d'autres serveurs RADIUS.

En termes de sécurité, les données transportées par RADIUS transitent en clair, seul le mot de

passe (de l’utilisateur final) est chiffré.

La sécurité impose la sécurisation des échanges entre les utilisateurs et le serveur par sécurité

physique ou à travers des solutions comme les Réseaux Privés Virtuels (VPN) [Scott et al. 1999].

RADIUS n'offre pas de mécanisme d’identification du serveur; il est alors tentant dans le cadre de

certaines attaques de se faire passer pour un serveur afin de récolter des noms et mots de passe.

Pour remédier à toutes ces faiblesses, des extensions ont été proposées pour RADIUS :

a) Extensible Authentication Protocol (EAP) [Saillard 2003] conçu pour étendre les fonctions du

protocole RADIUS à des types d'identification plus complexes. EAP permet ainsi une

identification mutuelle du client et du serveur.

b) Diameter [Calhoun et al. 2003] qui n'est pas vraiment une extension mais un successeur du

protocole RADIUS, est basé sur Transmission Control Protocol (TCP) alors que RADIUS est en

User Datagram Protocol (UDP)

Diameter utilise des attributs de grande taille et il est destiné aux échanges entre serveurs sur

des liaisons sûres en utilisant Internet Protocol Security (IPsec) et Transport Layer Security (TLS) par

exemple.

RADIUS est conçu pour fonctionner dans des réseaux d’infrastructures explicitement configurés

(réseaux des fournisseurs d’accès Internet, réseaux locaux sans fil, etc.). Il n’est pas adapté aux

réseaux d’ordinateurs et des stations de travail. En plus, il n’offre pas la fonctionnalité

d’authentification unique comme Kerberos.

Le principe de fonctionnement de Kerberos et de RADIUS repose respectivement sur La notion

de tickets et des mots de passe pour l’authentification des utilisateurs auprès des contrôleurs de

domaine (respectivement KDC et le serveur RADIUS). Afin de renforcer le niveau d’authentification

offert par les mots de passe et les tickets de services, la notion de clés publiques et de certificats

numériques est introduit. Clés publiques et certificats numériques sont gérés au niveau

d’infrastructures appelées Infrastructures à Clés Publiques.

3.4.3. Infrastructure à clé publique

Les Infrastructures à Clés Publiques ou PKI sont un ensemble de composants

Physiques (ordinateurs, équipements cryptographiques), de procédures humaines (vérification,

validation) et de logiciels (systèmes et applications) en vue de gérer le cycle de vie des certificats

numériques. Un certificat numérique est une carte d'identité numérique dont l'objet est d'identifier

une entité physique ; c’est un lien entre l'entité physique (le sujet) et l'entité numérique (clé

publique).

Une clé publique est une quantité numérique, attachée à une ressource ou un individu, qui

la distribue aux autres afin qu'ils puissent lui envoyer des données chiffrées ou pour qu’il puisse




22 22

déchiffrer sa signature. A chaque clé publique correspond une clé privée qui va être transmise à

l’entité physique avec son certificat numérique.

Une clé privée est une quantité numérique secrète attachée à une ressource ou à un

individu, lui permettant de déchiffrer des données chiffrées avec la clé publique correspondante ou

d'apposer une signature au bas de messages envoyés vers des destinataires.




23 23

Chapitre 4 : La gestion des accès

Il est évident que la gestion des identités des utilisateurs à elle seule n’est pas suffisante surtout

dans des environnements ouverts où les contraintes de sécurité pèsent énormément sur les

organisations membres. En effet, il ne suffit pas de répondre à la question : « qui peut accéder à la

ressource » mais en plus, il faut préciser « il peut faire quoi une fois qu’il a accédé ».

Les solutions telles que le SSO et la fédération d’identité étudiée dans le chapitre 3 offrent un

certain niveau d’autorisation lié à l’identité de l’utilisateur. En effet, avec le SSO, un utilisateur

s’authentifie une seule fois auprès d’un système et depuis, il peut accéder à tous les autres systèmes

qui sont dans le même domaine de confiance de ce système. De même pour la fédération d’identité

mais avec en plus l’accès à des systèmes qui se trouvent dans d’autres domaines de sécurité. Mais,

de notre point de vue et, dans les cas de figures où les contraintes de sécurité sont énormes, un tel

type d’autorisation n’est pas suffisant et devra être amélioré et renforcé. Dans ce chapitre, nous

expliciterons le concept de contrôle d’accès, puis présenterons les modèles existants de gestion des

accès et enfin nous expliciterons les architectures de gestion d’autorisation utilisées.

4.1. La gestion d’accès : le concept

4.1.1. Définition

Par la gestion des accès, nous entendons les systèmes qui peuvent avoir recours aux services

d'authentification et d'autorisation, afin de mieux maîtriser l'utilisation d'un réseau de ressources.

Chaque ressource, fournie par une organisation, est protégée par des règles qui la rendent accessible

uniquement aux entités ayant les accréditations nécessaires.

4.1.2. Principe de fonctionnement

La gestion des habilitations est basée sur les principes suivants :

tout accès au Système d’Information est conditionné par une authentification et une

autorisation. L’authentification peut être déléguée à un système tiers de confiance,

tout acteur du système est déclaré d’une manière unique dans un référentiel central de

sécurité en tant que personne physique et peut disposer de comptes dans différents

environnements et de permissions dans les applications en fonction des habilitations

accordées. La cohérence de ces informations est maintenue automatiquement par le système

de gestion des habilitations,

toute habilitation est attribuée en fonction du poste opérationnel au sein de l’organisation

et non à titre individuel. Le poste opérationnel détermine les rôles et les périmètres

Chapitre 4 : La gestion des accès




24 24

nécessaires. Le poste opérationnel (position de travail) correspond à une fonction métier

exercée au sein d’un élément de structure,

un utilisateur peut avoir un ou plusieurs profils. L’attribution se fait en fonction du poste

opérationnel de l’utilisateur,

un profil regroupe un ensemble de rôles nécessaires à l’exécution d’une fonction métier,

un rôle définit les permissions nécessaires à l’utilisation d’une application ou des ressources,

Les définitions des rôles, profils ainsi que l’attribution des profils aux personnes se font via un

outil central qui propage ensuite les informations nécessaires vers toutes les applications et

environnements concernés. L’association personne / rôle applicatif (ou profil applicatif) est

gérée hors application, lorsque l’application l’autorise. Cela permet d’éviter d’avoir à

développer une gestion des droits des utilisateurs dans l’application,

l’association personne / rôle applicatif est gérée de façon statique et explicite dans l’annuaire

de sécurité (plutôt que de façon dynamique à base de règles de gestion organisationnelles).

L’évaluation des droits, par le système de contrôle d’accès, doit être basée pour l’essentiel

sur la consultation de ce rôle applicatif explicite (pas d’interprétation de règles complexes

dans le processus d’autorisation),

un contrôle permanent de l’adéquation des profils attribués aux rôles effectifs des

personnes, la définition des droits d’accès aux ressources ou aux groupes de ressources est

administré dans les environnements cibles via les outils natifs de ces environnements. Les

administrateurs locaux continuent de gérer les ressources elles-mêmes et leurs associations

avec les habilitations,

le contrôle d’accès lui-même est assuré soit par les composants du socle technique (cas de

ressources et applications Web) soit par les mécanismes natifs des environnements (OS,

NOS, messagerie, groupware, etc) soit par les applications.

Il est à noter donc que les informations nécessaires à la gestion des habilitations sont distribuées

dans différents référentiels. On distingue :

a. le référentiel des habilitations, référentiel mis à jour lors de la gestion des utilisateurs,

des habilitations et des mots de passe,

b. les annuaires de sécurité, qui ne contiennent qu’une partie des données du référentiel

des habilitations (par exemple, les profils n’y figurent pas) et sont utilisés par les services

d’authentification et d’autorisation, tels que :

o Systèmes d’exploitation,

o Sous systèmes de gestion des droits,

o LDAP,

o NOS (Network Operating Systems) et systèmes de partage des fichiers,

o Messageries et systèmes collaboratifs.




25 25

4.2. Modèles de gestion d’accès

4.2.1. Modèle RBAC

Le modèle de sécurité RBAC (Role Based Access Control) est principalement issu d'Internet afin

de prendre en compte des applications déployées sur de vastes organisations ou des applications

inter-organisations (Extranet par exemple). Ce modèle permet en particulier de simplifier

l'administration des droits et de prendre en compte la délégation de l'administration.

Le modèle RBAC modélise des fonctions métiers plutôt que des accès à des ressources

informatiques. Un rôle correspond à une fonction au sein d'une organisation. Le principe de base du

RBAC est que deux utilisateurs ayant les mêmes rôles ont les mêmes droits sur le système.

Modèle RBAC de base

Le standard propose un modèle de base (Core RBAC) ainsi que les extensions présentées dans

les sous-chapitres suivants.

Les concepts manipulés par le modèle RBAC sont les suivants : USERS (utilisateurs), ROLES, OBS

(objets), OPS (opérations), PRMS(Permissions), SESSIONS.

Suivant le schéma ci-dessus :

Figure 4.1 : Modèle RBAC de base

Principe de privilège minimum

Le fonctionnement de ce modèle et l’intégrité du système sont garantis si l’attribution des

permissions respecte le principe de privilège minimum.

Ce principe exige que l’utilisateur ne dispose pas de plus de droits que nécessaire à son travail.

Ce qui implique que les permissions affectées à un rôle constituent le strict minimum nécessaire à

l’accomplissement des tâches relatives à ce rôle.




26 26

Modèle RBAC hiérarchique

Le modèle RBAC hiérarchique (Hierarchical RBAC) ajoute au modèle de base le support de

hiérarchie des rôles.

La hiérarchie établit les liens de parenté entre plusieurs niveaux des rôles et permet aux rôles «

parents » de disposer des permissions attribuées aux rôles « enfants ».

Le standard admet deux types de hiérarchies :

a) Le modèle hiérarchique général (General Hierarchical RBAC) : cette variante établie des

relations multiples entre plusieurs « parents » et « enfants »,

b) Le modèle hiérarchique limité (Limited Hierarchical RBAC) : cette version limite la

relation à une simple structure d’arborescence. Ce qui veut dire qu’un rôle ne peut avoir

qu’un seul « parent ».

Cette extension du modèle permet une administration plus efficace dans les grandes structures

qui gèrent de très nombreuses permissions d’un grand nombre d’utilisateurs. D’autre part ce

principe permet de bien gérer les situations où certains rôles différents (du niveau supérieur) doivent

bénéficier de certaines permissions communes.

Modèle RBAC avec contraintes

Le modèle RBAC avec contraintes (Constrained RBAC) ajoute au modèle la contrainte de

séparation des pouvoirs. Cette contrainte permet d’inclure dans le modèle la gestion de conflits

d’intérêts et assurer que les utilisateurs bénéficieront des permissions selon la politique définie par

l’organisation et ne pourront pas abuser de cumul non contrôlé de droits.

a) Séparation Statique des Pouvoirs (SSD - Static Separation of Duty Relations)

La contrainte de séparation des pouvoirs est utilisée pour assurer le respect de la politique des

habilitations. Un conflit d’intérêts peut arriver (dans un système du type RBAC) quand l’utilisateur

obtient simultanément les droits associés à des rôles incompatibles.

L’exclusion mutuelle de certains rôles est spécifiée par les règles de SSD. Ces règles sont

interprétées lors du processus d’affectation des rôles par l’administrateur et l’empêchent d’affecter

des rôles incompatibles au même utilisateur. De cette manière, à une personne qui bénéficie d’un

rôle, on ne pourra pas affecter un deuxième rôle interdit par la règle de SSD.

b) Séparation Dynamique des Pouvoirs (DSD - Dynamic Separation of Duty Relations)

La séparation dynamique limite comme la SSD les rôles accessibles à un utilisateur. Par contre le

contexte est différent. La limitation n’est pas exploitée au moment de l’affectation des rôles mais au

moment de leur activation dans une session. Dans une même session, un utilisateur a la possibilité

de ne pas activer tous ses rôles, mais uniquement le sous-ensemble de ses rôles nécessaires à la




27 27

réalisation de la tâche à accomplir. Ce mécanisme permet de garantir l’application des permissions

minimales nécessaires dans une période d’exécution d’une tâche. On peut parler, dans ce contexte,

de révocation temporaire des privilèges. La mise en œuvre de ce mécanisme peut se révéler très

complexe et le plus souvent n’est pas réalisée.

4.2.2. Modèle MAC

En opposition avec le DAC où le propriétaire d’une ressource jouit de tous les droits sur une

ressource qu’il a créée, le modèle Mandatory Access Control est utilisé quand la politique de sécurité

d’une organisation définit que :

a) les décisions de protection d’une ressource ne doivent pas être sous la responsabilité de

son propriétaire,

b) le système doit mettre en œuvre les mécanismes permettant de respecter la politique de

sécurité et interdire au propriétaire d’une ressource d’agir à sa guise.

Afin d’aboutir à ces principes, ce modèle introduit la notion d’accès aux ressources en regard de

la sensibilité des informations qu’elles contiennent et repose sur la labellisation systématique de ces

ressources et des utilisateurs du système considéré. En hiérarchisant ces entités en plusieurs niveaux

de confiance et sensibilité, puis en les labélisant en conséquence, on aboutit à une décomposition à

laquelle il faudra ensuite ajouter des règles d’accès. On notera qu’un système informatique adhérant

à ce principe est dit multi-level security (MLS).

Les labels suivent une logique hiérarchique (ex: Confidentiel, Secret, Très secret, non classifié) et

décrivent ainsi différents niveaux d’habilitation. Les droits d’accès aux ressources sont attribués en

fonction du niveau d’habilitation de l’utilisateur et sont définis selon la problématique de sécurité à

adresser : Confidentialité ou Intégrité.

4.2.3. Modèle DAC

Le DAC (Discretionary Access Controls) est un modèle conceptuel dont le principe est de limiter

l’accès à des objets en regard de l’identité des utilisateurs (humain, machines, etc.) et/ou des

groupes auxquels ils appartiennent. Les contrôles sur une ressource sont dits discrétionnaires dans le

sens où un utilisateur avec une autorisation d'accès définie est capable de la transmettre

(indirectement ou directement) à n'importe quel autre utilisateur.

Ce modèle est principalement utilisé au sein d’implémentations informatiques car les notions

développées sont surtout adaptées à la gestion d’accès sur des ressources informatiques. Ainsi, les

implémentations adhérant à ce concept, doivent mettre en œuvre des mécanismes permettant

d’enregistrer un ensemble de droits d’accès ou d’actions représentées sous la forme d’une matrice

de contrôle d’accès.

Fichier Gisèle Fichier Danny

Gisèle rwx r

Léa r

Danny r rwx




28 28

Parmi les différentes implémentations réalisées, les plus connues sont :

Protection Bits: Popularisée par les systèmes Unix, cette implémentation représente la

matrice de droits d’accès par colonne. Son principe consiste à définir pour une ressource

si elle est partagée pour tous les utilisateurs, un groupe ou seulement son propriétaire,

Access Control Lists (ACLs): Le principe des ACLs implémente la matrice de contrôle

d’accès par colonne en créant des listes d’utilisateurs pouvant accéder à la ressource

et/ou des listes d’utilisateurs interdits d’accès à celle-ci,

Capabilities: Comme pour les ACL une liste est créée, mais elle est liée à un utilisateur et

non à une ressource, ainsi la représentation de la matrice est faite par ligne.

4.3. Architectures de gestion d’accès

4.3.1. Architectures AAA

Une architecture d’autorisation doit complémenter le concept de fédération d’identité que nous

avons adopté pour l’échange d’information de sécurité sur les utilisateurs entre les fournisseurs

d’identité et les fournisseurs de services.

Des architectures d’autorisation bâties autour d’un serveur unique qui assure des fonctionnalités

d’authentification, d’autorisation et de comptabilité (AAA : Authentication Authorization Accounting)

se révèlent comme une solution possible pour répondre aux besoins relevés en termes de gestion

d’accès (qui a droit de faire quoi, comment et dans quelles circonstances).

Les entités de base qui participent à une autorisation dans le cadre d’une architecture AAA sont :

- Un utilisateur qui demande un service,

- L’organisation de tutelle de l’utilisateur concomitante du contrat établi et qui doit vérifier

sous une forme active ou passive si l’utilisateur est habilité ou non à déclencher l’exécution

du service,

- Le serveur AAA du fournisseur de services qui autorise l’accès au service en se basant sur le

contrat signé avec l’organisation mère de l’utilisateur et

- L’équipement du fournisseur de services dédié à l’approvisionnement du service

Ce concept de serveur AAA permet de faire la rupture définitive entre services d’authentification

et d’autorisation d’un côté et les applications gérées d’un autre côté mais, ça reste une solution de

gestion centralisée.




29 29

Figure 4.2 : Architecture AAA

4.3.2. Infrastructures de gestion à base de politiques

Les systèmes de gestion à base de politiques sont une solution de remplacement des ACLs

intégrées habituellement aux applications gérées. Elles rendent la gestion plus dynamique et

évolutive. Avec une telle approche, pour une autorisation efficace, deux actions doivent être

réalisées :

- Une décision d’autorisation doit être prise après consultation de politiques et,

- La décision doit être appliquée.

Ces deux fonctions sont accomplies par deux entités distinctes nommées

Respectivement PDP (Policy Décision Point) et PEP (Policy Enforcement Point).

Un PDP est une entité logique qui prend des décisions d’autorisation en considérant les

informations suivantes :

o La ressource demandée et l’action requise (consultation, modification, etc.),

o L’entité qui demande la ressource et,

o La politique qui gère l’accès à la ressource.

Un PEP est une entité logique qui applique la décision d’autorisation prise par le PDP. C’est le PEP

qui réalise techniquement l’attribution ou le refus d’une demande d’accès à une ressource. Les

interactions entre PDPs et PEPs peuvent suivre l’un des modèles suivants :

Modèle Agent, permet à l’utilisateur d’adresser sa requête de demande de ressource, à une

partie tierce (le serveur d’autorisation : PDP/PEP). Ce dernier joue le rôle d’agent entre

l’utilisateur et l’équipement fournissant le service.

Modèle Push, L’utilisateur adresse sa requête directement au fournisseur de service (i.e. la

ressource demandée) et en particulier, au serveur d’autorisation (PDP) qui gère l’accès à la

ressource

Modèle Pull. Le modèle Pull laisse la responsabilité de la récupération de l’information

d’autorisation au PEP seul. Une fois que l’utilisateur a demandé l’accès à une ressource




30 30

4.3.3. Infrastructures de gestion des privilèges

Une IGP fournit un cadre d’autorisation basé sur les attributs des utilisateurs pour gérer les

accès aux ressources et aux services. L’utilisation de certificats d’attributs rend le service

d’autorisation plus flexible et rigide et, c’est pour cette raison que nous avons adopté le concept

d’IGP pour bâtir une architecture de contrôle d’accès.

Une IGP fournit un cadre dans lequel il est possible d’appliquer la politique d’autorisation

d’accès ou d’attribution au niveau des applications ou des ressources en fonction du rôle des

utilisateurs ou de leur appartenance à un groupe. Un rôle dépend de la position de l’utilisateur (e.g.

ingénieur, cadre, technicien) dans son organisation de rattachement. Le processus de définition de

rôles est fondé sur une analyse approfondie de la façon dont fonctionne une organisation et intègre

une contribution d'un large éventail d'utilisateurs dans une organisation.

En d’autres termes, une IGP permet l’allocation, la délégation, la révocation et le retrait des

privilèges ou droits des utilisateurs d’une façon électronique.

Au sein d’une Infrastructure de Gestion de Privilèges, des politiques de contrôle d’accès gérant

l’accès aux ressources protégées doivent être définies, évaluées et appliquées. Ces politiques de

contrôle d’accès viennent remplacer les listes de contrôle d’accès (ACLs) qui étaient définies et

intégrées aux ressources auxquelles elles s’appliquent.




31 31

Troisième partie : Implémentations et expérimentations

3ème partie : Implémentations et

expérimentations




32 32

Chapitre 5 : Les solutions de contrôle d’accès

Dans ce chapitre, il sera question d’étudier quelques logiciels de gestion d’identités et des droits

d’accès qui sont présents actuellement sur le marché, tant sur l’environnement windows et

l’environnement linux.

5.1. Architectures de gestion d’accès

De nombreuses offres de solutions de gestion des identités et des droits d’accès existent sur le

marché ; et de plus en plus d’entreprise ont du mal à faire un choix de solutions optimales en

présence de ces nombreux logiciels d’IAM.

Cependant une solution de gestion d’accès doit respecter au minimum certains critères et c’est à

partir de ces critères que le choix des logiciels présentés ci-dessous s’est opérer. Parmi les critères de

choix d’une solution de gestion des identités et des accès nous avons retenus:

Facilité de déploiement et de configuration

Ce critère est intéressant car il n’est pas question de demander à l’entreprise de modifier la

structure de son système d’information. La solution devra être déployé et configuré facilement

indépendamment de l’existant.

Approche adoptée pour gérer la fédération

Ce critère permet d’évaluer la facilité de l’intégration de l’outil à l’existant dans l’entreprise et

définir la stratégie de déploiement de l’outil dans l’infrastructure TI.

Conformité au langage d’échange de l’information SAML 2 et WS-Federation

Un outil qui ne supporte pas les langages SAML ou WS-Federation, ne pourra pas être utilisé

sinon un problème d’hétérogénéité surgit.

Possibilité de fédérer l’identité entre les web-services

Ce critère permet d’évaluer l’efficacité de l’outil car un jour ou l’autre, les organisations auront à

traiter des identités dans le cadre d’architectures orientées services.

Le coût de la solution

Ce critère est toujours critique dans le choix d’une solution à déployer par les organisations.

Support pour différents systèmes hétérogènes

Chapitre 5 : Les solutions de

contrôle d’accès




33 33

Un outil de fédération qui va s’intégrer au SI d’une organisation doit supporter les systèmes

d’authentification déployés et utilisés jusqu’à présent par l’organisation. Une remise à zéro ne sera

jamais acceptée.

Niveau de sécurité offerte

Ceci présente un critère critique pour les organisations qui vont accepter d’ouvrir leurs SI aux

partenaires en s’appuyant sur l’outil de fédération. En aucun cas, les organisations n’accepteront de

se baser sur une solution de fédération pouvant leur risquer la perte de leurs actifs.

Respect de la vie privée

Ceci pourrait être critique ou pas, tout dépend de la stratégie adoptée par les partenaires

concernant la conservation de la vie privée des entités communicantes.

5.2. Les solutions de gestion d’identités et de droits d’accès

5.2.1. Les solutions propriétaires

Tivoli Identity management d’ IBM

IBM Tivoli Identity Manager est une solution d'applications des accès utilisateur basée sur des

règles qui gère les rôles, identités et droits d'accès des utilisateurs dans toute l'infrastructure

informatique. Ce logiciel sécurisé de gestion des identités est facile à déployer et à utiliser. Il permet

aux organisations de se mettre en conformité avec les réglementations, de gérer les risques et

autorise une collaboration sécurisée.

Tivoli Identity Manager permet de réaliser des économies et d'améliorer la productivité grâce à

l'automatisation, le libre-service utilisateur et d'autres innovations.

IBM propose aussi la solution pour l’identité fédérée dénommé Tivoli Federated Identity

Manager (TFIM).

Identity & accès management d’Evidian

Des centaines de milliers d'utilisateurs accèdent à leurs applications chaque jour par

l'intermédiaire des solutions de gestion de l'authentification d'Evidian. Le single sign-on (SSO)

simplifie leur travail car ils n'ont pas besoin de mots de passe pour accéder à leurs applications. Cela

réduit considérablement la charge du help desk, assurant un retour sur investissement rapide. Les

accès aux PC et aux applications peuvent faire l'objet d'une authentification forte par carte à puce,

badge radio, biométrie ou mot de passe à usage unique. La demande de mot de passe en self-service

(SSPR) rend les utilisateurs autonomes : les employés en déplacement ne sont jamais bloqués parce

qu'ils ont oublié leurs données d'authentification.

Avec les solutions IAM d'Evidian, les entreprises déploient la gestion des identités et un

workflow d'approbation pour s'assurer que les utilisateurs individuels respectent la politique d'accès

aux applications. Les solutions d'Evidian sont conçues pour être adaptables et compatibles avec les




34 34

processus d'entreprise, notamment en termes de disponibilité et de mobilité. Ainsi, la sécurité

renforce l'activité de l'entreprise.

Oracle Identity and accès management

La suite complète d'Oracle offre le meilleur retour sur investissement : sécurité accrue, coûts

administratifs allégés, grande évolutivité et la garantie de support d'un leader du marché. Les

solutions offertes de sont :

Oracle Access Management Suite Plus

Oracle Access Manager

Oracle Adaptive Access Manager

Oracle Directory Services Plus

Oracle Enterprise Single Sign-On Suite

Oracle Entitlements Server

Oracle Identity Analytics

Oracle Identity Federation

Oracle Identity Manager

Oracle Identity & Access Management Suite Plus

Oracle Information Rights Management

Oracle Management Pack for Identity Management

Oracle Role Manager

Oracle Security Governor for Healthcare

Oracle Web Services Manager

Oracle Identity and accès management est présenté comme l’offre de solutions la plus

complète.

Services Active directory de Microsoft

Les services Active Directory sont utilisés dans la plateforme système Windows server et

incluent : Les services de certificats Active Directory (AD CS),

Les services de domaine Active Directory (AD DS),

Les services AD FS (Active Directory Federation Services),

Les services AD LDS (Active Directory Lightweight Directory Services) et les services AD RMS

(Active Directory Rights Management Services).

Ces services seront expérimentés dans le chapitre suivant

http://www.oracle.com/us/products/middleware/identity-management/oracle-access-mgmt/index.html?ssSourceSiteId=ocomfr

http://www.oracle.com/us/products/middleware/identity-management/oracle-access-manager/overview/index.html?ssSourceSiteId=ocomfr

http://www.oracle.com/us/products/middleware/identity-management/oracle-ada-access-mgr/overview/index.html?ssSourceSiteId=ocomfr

http://www.oracle.com/us/products/middleware/identity-management/oracle-directory-services/overview/index.html?ssSourceSiteId=ocomfr

http://www.oracle.com/us/products/middleware/identity-management/oracle-enterprise-sso/index.html?ssSourceSiteId=ocomfr

http://www.oracle.com/us/products/middleware/identity-management/oracle-entitlements-server/overview/index.html?ssSourceSiteId=ocomfr

http://www.oracle.com/us/products/middleware/identity-management/oracle-identity-analytics/overview/index.html?ssSourceSiteId=ocomfr

http://www.oracle.com/us/products/middleware/identity-management/oracle-identity-federation/overview/index.html?ssSourceSiteId=ocomfr

http://www.oracle.com/us/products/middleware/identity-management/oracle-identity-manager/overview/index.html?ssSourceSiteId=ocomfr

http://www.oracle.com/us/products/middleware/identity-management/oiam/index.html?ssSourceSiteId=ocomfr

http://www.oracle.com/us/products/middleware/identity-management/information-rights-mgmt/overview/index.html?ssSourceSiteId=ocomfr

http://www.oracle.com/us/products/middleware/identity-management/oracle-mgmt-pack-for-im/overview/index.html?ssSourceSiteId=ocomfr

http://www.oracle.com/us/products/middleware/identity-management/oracle-role-manager/overview/index.html?ssSourceSiteId=ocomfr

http://www.oracle.com/us/products/middleware/identity-management/security-governor-healthcare-168615.html?ssSourceSiteId=ocomfr

http://www.oracle.com/us/products/middleware/identity-management/oracle-web-services-mgr/overview/index.html?ssSourceSiteId=ocomfr




35 35

5.2.2. Les solutions propriétaires

Plusieurs solutions libres existent mais de nombreuses critiques sont apportés notamment :

souvent hétérogènes et non-interopérable, complexes à mettre en œuvre, souvent de qualité

médiocre, souvent mal supportées, souvent peu industrialisés, souvent peu robuste.

Cependant, Nous avons pu étudier quelques des solutions open source de gestion d’identité et

d’accès :

Internet2 shibboleth

Shibboleth est une suite de logiciels développée par le consortium Internet2, fournissant une

solution complète de fédération d’identités.

Les trois briques Shibboleth sont le fournisseur de services, le fournisseur d’identités et le

service de découverte (ou WAYF).

Le fournisseur de services est un module d'authentification pour le serveur Web ; il permet de :

- déléguer l'authentification des utilisateurs à un fournisseur d'identités ;

- transmettre le profil utilisateur ;

- gérer le contrôle d'accès de manière optionnelle.

Le fournisseur d'identités est une application Java (servlet) ; il permet de gérer l'authentification

des utilisateurs, en réponse à la requête d'un fournisseur de services. L'authentification peut être

déléguée à un serveur CAS (Central Authentication Service) : l'authentification se fait par login/mot

de passe ou certificat électronique ou encore propose les deux ; les attributs de l'utilisateur sont

extraits d'un annuaire LDAP, d'une base SQL ou bien calculés, puis propagés au fournisseur de

services.

Le service de découverte (WAYF) permet à un utilisateur de sélectionner son organisme de

rattachement, c'est-à-dire celui auprès duquel il pourra s'authentifier. Le service de découverte

propose un menu déroulant à l'utilisateur avec la liste des fournisseurs d'identités reconnus.

FederID

FederID est une solution qui intègre les projets libres suivants :

- Authentic : un fournisseur d'identités basé sur lasso (Liberty Alliance SSO) capable d'utiliser

un annuaire LDAP comme base d'authentification.

- LemonLDAP::NG : un portail SSO compatible Liberty Alliance, dont les autorisations sont

gérées directement dans l'annuaire LDAP.

- InterLDAP : un outil de gestion de contenu d'annuaires LDAP et fournisseur d'attributs sur un

cercle de confiance Liberty Alliance.




36 36

OpenIAM

Multiplate-forme (Unix, mac,windows), openIAM est la solution open source de gestion d’accès

et d’identité qui fournit les services tel que : provisionning, gestion des mots de passe, administration

déleguée, synchronisation active, moteur de workflow… Elle inclut les connecteurs pour LDAP,

Active Directory, Google Apps et les bases de données relationnelles.




37 37

Chapitre 6 : Implémentation d’une solution de contrôle d’accès

Dans ce chapitre, il sera question de présenter la solution de contrôle d’accès Active Directory et ses services et de le mettre en œuvre par son déploiement.

6.1. Environnement de travail

La solution Active Directory est implémentée dans l’environnement serveur Windows Server

2008 R2.

Pour ce qui est de Windows Server 2008 R2, la version Windows Serveur 2008 R2 Edition Enterprise

a été utilisé.

Nous avons installé ce système serveur en dual boot sur une machine physique aux

caractéristiques telles que nous la voyons sur la copie d’écran :

Figure 6.1 : Information système générale

Nous avons bénéficié des nouvelles fonctionnalités de Windows Server 2008 R2 tel que Hyper-V

pour virtualiser les rôles de serveur et client sous forme de machines virtuelles séparées s’exécutant

sur l’unique ordinateur physique, sans avoir à acquérir un logiciel tiers.

Pour cela, nous avons créé 03 machines virtuelles (01 serveur et 02 clients) :

Les caractéristiques d’un poste serveur sont :

• Matériel : Processeur 1 Ghz, RAM 512 Mo, DD 40 Go, architecture 64bits

• Logiciel : Windows Server 2008 R2 Edition Entreprise

Les caractéristiques d’un poste client sont :

• Matériel : Processeur 1 Ghz, RAM 512 Mo, DD 20 Go, architecture 32bits

• Logiciel : Windows XP, Windows 7

Chapitre 6 : Implémentation d’une

solution de contrôle d’accès




38 38

6.2. Présentation d’Active Directory

Active Directory est le nom du service d'annuaire (au sens informatique) de Microsoft. AD

permet de regrouper toutes les informations concernant le réseau, que ce soient les utilisateurs, les

machines ou les applications. L'utilisateur peut ainsi trouver facilement des ressources partagées, et

les administrateurs peuvent contrôler leurs utilisations grâce à des fonctionnalités de sécurisation

des accès aux ressources répertoriées.

AD a pour objectif de permettre la gestion des comptes, des ordinateurs, des ressources et de la

sécurité de façon centralisée, dans le cadre d’un domaine. Un domaine constitue un ensemble

d’utilisateurs et de machines dont le contrôle est centralisé.

6.2.1. Active Directory et services d'accès et d'identité

Active Directory fournit la solution d'identité et d'accès (IDA) pour les réseaux d'entreprise

fonctionnant sous le système d'exploitation Windows®. IDA est nécessaire pour préserver la sécurité

des ressources de l'entreprise telles que les fichiers, les e-mails, les applications et les bases de

données. L'infrastructure IDA devrait effectuer les opérations suivantes :

Stocker des informations sur les utilisateurs, les groupes, les ordinateurs et les autres

identités. Comme nous l'avons vu, une identité est une représentation d'une entité qui

effectue des actions dans le réseau de l'entreprise. Par exemple, un utilisateur ouvre des

documents dans un dossier partagé sur un serveur. Vous savez que le document est

sécurisé avec des autorisations sur une liste ACL. L'accès au document est géré par le

sous-système de sécurité du serveur qui compare l'identité de l'utilisateur aux identités

de la liste ACL pour déterminer si la demande d'accès de l'utilisateur doit être accordée

ou refusée. Des ordinateurs, des groupes, des services et d'autres objets effectuent

également des actions sur le réseau ; ils doivent être représentés par des identités. Parmi

les informations stockées sur une identité, il y a les propriétés qui identifient de manière

unique l'objet, telles qu'un nom d'utilisateur ou un SID et le mot de passe de l'identité. Le

magasin d'identités est donc un composant d'une infrastructure IDA. La banque de

données Active Directory, également appelée annuaire est un magasin d'identités.

L'annuaire lui-même est hébergé et géré par un contrôleur de domaine : un serveur

jouant le rôle AD DS.

Authentifier une identité. Le serveur n'accorde pas à l'utilisateur l'accès au document à

moins qu'il ne soit sûr de la validité de l'identité présentée dans la demande d'accès. Pour

valider l'identité, l'utilisateur fournit des secrets connus uniquement par lui-même et

l'infrastructure IDA. Ces secrets sont comparés aux informations du magasin d'identités

lors d'un processus appelé authentification.

Dans un domaine Active Directory, un protocole appelé Kerberos est utilisé pour

authentifier les identités. Lorsqu'un utilisateur ou un ordinateur ouvre une session sur le

domaine, Kerberos authentifie ses informations d'identification et émet un ensemble

d'informations appelé ticket d'accord de ticket (TGT). Pour que l'utilisateur puisse se

connecter au serveur et demander le document, une requête Kerberos est envoyée à un




39 39

contrôleur de domaine avec le TGT qui permet d'identifier l'utilisateur authentifié. Le

contrôleur de domaine envoie à l'utilisateur un autre ensemble d'informations appelé

ticket de service qui identifie l'utilisateur authentifié sur le serveur. L'utilisateur présente

le ticket de service au serveur qui l'accepte comme preuve d'authentification de

l'utilisateur.

Ces transactions Kerberos conduisent à une connexion réseau unique, ou authentification

unique. Après l'ouverture de session initiale de l'utilisateur ou de l'ordinateur et la remise

d'un TGT, l'utilisateur est authentifié dans l'ensemble du domaine et peut recevoir des

tickets de service qui l'identifient auprès de n'importe quel service. Toute cette activité de

tickets est gérée par les clients et services Kerberos intégrés à Windows et est

transparente pour l'utilisateur.

Contrôler l'accès. L'infrastructure IDA est responsable de la protection des informations

confidentielles telles que les informations stockées dans le document. L'accès aux

informations confidentielles doit être géré conformément aux stratégies de l'entreprise.

L'ACL sur le document reflète une stratégie de sécurité composée d'autorisations qui

spécifient des niveaux d'accès pour des identités particulières. Le sous-système de

sécurité du serveur dans cet exemple effectue la fonctionnalité de contrôle d'accès dans

l'infrastructure IDA.

Fournir une piste d'audit. Une entreprise peut souhaiter surveiller les modifications et les

activités au sein de l'infrastructure IDA. Elle doit donc fournir un mécanisme permettant

de gérer les audits.

Les services de domaine Active Directory constituent le plus important composant d'une

infrastructure IDA, mais d'autres composants IDA sont aussi pris en charge par Windows Server

2008. Avec Windows Server 2008, Microsoft a regroupé un certain nombre de composants

auparavant distincts dans une plate-forme IDA intégrée.

• Services AD LDS (Active Directory Lightweight Directory Services)

• Services de certificats Active Directory (AD CS)

• Services AD RMS (Active Directory Rights Management Services)

• Services ADFS (Active Directory Federation Services)

Chacun de ces services joue un rôle dans l'extension d'IDA pour prendre en charge des configurations

et des scénarios plus complexes.

6.2.2. Arborescence Active Directory

Une arborescence Active Directory est composée de :

• La forêt : ensemble d’un ou plusieurs domaines Active Directory

• L'arbre : Représente le domaine et toutes ses ramifications. domaine.com,

sous1.domaine.com, sous2.domaine.com et projet.sous1.domaine.com forment un arbre

• Le domaine : constitue les feuilles de l'arborescence.

projet.sous1.domaine.com peut-être un domaine au même titre que domaine.com




40 40

Figure 6.2 : Arborescence Active Directory

Dans le cadre de ce travail, en partant du principe que l’on a qu’un seul domaine, on va donc avoir

une forêt composé d’un domaine qui sera le domaine racine.

6.3. Création d’une nouvelle forêt avec Windows Server 2008

Avant d'installer le rôle AD DS sur un serveur et promouvoir son action en contrôleur de

domaine, vous devez planifier votre infrastructure Active Directory. Les informations à rassembler

pour créer un contrôleur de domaine pour notre projet test sont les suivantes :

Nom de l’ordinateur SRVDC01

Nom DNS du domaine twmicronics.ads

Configuration IP pour le contrôleur de domaine

IP v4 : 192.168.11.1

Masque : 255.255.255.0

DNS : 192.168.11.1

Nous allons maintenant installer et configurer un contrôleur de domaine Windows Server 2008

« SRVDC01 ».

Cette étape s'effectue en exécutant l'Assistant Installation des services de domaine Active

Directory. Cet Assistant, également appelé DCPromo car il peut être lancé à l'aide de la commande

dcpromo.exe, vous guide à travers les étapes du processus de sélection de la configuration du

déploiement, en ajoutant des fonctions de contrôleur de domaine supplémentaires telles que le rôle

DNS (TWMicronics.ads), en définissant le niveau fonctionnel de la forêt (Windows Server 2008 R2),

en spécifiant l'emplacement des fichiers Active Directory (par défaut) et en configurant le Mot de




41 41

passe administrateur de restauration des services d'annuaire. Ce mot de passe est utilisé lors de la

restauration d'Active Directory à partir d'une sauvegarde.

Une fois l’installation d’Active Directory terminée, redémarrez le serveur.

Vous devez maintenant trouver en plus dans les « Outils d'administration », « DNS » et « Utilisateurs

et ordinateurs Active Directory ».

6.4. Gestion des utilisateurs et des ordinateurs

6.4.1. Unité d’organisation

Une unité d’organisation (OU, Organizational Unit) est un conteneur dans lequel on va pouvoir

mettre des utilisateurs, des groupes, des ordinateurs ainsi que d’autres OU.

On peut grâce aux OU représenter une certaine architecture pouvant ou non représenter la

structure de l’entreprise.

Des stratégies de groupes peuvent être affectées à une OU et on pourra déléguer

l’administration de celle-ci et son contenu à un administrateur par exemple.

On peut donc donner les autorisations à un utilisateur, de modifier les objets contenus dans une

OU par exemple. Avec la structure d’OU que l’on peut mettre en place, la délégation d’administration

est simplifiée et la gestion plus facile en séparant les différents privilèges accordées en fonction des

différentes OU.

Dans ce travail de recherche, nous allons créer une architecture de test à partir des OUs pour

simuler l’architecture d’une entreprise.

On va crée ensuite des groupes et des utilisateurs de test que l’on va répartir dans ces OUs en

fonction de leur rôle. Des stratégies de groupes vont être finalement appliquées aux OUs pour

fournir une infrastructure au sein de laquelle les paramètres peuvent être définis de façon

centralisée, puis déployés dans les ordinateurs et pour les utilisateurs de l'entreprise.

Pour créer une OU il suffit de faire un clic droit à l’endroit où l’on veut créer l’OU et de faire,

« Nouveau » puis de choisir « Unité d’Organisation » :




42 42

Figure 6.3 : Architecture Active Directory de l’entreprise

6.4.2. Compte d’utilisateurs

Un objet utilisateur, appelé généralement compte d'utilisateur, contient le nom et le mot de

passe de l'utilisateur qui servent d'informations d'identification d'ouverture de session. Un objet

utilisateur contient également d'autres attributs qui décrivent et gèrent l'utilisateur.

Nous allons créer des utilisateurs que nous allons répartir dans ces OU en fonction de leur rôle.

Des autorisations vont être finalement appliquées aux OU pour accorder ou non aux utilisateurs

présents dans ces OU des tâches d’administrations, comme par exemple la gestion des utilisateurs, la

gestion des ordinateurs de l’entreprise ou encore la gestion du serveur DNS (Domain Name System).

Certains utilisateurs peuvent donc avoir plusieurs rôles d’administration à gérer et l’on peut avoir des

utilisateurs avec plus ou moins de privilèges que d’autres.

Certaines pourront par exemple crée de nouveaux utilisateurs alors que d’autres ne pourront que

modifier les informations de comptes déjà existants.

Il existe beaucoup de scénarios possibles que l’on peut appliquer à une l’entreprise. Cela dépend par

exemple du niveau de sécurité que l’on veut pouvoir garantir, du nombre d’administrateurs délégués

que l’on veut avoir, du nombre de tâches d’administration à effectuer ou encore de la complexité de

l’architecture de l’entreprise.




43 43

Pour créer un objet utilisateur :

Cliquez avec le bouton droit de la souris sur l'UO ou le conteneur dans lequel vous voulez créer

l'utilisateur, pointez sur Nouveau et cliquez sur Utilisateur. Puis vous remplissez les champs par les

informations souhaitées comme illustrée dans la page suivante :

Figure 6.4 : informations d’un utilisateur

Chaque utilisateur devra pouvoir se connecter par le login suivant :

Première lettre du prénom, nom complet, par exemple Danny BATOMEN devra taper : DBatomen

Le mot de passe sera Miage12

Les utilisateurs ne pourront pas changer de mot de passe. La figure ci-dessous représente la liste des

utilisateurs de l’OU « Personnels » :




44 44

Figure 6.5 : Liste des utilisateurs de l’OU « Personnels »

6.4.3. Groupe Active Directory

Les groupes dans Active Directory servent à rassembler plusieurs objets comme des utilisateurs

ou des ordinateurs dans une même entité pour simplifier l’administration.

Lors de l’installation de l’annuaire AD, le système installe certains groupes et utilisateurs par

défaut avec des droits et des autorisations prédéfinis. Comme par exemple à l’installation de

Windows Seven où le système installe les comptes « administrator » et « guest » par défaut.

Il existe plusieurs sortes de groupes, on différentie ceux-ci avec une caractéristique appelée

« étendue de groupe » ou « Group Scope ». Celle-ci va permettre de restreindre l’accès à des objets

de la forêt.

On peut observer trois sortes de groupes :

Domain Local Groups

Généralement ce groupe est utilisé lorsque l’on veut appliquer des autorisations pour l’accès à

une application. On ne peut assigner des autorisations que sur les ressources se trouvant dans le

même domaine que là où le groupe a été crée.

On peut ajouter des utilisateurs de n’importe quel domaine au groupe « Domain Local Groups ».

Global Groups




45 45

On utilise souvent ce type de groupe pour rassembler des utilisateurs afin de simplifier

l’administration. Dans ce groupe, on ne peut ajouter que des utilisateurs faisant partis du même

domaine que le « Global Groups » créé.

Universal Groups

Ce type de groupe est généralement utilisé lorsque l’on veut partager des ressources entres

plusieurs domaines par exemple ou lorsque l’on veut regrouper plusieurs « Global Groups » entre

eux. On peut ajouter des utilisateurs de n’importe quel domaine à ce groupe.

Dans ce projet, l’utilisation de groupes universelle est inutile étant donné que l’on a qu’un seul

domaine.

6.4.4. Implémentation de la gestion a base des rôles en utilisant des groupes

Pour améliorer la gestion des accès aux ressources de notre organisation, nous avons décidé

d'implémenter la gestion à base de rôles. La gestion à base de rôle est un concept utilisé en

informatique et dans la protection des informations et elle est accessible avec les fonctions standards

d'Active Directory. IGDLA est l'implémentation de la gestion à base de rôles en utilisant des groupes

Active Directory.

La première opération consistera à déterminer les personnes autorisées à accéder aux

informations des ventes. Nous devons créer des groupes afin de gérer l'accès à ces informations

confidentielles. Selon les règles de l'entreprise par exemple, les employés du département Ventes et

Marketing et de l'équipe des Finances sont autorisés à consulter les dossiers des ventes. De plus,

l’utilisateur Guy WASSEU nécessite un accès en lecture.

Nous allons implémenter la gestion à base de rôles en utilisant des groupes et la meilleure

pratique de stratégie d'imbrication de groupes, IGDLA. Nous allons créer différents étendues et types

en utilisant le composant logiciel enfichable Utilisateurs et ordinateurs.

1) Créer des groupes de rôles avec Utilisateurs et ordinateurs Active Directory

• Créez les groupes de sécurité globaux, par exemple Sales dans l'UO Groupes\Roles.




46 46

Figure 6.6 : Les groupes de rôles

• Puis ajouter des utilisateurs au groupe de rôles.

Figure 6.7 : Utilisateurs membres d’un groupe

2) Créer des groupes de gestion des accès aux ressources.

• Créez par exemple le groupe de sécurité local de domaine ACL_Sales Folders_Read dans l'UO

Groups\Access.

• Affecter des autorisations au groupe de gestion des accès aux ressources

• Dans D:\Data, créez le dossier Sales.

• Cliquez avec le bouton droit de la souris sur le dossier Sales, puis cliquez sur Propriétés et sur

l'onglet Sécurité.




47 47

Figure 6.8 : les propriétés d’un dossier partagé

• Cliquez sur Modifier et sur Ajouter.

• Tapez ACL_ et appuyez sur ENTRÉE.

Notez que lorsque vous utilisez un préfixe pour les noms de groupe, tel que ACL_ pour les groupes

d'accès aux ressources, vous pouvez les retrouver rapidement.

• Cliquez sur ACL_Sales Folders_Read et sur OK.

• Vérifiez que le groupe a bien reçu l'autorisation de lecture et d'exécution.

Figure 6.9: Les autorisations

• Cliquez sur OK pour fermer la boîte de dialogue ouverte.




48 48

Figure 6.10 : Les groupes de règles

Déterminer les rôles et les utilisateurs qui peuvent accéder à une ressource.

• Ajoutez Sales, Finances, et Guy WASSEU au groupe ACL_Sales Folders_Read.

6.4.5. Mises des machines clientes dans le domaine

Avec votre client XP ou Seven, intégrez le domaine TWMicronics.ads (clic droit > propriétés sur le

poste de travail, onglet nom de l'ordinateur).

Indiquez un nom d'utilisateur du groupe Admins du domaine pour vous connecter.

La copie d’écran suivante illustre les postes client mis dans le domaine de l’OU « PC Privés »:

Figure 6.11 : Postes de l’OU « Privés »

6.5. Amélioration de la sécurité et piste d’audit

La sécurité est au centre des préoccupations de la plupart des entreprises d'aujourd'hui.

Alors que les organisations œuvrent à la suppression des privilèges administratifs superflus qui ont

été attribués par le passé aux utilisateurs, elles s'efforcent également de verrouiller et de gérer les

privilèges accordés aux administrateurs eux-mêmes. Pour gérer la sécurité de l’administration




49 49

d’Active Directory, il est indispensable de comprendre comment certaines tâches d’administration

sont déléguées et comment l’audit des activités liées à l’authentification est effectué.

6.5.1. Délégation des autorisations administratives

Pour augmenter la sécurité au maximum dans l’annuaire Active Directory, il est recommandé

d’utiliser le principe du moindre privilège. Un utilisateur à qui on confie une tâche d’administration,

doit seulement pourvoir exécuter les tâches associées à son rôle.

On crée donc un compte spécifiquement pour chaque tâche d’administration à qui on attribue

un certains nombres d’autorisations en fonction du rôle du compte. Aucune autre action ne doit

pouvoir être effectuée à partir de ce compte. De cette façon le principe du moindre privilège est

respecté.

Si un utilisateur est chargé de la gestion des comptes par exemple, il ne doit pas pouvoir

intervenir sur la configuration DNS du serveur ou pouvoir supprimer des ordinateurs de l’annuaire.

6.5.1.1. Approche de la délégation

Les politiques de sécurité étant généralement différentes au sein des divisions et les équipes IT

mêmes, il convient de trouver une solution afin de déléguer les tâches nécessaires au travail de

chacun sans pour autant compromettre la sécurité de tout le domaine Active Directory.

La structure d’un domaine Active Directory est organisée par défaut de façon hiérarchique. Il est en

effet possible de déléguer des tâches au niveau d’une forêt, d’un site, d’un domaine ou bien même

d’une unité d’organisation. De plus, chaque objet possédant des attributs avec des DACL

(Discretionary Access ControlList) associées à ces derniers, il est également possible de déléguer des

options de façon assez fine (réinitialiser le mot d’un utilisateur, autoriser la désactivation d’un

compte utilisateur, etc.). Nous passerons à la pratique un peu plus loin.

Avant de vous lancez dans la configuration de la délégation de votre Active Directory, il convient de

bien étudier les besoins auxquels vous devez répondre.

6.5.1.2. Délégation des comptes utilisateurs.

Passons maintenant à la pratique en déléguant deux actions particulièrement utiles à la hotline

et au support informatique d’une entreprise. Ces services n’ayant pas pour vocation d’effectuer des

tâches administratives lourdes sur l’Active Directory, il serait démesuré d’ajouter ces derniers au

groupe « Administrateurs du domaine » par exemple.

Parmi les besoins les plus demandés par ces services afin de répondre aux demandes utilisateurs,

vous trouverez notamment le droit de joindre un poste à un domaine Active Directory et le droit de

réinitialiser les mots de passe des utilisateurs.

Les délégations s’effectuent généralement sur tout ou partie des objets d’une unité d’organisation

ou d’un domaine. Cela a pour but de simplifier l’administration et la gestion des droits de votre

Active Directory. Inutile de vous rappelez qu’il est d’ailleurs impératif de garder une trace des

délégations effectuées afin de faciliter l’administration quotidienne et les opérations de dépannage

en cas de problème.




50 50

Prenons comme besoin celui du service de support technique qui souhaite pouvoir déverrouiller les

comptes d’utilisateurs, réinitialiser les mots de passe et imposer aux utilisateurs de changer de mot

de passe à la prochaine ouverture de session.

Cette autorisation se limitera aux comptes d'utilisateur standard et ne permettra pas au support

technique de modifier les mots de passe de comptes administratifs. Vous allez également déléguer

au groupe Administrateurs de comptes d’utilisateurs l’autorisation de créer et supprimer des

comptes d’utilisateurs, ainsi qu’un contrôle total sur les comptes d’utilisateurs. Tous les membres du

groupe utilisateurs font partie du même OU nommé utilisateurs.

Afin de déléguer ces droits, Microsoft met à disposition un assistant délégation. Pour cela, placez-

vous au niveau de l’objet ou du conteneur parent depuis lequel vous souhaitez effectuer une

délégation de droits. Dans la plupart des cas, cette délégation s’effectue au niveau d’une unité

d’organisation.

• Faites alors un clic avec le bouton droit de la souris sur l’objet et choisissez Délégation de

contrôle.

Figure 6.12: délégation de contrôle

• Cliquez sur Suivant dans l’écran de bienvenue. L’assistant vous demande alors de

sélectionner les utilisateurs ou groupes pour lesquels les droits délégués seront attribués.

• Cliquez sur Ajouter puis tapez le nom de votre groupe et Vérifier les noms puis OK.




51 51

Figure 6.13: Ajout d’un compte

• Une fois le ou les groupe(s) ajouté(s), cliquez sur Suivant.

Vous pouvez maintenant choisir le niveau de permissions qui sera appliqué à l’objet délégué.

Vous avez le choix entre choisir des délégations prédéfinies pour des tâches courantes ou bien de

définir une tâche personnalisée à déléguer.

Dans notre exemple, nous pourrions choisir les tâches prédéfinies mais celles-ci permettraient

trop de droits comparés à ce que nous souhaitons autorisés.

• Choisissez donc de Créer une tâche personnalisée à déléguer afin de pouvoir effectuer

une délégation très granulaire puis cliquez sur Suivant.

• Choisissez de déléguer le contrôle Seulement des objets suivants dans le dossier et

cochez ObjetsUtilisateur puis Suivant.

• Sélectionnez alors le ou les types d’autorisations que vous souhaitez déléguer aux

utilisateurs.

Dans notre exemple l’attribut Modifier le mot de passe(ou Change Password en anglais) est

utilisé pour la réinitialisation du mot de passe et les attributs Lire lockout Time(ou Read lockout

Time) et Ecrire Lockout Time(ou Write lockout Time) sont utilisés pour déverrouiller un compte

utilisateur. Les deux derniers attributs ne sont visibles qu’en cochant la cases spécifiques aux

propriétés car comme son nom l’indique, ils sont spécifiques à l’objet Utilisateur.




52 52

Figure 6.14 : les autorisations a délégué

• Une fois les trois cases cochées, cliquez sur Suivant.

Une fenêtre récapitulative indique les différents choix effectués au cours de l’assistant

délégation.

• Sur la page de Fin de l’Assistant Délégation de contrôle, cliquez sur Terminer., les ACL

(liste de contrôle d’accès) seront modifiés sur l’OU Utilisateur.

6.5.2. Configuration des paramètres de mot de passe et de

verrouillage

Afin d’améliorer la sécurité et de contrôler l’authentification pour le domaine AD DS de

l’entreprise. Nous devons appliquer une stratégie de mot de passe précise pour tous les comptes

d'utilisateur, ainsi qu'une stratégie de mot de passe plus stricte pour des comptes administratifs

sensibles sur le plan de la sécurité.

6.5.2.1. Configuration des stratégies de comptes du domaine

Active Directory prend en charge un seul ensemble de stratégies de mot de passe et de

verrouillage par domaine. Ces stratégies sont configurées dans un objet GPO étendu au domaine. Un

nouveau domaine contient un objet GPO appelé Stratégie de domaine par défaut. Celui-ci est lié au

domaine et il contient les paramètres par défaut des stratégies de mot de passe, de verrouillage de

compte et Kerberos.

Les stratégies de mot de passe et de verrouillage se composent des éléments suivants :




53 53

Tout au long de ce travail, nous allons modifier ces paramètres en modifiant la stratégie de domaine

par défaut.

• Exécutez le composant logiciel enfichable Gestion des stratégies de groupe

• Modifiez l’objet GPO Stratégie de domaine par défaut.

• Configurez les paramètres de stratégie de mot de passe ci-dessous. Conservez-les valeurs par

défaut des autres paramètres.

- Durée de vie maximale du mot de passe : 90 jours

- Longueur minimale du mot de passe : 10 caractères

Figure 6.15 : Les paramètres de stratégies de mot de passe

• Configurez le paramètre de stratégie de verrouillage de compte ci-dessous.

- Conservez les valeurs par défaut des autres paramètres.

- Seuil de verrouillage de compte : 5 tentatives d’ouverture de session non valides.

Stratégies Paramètre par défaut

Stratégie de mot de passe

Conserver l’historique des mots de passe 24 mots de passe

Durée de vie maximale du mot de passe 42 jours

Durée de vie minimale du mot de passe 1 jour

Enregistrer les mots de passe en utilisant un chiffrement réversible

Désactivé

Le mot de passe doit respecter des exigences de complexité

Activé

Longueur minimale du mot de passe 7 caractères

Stratégie de verrouillage du compte

Durée de verrouillage des comptes Non défini

Réinitialiser le compteur de verrouillages Non défini

Seuil de verrouillage du compte 0 tentatives d’ouverture de session non valide




54 54

Figure 6.16 : Les paramètres de stratégie de verrouillage du compte

• Fermez l’Éditeur de gestion des stratégies de groupe et la Gestion des stratégies de groupe.

6.5.2.2. Stratégie de mot de passe affinée On pouvait remplacer la stratégie de mot de passe et de verrouillage du domaine par le biais d’une

nouvelle fonctionnalité de Windows Server 2008 appelée stratégie de mot de passe et de

verrouillage affinée, souvent abrégée sous la forme stratégie de mot de passe affinée. La stratégie de

mot de passe affinée permet de configurer une stratégie qui s’applique à un ou plusieurs groupes ou

utilisateurs du domaine comme illustrée sur la diapositive suivante :

Figure 6.17 : Les stratégies affinées

6.5.3. Audit de l’authentification de connexion

Une stratégie d’audit définit les types d’événements de sécurité que Windows Server 2008

enregistre dans le journal de sécurité sur chaque ordinateur. Windows Server 2008 consigne les

événements dans le journal de sécurité de l’ordinateur lorsque l’événement se produit.

La configuration d’une stratégie d’audit pour un ordinateur permet de :




55 55

suivre l’aboutissement ou l’échec d’événements tels que les ouvertures de session, la lecture

d’un fichier donné par un certain utilisateur, ainsi que les modifications apportées à un

compte d’utilisateur ou une appartenance de groupe et aux paramètres de sécurité ;

réduire les risques d’utilisation non autorisée des ressources ;

conserver un enregistrement des activités des utilisateurs et administrateurs.

Utilisez l’Observateur d’événements pour voir les événements que Windows Server 2008

enregistre dans le journal de sécurité.

Dans ce travail, nous allons utiliser la Stratégie de groupe pour activer l’audit des connexions

réussies et celles ayant échoué, qui ont été initiées par les utilisateurs du domaine twmicronics.ads.

Nous génèrerons ensuite des événements de connexion et examinerons les entrées résultantes dans

les journaux d’événements.

1. Configurer l’audit des événements de connexion aux comptes

• Exécutez la Gestion des stratégies de groupe

• Modifiez l’objet de stratégie de groupe de la stratégie par défaut des contrôleurs de domaine

pour activer l’audit des événements de connexion aux comptes qui ont réussi et ceux qui ont

échoué.

Figure 6.18 : paramètres d’audit

• Fermez l’Éditeur de gestion des stratégies de groupe.




56 56

2. Configurer l’audit des événements de connexion

• Créez un objet de stratégie de groupe (GPO) lié à l’UO Servers\Important Project. Nommez

l’objet GPO Server Lockdown Policy.

• Modifiez la stratégie Server Lockdown Policy pour activer l’audit des événements de

connexion aux comptes qui ont réussi et ceux qui ont échoué.

• Fermez l’Éditeur de gestion des stratégies de groupe et la Gestion des stratégies de groupe.

3. Forcer une actualisation de la Stratégie de groupe

Le client de stratégie de groupe du poste récupère la configuration (par défaut au bout de 90 à

120 minutes) qui est applicable à l’ordinateur et/ou à l’utilisateur connecté.

Pour forcer l'application des GPO, vous pouvez utiliser la commande : gpupdate /force

4. Examiner les événements de connexion

• Exécutez l'Observateur d'événements pour identifier les événements ayant échoué et les

événements réussis dans le journal Sécurité.

Figure 6.19 : observateur d’événements

6.6. Configuration du service DNS

DNS (Domain Name System) est un service de noms qui fait la correspondance (le mappage)

entre les noms d’ordinateurs (nom d’hôte) et les adresses IP. C’est une base de données

distribuée hiérarchisée.

• Exécutez la console Gestionnaire DNS « Démarrer », « Outils d’administration », « DNS »

• Développez le noeud sur « Zone de recherche directe (nom du serveur : ici SRVDC01) », vous

remarquez que dans le volet d’informations (la partie droite de la console), on trouve des

dossiers (encadrés en rouge sur la copie d'écran) qui sont indispensables au bon




57 57

fonctionnement du serveur et des stations XP, Vista et Seven ainsi qu'aux éventuels autres

serveurs du réseau.

Figure 6.20 : La zone de recherche directe du domaine

• Créer une « Zone de recherche inversée » en faisant clic droit sur « Zone de recherche

inversée (nom du serveur : ici SRVDC01), « Nouvelle zone » »

• « Zone principale », Rentrez le « ID réseau »

Figure 6.21: Assistant de création de la zone de recherche inversée

• « Suivant », « Suivant » et « Terminer ».

• Créez un pointeur correspondant au serveur dans la zone de recherche inversée.

• Redémarrez le serveur DNS.

• Puis vérification du DNS avec la commande « nslookup ».

La commande « nslookup » est intégrée au système d'exploitation.




58 58

« nslookup » permet de tester la résolution des noms d'hôtes en adresses IP et inversement. On

utilise « nslookup » pour vérifier le bon fonctionnement du serveur DNS.

Lorsque l'on tape nslookup en mode texte, une invite de commande apparaît. Le nom d'hôte et

l'adresse IP du serveur DNS par défaut sont affichés.




59 59

CONCLUSION GENERALE

Le sujet consacré a notre étude portant sur « les systèmes de gestion d’identités et

droits d’accès : mise en œuvre et apport pour la sécurité d’une organisation » a été

l’occasion pour nous de comprendre et d’expérimenter les concepts liés au domaine de la

sécurité informatique.

Un tel système dans une organisation est une solution centralisé adapté pour la gestion

de ces acteurs (partenaires, clients, employés…) et le contrôle d’accès aux ressources

(matérielles ou logicielles).Sa mise en place est certes couteuses, mais le retour sur

investissement est très visible car facilite largement l’administration des acteurs, et accroît

fortement la productivité au sein d’une organisation.

De nombreuses entreprises dans le monde sont conscients de l’apport d’un système de

gestion d’identités et d’accès, c’est pourquoi plusieurs solutions existe sur le marché afin de

satisfaire les demandeurs car chacun ayant des besoins spécifiques. Par conséquent le

domaine de la sécurité informatique est constamment en évolution pour intégrer les

nouvelles technologies.

Conclusion Générale




xv xv

BIBLIOGRAPHIE

Livres, Documents [Abi Haidar et al. 2006] Abi Haidar D., Cuppens-Boulahia N., Cuppens F. et DebarH.,"An extended

RBAC profile of XACML", CCS, USA, November 2006.

[Abou El Kalam et al. 2003] Abou El Kalam A., Baida R., Balbiani P., Benferhat S., Cuppens

[Federation 2007] "The business value of identity federation", a Computer Associates white

*Clusif 2007+ Fédération d’identité, "Gestion des Identités", dossier technique, groupe

"Gestion des identités", juillet 2007.

[Kamel et al. 2006] Kamel M., Benzekri A., Barrère F., Nasser B., "Information Security

[Kerberos 1996] Kerberos, http://www.ietf.org/rfc/rfc1964.txt, 1996

[Kerberos 2005] Kerberos, http://www.ietf.org/rfc/rfc4120.txt, 2005

[Saillard 2003] Saillard C., "802.1X : Solution d'authentification sécurisée pour le futur réseau sans fil

de l'Université Louis Pasteur", Centre Réseau Communication, Université Louis Pasteur, Strasbourg,

2003.

*Scott et al. 1999+ Scott C., Wolfe P., Erwin M., "Virtual Private Networks", O’REILLY, 211 p., ISBN 1-

56592-529-7, 1999.

Webographie

[AAA 2000a] AAA Authorization Framework,

http://www.ietf.org/rfc/rfc2904.txt?number=2904, 2000

[AAA 2000b] AAA Authorization Requirements,

http://www.ietf.org/rfc/rfc2906.txt?number=2906, 2000

[Windows Live] Windows Live ID, http://msdn2.microsoft.com/fr-fr/library/aa479889.aspx

Bibliographie

LES SYSTEMES DE GESTION DES IDENTITES ET DES ACCES : MISE EN ŒUVRE ET APPORT POUR LA SECURITE...

Technology

Transcript of LES SYSTEMES DE GESTION DES IDENTITES ET DES ACCES : MISE EN ŒUVRE ET APPORT POUR LA SECURITE...