L’intelligence artificielle s’impose désormais comme un levier structurant pour les entreprises : 70%¹ l’ont déjà placée au cœur de leur stratégie. Jusqu’ici, la majorité des déploiements reposaient sur des assistants conversationnels capables de restituer de l’information, parfois enrichie par des données internes, mais dont les interactions avec le système d’information restaient limitées.

Une rupture est désormais en cours : l’essor de l’IA agentique. Contrairement aux simples chatbots, les agents IA ne se contentent plus de répondre ; ils raisonnent, décident d’appeler des outils et déclenchent des actions. Ils peuvent envoyer un courriel, planifier un déplacement, mettre à jour un dossier, initier une transaction ou, demain, exécuter des opérations plus sensibles encore. Leur promesse en matière d’automatisation est considérable. Leur impact potentiel sur la surface d’attaque du système d’information l’est tout autant.

Car dès lors qu’un système d’IA agit, une question devient centrale : au nom de qui agit-il, avec quels droits, dans quel périmètre, et sous quel contrôle ?

Cette question est d’autant plus critique que les usages progressent rapidement : 51 %² des organisations ont déjà déployé un agent IA à destination de leurs collaborateurs, tandis que 59 %³ des salariés reconnaissent utiliser des agents IA non officiellement autorisés. Au-delà des usages individuels, chaque direction métier peut être tentée de déployer ses propres agents pour répondre à des besoins locaux. Ce phénomène alimente un Shadow IT agentique, dans lequel les agents se multiplient de manière fragmentée, avec des architectures hétérogènes, des contrôles variables et une gouvernance souvent lacunaire.

Dans ce contexte, l’Identity and Access Management (IAM) doit redevenir le centre de gravité de la stratégie de sécurité. Toute donnée qu’un agent peut consulter, toute ressource qu’il peut modifier, toute action qu’il peut exécuter doivent relever d’un dispositif de contrôle d’accès, de traçabilité et de gouvernance centralisé.

Cet article propose d’analyser la sécurisation des agents IA à travers le prisme de l’IAM, non comme une brique parmi d’autres, mais comme l’un des garde-fous structurants pour encadrer leurs usages et protéger durablement le système d’information.

Des assistants conversationnels aux agents IA : comment ils interagissent avec le SI

Par quels mécanismes un agent IA peut-il agir sur une application ?

La capacité d’un agent IA à interagir avec les applications du système d’information repose sur l’émergence de nouveaux protocoles, parmi lesquels le Model Context Protocol (MCP) occupe aujourd’hui une place croissante. Ce type de protocole permet à un agent IA de dialoguer avec des applications tierces via une couche intermédiaire, souvent matérialisée par une brique IT appelé serveur MCP.

Ce serveur MCP agit comme un composant d’exposition et d’orchestration. Il reçoit des requêtes émises par un modèle d’IA, les traduit en appels exploitables, puis les relaie vers les API de l’application cible.  Pour cela, le serveur MCP met à disposition du modèle des outils (“tools”) décrivant les actions qu’il est autorisé à invoquer. Une fois le serveur déclaré dans l’interface conversationnelle ou dans l’environnement de l’agent, le modèle peut décider, en fonction de la demande utilisateur et de son raisonnement, d’appeler un ou plusieurs de ces outils.

D’un point de vue sécurité, cela introduit une question d’identité : comment l’utilisateur final est-il authentifié, et comment cette identité est-elle propagée — ou non — jusqu’aux services cibles ? Dans les architectures modernes, l’authentification utilisateur repose généralement sur OpenID Connect (OIDC), tandis que l’autorisation d’accès aux API repose sur OAuth 2.x via des jetons d’accès. L’enjeu, pour un agent, est de garantir que les appels aux outils et aux API soient réalisés dans un modèle contrôlé de délégation : l’agent agit-il avec ses propres droits, avec les droits de l’utilisateur, ou selon un mécanisme hybride ?

Illustrons ce fonctionnement à travers un cas d’usage : la planification d’une réunion par un agent IA. L’utilisateur formule sa demande dans l’interface conversationnelle : « Planifie une réunion avec l’équipe demain à 10h ». L’agent IA analyse la requête et décide d’utiliser l’outil « Calendrier » mis à disposition par le serveur MCP. Il envoie alors une requête structurée à ce serveur, contenant uniquement les informations nécessaires à la création de l’événement (participants, date, heure, sujet). Le serveur MCP relaie cette demande à l’API du calendrier d’entreprise, qui permet de créer la réunion.

En apparence, le mécanisme est simple. En pratique, il introduit un changement majeur : le modèle ne se contente plus d’assister l’utilisateur ; il devient un intermédiaire actif entre l’intention humaine et l’exécution technique dans le SI.

Un mode de fonctionnement opaque

Cette architecture soulève immédiatement une difficulté de sécurité : dans de nombreux cas, le composant d’intégration ne dispose que d’une visibilité partielle sur le contexte d’origine. Il reçoit une requête structurée, mais pas nécessairement l’intégralité de la requête initiale, des arbitrages du modèle ou des éléments qui ont conduit au choix de l’outil invoqué. Le système d’information voit alors arriver une action, sans toujours pouvoir reconstituer de manière fiable la chaîne complète qui relie la demande utilisateur, le raisonnement du modèle, l’appel d’outil et l’effet final produit. Cette perte de contexte est d’autant plus critique lorsque l’appel à l’API est porté par un jeton OAuth : selon l’architecture, le service cible peut ne voir qu’une identité applicative (compte de service / application) et non l’utilisateur réel à l’origine de la demande. Cela fragilise l’attribution, la détection d’abus et la capacité à appliquer des politiques conditionnelles différenciées entre action humaine et action agentique.

Autrement dit, l’agent interagit avec le SI selon une logique partiellement opaque, qui rompt avec les schémas plus traditionnels d’interaction applicative. Cette opacité complique le contrôle en temps réel, la traçabilité ex post, ainsi que l’attribution claire de responsabilité.

Une technologie émergente qui pose des défis de sécurité

L’IA agentique introduit des cas d’usage nouveaux, mais aussi des risques nouveaux, qui doivent être analysés et traités au niveau de l’IAM. Quatre défis apparaissent comme particulièrement structurants.

Défi 1 : Recenser les agents IA 

Le premier défi est celui de la visibilité. Dans de nombreuses organisations, il n’existe aujourd’hui ni cartographie exhaustive des agents IA déployés, ni inventaire consolidé des outils auxquels ils sont connectés.

Cette situation résulte de deux dynamiques :

• D’une part, les usages se développent souvent en dehors des circuits de gouvernance historiques : certaines équipes déploient des agents pour leurs besoins propres, sans associer en amont les équipes sécurité, IAM ou architecture et dans parfois dans des solutions plateformes qui permettent à chacun de construire ses propres usages.
• D’autre part, les modalités techniques d’intégration sont diverses. Le MCP constitue une approche montante, mais il coexiste avec des intégrations propriétaires, des connecteurs natifs à certains écosystèmes, des mécanismes d’exécution locale de code, ou encore des capacités embarquées directement dans les plateformes des éditeurs.

Le sujet n’est donc pas seulement celui du recensement des agents eux-mêmes, mais celui de l’identification de l’ensemble de la chaîne d’exécution : agent, interface, outils exposés, applications cibles, comptes utilisés, données manipulées et flux générés. Sans cette visibilité, aucune gouvernance sérieuse n’est possible.

Défi 2 : Attribuer et gouverner les droits des agents IA

Le deuxième défi concerne l’autorisation. Les modèles IAM traditionnels ne disposent pas encore, dans la plupart des environnements, d’un objet natif et généralisé permettant de représenter proprement un agent IA comme une identité gouvernable à part entière.

En pratique, les composants intermédiaires sont fréquemment enregistrés comme des applications techniques ou opèrent à l’aide de comptes de service. Il en résulte plusieurs dérives connues : droits trop larges, absence de séparation fine entre les capacités d’un agent et celles du composant qui l’héberge, difficulté à appliquer le moindre privilège, et impossibilité de différencier clairement une action humaine directe d’une action exécutée par un agent.

Le risque est majeur : l’agent n’exécute plus seulement une intention métier ; il devient un vecteur d’accès indirect au SI, parfois avec un niveau de privilège supérieur à ce qui serait acceptable pour un utilisateur ou une application classique.

Défi 3 : Authentifier un agent IA

L’authentification constitue le troisième défi, à deux niveaux distincts. Il faut d’abord authentifier correctement l’utilisateur final, afin de garantir que l’agent n’agit pas dans un vide identitaire. Mais il faut également authentifier l’agent lui-même, ou à tout le moins le composant qui agit pour son compte, afin de pouvoir lui appliquer des politiques spécifiques, des restrictions adaptées et des exigences de supervision proportionnées.

Cette double exigence est nouvelle par son intensité : avec les agents IA, le système doit simultanément gérer l’identité du demandeur, l’identité du système exécutant, et la relation précise entre les deux.

Défi 4 : Tracer les actions réalisées par les agents IA

Le dernier défi est celui de la traçabilité. Dans de nombreuses architectures actuelles, les journaux permettent surtout d’observer l’appel technique émis vers le service cible. En revanche, il reste difficile de reconstituer de manière fiable :

• quel utilisateur est à l’origine de la demande ;
• quel agent a décidé ou exécuté l’action ;
• dans quel contexte métier l’appel a été réalisé ;
• quelles étapes intermédiaires ont conduit à l’exécution finale.

Ce déficit d’auditabilité fragilise à la fois la détection, l’investigation et la responsabilité. Lorsqu’une action sensible est déclenchée, il doit être possible de déterminer si elle résulte d’une instruction légitime, d’une mauvaise interprétation, d’une dérive autonome, d’un abus de privilège ou d’une compromission du contexte d’entrée, par exemple via une attaque de type prompt injection.

L’IAM comme cadre de référence pour sécuriser les agents IA

Les grands principes IAM restent inchangés

Face à cette transformation, un point doit être clairement affirmé : les fondamentaux de l’IAM ne disparaissent pas avec l’IA agentique. Au contraire, ils redeviennent essentiels.

Un système d’information maîtrisé repose sur quelques principes simples et robustes :

• centraliser l’authentification autant que possible autour d’un fournisseur d’identité de référence ;
• éviter les comptes génériques lorsqu’un usage nominatif est possible ;
• limiter les privilèges au strict nécessaire ;
• gouverner les habilitations dans la durée ;
• tracer les accès et les actions ;
• distinguer clairement les rôles, les responsabilités et les périmètres d’exécution.

L’arrivée des agents IA ne remet pas en cause ces principes. En revanche, elle révèle leurs angles morts actuels et impose de faire évoluer la gouvernance comme les mécanismes techniques. Ce n’est pas l’IAM qu’il faut réinventer ; c’est son modèle d’application qu’il faut adapter à une nouvelle catégorie d’acteurs numériques, capables de prendre des initiatives et de déclencher des effets dans le SI.

Une trajectoire de sécurisation en quatre étapes

1. Recenser les cas d’usage et les agents

La première étape consiste à obtenir une visibilité exhaustive. Cela suppose d’identifier :

• les agents déployés ;
• les environnements dans lesquels ils opèrent ;
• les outils et connecteurs qu’ils utilisent ;
• les applications qu’ils peuvent atteindre ;
• les comptes, identités techniques ou jetons qu’ils mobilisent ;
• les données qu’ils peuvent lire, modifier ou transmettre.

Cette cartographie n’est pas un exercice documentaire accessoire : elle constitue la condition préalable à toute politique de contrôle d’accès cohérente. Pour la réaliser, des outils du marché émerge, comme la solution Agent 365 de Microsoft.

2. Introduire un type d’identité spécifique pour les agents IA

La deuxième étape consiste à reconnaître les agents IA comme une catégorie spécifique d’identités non humaines. Ce marquage est essentiel, car il permet d’appliquer des politiques différenciées : interdiction de certaines actions, limitation à certains périmètres, exigences de validation préalable, surveillance renforcée ou restrictions conditionnelles.

Cette distinction est structurante. Une application classique n’a pas le même niveau d’autonomie, ni le même profil de risque, qu’un agent IA capable de sélectionner lui-même un outil, d’enchaîner plusieurs actions ou de réagir à un contexte ambigu. L’IAM doit donc être en mesure de dire non seulement qui agit, mais aussi de quelle manière le système agit.

À titre d’exemple, un utilisateur peut disposer du droit d’envoyer un courriel ou de créer un ordre de modification. Cela ne signifie pas qu’un agent puisse exécuter cette action sans garde-fou. Selon la sensibilité du processus, une politique dédiée peut imposer une validation humaine, un périmètre restreint ou une interdiction pure et simple.

3. Rattacher l’authentification et la gestion des droits à un fournisseur d’identité unique et à l’utilisateur final

La troisième étape consiste à ramener l’authentification dans le giron d’un fournisseur d’identité central, afin que les droits soient gouvernés de manière homogène. L’objectif est double : éviter le recours incontrôlé à des comptes techniques sur-privilegiés, et faire en sorte que l’agent opère, autant que possible, dans la limite des habilitations de l’utilisateur à l’origine de la demande.

Cela ne signifie pas que l’agent doit être transparent du point de vue de la sécurité. Au contraire, l’enjeu est de pouvoir appliquer une logique du type : « même si l’utilisateur a le droit, l’agent n’a pas nécessairement le droit de le faire seul, dans n’importe quel contexte, et sans contrôle complémentaire ».

4. Mettre en place une approbation humaine avant certaines actions initiées par les agents

La sécurisation des agents IA ne peut pas reposer exclusivement sur l’authentification et l’autorisation. Elle suppose aussi de définir le niveau d’autonomie acceptable selon la criticité des actions concernées.

Trois modèles sont classiquement distingués.

Human-in-the-loop

C’est le mode le plus protecteur. L’agent prépare l’action, mais son exécution reste conditionnée à une validation explicite. Ce schéma doit être privilégié pour les opérations sensibles : mouvement financier, modification de droits, envoi externe engageant l’entreprise, accès à des données sensibles, action à effet irréversible, etc.

Son intérêt est majeur : la validation finale est portée par une interface de contrôle indépendante du raisonnement de l’agent. Même si le modèle a été influencé, manipulé ou simplement trompé, l’utilisateur ou l’opérateur conserve la maîtrise de la décision.

Human-over-the-loop

Dans ce modèle, l’humain ne valide pas chaque action individuellement, mais supervise l’exécution et conserve une capacité d’interruption immédiate. Ce schéma peut convenir à des processus fréquents, encadrés et faiblement risqués, à condition que la surveillance soit réelle et que le mécanisme d’arrêt soit effectivement opérationnel.

Human-out-of-the-loop

Ici, l’agent exécute de manière autonome, sans intervention humaine immédiate. Ce niveau d’autonomie ne devrait être envisagé que pour des usages à très faible criticité, dans des environnements strictement bornés, avec des périmètres d’action réduits, des mécanismes de contrôle compensatoires solides et une tolérance explicite au risque résiduel.

Pour un RSSI, la logique est simple : plus l’impact métier, réglementaire ou sécurité est élevé, plus la boucle humaine doit être proche de l’exécution.

Une cible claire, mais encore freinée par plusieurs limites

Obstacles fonctionnels

La cible de sécurisation peut être formulée de manière claire. Sa mise en œuvre se heurte toutefois à plusieurs obstacles majeurs d’un point de vue fonctionnel.

Le premier concerne le manque de granularité des autorisations. Aujourd’hui, un utilisateur peut vouloir demander à un agent d’effectuer une action précise sur une ressource précise. Pourtant, les mécanismes disponibles imposent souvent des permissions bien plus larges que nécessaire. Traiter un courriel peut conduire à ouvrir l’accès à toute une boîte de messagerie ; planifier une réunion peut impliquer un accès étendu à l’agenda ; interagir avec un référentiel peut nécessiter des droits de lecture ou d’écriture bien au-delà du besoin exprimé. Ce décalage est particulièrement problématique dans un contexte agentique. Une IA étant par nature non déterministe dans sa manière de sélectionner et d’enchaîner ses actions, un accès trop large devient mécaniquement un risque disproportionné. Une adoption sécurisée suppose donc d’évoluer vers des mécanismes d’autorisation plus fins, contextualisés, temporaires et proportionnés à la requête réellement formulée.

Le second obstacle porte sur l’authentification et la propagation de l’identité. Dans beaucoup de cas, les architectures actuelles reposent encore sur des comptes techniques, des secrets partagés ou des mécanismes d’authentification peu satisfaisants au regard d’une gouvernance IAM mature. La cible consiste au contraire à faire en sorte que chaque action soit reliée de manière explicite à (i) l’utilisateur à l’origine de la demande, et (ii) au fait qu’elle a été exécutée par un agent — ce qui implique de distinguer l’identité du demandeur et l’identité du système exécutant, tout en documentant la relation de délégation entre les deux.  En pratique, cela renvoie à des mécanismes de délégation contrôlée tels que les flux OAuth “On‑Behalf‑Of (OBO)” : l’agent (ou sa couche d’orchestration) appelle une API en portant une autorisation dérivée de l’utilisateur, mais avec des contraintes supplémentaires (portée limitée, durée réduite, contexte, politiques conditionnelles). L’objectif est de réduire la dépendance aux comptes techniques sur‑privilégiés tout en conservant une chaîne de responsabilité exploitable.  À ce stade, le marché ne propose toutefois pas encore un modèle totalement homogène et interopérable couvrant à la fois l’authentification, l’autorisation fine, la traçabilité et la gouvernance des agents à grande échelle.

Dernier obstacle fondamental, la traçabilité : chaque action doit être liée de façon explicite à une chaîne de responsabilité intelligible. Sans cette capacité, il n’y a ni auditabilité robuste, ni contrôle effectif, ni gouvernance défendable devant les métiers, les auditeurs ou le régulateur. Et cela a un coût pour les SIEM…

Un marché encore fragmenté, qui complique la sécurisation

Du point de vue des entreprises, la difficulté n’est pas seulement technique : elle est aussi liée à la maturité du marché. Les capacités agentiques se diffusent plus vite que les standards de sécurité et de gouvernance capables de les encadrer de manière homogène. Résultat : les organisations doivent composer avec des solutions hétérogènes, dont le modèle d’identité, d’audit et de contrôle varie fortement d’un éditeur à l’autre.

Le MCP peut-il s’imposer comme standard de marché ?

Certains éditeurs exposent leurs applications via des serveurs MCP ou des mécanismes comparables, tandis que d’autres privilégient des intégrations natives, plus fermées, au sein de leur propre écosystème. Dans les faits, il n’existe pas encore de cadre pleinement homogène couvrant de manière satisfaisante les enjeux d’authentification, d’autorisation, de traçabilité, de gouvernance et de nomenclature des capacités exposées.

Deux trajectoires peuvent être envisagées :

• La première serait celle d’une convergence vers un socle standardisé, permettant l’interopérabilité des agents, des outils et des plateformes. Une telle évolution faciliterait le déploiement à grande échelle, améliorerait l’expérience utilisateur et rendrait possible une gouvernance plus cohérente à l’échelle de l’entreprise.
• La seconde serait celle d’une fragmentation durable du marché. Dans ce scénario, chaque éditeur continuerait à privilégier ses propres mécanismes, ses propres objets de sécurité et ses propres modèles d’intégration. Les conséquences seraient lourdes pour les entreprises : multiplication des angles morts, hétérogénéité des contrôles, difficulté à centraliser la supervision et impossibilité pratique d’appliquer une politique IAM homogène sur l’ensemble du périmètre agentique.

À court terme, les signaux du marché suggèrent une co‑existence : des initiatives d’interopérabilité émergent, mais les grands éditeurs conservent des logiques d’écosystèmes intégrés. Pour un RSSI, cela impose de raisonner non seulement “outil par outil”, mais aussi en termes de capacité à gouverner un portefeuille d’agents sur un périmètre multi‑éditeurs.

Vers des registres d’agents IA

La montée en puissance des agents IA justifie l’émergence d’un nouvel objet de gouvernance : le registre d’agents. Parce qu’un agent est un système autonome capable de déclencher des actions, il ne peut plus être traité comme un simple composant applicatif invisible. Il doit être identifié, qualifié, rattaché à un propriétaire, inscrit dans un cycle de vie, évalué en fonction de son périmètre d’action et soumis à des règles spécifiques.

Ce registre doit, à terme, permettre de répondre à des questions simples mais décisives :

• quels agents existent dans l’organisation ;
• qui en est responsable ;
• dans quel environnement opèrent-ils ;
• à quels outils et à quelles données ont-ils accès ;
• quels mécanismes d’authentification utilisent-ils ;
• quelles validations humaines sont exigées ;
• quels journaux produisent-ils ;
• quand doivent-ils être revus, requalifiés, suspendus ou retirés.

Certains fournisseurs d’identité commencent à introduire des capacités dédiées à cette nouvelle catégorie d’identités non humaines. C’est un signal important. Mais la maturité du marché reste naissante, et la gouvernance ne pourra pas être déléguée aux seuls éditeurs. Le vrai sujet est avant tout d’entreprise : définir un modèle de responsabilité, de contrôle et de sécurité adapté à l’autonomie croissante des systèmes d’IA.

Quand s’attaquer à l’IAM des agents IA ? Maintenant !

L’essor des agents IA marque une évolution majeure dans la transformation des systèmes d’information. En passant d’une logique d’assistance à une logique d’action, ces systèmes déplacent profondément les enjeux de sécurité : il ne s’agit plus seulement de maîtriser les données qu’une IA peut consulter, mais bien les actions qu’elle est en mesure d’exécuter, les droits qu’elle mobilise et les responsabilités qu’elle engage.

Dans ce contexte, l’IAM s’impose comme un levier structurant. Il constitue le socle permettant de rendre visibles les agents, de maîtriser leurs habilitations, de tracer leurs actions et de définir les conditions dans lesquelles leur autonomie peut être acceptée. Autrement dit, la sécurisation des agents IA ne pourra pas reposer sur des mesures périphériques : elle suppose une approche de gouvernance intégrée, articulant identité, contrôle d’accès, supervision et validation humaine.

Pour les organisations, l’enjeu n’est pas de freiner l’adoption de l’IA agentique, mais de l’encadrer dans un modèle de confiance soutenable. Cela implique dès aujourd’hui de poser des choix structurants : cartographier les usages, intégrer les agents dans les dispositifs IAM, distinguer les identités humaines et non humaines, adapter les politiques d’autorisation, et définir des garde-fous proportionnés à la criticité des actions confiées.

À mesure que les architectures se standardiseront et que les offres du marché gagneront en maturité, les entreprises les mieux préparées seront celles qui auront traité les agents IA non comme de simples assistants innovants, mais comme de nouveaux acteurs du SI, soumis aux mêmes exigences de sécurité, de traçabilité et de gouvernance que tout composant critique.

La question n’est donc plus de savoir si les agents IA trouveront leur place dans l’entreprise, mais dans quelles conditions de maîtrise. Pour les RSSI, le sujet est clair : la capacité à industrialiser l’IA agentique dépendra moins de la performance des modèles que de la robustesse du cadre IAM et de gouvernance mis en place pour l’encadrer.

Si, vous aussi, vous vous interrogez sur la gestion des accès des agents IA ou souhaitez approfondir la sécurisation de ces nouveaux usages, nous serions ravis d’échanger avec vous. N’hésitez pas à nous solliciter pour partager vos enjeux ou explorer ensemble des pistes adaptées à votre contexte.

1. Wavestone – Global AI Survey 2025  – AI Adoption and Its Paradoxes: Global AI survey 2025 | Wavestone)
2. PagerDuty (2025) More than Half of Companies (51%) Already Deployed AI Agents. Pager Duty, March 2025. Available at: 2025 Agentic AI ROI Survey Results (Accessed: 2 January 2026)
3. Cybernews (2025) Unapproved AI Tools in the Workplace. September 2025. Available at: https://cybernews.com/ai-news/ai-shadow-use-workplace-survey/ (Accessed: 2 January 2026).

Cet article Sécuriser les agents IA : pourquoi l’IAM devient central est apparu en premier sur RiskInsight.

Les équipes de réponses à incident Wavestone relèvent que 38% des attaques démarrent par une compromission d’identités (vs. 20% en 2024). Plus globalement, les attaquants exploitent fréquemment les identités on-premise pour se déplacer latéralement vers les environnements cloud (Microsoft Digital Defense Report 2025 [1]). 

Dans un contexte où l’hybridation des identités augmente une surface d’attaque déjà vaste, les entreprises doivent pouvoir en comprendre les enjeux et s’outiller efficacement. 

A travers ce nouveau panorama 2026 des outils de sécurisation Active Directory, nous vous proposons : 

1. Une cartographie actualisée des outils de sécurisation Active Directory 
2. Une lecture des grandes tendances du marché (consolidation, passage aux plateformes, hybridation cloud) 
3. Un retour d’expérience sur les difficultés d’implémentation opérationnelle et les facteurs clés de succès 

Un panorama des outils de sécurisation AD 2026 qui s’est encore enrichi 

En analysant le marché, nous avons identifié 4 cas d’usage principaux sur lesquels ces outils se positionnent : 

1. L’analyse et l’audit 
2. Le durcissement et le maintien en condition de sécurité 
3. La détection 
4. La réponse et la reconstruction 

Un recensement des éditeurs et outils proposant des fonctionnalités répondant à un ou plusieurs de ces 4 cas d’usage été effectué. Il a été réalisé avec l’objectif d’être le plus complet possible, intégrant les outils des acteurs les plus connus et utilisés du marché et ceux des acteurs moins/peu connus, les outils propriétaires et les outils open-source, les outils à large spectre de fonctionnalités et les outils proposant un panel plus limité de fonctionnalités. Tout outil pertinent a ainsi été consigné dans une liste, comportant pour chacun, diverses informations (renommée, description de l’outil et des cas d’usage couverts, hébergement…).  

Le panorama suivant recense un ensemble d’éditeurs de cette liste, sélectionnés en raison de la couverture fonctionnelle qu’ils proposent et de l’étendue de leur utilisation au sein des organisations. 

Le logo de Microsoft Entra ID est ajouté aux outils qui offrent la possibilité de l’intégrer dans leur fonctionnement en plus de la couverture de l’AD on-premise. Il s’agit d’une tendance forte sur le marché. 

1. Un marché en mouvement en pleine consolidation 

Le marché de l’Active Directory a connu un certain nombre de changements depuis 2022, avec plusieurs transactions majeures. Le but étant le plus souvent pour les éditeurs de compléter leur offre, ou de couvrir un nouveau besoin de la sécurisation Active Directory. 

On peut noter entre-autres : 

Rachat de PingCastle par Netwrix  [2] : PingCastle, reconnu pour son expertise dans l’audit de sécurité AD vient renforcer l’offre de Netwrix. Cette acquisition permet à Netwrix d’élargir son portefeuille avec un outil léger, rapide à déployer et apprécié des équipes techniques, tout en affirmant sa volonté de proposer une plateforme unifiée couvrant l’ensemble du cycle de vie de la sécurisation AD. 

Rachat de Attivo par SentinelOne  [3] : Attivo, spécialiste de la sécurité des identités et de la détection des mouvements latéraux, renforce l’offre SentinelOne en intégrant des capacités avancées de protection AD, dans une logique de plateforme unifiée alliant EDR, XDR et sécurité des identités. 

Rachat de BrainWave par Radiant Logic [4] : Radiant Logic renforce les capacités d’analyse d’identité et de gouvernance. En combinant la cartographie fine des droits de BrainWave avec la fédération d’identités de Radiant Logic, l’offre devient plus complète pour répondre aux enjeux AD. 

Intégration de Stealthbits par Netwrix  [5] : En fusionnant avec Stealthbits, Netwrix a intégré des briques historiques d’audit et de détection Active Directory (StealthAUDIT, StealthDEFEND, etc.), renforçant son offre sur la protection des identités et des données sensibles et s’orientant vers une plateforme unifiée autour de la sécurité d’AD. 

2. De l’outil spécifique à la plateforme centralisée 

En 2022, notre panorama des outils de sécurisation Active Directory mentionnait « des outils spécialisés, répondant chacun à une partie de l’équation. » [6]. En 2026, on observe l’émergence de plateformes centralisées, capables de couvrir plusieurs besoins autour d’Active Directory et, souvent, d’Entra ID. Cette dynamique est d’abord tirée par les éditeurs, qui cherchent à élargir leur proposition de valeur et à se différencier sur des plateformes complètes plutôt que par des outils spécialisés offrant des fonctionnalités spécifiques. 

Certains éditeurs construisent leurs plateformes par acquisitions successives, comme Netwrix (audit AD, protection des données, découverte de vulnérabilités, PingCastle…) ou SentinelOne (EDR/XDR renforcé par Attivo sur l’identité), tandis que d’autres enrichissent progressivement leurs offres historiques pour proposer des suites modulaires, qu’il s’agisse d’outils d’administration / surveillance comme ManageEngine ADAudit Plus ou Quest Change Auditor, qui ajoutent des briques d’audit AD, de durcissement et de détection sur l’ensemble de l’écosystème Active Directory. 

Les promesses mises en avant par les éditeurs sont claires : 

• Centralisation des données (comptes, groupes, droits, événements de sécurité) 
• Vision unifiée des chemins d’attaque entre AD et Entra ID 
• Pilotage simplifié pour les équipes sécurité, infrastructure et IAM, via des consoles et tableaux de bord consolidés 

Côté clients, les atouts sont évidents, mais la réalité peut être plus nuancée : 

• La consolidation peut réduire le nombre d’outils et simplifier les intégrations, mais elle ne supprime pas le besoin d’expertise AD ni les outils spécialisés (par exemple pour la reconstruction post-incident). 
• Les environnements restent souvent multi-éditeurs, avec un mix entre plateformes globales (XDR, CNAPP, Identity Security) et outils ciblés AD, notamment dans les grands groupes ou les organisations déjà fortement outillées. 

Dans ce contexte, l’enjeu n’est pas seulement de « choisir une plateforme », mais de composer un ensemble cohérent, en s’assurant que : 

• Le périmètre AD / Entra ID est bien couvert sur tout le cycle de vie (prévention, détection, réponse, reconstruction) 
• Les outils peuvent alimenter les processus existants (SOC, gestion de crise, PRA, IAM) 
• La dépendance à un éditeur unique est évaluée et maîtrisée. 

3. L’hybridation Cloud 

Avec l’essor d’Entra ID et des applications SaaS, l’hybridation des identités est devenue la norme : comptes et groupes AD sont synchronisés vers le cloud, les mêmes identifiants servent à accéder aux ressources on-premise et cloud. De nombreux incidents récents montrent que les attaquants exploitent ces architectures hybrides pour pivoter entre AD et Entra ID, en tirant parti de mauvaises configurations ou d’alignements trop faibles entre les deux mondes. [7] 

Cela se traduit par plusieurs besoins concrets : 

• Supervision conjointe d’AD et d’Entra ID : capacité à corréler les signaux issus de l’annuaire on-premise (changes, anomalies, tentatives de mouvement latéral) et du cloud (signaux Entra ID Protection, anomalies de connexion, accès conditionnel…).  
• Alignement des politiques de sécurité : durcissement de l’AD (configuration, délégation, comptes à privilèges) en cohérence avec les politiques d’accès conditionnel, de MFA et les exigences Zero Trust.  
• Capacités de reconstruction hybride : en cas de compromission AD, la reconstruction et la remise en service doivent intégrer les dépendances Entra ID (synchronisation, comptes de service, applications) pour éviter les effets de bord sur le cloud, et inversement. 

Les éditeurs se positionnent progressivement sur cette hybridation. Certains élargissent leurs moteurs d’audit AD pour inclure Entra ID (on-premise to cloud) et offrir une vue unifiée des vulnérabilités d’identité : Netwrix Auditor permet désormais de surveiller Entra ID en parallèle d’Active Directory avec une vue unique des menaces hybrides. Tenable Identity Exposure étend ses indicateurs d’exposition aux risques spécifiques Entra ID et Semperis Directory Services Protector corrèle les changements AD et Entra ID dans une console unique pour réduire la surface d’attaque hybride. 

D’autres outils partent du cloud (Entra ID, SaaS) et descendent vers l’AD on-premise (cloud to on-premise), dans une logique de “hybrid identity threat detection & response” : Microsoft Defender for Identity fournit un inventaire consolidé des identités AD et Entra ID et de nouvelles capacités de détection sur les composants hybrides (Entra Connect, AD FS, etc.), CrowdStrike Falcon Identity Threat Protection analyse les comptes hybrides présents à la fois dans AD et Entra ID / Azure AD. 

Une mise en œuvre opérationnelle encore perfectible 

Le marché de la sécurisation Active Directory montre une adoption croissante et structurée d’outils pointus. Dans beaucoup d’organisations, la couverture fonctionnelle est désormais correcte, voire avancée, sur les différents volets de la sécurité AD (audit, durcissement, détection, sauvegarde). 

Pour autant, la maturité technologique contraste, avec une mise en œuvre opérationnelle encore incomplète. Les plans de reprise d’activité (PRA / DRP) AD restent souvent théoriques, peu testés, ou déconnectés des outils de sauvegarde et de reconstruction déployés. Les revues régulières (revue de privilèges, de délégations, de relations d’approbations) sont encore rarement industrialisées : elles dépendent souvent de quelques experts, avec un niveau d’automatisation limité. 

L’efficacité de mise en œuvre est, de même, impactée par l’évolution constante de l’écosystème, entre plateformisation des outils et hybridation des identités. L’enjeu des prochaines années sera donc d’aligner les outils (existants et futurs) sur des processus robustes, documentés et testés : 

1. Clarifier les responsabilités entre équipes infra, IAM, sécurité et SOC, 
2. Formaliser et automatiser les contrôles récurrents (revues de droits, validation de configuration, tests de restauration). 

C’est à cette condition que les investissements dans les outils de sécurisation Active Directory, on-premise et cloud, permettront d’atteindre une résilience réelle. 

Méthodologie du panorama 

Nous identifions 4 catégories principales pour regrouper les outils : 

Analyse et audit : 

• Account and Privilege : Inventaire des comptes, groupes et droits associés pour détecter les privilèges excessifs ou non conformes. 
• AD Discovery : Exploration de la structure AD (OUs, GPOs, objets) pour déduire l’architecture, les relations et dépendances. 
• Vulnerability Discovery :  Identification des failles de sécurité (configuration, comptes obsolètes, mots de passe faibles…). 
• Attack Path Discovery : Modélisation des chemins d’attaque potentiels vers des comptes à privilèges. 

Durcissement et gestion : 

• Password Management : Gestion des politiques de mot de passe, synchronisation, audit des mots de passe (robustesse, réutilisation, compromission…). 
• Rights & Privilege Management : Délégation, contrôle des accès, gestion des rôles et des permissions. 
• GPOs Management : Création, analyse, modification des objets de stratégie de groupe. 
• Change Management : Suivi des modifications, traçabilité, gestion des changements et outils de migration. 

Surveillance : 

• Threat Detection : Détection proactive des comportements suspects, escalades de privilèges, mouvements latéraux. 
• Security Incident Detection : Identification des incidents de sécurité, alertes en temps réel, corrélation d’événements. 

Sauvegarde et Recouvrement : 

• AD Backup & Recovery : Sauvegarde partielle ou complète des objets AD, restauration rapide après sinistre. 
• Investigation & Forensics : Analyse post-incident, traçabilité des actions malveillantes, collecte de preuves. 

Pour chacun des outils ainsi classifiés, un badge (logo Microsoft Entra ID) est ajouté lorsque l’outil offre la possibilité d’intégrer Microsoft Entra ID dans son fonctionnement. 

Conclusion

Le panorama de 2026 se base sur l’analyse de 180 outils, contre 150 en 2022. Il a été construit dans une démarche similaire à celui de 2002. Il se base sur un recensement des outils du marché. Sur cette base et en lien avec les thèmes récurrents de sécurisation de l’Active Directory, une catégorisation a été établie pour en faciliter la lecture. 

La liste des outils mentionnés ne prétend pas être exhaustive, dans la mesure où la liste d’outils pouvant concourir de près ou de loin à la sécurité de l’Active Directory est vaste. Ce panorama est donc une synthèse des principaux outils existants, notamment ceux que les consultants Wavestone rencontrent le plus dans les grandes organisations (envisagés, étudiés, testés ou déployés). 

Références 

[1] Microsoft Digital Defense Report 2025 | Microsoft 

[2] Netwrix Acquires PingCastle | Netwrix 

[3] SentinelOne, Inc. – SentinelOne Completes Acquisition of Attivo Networks 

[4] Radiant Logic Signs Definitive Agreement to Acquire Brainwave GRC – Radiant Logic | Unify, Observe, and Act on ALL Identity Data 

[5] Netwrix annonce sa fusion avec Stealthbits | Netwrix 

[6] Radar des outils pour renforcer la sécurité d’Active Directory – RiskInsight 

[7] Microsoft Incident Response lessons on preventing cloud identity compromise | Microsoft Security Blog 

Cet article Panorama des outils de sécurisation Active Directory – version 2026  est apparu en premier sur RiskInsight.

Les attaques impliquant ces chaînes d’approvisionnement introduisent de nouveaux risques dans les systèmes d’information. Des intrusions peuvent entraîner des fuites de propriété intellectuelle, des altérations de code source, des interruptions de service ainsi que des élévations de privilèges vers des parties plus critiques du SI.  

Quels sont donc ces nouveaux vecteurs d’attaques sur les chaînes CI/CD et comment s’en protéger ? Cet article vise à dresser un panorama de chemins de compromission observés sur le terrain, ainsi que des recommandations pour les contrer. 

Quels risques pour les chaînes CI/CD ? 

L’attaque de SolarWinds en 2020 est un exemple qui ne cesse d’être énoncé, mais qui a mis en lumière l‘ampleur qu’une attaque de ce type peut causer. Après avoir vraisemblablement volé des identifiants FTP laissés en clair dans un ancien dépôt GitHub, l’opération a exploité la chaîne d’approvisionnement de SolarWinds en insérant un beacon C2 (Command & Control) dans leur logiciel de gestion réseau, Orion, en amont du processus de signature. 

Cette backdoor a permis aux attaquants d’accéder aux réseaux internes de plusieurs agences gouvernementales américaines et entreprises privées, et ce, pendant plusieurs mois avant d’être détectée. 

Cet incident, ainsi que des plus récents comme Log4Shell, Codecov et XZ Utils, ont non seulement souligné la nécessité d’une sécurité accrue dans la chaîne CI/CD mais aussi celle d’une réponse à incident beaucoup plus adaptative. L’OWASP présente de façon concrète un panorama des surfaces de risques les plus communes dans leur Top 10 CI/CD Security. 

Fig 1 – Top 10 OWASP CICD-Sec 

Quels retours terrain chez Wavestone ? 

Les audits et tests d’intrusion permettent de détecter des vulnérabilités de façon proactive avant qu’elles ne soient exploitées par des attaquants. En simulant de réelles attaques, ces évaluations offrent une perspective pratique sur la manière dont un système peut être compromis, ce qui permet d’appréhender plus concrètement les potentielles failles dans un système. 

Les différentes interventions menées chez nos clients nous permettent de faire un constat clair : 

• Dans nos audits Cloud et CI/CD, des vulnérabilités sont systématiquement trouvées au niveau des chaînes CI/CD, permettant dans la majorité des cas de prendre le contrôle de la chaîne, des artefacts, voire des infrastructures sous-jacentes.  
• De même, au niveau de nos interventions CERT & RedTeam, nous observons que les chaînes CI/CD sont souvent utilisées comme accélérateur dans les chemins de compromission. 

Regardons ensemble deux exemples d’attaque observés par nos équipes d’audit : 

Ce premier test d’intrusion en boîte grise a permis la compromission totale d’une organisation Cloud AWS (600+ comptes) en partant de comptes standards de DevOps. 

