Comprendre l'authentification OPC-UA en environnement isolé
Un réseau isolé ne peut joindre une autorité de certification externe, ni télécharger une liste de révocation de certificats (CRL) depuis internet. Comment exécuter alors OPC-UA avec une authentification correcte lorsque toute l'infrastructure à clés publiques (PKI) doit résider à l'intérieur de l'enclave ? C'est le défi précis que traite cet article : mettre en oeuvre l'authentification OPC-UA dans des réseaux isolés (air-gapped) où les schémas connectés au cloud, supposés par la plupart des documentations, n'existent tout simplement pas.
La première chose à clarifier est qu'OPC-UA authentifie à deux niveaux distincts, et leur confusion est la première cause de mauvaise configuration. Le protocole sépare l'authentification de l'application, qui établit la confiance entre un processus client et un processus serveur, de l'authentification de l'utilisateur, qui établit l'identité de la personne ou du compte de service à l'origine d'une session. Ces deux niveaux sont définis dans le modèle de sécurité de l'OPC Foundation. Consultez OPC UA Part 2: Security Model pour la description normative de leur interaction, y compris le modèle de menaces contre lequel la norme a été conçue.
Niveau un : authentification de l'application par certificat d'instance
Toute application OPC-UA conforme, qu'elle soit cliente ou serveur, détient un certificat d'instance d'application (Application Instance Certificate). Il s'agit d'un certificat X.509 qui lie une clé publique à une instance logicielle précise, identifiée par son ApplicationUri. Lorsqu'un client ouvre un SecureChannel vers un serveur, les deux applications échangent leurs certificats et chacune décide si elle fait confiance à l'autre. Cette décision n'est pas prise en interrogeant un annuaire en ligne. Elle est prise localement, par rapport à une liste de confiance (trust list).
Une liste de confiance est l'ensemble de certificats, stocké sur disque, qu'une application accepte. Elle se divise en deux magasins. Le magasin de confiance contient soit les certificats feuilles des pairs auxquels vous faites explicitement confiance, soit les certificats d'autorité dont vous acceptez par chaîne les certificats émis. Le magasin d'émetteurs contient les certificats d'autorité intermédiaires et racines nécessaires uniquement pour compléter la validation de chaîne, ainsi que les CRL. Les mécanismes de cette validation, et la structure même de la liste de confiance, sont spécifiés dans OPC UA Part 6: Mappings, qui définit les formats de fichiers et les étapes de validation qu'une pile doit exécuter avant d'accepter un canal.
Dans un déploiement connecté, un Global Discovery Server (GDS) automatise la distribution des listes de confiance et l'enrôlement des certificats à l'échelle de l'usine. Dans un déploiement isolé, aucun GDS n'est joignable : la gestion des listes de confiance devient donc une opération manuelle et délibérée. C'est la différence architecturale centrale, et tout le reste de cet article en découle.
Niveau deux : authentification de l'utilisateur et jetons d'identité
Une fois que deux applications se font confiance et qu'un SecureChannel existe, le client ouvre une Session et présente un jeton d'identité utilisateur (user identity token). OPC-UA définit trois types de jetons, par niveau d'assurance croissant :
- Anonyme : aucune identité utilisateur n'est affirmée. La session n'hérite que des droits que le serveur accorde aux appelants non authentifiés. Acceptable uniquement pour des données non sensibles en lecture seule, et de préférence désactivé en production.
- Nom d'utilisateur / mot de passe : le client envoie un identifiant et un mot de passe chiffrés avec la clé publique du serveur. C'est simple, mais cela hérite de toutes les faiblesses opérationnelles des secrets partagés : rotation, stockage et risque de réutilisation entre systèmes.
- Certificat X.509 : l'utilisateur présente un certificat et prouve la possession de la clé privée. Cela offre une identité cryptographique par utilisateur, la révocabilité et une piste d'audit propre, au prix de la gestion d'une seconde population de certificats en plus de celle des applications.
Le point crucial pour la conception en environnement isolé est que ces deux niveaux sont indépendants. Vous pouvez activer la sécurité applicative SignAndEncrypt avec des jetons utilisateur Anonyme, ou un transport applicatif non sécurisé avec des jetons par nom d'utilisateur : ce sont deux mauvaises configurations. Une authentification forte sécurise les deux niveaux ensemble : des certificats d'application de confiance établissant un canal chiffré, puis un jeton utilisateur non anonyme établissant la responsabilité par-dessus.
Politiques de sécurité et SignAndEncrypt
La protection appliquée au SecureChannel lui-même est régie par le MessageSecurityMode et la SecurityPolicy choisie. Il existe trois modes de sécurité : None, Sign et SignAndEncrypt. None n'offre aucune protection et ne doit jamais être utilisé en dehors d'un laboratoire. Sign garantit l'intégrité et l'authenticité, mais laisse les charges utiles lisibles sur le réseau. SignAndEncrypt garantit l'intégrité, l'authenticité et la confidentialité, et constitue le seul mode adapté au trafic OT en production.
La SecurityPolicy sélectionne la suite cryptographique effective. Les anciennes politiques fondées sur SHA-1 et RSA-15, telles que Basic128Rsa15 et Basic256, sont obsolètes et doivent être désactivées. Les déploiements actuels doivent exiger Aes256_Sha256_RsaPss ou, lorsque c'est possible, les politiques fondées sur ECC. Le catalogue complet des politiques et de leurs primitives cryptographiques est tenu à jour dans OPC UA Part 2: Security Model. Verrouiller les serveurs sur SignAndEncrypt avec une politique moderne, et rejeter explicitement None ainsi que les suites obsolètes, ferme la principale voie de rétrogradation qu'un attaquant chercherait sinon à exploiter.
Gestion des certificats sans GDS dans le cloud
C'est ici que les déploiements isolés s'écartent nettement de la théorie. Sans autorité de certification joignable sur internet ni GDS en ligne, l'ensemble du cycle de vie des certificats doit être conçu comme un flux hors ligne.
Exploiter une autorité de certification hors ligne
Mettez en place une autorité racine dédiée et hors ligne à l'intérieur de l'enclave, sur du matériel qui ne touche jamais un réseau externe. Conservez la clé racine hors ligne et utilisez-la uniquement pour signer une autorité émettrice intermédiaire ; l'intermédiaire assure l'émission quotidienne. Cette conception à deux niveaux limite l'exposition de la clé racine et permet de révoquer puis réémettre l'intermédiaire sans reconstruire chaque point d'extrémité. Les recommandations du NIST sur la sécurité des systèmes de contrôle industriel considèrent ce type de PKI administrée en interne, avec une gestion des clés documentée, comme un contrôle de base pour les réseaux isolés. Consultez NIST SP 800-82 Rev. 3, Guide to Operational Technology Security.
Distribuer les listes de confiance manuellement
Comme aucun GDS n'est joignable, les listes de confiance sont diffusées manuellement. Exportez le certificat de l'autorité ainsi que les certificats d'application de chaque point d'extrémité, transférez-les au travers de l'enclave sur un support amovible contrôlé et analysé, conformément à votre procédure de gestion des supports, puis installez-les dans les magasins de confiance et d'émetteurs de chaque application. Traitez cette opération comme un changement contrôlé, avec un inventaire enregistré indiquant quel certificat réside sur quel point d'extrémité, car cet inventaire est la seule carte dont vous disposerez lors d'un incident.
Résoudre la révocation hors ligne
Les points de distribution de CRL et les répondeurs OCSP supposent tous deux une infrastructure joignable : aucun ne fonctionne au travers d'une enclave par défaut. Vous avez deux options réalistes. Soit générer les CRL sur l'autorité hors ligne et les distribuer au même rythme contrôlé que les listes de confiance, en acceptant que la latence de révocation soit égale à votre intervalle de distribution, soit, pour la posture la plus robuste, traiter la liste de confiance elle-même comme l'autorité de référence : retirer directement un certificat compromis de chaque magasin de confiance. Le NIST SP 800-82 et les recommandations plus larges du NIST SP 800-57 sur la gestion des clés soulignent tous deux qu'un processus de révocation doit exister et être testé, et pas seulement conçu, avant de s'appuyer sur la PKI.
Planifier le renouvellement autour des fenêtres de maintenance
Les certificats expirent, et un certificat d'application expiré rompt silencieusement un SecureChannel. Suivez de façon centralisée la fenêtre de validité de chaque certificat, planifiez la rotation avant l'expiration, et répétez la rotation lors d'une fenêtre de maintenance planifiée plutôt que de découvrir la dépendance en pleine production. Le renouvellement hors ligne est un cycle manuel de réémission et de redistribution : il faut donc prévoir un délai dans le calendrier de maintenance.
Assembler les niveaux
Un déploiement OPC-UA isolé défendable se présente ainsi en pratique. Les serveurs exigent le MessageSecurityMode SignAndEncrypt avec une SecurityPolicy moderne et rejettent tout ce qui est plus faible. Les certificats d'instance d'application sont émis par l'autorité intermédiaire hors ligne et présents aux deux extrémités, avec des listes de confiance ne contenant que les certificats qui s'y trouvent légitimement. Le jeton utilisateur Anonyme est désactivé, et les sessions s'authentifient par nom d'utilisateur ou, de préférence, par certificat X.509, afin que chaque action soit reliée à une identité. La révocation et le renouvellement suivent un rythme hors ligne documenté, appuyé par un processus testé.
Surmonter les difficultés courantes
Systèmes hérités
Les anciens points d'extrémité ne prennent parfois en charge que des politiques obsolètes, voire aucune sécurité de message. Plutôt que d'affaiblir toute l'usine pour s'y adapter, placez ces équipements derrière une passerelle qui termine un canal sécurisé à leur place, ou dans une enclave étroitement délimitée qui restreint qui peut les joindre. L'objectif est de contenir le maillon faible, non d'abaisser le niveau pour tout le reste.
Conformité et normes
Une PKI administrée en interne, une gestion des clés documentée et un processus de révocation testé correspondent directement aux contrôles attendus par des cadres tels que NIS2 et CMMC, ainsi qu'aux recommandations spécifiques à l'OT du NIST SP 800-82. Concevoir délibérément le cycle de vie hors ligne est aussi ce qui rend un audit propre possible par la suite.
Formation et sensibilisation
La distribution manuelle des listes de confiance et le renouvellement hors ligne sont des procédures, et les procédures échouent lorsque les personnes qui les exécutent n'en comprennent pas la raison d'être. Investissez dans les runbooks et la formation associée, car dans une PKI isolée, le processus humain est le contrôle.
Conclusion
À retenir : dans les environnements isolés, votre autorité de certification hors ligne et la discipline de votre distribution manuelle des listes de confiance sont les composants de sécurité les plus critiques. Maîtrisez la gestion des clés de l'autorité hors ligne, la procédure de distribution des listes de confiance, la voie de révocation et le calendrier de renouvellement avant de déployer l'authentification OPC-UA dans toute l'usine. Verrouillez chaque serveur sur SignAndEncrypt avec une politique moderne, désactivez l'accès anonyme et authentifiez les utilisateurs par certificat partout où c'est possible. Testez la rotation des certificats lors d'une fenêtre de maintenance, pas en production. Une fois la PKI hors ligne solide, le modèle de sécurité intégré d'OPC-UA est pleinement utilisable sans aucune connexion internet.
