Nous avons proposé 5 facteurs clés de succès pour mener un projet de mise sous contrôle des risques liés aux habilitations des ERP :

Les deux premiers facteurs clés de succès ont été vus dans le précédent article ; les trois derniers sont détaillés ci-après.

3. Industrialiser le déploiement

Services, filières, entités géographiques ou légales… la remédiation des risques sur les habilitations nécessite de passer en revue les comptes utilisateurs de différents – et souvent nombreux – périmètres. Afin de tenir les plannings, de limiter la charge de travail, mais également de rassurer les contributeurs locaux, il est préférable « d’industrialiser » au maximum le déploiement. Cela passe notamment par :

• la définition et la communication d’une méthodologie d’analyse et de remédiation des risques ;
• la mise en place d’outils de pilotage ;
• la mise en place d’outils d’analyse plus ou moins automatisés pour faire face à la volumétrie ;
• la formalisation de supports d’ateliers et de restitution ;
• la documentation de la méthodologie et de l’outil pour former les utilisateurs.

Tous les documents produits dans ce cadre constitueront le « kit » de déploiement utilisé par le projet sur les différents périmètres, et qui pourra également servir après le projet.

« Kit » de déploiement d’un projet de remédiation des risques liés aux habilitations d’un ERP

La méthodologie de déploiement va nécessairement s’articuler autour des activités suivantes, à reproduire pour chaque périmètre :

• Analyse des risques et définition d’indicateurs.
• Ateliers de remédiation des risques portés par les utilisateurs.
• Validation et exécution des plans de remédiation.
• Formation et accompagnement à la montée en compétence.

Cette méthodologie doit néanmoins s’adapter à l’organisation de l’entreprise et aux moyens de chaque entité : effectifs, déclinaisons locales des processus métiers, maturité dans la gestion des risques et des habilitations…

En particulier, il s’agira de mobiliser des sachants locaux aussi bien sur le volet technique des habilitations (correspondants habilitations, responsables applicatifs, responsables sécurité) que sur le volet métier des processus (représentants métiers, responsables de processus, contrôleurs internes, managers d’équipe…). À ce titre, la contribution attendue de leur part et la charge qu’ils devront y consacrer devra être annoncée le plus tôt possible et rester « raisonnable ». Le management local devra donc être impliqué pour garantir la mobilisation des contributeurs et aider dans la prise de décisions.

Lors des ateliers de remédiation, les contributeurs participeront notamment à l’analyse des risques portés par les utilisateurs et seront amenés à étudier différentes stratégies de remédiation telles que celles-ci :

Stratégies à considérer dans un projet de remédiation des risques liés aux habilitations d’un ERP

Il est bien entendu préférable de valider cette méthodologie sur un périmètre pilote, d’une volumétrie limitée tout en restant représentatif de l’entreprise. Suivant le contexte, il peut être plus stratégique de choisir un périmètre a priori « favorable » au projet, ou bien au contraire un périmètre qui demandera de toute façon plus d’accompagnement. Les leçons apprises dans le cadre du pilote permettront d’ajuster la méthodologie et l’outillage qui l’accompagne avant la phase de déploiement généralisé.

4. Bien s’outiller

Les outils mis en place doivent aider à mener à bien la phase projet, mais aussi et surtout être utilisés dans la durée en support de la méthodologie, les deux fonctionnant de concert.

Bien s’outiller, c’est déjà être au clair quant aux contrôles à réaliser a priori (au moment de la demande d’une nouvelle habilitation) et aux contrôles à réaliser a posteriori (une fois que les habilitations ont été données). Avoir beaucoup de contrôles a priori peut certes aider à prévenir plus de risques, mais l’efficacité opérationnelle peut aussi en pâtir (délais, difficultés dans le traitement des demandes), d’où l’intérêt de trouver le bon équilibre.

D’un point de vue fonctionnel, il s’agit d’être en mesure de réaliser plusieurs familles de contrôles typiques pour un tel projet, à savoir :

• Contrôles sur la qualité des données : complétude et cohérence des données, respect des nomenclatures…
• Contrôles sur des règles de sécurité IT : comptes orphelins, dormants et administrateurs, permissions temporaires ou rémanentes, comptes IT avec des permissions métier et réciproquement…
• Contrôles sur des règles métier / conformité : écarts entre la fonction et les permissions, écarts de permissions entre les membres d’une même équipe, infractions aux règles de séparation des tâches, accès en dehors du périmètre de responsabilité…
• Contrôles sur les usages et le comportement : usages excessifs ou inhabituels, comportements suspects, scénarios de fraude typiques…

Familles de contrôles typiques pour un projet de remédiation des risques liés aux habilitations d’un ERP

Bien s’outiller, c’est aussi prioriser et automatiser les contrôles qui en valent le coup. Le retour sur investissement doit être évalué au regard de la pertinence de chaque contrôle dans le contexte de l’entreprise (le contrôle ne coûte-t-il pas plus cher que l’impact du risque qu’il est censé couvrir ?) et du gain potentiel lié à l’automatisation (combien économise-t-on par rapport à une réalisation manuelle ?).

La volumétrie et la complexité des modèles d’habilitation des ERP imposent le recours à des outils adaptés : il n’est en effet pas étonnant de voir par exemple des systèmes SAP avec plusieurs milliers de rôles et plus d’une centaine de milliers de permissions fines (transactions et objets d’autorisation).

Les besoins se retrouvent à la croisée de plusieurs marchés logiciels particulièrement dynamiques en ce moment et aux frontières assez poreuses : « Gestion des identités et des accès », « Contrôle continu », « Outils de Gouvernance-Risque-Conformité spécialisés sur un ERP donné »… L’approche, la maturité, la couverture fonctionnelle et le mode de delivery (sur site ou cloud/SaaS) peuvent ainsi varier sensiblement d’un produit à l’autre.