Dans ce scénario d’attaque, 

• Un attaquant pousse du code malveillant vers un repository GitLab, déclenchant une pipeline dans GitLab CI qui déploie ce code dans un pod Kubernetes générique. 
• Ce code ouvre un reverse shell, permettant à l’attaquant de se connecter à distance à l’environnement Kubernetes. 
• Depuis ce pod, l’attaquant exploite le fait que le compte de service associé au nœud dispose de privilèges trop élevés (capacité de patcher des jetons dans le cluster) et patch le jeton du nœud administrateur par un jeton générique. 
• Quand un redéploiement est déclenché, le pod malveillant ne peut qu’être déployer sur l’ancien nœud administrateur bénéficiant toujours des droits admin. 
• Cela permet donc à l’attaquant d’obtenir des privilèges élevés et de se latéraliser dans l’infrastructure AWS, compromettant ainsi le cluster Elastic Kubernetes Service (EKS) et les ressources associées. 

Regardons maintenant un deuxième exemple : 

Fig 3 – Condensé de plusieurs typologies d’attaques observées dans les CI/CD de nos clients 

Ce condensé, présenté à la DefCon & BSides 2022, met en évidence comment différents composants d’une chaîne peuvent être utilisés dans une attaque. Retrouvez cette présentation détaillée sur les nouveaux vecteurs d’attaque liés aux CI/CD en vidéo ! 

Quelles recommandations pour sécuriser sa chaîne CI/CD ? 

La chaîne CI/CD est désormais devenue un composant systémique des systèmes d’information pouvant être utilisée afin de compromettre des ressources critiques d’une entreprise. 

Nos recommandations en matière de sécurité de la chaîne CI/CD peuvent être articulées autour de trois grands axes : la gestion des identités et des accès (IAM), une meilleure conception de la chaîne CI/CD, ainsi que sa surveillance. Ces recommandations suivent notamment le guide DevSecOps de l’ANSSI. 

Fig 4 – Trois grands axes de recommandations pour sécuriser une CI/CD 

Gestion des identités et accès (IAM) 

Fig 5 – Recommandations IAM

Gestion des identités 

Outre les règles traditionnelles de gestion du cycle de vie des identités, il est recommandé d’utiliser systématiquement du Single-Sign On (SSO) avec authentification multifacteur (MFA) afin de réduire significativement le risque d’intrusion en CI/CD. Cela assurerait par exemple que les utilisateurs qui accèdent aux dépôts de code, qui signent un commit ou effectuent tout autre action privilégiée soient légitimés. 

Contrôle des accès 

Il est nécessaire de limiter au maximum les droits des utilisateurs et des comptes de service selon leur fonction dans la chaîne CI/CD, toujours en suivant le principe du moindre privilège. Les comptes sans mot de passe gérés par jetons d’accès doivent également être soumis à une gouvernance claire, avec des règles de cycle de vie, de rotation et de recertification régulière pour réduire les risques liés à leur utilisation. 

Cela peut aussi se faire en passant par du contrôle d’accès basé sur les rôles (RBAC). Par exemple, il ne serait pas utile de manière générale de donner un accès en écriture sur la configuration de la chaîne en elle-même à un développeur travaillant sur un projet spécifique. 

De la même façon, il est pertinent de segmenter ses projets en utilisant différents dépôts de code et de s’assurer que le compte orchestrateur d’un projet n’ait pas des droits excessifs sur le déploiement des projets auxquels il n’est pas rattaché. 

Gestion des secrets 

Les secrets en CI/CD désignent des données sensibles telles que des mots de passe, des clés d’API, des certificats ou des jetons d’accès. Ces secrets permettent notamment d’effectuer des actions privilégiées dans les pipelines et doivent être récupérés de façon automatique. 

Des éditeurs comme HashiCorp proposent des solutions de gestionnaires de secrets pour stocker facilement ses données sensibles et les chiffrer en transit et au repos.  

Conception de la CI/CD 

Fig 6 – Recommandations sur la conception d’une CI/CD 

Segmentation des environnements 

Il est nécessaire de préserver le cloisonnement entre les utilisateurs, les applications et l’infrastructure pour minimiser les impacts en cas de compromission. Reprenant des conseils de l’ANSSI, il faut considérer les actions réalisées par la chaîne CI/CD de production comme des actions d’administration et réduire au maximum le nombre d’utilisateurs pouvant y accéder. De plus, il est nécessaire d’utiliser du chiffrement bout à bout et de s’assurer qu’aucun environnement n’est exposé sur internet. 

Intégration d’outils tiers 

De la même manière que l’attaque SolarWinds, un grand nombre d’attaques de type supply-chain sont à l’origine un composant tiers compromis dans une chaîne CI/CD. Ces outils tiers sont souvent indispensables au bon fonctionnement des chaînes d’approvisionnement, ils peuvent aller d’un simple add-on sur un espace de développement, jusqu’à un outil de contrôle de version ou un orchestrateur. 

Généralement, ces outils se voient accorder des droits leur permettant d’accéder à des ressources sensibles ou d’effectuer des actions spécifiques au sein de la chaîne CI/CD. Si une vulnérabilité sur un outil n’est pas patchée et est exploitée par un attaquant, la capacité d’intervention sera limitée car la résolution de la faille dépendra souvent du fournisseur de l’outil. Il convient donc d’adopter une gouvernance stricte et un processus de Third-Party Cyber Risk Management (TPCRM) pour ces outils tiers. 

Gestion des artefacts 

Pour éviter de stocker des artefacts malveillants, il est recommandé de les signer en amont de la chaîne pour assurer leur intégrité en vérifiant cette signature au moment de leur déploiement. De la même façon, il faut s’assurer de ne pas déployer des librairies malveillantes en réalisant des scans Software Composition Analysis (SCA) régulièrement. 

Surveillance de la chaîne  

Fig 7 – Recommandations de surveillance 

Journalisation et détection 

Garder un haut niveau de visibilité et de contrôle sur tous les composants de la chaîne permet d’assurer une maintenance plus facile et une réponse plus rapide en cas d’attaque.  

Premièrement, il faut mettre en place une stratégie de journalisation adaptée, en maintenant des logs contenant uniquement ce qui est utile à la traçabilité et la responsabilité en cas d’incident. Il faut aussi s’assurer de stocker ces logs de façon sécurisée, ne pas y laisser des secrets en dur, ainsi que les partager efficacement à son Security information and Event management (SIEM). 

Aussi, pour réévaluer sa posture de sécurité et limiter au maximum les possibles chemins de compromission du pipeline CI/CD, des audits et des tests d’intrusion réguliers sont nécessaires.  

Réponse à incident 

Enfin, il faut s’assurer d’inclure sa chaine CI/CD dans ses plans de réponses à incident au même titre que n’importe quel autre périmètre de son système d’information. Il convient par exemple d’avoir des sauvegardes de son code source et ses configurations ainsi que des plans de continuité d’activités en cas de panne d’un outil. 

En conclusion 

Les chaînes CI/CD sont devenues une véritable pierre angulaire dans les systèmes d’information. Ces composants systémiques sont aujourd’hui indispensables pour développer et déployer des applications. Pourtant, leur criticité dans les SI appelle à mettre en place des mesures de sécurité adaptées pour qu’elles ne deviennent pas un vecteur d’attaques.  

Fig 8 – Quelques composants systémiques et critiques en CI/CD 

Outre les recommandations de cet article, d’autres mesures préventives peuvent se traduire plus précisément par des guides de durcissement pour des outils particuliers d’une chaîne. L’adoption d’une stratégie pertinente de formation des utilisateurs ainsi que de conduite du changement est aussi nécessaire pour réussir ces transformations.  

Un grand merci à Jeanne GRENIER pour sa précieuse contribution à la rédaction de cet article.

Cet article CI/CD : la nouvelle pierre angulaire du SI ?  est apparu en premier sur RiskInsight.

A cette fin, les modèles de droits existants sont nombreux : MAC, DAC, GBAC, ABAC…

Comment comprendre concrètement ces multiples déclinaisons de modèles de droits et les appliquer à son entreprise ?

Les modèles diffèrent dans leur degré de complexité et dans la réponse qu’ils apportent à des besoins et contraintes spécifiques d’une organisation ou d’un système. Les plus récents intègrent des problématiques de sécurité, de scalabilité et de conformité dans un environnement technologique toujours plus complexe.

Dans cet article, nous suivrons une logique chronologique en identifiant comment l’autorisation a évolué au cours des décennies pour répondre aux défis des organisations. Nous verrons, que, comme les systèmes d’information, les approches de modèles de droits se sont complexifiées, et intègrent aujourd’hui de plus en plus de paramètres pour décider d’accorder ou de refuser un accès.

On peut ainsi regrouper les modèles selon 3 approches reflétant leur sophistication progressive :

• Approche classique : l’admin-time
• Approche moderne : run-time
• Approches prospectives : event-time

Nous illustrerons chacune de ces approches par des modèles emblématiques en mettant en évidence :

• la réponse apportée à un besoin initial
• les limitations du modèle.

Et conclurons notre propos par une synthèse chronologique des approches et de leurs modèles.

Approches classiques d’autorisation : Admin-time

Dans les années 60-70, le développement des systèmes informatiques, marqué par la mise au point des premiers systèmes multi-utilisateurs (Multics, HP-3000), fait naître la nécessité de repenser les droits des utilisateurs.

Des principes de sécurité innovants, encore utilisés aujourd’hui, sont ainsi définis sur ces systèmes, à l’instar des anneaux de protection (rings en anglais), qui d’une part, visent à protéger l’intégrité du système d’exploitation contre les modifications volontaires et accidentelles, et d’autre part, initient la réflexion sur les politiques d’accès aux ressources par les utilisateurs.

Dans les premiers modèles de droits d’accès qui émergent, la gestion des droits reste sommaire, définie en dur par des « administrateurs » : c’est l’admin-time, dont on retient en particulier les modèles DAC et MAC (années 60-70) et RBAC (années 90).

Discretionary Access Control (DAC) et Access Control Lists (ACLs)

Comme son nom le suggère, le modèle DAC – pour « contrôle d’accès discrétionnaire » – laisse à chaque propriétaire de ressource le soin d’attribuer les permissions aux utilisateurs. Il est le modèle de droits de base que l’on trouve sur les systèmes Unix, qui peut être complété par le mécanisme d’ACL, des « listes pour le contrôle d’accès ». Souvent associées à DAC, les ACLs spécifient, pour une ressource donnée, les utilisateurs et leurs droits sur la ressource, comme illustré ci-dessous sur l’exemple d’Unix.

Au-delà d’Unix, les systèmes de partage de fichiers tels que OneDrive ou encore les réseaux sociaux, où l’utilisateur peut choisir qui peut voir ou commenter chaque publication, sont d’autres exemples d’utilisation de DAC et des ACLs.

En effet, la flexibilité et la granularité de ce modèle constituent un avantage pour des implémentations locales et centrées sur les individus. En revanche, elles deviennent problématiques pour assurer un niveau correct de protection des ressources à large échelle sur des systèmes plus complexes.

Mandatory Access Control (MAC)

Le modèle MAC, pour « contrôle d’accès obligatoire », prend le contrepied de DAC. Plutôt que de laisser l’assignation des droits à la « discrétion » des utilisateurs, ressource par ressource, limitant la visibilité à l’échelle du système et favorisant de fait erreurs et failles, des règles sont prédéfinies par des administrateurs selon différentes classifications de sécurité et appliquées de façon stricte par une autorité centrale, généralement représentée par le système d’exploitation lui-même.

Il prévaut en particulier dans les milieux gouvernementaux, militaires ou industriels, car il permet un contrôle étroit de l’accès aux données sensibles. Il utilise ainsi des labels qui caractérisent la sensibilité des objets et des utilisateurs, selon les règles de l’organisation concernée :

• Un niveau de classification des ressources, par exemple : « Non classifié », « Restreint », « Confidentiel », « pointe de diamant »[1], …
• Un niveau d’habilitation des utilisateurs, liés aux niveaux de classification des ressources existants.

Nous détaillons ci-dessous Multics et SELinux, qui sont deux exemples fondamentaux d’implémentation de MAC.

Exemple MAC 1 : Multics et les anneaux de protection

Déjà évoqué précédemment comme un précurseur des systèmes multi-utilisateurs (également dits « à temps partagé »), le projet Multics, sorti en 1969, a été porteur de multiples fonctionnalités innovantes, notamment dans sa gestion de la mémoire ou de la sécurité. Il préfigure ainsi MAC avant même la formulation de modèles tels que Bell-LaPadula (1973) et sa première définition formelle énoncée dans le « Orange Book » (1983) du Department of Defense, qui établit les normes de sécurité informatiques américaines.

Il repose sur le concept d’anneaux de protection (rings), que Multics a créé, en témoigne son logo (image ci-dessus), et qui constituent le fondement des systèmes MLS – Multi-Level Security –, très utilisés dans les contextes de haute confidentialité. Il s’agit d’un ensemble d’anneaux concentriques représentant des niveaux de sensibilité d’autant plus élevés que l’on se rapproche du centre (ring 0) – et donc de privilèges requis pour y accéder. Des mécanismes dits guards ou gatekeepers, situés à l’interface entre deux anneaux, contrôlent étroitement la légitimité des accès dans les deux sens, qu’ils accordent ou réfutent.

En réalité, ces anneaux sont de deux types :

• Les anneaux de protection du kernel sont des anneaux physiques intégrés aux processeurs et exploités par le système d’exploitation pour garantir son intégrité contre les fautes (à l’origine de plantages de la machine) ou des modifications, intentionnelles ou non.
• Les anneaux de l’espace utilisateur sont des anneaux logiques mis en œuvre par le système d’exploitation. C’est là que l’on retrouve MAC. Par le biais de labels, chaque utilisateur et chaque ressource se retrouve rattaché à un niveau d’anneau. De là, des règles définissent les actions possibles ou non, à l’instar du modèle Bell-LaPadula qui met l’accent sur la confidentialité des données : « No read up » (un utilisateur ne peut accéder en lecture à des couches supérieures à la sienne), « No write down » (il ne peut non écrire dans des couches inférieures, évitant les fuites).

L’image ci-dessous résume le principe des anneaux de protection.

Exemple MAC 2 : SELinux, module de sécurité du noyau Linux

Initialement développé par la NSA, en 2001, SELinux a été proposé et ajouté dès 2003 aux modules de sécurité pour le noyau Linux (LSM, Linux Security Modules), et est nativement intégré aux distibutions RedHat, telles que Fedora.

C’est un autre exemple notoire d’implémentation de MAC : il permet aux administrateurs d’attribuer à chaque ressource un label security context afin de les classifier, et de définir les politiques de sécurité qui seront appliquées par le système d’exploitation. Même avec des droits privilégiés, une application verra ses droits cantonnés au domaine qui lui est nécessaire pour fonctionner (par exemple les dossiers qui ont été lui spécifiés), SELinux détectant et empêchant toute action non conforme.

SELinux apporte donc une couche de protection supplémentaire dans le cas où un utilisateur ou un processus parvient à contourner les contrôles d’accès traditionnels.

Dans la pratique, les politiques MAC se suffisent rarement à elles-mêmes mais viennent se superposer aux règles DAC existantes, dont elles pallient la flexibilité. Deux modèles avant tout fondés sur l’identité de l’utilisateur ou du processus, à partir de laquelle ils autorisent ou refusent des accès : on parle de contrôle d’accès basé sur l’identité ou IBAC (Identity-Based Access Control). Ces modèles restent limités à des contextes locaux qui résistent peu au passage à l’échelle.

Role-based Access Control (RBAC)

Formulé en 1992 par David FERRAIOLO et Richard KUHN, deux ingénieurs du NIST américain, le modèle RBAC – modèle d’accès basé sur les rôles – a été pensé pour simplifier la gestion des permissions à l’échelle d’une organisation tout en en reflétant au mieux la structure (hiérarchie, responsabilités, départements…).

Au lieu d’octroyer les droits directement à une identité comme avec IBAC, une méthode vite difficile à maintenir, on conçoit des rôles métier et les privilèges associés. L’utilisateur hérite alors des droits rattachés à son rôle au sein de l’entreprise, ce qui lui permet d’accéder aux différents applicatifs et systèmes de partage d’entreprise considérés comme nécessaires pour ses activités internes.

Ce premier cadre conceptuel a été complété et standardisé en 2004 avec la norme ANSI INCITS 359-2004, qui tient compte de cas pratiques et scénarios d’entreprise. Par exemple, il aborde les besoins en séparation des responsabilités (SoD, Segregation of Duty), fondamentale dans les institutions financières et bancaires, mais aussi le principe de moindre privilège, ou encore l’héritage des permissions.

Une adoption progressive et toujours plus centralisée de RBAC

Dès les années 80-90, largement adoptées par des grandes entreprises et susceptibles de contenir des informations sensibles dont on a naturellement voulu contrôler l’accès, les bases de données ont été pionnières dans la mise en œuvre du modèle RBAC. Elles illustrent son implémentation au niveau d’applications isolées, non répercutée sur les applications ou systèmes externes.

Les années 2000 voient le lancement de l’Active Directory de Microsoft, à partir du Windows 2000 Server. Cet annuaire centralisé vise la gestion de l’ensemble des ressources de l’organisation (personnes, ressources physiques, applicatifs). Bien que ce ne soit pas à proprement parler un outil RBAC, un rapprochement peut être fait. L’attribution de droits d’accès se base en effet sur des groupes de sécurité – qui peuvent être perçus comme des rôles – avec des mécanismes d’héritage de permissions et des concepts de domaines, arbres et forêts visant à représenter les structures logiques d’entreprise.

Depuis, les solutions IAM modernes, comme Okta, SailPoint IIQ ou Microsoft AzureAD, supportent RBAC pour des environnements hétérogènes, notamment les services cloud. Elles illustrent la centralisation progressive de la gestion des droits d’accès, d’abord gérée localement dans les applications, et aujourd’hui de plus en plus déléguée à des solutions IAM couvrant un spectre maximal.

RBAC attribue des droits en fonction d’un rôle métier tandis qu’IBAC est lié à une identité. La couche d’abstraction créée entre l’identité du sujet et son rôle permet de s’extraire de contextes restreints (systèmes de fichiers pour DAC, systèmes d’exploitation pour MAC) et de s’adapter (enfin !) aux besoins de contrôle d’accès d’organisations. Tous partagent néanmoins comme caractéristique une définition rigide des droits, basée sur une identité ou un rôle.

Dans des entités où les échanges sont plus dynamiques et plus fluctuants, cette abstraction au travers de rôles seuls peut s’avérer insuffisante. De nouveaux modèles ont émergé pour représenter des organisations plus complexes, prenant en compte des attributs supplémentaires, évolutifs, pour évaluer plus finement un droit d’accès à un instant t : de l’admin-time, nous entrons dans le run-time.

Les nouvelles approches d’autorisation : Run-time

La complexification des systèmes d’informations, donc des accès, ont conduit à l’approche run-time. Une approche qui répond aux besoins de flexibilité et de sécurité dynamiques des organisations. Contrairement à l’ère “admin-time”, caractérisée par des permissions statiques, l’ère “run-time” offre une gestion en temps réel au moment de la demande d’accès, fondée sur différents éléments contextuels. Cette transition vers des modèles d’autorisation plus flexibles et précis permet aux organisations de s’adapter aux changements et de mieux protéger leurs ressources contre les menaces actuelles.

Graph-Based Access Control (GBAC)

Le modèle GBAC (Graph-Based Access Control) ou GraphBAC, repose sur l’utilisation de graphes pour représenter les relations entre les utilisateurs, les rôles et les ressources au sein d’une organisation. Ces 3 types d’entités (utilisateurs, rôles, ressources) et les relations entre elles constituent le cœur de ce modèle : on peut représenter les entités par les nœuds du graphe, et les relations entre elles par les arêtes.

Les autorisations d’accès à une ressource sont déterminées en temps réel par des requêtes sur cette base de données de graphe, permettant de prendre des décisions d’accès basées sur les connexions entre les entités au moment de la demande. Un utilisateur peut ainsi obtenir l’accès à une ressource en fonction de son rôle et de ses relations avec d’autres utilisateurs ou ressources de l’organisation

Le modèle GBAC est adapté aux environnements dynamiques de grandes organisations, où les relations entre entités évoluent constamment. En revanche, sa mise en œuvre peut s’avérer complexe et les projets de mise en place sont relativement longs donc avec des coûts élevés non négligeables. De plus, l’ajout progressif de nouvelles relations peut rendre le graphe de plus en plus difficile à gérer, compliquant ainsi les activités d’audit interne ou encore de recertification par exemple.

Attribute-Based Access Control (ABAC)

Dans le modèle d’accès ABAC (Attribute-Based Access Control), la gestion des accès à une ressource s’appuie sur la combinaison dynamique d’attributs. Ces attributs concernent aussi bien l’utilisateur demandant l’accès (rôle, groupe), la ressource demandée (type de ressource), que le contexte dans lequel s’effectue la demande (heure, type de réseau). Cette approche permet d’autoriser ou non l’accès de façon flexible et en temps réel.

Le modèle a été formalisé en 2014 dans la publication par le NIST (SP 800-162) qui fournit des informations détaillées pour sa mise en place.

4 composants sont essentiels au fonctionnement de ce modèle : les Policy Enforcement Points (PEP), les Policy Decision Points (PDP), les Policy Administration Points (PAP), et les Policy Information Points (PIP).

Après interception par le PEP, la demande d’accès est transmise au PDP, qui est responsable de la prise de décision en analysant les politiques d’accès qui sont gérer au niveau du PAP et souvent accessible depuis une base de données de politique d’accès. Le PIP fournit lui, au PDP des informations complémentaires sur l’utilisateur ou la ressource provenant de différentes sources permettant ainsi de rendre des décisions conformes aux règles d’accès. Pour les informations contextuelles le système d’information peut être connecter à d’autres outils ou sources (IDS, logs, capteurs) qui permettent la collecte de ces informations au moment d’une demande d’accès.

L’ABAC se présente comme un modèle particulièrement intéressant dans les environnements où les besoins d’accès sont variés et évolutifs, car il permet une gestion fine et granulaire des autorisations, notamment dans le cadre du PAM (Privileged Access Management), concernant des accès, et ressources critiques.

Cependant, ce niveau de détail et de flexibilité vient avec des défis comme la revue continue des attributs, la maintenance des politiques qui nécessitent une attention constante afin de s’assurer qu’ils répondent aux besoins de l’entreprise. Au fil du temps, le nombre croissant d’attributs et de conditions peut compliquer le maintien d’une architecture ABAC claire et fonctionnelle, surtout dans des environnements en perpétuelle transformation.

Dans les architectures ABAC actuelle, les PEPs sont généralement conçus pour fonctionner uniquement avec les PDPs du même fournisseur, avec des protocoles propriétaires, sans support pour une compatibilité entre différents fournisseurs.

Standardiser la manière dont ces différents PEP et PDP interagissent, afin d’améliorer l’interopérabilité des systèmes et de réduire la dépendance à un seul fournisseur est l’objectif du groupe de travail OpenID AuthZEN.

OpenID AuthZEN : Vers une interopérabilité améliorée

AuthZen est une initiative lancée en 2023, au travers d’un groupe de travail, par l’OpenID Foundation visant à standardiser les interactions entre les PEPs et les PDPs afin d’améliorer l’interopérabilité entre les systèmes de différents fournisseurs.

Cette initiative répond aux problèmes actuels où les services d’autorisation (PEP et PDP) sont souvent conçus pour fonctionner uniquement avec des solutions du même fournisseur, limitant leur interopérabilité.

AuthZen a été lancée pour développer un protocole standardisé qui faciliterait l’intégration et la communication entre les PEPs et les PDPs, et réduirait la dépendance aux solutions provenant d’un seul fournisseur mais aussi d’améliorer la sécurité globale des autorisations.

Pour rendre ces interactions plus flexibles et universelles, AuthZen s’appuie sur des architectures et des technologies existantes (OPA/Rego, XACML…), afin d’améliorer le déploiement, la scalabilité et l’interopérabilité. Les deux premières étapes de cette standardisation avec l’Open ID AuthZen sont la mise en place d’un protocole simple de type “Request/Response” et “Permit/Deny” et d’une approche de décisions multiples afin de regrouper plusieurs demandes d’autorisation en une seule et de recevoir plusieurs décisions en retour.

Ce cadre de réflexion autour de l’AuthZen comprend des acteurs du domaine de la sécurité tels que 3Edges, Axiomatic, et d’autres. Il est également ouvert aux acteurs voulant faire évoluer les systèmes d’autorisation et rendre les architectures plus sécurisées et interopérables.

Perspectives d’évolution d’autorisation : Event-time

Une nouvelle approche dans l’évolution des systèmes d’accès est l’event-time. Il se défini comme une implémentation de l’autorisation dynamique où les droits des accès sont ajustés en temps réel en réponse à des événements ou changements immédiats qui surviennent. Contrairement aux approches statiques ou basées sur des attributs, l’event-time se caractérise par une évaluation continue des droits d’accès, afin de s’assurer que tous les accès restent conformes aux politiques en place dans l’organisation.

Par exemple, lorsque l’état d’un utilisateur change (promotion, départ, mobilité, etc.), le système ajuste ou révoque automatiquement ses droits d’accès. Cette approche d’ajustement proactive basée sur des évènements est courante dans la surveillance des systèmes d’informations et la gestion des incidents de sécurité.

L’event-time repose sur des concepts clés qui sont :

• Les écouteurs (listeners), des composants du système surveillant les évènements en temps et analysant les changements importants (mobilité, promotions, départ, etc.) provenant de diverses sources notamment systèmes RH.
• Les déclencheurs (triggers), des actions en réponse à un événement identifié par un écouteur comme la révocation des droits d’accès au jour effectif de départ d’un utilisateur.
• Shared Signals (Signaux partagés), permettant à différents systèmes de partager des informations sur des événements en temps réel.
• L’évaluation continue est la vérification constante des droits d’accès pour s’assurer que chaque action ou accès reste en conformité avec les politiques.

Les frameworks et standards jouent un rôle clé dans l’implémentation de l’event-time en fournissant une structure pour la mise en œuvre les concepts dans les systèmes :

Le Shared Signals Framework (SSF) est directement lié au concept de shared signals, qui permet aux systèmes via une API de partager des informations sur les événements en temps réel pour assurer une gestion cohérente des accès. L’évaluation continue de ces informations est soutenue par le CAEP (Continuous Access Evaluation Protocol), un protocole permettant de standardiser l’écriture des changements de statut. Le RISC (Risk and Incident Sharing and Coordination) est un protocole générique qui lui permet la standardisation de la transmission et la réception des incidents de sécurité entre ces différents systèmes, renforçant ainsi la réactivité globale d’un système d’information.

L’event-time ne repose pas sur un modèle spécifique de type RBAC ou ABAC mais peut fonctionner comme une couche de gestion des accès complémentaires à ces systèmes d’accès traditionnels en les rendant plus dynamiques et alignés sur les situations en temps réel.

L’évolution des modèles d’autorisation, des approches traditionnelles aux méthodes modernes et dynamiques, reflète l’adaptation continue de l’IAM et des systèmes d’accès aux besoins croissants et changeants des organisations.

Les approches admin-time ont posé les bases de la sécurité des ressources avec des modèles tels que le DAC et le MAC. Le RBAC a introduit une gestion structurée des droits, largement adoptée dans les organisations aujourd’hui du fait de son application relativement simple.

Avec l’avènement du runtime, les décisions d’accès se sont affinées en s’appuyant sur des attributs spécifiques aux utilisateurs, aux ressources et au contexte, comme avec les modèles ABAC et GBAC. Cependant, ces modèles toujours plus sophistiqués ont conduit à l’apparition de nombreux éditeurs de solutions propriétaires, limitant l’interopérabilité des composants d’autorisation et créant une dépendance envers des technologies spécifiques. C’est ainsi qu’ont émergé des initiatives telles que le groupe de travail AuthZen œuvrant à l’élaboration de standards.

L’approche event-time apporte une réactivité en temps réel, permettant aux systèmes d’ajuster automatiquement les accès en réponse à des événements spécifiques. Le CAEP et le Shared Signals Framework facilitent cette dynamique en standardisant l’échange d’informations entre systèmes, renforçant ainsi la sécurité et la conformité.

Une vue d’ensemble de ces différentes approches et de leurs modèles associés est présentée dans la frise chronologique ci-dessous, accompagnée d’un tableau récapitulatif des différents modèles abordés. 

En combinant ces différentes approches, vous pouvez mettre en place une gestion des accès plus sécurisée, flexible et proactive, capable de répondre aux défis actuels et futurs liés à l’identité. Ces évolutions soulignent également l’importance d’adopter des solutions d’autorisation adaptatives et interopérables pour assurer une protection efficace des ressources tout en répondant aux exigences opérationnelles des équipes.

Ces évolutions posent une question essentielle sur la capacité des organisations à anticiper ces changements et intégrer ces nouvelles dynamique de la gestion de leur accès.

 Que vous utilisiez encore des modèles admin-time, exploriez des options runtime, ou envisagiez de passer à une gestion event-time, il est crucial de choisir un modèle qui répond à vos enjeux spécifiques. Il est aussi très important d’anticiper les conséquences sur la gestion dans le temps de ce modèle (revue de droits, mesure de la qualité des données, revue des politiques, définition des réactions attendues, etc.). 

Et vous quel type de modèle utilisez-vous ?  

N’hésitez pas à nous contacter pour en savoir plus et comprendre concrètement comment les appliquer en fonction du contexte de votre organisation !

[1] Habilitation de sécurité en France, Wikipédia (wikipedia.org)

Cet article Gestion des accès : comment l’autorisation évolue pour répondre aux défis et besoins des organisations ? est apparu en premier sur RiskInsight.

Afin d’accompagner cette évolution, l’Union européenne avait instauré la Directive sur les Services de Paiement. Dans sa deuxième version (DSP2), publiée en 2015, cette directive a voulu la création et la régulation du secteur de l’Open Banking. L’objectif était de permettre aux utilisateurs de laisser un accès à leurs données bancaires à de nouveaux acteurs innovants tels que les initiateurs de paiement et les agrégateurs, tout en favorisant la sécurité et la compétition au sein de l’écosystème des services de paiement.

Malheureusement, la DSP2 présente des limites dont :

• Un problème d’harmonisation des législations conduisant au « forum shopping » qui consiste, pour les fournisseurs de services de paiement, à choisir leur pays d’installation en fonction de la législation locale la plus arrangeante à leur égard.
• Un écart qui n’a pas été suffisamment comblé entre les banques, qui sont en position privilégiée pour fournir des services aux consommateurs, et les prestataires de services de paiement qui en dépendent.
• La fraude, pour laquelle les méthodes employées évoluent rapidement, et pour laquelle les provisions de DSP2 sont maintenant insuffisantes.

C’est pour cela que l’Union Européenne a publié un projet de DSP3 le 28 juin 2023, et une version finale est attendue pour fin 2024 ou début 2025. Le texte sera alors applicable 18 mois après la publication, soit aux alentours du troisième trimestre 2026.

Comment uniformiser l’existant de la DSP2 ?

A la lecture de cette ébauche, il est clair que là où la DSP2 a instauré des concepts structurants et complètement nouveaux comme l’Open Banking ou l’Authentification Forte du Client, la DSP3 cherche à apporter une mise à niveau sur des concepts existants. Comme indiqué sur le site de la commission européenne, il s’agit d’

« une évolution, pas une révolution ».

La forme évolue : la DSP3 s’accompagne d’un règlement, le RSP (Règlement sur les Services de Paiement). Dans son contenu, elle reprend beaucoup d’éléments présents dans la DSP2, ou ses RTS (pour Regulatory Technical Standards ou Normes Techniques de Règlementation). La nouveauté vient du format : il s’agit d’un règlement, qui est donc directement applicable dans les états membres, au contraire des directives qui ont besoin d’être traduites en droit local. Il s’agit d’une des solutions que l’UE considère pour aborder le problème d’harmonisation mentionné précédemment.

Le cadre réglementaire des monnaies électroniques se retrouve aussi simplifié. Les difficultés pratiques liées à la différenciation existante entre les paiements en ligne, réglementés par DSP2, et l’utilisation de monnaies électroniques, réglementée par la Directive sur les Monnaies Electroniques de 2009 (DME) disparaissent puisque DSP3 couvre maintenant ces deux types de services.

En outre, bien qu’il ne s’agisse pas de nouveautés à proprement parler, DSP3 apporte un lot de clarifications dans ses définitions :

• Les comptes de dépôt, tels que les livrets, sont explicitement exclus de la définition de comptes de paiements.
• Les agrégateurs sont définis par leur capacité à collecter et consolider de l’information sur les comptes de paiement, et ce même si l’utilisateur détenteur des comptes n’est pas le destinataire de l’information agrégée.
• Les authentifications multi-facteurs reposent sur deux facteurs dans les catégories classiquement définies (ce que je sais, ce que je suis, ce que je possède), mais il n’est pas nécessaire que les deux facteurs soient de catégories différentes, seulement qu’ils soient indépendants (défini comme : la compromission de l’un n’affecte pas le niveau de sécurité de l’autre).

Que devront faire les différents fournisseurs de services de paiement pour se conformer à la DSP3 ?

Les évolutions phares de la DSP3 portent sur des changements techniques visant protéger le consommateur contre la fraude.

Ainsi, les prestataires de services de paiement vont devoir proposer de nouveaux services. Un premier exemple consiste à fournir à l’utilisateur un tableau de bord de permissions permettant de vérifier à tout moment qui est autorisé à accéder aux données des comptes de paiement. Un autre exemple est le service de vérification du nom du détenteur du compte bénéficiaire d’un paiement, visant à informer l’utilisateur d’une éventuelle usurpation d’identité.

De même, la DSP3 s’intéresse à l’accessibilité pour tous de l’authentification forte. Toutes les banques devront avoir la capacité de fournir un moyen d’authentification adapté à tous leurs utilisateurs, y compris les personnes en situation d’handicap, les personnes âgées, les personnes ayant des faibles compétences numériques ou sans smartphone etc…

L’ajout d’un nouvel acteur en particulier va changer la répartition des responsabilités de conformité : il s’agit des prestataires de services techniques. Ces derniers hériteront d’une partie de la charge de mise en conformité et d’audit, en particulier pour ce qui touche à l’authentification forte du client, lorsque celle-ci est gérée par une solution tierce.

Quels seront les impacts de ces changements ?

Les banques et autres prestataires de paiement sont incités par les changements de la DSP3 à s’échanger des informations pour lutter contre la fraude : des dispositions sont d’ailleurs prévues pour pouvoir le faire dans le respect de la RGPD.

En particulier pour la vérification du nom du détenteur du compte bénéficiaire, cela signifie que les APIs d’Open Banking devront être mises à jour pour pouvoir permettre cette vérification par la banque du payeur. A cause de la complexité de cette opération, à plus forte raison pour les paiements instantanés, l’article associé entrera en vigueur 2 ans après le reste (donc pas avant le troisième trimestre 2028).

Les utilisateurs vont aussi voir apparaitre de nouvelles fonctionnalités, et un temps d’adaptation sera nécessaire pour qu’ils se familiarisent avec ces nouveautés. Un accompagnement devra être mis en place afin de faciliter la compréhension et favoriser l’adoption de ces nouvelles fonctionnalités.

Si le texte final est publié début 2025, les entreprises du secteur des paiements auront jusqu’au troisième trimestre 2026 pour se mettre en conformité.

Il est essentiel de prendre en compte ces changements dès aujourd’hui et d’assurer une veille réglementaire pour se tenir informé des différents textes (RTS, guidelines) qui seront publiés à la fois par la commission européenne et l’Autorité Bancaire Européenne.

[1] Rapport annuel de l’Observatoire de la sécurité des moyens de paiement 2023

Cet article Transition vers la 3e Directive sur les Services de Paiements : quels impacts ? est apparu en premier sur RiskInsight.

Cette tendance s’explique par une volonté de digitalisation des usines et de développement de l’industrie connectée, qui ne s’est que rarement accompagnée d’une modernisation des systèmes industriels associés : les attaques sont rendues plus simples, leurs conséquences plus fortes. Et dans le cas des ransomwares, un défaut d’authentification est souvent le point de départ de la kill-chain : trop faible ou reposant sur des facteurs d’authentification partagés entre opérateurs, les comptes en deviennent sensibles aux attaques par phishing.

Ce constat peut d’ailleurs être retrouvé en analysant les « Fiches incidents Cyber SI industriel »^[2]  partagées par le Clusif. On retrouve parmi elles la prise de contrôle du système de production d’une aciérie allemande, qui aurait pu être évitée si un second facteur d’authentification avait été requis lors de l’exécution d’actions critiques sur le site industriel.

Dès lors, le besoin de sécurisation et de modernisation des méthodes d’authentification des populations dites cols bleus apparait comme crucial, afin de limiter les risques de vols de ces comptes souvent mal protégés sans impacter négativement la productivité globale des opérateurs sur site.

Cet article vise donc, après être revenu plus en détail sur le contexte actuel et sur les contraintes liées à ces populations, à comparer les différentes solutions disponibles aujourd’hui pour ces usages, à analyser les freins à la démocratisation des méthodes jugées les plus prometteuses, et à partager notre vision et recommandations pour rattraper au mieux le retard observé.

Qu’est-ce que l’authentification ?

S’authentifier consiste à certifier son identité auprès d’un système informatique avant de pouvoir accéder à des ressources sécurisées. Tout au long de cet article, nous parlerons d’authentification multifacteur lorsqu’au moins deux facteurs d’authentification parmi les quatre ci-dessous sont combinés :

• Ce que je sais (mot de passe, code PIN, schéma, …)
• Ce que je possède (appareil personnel, clé USB, carte à puce, badge, …)
• Ce que je suis (reconnaissance faciale, empreinte digitale, réseau veineux, …)
• Ce que je fais (mouvement des yeux, signature, dynamique de frappe, …)

Note : le niveau de sécurité dépend de la robustesse des facteurs et de leur indépendance en cas de combinaison^[3] 

Les cols bleus : des cas d’usages diversifiés…

Quand on parle de population col bleu, on entend tous les travailleurs manuels, ne disposant pas de leur propre poste de travail professionnel (e.g. métiers de la mécanique, de l’industrie, de l’aide à la personne). Ces populations rencontrent des cas d’usages d’authentification différentes des populations dites cols blancs, car utilisant la majorité du temps un SI bureautique avec des appareils multiples et partagés entre différents collaborateurs :

• Postes mobiles et tablettes (accès aux logiciels de pilotage de production (MES), …)
• Postes fixe de contrôle (pilotage des machines-outils, gestion, …)
• Postes bureautiques partagés (pointage, formation, …)

Les opérateurs doivent donc pouvoir s’authentifier sur des postes de pilotage, par exemple directement reliés aux machines-outils à l’aide d’une carte réseau, mais aussi indépendamment de leur situation au sein du site sur des postes mobiles.

… Avec des contraintes multiples

Dans le but d’évaluer au mieux les différentes solutions d’authentification envisageables pour les cols bleus, il est important d’avoir à l’esprit les contraintes professionnelles qui leur sont propres.

Ces dernières se déclinent en trois volets principaux :

• Contraintes de rythme:  travailler sous cadence automatique et respecter des normes de production empêche l’utilisation de processus longs ou intempestifs
• Contraintes liées au port d’EPI (équipement de protection individuelle) tels que des gants ou un masque : ils peuvent empêcher l’utilisation de certains facteurs biométriques (reconnaissance faciale, empreinte digitale, …) ou rendre l’usage de mot de passe peu ergonomique (utilisation de gants sur écran tactile ou clavier)
• Contraintes liées à la régularité des changements de poste: changer régulièrement de poste implique de devoir s’authentifier quotidiennement plusieurs fois sur différents postes. De plus, si cette authentification est locale, l’enrôlement préalable devra être fait pour chacun d’entre eux

