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.

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

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

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

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

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

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

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

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

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

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

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

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

Comment m’outiller ?

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

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

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

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

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

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

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

Combien de temps dois-je prévoir ?

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

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

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

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

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

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

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

En conclusion

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

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

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

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

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

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

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

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

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

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

Une couche d’abstraction…

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

…qui simplifie la gestion des habilitations…

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

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

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

… et améliore la sécurité

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

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

Panorama des modèles possibles

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

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

RBAC : Role-Based Access Control

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

OrBAC : Organization-Based Access Control

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

ABAC : Attribute-Based Access Control

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

GraphBAC : Graph-Based Access Control

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

Vision du marché

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Industrialiser le déploiement

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

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

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

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

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

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

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

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

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

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

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

4. Bien s’outiller

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

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

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

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

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

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

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

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

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

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

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

5. S’inscrire dans la durée

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

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

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

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

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

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

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

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

En conclusion, c’est possible !

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

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

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

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

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

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

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

Une maîtrise toute relative des habilitations sur les ERP

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

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

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

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

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

Comment s’y prendre ?

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

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

1. Piloter de façon rapprochée

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

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

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

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

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

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

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

2. Préparer le terrain

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

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

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

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

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

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

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

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

Stop aux mots de passe !

S’authentifier, c’est prouver par un moyen convenu que l’on est bien la personne que l’on prétend être. Depuis l’Antiquité, le moyen le plus adopté et utilisé reste sans conteste le mot de passe. Il est cependant source d’agacement pour les utilisateurs et présente de nombreuses limites d’un point de vue sécurité.

Un sentiment partagé de « ras-le-bol »…
Nous avons tous une fois rêvé de ne plus devoir se rappeler quel mot de passe utiliser pour se connecter à nos applications préférées. Mais force est de constater que cela reste toujours un rêve.
La promesse de l’authentification unique est loin d’être tenue en entreprise et l’essor des coffres forts de mots de passe montre bien les difficultés rencontrées par les utilisateurs : multiplicité et pertinence relative des politiques de mot de passe, changement de mot de passe obligatoire, sans compter que réinitialiser son mot de passe peut relever du parcours du combattant.
Néanmoins, le principal avantage du mot de passe reste son côté universel et déjà inscrit dans les habitudes de tout un chacun.

… et un niveau de sécurité limité
De nombreux scénarios de cyberattaques s’appuient à un moment ou à un autre sur la compromission d’un mot de passe, de préférence celui d’un compte à privilèges, en utilisant différentes techniques : tests de combinaisons en grand nombre (brute force), interception de communication (Man-In-The-Middle), reconstitution du mot de passe à partir de son empreinte (Rainbow Table)…

Des mesures de sécurité pour se prémunir de ces attaques existent (chiffrement, hachage, salage, blocage du compte…) mais ne sont pas toujours implémentées systématiquement voire pas toujours de manière satisfaisante. Comme le dit l’adage, « Les mots de passe sont du point de vue de l’entreprise comme des déchets nucléaires : on les enterre profondément et on espère qu’il n’y aura pas de fuite.»

Outre les faiblesses techniques évoquées, un risque majeur réside dans les comportements des utilisateurs : réutilisation du même mot de passe pour plusieurs services, mots de passe trop faibles ou faciles à deviner, incrémentation… Ainsi, lorsqu’un mot de passe est réutilisé sur plusieurs services, le maillon le plus faible fragilise toute la chaîne.

En définitive, l’expérience utilisateur appauvrie et le niveau de sécurité limité poussent les entreprises à chercher de nouveaux moyens d’authentification.

Quels remèdes ?

On divise généralement les moyens d’authentification en 4 catégories :

Ce que je sais

Ces méthodes d’authentification se basent sur une clé ou un code que l’utilisateur connait. Elles représentent la majeure partie des solutions mises en place aujourd’hui aussi bien en entreprise que dans la sphère privée. Parmi les solutions existantes, on peut notamment retrouver le traditionnel mot de passe, le code PIN ou encore les questions secrètes. Ces dernières sont toutefois rarement utilisées car soit trop génériques (« Quelle est votre couleur préférée ? ») soit trop difficiles à retenir.