Lors du choix de l’outil, il s’agira de considérer attentivement les éléments suivants :

• L’ergonomie et la facilité d’utilisation – une fois le projet terminé, les utilisateurs de l’outil seront majoritairement « Métier » et peu « IT ».
• Les possibilités de personnalisation – pour que l’outil vienne véritablement en support de la méthodologie (vocabulaire et écrans, règles et contrôles, tableaux de bord et rapports spécifiques à l’entreprise…).
• Le référentiel des contrôles déjà préconfigurés pour l’ERP de l’entreprise – généralement basés sur des bonnes pratiques.
• La capacité à réaliser des contrôles sur d’autres applications et entre applications – dans une logique moyen terme pour l’entreprise.
• Les fonctionnalités d’aide à l’analyse et à la décision – mise en évidence des anomalies, simulation de changements sur les habilitations, analyses approfondies et suggestions de remédiations…

Bien que les outils soient généralement peu « intrusifs » vis-à-vis des applications, il s’agira tout de même d’automatiser et de fiabiliser le transfert des données depuis l’ERP et les autres référentiels éventuels. Les équipes IT concernées devront donc être sollicitées également.

5. S’inscrire dans la durée

Un tel projet n’a de sens que s’il permet de maîtriser efficacement et dans la durée les risques liés aux habilitations. Il s’agit en effet d’éviter que les risques couverts en phase projet ne soient de nouveau présents quelques temps plus tard.

Pour favoriser l’appropriation de la méthodologie et des outils mis en place, il est indispensable d’investir dès le début et tout au long du projet dans la conduite du changement : réunions et lettres d’information régulières, séances de formation et de coaching, documentation et tutoriels… On préfèrera diversifier les canaux et supports d’échange afin de toucher un maximum de personnes sans donner l’impression de les sursolliciter.

Il convient par ailleurs d’aider les futurs responsables des risques liés aux habilitations à inscrire les nouveaux contrôles dans leurs activités récurrentes. On peut ainsi définir à quelles fréquences les contrôles plus ou moins avancés doivent être réalisés, quels sont les objectifs à atteindre ou les seuils de risques à ne pas dépasser. Ces objectifs se doivent d’être réalistes et progressifs : « Visons loin mais jalonnons court. »

Dans une logique de « communauté », il est important de favoriser les échanges entre responsables des différents périmètres afin qu’ils partagent leurs retours d’expérience et leurs bonnes pratiques. Il peut également être intéressant de créer une émulation saine entre les différents périmètres, voire même d’organiser de petits challenges. On veillera néanmoins dans un premier temps à valoriser plus la progression que l’atteinte d’un objectif chiffré donné, les différents périmètres n’ayant probablement pas tous la même situation de départ ni les mêmes moyens.

Enfin, il convient de mettre en place le mode « nominal », garantissant que les risques liés aux habilitations restent sous contrôle une fois le projet terminé. Cela passe notamment par :

• la nomination d’un référent de la méthodologie et de l’outil de contrôle des habilitations ;
• la montée en compétence des équipes techniques pour assurer le maintien en condition opérationnelle des outils et assurer l’évolution des rapports et des contrôles lorsque nécessaire ;
• la documentation et la capitalisation des connaissances acquises durant la phase projet.

La définition d’une feuille de route pour l’extension ultérieure du périmètre est également à envisager, afin de mettre sous contrôle de nouveaux processus, risques, applications, populations…

Inscrire dans la durée la maîtrise des risques liés aux habilitations d’un ERP

En conclusion, c’est possible !

Comme nous venons de le voir au travers de ces deux articles, maîtriser les risques liés aux habilitations d’un ERP nécessite de mener plusieurs chantiers importants, de la mise en place de l’outillage à la conduite d’ateliers avec les métiers, en passant par la formation et la conduite du changement.

Mais avec de la méthode et les bons contributeurs IT et Métiers embarqués dans le projet, rien d’impossible ! Des résultats tangibles peuvent être obtenus dans un délai raisonnable et initier une dynamique d’entreprise pour retrouver la maîtrise des habilitations sur l’ensemble du SI. Les facteurs clés de succès présentés ici sont en effet tout à fait applicables à des applications autres que les ERP.

Cet article ERP : comment mettre sous contrôle les risques liés aux habilitations ? (2/2) est apparu en premier sur RiskInsight.

Les commissaires aux comptes, les contrôleurs internes et les auditeurs ne s’y sont d’ailleurs pas trompés, augmentant la pression depuis plusieurs années pour mettre ces risques sous contrôle et s’assurer de la conformité avec les règlementations afférentes.

Les enjeux de la mise sous contrôle des habilitations d’un ERP

Il convient dès lors de se pencher sérieusement sur le sujet des « habilitations » (appelées également droits, permissions, rôles ou encore profils d’accès). C’est en effet grâce aux habilitations qui leur sont octroyées sur les ERP que les utilisateurs peuvent réaliser une grande partie de leurs activités, qu’elles soient légitimes ou non. Donner les bonnes habilitations, aux bonnes personnes, au bon moment, doit donc permettre de réduire significativement les risques évoqués précédemment.

Au travers de deux articles, nous présentons notre vision du sujet et partageons des bonnes pratiques éprouvées permettant de mettre sous contrôle les risques liés aux habilitations des ERP.

Une maîtrise toute relative des habilitations sur les ERP