Au-delà des contraintes cols bleus, des éléments sont également à prendre en compte d’un point de vue employeur.

Nous retrouvons également trois thèmes principaux, à savoir :

• Un enjeu important d’uniformité: tous les collaborateurs devraient pouvoir s’authentifier de la même manière sur toutes les machines et logiciels afin d’avoir une expérience utilisateur commune, un unique processus, support et une seule documentation
• Un investissement non négligeable: une solution d’authentification est coûteuse à acquérir (e.g. badges, bracelets, capteurs) mais aussi à entretenir (e.g. support & serveurs). Ces couts pourront être difficiles à justifier si les employés n’ont pas besoin d’accéder à des ressources sensibles
• Une sécurité physique déjà présente: l’ajout d’un second facteur ou le durcissement du premier peut paraître inutile pour les entreprises qui sécurisent déjà physiquement leurs sites, et supposent donc qu’un individu ayant un accès physique à l’appareil sera digne de confiance

Quelles sont les méthodes d’authentification présentes sur le marché ?

Deux grandes catégories se distinguent :

• Des acteurs « matures », proposant une authentification multifacteur avec un badge couplé à un mot de passe ou à un code PIN stocké localement. Ce choix permet la fusion des accès physiques et logiques, en autorisant par exemple l’accès aux appareils contrôlant les chaines de production via badges d’accès intégrant le standard FIDO2
• Des acteurs qui le sont moins, conservant une authentification faible avec uniquement l’utilisation de mots de passe. Ils restent majoritaires, et les comptes utilisés sont souvent génériques afin de maximiser la rapidité de l’authentification, et donc la productivité

Quelles méthodes d’authentification pour répondre à ces enjeux ?

Plusieurs critères à prendre en considération…

Dans le but de comparer les différentes méthodes envisageables, six critères ont été considérés, avec un accent particulier sur deux enjeux principaux : l’expérience utilisateur et la sécurité.

… afin d’identifier les méthodes d’authentification les plus pertinentes

Sur la base de ces critères, les méthodes d’authentification considérées pertinentes et viables pour les cols bleus peuvent être distribuées comme ci-dessous :

Outre les solutions biométriques, fortement réglementées en France par la CNIL, la carte RFID/NFC (badge) émerge comme offrant la meilleure ergonomie pour un niveau de sécurité satisfaisant. Ceci est en adéquation avec ce qui a pu être observé chez les acteurs « matures » sur cette thématique.

Le badge est extrêmement ergonomique et présente un niveau de sécurité satisfaisant s’il est couplé à un code PIN ou un mot de passe dans le cadre d’une authentification à multi facteurs.

Pour la plupart des acteurs du monde industriel, cette solution est suffisante afin d’augmenter drastiquement la sécurité des accès des opérateurs, tout en restant simple d’utilisation. Si des badges pour les accès physiques sont déjà distribués, il est envisageable de les remplacer progressivement par des badges compatibles avec le standard FIDO2.

Néanmoins, dans des industries particulièrement sensibles où la sécurité est un enjeu critique, certaines solutions innovantes peuvent se démarquer :

La clé biométrique FIDO2  :

• Beaucoup de machines possèdent un port USB et le standard FIDO2 assure une compatibilité avec un grand nombre d’applications
• L’empreinte digitale remplace le code PIN et assure une certaine sécurité même en cas de vol ou de perte de la clé
• Aucune image biométrique n’est sauvegardée et aucun gabarit n’est stocké ailleurs que dans la clé

Le bracelet biométrique reposant également sur le protocole FIDO2 (exemple du bracelet « Nymi », non affilié avec Wavestone) :

• Chaque collaborateur reçoit un bracelet nominatif et s’enrôle avec son empreinte digitale
• Au début de la journée, chaque collaborateur met son bracelet et le déverrouille avec son empreinte digitale
• Tant que le collaborateur n’enlève pas son bracelet, il n’a qu’à le passer à côté des équipements équipés de capteurs NFC afin de s’authentifier avec le standard FIDO2
• Le bracelet est capable de détecter « le vivant » et se verrouille dès qu’il est enlevé
• Aucune image biométrique n’est sauvegardée et aucun gabarit n’est stocké ailleurs que dans le bracelet du collaborateur

Ces solutions sont coûteuses mais présentent un niveau de sécurité et d’ergonomie à l’état de l’art.

Une démocratisation freinée par plusieurs facteurs

Même si des solutions sont disponibles, il existe un retard en matière d’authentification des cols bleus, pouvant s’expliquer par différents freins à leur démocratisation :

• La sensibilité des accès logiques: celle-ci n’est pas toujours suffisante pour justifier des coûts engendrés par la modernisation et le renforcement de l’authentification
• Les priorités des attaquants: les SI de gestions et bureautiques restent les cibles prioritaires des attaquants, ce qui incite les entreprises à concentrer leurs efforts de sécurité sur ceux-ci
• L’obsolescence logiciels et de l’infrastructure: les machines et programmes utilisés sur les lignes de production peuvent être obsolètes. Les entreprises sont donc réticentes à remplacer ces ressources fonctionnelles au risque de se heurter à des problèmes de compatibilité
• La réglementation imposée : la CNIL ne favorise pas le développement des moyens d’authentification biométriques en France^[4] 

Cependant, la modernisation devrait s’accélérer grâce aux nouveaux besoins de sécurité
liés au développement de l’IoT. Le standard FIDO2 poursuit lui aussi sa popularisation, et il existe des solutions innovantes commençant à prendre de l’ampleur sur le marché. Il est enfin à noter que certains opérateurs sur ligne utilisent les mêmes ressources que les populations bureautiques, certaines solutions passwordless comme Windows Hello for Business sont donc envisageables et simples à mettre en place grâce aux capteurs intégrés aux appareils.

La convergence des accès logiques et physiques, la solution pour déclencher la démocratisation à large échelle ?

Les accès physiques des cols bleus sont bien souvent déjà sécurisés puisqu’il s’agit de populations exerçant sur des sites sensibles. Un système de badge est donc dans la plupart du temps déjà en place pour l’accès aux bâtiments et aux zones restreintes, avec sur les lieux les plus critiques, des lecteurs biométriques ou d’autres outils de surveillance (vidéosurveillance, …). Dès lors, la question de la capitalisation et centralisation du contrôle d’accès se pose, et proposer les mêmes moyens d’authentification pour les accès logiques que ceux déjà en place pour les accès physiques présenterait des avantages certains tout en faisant émerger de nouveaux enjeux :

• Une expérience utilisateur améliorée, un même processus pour tous les accès.
• Une gestion des autorisations simplifiée et renforcée.
• Une nécessité de coordonner les équipes chargées de la sécurité physique avec la DSI, de forts enjeux de gouvernance à anticiper.
• Une infrastructure commune à prévoir, tous les réseaux contrôlant les accès à connecter.

[1] Authentication Security Best Practices in the Manufacturing Industry, publié par Chris Collier sur le site HYPR

[2] Fiches Incidents Cyber Industriels, publiées par le Clusif

[3] Recommandations relatives à l’authentification multifacteur et aux mots de passe, publiées par l’ANSSI

[4] Le contrôle d’accès biométrique sur les lieux de travail, publié par la CNIL

Cet article L’authentification des populations cols bleus, un défi incontournable trop souvent négligé ? est apparu en premier sur RiskInsight.

La fraude s’est développée en même temps, devenant plus impactante et plus complexe. Selon la Banque de France, la fraude au paiement représente une perte de 1.2 milliards d’euros en 2022, une somme non-négligeable et qui n’est pas près de diminuer puisque les transactions frauduleuses ne cessent d’augmenter. Environ 70% de ces transactions frauduleuses proviennent de la banque en ligne.

La lutte contre la fraude est donc l’une des préoccupations les plus importantes pour la banque en ligne, mais d’autres secteurs commencent aussi à se pencher sur la question.

Fraude à l’identité, fraude métier

Le terme de fraude fait partie du langage courant et peut avoir des définitions très variées. Il est possible de « frauder » un ticket métro, une assurance, ou un compte fidélité chez un acteur de la grande distribution.

Quand il est question de fraude informatique, notamment bancaire, on distingue la fraude à l’identité et la fraude métier.

La première induit une manipulation des données d’identité de l’émetteur, de son contexte d’accès au service ou des informations en lien avec son authentification et autorisation. Il est possible de la détecter en analysant le comportement de l’utilisateur quand il s’authentifie, la machine qu’il utilise, l’IP depuis laquelle il se connecte, etc.

La seconde demande de manipuler des données en lien avec la transaction elle-même, le profil bancaire de l’émetteur et du récepteur, et le contexte de réalisation de la transaction. Des indicateurs de fraude métier pourraient être par exemple un IBAN récepteur venant d’un pays inhabituel, un montant de transaction important, etc.

Les deux types de fraudes et leur détection reposent sur des signaux différents mais ces deux mécanismes de protection peuvent et doivent échanger, s’alimenter l’une l’autre afin d’apporter une part de contexte supplémentaire et permettre une analyse plus holistique du risque.

Cette nécessité de synchronisation s’est traduite concrètement par un récent rapprochement organisationnel entre les équipes de lutte contre la fraude métier et les équipes IAM.

Quels risques sont couverts par la détection de la fraude à l’identité ?

Derrière la fraude à l’identité se cachent de nombreux cas d’usage différents. La détecter permet donc de couvrir des risques variés qui aujourd’hui sont difficiles à appréhender. Voilà une liste non exhaustive de techniques utilisées par les attaquants qui pourraient être détectées par un outil anti-fraude :

• SIM swapping : le SIM swapping demande de convaincre le fournisseur téléphonique de la victime d’envoyer une nouvelle carte SIM à l’attaquant, qui pourra ensuite valider des demandes de double authentification via OTP en se faisant passer pour la victime.
• MFA fatigue : la MFA fatigue consiste à envoyer un grand nombre de notifications de validation MFA, au point que la victime finisse par accepter la demande et autoriser l’accès à l’un de ses comptes par inadvertance.
• Social engineering : le social engineering est utilisé lors d’attaques ciblées sur un individu, l’attaquant recueille des informations sur lui et sur son compte bancaire, puis les exploite pour lui soutirer de l’argent. Un exemple de plus en plus fréquent est celui des fraudes au conseiller bancaire, un attaquant se faisant passer pour le conseiller de la victime et la poussant à effectuer un virement, souvent en prétextant un risque de… fraude.
• Bots : l’automatisation des attaques ouvre de nouvelles possibilités pour les attaquants, ces derniers pouvant cibler un grand nombre de comptes au cours d’une seule campagne. En émulant des appareils ou en lançant des campagnes de phishing massives, il devient de plus en plus simple de récupérer des informations personnelles et des mots de passe.

Les banques en tête de proue, mais rejointes par de nouveaux acteurs

Sans surprise, le secteur bancaire a une longueur d’avance sur ces questions. Premièrement parce que l’impact de la fraude est très concret et la banque est une cible privilégiée. Ensuite parce que les utilisateurs sont habitués, voire rassurés, de constater des processus de sécurité important au détriment de leur expérience utilisateur. Enfin parce que le passage massif à la banque en ligne a soulevé des questions que d’autres secteurs n’ont pas eu à se poser immédiatement.

Aujourd’hui, la détection de la fraude pour une banque en ligne se concentre sur trois étapes clés du parcours utilisateur :

• L’enrôlement d’un nouvel appareil
• La validation d’un paiement
• La réalisation d’actions sensibles sur le compte, comme l’ajout d’un bénéficiaire pour les virements

Si le secteur bancaire est indubitablement le plus touché et le plus protégé, d’autres secteurs commencent à se pencher sur la question de la détection de la fraude. C’est le cas de la grande distribution et de l’e-commerce par exemple, ainsi que du luxe qui se trouvent dans la ligne de mire des attaquants. Cela les force à imaginer de nouveaux processus et à investir dans la lutte contre la fraude, faisant à leur tour évoluer les solutions et pratiques pour limiter les impacts sur le business.

De nouvelles avancées technologiques : protocoles et algorithmes

La pression des attaques explique en grande partie l’intérêt dans les solutions de détection de la fraude. Ces dernières se sont développées rapidement, embarquant de plus en plus de fonctionnalités et démontrant une capacité grandissante de lutte contre les attaques complexes qui se développent.

Les récentes avancées technologiques liées à la détection de la fraude sont multiples, mais deux principaux mécanismes ont rendu ces solutions plus puissantes : la capacité à échanger des informations entre les briques de détection, et la précision des algorithmes d’estimation du risque.

Le premier mécanisme est un produit de la tendance actuelle à la standardisation des protocoles et des signaux de détection, permettant aux différentes briques du SI de mettre en commun les informations récoltées et les réactions appropriées. Le groupe de travail Shared Signals (Okta, Cisco, Disney, fondation OpenID, etc.) a par exemple produit un framework utilisé dans deux protocoles : Continuous Access Evaluation Protocol (CAEP) et Risk Incident Sharing and Coordination protocol (RISC).

Le deuxième mécanisme ; la précision des algorithmes ; repose sur le nombre grandissant de critères pouvant être exploités. Il y a quelques années, un moteur de détection se reposait sur l’analyse de l’IP, la géolocalisation et quelques attributs de l’identité. Aujourd’hui, les critères sont démultipliés, incluant le comportement propre à l’utilisateur (les mouvements de souris, la vitesse de frappe), l’analyse des appareils utilisés (modèle, OS, navigateur), l’historique du compte, les parcours utilisateurs usuels, ainsi qu’une panoplie de signaux faibles provenant d’autres applications ou de briques du SI. Cette multiplication des signaux entrants dans les algorithmes permet une analyse bien plus fine de chaque transaction et une estimation du risque toujours plus pertinente.

IA et orchestration au service de la lutte contre la fraude

Augmenter le nombre de critères permet d’améliorer les algorithmes, mais pour tirer le meilleur de ces informations il est essentiel de tirer profit des capacités du Machine Learning et de l’intelligence artificielle. Chaque critère devient une dimension permettant à l’intelligence artificielle d’apprendre de manière dynamique les comportements des utilisateurs (comme les parcours usuels, les emplacements des clics de souris ou la vitesse de frappe) et ce qui constitue un contexte d’accès normal et non risqué afin de mieux détecter tout ce qui en dévie.

Malgré la capacité de l’IA à produire une décision à partir d’un nombre très important de paramètres, elle demeure victime des déboires de tous les algorithmes de décision : les faux positifs. Et avec l’intérêt de nouveaux secteurs, qui se doivent d’équilibrer sécurité et expérience utilisateur pour limiter les impacts négatifs sur le business, la gestion des faux positifs est une question à part entière pour les éditeurs. Aujourd’hui, les modèles de détection peuvent être ajustés de plusieurs manières : en les entraînants de manière récurrente, pour les adapter aux nouveaux cas d’usages ; en jouant avec les poids des critères, selon le contexte du client ; et en revenant sur les décisions prises par l’algorithme afin de signaler les faux positifs.

Au-delà de ces ajustements, les solutions de détection de la fraude offrent une grande flexibilité au niveau de l’orchestration, c’est-à-dire au niveau de la réaction à mettre en œuvre vis-à-vis des recommandations de l’algorithme. Il est ainsi possible de limiter l’impact pour les utilisateurs, en utilisant des challenges invisibles pour les risques faibles et en limitant les demandes contraignantes comme la MFA ou le traitement manuel différé aux transactions très risquées. L’orchestration permet aussi d’effectuer une mise en place progressive de l’outil : les réactions peuvent se limiter à une levée d’alerte transmises à un outil SIEM par exemple afin d’affiner l’algorithme, puis un passage à du blocage effectif et en temps réel.

Conclusion

La lutte contre la fraude, est un sujet qui concerne de nombreux secteurs. Si le secteur bancaire est en avance et que ceux du e-commerce et du luxe suivent, toute organisation peut être ciblée par la fraude. Cela implique une pluralité des cas d’usage et des problématiques auxquels les solutions de détection de la fraude peuvent souvent mais pas toujours répondre.

Le secteur d’activité, le contexte, la récurrence et le type d’attaques, l’impact et le risque associé, ainsi que les moyens pouvant être débloqués, toutes ces dimensions doivent être prises en compte pour contextualiser les solutions de lutte. Ces solutions peuvent être chères ou inadaptées malgré les mécanismes innovants mis en place et d’autres mécanismes de remédiation peuvent être envisagés selon les contextes.

C’est le cas des solutions anti-bots par exemple, ou des mécanismes de risk based authentication, ou encore tout simplement la refonte de certains processus métier pour les rendre intrinsèquement plus résilients à la fraude. Ces remédiations peuvent accompagner une solution de détection de la fraude, ou suffire à contrer les cas de fraude observés dans le contexte étudié.

Cet article La lutte contre la fraude : un nouvel enjeu pour l’identité numérique ? est apparu en premier sur RiskInsight.

Aussi, malgré de belles réussites et le rôle cardinal de l’identité dans les transformations des entreprises, l’IAM demeure une thématique dénigrée dans les organisations, synonyme de « mal nécessaire » plutôt que « d’enjeu clé » pour l’entreprise.

Comment redorer le blason de l’IAM ? Comment mieux l’expliquer pour lui donner sa juste place dans l’entreprise ?

Le paradoxe de l’identité

Un moteur essentiel des programmes de transformation…

Cette situation est paradoxale tant l’identité joue un rôle fondamental dans les programmes de transformation actuels, en présentant trois atouts majeurs.

• Elle est tout d’abord un pilier de la cybersécurité en permettant de :
  • Disposer d’une connaissance homogène de l’ensemble des utilisateurs, en centralisant les informations essentielles comme le nom, le manager, la fonction et bien d’autres caractéristiques propres à chacun ;
  • Garantir l’unicité des personnes via la publication d’un référentiel unique ;
  • Contrôler et adapter les accès des utilisateurs tout au long de leur cycle de vie ;
  • S’inscrire dans une démarche Zero Trust en veillant à ce que seules les bonnes personnes, avec le bon niveau de droit et le bon niveau d’authentification accèdent aux ressources appropriées.
• Elle constitue également un facilitateur métier essentiel, notamment pour :
  • Accélérer l’adoption de service Cloud, et le déploiement de nouvelles applications grâce à la création automatique de comptes et l’attribution simplifiée des droits (souvent par le biais d’un outil IGA – Identity Governance & Administration) ;
  • Faciliter l’ouverture contrôlée du SI à et vers des tiers : des partenaires, des fournisseurs ou en cas de création de Joint Ventures ;
  • Améliorer, grâce au CIAM (Customer Identity and Access Management), la relation client et la mise en conformité réglementaire en simplifiant la création progressive des comptes et le respect des règlements sur la vie privée tels que la RGPD en France.
• Enfin, avoir une gestion des identités efficiente est une condition sine qua none pour offrir une expérience utilisateur à l’état de l’art, combinant confort et exigences de sécurité :
  • Un accès fluide et sans couture à toutes ses applications et ses données, quel que soit son contexte d’accès ;
  • Des droits d’accès accordés automatiquement et disponibles le jour de son arrivée ;
  • D’un portail unique pour effectuer et suivre ses demandes ad hoc.
  • Des tableaux de bord parlants et des campagnes de revues ciblées pour répondre aux exigences réglementaires sans sur-solliciter les managers et les process owners.

… mais une thématique injustement considérée

Malgré les avantages significatifs qu’elle représente, la thématique de l’identité est rarement au centre des préoccupations des entreprises. Elle est plutôt perçue comme un mal nécessaire, voire occupe une place de « vilain petit canard ». Ainsi, il est commun de constater les écueils lorsque l’identité est insuffisamment bien gérée, et encore plus courant de considérer comme normaux et acquis les avantages qu’elle produit.

Au-delà du simple constant, il convient de comprendre les raisons qui ont mené à cette situation de manque d’investissements, de sponsoring, voire de reconnaissance.

Première explication du paradoxe : la dispersion des gains attendus vers différents bénéficiaires. En effet, l’IAM est, par nature, très transverse dans l’entreprise. Pour réussir, elle se doit d’embrasser un large panel de sujets et mobilise donc de nombreuses parties prenantes. Si chacune d’elles y verra des gains ; aucune ne se démarquera suffisamment pour endosser la responsabilité première. À titre d’exemples :

• L’identité permet de simplifier la mise en relation client, sujet d’intérêt majeur pour un responsable marketing/digital, mais pas pour le responsable conformité.
• Ce dernier verra dans l’identité un avantage significatif pour répondre aux exigences des commissaires aux comptes en matière de revue des accès.
• Le DSI attendra de l’identité une gestion homogène et automatique de l’attribution des comptes et des droits, synonymes de gains financiers, notamment en coûts de licences, en charge de support, etc.
• Quant au RSSI, sa priorité sera de supprimer les accès en cas de départ et d’appliquer le principe de « moindre droits attribués » ou encore la détection au plus tôt des comportements « suspects ».

Deuxième explication : comme toute transformation, qui plus est transverse, le lancement et la réussite d’un projet d’identité sont conditionnés par des prérequis indispensables.

La difficulté et l’effort nécessaire pour réunir ces prérequis dépendent du contexte de chaque entreprise ; mais les prérequis eux-mêmes sont relativement constants et peuvent s’articuler autour de 4 axes :

• La qualité des données : aussi bien pour les données consommées par l’IAM (organisations, structures, données d’identité provenant des RH…) que pour les données que l’IAM doit mettre à disposition (identifiants des comptes applicatifs, attributs dans les applications…).
• La connaissance profonde des processus de bout-en-bout : celle-ci est indispensable pour prévoir les impacts sur les utilisateurs des changements à venir mais surtout pour être en capacité de changer et d’harmoniser les manières de faire et ne pas reconduire l’existant « parce que l’on a toujours fait ainsi ».
• La maîtrise des applications à raccorder : il est nécessaire de mobiliser à la fois des sachants techniques (technologies utilisées, API disponibles…) et des sachants fonctionnels (populations utilisatrices, modèle de données, modèle d’habilitation…).
• Enfin et surtout, la capacité à imposer un cadre IAM « normatif », à trouver un compromis et à arbitrer tant sur la cible (modèle opérationnel, cadre fonctionnel, attributs et règles de gestion, processus d’arrivée/mobilité/départ, cadre de raccordement normé pour les applications…) que sur la trajectoire et les indicateurs de réussite (priorités, lotissement…). Pour le dire en une phrase « Ce n’est pas à l’IAM de panser ce qui a été mal pensé ou ce qui est devenu inadapté avec le temps».

Troisième et dernière explication : une gestion complète de l’identité repose sur plusieurs briques technologiques complémentaires. Avec des origines variées et des dénominations quelque peu ambigües, il n’est pas toujours facile pour un non-expert du domaine de comprendre précisément l’apport en propre de chacune de ces briques :

• IGA – Identity Governance & Administration: Gouvernance des identités
• IAI – Identity Analytics & Intelligence : Analyse et contrôle des données
• PAM – Privileged Access Management: Gestion des comptes à privilèges
• AM – Access Management: Authentification et contrôle d’accès
• CIAM – Customer Identity & Access Management: Gestion des identités clients

De plus, ces dénominations ont évolué dans le temps, parfois de manière légitime pour rendre compte d’évolutions majeures, parfois plutôt sous l’effet d’éditeurs souhaitant démarquer leur proposition de valeur. L’apparition de nouvelles fonctionnalités (détection temps réel, gestion du consentement, etc.) et les innovations proposées par les éditeurs font également évoluer le champ lexical de l’IAM.

Comment donner à l’identité sa juste place dans l’entreprise ?

Pour surmonter ce paradoxe, les pistes usuelles (sponsor de haut niveau, plus de moyens, évangélisation…) sont nécessaires mais souvent insuffisantes. Des transformations plus structurantes s’imposent.

Unifier les forces de l’identité sous une même bannière

Les thématiques IAM sont apparues en ordre dispersées dans les entreprises et ont muries à des rythmes très différents. Il en résulte que, encore trop souvent, les équipes sont isolées.

Il est donc impératif de rapprocher toutes les équipes et les budgets traitant de l’identité sous une même barrière. Et si l’union fait la force comme dit le proverbe, l’objectif n’est pas uniquement de « faire nombre » pour être visible, légitime et avoir voix au chapitre dans l’organisation.

Les synergies sont en effet nombreuses :

• Faire de l’identité un sujet pérenne et récurrent, a minima au niveau du CoDIR DSI, et dans toutes les évolutions de l’entreprise.
• Définir une proposition de valeur globale, proposer une offre unifiée plus lisible pour les métiers et les responsables applicatifs qui pourront s’appuyer sur un interlocuteur unique.
• S’inscrire dans la durée pour tirer parti des feuilles de route des éditeurs, créer une démarche d’amélioration continue et se préparer aux évolutions à venir de l’entreprise : réorganisations, fusions-acquisitions, nouvel ERP…
• Améliorer la cohérence des services IAM et se piloter avec des indicateurs de service de bout-en-bout.
• Garantir un haut niveau d’expertise en valorisant les savoir-faire des équipes, en les fidélisant et en offrant des perceptives d’évolution plus riches.

Cette transformation profonde peut apparaître comme délicate et source de risques pour les entreprises les moins matures en IAM. C’est pourquoi il est possible de l’initier progressivement, en partant d’un des axes suivants :

• Rapprocher sous une même organisation les équipes travaillant sur les différentes thématiques IAM : IGA, IAI, AM, PAM et même CIAM.
• Unifier les équipes en charge des projets et celles en charge du « RUN » afin de proposer une approche « produit » de chaque service d’identité, et s’inscrire dans une logique d’amélioration continue.
• Étendre la responsabilité des équipes IAM sur le contrôle des données enfin de pouvoir s’engager sur des indicateurs et, au final, sur la qualité du service rendu et perçu.

Sur ce dernier point, précisons néanmoins que les équipes IAM ne peuvent endosser la responsabilité de la qualité des données et des référentiels de l’entreprise. Il s’agira néanmoins de garantir la qualité du service rendu en s’assurant à la fois du bon fonctionnement des services IAM (le « contenant ») et de la qualité des données manipulées (le « contenu »). Ainsi, les équipes IAM doivent s’outiller et s’organiser pour superviser, contrôler et alerter la qualité des données reçues comme l’usage qui en est fait.

Une unification avantageuse mais qui oblige

Cette ambition d’unification, qui met l’IAM en pleine lumière, oblige de facto le responsable Identité à être exemplaire dans son rôle et ses responsabilités :

• Face à ses clients: disposer d’une offre de service claire, tenir compte des retours et des réalités du terrain, définir et respecter une feuille de route d’évolutions, fournir des indicateurs de qualité du service rendu « parlants » c’est-à-dire ayant un sens dans le quotidien des métiers, valoriser les gains et les bénéfices…
• Vis-à-vis des autres parties prenantes dans l’entreprise (RH, Achats, Cybersécurité, Conformité réglementaire, Audit et contrôle…) : communiquer, matérialiser et aider à l’appropriation de la proposition de valeur de l’Identité au quotidien et lors de transformations structurantes (réorganisations, acquisitions…), trouver des voies de compromis, monter le caractère « gagnant-gagnant » des évolutions de processus et de modèle opérationnel, partager les rôles et responsabilités de chacun, illustrer les impacts en cas de manquements…
• Pour ses équipes: disposer d’un modèle opérationnel robuste, équilibrer les responsabilités entre collaborateurs internes et prestataires externes, construire une véritable ambition RH à moyen et long terme (validation de l’expertise, gestion des talents, construction de parcours d’évolutions, valorisation de la filière IAM…).

Conclusion

L’unification des services IAM est une tendance de fond et, d’ici 3 ans, une large majorité des grandes entreprises aura convergé vers ce modèle, a minima partiellement.

Ce mouvement ne résulte pas toujours d’une volonté de repositionner de manière durable l’identité dans l’organisation. Il est parfois subi par les équipes pour pallier des manques de ressources, d’expertise ou dans un espoir de maîtrise des coûts ; renforçant dans ce cas le sentiment de manque de considération.

Pourtant, les opportunités sont nombreuses pour démontrer la nécessité de repenser en profondeur son ambition IAM et de lui donner sa juste place : obsolescence technique des outils IAM, stratégie d’entreprise pour basculer vers des solutions Cloud, difficultés à accompagner les transformations structurantes de l’organisation, nouvelles exigences réglementaires, ou résultats d’une simple enquête de satisfaction auprès des utilisateurs ou des responsables d’applications…

Oserez-vous les saisir ?

Cet article Comment donner à l’identité sa juste place dans l’entreprise est apparu en premier sur RiskInsight.

L’identité numérique régalienne regroupe toutes les informations essentielles pour authentifier formellement un individu ou une organisation dans le monde numérique. Cela inclut les données d’identification personnelles, les certificats électroniques et les informations biométriques. Cette identité est cruciale pour sécuriser les transactions électroniques, faciliter l’accès aux services publics en ligne et protéger les droits et la vie privée des citoyens.

En France, un programme a été lancé en 2018 pour créer une identité régalienne numérique de garantie élevée. Parallèlement, la France s’engage dans la mise en place d’une carte d’identité à puce, qui constituera la base de cette identification électronique. Ce mode d’authentification sera intégré à FranceConnect+ créé à la fin de 2021, un service en ligne d’identification et d’authentification de niveau substantiel minimum.

Exemples de cas d’usage en fonction de la cible :

Entreprises

Un cas d’usage B2E potentiel pourrait-être le réenrôlement et de la récupération d’accès. L’utilisation de l’identité numérique régalienne devient particulièrement pertinente dans les entreprises ou l’authentification des employés repose exclusivement sur des passkeys FIDO liées à un appareil, souvent leur téléphone. En cas de perte de ce dispositif, l’employé se trouve dans l’incapacité de s’authentifier. Grâce à l’identité numérique régalienne, la récupération d’accès devient simplifiée. L’employé peut utiliser son identité numérique pour restaurer ses accès, puis récupérer un nouveau téléphone et réenrôler ses passkeys FIDO. Ainsi, le processus de réenrôlement et de récupération d’accès est grandement facilité, garantissant une continuité de service accrue.  

Côté CIAM, les banques pourraient utiliser l’identité numérique régalienne pour vérifier l’identité des clients lors de l’ouverture de comptes en ligne ou lors de transactions sensibles et améliorer ainsi le niveau de sécurité de leur service et leur processus KYC (know Your Client). Actuellement en France, les clients peuvent utiliser FranceConnect pour s’authentifier auprès de banques telles que BNP Paribas lors de l’ouverture de comptes en ligne, garantissant une vérification d’identité sécurisée et simplifiée. De la même manière des sites de commerce en ligne pourraient utiliser l’identité numérique régalienne pour permettre aux utilisateurs de s’authentifier de manière sécurisée lors de l’achat de produits, renforçant encore la sécurité et réduisant les risques de fraude.

Dans le contexte de l’entreprise étendue (mode d’organisation permettant la collaboration entre une entreprise, ses filiales et ses partenaires), l’enrôlement sécurisé des partenaires pour accéder aux systèmes d’information (SI) de l’entreprise est crucial. Le défi consiste à augmenter le niveau de confiance de l’enrôlement tout en le facilitant.

L’utilisation du portefeuille d’identité européen ou autre wallet d’identité pourrait significativement simplifier et sécuriser ce processus. Les employés des partenaires pourraient prouver leur identité auprès de l’entreprise avec laquelle ils souhaitent collaborer en utilisant leur wallet d’identité. Voici comment cela pourrait fonctionner :

Premièrement l’enregistrement initial, les employés des organisations partenaires utilisent leur portefeuille d’identité pour s’enregistrer auprès du système de l’entreprise principale. On procède alors à la vérification de l’identité grâce à des certificats électroniques et autres informations sécurisées.

Une fois l’enregistrement validé, ces employés peuvent accéder aux systèmes d’information de l’entreprise principale. Le wallet d’identité permet une authentification sécurisée et conforme aux normes de sécurité de l’entreprise. Ou un enrôlement sécurisé à des moyens d’authentification locaux de l’entreprise.

Le wallet d’identité peut également être utilisé pour gérer et moduler les droits d’accès en fonction des rôles et des besoins spécifiques des employés partenaires, réduisant ainsi le risque de sur-approvisionnement et augmentant la sécurité.

Si les informations d’identité changent (par exemple, si un employé change de poste ou de responsabilité), la mise à jour des accès peut être effectuée de manière fluide via le portefeuille d’identité, sans nécessiter de processus administratifs lourds.

Imaginons une entreprise de construction collaborant avec divers sous-traitants pour différents projets. Les employés des sous-traitants peuvent utiliser leur portefeuille d’identité pour s’authentifier et accéder aux plans et documents de projet hébergés dans le SI de l’entreprise principale. Cela garantit que seuls les employés autorisés et vérifiés ont accès aux informations sensibles, et que leurs accès peuvent être rapidement modifiés ou révoqués en cas de besoin.

Citoyens

L’identité numérique régalienne offre aux citoyens de nombreux avantages, notamment en simplifiant l’accès à divers services en ligne et en renforçant la sécurité des transactions numériques. En France, par exemple, les assurés sociaux peuvent utiliser leur identité numérique via le service Ameli pour accéder à leur espace personnel. Cela leur permet de consulter leurs remboursements, de prendre rendez-vous avec des professionnels de santé et de gérer d’autres aspects de leur couverture médicale en ligne de manière sécurisée.

De même, pour les démarches fiscales, les citoyens français peuvent utiliser leur identité numérique régalienne via le site impots.gouv.fr. Cette fonctionnalité facilite la déclaration fiscale en ligne, permettant aux utilisateurs de remplir leurs déclarations, de consulter leurs avis d’imposition et de suivre leurs paiements et remboursements de manière simple et sécurisée.

Au-delà de la France, d’autres pays européens mettent également en œuvre des solutions d’identité numérique pour améliorer l’accès aux services publics. Par exemple, les étudiants pourront bénéficier grandement de l’identité numérique régalienne pour leurs démarches administratives. Ils pourront l’utiliser pour s’inscrire à des universités, accéder à leurs relevés de notes, et gérer leurs comptes étudiants de manière sécurisée et simplifiée. De plus, les étudiants internationaux pourront également utiliser cette identité pour valider leur statut de résidence et accéder à divers services publics et académiques sans le tracas des procédures papier.

En Espagne, l’identité numérique régalienne permet aux citoyens de signer électroniquement des documents officiels via le service FirmaDigital.gob.es. Cette solution est utilisée pour des tâches telles que la signature de contrats de location, la soumission de documents administratifs, et d’autres procédures nécessitant une signature légale. Cela rend les processus administratifs plus efficaces et sécurisés, en éliminant la nécessité de signatures physiques et en réduisant le risque de fraude.

Le portefeuille d’identité européen (EUDI)

Le portefeuille d’identité européen (EUDI Wallet) est une initiative majeure de la Commission Européenne visant à fournir aux citoyens de l’Union européenne un moyen sûr et interopérable de gérer leur identité numérique à travers les frontières. Conçu pour offrir une solution pratique et sécurisée, l’EUDI Wallet permettra aux citoyens de stocker et de partager leurs informations d’identification électronique de manière transparente, tout en préservant leur vie privée et en respectant les normes strictes de protection des données de l’UE.

Ce concept émerge dans le contexte de la numérisation croissante de la société européenne et de la nécessité de renforcer la confiance dans les transactions en ligne. Avec la diversité des systèmes d’identification électronique utilisés à travers l’UE, l’EUDI Wallet vise à harmoniser ces systèmes et à faciliter l’accès aux services numériques transfrontaliers, tels que les services publics, les transactions commerciales et les interactions en ligne avec les entreprises.

L’EUDI Wallet fonctionnera donc comme un portefeuille numérique sécurisé où les citoyens pourront stocker leurs informations d’identification telles que les certificats électroniques, les données biométriques et les documents d’identité. Ils pourront utiliser ce portefeuille pour s’authentifier en ligne et accéder à une gamme de services numériques à travers l’Union européenne.

Avec l’EUDI Wallet, les citoyens pourront accéder facilement à leurs données de santé, comme leur résumé de patient et leurs ordonnances électroniques, n’importe où dans l’UE, favorisant une meilleure continuité des soins. De plus, le wallet permettra de gérer et vérifier les diplômes et qualifications professionnelles de manière sécurisée, simplifiant ainsi la reconnaissance des qualifications et favorisant la mobilité des travailleurs. Enfin, il facilitera les transactions en ligne en assurant une authentification forte et harmonisée, renforçant ainsi la confiance dans le commerce électronique transfrontalier.

Afin de procéder à ces cas d’utilisations, la Commission Européenne a défini deux scénarios principaux décrivant très basiquement les flux d’utilisations du portefeuille ;

À ce jour, les pays de l’Union Européenne ont convenu du contenu à inclure dans le wallet européen et se sont accordés sur un standard global pour le projet, avec une date de mise en œuvre cible en 2026. Ce qui reste à accomplir comprend la finalisation du standard, l’élaboration des spécifications techniques précises de ce standard, ainsi que le développement des solutions techniques devant être mises en œuvre dans chaque pays européen pour assurer leur compatibilité avec le standard établi.

Conclusion

L’introduction du portefeuille d’identité européen (EUDI Wallet) représente une étape cruciale vers une Europe numérique plus intégrée et numérisée, offrant de nombreux avantages aux citoyens et aux entreprises à travers l’Union Européenne. En France, l’adoption de l’EUDI Wallet dépendra de plusieurs facteurs clés. Tout d’abord la mise en place d’un cadre réglementaire solide et conforme aux normes de protection des données telles que le RGPD sera essentielle pour assurer la confiance des utilisateurs et la sécurité de leurs données personnelles. De plus, la confiance du public dans la sécurité et la fiabilité de l’EUDI Wallet jouera un rôle déterminant dans son adoption généralisée. Des campagnes de sensibilisation et d’éducation du public sur les avantages et les mesures de sécurité de l’EUDI Wallet pourraient contribuer à renforcer cette confiance.

Cependant, l’élément le plus important pour l’EUDI Wallet sera le taux d’adoption par les services privés. L’implication des entreprises privées est cruciale car elles fournissent une grande partie des services utilisés quotidiennement par les citoyens. Une adoption généralisée par les secteurs bancaires, de la santé, de l’éducation, et d’autres services privés, assurerait une utilisation plus large et régulière du wallet, rendant son intégration plus fluide et naturelle pour les utilisateurs.

La technologie reste émergente et n’est pas encore assez mature pour être mise en place immédiatement. Toutefois, compte tenu des nombreux bénéfices potentiels, il est crucial de suivre de près cette technologie et de l’adopter dès que possible. Cela est particulièrement vrai pour le secteur bancaire et les cas d’usages de l’entreprise étendue, où l’EUDI Wallet pourrait apporter des améliorations significatives en matière de sécurité, de fluidité des transactions et d’efficacité opérationnelle.

Néanmoins, en surmontant ces obstacles et en tirant parti des opportunités offertes par l’EUDI Wallet, la France pourrait jouer un rôle de leader dans la construction d’une Europe numérique plus sûre, plus innovante et plus connectée pour les années à venir.

Cet article Le portefeuille d’identité européen, l’identité régalienne numérique bientôt dans nos poches est apparu en premier sur RiskInsight.

Qu’est-ce que l’entreprise étendue ?

