Etude et implémentation d’un IAM (Identity and Access Manager)

Etude et implémentation d’un IAM (Identity and Access Manager)

Conception et modélisation 

Les concepts 

Ce chapitre introduit les concepts et les objets manipulés, avant de décrire les mécanismes de gestion des identités et des habilitations. 

Personne (utilisateur / acteur) 

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. Des attributs supplémentaires fournissent les informations concernant la personne. Ces attributs sont :  un nom ;  un prénom ;  une durée de validité ;  un état (actif, suspendu) ;  les périmètres d’accès autorisés ;  un niveau de confidentialité (par domaine d’activité) ;  etc… Tout acteur du système est déclaré d’une manière unique dans un référentiel central de sécurité et de gestion des habilitations en tant que personne physique et peut disposer de comptes dans différents environnements et applications en fonction des habilitations accordées. La cohérence de ces informations est maintenue automatiquement par le système de gestion des habilitations. D’une manière générale, les autorisations ne sont pas attribuées directement aux personnes mais à travers des profils/rôles. Certaines autorisations particulières peuvent être associées à la personne physique. Elles sont limitées aux autorisations d’accès global au système d’Information d’entreprise comme limitation temporelle ou géographique d’ouverture de session ou suspension générale d’accès. 

Compte 

A chaque personne peuvent être associés des comptes d’accès aux systèmes et applications. Le compte est défini par l’identifiant d’accès, un mot de passe (ou un identifiant d’une autre nature), et plusieurs attributs supplémentaires en fonction de l’environnement dans lequel il est créé 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 :  le compte global. Ce compte, unique (à un utilisateur correspond un seul compte) identifie une personne dans le référentiel central de gestion des habilitations et est utilisé par tous les processus d’attribution de droits.  le compte utilisateur. Ce compte donne l’accès à un utilisateur dans un environnement particulier auquel cet utilisateur est habilité. Chaque compte utilisateur est obligatoirement associé à une personne (et son identifiant unique).  le compte d’administration. Ce compte donne accès à un administrateur dans un environnement particulier. Ce compte n’est pas associé à une personne. Il correspond donc à aucune entrée dans le référentiel central. Leur usage doit être limité aux actes d’administration techniques des environnements et des applications dans les environnements où ces tâches ne peuvent pas être effectuées via les rôles. Exemple : compte ROOT d’Unix. Les procédures mises en œuvre doivent garantir la traçabilité et l’auditabilité des personnes physiques auxquelles ces comptes administrateurs ont été autorisés d’emploi. Un changement d’affectation doit être associé à une procédure de changement de mot de passe.  le compte « de service fonctionnel et technique ».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. La connexion au système cible, utilisant ce compte doit être authentifié et seulement identifié si la liaison se fait intégralement dans une zone sécurisée. Le compte est donc associé au système ou application cliente et non à une personne. Aucune personne n’est autorisée à l’utiliser. Un compte (unique dans un environnement) est associé à une te une seule personne à l’instant T (à l’exception des comptes d’administration et techniques). A un compte peuvent être associés (en fonction de la capacité de gestion de l’environnement) :  une durée de validité,  un état (actif, suspendu) ;  etc. 

Rôle

 Un rôle définit les permissions nécessaires à l’utilisation des objets (applications, et/ou ressources). Le rôle applicatif est un ensemble de droits propres à une seule fonction dans une application. Par exemple : le droit d’usage d’un jeu d’écrans et de menus correspond à une fonction dans l’application. 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. L’habilitation est affectée à la personne via l’attribution des rôles applicatifs :  un rôle applicatif appartient à une seule application.  L’application admet plusieurs rôles.  Un rôle ne peut pas être affecté directement à l’utilisateur mais uniquement par l’intermédiaire d’un profil métier.  Sont associés au concept de rôle : o Des modes d’authentification autorisés ; o Les périmètres d’accès autorisés ; o La cardinalité (nombre d’occupants maximum autorisés) ; o La séparation statique des pouvoirs (rôles interdits de cohabitation). 

