OPC UA est sécurisé par conception. La plupart des déploiements ne le sont pas.
Le protocole intègre signature, chiffrement, identité applicative par certificat et authentification utilisateur nommée. Tout cela est optionnel, et les valeurs par défaut sont ouvertes. Ce guide explique ce que fait réellement le modèle de sécurité, quels réglages changent quoi, et comment protéger les serveurs qu'on ne peut pas reconfigurer.
Dernière mise à jour:
Qu'est-ce que la sécurité OPC UA, et pourquoi est-elle presque toujours désactivée ?
La sécurité OPC UA est un modèle à trois couches intégré au protocole : un transport, un SecureChannel qui signe et chiffre chaque message, et une Session qui porte l'identité utilisateur. Les trois couches sont optionnelles, et la plupart des produits sont livrés en SecurityPolicy None, MessageSecurityMode None et accès anonyme actif pour faciliter le premier démarrage. Presque toute faiblesse OPC UA rencontrée sur le terrain est un défaut de configuration et non une faille du protocole, ce qui la rend corrigeable.
OPC UA est le protocole qui relie un parc industriel : automates, variateurs, capteurs, SCADA et historians qui n'avaient pas été conçus pour se parler. Contrairement à Modbus, il a été pensé avec la sécurité dès le départ, et le modèle est réellement bon. Le problème est qu'il est en couches et optionnel. Un serveur peut annoncer un chiffrement fort et accepter malgré tout une session anonyme en clair sur le même port, parce que c'est ainsi que la plupart des produits sont livrés.
Pourquoi la plupart des serveurs OPC UA restent-ils non sécurisés ?
Quatre réglages par défaut expliquent l'essentiel de ce qu'un audit trouve en atelier. Aucun n'est une vulnérabilité de la spécification. Tous correspondent à l'état dans lequel un serveur se trouve quand la mise en service s'est terminée et que personne n'est revenu.
SecurityMode None en production
Un serveur laissé en SecurityPolicy None avec MessageSecurityMode None accepte des sessions en clair de quiconque atteint le port TCP 4840. On peut parcourir l'espace d'adressage, lire les valeurs de process en direct et très souvent écrire des consignes. La Fondation OPC destine None à la découverte et aux tests, pas au transport de données réelles. Si vous n'auditez qu'une chose ce trimestre, auditez cela. Avec SecurityPolicy None, il n'existe pas non plus de clé pour chiffrer le jeton d'identité : une authentification UserName envoie donc le mot de passe en clair UTF-8 sur le réseau (OPC UA Part 4, 7.40).
Accès utilisateur anonyme laissé actif
L'authentification applicative et l'authentification utilisateur sont distinctes. Un canal peut être cryptographiquement sain, avec des certificats valides des deux côtés, et admettre malgré tout une session anonyme par-dessus. Chiffrer le tuyau ne dit rien de qui se trouve à l'autre bout.
Certificats non fiables acceptés automatiquement
Accepter automatiquement les certificats est pratique pendant la mise en service et n'est très souvent jamais désactivé ensuite. Le paramètre s'appelle AutoAcceptUntrustedCertificates dans la pile de la Fondation OPC, souvent présenté comme trust-on-first-use dans les interfaces constructeur, alors qu'il est plus faible que ce nom laisse croire : il fait confiance à chaque certificat, à chaque fois, et pas seulement au premier vu. Un serveur dans cet état n'a plus aucune authentification applicative, quel que soit le mode de sécurité affiché.
Politiques dépréciées conservées par compatibilité
Basic128Rsa15 et Basic256 reposent sur SHA-1 et un padding RSA faible, et la Fondation OPC les a sorties de l'ensemble recommandé. On les laisse généralement annoncées pour qu'un vieux client continue de fonctionner, et les vieux clients continuent de les choisir.
Que peut faire un attaquant avec un serveur OPC UA ouvert ?
OPC UA est riche par conception : un client peut découvrir tout l'espace d'adressage, s'abonner aux valeurs en direct et appeler des méthodes. C'est précisément cette richesse qui rend un point de terminaison non authentifié intéressant pour un attaquant.
Reconnaissance de l'espace d'adressage
Le service browse est conçu pour être auto-descriptif. Un client non authentifié peut énumérer chaque nœud, son type de données et souvent le nom lisible du process qu'il pilote, produisant une cartographie de l'usine sans envoyer un seul paquet malveillant.
Écritures non autorisées sur les consignes
Là où le serveur expose des nœuds accessibles en écriture et n'exige aucune identité utilisateur, la session qui lit une valeur peut la modifier. Rien dans le protocole ne distingue un ingénieur de quiconque a atteint le port.
Repli silencieux en clair
Certains clients retombent en SecurityMode None quand la négociation sécurisée échoue, au lieu de refuser la connexion. Un attaquant capable de casser la négociation obtient du clair, et l'exploitant voit une connexion qui fonctionne.
Interception sur un réseau plat
En opc.tcp avec Sign seul, les charges utiles circulent lisibles. Valeurs de process, noms de tags et la forme du procédé sont visibles de tout ce qui se trouve sur le même segment. Les mots de passe font exception : la spécification impose au serveur de chiffrer séparément le jeton d'identité utilisateur dès que le canal n'est pas en SignAndEncrypt. Le défaut du mot de passe en clair relève donc de SecurityPolicy None et non de Sign.
Comment fonctionne le modèle de sécurité OPC UA ?
La sécurité OPC UA n'est pas un interrupteur. La spécification décrit trois couches qui coopèrent, et savoir à laquelle appartient un réglage donné constitue l'essentiel du travail.
- 01
Transport
La connexion qui transporte les octets. Pour le binding opc.tcp courant, il s'agit d'une socket TCP brute. Pour les bindings opc.https et opc.wss, c'est TLS.
- 02
Communication : le SecureChannel
Là où confidentialité et intégrité sont établies, indépendamment du transport. En opc.tcp, c'est UA-SecureConversation : il négocie les clés, signe les messages et les chiffre en option.
- 03
Application : la Session
S'exécute au-dessus d'un SecureChannel et porte l'authentification et l'autorisation utilisateur. Une session peut être ré-associée à un nouveau canal si la connexion tombe.
Quelle différence entre None, Sign et SignAndEncrypt ?
À l'ouverture d'un SecureChannel, le client choisit l'un des trois modes. Ils correspondent directement à la protection dont bénéficie le trafic.
| Mode | Intégrité | Confidentialité | Où c'est légitime |
|---|---|---|---|
| None | Aucune. Rien ne détecte l'altération. | Aucune. En clair sur le réseau. | Découverte et tests uniquement. Aucune place sur un point de terminaison en production. |
| Sign | Chaque message signé. L'altération est détectable. | Aucune. Charge utile lisible sur le réseau. | Cas étroit : quand l'intégrité compte et la confidentialité réellement pas. |
| SignAndEncrypt | Chaque message signé. | Complète. Charge utile chiffrée. | La valeur par défaut en production. Tout ce qui porte consignes, valeurs de process ou identifiants. |
Quelle SecurityPolicy OPC UA choisir ?
Une SecurityPolicy est l'ensemble nommé d'algorithmes qu'utilise un SecureChannel une fois Sign ou SignAndEncrypt sélectionné. Choisir une politique, c'est choisir sa force cryptographique.
| Politique | Algorithmes | Statut |
|---|---|---|
| Aes256_Sha256_RsaPss | AES-256, SHA-256, signatures RSA-PSS | Recommandation actuelle. À préférer partout où les deux extrémités la supportent. |
| Aes128_Sha256_RsaOaep | AES-128, SHA-256, RSA-OAEP | Actuelle, plus légère. Acceptable quand AES-128 suffit au besoin. |
| Basic256Sha256 | AES-256, SHA-256, signatures RSA PKCS#1 v1.5 | Largement déployée et encore acceptable. Choix raisonnable quand les politiques plus récentes ne sont pas disponibles des deux côtés. |
| Basic256 | AES-256, SHA-1, RSA-OAEP | Dépréciée par la Fondation OPC. Le padding est sain, mais SHA-1 n'est plus acceptable. Sa présence est un constat à corriger. |
| Basic128Rsa15 | AES-128, SHA-1, chiffrement RSA PKCS#1 v1.5 | Dépréciée par la Fondation OPC. Padding faible et empreinte cassée. Sa présence est un constat à corriger. |
Une étape d'audit concrète
Tout serveur OPC UA annonce les points de terminaison qu'il supporte via le service de découverte. Énumérez-les, vérifiez que le serveur propose une politique forte avec SignAndEncrypt, et que les politiques dépréciées sont désactivées ou ne sont pas celles que les clients choisissent réellement. Une liste de points de terminaison est la réponse honnête la plus rapide à « est-ce que c'est sécurisé ».
Quelles sont les méthodes d'authentification OPC UA ?
OPC UA authentifie à deux niveaux distincts, et les confondre est une source fréquente de fausse confiance. L'un demande si le logiciel à l'autre bout est connu. L'autre demande qui s'en sert.
Authentification applicative
Se situe au niveau du SecureChannel et répond à « cette application cliente et cette application serveur sont-elles bien ce qu'elles prétendent ? ». Chaque application détient un certificat d'instance X.509, et les deux côtés échangent et valident leurs certificats à l'ouverture du canal. La confiance est gérée par une liste de certificats de confiance : vous décidez quels certificats, ou quelle autorité émettrice, vous acceptez. C'est ce qui empêche une application inconnue d'établir un canal.
Authentification utilisateur
Se situe au niveau de la Session et répond à « quel humain ou quel service est à l'autre bout ? ». OPC UA supporte plusieurs types de jetons d'identité : Anonymous, qui n'a pas sa place en production, UserName avec mot de passe, et certificats utilisateur X.509. Un canal peut être cryptographiquement sain au niveau applicatif tout en admettant un utilisateur anonyme par-dessus.
Un point de terminaison correctement sécurisé fait les deux : il valide le certificat de l'application pair contre une liste de confiance gérée, et il exige une identité utilisateur nommée. Émettre, distribuer, faire confiance et renouveler ces certificats est le travail opérationnel qui rend tout cela réel, et c'est la partie que la plupart des équipes sous-investissent.
Où la sécurité OPC UA casse-t-elle sur le terrain ?
La plupart des incidents OPC UA relèvent de la configuration plutôt que d'une faille du protocole. Ces cinq-là représentent l'essentiel de ce qu'un audit remonte.
SecurityMode None en production
Le problème dominant, de loin, et le premier à vérifier.
Acceptation automatique de certificats non fiables
AutoAcceptUntrustedCertificates laissé actif en permanence, ce qui annule complètement l'authentification applicative.
Accès anonyme à côté d'un canal chiffré
Le canal est sain, la session grande ouverte, et les tableaux de bord affichent le point de terminaison comme sécurisé.
Politiques dépréciées encore annoncées
Conservées par rétrocompatibilité, puis choisies exactement par les vieux clients qui vous inquiétaient.
Repli silencieux en clair
Un client qui retombe en None quand la négociation sécurisée échoue, au lieu de refuser franchement la connexion.
Comment gérer les certificats OPC UA sans Global Discovery Server ?
L'authentification applicative d'OPC UA repose sur des certificats, et la réponse de la spécification à grande échelle est un Global Discovery Server (GDS, OPC UA Part 12). Beaucoup de parcs OT n'en déploient jamais : c'est un serveur de plus à exploiter, corriger et sauvegarder à l'intérieur du réseau de production, et un petit parc le justifie rarement. Les couches fonctionnent toujours, seule la distribution change.
Émettre depuis une autorité locale
Une CA sur site, ou des certificats d'instance auto-signés quand le parc est assez petit pour être énuméré. Ce qui compte est qu'un humain ait décidé quels certificats sont de confiance, pas qu'une CA publique se soit portée garante.
Remplir les listes de confiance délibérément
Chaque application tient sa propre liste de confiance. La remplir à la mise en service, puis désactiver AutoAcceptUntrustedCertificates, est ce qui transforme les certificats de décoration en authentification.
Planifier le renouvellement avant l'expiration
Les certificats expirent, et dans un parc isolé rien ne les renouvelle automatiquement. Une expiration que personne n'a suivie devient une panne un dimanche. Consignez dates d'émission et d'expiration dans le même runbook que le reste de l'état du réseau.
Ou déplacer le problème hors des équipements
Quand le travail de certificat par équipement n'est pas réaliste, terminer la session sur un proxy conscient du protocole permet à un seul composant de porter la PKI plutôt qu'à chaque équipement d'en porter un morceau.
Checklist de durcissement OPC UA : ce qu'il faut vérifier
La sécurité OPC UA se ramène à une liste courte et vérifiable. L'essentiel relève de la vérification plutôt que de la construction. Tout cela suppose une chose : que vous ayez le droit de modifier le point de terminaison. Quand ce n'est pas le cas, la section suivante couvre l'autre façon de combler les mêmes écarts.
- 01
Vérifier qu'aucun point de terminaison en production ne tourne en MessageSecurityMode None.
- 02
Exiger SignAndEncrypt pour tout ce qui porte données de process, consignes ou identifiants.
- 03
Choisir une SecurityPolicy actuelle, de préférence Aes256_Sha256_RsaPss, et retirer Basic128Rsa15 et Basic256.
- 04
Valider les certificats d'instance contre une liste de confiance gérée, et désactiver AutoAcceptUntrustedCertificates une fois la mise en service terminée.
- 05
Exiger une identité utilisateur nommée. Désactiver l'accès anonyme.
- 06
Vérifier que les clients refusent de se rabattre en clair plutôt que de retomber en None.
- 07
Se rappeler qu'en opc.tcp la protection est le SecureChannel, tandis qu'opc.https et opc.wss reposent sur TLS. Vérifier le binding avant de raisonner sur ce qu'un proxy ou une capture peut voir.
Ces contrôles se rattachent à l'identification et l'authentification IEC 62443 (FR1) et au contrôle d'usage (FR2), au NIST SP 800-82r3 pour les systèmes OT, et aux mesures de contrôle d'accès que l'article 21 de NIS2 impose aux entités essentielles et importantes.
OPC UA utilise-t-il TLS ?
En opc.tcp, ce qui protège vos données est le SecureChannel, pas TLS. Une connexion qui semble chiffrée n'utilise pas forcément TLS, car UA-SecureConversation assure sa propre signature et son propre chiffrement. TLS n'intervient qu'avec les bindings opc.https et opc.wss. Cela compte dès l'instant où vous raisonnez sur ce qu'un pare-feu, une capture réseau ou un proxy terminant TLS peut voir ou non.
Comment sécuriser un serveur OPC UA qu'on ne peut pas reconfigurer ?
La checklist suppose que vous pouvez modifier le point de terminaison. Souvent non : le constructeur l'interdit, la fenêtre de maintenance n'existe pas, ou le serveur est antérieur aux parties de la spécification que vous voulez appliquer. L'alternative est de placer la protection devant l'équipement, au niveau réseau, pour que le point de terminaison non sécurisé ne soit jamais joignable directement.
L'envelopper dans un tunnel transparent
Access Gate exploite sa propre PKI et émet les certificats terminaux à la volée. Le canal vers le Gate est en TLS 1.3 avec échange de clés post-quantique (ML-KEM-768), vérifié contre cette PKI, devant un serveur qui n'en parle rien, et sans travail de certificat équipement par équipement.
Refus par défaut, par identité et par protocole
Donner à un utilisateur l'accès OPC UA à un actif ne donne rien d'autre. Chaque protocole sur chaque actif est une autorisation explicite, ce que la session anonyme du serveur ne peut pas fournir.
Garder le serveur hors du réseau plat
Le point de terminaison se trouve dans une enclave segmentée et garde sa propre IP. Rien ne change sur l'équipement, et rien n'atteint le port TCP 4840 sans passer d'abord par la politique.
Enregistrer qui s'est connecté à quoi
Le proxy qui filtre le canal journalise la session : quelle identité, quel actif, quel protocole. C'est la preuve de contrôle d'accès que réclament in fine IEC 62443, NIST SP 800-82r3, NIS2 et CMMC.
Reprendre la main sur un serveur OPC UA sans y toucher
Si votre parc comporte des serveurs non reconfigurables, ou un travail de certificats irréaliste équipement par équipement, nous pouvons dérouler ensemble ce que donne le filtrage du canal sur votre réseau.
Configurer l'accès OPC UA
Le guide pas à pas : placer un serveur non sécurisé dans une enclave, puis sécuriser le canal par TLS, sécurité de message ou tunnel filtré.
Le voir sur votre parc
Une revue sur votre topologie : quels points de terminaison sont exposés, à quoi ressemble l'application des politiques, et ce que le déploiement demande.
Questions sur la sécurité OPC UA
Le port TCP OPC UA par défaut. Un point de terminaison à l'écoute ici en SecurityMode None est lisible, et souvent modifiable, par tout ce qui peut le router.
Seulement sur certains bindings. Les bindings opc.https et opc.wss reposent sur TLS. Le binding opc.tcp courant, non : il utilise UA-SecureConversation, la signature et le chiffrement propres au protocole au niveau du SecureChannel. Une connexion peut être entièrement chiffrée sans aucun TLS, ce qui compte quand vous raisonnez sur ce qu'un proxy terminant TLS ou une capture réseau peut voir.
Non. Le modèle de sécurité est solide mais chacune de ses couches est optionnelle, et la plupart des produits sont livrés en SecurityPolicy None, MessageSecurityMode None et accès anonyme actif pour faciliter le premier démarrage. Un serveur n'est sécurisé que si quelqu'un l'a configuré ainsi après la mise en service.
Sign apporte l'intégrité : chaque message est signé, donc l'altération est détectable, mais la charge utile reste lisible sur le réseau. SignAndEncrypt ajoute la confidentialité, la charge utile est également chiffrée. Pour du trafic OT en production, SignAndEncrypt devrait être la valeur par défaut ; Sign n'a qu'une place étroite, quand la confidentialité ne compte réellement pas.
Aes256_Sha256_RsaPss là où les deux extrémités la supportent, et Basic256Sha256 comme repli acceptable. Basic128Rsa15 et Basic256 sont dépréciées : elles reposent sur SHA-1 et un padding RSA faible, et la Fondation OPC les a sorties de l'ensemble recommandé. Si un serveur les annonce encore, traitez-le comme un constat plutôt que comme un réglage à préserver.
Placez la protection devant lui. Mettez le serveur dans une enclave segmentée pour qu'il ne soit pas joignable directement, et terminez la session sur un proxy conscient du protocole qui applique identité et politique avant de rétablir la connexion vers l'actif. L'équipement garde son IP, son firmware et sa configuration, et le chiffrement, le contrôle d'accès et la journalisation se font au point de passage plutôt que sur le point de terminaison.
