Exploration des fonctionnalités avancées des solutions IGA

Aujourd'hui je vous propose un aperçu des fonctionnalités principales des solutions de gestion et administration des identités (Identity Governance and Administration - IGA).

Je suis consultante en cybersécurité depuis 4 ans : j’ai travaillé deux ans dans le domaine de l’intégration de solutions d’IGA (plus particulièrement la solution IdentityIQ, de SailPoint) et je travaille depuis deux ans au développement d’une solution de rapports et de tableaux de bords pour les outils d’IAM.

Un aperçu des fonctionnalités des solutions d’IGA

L’applicationautoritaire

Pourcela,uneapplicationautoritaireestdéfinie.

Une application est dite autoritaire si elle permet la création des identités. Chaque compte lu sur cette application estuneidentitéduSI.Lapremièrelecturedecetteapplicationcréelesidentitésdusystème.Parlasuite,siun nouveau compte apparaît à la lecture, il déclenchera la création d’une nouvelle identité.

L’application autoritaire est en général l’application des ressources humaines (RH). Il peut y avoir plusieurs applications autoritaires : par exemple si il existe une application RH pour les externes et une autre pour les in- ternes.

La solution d’IGA peut être définie comme la source autoritaire. Cela revient à initialiser la solution en créant les identités au moyen d’une autre application définie autoritaire uniquement à l’initialisation. Puis par la suite, rendre la solution autoritaire en n’autorisant les créations de nouvelles identités que via la solution elle-même (au moyendeformulairesengénéral).

Lecubeidentité

L’application autoritaire permet la création des identités. Chaque identité est symbolisée par son cube. Dans le cube, on retrouve toutes les informations connues sur cette identité. Les premières informations sont donc celles présentesdansl’applicationautoritaire.

Parexemple:onytrouvesouventlenom,leprénom,lemail,lemétier, l’unité organisationnelle, les informations personnelles comme le téléphone professionnel et le bureau etc.

Viennent s’ajouter à cela toutes les informations lues sur les autres applications ainsi que les comptes, les habili- tations et les rôles possédés. Certaines informations ne sont pas lues mais calculées à partir d’informations lues.

Ex: le manager peut être calculéàpartirdel’unitéorganisationnelle,lestatutactif/inactifdansl’entreprisepeutêtrecalculéàpartirdesdatesdedébut et de fin contrat de l’identité.

Certaines informations peuvent être paramétrées pour être modifiables dans l’interface de la solution. Cela permet la correction ou l’ajout d’informations. Ces actions peuvent être paramétrées pour demander une appro- bationetlasolutionpeutengarderunetrace.

Une fois le cube identité complet, ces informations peuvent être écrites sur les applications non autoritaires. Cela permet une synchronisation automatique des informations concernant l’identité entre la solution d’IGA et les ap- plications du SI.

Un cube identité de l’outil IdentityIQ de SailPoint est un bon exemple : on y retrouve bien les informations de l’identité (peu nombreuses dans cet exemple) et on peut voir que des onglets sont disponibles pour visualiser les habilitations (Entitlements), les comptes applicatifs (Application Accounts), les évènements du cycle de vie de cette identité (Events) etc.

UncubeidentitédansIdentityIQissudehttps://allidm.com/sailpoint-identityiq-create-identity/

La gestion du cycle de vie de l’identité

Une identité d’un SI passe par de nombreuses étapes tout au long de son existence dans le SI. Ces étapes sont significatives et les traquer permet de limiter les anomalies telles que des habilitations non adaptées à la situation del’identitéoudesinformationserronées.

La mise en place de processus associés à chaque étape permet une gestion automatique et fluide du cycle de vie de l’identité.

Lesévènementsdéclencheurs

Exemple de cycle de vie d'une identité

Les évènements du cycle de vie de l’identité sont nombreux. Chacun de ces évènements demande une prise en charge des informations et des habilitations de l’identité. Les évènements du cycle de vie de l’identité sont propres à chaque SI, chaque environnement et chaque client.

