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.

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.

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.

Ces dernières années, les entreprises ont fait face à un élargissement du champ d’action de l’Identity and Access Management. Cette discipline n’est plus uniquement centrée sur les problématiques de provisioning utilisateur et d’authentification ; elle s’est tournée non seulement vers des problématiques de revue et de certification des comptes mais aussi vers l’utilisation des mécanismes de fédération d’identités (eg. SAML). Ces changements concernent aussi bien les applications SaaS que les applications restées en interne. Ces évolutions ont chacune permis une ouverture du SI toujours plus large, et nécessitent par conséquent d’être correctement implémentées pour limiter les failles de sécurité.

Cette évolution de l’IAM se fait en parallèle de la généralisation des services Cloud, qui ne cessent de donner naissance à de nouveaux usages pour plus de flexibilité et de souplesse dans l’accès et l’utilisation du SI. Les utilisateurs internes accédant au SI le font de plus en plus majoritairement depuis l’extérieur du réseau de l’entreprise, et ce depuis des terminaux de plus en plus variés.

En outre, les nouvelles technologies agiles et DevOps poussent le SI à évoluer différemment, intégrant beaucoup plus rapidement de nouvelles technologies (IoT, etc.) et de nouveaux usages.

Toutes ces évolutions font aujourd’hui du SI une bulle parmi d’autres interagissant avec son environnement et devant maîtriser, à distance, des interactions entre des composants décentralisés.

… rendant les APIs incontournables

Ce nouveau modèle décentralisé du SI donne naissance à la problématique d’interconnexion des services et des applications : comment assurer l’accès aux données à chaque instant et en chaque endroit ?

Aujourd’hui les APIs (Application Programmable Interface) représentent déjà un mécanisme de communication prépondérant et incontournable pour toute entreprise lancée dans sa transformation numérique. Elles sont utilisées dans  les traitements réalisés non seulement sur des données publiques (adresses d’agences, horaires des transports, etc.) mais aussi sur des données personnelles (tracking fitness, application Ameli et CAF, etc.) et des données sensibles (DSP2, achat en ligne, informations industrielles en mobilité, etc.).

Quelle recette pour sécuriser ses API ?

La sécurisation des API passe par une recette à base de 4 ingrédients à doser finement.

Une base de security as usual

Selon un benchmark Wavestone sur le sujet de la sécurité des applications web, sur 128 applications auditées, des failles graves sont observées dans 60% des cas et la situation est très similaire pour les APIs. À cet effet, les recommandations habituelles de la sécurité web, par exemple celles d’OWASP doivent être prises en compte de la même manière.

Il s’agit essentiellement de s’assurer de couvrir les principales zones à risques d’une application web et de déterminer les mesures de sécurité appropriées.

Une pincée d’OAuth

OAuth est un framework de délégation d’autorisation qui permet à une application d’obtenir l’autorisation d’accès à une ressource au nom d’un utilisateur.

OAuth se propose de couvrir un large éventail de cas d’usages (applications web, mobile, accès ou non à un navigateur, accès serveur-à-serveur, etc.) et offre à cet effet 4 cinématiques principales pour obtenir un jeton. Combiné à une spécification détaillant l’utilisation de ce jeton, un document détaillant le threat model, et enfin une surcouche dédiée à l’authentification (OpenID Connect), il s’agit d’un corpus documentaire équivalent à 250 pages, laissant une place certaine à un grand nombre d’options et de choix d’implémentation.

Et c’est bien cette abondance d’options et ce manque de contraintes qui entraînent les failles de sécurité observées régulièrement dans la mise en place d’OAuth2.0 : usurpation d’identité d’une application, accès aux données personnelles d’un utilisateur tiers, vol de cookie Facebook/Google lors d’un social login ou encore compromission de compte utilisateur.

Les six recommandations suivantes sont essentielles pour une mise en place sécurisée du Framework :