L’écosystème des ERP se révèle relativement complexe et les entreprises dépensent généralement beaucoup de temps et d’énergie pour leur mise en place. Pourtant, le volet « gestion des identités et des habilitations » est bien souvent traité a minima. Au fil du temps, cela se traduit par une dégradation du niveau de maîtrise et de sécurité :

• Comptes obsolètes, génériques ou partagés qui s’accumulent.
• Nombre de rôles qui explose.
• Non-respect du principe de moindre privilège.
• Combinaisons toxiques de droits (infractions à la séparation des tâches, Segregation of Duties en anglais), etc.

Autant de facteurs qui tendent à augmenter l’exposition aux risques évoqués plus haut.

Ainsi, rares sont les entreprises pouvant se targuer d’avoir la pleine maîtrise des identités et des habilitations sur leurs ERP. Pour s’en convaincre, les quelques questions symptomatiques ci-dessous peuvent aider à évaluer sa propre maturité sur le sujet :

• Combien de comptes ne peuvent pas être rattachés à une personne physique (comptes génériques, comptes non réconciliés avec les référentiels RH ou Active Directory…) ?
• Combien d’utilisateurs peuvent changer les droits d’accès d’autres utilisateurs ?
• Combien d’utilisateurs disposent de profils à forts privilèges (tels que « SAP_ALL» et « SAP_NEW » dans SAP ECC) ? Parmi ceux-ci, combien sont réellement légitimes ?
• Combien d’utilisateurs peuvent changer les données de base fournisseurs ?
• En moyenne, combien de rôles sont affectés aux utilisateurs ? Plutôt 2 ou 3 rôles par utilisateur, ou bien la dizaine de rôles est-elle régulièrement dépassée ?
• Combien de rôles IT sont affectés à des utilisateurs métiers… et inversement ?
• Combien de rôles donnent en réalité plus de droits que ceux prévus théoriquement (rôles supposés en lecture mais donnant des droits en écriture, rôles avec périmètres plus larges que prévu, etc.) ?

Comment s’y prendre ?

Maintenant que le constat est posé, que faire ? Surtout ne pas s’avouer vaincu ni se décourager face au chantier en apparence titanesque qui s’annonce ! Améliorer la situation et remettre les risques liés aux habilitations sous contrôle, c’est possible. Il faut pour cela, outre s’en donner les moyens évidemment, respecter quelques facteurs clés de succès déterminants détaillés ci-après.

Facteurs clés de succès d’un projet de remédiation des risques liés aux habilitations d’un ERP

1. Piloter de façon rapprochée

Dans un tel projet, il ne faut bien évidemment pas chercher à tout traiter tout de suite. Il s’agit donc de cibler stratégiquement des « périmètres » qui permettront de montrer des résultats significatifs dans un délai raisonnable. Il peut s’agir par exemple d’une application clé ou d’un module central de l’ERP, d’un processus particulièrement mis en lumière lors d’un récent audit, ou encore d’une série de risques déjà identifiés comme critiques dans le référentiel d’entreprise. L’analyse des données réelles, extraites des systèmes ERP, peut s’avérer d’une grande aide quant à la priorisation et la justification de cette priorisation.

En termes de démarche, le projet doit nécessairement prendre en compte 3 volets :

• L’analyse et la mise sous contrôle des risques liés aux habilitations, cœur du projet.
• La mise en place d’une solution technique, en support de la méthodologie.
• Le pilotage et la conduite du changement, indispensables pour la bonne réussite d’un tel projet.

Il est important de cadencer ce projet avec des jalons réguliers sur chacun des trois volets et durant chaque phase du projet :

• La phase de préparation, qui comprend le cadrage à proprement parler, la mise en place de l’outillage et la préparation des prérequis.
• La phase de déploiement, dite Get-clean, qui vise à mettre sous contrôle les risques à date : validation de la démarche sur un pilote, déploiement généralisé et adaptation de l’outillage en fonction des retours.
• Le mode nominal, dit Stay-clean, qui prend la suite du projet mais doit se préparer pendant celui-ci, afin d’assurer la maîtrise des risques dans la durée.

Démarche type d’un projet de remédiation des risques liés aux habilitations d’un ERP

Il sera impératif de suivre de près les actions des différents contributeurs et décisionnaires, et plus globalement la bonne atteinte des engagements pris pour chaque étape. Ces engagements pourront se matérialiser par des résultats aussi bien quantitatifs (réduction de X% du nombre de risques critiques, pas plus de 5 risques par utilisateur désormais…) que qualitatifs (évolution des processus ou des contrôles compensatoires). Il s’agira dès lors d’être en capacité de mesurer et de valoriser ces résultats auprès des sponsors du projet et des représentants métiers.

2. Préparer le terrain

Les aspects techniques et métiers sont étroitement liés dans les projets qui ont trait aux habilitations, et encore davantage dans le cas des ERP. Il est donc nécessaire de trouver dès le début les bons sponsors pour le projet, à la fois côté Sécurité ou IT et côté Métier ou Contrôle Interne par exemple.

Il pourra par ailleurs être nécessaire de solliciter de nombreux acteurs : correspondants habilitations, responsables sécurité, représentants métiers, responsables de processus, managers d’équipe, contrôleurs internes, etc. La coordination va s’avérer essentielle tout au long du projet et il faudra dès le début embarquer et mobiliser les futurs contributeurs et personnes concernées par le projet en leur partageant les enjeux, les objectifs et la démarche. L’approche se doit d’être « bienveillante » : il ne s’agit pas de stigmatiser une situation, des comportements, ou un périmètre par rapport à un autre, mais bien de faire progresser l’entreprise et les collaborateurs dans la maîtrise des risques.