L’entreprise étendue est un ensemble d’entités et d’acteurs économiques associés pour la réalisation de projets communs. Les entreprises ont toujours eu besoin de collaborer entre elles en partageant des ressources et en échangeant des données. Pour ce faire, les collaborateurs de chacune de ces entreprises doivent pouvoir interagir en toute sécurité avec des utilisateurs externes.
Ces utilisateurs externes peuvent être des fournisseurs, des sous-traitants, des clients B2B, des filiales qui ne partagent pas le même SI, etc. La collaboration peut prendre différentes formes et peut ou non être limitée dans le temps.
Du fait de cette diversité de cas figures, il n’est pas possible ni pertinent de définir une réponse unique à tout projet IAM pour l’entreprise étendue. La stratégie à adopter par tout entreprise voulant adresser ce sujet va dépendre de son contexte propre et de ces cas d’usage spécifiques.
Une stratégie IAM entreprise étendue pourra être initiée en répondant à deux questions primordiales : quel mode de gouvernance IAM et de délégation cible avec les différents partenaires ? Et quel type de solution du marché couvre le mieux ses cas d’usage ?

Quelle mode de gouvernance ?

4 grandes approches de gouvernance IAM peuvent être envisagées en entreprise étendue, le choix d’une de ces approches va dépendre principalement de deux critères : le niveau de maturité IAM des différentes parties-prenantes et le niveau de sensibilité des ressources accédées.

Quelle solution éditeur ?

Un certain nombre de fonctionnalités distinguent clairement les solutions éditeur CIAM (périmètre client) des solutions Workforce IAM (périmètre employés). Ces deux types de solutions se situent aux extrémités opposées du spectre par rapport aux critères analysés dans le diagramme ci-dessous.

Les cas d’usage entreprise étendue (B2B) peuvent être positionnés sur une large gamme de ce spectre pour chaque critère selon les contextes. Il est donc difficile d’y répondre avec des solutions classiques workforce IAM ou CIAM mais de plus en plus d’éditeurs proposent de nouveaux modules dédiés pour répondre à ces nouveaux besoins.

Quelles nouvelles technologies pour faciliter la mise en œuvre ?

Un des facteurs clés de réussite d’un projet Entreprise Etendue réside dans la capacité de décentralisation des process et mécanismes IAM. Les avancées technologiques présentées dans le tableau ci-dessous permettent de repenser les approches traditionnelles de gestion des identités et des accès sous cet angle. Elles offrent des solutions plus flexibles, adaptées à la diversité des cas d’usage rencontrés, en permettant donc plus de décentralisation, notamment avec des partenaires peu matures grâces aux wallets d’identité et au passkeys:

Dans cette quête de solutions adaptées à la pluralité des use cases, il est impératif de rester à l’affût des développements du marché et d’évaluer en permanence la pertinence des solutions proposées par rapport aux besoins spécifiques de chaque contexte.

Cet article Quel IAM pour l’entreprise étendue ? est apparu en premier sur RiskInsight.

Fort de son expérience sur le sujet de l’identité numérique, Wavestone publie en 2024 sa première édition du radar du CIdO. Ce radar suit la même méthodologie que le radar du RSSI publié depuis 10 ans par le cabinet, et propose un zoom sur les tendances de fond qui animent l’écosystème de l’identité numérique.

Nous vous proposons dans cet article de (re)découvrir quelques sujets impactants et structurants pour le paysage IAM (Identity and Access Management) en en partant de deux sujets ayant le vent en poupe actuellement (passwordless et CLM) pour ensuite se diriger vers les sujets futurs qu’ils laissent entrevoir, dans la partie émergent du radar (predictive anti-fraud et cryptographie post-quantique).

Le passwordless, une évolution majeure pas si simple à organiser

Le mot de passe a été durant des décennies le facteur d’authentification central en informatique (et il l’est encore souvent). Le mot de passe a ensuite été intégré à des stratégies d’authentification multifacteur dans le but de compenser les faiblesses inhérentes à ce mode d’authentification (faible complexité, réutilisation, risque de phishing, etc.). De nouveaux outils sont ainsi venus s’ajouter à la cinématique d’authentification de l’utilisateur : OTP SMS ou mail, notification push, soft token et hard token entre autres. Malgré l’élévation du niveau de sécurité permise par l’ajout de ces nouveaux facteurs d’authentification, le mot de passe reste à la fois un point de faiblesse s’il est découvert (il reste réutilisable sur un compte sans MFA où il est enrôlé) et un poids pour l’expérience de l’utilisateur qui doit s’en souvenir et le stocker de manière sécurisée.

Toutes ces raisons ont poussé les éditeurs à imaginer des modes d’authentification sécurisés ne reposant pas sur l’utilisation d’un mot de passe. L’élimination du mot de passe permet aux entreprises d’améliorer l’expérience utilisateurs de leurs collaborateurs, d’élever le niveau de sécurité des authentifications en réduisant la surface d’attaque et de bénéficier d’une image positive sur le marché. L’utilisateur se retrouve alors dans un environnement où il n’a plus besoin de se rappeler d’une multitude de mots de passe complexes, et où il ne risque plus de se faire voler son compte par phishing. L’utilisation de la technologie FIDO2 (Fast Identity Online 2) reposant sur la cryptographie asymétrique est aujourd’hui l’alternative au mot de passe la plus répandue. Cette technologie poussée par la FIDO Alliance (Google, Microsoft, Amazon, Apple, etc.) repose sur l’utilisation de clés de sécurité physiques stockant localement la clé privée associée à chaque service et permettant à un utilisateur de se connecter à l’ensemble de ses comptes sans mot de passe, et même sans utiliser de login ou d’adresse mail (en utilisant simplement la clé physique en sa possession et un deuxième facteur tel que la biométrie).

La mise en place du passwordless s’accompagne cependant d’importantes questions organisationnelles pour une structure. Comment gérer la récupération d’un compte si celui-ci ne repose pas sur un mot de passe ? Si un collaborateur perd sa clé de sécurité, comment faire pour lui redonner accès à son compte sans pouvoir utiliser la clé privée associée ? Ce sujet majeur du « credentials recovery » est indissociable de toute politique passwordless et suppose qu’une organisation ait anticipé chaque étape de celle-ci : achat et distribution des supports d’authentification, gestion de leur perte/vol/oubli/destruction, processus de rotation des supports obsolètes, solution de back-up des comptes, double enrôlement pour les comptes critiques, gestion des départs de collaborateurs, etc.

Le passwordless est un sujet en vogue et est en cours de déploiement dans de nombreuses organisations. Pour beaucoup, l’étape suivante passe par l’établissement de capacités de détection des fraudes avant qu’elles ne soient commises (aussi appelé « predictive anti-fraud »).

Predictive anti-fraud, comment empêcher une fraude avant qu’elle ne soit commise ?

Le « Predictive anti-fraud » correspond une surveillance proactive des systèmes dans le but d’identifier et de stopper une fraude avant même qu’elle ne soit réalisée, et non plus de se limiter à une analyse à postériori des actes malveillants. Ces capacités de surveillance trouvent en particulier leur sens pour sécuriser les activités commerciales en ligne impliquant des transferts d’argent (cagnotte, compte fidélité, paiement en ligne, etc.) dans les secteurs de la grande distribution, du luxe ou du retail par exemple (car souvent moins matures sur ce sujet que les banques). Nous assistons d’ailleurs actuellement à une hausse des attaques de phishing visant à voler des données de comptes client afin d’en détourner de le contenu (les fraudes à la carte de fidélité sont par exemple un vrai sujet pour les acteurs de la grande distribution).

Les solutions de gestion d’accès sont aujourd’hui de plus en plus capables de détecter des patterns de fraude et de stopper des activités illicites avant leur finalisation. Toutes ces capacités reposent sur du machine learning (impliquant une phase d’entrainement des outils) et passent par trois étapes :

• La détection: les systèmes sont capables de détecter des comportements s’éloignant des parcours utilisateurs/clients courants ainsi que des successions d’actions suspectes. La détection s’appuie à la fois sur le contexte statique du client (navigateur utilisé, réseau, cookie, etc.), le contexte dynamique (adresse IP, appareil utilisé, comportement utilisateur, vitesse de frappe, force de l’authentification réalisée, etc.) et sur le contexte métier en question (type de transaction demandée, montants, modifications d’informations sensibles, etc.).
• L’analyse: une analyse automatique est conduite avec l’attribution d’un score de confiance accordé au profil en cours d’utilisation.
• La réponse: des règles de réponse sont définies afin de répondre au mieux aux levées d’alerte, avec des réponses automatiques pour les situations évidentes ou critiques (ex : facteur d’authentification supplémentaire, coupure de la session), ou des réponses manuelles pour les cas nécessitant une prise de décision humaine.

Le principal défi du predictive anti-fraud est le bon calibrage des outils de machine learning, et leur bonne adaptation au contexte métier en question. Un accent trop fort sur la sécurité pourrait avoir un impact trop négatif sur le service : nombre important de faux positifs affectant l’expérience utilisateur, alourdissement et ralentissement du service (captcha, step-up authentication, consommation réseau importante, temps de traitement rallongés). La définition de règles de sécurité et de détections pertinentes doit être accompagnés d’un machine learning le plus personnalisé et complet possible. Face à la croissante complexité des attaques, la clé d’une stratégie de predictive anti-fraud efficace réside dans la capacité des solutions à détecter et corréler des signaux faibles. Par exemple, certains éditeurs sont aujourd’hui capables de détecter des tentatives de fraude au conseiller, en corrélant les actions réalisées par un utilisateurs et le fait qu’il soit ou non en communication téléphonique.

Certificate Lifecycle Management (CLM), un nouveau marché pour un problème ancien

De nombreuses entreprises sont actuellement confrontées à une explosion du nombre de certificats électroniques au sein de leur SI. Ces certificats (et les clés cryptographiques associées) ont de nombreuses utilités comme l’authentification machine-to-machine, l’authentification des utilisateurs, la signature et le chiffrement de données, la sécurisation des sites web, des micro-services applicatifs et des communications entre objets connectées, etc. Cette augmentation du nombre de certificats électroniques sous gestion accroît considérablement la charge des équipes.

Le cycle de vie d’un certificat électronique comprend de nombreuses étapes comme :

1. La demande du certificat auprès d’une PKI (Public Key Infrastructure)
2. La réception du certificat et des clés associées
3. Le déploiement du certificat sur son périmètre (soit en remplacement d’un ancien certificat expirant bientôt, soit sur un nouveau périmètre)
4. Le décommissionnement et la révocation de l’ancien certificat remplacé (le cas échéant)
5. Le suivi continu du certificat et de sa future date d’expiration
6. Reproduction de ce processus pour chaque certificat avant son expiration

Une gestion manuelle de dizaines (voire de centaines) de milliers de certificats électroniques pose de nombreux problèmes. Ce type de gestion est très demandeur en ressources humaines, repose sur des tâches répétitives tout en étant propice aux erreurs humaines. Il n’est en effet pas rare que des certificats passent sous le radar des équipes et ne soient pas renouvelés, ou qu’ils ne soient tout simplement pas déclarés au sein du SI (shadow IT). Pour toute ces raisons, une organisation disposant d’une large flotte de certificats électroniques devrait envisager de recourir à une solution de CLM.

Les solutions de CLM proposent de nombreuses fonctionnalités permettant de faciliter et fiabiliser la gestion du cycle de vie des certificats. Parmi ces fonctionnalités on retrouve, par exemple :

• Des outils de découverte de certificats permettant à une entreprise d’avoir une vision exhaustive de sa flotte de certificats (même pour les certificats non déclarés)
• L’utilisation de protocoles automatisant toutes les actions autour des certificats mentionnées ci-dessus
• De nombreux connecteurs permettant à leurs clients d’intégrer au mieux ces solutions au sein de leur SI
• Des modules de gouvernance et de gestion des droits sur les certificats
• Des capacités d’alerting représentant un filet de sécurité pour les équipes

La philosophie « Zero Trust », nécessitant souvent de sécuriser les communications entre services par authentification mutuelle à l’aide de certificats électroniques (avec le recours de plus en plus fréquent aux architectures en micro-services, à l’explosion du nombre de comptes non humains, etc.) tend à accroître le nombre de certificats électroniques au sein des organisations. Utiliser des outils de gestion dédiés à la gestion du cycle de vie des certificats plutôt qu’un suivi manuel permet de réduire de 90% les incidents liés aux certificats, et de réduire de 50% le temps de traitement de ces incidents, selon le Gartner[2].

Pour plus de détail sur les solutions de CLM, vous pouvez lire l’article de Wavestone consacré à ce sujet ici.

L’implémentation d’une solution de CLM est synonyme d’un pas en avant vers la sécurisation des infrastructures, mais aussi et surtout vers la crypto-agilité (capacité à rapidement remplacer ou mettre à jour des algorithmes ou des protocoles de chiffrement pour faire face à l’évolution des menaces). La crypto-agilité est un thème qu’il faut s’attendre à retrouver de plus en plus souvent à moyen terme, en grande partie à cause du développement des ordinateurs quantiques.

Et après ? Des défis technologiques à venir, exemple de la cryptographie post-quantique

Alors que les organisations s’efforcent d’adopter des stratégies IAM robustes, la prise en compte des menaces technologiques actuelles n’est désormais plus suffisante. L’avènement prochain des ordinateurs quantiques (les CIdO ont tout de même encore quelques années devant eux) sera amené à bouleverser toutes nos habitudes de chiffrement, ce qui nécessite d’anticiper le plus tôt possible les mesures à appliquer pour la décennie 2030. Le recours aux ordinateurs quantiques et à leurs fameux qubits (pouvant à la fois prendre 0 ou 1 comme valeur) permet dès aujourd’hui de tester des calculs cryptographiques beaucoup plus efficacement qu’avec l’utilisation d’ordinateurs traditionnels.

Il est important de noter que la cryptographie symétrique n’est pas à risque face aux menaces quantiques, et qu’augmenter la taille des clés de chiffrement permettra à ce mode de chiffrement d’y résister assez efficacement. Cependant, la cryptographie asymétrique utilisée pour sécuriser un canal d’échange de clés, avant l’utilisation de la cryptographie symétrique est réellement mise en danger par les ordinateurs quantiques. L’algorithme de Shor pourrait permettre à un ordinateur quantique de casser un chiffrement basé sur du RSA 2048 en quelques heures. La cryptographie-post quantique s’intéresse donc actuellement aux solutions permettant d’adapter le chiffrement aux capacités futures des ordinateurs quantiques. Le NIST a ainsi publié en 2022 une liste de 4 algorithmes de chiffrement résistants aux ordinateurs quantiques : CRYSTALS-Kyber pour le chiffrement général, CRYSTALS-Dilithium, FALCON et SPHINCS+ pour la signature électronique.

La principale recommandation actuelle permettant d’assurer la transition vers un chiffrement post-quantique est d’effectuer un chiffrement hybride, c’est-à-dire d’utiliser à la fois des algorithmes de chiffrement classiques et post-quantiques afin de sécuriser les communications. Si cette problématique n’est pas encore au cœur des enjeux IAM actuels, il convient d’en suivre l’évolution, d’autant plus que certains grands éditeurs commencent déjà à investir le marché et à introduire un nouveau terme : QCaaS (Quantum Computing as a Service).

Cet article Radar CIdO 2024 est apparu en premier sur RiskInsight.

Bien que les avis soient partagés entre les enthousiastes, les craintifs et les sceptiques de l’IA, les plus optimistes avancent que l’intelligence artificielle peut améliorer nos processus de travail et faciliter des actions parfois répétitives en se posant comme un facilitateur à la réalisation de nos tâches.

Mais ces avancées sont-elles applicables en matière d’IAM ? Peut-on déléguer partiellement ou entièrement la gestion de nos identités et de nos accès lorsque la protection des données des utilisateurs est devenue une préoccupation majeure ?

IA et IAM : un nouveau défi pour les entreprises

Une question fondamentale apparaît lorsqu’il s’agit de réfléchir à la relation entre IA et IAM :  dans la mesure où les systèmes IAM existent pour instaurer une confiance numérique, que ce soit envers nos collaborateurs, clients ou partenaires, est-il possible de garantir que des solutions basées sur l’IA assureront ce même niveau de confiance ?

Malgré les interrogations possibles, nous estimons qu’il est impératif d’envisager les possibilités offertes par l’IA. Les équipes IAM doivent s’ouvrir à ces nouveaux enjeux et adopter une approche de « Test & Learn » sur la base de cas d’usage concrets. La collaboration avec les éditeurs IAM, les intégrateurs ou les équipes internes Data ou IA est nécessaire afin d’explorer toutes les possibilités.

En outre, nous sommes convaincus que l’environnement actuel offre un terrain propice à l’adoption de cette approche :

• Les directions et les métiers de l’entreprise cherchent à comprendre l’impact potentiel de l’IA sur différents aspects de l’entreprise et les équipes IAM doivent être en mesure de fournir des réponses.
• Le développement des offres Cloud pour la gestion des identités et des accès, ainsi que la convergence renforcée des solutions d’Access Management (AM) et d’Identity Governance and Administration (IGA), créent un environnement favorable au développement de l’IA. Les algorithmes d’entraînement peuvent accéder à davantage de données, facilitant ainsi la production de valeur.
• Le paysage des menaces évolue toujours plus vite – avec l’IA notamment – et les équipes IAM sont confrontées à toujours plus de besoins en termes de conformité, sécurité, expérience utilisateur ou encore efficacité opérationnelle.

Il semble donc naturel de se demander si l’IA peut contribuer à résoudre ces défis en s’intéressant à des cas d’usage concrets. Dans cet article, nous allons regarder de plus près les possibilités offertes par l’IA, les leviers clés susceptibles d’être impactés par son utilisation et comment elle pourrait (ou non) changer nos modes de fonctionnement autour de l’IAM.

La contribution de l’IA aux 3 enjeux essentiels de l’IAM

L’analyse de différents cas d’usage prenant en compte l’IA pour l’IAM a été pensée autour des 3 moteurs de l’IAM :

• La cybersécurité et la conformité
• L’expérience utilisateur
• L’efficacité opérationnelle et business

Les cas d’usage présentés ci-dessous sont le fruit de la réflexion d’une quarantaine de consultants et professionnels de l’IAM amenés à s’interroger sur la contribution que peut avoir l’IA pour l’IAM au travers de différents ateliers.

Être un levier pour la cybersécurité et la conformité

Cas d’usage 1 : Vérification continue

Actuellement de nombreux mécanismes permettent de contrôler le comportement d’un utilisateur via différents critères (localisation, appareil utilisé, etc.). L’ajout de l’intelligence artificielle dans un processus de vérification en continu permettrait de maximiser le potentiel de surveillance pendant et après l’authentification de l’utilisateur en agrégeant une multitude d’informations au sujet de l’utilisateur (analyse comportementale des frappes clavier ou cliques souris, horaire habituel de connexion, comportement suspect au sein de l’application, etc.) et d’apporter une remédiation automatique adaptée (demande de réauthentification, arrêt de session, alerte aux équipes sécurité, etc.).

A l’heure actuelle, certains éditeurs proposent ou prévoient de proposer des fonctionnalités sur la vérification continue. Le but étant d’utiliser l’IA pour évaluer en continu les risques et appliquer des politiques de sécurité à la connexion, mais aussi durant la session d’un utilisateur actif. Ces fonctionnalités réduisent le risque d’accès non autorisés et les menaces dites « post-authentification », comme le détournement de session, le piratage de compte ou encore la fraude lors de l’authentification.

Cas d’usage 2 : Aide à la décision

La prise de décision peut poser des défis tant pour un manager que pour l’utilisateur lui-même, notamment lorsqu’il s’agit d’assigner ou de demander des droits.

Les managers, par exemple, peuvent ne pas toujours avoir une connaissance approfondie des droits spécifiques à accorder à un membre de leur équipe, et il peut être nécessaire de solliciter de l’aide pour déterminer la meilleure approche lors de l’attribution de ces droits.

De plus, la revue des droits est un processus généralement peu apprécié par les différents métiers, d’autant plus lorsqu’elle est faite de manière manuelle. Les managers peuvent parfois opter pour une validation des droits de leur équipe « par défaut » par manque de temps ou de connaissance.

C’est là que l’intelligence artificielle peut intervenir en offrant une assistance rapide et efficace aux responsables concernés. Elle peut ainsi fournir des recommandations pour un utilisateur en tenant compte de divers facteurs tels que le nombre de personnes de son équipe ayant des droits similaires, les droits récemment attribués aux collaborateurs travaillant avec lui ou encore les droits requis pour son activité. Cette assistance dans l’attribution des droits et des accès ainsi que dans leur revue constitue une orientation précieuse pour les responsables. Elle permet de renforcer la légitimité des droits d’accès des utilisateurs ainsi que la sécurité.

Notons que l’aide à la décision basée sur l’IA fait partie des cas d’usage les plus mis en avant par les éditeurs en ce moment.

Améliorer l’expérience utilisateur

Cas d’usage 3 : Documentation des droits accès

Il est essentiel pour les utilisateurs d’avoir une compréhension exhaustive et détaillée de leurs autorisations et de leurs accès. Cela leur permet non seulement de connaître leurs droits d’accès, mais aussi d’identifier les éventuels manques au sein de leurs activités. Une simple liste de droits peut parfois être peu explicite pour la plupart des utilisateurs. Cependant, l’utilisation de l’intelligence artificielle générative pourrait permettre la création rapide d’un schéma « intelligent », offrant une visualisation claire des droits accessibles à l’utilisateur, avec une distinction visuelle selon certains critères tels que :

• Le niveau de droits (consultation, modification, administration, etc.)
• Le domaine d’application (gestion des achats, validation des paiements, etc.)
• La criticité du droit
• La durée de validité des droits
• Les conditions d’octroi des droits (cycle d’approbation)
• L’historique des droits utilisés

Ainsi, l’IA pourrait grandement faciliter la compréhension des droits par les utilisateurs en offrant une vision claire, structurée et contextualisée de leurs autorisations.

Cas d’usage 4 : Autorisation dynamique

Se retrouver bloquer par manque de droits pour accéder à un document, une application ou un groupe SharePoint n’est pas une situation anodine et peut fortement nuire à l’expérience utilisateur, d’autant plus lorsque les délais de traitement sont importants. Cependant, lorsque les ressources accédées ne sont pas critiques, l’intelligence artificielle a un vrai rôle à jouer afin d’automatiser l’accès de manière efficace. Par exemple, basé sur le fait que des personnes de la même équipe ou travaillant sur le même projet aient certains accès, l’IA pourrait temporairement accorder l’accès à un utilisateur pour éviter tout blocage. En parallèle, des suggestions pourraient être proposées à l’utilisateur afin d’effectuer la demande et avoir un accès prolongé.

Par ailleurs, cette approche dynamique de l’autorisation peut présenter des avantages en termes d’économie de licences. Si l’attribution d’un droit dans une application nécessite l’utilisation d’une licence, une attribution temporaire (« juste à temps ») permet à l’utilisateur de n’utiliser la licence que pendant la durée nécessaire à ses tâches, avant de la réattribuer à un autre utilisateur. Au-delà de l’amélioration de l’expérience utilisateur, cette approche peut également générer des économies budgétaires significatives.

Être un facilitateur business et améliorer l’efficacité

Cas d’usage 5 : Automatisation des droits d’arrivée

Les processus Joiner-Mover-Leaver (JML) revêtent une importance cruciale au sein des processus IAM des entreprises. Ils visent entre autres à contrôler et à faciliter les changements de statut d’un utilisateur conformément à un ensemble de règles définies. Cela inclut notamment l’activation ou la désactivation des accès et l’attribution du niveau de droits approprié en suivant le principe du moindre privilège, par exemple, en supprimant les droits obsolètes à la suite d’une mobilité interne.

L’utilisateur ne doit donc pas être « bloqué » (par manque ou absence de droits) lors de son arrivée ou lors d’une mobilité, car cela impacterait fortement ses activités.

L’intelligence artificielle pourrait jouer un rôle majeur dans ces processus JML en analysant le passé des utilisateurs occupant un même poste/service, ayant déjà reçu un ensemble de droits à leur arrivée. Ces analyses pourraient générer des suggestions de droits et d’accès à attribuer à un nouvel arrivant dans le même service. De plus, l’intelligence artificielle pourrait proposer des améliorations pour les processus de mobilité en suggérant un ensemble de droits correspondant aux rôles attribués dans le nouveau service, voire même faciliter l’évolution des rôles métiers en proposant des modifications de leurs compositions.

Cas d’usage 6 : Support IAM

Les chatbots interactifs gagnent une place croissante au sein des entreprises en assistant les utilisateurs dans divers processus tels que la création d’incidents ou la recherche de documents.

Toutefois, grâce à l’intelligence artificielle, ces chatbots pourraient également apporter un soutien précieux aux équipes de cybersécurité et de support en accélérant la récupération d’informations. Par exemple, les équipes de cybersécurité pourraient demander au chatbot de fournir toutes les autorisations sensibles d’un utilisateur, tandis que les équipes de support pourraient demander pourquoi un utilisateur est en attente d’habilitation pour une application.

Le temps considérable actuellement consacré par ces équipes à rechercher les informations pertinentes, à récupérer les bons tickets d’incident et à examiner l’historique des utilisateurs pourrait ainsi être significativement réduit. Ces chatbots seraient en mesure d’interroger les solutions IAM, les outils de gestion des incidents et d’autres outils de l’entreprise pour récupérer les données nécessaires. Cela permettrait ainsi aux équipes de se concentrer sur des tâches à plus forte valeur ajoutée et de résoudre les incidents de manière plus efficace.

***

Loin d’être exhaustifs, ces quelques exemples illustrent la diversité des domaines d’application de l’IA au sein de l’IAM. D’autres cas d’usage pourraient également tirer partie de l’IA, tels que :

• La détection de droits d’accès incompatibles (Segregation of Duties) : Suggérer des droits incompatibles suivant les activités de l’entreprise, identifier de manière proactive les conflits dans les autorisations des utilisateurs et proposer des remédiations.
• L’optimisation de la qualité des données : Améliorer la qualité des données en effectuant des rapprochements automatiques d’un grand nombre de données, en corrigeant les doublons ou les données orphelines, en signalant les divergences ou les volumes anormaux, en nettoyant automatiquement les données et en les corrigeant.
• La vérification de la conformité du système IAM : Évaluer la configuration du système IAM par rapport aux normes, aux meilleures pratiques, aux recommandations des fournisseurs et aux observations externes, et proposer des suggestions pour renforcer la sécurité.

Il est important de noter que la facilité de mise en œuvre et l’intérêt pour l’ensemble des cas d’usage mentionnés varient selon les secteurs d’activité des entreprises. Par exemple, dans le secteur industriel, l’accent peut être mis sur l’efficacité des processus et la sécurité, au détriment parfois de l’expérience utilisateur, en raison de processus complexes et historiques reposant sur des technologies plus anciennes.

Pour autant, dans le cadre des ateliers organisés autour des sujets IA et IAM,  voici ce qu’il ressort en termes d’estimation de la faisabilité et de la valeur ajoutée sur les 9 cas d’usage présentés précedemment :

Que peut-on espérer à l’avenir ?

L’IA permet et va permettre de plus en plus de répondre aux 3 piliers de l’IAM (sécurité & conformité, expérience utilisateur et efficacité opérationnelle). Certains cas d’usage sont déjà proposés par des éditeurs et vont continuer d’évoluer, d’autres sont sur leur feuille de route, et d’autres encore se limitent à des contraintes techniques et restent pour l’instant au stade d’ambitions prometteuses.

Cependant, ne s’intéresser qu’aux promesses serait se mettre des œillères, il est impératif de reconnaitre et d’anticiper d’ores et déjà les risques induits par l’utilisation de l’IA dans l’IAM : notamment la possibilité de tromper les mesures d’authentification, le développement d’attaques innovantes basées sur l’identité (phishing de haute qualité, voix modifiée, etc.) et la capacité à exploiter les données et les vulnérabilités au sein des systèmes et des politiques IAM. On peut également craindre une prise de décision biaisée dans l’octroi des accès ou encore la gestion des accès d’une IA qui doit être interconnectée de toute part. Ces risques sont également complétés par les risques inhérents à l’IA : corruption des données en sortie, vol d’informations en comprenant les limites/faiblesses du modèle IA, possibilité de tromper la capacité de reconnaissance de l’IA… Ces risques ont été abordés de manière plus approfondie dans un autre article que nous vous conseillons : Sécuriser l’IA : Les nouveaux Enjeux de Cybersécurité.

En raison des risques associés, du manque de réglementation, du rôle fondamental de l’IAM et d’une forte dépendance au contexte de chaque entreprise, la tendance actuelle en matière d’IA dans l’IAM penche davantage vers la suggestion et l’aide à la décision plutôt que vers une prise de décision autonome, mais pour combien de temps ? L’émergence rapide de l’IA et son intégration de plus en plus fréquente dans notre paysage amènent à se demander combien de temps nous avons avant de devoir faire confiance à l’IA pour avoir le bon niveau de réactivité, de détection et de résolution… pour faire face à l’IA. 

Cet article L’intelligence artificielle, une révolution pour l’IAM ? est apparu en premier sur RiskInsight.

Afin de formaliser notre expérience acquise et d’aller plus profondeur, nos experts ont créé un outil d’évaluation de maturité IAM.

Entretien avec Anatole CATHERIN, Manager et expert IAM depuis presque 10 ans chez Wavestone.

Bonjour Anatole, merci pour ton temps ! Pour commencer, pourrais-tu nous expliquer ce que c’est (vraiment) l’IAM ?

L’Identity and Access Management (IAM) est une discipline à la croisée de trois mondes.

Évidemment, celui de la cybersécurité puisqu’il s’agit de gérer les identités, les droits accordés à ces identités et l’accès des utilisateurs aux ressources de l’entreprise. Concrètement, chaque utilisateur a des accès dans le cadre de son rôle au sein d’une organisation. Les organisations doivent savoir qui peut faire quoi, quand et pourquoi au sein de leur système d’information. L’IAM est ainsi une condition sine qua non de la cybersécurité, notamment pour mettre en place une politique Zero Trust.

La gestion des identités et des accès doit aussi être perçue comme un business enabler, un facilitateur pour la réussite des programmes de transformation numérique des organisations , tout en offrant des processus opérationnels plus efficaces à ses collaborateurs et clients. Il permet par exemple de contrôler et fluidifier la gestion des arrivés, des départs ou des mobilités : l’IAM assure que chaque nouveau collaborateur bénéficie des bons accès, qu’en cas de mobilité ou de départ, les accès pertinents soient coupés et qu’il n’y ait pas de perte d’informations.

Le troisième volet est que l’IAM fluidifie l’expérience utilisateur des collaborateurs au sein d’une organisation. D’ailleurs, le meilleur système IAM ne se voit pas ; pouvoir travailler dès son arrivée ou bénéficier d’une connexion renforcée lorsque le contexte de sécurité le nécessite devraient être considérés comme normal, par tous.

Pourquoi est-ce si difficile de construire un système IAM qui fonctionne ?

Vous l’aurez compris, l’enjeu de l’IAM c’est de trouver (et garder) l’équilibre entre sécurité et fluidité de navigation et ce n’est pas simple.

Et pour progresser, il faut savoir où on en est… Mais d’expérience, nous avons constaté que nos clients éprouvaient des difficultés à mesurer l’efficacité de leur système IAM en place… et pour cause ! Il n’existe pas sur le marché de référentiel dédié pour s’évaluer. Les piliers du NIST restent très haut niveau et ne permettent pas de couvrir toutes les questions liées à l’IAM évoquées précédemment ; les référentiels existants ne traitent l’IAM que sous le volet cybersécurité sans mesurer son impact sur l’efficacité opérationnelle des procédures internes d’une organisation et sans mesurer non plus la fluidité du parcours utilisateur.

Le but en créant l’IAM Framework était donc de proposer un cadre qui évalue l’ensemble de la discipline et qui puisse servir à construire un plan d’actions concrètes.

Justement, peux-tu nous parler brièvement de l’outil d’évaluation de maturité IAM ?

Plus qu’un outil, je parlerais surtout d’un cadre de travail et d’une méthodologie outillée pour accompagner clients et les aider à faire un état des lieux de leur maturité IAM.

Le Framework permet de savoir où en est l’organisation à date : sur quel périmètre l’IAM est déployé (ou non) et quels sont les grands axes sur lesquels travailler. Il donne ainsi une vue d’ensemble, avec le bon cadre, le bon angle et la bonne résolution pour parcourir tous les sujets IAM.

Cette évaluation de maturité permet ensuite de prioriser les chantiers et de mettre en place un plan d’action IAM !  Grâce à ce cadre, nous pouvons identifier les grands axes d’amélioration, tout en tenant compte des spécificités de chaque organisation, via l’introduction de la notion de périmètre.

En résumé, il répond à trois objectifs : Evaluer, Améliorer et Etendre l’IAM sur d’autres périmètres, par exemple, au-delà des internes et prestataires, avec les clients ou partenaires. Il a été voulu exhaustif afin de mettre en lumière les manquements de nos clients et mesurer par la suite leur progression et l’efficacité de leur programme de transformation.

Notre ambition serait d’en faire le premier standard d’évaluation, intégralement dédié à l’IAM, avec un niveau de granularité suffisant pour couvrir toutes les thématiques !

Comment est-il construit ?

Concrètement, notre outil est composé d’une cinquantaine de questions qui couvrent les 6 thématiques IAM :

1. Gouvernance
2. Gestion des identités
3. Gestion des habilitations
4. Contrôle des accès
5. Gestion des accès à privilège
6. Rapport et contrôles

Il peut être utilisé dans plusieurs cas, dont voici 2 exemples :

Peux-tu nous parler de la dernière fois que tu l’as utilisé avec un exemple concret ?

Nous avons confronté le questionnaire à la réalité terrain lors de plusieurs missions, au cours desquelles l’exploitation de l’IAM Framework a permis d’accélérer la démarche mise en œuvre. Ces missions concernaient :

• la définition d’une feuille de route IAM pour une grande entreprise de l’énergie
• le cadrage d’une migration vers un outil IAM pour le compte d’un groupe bancaire, qui a permis de mesurer les écarts entre leur solution existante et la nouvelle
• l’évaluation de maturité IAM pour un acteur de l’assurance, afin d’identifier les points de frictions et les axes d’amélioration et d’établir une roadmap

Pour ces trois projets, la grille d’évaluation a permis d’identifier l’ensemble des sujets à traiter (connus ou non du client au départ) afin de fournir une roadmap actionnable couvrant l’intégralité des enjeux IAM. En d’autres termes, le Framework peut être utilisé comme cadre d’analyse pour la réalisation d’un projet.

De nouvelles missions vont se lancer sur le sujet et nous avons hâte d’accompagner de nouveaux clients pour améliorer leur structure IAM !

Un mot pour la fin ?

Je terminerai par rappeler toutes les qualités du Framework !

• Prêt à l’emploi, il permet de couvrir tous les sujets IAM grâce ses cinquantaines de questions, pensées par les experts Wavestone,
• Il offre une vision standardisée et formalisée de sa maturité sur le sujet de la gestion des accès et des identités. Cette évaluation est d’ailleurs l’occasion d’impliquer tous les acteurs clés impactés par l’IAM: les équipes cyber bien sûr, avec les équipes IT, mais aussi les équipes d’audit interne et surtout métier,
• Il facilite la priorisation des actions à mener dans le cadre d’un programme de transformation. Comme expliqué précédemment, il peut par ailleurs être utilisé à différent moment et peut donc s’inscrire comme support dans le cadre d’une réflexion plus large,
• C’est enfin un moyen flexible d’utilisation: soit à utiliser pour du très haut niveau (un niveau stratégique) soit à utiliser pour développer des actions très précises.

Envie de vous évaluer ? Contactez nous !

Cet article [INTERVIEW] Maturité IAM : où en êtes vous et pourquoi est-ce essentiel de le savoir ! est apparu en premier sur RiskInsight.

De l’évidence de l’IAM, et de la difficulté des transformations qu’il implique

Face à l’évolution des menaces et des usages (mobilité, télétravail, Cloud Computing…), non seulement l’IAM n’est plus une option ; mais il est désormais acquis que disposer d’une gestion efficace et agile des identités et des accès est un différentiateur.

Par essence, l’IAM est à la croisée de toutes les transformations structurantes : c’est entre autres choses un pilier majeur pour s’orienter dans une approche zéro-trust, un essentiel « de base » pour servir efficacement ses utilisateurs et leur apporter un confort constant pendant toutes les phases de transformation, et c’est évidemment un différentiateur dans la création de la relation avec ses clients.

L’IAM ne peut plus simplement se permettre de « suivre à distance » les transformations de l’Entreprise, en offrant un niveau de service a minima et souvent difficile à faire évoluer. Il doit être efficace, agile, et en capacité d’anticiper des situations parfois complexes comme des M&A, la multiplication des APIs, ou la bascule vers modèle d’économie « plate-forme ». Ces situations impliquent de repenser en profondeur son IAM : son périmètre et son ambition, sa politique et sa gouvernance, son mode de delivery (on-premise vs SaaS), son offre de service et son modèle économique…

Le déploiement des services d’IAM chez les grands comptes 

Maturité du marché : savoir évaluer sa maturité par rapport au marché pour engager son programme de transformation sur une base solide et objective

La grande majorité des grands comptes ont déjà conduit un ou plusieurs projets qui ont permis de déployer des services IAM. Toutefois, ces déploiements sont souvent partiels et la maturité du déploiement peut fortement varier d’une entité à l’autre. Historiquement, ces projets sont en fait confrontés à une forte hétérogénéité des existants (en matière d’organisations, de processus et de SI), et ne dispose pas de la légitimité nécessaire pour faire converger les pratiques. De plus, l’IAM était souvent vu comme un projet « one shot » avec des moyens souvent insuffisants pour suivre et s’adapter aux évolutions de l’Entreprise (réorganisation, M&A, évolutions d’application…). Ces éléments ont pu conduire à un « décrochage » entre les sujets IAM, trop statiques, et les besoins réels en évolution permanente.

Parce que déployer des services d’IAM, ce n’est pas simplement déployer une « boîte » en production. Pour en tirer bénéfice, il est nécessaire de repenser et simplifier son organisation et ses processus IAM, et notamment se poser les questions suivantes :

• Comment gérer l’arrivée d’un nouveau collaborateur ?
• Comment gérer l’internalisation d’un prestaire ?
• Comment modéliser ses profils métiers ? Comment les faire évoluer dans le temps ?
• Comment impliquer les managers, les responsables des données dans les processus IAM ?
• Comment traiter la perte de moyen d’authentification forte ?
• Quels standards imposer pour simplifier le raccordement des applications à l’IAM ?
• Comment s’assurer du respect des règles internes ou de règlementations ?

Depuis maintenant quelques années, nous constatons une réelle prise de conscience et une volonté de nos clients à s’emparer de l’IAM pour le rendre plus efficace, plus rationalisé et plus agile : cela implique pour pouvoir arbitrer et conduire une transformation en profondeur. Concrètement, sur les 3 dernières années, 2/3 de nos clients ont lancé de tels programmes de transformations IAM. Ces initiatives, pluriannuelles, ont gagné en ambition, en structure, en investissement, en visibilité et réussissent désormais à figurer en bonne place dans le « Top 5 » des grands projets de transformation de la DSI.

Pour engager de tels programmes, la première étape consiste à pourvoir évaluer sa maturité réelle, entité par entité, avant de pourvoir définir une trajectoire de transformation réaliste et fédératrice entre les parties prenantes. De manière très simplifiée, nous pouvons distinguer 4 niveaux de maturité :

• Fragmenté: l’organisation n’a pas d’approche consolidées
• Rationnalisé: l’IAM est simplifié et géré de manière centralisée sur les services de base
• Etendu: capacités organisationnelles d’IAM adaptées à un S.I en évolution
• Maîtrisé: IAM efficient, agile, réduction de la charge de travail grâce à l’automatisation

En tendance, nous pouvons considérer que les grandes entreprises se situent sur les niveaux intermédiaires « Rationnalisé » et « Etendu », et vise une cible « maitrisée » ; s’appuyant sur :