• Secret local : L’application est munie d’identifiants lui permettant de s’authentifier auprès du serveur OAuth : ne pas mettre ce secret (identifiant du service) dans l’application mobile ou le considérer compromis
• Redirect URI: Valider strictement les URLs de redirection vers l’application, sans wildcard
• Implicit: Éviter le « Implicit grant » dans la mesure du possible (et se tourner vers le proxy pattern)
• Authorization code: Valider strictement les authorization codes et clients associés
• State and PKCE: À utiliser pour garantir l’intégrité d’une cinématique complète
• Authorization ≠ Authentication: Utiliser OpenID Connect pour authentifier, OAuth pour déléguer l’accès

Limitez les additifs

À peine cette première pincée d’OAuth digérée, il faut déjà réfléchir à des solutions de sécurité permettant de répondre aux besoins que nous rencontrons le plus fréquemment.

Le Single Sign-On mobile, ou comment permettre à des employés en mobilité ou des clients d’accéder aisément aux applications sans se réauthentifier ?

Qu’il s’agisse d’un agent terrain en contact clientèle ou en tournée d’intervention qui peut utiliser plus d’une dizaine d’applications par jour ou qu’il s’agisse d’un client ayant installé plusieurs applications sur le store public, le besoin d’accéder à l’ensemble des applications sans avoir à se réauthentifier sur chacune est aujourd’hui très présent. Si, depuis 2008, les techniques le permettant ont varié au gré des possibilités offertes par les OS mobiles (KeyChain iOS, paramètres d’URL, Mobile Device Management…), Apple et Google ont convergé vers une solution commune en 2015 : utiliser le navigateur système comme point d’ancrage d’une session SSO. C’est maintenant une bonne pratique officielle matérialisée par la BCP « OAuth2 for native applications »

L’authentification contextuelle, ou comment adapter le niveau d’accès à une donnée en fonction de la criticité de celle-ci ?

Un des nombreux enjeux concernant l’authentification est de simplifier au maximum l’accès des utilisateurs à leurs données tout en garantissant un niveau de sécurité satisfaisant. L’authentification contextuelle permet de répondre à cet enjeu, en adaptant le niveau d’accès à la nature de la transaction, à ses caractéristiques, aux habitudes utilisateurs, à son contexte…. On parle de LOA (Level of Assurance). Dans le cadre d’une application mobile bancaire, cela permet à l’utilisateur de consulter son compte en banque, de bénéficier de la météo de ses comptes sans avoir à se réauthentifier à chaque accès. L’application requerra toutefois une authentification au moment de réaliser une opération sensible (un virement interne par exemple), et une authentification forte au moment de réaliser une opération très sensible (ajout d’un bénéficiaire par exemple).

Les solutions du marché proposent aujourd’hui des solutions pensées selon une logique où le client applicatif est responsable d’initier la demande de LOA correspondant à la donnée ou au service auquel il souhaite accéder. Mais le vrai besoin consiste à définir et appliquer ces politiques d’accès aux données de manière centralisée, au sein du serveur d’autorisation. Il s’agit notamment d’un besoin essentiel lorsque l’on veut appliquer une authentification liée au niveau de risque du contexte (géolocalisation, terminal connu ou non, habitudes de transactions, etc.)

Propagation de l’identité, ou comment transmettre un jeton d’accès entre deux applications (ou plus) ?

Il est courant qu’un appel vers une API déclenche une cascade d’appels vers d’autres API, notamment dans le cadre d’une architecture de type micro-service. La transmission de l’identité de l’utilisateur doit alors être assurée sans créer de risque de sécurité. Et les trois premières solutions qui viennent à l’esprit présentent des limites :

• La transmission du token initial est évidement à proscrire, à la vue du risque de fraude interne très élevé que cela entrainerait.
• L’authentification de l’appelant seule n’est pas suffisante non plus, car un composant compromis dans la chaîne peut usurper l’identité de n’importe quel utilisateur et compromet le reste de la chaîne.
• La génération d’un token pour l’appelant transmis avec le token de l’utilisateur initial ne permet pas d’assurer l’intégrité de la combinaison utilisateur/API et ne permet pas de vérifier la chaine.