La phase de préparation va consister dans un premier temps à recueillir les différents entrants nécessaires au projet, et particulièrement tout ce qui permettra de réaliser une première analyse des données : informations organisationnelles sur les utilisateurs (département, métier…), habilitations, journaux d’accès, référentiels de contrôle, matrice de séparation des tâches, etc. Sur ce dernier point en particulier, des ateliers sont certainement à prévoir pour compléter cette matrice et la « traduire » en permissions techniques afin d’automatiser les contrôles dans un outil.

Il s’agira par ailleurs de définir les indicateurs, tableaux de bord et rapports qui seront utilisés à la fois pendant la phase projet mais également dans la durée par les personnes en charge du contrôle continu.

Un autre point important durant cette phase de préparation sera de mettre en qualité les données. Ce prérequis se révèlera d’autant plus indispensable que le niveau de maturité de l’entreprise en termes de gestion des identités et des habilitations sera faible. La mise en qualité porte non seulement sur les comptes utilisateurs, mais également et surtout sur le modèle d’habilitation de l’ERP. En effet, si les rôles ou les profils d’accès sont eux-mêmes porteurs de risques (en termes de séparation des tâches notamment), il faudra y remédier avant de s’attaquer aux risques individuels portés par les utilisateurs.

Exemples de prérequis pour un projet de remédiation des risques liés aux habilitations d’un ERP

Nous venons de voir les deux premiers facteurs clés de succès pour mener à bien un projet de remédiation des risques liés aux habilitations d’un ERP, à savoir piloter de façon rapprochée et préparer le terrain. Les trois facteurs clés suivants seront détaillés dans un second article, à venir très prochainement.

Cet article ERP : comment mettre sous contrôle les risques liés aux habilitations ? (1/2) est apparu en premier sur RiskInsight.

L’approche « mise sous contrôle de l’existant »

Cette approche vise à vérifier l’efficacité opérationnelle de l’IAM par rapport aux règles prédéfinies (format des identifiants, nomenclatures des comptes, droits réels…).

C’est une démarche de mise en qualité des données. Elle consiste à comparer les données réelles d’une part (comptes dans les applications…) et les référentiels qui régissent l’IAM (liste des demandes d’habilitations…).

Pour les organisations ne disposant pas de service IAM, cette approche permet de s’assurer de la bonne réalisation des opérations manuelles. Elle permet de détecter et de corriger les éventuels biais survenus au cours du temps : erreur de saisie dans le nom d’un utilisateur, erreur dans l’attribution d’un droit, non-suppression d’un compte en cas de départ…

Pour les organisations possédant des outils IAM, elle permet de s’assurer du bon fonctionnement de ce dernier. Elle sera notamment d’une aide précieuse lors des investigations en cas de dysfonctionnement ou de plainte d’un utilisateur. En effet, l’IAG conserve l’historique des identités et des droits. Elle permet donc d’identifier immédiatement si une identité a été modifiée, pour quelles raisons et quelles en sont les conséquences.

Enfin, cette approche de l’IAG permettra de s’assurer de la bonne prise en compte des  événements non-standard (rachat de société et fusion des bases d’identités…) traités dans l’IAM via batch technique et souvent dépourvus de contrôles.

L’approche par les risques

Cette approche vise à donner de la visibilité sur les droits sensibles et à s’assurer du respect des règles de maîtrise des risques liées aux habilitations.

C’est une approche qui peut être conduite que l’on dispose ou non d’une solution d’IAM conventionnelle.Elle consiste à consolider les droits réels des applications sensibles pour pouvoir les comparer aux règles de l’entreprise.

Plusieurs actions sont ensuite envisageables : suppression des droits suspects, demande de dérogation temporaire, re-certification des droits à risques. Ou encore, si la règle s’avère inapplicable, adaptation de celle-ci et des moyens de mitigation associés.

Un point remarquable est que l’IAG s’inscrit dans une démarche d’audit, a posteriori de la demande d’habilitation. Cela permet de grandement simplifier les processus d’approbation et de certification ainsi que les workflows de gestion des demandes ; les cas d’exception pourront alors être détectés et instruits dans une démarche d’audit et de révision de droits.

Enfin, selon son contexte, une organisation devra choisir où porter son effort. Sur le  stock, c’est à dire sur la mise en conformité des droits déjà attribués. Ou sur le flux, c’est à dire sur les nouvelles attributions de droits sensibles. En effet, l’IAG conservant les historiques des droits, elle pourra quotidiennement identifier les nouvelles attributions de droits et déclencher les processus ad hoc.

Une approche par le flux, si elle ne permet pas de traiter l’existant déjà attribué, s’avère beaucoup plus simple à conduire : les demandes sont récentes, les approbateurs présents… Il est donc aisé de comprendre le contexte et les raisons ayant conduit à la demande. Elle pourra également constituer un premier palier quick-win du projet IAG.

L’approche par la justification et la prise de conscience

Si cette approche vise également à améliorer la maîtrise des risques, elle adopte une démarche plus douce.

En effet, parfois, l’application stricte des règles de contrôle et de séparation des tâches s’avère délicate : parce qu’il est convenu d’une application « souple », ou simplement parce que de telles règles ne sont pas suffisamment formalisées.

Dans ce cas, il est possible d’agir par réaction  par rapport aux demandes d’habilitations formulées. Ainsi, l’IAG va mettre en lumière des incohérences potentielles et permettre de les instruire unitairement.

À titre d’illustration, quelques exemples d’incohérences potentielles : personne du service RH qui reçoit un droit sur une application de gestion des stocks, personne qui reçoit un droit possédé par moins de 1% des personnes de son entité, personne recevant un droit administrateur sur une application, personne qui change de fonction mais qui conserve ses habilitations précédentes…

