Dans ce contexte, la grande majorité des entreprises a mené des projets d’IAM : les accès aux applications sensibles sont étroitement contrôlés et les niveaux d’accès sont restreints selon les profils des utilisateurs et les actions à réaliser.

Or, trop souvent, ces démarches IAM « oublient » les populations IT qui ont pourtant des accès privilégiés sur l’infrastructure de l’entreprise. Et pour ces derniers, plusieurs spécificités sont à prendre en compte.

Les utilisateurs IT ont des besoins d’accès différents

Les utilisateurs « non-IT » représentent les utilisateurs « standards » du SI : utilisateurs des directions métier ou des fonctions support comme RH, paie, ou comptabilité… Ils accèdent classiquement :

• Aux applications en environnement de production,
• Et via les IHM standard de celles-ci.

Les populations « IT » (service informatique interne, télémaintenance, support…) ont quant à elles des accès très différents :

• Elles opèrent les infrastructures (serveurs, bases de données), et le code applicatif, sur lesquels reposent les applications ;
• Elles accèdent à tous les environnements et en particulier production et hors-production (ces derniers contenant souvent des données de production ou à caractère sensible ou personnel) ;
• Très souvent, elles opèrent avec des niveaux de droits (des « privilèges ») très élevés, présentant donc un niveau de risque non négligeable.

Ainsi, la terminologie « accès à privilèges » désigne tout accès technique, sur une infrastructure ou une brique logicielle, dans des environnements de production ou hors-production.

Ces accès sont parfois créés pour des individus, ou pour les applications elles-mêmes (une application a besoin de plusieurs comptes techniques, comme pour écrire dans une base de données).

On distingue différents niveaux d’accès « à privilèges ». Les plus critiques, de niveau « administrateur », offrent un contrôle total d’un ou plusieurs serveurs, et donc potentiellement plusieurs applications. Les accès IT de niveau « standard » sont moins sensibles mais restent à surveiller. Ces derniers pourraient permettre, par exemple, de consulter des informations sensibles dans une base de données.

Accès IT, risques métier

Par définition, la maitrise des accès privilégiés des populations IT doit être au cœur des préoccupations des entreprises.

Parmi les risques les plus importants, nous retrouvons :

• Les risques opérationnels, sans impact sur la production

Exemple : des traces d’exploitation sont supprimées par erreur ou un serveur non critique est éteint.

• Les risques sur l’activité de l’entreprise

Exemple : indisponibilité de la plateforme de flux des paiements / transaction suite à un redémarrage des serveurs par erreur.

• Les risques de non-conformité aux régulations

Exemple : mise en évidence d’un accès non-justifié sur un périmètre régulé suite à un audit interne.

• Des actions frauduleuses

Exemple : délit d’initié commis grâce à une information sensible consultée directement depuis une base de données.

Sans compter les risques plus larges autour du système d’information : vol de données, ransomwares et autres actions malveillantes. Parce qu’ils sont puissants (et permettent notamment de désactiver les mesures de sécurité), les accès à privilèges sont des cibles de choix en cas de cyber-attaque.

Aujourd’hui, la plupart des responsables d’application sensibles sont en mesure de rendre des comptes quant à l’usage des accès métier dans leur application. De la même manière, les responsables d’application et les responsables d’infrastructure doivent pouvoir répondre à des questions simples telles que :

• Qui utilise réellement des accès à privilèges sur mon périmètre ?
• Combien de comptes à privilèges existent sur mon périmètre ?
• Les mots de passe de ces comptes sont-ils changés régulièrement ?
• Quels sont les niveaux d’accès nécessaires pour mon application ou mes services, et qui ne peuvent pas être retirés sans conséquence pour la production ?

Plusieurs particularités à prendre en compte

Avant de se lancer dans un projet de mise sous contrôle des accès à privilèges, il est bon d’avoir conscience de certaines spécificités qui ne s’appliquent pas pour les accès métier.

À commencer par le cycle de vie de certains accès à privilèges. Dans le monde des accès métier, le cycle de vie est lié au statut RH de leur unique propriétaire. Mais dans le monde IT, il existe des accès partagés entre plusieurs personnes (pour des besoins opérationnels spécifiques), ou bien qui sont utilisés par l’application elle-même pour fonctionner. La durée de vie de ces accès-là est plutôt liée à la durée de vie de l’application concernée, ou bien parfois à la durée d’un projet.

Certaines contraintes opérationnelles sont aussi à prendre en compte. Notamment en ce qui concerne :

• La gestion de la production, qui ne souffre aucun délai. Dans le monde des accès métier, les niveaux d’accès sont généralement liés à la fiche de poste des utilisateurs, et c’est aussi le cas pour les populations IT. Mais dans certaines circonstances, les utilisateurs IT doivent pouvoir obtenir de nouveaux accès sans délai. Par exemple, en cas de panne d’une application critique, les équipes IT doivent pouvoir intervenir au plus vite avec toute la latitude nécessaire. Ce qui peut nécessiter des élévations de privilèges. Dans ce contexte, des processus de validation seraient trop longs (avec validation du responsable hiérarchique, puis éventuellement un autre niveau de validation…). Une autre approche peut consister à autoriser ce type de demande sans validation préalable, mais tracer et contrôler à posteriori l’usage qui a été fait de cet accès.

• Le grand nombre de ressources cibles. Certaines applications reposent sur un grand nombre de serveurs de production, et au moins autant de serveurs hors-production. Des applications peuvent aujourd’hui créer ou supprimer des serveurs virtuels à la volée, en fonction de la charge. Dans ce cas, il serait vite ingérable d’imposer aux utilisateurs des demandes d’accès pour chaque ressource cible. Une solution peut consister à gérer des demandes d’accès à des groupes de ressources (par exemple un groupe Active Directory qui représente tous les serveurs de production d’une application, lequel groupe pourrait même être déployé automatiquement sur les nouveaux serveurs par un orchestrateur).

Surtout, l’hétérogénéité de l’environnement peut rendre le modèle d’accès complexe. En effet, articuler la gestion des accès à privilèges autour d’un modèle cohérent, implique de composer avec :

• Des serveurs qui hébergent parfois plusieurs applications. Dans ce cas, un besoin d’accès à une seule application se traduit, en pratique, par des accès indus à plusieurs applications. Dans le cas d’applications critiques, il vaut donc mieux investir dans des serveurs dédiés (virtuels ou non, face aux risques portés par les administrateurs des plateformes de virtualisation).

• Des ressources hétérogènes avec leurs propres particularités. Serveur Windows, Unix, base de données Oracle, middleware Tomcat, des équipements réseau, voire des conteneurs comme Docker… La liste des technologies à prendre en compte est longue.

• Pour une même ressource, différents comptes à créer. Un utilisateur peut souvent intervenir sur une même ressource via différents moyens. Pour un même serveur, on pourra offrir la possibilité de s’y connecter directement (protocoles SSH, RDP…), via l’intermédiaire d’un serveur de rebond (et dans ce cas, c’est sur ce serveur qu’il faut créer un accès utilisateur), ou encore via une interface logicielle d’administration (c’est d’ailleurs la voie du DevOps).

• Des populations hétérogènes et des besoins qui évoluent rapidement. Le modèle d’accès est difficile à uniformiser, notamment parce que différents types de population, comme des administrateurs d’infrastructures ou des développeurs, ont des besoins différents. Par exemple, un administrateur Windows opère tous les serveurs Windows, quelle que soit l’application, alors qu’un développeur intervient sur plusieurs technologies dans la limite d’une application. Mais il est aussi difficile d’uniformiser le modèle d’accès pour une même population, car les développeurs de 2 applications différentes peuvent avoir des besoins différents.

Les accès à privilèges : un challenge pour la sécurité ?

Accès standards métier et accès à privilèges sont les 2 faces de la même pièce. Et les accès à privilèges en sont la face sombre, car ils sont à la fois plus sensibles et techniquement plus complexes à gérer.

Face à cet état des lieux, la prise de conscience des entreprises est inégale. Les mieux informées sont les équipes techniques IT qui utilisent les comptes à privilèges, et qui sont souvent favorables au statuquo.

Au-delà de la Direction des systèmes d’information, ce sont les Directions en charge des processus internes, de la qualité ou encore le contrôle interne, qui ont un rôle clé de sponsoring à jouer.

Le législateur, lui, commence aussi à s’y intéresser. Ainsi la Loi de programmation militaire, qui concerne les opérateurs d’importance vitale, impose une mise sous contrôle des accès à privilèges les plus critiques.

Mais alors comment s’y prendre, pour mettre les accès à privilèges sous contrôle ? Nous y reviendrons dans un prochain article.

Cet article Accès à privilèges : la face sombre de l’IAM est apparu en premier sur RiskInsight.

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.

Des tentatives infructueuses

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

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

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

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

2013 : un nouvel envol ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

À suivre au 3^ème épisode…

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