• Une infrastructure IAM centrale, unique et optimisée.
• Une gestion courante déléguée au sein de chaque entité.

5 clés pour réussir à opérationnaliser sa stratégie d’IAM

L’IAM est un vaste sujet où il est facile de se perdre. De plus, la réalité opérationnelle de l’IAM est très souvent mal connue et la complexité de transformation sous-estimée.

Pour pallier ces risques, nous vous proposons 5 clés majeures :

• Bien définir son ambition IAM et s’assurer de la cohérence entre cette ambition et les moyens alloués : sponsor, capacité à faire bouges les lignes, moyens humains et financiers
• Prendre le temps de s’approprier la réalité opérationnelle de l’IAM
• S’organiser dans un programme de transformation à même d’aborder l’ensemble des facettes
• Se préparer à une transformation en profondeur, et accepter d’avancer par étapes et avec des compromis, et donc des renoncements, pour faire face à la somme des contraintes
• S’appuyer sur les données réelles pour expliquer ses arbitrages et pour anticiper les éventuels manques de qualité.

S’appuyer sur les fournisseurs IAM : tendances et risques

Le marché des fournisseurs IAM se structure, et translate dans le Cloud

Le marché des fournisseurs IAM, comme les autres marchés spécialisés, évolue à partir des évolutions que connaissent les systèmes d’informations : basculer vers le Cloud, offrir plus d’API, intégrer des fonctionnalités d’analyse de données, d’IA, afin de simplifier voire d’automatiser la prise de décision.

En complément de ces considérations, deux tendances propres au marché des fournisseurs IAM se dégagent :

• Premièrement, les acteurs leaders de l’Access Management cherchent à progressivement étendre leur couverture fonctionnelle vers des fonctionnalités de Gestion des Identités ou de PAM.
• Deuxièmement, il y a de plus en plus d’acteurs couvrant des besoins fonctionnels spécifiques, comme l’IAI (Identity Analytics & Intelligence), le CIAM ou le souhait de disposer d’une plate-forme directement développée dans Service Now.

Le déplacement dans le Cloud indique des modifications d’architecture des solutions IAM

De plus en plus d’éditeurs proposent des solutions d’IAM dans le Cloud. Ce mouvement vise à offrir la même couverture fonctionnelle que les applications « on-premise » en mode SaaS. Suivant les services offerts, elles sont structurées autour de deux composants :

• Une partie « Cloud » qui porte l’ensemble des fonctionnalités et stocke les données des clients ;
• Une « passerelle » sur site qui permet de faire le lien avec le système historique en place (pour le provisioning par exemple). Elle permet un meilleur contrôle des échanges de données et concourt donc à sécuriser l’architecture.

Ainsi, cette architecture à deux composants présente les mêmes risques que tout autre service Cloud, et il faut les aborder de la même manière : Quels sont les niveaux de services garantis ? Où sont stockées mes données ? Quid de la protection de mes données et du respect des normes (GDPR notamment) ? Dans quelles conditions puis-je changer de fournisseurs ?

Le contexte géopolitique accroit ces risques et fait également peser un risque spécifique de coupure de service en application d’éventuelles sanctions internationales.

Et l’IAM du futur : quelles évolutions ?

Demain, l’IAM va continuer ses transformations pour aller vers plus d’agilité, plus de Cloud, plus de standard et d’intégration, plus d’aide à la décision et d’automatisation grâce à l’IA. Concernant le système d’authentification, l’authentification forte est désormais un « basic » et deux évolutions majeures se jouent :