Ainsi, cette approche permet de challenger les demandes d’habilitation soumises et t de s’assurer que le principe du « juste droit » (les habilitations dont j’ai besoin et pas plus) est bien respecté.

À mesure de la prise de conscience et de la maturité de l’organisation, elle pourra se transformer en une approche plus coercitive.

L’approche en amélioration douce

L’approche en amélioration douce fait le choix de l’amélioration continue pour offrir une meilleure efficacité opérationnelle. Pour cela, elle analyse et compare les pratiques IAM constatées au quotidien dans l’entreprise. Elle vise ainsi à améliorer l’IAM en améliorant ses processus et la modélisation des habilitations.

À titre d’illustration, quelques exemples d’analyse de pratiques constatées : deux profils d’accès toujours possédés simultanément et qui pourraient constituer un profil métier, profils possédés par moins de 0,1% des personnes et qui pourraient être supprimés ou masqués, profils métiers redondants en termes de profils d’accès, profils possédés par plus de 80% des personnes d’une équipe et qui pourraient être recommandés en cas d’embauche…

Cette approche peut paraître plus avancée, et donc requérir un niveau de maturité important. Dans la pratique, les solutions d’IAG sont suffisamment souples pour permettre des démarches empiriques, en échange constant avec les Métiers.
Et le premier objectif n’est pas de tout analyser et comparer. Mais bien de se concentrer sur les cas les plus courants, les plus visibles, les plus significatifs pour les utilisateurs au quotidien.

Cet article Identity and Acces Governance : tour d’horizon des approches projet est apparu en premier sur RiskInsight.

Microsoft fait partie de ces acteurs de l’IAM pour le cloud. En raison de son rôle déterminant dans le SI « On-Premises » des entreprises, nous allons nous pencher de plus près sur sa solution : Windows Azure Active Directory (WAAD).

WAAD : une solution IAM-as-a-Service pour le cloud

Contrairement à ce que pourrait indiquer son nom, la solution Windows Azure Active Directory n’est pas un Active Directory hébergé dans Azure, la plate-forme cloud de Microsoft.

Officiellement lancée le 8 avril 2013, WAAD est décrit par Microsoft comme « une solution complète et sécurisée pour la gestion des identités et des accès dans le cloud. Elle combine des services d’annuaires principaux, une gouvernance des identités avancée, une gestion et une sécurisation des accès aux applications ».

Microsoft propose donc WAAD comme solution d’IAM-as-a-Service permettant, entre autres, de couvrir les applications hébergées dans le cloud. Contrairement à son approche « brique à brique » traditionnelle pour les services IAM On-Premises, dans laquelle chaque service est fourni par un produit spécifique, Microsoft adopte là une approche plus globale comme le démontre le tableau suivant :

Windows Azure Active Directory permet ainsi aux entreprises de :

• Étendre au cloud les identités gérées localement au sein d’un Active Directory On-Premises ;
• Gérer les identités et accès depuis le cloud, à la fois pour les applications cloud de Microsoft (Office 365, Dynamics CRM Online, Windows Intune), pour un nombre important d’applications SaaS du marché, mais également pour toute application que l’entreprise raccorde à WAAD ;
• Apporter une connexion unique (SSO) aux applications hébergées dans le cloud, voire aussi, dans certains cas, aux applications On-Premises ;
• Protéger les applications les plus critiques avec une solution d’authentification forte.

Notons que certains services proposés sont antérieurs à la date de lancement officielle puisqu’ils ont été introduits dès 2010 pour offrir les fonctionnalités de gestions des identités et des accès à Office 365. C’est ainsi que Microsoft a pu afficher les chiffres de 265 milliards d’authentifications réalisées et de 2,9 millions d’organisations clientes à la date de lancement de la solution.

Comment mettre en œuvre WAAD ?

Deux modes d’implémentation sont envisageables en fonction des usages que l’entreprise souhaite couvrir.

La première possibilité est une implémentation en stand alone, sans aucun lien avec les annuaires ou briques d’identités présentes dans le SI de l’entreprise. Cette absence de lien avec les infrastructures de l’entreprise permet de bénéficier rapidement d’une solution IAM pour le cloud. Néanmoins, cela impose de gérer spécifiquement le cycle de vie des identités (créations, modifications, suppressions), des mots de passe (initialisations, réinitialisations) et des habilitations (affectations de groupes).

La seconde possibilité consiste à « étendre les identités locales vers le cloud ». Ce type d’implémentation permet de déployer simplement des applications cloud et ce de façon transparente pour les utilisateurs. Pour cela, une synchronisation unidirectionnelle entre un Active Directory géré localement et WAAD est mise en place (via l’outil DirSync). Dès lors, les processus de gestion du cycle de vie des identités déjà en place au sein de l’entreprise se retrouvent étendus au cloud.

Et afin de permettre un accès sans couture aux utilisateurs à la fois aux applications cloud et aux applications hébergées dans le SI de l’entreprise, il est nécessaire de disposer d’une infrastructure de fédération des identités On-Premises.

Par ailleurs, il est possible d’utiliser un module d’authentification forte. Un téléphone est alors indispensable quel que soit le mode d’authentification choisi : One-Time Password par SMS, OTP par appel téléphonique ou encore notifications sur smartphone. Notons que ces fonctionnalités reposent sur la solution de l’éditeur PhoneFactor, racheté par Microsoft en octobre 2012.

Rappelons que Windows Azure Active Directory reste une solution d’IAM pour le cloud parmi d’autres. Dans un marché où des mouvements sont à prévoir dans les mois qui viennent, on peut se demander quels sont les véritables bénéfices de ces solutions, et ce qui les distingue les unes des autres. Des questions qui seront abordées dans un prochain article…

