Il y a deux ans, nous posions la question de savoir si l’IA pouvait constituer une révolution pour l’IAM dans notre article « L’intelligence artificielle, une révolution pour l’IAM ? – RiskInsight ». Nous insistions déjà sur la nécessité d’une approche nuancée, fondée sur des cas d’usage concrets, une logique de test and learn et une exigence de confiance compatible avec les enjeux propres à l’identité et aux accès.

Aujourd’hui, le constat a gagné en précision : l’IA n’a pas provoqué la rupture que certains annonçaient, mais elle commence à y trouver une place réelle, plus ciblée et surtout plus pragmatique.

Ce que l’on observe aussi c’est que l’IA entraine un élargissement du périmètre de l’IAM : l’IAM doit désormais aussi traiter les enjeux liés à l’IA et aux agents IA.
Pour approfondir ce point, nous vous invitons à consulter notre article « Sécuriser les agents IA : pourquoi l’IAM devient central – RiskInsight ».

Pour rappel, l’intelligence artificielle s’impose progressivement comme un levier de transformation des systèmes d’information, et l’IAM n’échappe pas à cette dynamique. Face à la multiplication des identités portée par des transformations de nature différente, qu’il s’agisse d’évolutions d’infrastructure avec le cloud, de changements de vision métier avec l’essor du CIAM ou encore de l’arrivée de nouvelles technologies comme les agents d’IA, les organisations doivent composer avec des modèles d’habilitation toujours plus riches et difficiles à maintenir.

Dans ce contexte, l’IA promet de rendre les services IAM plus efficaces et plus accessibles, qu’il s’agisse de recommandations intelligentes, d’assistants conversationnels, d’une meilleure exploitation des données ou du traitement de volumétrie difficilement gérable par des approches classiques.

Toutefois, ces apports appellent à la prudence. L’IAM touche directement à la sécurité des accès : à ce stade, l’IA doit y rester un outil d’assistance, sous supervision humaine, car la responsabilité ne saurait lui être déléguée. Sur le terrain, elle se manifeste d’ailleurs encore majoritairement sous forme de briques périphériques (copilots, chatbots, agents) qui viennent enrichir l’existant sans bouleverser les fonctions critiques. L’enjeu n’est donc plus tant de savoir si l’IA a sa place en l’IAM, mais d’identifier où et comment l’appliquer de manière réellement pertinente.

2.    Quels cas d’usage IA ont réellement du sens en IAM ?

Les apports de l’IA dans l’IAM sont répartis de manière inégale :

• L’​​​​Identity Governance & Administration (IGA) concentre l’essentiel des initiatives grâce à ses volumes de données et ses décisions fréquentes (revues, validations, recommandations)
• L’Access Management (AM) est lui aussi largement mis en avant, avec des projets visant avant tout à accélérer et fluidifier le parcours d’authentification des utilisateurs.
• Le Privileged Access Management (PAM) voit émerger des usages plus ciblés, notamment autour de la détection et de la surveillance des comportements à privilèges.
• Le potentiel de l’IA dans le Customer Identity and Access Management (CIAM) reste encore relativement peu exploité, alors même qu’il tend à devenir stratégique. Il apparaît notamment dans l’émergence d’agents IA capables d’interagir ou d’agir pour le compte des utilisateurs, en particulier via des chatbots.
• L’IA présente aujourd’hui une valeur limitée pour les Trust Services, dont les processus sont déjà largement automatisables sans IA, et se positionne davantage en support périphérique

Pour structurer ces initiatives sans tomber dans l’effet catalogue, deux grandes familles de cas d’usage se distinguent :

1. Ceux qui visent à résoudre des irritants connus dans les processus existants
2. Ceux qui permettent de traiter des problématiques que les approches traditionnelles ne parviennent pas à adresser.

La valeur de l’IA émerge d’abord des irritants actuels de l’IAM…

Cette première famille de cas d’usage constitue généralement le point d’entrée le plus naturel, car elle s’appuie sur des processus IAM déjà en place.

L’IA y joue alors un rôle d’accélérateur, en réduisant les coûts et la charge opérationnelle, tout en améliorant l’expérience, la qualité de service et la rapidité d’exécution, sans remettre en cause le modèle de contrôle.

…pour devenir un levier permettant de dépasser les limites des approches traditionnelles

La seconde famille de cas d’usage relève d’un registre différent : l’IA n’y vise plus seulement un gain de temps, mais ouvre des capacités d’analyse inaccessibles aux approches classiques, en croisant de multiples signaux (identité, organisation, droits, usage, événements) sur des volumes importants. Elle permet notamment de détecter à grande échelle des accès atypiques, tels que des combinaisons rares de droits, des habilitations incohérentes avec une fonction ou des accumulations liées à des exceptions successives.

L’IA rend également possible l’analyse de trajectoires d’habilitation, en identifiant comment certains profils dérivent au fil des mobilités, projets ou urgences, afin de cibler les actions de remédiation. Elle permet aussi une priorisation intelligente de ces remédiations en combinant criticité des applications, sensibilité des données et signaux d’usage, tandis que dans le domaine du PAM, des usages émergents visent à repérer des comportements à privilèges inhabituels pour déclencher des contrôles renforcés.

Enfin, cela ouvre également la voie à une délégation de tâches à plus faible valeur ajoutée, comme le traitement de tickets de niveau 1, pour lesquelles l’automatisation était techniquement envisageable mais économiquement difficile à justifier. Aujourd’hui, certaines solutions IAM « boostées » à l’IA rendent cette substitution réaliste et accessible.

La multiplication des irritants et des pistes d’automatisation ne doit pas pour autant conduire à déployer l’IA de manière indiscriminée. Certains besoins se traitent efficacement à l’aide de règles ou d’algorithmes simples, et dès lors que l’on touche aux accès, chaque erreur potentielle comporte un risque de sécurité. Il est donc essentiel, une fois les cas d’usage identifiés, de les sélectionner et de les prioriser, plutôt que d’accumuler les initiatives.

3.    Prioriser l’IA dans l’IAM avant qu’elle ne devienne un empilement d’initiatives

Une fois les cas d’usage pertinents identifiés, il convient de déterminer ceux sur lesquels concentrer les efforts, car tous ne justifient pas le même niveau d’investissement. La priorisation peut ainsi s’appuyer sur deux axes clés : la valeur ajoutée et la complexité de mise en œuvre.

La difficulté réside ici dans la capacité à analyser rigoureusement ces deux axes pour chaque cas d’usage.

Le premier axe, relatif à la valeur, peut ainsi être appréhendé à travers plusieurs sous critères :

• La réduction des coûts opérationnels : mesurer comment le cas d’usage permet d’éviter certains coûts récurrents
• Les gains d’efficacité et la réaffectation des efforts : la capacité à libérer du temps et à réorienter les équipes vers des tâches à plus forte valeur ajoutée.
• La diminution du risque cyber: l’impact du cas d’usage sur la réduction d’un risque identifié en matière de cybersécurité, d’informatique ou de contrôle
• La contribution aux enjeux réglementaires et stratégiques : dans quelle mesure le cas d’usage répond à une attente réglementaire ou stratégique prioritaire (par exemple, DORA, BCE, audits)
• L’impact sur les populations concernées : apprécier à qui le cas d’usage rend service et avec quelle fréquence d’usage, car un usage modeste mais mobilisé au quotidien par un grand nombre d’utilisateurs peut créer plus de valeur qu’un cas d’usage plus ambitieux mais limité à un périmètre restreint. Les principales populations à considérer sont généralement les administrateurs IAM, les intégrateurs IAM, les utilisateurs finaux et les managers approbateurs.

Le second axe, la complexité peut être évaluée selon quatre dimensions complémentaires. Elle inclut :

• L’exploitation des données : dans quelle mesure les données nécessaires au cas d’usage sont disponibles, de qualité suffisante et accessibles dans des conditions compatibles avec sa mise en œuvre.
• La complexité technique : l’effort technologique requis pour déployer le cas d’usage, qu’il s’agisse des intégrations, de l’architecture, des modèles d’IA mobilisés ou des dépendances vis-à-vis du système d’information existant.
• La complexité organisationnelle : le niveau de coordination nécessaire entre les équipes, les périmètres et les processus pour porter le cas d’usage de manière effective.
• Les risques associés : les risques cyber, réglementaires ou opérationnels susceptibles d’être introduits ou renforcés par la mise en œuvre du cas d’usage.

Pour rappel, cette approche vise avant tout à guider la réflexion et à structurer les arbitrages, et n’est qu’une proposition qui doit donc être adaptée à chaque contexte.

Les cas d’usage à fort impact mais rapides à déployer doivent être privilégiés. À l’inverse, ceux mobilisant des efforts importants (données indisponibles, intégrations complexes, exigences de sécurité élevées) pour un bénéfice limité doivent être écartés ou différés. Pour rendre l’arbitrage concret, une logique “matrice” fonctionne bien :

Toutefois, cette démarche suppose aussi d’être lucide sur un point : l’IA dépend fortement des données (qualité, complétude, traçabilité, référentiels) et de la capacité à l’exploiter de manière sécurisée. Sans fondations solides, même un cas d’usage prometteur restera au stade de démonstration. Car pour produire de la valeur en conditions réelles, il doit pouvoir s’appuyer sur des bases IAM suffisamment robustes : qualité des données, structuration des référentiels, stabilité des processus, lisibilité du modèle d’habilitation, etc. Ainsi, la priorisation doit être confrontée à la réalité des solutions disponibles et à leur maturité.

4.    Un marché en effervescence, des usages encore largement inégaux

Le marché IAM s’anime fortement autour de l’IA, avec des feuilles de route qui s’étoffent et l’émergence de produits dits « IA-native », conçus dès l’origine pour intégrer des mécanismes d’assistance, d’analyse et d’automatisation. Ces approches répondent généralement soit à un besoin ciblé, soit à une logique de différenciation sur un marché en forte évolution.

En parallèle, les solutions IAM historiques enrichissent progressivement leurs offres avec des fonctionnalités d’IA et bénéficient généralement de moyens plus importants que les acteurs IA‑native pour soutenir cette transformation, principalement dans des environnements cloud, plus propices à leur déploiement que les architectures on‑premise.

Il subsiste toutefois un décalage notable entre promesse et réalité en production : la plupart des fonctionnalités disponibles aujourd’hui relèvent encore de l’assistance périphérique (recherche, résumé, copilots) plutôt que d’une IA véritablement embarquée dans les fonctions critiques.

L’adoption reste par ailleurs progressive, en particulier dans les grands comptes, où la priorité demeure l’optimisation de l’existant, la stabilisation des référentiels, la réduction de la dette technique et la conformité. Les approches IA-native, encore relativement nouvelles, doivent s’intégrer à une trajectoire réaliste et à un modèle d’exploitation clair. L’IA ne saurait être considérée comme un produit miracle, mais bien comme un levier à inscrire dans une transformation globale de l’IAM.

5.    Conclusion – De l’effet d’annonce à une trajectoire maîtrisée

L’IA appliquée à l’IAM semble franchir un cap. Le véritable enjeu n’est pas d’accumuler les cas d’usage : il s’agit de construire une démarche cohérente, sélective et durable. Parce qu’elle intervient sur la décision d’accès, l’IA en IAM exige un niveau de prudence supérieur à d’autres domaines. La promesse de l’automatisation ne doit jamais masquer la responsabilité de l’humain et des organisations. Toute recommandation doit pouvoir être comprise, contestée et justifiée, notamment en contexte d’audit. Il faut définir clairement qui valide et qui arbitre, garantir l’acceptation des équipes métier sans laquelle l’IA sera contournée, assurer la conformité réglementaire et cadrer rigoureusement les données exposées aux assistants pour prévenir toute exfiltration d’informations sensibles.

Pour tenir cette trajectoire, il ne suffit pas d’évaluer les cas d’usage isolément : il faut faire évoluer les fondations (qualité des données identitaires, référentiels, modèle de rôles, contrôles), définir un modèle opérationnel capable de superviser l’IA au quotidien et sécuriser les usages émergents, notamment autour des agents d’IA. L’IA pour l’IAM ne doit donc pas être pensée comme une révolution immédiate, mais comme une progression graduelle, des briques d’assistance vers des capacités d’analyse avancées pour finalement arriver à des automatisations mieux maîtrisées.

Au fond, bien aborder l’IA dans l’IAM, c’est avancer avec pragmatisme, en ciblant les usages présentant le meilleur équilibre entre valeur et complexité, en gardant la maîtrise des décisions sensibles et en restant attentif à la maturité réelle du marché.

6.    Cinq priorités pour lancer une trajectoire IA en IAM

En résumé, voici les points à garder en tête pour s’adapter à cette transformation :

1. Identifiez les cas d’usage IA qui ont réellement du sens pour l’IAM, qu’il s’agisse d’améliorer l’existant ou d’ouvrir de nouvelles capacités d’analyse et d’automatisation.
2. Définir objectivement la valeur et la complexité de chaque cas d’usage afin de les prioriser en vue de leur mise en œuvre.
3. Construisez une trajectoire progressive, maîtrisée et gouvernée, plutôt qu’accumuler des initiatives sans vision d’ensemble.
4. Le marché se structure rapidement : échangez avec vos éditeurs pour comprendre ce qu’ils proposent réellement.
5. Renseignez-vous aussi sur les nouvelles solutions émergentes, notamment IA-native, et n’hésitez pas à nous solliciter si vous souhaitez confronter vos premiers retours de terrain ou enrichir votre vision du marché.

Cet article IA pour l’IAM : Une trajectoire pragmatique plutôt qu’une révolution est apparu en premier sur RiskInsight.

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.