Pour chaque évènement, on définit une liste de facteurs permettant de savoir qu’une identité vit l’évènementenquestion.

Ex:uneidentitépeutvivresonarrivéedansleSIquandelleestcrééedanslasolution:soitvialalecture de l’application autoritaire, soit via une création dans la solution. Mais dans un autre SI, une identité peut vivre son arrivée quand sa date de début de contrat arrive : elle peut donc être créée dans la solution avant son arrivée effective.

Lesfacteurs àlister peuventêtre deschangements d’informationsou desdates.

Ex: lemanager change,l’unité organisationnelle change alors on détecte une mutation, la date de fin de contrat déclenche le départ de l’identité, la date de fin d’un projet déclenche le retrait des droits et rôles associés. Il peut y avoir plusieurs facteurs pour un même évènement.

La définition précise des évènements et de leurs déclencheurs est une étape importante nécessitant de la partde l’entreprise cliente une grande connaissance des processus déjà existants et beaucoup de réflexion : les effets de bords d’une mauvaise définition peuvent être importants.

Les processusassociésaux évènements

La détection d’un évènement déclenche un processus associé. Les processus sont des suites d’étapes permet- tant de mettre en conformité l’identité avec les politiques du SI relatives à l’évènement en question.

LadéfinitiondecesprocessussefaitenfonctiondespolitiquesduSIetdesprocessusdéjàenplacedansl’entreprise. C’est un endroit où la conduite du changement peut être nécessaire si les processus déjà existants ne sont passatisfaisantsentermes de sécuritéoud’efficacité,ous’ilssontinexistants.C’estégalementunendroitoùle conseil et l’apport de bonnes pratiques est crucial : la création ou la modification des processus peut représenter un challenge pour le client.

Lesétapes génériquesde cesprocessus sontla modificationet lecalcul d’informations,le retraitet l’ajoutde droitsd’accèsetderôles,l’envoidenotifications,lagénérationderapportsetc.

Ex :pour une mutation déclenchée par le changement de l’unité organisationnelle (UO) d’une identité, les étapes peuvent être le calcul du nouveau manager en fonction de la nouvelle UO, le retrait des rôles et des droits associés à l’ancienne UO, l’ajout des rôles et des droits associés à la nouvelle UO, la notification des managers et de l’identité concernés et la génération d’un rapport contenant les identités mutées ce jour-là.

Les processus sont une étape importante permettant de préciser les politiques en vigueur et de mettre en place unemeilleuresécuritédesdonnées.

L’écriture ou provisionning

Après le déclenchement d’un processus suite à la détection d’un évènement du cycle de vie de l’identité, vient le moment de mettre à jour les applications du SI avec les nouvelles informations et habilitations de l’identité.

Cetteétapepasseparlafonctionnalitéd’écritureaussiappeléeprovisioning.

Les nouvelles informations de l’identité sont écrites sur ses comptes applicatifs. Les nouvelles habilitations de l’identité sont mises a jour dans les applications : certaines sont ajoutées et d’autres sont retirées des comptes applicatifs correspondants.

Finalement,l’identitéestàjour,lesapplicationsduSIaussietl’évènementaététraité.

Voici un exemple de vue fonctionnelle de la gestion d’une création d’identité : on y retrouve bien le déclenche- ment du processus par la reconnaissance de l’évènement Création d’une identitépuis les étapes nécessaires pour traiter l’évènement en question.

Unprocessusdecréationd’identitéissude : https  ://documentation.sailpoint.com/saas/help/workflows/workflow-basics.html

La gestion des habilitations

L’IGAcomprend la gestion des habilitations (ou droits d’accès) des identités au sein du SI.

La gestion des habilitations passe par la construction d’un catalogue applicatif complet, la gestion des demandesd’accès, la définition d’un modèle de rôles et la création d’une politique précise en termes de droits d’accès.

