Accueil > OpenID Connect OAuth Serveur dédié > L’authentification dans le cadre de l’IIoT

L’authentification dans le cadre de l’IIoT

Un consortium a été initié en mars 2022 alliant la société i-Tego et l’Equipe Modélisation et Sûreté des Systèmes (MDS) de l’Université Technologique de Troyes (UTT) dans le but d’assurer la sécurité de la transmission des données entre les applications et les objets connectés de l’Industrie du Futur.
Outre la sécurisation des données en provenance des capteurs, l’étude et le démonstrateur du projet "AuthSec" seront particulièrement orientés vers la sécurité des ordres passés aux actionneurs en vue d’éviter les dysfonctionnements et les accidents.
Deux techniques seront combinées : l’authentification de bout en bout, au niveau applicatif, pour compléter la sécurité du niveau réseau ; des algorithmes basés sur l’apprentissage profond pour détecter et bloquer les commandes à risque.
Cette démarche s’inscrit dans une réflexion sur les conditions de la Cyber-résilience de l’Usine du Futur.

Le contexte dans lequel se conçoit la sécurité de l’Usine du Futur

Une ouverture encore mal maîtrisée

S’agissant de la sécurité des applications informatiques des entreprises le modèle initial consistait (et consiste toujours pour beaucoup) à sanctuariser les données et les traitements dans un réseau local isolé des services extérieurs et auquel seuls les utilisateurs du site pouvaient accéder. Ce modèle radicalement efficace est devenu inapplicable compte tenu de l’intérêt que pourraient présenter certains services externes pour une application particulière et de la nécessité d’ouvrir l’accès au réseau à des utilisateurs extérieurs : collaborateurs, clients, usagers. Il paraît inutile de justifier plus avant ce qui est maintenant une évidence.
S’agissant des collaborateurs hors site, une première ouverture a consisté à permettre l’accès à des utilisateurs ou des applications depuis le réseau Internet à l’aide de pare-feu, de tunnels ou d’une console distante, l’accès étant contrôlé en une seule fois à l’entrée, l’utilisateur distant se trouvant alors dans la même situation que s’il se trouvait sur site. Bien que ce modèle périmétrique soit à l’origine de nombreux et graves problèmes de sécurité, sa simplicité conceptuelle et sa facilité de mise en œuvre en font une solution très largement adoptée. Sa simplicité apparente et sa large application dès les débuts de l’informatique en font le choix préféré des comité de direction et des (ir)responsables soucieux de la sécurité de leur emploi s’appuyant sur la promotion qu’en font de très grandes entreprises.
Parallèlement, le besoin s’est fait sentir de mettre à la disposition du public des applications leur permettant d’interagir avec les données de l’entreprise ou de l’administration. C’est tout naturellement que les applications Web sont nées. L’utilisateur distant n’accède plus au réseau avec des outils omnipotents, mais au niveau applicatif, de son navigateur au « site web », c’est à dire à une application résidant sur un serveur . Une authentification de niveau applicatif, gérée par l’application elle même, permet de limiter son accès aux seuls traitement et données qui sont autorisés à l’utilisateur qui s’y connecte.
On aurait pensé que les applications Web auraient été développées dans le même temps pour permettre le télétravail, mais cela n’a pas été anticipé par les grandes entreprises restées positionnées sur le travail sur site, ou accoutumées aux tunnels ( établissant des réseaux virtuels privés ou virtual private network, ou tunnel VPN ) pour le travail de site à site, et qui ont naturellement adopté le modèle périmétrique pour le télétravail. Ainsi, le réseau local de la box familiale est joint au réseau de l’entreprise. Terrifiant.
Outre les facteurs historiques et culturels, il faut reconnaître le frein que représente la nécessité de modifier les applications « natives » pour en faire des applications web capables d’authentification, avec des délais et des coûts considérés comme improductifs. Face à l’urgence d’organiser le télétravail, un marketing opportuniste a fait admettre le tunnel VPN comme la panacée, alors que cela consiste à étendre le réseau de l’entreprise aux réseau locaux des box familiales au domicile des employés, avec les risques que l’on imagine - eh bien non, justement, on ne l’imagine pas. Alors que la sécurité des tunnels de site à site avait soigneusement été établie, la précipitation et les mauvaises pratiques prévalent dans le cadre du télétravail.

La tentation du Cloud