Une ébauche avancée de solution existe aujourd’hui, proposant un nouveau grant type : Token Exchange. Ce mécanisme permet à l’appelant de demander un jeton intermédiaire, composé notamment de l’identité de l’utilisateur, de l’identité de l’appelant et de la chaine d’appel déjà effectuée. Cette nouvelle cinématique permet de centraliser la politique d’appel entre micro-service et l’application de cette politique, et d’assurer la traçabilité des appels.

Protection contre le vol de jeton, ou comment se prémunir du vol d’un ou d’une base de jetons ?

Par principe, le jeton contient de nombreuses informations sur son porteur, ce qui entraîne un risque important en cas de vol. Plus impactant encore, dans certains contextes (e.g. DSP2), un tiers (agrégateur) peut se retrouver en possession de très nombreux jetons, et le propriétaire de l’API se retrouve à la merci de ce tiers et de son niveau de sécurité. La détection du vol étant très difficile, il a fallu trouver d’autres solutions comme le Token Binding, un mécanisme de négociation à deux ou trois composants, permettant de lier un jeton à une paire de clés cryptographiques, et dans lequel le client doit prouver qu’il possède la clé privée constituant une partie de cette paire en établissant une connexion TLS mutuelle avec l’API.

Écrire la recette

Dernier ingrédient de la recette, il convient de décliner une architecture de référence de OAuth pour l’adapter au contexte du SI de l’entreprise. Pour cela, il faut définir le cadre d’utilisation des API en :

• Définissant et partageant les règles de sécurité : Les cinématiques autorisées et le cadre d’application, les checklists sécurité et l’architecture de référence doivent être formalisées.
• Formant et outillant les développeurs: Des sessions de formation et de présentations des principes adoptés doivent être organisées. Les équipes projets peuvent être rendues autonomes dans leur intégration au reste du SI.
• Intégrant les ressources sécurité dans les sprints agiles: Les ressources agissant en tant que coach sécurité doivent être identifiées pour accompagner la conception applicative et apporter des solutions prêtes à l’emploi et être un accélérateur

En synthèse

Au final, comme la recette du bon miel, sécuriser des APIs nécessite une succession d’ingrédients allant du plus basique jusqu’au plus élaboré tout en tenant compte du besoin et du contexte.

Cet article La sécurité des APIs ou la recette du bon miel est apparu en premier sur RiskInsight.

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.

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.

Et puis sont venus les partenaires externes et leurs employés. Dans le cas d’usage classique, un constructeur d’avion doit pouvoir collaborer avec l’ensemble de ses sous-traitants : il faut leur permettre l’accès aux applications, gérer ou faire gérer leurs comptes et leurs droits. La fédération des identités ainsi que ses standards et protocoles ont permis de répondre à cette problématique. La gestion des identités si elle devait prévoir de nouveaux processus n’a été que faiblement impactée (la volumétrie restait d’un ordre de grandeur comparable, les utilisateurs restaient des humains maîtrisés, etc.)

Aujourd’hui, un premier palier doit être franchi pour gérer une volumétrie beaucoup plus forte et des utilisateurs d’un nouveau type : les clients. Des centaines de milliers voire des millions d’identités. Il faut maintenant gérer l’identité d’un client et pouvoir l’authentifier et l’autoriser sur les applications mises à sa disposition. Il faut savoir l‘authentifier simplement de son point de vue (e.g. via un réseau social) et faire le lien avec son compte traditionnel dans le CRM pour gérer la relation. Les opérateurs télécoms et les banques et leurs bases clients sont devenues le nouveau cas d’usage classique : les accès aux applications via Internet et terminaux mobiles sont dans l’air du temps.

Au-delà de ce changement d’échelle, les caractéristiques de ces identités de clients sont différentes des traditionnelles identités de l’entreprise : le nombre d’applications accédées et de rôles est plus faible. Par ailleurs, plus question de devoir gérer des cas particuliers, tous les clients sont logés à la même enseigne et ce pour le plus grand bénéfice des projets IAM qui vont enfin voir se réduire fortement leur complexité fonctionnelle.

Enfin, un deuxième palier s’annonce déjà : la gestion des identités des objets connectés. Le CES 2014 qui s’achève ces jours-ci nous en offre de multiples illustrations : brosses à dent, cocottes minutes, lits, ampoules, etc. Tous les objets du quotidien sont désormais connectés. Par ailleurs, la complexité et les facultés de ces objets nous environnant sont telles aujourd’hui que de nouvelles approches sont nécessaires.