Le catalogue applicatif

La gestion des habilitations nécessite de connaître l’intégralité des habilitations sur le SI et de les corréler auxbonnes identités.

Cela passe par la connexion de la solution d’IGA aux applications, la lecture des comptes applicatifs et la juste corrélationentrelesidentitésduSIetlescomptesapplicatifs.

Lecatalogueapplicatifestconstituédescomptes,groupesethabilitationsluessurlesapplicationsduSI.

Lesconnecteurs

Le rôle du connecteur est de faire le lien entre les applications du SI et la solution. Il existe de multiples connec- teurs dont la principale différence est le type d’application à laquelle ils permettent la connexion. Ex : il existe des connecteurs Active Directory, SAP, JDBC, CSV, XML... Il est aussi possible de développer des connecteurs personnalisés pour se connecter à des types d’applications non couverts par les connecteurs par défaut.

Chaque connecteur comprend une configuration leur permettant de se connecter à l’application concernée. Le connecteur permet la lecture et l’écriture des données présentes sur l’application. Certaines applications sont dites connectéesoudirectes:c’estlecasquandleconnecteurlitetécritdirectementsurl’application.

Lerôleduconnecteur-Applicationconnectée

Les applications déconnectées ou indirectes ne permettent pas une lecture et une écriture depuis la solution :onpassegénéralementviadesfichiersplats(CSVouXML).Oncréelefichierplatparextractiondesdonnées de l’application concernée. Le connecteur permet la lecture du fichier et la création des objets dans la solution. Lorsque des modifications des données de cette application sont nécessaires le connecteur modifie le fichier platou en crée un nouveau. L’application se met à jour en lisant le fichier plat le plus récent disponible.

Lerôleduconnecteur-Applicationdéconnectée

La lecture des applications

Lors de la lecture des applications, la solution obtient les objets présents sur les applications. Les plus communs sont les comptes applicatifs, les groupes et les habilitations. La solution stocke tous les objets nécessaires : c’est le catalogue applicatif.

La corrélation

Les règles de corrélation permettent d’attribuer chaque compte applicatif à l’identité concernée. Pour cela, des informations présentes sur le compte applicatif sont comparées à ces mêmes informations sur le cube identité.

Siuneuniqueinformationsuffitàfairelacorrélation,ils’agitdel’identifiantdesidentités:cedoitêtreun attributuniqueetpersonnel,différentpourchaqueidentité.Ex:lemail,l’identifiantemployéouletrigramme.

On peut également utiliser plusieurs informations qui ensemble permettent l’attribution du compte applicatif sans risqued’erreur.

Ex:lenom,leprénometl’UOpeuventsuffiredanscertainesentreprises.

Corrélationsurl’adressemail

Une étude de la qualité des données et de l’unicité des facteurs de corrélation est souvent nécessaire pour cer- tifierquelesrèglesdecorrélationsontadéquates.

Les comptes non corrélables aux identités existantes provenant des applications autoritaires sont à l’origine de la création de nouvelles identités. En revanche, les comptes non corrélables provenant des autres applications restent orphelins.

Lesdemandesd’accès

La lecture des applications permet de connaître l’état du SI à chaque instant. La gestion des habilitations passe également par la gestion automatique et fluide des besoins des utilisateurs.

Les demandes d’ajout ou de retrait d’accès peuvent être motivées par des évènements prédéfinis. Un évène- ment déclenche alors un processus qui comprend l’ajout et le retrait d’habilitations. Ex : les évènements de cycle devie de l’identité nécessitent souvent l’ajout et le retrait de droits d’accès. Lors de la mutation d’une identité dans l’entre- prise,lesaccèscorrespondantsàsonancienpostesontretirésetceuxcorrespondantsàsonnouveaupostesontattribués.

Il est également possible de donner une durée définie à l’attribution des habilitations.