Une certaine image de l’Usine du Futur est aujourd’hui déterminée par des facteurs qui lui sont largement étrangers :
- la domination du marché grand public sur le marché professionnel, imposant ses produits et ses schémas mentaux ainsi que ses méthodes de marketing,
- le besoin de connexion à distance pour le télétravail, malheureusement fondé sur des réseaux conçus pour le grand public et des équipements domestiques,
- le désir de mobilité, recherche quasi ludique d’une facilité de connexion permanente, sans distinction de moyens, de techniques ou de comportement entre l’espace professionnel et la vie extérieure,
- l’approche commerciale des entreprise de services du numérique qui, à la suite des GAFAMs ayant largement promu la technique d’externalisation des services dans le Cloud, proposent de plus en plus des plateformes en tant que service (PaaS) qui leur sont particulièrement avantageuses, en évitant de trop mentionner ni traiter les problèmes de sécurité que cela implique.

A ces facteurs extérieurs, on pourrait ajouter deux tendances bien ancrées dans l’esprit de certains dirigeants et qui devraient pourtant appartenir au passé :
- l’externalisation de fonctions relevant de compétences considérées comme inaccessibles ou rangées par principe hors du « coeur de métier »,
- l’incompréhension des techniques de sécurité, la confiance excessive, la négligence au nom de la rapidité de développement et de la productivité, ou encore le classement des investissements de sécurité dans les charges improductives.,
- la crainte de se voir reprocher des choix technologiques hasardeux plutôt que le maintien de techniques dont la fiabilité serait justifiée par leur ancienneté et leur large adoption,
- le sentiment de propriété des IT sur la sécurité, qui devrait être de leur seule compétence et donc appliquée exclusivement au niveau réseau, faussement en concurrence avec une sécurité au niveau applicatif présentée comme alternative et non comme complémentaire.

Ainsi, il est donné aux public et aux chefs d’entreprise une vision de l’Usine du Futur dans laquelle tout est connecté à tout, sur le modèle applicable au grand public.
L’une des implications les plus lourdes pour la sécurité des réseaux est la multiplication des connexions extérieures non seulement à la périphérie des réseaux, mais encore dans leur profondeur.
Or, un grand désordre existe dans la sécurité des réseaux, à l’origine de nombreux accidents de sécurité ou de sûreté de fonctionnement. Pour l’Usine du Futur, de tels accidents sont inacceptables car ils pourront se traduire en perte de propriété industrielle et en arrêt de production.

Le modèle « Jéricho »

Depuis longtemps déjà les entreprises ont ouvert l’accès à leur réseau en contrôlant l’accès à leur périmétrie. Cependant, de multiples attaques aux conséquences graves ont démontré la faillite du modèle périmétrique.
Ce constat a été fait il y a de nombreuses années déjà. En 2004, le Jericho Forum introduisait le concept de dépérimétrisation, une stratégie de sécurité qui consiste en un système de sécurité segmenté et multicouche basé sur le chiffrement et l’authentification, incluant les ressources hors site. Plus proche de nous, le concept de « zéro confiance à l’accès réseau »( Zero Trust Network Access, ZTNA ) en reprend quelques principes, sous une forme plus médiatique, mettant l’accent sur l’authentification.
Selon le modèle « Jéricho », la sécurité est appliquée là où se trouvent les données et les traitements à protéger, c’est à dire au niveau applicatif de chaque service ( application, services Web etc. ).
Il ne faut pas concevoir l’authentification comme un moyen de suppléer à une mauvaise sécurité du réseau. Assurer la sécurité à travers les applications web exige que l’on ne puisse pas accéder directement aux données au niveau réseau. Le principe sera d’isoler les services dans un périmètre réduit ( résultant de la segmentation multicouche ), bien sécurisé au niveau réseau et accessibles seulement au niveau applicatif avec authentification. L’idéal serait de n’ouvrir au niveau réseau que les ports strictement nécessaires aux protocoles web, à la limite seulement HTTPS.

L’Usine du Futur sera sécurisée ou ne sera pas

Mais de quoi parle-t-on ? L’usine du Futur n’existe-t-elle pas déjà ? Les chaînes de construction automobile ne sont-elles pas déjà totalement informatisées et robotisées ? Le système CATIA ne permet-il pas de concevoir, développer et réaliser de nouveaux produits, son succès mondial témoignant de sa sécurité ? A l’évidence les grandes entreprises ont maîtrisé le sujet. Il est certain qu’elles ne sont pas sensibles à l’image médiatique, ayant les moyens d’étude nécessaires à la conduite de leur évolution.
Ce sont les TPE/PME qui se trouvent à la merci du tapage médiatique – y compris sur les revues « professionnelles » - et la cible de démarches commerciales mal adaptées. Ce sont elles qui doivent être accompagnées au cours de leur création ou de leur transformation.

Sûreté de fonctionnement, Contrôle des accès et Sécurité des données