Les premiers objets connectés étaient de simples capteurs : température, pression, cellules infrarouge, compteurs, etc. Généralement non connectés directement à Internet, ils émettaient de l’information dans un protocole spécifique à destination d’une passerelle qui elle avait pour rôle de centraliser les données et de les transmettre via Internet à un serveur de traitement.

Nouveaux usages et nouveaux besoins

L’identification de ces objets est alors très sommaire, allant de la simple déclaration d’adresse MAC jusqu’à l’utilisation d’une clé de chiffrement des échanges pour les installations les plus sophistiquées.

Les objets connectés sont maintenant non seulement émetteurs de données de plus en plus complexes mais également destinataires de commandes et d’action à réaliser, de correctifs et patches de sécurité, etc.

Dernier cas d’usage classique à la mode : la voiture connectée informe directement le constructeur ou le concessionnaire qu’un sous-composant est en mauvaise santé ou qu’une révision est nécessaire.

Ces objets doivent pouvoir être joints depuis n’importe où (et ne plus être masqués par une passerelle) et par ailleurs, les capacités d’attaques cybercriminelles ayant fortement augmentés ces dernières années, la sécurité des échanges et l’authentification préalable des objets est devenu un prérequis. Et nous voilà donc avec des milliers d’objets disposant d’une identité !

Cet article Des objets et des hommes est apparu en premier sur RiskInsight.

Que peut apporter le SIRH à ma solution IAM ?

Pour remplir ses objectifs, mon IAM doit être en mesure de répondre à des questions simples  en apparence: qui est cet utilisateur, quel est son nom, son prénom, son matricule ? Quelle est sa fonction dans l’entreprise, quel métier exerce-t-il, et par extension, quelles applications devra-t-il utiliser, ou encore quelles listes de diffusion seront adéquates pour lui ? Qui est son supérieur hiérarchique, et peut-être futur valideur pour ses demandes d’habilitations ? Quelle est son organisation de rattachement ?

Obtenir ces réponses est un premier besoin… mais n’est pas le seul ! Ses informations évoluent : un nouveau collaborateur intègre l’entreprise dans une semaine, il faut lui donner le plus rapidement possible ses accès SI pour qu’il puisse travailler ; Mademoiselle Durand, anciennement contrôleuse de gestion, devient responsable de la comptabilité… il faut lui donner ses nouveaux accès, certes, mais également supprimer les droits qui lui sont devenus inutiles, voire qui pourraient devenir « dangereux » par rapport à son nouveau poste (SoD). Monsieur Thomas, lui, quitte définitivement l’entreprise – or il avait accès (et à distance) à une application critique du SI : ses accès doivent être supprimés dès son départ !

Ces éléments et leurs mises à jour sont généralement présents dans le SIRH d’une entreprise, notamment en raison du lien de celui-ci avec la paie, qui a besoin de savoir qui payer (et quand arrêter de payer), qui est responsable des augmentations d’untel ou d’untel, quelle entité sera facturée, etc. Avec de tels enjeux financiers à la clé, un soin particulier est généralement accordé au maintien à jour de ce référentiel… une opportunité pour mon IAM !

Des atouts certains… mais des limites à avoir en tête

Les liens possibles entre SIRH et IAM sont donc bien réels. Mais attention cependant à ne pas oublier un point essentiel : systèmes d’information et ressources humaines sont deux univers différents, portés par des métiers différents, avec des enjeux, des objectifs, des vocabulaires différents.

Comme nous l’avons dit, le référentiel SIRH est souvent lié à la paie, et cette relation permet d’illustrer les limites des liens qui pourront, ou non, être tissés entre mon SIRH et mon outil d’IAM.

Première limite, là où la paie n’a besoin d’avoir dans son périmètre que les personnes qui seront payées par l’entreprise, mon IAM, lui, se doit de connaître tous les utilisateurs de mon SI, qu’ils soient prestataires, intérimaires ou salariés.