Ex : Au début d’un projet, les habilitations nécessaires sont attribuées et la date de fin du projet est renseignée pour que les habilitations soient retirées automatiquement.

Enfin, les utilisateurs du SI peuvent faire eux-mêmes des demandes d’ajout et de retrait de droits d’accès. Les processus automatisés couvrent une grande partie des besoins des utilisateurs et leur objectif est de minimiser les demandes supplémentaires. Les cas particuliers sont pris en charge via les demandes unitaires faites par les utilisateursdans lasolution. Unprocessus dédié est défini pour gérer ces demandes. Ex: les utilisateurs ont accès à un formulaire leur permettant de demander l’ajout ou le retrait d’accès. Quand une demande est faite, le processus d’attributionouderetraitcomprendgénéralementdesapprobationsparlemanageretlegestionnairedel’application concernée. Une fois le processus terminé avec succès, les habilitations peuvent être attribuées et les applications sont mises à jour.

La définition des processus et formulaires liés aux demandes d’accès est très personnalisable et doit être ré- fléchie en détail. Les utilisateurs peuvent faire ces demandes directement depuis l’interface de la solution, pour eux-mêmes et pour les collaborateurs qu’ils managent. Les demandes d’accès peuvent être paramétrées pour que deschampscommecommentaires,datededébutetdefind’attribution,justificatifetautressoientremplisparlede- mandeur. Aussi, les formulaires peuvent être paramétrés pour afficher au demandeur les informations importantes à propos des accès telles que description, rôles dont il fait partie, risque associé etc.

Un formulaire simple de demande d’accès de l’outil IdentityIQ de SailPoint est un bon exemple : on y observelepremierongletd’unedemanded’accèspoursoi-même.Ilyaunongletpourdemanderunajoutd’accèsetun autrepourlesretraitsd’accès.Lesaccèsàl’écransontdeshabilitationsetunrôle.Onvoitdesinformationsles concernant.Le secondonglet estun ongletde revuede lademande pourvérifier qu’elleest correcteavant dela soumettre.

Unformulairededemanded’accèsdansIdentityIQ issudeIdentityIQAccessRequestsparSailPointTechnologiessurYouTube.

Lemodèlederôles

Les rôles sont des ensembles de caractéristiques réunissant des identités et donnant droit à des habilitations.La définition de rôles permet la simplification de l’attribution des droits d’accès et de leur relecture par la suite.

La définition du modèle de rôles peut être réalisée par les collaborateurs eux-mêmes : on demande à chaque manager de réunir les habilitations nécessaires pour travailler dans son équipe. Cela crée un modèle de rôles selon les métiers et les UO.

Les solutions d’IGA possèdent généralement une fonctionnalité d’extraction de rôles qui permet de définir les rôles observables à partir du catalogue applicatif corrélé au référentiel des identités. La solution identifie elle-même les points communs entre les identités possédant un même ensemble de droits d’accès.

Le modèle de rôle est un atout pour une solution d’IGA performante et sûre.

• Lesutilisateurssevoientattribuésunjeud’accèscohérentsansavoiràfairededemande.
• La compréhension des accès est simplifiée : le rôle a un nom et une description clairs, contrairement aux multiples accès techniques qu’il comprend.
• Les demandes d’accès sont plus simples à réaliser et à approuver : un rôle clair plutôt qu’une liste d’accèsindéfinie.
• Le risque de demander et d’obtenir des droits non nécessaires est diminué.

Lesdifférentstypesderôles

Unexempledemodèlederôlespourl’UOFinance

Unematricederôlescomplètepossèdeplusieursniveaux.

• Lesrôlesd’habilitations(enorange)associentundroitd’accèsàsafonction
• Lesrôlestechniques(envert)associentunensemblederôlesd’habilitationsàunbesointechnique
• Les rôles métiers (en bleu) associent un ensemble de rôles techniques à un métier ou à une tâche caractéristique d’un métier
• Lesrôlesorganisationnels(enviolet)associentunensemblederôlesmétiersàuneUO