L’effervescence croissante au sujet de l’avènement des ordinateurs quantiques est justifiée pour un sujet qui ne relève plus de la science-fiction, mais qui implique une menace d’un nouveau genre.

En effet, selon les prévisions de nombreux experts tels que le Global Risk Institute, les ordinateurs quantiques devraient prochainement être capables de résoudre les problèmes mathématiques qui sous-tendent les standards cryptographiques actuels – ce qui, en conséquence, rendrait obsolètes les systèmes classiques protégeant nos communications, nos finances et nos infrastructures critiques.

Pour les entreprises, l’urgence n’est plus de se demander si cette menace deviendra réalité, mais quand. Comment anticiper les impacts opérationnels et structurels de ce bouleversement technologique tout en répondant aux recommandations croissantes des régulations à ce sujet ? Quels outils adopter pour garantir la confidentialité et l’intégrité des données dans un futur proche ? Le défi est de taille, mais des solutions sont à l’étude comme la cryptographie post-quantique (PQC), déjà massivement plébiscitée par la communauté internationale. 

La menace quantique

Aujourd’hui, la sécurité des systèmes d’information repose principalement sur la cryptographie symétrique, asymétrique (ou à clé publique) et les fonctions de hachage. Ces catégories sont représentées par des algorithmes largement utilisés aujourd’hui, en particulier AES, RSA, ECC, ainsi que SHA pour les fonctions de hachage. Adoptés massivement par la communauté mondiale et intégrés nativement dans de nombreux dispositifs modernes, ces algorithmes ont fait leurs preuves depuis des décennies pour assurer la confidentialité, l’authenticité et l’intégrité des échanges de données.

Les problèmes mathématiques sur lesquels sont basés ces standards présentent un niveau de complexité de calcul suffisant pour assurer l’absence de capacité de brute-force même avec les meilleurs supercalculateurs actuels.

L’ordinateur quantique vient rebattre ces cartes.

Ces machines reposent sur des principes physiques fondamentalement différents des ordinateurs classiques actuels. Grâce aux phénomènes de superposition et d’intrication, un processeur quantique peut traiter simultanément différents états physiques. Ce que l’on décrit souvent comme du « parallélisme quantique » ne correspond pas à un simple calcul parallèle classique (où plusieurs cœurs exécutent des tâches identiques), mais à la capacité d’explorer simultanément de multiples chemins d’exécution. Pour certains algorithmes, cette approche permet de réduire considérablement l’espace de recherche et d’accélérer le traitement.

Une question essentielle se pose alors : existe-t-il déjà des algorithmes capables d’exploiter ces propriétés quantiques, et ainsi de venir à bout des standards de chiffrement actuels ?

En 1994, P. Shor, suivi de L. Grover en 1996, introduisent des algorithmes intégrant des processus de calcul quantique pour résoudre certains problèmes mathématiques complexes. Le premier permet de factoriser de grands nombres de manière exponentiellement plus rapide qu’un algorithme classique, tandis que le second optimise la recherche d’un élément dans des ensembles non ordonnés. Si les caractéristiques  des ordinateurs classiques rendaient jusque-là leur mise en œuvre impraticable, l’émergence des ordinateurs quantiques changerait radicalement la donne, rendant ces algorithmes exploitables. 

En effet, le meilleur supercalculateur mettrait 1.02 x 10¹⁸ ans (un trillion d’années) pour casser AES-128 par force brute et 10¹⁰ ans (10 milliards d’années) pour RSA-2048 avec les meilleures méthodes actuelles. En comparaison, un ordinateur quantique exécutant l’algorithme de Grover pourrait briser AES-128 en 600 ans, tandis que l’algorithme de Shor viendrait à bout de RSA-2048 en seulement 8 heures avec une machine de 20 millions de qubits.

Face à cette menace, AES et la cryptographie symétrique, ainsi que SHA-256 et les fonctions de hachages restent viables en doublant la taille des clés utilisées, mais la cryptographie asymétrique doit être repensée. Dans cette optique, la cryptographie post-quantique s’impose comme la solution la plus prometteuse. 

Qu’est-ce que la cryptographie post-quantique ?

Selon l’ANSSI, « la cryptographie post-quantique (PQC) est un ensemble d’algorithmes cryptographiques classiques comprenant les établissements de clés et les signatures numériques, et assurant une sécurité conjecturée vis-à-vis de la menace quantique en plus de leur sécurité classique ».

Cela désigne donc l’ensemble des nouveaux algorithmes de chiffrement asymétriques capables de garantir la sécurité à la fois face aux attaques classiques, et face aux nouvelles attaques quantiques. La différence avec ceux que nous utilisons aujourd’hui réside essentiellement dans les problèmes mathématiques sous-jacents aux algorithmes, choisis pour rester complexes à résoudre, même pour un ordinateur quantique.

Pourquoi cette solution est-elle considérée comme la plus prometteuse ?

La PQC n’est pas la seule réponse envisagée face à la menace quantique, mais elle est largement considérée comme étant la solution la plus viable selon la communauté internationale. Plusieurs facteurs expliquent cet intérêt, parmi lesquels on retrouve :

• Une continuité avec les systèmes actuels, facilitant son adoption et son intégration progressive dans les infrastructures classiques.
• Une maturité avancée, avec des standards déjà établis et soutenus par les principales autorités en cybersécurité.

Une continuité avec les systèmes actuels

Comment cette cryptographie de nature classique permet-elle de protéger les données chiffrées face aux attaques quantiques ?

La PQC n’implique pas un changement de paradigme dans notre approche de sécurisation des infrastructures. Comme évoqué plus tôt, la PQC s’inscrit dans la famille de la cryptographie asymétrique et conserve donc le même fonctionnement et objectif que les algorithmes à clé publique actuels. Sa résistance face aux attaques quantiques est assurée par la nature des problèmes mathématiques sous-jacents, différents de ceux utilisés par la cryptographie asymétrique classique.  Cette différence structurelle permet également une intégration plus fluide de cette cryptographie dans les infrastructures numériques actuelles, assurant ainsi une transition progressive vers un avenir où la PQC supplanterait totalement et efficacement les standards de chiffrement modernes.

Une maturité avancée

Le deuxième atout majeur de la PQC est sa maturité par rapport aux autres options envisagées. En effet, cette année a été marquée la publication des standards de PQC par le National Institute of Standards and Technology (NIST) américain en août 2024.

Ce processus a débuté en 2017 avec 69 candidats initiaux, dont 4 ont été retenus afin de devenir les nouveaux standards de PQC. Aucune des autres solutions évoquées pour contrer la menace à venir, parmi lesquelles se trouve la cryptographie quantique (basée sur l’usage des propriétés quantiques en opposition à la PQC, dont les implémentations sont possibles sur des ordinateurs classiques), n’ont été l’objet d’un processus de standardisation.

De surcroît, les organismes de cybersécurité nationaux tels que l’ANSSI (France), la BSI (Allemagne), la NLNCSA (Pays-Bas), la SFA (Suède), le NCSC (UK), la NSA (USA) etc. s’accordent tous à dire que la PQC est la meilleure façon de se prémunir contre la menace quantique, et que la priorité des entreprises doit être la migration vers des systèmes de PQC.

Quand et comment mettre en place cette technologie ?

Les prédictions des organismes de recherche sur l’avènement  de la menace quantique restent encore assez disparates, mais s’accordent néanmoins à annoncer que des ordinateurs quantiques capables d’exécuter des algorithmes responsables de la future désuétude des standards de cryptographie actuelle, appelés en anglais Cryptographically Relevant Quantum Computer (CRQC) rendront obsolètes RSA-2048 notamment, d’ici les 15 prochaines années. En effet, il est difficile de prédire avec exactitude quand l’ordinateur quantique sera prêt et atteindra des performances suffisantes pour des cas d’usage concrets, mais les croisements entre les recommandations d’organismes comme la la NSA et les prédictions d’experts sur le sujet nous permettent d’estimer l’émergence des premiers CRQC entre 2033 et 2037. 

Harvest now, decrypt later

Nous ne disposons pas pour autant de 10 ans devant nous pour nous armer face à cette menace. Les données en transit actuellement restent exposées aux attaques de type « harvest now, decrypt later ». Ce sont des attaques reposant sur l’interception et le stockage à long terme de données chiffrées, dans l’attente des percées technologiques en matière de décryptage qui les rendraient lisibles à l’avenir.

Les données ciblées par ce type d’attaques sont principalement des données en transit, car c’est lors de leur transport que des protocoles comme TLS utilisent des paires de clés asymétriques. C’est à ce moment que la donnée est « vulnérable au quantique » et donc intéressante à intercepter puis stocker afin de la déchiffrer ultérieurement. Les données au repos sont au contraire généralement chiffrées à l’aide d’algorithmes symétriques, et requiert d’être exfiltrées pour être capturées, elles ne sont donc pas la cible de ces attaques.

Le risque principal de ces attaques demeure la violation de la confidentialité à long terme de données. Selon les secteurs, notamment financier ou industriel, les données peuvent rester sensibles sur de longues périodes et par conséquent l’accès à ces informations peut entraîner des conséquences multiples graves. 

Il est raisonnable de considérer que des attaquants pourraient actuellement récupérer une quantité considérable de données chiffrées afin de les décrypter ultérieurement. Dès lors, il est impératif d’amorcer une migration vers des systèmes cryptographiques résistants aux algorithmes quantiques dès aujourd’hui. 

Recommandations des organismes au sujet de la préparation

La CISA, la NSA et le NIST américain pour ne citer qu’eux, exhortent les entreprises à se préparer dès maintenant en établissant une feuille de route quantique, pilotée par une équipe projet dédiée, dont le but serait de planifier et superviser la migration de l’organisation vers la PQC.

Le cadrage du projet devra être axé sur ces 3 volets principaux :

1. Inventaire cryptographique : l’objectif est de comprendre l’exposition de l’organisation aux mécanismes cryptographiques vulnérables. Cela passe par l’identification des technologies utilisées au sein des systèmes, des protocoles réseaux, des applications, et des bibliothèques de programmation.

2. Analyse de risques : cet axe vise à prioriser les actifs et processus à sécuriser en premier. Il s’agit d’évaluer la criticité des données protégées, mais aussi d’anticiper leur durée de protection nécessaire. Cette analyse repose sur l’inventaire cryptographique fait en amont et permet de cibler les efforts là où l’impact d’une attaque quantique serait le plus critique.

3. Responsabilité des fournisseurs : la transition vers la cryptographie post-quantique implique également un travail étroit avec les partenaires technologiques. Les entreprises doivent s’assurer de la crypto-agilité des solutions qu’elles utilisent : les produits actuels pourront-ils être mis à jour vers des systèmes résistants à la menace quantique ou devront-ils être remplacés pour éviter l’obsolescence ?

La stratégie de migration que nous préconisons chez Wavestone reprend les grandes étapes évoquées par la CISA, la NSA et le NIST, et les approfondit en les adaptant aux réalités opérationnelles de chaque entreprise :

1. Phase stratégique :
   • Compréhension et sensibilisation : Premièrement, il s’agit de former et d’informer l’ensemble des acteurs (direction, équipes métiers, équipes techniques) sur l’impact de la menace quantique, les enjeux liés à la cryptographie post-quantique, ainsi que sur les grandes orientations réglementaires.
   • Évaluation des risques et inventaire initial : Cartographie des usages cryptographiques (protocoles, bibliothèques, applications, etc.) et identification des données sensibles devant rester confidentielles sur une longue période. C’est également à ce stade que l’on évalue la maturité de l’entreprise et qu’on priorise les chantiers les plus critiques.
   • Cadrage du programme : Sur la base des risques identifiés, la feuille de route globale (objectifs, budget, organisation) est définie. Une équipe dédiée – ou “centre d’excellence” – est créée pour piloter la transition, coordonner les différents chantiers et définir les indicateurs de succès.
2. Quick wins
   • Avant d’entrer dans une phase de transformation plus lourde, nous préconisons de lancer rapidement des initiatives à faible investissement, par exemple inclure des clauses post-quantiques dans les contrats (fournisseurs, partenaires). L’objectif est d’obtenir des retours concrets, de sensibiliser davantage les parties prenantes et de créer une dynamique positive autour du projet.
3. Programme de transition
   • Test d’un premier cas d’usage : Sélection d’un cas d’usage représentatif pour déployer, en conditions réelles, les premiers algorithmes ou mécanismes de cryptographie post-quantiques.
   • Inventaire détaillé (seconde itération) : Il faut ensuite affiner la cartographie des composants cryptographiques (PKI, gestion de clés, protocoles réseaux, librairies de chiffrement, etc.) afin de planifier précisément la migration.
   • Modernisation de la “confiance numérique” : Il s’agit d’actualiser les infrastructures (PKI, gestion de certificats, politiques de rotation de clés…) et de mettre en place des procédures permettant d’accueillir les nouveaux algorithmes.
   • Migration et veille : Déploiement progressif des algorithmes post-quantiques sur les systèmes critiques, tout en maintenant la continuité de service. Cette phase s’accompagne de contrôles, de tests de performance et de vérifications de sécurité. À terme, l’ensemble du SI est couvert, garantissant la pérennité et la conformité réglementaire.

Cette feuille de route, à la fois pragmatique et en phase avec les préconisations des organismes compétents, garantit une transition maîtrisée vers la cryptographie post-quantique. 

L’hybridation évoquée en Europe comme une étape importante dans la transition

