Sécurité OPC UA : ce que tout ingénieur OT devrait savoir

Pourquoi la sécurité OPC UA mérite votre attention

En tant qu'ingénieur en technologie opérationnelle (OT), vous savez tout ce qui repose sur les systèmes industriels. OPC UA (Open Platform Communications Unified Architecture) est devenu le protocole qui relie ces systèmes entre eux : automates, capteurs, variateurs, SCADA et historiens qui n'ont jamais été conçus pour partager un même réseau. La bonne nouvelle, c'est qu'OPC UA a été pensé pour la sécurité dès l'origine. La mauvaise, c'est que ce modèle est en couches et optionnel, ce qui signifie que la plupart des déploiements sur le terrain n'en activent qu'une partie, voire aucune. Savoir précisément ce qu'offre le protocole, et quel réglage change quoi, fait toute la différence entre un point d'accès durci et une porte ouverte.

Ce guide parcourt le modèle de sécurité OPC UA tel que la spécification le structure réellement, puis pointe les erreurs les plus fréquentes sur le terrain.

Le modèle de sécurité en couches

La sécurité OPC UA n'est pas une fonction unique que l'on active. Le document OPC Foundation Part 2 Security Model la décrit comme trois couches coopérantes, chacune résolvant un problème distinct :

1. Couche transport. C'est la connexion sous-jacente qui transporte les octets entre le client et le serveur. Pour le binding courant opc.tcp, le transport est une simple socket TCP. Pour les bindings HTTPS et WebSocket (opc.https, opc.wss), le transport est TLS.
2. Couche communication (le SecureChannel). C'est ici qu'OPC UA établit la confidentialité et l'intégrité de l'échange, indépendamment du transport. Sur opc.tcp, cette couche est assurée par UA-SecureConversation, définie dans OPC Foundation Part 6 Mappings. Elle négocie les clés, signe les messages et, en option, les chiffre.
3. Couche application (la Session). Une Session s'exécute au-dessus d'un SecureChannel et c'est là que résident l'authentification et l'autorisation de l'utilisateur. Un même SecureChannel peut porter une Session, et les Sessions peuvent être réassociées à un nouveau canal si la connexion sous-jacente est interrompue.

L'élément essentiel à retenir : sur opc.tcp, la sécurité qui protège vos données est le SecureChannel, et non TLS. On suppose souvent qu'une connexion « qui semble chiffrée » utilise forcément TLS, mais opc.tcp réalise sa propre signature et son propre chiffrement via UA-SecureConversation. TLS n'intervient que lorsque vous utilisez les bindings opc.https ou opc.wss. Cette distinction compte dès que vous raisonnez sur ce qu'un pare-feu, une capture de paquets ou un proxy de terminaison TLS peut voir, ou ne pas voir.

MessageSecurityMode : None, Sign, SignAndEncrypt

Lorsqu'un client ouvre un SecureChannel, il choisit un MessageSecurityMode. Il existe trois valeurs, qui correspondent directement à la protection réellement appliquée à votre trafic :

• None. Aucune signature, aucun chiffrement. Les messages circulent en clair et rien ne vérifie qu'ils n'ont pas été modifiés en transit. C'est l'équivalent d'utiliser le protocole portes ouvertes.
• Sign. Chaque message est signé : le destinataire peut détecter toute altération et confirmer que le message provient bien du détenteur de la clé négociée. Le contenu reste lisible sur le réseau, mais il ne peut pas être modifié en silence.
• SignAndEncrypt. Les messages sont à la fois signés et chiffrés. Vous obtenez ainsi l'intégrité et la confidentialité ensemble, et c'est le mode à privilégier pour tout ce qui transporte des consignes, des valeurs de procédé ou des identifiants.

Pour le trafic OT en production, SignAndEncrypt doit être le réglage par défaut. Le mode Sign seul a une place limitée, lorsque la confidentialité n'a véritablement pas d'importance mais que l'intégrité en a. Le mode None n'a pour ainsi dire aucune place en production, ce qui nous amène à l'erreur la plus fréquente sur le terrain.

Le piège du mode None