Profil

 Pour faciliter la gestion des habilitations, il est courant de lier l’attribution d’un ensemble d’habilitation à l’obtention d’un profil « fonctionnel ». Un profil fonctionnel regroupe un ensemble de rôles nécessaires à l’exécution d’une fonction métier. Un utilisateur peut avoir un ou plusieurs profils fonctionnels. Le profil d’habilitation, auquel sont rattachés, via les rôles, les droits d’accès aux applications, est déterminé par le poste opérationnel (Cf. poste opérationnel 4.1.5). A chaque poste est associé un ou plusieurs profils d’habilitation. 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 ainsi correspondre à un ensemble d’habilitations spécifiques. 

Le 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. 

Groupe 

Les utilisateurs peuvent être regroupés, dans le référentiel central, en groupes statique sou dynamiques. Ces groupes sont utilisés pour faciliter la gestion en masse des habilitations. 

 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 avoir trois types différents (temporel, géographique et fonctionnel) et être associé à :  une personne  un compte (uniquement dans le cas de limitation des autorisations d’accès à des ressources d’un environnement)  un rôle.  Il ne peut pas être associé à un profil. 

Périmètre temporel 

Le périmètre temporel permet de restreindre les possibilités d’accès d’un utilisateur dans le temps. Plusieurs types de restrictions sont possibles :  période : o définis par : ; o L’accès n’est autorisé que si la date du jour se situe entre les deux dates spécifiées ;  plage horaire : o Définis par : ; o L’accès n’est autorisé, chaque jour, que si l’heure (locale du système d’autorisation) se situe entre les deux heures spécifiées ;  calendrier : o définis par : ; o L’accès n’est autorisé que si le jour de la semaine (local du système d’autorisation) correspond à une des entrées de la liste :  (ex : 26/01, 30/06, etc.) ;  (ex : S2, S3, etc.) ;  (ex : janvier, février, etc.). Ces limitations sont appliquées par les différents systèmes d’autorisation en fonction de la capacité du système à gérer ce type de restriction. Le périmètre temporel peut être associé à :  une personne ;  un rôle ;  une ressource. Un périmètre temporel associé à une personne limite son accès à l’ensemble des ressources et applications en empêchant l’utilisateur d’établir une session en dehors de périodes autorisées. Un périmètre temporel associé à un rôle limite l’accès à l’application ou à un ensemble de ressources :  dans le cas d’une application, il empêche l’utilisateur d’exécuter l’application (contrôlé par l’application lui-même) en dehors des périodes autorisées. Le profil de l’utilisateur présentera donc un ensemble des applications disponibles variable dans le temps ;  dans le cas d’une ressource, il empêche l’utilisateur d’établir une session, dans l’environnement qui héberge les ressources concernées, en dehors des périodes autorisées. De fait, la limitation temporelle s’applique donc à un compte d’utilisateur dans ces environnements. Cette association doit être gérée par le système de gestion des habilitations (en fonction des limitations des personnes et des rôles) et transmise aux différents systèmes de contrôle d’accès pour application.

Table des matières