L’ANSSI dans une publication commune avec plusieurs de ses homologues européens BSI, NLNCSA, SNCSA, et SFA, recommandent également une préparation à cette transition devant débuter le tôt possible. Bien que les nouveaux standards de PQC incluant les algorithmes, les instructions d’implémentation, et leur utilisation, ont été publiés par le NIST en août 2024, ces organismes n’encouragent pas l’intégration immédiate de ces algorithmes dans les systèmes cryptographiques des entreprises. L’ANSSI annonce même « n’approuver aucun remplacement direct à court ou moyen terme ». En cause, « un manque de recul cryptanalytique sur plusieurs aspects de sécurité » ; malgré son processus de standardisation terminé, la PQC n’est pas encore considérée suffisamment mature pour garantir la sécurité à elle seule :

• Plusieurs algorithmes finalistes (et donc jugés comme prometteurs) du processus de standardisation du NIST ont été l’objet d’attaques classiques ayant abouties. L’algorithme SIKE dont on est venu à bout en 10min, et Rainbow en un week-end.
• Le dimensionnement, l’intégration des algorithmes dans des protocoles de communication, et la conception d’implémentations sécurisées sont d’autres aspects sur lesquels il faut progresser selon l’ANSSI.

Par conséquent, au contraire du NIST, l’ANSSI mais également la BSI entre autres, recommande l’adoption de systèmes hybrides par les organisations. C’est un concept qui consiste à « combiner des algorithmes asymétriques post-quantiques avec une cryptographie asymétrique pré-quantique bien connue et bien étudiée » ANSSI. Ainsi, l’on peut bénéficier de l’efficacité des standards actuels sur les attaques classiques, et de la résistance conjecturée de la PQC sur les attaques quantiques.

L’hybridation est possible pour les mécanismes d’encapsulation de clés et pour les signatures numériques. Chaque opération classique est remplacée soit par :

• l’exécution successive,
• l’exécution en parallèle des 2 algorithmes, pré-quantique et quantique.

La deuxième option peut être implémentée dans le but de réduire la perte de performance du système. Ces schémas hybrides nécessitent par ailleurs que les acteurs impliqués supportent les deux types d’algorithmes.

C’est un schéma dont « le surcoût de performance d’un schéma hybride reste faible par rapport au coût du schéma post-quantique ». L’ANSSI estime « qu’il s’agit d’un prix raisonnable à payer pour garantir une sécurité pré-quantique au moins équivalente à celle apportée par les algorithmes normalisés pré-quantiques actuels ».

Outre-manche et Atlantique, on est beaucoup plus nuancé que les homologues européens sur la question. Bien que l’intérêt de l’hybridation soit reconnu par les autorités de cybersécurité anglaise et étatsunienne, le NCSC et le NIST insiste sur le caractère temporaire de cette solution et n’imposent pas l’hybridation comme étape obligatoire avant de migrer totalement vers la PQC. La NSA dit explicitement avoir confiance dans les standards de PQC et ne requiert pas l’utilisation de modèles d’hybridation dans les systèmes de sécurité nationaux. En résumé, la décision d’utiliser ces modèles doit être prise en tenant compte :

• des contraintes techniques d’implémentation,
• de la complexité accrue (deux algorithmes au lieu d’un),
• du coût additionnel,
• de la nécessité de transitionner une seconde fois à l’avenir vers un système de PQC total, , ce qui peut constituer un exercice complexe de crypto-agilité – c’est-à-dire la capacité de modifier rapidement et sans bouleversements majeurs son infrastructure cryptographique en réponse à l’évolution des menaces – pour certaines entreprises.

Aspect règlementaire

Il n’y a actuellement pas de règlementation européenne qui formule d’exigences explicites au sujet de la cryptographie post-quantique. Néanmoins, parmi les différents textes évoquant le chiffrement de données (NIS2, DORA, HDS…), certains exigent explicitement de l’appliquer à l’état de l’art.  DORA impose notamment la mise à jour constante des moyens cryptographiques utilisés par rapport à l’évolution des techniques de cryptanalyse. Il est donc possible de considérer cela comme un premier pas pour guider les organisations vers le concept de crypto-agilité.

Malgré cette absence d’exigences actuellement, l’ANSSI prévoit un plan de transition post-quantique en 3 phases :

1. Phase 1 (en cours)

La sécurité post-quantique effective à travers l’hybridation reste facultative et est considérée par l’agence comme une défense en profondeur. Les visas de sécurité délivrés par l’ANSSI restent inchangés et garantissent uniquement la sécurité pré-quantique.

2. Phase 2 (après 2025)

La résistance quantique devient une propriété de sécurité. Des critères de sécurité post-quantique pour les algorithmes de PQC auront été définis par l’ANSSI, et seront pris en compte dans la délivrance de visas de sécurité.

3. Phase 3 (après 2030)

On estime que le niveau d’assurance de sécurité post-quantique sera équivalent au niveau pré-quantique actuel. L’hybridation deviendra donc optionnelle ; des visas de sécurité pourront être délivrés pour des entreprises utilisant des schémas post-quantiques sans hybridation.

En outre, suivant le contexte, l’ANSSI pourra décider de n’octroyer ses visas de sécurité que pour la sécurité à long terme post-quantique.

Aux Etats-Unis, le plan de transition post-quantique du NIST n’est pas définitif, mais l’obsolescence de RSA et ECC est d’ores et déjà projeté pour 2030, suivi d’une interdiction d’implémentation totale en 2035 ; d’où l’objectif annoncé – aligné avec la NSA – pour l’achèvement de la migration vers la PQC dans l’ensemble des systèmes fédéraux la même année. Selon les exigences des différents secteurs, il sera peut-être nécessaire de transitionner plus rapidement selon les niveaux de risque associés. 

Même si 2035 semble être un horizon lointain, la migration complète vers la cryptographie post-quantique est un long processus, et les phases initiales d’inventaire cryptographique, classification de données et d’analyse de risques notamment, requièrent un temps considérable. Par conséquent, il est essentiel de démarrer dès aujourd’hui afin de planifier une transition réussie.

L’avènement des ordinateurs quantiques n’est donc plus une hypothèse lointaine, mais une certitude qui redéfinira les fondations de la cybersécurité. Si le timing précis (2033-2037) reste incertain , la pression règlementaire impulsée par les institutions de cybersécurité se précise, et les impacts sur la confidentialité et l’intégrité des données sont, eux, inéluctables. Chaque jour qui passe sans adaptation renforce la vulnérabilité des entreprises face aux attaques futures.

Pourtant, des solutions existent déjà : la cryptographie post-quantique, bien que peu mature à date – surtout dans ses implémentations – offre une réponse prometteuse à cette menace. Standardisée et soutenue par les plus grandes instances internationales, elle incarne la première étape vers une sécurité pérenne à l’ère quantique.

Cependant, adopter cette technologie ne se limite pas à un simple déploiement technique. C’est une transition stratégique, un exercice de crypto-agilité , et une opportunité pour les entreprises d’affirmer leur résilience face aux bouleversements technologiques.

La question n’est plus de savoir si votre organisation sera prête lorsque le premier ordinateur quantique capable de briser RSA-2048 verra le jour. Il s’agit de savoir si elle aura su anticiper ce futur, en s’armant dès maintenant des outils et des plans nécessaires pour transformer cette contrainte en un avantage compétitif. Le futur de la sécurité commence aujourd’hui. 

Contactez-nous

Cet article Ordinateur quantique et cryptographie post-quantique : quelle stratégie les entreprises doivent-elles adopter sur ces éléments ? 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.

Démystification du fonctionnement

Ces technologies ont comme objectifs d’identifier et d’extraire les visages d’images ou de flux vidéo, et de calculer une empreinte faciale pour chacun de ces visages, encapsulant l’ensemble de leurs caractéristiques, afin de faciliter une recherche et identification par la suite.  

L’idée d’utiliser le visage comme information d’identification dans des systèmes ainsi que les premiers systèmes fonctionnels remonte aux débuts des années 1960 avec le système Woodrow Wilson Bledsoe (1964), le système était capable de reconnaître des visages en analysant des photos numérisées. Son approche reposait sur l’identification des caractéristiques faciales telles que la distance entre les yeux et la largeur du nez.
Les dernières avancées en matière d’intelligence artificielle, notamment avec l’avènement du Machine Learning ainsi que l’explosion du volume de photos et vidéos partagé sur Internet, ont permis un développement rapide et massif des algorithmes de reconnaissance faciale.

En pratique, ces systèmes s’appuieront sur les images capturées par nos smartphones et caméra, constituées d’une grille de pixels, portant chacun les valeurs des trois couleurs, rouge, vert et bleu pour le pixel en question. Contrairement au fonctionnement de la vision humaine, c’est sous cette forme complètement numérique que le système de RF appréhendera les images. Le traitement qu’appliquera l’algorithme de RF devra ainsi généralement suivre les 5 étapes suivantes :

1. Capture de l’image : Tout commence par la capture d’une image contenant un visage. Cette image peut provenir d’une photo prise par une caméra tout comme être extraite d’une vidéo.
2. Détection du visage : L’algorithme va analyser l’image pour détecter la présence et la position des visages. Pour cela il va utiliser des techniques de traitement d’image pour rechercher des motifs et des schémas caractéristiques des visages, comme les contours, les éléments structurant (comme les yeux) et les variations de luminosité
3. Extraction des caractéristiques faciales de la personne : Une fois le visage est détecté, l’algorithme extrait des caractéristiques spécifiques qui vont permettre de le distinguer des autres visages. Ces caractéristiques incluent des éléments intelligibles (position des yeux, forme globale …) ainsi que des éléments intelligibles uniquement par le modèle IA (dégradé et arrangements spécifiques de pixels)
4. Création d’une empreinte faciale : A partir des caractéristiques extraites, l’algorithme crée une empreinte faciale, qui est essentiellement un résumé du visage, sur un format numérique compréhensible pour le modèle.
5. Comparaison avec la base de données : Afin de réaliser des identifications et des recherches, l’empreinte faciale obtenue pourra être comparée avec des bases de données d’empreinte ou d’image. Les correspondances trouvées mentionneront généralement un pourcentage de confiance, selon le niveau de ressemblance calculé.

De nos jours, les mécaniques sous-jacentes de traitement d’image et de Machine Learning peuvent offrir des performances excellentes, en termes de rapidité ou de cohérence des résultats. Mais au même titre que le reste des services technologiques automatisés, elles peuvent souffrir de vulnérabilité de sécurité cyber, et peuvent dans certains cas être détournées par un attaquant.

Panorama des attaques et faiblesses

L’objectif ne sera pas d’énumérer l’ensemble des attaques potentielles sur les systèmes liés au Machine Learning, mais de se concentrer sur les attaques pouvant viser les algorithmes de RF. Les principales typologies sont les suivantes :

Les attaques par adversaire (Adversary Attacks)
Premières fissures dans l’armure des algorithmes de RF, découvertes dans les années 2010, leur principe est d’introduire subtilement un bruit très léger dans les images envoyées au système. Cette altération, quasi invisible pour un être humain, bouleversera en revanche les caractéristiques fines vues par le modèle, et pourra permettre volontairement des erreurs de compréhension et de classification par le réseau de neurones sous-jacent. S’il est en mesure d’altérer les images envoyées, un attaquant ayant une bonne connaissance du système en question pourrait ainsi usurper l’identité d’un utilisateur.

Exemple d’attaque par adversaire

Attaques par occlusion
Dès 2015, des chercheurs ont pu mettre en pratique des attaques où l’occlusion de parties du visage, comme par le port de lunettes ou de masques, peut permettre de tromper certains modèles de RF. En effet, le modèle pourra ne pas réussir à détecter et extraire de visages des images capturées, ou bien à extraire des caractéristiques incohérentes. Dans les deux cas, de telles attaques permettent une anonymisation des sujets

Exemples de dispositifs d’occlusion

Attaques par substitution de visage

A l’instar des films d’espionnage, les chercheurs ont exploré les attaques par substitution de visage, utilisant des techniques parfois sophistiquées pour tromper les systèmes en présentant des visages artificiels qui ressemblent à de vrais visages. Les techniques peuvent aller du simple masque en carton, jusqu’à la reproduction d’un visage et de ses détails sur un masque « sur-mesure » en silicone. Ces attaques ont soulevé des préoccupations quant à la fiabilité des systèmes de reconnaissance faciale dans des scénarios du monde réel.

A noter que certains systèmes de RF (comme Windows Hello de Microsoft) s’appuieront sur une caméra infrarouge, pour notamment s’assurer d’être face à un vrai visage.

Procédure de création de visage pour une attaque par substitution de visage

Attaques par superposition

Dans certains cas, une simple superposition d’un “patch” sur une autre image peut induire en erreur les algorithmes de RF. Il est possible de calculer l’image qui représente le mieux une personne ou un objet (un grille-pain dans notre cas) du point de vue du modèle, et d’insérer cet élément dans l’image que l’on souhaite détourner. Le modèle de RF aura tendance à se focaliser sur cette zone, et cela pourra altérer complètement ses prédictions.

Exemple d’attaque par superposition

Attaques par illumination

En jouant sur l’éclairage environnant, il est courant de pouvoir altérer la performance d’un algorithme de RF, mettant en avant la nécessité de prendre en compte les conditions environnementales.

Demain, une défense à la hauteur des risques 

Face à ces systèmes faillibles, tout un ensemble de stratégies de protection apparaissent, misant généralement sur la vérification de la cohérence et la véracité des images présentées. Un bref panorama des axes de travail pour la défense :