Les règles et politiques

Unefonctionnalité dessolutions d’IGAest lapossibilité dedéfinirdes règles et politiques pour assurer la sécurité du SI.

Lesmécanismescommelaséparationdestâches(SegregationofDu- ties - SoD) permettent de vérifier automatiquement la cohérence des droits et accès avec les règles en vigueur et de signaler les anomalies. La SoD reposesurdesassociationsdedroits,d’accès,decomptesquisontinter- dites. La solution peut empêcher ces associations d’avoir lieu, en interdisant une demande d’accès si elle n’est pas compatible avec les accès déjà possédés.

Destâchesautomatiquespourreleverlesviolationsdesesrèglessont mises en place. Si une règle est enfreinte, des notifications peuvent être en- voyées,des auditssont déclenchéspour garderune tracede l’évènementet desprocessuspeuventêtrelancéspourcorrigerl’anomalie.

Lestypesdepolitiquesissusdehttps://community.sailpoint.com/t5/IdentityIQ-Wiki/Separation-of-duties-SoD-best- practices-in-IdentityIQ/ta-p/178004#toc-hId–192551779

L’intelligence d’analyse

Lapartieintelligenced’analysereposesurplusieursnécessités:

Lesbesoinsd’analyseenIGA

Au sein d’une solution qui centralise l’entièreté des identités et des applications, des fonctionnalités comme les audits, les rapports et les recherches permettent d’avoir une vision claire du SI et de garder un historique des actions et de l’état du SI.

Le respect des politiques en vigueur dans le SI est assuré par des fonctionnalités de détection et de correction des anomalies.

Lesutilisateurspeuventégalementreleveretcorrigerd’éventuellesanomalieslorsdesrevuesdesaccès.

L’analysedesdonnées

Des outils tels que la génération de rapports, de tableaux de bords et les moteurs de recherches sont disponibles dans les solutions d’IGA pour aider les administrateurs de ces solutions à gérer le SI au mieux.

Les rapports et les recherches

Les rapports d’audit sont des rapports simples, informatifs et concis. Leur écriture est déclenchée par une liste d’actionsprédéfiniesqueleclientsouhaitetracer.Ex:l’actionderedémarragedelasolutionpeutlancerunrapport d’audit dans lequel on retrouvera l’heure du redémarrage et le temps nécessaire. On peut également paramétrer des rap- portsd’auditpourchaquecréationd’identitéavecl’heure,ladate,lesinformationsdel’identitéenquestionetlasource.

Les rapports spécifiques sont plus détaillés, complets et complexes. Ils sont paramétrés pour répondre aux besoins en information du client et pour être exportés. Ils peuvent être créés au besoin ou paramétrés pour être générésrégulièrement.Ex:lescomptessuruneapplicationdontleslicencessontpayantespeuventfairel’objetd’un rapport spécifique, on pourrait y trouver des colonnes telles que les noms et prénoms des identités concernées, la date de création et de dernière utilisation de chaque compte ainsi que les droits associés.

Les rapports offrent une multitude de possibilités et les plus pertinents dépendront du contexte et des besoins du client.

Les recherches avancées et personnalisées permettent la recherche d’objets dans la solution et fournissent un grandnombre d’informations.Les recherchessont paramétréessimplement depuisl’interface graphiquepar le client et permettent d’avoir une vue d’ensemble rapide des identités, des accès et des habilitations présents dans la solution. Des recherches bien paramétrées peuvent donner lieu à l’établissement d’un nouveau rapport.

Lesfonctionnalitésd’analysededonnées donttroisimagesissuesdeIdentityIQdeSailpoint

La détection et la correction des anomalies

En cas d’écart avéré entre la théorie et la pratique, le système doit être capable d’identifier les anomalies, de lancer l’alerte et de régler le problème ou de permettre aux utilisateurs de le régler rapidement.