Cet article Identité dans le cloud : le marché se structure, quid de l’approche de Microsoft ? est apparu en premier sur RiskInsight.

Des tentatives infructueuses

La carte d’identité nationale électronique sécurisée est un projet d’identité numérique français datant de 2003. Cette carte d’identité devait contenir des informations biométriques. Ces données devaient également être conservées dans un fichier centralisé, solution perçue comme une atteinte aux libertés individuelles par nombre d’associations. Le projet a été arrêté puis relancé à de nombreuses reprises jusqu’en 2012. Le Conseil constitutionnel donna alors un coup d’arrêt définitif au projet en le censurant.

En parallèle, certains citoyens français ont pu expérimenter l’utilisation d’un certificat électronique « pour un usage unique » dans le cadre de leur déclaration d’impôts en ligne. L’expérimentation a finalement été abandonnée en raison de processus jugés trop complexes pour les utilisateurs (notamment lors d’un changement d’ordinateur) et trop coûteux pour le fournisseur (notamment en matière de support aux utilisateurs).

En 2010, un nouveau projet d’identité numérique, baptisé IDéNum est lancé. Deux ans plus tard, peu d’avancées concrètes à constater, sans qu’aucune raison officielle ne soit donnée.

L’échec des précédents projets gouvernementaux n’a cependant pas découragé les initiatives privées. Ainsi, La Poste propose un service de courrier recommandé en ligne, via une identité numérique baptisée « IDN ». Les informations personnelles sont vérifiées via plusieurs mécanismes, notamment la présentation d’une pièce d’identité à domicile à un facteur. Son utilisation reste cependant limitée à cet usage très ciblé.

2013 : un nouvel envol ?

Le gouvernement tente de relancer le projet IDéNum depuis début 2013. Le projet, financé par un partenariat public-privé, doit permettre de « préserver notre souveraineté nationale face aux alternatives étrangères et non sécurisées ».

Le projet adopte une approche innovante : garantir la fiabilité des Identités émises sans imposer l’État comme autorité de confiance. Ainsi, IDéNum devrait proposer un ou plusieurs « labels » reprenant des critères de qualité, de confidentialité, d’interopérabilité ou encore de contrôle fixés par l’État. Charge aux fournisseurs d’Identités privés de répondre à ces critères pour être labélisés et ainsi pouvoir émettre des Identités numériques fiables et reconnues.

Cette identité numérique devrait permettre d’accéder aux services administratifs de l’État, et plus largement à n’importe quel service privé qui y aura souscrit. C’est donc bien le « label » qui porte le niveau de fiabilité associé à l’identité numérique. D’où, peut-être, la possibilité de promouvoir plusieurs labels, correspondant à des critères de qualité différents, et adaptés à différents usages. Le « label » devrait aussi définir les « droits et devoirs » des fournisseurs de services souhaitant utiliser IDéNum. Ainsi, il permettrait d’encadrer l’usage et la diffusion des données recueillies.

Caractère universel, maîtrise de ses informations personnelles et fiabilité : 3 conditions de succès

Quels que soient les choix retenus, trois points cristallisent la relation à l’objet « identité numérique », et donc son futur niveau d’adoption : le caractère universel de son usage, la confiance de l’utilisateur dans le système – matérialisée par la maîtrise de ses informations personnelles -, et la confiance des fournisseurs de services utilisant ce même système, matérialisée par la fiabilité des informations.

Le caractère quasi universel d’une identité numérique – c’est-à-dire la possibilité de l’utiliser pour tout, tout le temps sans limite ni contrainte – est une condition sine qua non à une adoption de masse. Aussi, la question de l’interopérabilité, avec fournisseurs de services et entre pays, est primordiale. Le projet se doit donc d’emporter l’adhésion de nombreux acteurs publics comme privés. Pour cela il doit notamment offrir une prise en main et une utilisation des plus simples, pour les utilisateurs et également pour les fournisseurs de services. Par ailleurs, les initiatives de chaque pays européen doivent être compatibles et offrir un unique standard d’interopérabilité. En 2012, la Commission européenne a d’ailleurs publié un projet de règlement visant à définir un cadre européen pour l’identité numérique.

De plus, les utilisateurs doivent avoir confiance dans la maîtrise de leurs informations personnelles. La multiplication des comptes en ligne a conduit les internautes à diffuser massivement des informations personnelles, qui sont parfois monnayées à des tiers. L’identité numérique, qui fournit des informations qualifiées, ne doit pas devenir une source d’information à tout-va. L’utilisateur devra pouvoir choisir quelles informations il souhaite communiquer en fonction du service accédé et donc contrôler la diffusion de ses informations personnelles.

Aujourd’hui, un site de poker en ligne qui souhaite vérifier que vous êtes majeur vous demande de fournir une photocopie de votre carte d’identité. Cette dernière contient bien plus d’informations que la simple réponse à la question « Êtes-vous majeur ? ». Une identité numérique pourrait autoriser une granularité bien plus fine dans la diffusion des informations personnelles. De la même manière, un site de vente en ligne a besoin de connaître votre adresse postale, mais non votre date de naissance ou votre statut marital. Autre point d’attention : les adhérences entre les sphères privées, publiques ou professionnelles. Un fournisseur de services (par exemple de la sphère professionnelle) ne devrait a priori pas avoir connaissance des autres usages associés à une identité. L’identité numérique doit donc garantir souplesse, transparence et confidentialité sur les informations diffusées.