1. Clignement des yeux : Le clignement des yeux peut être utilisé comme mécanisme de défense pour vérifier l’authenticité des visages en temps réel, en effet le clignement des yeux est dur à reproduire et manière naturelle sur une image ou une vidéo. En se basant sur des schémas de clignement naturels, les systèmes de reconnaissance faciale peuvent détecter les tentatives de fraude et renforcer la sécurité de l’identification biométrique.
2. Analyse de la démarche : L’analyse de la démarche offre une couche supplémentaire de défense en vérifiant la cohérence entre l’identité revendiquée et la manière dont une personne marche. Cette méthode peut aider à prévenir les attaques basées sur des imposteurs ou des contrefaçons en détectant les irrégularités dans la manière dont une personne se déplace, renforçant ainsi la sécurité des systèmes de reconnaissance faciale.
3. Analyse de la vivacité des visages : En utilisant des caractéristiques dynamiques du visage, tels que les mouvements musculaires et les clignements des yeux, l’analyse de la vivacité des visages permet de distinguer les visages réels des faux, empêchant ainsi les attaques basées sur des images ou des vidéos préenregistrées. Cette technique renforce la sécurité de l’authentification biométrique en s’assurant que les visages soumis à la reconnaissance sont vivants et en direct.
4. Scan 3D complet : Le scan 3D complet capture les détails tridimensionnels du visage, offrant une représentation plus précise et difficile à contrefaire. En utilisant cette technique, les systèmes de reconnaissance faciale peuvent détecter les tentatives de fraude par des masques ou des sculptures faciales, renforçant ainsi la sécurité de l’identification biométrique.
5. Techniques biométriques complémentaires de confiance : En combinant plusieurs modalités biométriques telles que la reconnaissance faciale, l’empreinte digitale et la reconnaissance de la voix, les systèmes de reconnaissance faciale peuvent bénéficier de multiples niveaux de défense. Cette approche renforce la sécurité en réduisant les risques d’erreurs de reconnaissance et de contournement, offrant ainsi une identification biométrique plus robuste et fiable.

Conclusion

De par leur conception en “boite noire”, les systèmes basés sur l’IA, avec plus récemment l’IA générative, sont actuellement faillibles. De nouvelles typologies et techniques d’attaque voient le jour, au même titre que des technologies de défense.

Dans le cas de la reconnaissance faciale, elle peut exposer ses utilisateurs à des risques évidents d’usurpation d’identité, avec de plus une perméabilité pro/perso, comme toute authentification biométrique, à la différence d’un simple mot de passe.

Avec la démocratisation des technologies de “deepfake”, et l’érosion de notre confiance dans les images, un effort de sécurisation de ces systèmes doit être assuré, à la hauteur de la grande responsabilité pouvant leur être accordée.

Cet article Les différents visages de la Reconnaissance Faciale : fonctionnement et attaques 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.

Un compte privilégié est un compte qui possède plus de privilèges qu’un utilisateur ordinaire. Par exemple, il peut lire et modifier la sécurité d’un système, exécuter des fonctions qui peuvent affecter de nombreux utilisateurs, etc… Ces comptes sont donc les préférés des attaquants (75 % des organisations ont subi une attaque impliquant un compte privilégié) et nécessitent un niveau de sécurité maximal.

Ce webinaire s’est concentré sur la sécurisation de l’accès aux ressources informatiques telles que les serveurs. Cependant, il est important de comprendre qu’un accès sécurisé est également nécessaire pour de nombreux autres éléments (tels que les applications) et qu’il existe différents types d’accès privilégiés, ce qui fait que la sécurité n’est pas une solution unique et doit être adaptée à chaque situation.

Les approches de sécurité traditionnelles utilisées par les organisations, y compris la solution PASM traditionnelle, ne suffisent pas à protéger les accès privilégiés contre les attaquants car elles ne répondent pas aux cinq questions clés nécessaires pour une sécurité solide, étant :

• Comment déployer l’authentification forte ?
• Comment sécuriser les superadministrateurs intégrés ?
• Comment contrôler les permissions effectives ?
• Comment gérer un grand nombre de serveurs ?
• Comment surveiller de près les opérations ?

Pour résoudre ce problème, les entreprises peuvent améliorer la solution PASM afin de la rendre plus efficace dans la sécurisation des accès privilégiés. Pour ce faire, elles peuvent :

1. Automatiser les autorisations autant que possible : Les serveurs sont nombreux et évoluent constamment, et les utilisateurs aussi. La normalisation et l’automatisation des autorisations leur permettront de suivre ce rythme.
2. Prise en compte d’autres cas d’utilisation au-delà de l’administration interactive : Il s’agit de prendre en compte d’autres besoins pour éviter que les utilisateurs ne contournent le PASM. On peut citer comme exemple les scripts utilisant des identifiants d’administrateur et les DevOps / machine-to-machine.
3. Concevoir votre modèle de compte en suivant le principe du moindre privilège (least privilege) : Par exemple, en concevant un seul compte nominatif centralisé par utilisateur pour simplifier la gestion, bien que cela n’entraîne pas de propagation latérale. Un compte générique local serait plus favorable dans ce cas précis, bien qu’il soit plus difficile à mettre en œuvre pour une organisation et qu’il pose question sur la responsabilité des comptes locaux, rendant la gouvernance plus complexe.

Le PASM présente-t-il des risques ?

Lors de la phase de projet, les administrateurs peuvent rejeter le PASM si la gestion du changement n’a pas été suffisante pour les former à ce dernier. Pour éviter cela, il est essentiel d’intégrer et de former les administrateurs à la solution PASM dès le début. De plus, la difficulté du déploiement et le coût peuvent être un obstacle aux solutions PASM pour les organisations. Ainsi, plus le modèle d’accès est simple, plus la solution sera facile à déployer et moins elle prendra de temps, ce qui permettra de réduire les coûts. Enfin, une solution PASM locale risque d’être très lourde et coûteuse en termes d’architecture, d’où l’intérêt de définir une solution SaaS. Bien qu’il s’agisse d’une solution de sécurité complète, les solutions PASM seules ne sont peut-être pas l’avenir des solutions de sécurité, avec l’émergence des stratégies ZSP…

Zero-standing Privilege(ZSP) est une stratégie de sécurité alternative qui vise à remplacer les comptes et privilèges persistants par un système « juste à temps » et « juste assez » pouvant être appliqué à la fois pour l’utilisateur et pour le serveur.

Pour l’utilisateur :

• Zero Standing Privilege : Les utilisateurs ont droit à un ensemble de privilèges préapprouvés, mais ces privilèges ne sont pas activés par défaut
• Juste assez : Lorsqu’ils doivent effectuer une opération, ils peuvent activer les privilèges minimaux nécessaires à la réalisation de leur tâche…
• Juste à temps : … pendant la période requise, suite à laquelle les privilèges sont automatiquement révoqués.

La ZSP appliquée au niveau de l’utilisateur permet de sensibiliser les utilisateurs, d’améliorer la traçabilité des opérations des organisations et de limiter le risque de « fat-finger ».

Pour le serveur :

• Zero standing privilege : Les comptes ne restent pas sur les serveurs, ou ils n’ont pas d’autorisation.
• Juste assez : Lorsqu’un utilisateur a besoin d’accéder au serveur, un compte est créé à la volée sur le serveur ciblé…
• Juste à temps : …uniquement pour la durée de la session.

La ZSP appliquée au niveau du serveur évite la compromission d’un compte en cas de violation, évite le contournement des outils PAM et évite les écarts entre les solutions théoriques et les solutions effectives.

La ZSP est-elle l’avenir de la gestion des accès privilégiés ?

La ZSP est conçue pour l’avenir des technologies de l’information, où de nombreux utilisateurs ont accès à de nombreuses ressources en constante évolution, et elle permet d’utiliser efficacement les principes du Zéro Trust. Cependant, la ZSP ne répond pas à tous les cas d’utilisation (comme machine-to-machine) et son développement n’est pas abouti, ce qui signifie que l’on manque d’expérience sur le terrain.

Ainsi, le conseil de Wavestone sur la stratégie à adopter est de définir d’abord votre stratégie PAM globale, puis une solution PASM solide pour sécuriser efficacement les accès à vos serveurs, avant d’envisager l’introduction d’un peu de ZSP. Par exemple, au niveau de l’utilisateur pour les privilèges élevés ou pour les utilisateurs ayant des besoins occasionnels et au niveau du serveur pour le cloud.

Webinar accessible à ce lien : https://www.thesasig.com/calendar/event/23-10-11-networks/

Cet article La sécurisation des accès privilégiés – Approches pour relever des défis multiples 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.

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.

Notamment, avec l’explosion des IoT et les réglementations tels que la DSP2, le besoin de déclencher des authentifications décorrélées du medium d’accès de l’utilisateur se fait de plus en plus présent : en effet, ce dernier ne dispose peut-être pas des interfaces nécessaires, ou peut ne pas être reconnu comme un support suffisamment sécurisé.

La cinématique additionnelle CIBA, Client Initiated Backchannel Authentication Flow a pour but de définir les échanges et les appels permettant de déclencher des tels authentifications. Ce premier article a pour but de décrire brièvement le fonctionnement haut niveau de cette cinématique, et de présenter les apports et les cas d’usage supplémentaire qu’il peut couvrir.

C’est quoi CIBA ?

CIBA signifie Client Initiated Backchannel Authentication. Il s’agit d’un nouveau flux d’authentification et d’autorisation du standard OpenID Connect définit par la fondation Open ID.

Le flux CIBA est le premier flux d’OpenID qualifié de « découplé » car il introduit la notion de Consumption Device (CD) et d’Authentication Device (AD). Le CD est l’appareil sur lequel l’accès à un service (Relying Party, RP) est demandé tandis que l’AD est l’appareil sur lequel l’utilisateur s’authentifie auprès de l’OpenID Provider (OP) et autorise l’accès qui est demandé sur le CD, en donnant son consentement.

Contrairement aux autres flux du standard OIDC, CIBA considère donc que l’utilisateur peut s’authentifier sur un appareil différent de celui sur lequel il veut accéder au service. Par exemple, un utilisateur cherche à accéder à son compte en banque depuis son ordinateur et s’authentifie pour autoriser l’accès depuis son smartphone.

Quels apports ?

Le flux CIBA présente plusieurs intérêts significatifs pour l’authentification des utilisateurs.

Les flux d’authentification OIDC aujourd’hui sont conçus autour de la notion de redirections web entre le service accédé (Relying Party) et le fournisseur d’identité. Ces redirections peuvent se montrer inconfortables et perturbantes pour l’utilisateur qui voit son navigateur ou son application passer d’un site à un autre sans forcément comprendre ce comportement. Avec CIBA, l’appareil que l’utilisateur utilise pour accéder à un service reste sur la page du service demandé en attendant que l’authentification soit réalisée sur l’AD. Cette disparition des redirections améliore également l’acceptation des Relying Party qui ne perdent plus le contrôle et la visibilité des actions de l’utilisateur lorsque ce-dernier doit s’authentifier auprès de l’OP.

Bénéfice par population

L’authentification multi-facteur (MFA) est de plus en plus répandue et recommandée pour accéder à des services sur Internet. Les SMS, les soft-token ou encore les Out-Of-Band push notification sont divers exemples de facteurs d’authentification additionnels, utilisés aujourd’hui en complément d’un mot de passe. Avec CIBA, la présence de ce facteur fait naturellement partie de l’authentification puisque celle-ci s’effectue sur un appareil enregistré comme AD. En demandant à l’utilisateur de s’authentifier sur l’AD avec un mot de passe, un code PIN, un facteur biométrique, … on permet de centraliser les actions d’authentification sur un seul et même appareil tout en permettant de faire du MFA.

Exemples de cas d’usage

Le call center

Lorsqu’un client appelle aujourd’hui un centre d’aide ou de services, l’opérateur vérifie le plus souvent l’identité du client avec diverses questions personnelles (date et lieu de naissance, numéro de sécurité sociale) ou bien à l’aide des questions de sécurité. Cette méthode d’authentification est particulièrement vulnérable à des attaques telles que l’ingénierie sociale.

Grâce à CIBA, il est possible pour l’opérateur de déclencher une demande d’authentification de l’appelant sur son Authentication Device et ainsi s’assurer de façon plus sécurisée de l’identité du client.

Les assistants virtuels

La DSP2 impose aux organismes bancaires de s’assurer de l’identité de la personne effectuant une opération au-dessus de certain montant, ce qui passe obligatoirement par une phase d’authentification (2 facteurs) lors d’un transfert par exemple. Néanmoins, les IoT tels que les assistants vocaux ne disposent pas d’interface permettant à l’utilisateur de saisir leurs identifiants, et forcer le client à valider une demande de transfert sur un portail web via son smartphone ou son pc n’est pas l’expérience utilisateur idéale. CIBA permet de s’affranchir de cette contrainte, car la banque du client est alors en capacité d’envoyer une demande d’authentification directement sur le bon terminal (AD), limitant l’impression de rupture de parcours pour le client.

Conclusion

La cinématique d’authentification CIBA comble de vraies faiblesses du protocole OpenID Connect, tant au niveau de la couverture fonctionnelle que de l’expérience utilisateur. Sa mise en œuvre dans le monde réel devrait se faire rapidement, et de nombreux acteurs du marché regardent déjà comment l’implémenter.

Cet article FAPI-CIBA : Comment authentifier mon utilisateur sans interface ! 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.

Le lieu de travail et ses outils de collaboration