Si on se réfère aux offres d’un marketing dominant, il faut s’en remettre à l’Internet pour délocaliser les données et les traitements dans le Cloud. Les données font alors le tour du monde : où et par qui sont-elles traitées, et par quelles applications ? Comment sont-elles protégées ?
Avant de répondre à ces questions, il faut définir la notion de Cloud .

Cloud ou Cloud privé ?

Il convient tout d’abord de distinguer :
- La définition initiale du Cloud qui est née de la virtualisation des traitements et du stockage des données chez les grands hébergeurs, permettant de mettre à disposition des abonnés des ressources virtuelles. Dans cette configuration, il s’agit de "Cloud privé" dont l’accès et la configuration sont sous le contrôle de l’entreprise ( ou a minima d’un sous-traitant de confiance ). Des offres telles que IBM Cloud, Amazone AWS ou OVH Private Cloud offrent les garanties de propriété attendues par les entreprises.
- Une externalisation générale des traitements et des données confiés à des sous-traitants extérieurs à l’entreprise, qui eux-mêmes peuvent faire appel à d’autres intervenants sans que ce soit identifiable et contrôlable par l’entreprise, ni même stable dans le temps. Parmi ces offres, il existe des services de données ou de traitement sans doute très commodes, mais dont la qualité et la pérennité est incontrôlable. L’opacité de cette configuration a conduit au terme de nuage, qui par un effet de sablier a été érigé au niveau d’un principe largement véhiculé par les médias.

Un enjeu de sécurité

Avec des données et des traitements distribués dans un tel Cloud, tous les enjeux de sécurité se situent hors de la portée de l’entreprise :
• Sécurité des accès : l’authentification des utilisateurs et des applications est déléguée hors du contrôle de l’entreprise.
• Sécurité des données des utilisateurs du public : peut-on réellement appliquer le RGPD ?
• Sécurité des données de l’entreprise non garantie, exposant à l’espionnage industriel et à la contrefaçon.
• Sauvegarde des données de l’entreprise : il lui est impossible de s’en assurer, au risque d’une perte totale.
De plus dans une telle configuration, la surface d’attaque est indéfinie et probablement immense.

Un enjeu de sûreté, de disponibilité et de rapidité de fonctionnement

• Sûreté de fonctionnement : trop de composants hors du champ d’action de l’entreprise, totalement contraire à toute démarche de qualité.
• Les processus industriels sont quasi temps réel. Des interruptions de service de quelques secondes, ou des temps de réponse présentant de temps en temps des valeurs inacceptables, peuvent déstabiliser une chaîne de production, voire provoquer son arrêt.
• La disponibilité des réseaux est également en question, en commençant par le raccordement de l’entreprise au réseau. Certes, le maillage de l’Internet assure la sûreté du transport à longue distance, mais le même problème de disponibilité se retrouve du côté des fournisseurs, à moins qu’il s’agisse de grands hébergeurs.

Pas totalement convaincu ? Voyez : David Heinemmeier Hansson : « Why we are leaving the cloud ».

"On premise" ou cloud privé ?

L’analyse ci-dessus conduit à :
- ne pas tout mettre dans un Cloud mal défini et hors contrôle, mais s’en tenir aux Cloud privés des grands hébergeurs, voire à un datacenter de proximité ( ou Cloud de proximité ),
- identifier les tâches sensibles aux délais de transmission ou d’interruption de service (voire aux attaques de déni de service) et les assurer localement (résilience),
- veiller à confier les tâches sensibles à des sous-traitants proches.

Une approche radicale de la résilience conduirait à distinguer un ensemble indépendant de machines, d’applications de contrôle et de gestion quotidienne de la production capable d’assurer la production sans connexion extérieure.

Quel choix pour un serveur d’authentification ?

Le principe de l’authentification avec OpenID Connect est que les applications délèguent le processus au serveur, le dialogue d’identification étant effectué directement entre l’utilisateur et le serveur, sans intervention de l’application. Il en résulte que toutes les données relatives à l’authentification des applications et des utilisateurs, leurs données personnelles et les données cryptographiques sont situées sur le serveur.
De plus, les échanges entre les différents pôles pour l’authentification se produisent très fréquemment au rythme des échanges de données et doivent être extrêmement rapides. Quelques dizaines de millisecondes est l’ordre de grandeur visé. Enfin, le serveur est le coopérant obligé de toute transaction sécurisée. Il doit donc être parfaitement disponible.

La sécurité et la sûreté imposent donc de situer le serveur d’authentification à proximité du réseau de l’entreprise.
Notons que pour le "sous-traitant proche" mentionné précédemment, il est équivalent de manager un serveur situé chez un grand hébergeur ou sur un cloud de proximité. Cette dernière option parait donc la bonne.