La détection

Desalertes peuventêtre misesen placelorsque desanomalies ontété repéréespar lasolution d’IGA. Si ces alertes sont à destination des utilisateurs, des notifications sont affichées ou des mails sont envoyés. S’il est prévu que la solution gère ces anomalies, ces alertes seront les déclencheurs de processus.

Les deux solutions peuvent être utilisées conjointement : notification des utilisateurs et déclenchement d’un pro-cessus dédié.

Desrapportsd’auditpeuventêtregénérésparcesalertespourgarderunetracedel’évènement.

La correction par la solution

Si les anomalies repérées sont anticipables, des processus sont définis pour y remédier automatiquement, rapi- dement et sans intervention des utilisateurs du SI. Le client doit définir les étapes clefs pour pallier chaque alerte. Cela permet à la solution de gérer elle-même sa conformité aux règles en place. Aussi, les anomalies pouvant re- présenter des failles de sécurité pour le SI sont remédiées sans attendre et la sécurité du SI est préservée.

Ex :on se place dans un SI où il a été défini que les mots de passe doivent être changés tous les 3 mois. La solution d’IGAlanceunealertesilemotdepassed’unutilisateurestvieuxdeplusde3mois.Leprocessuspeutêtrededemander systématiquementunautrefacteurd’authentification(réponseàunequestion,codeenvoyéparmail...)àl’utilisateur quand il tente de se connecter puis de rendre obligatoire le changement du mot de passe dès qu’il est authentifié sur la solution.Ainsi,lapolitiquedesmotsdepassedelasolutionestrespectéeetl’alerte’Motdepassetropvieux’esttraitée directement par la solution elle-même.

La correction par les utilisateurs

Les utilisateurs de la solution peuvent également régler certaines anomalies du SI. Si une intervention humaine est nécessaire au traitement d’une alerte, des formulaires peuvent être affichés aux utilisateurs responsables pour obtenir les directives ou informations nécessaires.

Quand l’anomalie est un cas particulier inédit ou qu’aucun processus ne peut être généralisé pour résoudre ce problème, les utilisateurs responsables seront notifiés et corrigeront l’anomalie à la main.

Ex:LescomptesdesapplicationsnonautoritairesquinesontpascorrélablesauxidentitésduSIseretrouventorphelins. Lesutilisateursresponsablesdesapplicationsconcernéespeuventalorsréconciliercescomptesaveclesidentitésquiles possèdent.

Si le cas particulier mis en évidence par l’anomalie peut se reproduire, une nouvelle règle sera définie. Si une erreur humaine est la source de ce cas particulier, l’anomalie sera traitée puis l’alerte sera archivée.

Lesrecertifications

Une recertification permet aux personnes compétentes de vérifier que les accès, comptes ou rôles accordés sont lesbonsetderévoquerceuxnonadéquats.

Le cadre

Unecampagnederecertificationsedéfinitparsoncadre:qu’est-cequiestrevu ?

Il est possible de revoir les comptes, les habilitations et/ou les rôles des identités. Une recertification peut porter sur une ou plusieurs applications du SI. Les identités incluses dans la recertification peuvent être identifiées par unecaractéristiquecommune.Lespossibilitéssontinfinies.

Ex :une re certification des accès notés comme sensibles se fera sur toutes les identités possédant au moins un accès sensible. Toutes les applications qui proposent des accès dits sensibles seront concernées.

Lesapprobateurs

Unerecertificationsedéfinitégalementparsesapprobateurs:quirevoit ?

Les choix fréquents sont les managers des identités et/ou les responsables des applications concernées. Il est pos-sible de choisir que la recertification demande plusieurs approbations.