C’est formidable de pouvoir travailler de n’importe où, avec n’importe quel appareil et de disposer de la technologie nécessaire quand on en a besoin. Plus qu’un luxe, c’est une nécessité dans la situation actuelle de travail à distance intensifié, ou pour les organisations internationales dont les utilisateurs sont très mobiles, répartis et fluides. Alors que tant de changements se produisent pendant la crise, votre lieu de travail devrait soutenir la reconfiguration de votre entreprise en permettant au personnel, aux partenaires, aux fournisseurs de travailler avec différentes applications, différentes équipes, etc.

Le mot « lieu de travail » utilisé dans ce contexte ne se limite pas aux postes de travail et aux outils de collaboration. Il s’étend à des domaines plus larges tels que l’architecture d’entreprise, la sécurité des applications et la gestion des identités et des accès. On peut dire que nous parlons de la base informatique plus large et des capacités numériques, pour soutenir et répondre aux besoins des entreprises – le lieu de travail n’est peut-être que la partie visible de l’iceberg.

L’héritage sur l’héritage ajoute de la complexité

Du côté de l’utilisateur, dès que vous passez par plusieurs cas d’utilisation, par exemple l’accès à un système existant sur place ou à une application Software as a Service, vous êtes susceptible d’avoir besoin de plusieurs comptes et donc d’une expérience utilisateur lourde.

Du côté de l’exploitation informatique, c’est également un fardeau de la faire fonctionner : les postes de travail sont encore la plupart du temps un dispositif physique lié à un domaine rigide de l’entreprise ; ils doivent être configurés, puis expédiés au personnel distant ou à des parties externes, et les comptes doivent encore être approvisionnés dans des environnements cibles, avec des droits d’accès définis de manière appropriée. Tous les éléments ci-dessus sont généralement des processus différents qui se répètent pour chaque fournisseur ou partenaire, ce qui entraîne autant de dispositifs et de configurations.

Plus important encore, dans quelle mesure cette situation désorganisée et chevauchante est-elle sûre ? Avoir une visibilité et un contrôle sur qui a accès à quoi, de bout en bout et pour tous les environnements, est un défi en raison des cas d’utilisation cloisonnés. Et à mesure que les utilisateurs rejoignent et quittent l’entreprise, que les applications évoluent, le niveau de sécurité diminue probablement en raison du manque de précision des comptes et des droits.

D’après notre expérience chez Wavestone, tous ces défis découlent de l’accumulation de nouveaux cas d’utilisation et de nouvelles technologies, mis en œuvre en silo, pour leur propre usage ou pour un groupe limité de cas d’utilisation. La plateforme, qui a d’abord été conçue pour une utilisation principale, s’est maintenant transformée en une plateforme à utilisations multiples avec un modèle et des processus mal adaptés. De nombreuses organisations peuvent aujourd’hui être fières de pouvoir compter sur une plate-forme fédérée et une expérience d’accès moderne pour les applications en nuage d’un côté – et sur une expérience différente, mais raisonnablement bonne, du côté des applications internes. Cependant, souvent, les deux ne sont pas intégrés et ne bénéficient donc pas des avantages que nous avons décrits dans l’introduction. Nous pensons que cela est dû à l’absence d’un modèle/architecture véritablement partagé pour soutenir une expérience moderne, dans tous les cas d’utilisation.

Figure 1 – Exemple de modèle d’entreprise dans lequel chaque entité gère séparément les identités et leur accès : duplication des processus

Un modèle pour une expérience de rationalisation

Pour cette raison et pour l’avenir de l’expérience utilisateur, chez Wavestone, nous croyons en un modèle basé sur la ou les Tours de Contrôle d’Identité.

Une tour de contrôle d’identité est une plate-forme permettant de faire respecter vos politiques d’accès. Son but est de vérifier les demandes d’accès provenant de sources d’identité fiables et de déterminer si cette identité est autorisée à accéder à une ressource numérique cible. Pour reprendre la métaphore, un pilote désireux d’obtenir une autorisation de décollage soumettra son plan de vol en utilisant un canal de confiance, et après son approbation et d’autres vérifications par les contrôleurs, le pilote pourra procéder au décollage. Si nous devions transposer cette métaphore en numérique, nous parlerions d’un utilisateur : pour que ledit utilisateur puisse accéder à la plate-forme X, il devrait utiliser un processus d’entreprise qui est lui-même fiable par une tour de contrôle d’identité. Cet utilisateur fournit son « plan d’accès » (par exemple, un jeton de session) à la tour de contrôle d’identité. Après que la tour de contrôle d’identité a vérifié l’authenticité du « plan d’accès » par rapport à ses politiques d’accès, elle effectuera d’autres vérifications de contexte, telles que : l’heure de la demande, le lieu d’origine de l’accès, le niveau de confiance du dispositif, etc. Si ces vérifications mettent en évidence quelque chose d’inhabituel ou d’incohérent dans l’authentification de l’utilisateur, des demandes supplémentaires peuvent être faites pour permettre à l’utilisateur d’entrer (ré-authentification ou renforcement).

La tour de contrôle d’identité est sous votre contrôle et détient les conditions d’accès, c’est-à-dire les politiques d’accès et accepte les utilisateurs de sources spécifiques grâce à une relation de confiance préétablie entre les organisations.

Par exemple, dans le schéma ci-dessous, imaginez une situation dans laquelle un fournisseur développe un nouveau service dans votre environnement en nuage. Les utilisateurs du fournisseur conserveraient leur dispositif et le processus d’authentification qu’ils utilisent dans leur environnement d’entreprise, tandis que la tour de contrôle d’identité (TIC) imposerait un contrôle d’accès à l’environnement en nuage – sans avoir à utiliser et à gérer un compte différent et à se ré-authentifier. Pour les environnements avec des privilèges très granulaires comme AWS, construire une TIC découplée n’est peut-être pas une approche réaliste et la TIC est alors probablement la plateforme d’identité d’Amazon qui est gérée par votre organisation et liée au fournisseur d’identité du fournisseur. Le modèle de la tour de contrôle d’identité est essentiellement une extension de la fédération, mise en œuvre pour couvrir tous les cas d’utilisation.

Figure 2 – Accès d’un utilisateur partenaire à une ressource du fournisseur de services dans le nuage via une tour de contrôle d’identité

Dans un autre scénario, comme le montre ce schéma, considérons un candidat qui postule à un emploi dans votre organisation, grâce à un portail de recrutement que vous proposez. Il déposerait une candidature sur votre portail en utilisant son identité numérique soutenue par le gouvernement, et une fois qu’il aurait donné son accord pour accéder à son profil LinkedIn, vous pourriez obtenir un CV numérique. Pour le candidat, il suffit de montrer sa pièce d’identité et de donner une copie de son CV, plutôt que de remplir le(s) formulaire(s) d’inscription en demandant une nouvelle fois les mêmes informations d’identité standard et en risquant de faire une faute de frappe dans ses coordonnées – ou même de devoir envoyer des copies de documents sensibles comme son passeport.

Figure 3 – Un scénario alternatif présentant la relation de confiance entre une plateforme d’identification gouvernementale et l’entreprise

Un modèle, trois piliers clés

Forts de nos connaissances et de notre expérience, nous pensons que ce modèle devrait reposer sur trois piliers clés : une identité unique dans tous les systèmes, un modèle commun et flexible d’accès à l’information et l’établissement d’une relation de confiance à 360°.

Une Architecture d’Identité Unique : elle est réalisée en suivant une règle simple : ne pas dupliquer les données d’identité. Moins vous créez de fiches d’identité pour une même personne physique, plus l’expérience numérique sera simplifiée – car des étapes lourdes commencent à apparaître lorsqu’un compte, un dispositif ou une action d’authentification supplémentaire est nécessaire pour que l’utilisateur accède à la ressource cible. La clé d’une donnée d’identité unique est d’essayer de réutiliser les données de sa source (qui fait autorité) au lieu de les dupliquer/copier dans vos propres systèmes. Par exemple, les fournisseurs ou partenaires travaillant avec votre organisation ont probablement déjà des identités numériques professionnelles pour leur propre usage informatique – quelles seraient les conditions pour les exploiter au lieu de les recréer ?  Les deux piliers suivants contribuent à répondre à cette question.

Un modèle commun et flexible : Le deuxième pilier consiste à utiliser un modèle commun et flexible pour permettre/restreindre l’accès à l’information. Pour assurer la flexibilité, un modèle de contrôle d’accès basé sur les attributs (ABAC) permet des règles granulaires et est bien adapté à une approche adaptative et basée sur les risques. Pour que cela fonctionne, il est toutefois essentiel de définir la « grammaire » du modèle d’autorisation : quels sont les attributs réels utilisés pour fournir des accès qui ont un sens au niveau de l’entreprise ? Comment se traduisent-ils en « privilèges » ? Quels sont leurs formats/valeurs ? Lorsque la tour de contrôle d’identité est fournie par un fournisseur de cloud (par exemple, par un fournisseur de cloud comme Azure ou AWS), la grammaire est souvent déterminée par ledit service. En outre, pour que ce modèle soit le plus répandu possible dans les cas d’utilisation, tant du côté de la source d’identité que de la fourniture d’accès du côté du service cible, nous recommandons de mettre en œuvre votre plate-forme en suivant les normes du marché afin de maximiser l’interopérabilité (SAML, OpenID Connect, OAuth, FIDO, etc.).

Une relation de confiance à 360° : Enfin, le dernier pilier consiste à assurer l’établissement d’une relation de confiance à 360°. En d’autres termes, il faut faire preuve de diligence raisonnable et établir des seuils de confiance pour accepter l’interconnexion (« confiance technique ») des plateformes d’identité. La diligence raisonnable doit s’étendre à tous les processus en amont qui permettent d’alimenter la plateforme en identités, par exemple les processus RH/achats pour vérifier les identités, jusqu’au processus d’intégration informatique lui-même – parce que la confiance dans une plateforme d’identité est une première étape pour que ces identités puissent accéder à vos ressources numériques, vous devez être dans la tolérance du risque qu’elle comporte. Cette relation de confiance doit ensuite être mise en œuvre par le biais des attentes en matière de niveau de sécurité, de l’auditabilité des clauses contractuelles, et être appliquée par le biais de la gouvernance de la gestion des services des fournisseurs. Avec des exigences aussi strictes, une organisation doit être prête à intégrer temporairement des fournisseurs ou des partenaires au sein de sa propre plate-forme, pendant que les fournisseurs ou partenaires remettent leurs processus et plates-formes en conformité.

Deux facteurs clés de succès

Afin de mettre en œuvre ces trois piliers clés, Wavestone a identifié deux facteurs clés de succès : être parrainé par un niveau de gestion approprié et renforcer la résilience et la protection de la vie privée dès la conception. Un programme de transformation visant à établir ce modèle aurait des implications et des exigences dans plusieurs départements de votre organisation (RH, approvisionnement, juridique, informatique, risques, sécurité, etc.), et devrait donc être parrainé par la direction générale et mené avec une approche panorganisationnelle.

En outre, comme toujours, la plateforme de support doit être conçue et construite en tenant compte dès le départ des questions de sécurité, de confidentialité et de résilience.

Réflexions finales

Comme vous avez pu le comprendre tout au long de cet article, il est essentiel d’examiner l’expérience de l’utilisateur de bout en bout et d’un cas d’utilisation à l’autre pour vraiment rationaliser les services numériques. Cela peut être réalisé grâce à un changement d’organisation pour imposer une identité unique à tous les systèmes, un modèle commun et flexible d’accès à l’information et l’établissement d’une relation de confiance à 360° avec les tiers.

Pour aller plus loin dans votre réflexion sur le sujet et comprendre l’état actuel de votre organisation, réfléchissez à ces questions et essayez d’y répondre : en choisissant des utilisateurs de différents services, à quoi ressemble l’expérience numérique quotidienne typique ? Combien de temps faut-il à mon organisation pour embarquer des sous-traitants et des tiers ? Comment mon organisation donne-t-elle effectivement accès à ses données et ressources aux utilisateurs externes ? Combien d’identités doubles existe-t-il dans mon parc informatique ? 

Cet article Les facteurs clés pour créer une expérience utilisateur transparente et sécurisée est apparu en premier sur RiskInsight.

Différentes stratégies pour se prémunir des deepfakes

En parallèle du cadre légal, les organisations publiques et privées s’organisent pour proposer des solutions permettant de détecter et d’empêcher la diffusion malveillante de deepfakes. On peut distinguer quatre stratégies pour s’en prémunir.

1/ La détection d’imperfections

Détecter les deepfakes par leurs imperfections est l’une des principales méthodes existantes. Certaines irrégularités restent présentes dans les contenus générés, comme le manque de clignements des yeux et de synchronisation entre les lèvres et la voix, les distorsions du visage et des accessoires (branches de lunettes), ou encore l’inexactitude du contexte (météo, localisation).

Les deepfakes sont cependant construits pour apprendre de leurs erreurs et générer un contenu de plus en plus proche de l’original, rendant les imperfections moins perceptibles. Les outils utilisant cette stratégie de détection des deepfakes peuvent être efficaces mais nécessitent d’être sans cesse améliorés pour détecter des anomalies de plus en plus légères.

On peut citer dans cette catégorie de protection Assembler, un outil à destination des journalistes développé par Jigsaw (branche d’Alphabet, maison-mère de Google). Il permet de vérifier l’authenticité des contenus en les analysant via cinq détecteurs dont les anomalies de motifs et de couleurs, les zones copiées et collées, et les caractéristiques connues d’algorithmes de deepfakes.

2/ Le screening et l’analyse comparative

Comparer les contenus à une base de données de vrais ou en cherchant des contenus similaires sur les moteurs de recherche pour voir s’ils n’ont pas été manipulés (par exemple, en trouvant la même vidéo avec un visage différent) est une autre stratégie permettant de se prémunir des deepfakes.