Le problème de sécurité OPC UA le plus fréquent n'est pas un exploit exotique. Ce sont des serveurs laissés sur SecurityPolicy=None, avec MessageSecurityMode=None et un accès utilisateur anonyme, exactement la configuration livrée par défaut par de nombreux produits pour faciliter le premier démarrage. Dans cet état, quiconque peut atteindre le port TCP (souvent le 4840) peut parcourir l'espace d'adressage, lire les valeurs de procédé en direct et, souvent, écrire des consignes, sans authentification ni chiffrement.

Ce n'est pas un risque théorique. C'est ainsi que fonctionne réellement une grande partie des serveurs OPC UA exposés sur Internet ou présents sur des réseaux à plat, parce que les modes sécurisés n'ont jamais été activés après la mise en service. Les recommandations de l'OPC Foundation dans l'article "Exploring OPC UA Security Concepts" indiquent explicitement que le mode None est destiné à la découverte et aux tests, et non au transport de données réelles. Si vous ne vérifiez qu'une seule chose ce trimestre, recherchez le mode None sur les points d'accès en production.

SecurityPolicies : quelle suite cryptographique est utilisée

Une SecurityPolicy est l'ensemble nommé d'algorithmes cryptographiques, le hachage, les chiffrements symétrique et asymétrique, les algorithmes de signature et de dérivation de clés, qu'un SecureChannel utilise une fois Sign ou SignAndEncrypt sélectionné. Choisir une politique, c'est choisir votre niveau de robustesse cryptographique. Celles que vous rencontrerez :

• Aes256_Sha256_RsaPss. La politique recommandée actuelle. Elle utilise AES-256, SHA-256 et des signatures RSA-PSS. Privilégiez-la lorsque les deux extrémités la prennent en charge.
• Basic256Sha256. Largement déployée et toujours considérée comme acceptable. AES-256 avec SHA-256 et signatures RSA-PKCS#1 v1.5. Un choix raisonnable lorsque la politique plus récente n'est pas disponible des deux côtés.
• Basic128Rsa15 et l'ancienne Basic256. Ces politiques sont dépréciées. Elles reposent sur SHA-1 et un remplissage RSA faible, et l'OPC Foundation les a retirées de l'ensemble recommandé. Considérez leur présence comme un point à corriger, et non comme une configuration à conserver.

Une étape d'audit pratique : énumérez les endpoints qu'un serveur annonce (chaque serveur OPC UA expose ses endpoints pris en charge via le service de découverte) et vérifiez qu'il propose une politique robuste avec SignAndEncrypt, et que les politiques dépréciées sont soit désactivées, soit non sélectionnées par les clients.

Authentification d'application et authentification d'utilisateur

OPC UA authentifie à deux niveaux distincts, et les confondre est une source fréquente de fausse confiance.