Ex :une recertification peut demander d’abord l’approbation du manager puis celle du responsable de l’application. Les approbations peuvent également être déléguées, c’est-à-dire que l’approbateur désigné peut choisir de deman- der à une autre identité d’approuver l’accès en question. C’est utile dans le cas de managers qui ne connaissent pasun périmètreen particulieret préfèrentdemander auresponsable duprojet d’approuverl’accès.

Lesconséquences

Enfin,unecampagnesedéfinitparsesconséquences:quesepasse-t-il ? Lesaccès nonrevus aprèsla datede finde larecertification peuventêtre retirés,notés commedésapprouvés ou notés comme non-revus. Les accès désapprouvés peuvent être retirés dès que l’accès est revu ou à la fin de la recertification. Ils peuvent être notéscomme désapprouvésmais laissésaux identitésen attendantqu’un responsableles retirelui-même.

Lacriticitédesobjetsrevuslorsdelarecertificationpermettradedéfinirlesactionsàmettreenplace.

Lespersonnalisations

Des notifications par mails sont généralement envoyées lors des recertifications. On notifie les approbateurs du début de la campagne et on les notifie régulièrement qu’il leur reste des objets à revoir tant qu’ils n’ont pas terminés.

Des options fines comme les commentaires, les dates de révocations, les approbations par lots, etc. permettent de définir des campagnes de recertifications au plus près du besoin du client. Despolitiquespeuventêtremisesenavantlorsdesrecertifications.

Le principe du moindre privilège peut être mis en avant lors de la recertification en affichant clairement quelles habilitations détenues ne semblent pas indispensables à l’identité en fonction de son métier, son UO et ses projets en cours. Les approbateurs décideront ensuite de laisser ces habilitations si elles sont nécessaires ou de les révoquer. Le principe du besoin d’en connaître peut également être mis en avant en rappelant aux approbateurs que seules les habilitations réellement utiles à l’identité doivent être conservées. Le fait de pouvoir avoir une habilitation car son métier, son UO ou ses projets en coursle permettent ne suffit pas à accorder une habilitation. Les réunions d’information et les mails de notification peuvent permettre de rappeler aux approbateurs ces bonnes pratiques cruciales.

Exemplederevued’accès issuedeIdentityIQdeSailpoint

Les outils à disposition

Quelques fonctionnalités très utiles sont disponibles pour permettre aux solutions d’IGA de s’adapter aux besoinsdesclientsetdes’intégrerdanslaviedel’entreprise.

L’interface graphique

L’interface graphique des solutions d’IGA est personnalisable pour correspondre à la marque du client : les codes couleurs, les logos, les polices sont à définir avec le client pour coller au plus près de sa charte graphique habituelle et pour que l’outil se fonde dans l’environnement du client.

L’interface graphique est également personnalisable en termes d’affichage, de raccourcis et de fonctionnalités. Les menus déroulants, les raccourcis, les informations présentent sur la page d’accueil sont à définir avec le client. La page d’accueil doit être intuitive, facile à utiliser et à comprendre pour que la solution fonctionne bien dans l’en- treprise. Les fonctionnalités et informations les plus importantes doivent être en premier plan et rapides d’accès. Conjointement au client, en observant les outils qui sont déjà utilisés, on définit la meilleure interface graphique pour un projet.

Enfin, l’interfacegraphique proposée à l’utilisateurpeut être personnaliséeen fonction de sonposte, de son UOoudesaplacehiérarchiquedansl’entreprise.

Ex :les collaborateurs auront une interface personnalisée permettant une gestion simple de leur propre identité, de leurscomptesethabilitations.Lesmanagersaurontuneinterfacedifférentepourgéreralafoiscequilesconcerneetce quiconcernelesemployésqu’ilsmanagent.Enfin,lesresponsablesd’UOaurontuneinterfacepermettantdevisualiser plus facilement les différentes identités qu’ils gèrent, les tâches à faire (certifications, approbations en attente, etc.) et les fonctionnalités qu’ils utilisent le plus.