En 2020, la AI Foundation devrait rendre disponible un plug-in, Reality Defender, à intégrer aux navigateurs et à insérer à terme aux réseaux sociaux. Celui-ci permettra de détecter les manipulations des contenus, ciblant dans un premier temps les politiciens. Les utilisateurs seront amenés à régler la sensibilité de cet outil, selon les manipulations qu’ils voudront détecter ou non pour ne pas être notifiés à chaque manipulations de média, notamment pour les manipulations les plus courantes (retouches d’une photo de la page Web faite sur Photoshop par exemple).

3/ Le tatouage numérique (watermarking)

Une troisième méthode consiste à marquer les contenus d’un tatouage numérique pour faciliter le processus d’authentification en en renseignant la source et en suivant les manipulations réalisées sur ces contenus.

Une équipe de l’Université de New York travaille sur un projet de recherche de création d’un appareil photo embarquant une technologie de watermarking destinée à marquer les contenus photographiés, afin non seulement d’authentifier la photographie d’origine, mais aussi de marquer et suivre toutes les modifications opérées sur la photographie pendant son cycle de vie.

4/ L’implication du facteur humain

Impliquer les utilisateurs dans le processus de détection permet à la fois de mitiger les impacts des deepfakes en faisant prendre conscience que l’altération des contenus accédés est possible, et de réduire leur occurrence en leur permettant de reporter leurs suspicions de deepfakes.

Le plugin Reality Defender déjà évoqué offrira la possibilité aux utilisateurs de signaler les contenus qu’ils jugent faux pour en informer les autres utilisateurs – qui en plus de l’analyse réalisée par l’outil verront si les contenus ont été signalés par d’autres utilisateurs, offrant un second niveau de signalisation.

Des initiatives portées par des coopérations d’acteurs multisectoriels combinent ces quatre stratégies pour une efficacité maximale contre les deepfakes. Certaines sont déjà utilisées ou testées par des journalistes. C’est le cas de InVID, initiative développée dans le cadre du programme de l’Union Européenne Horizon 2020 de financement de la recherche et de l’innovation, utilisé par l’Agence France-Presse.

Des solutions et stratégies émergent donc, le marché se construit, et de nouvelles solutions innovantes devraient apparaitre très prochainement avec les résultats du Deepfake Detection Challenge. Ce concours anti-deepfake a été lancé par Facebook à l’approche des élections présidentielles américaines, et plus de 2600 équipes s’y sont inscrites. Résultats le 22 avril !

Ci-dessous un tableau présentant des exemples d’initiatives combinant différentes stratégies pour se prémunir des deepfakes.

Différents moyens pour protéger son activité

Le risque présenté par les deepfakes pour les entreprises est bien réel et voici quelques actions clés à lancer pour s’en protéger et mitiger ses impacts dès maintenant.

• Evaluer son exposition : Les cas d’usage des deepfakes et le worst-case scenario de leur utilisation doivent être déterminés sur les périmètres de l’entreprise, en considérant les risques de fraude et de déstabilisation, et en identifiant la ou les stratégies de sécurité adaptées.

• Sensibiliser : Les collaborateurs doivent être sensibilisés à la détection des deepfakes (pour éviter les cas de fraudes) mais aussi à la limitation des contenus partagés sur les réseaux sociaux pouvant être réutilisés pour produire des deepfakes (pour éviter la déstabilisation). A l’image des campagnes de faux phishing, cette sensibilisation porte à la fois sur la détection des défauts techniques (forme) des deepfakes (bien qu’elles seront amenées à disparaître avec le perfectionnement des techniques), mais surtout sur la détection du caractère suspect des informations (fond), invitant à la méfiance, au recoupement des informations et à la notification de suspicions aux équipes compétentes (que faire si je vois une vidéo suspecte de mon responsable communication sur les réseaux sociaux pendant le week-end ? Que faire si je reçois un message vocal de mon chef me demandant de réaliser une opération ponctuelle un peu hors de mon périmètre ?).

• Adapter ses processus de vérification : Les plans anti-fraude existants peuvent être repensés pour s’appliquer aux deepfakes. Par exemple, pour une fraude au président via deepfakes, une des recommandations est de proposer à son interlocuteur de raccrocher et le rappeler (si possible sur un numéro déjà connu, et après des vérifications internes). Pour les scénarios de fraudes les plus sensibles, ces processus de réactions doivent être définis très finement et les collaborateurs concernés régulièrement formés aux réflexes à adopter. Des outils tels que définis précédemment peuvent également être utilisés pour vérifier tout ou partie des médias consommés par les collaborateurs.

• Protéger ses contenus : Les contenus représentant des collaborateurs partagés en interne et en externe par l’entreprise peuvent être contrôlés pour éviter qu’ils ne soient réutilisés pour produire des deepfakes. Les entreprises peuvent limiter la diversité des données potentiellement utilisables par des personnes malintentionnées (angles de vues des personnes et types de médias) et jouer sur la qualité numérique (définition) des contenus partagés. En effet, plus les attaquants bénéficient de contenus divers et de bonne qualité représentant des collaborateurs, plus il est facile de les réutiliser pour générer des deepfakes. De plus, les entreprises peuvent limiter leurs moyens de communication à une chaine officielle, des réseaux sociaux vérifiés et leurs sites web officiels – ce qui crée des habitudes de consommation de contenus par l’audience, qui verra sa méfiance éveillée par toute diffusion sortant de ces habitudes.

• Anticiper les crises : Les besoins de communications en cas d’incident avéré lié aux deepfakes doivent être prévus, et la gestion du cas du deepfake doit intégrer les scénarios de communications « génériques » adressés dans les plans de communication de crise.

Cet article Cybersécurité à l’heure du deepfake – Comment agir face à de fausses informations de plus en plus crédibles ? (2/2) est apparu en premier sur RiskInsight.

Les récents évènements liés au COVID-19 ont démontré la nécessité d’accès à de l’information fiable et véridique par l’ensemble de la société. En plus de l’épidémie, nous avons été sujets à une « infodémie », propagation rapide d’informations fausses ou trompeuses sur les réseaux sociaux, posant la question de la confiance accordée aux plateformes de relai de contenu et de l’authenticité des informations qu’elles relayent.

L’usage des deepfakes est un phénomène d’actualité touchant d’abord le grand public. Il est intrinsèquement lié à l’importance qu’ont pris les réseaux sociaux et médias en ligne dans notre vie quotidienne.

En septembre 2019, on comptait près de 15.000 vidéos deepfake en ligne, soit deux fois plus qu’en décembre 2018. Si 96% étaient des deepfakes pornographiques postés sur des sites spécialisés, l’étendue des sujets touchés augmente pour atteindre tous les réseaux sociaux populaires (Youtube, Vimeo, Dailymotion). Parmi les deepfakes postés sur YouTube, 20% représentaient déjà des politiciens, hommes d’affaires et journalistes[1]. Leur pouvoir de désinformation sur le grand public leur permet d’exercer une influence sur des évènements politiques et sociétaux majeurs dès lors que des personnalités connues y sont représentées.

Et ceux-ci ne cessent de se perfectionner, alors que les outils permettant de les générer se démocratisent (comme Lyrebird, pour les deepfakes audios, ou Zao, pour les face-swapping, et le plus récent Avatarify, intégré à Zoom et Skype, pour la vidéo). Leur pouvoir de nuisance pèse de plus en plus non seulement sur les acteurs et organisations publics, mais également privés, et doit être étudié dans chaque secteur d’activité.

Un risque à prendre en compte par les entreprises

Les deepfakes peuvent également être utilisés contre les entreprises. Ils offrent en effet un nouveau terrain de jeu pour les acteurs malveillants, avec notamment deux moyens d’action :

• Perfectionnement des attaques par fraude au président, dont les impacts et la probabilité sont augmentés avec les deepfakes. La fraude est rendue plus vraisemblable par des photos, vidéos et audios copiant la personne dont l’identité est usurpée. Les collaborateurs ciblés prennent ainsi ces contenus comme une authentification en soi de l’interlocuteur, et les chances de réussite des attaques sont augmentées – ce qui les encourage à demander des sommes plus importantes. De plus, certains outils de généreration de deepfakes étant accessibles au grand public, le recours à ces fraudes par des personnes malintentionnées augmente.
• La déstabilisation de l’entreprise via de fausses informations relayées peut fortement détériorer son image, entrainant un certain nombre de conséquences, notamment financières et juridiques. On peut se demander quels impacts pourrait avoir le discours vidéo d’un membre du CoMex d’une entreprise diffusant de faux résultats ou orientations stratégiques sur le cours de son action ou la confiance de ses prospects ; ou encore quels seraient ceux d’une révélation d’anomalie produit sur les prises de commandes directes. Qui plus est, le démenti de rumeurs est rendu plus difficile lorsque des deepfakes sont utilisés. Et aujourd’hui les entreprises se sentent pour beaucoup encore loin du sujet : combien se sont déjà demandées quels seraient les impacts que pourrait avoir un deepfake sur leurs activités ?

Un cadre légal en construction

Les Etats commencent à s’organiser pour répondre à l’enjeu des deepfakes et à légiférer pour encadrer leur diffusion. Certains pays comme la Chine criminalisent la diffusion de deepfakes sans en notifier l’audience (depuis le 1^er janvier 2020). Aux Etats-Unis, le traitement de la question des deepfakes s’accélère à l’approche des élections présidentielles de novembre 2020 et se fait à la fois au niveau fédéral (lois interdisant la diffusion de deepfakes en Californie, Virginie et au Texas), et national (le DEEPFAKE Accountability Act[2] est en discussion au congrès pour « combattre la propagation de désinformation à travers des restrictions sur les deepfakes »). En France, la question des deepfakes est intégrée à la loi du 22 décembre 2019 relative à la lutte contre la manipulation de l’information et n’est donc pas encore traitée explicitement.

Ces cadres légaux restent naissants et hétérogènes, et ne représentent qu’une partie de la réponse à apporter à cette technologie. Plus que condamner leur utilisation malveillante, l’enjeu est surtout de pouvoir les détecter et les empêcher.

Dans cette première partie, nous avons donné une vision des risques que présentent les deepfakes pour les entreprises. Dans la seconde partie de l’article, nous traiterons des moyens techniques et organisationnels à disposition aujourd’hui pour s’en protéger.

[1] Etude réalisée par Deeptrace en Septembre 2019.

[2] Defending Each and Every Person from False Appearances by Keeping Exploitation Subject to Accountability Act.