La notion de métier ou encore de hiérarchie n’est pas forcément identique dans le SIRH et  pour l’IAM. Pour le SIRH, Mme Mercier est supérieure hiérarchique de Mlle Durand, car c’est elle qui est responsable de ses augmentations… mais au quotidien, c’est M. Simon son manager ! Et c’est bien lui qui sera légitime pour valider les demandes d’habilitations de Mlle Durand. Les priorités ne sont pas non plus toujours les mêmes entre ces deux univers : un nouvel arrivant doit avoir ses accès SI (et donc être créé dans l’IAM) dès son arrivée… en revanche, il y a souvent moins d’urgence à le créer dans le SIRH, car il ne percevra son premier salaire qu’à la fin du mois…

Lorsque qu’il s’agit de parler de mobilité interne, les deux mondes peuvent également avoir quelques différends. Un collaborateur change d’équipe projet, tout en restant rattaché au même département ? Au niveau du SIRH, ce n’est pas une mutation, son métier reste la même. D’un point de vue SI, a contrario, ce changement constitue un petit bouleversement : son responsable opérationnel (et valideur) n’est plus le même, et l’utilisateur n’a plus les mêmes besoins en termes d’applications métiers. À l’inverse, un changement de nom d’organisation pour toute une filiale n’a quasiment aucun impact sur le SI, alors que tous les utilisateurs sont impactés dans le référentiel RH.

Comment s’interfacer avec le SIRH ?

Comme nous l’avons vu, le SIRH est capable de fournir énormément d’informations structurantes pour ma solution d’IAM, mais possède des spécificités à ne surtout pas négliger. Afin de tirer pleinement parti de cette source d’information et réussir un interfaçage propre, efficace et limitant au maximum les malentendus entre ces deux mondes, trois éléments sont nécessaires :

• Dans un premier temps, définir les éléments structurants pour l’activité opérationnelle et qui seront exploités par l’IAM : les organisations de rattachement des utilisateurs, leurs supérieurs hiérarchiques, les dates d’arrivées et de départ, etc.

• Il est ensuite primordial de se doter de l’organisation, des processus et outil d’IAM flexible, capable de s’adapter aux différences évoquées précédemment. La solution IAM doit ainsi permettre la création d‘identités en avance de phase, ou encore la modification manuelle de certains attributs d’identité. Elle doit conserver une certaine marge de manœuvre sur la gestion de ses identités, ne pas avoir une dépendance trop rigide vis-à-vis du SIRH.

• Enfin, une attention particulière doit être portée à la réconciliation entre les identités du SIRH et celles de l’IAM. Qu’un utilisateur soit créé « en avance » dans l’IAM, ou que certains de ses attributs soient modifiés manuellement, le lien avec le SIRH doit être assuré… faute de quoi, gare aux doublons et aux identités fantômes. Définir une clé unique de réconciliation entre les identités est indispensable pour un interfaçage efficace… et pérenne !

Le SI RH peut se révéler d’une aide précieuse pour la gestion du cycle de vie des utilisateurs grâce aux informations dont il dispose sur les personnes et sa connaissance des mobilités et départs. À condition toutefois de bien comprendre les processus RH sous-jacents, leurs particularités par rapport au monde du SI, et de s’y adapter dans une logique de gestion des identités et de contrôle des accès, sujet qui fera l’objet d’un prochain article.

Cet article Interface avec le SIRH : une opportunité pour l’IAM ? est apparu en premier sur RiskInsight.

Un apport des DLP complémentaire à la lutte contre l’intrusion et au contrôle d’accès

Une fuite d’information peut provenir de trois sources différentes. L’attaquant externe est souvent celui qui vient à l’esprit en premier. Cependant, l’expérience montre que ce sont les utilisateurs internes, autorisés ou non, qui font fuir le plus d’information.

Suivant la position de celui qui fait fuir l’information, trois grandes étapes peuvent être enchaînées : intrusion, accès à l’information, diffusion de l’information – dont la nécessité dépend des accès initiaux de l’acteur à l’origine de la fuite d’information. À chacune de ces étapes, des solutions de sécurité permettant de réduire le risque existent.