Enfin, l’adoption par les fournisseurs de services passe par un niveau de confiance élevé dans la fiabilité des informations recueillies. Par exemple, pour les services les plus critiques, permettre d’interroger le fournisseur d’Identités numériques pour garantir la validité de l’information fournie. À l’instar des cartes d’Identité physique, le vol ou la falsification seront autant de menaces pesant sur l’identité numérique. D’où la nécessité de définir un cadre légal, autant pour protéger les utilisateurs que les fournisseurs de services.

Alors, l’identité numérique, un levier pour de nouveaux usages ?

IDéNum doit permettre de dématérialiser encore plus de procédures, avec un niveau de confiance adapté, et accélérer ainsi l’émergence de nouveaux services sur internet (B2C notamment). Les entreprises vont en particulier y trouver un levier pour faciliter la relation client. L’identité numérique devrait simplifier des processus de souscription, et améliorer la confiance mutuelle : l’utilisateur dans l’usage de ses données personnelles et les fournisseurs de services dans la qualité des informations recueillies.

Mais soyons pragmatiques et n’attendons pas IDéNum pour avancer. Les Identités numériques existent déjà, même si elles ne sont pas qualifiées ou réputées fiables. Et pour certains usages, c’est déjà bien suffisant. Quels risques à permettre à un prospect de sauvegarder un devis et de s’authentifier avec son compte Google ? Si vous employez des étudiants saisonniers durant les congés estivaux, est-ce plus risqué d’utiliser des comptes génériques avec un mot de passe trivial, ou de leur permettre de s’authentifier avec leur compte Facebook ou LinkedIn ? Cette tendance est d’ailleurs déjà associée à un acronyme : « BYOID » pour Bring Your Own IDentity.

Au-delà des concepts, les fondamentaux « traditionnels » de l’identité doivent rester au cœur des réflexions : comment proposer une Identité unique et pérenne ? Comment garantir le lien avec le cycle de vie des utilisateurs dans l’entreprise ? Ou encore comment garantir un niveau d’authentification en cohérence avec les services offerts et les risques associés ? Autant de questions qui devront servir de guide à la définition de l’identité numérique de demain.

Cet article Identité numérique : quel état des lieux aujourd’hui en France ? est apparu en premier sur RiskInsight.

Des principes de bases partagés mais des divergences dans leur application

De nombreux pays tentent, à leur échelle, de répondre aux enjeux de l’identité numérique. Ces initiatives partagent les mêmes principes de base, calqués sur ceux de l’identité réelle. En revanche, elles divergent sur la mise en application de ces principes : acteurs autorisés à émettre des identités numériques, stockage des données personnelles, caractère universel ou non, etc. Ces spécificités ont pour objectif de façonner une identité numérique au plus près de la culture de chaque pays.

L’émission des identités numériques : par l’État, mais pas uniquement

Contrairement au monde réel, ce sont les acteurs privés qui ont été force d’initiative sur Internet. Par exemple Yahoo, Facebook, Google ou d’autres sites proposent d’ores et déjà de vous authentifier sur des sites tiers. Mais attention, si ce mode de fonctionnement apporte un réel confort aux utilisateurs, ces identités restent déclaratives, sans réellement améliorer le niveau de confiance associé. En effet, personne n’a vérifié que vous êtes bien la personne que vous prétendez être.

Comment alors vérifier les informations fournies et améliorer la fiabilité des identités ?

C’est souvent l’État qui se charge de vérifier et délivrer les Identités numériques de confiance. Toutefois, et principalement pour des raisons culturelles, cette responsabilité peut être déléguée à des entreprises privées, parfois sous contrôle de l’État. C’est notamment le cas au Royaume-Uni, où il n’existe pas de carte d’identité. La dernière tentative du gouvernement pour introduire une carte d’identité en 2010 n’a pas survécu à son impopularité. Le gouvernement s’est alors tourné vers les modèles américains et canadiens, en choisissant de confier la délivrance d’Identités numériques à des acteurs privés. Ainsi, il est possible de se connecter certains sites administratifs de l’État avec une Identité numérique fournie par Paypal ou The Post Office.

Des données personnelles stockées de manière centralisée ou portées par chacun

Autre point structurant de divergence entre les initiatives : le stockage des données d’identité.

Le plus souvent, les informations d’Identité numérique se présentent sous la forme d’une carte à puce. Celle-ci contient peu ou prou les mêmes informations qu’une carte d’identité traditionnelle, ainsi que des certificats électroniques protégés par un code PIN. Elle peut être intégrée à la carte d’identité physique, ou être contenue dans un support dédié (carte à puce, clé USB, carte SIM du téléphone portable…).

À contrario, l’Inde a pris le parti de centraliser les données biométriques de ses citoyens dans une base de données unique. D’ici 2015, le gouvernement espère enregistrer dans un fichier centralisé les empreintes digitales et rétiniennes de la moitié de la population. Avec un terminal biométrique, toute administration ou commerçant affilié peut alors identifier une personne. Notons que, en l’état actuel, un tel dispositif ne pourrait être transposable en France, la CNIL interdisant l’utilisation d’une base de données biométrique centralisée, sauf pour « fort impératif de sécurité »¹.

Déployer l’identité numérique : l’exemple Estonien 

L’initiative de l’Estonie se démarque cependant par son niveau d’adoption et le caractère universel de l’usage de l’identité numérique, tant dans le monde numérique que dans le monde réel. Grâce à un badge remis à tout citoyen (ou à la carte SIM de leur mobile), les estoniens sont en mesure depuis 2002 de certifier dans le monde numérique leur identité, et toute information personnelle qui s’y rattache (âge, sexe, domicile, etc.). Plus qu’une carte d’identité dématérialisée, cette identité numérique est pleinement intégrée à leur quotidien. Moyens de transport, transactions bancaires, déclarations fiscales, inscriptions à l’université, créations d’entreprise, etc. Elle permet même de voter aux élections nationales.