Cet article Cybersécurité à l’heure du deepfake – Comment agir face à de fausses informations de plus en plus crédibles ? (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.

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 ?

GitGuardian souligne l’importance de l’expérience de ses cofondateurs ingénieurs, spécialisés en intelligence artificielle dans la conception de leur solution : « Nous utilisons au quotidien les outils de l’open source, et en particulier la plateforme GitHub », qui reste génératrice de risques pour ses utilisateurs. Certains codes source publiés peuvent contenir une clé privée, suffisante pour « s’introduire dans des systèmes d’information d’entreprise, de la petite start-up aux grands groupes du CAC40 », la solution GitGardian a été créée pour « analyser en temps réel l’ensemble du code open source pour détecter les informations sensibles ».

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 ?

Eric Fourier souligne l’interconnexion croissante entre les systèmes bancaires : « cette augmentation de la surface de vulnérabilité attire les hackers et le nombre de cyberattaques augmente tous les ans. Les failles de sécurité que nous détectons exposent régulièrement des données personnelles, pouvant appartenir aux employés de la banque, à ses clients, ou à des tiers. Ces fuites détériorent leurs images et leur font courir un risque légal et stratégique. Ainsi, GitGuardian permet de diminuer ces risques en détectant certaines vulnérabilités au niveau des interfaces entre les systèmes » bancaires.

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é ?

GitGuardian met en avant la nature exogène de sa solution face « à l’infrastructure IT dans la mesure où nous analysons des données disponibles publiquement. Il suffit donc de quelques minutes pour l’installer. Nos algorithmes basés sur du Machine Learning nous permettent d’alerter le RSSI et son équipe sécurité d’une vulnérabilité moins de quatre secondes après l’événement, lorsqu’il est encore temps de limiter fortement les dégâts possibles ». Grâce à ce temps de réaction très faible, la solution est la seule sur le marché à fournir un service aussi précis et rapide car « les acteurs traditionnels s’appuient sur l’analyse humaine, qui peut prendre quelques semaines ».

Quelles sont les synergies entre votre innovation et les solutions de sécurité bancaires existantes à l’heure actuelle ?

GitGuardian note l’effort croissant des banques pour protéger leurs clients : « elles luttent contre la fraude bancaire avec des solutions de sécurisation des achats sur Internet, de protection contre les faux sites bancaires ou les tentatives d’hameçonnage. Les banques possèdent aussi des solutions standardisées pour la protection de leurs systèmes d’information, telles que les pare-feus ou le chiffrement des données. Cependant, les banques se protègent péniblement contre les erreurs humaines de leurs milliers d’employés et prestataires répartis sur le territoire français et dans le monde entier. GitGuardian colmate ces brèches en temps réel, avant que des dommages soient causés par des acteurs malveillants ».

Comment voyez-vous la banque de demain ? Quelles opportunités pour la cybersécurité dans la banque de demain ?

La principale tendance qui émerge est celle du numérique et de la transparence. GitGuardian l’explique ainsi : « La banque de demain sera une banque entièrement digitalisée et connectée. Les applications liées au secteur bancaire se multiplient, les exigences des clients s’intensifient et les fraudes bancaires s’amplifient. La banque de demain se doit d’être plus ouverte et transparente, comme en témoigne l’engouement qui s’anime autour de la technologie blockchain. Tout cela se traduit nécessairement par la mise en place de programmes de cybersécurité encore plus élaborés pour protéger la transition et assurer la sécurité de millions de personnes ».

Pour en savoir plus : https://www.gitguardian.com/

Cet article L’interview de GITGUARDIAN – Sécuriser les clés privées 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.

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

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

3. Industrialiser le déploiement

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

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

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

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

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

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

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

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

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

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

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

4. Bien s’outiller

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

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

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

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

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

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

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

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

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

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

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

5. S’inscrire dans la durée

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

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

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

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

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

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

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

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

En conclusion, c’est possible !

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

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

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

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

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

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

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

Une maîtrise toute relative des habilitations sur les ERP

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

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

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

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

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

Comment s’y prendre ?

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

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

1. Piloter de façon rapprochée

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

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

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

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

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

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

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

2. Préparer le terrain

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

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

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

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

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

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

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

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

Depuis l’arrivée de Facebook en 2004, Internet a été témoin d’une explosion du nombre de réseaux sociaux, des plus généralistes aux plus spécialisés. Leur adoption et utilisation massive les positionnent comme des véritables mines d’or pour les entreprises, en leur offrant une porte d’accès à des données jusqu’alors inaccessibles (préférences de leurs clients, envies, intérêts…).

À l’heure où l’expérience utilisateur et la connaissance des clients deviennent des problématiques incontournables pour les entreprises, le social login semble être la solution rêvée… mais est-ce vraiment le cas ?

Chapitre 1 : la promesse

En 2018, nous comptons plus de 70 réseaux sociaux, dont les plus connus et utilisés restent Facebook, Google+, Twitter ou encore LinkedIn. Certains réseaux peuvent être même rattachés à des plaques géographiques ou pays particuliers, comme l’Asie avec WeChat, Weibo, Mixi ou et la Russie avec Vkontakte.

À titre indicatif, l’utilisation de réseaux sociaux est passée de 153 millions d’utilisateurs en 2011 à 837 millions en 2013, pour passer largement au-delà du milliard en 2017.

Les réseaux sociaux sont donc devenus de véritables référentiels d’identités, dont certains promettent de détenir l’Identité de référence sur Internet, les motivant à se positionner naturellement comme fournisseur d’identités pour les entreprises. C’est dans ce cadre et sur la base de cette promesse que le social login est né.

L’objectif premier du social login est de permettre à un utilisateur d’accéder aux services d’une marque ou boutique virtuelle le plus simplement possible, à l’aide d’un compte d’un réseau social.

Il s’affiche comme une réponse aux attentes des clients en simplifiant les processus d’enregistrement et d’accès aux services, mais également à celles des entreprises en donnant des moyens d’authentification rapides à déployer afin d’améliorer le taux de conversion des prospects.

Une solution pratique et simple à utiliser

Lorsque nous parlons de social login, nous distinguons deux cas d’usage :

• Social registration: utilisation d’un compte d’un réseau social (ex : Facebook, Google, Twitter, LinkedIn…) pour créer un compte sur une application
• Social login: utilisation d’un compte d’un réseau social pour s’authentifier sur une application pour laquelle le compte applicatif a été déjà créé via social registration

La cinématique décrite ci-après présente les étapes du social registration. La cinématique du social login est similaire et repose uniquement sur les étapes 1, 2 et 3.

Étape 1 – Accès initial au service

L’utilisateur accède à l’application (mobile ou web) d’une entreprise qui lui fournit des services et choisit de créer un compte depuis le réseau social de son choix.

Étape 2 – Authentification

L’utilisateur est alors redirigé vers le réseau social sélectionné pour s’authentifier selon le mécanisme en vigueur (ex : identifiant / mot de passe, code (OTP) envoyé par SMS…).

Dans l’éventualité où l’utilisateur a déjà une session active sur ce réseau social, il sera automatiquement authentifié (SSO – Single Sign On) et passera directement à l’étape suivante.

Étape 3a – Recueil du consentement

Le réseau social informe l’utilisateur que l’application souhaite accéder à des informations de son compte (ex : nom, prénom, date de naissance, liste des amis, préférences…) afin de lui créer un compte applicatif. L’utilisateur doit alors donner son consentement explicite pour que la cinématique se poursuive.

À noter que certains réseaux sociaux comme Facebook offrent la possibilité à l’utilisateur de visualiser en détail les informations que l’application souhaite recueillir afin de pouvoir gérer plus finement son consentement (étape 3b).

Étape 3b – Gestion fine du consentement

L’utilisateur visualise l’ensemble des informations que l’application souhaite recueillir. Il peut alors décocher celles qu’il ne souhaite pas partager. Toutefois, des informations peuvent être obligatoires pour que l’application puisse lui créer un compte applicatif et ne pourront être décochées par l’utilisateur (généralement l’adresse e-mail car souvent utilisée comme identifiant).

Étape 3 / Étape 3c – Redirection vers le service souhaité

L’utilisateur est alors redirigé vers le service souhaité. Éventuellement, l’affichage pourra être personnalisé pour montrer l’intérêt de partager les informations de son compte social (affichage de la photo de profil, contenus personnalisés sur la base des préférences de l’utilisateur…).

Un avantage concurrentiel pour les entreprises

Simplifier le processus de création

La conversion des prospects en clients est l’objectif principal des entreprises. L’un des premiers freins à cette conversion est le processus de création de compte. Selon une étude de WebHostingBuzz, plus de 86% de prospects abandonnent dès cette étape, souvent jugée trop longue et complexe.

Le social registration est une alternative de plus en plus adoptée par les entreprises : abandonner le formulaire de création de compte traditionnel pour mettre en avant l’utilisation d’un compte d’un réseau social. En d’autres termes, passer de plusieurs minutes à quelques clics.

Faciliter l’accès aux services

Simplifier le processus de création de compte n’est pas une fin en soi. Il faut également donner envie aux clients de revenir et consommer les services de l’entreprise, notamment en :

• Offrant une expérience utilisateur omnicanale: ne pas perdre le client en lui imposant des parcours différents en fonction du moyen d’accès utilisé
• Réduisant le nombre de mots de passe à retenir: favoriser l’usage d’un compte (i.e. : couple identifiant / mot de passe) déjà connu de l’utilisateur pour éviter de récréer un nouveau mot de passe

Le social login se positionne comme une solution permettant de répondre à ces problématiques : que ce soit depuis un ordinateur, un smartphone, une tablette, le client bénéficiera de la même expérience utilisateur (même cinématique d’accès), basée sur l’usage d’un compte social pour accéder aux services de l’entreprise, et ses partenaires.

Personnaliser l’expérience utilisateur

L’utilisation du social login permet d’accéder à un nombre important de données qualitatives sur les clients : données d’identité (nom, prénom, date de naissance), données de contact (adresse e-mail, numéro de téléphone…), données de préférences (intérêts, partages, likes) …

Des données jusqu’alors inaccessibles dans une gestion des identités clients classique le deviennent, qui offrent la possibilité aux entreprises de personnaliser davantage leur relation avec leurs clients :

• Affichage et communication personnalisés
• Proposition de contenu personnalisé
• Anticipation ou adaptation de services en ligne avec les intérêts des clients

La personnalisation de l’expérience utilisateur permettra aux entreprises d’instaurer un climat de confiance, proposer des services sur-mesure et fidéliser ses clients dans la durée.

Ils l’ont adopté… ou pas encore

L’adoption du social login est très disparate en fonction du secteur d’activité de l’entreprise et de la nature de ses relations avec ses clients. Nous distinguons deux typologies de clients :

• Les consommateurs: bénéficient des services d’une entreprise sans pour autant avoir de relation directe et/ou de contrat les liant (ex : j’achète une bouteille de soda dans mon magasin préféré, mais l’entreprise qui conçoit ce soda ne me connait pas forcément)
• Les clients directs: bénéficient des services d’une entreprise sur la base d’un lien direct (contrat, comptes bancaires…), nécessitant une relation de proximité entre l’entreprise et le client

Selon une étude Wavestone réalisée en mars 2018 sur un échantillon de 172 marques majeures réparties dans tous les secteurs d’activité, 32% d’entre elles ont adopté le social login.

Ce constat met en lumière une adoption forte par les entreprises ayant des clients de type « consommateurs », dont l’objectif est de vendre rapidement des services de consommation (VOD, matériels, presse…).

À contrario, peu, voire pas du tout, d’entreprises ayant des clients directs adoptent le social login, leur relation débutant par l’établissement d’un contrat (et donc la création d’un compte avec des données vérifiées par l’entreprise (carte d’identité, justificatif de domicile…)). Toutefois, certaines de ces entreprises ont déjà commencé à instruire le social login dans leur feuille de route de services numériques, et il commence à s’imposer comme une norme au regard de l’arrivée d’un nouveau type de clients : la génération Z.

Parmi les entreprises ayant adopté le social login, Facebook et Google+ sortent du lot avec un taux d’adoption respectivement de 100% et 55,4%. Suivent LinkedIn (15,4%), Twitter (12,3%) et Yahoo (9,2%).

Du rêve à la réalité

La transformation numérique et l’évolution de la relation client repositionne l’expérience utilisateur au cœur des réflexions stratégiques des entreprises.

Simplicité, efficacité, fidélité sont les maîtres-mots de la nouvelle relation client, trois enjeux pour lesquels le social login semble être un accélérateur à considérer.

Toutefois, son déploiement n’est pas une évidence, ni même opportun pour toutes les entreprises (en fonction du secteur d’activité, des populations cibles, de la typologie de clients…) et requiert le respect de certaines bonnes pratiques de sécurité et de protection des données personnelles.

Pour plus de détails, rendez-vous au prochain article : « Chapitre 2 : La réalité ».

Cet article Social Login : faire d’un rêve une réalité (1/2) 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.

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.

Une évolution indispensable de l’approche « traditionnelle »  de l’authentification

Si les solutions d’authentification classiques (normale, forte ou renforcée) constituent bien une première couche de sécurité essentielle pour la protection des ressources, force est de constater qu’elles affichent aujourd’hui certaines limites :

• L’authentification étant bien souvent le premier niveau de sécurité rencontré par un client (par exemple sur sa banque en ligne), il est aussi fort logiquement le premier à être attaqué. On constate par exemple depuis quelques années une course entre les banques en ligne pour renforcer leurs solutions d’authentification proposées à leurs clients.
• Comme souvent, la course au renforcement de la sécurité au niveau de l’authentification se fait au détriment de l’expérience utilisateur avec des solutions par toujours très ergonomiques, lors de leur activation ou de leur utilisation. Certaines (token matériel, certificats) ne sont par ailleurs pas adaptées aux nouveaux usages mobiles.

Trouver un bon compromis entre niveau de sécurité et expérience utilisateur reste pour autant un point essentiel pour des acteurs tels que des banques en ligne ou les sites de e-commerce qui savent bien qu’une authentification trop complexe risque de décourager un client d’utiliser ses services en ligne, voire de le faire abandonner un achat.

Améliorer la sécurité en ayant un impact limité sur l’expérience des clients, apporter une stratégie de sécurisation complémentaire à l’authentification, telles sont les promesses des solutions de détection de fraude dont le marché est aujourd’hui florissant. Les derniers rapports des analystes tels que Gartner ou Forrester montrent bien l’expansion de ce type de solution, ces derniers évaluant désormais plus de 40 solutions dans leurs études.

La fraude en ligne : quelle stratégie adopter ?

S’il existe aujourd’hui un marché très riche de solutions de détection de fraude en ligne, on retrouve une approche souvent semblable, s’articulant autour de trois piliers.

Le premier enjeu consiste à collecter un maximum d’informations afin de permettre une évaluation du contexte dans lequel se présente un client et d’estimer si les opérations qu’il est en train de réaliser sont légitimes. À ce titre, différents types de données peuvent être pertinentes à collecter :

• Des données liées au contexte de connexion de l’utilisateur, telles que le fingerprint de son device, l’IP, la localisation et l’horaire de la connexion, ainsi que des données techniques permettant par exemple de détecter la présence de malwares connus.
• Des données de type comportemental liées à l’interaction de l’utilisateur avec son device et son environnement : habitude de navigation sur un site web ou biométrie comportementale telle que la manière de frapper au clavier, de bouger sa souris, de remplir des formulaires,…
• Des données métier propres aux opérations réalisées par un utilisateur : type de bénéficiaire ajouté pour un virement, montant d’un achat en ligne,…

Une fois ces données collectées, les solutions de détection de fraude en ligne vont chercher à mettre en œuvre des stratégies permettant d’exploiter en temps réel ces données pour juger de la dangerosité de l’opération en cours. Ces stratégies consistent en général à définir des règles de détection (ex : interdire une opération depuis un pays à risque, lever une alerte en cas de connexion sur de multiples comptes depuis le même device en un cours délai,…) et à utiliser des profils comportementaux dans une logique de scoring. Dans ce second cas, des écarts trop importants par rapport à l’usage « habituel » pourra être considéré comme risqué et déclencher une action de la part de la banque ou du site de e-commerce.

Comment traiter les contextes suspects ?

Ces solutions de détection de fraude en ligne présentent donc de nombreux avantages :

• Tout d’abord, elles ne se substituent pas aux solutions d’authentification classiques, mais on bel et bien pour objectif de renforcer et compléter cette première couche de sécurité.
• Ce renforcement de la sécurité est, dans la majeure partie des cas, transparente pour les utilisateurs, a minima lorsqu’aucun contexte suspicieux n’a été détecté. En cas de détection d’un contexte suspicieux, ces solutions ont également l’avantage de pouvoir adapter les réponses apportées en fonction du niveau de risque quantifié. Ainsi, des contextes de connexion fortement suspects peuvent conduire par exemple à redemander une authentification à l’utilisateur, demander une authentification avec un niveau de sécurité plus élevée, bloquer l’opération ou encore notifier l’utilisateur via un canal tiers. En revanche, lorsque le niveau de risque détecté reste modéré (bien que plus élevé que pour un contexte « normal »), le traitement de ce dernier peut également être transparent pour l’utilisateur, par exemple en alertant simplement le centre antifraude du fournisseur de service sans pour autant bloquer ou alerter l’utilisateur.
• Enfin, une meilleure détection de ces fraudes ou tentatives de fraudes en amont permet d’alléger et simplifier les chaines de traitement des dossiers de fraude en aval, lorsque ces dernières sont avérées.

Parallèlement aux avantages sus-cités, certaines questions ou points d’attention doivent être pris en compte avant de déployer ce type de solutions.

• Des phases pilotes en amont du déploiement sont indispensables afin de s’assurer que les règles implémentées conduisent à des taux de faux positifs / faux négatifs acceptables. Par exemple, des taux de faux positifs trop importants peuvent rapidement dégrader l’expérience utilisateur et générer de l’incompréhension (pourquoi me demande-t-on une seconde authentification ? pourquoi suis-je bloqué ? j’ai reçu une notification par mail, ai-je réellement été piraté ? etc.).
• Ces solutions, si elles ont pour but de réduire le nombre de fraudes, ont également pour conséquence d’augmenter le nombre d’alertes en amont, comme dit précédemment. Il est donc indispensable, pour le fournisseur de service, d’être en mesure de traiter ces alertes remontées et donc dimensionner les équipes en charge de ces traitements en conséquence.
• Enfin, afin de complexifier le contournement (toujours possible !) de ces solutions par les hackers, il est important notamment de diversifier au maximum les types de données collectées, les règles utilisées pour évaluer le risque de fraude, de s’assurer que les traitements de ces données sont bien réalisés côté serveur et non côté client, etc.

Cet article La fraude en ligne : comment la détecter et s’en prémunir ? est apparu en premier sur RiskInsight.

Touch ID, un lecteur d’empreintes simple et plus sûr

Selon Apple, Touch ID est plus sécurisé qu’un code à quatre chiffres : la probabilité que le capteur confonde deux empreintes digitales est de 1 sur 50 000 et elle augmente à « 1 sur 10 000 lorsqu’un utilisateur non autorisé devine un code d’accès à 4 chiffres ». Il faut néanmoins préciser que ces deux chiffres ne sont pas réellement de même nature car le premier représente une probabilité de fausse détection tandis que le second correspond à la probabilité de trouver le bon code de déverrouillage, et donc de pouvoir se ré-authentifier par la suite.

Utiliser Touch ID est également relativement simple. Lorsque le doigt est apposé sur le bouton d’activation de l’écran d’accueil, une photographie haute résolution de l’empreinte digitale est prise, puis comparée à un gabarit référence généré au moment de l’enregistrement de l’utilisateur. Concernant la confidentialité de ces données, la documentation technique précise que lors du processus d’enregistrement, c’est la modélisation mathématique de l’empreinte digitale qui est hébergée dans l’enclave sécurisée du processeur, au plus proche du capteur, et non les empreintes digitales des utilisateurs.

Un capteur biométrique aux usages multiples

Avec le lancement de l’iPhone 6 et d’iOS 8, les usages évoluent. Jusqu’à présent, le capteur permettait uniquement de s’authentifier et de payer ses achats sur l’Apple store, l’iTunes Store et l’iBooks Store. Désormais, l’arrivée d’Apple Pay permet de réaliser tous types d’achats en validant ses paiements via Touch ID, notamment grâce à l’intégration d’une puce NFC (pour le moment, Apple Pay n’est disponible qu’aux États-Unis). Il devient également possible de sécuriser l’accès à des applications tierces.

Les nouvelles fonctionnalités que pourraient offrir ces capteurs biométriques sont nombreuses, telles que déverrouiller une voiture ou effectuer un virement bancaire. La question de la sécurité devient donc cruciale.

Performances et limites de Touch ID

En dépit des tests et des études montrant que cette technologie est robuste et que les taux de faux positif et de faux négatif restent bas, Touch ID possède quelques limites.

L’authentification peut être avortée si le lecteur biométrique porte des traces de poussières, de graisse…Le capteur est également insensible à la chaleur corporelle et ne fait donc pas la différence entre la peau et les corps inertes. Enfin, comme pratiquement tous les lecteurs d’empreintes digitales, il est possible de le piéger. De nombreux experts en sécurité ont posté des vidéos montrant leurs tentatives réussies de piratages à partir de fausses empreintes digitales. Le « Chaos Computer Club » a ainsi réussi à tromper Touch ID en photographiant en haute résolution une empreinte digitale et en moulant cette dernière.

Nous avons, nous aussi, voulu tester la fiabilité de cette technologie avec de fausses empreintes digitales réalisées en gélatine alimentaire et en colle à bois. Le processus est fastidieux et les résultats varient en fonction de la qualité des copies et de leur fidélité par rapport à l’originale, mais nous sommes bien parvenus à déjouer le capteur biométrique.

Ainsi, une personne mal intentionnée pourrait parvenir, moyennant de nombreux efforts, à s’authentifier sur les appareils utilisant la biométrie par Touch ID. Cela implique cependant de pouvoir récolter une empreinte digitale nette, claire et épaisse qui puisse être facilement dupliquée, ce qui est au quotidien difficile à trouver.

Des évolutions dans le futur ?

Simple d’usage et efficace, la technologie Touch ID est une belle avancée pour la sécurité des terminaux mobiles. Malgré ses limites, les usages cités précédemment (accès aux données personnelles sur les terminaux, paiements mobiles…) ne devraient théoriquement pas souffrir de problèmes majeurs de sécurité pour le grand public.

Cependant, pour des populations sensibles ou dans des contextes à risques, il faut avoir conscience des limites concrètement démontrées. Il aurait été souhaitable que la sortie de l’iPhone 6 améliore de façon notable la sécurité et les performances du capteur biométrique. Malheureusement, à part une plus grande sensibilité impliquant une diminution du taux de faux négatifs (la résolution du capteur étant plus grande), il n’y a pas eu de modifications substantielles. Dans le futur, une approche combinant l’empreinte et un code pourrait être une évolution intéressante et simple à mettre en œuvre.

Enfin, si l’on souhaitait renforcer la sécurité de manière significative, on aurait pu s’orienter vers des technologies biométriques « sans traces » (réseau veineux, reconnaissance d’iris…etc). Mise à part l’usabilité de la plupart de ces technologies qui ne permet pas à l’heure actuelle de les intégrer sur un smartphone, la question essentielle est de savoir si le grand public est prêt à les accepter et à les utiliser. Affaire à suivre…

Cet article Touch ID marque-t-il la sécurité de son empreinte ? 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.

Pourquoi la gestion des identités et des habilitations des ERP ne doit-elle pas être négligée ?

Les ERP comme SAP sont devenus incontournables dans beaucoup d’entreprises, particulièrement dans les grands groupes. Tout le monde les utilise : de la gestion des achats à celle des contrats, en passant par le contrôle des factures, le mouvement des stocks ou la gestion des ressources humaines, les ERP permettent de tout gérer. À tel point que pour un utilisateur au cœur de ces fonctions, l’ERP peut devenir son principal outil de travail, et représente la majeure partie de « son SI ». Une ville dans la ville du SI, en somme.

Des métiers comme les achats ou la distribution sont potentiellement sensibles, et sont de fait réglementés. La loi de sécurité financière en France, ou la loi Sarbanes-Oxley aux États-Unis, responsabilisent les utilisateurs, mettent en place le contrôle interne et contribuent à la prévention des conflits d’intérêt. Pour être en mesure de se conformer à ces règlementations, il est nécessaire de contrôler les opérations réalisées via les ERP.

Mais encore faut-il savoir qui fait quoi dans l’ERP… ce qui n’est pas toujours le cas. La criticité des opérations impose de donner au sein de l’ERP les bons droits d’accès, aux bonnes personnes, au bon moment, et de contrôler la bonne application des règles. Cela implique, entre autres, de maintenir un référentiel d’utilisateurs dans le temps, de définir des processus d’habilitation à différents niveaux de validation, ou encore de définir des processus de gouvernance qui permettent de faire évoluer la gestion des habilitations de l’ERP en phase avec l’organisation opérationnelle. Avec une attention particulière sur le modèle d’habilitation et l’accompagnement aux utilisateurs.

La richesse des modèles d’habilitation peut induire trop de complexité : comment trouver le bon équilibre ?

Les ERP permettent beaucoup de souplesse dans la définition du modèle d’habilitation. Dans le cas de SAP, le modèle est défini, notamment, via des rôles « pères » et des rôles « fils » liés par des notions d’héritage, et qui instancient un ensemble de transactions sur un périmètre donné. Ou encore des rôles composites qui regroupent plusieurs rôles « fils ». Chaque entreprise utilisant SAP est ainsi en mesure de définir son modèle d’habilitation avec la granularité et la richesse nécessaire à son contexte.

Et c’est bien là le risque. Cette souplesse ne doit pas inciter à définir un modèle d’habilitation (trop) complexe pour l’entreprise. Elle rendrait en effet  la gestion des demandes plus compliquée au jour le jour et induirait au bout du compte un risque de non-conformité aux réglementations.

Nous avons déjà rencontré des situations où les responsables du modèle métier  se désapproprient le sujet, laissant le modèle à la dérive. De même dans le cas des responsables de la ségrégation des tâches (qui limitent le cumul par une même personne de fonctions incompatibles, comme par exemple être en mesure d’éditer une facture et de la payer), cette complexité peut entraîner des attributions abusives de droits. Trop souvent, nous observons la situation « je valide parce que je ne comprends pas… et ne veux pas empêcher les utilisateurs de travailler ».

Le modèle d’habilitation doit donc être cadré et maintenu dans le temps. Un cadre « ferme et simple » fixera des principes et limitera les dérives. Il  définira les rôles types en fonction des métiers et les processus associés, sans essayer de prendre en compte toutes les exceptions de chaque métier.

Par ailleurs, une organisation qui fasse évoluer le modèle dans le temps est aussi nécessaire : la complexité peut résulter d’évolutions successives sans vision d’ensemble. Par exemple dans SAP, le modèle d’habilitation évolue notamment via la mise à jour de rôles simples, lesquels contiennent des droits fins (transactions), répercutés dans plusieurs rôles composites, impactant in fine plusieurs métiers.

Un travail en silo où les évolutions seraient dictées par les besoins spécifiques de quelques fonctions conduirait à un modèle d’habilitation cacophonique. Une organisation et des processus de gouvernance permettent d’éviter cela en contrôlant et en validant collectivement les évolutions. Les acteurs d’une telle gouvernance peuvent inclure des responsables des processus métiers, qui associent la connaissance du terrain à celle du modèle d’habilitation. On pourra y associer un acteur du contrôle interne.

Une équipe transverse s’assure en complément que les responsabilités définies sont bien attribuées et vivent au gré des arrivées, mobilités et départs.

Accompagner les utilisateurs : la clé pour garantir que les outils soient utilisés à bon escient

Les utilisateurs aussi ont besoin de comprendre les habilitations elles-mêmes  et de connaître les acteurs liés aux processus. À défaut de réponse à ces questions, les utilisateurs se tourneront vers le chemin le plus court, parfois même en contournant les processus. Les utilisateurs qui ne savent pas quels rôles correspondent à leur besoin ont tendance à demander les mêmes que leur collègue de bureau, ou bien leur prédécesseur. Ceux qui souhaitent obtenir rapidement un rôle donné seront enclins à le demander directement à la personne effectuant l’attribution finale. Avec le temps, des droits dont les utilisateurs n’ont pas besoin, voire  incompatibles entre eux, s’accumulent.

Permettre aux utilisateurs de travailler correctement sur un ERP implique aussi de les former à l’utilisation des outils. Cela parait naturel pour les transactions métier qu’ils utilisent tous les jours. Mais c’est tout aussi nécessaire pour les démarches de demande d’accès liées à l’ERP qu’ils n’utilisent qu’occasionnellement, et qu’ils ont tendance à oublier.

Enfin la gestion du changement doit permettre de faire vivre les référentiels documentaires et le réseau des utilisateurs clé.

Les projets de gestion des identités et des habilitations du SI ne devraient pas hésiter à intégrer les ERP dans leur périmètre… et réciproquement. En effet ces projets sont encore trop souvent menés de manière disjointe pour les ERP d’une part, et le reste du SI d’autre part. Les gestions des identités et des habilitations doivent pourtant être mises en cohérence opérationnellement, tout utilisateur d’un ERP étant d’abord un utilisateur du SI. Sans surprise, leurs problématiques sont d’ailleurs similaires… et leurs réponses aussi ! Les questions des organisations, des processus et des interfaces techniques entre les deux environnements méritent donc d’être instruites. Bien que ces questions dépendent du contexte, un début de réponse serait à minima de décliner les mêmes processus de gestion des identités. Sans oublier que la gestion des accès doit être considérée comme un pan complet de la conduite du changement et de la formation.

Cet article SAP : le parent pauvre de la gestion des identités et des accès ? 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.

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.

Des tentatives infructueuses

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

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

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

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

2013 : un nouvel envol ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

À suivre au 3^ème épisode…

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

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.