Il convient d’agir à toutes les étapes d’une fuite d’information en s’appuyant sur des mesures allant de la sécurité physique aux solutions de Digital Right Management (DRM), en passant par le chiffrement de flux, le cloisonnement, ou encore la gestion des accès et des habilitations…

Si de telles mesures sont déjà mises en œuvre, les outils de DLP permettent alors essentiellement de se prémunir contre des erreurs ou malveillances d’utilisateurs ayant un accès légitime à l’information. En ce sens, ils permettent d’apporter une protection au plus proche de la donnée.

Des solutions fonctionnellement matures

Les mécanismes de contrôle des DLP sont mis en œuvre à travers des règles ou politiques centralisées permettant d’analyser les traitements faits sur la donnée quelle que soit sa nature ou son support.

Grâce à des agents déployés sur le réseau et/ou sur les postes de travail, le DLP va pouvoir empêcher la copie d’un fichier sur un périphérique externe, l’envoi d’un document sensible par email, l’impression d’un document ou encore la publication d’une information confidentielle sur les réseaux sociaux.

Après analyse et filtrage des données par la solution DLP, différentes mesures de prévention peuvent être prises, avec un impact plus ou moins élevé pour l’utilisateur : alertes, demande de justification, blocage…

Enfin, il convient de noter que les acteurs du marché mettent de plus en plus l’accent sur le contexte d’utilisation de la donnée. Certains éditeurs proposent ainsi des fonctionnalités de gouvernance au sein de leur solution de DLP permettant par exemple de savoir exactement où se trouvent les données sensibles et qui y a accès.

Le marché des DLP est donc de plus en plus mature : la couverture fonctionnelle proposée est élevée et évolutive, la gestion de l’impact sur les collaborateurs de plus en plus souple. Néanmoins, les retours d’expérience restent limités par rapport à ce que l’on pourrait attendre.

La raison de ce paradoxe vient du fait que les métiers sont trop souvent insuffisamment impliqués dans les projets de DLP, alors même que ces projets n’ont que peu de chance d’aboutir sans eux, en particulier vu le volet RH nécessairement associé.

Adopter une approche par les résultats pour mobiliser les métiers

Il est illusoire de vouloir protéger toutes ses données dans tous les cas d’usage imaginables. Une approche purement technique visant un périmètre exhaustif n’a que peu de chance de convaincre, particulièrement dans la conjoncture économique actuelle.

Une approche par les résultats mêlant ciblage précis, démarche outillée, accompagnement et visibilité est donc à favoriser dès la sélection de la solution. Une fois les objectifs atteints sur un périmètre prioritaire, on peut envisager de l’élargir.

La première étape, primordiale, est donc la définition du périmètre prioritaire de données à protéger et des cas d’usage fonctionnels à traiter. Identifier les dix données les plus critiques, s’appuyer sur des situations fonctionnelles avérées, commencer par un nombre limités de supports pour réduire les aléas techniques sont autant de facteurs clés de succès.

La définition des processus de surveillance (politiques d’interaction avec les utilisateurs, processus en cas d’alerte…) ne doit également pas être négligée. Sur ce volet, et dès le début du projet, il est important de mobiliser les fonctions RH de l’entreprise pour valider le mode de mise en œuvre de la démarche DLP (alerte, blocage, journalisation…), construire les processus de gouvernance associés et au final envisager un passage devant les instances représentatives du personnel.

Lorsque le cadrage global du périmètre fonctionnel est effectivement achevé, la phase de sélection de la solution peut être entamée. Une démarche outillée impliquant la réalisation d’une maquette est indispensable pour s’assurer de l’adéquation de la solution aux cas d’usages fonctionnels identifiés et évaluer les résultats envisageables.

En cas de résultats satisfaisants, un déploiement progressif est à envisager avec un leitmotiv : la sensibilisation des utilisateurs.

Enfin, en mode récurrent, l’intégration à un SOC (Security Operation Center) peut permettre de bénéficier de la maturité de la gestion opérationnelle de la sécurité pour optimiser la surveillance d’une part et l’accompagnement et la visibilité fournis aux métiers d’autre part.