L’Estonie fait figure d’exception,  les niveaux d’adoption restant généralement faibles et les déploiements limités à des usages ciblés. L’Identité numérique existe malgré tout aujourd’hui dans plusieurs pays, et notamment en Europe. Qu’en est-il de la France ? Des initiatives sont-elles à y souligner ? La réponse est oui.

À suivre au 3^ème épisode…

Cet article Identité numérique : de nombreuses initiatives à travers le monde est apparu en premier sur RiskInsight.

Long, cher, compliqué : trois qualificatifs qui façonnent encore l’imaginaire autour de l’IAM. Si l’écart entre les ambitions des projets et les moyens alloués est certainement le premier facteur de cette désillusion, les difficultés historiques du marché à répondre aux nouvelles exigences exprimées par les métiers sont également à incriminer.          

Les dernières évolutions des acteurs leaders du marché, comme l’apparition de challengers innovants, bousculent ces idées reçues et créent une nouvelle dynamique.

Un marché historique tiré par des besoins IT mais peu adapté aux utilisateurs métiers

Gérer ses identités, prendre en compte les mouvements, donner des habilitations a minima, contrôler les droits d’accès aux ressources de l’entreprise… ces attentes ne sont pas une nouveauté.

Pour  y répondre, les outils historiques ont été conçus, sous l’influence des directions IT, pour optimiser les tâches récurrentes à faible valeur ajoutée. Ils se caractérisent donc par des capacités riches d’interfaçage avec les ressources existantes dans le SI, sans velléité particulière d’offrir des interfaces aux utilisateurs finaux, et souvent au prix d’un effort d’intégration important. Aussi, l’effet de volume de comptes traités est indispensable pour rechercher un équilibre économique.

Sous l’impulsion des métiers, ce paradigme a été fortement bousculé. En effet, les enjeux visés sont radicalement différents. En premier lieu, redonner aux managers – et aux responsables des données sensibles – la maîtrise de la gestion des habilitations. En deuxième lieu, respecter et donner des preuves du respect des cadres réglementaires. Enfin, s’inscrire dans une démarche valorisante de maîtrise des risques, c’est-à-dire se focaliser sur les identités et les accès sensibles et prendre en compte les exigences du contrôle interne ou de l’inspection générale.

Face aux attentes des métiers, le marché de l’IAM  s’adapte à marche forcée

Au-delà de l’effet marketing, l’apparition du terme IAG (Identity & Access Governance) symbolise à lui seul les faiblesses de la réponse du marché – et son obligation à évoluer.

Pour faire face à ce mouvement, les acteurs historiques ont bien naturellement étoffé leurs offres, au moyen de rachats ou de développements internes. Et si certains acteurs proposent aujourd’hui des solutions cohérentes, les résultats sont très contrastés voire parfois même peu convaincants. Comme s’ils avaient appliqué une surcouche sur une base non adaptée…

En parallèle, de nouveaux acteurs challengers se positionnent en misant principalement sur la simplicité et l’ergonomie : des moteurs de workflow souples, pouvant s’adapter aux différentes organisations d’un client ; des interfaces plus ergonomiques, inspirées par exemple du e-commerce (avec panier, moteur de recherche) ; des tableaux de bord adaptés à l’utilisateur connecté (suivi des demandes, des approbations…).
Ces solutions permettent généralement de travailler plus rapidement et plus étroitement avec les métiers. Elles peuvent nécessiter moins d’effort d’intégration mais demandent une réelle expertise fonctionnelle et technique des fonctionnalités et concepts mis en œuvre. Par ailleurs, leur portefeuille de connecteurs est souvent moins riche, mais est-ce une réelle limitation dans la pratique ?

Enfin, des acteurs de niche apportent des réponses justes et innovantes aux points de faiblesse des solutions historiques : « Gouvernance, Risque, Conformité » est leur crédo préféré. Pour ce faire, ils proposent des solutions peu intrusives sur le SI et à la mise en œuvre rapide.
Ils incarnent naturellement de réels leviers d’amélioration pour les organisations ayant déjà déployé une solution historique sans atteindre pleinement leurs ambitions initiales.
Mais ils offrent aussi de nouvelles approches projet en s’appuyant sur les droits effectifs sur le SI. En réalisant une photo consolidée du SI, ils permettent à moindre frais d’identifier les comptes présents (actifs, inactifs, orphelins…), les droits assignés, les risques liés aux droits incompatibles accumulés par certains utilisateurs…
Cette approche peut entraîner la prise de conscience nécessaire au déclenchement d’un projet IAM plus vaste.

Les enjeux de demain : embrasser pleinement les attentes des métiers tout en contribuant à la transformation de l’IT

Les métiers se sont appropriés les enjeux de l’IAM et imposent leurs exigences (interfaces simples, processus calqués sur les organisations, approche par les risques…).
Demain, il faudra embrasser pleinement leurs attentes en offrant des solutions simples, rapides d’évolution et ergonomiques. Mais aussi des solutions riches fonctionnellement : re-certification, profiling, aide à la détection de fraude, implémentation des règles de contrôles avancées…

Ces enjeux cruciaux ne doivent cependant pas masquer la contribution nécessaire de l’IAM à la transformation de l’IT : la consumérisation des identités, l’authentification basée sur les risques (risk-based authentication), la prise en compte du Cloud dans l’authentification sans couture ou encore l’émergence de l’IdM-as-a-service.

Un équilibre subtil à trouver, propice à l’émergence de nouveaux leaders ?

Cet article Le marché de l’IAM s’est-il enfin libéré de son carcan IT ? est apparu en premier sur RiskInsight.