• L'authentification d'application intervient au niveau du SecureChannel et répond à la question : « cette application cliente et cette application serveur sont-elles bien celles qu'elles prétendent être ? » Elle repose sur des certificats d'instance d'application : chaque application détient un certificat X.509, et les deux parties échangent et valident leurs certificats lors de l'établissement du canal. La confiance est gérée via une liste de certificats de confiance de chaque côté ; vous décidez quels certificats (ou quelle autorité de certification émettrice) vous acceptez. C'est ce qui empêche une application inconnue d'établir un canal sécurisé.
• L'authentification d'utilisateur intervient au niveau de la Session et répond à la question : « qui, humain ou service, se trouve à l'autre extrémité ? » OPC UA prend en charge plusieurs types de jetons d'identité utilisateur : Anonymous (aucune identité d'utilisateur, à éviter en production), UserName/Password, et certificats utilisateur X.509. Un SecureChannel peut être cryptographiquement solide au niveau de l'application tout en admettant un utilisateur anonyme au niveau de la session ; les deux couches demandent donc de l'attention.

À retenir : un point d'accès OPC UA correctement sécurisé valide le certificat de l'application distante par rapport à une liste de confiance gérée, et exige une identité d'utilisateur nommée plutôt qu'un accès anonyme. La gestion des certificats, leur émission, leur distribution, leur mise en confiance et leur rotation pour les certificats d'application et d'utilisateur, est le travail opérationnel qui rend tout cela réel, et c'est aussi la partie que la plupart des équipes négligent.

Où se concentrent les écueils du terrain

La plupart des incidents OPC UA sur le terrain découlent de la configuration, et non de défauts du protocole :

• Le mode None en production, décrit plus haut, le problème dominant.
• L'acceptation automatique de certificats non approuvés. Certains déploiements configurent le serveur pour faire confiance à tout certificat qu'il rencontre (un « trust on first use » laissé activé en permanence), ce qui annule complètement l'authentification d'application.
• L'accès utilisateur anonyme laissé activé en parallèle d'un canal pourtant chiffré.
• Les SecurityPolicies dépréciées maintenues disponibles pour la compatibilité ascendante, puis sélectionnées par d'anciens clients.
• Le repli en clair lorsqu'un client passe silencieusement en mode None si la poignée de main sécurisée échoue, au lieu de refuser la connexion.

Ce sont précisément les faiblesses que des recommandations OT plus larges, comme le NIST SP 800-82, Guide to Operational Technology Security, vous invitent à détecter et à corriger : imposer l'authentification, protéger les données en transit et segmenter le réseau afin qu'un point d'accès non sécurisé ne soit pas directement joignable de partout.

Que faire concrètement

Vous disposez généralement de deux approches complémentaires. La première consiste à configurer correctement la sécurité OPC UA sur les points d'accès eux-mêmes : sélectionner une SecurityPolicy robuste, exiger SignAndEncrypt, valider les certificats d'application par rapport à une véritable liste de confiance et exiger une authentification d'utilisateur nommée. La seconde, pour les serveurs et clients hérités que vous ne pouvez pas reconfigurer, consiste à placer la protection devant l'appareil au niveau du réseau, en plaçant le serveur dans une enclave segmentée et en sécurisant le canal au moyen d'un tunnel filtré, de sorte que le point d'accès non sécurisé ne soit jamais directement exposé.

Sécuriser les points d'accès OPC UA qui ne peuvent pas se sécuriser eux-mêmes

Cette seconde approche correspond précisément à la lacune que Trout Access Gate est conçu pour combler. Plutôt que de provisionner et de maintenir des certificats sur chaque point d'accès, Access Gate termine la session au niveau d'un proxy conscient du protocole, applique l'identité et la politique, puis rétablit la connexion vers l'équipement. Ce point de passage unique permet d'ajouter du chiffrement, d'imposer le contrôle d'accès et de visualiser le trafic sans toucher au micrologiciel de l'appareil.

Pour un serveur OPC UA, ou tout protocole en clair ou hérité, cela signifie que vous pouvez :

• L'envelopper dans un tunnel TLS transparent. Access Gate exploite sa propre PKI et génère des certificats terminaux à la volée, de sorte qu'un appareil qui parle en clair sur le terrain peut être joint en toute sécurité sur un réseau plus large, sans travail de certificat appareil par appareil. Le guide Configurer le chiffrement TLS le détaille de bout en bout, et Le rôle de TLS dans la sécurisation d'OPC UA explique où TLS s'applique, ou non, à OPC UA.
• Refus par défaut selon l'identité et le protocole. Accorder à un utilisateur l'accès OPC UA à un équipement n'accorde rien d'autre ; chaque protocole sur chaque équipement est une autorisation explicite. Voir Cas d'usage de configuration des protocoles.
• Segmenter et observer. Le même proxy qui filtre le canal enregistre qui s'est connecté, à quoi et via quel protocole, soit la preuve que des cadres comme NIST 800-171, CMMC et NIS2 finissent par exiger. C'est le cœur de la sécurité réseau OT.

Conclusion

La sécurité OPC UA se résume à une courte liste vérifiable. Confirmez que les points d'accès en production ne tournent pas en mode None. Exigez SignAndEncrypt avec une SecurityPolicy actuelle telle qu'Aes256_Sha256_RsaPss, et retirez les politiques dépréciées comme Basic128Rsa15. Validez les certificats d'instance d'application par rapport à une liste de confiance gérée, et exigez une authentification d'utilisateur nommée plutôt qu'un accès anonyme. Rappelez-vous que sur opc.tcp, votre protection est le SecureChannel, tandis que opc.https et opc.wss reposent sur TLS. Presque toutes les faiblesses OPC UA que vous trouverez sur le terrain sont des lacunes de configuration, et non des défauts du protocole, ce qui signifie aussi que vous pouvez les corriger.