L’interface peut aussi être personnalisée en fonction des options disponibles pour chaque collaborateur dans la solution.

Ex :touslescollaborateursontaccèsàdesfonctionnalitéslesconcernantcommelademanded’habilitationetlavisibi- litédesinformationsliéesàleuridentité.Pluslesprivilègesdansl’entreprisesontimportants,pluslesfonctionnalités delasolutionsontdisponibles:onpensenotammentàl’intelligenced’analysepermettantd’obtenirdesrapportsetdes tableaux de bords sur les identités et les applications du SI qui n’est disponible que pour certains collaborateurs.

La finesse de personnalisation de l’interface graphique et de la page d’accueil demande de réfléchir la structure organisationnelle de l’entreprise et les besoins de chaque collaborateur. Plus l’interface sera facile d’accès, plus la solutions’intègreradanslaviedel’entrepriseetseraunatout.

Desexemplesdepagesd’accueildesolutiond’IGA

Lesformulaires

Les solutions d’IGA disposent de formulaires pour demander aux utilisateurs certaines informations néces- sairesaufonctionnementdelasolution.

Les formulaires peuvent être des supports pour des fonctionnalités telles que les demandes d’accès, les créa- tions d’identités, les modifications des informations d’une identité (déménagement, mutation, etc.). Dans ce cas, remplir le formulaire est la première étape du processus et le formulaire est disponible de façon permanente pour les utilisateurs.

Les formulaires peuvent également être des étapes des processus. Dans ce cas, le formulaire n’apparaît que quand l’information est nécessaire au processus, sous forme de pop-up, et ne sera plus disponible une fois validé.

Les champs d’un formulaire sont personnalisables : des listes cliquables, des champs formatés (NOM Prénom), des dates,des champscalculés etnon modifiables(manager calculéen fonctionde l’UOchoisie), desvaleurs pardéfaut modifiables, etc.

Lavalidationd’unformulairelanceunprocessusadaptéetprenantencomptelesinformationssaisies.

L’un des enjeux est de les rendre très facile à utiliser en s’adaptant aux utilisateurs ciblés. Des tests des formu- laires en cours de développement peuvent être réalisés sur un panel de futurs utilisateurs pour prendre en compte dèsla conceptionles éventuelles remarques desmétiers. S’adapterau plusprès desformulaires etprocessus déjà existantspermetalorsdelimiterlaconduiteduchangement.

L’automatisationdes tâches

Les tâches permettent d’automatiser la mise à jour de la solution. Elles peuvent être lancées manuellement au besoin, programmées pour s’effectuer régulièrement ou programmées pour s’effectuer à des moments clefs (une tâcheseterminantavecunrésultatprécisendéclencheuneautreparexemple).

Exemplededifférentes tâches

Des enchaînements de tâches peuvent être prévus pour la mise à jour de la solution ou d’autres besoins réguliers ettropconséquentspourêtregérésparunsimpleprocessus.

Ex :La mise à jour de la solution peut demander de :

• Lirelesdonnéesdel’application autoritaire
• Mettre à jour les cubes identités
• Déclencherlesprocessusdecréationd’identitésidenouveauxcomptessont apparussurl’applicationautoritaire
• Supprimerlesidentitésquin’ontplusdecomptessurl’applicationautoritaire,
• Lirelesdonnéesdesautresapplications
• Lancerlesprocessusrelatifsauxpolitiquespourvérifierlaconformitédeshabilitationsetdescomptesexistants
• Mettreàjourlesdemandesd’accès(clôturercellespourlesquellesleslecturesontmontréquelesaccèssontbien attribués)

Les tâches disponibles et l’historique de leurs résultats permettent une maintenance de la solution sans inter- vention humaine et une traçabilité des informations importante : on sait grâce à l’historique quand est-ce que les informationssontobtenuesetlesprocessussontdéclenchés.

Mariann FAURE

Consultante Cybersécurité