Ce que je possède

La sécurité repose sur le fait de posséder un matériel particulier. On retrouve notamment les matériels suivants :

• Un smartphone

Le smartphone permet, en entreprise comme dans la sphère privée, de sécuriser la réalisation d’opérations plus sensibles : accéder au réseau interne de l’entreprise, confirmer un paiement en ligne ou une opération bancaire inhabituelle…

Le smartphone peut ainsi être utilisé de différentes façons pour s’authentifier :

• Un token matériel

Un token a souvent la forme d’une mini-calculatrice et permet de générer un code à usage unique (OTP), le token pouvant lui-même être protégé par un code PIN choisi par l’utilisateur. Historiquement très utilisé dans les entreprises (accès VPN notamment) et occasionnellement dans la sphère privée pour la connexion à certains espaces clients, les tokens tendent néanmoins à disparaître au profit des smartphones, éliminant ainsi une logistique coûteuse.

• Une carte à puce

La carte à puce contient un certificat qui sert à prouver l’identité du porteur. Un lecteur de carte est indispensable pour l’authentification ; par ailleurs la gestion des certificats nécessite des infrastructures et des procédures de gestion du cycle de vie (arrivée, départ, perte…). Plutôt réservée au monde de l’entreprise, son usage tend à se limiter à des populations ou des usages ciblés (administration IT, opérations financières…).

• Une clé U2F

Cet objet se présente sous la forme d’une clé USB standard mais au lieu d’être utilisée pour stocker des fichiers, elle stocke une clé unique liée à l’utilisateur. Basée sur un standard défini par l’alliance FIDO, cette solution allie bon niveau de sécurité (notamment une résistance au phishing) et bonne expérience utilisateur (les clés peuvent rester brancher sur un port USB du poste) puisqu’une simple pression sur la clé suffit pour s’authentifier. Notons toutefois qu’il ne s’agit pas d’une reconnaissance d’empreinte digitale.

• Un objet connecté tel qu’une montre

Cette dernière solution, la plus novatrice dans cette catégorie, permet à l’utilisateur de se connecter par le biais d’un objet connecté qu’il possède déjà. Ce moyen d’authentification est très peu utilisé en entreprise mais Apple propose par exemple de déverrouiller son ordinateur en s’approchant simplement avec un objet connecté de la même marque.

Ces solutions basées sur la possession d’un matériel se distinguent essentiellement par leur niveau d’ergonomie. Dans tous les cas, il s’avère indispensable de gérer « l’enrôlement » (le fait de lier l’objet à son porteur), le renouvellement, la perte et le vol du matériel en question.

Ce que je suis

Les caractéristiques physiologiques d’une personne telles que l’empreinte digitale, le réseau veineux de la main, l’iris, le visage, l’empreinte vocale ou encore le rythme cardiaque permettent également d’authentifier une personne. L’usage de ces solutions est pour le grand public principalement limité à l’ouverture de son poste de travail ou de son smartphone (empreinte digitale ou visage). Cependant, ces solutions sont mises en œuvre depuis plusieurs années en entreprise pour contrôler l’accès à des salles ou zones hautement sensibles.

Ce que je fais

Le rythme de frappe au clavier, les mouvements de la souris, le maintien du téléphone, ou encore le toucher sur l’écran sont différents moyens de distinguer un utilisateur légitime d’un usurpateur ou encore d’un robot. Ces solutions de biométrie comportementale nécessitent un volume de données important pour être fiables mais cela tend à s’améliorer grâce aux nouvelles approches de Machine Learning. Ces solutions sont plutôt utilisées comme mesures de sécurité complémentaires à l’authentification (détection d’attaque par robot, détection de partage de comptes…).

En synthèse, la figure ci-dessous représente les différentes solutions d’authentification en fonction de leur niveau de sécurité et de leur simplicité d’utilisation.

Expérience utilisateur et sécurité, ennemis inconciliables ?

Nous pensons qu’il est possible de réconcilier expérience utilisateur et sécurité et proposons ici 4 orientations pour y parvenir.

Orientation 1 : Simplifier l’utilisation des mots de passe

S’il parait illusoire d’imaginer une suppression complète de l’utilisation des mots de passe, il reste possible néanmoins de s’attaquer à certains de leurs défauts. On peut déjà réduire la fréquence de saisie via des mécanismes de fédération d’identité qui permettent d’accéder aussi bien à des services de l’entreprise que des services de partenaires. Par ailleurs, des chatbots voient le jour pour simplifier les processus de réinitialisation de mots de passe et vont dans le sens d’une amélioration significative de l’expérience utilisateur. Quant à la sécurité, la sensibilisation des utilisateurs sur la bonne utilisation des mots de passe reste aujourd’hui une action essentielle pour réduire les risques (social engineering, spam, phishing, vols de mot de passe…).

Orientation 2 : Adapter les exigences de sécurité au contexte

De même que l’on doit adapter sa vitesse sur route aux conditions climatiques, la notion de « risque » doit nous guider dans le niveau de sécurité attendu pour authentifier l’utilisateur. Ainsi, pour consulter des informations non sensibles, un simple mot de passe peut suffire, là ou des opérations sensibles (virement bancaire important…) vont nécessiter d’authentifier l’utilisateur avec plus de certitude en combinant plusieurs facteurs d’authentification. D’autres critères peuvent être pris en compte pour évaluer le risque comme le PC ou smartphone utilisé, la localisation géographique, l’heure de connexion voire même le comportement habituel ou non de l’utilisateur.

Au-delà de la phase d’authentification, le niveau de risque peut également influencer la durée avant nouvelle demande d’authentification (pas besoin de retaper son mot de passe Facebook tant que l’on reste sur le même PC ou smartphone, réauthentification à un webmail tous les X jours seulement…).

Finalement, l’authentification n’est plus vue comme un événement mais comme un processus continu.

Orientation 3 : Laisser à l’utilisateur le choix de son facteur d’authentification

Plutôt que d’imposer un unique moyen d’authentification à tous les utilisateurs, le Bring Your Own Token (BYOT) consiste à laisser chacun choisir celui qui lui paraît le plus adapté à son usage. L’idée reste de proposer un choix parmi des solutions de niveau de sécurité comparable.

Aujourd’hui, Facebook ou encore Google, proposent du BYOT comme second facteur d’authentification via l’enregistrement d’un smartphone ou d’une clé USB sécurisée par exemple.

Dans le monde professionnel, cela reste moins développé pour le moment mais on peut facilement imaginer proposer ce service à des populations ciblées : besoins de mobilités spécifiques, appétence technologique…

Orientation 4 : S’appuyer sur les comptes déjà existants

Il est de plus en plus courant d’utiliser son compte d’un réseau social (Facebook, Google, LinkedIn) pour se connecter à des sites de e-commerce ou à d’autres sites web. Le Social Login permet à la fois de simplifier la création du compte sur le nouveau site en ligne et de limiter le nombre de mots de passe à retenir.

Tous les services en ligne n’ont cependant pas vocation à utiliser le Social Login. Dans le cas de services publics ou parapublics par exemple, on privilégiera plutôt le State Login qui permet par exemple d’utiliser son compte des Impôts, de l’Assurance maladie ou de La Poste pour effectuer différentes démarches administratives en ligne (FranceConnect). Le développement de ces usages est en pleine accélération aujourd’hui.

En conclusion

Si les mots de passe ne sont pas prêts de disparaître complètement, la recherche d’alternatives est en plein essor : les usages et les solutions technologiques évoluent rapidement, des consortiums et de nouveaux standards voient le jour (OAuth2, OIDC) et désormais l’expérience utilisateur est au centre de la réflexion au même titre que les enjeux de sécurité.

Cet article Quels remèdes contre les maux de passe ? est apparu en premier sur RiskInsight.