• Une évolution plutôt technique avec le « passwordless » qui vise à faire disparaitre les mots de passe, y compris techniquement dans les bases de données des applications et les flux inter-applicatifs.
• Une évolution sur le moyen d’authentification donné aux utilisateurs. Le Smartphone s’est imposé comme un facteur d’authentification mais toutes les populations en Entreprise ne sont pas équipées. Et alors que le support « carte à puce » est en perte de vitesse, les dongles sécurisés (composant matériel se branchant sur les ordinateurs ou les téléviseurs, généralement sur un port d’entrées-sorties semblent s’imposer pour ces populations sans Smartphone.

Enfin, à plus long terme, l’IAM évoluera certainement sous l’impulsion de l’approche « privacy-by-design », de plus en plus intéressante et amenée à être de plus fréquente ; et, pourquoi pas, avec la généralisation de l’identité citoyenne (avec un niveau d’enrôlement ad hoc), y compris pour des usages commerciaux.

Cet article L’IAM est enfin entré dans le Top des grands projets de transformation de la DSI ! est apparu en premier sur RiskInsight.

Que faire alors de ce mot de passe en attendant sa potentielle disparition ? Comment réduire l’impact de ce qui est aujourd’hui le principal point de friction du parcours utilisateur, tout en sécurisant mieux ses services ?

Pourquoi le mot de passe est-il si répandu ?

Les mots de passe sont utilisés depuis longtemps comme un moyen d’accès, par exemple aux clubs secrets et/ou clandestins. Ce système historique de gestion des accès « si j’ai le secret, alors j’ai le droit d’entrer » s’est transformé lors de son passage dans le monde informatique en un moyen de prouver son identité – « si j’ai le secret, alors je suis qui je dis que je suis ». L’insertion de caractères dans un certain ordre connu uniquement de l’utilisateur ayant droit d’accès, est ainsi devenue la solution pour lui permettre de prouver son identité.

Si les faiblesses de ce système se sont très vite révélées, tant que les systèmes informatiques n’étaient pas connectés et nécessitait donc un accès physique, la surface d’attaque restait limitée. Le mot de passe est donc devenu un pilier de la sécurité IT et est utilisé dans quasiment tous les services demandant une gestion de l’utilisateur.

Cependant, l’arrivée des réseaux, notamment internet, et par conséquent l’agrandissement de la surface d’exposition ont fait évoluer ces faiblesses en de réelles vulnérabilités.

Comment en est-on arrivé à mettre sur le chemin de l’utilisateur une telle complexité ?

Le nombre élevé de possibilités d’attaque sur les mots de passe ont petit à petit amené les experts de la sécurité à multiplier les mesures de protection censées sécuriser l’utilisation des mots de passe.

Ainsi, sont apparus un certain nombre de mesures autour du mot de passe et des processus associés complexifiant toujours plus les parcours utilisateurs. Par exemple:

• Nombre de caractères minimum
• Complexité (1 chiffre, une lettre, un caractère spécial, etc.)
• Liste de mots interdits
• Recommandation d’unicité du mot de passe entre les services
• Renouvellement périodique & historique

Ces règles, en grande partie issues des recommandations passées du National Institute of Standards and Technology (NIST), NIST.SP.800-63-2, 2015, et que l’on retrouvait dans la plupart des frameworks de sécurité (UK, français, etc.) impactent négativement l’expérience utilisateur. Souvent peu intuitives et différentes d’un service à l’autre, leur compréhension par l’utilisateur peut relever du défi : manque d’explication claire sur la complexité attendue, pas de compteur de tentatives erronés avant le verrouillage du compte, ou encore expérience variant en fonction du canal d’accès utilisé (l’accessibilité de certains caractères spéciaux variant grandement d’un terminal à l’autre, par exemple : le caractère « § » sur un iPhone ou un iPad).

Et pour quelle efficacité ?

Malgré toutes ces mesures, le mot de passe reste largement décrié pour son faible niveau de sécurité, car il repose sur deux principes peu compatibles avec un fort niveau de sécurité.

Le principe même sur lequel le mot de passe repose, le secret partagé, entraine deux vecteurs d’attaque :

• Données en transit – transmettre le secret régulièrement : le mot de passe peut alors fuiter/être volé via un proxy trop informatif dans ses logs, une mise en cache dans la mémoire partagée d’un Smartphone, ou des malwares de type keylogger.
• Données au repos – stocker le mot de passe entreprise pour le vérifier : l’utilisation de méthodes de stockage avec des niveaux de sécurité faible reste trop répandu (chiffrement réversible au lieu de hash non-réversible, protocole ancien type sha-1, pas de salage, ou pire, stockage en clair).

Et même des protocoles de hachage plus récents restent potentiellement faillibles face aux puissances de calcul actuelles. Par exemple, même avec un protocole récent de hashage type sha256, retrouver un mot de passe de 8 caractères depuis son hash prendra… moins d’une journée.

Les attaquants peuvent ainsi récupérer directement le mot de passe faisant fi de sa complexité (si ce n’est la longueur pour le brute force et le stockage si utilisation d’un protocole de hash récent, robuste et régulièrement mise à jour).

La place prépondérante de l’humain dans le système et sa capacité à commettre des impairs – error humanum est – a un impact encore plus important :

• Nous sommes de mauvais générateurs d’aléatoire : cela explique notamment les listes de mots de passe les plus courants paraissant chaque année. De plus, les contraintes de création trop fortes, réduisant les possibilités de variations, limitent la création de mot de passe différent, baissant le niveau d’entropie. La complexité devient contre-productive.
• Nous avons mauvaise mémoire : favorisant des pratiques abaissant le niveau de sécurité (utilisation d’un dérivé voir du même mot de passe – 63% des utilisateurs admettant cette pratique – post-it sur le bureau, fichier .txt non chiffré, etc.)
• Nous sommes faciles à tromper : le phishing, le spearphishing et l’ingénierie sociale sont ainsi des vecteurs d’attaque largement répandue et toujours très efficaces.

Si l’utilisateur fournit son mot de passe à l’attaquant, il ne fait aucune importance qu’il fasse 60 caractères de long ou soit composé de lettre de différents alphabets.

La complexité du mot de passe n’a ainsi pas d’influence pour les types d’attaque les plus courants, et n’induit donc que du désagrément pour l’utilisateur.

Que faire ?

Les problématiques autour des mots de passe n’étant pas récentes, il existe plusieurs solutions possibles et combinables pour réduire les problèmes et leurs impacts. La délégation de l’authentification vers des services tiers (social login, IAM d’entreprise, etc.), et la mise en place de Single Sign-On ont ainsi facilité les parcours utilisateurs et limité les rejeux / transitions du mot de passe et les endroits où le mot de passe est stocké au repos.

L’utilisation de seconds facteurs d’authentification (OTP SMS ou mail, notification push, hard tokens, etc.), les plus récents étant moins intrusifs et moins perturbateurs, est indispensable pour élever le niveau de sécurité.

En plus de ces solutions, déjà éprouvées et largement déployées, et dans l’attente d’être prêt à entrer dans le monde du passwordless qui représente un projet à part entière, le NIST et d’autres frameworks ont récemment révisé leurs recommandations concernant la complexité requise autour des mots de passe (NIST.SP.800-63b, 2017, NCSC UK, Password policy : updating your approach, 2018 par exemple).

Ainsi, d’un point de vue utilisateur, les contraintes sur les mots de passe ont été réduites à un nombre de caractères minimal (8) et la blacklist des mots de passe courant/compromis. En contrepartie, des mesures offrant plus de liberté à l’utilisateurs sont recommandés :

• Tous les caractères Unicode, incluant l’espace doivent être autorisés, sans être forcés
• La limite de taille maximale doit être au moins de 64 caractères
• Les rotations ne doivent plus se faire sur une notion de temps, mais uniquement en cas de compromission
• L’utilisateur doit avoir au moins 10 tentatives avant d’être bloqué
• Différents agréments de parcours sont à prendre en compte (information sur la complexité attendues, capacité d’afficher le mot de passe en cours de saisie, capacité de coller des valeurs)

Ces nouvelles recommandations visent à orienter les utilisateurs vers l’utilisation de mot de passe plus long et surtout plus aléatoires en réduisant les contraintes. Elles peuvent être accompagnées par la mise en place / la sensibilisation à l’utilisation de coffre-fort de mot de passe, évitant à l’utilisateur d’avoir à se souvenir de trop de mot de passe.

Les autres recommandations, indispensables pour ne pas abaisser le niveau de sécurité, affinent certains aspects précédemment évoqués. Ces mesures visent également à renforcer la transmission (chiffrement, etc.) et le stockage (hashage, salage) afin d’augmenter le niveau de sécurité des activités de l’entreprise et d’empêcher l’utilisation de certaines pratiques qui diminuent la sécurité (utilisation de questions secrètes pour la réinitialisation du mot de passe, etc.)

Conclusion

Si la disparition du mot de passe est un objectif, sa réalisation est encore loin d’être effective. Il est nécessaire, avant d’en arriver à ce Graal, de mettre en œuvre les mesures visant à la fois à sécuriser les données de l’utilisateur. Par exemple en implémentant de l’authentification multi-facteur sur les services sensibles, tout en facilitant les parcours et en encourageant l’utilisateur à se protéger lui-même. Cela passe par la mise en place d’éléments évitant à l’utilisateur de se connecter trop souvent ou de créer trop de mots de passe, mais également par une refonte de la complexité des mots de passe, afin d’augmenter la part d’aléatoire, et par une mise à niveau technique des moyens de transmissions et de stockage.

L’utilisation des processus existants pour préparer les facteurs de demain est aussi indispensable. Ainsi, refondre le parcours de récupération du mot de passe pour orienter l’utilisateur vers de l’authentification passwordless peut aider à une transition en douceur vers plus de sécurisation tout en améliorant l’expérience utilisateur.

Cet article L’évolution des règles de complexité des mots de passe du NIST : une étape indispensable en attendant un monde sans mot de passe ? est apparu en premier sur RiskInsight.

L’IAM est un concept ayant des impacts multiples. Cela doit être pris en compte lors de l’exécution d’un tel programme, afin d’éviter de tomber rapidement dans les problématiques courantes. Voyons cela de plus près.

Les défis d’un programme IAM : quelques exemples typiques

Les trois principaux facteurs qui imposent des exigences en matière d’IAM sont l’évolution des activités métier, la cybersécurité et l’expérience des utilisateurs. Cependant, les organisations entreprennent souvent des programmes IAM motivés, exclusivement ou principalement, par le désir de migrer vers une nouvelle solution. Avec la dette technique ou l’outillage comme seule véritable préoccupation, les programmes IAM peuvent être très rapidement confrontés à des problèmes.

1/ Impacts de la migration vers une nouvelle solution

Souvent, le désir est de simplement migrer vers un nouvel outil ou d’effectuer une mise à niveau majeure de la solution technique existante, tout en laissant tous les autres éléments du service IAM inchangés. Cela peut avoir des effets indésirables sur ces autres aspects. Par exemple, un nouvel outil entraînera probablement de nouveaux processus d’approbation, qui nécessiteront la formation du personnel à une nouvelle interface utilisateur. Il pourrait même nécessiter des processus de départ et d’arrivée entièrement nouveaux pour les RH. Ce point sensible se résume finalement à un manque d’évaluation de l’impact du changement technologique, dans le contexte d’un écosystème IAM plus large.

2/ Une liste d’exigences toujours plus longue

Lorsqu’une organisation réalise que le changement IAM ne se limite pas à l’outillage, cela peut souvent ouvrir les vannes à un nombre irréaliste de nouveaux objectifs. Les parties prenantes finissent par exiger davantage du programme (comme une meilleure expérience utilisateur et une intégration ITSM accrue), alors que ces nouveaux objectifs n’avaient pas été identifiés et pris en compte à l’origine. Le programme peut devenir un moyen d’exprimer le mécontentement à l’égard du service IAM existant, ce qui entraîne un glissement de périmètre. Cette dynamique peut rapidement mettre à mal le programme au niveau de la gestion du changement, du budget et de l’architecture de la solution.

3/ Forcer une mise en œuvre similaire

Une fois que les interactions entre la nouvelle solution IAM et ses services périmétriques sont pleinement opérationnelles, vous devez encore tenir compte des différences de philosophie de conception entre le nouvel outil et l’ancien. Les principales différences de conception des produits doivent être prises en compte. Si ce n’est pas le cas, les organisations peuvent finir par exiger un code personnalisé et des configurations complexes sur la nouvelle solution, simplement pour correspondre à l’ancienne configuration. Cela peut avoir un impact sur l’assistance du fournisseur, la maintenance, les performances globales – sans parler de la nécessité de conserver un énorme corpus de connaissances sur la personnalisation complexe. En empruntant cette voie, vous risquez de causer plus de problèmes que ceux que vous essayez de résoudre. Un véritable effet papillon peut donc se produire lorsqu’on essaie de forcer l’utilisation d’outils différents à des fins similaires.

La clé pour éviter ces problèmes courants est de reconnaître que l’IAM doit être considérée comme un sujet transversal, qui a un impact sur la technologie, les personnes et les processus.

Quelle est donc l’approche recommandée ?

La clé du succès est la reconnaissance du fait que l’amélioration de l’IAM est un programme de grande envergure. La mise en œuvre de nouvelles solutions n’est que la partie émergée de l’iceberg, et les impacts clés ne doivent pas être sous-estimés. Les points clés à considérer lors de la transformation sont :

• Le renouvellement de la solution IAM : le déploiement (ou la mise à niveau) de la nouvelle solution IAM. Cela comprend l’architecture de la solution, l’ingénierie et la migration technique.
• La modélisation des droits : les droits d’accès existants doivent être traduits dans le nouvel écosystème IAM, tels que les rôles métier et les profils d’application.
• Le nettoyage des données IAM : l’examination, le nettoyage et la validation de la fiabilité et de l’exactitude des données utilisateurs existants. Par exemple, la recertification du rôle d’un utilisateur et la validation de son supérieur hiérarchique pour s’assurer que la bonne personne approuve les demandes d’accès.
• Les nouveaux processus et la gestion du changement : cela inclut de nouvelles façons de demander et d’examiner l’accès aux applications, de nouveaux processus pour gérer les départs et les arrivées, et la formation du personnel.
• L’interopérabilité avec les autres services et actifs du SI : par exemple, l’intégration du nouvel outillage IAM avec le SOC peut nécessiter une réingénierie de l’ingestion des journaux dans le SIEM et des appels API. Un autre travail typique consiste à coordonner la migration avec celles liées à l’AD.

Nous recommandons donc de structurer le programme IAM de telle sorte que chacun de ces sujets soit couvert par un projet individuel. Le département en charge de la rédaction des politiques IAM doit opérer au niveau du programme, afin de fournir des inputs clairs permettant de guider les différents projets.

Un sponsorship fort et une vision publiquement partagée des objectifs sont également essentiels à la réussite. Les programmes IAM touchant de nombreux domaines organisationnels, il est essentiel que le gestionnaire de programme et la fonction PMO soient soutenus au niveau de la direction.

Enfin, la flexibilité est essentielle pour gérer l’évolution des circonstances et des contraintes. Voici d’autres conseils pour que le programme puisse rester sur la bonne voie et atteindre les objectifs prévus :

• Trouver un bon compromis entre les actifs hérités, la cible idéale et les capacités de la nouvelle solution : la cible doit être basée sur ce qui aide le mieux à fournir le service IAM de bout en bout à l’entreprise.
• Évaluez la possibilité d’intégrer des nouvelles solutions aux services existants, même s’ils ne sont pas envisagés à l’origine dans l’état cible idéal. Simplifiez et rationalisez dans la mesure du possible. Cela sera utile à la fois à court et à long terme.
• N’excluez pas la possibilité de conserver des outils existants qui devaient initialement être déclassés, si cela soutient les objectifs de l’IAM : il est parfois préférable de conserver certains actifs existants, plutôt que de déclasser et de migrer au nom de la modernisation technique.

Dans cet article, nous avons vu comment la définition des objectifs clés est essentielle pour la réussite du programme. Il est important de comprendre l’ampleur du changement IAM, à la fois pour structurer le programme et pour respecter les délais et le budget. Cette approche permettra également aux responsables du programme et à chaque responsable de stream de mettre en œuvre des mesures flexibles pour migrer d’un écosystème et d’applications legacy vers la nouvelle solution. Le tout sans perdre de vue les principes directeurs de la gestion des identités et des accès.

Cet article Gestion des identités et des accès : les clés d’un programme de transformation réussi est apparu en premier sur RiskInsight.

Transformation de l’IAM : quels sont les principaux moteurs ?

Les entreprises évoluent à un rythme effréné et la rapidité de mise sur le marché dépend fortement de systèmes informatiques reposant sur des services d’identité robustes et évolutifs. Qu’il s’agisse d’un nouveau service web disponible pour les clients, d’une expansion importante ou d’une fusion de back-office, la nécessité de faire évoluer les services IAM rapidement et efficacement est omniprésente.

Chez Wavestone, nous observons trois facteurs, souvent combinés, qui exigent davantage de la gestion des identités et des accès :

1. Les risques de cybersécurité
2. L’évolution des besoins métiers
3. L’expérience de l’utilisateur final

Examinons chacun de ces points plus en détail.

1/ Évolution des modèles de cybersécurité et de systèmes d’information

Les systèmes d’information sont de plus en plus ouverts et fragmentés. L’adoption du cloud et les architectures distribuées contribuent à ce changement fondamental. La sécurité adapte ses principes et la notion de zero trust est désormais bien établie. La gestion des identités et des accès est un élément clé du zero trust.

Les systèmes d’information sont consommés par des tiers, des clients et des employés. L’identité est essentielle pour l’échange de données critiques et la confidentialité entre diverses entités. Il est donc nécessaire de disposer d’une identité unique pour chaque entité dans l’ensemble du système d’information. Si les architectures évoluent, l’objectif ultime de l’IAM ne change pas : la bonne personne ou entité, avec le niveau de droits approprié, pour accéder à la bonne ressource, dans le bon contexte. Il est essentiel que ce principe soit respecté en permanence.

L’identité unique de chaque machine et de chaque utilisateur est également essentielle pour la traçabilité. Une organisation doit être en mesure d’identifier, d’authentifier et d’autoriser tout utilisateur, de toute autre entité, lorsqu’il accède à une ressource. Il est essentiel de pouvoir centraliser l’enregistrement, l’audit et le suivi de ces événements à travers le système d’information.

2/ L’identité au service de l’entreprise

Les entreprises subissent des transformations fondamentales qui exigent une plus grande agilité et des délais de mise sur le marché plus courts. Par exemple, de nombreux commerçants cherchent de nouvelles voies numériques pour accéder au marché en raison de l’évolution du paysage du commerce électronique et des défis opérationnels posés par la pandémie de COVID-19. Les services d’identité doivent être en mesure de soutenir des initiatives commerciales de grande envergure et d’assurer l’innovation à grande échelle.

L’évolution complexe de l’entreprise ne peut être ralentie par des délais de sécurité ou de livraison d’infrastructure prolongés. L’identité doit être un catalyseur, et non un synonyme de retard. Tout projet doit pouvoir s’appuyer sur des services d’identité qui sont fournis comme un produit de base à l’entreprise, et non pas nouvellement conçus et déployés pour chaque initiative.

La consolidation et la normalisation des solutions et processus IAM sont essentielles à la mise en œuvre de ce modèle. Il s’agit notamment d’une gestion cohérente et solide, qui dépend de méthodes et de protocoles agnostiques sur le plan technologique, basés sur les normes industrielles les plus récentes et les plus sûres (telles que SAML, OIDC et OAuth).

La fourniture de services d’identité doit être intégrée dans le modèle opérationnel de l’organisation et dans des pratiques telles que Agile, DevOps @ scale et innovation @ scale : l’IAM doit être fourni comme un service à l’entreprise.

3/ Les exigences en matière d’expérience utilisateur sont désormais au centre des préoccupations

Le troisième moteur, crucial, de la transformation de l’IAM est l’expérience utilisateur. Il s’agit pour les organisations de fournir aux employés la même qualité de services d’authentification et d’autorisation que celle dont les clients externes ont souvent bénéficié par le passé. L’objectif est de permettre aux utilisateurs finaux de prouver leur identité facilement et sans effort, et d’accéder aux services requis, en tout lieu et à partir de tout appareil. Cela constitue la base d’une véritable expérience continue qui soutient les nouveaux modes de collaboration, également accélérés par le travail à distance.

Des processus d’enregistrement faciles et fluides, ainsi qu’une authentification cohérente dans les différentes applications, doivent être proposés aux clients pour simplifier leur expérience et les fidéliser à la marque. Ce même principe vaut pour les employés et les tiers.

Les technologies sans mot de passe et les identifiants uniques pour les applications sont des exemples de solutions en plein essor ; des approches innovantes fondées sur le risque et le contexte peuvent rationaliser les accès, ce qui peut avoir un impact positif important sur l’expérience des utilisateurs en réduisant les demandes d’authentification.

Quelles sont les étapes de la transformation de l’IAM ?

La compréhension de votre maturité actuelle est une étape clé pour atteindre les objectifs ci-dessus. Au fil des années de soutien aux initiatives IAM de nos clients, nous avons construit notre parcours d’amélioration de la maturité IAM, qui comprend 4 étapes de maturité.

• Fragmenté : l’organisation n’a pas d’approche consolidée de l’IAM à travers les solutions, la gouvernance et les normes.
• Rationalisé : le paysage technologique soutenant l’IAM est simplifié et géré de manière centralisée afin de faciliter l’expérience utilisateur pour toutes les applications et tous les utilisateurs. La consolidation fournit des capacités de supervision satisfaisantes.
• Étendu : les capacités organisationnelles d’IAM sont adaptées à un système d’information en évolution : tout utilisateur, tout appareil, tout service.De nombreuses organisations disposent actuellement d’éléments de ces capacités, mais rarement déployés à l’échelle mondiale.
• Maîtrisé : l’organisation a adopté des solutions de nouvelle génération, qui offrent de solides avantages en matière de sécurité et une expérience utilisateur fluide, tout en réduisant la charge de travail des opérations informatiques grâce à une automatisation intelligente.A ce jour, ces solutions sont adoptées au cas par cas ou servent d’objectif dans les feuilles de route IAM.

Chacune des étapes ci-dessus nécessite une transformation profonde de l’environnement : changement de gouvernance, changement de processus, et déploiement ou migration des technologies de soutien. Pour réussir, nous pensons qu’elles doivent être abordées dans le cadre d’un programme de transformation IAM dédié.

Restez à l’écoute de notre prochaine publication, où nous partagerons avec vous ce qui est bon pour un programme de transformation IAM…

Cet article La gestion des identités et des accès de retour sur le devant de la scène est apparu en premier sur RiskInsight.

Nous poursuivons ici avec quelques questions – et réponses – complémentaires pour approfondir le sujet.

Combien de rôles dois-je créer ? Combien de rôles chaque utilisateur doit-il avoir ?

Il peut être tentant de concevoir un modèle qui permet de traiter l’ensemble des cas d’usage relevés lors d’une phase de collecte des besoins. Il faut toutefois avoir en tête que le modèle devra vivre et évoluer en fonction des nouvelles applications, des nouvelles unités organisationnelles…

Il n’y a pas de règle générale sur le nombre de rôles à attribuer à chaque utilisateur. Il est parfaitement envisageable de construire son modèle pour n’attribuer qu’un seul rôle par utilisateur, comme il est possible d’en attribuer plusieurs.

Il faut néanmoins trouver un compromis entre la création de rôles trop spécifiques, qui font vite tomber dans le « 1 rôle pour chaque utilisateur », et la création de rôles trop généraux qui n’apportent pas grand-chose et qui entraînent de la surallocation de droits.

Viser 80% de droits attribués via le modèle de rôles et 20% de droits discrétionnaires s’avère déjà un bel objectif.

Bottom Up ou Top down, quelle méthode adopter ?

Deux grandes méthodes sont envisageables lors de la création d’un modèle d’habilitation.

L’approche « Bottom Up » consiste à partir des droits existants et à les analyser pour en déduire un modèle. Par exemple, si tous les collaborateurs du service Comptabilité disposent des mêmes droits, on peut alors créer un rôle dédié à ce service qui contiendra les permissions correspondantes. Dans cette approche, la qualité des données est un prérequis à une modélisation réussie. De mauvaises attributions de droits viendraient en effet ajouter du bruit dans la modélisation et en réduire la pertinence.

L’approche « Top Down » commence par définir le modèle d’habilitation théorique, sur lequel on vient ensuite projeter les habilitations nécessaires. Ainsi par exemple, on peut créer un rôle pour le service Comptabilité et y inclure les permissions que des représentants Métier jugent nécessaire pour accomplir ses missions.

Dans les faits, il est courant d’adopter une approche intermédiaire.

Il est par ailleurs recommandé de travailler de manière itérative, et de valider son approche sur un périmètre pilote avant généralisation. L’implication du Métier dans la définition et la validation de la composition des rôles joue ici un rôle capital.

Comment m’outiller ?

La volumétrie conséquente de droits à traiter et les multiples itérations nécessaires impliquent l’utilisation d’un outillage qui peut être issu du marché ou bien développé en interne (tableaux Excel, base de données, scripts…). Une analyse préalable des besoins doit permettre de s’assurer de l’adéquation de cet outillage.

Au-delà des capacités de création de rôles ou de règles d’attribution de droits, de plus en plus facilités via l’utilisation d’algorithmes tirant parti du machine learning, l’outillage choisi doit notamment permettre de faciliter la mise en qualité des données en amont de la phase de modélisation. Il est également utile de prévoir une fonctionnalité de simulation qui permettra de mettre en évidence les sur- ou sous-allocations engendrées par le nouveau modèle par rapport aux affectations actuelles.

En mode nominal, les solutions IAM du marché offrent diverses possibilités dont il est possible de tirer parti : hiérarchie de rôles, attributions automatiques à la façon d’ABAC, attributions suggérées, dimensions de rôles multiples, etc. Il faudra cependant être attentif à ne pas tomber dans le piège d’un modèle trop compliqué à utiliser et à administrer.

Si le choix de la solution IAM qui supportera le modèle est déjà arrêté, il conviendra de s’assurer que ladite solution permet de prendre en charge toute la complexité souhaitée, quitte à procéder à quelques simplifications ou ajustements du modèle.

Dois-je construire mon modèle d’habilitation avant, pendant, ou après la mise en place de ma nouvelle solution IAM ?

D’une manière générale, il est préférable de concevoir son modèle d’habilitation en amont de la mise en place d’une nouvelle solution IAM. Ce cadrage peut en effet fortement influencer le choix de l’outil, en fonction de l’adéquation des possibilités techniques et des attendus fonctionnels.

Si la qualité des données est satisfaisante, l’implémentation du modèle à proprement parler peut alors se dérouler en même temps que la mise en place de l’IAM. Au besoin, il est envisageable de prévoir une phase de transition où l’ancien outillage peut cohabiter avec le nouveau. Les périmètres prêts pour le passage au nouveau modèle sont ainsi traités dans le nouvel outil, ce qui donne plus de temps pour la migration des périmètres plus compliqués ou qui nécessitent plus de travail. Un planning de migration doit alors être défini et suivi de près pour éviter toute dérive qui prolongerait cette situation.

Combien de temps dois-je prévoir ?

Les projets de mise en place d’un modèle d’habilitation sont en général conséquents. Ils nécessitent la prise en compte de nombreux facteurs et ont un impact important sur l’ensemble des parties prenantes des habilitations (responsables applicatifs, support aux utilisateurs, Métiers…).

D’une part, il est capital de prendre son temps lors de la phase de cadrage des attentes et de conception afin d’assurer la réussite de son projet.

D’autre part, la phase de modélisation peut s’avérer longue et fastidieuse, particulièrement si la volumétrie est importante (en termes de nombre de rôles ou en nombre d’entités à couvrir) ou bien si la qualité des données de base n’est pas satisfaisante et nécessite de la remédiation.

Enfin, la gestion du changement n’est pas à négliger, eu égard aux impacts bien visibles par les utilisateurs. Des formations et une phase de support renforcé sont la plupart du temps nécessaires une fois le modèle mis en place.

Quelle gouvernance mettre en place pour faire vivre mon modèle d’habilitation ?

Le modèle d’habilitation n’est pas statique. Le catalogue des habilitations vit au gré des nouvelles applications, des décommissionnements, des évolutions SI ou Métiers et des réorganisations. Dès la phase de conception, une réflexion sur les principes de gouvernance courante est nécessaire afin de ne pas construire un modèle trop complexe et impossible à maintenir dans le temps.

Si la gestion du modèle est souvent prise en charge par une équipe dédiée aux habilitations, l’implication des autres parties prenantes est essentielle, notamment du côté du Métier qui doit faire part des évolutions de ses besoins. La désignation de correspondants habilitations au sein des directions métiers peut être un moyen de favoriser cette participation.

En conclusion

L’implémentation parfaite d’un modèle d’habilitation n’existe probablement pas. Même s’il n’y a pas d’interdit majeur, la recherche d’un compromis entre attentes et possibilités reste un exercice délicat qui nécessite réflexion, préparation et suivi poussés.

En synthèse, voici 5 bonnes pratiques pour la réussite d’un projet de refonte de son modèle d’habilitation :

1. Prévoir suffisamment de temps pour le projet.
2. Cadrer et piloter avec la plus grande attention pour éviter les dérives en termes d’ambition, de priorités, de charges ou de délai.
3. Communiquer vers, et impliquer les bons contributeurs IT et Métier.
4. Savoir dire « non » lorsque la couverture d’un besoin risquerait de trop détériorer la simplicité d’utilisation ou la capacité de maintenance.
5. Ne pas négliger la conduite du changement auprès des utilisateurs.

Notons que ces bonnes pratiques restent parfaitement applicables à tout projet IAM en général !

Cet article Refondre son modèle d’habilitation : les questions essentielles (2/2) est apparu en premier sur RiskInsight.

DAC, RBAC, OrBAC, ABAC ou encore GraphBAC ? Les modèles d’habilitation phares évoluent régulièrement et apportent chacun leur lot d’enjeux, de promesses et de complexité.

Depuis une vingtaine d’années au cours desquelles les modèles RBAC/OrBAC semblent s’être imposés, les difficultés de conception, d’implémentation et de maintenance d’un modèle d’habilitation sont restées les mêmes, et rares sont les exemples de réalisation parfaitement satisfaisants.

Vouloir refondre son modèle d’habilitation amène à se poser beaucoup de questions. Nous essayons au travers de deux articles de répondre aux plus fréquentes.

Mais avant cela, revenons sur quelques notions de base concernant les modèles d’habilitation.

Qu’est-ce qu’un modèle d’habilitation ?

Une couche d’abstraction…

Un modèle d’habilitation est une couche d’abstraction qui vient se placer au-dessus des permissions techniques (droits applicatifs, transactions, groupes…). Elle est constituée d’objets soigneusement définis (rôles, permissions…), disposant d’un nom en langage naturel, et souvent organisés hiérarchiquement.

…qui simplifie la gestion des habilitations…

Cette couche d’abstraction permet notamment de rationaliser le nombre d’objets à manier.

Pour le Métier, il devient plus facile de comprendre les habilitations disponibles et de demander ou valider les droits adéquats.

Pour les équipes IT et le support, la charge d’attribution des habilitations s’en retrouve globalement réduite. La mise en place d’outils d’automatisation peut prendre en charge une grande partie des demandes quotidiennes, ce qui permet de traiter les demandes spécifiques avec plus d’attention.

… et améliore la sécurité

Au-delà de la dimension réglementaire et normative de la maîtrise des habilitations, souvent rappelée par les Commissaires aux Comptes lors de leurs audits, le manque de contrôle des habilitations est une porte ouverte aux intrusions et aux mauvaises utilisations du SI.

La connaissance de ses habilitations est un prérequis à leur sécurisation, et la mise en place d’un modèle permet de simplifier les contrôles, notamment lors des campagnes de revue. Il est en effet bien plus aisé pour un manager de valider l’attribution d’un rôle métier parlant, que celle d’une transaction à la dénomination très technique.

Panorama des modèles possibles

DAC : Discretionary Access Control, ou pas de modèle !

Et si le meilleur modèle était l’absence de modèle ? Dans certains cas limités, en particulier si le nombre de permissions ou d’utilisateurs est très restreint, on peut très bien se passer de concevoir un modèle qui viendrait ajouter une couche de complexité non nécessaire. Cela suppose néanmoins que les permissions applicatives soient suffisamment explicites.

RBAC : Role-Based Access Control

Le modèle RBAC permet de regrouper en « rôles » les habilitations nécessaires à l’exercice d’une fonction au sein une entreprise (métier, mission, projet…). Ces rôles sont alors attribués en lieu et place des habilitations discrétionnaires. Ils peuvent être organisés hiérarchiquement, par exemple en subdivisant des « rôles métier » en « rôles applicatifs ».

OrBAC : Organization-Based Access Control

Le modèle OrBAC est une variante du modèle RBAC dans laquelle les entités qui composent une entreprise sont un des axes de modélisation. Chaque utilisateur a alors un ou plusieurs rôles en fonction de son appartenance à une direction, un service ou une équipe.

ABAC : Attribute-Based Access Control

L’attribution des habilitations via le modèle ABAC se fait grâce à un ensemble de règles qui se basent sur des attributs liés aux utilisateurs, aux ressources elles-mêmes, ou bien à l’environnement. Cette attribution est souvent « dynamique », c’est-à-dire que l’autorisation ou non d’accéder à une application ou une partie d’une application est évaluée au moment où l’utilisateur tente d’y accéder. Dans les faits, il est possible de mettre en place un modèle ABAC tirant parti des rôles d’un utilisateur, comme dans le modèle RBAC.

GraphBAC : Graph-Based Access Control

Le modèle GraphBAC ou GBAC repose sur la représentation des habilitations à l’aide d’un graphe liant entre eux des objets (fichier, compte utilisateur, …) grâce à des relations diverses (lien entre manager et managé, appartenance à une structure, possession d’un fichier…). Les habilitations sont alors le résultat de requêtes sur ce graphe, ce qui permet de donner accès à une ressource suivant sa relation avec d’autres objets.

Vision du marché

Le tableau ci-dessous compare de manière très synthétique les différents modèles d’habilitation que nous venons de voir.

Les questions les plus fréquentes sur les modèles d’habilitation

À quoi doit servir mon modèle d’habilitation ?

La mise en place d’un modèle d’habilitation peut s’avérer complexe, coûteuse et chronophage. Il est donc crucial d’étudier en profondeur les besoins et de définir clairement ses attentes. Comme évoqué en introduction, la mise en place d’un modèle d’habilitation peut permettre de répondre aux enjeux de sécurité des accès, aux enjeux réglementaires, mais également de simplifier l’expérience utilisateur et d’améliorer l’efficacité des processus IAM (Identity & Access Management). Un des facteurs clés de succès d’un projet de modélisation des habilitations réside dans la capacité à exprimer ses attentes précisément, à l’aide d’indicateurs chiffrés le cas échéant : réduire le temps nécessaire à la création des accès par un manager lors de l’arrivée d’un collaborateur à 15 min, atténuer 90% des risques considérés critiques, etc.

Qui impliquer pour construire, instancier et faire vivre mon modèle ?

Vu le caractère transversal et l’ampleur de la transformation induite par un changement ou une création de modèle d’habilitation, il est nécessaire de prévoir une gouvernance forte.

Il est préférable d’impliquer un sponsor à forte visibilité auprès du COMEX, qui saura apporter son appui, et qui permettra d’obtenir une adhésion forte de la part du Métier, premier concerné par les changements, et des responsables applicatifs, qui seront fortement sollicités lors de la conception et de la mise en œuvre. On peut également identifier des relais clés, qui viendront apporter leur aide au sein des différentes équipes de l’organisation (RH, DSI, Contrôle Interne…).

Au-delà de la phase projet, il faut également identifier les acteurs qui seront en charge de faire vivre le modèle. Un facteur clé de succès de la mise en place d’un modèle d’habilitation est l’identification des propriétaires des rôles. Si chaque rôle ne comprend que des permissions d’une seule application, on peut facilement se tourner vers le responsable d’application, mais dans la plupart des cas, chaque rôle est composé de permissions provenant d’applications diverses.

L’idéal est de trouver une personne qui a à la fois la connaissance des processus métiers, de l’organisation de l’entreprise, des applications, et une compréhension des règles de sécurité : c’est un exercice difficile ! À défaut, une petite équipe combinant les différentes expertises doit permettre d’assurer cette fonction.

Dois-je couvrir les « droits fins » ? Les « périmètres » ? Quelle granularité pour mon modèle ?

Le monde des habilitations est aussi vaste que la multitude des applications existantes, et les cas d’usage qu’un modèle d’habilitation doit couvrir sont nombreux.

La question des droits fins et de la gestion des périmètres revient régulièrement sur la table lors de la phase de conception. Faut-il, ou non, les inclure dans son modèle ? Il n’existe pas de réponse prédéfinie.

Il est parfaitement envisageable dans certains cas de n’inclure dans le modèle que l’accès à l’application, et de laisser la gestion des droits fins et des périmètres à la main du responsable applicatif et de son équipe, en précisant uniquement les accès demandés dans un champ libre lors de la demande. On perd alors en auditabilité, mais on gagne en simplification de la gestion des demandes.

Si l’on décide d’inclure la notion de périmètre, il faut alors choisir entre une implémentation croisée, dans laquelle on crée autant de droits que de croisements permission-périmètre, ce qui risque de créer un nombre important de rôles, et une implémentation séparée, où on crée d’une part les permissions, et d’autre part les périmètres.

Il est probablement préférable d’aborder le problème séparément, quitte à créer les rôles combinés avec leur périmètre dans un second temps, en fonction des usages identifiés : le modèle qui en découle a ainsi une volumétrie plus limitée.

Que dois-je inclure dans mon modèle ? Quid des accès physiques et des assets physiques ?

Inclure l’ensemble des habilitations au sein de son modèle est extrêmement difficile, voire impossible, d’une part au vu de la grande diversité des cas existants, d’autre part pour des raisons d’efficacité du projet.

Il faut sans cesse garder en ligne de mire l’objectif de la mise en place d’un modèle. Ainsi par exemple, si le but est l’amélioration de l’expérience utilisateur lors des demandes de droits, il vaut mieux prioriser le traitement des permissions orientées vers le métier, qui seront susceptibles d’être attribuées fréquemment, par rapport à des permissions techniques peu utilisées.

Par ailleurs, il peut être tentant d’inclure dans son modèle d’habilitation les accès physiques (locaux, salles spécifiques…) ou les assets physiques (badge, PC, téléphone…) car ils font partie – au même titre que les accès logiques – des moyens dont doivent disposer les collaborateurs pour travailler.

Ici encore, il n’y a pas d’interdit majeur, et des sociétés gèrent par exemple les accès à leurs locaux au sein de leur modèle d’habilitation. Néanmoins, en règle générale, les accès et assets physiques n’en font pas partie en tant que telles.

Pour autant, la solution IAM peut contribuer à leur bonne gestion avec par exemple :

• Un rôle de centralisateur de demandes, envoyées à différents acteurs ou systèmes lors de l’arrivée d’un collaborateur. Ce « package d’arrivée » comporte alors aussi bien des accès logiques (comptes et droits par défaut) que des ressources physiques.
• Un rôle de référent des données et évènements relatifs à une personne. Ces informations, en particulier les dates d’arrivée/départ sont partagées avec les systèmes de gestion des badges pour en gérer le cycle de vie.

Nous venons d’aborder quatre premières questions pour mener à bien un projet de refonte de modèle d’habilitation. D’autres questions seront détaillées dans un second article, à venir très prochainement.

Cet article Refondre son modèle d’habilitation : les questions essentielles (1/2) est apparu en premier sur RiskInsight.

Quels besoins pour l’IAMoT ?

Il est possible de définir l’IAM comme une discipline permettant de « donner les bons droits, aux bonnes personnes, aux bons moments ». L’IAMoT vient ajouter une composante à cette définition pour permettre de « donner les bons droits, aux bonnes personnes et aux bons objets, aux bons moments ».

Mettre en œuvre des solutions pour permettre une gestion adaptée des identités des objets connectés se traduit donc par le besoin de prendre en compte :

• La gestion des identités des objets et de leur état (voir l’article détaillant le cycle de vie des objets) ;
• La gestion du contrôle d’accès et des habilitations :
  • des objets sur le SI et sur ses données ;
  • des objets sur les autres objets et leurs données ;
  • des employés/partenaires de l’entreprise sur l’objet et ses données ;
  • des clients finaux sur l’objet et ses données ;
• La gouvernance des identités des objets et la pertinence des droits associés dans le temps.

Tout comme pour l’IAM, pour chacun de ces domaines, il va être nécessaire de définir des processus, une organisation associée et des outils adaptés aux contraintes technologiques du projet.

La question est donc maintenant : vers quelles solutions s’orienter pour répondre à mes besoins ?

Des plates-formes IoT orientées connectivité et gestion de flotte

Le premier réflexe est de se tourner vers les services que peuvent fournir les plates-formes de gestion d’objets connectés.

En étudiant ces plates-formes plus en détail, nous avons fait le constat que leur priorité est déjà de couvrir les services essentiels pour la gestion de la flotte des objets connectés :

• gérer la connectivité multi-protocolaire des objets avec le SI de l’entreprise (SigFox, LoRa, 3/4/5G…) ;
• maîtriser l’inventaire des objets déployés et en assurer la configuration ou la mise à jour via un module de « Device Management » (LWM2M, OMA-DM, TR-069/CWMP…) ;
• permettre la remontée et la mise à disposition des données générées par l’objets (DTLS, CoAP, MQTT, AMQP…).

Ces fonctions s’accompagnent de solutions techniques d’authentification de l’objet sur les plates-formes mais celle-ci n’offrent aucune opportunité de couverture des besoins métier.

Dans ce cas, que font les acteurs traditionnels de l’IAM et du CIAM ? Puis-je me tourner vers leurs solutions qui sont aujourd’hui orientées sur la couverture des besoins des utilisateurs ?

Des marchés IAM et CIAM en mutation pour couvrir une infime partie du besoin IoT

Les éditeurs historiques de solutions IAM et CIAM ont compris l’énorme opportunité que représente l’IAMoT et orientent progressivement leurs offres et le discours associé sur ce marché. Néanmoins, nous constatons qu’ils ne couvrent encore que très partiellement les besoins identifiés ci-dessus et que selon leur capacité à innover le délai de mise en œuvre des nouveautés pourra être important.

Forts de leurs savoir-faire technologiques, ils se concentrent aujourd’hui quasi-exclusivement sur le volet contrôle d’accès. Ils offrent ainsi des solutions pertinentes pour permettre l’authentification applicative des objets sur le SI et la délivrance de jetons d’autorisation dont la gestion du contenu relève encore d’un défi propre à chaque projet. Sur les autres volets de l’IAMoT tels que la gestion de l’identité et de l’état des objets, la gestion du modèle de rôles liant objets / utilisateurs / identités internes / identités externes, ou la gouvernance des droits dans le temps, il est urgent que leur offre s’étoffe.

Dès lors, comment peut-on couvrir des besoins IAMoT bien présents malgré les lacunes du marché ?

Une hétérogénéité des usages rendant complexe la normalisation des pratiques et la standardisation des solutions

La diversité des usages et donc des modes de fonctionnement des objets connectés est évidemment à l’origine de la difficulté des éditeurs à proposer une offre générique adaptée à ses clients. Mais les projets IoT sont là et il n’est pas envisageable d’attendre que le marché prenne forme.

Mais si l’harmonisation est actuellement impossible au niveau global du marché, un effort peut être consenti au niveau de l’entreprise afin d’essayer d’harmoniser les réponses pour l’ensemble de ses usages IoT. Ainsi tout en cherchant à tirer parti de ce que propose le marché IAMoT, il est nécessaire d’envisager le développement modulaire des briques manquantes et en priorité celles ayant trait à la gestion des relations « objets / utilisateurs / identités internes / identités externes ». Attention toutefois à ne pas succomber aveuglement à l’utilisation des frameworks bas-niveau propriétaires proposés par les plates-formes IoT. Chacun devra être vigilant à conserver un niveau d’abstraction et d’autonomie suffisant pour ne pas être lié ad vitam æternam à un éditeur unique. Ce point d’attention est d’autant plus important dans un marché peu mature et en explosion où les bonnes idées se font et se défont.

Que faut-il retenir ?

Aucune solution du marché ne couvre l’intégralité des besoins fondamentaux de l’IAM of Things. Les plates-formes IoT se limitent aux fonctions de connectivité des objets, de gestion de flotte et de remontée de données. Les plates-formes IAM et CIAM n’offrent quant à elles que des réponses technologiques aux besoins d’authentification et d’autorisation.

Afin de combler les manques, chaque entreprise devra évaluer le besoin de se lancer dans le développement de ses propres modules applicatifs. Un effort tout particulier devra être entrepris pour atteindre un niveau adapté de généricité des modules pour l’ensemble de leurs usages et d’indépendance vis-à-vis des solutions éditeur.

Cet article IAM of Things, un marché émergeant mais un besoin déjà présent est apparu en premier sur RiskInsight.

L’administration, point névralgique de l’architecture réseau

L’administration d’un SI est essentielle pour garantir sa disponibilité et sa sécurité. Dans un programme de sécurisation d’un SI, il convient de prendre en compte les objectifs que l’on souhaite atteindre afin d’obtenir le modèle le plus adapté. Dans notre cas, les bonnes pratiques que nous observons sur le terrain consistent à :

• Créer un réseau d’administration isolé du réseau de production et étendu à la fois en central et localement pour protéger les flux d’administration afin d’éviter des pertes d’intégrité sur des flux de pilotage d’opérations sensibles ;
• Protéger les équipements d’administration pour éviter une prise de contrôle directe de ces éléments critiques par un attaquant ;
• Homogénéiser au maximum les pratiques et standardiser les équipements afin de faciliter les déploiements d’une architecture d’administration sécurisée voire centralisée, et le maintien dans le temps du niveau de sécurité – cela pouvant se faire en mutualisant les ressources dans une équipe centrale et dédiée.

Attention, nous ne traitons ici que l’administration de l’infrastructure des SI Industriels. L’administration des automates, par exemple, est faite par le métier pour ce qui est de la configuration et passera par le poste de configuration et de maintenance dédié, en cas de besoin de mise à jour.

La première étape consiste à créer la structure du réseau d’administration isolé et étendu. Cet objectif peut être atteint au travers des mesures suivantes :

• Dans une optique d’optimisation et de mutualisation des ressources, le réseau d’administration est construit autour d’un ou plusieurs datacenters, notamment pour assurer le DRP[1].
• Afin de réduire le risque de propagation par rebond depuis un site infecté, le réseau WAN[2] mis en place entre le datacenter et les sites industriels peut être configuré en hub and spoke[3] pour assurer une isolation entre chaque site.
• Pour pouvoir garantir l’intégrité et la confidentialité des flux d’administration, ceux-ci doivent être isolés au sein d’une VRF[4] spécifique ou d’un réseau VPN[5] d’administration entre le datacenter et chaque site. La mise en place de ce réseau dédié à l’administration se fait notamment par l’utilisation d’équipements télécom, de sécurité et d’interfaces dédiées sur les serveurs.
• Pour les sites les plus importants, le risque d’intrusion depuis le LAN utilisateur peut être réduit par la mise en place d’un LAN[6] d’administration accessible uniquement depuis le LAN d’administration du datacenter. Une telle architecture doit cependant prévoir une solution de résilience dans le cas où le WAN venait à être coupé pour permettre aux sites d’y accéder directement mais aussi pour les équipements qui ne sont tout simplement pas maintenables à distance.
• Les entreprises ayant de nombreux sites peuvent également utiliser un boitier standardisé embarquant toutes les fonctions de sécurité nécessaires à l’interconnexion d’un site. Cela facilite en effet la configuration et le maintien en conditions de sécurité.

Figure 1 – Schéma d’interconnexion d’un site standard ou avec SCADA

La deuxième étape consiste à brancher les équipements d’administration et les équipements à administrer sur ce réseau en les protégeant d’une compromission.

Figure 2 – Schéma d’interconnexion d’un site autonome

Il arrive également d’avoir une partie du SI complétement déconnectée pour des raisons diverses. Ce SI étant déconnecté, il ne présente pas de risque SSI mais uniquement un risque métier. Son état déconnecté abaisse cependant son niveau d’exposition et donc le risque d’intrusion. Il est donc opportun de réaliser une analyse de risques pour décider de la façon de procéder. Les moyens seront alors adaptés en allant d’une simple procédure d’administration locale jusqu’à la mise en place d’une infrastructure d’administration dédiée, celle-ci pouvant se révéler coûteuse.

Ces différentes briques réseau permettent ainsi aux administrateurs centraux d’accéder aux équipements. Il faut cependant leur donner accès aux outils nécessaires.

L’outillage des administrateurs, comment prévoir leurs besoins en garantissant la sécurité

La gestion des SI de Gestion et Industriel étant généralement distincte, l’outillage mis en œuvre est dédié, bien qu’il puisse s’appuyer sur des produits identiques. La mise en place de cet outillage va permettre de répondre à plusieurs objectifs :

• Assurer le contrôle d’accès sur les interfaces d’administration pour réduire la probabilité d’obtention de capacités d’attaque et d’utilisation frauduleuse des outils ;
• Tracer les actions des administrateurs pour réduire les impacts potentiels d’une attaque en se créant des moyens de détection et réaction et en assurant la facilité d’investigation à posteriori.

Cela se traduit par la mise en œuvre d’une chaîne d’administration.

Figure 3 – Schéma de principe de la chaîne d’administration

Afin de centraliser les accès et de maintenir un contrôle fin sur les autorisations, un bastion d’administration doit être mis en place. Les comptes génériques sont joués par le bastion et protégés dans son coffre-fort numérique. Le bastion assure également la traçabilité des actions et diminue le risque de vol de comptes à privilèges génériques. Le bastion peut également sécuriser les flux d’administration en réalisant de la translation de protocole (Telnet[8] vers SSH[9] par exemple).

Pour les équipements ayant un niveau de maturité sécurité suffisant (gestion fine des droits, traçabilité, comptes nominatifs), il peut être envisagé d’assurer leur administration directement, sans passer par un bastion (cela peut notamment être le cas pour des équipements télécom).

La mise en place d’un poste d’administration dédié, où seront installés les outils nécessaires au Métier, nécessite la mise en place d’un processus d’installation de ces outils afin de maintenir le niveau de sécurité de ce poste mais aussi de connaître la liste des outils déployés sur le SI.

La prise en compte des mainteneurs externes

Enfin, il est primordial de sécuriser l’accès des tiers mainteneurs afin de limiter les risques provenant d’accès abusifs ou non cadrés (infection du SI après installation d’un outil non validé, perte de donnée liée à un tiers malicieux, indisponibilité des équipements, …).

La mise en œuvre d’un point d’accès externe avec une authentification forte est nécessaire afin de garantir l’identité des utilisateurs. Ce point d’accès permet aux mainteneurs d’accéder à un poste de rebond maîtrisé et durci par le client tout en assurant la traçabilité des actions. Sur ce point, les clients les plus avancés mettent en œuvre des solutions permettant de ne donner accès au SI que durant la durée de l’intervention et cela uniquement après validation interne.

Les postes de configuration et de maintenance, dédiés au site et aux automates, doivent quant à eux faire l’objet d’un suivi particulier pour être mis à jour et rester en conditions de sécurité, notamment pour ce qui est des outils déployés.

Pour aller plus loin, on peut s’intéresser au Groupe de Travail de l’ANSSI[12] sur la Cybersécurité des Systèmes Industriels et à son référentiel PIMSEC[13] qui recommande un certain nombre d’exigences de sécurité à appliquer contractuellement à ses prestataires intervenants sur le SI Industriel.

Nous avons à présent une connaissance de nos équipements et des solutions pour les sécuriser et les administrer. Cependant, les enjeux de cybersécurité évoluent dans le temps, il est donc primordial de garantir un niveau de sécurité dans le temps et de déployer des moyens de détection adéquats. Comment ? Ce sera le sujet de notre prochaine article !

[1] Disaster Recovery Plan i.e. Plan de Reprise d’Activité.

[2] WAN i.e. Wide Area Network.

[3] Réseau Hub and Spoke i.e. Réseau en étoile autour du data center.

[4] Virtual Routing and Forwarding i.e. un plan de routage virtuel.

[5] VPN i.e. Virtual Private Network.

[6] LAN i.e. Local Area Network.

[7] VLAN i.e. Virtual Local Area Network, ou Virtual LAN

[8] Telnet i.e. Terminal Network, Telecommunication Network ou encore Teletype Network

[9] SSH i.e. Secure Shell

[10] RDP i.e. Remote Desktop Protocol

[11] Loi de Programmation Militaire servant à identifier et sécuriser les organisations et les SI d’Importance vitale.

[12] ANSSI i.e. Agence Nationale de la Sécurité des Systèmes d’Information.

[13] PMSEC i.e. Référentiel d’exigences de sécurité pour les prestataires d’intégration et de maintenance de Systèmes Industriels.

Cet article Saga (2/3) – Retours d’expérience et bonnes pratiques pour protéger et maintenir en condition de sécurité des SI industriels est apparu en premier sur RiskInsight.

UMA2.0 : une extension d’OAuth2

Avant de creuser davantage le sujet, le point important à garder en tête est le fait que UMA2.0 a été conçu comme un nouveau type d’autorisation d’OAuth2 et non comme un nouveau protocole. Si vous êtes déjà familier avec OAuth 2.0, vous pourrez comprendre UMA2 en moins de 10 minutes. Je vous le promets !

Ci-dessous une illustration d’un flux typique d’UMA2.0 :

1. Le client initie une requête contre la ressource sans jeton ;
2. Le serveur de ressources sollicite un ticket auprès du serveur d’autorisation en lui envoyant les détails de la ressource demandée (champs d’application et identifiant enregistré de la ressource demandée) ;
3. Le serveur de ressources renvoie une réponse d’erreur incluant l’emplacement du serveur d’autorisation accompagné d’un ticket de permission ;
4. Le client demande en option un « Requesting Party Token » (RPT – considéré comme la forme personnalisée d’un jeton d’accès d’UMA) directement dans le terminal du serveur d’autorisation grâce au ticket de permission ;
5. Le client redirige l’utilisateur vers le endpoint d’autorisation du serveur d’autorisation pour demander un jeton. Le serveur d’autorisation interagit avec le demandeur pour rassembler tout ce qui est nécessaire pour prendre une décision d’autorisation (authentification, collecte des attributs, etc.) – vous allez vous rendre compte que ça nous semble familier !
6. Le serveur d’autorisation redirige l’utilisateur vers l’URI de redirection client (URI pour « Uniform Resource Identifier ») incluant un ticket de permission mis à jour – oui, je connais ça !
7. Le client demande un « Requesting Party Token » (RPT) contre le terminal du serveur d’autorisation grâce à un ticket de permission mis à jour – je m’en souviens maintenant… !
8. Les serveurs d’autorisation répondent avec le « Requesting Party Token » (RPT) et un « Persisted Claims Token » (PCT) (les détails suivent) – nous avons donc un code éphémère contre deux jetons, mmh, ça me semble vraiment familier…
9. Le client demande le serveur de ressources avec le « Requesting Party Token » (UMA2 recommande en fait de se conformer à la pratique OAuth2, de manière similaire au RFC 6750 ou au PoP)
10. Le serveur de ressources demande facultativement au serveur d’autorisation de valider le jeton demandeur de requête (en utilisant le terminal d’introspection OAuth2 – suivant « RFC 7662 Token Introspection » étendu par UMA2) ou peut le faire localement selon le format du jeton.

Voyez-vous le flux des codes d’autorisation ? Laissez-moi vous monter :

En effet, les étapes 5 à 8 sont TRES semblables à l’attribution du code d’autorisation d’OAuth2.

Si vous passez outre les approximations suivantes, il n’y a vraiment pas d’autres différences majeures :

• L’« Access Token » (AT) devient un « Requesting Party Token » (RPT) (un jeton avec des résultats d’introspection de jeton personnalisés) ;
• Le « Refresh Token » (RT) a maintenant un compagnon : le « Persisted Claims Token » (PCT) (qui est en fait une variante de la classe « refresh token ») ;
• Le code d’autorisation devient une sorte de ticket d’autorisation modifiable.

Donc effectivement, ce n’est pas la même chose : il y a quelques étapes à intégrer avant la partie surlignée et c’est conséquemment un peu plus long.

UMA2.0 : bien plus qu’OAuth2

A présent, User-Managed Access (UMA) a été conçu pour une raison. Et il ne s’agit pas de simplement renommer quelques artefacts OAuth2. Il y a quelques différences qui permettent à UMA2.0 de fonctionner au-delà des capacités standards OAuth2.

Examinons de plus près les différences :

• Étape 1-3 : Le client peut obtenir des informations de manière standardisée sur la manière d’obtenir un jeton (en particulier l’emplacement du serveur d’autorisation) en contactant la ressource avec une demande sans jeton alors que si l’on suit protocole OAuth2 RFC 6750, aucune information ne devrait être retournée par la ressource (un périmètre insuffisant pourrait être couvert seulement si un jeton était fourni).
• Etape 4 : Le client peut essayer d’obtenir un jeton sans se lancer dans une démarche impliquant l’utilisateur. Peut-être qu’aucune autorisation ou qu’aucun consentement de l’utilisateur ne soit nécessaire pour recueillir un nouveau jeton, ou peut-être qu’un jeton déjà délivré (le PCT) était suffisant pour obtenir celui-ci. Si cet appel réussit, vous passerez directement à l’étape 9 et ceci peut être comparé au flux d’assertion OAuth2 (« RFC 7523 JSON Web Token Profile »).
• Étape 5 : Seulement si nécessaire, l’utilisateur final est incité à interagir avec le serveur d’autorisation par l’intermédiaire de l’agent utilisateur, pour s’authentifier, recueillir des réclamations à son sujet, obtenir son consentement, etc. alors que dans OAuth2, l’agent utilisateur est sollicité même si aucune interaction n’est requise et même si cela peut nuire à son expérience utilisateur.
• Étape 8 : Un « Persisted Claims Token » (PCT) supplémentaire peut être remis au client afin de faciliter les livraisons de « Requesting Party Token » (RPT) ultérieures pour le même demandeur mais pour une ressource cible différente (alors qu’un « Refresh Token » (RT) ne ferait que rafraîchir un RPT pour une partie requérante et une ressource cible données).

Avant l’étape 1, une ressource peut enregistrer des endpoints sur un serveur d’autorisation d’une manière standard après l’autorisation fédérée pour UMA2.0 (mais cela pourrait être couvert dans un autre article).

La norme UMA2 permet de (et est en fait conçue pour) séparer le demandeur et le propriétaire de la ressource (alors que OAuth2 considère qu’il s’agit d’une seule et même personne). Cette différenciation nous permet de traiter davantage de cas d’usage que OAuth2 ne peut permettre par défaut :

• Un propriétaire de document peut le partager avec d’autres personnes ; par exemple, un patient peut partager des données médicales (différentes) avec son conjoint, ses proches ou son médecin ;
• Un propriétaire d’application peut concevoir des règles permettant à certains employés de l’entreprise (ou partenaires commerciaux) d’accéder à une application/API ;
• Un propriétaire de ressources peut agréger la gestion du partage des ressources sous un seul serveur d’autorisation, même si les ressources résident dans de nombreux domaines ;
• Une application peut obtenir des permissions supplémentaires et mettre à jour les portées des « Access Token » sans impliquer l’agent utilisateur dans une démarche OAuth2 si les politiques d’autorisation le permettent.

Toutes les permissions ci-dessus peuvent être accordées de manière asynchrone (alors que le consentement de l’utilisateur OAuth2 n’est synchrone que dans le flux de demande de jeton).

Merci à Eve Maler pour ses éclairages dans l’écriture de cet article!

Cet article Démystifions ensemble UMA2.0 est apparu en premier sur RiskInsight.

Pourtant, le volet IAM « Identity and Access Management » est souvent relégué au second plan dans les Programmes de mise en conformité LPM/NIS mis en œuvre par les Opérateurs d’Importance Vitale (OIV) / Opérateurs de Service Essentiel (OSE).

Comment comprendre cette situation et quelles leçons en tirer pour construire sa feuille de route IAM pour ses infrastructures critiques ?

L’IAM est un des piliers du volet cybersécurité de la LPM/NIS

Les mesures IAM à mettre en place sur les infrastructures critiques sont décrites dans les quatre règles suivantes :

Auxquelles il convient d’ajouter la règle portant sur les indicateurs (règle 20 pour la LPM et règle 4 pour NIS).

Les bonnes pratiques IAM habituelles à appliquer à tous les accès

Les exigences des trois premières règles reprennent les bonnes pratiques habituelles à appliquer à la gestion des comptes et des droits, tant pour les utilisateurs physiques que pour les processus automatiques accédant aux infrastructures critiques :

• Gérer le cycle de vie des utilisateurs, notamment les mutations et départs
• Affecter les droits selon le principe du moindre privilège
• Revoir (ou recertifier) régulièrement les droits affectés, a minima annuellement
• Contrôler et auditer les droits
• Attribuer des comptes et des moyens d’authentification strictement nominatifs

Le cadre ci-dessous résume les règles concernées :

Ces règles fixent un cadre mais laissent une grande liberté aux Opérateurs pour les décliner dans leur contexte.

Des comptes d’administration dédiés et soumis aux mêmes exigences

La quatrième règle (n°14 LPM et n°11 NIS) traite spécifiquement des comptes d’administration, destinés aux seuls personnels en charge de l’administration des infrastructures critiques : installation, configuration, maintenance, supervision, etc. L’exigence forte est la mise en place de comptes d’administration dédiés à la réalisation des opérations d’administration.

Au-delà du principe de moindre privilège explicitement mentionné, les comptes d’administration doivent respecter les mêmes exigences que les autres comptes telles que décrites précédemment.

Des indicateurs à produire pour surveiller les comptes à risque élevé

Enfin, la règle sur les indicateurs prévoit la définition de plusieurs indicateurs concernant la gestion des comptes présentant un niveau de risque élevé :

• Pourcentage de comptes partagés
• Pourcentage de comptes privilégiés
• Pourcentage de ressources dont les éléments secrets ne peuvent pas être modifiés

Au vu de ces exigences, l’intégration des infrastructures critiques dans les outils IAM (ci-après appelés « l’IAM ») de l’Opérateur apparaît comme la réponse nécessaire ; à compléter par l’application de mesures de durcissement (suppression, désactivation ou changement de mot de passe des comptes par défaut).

NB : les exigences LPM et NIS étant très similaires, nous emploierons par la suite le terme « OIV » pour désigner aussi bien les Opérateurs d’Importante Vitale et les Opérateurs de Service Essentiel, et le terme « SIIV » pour désigner les Systèmes d’Informations d’Importance Vitale et les Systèmes d’Informations Essentiels.

Pourtant, les Opérateurs hésitent encore à raccorder leurs infrastructures critiques à l’IAM

Les règlementations LPM et NIS ont accéléré la mise en place et le déploiement de solutions de bastion d’administration afin de sécuriser les accès d’administration. Cependant, bien que ces projets soient nécessaires, ils ne permettent de répondre que très partiellement aux exigences évoquées précédemment.

Ces règlementations devraient pourtant être un bon driver pour les projets IAM, mais les Opérateurs sont confrontés à deux principaux problèmes :

• La complexité d’intégration des systèmes industriels avec l’IAM – pour les Opérateurs industriels.
• Le risque induit par le raccordement des infrastructures critiques à l’IAM.

Des systèmes industriels complexes à intégrer

Les systèmes industriels présentent en effet des spécificités qui, d’une part complexifient le raccordement à un outil IAM, et d’autre part le rendent moins indispensable. Car, de façon générale :

• le nombre d’utilisateurs est limité ;
• ces systèmes sont cloisonnés, voire isolés du réseau d’entreprise ;
• la maturité sécurité des éditeurs et constructeurs est en retrait, les capacités d’interfaçage sont réduites, tant pour la gestion des comptes que pour la délégation d’authentification ;
• la granularité des droits d’accès est faible, se limitant souvent à autoriser l’accès ou non à l’ensemble du système, et non fonctionnalité par fonctionnalité.

Une intégration potentiellement génératrice de risques

Mais, au-delà de ces considérations propres aux systèmes industriels, les Opérateurs sont parfois réticents à mettre en place cette intégration, car elle est perçue comme génératrice de risques. En effet, si l’outil IAM ne présente pas un niveau de sécurité à la hauteur des règlementations, il pourrait paradoxalement constituer un point d’entrée sur les SIIV et ainsi amener de nouvelles vulnérabilités : création de compte ou attribution de droit illégitime, suppression malveillante de tous les comptes, etc.

Quant à mettre en place un IAM entièrement dédié au périmètre SIIV, cela représente un investissement très conséquent, parfois disproportionné, et qui ne permet pas de tirer tous les avantages d’un IAM mutualisé, par exemples les liens avec les sources autoritaires comme le SI RH.

Différentes approches d’intégration IAM permettent de répondre aux exigences règlementaires en maintenant un niveau de cloisonnement élevé

Dès lors, comment répondre efficacement aux exigences de la LPM et de la directive NIS ? Comment tirer parti des services proposés par les outils IAM sans ouvrir de nouvelle porte sur les infrastructures critiques ?

Nous distinguons différentes approches pour intégrer un système avec les outils IAM.

L’approche « délégation », à l’état de l’art mais fortement couplée

La première approche consiste à déléguer l’authentification et l’autorisation à l’IAM, en l’occurrence au service d’authentification et de contrôle d’accès, via un protocole de Fédération d’Identités (SAML2, OpenID Connect / OAuth2) ou via un raccordement Active Directory / LDAP.

Cette solution permet une gestion des comptes et des accès à l’état de l’art, mais rend le SIIV totalement dépendant de ce service et l’expose aux risques évoqués précédemment. Même en situation de crise, une isolation du SIIV serait difficilement envisageable.

Cette approche est donc plutôt à réserver aux applications qui fonctionnent déjà sur ce principe, typiquement les applications du SI de gestion avec un grand nombre d’utilisateurs. Pour les systèmes industriels, la solution à privilégier est de conserver le service d’authentification au sein du SIIV et d’opter pour une autre approche.

L’approche « provisioning », avec un niveau de couplage à ajuster au contexte

Cette approche consiste à conserver un système d’authentification et de contrôle d’accès propre au SIIV mais provisionné – c’est-à-dire alimenté – par l’IAM : les comptes et droits des utilisateurs sont stockés dans un référentiel interne au SIIV, et la solution IAM les gère au travers d’un connecteur. En fonction du niveau d’isolation souhaité, ce connecteur peut prendre différentes formes :

• Un connecteur automatique, permettant à l’IAM d’écrire directement les informations sur les comptes et accès dans le SIIV. Une isolation temporaire devient possible, en situation de crise ou en cas de détection d’activité anormale (par exemple : suppression massive de tous les comptes). Mais rien n’empêche un utilisateur malveillant ayant la main sur l’IAM de se donner accès au SIIV.
• Des ordres transmis aux administrateurs du SIIV (par ticket ITSM ou par mail) qui réalisent les actions manuellement. Un « sas » d’isolation est ainsi maintenu entre l’IAM et le SIIV, avec une étape de contrôle par les administrateurs.

Cette approche permet de bénéficier des processus de gestion des identités et des accès : validation et traçabilité des demandes d’accès, retrait des comptes et droits en cas de mutation ou de départ, etc. tout en préservant un degré de cloisonnement du SIIV.

L’approche « revue », orientée contrôle a posteriori

L’approche « revue » (également appelée « recertification ») se distingue des autres par le fait qu’elle repose sur une logique de contrôle a posteriori plutôt que de gestion a priori. Il s’agit cette fois d’analyser périodiquement les accès déclarés dans le SIIV afin de vérifier s’ils sont toujours légitimes. Cette vérification peut reposer sur un rapprochement des comptes avec un référentiel de collaborateurs (fichier RH, solution IAM, etc.), ou sur une validation explicite de la part des responsables des utilisateurs.

Ce peut être l’occasion de réaliser des contrôles approfondis (par exemple détection de combinaisons toxiques), de produire des indicateurs et des rapports d’audit.

Adapter son projet IAM – Infrastructures critiques à son niveau de maturité et à la typologie du SIIV

Sur la base de ces différentes options, nous proposons ci-dessous des pistes pour construire la feuille de route de mise en conformité LPM/NIS en fonction du niveau de maturité IAM et de la typologie des SIIV concernés.

Conserver la brique d’authentification et autorisation localement dans chaque SIIV

Il est préférable de conserver un référentiel de comptes et de droits d’accès localement dans chaque SIIV. Cependant, pour les systèmes déjà raccordés à un service mutualisé d’authentification et d’autorisation, le système mutualisé peut être conservé mais l’Opérateur doit lui appliquer les mesures prévues par la LPM et NIS : a minima le cloisonnement réseau, le durcissement, le maintien en conditions de sécurité, l’administration depuis un SI d’administration dédié, l’envoi des logs au SIEM, etc.

Dans un environnement de gestion des identités et des accès non mature, commencer par la revue des comptes et des droits

En l’absence d’outillage de gestion IAM mature, le moyen le plus rapide d’atteindre un premier niveau de maîtrise des risques et de conformité est de définir et mettre en œuvre un processus de revue régulière, sur une base a minima annuelle.

Sur un SIIV au nombre d’utilisateurs limité, le processus peut être déroulé manuellement, avec un niveau de qualité acceptable et une charge de travail raisonnable. Mais pour gérer des volumétries plus importantes, un outillage adéquat est à envisager : il facilite le pilotage des campagnes de revue et garantit la traçabilité des décisions. Il constitue en outre une opportunité pour envisager ensuite la mise en place d’un outil de gestion IAM.

Lorsqu’un outil de gestion IAM est en place, le sécuriser pour y raccorder les SIIV

Lorsque l’Opérateur dispose d’un outillage IAM mature, le provisioning des SIIV par l’IAM est recommandé : l’automatisation, la fiabilisation et la maîtrise que permettent les outils doivent compenser les risques induits par le couplage. A condition toutefois de garantir la sécurité de l’IAM : en complément des mesures techniques précédemment évoquées, l’Opérateur doit configurer l’IAM de sorte à ce que seuls les utilisateurs susceptibles d’accéder au SIIV peuvent demander l’accès, que le propriétaire du SIIV valide les demandes d’accès et puisse consulter facilement la liste des utilisateurs autorisés, et enfin que des contrôles permettent de détecter des anomalies sur les comptes et accès.

Le rehaussement de la sécurité profitera d’ailleurs à l’ensemble du Système d’Informations.

Trouver le bon équilibre risques / bénéfices pour construire son projet IAM – Infrastructures critiques

Ces propositions doivent permettre à tout Opérateur de construire sa feuille de route IAM pour ses infrastructures critiques en trouvant le bon équilibre entre les bénéfices apportés, les risques induits et le coût de mise en conformité.

Cet article Quelle approche pour gérer les identités et les accès sur les infrastructures critiques ? est apparu en premier sur RiskInsight.

Les objets connectés apportent de nouvelles perspectives pour l’évolution des processus et méthodes de travail des entreprises et utilisateurs. En effet, ces objets sont aujourd’hui en capacité d’interagir avec leur environnement pour échanger des informations ou exécuter des actions. Ces échanges se caractérisent notamment par des relations avec le système d’information de l’entreprise, les employés, les utilisateurs finaux et même les autres objets. Afin d’assurer la sécurité de ces échanges, il est absolument nécessaire de mettre en œuvre des mécanismes de contrôle d’accès, ce qui implique de connaître et de maîtriser les identités de l’ensemble des objets connectés du parc ainsi que celles des utilisateurs.

Cette discipline de gestion des identités est connue au sein des entreprises et rattachée au domaine de l’IAM (Identity & Access Management), c’est-à-dire la gestion du cycle de vie des identités des collaborateurs et partenaires (IAM traditionnel) ou des clients finaux (Customer IAM ou CIAM). Elle doit désormais se décliner sur le périmètre des objets connectés : c’est l’IAM of Things (IAMoT).

Figure 1 – IAM traditionnel, Customer IAM et IAMoT : trois domaines fortement liés

Un objet connecté, oui… mais avec quoi ?

Les interactions entre un objet connecté et son environnement peuvent être regroupées en 3 catégories principales.

1. Un objet connecté au SI de l’entreprise

C’est le premier cas d’usage qui vient à l’esprit. Chaque objet communique avec le SI via une identité unique qui le caractérise et des droits d’accès associés. Cela implique la mise en place de principes de création, de référencement, de gestion, de contrôle et de pilotage de ces identités. L’état d’un objet ou l’identité de son propriétaire doivent être connus à tout moment.

Dans une chaîne technologique type « objets – relais – plate-forme IoT – applications » la plate-forme IoT offre un point central permettant la gestion de l’ensemble des identités des objets.

Dans ce cadre, il est par ailleurs essentiel de maîtriser l’authentification des objets auprès des applications, et donc de définir les principes de génération des secrets qu’ils utiliseront.

Figure 2 – Chaîne technologique type

2. Un objet utilisé par les clients finaux

Pour ce type d’objets, une relation forte avec le domaine du Customer IAM apparaît. En effet, l’objet doit être en mesure de vérifier l’identité de l’utilisateur auprès du CIAM et de déterminer les services auxquels il a souscrit.

En cas d’usage partagé d’un même objet, un modèle de rôles et de données impliquant différents types d’utilisateurs finaux doit aussi être envisagé.

Prenons l’exemple d’un véhicule connecté :

• Le conducteur du véhicule souhaite accéder au service GPS. Avant de permettre l’accès au service le véhicule doit répondre à de nombreuses questions. Quelle est l’identité du conducteur et quel profil personnel dois-je utiliser (chargement des précédents trajets) ? Est-il propriétaire du véhicule, locataire ou s’agit-il d’un prêt pour un usage ponctuel ? Le conducteur a-t-il souscrit au service GPS auprès du fabricant et à quel niveau de service (calcul des trajets uniquement ou alerte des zones de danger) ?

3. Un objet en interaction avec les employés de l’entreprise et ses partenaires

Dernier cas, chaque objet peut interagir avec les employés de l’entreprise, des prestataires ou des partenaires. La relation avec le domaine de l’IAM traditionnel assurant la gestion des habilitations et des rôles des partenaires et employés de l’entreprise est alors essentielle.

Les différents usages de l’objet imposent la création d’un modèle de rôle permettant de répondre à la question : quels droits pour quelles populations sur quelles fonctionnalités de l’objet ?

Reprenons l’exemple d’un véhicule connecté :

• Lors d’une réparation un garagiste doit pouvoir, à des fins de diagnostic, visualiser les derniers indicateurs de fonctionnement d’un véhicule avant une panne. S’agit-il d’un garagiste du réseau constructeur ou d’un garagiste indépendant ? Peut-il accéder aux informations GPS ou uniquement aux indicateurs techniques du moteur ? Le client final peut-il consentir ou a minima être informé de l’accès aux données de son véhicule ?

Cet exemple met aussi en évidence le fait que les droits accordés peuvent être étroitement liés à la notion de temps (uniquement pendant la durée de la réparation) ou à la nature d’une donnée (protection de la vie privée dans le cas des données GPS).

L’IAM of Things, c’est aussi des processus

Tous les experts de l’IAM vous le diront : il n’y a pas d’IAM sans une étude approfondie du cycle de vie de identités concernées. L’IAMoT doit étudier l’ensemble des processus impliquant l’objet sur l’ensemble de son cycle de vie. En effet, tout au long de la vie d’un objet, la nature des interactions avec son environnement est amenée à évoluer selon l’état dans lequel il se trouve. Un objet neuf devra, par exemple, être associé à son utilisateur principal via un processus d’appairage assurant un niveau de confiance en cohérence avec les enjeux.

Appuyons-nous une dernière fois sur l’exemple du véhicule connecté :

• Un particulier vient de faire l’acquisition d’un véhicule connecté d’occasion auprès d’un autre particulier. Dans le cadre de cette revente, il est nécessaire pour le nouvel acquéreur de s’assurer que les accès aux services sont révoqués pour le précédent propriétaire. La détection de l’événement de revente doit donc déclencher un processus de désappairage de l’ancien propriétaire.

Figure 3 – Ingrédients pour la recette de l’IAM of Things

L’IAM of Things, une nouvelle discipline s’appuyant sur des concepts maîtrisés

Cet article met en évidence la problématique de la gestion des identités pour l’IoT et souligne les liens existant avec les autres domaines de l’IAM. Il est important de retenir que, même si les principes fondamentaux de l’IAM s’appliquent aussi à l’identité des objets connectés, des réponses adaptées à chaque contexte projet doivent être étudiées.

Cet article Qu’est-ce que l’IAM of Things ? est apparu en premier sur RiskInsight.

Comment l’idée vous est-elle venue ?

Georges Bote (ICARE Technologies) raconte que l’idée est venue au fondateur, Jérémy Neyrou « il y a 6 ans de cela, en perdant mes clés de voiture sur une plage Corse complètement déconnectée de tout réseau, après avoir parcouru près d’une dizaine de kilomètres en plein soleil d’été à pied », il imagine un « objet à la fois intuitif et autonome qui permettrait d’embarquer [le] trousseau de clés et [les] moyens de paiement ». C’est ainsi qu’est née Aeklys, « cette bague intelligente qui permet d’embarquer jusqu’à 28 fonctionnalités différentes ».

Quel est le plus grand risque de sécurité pour les banques et pour ses clients selon vous ? Comment répondez-vous à la menace qui pèse sur les banques ?

Georges Bote (ICARE Technologies) s’accorde également à dire que « la fraude à la fois bancaire et sur l’identité des personnes reste le grand risque pour les banques et leurs clients ». C’est pourquoi la bague connectée proposée par ICARE Technologies embarque un mécanisme de désactivation en cas de perte ou de vol, protégeant ainsi son propriétaire contre l’usurpation de ses moyens de paiement sans qu’il ne doive faire opposition d’une quelconque manière que ce soit.

L’enjeu pour les RSSI aujourd’hui est de parvenir à concilier la facilité d’implémentation, la simplicité d’utilisation des solutions de sécurité avec une technologie sécurisée. Comment convaincre un RSSI de la pertinence de votre solution et de la sécurité du produit ? Quels sont les différenciateurs qui vous démarquent sur le marché ?

ICARE Technologies explique que la pertinence de la sécurité de sa solution « réside dans notre technique et différentes certifications bancaires. Notre secure element dispose d’un niveau EAL6+ certifié par l’ANSSI, ce qui nous permet de travailler dans le domaine militaire en plus d’avoir un chiffrement en AES 256 bits ».

Quelles sont les synergies entre votre innovation et les solutions de sécurité bancaires existantes à l’heure actuelle ?

La force du produit d’ICARE Technologies réside dans son innovation et en sa sécurité : « de plus, il caractérise une nouvelle forme de liberté et de sécurité qui est fortement attractive pour les clients potentiels. L’intérêt est donc d’en faire devenir un objet « à la mode » de manière à orienter la connotation sociale de la bague comme une tendance ».

Les synergies existent et la technologie est actuellement en phase de test avec des partenaires bancaires et industriels pour travailler notamment sur la sécurisation de valises informatiques. Georges Bote annonce « la préparation d’un 2ème tour de table et de belles surprises pour notre Go To Market qui sera prévu le 1er trimestre 2019 ».

Pour en savoir plus : https://fr.icaretechnologies.com/

Cet article L’INTERVIEW D’ICARE TECHNOLOGIES – LA BAGUE INTELLIGENTE SECURISEE est apparu en premier sur RiskInsight.

Comment l’idée vous est-elle venue ?

Juliette Delanoë évoque l’importance de la transformation digitale des grands groupes : « de plus en plus de biens et services peuvent être souscrits ou consommés en ligne. En particulier, la vérification des identités en ligne est un enjeu fondamental pour que la révolution digitale soit vecteur de progrès durable pour la société ». La combinaison des expériences des fondateurs a permis de développer un produit permettant via le flux vidéo, d’identifier « et de protéger les individus dans le monde digital, en permettant d’y utiliser les documents d’identité physique régaliens de façon fiable, pratique, et respectueuse de la vie privée ».

Quel est le plus grand risque de sécurité pour les banques et pour ses clients selon vous ? Comment répondez-vous à la menace qui pèse sur les banques ?

Juliette Delanoë met en parallèle l’importance d’avoir des parcours digitaux agréables et rapides pour leurs utilisateurs et la nécessité d’en assurer la sécurité : « l’entrée en relation, étape très critique de l’expérience utilisateur, avait lieu il y a quelques années exclusivement en boutique, mais avec l’arrivée des néo-banques, et de la génération des millenials, cette étape se digitalise et s’automatise rapidement ». Il convient donc de conserver cette opportunité mais de faire attention aux enjeux sécuritaires qui se dessinent et notamment aux « nouveaux types de fraudes propre au digital qui se développent – comme l’utilisation de faux documents d’identité pour ouvrir un compte bancaire en ligne ».

L’enjeu pour les RSSI aujourd’hui est de parvenir à concilier la facilité d’implémentation, la simplicité d’utilisation des solutions de sécurité avec une technologie sécurisée. Comment convaincre un RSSI de la pertinence de votre solution et de la sécurité du produit ? Quels sont les différenciateurs qui vous démarquent sur le marché ?

Ubble propose aux RSSIs de tester la solution en partageant sa conviction profonde que « le mouvement (donc la vidéo) est indispensable à la vérification des visages comme des documents (hologrammes, reflets), et nous développons des technologies qui vérifient les identités non pas sur la base de simples images, mais sur un flux de vidéo en streaming ». En effet, les streams vidéo, la computer vision et le deep learning permettent d’éviter la fraude. Ainsi il n’est pas possible de « présenter un document d’identité qui soit une simple photocopie [ou …] d’utiliser le document de quelqu’un d’autre ». L’atout de la solution réside également dans une expérience utilisateur aisée et agréable pour un client de bonne foi.

Quelles sont les synergies entre votre innovation et les solutions de sécurité bancaires existantes à l’heure actuelle ?

Ubble explique : « nos technologies répondent à une faille sécuritaire nouvellement créée, que les solutions existantes n’adressent pas, ou seulement partiellement. Nos technologies sont en parfaite synergie avec les systèmes mis en place par les banques, et viennent s’ajouter pour combler la faille sécuritaire créée lors de la digitalisation et de l’automatisation de l’entrée en relation ».

Comment voyez-vous la banque de demain en 3 tendances ? Quelles opportunités pour la cybersécurité dans la banque de demain ?

Selon ubble, le futur verra l’apparition d’un nouveau rôle pour la banque : la banque de demain « sera un des services les plus sécurisé dans le monde digital ». La start-up prévoit ainsi que « la banque de demain [sera amenée à jouer] un rôle sécuritaire fort dans le monde digital en général. En tant qu’acteur de confiance qui connaît ses clients, elle pourra attester de leur identité auprès d’autres fournisseurs de services ».

Pour en savoir plus : http://www.ubble.ai

Cet article L’INTERVIEW D’UBBLE – VERIFICATION D’IDENTITE VIA LA VIDEO est apparu en premier sur RiskInsight.

Stop aux mots de passe !

S’authentifier, c’est prouver par un moyen convenu que l’on est bien la personne que l’on prétend être. Depuis l’Antiquité, le moyen le plus adopté et utilisé reste sans conteste le mot de passe. Il est cependant source d’agacement pour les utilisateurs et présente de nombreuses limites d’un point de vue sécurité.

Un sentiment partagé de « ras-le-bol »…
Nous avons tous une fois rêvé de ne plus devoir se rappeler quel mot de passe utiliser pour se connecter à nos applications préférées. Mais force est de constater que cela reste toujours un rêve.
La promesse de l’authentification unique est loin d’être tenue en entreprise et l’essor des coffres forts de mots de passe montre bien les difficultés rencontrées par les utilisateurs : multiplicité et pertinence relative des politiques de mot de passe, changement de mot de passe obligatoire, sans compter que réinitialiser son mot de passe peut relever du parcours du combattant.
Néanmoins, le principal avantage du mot de passe reste son côté universel et déjà inscrit dans les habitudes de tout un chacun.

… et un niveau de sécurité limité
De nombreux scénarios de cyberattaques s’appuient à un moment ou à un autre sur la compromission d’un mot de passe, de préférence celui d’un compte à privilèges, en utilisant différentes techniques : tests de combinaisons en grand nombre (brute force), interception de communication (Man-In-The-Middle), reconstitution du mot de passe à partir de son empreinte (Rainbow Table)…

Des mesures de sécurité pour se prémunir de ces attaques existent (chiffrement, hachage, salage, blocage du compte…) mais ne sont pas toujours implémentées systématiquement voire pas toujours de manière satisfaisante. Comme le dit l’adage, « Les mots de passe sont du point de vue de l’entreprise comme des déchets nucléaires : on les enterre profondément et on espère qu’il n’y aura pas de fuite.»

Outre les faiblesses techniques évoquées, un risque majeur réside dans les comportements des utilisateurs : réutilisation du même mot de passe pour plusieurs services, mots de passe trop faibles ou faciles à deviner, incrémentation… Ainsi, lorsqu’un mot de passe est réutilisé sur plusieurs services, le maillon le plus faible fragilise toute la chaîne.

En définitive, l’expérience utilisateur appauvrie et le niveau de sécurité limité poussent les entreprises à chercher de nouveaux moyens d’authentification.

Quels remèdes ?

On divise généralement les moyens d’authentification en 4 catégories :

Ce que je sais

Ces méthodes d’authentification se basent sur une clé ou un code que l’utilisateur connait. Elles représentent la majeure partie des solutions mises en place aujourd’hui aussi bien en entreprise que dans la sphère privée. Parmi les solutions existantes, on peut notamment retrouver le traditionnel mot de passe, le code PIN ou encore les questions secrètes. Ces dernières sont toutefois rarement utilisées car soit trop génériques (« Quelle est votre couleur préférée ? ») soit trop difficiles à retenir.

Ce que je possède

La sécurité repose sur le fait de posséder un matériel particulier. On retrouve notamment les matériels suivants :

• Un smartphone

Le smartphone permet, en entreprise comme dans la sphère privée, de sécuriser la réalisation d’opérations plus sensibles : accéder au réseau interne de l’entreprise, confirmer un paiement en ligne ou une opération bancaire inhabituelle…

Le smartphone peut ainsi être utilisé de différentes façons pour s’authentifier :

• Un token matériel

Un token a souvent la forme d’une mini-calculatrice et permet de générer un code à usage unique (OTP), le token pouvant lui-même être protégé par un code PIN choisi par l’utilisateur. Historiquement très utilisé dans les entreprises (accès VPN notamment) et occasionnellement dans la sphère privée pour la connexion à certains espaces clients, les tokens tendent néanmoins à disparaître au profit des smartphones, éliminant ainsi une logistique coûteuse.

• Une carte à puce

La carte à puce contient un certificat qui sert à prouver l’identité du porteur. Un lecteur de carte est indispensable pour l’authentification ; par ailleurs la gestion des certificats nécessite des infrastructures et des procédures de gestion du cycle de vie (arrivée, départ, perte…). Plutôt réservée au monde de l’entreprise, son usage tend à se limiter à des populations ou des usages ciblés (administration IT, opérations financières…).

• Une clé U2F

Cet objet se présente sous la forme d’une clé USB standard mais au lieu d’être utilisée pour stocker des fichiers, elle stocke une clé unique liée à l’utilisateur. Basée sur un standard défini par l’alliance FIDO, cette solution allie bon niveau de sécurité (notamment une résistance au phishing) et bonne expérience utilisateur (les clés peuvent rester brancher sur un port USB du poste) puisqu’une simple pression sur la clé suffit pour s’authentifier. Notons toutefois qu’il ne s’agit pas d’une reconnaissance d’empreinte digitale.

• Un objet connecté tel qu’une montre

Cette dernière solution, la plus novatrice dans cette catégorie, permet à l’utilisateur de se connecter par le biais d’un objet connecté qu’il possède déjà. Ce moyen d’authentification est très peu utilisé en entreprise mais Apple propose par exemple de déverrouiller son ordinateur en s’approchant simplement avec un objet connecté de la même marque.

Ces solutions basées sur la possession d’un matériel se distinguent essentiellement par leur niveau d’ergonomie. Dans tous les cas, il s’avère indispensable de gérer « l’enrôlement » (le fait de lier l’objet à son porteur), le renouvellement, la perte et le vol du matériel en question.

Ce que je suis

Les caractéristiques physiologiques d’une personne telles que l’empreinte digitale, le réseau veineux de la main, l’iris, le visage, l’empreinte vocale ou encore le rythme cardiaque permettent également d’authentifier une personne. L’usage de ces solutions est pour le grand public principalement limité à l’ouverture de son poste de travail ou de son smartphone (empreinte digitale ou visage). Cependant, ces solutions sont mises en œuvre depuis plusieurs années en entreprise pour contrôler l’accès à des salles ou zones hautement sensibles.

Ce que je fais

Le rythme de frappe au clavier, les mouvements de la souris, le maintien du téléphone, ou encore le toucher sur l’écran sont différents moyens de distinguer un utilisateur légitime d’un usurpateur ou encore d’un robot. Ces solutions de biométrie comportementale nécessitent un volume de données important pour être fiables mais cela tend à s’améliorer grâce aux nouvelles approches de Machine Learning. Ces solutions sont plutôt utilisées comme mesures de sécurité complémentaires à l’authentification (détection d’attaque par robot, détection de partage de comptes…).

En synthèse, la figure ci-dessous représente les différentes solutions d’authentification en fonction de leur niveau de sécurité et de leur simplicité d’utilisation.

Expérience utilisateur et sécurité, ennemis inconciliables ?

Nous pensons qu’il est possible de réconcilier expérience utilisateur et sécurité et proposons ici 4 orientations pour y parvenir.

Orientation 1 : Simplifier l’utilisation des mots de passe

S’il parait illusoire d’imaginer une suppression complète de l’utilisation des mots de passe, il reste possible néanmoins de s’attaquer à certains de leurs défauts. On peut déjà réduire la fréquence de saisie via des mécanismes de fédération d’identité qui permettent d’accéder aussi bien à des services de l’entreprise que des services de partenaires. Par ailleurs, des chatbots voient le jour pour simplifier les processus de réinitialisation de mots de passe et vont dans le sens d’une amélioration significative de l’expérience utilisateur. Quant à la sécurité, la sensibilisation des utilisateurs sur la bonne utilisation des mots de passe reste aujourd’hui une action essentielle pour réduire les risques (social engineering, spam, phishing, vols de mot de passe…).

Orientation 2 : Adapter les exigences de sécurité au contexte

De même que l’on doit adapter sa vitesse sur route aux conditions climatiques, la notion de « risque » doit nous guider dans le niveau de sécurité attendu pour authentifier l’utilisateur. Ainsi, pour consulter des informations non sensibles, un simple mot de passe peut suffire, là ou des opérations sensibles (virement bancaire important…) vont nécessiter d’authentifier l’utilisateur avec plus de certitude en combinant plusieurs facteurs d’authentification. D’autres critères peuvent être pris en compte pour évaluer le risque comme le PC ou smartphone utilisé, la localisation géographique, l’heure de connexion voire même le comportement habituel ou non de l’utilisateur.

Au-delà de la phase d’authentification, le niveau de risque peut également influencer la durée avant nouvelle demande d’authentification (pas besoin de retaper son mot de passe Facebook tant que l’on reste sur le même PC ou smartphone, réauthentification à un webmail tous les X jours seulement…).

Finalement, l’authentification n’est plus vue comme un événement mais comme un processus continu.

Orientation 3 : Laisser à l’utilisateur le choix de son facteur d’authentification

Plutôt que d’imposer un unique moyen d’authentification à tous les utilisateurs, le Bring Your Own Token (BYOT) consiste à laisser chacun choisir celui qui lui paraît le plus adapté à son usage. L’idée reste de proposer un choix parmi des solutions de niveau de sécurité comparable.

Aujourd’hui, Facebook ou encore Google, proposent du BYOT comme second facteur d’authentification via l’enregistrement d’un smartphone ou d’une clé USB sécurisée par exemple.

Dans le monde professionnel, cela reste moins développé pour le moment mais on peut facilement imaginer proposer ce service à des populations ciblées : besoins de mobilités spécifiques, appétence technologique…

Orientation 4 : S’appuyer sur les comptes déjà existants

Il est de plus en plus courant d’utiliser son compte d’un réseau social (Facebook, Google, LinkedIn) pour se connecter à des sites de e-commerce ou à d’autres sites web. Le Social Login permet à la fois de simplifier la création du compte sur le nouveau site en ligne et de limiter le nombre de mots de passe à retenir.

Tous les services en ligne n’ont cependant pas vocation à utiliser le Social Login. Dans le cas de services publics ou parapublics par exemple, on privilégiera plutôt le State Login qui permet par exemple d’utiliser son compte des Impôts, de l’Assurance maladie ou de La Poste pour effectuer différentes démarches administratives en ligne (FranceConnect). Le développement de ces usages est en pleine accélération aujourd’hui.

En conclusion

Si les mots de passe ne sont pas prêts de disparaître complètement, la recherche d’alternatives est en plein essor : les usages et les solutions technologiques évoluent rapidement, des consortiums et de nouveaux standards voient le jour (OAuth2, OIDC) et désormais l’expérience utilisateur est au centre de la réflexion au même titre que les enjeux de sécurité.

Cet article Quels remèdes contre les maux de passe ? est apparu en premier sur RiskInsight.

Ces dernières années, les entreprises ont fait face à un élargissement du champ d’action de l’Identity and Access Management. Cette discipline n’est plus uniquement centrée sur les problématiques de provisioning utilisateur et d’authentification ; elle s’est tournée non seulement vers des problématiques de revue et de certification des comptes mais aussi vers l’utilisation des mécanismes de fédération d’identités (eg. SAML). Ces changements concernent aussi bien les applications SaaS que les applications restées en interne. Ces évolutions ont chacune permis une ouverture du SI toujours plus large, et nécessitent par conséquent d’être correctement implémentées pour limiter les failles de sécurité.

Cette évolution de l’IAM se fait en parallèle de la généralisation des services Cloud, qui ne cessent de donner naissance à de nouveaux usages pour plus de flexibilité et de souplesse dans l’accès et l’utilisation du SI. Les utilisateurs internes accédant au SI le font de plus en plus majoritairement depuis l’extérieur du réseau de l’entreprise, et ce depuis des terminaux de plus en plus variés.

En outre, les nouvelles technologies agiles et DevOps poussent le SI à évoluer différemment, intégrant beaucoup plus rapidement de nouvelles technologies (IoT, etc.) et de nouveaux usages.

Toutes ces évolutions font aujourd’hui du SI une bulle parmi d’autres interagissant avec son environnement et devant maîtriser, à distance, des interactions entre des composants décentralisés.

… rendant les APIs incontournables

Ce nouveau modèle décentralisé du SI donne naissance à la problématique d’interconnexion des services et des applications : comment assurer l’accès aux données à chaque instant et en chaque endroit ?

Aujourd’hui les APIs (Application Programmable Interface) représentent déjà un mécanisme de communication prépondérant et incontournable pour toute entreprise lancée dans sa transformation numérique. Elles sont utilisées dans  les traitements réalisés non seulement sur des données publiques (adresses d’agences, horaires des transports, etc.) mais aussi sur des données personnelles (tracking fitness, application Ameli et CAF, etc.) et des données sensibles (DSP2, achat en ligne, informations industrielles en mobilité, etc.).

Quelle recette pour sécuriser ses API ?

La sécurisation des API passe par une recette à base de 4 ingrédients à doser finement.

Une base de security as usual

Selon un benchmark Wavestone sur le sujet de la sécurité des applications web, sur 128 applications auditées, des failles graves sont observées dans 60% des cas et la situation est très similaire pour les APIs. À cet effet, les recommandations habituelles de la sécurité web, par exemple celles d’OWASP doivent être prises en compte de la même manière.

Il s’agit essentiellement de s’assurer de couvrir les principales zones à risques d’une application web et de déterminer les mesures de sécurité appropriées.

Une pincée d’OAuth

OAuth est un framework de délégation d’autorisation qui permet à une application d’obtenir l’autorisation d’accès à une ressource au nom d’un utilisateur.

OAuth se propose de couvrir un large éventail de cas d’usages (applications web, mobile, accès ou non à un navigateur, accès serveur-à-serveur, etc.) et offre à cet effet 4 cinématiques principales pour obtenir un jeton. Combiné à une spécification détaillant l’utilisation de ce jeton, un document détaillant le threat model, et enfin une surcouche dédiée à l’authentification (OpenID Connect), il s’agit d’un corpus documentaire équivalent à 250 pages, laissant une place certaine à un grand nombre d’options et de choix d’implémentation.

Et c’est bien cette abondance d’options et ce manque de contraintes qui entraînent les failles de sécurité observées régulièrement dans la mise en place d’OAuth2.0 : usurpation d’identité d’une application, accès aux données personnelles d’un utilisateur tiers, vol de cookie Facebook/Google lors d’un social login ou encore compromission de compte utilisateur.

Les six recommandations suivantes sont essentielles pour une mise en place sécurisée du Framework :

• Secret local : L’application est munie d’identifiants lui permettant de s’authentifier auprès du serveur OAuth : ne pas mettre ce secret (identifiant du service) dans l’application mobile ou le considérer compromis
• Redirect URI: Valider strictement les URLs de redirection vers l’application, sans wildcard
• Implicit: Éviter le « Implicit grant » dans la mesure du possible (et se tourner vers le proxy pattern)
• Authorization code: Valider strictement les authorization codes et clients associés
• State and PKCE: À utiliser pour garantir l’intégrité d’une cinématique complète
• Authorization ≠ Authentication: Utiliser OpenID Connect pour authentifier, OAuth pour déléguer l’accès

Limitez les additifs

À peine cette première pincée d’OAuth digérée, il faut déjà réfléchir à des solutions de sécurité permettant de répondre aux besoins que nous rencontrons le plus fréquemment.

Le Single Sign-On mobile, ou comment permettre à des employés en mobilité ou des clients d’accéder aisément aux applications sans se réauthentifier ?

Qu’il s’agisse d’un agent terrain en contact clientèle ou en tournée d’intervention qui peut utiliser plus d’une dizaine d’applications par jour ou qu’il s’agisse d’un client ayant installé plusieurs applications sur le store public, le besoin d’accéder à l’ensemble des applications sans avoir à se réauthentifier sur chacune est aujourd’hui très présent. Si, depuis 2008, les techniques le permettant ont varié au gré des possibilités offertes par les OS mobiles (KeyChain iOS, paramètres d’URL, Mobile Device Management…), Apple et Google ont convergé vers une solution commune en 2015 : utiliser le navigateur système comme point d’ancrage d’une session SSO. C’est maintenant une bonne pratique officielle matérialisée par la BCP « OAuth2 for native applications »

L’authentification contextuelle, ou comment adapter le niveau d’accès à une donnée en fonction de la criticité de celle-ci ?

Un des nombreux enjeux concernant l’authentification est de simplifier au maximum l’accès des utilisateurs à leurs données tout en garantissant un niveau de sécurité satisfaisant. L’authentification contextuelle permet de répondre à cet enjeu, en adaptant le niveau d’accès à la nature de la transaction, à ses caractéristiques, aux habitudes utilisateurs, à son contexte…. On parle de LOA (Level of Assurance). Dans le cadre d’une application mobile bancaire, cela permet à l’utilisateur de consulter son compte en banque, de bénéficier de la météo de ses comptes sans avoir à se réauthentifier à chaque accès. L’application requerra toutefois une authentification au moment de réaliser une opération sensible (un virement interne par exemple), et une authentification forte au moment de réaliser une opération très sensible (ajout d’un bénéficiaire par exemple).

Les solutions du marché proposent aujourd’hui des solutions pensées selon une logique où le client applicatif est responsable d’initier la demande de LOA correspondant à la donnée ou au service auquel il souhaite accéder. Mais le vrai besoin consiste à définir et appliquer ces politiques d’accès aux données de manière centralisée, au sein du serveur d’autorisation. Il s’agit notamment d’un besoin essentiel lorsque l’on veut appliquer une authentification liée au niveau de risque du contexte (géolocalisation, terminal connu ou non, habitudes de transactions, etc.)

Propagation de l’identité, ou comment transmettre un jeton d’accès entre deux applications (ou plus) ?

Il est courant qu’un appel vers une API déclenche une cascade d’appels vers d’autres API, notamment dans le cadre d’une architecture de type micro-service. La transmission de l’identité de l’utilisateur doit alors être assurée sans créer de risque de sécurité. Et les trois premières solutions qui viennent à l’esprit présentent des limites :

• La transmission du token initial est évidement à proscrire, à la vue du risque de fraude interne très élevé que cela entrainerait.
• L’authentification de l’appelant seule n’est pas suffisante non plus, car un composant compromis dans la chaîne peut usurper l’identité de n’importe quel utilisateur et compromet le reste de la chaîne.
• La génération d’un token pour l’appelant transmis avec le token de l’utilisateur initial ne permet pas d’assurer l’intégrité de la combinaison utilisateur/API et ne permet pas de vérifier la chaine.

Une ébauche avancée de solution existe aujourd’hui, proposant un nouveau grant type : Token Exchange. Ce mécanisme permet à l’appelant de demander un jeton intermédiaire, composé notamment de l’identité de l’utilisateur, de l’identité de l’appelant et de la chaine d’appel déjà effectuée. Cette nouvelle cinématique permet de centraliser la politique d’appel entre micro-service et l’application de cette politique, et d’assurer la traçabilité des appels.

Protection contre le vol de jeton, ou comment se prémunir du vol d’un ou d’une base de jetons ?

Par principe, le jeton contient de nombreuses informations sur son porteur, ce qui entraîne un risque important en cas de vol. Plus impactant encore, dans certains contextes (e.g. DSP2), un tiers (agrégateur) peut se retrouver en possession de très nombreux jetons, et le propriétaire de l’API se retrouve à la merci de ce tiers et de son niveau de sécurité. La détection du vol étant très difficile, il a fallu trouver d’autres solutions comme le Token Binding, un mécanisme de négociation à deux ou trois composants, permettant de lier un jeton à une paire de clés cryptographiques, et dans lequel le client doit prouver qu’il possède la clé privée constituant une partie de cette paire en établissant une connexion TLS mutuelle avec l’API.

Écrire la recette

Dernier ingrédient de la recette, il convient de décliner une architecture de référence de OAuth pour l’adapter au contexte du SI de l’entreprise. Pour cela, il faut définir le cadre d’utilisation des API en :

• Définissant et partageant les règles de sécurité : Les cinématiques autorisées et le cadre d’application, les checklists sécurité et l’architecture de référence doivent être formalisées.
• Formant et outillant les développeurs: Des sessions de formation et de présentations des principes adoptés doivent être organisées. Les équipes projets peuvent être rendues autonomes dans leur intégration au reste du SI.
• Intégrant les ressources sécurité dans les sprints agiles: Les ressources agissant en tant que coach sécurité doivent être identifiées pour accompagner la conception applicative et apporter des solutions prêtes à l’emploi et être un accélérateur

En synthèse

Au final, comme la recette du bon miel, sécuriser des APIs nécessite une succession d’ingrédients allant du plus basique jusqu’au plus élaboré tout en tenant compte du besoin et du contexte.

Cet article La sécurité des APIs ou la recette du bon miel est apparu en premier sur RiskInsight.

Dans ce contexte, la grande majorité des entreprises a mené des projets d’IAM : les accès aux applications sensibles sont étroitement contrôlés et les niveaux d’accès sont restreints selon les profils des utilisateurs et les actions à réaliser.

Or, trop souvent, ces démarches IAM « oublient » les populations IT qui ont pourtant des accès privilégiés sur l’infrastructure de l’entreprise. Et pour ces derniers, plusieurs spécificités sont à prendre en compte.

Les utilisateurs IT ont des besoins d’accès différents

Les utilisateurs « non-IT » représentent les utilisateurs « standards » du SI : utilisateurs des directions métier ou des fonctions support comme RH, paie, ou comptabilité… Ils accèdent classiquement :

• Aux applications en environnement de production,
• Et via les IHM standard de celles-ci.

Les populations « IT » (service informatique interne, télémaintenance, support…) ont quant à elles des accès très différents :

• Elles opèrent les infrastructures (serveurs, bases de données), et le code applicatif, sur lesquels reposent les applications ;
• Elles accèdent à tous les environnements et en particulier production et hors-production (ces derniers contenant souvent des données de production ou à caractère sensible ou personnel) ;
• Très souvent, elles opèrent avec des niveaux de droits (des « privilèges ») très élevés, présentant donc un niveau de risque non négligeable.

Ainsi, la terminologie « accès à privilèges » désigne tout accès technique, sur une infrastructure ou une brique logicielle, dans des environnements de production ou hors-production.

Ces accès sont parfois créés pour des individus, ou pour les applications elles-mêmes (une application a besoin de plusieurs comptes techniques, comme pour écrire dans une base de données).

On distingue différents niveaux d’accès « à privilèges ». Les plus critiques, de niveau « administrateur », offrent un contrôle total d’un ou plusieurs serveurs, et donc potentiellement plusieurs applications. Les accès IT de niveau « standard » sont moins sensibles mais restent à surveiller. Ces derniers pourraient permettre, par exemple, de consulter des informations sensibles dans une base de données.

Accès IT, risques métier

Par définition, la maitrise des accès privilégiés des populations IT doit être au cœur des préoccupations des entreprises.

Parmi les risques les plus importants, nous retrouvons :

• Les risques opérationnels, sans impact sur la production

Exemple : des traces d’exploitation sont supprimées par erreur ou un serveur non critique est éteint.

• Les risques sur l’activité de l’entreprise

Exemple : indisponibilité de la plateforme de flux des paiements / transaction suite à un redémarrage des serveurs par erreur.

• Les risques de non-conformité aux régulations

Exemple : mise en évidence d’un accès non-justifié sur un périmètre régulé suite à un audit interne.

• Des actions frauduleuses

Exemple : délit d’initié commis grâce à une information sensible consultée directement depuis une base de données.

Sans compter les risques plus larges autour du système d’information : vol de données, ransomwares et autres actions malveillantes. Parce qu’ils sont puissants (et permettent notamment de désactiver les mesures de sécurité), les accès à privilèges sont des cibles de choix en cas de cyber-attaque.

Aujourd’hui, la plupart des responsables d’application sensibles sont en mesure de rendre des comptes quant à l’usage des accès métier dans leur application. De la même manière, les responsables d’application et les responsables d’infrastructure doivent pouvoir répondre à des questions simples telles que :

• Qui utilise réellement des accès à privilèges sur mon périmètre ?
• Combien de comptes à privilèges existent sur mon périmètre ?
• Les mots de passe de ces comptes sont-ils changés régulièrement ?
• Quels sont les niveaux d’accès nécessaires pour mon application ou mes services, et qui ne peuvent pas être retirés sans conséquence pour la production ?

Plusieurs particularités à prendre en compte

Avant de se lancer dans un projet de mise sous contrôle des accès à privilèges, il est bon d’avoir conscience de certaines spécificités qui ne s’appliquent pas pour les accès métier.

À commencer par le cycle de vie de certains accès à privilèges. Dans le monde des accès métier, le cycle de vie est lié au statut RH de leur unique propriétaire. Mais dans le monde IT, il existe des accès partagés entre plusieurs personnes (pour des besoins opérationnels spécifiques), ou bien qui sont utilisés par l’application elle-même pour fonctionner. La durée de vie de ces accès-là est plutôt liée à la durée de vie de l’application concernée, ou bien parfois à la durée d’un projet.

Certaines contraintes opérationnelles sont aussi à prendre en compte. Notamment en ce qui concerne :

• La gestion de la production, qui ne souffre aucun délai. Dans le monde des accès métier, les niveaux d’accès sont généralement liés à la fiche de poste des utilisateurs, et c’est aussi le cas pour les populations IT. Mais dans certaines circonstances, les utilisateurs IT doivent pouvoir obtenir de nouveaux accès sans délai. Par exemple, en cas de panne d’une application critique, les équipes IT doivent pouvoir intervenir au plus vite avec toute la latitude nécessaire. Ce qui peut nécessiter des élévations de privilèges. Dans ce contexte, des processus de validation seraient trop longs (avec validation du responsable hiérarchique, puis éventuellement un autre niveau de validation…). Une autre approche peut consister à autoriser ce type de demande sans validation préalable, mais tracer et contrôler à posteriori l’usage qui a été fait de cet accès.

• Le grand nombre de ressources cibles. Certaines applications reposent sur un grand nombre de serveurs de production, et au moins autant de serveurs hors-production. Des applications peuvent aujourd’hui créer ou supprimer des serveurs virtuels à la volée, en fonction de la charge. Dans ce cas, il serait vite ingérable d’imposer aux utilisateurs des demandes d’accès pour chaque ressource cible. Une solution peut consister à gérer des demandes d’accès à des groupes de ressources (par exemple un groupe Active Directory qui représente tous les serveurs de production d’une application, lequel groupe pourrait même être déployé automatiquement sur les nouveaux serveurs par un orchestrateur).

Surtout, l’hétérogénéité de l’environnement peut rendre le modèle d’accès complexe. En effet, articuler la gestion des accès à privilèges autour d’un modèle cohérent, implique de composer avec :

• Des serveurs qui hébergent parfois plusieurs applications. Dans ce cas, un besoin d’accès à une seule application se traduit, en pratique, par des accès indus à plusieurs applications. Dans le cas d’applications critiques, il vaut donc mieux investir dans des serveurs dédiés (virtuels ou non, face aux risques portés par les administrateurs des plateformes de virtualisation).

• Des ressources hétérogènes avec leurs propres particularités. Serveur Windows, Unix, base de données Oracle, middleware Tomcat, des équipements réseau, voire des conteneurs comme Docker… La liste des technologies à prendre en compte est longue.

• Pour une même ressource, différents comptes à créer. Un utilisateur peut souvent intervenir sur une même ressource via différents moyens. Pour un même serveur, on pourra offrir la possibilité de s’y connecter directement (protocoles SSH, RDP…), via l’intermédiaire d’un serveur de rebond (et dans ce cas, c’est sur ce serveur qu’il faut créer un accès utilisateur), ou encore via une interface logicielle d’administration (c’est d’ailleurs la voie du DevOps).

• Des populations hétérogènes et des besoins qui évoluent rapidement. Le modèle d’accès est difficile à uniformiser, notamment parce que différents types de population, comme des administrateurs d’infrastructures ou des développeurs, ont des besoins différents. Par exemple, un administrateur Windows opère tous les serveurs Windows, quelle que soit l’application, alors qu’un développeur intervient sur plusieurs technologies dans la limite d’une application. Mais il est aussi difficile d’uniformiser le modèle d’accès pour une même population, car les développeurs de 2 applications différentes peuvent avoir des besoins différents.

Les accès à privilèges : un challenge pour la sécurité ?

Accès standards métier et accès à privilèges sont les 2 faces de la même pièce. Et les accès à privilèges en sont la face sombre, car ils sont à la fois plus sensibles et techniquement plus complexes à gérer.

Face à cet état des lieux, la prise de conscience des entreprises est inégale. Les mieux informées sont les équipes techniques IT qui utilisent les comptes à privilèges, et qui sont souvent favorables au statuquo.

Au-delà de la Direction des systèmes d’information, ce sont les Directions en charge des processus internes, de la qualité ou encore le contrôle interne, qui ont un rôle clé de sponsoring à jouer.

Le législateur, lui, commence aussi à s’y intéresser. Ainsi la Loi de programmation militaire, qui concerne les opérateurs d’importance vitale, impose une mise sous contrôle des accès à privilèges les plus critiques.

Mais alors comment s’y prendre, pour mettre les accès à privilèges sous contrôle ? Nous y reviendrons dans un prochain article.

Cet article Accès à privilèges : la face sombre de l’IAM est apparu en premier sur RiskInsight.

Il est aujourd’hui indispensable pour les entreprises de connaitre au mieux leurs clients afin de leur proposer des services toujours plus personnalisés et ainsi augmenter leurs taux de transformation.

En quoi l’arrivée de systèmes centralisés de gestion des identités clients (Customer Identity and Access Management ou CIAM) peut être une première réponse à cette problématique.

Vers une gestion unifiée des données clients

Une organisation historiquement en silos

De par la spécificité des métiers de l’entreprise, de nombreuses solutions de gestion de la relation client ont émergé ces dernières années : CRM, email et vidéo marketing, e-commerce, mobile et web analytics…

Cette multiplicité des technologies a entraîné un silotage des données des clients ; en d’autres termes, il est aujourd’hui difficile pour une entreprise de disposer d’une vue unique de ses clients. En effet, une entreprise européenne posséderait en moyenne 4,5 solutions marketing^[1], soit autant de vues de chaque client.

Avoir une vision unifiée des clients est une première étape indispensable pour les entreprises afin d’être en mesure de leur proposer des offres pertinentes.

Par ailleurs, le taux de transformation depuis les canaux numériques reste faible du fait d’un ciblage incomplet, d’offres en décalage avec les intérêts du client et d’un manque de confiance envers la marque.

Afin d’allier la transformation numérique et business, positionner l’identité du client au centre de l’organisation est une manière de traiter ces points défaillants.

Le client au centre de l’organisation

Aujourd’hui, le nombre important de solutions marketing tend à multiplier les sources de données : points de vente, canaux numériques (sites web, mobiles), service après-vente…

Le client se retrouve alors dans un modèle en « toile d’araignée » : plusieurs sources, plusieurs systèmes, plusieurs bases de données et donc plusieurs identités.

Afin d’améliorer la connaissance de leurs clients, les entreprises doivent adopter un modèle plus unifié, combinant facilité d’accès et partage des données clients : le modèle « centralisé ».

Ce modèle vise à mettre une interface unique (CIAM) entre les sources de données et les solutions marketing qui aura pour objectifs de centraliser les données clients, améliorer leur qualité et créer de la valeur business en les agrégeant dans une même identité.

Une solution CIAM couvre 3 briques technologiques :

• Enregistrement et accès: fournit des services d’enregistrement et de connexion, indépendamment du moyen d’accès (site web, mobile…) : API/SDK, fédération d’identité, social login…
• Stockage et traitement: fournit des services de stockage et de traitement des données : profiling, mise en qualité, agrégation…
• Intégration: fournit des connecteurs permettant au CIAM d’échanger des données avec les différentes solutions marketing de l’entreprise.

Un tel modèle permettra à l’entreprise de mieux connaitre ses clients et les fidéliser (Know Your Customers, ou KYC).

Mieux connaitre ses clients grâce au CIAM

Globalement, l’ensemble des services offerts par le CIAM répond à des besoins business importants : mieux connaitre les clients, simplifier leur parcours et créer une relation de confiance.

Un CIAM pour… mieux connaitre les clients

Un client satisfait est un client fidèle, mais pour le satisfaire, encore faut-il le connaitre et anticiper ses attentes. Pour cela, le CIAM vise à contribuer à l’amélioration de la connaissance des clients que nous découpons en 4 grandes étapes :

Étape 1 : client anonyme

L’entreprise ne connait pas le client mais uniquement un utilisateur qui accède à ses services. Elle ne peut donc récupérer des informations restreintes (cookie).

L’objectif est alors de proposer un moyen simple d’identifier l’utilisateur (ex : inscription à une newsletter).

Étape 2 : client identifié

Le client crée un compte utilisateur par le biais d’un compte d’un réseau social ou en remplissant un formulaire. À cette étape, l’entreprise présente les conditions d’utilisation de ses données pour consentement, récupère des informations de contact (nom, prénom, date de naissance, e-mail, téléphone) et rattache les informations récupérées en étape 1 à l’identité du client.

L’objectif est alors de le faire revenir via une newsletter ou l’envoi d’offres en lien avec son historique de navigation pour établir son profil.

Étape 3 : client connu

Au fur et à mesure des échanges avec le client, le CIAM va récupérer ses préférences (via les produits consultés, l’affichage d’un bouton « J’aime » à l’instar des réseaux sociaux qui permet au client d’indiquer simplement son intérêt pour le produit, etc.). Le profil du client commence à se dessiner et des actions de marketing plus ciblées peuvent commencer.

L’objectif est maintenant de connaitre au mieux le client et faire vivre ses données.

Étape 4 : client fidélisé

La mise à jour des préférences du client va permettre de cibler davantage les actions marketing et de le fidéliser en proposant des offres personnalisées et attractives.

Cette étape se réalise sur le long-terme, dans une approche de construction dynamique du profil du client.

Un CIAM pour… simplifier le parcours client

Un des principaux intérêts du CIAM est de simplifier le parcours client, élément fondamental à la transformation numérique.

À l’enregistrement : faire simple, faire vite !

La première raison de perte de clients potentiels est un processus d’enregistrement compliqué (trop d’informations demandées, CAPTCHA à saisir…).

Afin de simplifier ce processus, les solutions de CIAM proposent des fonctionnalités d’enregistrement en 3 clics basés sur les comptes des réseaux sociaux (ex : Facebook, Twitter, LinkedIn, Google…).

Les réseaux sociaux seront privilégiés comme source d’information du client.

À l’usage : éviter l’effet RELOU !

S’il y a une chose à ne pas retenir dans la mise en place d’un CIAM, c’est d’imposer un nouveau mot de passe au client.

Les solutions CIAM facilitent l’accès aux services en proposant des méthodes de connexion également basées sur les réseaux sociaux. Mais attention, les clients ne doivent pas avoir à se rappeler du réseau social qu’ils ont utilisé lors de l’enregistrement.

C’est à ce moment-là que les solutions CIAM permettent de rendre le plus transparent possible l’accès des clients en apportant la capacité de rattacher tous comptes de réseaux sociaux d’un client à son identité (ex : si le client s’enregistre avec Facebook, il devra pouvoir se connecter plus tard avec Twitter).

Se connecter en 1 clic pour éviter l’effet RELOU (« Réellement, Encore un Login à OUblier ! »), voilà de quoi retenir vos clients.

Un CIAM pour… créer une relation de confiance

La fidélisation d’un client passe par l’instauration d’une relation de confiance avec ce dernier en respectant le bon usage de ses données.

Aujourd’hui, le cadre légal est en pleine évolution, particulièrement en Europe avec l’arrivée de la GDPR (General Data Protection Reglementation).

L’un des points important de la GDPR est l’obligation faite d’obtenir le consentement de l’utilisateur pour tout usage de ses données.

En conséquence, le client doit à tout moment pouvoir :

• Être tenu informé des termes d’utilisation de ses données
• Accéder à ses données et pouvoir les rectifier
• Restreindre l’accès d’un service à tout ou partie de ses donnée
• Être oublié

Le respect de ces réglementations est donc primordial pour augmenter la confiance des clients qui, in fine, sont devenus la source de données principale des solutions CIAM. Cette confiance permet à l’entreprise de recueillir le maximum d’informations sur le client et d’ainsi augmenter ses taux de transformation.

CIAM et IAM traditionnel : est-ce différent ?

Bien que les solutions IAM traditionnelles et CIAM proposent des briques fonctionnelles proches (gestion des identités, authentification, publication de données…), elles présentent néanmoins des différences technologiques et d’usages significatives :

En conséquence, l’extension d’un IAM traditionnel pour gérer les identités des clients n’est évidemment pas judicieuse et induirait immanquablement un projet coûteux, la mise en place d’un système hybride non agile et ne garantirait pas l’atteinte des besoins couverts nativement par un CIAM.

En synthèse

Fidéliser un client nécessite de le connaitre. Les solutions de CIAM apportent des moyens technologiques pour centraliser et unifier la vision d’un client au sein d’une organisation, tout en respectant les évolutions des réglementations actuelles et en simplifiant le parcours client.

Malgré leurs bases communes à l’IAM traditionnel, les solutions CIAM restent des outils à enjeux marketing. Leur mise en place nécessite de sortir du cercle IT pour inclure les métiers (marketing, communication, services supports) ainsi que le juridique.

[1] PAC, No more Silos – Towards a Holistic Customer Experience Strategy, 2016

Cet article Customer IAM : l’IAM, pilier de la transformation business ? est apparu en premier sur RiskInsight.

Historiquement la discipline de la gestion des identités et des accès (IAM ou identity and access management en anglais) s’est constituée autour du besoin de maîtriser qui accède (comment et) à quoi dans le système d’information de l’entreprise.

Du côté de la gestion des identités, les projets se sont initialement attelés à l’automatisation du provisioning et des tâches à faible valeur ajoutée. La discipline s’est ensuite peu à peu tournée vers les processus de demande et d’approbation de droits d’accès et plus récemment vers les problématiques de revue et recertification des comptes et habilitations.

Sur le sujet du contrôle d’accès, nous sommes passés par une première ère où l’authentification fut centralisée (sur un annuaire partagé par exemple), puis déléguée (à une solution de WebSSO) et enfin standardisée avec l’utilisation des mécanismes de fédération d’identités (eg. SAML) autant pour les applications SaaS que pour les applications restées en interne.

Dans le même temps, ces dernières années, le système d’information de nos entreprises s’est énormément ouvert à Internet : SaaS, IaaS, utilisateurs internes en mobilité, partenaires & clients accédant au SI, applications mobiles, etc. Et l’IAM a pu à chaque fois proposer des solutions à ces nouveaux usages et nouvelles orientations sans forcément nécessiter de remettre en cause l’existant et ses principes fondamentaux. Le marché s’est d’ailleurs petit à petit consolidé et nous sommes dans une situation de relatif calme… avant la tempête.

Les évolutions du SI

Nous estimons en effet que nous n’en sommes qu’au début de ces transformations.

Sous l’impulsion du Cloud d’une part, nous allons vers encore plus de SaaS, une utilisation du IaaS majoritaire par rapport aux datacenters historiques, une réelle adoption du PaaS (sous la forme d’applications conteneurisées, et server-less apps), des utilisateurs internes accédant majoritairement depuis l’extérieur et une explosion du nombre de terminaux accédant au SI (toujours plus de clients dont le parcours est digitalisé, explosion à venir du nombre d’objets connectés, OpenData, etc.)

Et sous l’impulsion de nouvelles méthodologies agiles et DevOps, le SI n’évolue plus de la même manière. Les cycles de développement et déploiement se sont considérablement raccourcis, les interactions entre le métier et la DSI se heurtent de moins en moins à l’opposition historique, et traditionnellement française, entre MOA et MOE. Ces nouvelles méthodes se sont d’ores et déjà répandues dans l’entreprise et il est difficile d’y résister.

Si la mission de l’IAM n’a guère changé : maîtriser qui accède à quoi dans le SI, il y aura beaucoup plus de « qui », de « quoi » et le SI ne sera plus qu’une bulle parmi d’autres interagissant avec son environnement et devant maîtriser, à distance, des interactions entre des composants décentralisés.

L’IAM de demain

Dans ce nouvel environnement où les métiers pilotent l’innovation technologique et imposent leurs exigences, où il est même parfois prescripteur de solutions technologiques, l’IAM doit se faire une nouvelle place. Dans ces architectures majoritairement Cloud, l’IAM doit démontrer qu’elle permet de maîtriser cette orientation et même d’apporter des plus-values par rapport à la situation précédentes.

Notre vision de l’IAM de demain s’articule autour de sept thèmes. Trois besoins exprimés par le métier et quatre nouvelles disciplines au sein de l’IAM.

L’agilité

Le métier attend de pouvoir proposer de nouveaux produits en un temps toujours plus court et ce qu’il a obtenu sur les applications métier est aujourd’hui attendu de tout le SI, y compris les services d’infrastructure et de sécurité et donc de l’IAM.

C’est l’occasion de passer d’un IAM monolithique, complexe à sortir de terre et très difficile à manœuvrer pour embrasser une architecture plus légère basée, par exemple, sur des micro-services.

La gestion des identités clients (Customer IAM ou CIAM)

La transformation numérique engagée par de nombreuses entreprises aujourd’hui a poussé le métier à interagir avec ses clients de plein de manières différentes et via toujours plus de canaux différents.

Une expérience utilisateur parfaite et la simplification du parcours client sont requis. L’optimisation des conversions clients et les taux de retours deviennent des indicateurs clés sur lesquels le métier insiste pour obtenir de l’IAM plus d’efforts.

Les objets connectés (Internet of Things ou IoT)

Que votre entreprise se lance dans la fabrication d’objets connectés ou qu’elle ne fasse que fournir des services consommés par ces objets, un certain nombre de questions vont devenir incontournables :

• Comment s’assurer que l’objet avec lequel je communique et celui qu’il prétend être ? Dans mon cas d’usage, est-ce finalement si important de le savoir ?
• Comment m’assurer de tenir la charge face au volume d’objets déployés ?
• Comment assurer la sécurité de bout en bout ?
• Quel cycle de vie doit-on anticiper ?

Ce sont des questions passionnantes qui imposent de savoir revenir à la planche à dessin et prendre en compte des hypothèses extrêmement différentes de celles de l’IAM classique.

IDentity as a Service

Comme nous l’avions prédit il y a quelques années, les entreprises n’hésitent plus à exporter leur IAM dans le cloud pour des questions de sécurité mais reviennent à la bonne question : en ai-je besoin ? Que vais-je gagner ?

Si le marché de l’IDaaS est encore jeune, les offres actuelles ne couvrant que très partiellement le spectre de l’IAM, tous les indicateurs montrent que cela ne va pas durer et que toute la gamme de fonctionnalités de gestion des identités aujourd’hui manquantes (provisioning on-premises, demande et approbation de droits, gouvernance des identités, etc.) sera bientôt couverte. Il reste à savoir si gestion des identités et contrôle d’accès seront packagés ou proposés par des acteurs différents et à choisir le(s) bon(s) acteur(s)…

APIs

Les APIs représentent déjà un format de communication prépondérant et incontournable pour toute entreprise lancée dans sa transformation numérique : échange avec les partenaires, applications mobiles, applications IHM client-side, OpenData, etc. Si vous ne vous êtes pas encore lancés, il va falloir sérieusement songer à plonger dans ce sujet !

Malgré des manques perçus par rapports aux standards des web-services des années précédentes (spécifiquement aux nostalgiques de la suite WS-*), il faut se résoudre à embrasser la vague REST/JSON, il faut se lancer dans Oauth2 et vous poser la question du API first pour tous vos projets.

Standards

La guerre des standards est éternelle. Et tout standard qui s’impose aujourd’hui a vocation à être challengé et remplacé plus tard par un autre. Cela n’empêche pas de bons standards de voir le jour, d’être adoptés et de permettre de correctement répondre aux problématiques de l’IAM.

Sur le sujet du contrôle d’accès en particulier, tant sur le volet de l’authentification proprement dite que de la propagation de cette authentification au travers du SI, plusieurs standards et protocoles sont matures et d’ores et déjà adoptés par une bonne part du marché. FIDO, U2F, OpenID Connect pour ne citer que ceux-là sont parmi les plus prometteurs de par leur ouverture, la maturité des technologies sous-jacentes ou encore les acteurs qui les ont conçus collectivement.

Identity & Access Intelligence

C’est sans doute le domaine de l’IAM qui offre les perspectives les plus excitantes. L’application des algorithmes du machine learning, la détection de signaux faibles, des réseaux neuronaux et bien d’autres encore pour faire émerger de nouveaux usages, de nouvelles possibilités en lien avec les identités de nos utilisateurs (ou objets) et leur comportement.

Détecter les scénarios de fraude avant même qu’ils ne se concrétisent, anticiper les risques et fermer la porte avant même que quelqu’un ne l’emprunte réellement. Il y a sans doute encore un peu de science-fiction dans les scénarios présentés par les éditeurs mais ce marché en pleine ébullition regorge de pépites et de bonnes surprises.

En synthèse

Ces sept thèmes, incontournables selon nous, requièrent d’ores et déjà une expertise à la fois pointue et très spécifique. Dans les prochaines semaines, nous éclairerons progressivement ces différents sujets pour donner les clés d’analyse et d’action sur l’IAM de demain, que ce soit en phase de cadrage, d’expérimentation ou de premières mises en œuvre.

Cet article Quel IAM pour demain ? est apparu en premier sur RiskInsight.

Le principal frein rencontré jusqu’ici était de voir toutes ses données externalisées. Ce frein est petit à petit en train de disparaître lorsque l’on se rend compte qu’elles le sont déjà. En effet, le système RH comme le CRM sont, pour bon nombre d’entreprises, déjà dans le cloud ! Les données critiques liées au métier de l’entreprise sont elles-mêmes déjà externalisées à travers les solutions de messagerie et autres suites collaboratives en mode SaaS. Pour quelles raisons l’IAM échapperait-il à cette révolution ?

Identity Access Management As A Service (IAMaaS) : qu’est-ce que cela représente réellement ?

Les offres d’IAM en cloud permettent de gérer et fédérer différentes ressources. Si elles sont bien utilisées, elles peuvent être un vrai accélérateur pour les métiers de l’entreprise. Mais comme tout service dans le cloud, il y a des avantages (coûts, mises à jour régulières, etc.) et des inconvénients (contrôle des données, protocoles et formats parfois non standards, etc.).

Les clients et les partenaires, tout comme les employés ou prestataires, peuvent bénéficier de la fédération d’identités. De même, des connecteurs spécifiques sont mis en œuvre pour les applications SaaS ou on-premises, utilisées par l’entreprise. Les utilisateurs peuvent se connecter via n’importe quel type de terminal. Il reste quelques incontournables pour profiter pleinement d’un IAMaaS et en garder la maîtrise : la capacité de faire des revues de comptes, la disponibilité des connecteurs de provisioning vers les applications et la maîtrise de l’envoi dans le cloud de données à caractère personnel.

Externalisation de l’IAM : penser avant tout à la maturité du SI

La capacité du SI à adopter des standards et des protocoles ouverts est un sujet clé pour réussir un déploiement d’IAM dans le cloud.

Il faut donc, après avoir choisi un premier périmètre d’application, s’assurer que ce dernier respecte les normes et bonnes pratiques en vigueur concernant l’authentification et la gestion des identités. De même l’existence d’un référentiel interne centralisé, afin de communiquer avec la solution d’IAM, sera nécessaire dans la majorité des cas.

Enfin, en prenant la problématique dans l’autre sens, c’est aussi une opportunité de fournir très rapidement aux nouveaux projets une plate-forme mâture supportant les derniers standards : fédération, authentification mobile, provisioning, etc.

Anticiper les risques : plus qu’un besoin, une nécessité

En comparaison avec des solutions on-premises, certains risques seront couverts de la même manière voire potentiellement mieux par une solution cloud : la disponibilité du système et la compromission des données. Les fournisseurs sont souvent plus mâtures que l’entreprise sur le sujet de la résilience des infrastructures et ont anticipé le cloisonnement vis-à-vis des administrateurs dès la conception du service.

D’autres risques doivent en revanche être spécifiquement adressés comme :

• Laréversibilité: il faut s’assurer qu’il est possible à tout moment de récupérer ses données dans un format exploitable et il ne faut faire aucun compromis sur l’utilisation de standards.
• L’isolation des données: cette dernière est parfois très difficile, voire impossible à contrôler ; néanmoins il est possible de s’assurer de manière contractuelle de l’isolation de ses données par rapport aux autres clients du fournisseur.
• La conformité: dans le cadre de certaines obligations (CNIL notamment) il est nécessaire de s’assurer que les données externalisées seront hébergées dans le respect de la norme (en Europe pour la CNIL). Une approche face à cela est de recourir au chiffrement des données avant envoi mais ce n’est pas forcément simple à exploiter dans une solution IAM.

Une opportunité pour moderniser son IAM

L’IAMaaS est une réelle opportunité qui permet d’offrir un service stable, standard et moderne aux différents métiers de l’entreprise.

De même, les utilisateurs étant habitués aux applications en cloud (accessibles partout, tout le temps et depuis tout terminal), la mise en place d’une fédération gérée par l’IAM en cloud et d’un portail IAM de ce type ne perturbera pas, ou très peu, leurs habitudes.

Enfin, en plus de des interfaces simples et efficaces proposées aux utilisateurs, les solutions d’IAMaaS mettent à disposition des API REST modernes, adaptés aux applications web (HTML5/Angular.js) ou aux applications mobiles, permettant à celles-ci d’interagir directement dans la gestion des identités. De quoi accompagner la transformation numérique que toute entreprise aborde aujourd’hui.

De nombreux acteurs sont aujourd’hui sur ce marché actif et l’offre fonctionnelle est très riche : Okta, Salesorce, Microsoft, Ping Identity, Memority, RSA, Cap Gemini, etc.

L’option cloud est aujourd’hui incontournable – ne serait-ce qu’en phase de cadrage IAM – et il faut désormais justifier la pertinence et le besoin de rester sur des infrastructures on-premises.

Cet article IAM dans le Cloud : est-ce le moment de se lancer ? 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.

D’où proviennent les échecs en matière d’IAM ? Pourquoi parler d’IAG ?

L’analyse de ces échecs révèle deux causes majeures. La première : l’inadéquation entre les ambitions visées et les moyens alloués. Elle se traduit concrètement par l’absence de gouvernance et de sponsoring transverse, de vision stratégique moyen terme reflet des enjeux métier ou encore de dynamique de construction et d’amélioration dans la durée.

La seconde : l’absence de métrique et d’outillage simple permettant de démontrer et de communiquer sur la situation réelle des habilitations, les apports ou encore le bien-fondé des choix retenus. C’est à ce second écueil que doit répondre l’IAG (Identity and Acces Governance. Par effet de rebond, elle doit également fournir les indicateurs opérationnels pour mieux mobiliser les bons relais dans le management et dans les métiers.

Qu’est-ce que l’IAG ? Quelles fonctionnalités en attendre ?

De manière simplifiée, l’IAG (parfois également appelée Identity & Access Intelligence ou encore Identity Analytics & Intelligence voire Governance Risk & Compliance) vise à fournir les moyens nécessaires au pilotage des données et des usages de l’IAM.

Pour ce faire, elle se positionne comme une « tour de contrôle transverse », alimentée autant par les référentiels Qualité et les règles du contrôle interne que les données de l’IAM et des applications. Au-delà du contrôle, l’IAG doit également offrir des moyens de remédiation.

Concrètement, une solution d’IAG va importer l’ensemble des comptes et habilitations pour les comparer avec les règles métiers; et en les croisant avec les schémas d’organisation, elle proposera des bilans structurés des écarts et des risques.

Elle doit ainsi permettre de prendre en compte l’ensemble des règles et contrôles métiers de l’entreprise (combinaisons toxiques de pouvoirs, accès limités à certaines populations, certaines plages horaires…). Mais aussi de corréler et de présenter les données opérationnelles de l’IAM, et de chaque application, à l’aune de ces règles. Enfin d’organiser et suivre les actions de remédiation nécessaires à la correction des éventuels écarts.

C’est donc un service essentiel pour s’assurer du bon fonctionnement et du bon usage du système IAM, corriger les biais de données et, in fine, améliorer la qualité perçue du service rendu. C’est également une clé pour réaliser rapidement un diagnostic de l’existant et ainsi déclencher une prise de conscience des efforts à réaliser.

Dans quels contextes l’IAG est-elle pertinente ?

Une approche IAG se révèle intéressante autant pour les organisations n’ayant pas engagé de démarche IAM, que pour celles ayant déjà conduit certains chantiers.

Pour les premières, le recours à l’IAG permet de conduire des démarches plus opérationnelles, en prise directe et immédiate avec l’existant en matière de comptes et de droits sur les applicatifs.

Ainsi, cette approche bottom-up permet de réaliser un diagnostic concret, argumenté d’exemples parlants. La prise de conscience est donc simplifiée pour les Métiers. L’ensemble des ingrédients est alors réuni pour engager une démarche d’amélioration plus structurante.

Pour les secondes, nombre d’initiatives pâtissent d’un manque d’indicateurs de suivi d’usage et de qualité. Ce manque est nuisible à la « qualité perçue » du système IAM. Il se révèle également des plus handicapants en cas de suspicion de dysfonctionnement et lors des phases d’investigations associées. Ainsi, l’IAG se pose comme une réponse à ce manque de visibilité.

Alors, l’IAG, «potion magique» pour réussir son projet de gestion des identités ?

En informatique, rien n’est magique ! Toutefois, avec ses fonctionnalités avancées d’analyse et de restitution, l’IAG offre enfin les moyens de mesurer l’efficacité de sa gestion des identités.Et, au prix d’une démarche adaptée, elle permet une prise de conscience parlante par les Métiers et le management.

Les Directions en charge des processus internes, de la qualité ou encore le contrôle interne ont alors un rôle clé de sponsoring à jouer. Elles doivent supporter les initiatives IAG et garantir leur pérennité dans le temps.

En effet, quelques semaines suffisent pour mettre en lumière les menaces et les incohérences majeures portés par les habilitations. Et quelques mois permettent de corriger ces écarts. Mais c’est dans la durée que doit se conduire une stratégie IAG, pour inscrire sa gestion des identités dans une démarche vertueuse d’amélioration durable.

Découvrez bientôt, sur Solucom Insight, comment adapter sa démarche projet pour en tirer le meilleur parti.

Cet article IAG: la gestion des identités a-t-elle enfin des yeux et des oreilles ? 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.

Et puis sont venus les partenaires externes et leurs employés. Dans le cas d’usage classique, un constructeur d’avion doit pouvoir collaborer avec l’ensemble de ses sous-traitants : il faut leur permettre l’accès aux applications, gérer ou faire gérer leurs comptes et leurs droits. La fédération des identités ainsi que ses standards et protocoles ont permis de répondre à cette problématique. La gestion des identités si elle devait prévoir de nouveaux processus n’a été que faiblement impactée (la volumétrie restait d’un ordre de grandeur comparable, les utilisateurs restaient des humains maîtrisés, etc.)

Aujourd’hui, un premier palier doit être franchi pour gérer une volumétrie beaucoup plus forte et des utilisateurs d’un nouveau type : les clients. Des centaines de milliers voire des millions d’identités. Il faut maintenant gérer l’identité d’un client et pouvoir l’authentifier et l’autoriser sur les applications mises à sa disposition. Il faut savoir l‘authentifier simplement de son point de vue (e.g. via un réseau social) et faire le lien avec son compte traditionnel dans le CRM pour gérer la relation. Les opérateurs télécoms et les banques et leurs bases clients sont devenues le nouveau cas d’usage classique : les accès aux applications via Internet et terminaux mobiles sont dans l’air du temps.

Au-delà de ce changement d’échelle, les caractéristiques de ces identités de clients sont différentes des traditionnelles identités de l’entreprise : le nombre d’applications accédées et de rôles est plus faible. Par ailleurs, plus question de devoir gérer des cas particuliers, tous les clients sont logés à la même enseigne et ce pour le plus grand bénéfice des projets IAM qui vont enfin voir se réduire fortement leur complexité fonctionnelle.

Enfin, un deuxième palier s’annonce déjà : la gestion des identités des objets connectés. Le CES 2014 qui s’achève ces jours-ci nous en offre de multiples illustrations : brosses à dent, cocottes minutes, lits, ampoules, etc. Tous les objets du quotidien sont désormais connectés. Par ailleurs, la complexité et les facultés de ces objets nous environnant sont telles aujourd’hui que de nouvelles approches sont nécessaires.

Les premiers objets connectés étaient de simples capteurs : température, pression, cellules infrarouge, compteurs, etc. Généralement non connectés directement à Internet, ils émettaient de l’information dans un protocole spécifique à destination d’une passerelle qui elle avait pour rôle de centraliser les données et de les transmettre via Internet à un serveur de traitement.

Nouveaux usages et nouveaux besoins

L’identification de ces objets est alors très sommaire, allant de la simple déclaration d’adresse MAC jusqu’à l’utilisation d’une clé de chiffrement des échanges pour les installations les plus sophistiquées.

Les objets connectés sont maintenant non seulement émetteurs de données de plus en plus complexes mais également destinataires de commandes et d’action à réaliser, de correctifs et patches de sécurité, etc.

Dernier cas d’usage classique à la mode : la voiture connectée informe directement le constructeur ou le concessionnaire qu’un sous-composant est en mauvaise santé ou qu’une révision est nécessaire.

Ces objets doivent pouvoir être joints depuis n’importe où (et ne plus être masqués par une passerelle) et par ailleurs, les capacités d’attaques cybercriminelles ayant fortement augmentés ces dernières années, la sécurité des échanges et l’authentification préalable des objets est devenu un prérequis. Et nous voilà donc avec des milliers d’objets disposant d’une identité !

Cet article Des objets et des hommes est apparu en premier sur RiskInsight.

Que peut apporter le SIRH à ma solution IAM ?

Pour remplir ses objectifs, mon IAM doit être en mesure de répondre à des questions simples  en apparence: qui est cet utilisateur, quel est son nom, son prénom, son matricule ? Quelle est sa fonction dans l’entreprise, quel métier exerce-t-il, et par extension, quelles applications devra-t-il utiliser, ou encore quelles listes de diffusion seront adéquates pour lui ? Qui est son supérieur hiérarchique, et peut-être futur valideur pour ses demandes d’habilitations ? Quelle est son organisation de rattachement ?

Obtenir ces réponses est un premier besoin… mais n’est pas le seul ! Ses informations évoluent : un nouveau collaborateur intègre l’entreprise dans une semaine, il faut lui donner le plus rapidement possible ses accès SI pour qu’il puisse travailler ; Mademoiselle Durand, anciennement contrôleuse de gestion, devient responsable de la comptabilité… il faut lui donner ses nouveaux accès, certes, mais également supprimer les droits qui lui sont devenus inutiles, voire qui pourraient devenir « dangereux » par rapport à son nouveau poste (SoD). Monsieur Thomas, lui, quitte définitivement l’entreprise – or il avait accès (et à distance) à une application critique du SI : ses accès doivent être supprimés dès son départ !

Ces éléments et leurs mises à jour sont généralement présents dans le SIRH d’une entreprise, notamment en raison du lien de celui-ci avec la paie, qui a besoin de savoir qui payer (et quand arrêter de payer), qui est responsable des augmentations d’untel ou d’untel, quelle entité sera facturée, etc. Avec de tels enjeux financiers à la clé, un soin particulier est généralement accordé au maintien à jour de ce référentiel… une opportunité pour mon IAM !

Des atouts certains… mais des limites à avoir en tête

Les liens possibles entre SIRH et IAM sont donc bien réels. Mais attention cependant à ne pas oublier un point essentiel : systèmes d’information et ressources humaines sont deux univers différents, portés par des métiers différents, avec des enjeux, des objectifs, des vocabulaires différents.

Comme nous l’avons dit, le référentiel SIRH est souvent lié à la paie, et cette relation permet d’illustrer les limites des liens qui pourront, ou non, être tissés entre mon SIRH et mon outil d’IAM.

Première limite, là où la paie n’a besoin d’avoir dans son périmètre que les personnes qui seront payées par l’entreprise, mon IAM, lui, se doit de connaître tous les utilisateurs de mon SI, qu’ils soient prestataires, intérimaires ou salariés.

La notion de métier ou encore de hiérarchie n’est pas forcément identique dans le SIRH et  pour l’IAM. Pour le SIRH, Mme Mercier est supérieure hiérarchique de Mlle Durand, car c’est elle qui est responsable de ses augmentations… mais au quotidien, c’est M. Simon son manager ! Et c’est bien lui qui sera légitime pour valider les demandes d’habilitations de Mlle Durand. Les priorités ne sont pas non plus toujours les mêmes entre ces deux univers : un nouvel arrivant doit avoir ses accès SI (et donc être créé dans l’IAM) dès son arrivée… en revanche, il y a souvent moins d’urgence à le créer dans le SIRH, car il ne percevra son premier salaire qu’à la fin du mois…

Lorsque qu’il s’agit de parler de mobilité interne, les deux mondes peuvent également avoir quelques différends. Un collaborateur change d’équipe projet, tout en restant rattaché au même département ? Au niveau du SIRH, ce n’est pas une mutation, son métier reste la même. D’un point de vue SI, a contrario, ce changement constitue un petit bouleversement : son responsable opérationnel (et valideur) n’est plus le même, et l’utilisateur n’a plus les mêmes besoins en termes d’applications métiers. À l’inverse, un changement de nom d’organisation pour toute une filiale n’a quasiment aucun impact sur le SI, alors que tous les utilisateurs sont impactés dans le référentiel RH.

Comment s’interfacer avec le SIRH ?

Comme nous l’avons vu, le SIRH est capable de fournir énormément d’informations structurantes pour ma solution d’IAM, mais possède des spécificités à ne surtout pas négliger. Afin de tirer pleinement parti de cette source d’information et réussir un interfaçage propre, efficace et limitant au maximum les malentendus entre ces deux mondes, trois éléments sont nécessaires :

• Dans un premier temps, définir les éléments structurants pour l’activité opérationnelle et qui seront exploités par l’IAM : les organisations de rattachement des utilisateurs, leurs supérieurs hiérarchiques, les dates d’arrivées et de départ, etc.

• Il est ensuite primordial de se doter de l’organisation, des processus et outil d’IAM flexible, capable de s’adapter aux différences évoquées précédemment. La solution IAM doit ainsi permettre la création d‘identités en avance de phase, ou encore la modification manuelle de certains attributs d’identité. Elle doit conserver une certaine marge de manœuvre sur la gestion de ses identités, ne pas avoir une dépendance trop rigide vis-à-vis du SIRH.

• Enfin, une attention particulière doit être portée à la réconciliation entre les identités du SIRH et celles de l’IAM. Qu’un utilisateur soit créé « en avance » dans l’IAM, ou que certains de ses attributs soient modifiés manuellement, le lien avec le SIRH doit être assuré… faute de quoi, gare aux doublons et aux identités fantômes. Définir une clé unique de réconciliation entre les identités est indispensable pour un interfaçage efficace… et pérenne !

Le SI RH peut se révéler d’une aide précieuse pour la gestion du cycle de vie des utilisateurs grâce aux informations dont il dispose sur les personnes et sa connaissance des mobilités et départs. À condition toutefois de bien comprendre les processus RH sous-jacents, leurs particularités par rapport au monde du SI, et de s’y adapter dans une logique de gestion des identités et de contrôle des accès, sujet qui fera l’objet d’un prochain article.

Cet article Interface avec le SIRH : une opportunité pour l’IAM ? est apparu en premier sur RiskInsight.

Internet : à chaque usage son avatar

Des réseaux sociaux à votre banque en ligne, en passant par votre messagerie électronique, tous ces comptes, ou « avatars », vous représentent dans la sphère numérique. Mais le développement libre et tous azimuts d’internet pose d’évidents problèmes de confiance. Se pose notamment la question du lien entre une personne physique, ses avatars numériques, et le sujet de droit qui la représente dans le cadre juridique. L’ère numérique se caractérise par la constante augmentation de la dématérialisation des usages : achats, déclaration d’impôts, signature de contrats, etc. Autant d’activités qui nécessitent de fournir des informations d’identification fiables.

Cet article L’identité numérique, vecteur de confiance 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.

Le certificat au coeur de la confiance numérique

Au centre de la confiance numérique repose le fameux « certificat ». Cette carte d’identité numérique, délivrée par les infrastructures de gestions de clés (IGC ou encore PKI),  permet de garantir qu’une personne, un équipement ou un service est bien celui qu’il prétend être dans le monde numérique.  Ce certificat est stocké sur des supports variés, pouvant être physiques (carte à puce, clé USB, badge) ou logiques (fichier). Il a le rôle d’une carte d’identité présentée lors de l’accès à des services ou à des informations pour prouver son identité.

Structurer une offre de services sous 3 axes

Pour tirer le meilleur parti des investissements réalisés, nos retours d’expérience montrent que l’entreprise doit s’attacher à construire son catalogue de service de confiance numérique en trois volets.  Premier volet, la fourniture simple de certificats. Les utilisateurs finaux pourront alors utiliser ces certificats dans leurs propres systèmes ou pour leurs projets techniques. C’est par exemple le cas de projets d’applications web métiers, d’authentification réseaux (802.1x)… Deuxième volet, la fourniture de services de confiance destinés à l’utilisateur et intégrant des certificats. Il s’agit par exemple de projets badges uniques (bâtiment, restauration, système d’information…), de chiffrement de messagerie ou de poste de travail. Le certificat est alors intégré de manière transparente dans les services fournis. Troisième et dernier volet, la fourniture de services « métiers » intégrant la confiance numérique. La dématérialisation des processus (bulletins de paye, facturation), les coffres forts numériques ou le stockage à valeur probante sont des exemples parlants.

Les 3 règles d’or de la construction

Mais au-delà de cette catégorisation, quels sont les éléments clés de la constitution de ces services ?

Règle n°1 : identifier les premiers « quick wins »

Le premier défi rencontré est celui de l’identification initiale et de l’extension du périmètre des services. L’implication des acteurs sécurité permet de recenser les besoins et préciser les volumétries, selon différentes typologies d’utilisateurs. L’identification de « quick wins » permet de cibler les premiers investissements à travers la valeur ajoutée des services qu’ils offriront. A cet égard, on peut envisager de ne retenir d’abord qu’un nombre limité de fonctionnalités de sécurité, au profit de fonctionnalités dites « de confort ». On pourra ainsi, dans un premier temps, coupler accès distant au SI (VPN) et messagerie sécurisée (signature et chiffrement de mails) et dans un second temps, une fois les identités numériques largement déployées, s’atteler à la greffe de services de sécurité éventuellement plus poussés : chiffrement de données, signature de documents, signature de code.

Règle n°2 : privilégier l’ergonomie et la facilité d’usage

En outre, l’ergonomie des outils doit rester au cœur des préoccupations : simplicité d’emploi, transparence de l’intégration au poste de travail, mais également gestion des accès de secours. Car si l’implémentation de ces derniers constitue souvent une atteinte au niveau de sécurité des outils, force est d’avouer qu’une offre rendant l’oubli du support cryptographique (carte à puce, clé USB.) bloquant pour l’utilisateur, compromettra l’acceptabilité de la solution toute entière, notamment auprès des utilisateurs les plus exigeants. lesquels sont aussi souvent les plus influents. C’est pourquoi  une étude précise des besoins des métiers permettra d’identifier le meilleur compromis entre niveau de sécurité et types d’accès de secours exigés par les utilisateurs. Notons également l’importance du dispositif utilisé, clé du succès de l’offre : un projet de badge unique, offrant par exemple, l’accès aux bâtiments, le paiement à la cantine et la sécurisation de la messagerie, comprend de vraies complexités organisationnelles mais apporte une valeur ajoutée considérable

Règle n°3 : le RSSI, sponsor de choix

Last but not least, notons que le RSSI doit, autant que possible, servir d’appui moteur au déploiement des services, que ce soit de façon directe, par exemple par le biais d’une participation au financement du projet abaissant ainsi le coût utilisateur, ou de façon indirecte, via la promulgation de règles de sécurité imposant in fine l’utilisation des services de confiance. Ce sponsoring est d’autant plus crucial que la plupart du temps, l’appétence des utilisateurs finaux pour les services de confiance numérique est relativement modeste et ne suffit pas à donner un élan au projet

La confiance a de l’avenir

Le monde a commencé sans l’homme et s’achèvera sans lui », nota le crépusculaire Levi-Strauss. « L’homme a commencé sans l’informatique et s’achèvera sans elle », pourrons-nous dire de façon analogue. Nous avons montré plus haut que, si la confiance est d’ores et déjà au coeœur de beaucoup de services offerts par les DSI, cela n’occulte en rien le fait que cette notion dépasse largement l’IT. Les technologies changent mais les principes et processus perdurent, aussi le périmètre des services de confiance s’étend-il inéluctablement aux usages métiers les plus divers, à travers la dématérialisation notamment. Le chemin est, nous l’avons vu, semé d’embûches, mais pour l’offreur avisé, c’est donc un succès assuré. Ad augusta per angusta ! (*) »

(*) « Vers la gloire, par des chemins étroits » (Victor Hugo, Hernani)

Cet article Services de confiance numérique : pour que le contrat de confiance règne ! est apparu en premier sur RiskInsight.

La difficulté de la prédictibilité des coûts dans le cloud

Le modèle du cloud nécessite une attention forte pour ne pas perdre au bout de quelques temps les gains économiques escomptés, voire éviter une réelle dérive des coûts. Dans le cloud, comme au sein du SI historique, une gestion fiable des identités est ainsi essentielle pour garantir durablement la maîtrise du nombre d’accédants à ces services.

Bien évidemment, elle vise également à renforcer la protection de l’accès aux informations qui y sont stockées. Elle y est même encore plus indispensable, vu l’absence de garde-fous traditionnellement rencontrés, comme par exemple la « porte d’entrée » Active Directory ou le contrôle d’accès physique.

Gérer les identités dans le cloud : quelles stratégies gagnantes ?

Comment le faire concrètement ? Plusieurs solutions sont envisageables :

–       Gestion manuelle sur le site du service cloud par les équipes de l’entreprise. C’est certes efficace pour lancer rapidement des initiatives cloud, mais il faut prévoir de rencontrer, tout aussi rapidement, toutes les limites bien connues de la gestion manuelle : écart, difficultés de maintien, complexité des revues…

–       Gestion automatisée via un service de provisioning/deprovisioning avec des contrôles a priori (validations) et/ou a posteriori (contrôles et recertifications) : l’accès aux services cloud piloté par les processus et les outils IAM de l’entreprise. Mêmes solutions que dans le SI historique… et mêmes vigilances et bonnes pratiques pour éviter toute désillusion !

–       Gestion automatisée via un service de fédération d’identités : certainement aujourd’hui la solution à privilégier quand cela est possible, puisqu’elle apporte des réponses satisfaisantes aussi bien sur les problématiques de gestion au quotidien qu’en termes d’expérience utilisateur. Après des années de balbutiements où les entreprises n’allaient quasiment jamais plus loin qu’un prototype, les derniers dix-huit mois marquent le réel envol de la fédération avec des réalisations significatives.

–       Gestion automatisée et fédérée par un tiers de confiance, jouant le rôle d’intermédiaire entre l’entreprise et les différents offreurs de services cloud. Des acteurs commencent à se positionner sur ce sujet, mais la classique question de la confiance se pose !

Le cloud : un booster pour les projets IAM

Sujets à traiter, bon sens et bonnes pratiques, priorisation et angles d’attaque, risques et écueils à éviter : la gestion des identités dans le cloud doit relever les mêmes challenges que dans le SI historique.

Et si le cloud était un levier formidable pour d’une part simplifier et fiabiliser les processus et outillages IAM actuels, et d’autre part faire décoller l’usage de nouveaux services IAM de type reporting et recertification ?

Cet article Cloud computing : maîtriser ses coûts grâce à une bonne gestion des identités est apparu en premier sur RiskInsight.