Cet article Le paradoxe des projets de Data Leak Prevention (DLP) : une problématique clé, des solutions matures… mais une mise en œuvre qui fait encore peur est apparu en premier sur RiskInsight.

La sécurité, une question négligée après la phase de contractualisation

Les limites posées par le SaaS sont aujourd’hui bien connues : difficultés d’adaptation du service aux besoins de l’entreprise, absence de possibilités d’audit, questions réglementaires, etc.

Pourtant, de plus en plus de services cloud sont adoptés, sans que la sécurité ne soit nécessairement un frein. Pour cela, une démarche classique d’analyse de risque est menée en évaluant les contraintes légales / réglementaires,  les mécanismes de protection des données, la gestion de la sécurité par le fournisseur, ou encore les conditions de réversibilité de la donnée.

Cette démarche est de plus en plus maîtrisée : de nombreux retours d’expérience et un outillage qui se professionnalise* amènent à faire des choix éclairés, en toute connaissance de cause des risques encourus, et donc parfois acceptés.

Malheureusement, la démarche sécurité s’arrête souvent là : à partir du moment où le sujet a été traité lors de la contractualisation, on considère qu’un bon niveau est assuré, puisque l’on a exigé du prestataire de s’en occuper !

Le maintien de la sécurité dans le temps est un enjeu régulièrement oublié, alors même qu’il est en partie du ressort de l’entreprise, et pas seulement à la charge du fournisseur.

Des sujets à inscrire dans la durée

Pour s’assurer que la solution cloud est déployée avec le bon niveau de sécurité, et maintenir celui-ci dans le temps, quatre grands thèmes sont à aborder en priorité. S’il s’agit de bonnes pratiques habituelles sur un SI d’entreprise, il faut aujourd’hui les adapter, voire les renforcer pour le SaaS.

•  La gouvernance : les services SaaS doivent être intégrés aux procédures de sécurité et des processus liés au service fourni. Il peut par ailleurs être utile de mener des actions de sensibilisation dans certaines situations.

• L’administration fonctionnelle du service est bien du ressort de l’entreprise : le fournisseur n’est pas en mesure de faire les choix fonctionnels à votre place (et ce n’est souvent pas ce qu’on lui demande) ! Pour l’aspect sécurité plus encore, c’est à l’entreprise de définir  et mettre en œuvre les fonctionnalités avancées disponibles, de restreindre les services au minimum requis par l’utilisateur, de former ses administrateurs… Ces aspects sont souvent les plus négligés, comme nous le constatons lors des audits que nous réalisons.
• Des contrôles réguliers peuvent et doivent aussi être mis en œuvre sur les parties auditables des services. Il s’agit en particulier de vérifier que les paramètres de sécurité sont inchangés, d’exploiter les logs sécurité, et de revoir les habilitations. S’il le permet, enfin, ne pas hésiter à auditer son fournisseur (visites de site, voire tests d’intrusion).
• Il reste enfin à traiter le sujet de l’IAM, enjeu transverse du Cloud, souvent peu ou mal maîtrisé de par sa complexité. Même si cette voie est souvent suivie, il faut pourtant éviter de recréer un compte dans le Cloud pour chaque utilisateur. Pour « synchroniser » les identités de l’entreprise dans le Cloud, il faut également éviter la multiplication des connecteurs  (et notamment ne pas en redévelopper un par fournisseur), sous peine de créer une situation ingérable. Deux approches sont aujourd’hui à prioriser : soit l’utilisation d’un outil de fédération d’identités interne (qui réalise la connexion avec la majorité des fournisseurs de SaaS), soit l’externalisation de l’IAM… dans le Cloud (!) en « Identity as a Service »

Le RSSI, garant de la cohérence des projets

Dans le cas du SaaS, le rôle des responsables sécurité de l’information est double.

D’une part, il s’agit d’accompagner les projets, en leur apportant des solutions transverses : un certain nombre de points peuvent être mutualisés en amont. C’est tout particulièrement le cas des sujets tels que l’IAM, qui doivent faire l’objet d’une approche unifiée et cohérente –  et surtout pas projet par projet.  C’est également le cas des questions légales qui doivent faire l’objet d’une réflexion globale amont.

D’autre part, la SSI demeure la garante du niveau de sécurité dans le temps : la Gestion Opérationnelle de la sécurité devra faire l’effort de partir à la conquête des nuages !

* On peut citer notamment le guide publié par l’ANSSI et la « Cloud Control Matrix » maintenue par la Cloud Security Alliance

Cet article SaaS et sécurité : entreprises, ne mettez pas vos responsabilités dans les nuages ! est apparu en premier sur RiskInsight.

Mettre en œuvre la carte CPS au travers d’un projet de gestion des identités et des accès

Le SI, tout en connaissant de profondes transformations, devient un enjeu majeur dans les hôpitaux : informatisation continue des services de soins, ouverture du SIH, dématérialisation des échanges et interopérabilité, renforcement des exigences réglementaires, etc. Ces évolutions facilitent le partage de l’information médicale mais rendent sa protection plus difficile.

La mise en œuvre d’un espace de confiance numérique pour le partage des données de santé devient alors une nécessité. Cette nécessité devient un prérequis dans le cadre du programme Hôpital Numérique et de la certification HAS (Haute Autorité de Santé).

La mise en place d’une gestion des identités et des accès, qui associe l’utilisation d’un dispositif d’authentification forte comme la Carte de Professionnel de Santé, permet de créer un espace de confiance numérique qui répond aux problématiques suivantes :

• Respecter les nouvelles règlementations ;
• Simplifier et sécuriser l’accès au SIH ;
• Accélérer les processus de gestion des droits ;
• Diminuer la charge d’administration et réduire les coûts de support.

Mener un projet de gestion des identités et des accès adapté au monde hospitalier

La gestion des identités et des accès associe des processus, des technologies et une stratégie de gestion des identités numériques et de spécification de leur usage pour accéder aux ressources informatiques de l’entreprise.

Mener un tel projet s’avère généralement plus complexe que la plupart des autres projets informatiques en raison du nombre et de la diversité des référentiels d’identités numériques, des solutions techniques mises en œuvre et des besoins des entités gouvernantes amenées à collaborer.

Notamment, les acteurs concernés par un tel projet dans le monde hospitalier sont nombreux : la Direction Générale, la Commission Médicale d’Établissement (CME), le Département d’Information Médicale (DIM), les directions gérant le personnel salarié et non salarié de l’établissement (Direction des Affaires Médicales, Direction des Ressources Humaines), le corps médical et soignant, la Direction des systèmes d’information (ou le service informatique), etc.

Par ailleurs, certains thèmes à aborder sont spécifiques aux établissements de santé :

• Comment instruire ce projet dans le cadre d’une mise en réseau de l’établissement au sein d’une ou plusieurs communautés hospitalières ?
• Faut-il limiter l’utilisation de la carte à l’accès aux postes de travail ou bien ai-je intérêt à étendre son usage comme pour l’accès aux locaux ?
• À qui dois-je la fournir ?
• Comment m’assurer que la carte CPS facilitera l’accès aux postes de travail ?
• Quelles applications dois-je prendre en compte dans mon projet ?

Un projet d’établissement nécessitant un engagement de moyens ainsi qu’une implication de tous les acteurs pour le rendre maîtrisable

Mettre en œuvre la carte CPS au travers d’un projet de gestion des identités et des accès se révèle être un projet stratégique d’établissement, porteur d’enjeux à la fois techniques, organisationnels et de conduite du changement, et à ce titre requiert une phase préalable de cadrage qui permettra :

• De définir le périmètre et évaluer la dimension du projet : état des lieux, besoins et les attentes, axes d’amélioration, périmètre fonctionnel cible, macro-évaluation charges, coûts, délais ;
• D’inscrire le projet dans une démarche globale : acteurs à mobiliser, instances de pilotage, possibilités de mutualisation.

Et vous, où en êtes-vous de la mise en œuvre de la carte de Professionnel de Santé au sein de votre établissement ?

Cet article La carte CPS : un projet d’établissement ou un projet informatique ? 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.