INTRODUCTION GENERALE
CHAPITRE 1 : Approche Théorique
1.1. Présentation du cadre de l’étude
1.1.1. Présentation de la Direction Générale des Douanes (DGD)
1.1.2. Mission fiscale et économique
1.1.3. Organigramme de la DGD
1.1.4. Présentation de la Direction des Systèmes Informatiques Douaniers (DSID)
1.2. Présentation du sujet
1.2.1. Contexte
1.2.2. Problématique
1.2.3. Objectifs
1.2.3.1. l’objectif principal
1.2.3.2. objectifs spécifiques
CHAPITRE 2 : Etude détaillée de l’implémentation de l’IAM
2.1. Conception et modélisation
2.1.1. Les concepts
2.1.1.1. Personne (utilisateur / acteur)
2.1.1.2. Compte
2.1.1.3. Rôle
2.1.1.4. Profil
2.1.1.5. Le poste opérationnel
2.1.1.6. Groupe
2.1.1.7. Périmètre
2.1.1.8. Périmètre temporel
2.1.1.9. Périmètre géographique
2.1.1.10. Périmètre fonctionnel
2.1.1.11. Mode d’authentification
2.1.1.12. Ressource
2.1.1.13. Environnement du SI
2.1.2. Modèle RBAC
2.1.2.1. Modèle de base RBAC
2.1.2.2. Limitations de la modélisation RBAC
2.1.2.3. Description du modèle RBAC étendu
2.2. Démarche
2.2.1. Populations cibles
2.2.1.1. Données autoritaires (principe général)
2.2.1.2. Sources de données
2.2.1.3. Mobilité entre les populations
2.2.1.4. Fournisseur de SSO
2.2.1.5. Identifiant unique
2.2.1.5.1. Convention de nommage
2.2.1.5.1.1. Identifiant unique IAM
2.2.1.5.1.2. SamAccountName
2.2.1.5.1.3. UPN
2.2.1.5.1.4. CN Active Directory
2.2.1.5.1.5. Adresse de messagerie
2.2.1.6. Mode d’attribution des droits
2.2.1.6.1. Manuelle
2.2.1.6.2. Automatique
2.2.1.6.3. Attribution des droits dans le contexte des Douanes Sénégalaises
2.2.1.7. Tableau de synthèse des populations
2.2.2. Cycle de vie des identités
2.2.2.1. Import initial
2.2.2.2. Collaborateurs des Douanes Sénégalaises
2.2.2.2.1. Gestion des arrivées
2.2.2.2.1.1. Arrivée planifiée
2.2.2.2.1.2. Arrivée urgente
2.2.2.2.2. Gestion des modifications (attributsd’identités)
2.2.2.2.3. Mobilité
2.2.2.2.4. Gestion des absences
2.2.2.2.5. Demande de droits (hors règle métier)
2.2.2.2.6. Gestion des départs
2.2.2.2.6.1. Opérations manuelles
2.2.2.2.6.2. Opérations planifiées
2.2.2.3. Externes
2.2.2.3.1. Gestion des arrivées
2.2.2.3.2. Gestion des modifications
2.2.2.3.3. Demande de droits (hors règle métier)
2.2.2.3.4. Gestion des absences
2.2.2.3.5. Mobilité .
2.2.2.3.6. Gestion des départs
2.2.2.3.6.1. Opérations manuelles
2.2.2.3.6.2. Opérations planifiées
2.2.3. Acteurs et processus
2.2.3.1. Les acteurs
2.2.3.2. Les processus
2.2.4. Applications
2.2.4.1. Applications provisionnées en automatiques
2.2.4.2. Applications provisionnées par Workflow Driven
2.3. Contraintes et exigences
2.3.1. Alimentation amont
2.3.2. Alimentation aval
2.3.3. Gestion des référentiels
2.3.4. Flexibilité
2.3.5. Interface IHM personnalisée
2.3.6. Conduite du changement
2.3.7. Besoin d’une procédure pour l’intégration d’applications futures
CHAPITRE 3 : Déploiement de l’IAM (Identity and Access Manager)
3.1. Architecture
3.1.1. Principes de l’architecture d’Identity & Access Manager
3.1.1.1. Principes généraux
3.1.1.2. Différentes fonctions basiques des BD utilisateurs
3.1.2. Architecture d’Identity & Access Manager
3.2. Fonctionnalités
3.2.1. La gestion des identités
3.2.2. La gestion des droits d’accès aux applications
3.2.3. Le provisioning des comptes utilisateurs et la réconciliation
3.2.4. Le service d’autorisation
3.2.5. La gestion de l’audit
3.3. Implémentation
3.3.1. Mise en place de l’infrastructure
3.3.2. Installation d’I&AM
3.3.2.1. Installation de Policy Manager
3.3.2.2. Installation des services de réconciliation et de provisioning
3.3.2.3. Installation des services d’audit
3.3.2.4. Installation de Request Manager
3.3.2.5. Installation de ID Synchronisation
3.3.3. Interfaces
3.3.3.1. Policy Manager
3.3.3.2. Request Manager
3.3.3.3. ID Synchronisation
INTRODUCTION
Références webographiques
Références bibliographiques

 

projet fin d'etudeTélécharger le document complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *