Utilisateurs IoT : gérer l’identité des milliards d’objets connectés

Pendant des décennies, la gestion des identités numériques dans les entreprises a principalement concerné les personnes. Un employé reçoit un compte lorsqu’il rejoint l’organisation, obtient des accès correspondant à son rôle, voit ses permissions évoluer lorsqu’il change de fonction et perd normalement ses accès lorsqu’il quitte l’entreprise. Cette gestion du cycle de vie constitue aujourd’hui l’un des fondements de la cybersécurité.

L’Internet des objets change considérablement l’échelle du problème. Des capteurs, caméras, véhicules, machines industrielles, équipements médicaux, systèmes énergétiques et autres appareils connectés doivent maintenant être reconnus par les infrastructures avec lesquelles ils communiquent. Ils doivent pouvoir prouver leur identité, accéder aux ressources nécessaires à leur fonction et être empêchés d’utiliser celles qui ne leur sont pas destinées. Leurs permissions doivent également pouvoir évoluer ou être révoquées pendant toute leur durée de vie.

À cette population d’équipements s’ajoutent les applications, les API, les services automatisés et maintenant les agents d’intelligence artificielle. Une entreprise numérique peut donc progressivement administrer beaucoup plus d’identités non humaines que d’identités humaines.

Ce changement peut sembler essentiellement technique. Il est pourtant fondamental. Lorsqu’une machine possède une identité, des permissions et une capacité d’agir, elle devient un participant de l’infrastructure numérique. La gestion des identités ne peut donc plus être organisée principalement autour d’une seule question : « Qui est cet utilisateur? »

Elle doit désormais répondre continuellement à une question beaucoup plus vaste : qu’est-ce qui essaie d’accéder à nos systèmes, et que sommes-nous prêts à lui permettre de faire?

Un appareil connecté rencontre un problème comparable à celui d’un utilisateur humain lorsqu’il souhaite accéder à une ressource. Lorsqu’un capteur transmet des données à une plateforme, celle-ci doit pouvoir déterminer qu’il s’agit réellement du dispositif attendu. Lorsqu’une machine demande une configuration ou qu’un véhicule communique avec un service distant, l’infrastructure doit être capable d’établir la légitimité de cette communication.

Une simple adresse réseau ne constitue pas une identité suffisamment fiable. Elle peut changer, être imitée ou ne fournir qu’une information très limitée sur l’équipement qui communique. Différents mécanismes permettent donc d’associer plus solidement une identité numérique au dispositif : certificats, clés cryptographiques, modules sécurisés, mécanismes de provisionnement ou identités associées à certaines infrastructures de connectivité.

Cette identité constitue toutefois le début de la relation de confiance, et non son aboutissement.

Un système peut établir avec un niveau élevé de confiance qu’un dispositif possède bien l’identité qu’il prétend avoir sans devoir accepter automatiquement toutes ses actions. Un appareil légitime peut être compromis. Son logiciel peut contenir une vulnérabilité, une clé peut avoir été exposée ou son comportement peut soudainement devenir incompatible avec sa fonction habituelle.

Cette distinction entre authentification et autorisation devient fondamentale. L’identité permet de déterminer qui ou quoi demande un accès. Les politiques de sécurité déterminent ensuite ce que cette identité peut réellement accomplir dans un contexte précis.

Un capteur chargé de transmettre une température n’a aucune raison d’accéder à l’ensemble du réseau de l’entreprise. Une caméra peut devoir transmettre des images vers un service particulier sans pouvoir consulter d’autres systèmes. Un équipement industriel peut recevoir certaines commandes opérationnelles tout en demeurant isolé des fonctions administratives auxquelles il n’a aucune raison d’accéder.

L’identité devient ainsi le point de départ du moindre privilège. Le défi prend cependant une dimension complètement différente lorsque le nombre d’appareils augmente. Une entreprise de quelques milliers d’employés peut déjà consacrer des ressources considérables à la gestion de ses comptes, rôles et permissions. Une organisation exploitant des dizaines ou des centaines de milliers d’appareils doit gérer une population numérique d’une tout autre ampleur.

Chaque dispositif peut posséder une identité distincte, une version logicielle particulière, des autorisations précises et une relation spécifique avec différents systèmes. Certains appareils sont ajoutés, d’autres remplacés. Ils peuvent changer d’emplacement, de propriétaire ou de fonction. Certains tombent en panne, sont compromis ou doivent être désactivés.

Une gestion essentiellement manuelle devient rapidement impossible. L’identité machine doit donc être conçue dès le départ pour fonctionner à grande échelle. Le provisionnement, le renouvellement des secrets, la modification des permissions et la révocation doivent pouvoir être automatisés tout en conservant suffisamment de contrôle et de traçabilité pour comprendre précisément ce qui se produit. Une architecture capable d’administrer cent appareils ne devient pas automatiquement une architecture capable d’en administrer cent mille.

Cette échelle oblige également à penser l’identité comme un cycle de vie. Une identité numérique ne devrait jamais être considérée comme permanente simplement parce qu’elle appartient à une machine. Lorsqu’un appareil est fabriqué, une identité initiale doit être créée ou établie. Au moment du déploiement, elle doit être associée à un environnement, un client, une organisation ou une fonction. Ses permissions peuvent ensuite évoluer pendant plusieurs années.

L’appareil peut changer de propriétaire ou de site. Une nouvelle fonction peut lui être attribuée. Ses clés cryptographiques devront éventuellement être renouvelées et ses certificats expireront. Une vulnérabilité ou un incident de sécurité peut nécessiter la révocation immédiate de certains accès. Puis viendra finalement le moment où l’équipement sera retiré du service.

La manière dont son identité disparaît devient alors aussi importante que celle dont elle a été créée. Un appareil mis au rebut qui conserve des identifiants valides peut devenir une porte d’entrée vers des systèmes qui continuent de le considérer comme légitime.

Cette question devient particulièrement complexe lorsque les appareils possèdent une durée de vie de dix ou quinze ans. Les technologies d’identité et de cryptographie utilisées lors de leur fabrication peuvent devoir évoluer plusieurs fois pendant leur exploitation. Une architecture robuste doit donc prévoir dès sa conception la possibilité de renouveler les identifiants, modifier les permissions et remplacer certains mécanismes cryptographiques.

Le provisionnement initial constitue lui aussi une étape critique. Un appareil peut être fabriqué plusieurs mois avant son installation, traverser différents intermédiaires et être finalement déployé dans un environnement inconnu du fabricant au moment de sa production. Inscrire durablement des identifiants sensibles dans le logiciel ou utiliser des secrets statiques crée alors des risques importants.

Le partage d’un même secret entre plusieurs équipements peut étendre considérablement les conséquences d’une compromission. L’utilisation d’un secret différent pour chaque appareil améliore la séparation, mais impose ensuite la capacité de gérer potentiellement des millions d’identifiants pendant plusieurs années.

Des approches plus dynamiques permettent d’utiliser l’identité initiale de l’équipement pour établir une première relation de confiance, puis obtenir les identifiants et permissions réellement nécessaires à son environnement opérationnel. L’appareil n’a ainsi pas besoin de conserver en permanence toutes les clés donnant accès directement à chaque plateforme qu’il pourrait utiliser.

L’identité devient alors moins un coffre contenant toutes les clés qu’un mécanisme permettant d’obtenir l’autorisation appropriée lorsqu’elle est nécessaire. Cette conception rejoint directement le principe du Continuous Trust. Dans une infrastructure distribuée, l’identité permet d’amorcer la relation, mais la confiance doit pouvoir évoluer avec le contexte. Un appareil correctement authentifié hier peut avoir changé d’état aujourd’hui. Sa configuration, son emplacement, son comportement, sa version logicielle ou son niveau de risque peuvent justifier une décision différente.

La confiance devient donc continuellement vérifiée et réévaluée plutôt que définitivement acquise. Cette capacité possède également une dimension de souveraineté numérique. Qui contrôle l’identité d’un dispositif? Qui peut la modifier ou la révoquer? Est-elle intimement liée à un fournisseur particulier? Peut-elle continuer de fonctionner si l’organisation change de réseau, de plateforme ou de fournisseur cloud?

Ces questions prennent une importance considérable lorsque les appareils demeurent en service pendant une décennie ou davantage. Une entreprise peut changer plusieurs fois de stratégie technologique pendant cette période. Elle peut migrer vers une autre infrastructure cloud, modifier ses systèmes de gestion, changer d’opérateur ou devoir satisfaire de nouvelles exigences réglementaires.

Si l’identité de toute une flotte est profondément dépendante d’une infrastructure pratiquement impossible à remplacer, les appareils eux-mêmes deviennent une source de dépendance technologique. Préserver la capacité de faire évoluer les identités, les permissions et les relations de confiance contribue donc directement à préserver la capacité de choisir.

Les appareils IoT ne représentent cependant qu’une partie de cette transformation. Les organisations possèdent déjà de nombreuses identités techniques associées aux applications, aux services, aux API et aux automatisations. L’arrivée des agents IA élargit encore cette population parce que ces systèmes peuvent consulter plusieurs sources d’information, utiliser des applications et déclencher des actions au nom d’un processus ou d’une équipe.

Un agent peut devoir consulter un CRM, accéder à une base documentaire, préparer une transaction ou déclencher une opération dans un autre système. Il lui faut donc une identité et des permissions clairement définies.

Cette situation soulève une question importante : l’agent doit-il utiliser l’identité de l’employé qui l’a lancé ou posséder sa propre identité? Une identité distincte permet généralement une gouvernance beaucoup plus précise. L’organisation peut définir exactement ce que l’agent est autorisé à faire, suivre ses actions et révoquer ses permissions indépendamment de celles de l’utilisateur humain.

Cette séparation devient particulièrement importante lorsque plusieurs agents collaborent entre eux ou commencent à interagir avec des dispositifs IoT.

Imaginons une infrastructure industrielle dans laquelle un capteur détecte une situation. Les données sont transmises à une plateforme où un agent IA les analyse, consulte l’historique de la machine et détermine qu’une intervention est nécessaire. Une instruction est ensuite transmise à un système de contrôle qui modifie certains paramètres de fonctionnement.

Plusieurs identités participent alors à une seule chaîne d’action : le capteur qui a produit l’information, la plateforme qui l’a reçue, l’agent qui l’a interprétée, le système qui a demandé l’intervention, l’équipement qui l’a exécutée et éventuellement l’employé qui supervisait le processus.

L’organisation doit pouvoir reconstruire cette chaîne. Elle doit savoir quelle identité a produit l’information, laquelle a pris ou recommandé une décision, laquelle a demandé l’action et quel système l’a finalement exécutée. À mesure que les systèmes deviennent autonomes, savoir qui — ou quoi — a fait quoi devient une propriété essentielle de la sécurité, de la gouvernance et de la responsabilité.

Cette multiplication des identités non humaines augmente inévitablement le nombre de cibles potentielles. Une architecture résiliente ne peut donc pas reposer sur l’hypothèse qu’aucune identité ne sera jamais compromise. Elle doit limiter les conséquences lorsqu’une compromission survient.

Si un capteur est compromis, son identité devrait uniquement permettre d’accéder aux ressources nécessaires à sa fonction. Si un agent IA est détourné, ses permissions devraient l’empêcher d’agir au-delà de son mandat. Si une clé est exposée, elle doit pouvoir être révoquée et remplacée rapidement.

C’est ici que se rencontrent l’IAM, le moindre privilège, la segmentation, le Zero Trust et le Continuous Trust. L’objectif consiste à éviter qu’une identité légitime puisse devenir un passe-partout permettant de se déplacer librement dans l’environnement numérique.

Cette transformation entraîne également un besoin beaucoup plus fondamental : les organisations devront savoir quelles identités existent.

L’inventaire des appareils ne suffit plus. Combien d’identités machines sont actives? À quels systèmes donnent-elles accès? Qui en est responsable? Quand ont-elles été créées? Quels certificats et mécanismes cryptographiques utilisent-elles? Quand doivent-ils être renouvelés? Certaines identités correspondent-elles à des équipements qui ne sont plus en service?

Ces questions deviennent particulièrement importantes dans une perspective de transition cryptographique. Une organisation qui doit remplacer un mécanisme de chiffrement ou de signature doit connaître les appareils, certificats, applications et systèmes qui en dépendent. L’identité machine rejoint ainsi directement la crypto-agilité et la préparation post-quantique.

Une entreprise qui ignore où se trouvent ses identités et leurs dépendances cryptographiques rencontrera inévitablement davantage de difficultés lorsqu’elle devra les faire évoluer.

Cette évolution nous amène finalement à reconsidérer le rôle même de l’identité dans l’architecture informatique. À mesure que les systèmes deviennent distribués, le réseau physique perd une partie de son rôle historique comme frontière de confiance. Un appareil peut être connecté par réseau cellulaire, satellite, Wi-Fi ou Ethernet. Un agent peut fonctionner dans un cloud public, une infrastructure privée ou directement à l’Edge.

L’emplacement ne suffit plus à établir la confiance. L’identité devient alors l’un des mécanismes permettant de maintenir une politique cohérente à travers ces environnements. Un système peut reconnaître un humain, un dispositif, une application ou un agent, vérifier son contexte et lui appliquer les permissions appropriées indépendamment de l’endroit où il se trouve.

L’identité devient progressivement une infrastructure en elle-même.

Elle n’est plus simplement le mécanisme permettant à un employé d’ouvrir une session le matin. Elle devient l’une des fondations permettant à des personnes, des machines, des applications et des intelligences artificielles de travailler ensemble tout en conservant exactement le niveau d’autorité nécessaire à leur rôle.

Les organisations entrent dans une période où les identités numériques ne représenteront plus principalement des personnes. Elles représenteront également des capteurs, des machines, des véhicules, des applications, des API, des services automatisés et des agents d’intelligence artificielle. Dans certaines organisations, cette population non humaine pourrait rapidement dépasser largement le nombre d’employés.

La gestion de ces identités devient donc une discipline stratégique. Chaque dispositif et chaque agent doit pouvoir être reconnu, authentifié, limité à son rôle, supervisé pendant toute sa durée de vie et révoqué lorsqu’il ne doit plus accéder aux systèmes. Cette gouvernance devra fonctionner à très grande échelle tout en conservant suffisamment de précision pour déterminer quelle identité a effectué quelle action.

Cette évolution constitue également l’un des fondements de l’Hypersécurité. Lorsque les infrastructures deviennent distribuées et intelligentes, la confiance ne peut plus dépendre principalement de l’emplacement réseau. Elle doit reposer sur des identités connues, des permissions maîtrisées, un contexte évalué continuellement, des interactions traçables et une capacité à contenir rapidement les conséquences d’une compromission.

Chez Quantum Beyond, cette transformation rejoint directement nos travaux en architecture de sécurité, IAM, Zero Trust, Continuous Trust, Q-Carbon Security Systems, infrastructures Edge, gouvernance des agents IA et préparation cryptographique. Nos experts travaillent aux côtés des équipes technologiques et de cybersécurité afin de renforcer les architectures existantes, structurer les relations de confiance et préparer les organisations à gérer des environnements où les identités humaines ne représenteront bientôt qu’une partie de l’écosystème numérique.

Pendant longtemps, la cybersécurité a cherché principalement à répondre à une question : « Est-ce réellement la bonne personne? »

Dans une infrastructure où travaillent ensemble des humains, des objets, des applications et des agents intelligents, la question devient plus exigeante : « Est-ce réellement la bonne personne, la bonne machine ou le bon agent, dans le bon contexte, et possède-t-il exactement le niveau d’autorité nécessaire pour accomplir cette action? »